One document matched: draft-hancock-nsis-pds-problem-01.txt
Differences from draft-hancock-nsis-pds-problem-00.txt
Next Steps in Signaling R. Hancock
Internet-Draft Siemens/RMR
Expires: January 19, 2006 C. Kappler
Siemens AG
J. Quittek
M. Stiemerling
NEC
July 18, 2005
A Problem Statement for Path-Decoupled Signalling in NSIS
draft-hancock-nsis-pds-problem-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The NSIS working group is currently developing a protocol suite for
signalling which manipulates network state related to data flows.
The protocol architecture incorporates the constraint that the
signalling protocol will be processed on the nodes which also handle
Hancock, et al. Expires January 19, 2006 [Page 1]
Internet-Draft Path-Decoupled NSIS July 2005
the data flows themselves ("path-coupled signalling"). This document
discusses motivations for a relaxation of this constraint in a
particular class of scenarios, allowing the signalling and data paths
to be decoupled. It includes pointers to related work elsewhere in
the IETF and in other standardisation bodies, and includes a
recommendation for allowing a particular deployment mode for the NTLP
that can cover these types of architectures.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Centralised Policy Control . . . . . . . . . . . . . . . . 4
2.2 Intradomain Monitoring and Resource Management . . . . . . 5
3. Network Configurations . . . . . . . . . . . . . . . . . . . . 6
3.1 Baseline NSIS Operation . . . . . . . . . . . . . . . . . 7
3.2 NSIS with Policy Outsourcing . . . . . . . . . . . . . . . 7
3.3 Off-Path NSIS . . . . . . . . . . . . . . . . . . . . . . 8
4. Solution Components . . . . . . . . . . . . . . . . . . . . . 9
4.1 Signalling Backhaul . . . . . . . . . . . . . . . . . . . 10
4.2 Network Element Control . . . . . . . . . . . . . . . . . 11
4.3 Router Determination . . . . . . . . . . . . . . . . . . . 11
4.4 Off-Path Transport . . . . . . . . . . . . . . . . . . . . 12
4.5 Signalling Node Identification . . . . . . . . . . . . . . 12
5. Implications for the NSIS Transport Layer . . . . . . . . . . 13
5.1 Requirements at the NTLP Level . . . . . . . . . . . . . . 13
5.2 NTLP Protocol Architectures . . . . . . . . . . . . . . . 15
5.3 Modifying the GIMPS Path-Coupled MRM . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1 Normative References . . . . . . . . . . . . . . . . . . . 20
8.2 Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23
Hancock, et al. Expires January 19, 2006 [Page 2]
Internet-Draft Path-Decoupled NSIS July 2005
1. Introduction
The NSIS working group is currently developing a protocol suite for
signalling which manipulates network state related to data flows.
Requirements for such signalling are contained in [1][2][3] and a
framework which describes a layered protocol architecture is given in
[4]. The architecture consists of a lower layer which is common to
all signalling applications, the NSIS Transport Layer Protocol
(NTLP), and separate upper layer protocols which implement the
application specific logic, called NSIS Signalling Layer Protocols
(NSLPs). The current design of the NTLP is known as GIMPS [5], and
NSLPs for QoS signalling and middlebox control are given in [6] and
[7] respectively.
The current NSIS work concentrates on the so-called 'path-coupled'
case (see section 3.1.2 of [4]). Here the signalling messages pass
through a sequence of nodes which is a subset of the nodes (end hosts
and routers) on the path taken by the data flow being signalled for.
However, it has become clear that there is considerable interest in a
more flexible set of network configurations, where the signalling
still refers to current or future data flows but is less tightly
constrained to follow the flow path. The ability to arrange
components of the signalling solution in this way gives some
additional engineering flexibility which can be very valuable in
certain operational environments; this has been recognised in other
IETF activities such as PCE [8], IPFIX [9], and PSAMP [10], and also
in the signalling architectures assumed by other standardisation
bodies. Even when these other configurations are considered, it is
clear that there are still large elements of the overall signalling
solution that remain common, specifically the semantics of signalling
application transactions and the language in which state manipulation
is specified. Therefore, we believe that it is important to
investigate whether the NSIS protocols can be extended to cover these
scenarios, where no other solutions are available. This would have
the additional advantage that signalling solutions would not fragment
into 'on-path' and 'off-path' worlds - and that indeed, mixed
configurations could be commonplace, served by a single overall
protocol suite.
It is the purpose of this draft to give an overview of the
engineering motivations for path-decoupled signalling concepts, and
to begin to explore how they could be accommodated within the current
NSIS framework. The remainder of this document is structured as
follows. Section 2 describes some very high level usage scenarios,
explaining the motivations for the basic concepts of path-decoupled
signalling, and Section 3 places the key scenarios in a set of
concrete network configurations, showing the entities involved and
listing the components needing to make a complete solution.
Hancock, et al. Expires January 19, 2006 [Page 3]
Internet-Draft Path-Decoupled NSIS July 2005
Section 4 describes these components in more detail, and Section 5
describes a design approach based on a modification of the usage of
the NTLP. Security considerations are given in Section 6, and
finally Section 7 provides conclusions and recommendations.
2. Motivation
This section introduces various high-level scenarios to motivate the
use of off-path signalling for data flows, describing some of the
engineering advantages that can be achieved. The description is
high-level and not related to specific NSIS concepts or concrete
network configurations (these topics are introduced in Section 3,
which also discusses what additional functionality would be needed to
support such solutions). The discussion is focussed on the use of
some off-path entity to carry out some part of the signalling
operation, either for the purpose of centralisation of a particular
function, or to allow the support of new signalling functionality
without modification of existing routing infrastructure. There are
also other classes of off-path signalling, in particular signalling
initiation on behalf of end-hosts and signalling on multiple
candidate paths, but they are not the focus at this stage.
2.1 Centralised Policy Control
It is commonplace to want to be able to carry out some of the policy-
related processing needed for a signalling transaction on a node
separate from the routers themselves. There are several reasons for
this:
o The policy processing may be computationally demanding and very
variable in load. It therefore makes sense to decouple the
platform for this from the platform handling the user plane itself
so they can be scaled separately.
o The policy processing requirements may evolve independently from
(and probably more rapidly than) the basic resource signalling
requirements.
o The same policy processing may be needed for several nodes within
a single domain. Using a dedicated node for this therefore allows
some centralisation of resources, and also concentrates interfaces
towards other network functions (such as accounting).
Policy centralisation alone is not the main theme of this document,
since there are already a number of solutions available or under
consideration. However, most of the other path-decoupled scenarios
include similar characteristics and have the same motivations, and it
would be sensible for implementation approaches to re-use parts of
Hancock, et al. Expires January 19, 2006 [Page 4]
Internet-Draft Path-Decoupled NSIS July 2005
these solutions where possible. For example, centralised policy
control implies the ability to configure a router with the identity
of a policy controller, and the same is needed if a router is to be
configured with a controller for other aspects of the signalling
process.
2.2 Intradomain Monitoring and Resource Management
In many scenarios, as well as servers for outsourced policy control,
there are central nodes which maintain an overview of the resource
utilisation status of the network (this is particularly the
assumption in PCE work [13], for example). Such nodes are
commonplace in operator networks because they allow monitoring the
network status in order to take corrective action quickly if needed.
Under these circumstances, there are advantages if the signalling
protocol can be executed directly at the same nodes. More
concretely, we can model the overall resource management problem as
four components (compare e.g. figure 1 of the QoS-NSLP specification
[6]):
1. Operation of the signalling protocol state machine
2. Decision making about resource availability and allocation
(admission/policy control)
3. Finally, resource configuration in the user plane (which by
definition must take place on-path)
4. Some kind of transaction management to bind items (1-3) together
in the correct sequence
In the baseline NSIS model, all four components are colocated on-
path. Policy outsourcing moves some part of (2) off-path, but the
transaction control remains on-path and must bind together the
operation of the signalling and policy protocols, as well as the
actual resource configuration steps. The assumption of the
centralised resource management scenario is that all of (1) and (2)
and the synchronisation between them can be moved off-path to nodes
which manage a whole set of routers.
This model requires less precise synchronisation of transaction
management between the on/off path nodes than in the policy
outsourcing case. If the resource availability information is
already being gathered centrally for other reasons, the only
additional interaction is the resource configuration which can be
done in parallel for all on the on-path nodes, rather than having to
be done along the sequence of on-path nodes. It can also usually be
done asynchronously with the signalling transactions (unless for
Hancock, et al. Expires January 19, 2006 [Page 5]
Internet-Draft Path-Decoupled NSIS July 2005
example pre-emption is required). Even if specific resource
availability information has to be gathered, again this can be done
in parallel for all the on-path nodes. These two advantages -
firstly the parallelisation of the per-on-path node operation and
secondly the decoupling between signalling/control transactions and
resource configuration - allow centralised resource management to
achieve better overall control-plane performance than the policy
outsourcing approaches, but with the same benefits from the
independence between control and user plane implementations.
This scenario is also a highly attractive intermediate step when
migrating an administrative domain towards full NSIS support.
Typically, not all routers in a domain can be updated to NSIS or
replaced with NSIS-capable equipment at the same time. The scenario
allows support of NSIS towards the outside with only the edge routers
and the central controllers implementing this new protocol. The
internal support by all routers can be achieved at a later point in
time. Then the central control function concerning NSIS would become
obsolete.
The discussion so far concentrates on the intra-domain case.
However, logically the same approach is possible in the inter-domain
case also, and may be attractive if both domain operators are using
centralised management mechanisms. Such interdomain signalling is
likely to be associated with other operations such as AAA; therefore,
it is attractive if the signalling assocations involved are long-
lived and small in number (since they will be expensive to create and
manage). In particular, a route change at the node level which does
not affect the path at the interdomain level should not require the
creation and correlation of two interdomain signalling transactions.
Despite these arguments, we believe that the on-path configuration is
a sensible default architecture, and the addition of an off-path mode
of operation as an option should not impose extra costs on those who
do not wish to use it. Therefore, it is important that any off-path
solution design includes the automatic negotiation of its use as part
of the general procedures of the on-path case, and that if off-path
capability is not present (e.g. in a peer domain), the signalling
proceeds in the normal on-path manner without any degradation of
operation. This requirement is supported by the approach outlined in
Section 5.
3. Network Configurations
This section describes some reference network configurations, to
explain how the different components of the overall solution interact
when they are no longer constrained to all be colocated on the same
device. It highlights the differences from the current NSIS
Hancock, et al. Expires January 19, 2006 [Page 6]
Internet-Draft Path-Decoupled NSIS July 2005
operational model and indicates where additional functions are
needed.
3.1 Baseline NSIS Operation
The baseline NSIS configuration is that a (sub-)set of routers on the
data path also takes part in the signalling protocol, as shown in
Figure 1. This is true both within the domain and between domains.
Administrative Domain
+----------------------------------------------------+
| +----------+ |
| ******|Controller|****** |
| * +----------+ * |
| * * * * |
| * * * * |
| * * * * |
| +--*---+ +--*---+ +---*--+ +---*--+ |
-----| NSIS |--------------------| NSIS |------| NSIS |-----
#####|Router|######|Router|######|Router|######|Router|#####
| +------+ +------+ +------+ +------+ |
+----------------------------------------------------+
######### = data path
--------- = signalling messages
********* = configuration commands
Figure 1: Baseline NSIS Operation
The figure also shows the existence of a separate node issuing
configuration commands to the routers, and/or carrying out monitoring
of router operation. This can be seen as part of network management,
and is conceptually only loosely coupled to the signalling (the
signalling transactions about flows and network management
transactions to set up general router configuration are not directly
interrelated). It is therefore also considered as a possible part of
the baseline scenario.
3.2 NSIS with Policy Outsourcing
"Policy outsourcing" is the use of an external server to take
responsibility for certain stages of a signalling transaction. The
prime example is where the decision about whether a transaction (e.g.
allocation of a resource to a flow) is administratively allowed is
not taken on the router directly, but the router calls out to a
separate policy server and waits for a response to be returned before
continuing. This situation is shown in Figure 2 below. Many
variants can be built on this basic concept, with different subsets
of the NSIS routers calling out to the policy server; in addition, as
Hancock, et al. Expires January 19, 2006 [Page 7]
Internet-Draft Path-Decoupled NSIS July 2005
a side effect of the policy decision making, the policy server can
carry out configuration actions on other routers using network
management capabilities as discussed above.
Administrative Domain
+----------------------------------------------------+
| +----------+ |
| ?????| Policy |***** |
| ? | Server | * |
| ? +----------+ * |
| ? * * * |
| ? * * * |
| ? * * * |
| +------+ +--*---+ +---*--+ +---*--+ |
-----| NSIS |----------------------------------| NSIS |-----
#####|Router|######|Router|######|Router|######|Router|#####
| +------+ +------+ +------+ +------+ |
+----------------------------------------------------+
######### = data path
--------- = signalling messages
********* = configuration commands
????????? = policy requests/responses
Figure 2: Policy Outsourcing from Edge Routers
This type of policy outsourcing is not the main theme of this draft,
since there are already mechanisms to support it. In particular,
COPS has been defined as an outsourcing protocol for RSVP in [11],
and a Diameter extension has been proposed to accompany the NSIS QoS-
NSLP for policy support to the AAA function in [12]. However, policy
outsourcing concepts (and solution components) are relevant to
support some of the broader off-path scenarios considered below.
3.3 Off-Path NSIS
In this configuration, the signalling itself is allowed to go off-
path to nodes which handles policy control and resource
configuration. The simplest case - of a single node handling a whole
domain - is shown in Figure 3. Note that, unlike the policy
outsourcing case, there is no separate policy protocol shown. The
additional functionality needed compared to standard NSIS signalling
is the ability for the NSIS routers to discover the NSIS controller
(in this case, on ingress), and for the NSIS controller to discover
an on-path node to re-attach the signalling to the data path (in this
case, on egress).
There are several variants of this basic concept, for example the use
of multiple controllers to handle a particular domain which need to
Hancock, et al. Expires January 19, 2006 [Page 8]
Internet-Draft Path-Decoupled NSIS July 2005
discover and signal directly to each other. In the interdomain case,
there is the additional need for adjacent controllers to discover and
communicate with each other; this should be done using the same
procedures as in the single controller case.
Administrative Domain
+-------------------------------------------------+
| +----------+ |
| ---------| NSIS |--------- |
| / |Controller| \ |
| / +----------+ \ |
| / * * \ |
| / * * \ |
| +------+ +--*---+ +---*--+ +------+ |
-----| NSIS | | | | | | NSIS |-----
#####|Router|#####|Router|####|Router|#####|Router|#####
| +------+ +------+ +------+ +------+ |
+-------------------------------------------------+
######### = data path
--------- = signalling messages
********* = configuration commands
Figure 3: A Single Off-Path NSIS Node
4. Solution Components
The previous sections have outlined several possible network
configurations where processing of signalling messages takes place at
least partly off the data path. Implementing such configurations
requires solutions to several inter-related problems; some of these
may be considered as natural extensions to NSIS, while others may use
existing protocols or require additional work in some other forum.
This section presents a decomposition of the problem space as a set
of required components, indicating initial assumptions about how each
component could be implemented or developed.
There are several different ways to map the overall path-decoupled
signalling problem onto a set of components, and this section
presents only one of them. This is because the primary purpose is
not to mandate a particular set of architectures but simply to
identify what NSIS extensions would be useful, and where additional
functionality might be needed from other protocols. It also
demonstrates that most of the scenarios are achievable with those
extensions and existing protocol or management solutions. Further
discussion of the implications of such extensions for the NTLP in
particular is contained in Section 5.
Hancock, et al. Expires January 19, 2006 [Page 9]
Internet-Draft Path-Decoupled NSIS July 2005
4.1 Signalling Backhaul
Some scenarios maintain the sequence of nodes traversed by the NSIS
messages as in the standard (path-coupled) case; however, they allow
for some or all of the processing associated with the NSIS messages
to be carried out on a remote server. We can model this by saying
that NSIS continues to operate in a normal (path-coupled) manner;
however, the NSIS implementations themselves are allowed to be
distributed between the on-path router and supporting nodes.
Distribution in this manner requires two related functions:
Server Node Configuration: The node to which the router will
outsource the processing needs to be configured. Typically this
would be a network management operation on the router; a minimal
approach would be to configure an IP address for remote NSIS
processing.
Backhaul Protocol: A protocol is needed to transport the signalling
messages (or parts of them) between the router and the server
node.
There are many different levels at which the on-router and off-router
processing could be split. However, three particularly natural ones
can be identified.
IP Level: The IP packets carrying the signalling messages are
intercepted by the router and forwarded to the server with some
additional encapsulation. This approach may be particularly
appropriate for legacy environments, since it minimises the level
of NSIS awareness required in the router. Instead it uses only
custom forwarding for particular packet types, a capability which
is common in many routers in some proprietary form (e.g. for off-
board firewall processing, caching and so on). The implied
requirement is that the signalling packets must be recognisable by
the router without deep packet inspection, and the backhaul
transport must carry the information which a local NSIS
implementation would have exchanged with the IP layer (mainly,
what interface a message arrives/leaves on).
NTLP Level: Here, the NTLP is implemented locally on the router.
This approach allows new signalling applications to be deployed
without router modification, while still allowing closer
integration with the router's IP layer functionality, for example
to allow direct routing protocol interactions. The backhaul
transport would carry individual signalling messages (NSLP-Data
objects) along with the associated control information as given in
the GIMPS API.
Hancock, et al. Expires January 19, 2006 [Page 10]
Internet-Draft Path-Decoupled NSIS July 2005
NSLP Level: Here, each signalling application is implemented on the
router, but elements of the signalling application processing call
on a remote server. How this should be done depends very much on
the details of the application in question, and efficiency and
manageability considerations about how the processing should be
split. Solutions for particular cases already exist; for example,
the use of AAA protocols to outsource authorisation decisions, or
COPS for policy processing in RSVP.
The signalling backhaul approach seems to have minimal impact on the
existing NSIS protocol development. A separate protocol for carrying
the GIMPS API could be developed if backhaul at the NTLP level was
seen as desirable (although this could also be mapped directly onto
existing RPC standards); the other cases should be satisfiable with
proprietary or implementation specific approaches, or are highly
application specific. Unless the backhaul is carried out at the NSLP
level, a separate element control protocol is needed to perform the
associated configuration operations on the router itself; this is the
topic of the next subsection.
4.2 Network Element Control
Several of the network configurations require the ability to
transport element control commands from an off-path entity to routers
on the data path. The problem of how to work out which routers to
control in this way is discussed below in Section 4.3; here we
concentrate only on the mechanics of transporting the commands
themselves. Here, a general network management protocol might be
used (such as SNMP [14] or a proprietary command line interface); or,
for particular applications, a more specialised configuration
protocol, such COPS in provisioning mode [15] or the protocols under
development in netconf [16], ForCES [17] and GSMP [18]. It would
appear that such protocols are logically outside the scope of NSIS.
4.3 Router Determination
An element control protocol needs to operate on a target router. In
some configurations, the target router can be identified directly
(e.g. it is the location from which on-path signalling messages are
being forwarded); in others, it can be identified using external
information (such as topology data). However, where the purpose of
the configuration is to control a sequence of routers between a pair
of NSIS capable nodes in arbitrary topologies, this requires route
recording which is either inefficient (using traceroute) or not
possible (because some specific subset of routers is to be selected)
using current techniques. However, a specific NSIS extension could
be well tuned for such a role.
Hancock, et al. Expires January 19, 2006 [Page 11]
Internet-Draft Path-Decoupled NSIS July 2005
4.4 Off-Path Transport
Where the actual hop-by-hop signalling path goes off the data path, a
protocol is needed to transfer the signalling messages along that
signalling path. This problem can be seen in two parts: the
identification of the signalling nodes to carry out the transfer with
(the subject of the next subsection, Section 4.5), and the transfer
mechanism itself.
The requirements on the transfer mechanism are not logically distinct
from the transfer requirements on the base NTLP. For example, there
should be the same needs for flow and congestion control and
reliability of the transfer, and also for message integrity and
confidentiality. The same questions about how to handle the
multiplexing of small messages, or multiplexing between several
sessions or logically independent signalling applications would also
arise.
Because of these considerations, it would seem natural to regard the
off-path transport as being an NSIS extension; in particular, an off-
path transport protocol should expose essentially the same API to
signalling applications as is done by GIMPS, with the same semantics.
4.5 Signalling Node Identification
If signalling messages are to be directed to an off-path node, the
question naturally arises: which one? A related question is that of
how to re-attach the signalling path to the data path. In fact,
three cases can be identified:
Divergence: An on-path node needs to identify its neighbour along the
signalling path, and that node is off-path. The on-path node
could be provisioned with a server as in the signalling backhaul
case; or, the peer could be selected using a modification of the
RSVP-like query mechanism used in GIMPS (returning some other peer
address than that of an on-path router). The mode of operation
could be dependent on the interface that the flow takes (e.g. to
select off-path operation only for 'domain-internal' operation).
Propagation: An off-path node needs to identify its neighbour along
the signalling path, and that node is off-path. The fundamental
question here is what criteria are used to define the off-path
neighbour. Several possibilities can be conceived:
* The peer is defined functionally, that is, on the basis of
support for a particular signalling application or role.
Routing of signalling messages would probably have to be
configured statically by management, since there would be no
Hancock, et al. Expires January 19, 2006 [Page 12]
Internet-Draft Path-Decoupled NSIS July 2005
dependence on the flow in question or the underlying network
topology.
* The peer is defined with respect to the remainder of the flow
path beyond the set of routers under 'local' control. This is
a combination of the 'divergence' case (above) and
'convergence' case (below), since the discovery process depends
on the local topology and has to take place in the context of
the current path.
Convergence: An off-path node needs to identify its neighbour along
the signalling path, and wishes that node to be on-path (e.g. for
compatibility with a peer domain). The discovery process must be
path-coupled in some sense, and in particular must take account of
the flow path even in the off-path region. Note that there are
security aspects to be considered here, since the off-path node
could be detected as an off-path attacker in some scenarios,
rather than a bona fide signalling peer.
In general, the peer discovery problem appears to be the most complex
part of the off-path signalling story, because of the wide variety of
discovery mechanisms that can be considered, and also because of the
intrinsic hardness of the problem (because of the interactions with
network topology and the expectation of needing to maintain
compatibility with the pure path-coupled case). However, it also
seems that it would have to be considered at least partly within the
NSIS problem scope, both because the equivalent problem is clearly an
NTLP problem in the path-coupled case, and also because of the
compatibility issue just mentioned. Even if some aspects of the
configuration of the set of off-path signalling nodes could be
considered as network management problems, the topological
interactions cannot. The following section describes a solution to
this problem within the current GIMPS design.
5. Implications for the NSIS Transport Layer
In this section we consider how to handle the additional requirements
on the NTLP for path-decoupled operation compared to the current
functionality of GIMPS. The discussion is divided into a summary of
the requirements, the basic implementation options, and specific
considerations for modifying GIMPS itself.
5.1 Requirements at the NTLP Level
These requirements can be summarised as follows:
1. Transfer of signalling messages between off-path nodes, with a
service that preserves the transport and security semantics of
Hancock, et al. Expires January 19, 2006 [Page 13]
Internet-Draft Path-Decoupled NSIS July 2005
the GIMPS API as far as possible.
2. Off-path 'server' discovery given an on-path node as context.
3. Off-path 'server' discovery from an off-path node.
4. On-path node discovery from an off-path node.
Of these requirements, the message transfer is not conceptually
difficult, since we have a worked example in GIMPS itself.
The most challenging parts of the problem for the NTLP are the node
discovery aspects. The two basic options are:
o to intercept and modify the existing RSVP-like discovery
mechanism. These discovery messages are still sent along the data
flow path, but their return values are modified to point to off-
path nodes. This requires some minimal functionality in the
controlled routers, at least to process the discovery messages or
forward them to some other node capable of doing so, but maintains
the linkage between signalling and routing.
o to use a totally separate mechanism to look up signalling peers
based on flow identification and other information (signalling
application, location within the network). This may be the ideal
approach for some scenarios (e.g. forwarding signalling messages
between nodes with different roles), but in general it is hard to
make such techniques automatically topology aware without major
work to integrate with routing protocol operation, or
alternatively the restriction to particular topologies such as
stub (single-homed) networks.
We can also consider the additional functionality of route recording
(Section 4.3) here, since it is not specific to any given signalling
application, even though it may not be a core NTLP component. It
could be provided using a generic object to be processed at the NSLP
level. Either a new signalling application could be defined for
precisely this purpose - indeed, an version of such an application
has already been developed as part of the other NSIS work in [20] -
or the object could be piggybacked in a message of the signalling
application to be processed off-path; there are several detailed
design choices to be made, depending on whether the set of
intermediate nodes has to be reported to one or both peers. However,
these choices are mainly a matter of object design rather than
affecting the overall signalling architecture.
Hancock, et al. Expires January 19, 2006 [Page 14]
Internet-Draft Path-Decoupled NSIS July 2005
5.2 NTLP Protocol Architectures
In this section we consider how an off-path NTLP should relate to the
current on-path NTLP as implemented by GIMPS. There are three
possible approaches.
Conceptually the simplest is to make a new off-path NTLP which
exposes the same API as GIMPS. This is at least theoretically
possible within the overall NSIS architecture, because the NTLP has
only single-hop scope, and only signalling applications see the
relationships along the sequence of NTLP hops, and even then only via
the API. However, this would imply the assumption of a firm division
between on- and off-path modes of operation - for example, a node
would have to decide in advance which mode to signal in, and this
information would have to be configured. It also implies a second
NTLP design with costs in protocol development, implementation and
testing.
A second approach is to use the modular structure of GIMPS to replace
only the parts directly affected by the off-path operation. Based on
the above discussion in Section 5.1, the main changes are needed in
the message routing area. GIMPS already has the concept of
interchangeable 'message routing methods' (MRMs), originally
introduced to allow for signalling about other types of entity than
flows. The basic path-coupled MRM (which uses an on-path query/
response exchange carried in packets emulating the flow being
signalled for) could be complemented by a path-decoupled MRM which
used the same flow identification but a different lookup algorithm
(e.g. based on static configuration or integration with routing
protocols or some external lookup service). What is open here is
whether this MRM should be distinguished at the API level (and hence
have to be explicitly selected by signalling applications at the API)
or whether it should just be regarded as an alternative
implementation of the path-coupled MRM itself, whose use is not
visible to the signalling applications.
The third approach is to modify the processing of the GIMPS path-
coupled MRM, to give a similar effect as path-decoupled operation.
This requires some level of GIMPS implementation in all the on-path
nodes, but maintains automatic integration with the network topology,
and also allows a node to support path-coupled and path-decoupled
modes simultaneously and automatically. Applicability of this design
approach depends on the way that GIMPS is decomposed into datagram-
(D-) and connection- (C-) modes. A worked example of the use of
GIMPS in this way is given in the next subsection.
Hancock, et al. Expires January 19, 2006 [Page 15]
Internet-Draft Path-Decoupled NSIS July 2005
5.3 Modifying the GIMPS Path-Coupled MRM
This section shows two modes of GIMPS operation where the normal
discovery process is modified to allow off-path signalling.
The first case is shown in Figure 4. Here, the upstream node sends a
normal GIMPS-Query and receives a normal GIMPS-Response containing
addressing information about the downstream signalling peer with whom
it subsequently sets up a messaging association. The modification
has taken place at the downstream peer, where the on-path node has
arranged to send a GIMPS-response containing addressing information
for the off-path node. (In the figure, this is done by forwarding
the initial Query to the off-path node which generates the Response
itself. Other configurations are possible, e.g. where the on-path
node generates the Response itself but with modified addressing
information. The configuration shown has the advantage that the off-
path node determines directly which on-path node is responsible for
the flow being signalled about.)
On the assumption that all signalling application communication takes
place over the messaging association that has been set up, and no
signalling application data is carried in the initial D-mode
exchange, this results in something functionally equivalent to off-
path signalling with a specific framework for the discovery process
(essentially, any rule that can be configured into the downstream on-
path node for selecting a server).
Hancock, et al. Expires January 19, 2006 [Page 16]
Internet-Draft Path-Decoupled NSIS July 2005
+----------+
|Signalling|
| Appl. |
Messaging association +----------+
##########################>>| |
# | GIMPS |
# | C/D-mode |
# ....................| |
# . GIMPS-response +----------+
# . ^ *
+----------+ # . . *
|Signalling| # . . *
| Appl. | # . . *
+----------+ # . . *
| |<<########## . . V
| GIMPS | . +-.--------+
| C/D-mode |<................... GIMPS-query | . GIMPS|
| |.......................................... D-mode|
+----------+ +----------+ +----------+ +----------+
| IP | | IP | | IP | | IP |
|Forwarding| |Forwarding| |Forwarding| |Forwarding|
| | | | | | | |
---------------------------------------------------------------------->
+----------+ +----------+ +----------+ +----------+
---------> = Data flow (and direction)
.........> = GIMPS D-mode messages (and direction)
<<######>> = GIMPS C-mode messages (bidirectional)
*********> = Control (off-path node to router)
Figure 4: Discovering a Downstream Off-Path Node
The converse case is where an off-path node itself needs to signal
downstream. That case is shown in Figure 5. The general concept is
as before, except that in this case the D-mode exchange is initiated
from the off-path node but routed via its on-path node for that flow.
Note that the addressing information included has to refer to the on-
path node itself (since this would normally be validated by the
downstream peer and also used to detect some types of route changes),
so the GIMPS-response is also sent through the on-path node.
However, the messaging association setup itself can take place
directly from the off-path node, leading to the same eventual
configuration as before.
Hancock, et al. Expires January 19, 2006 [Page 17]
Internet-Draft Path-Decoupled NSIS July 2005
+----------+
|Signalling|
| Appl. |
+----------+
| | Messaging Association
| GIMPS |<<##########################
| C/D-mode | #
| | #
+----------+ #
* . ^ #
* . . # +----------+
* . . # |Signalling|
V . . # | Appl. |
+-------.-.+ # +----------+
| . .| GIMPS-response ##########>>| |
|GIMPS . .........................................| GIMPS |
|D-mode . | GIMPS-query | C/D-mode |
| ...|......................................>| |
+----------+ +----------+ +----------+ +----------+
| IP | | IP | | IP | | IP |
|Forwarding| |Forwarding| |Forwarding| |Forwarding|
| | | | | | | |
---------------------------------------------------------------------->
+----------+ +----------+ +----------+ +----------+
---------> = Data flow (and direction)
.........> = GIMPS D-mode messages (and direction)
<<######>> = GIMPS C-mode messages (bidirectional)
*********> = Control (off-path node to router)
Figure 5: Discovering a Downstream Node from an Off-Path Node
The implication of these two analyses is that at least some of the
cases for off-path node discovery can be implemented within the
current GIMPS design in a way which eases interworking with pure on-
path configurations. At least some GIMPS functionality has to be
implemented in the on-path node (to carry out partial processing and
redirection of D mode messages), but even this can be offloaded using
low-level backhaul techniques as discussed in Section 4.1. It should
also be noted that this technique cannot handle all off-path
scenarios, in particular those where additional configuration is
needed to shuffle messages along a sequence of off-path nodes, or
where preconfigured message routing is needed for discovery in the
upstream direction (which is a problem even in the on-path case), and
in some cases different lookup mechanisms may be more appropriate or
Hancock, et al. Expires January 19, 2006 [Page 18]
Internet-Draft Path-Decoupled NSIS July 2005
efficient. However, it could serve as a robust default mechanism for
general topologies.
6. Security Considerations
Any redistribution of functionality within an architecture introduces
new security problems and mitigates some old ones. However, the
path-decoupled problem space discussed here mostly overlaps with the
existing work being carried out within NSIS, since the interactions
within and between signalling applications, and the interactions
between signalling applications and other elements in the network,
are mostly unchanged. The main new aspect from a security
perspective is the protocol or protocols between the off-path
controller and the router, the vulnerabilities of which need to be
considered in any overall security evaluation. The various
centralisation options introduce extra node types into the picture,
but probably reduce the overall number of them involved; it is not
clear whether the net impact of these changes on network security is
positive or negative, but it clearly depends mainly on the design of
any new protocols required, which in turn depends on the ability to
make sensible assumptions about what trust and authority
relationships can be required between these nodes.
7. Conclusions
This draft has provided an overview of the problem space for path-
decoupled signalling in the NSIS problem space, including the
engineering motivations for such approaches and considerations of
scenarios where they may be applicable. It has also presented a
decomposition of the problem space into a set of component parts,
with some discussion for each of whether these require new
development or could be satisfied using existing protocols. A
minimal solution was identified, with the following components:
1. A backhaul protocol to carry Query messages from on-path routers
to off-path NSIS controllers, and configuration of the on-path
router with its controller. (This could be as simple as a
particular usage of GRE.)
2. The ability to deploy GIMPS such that its routing state and hence
D-mode connections refer directly to off-path nodes. (It is not
clear at the moment that this requires any formal changes to the
specification at all, although the usage is clearly a
modification.)
3. A mechanism to discover (route-record) the sequence of routers
between two on-path nodes.
Hancock, et al. Expires January 19, 2006 [Page 19]
Internet-Draft Path-Decoupled NSIS July 2005
It is our conclusion that a small number of relatively precisely
scoped extensions to existing NSIS (in particular, NTLP)
functionality could be used to enhance the performance and usability
of the NSIS protocol suite in several important networking
environments, and in particular could ease deployment and
interworking with other networks that attach to the Internet. We
therefore recommend that the working group should consider taking on
this work.
8. References
8.1 Normative References
[1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004.
[2] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
"Middlebox Communications (midcom) Protocol Requirements",
RFC 3304, August 2002.
[3] Chaskar, H., "Requirements of a Quality of Service (QoS)
Solution for Mobile IP", RFC 3583, September 2003.
8.2 Informative References
[4] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005.
[5] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06
(work in progress), May 2005.
[6] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-
of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in
progress), February 2005.
[7] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress),
May 2005.
[8] "Path Computation Element (pce) Charter,
http://www.ietf.org/html.charters/pce-charter.html", 2005.
[9] "IP Flow Information Export (ipfix) Charter,
http://www.ietf.org/html.charters/ipfix-charter.html", 2005.
[10] "Packet Sampling (psamp) Charter,
Hancock, et al. Expires January 19, 2006 [Page 20]
Internet-Draft Path-Decoupled NSIS July 2005
http://www.ietf.org/html.charters/psamp-charter.html", 2005.
[11] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A.
Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[12] Alfano, F., "Diameter Quality of Service Application",
draft-alfano-aaa-qosprot-02 (work in progress), February 2005.
[13] Farrel, A., "Path Computation Element (PCE) Architecture",
draft-ietf-pce-architecture-00 (work in progress), March 2005.
[14] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing Simple Network Management Protocol (SNMP)
Management Frameworks", STD 62, RFC 3411, December 2002.
[15] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS
Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[16] "Network Configuration (netconf) Charter,
http://www.ietf.org/html.charters/netconf-charter.html", 2005.
[17] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding
and Control Element Separation (ForCES) Framework", RFC 3746,
April 2004.
[18] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
"General Switch Management Protocol (GSMP) V3", RFC 3292,
June 2002.
[19] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to
RSVP-TE for LSP Tunnels",
draft-ietf-mpls-rsvp-lsp-fastreroute-07 (work in progress),
September 2004.
[20] Juchem, I., "A stateless Ping tool for simple tests of GIMPS
implementations", draft-juchem-nsis-ping-tool-01 (work in
progress), May 2005.
Hancock, et al. Expires January 19, 2006 [Page 21]
Internet-Draft Path-Decoupled NSIS July 2005
Authors' Addresses
Robert Hancock
Siemens/Roke Manor Research
Old Salisbury Lane
Romsey, Hampshire SO51 0ZN
UK
Email: robert.hancock@roke.co.uk
Cornelia Kappler
Siemens AG
Siemensdamm 62
13627 Berlin
Germany
Email: cornelia.kappler@siemens.com
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Email: quittek@netlab.nec.de
Martin Stiemerling
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Email: stiemerling@netlab.nec.de
Appendix A. Acknowledgements
Sven van den Bosch of Alcatel contributed to several sections of this
draft. We would also like to thank Adrian Farrel for his comments
from a CCAMP perspective, and Bob Braden for a deep review of the
fundamental architectural implications of off-path approaches.
Eleanor Hepworth also provided review comments.
Hancock, et al. Expires January 19, 2006 [Page 22]
Internet-Draft Path-Decoupled NSIS July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hancock, et al. Expires January 19, 2006 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-23 08:52:11 |