Next Steps in Signaling R. Hancock
Internet-Draft Siemens/RMR
Expires: August 25, 2006 C. Kappler
Siemens AG
J. Quittek
M. Stiemerling
NEC
February 21, 2006
A Problem Statement for Partly-Decoupled Signalling in NSIS
draft-hancock-nsis-pds-problem-03
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 August 25, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The NSIS working group is currently developing a protocol suite for
signalling which manipulates network state related to data flows.
The protocol design incorporates the constraint that the signalling
protocol will be processed on the nodes which also handle the data
Hancock, et al. Expires August 25, 2006 [Page 1]
Internet-Draft Partly-Decoupled NSIS February 2006
flows themselves ("path-coupled signalling"). This document
discusses a particular deployment mode for GIST (the common lower
layer of the NSIS protocol suite) which relaxes this constraint,
allowing the signalling and data paths to be partially decoupled,
without sacrificing the integration with routing (e.g. sensitivity to
route changes) which is intrinsic to the path-coupled case.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Off-Path Signalling . . . . . . . . . . . . . . . 4
2.1. Baseline NSIS Operation . . . . . . . . . . . . . . . . . 5
2.2. Signalling Protocol Outsourcing . . . . . . . . . . . . . 6
2.3. Route Computation . . . . . . . . . . . . . . . . . . . . 7
2.4. Off-Path NSIS . . . . . . . . . . . . . . . . . . . . . . 8
3. A Partly-Decoupled GIST . . . . . . . . . . . . . . . . . . . 9
3.1. Requirements at the NTLP Level . . . . . . . . . . . . . . 10
3.2. NTLP Protocol Architectures . . . . . . . . . . . . . . . 10
3.3. Modifying the GIST Path-Coupled MRM . . . . . . . . . . . 11
3.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Supporting Protocol Functionality . . . . . . . . . . . . . . 15
4.1. GIST Backhaul . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Network Element Control . . . . . . . . . . . . . . . . . 16
4.3. Router Determination . . . . . . . . . . . . . . . . . . . 17
4.4. Off-Path Transport . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Hancock, et al. Expires August 25, 2006 [Page 2]
Internet-Draft Partly-Decoupled NSIS February 2006
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 [3][4][5] and a
framework which describes a layered protocol architecture is given in
[6]. 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 GIST specification [2] provides a design for the NTLP,
and NSLPs for QoS signalling and middlebox control are given in [7]
and [8] respectively. The current NSIS work concentrates on the so-
called 'path-coupled' case (see section 3.1.2 of the framework [6]).
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 which the signalling refers to. The flow may be
already active, or expected some time in the future; the signalling
itself defines the flow in terms of a set of header fields,
regardless of whether packets are actually flowing or not.
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 [9], IPFIX 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 with the strict path-coupled case, including at
least 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.
This draft gives an overview of the engineering motivations for path-
decoupled signalling concepts, and explains how they can be
accommodated within the current NSIS framework. There are many
different aspects of the general signalling problem, many of which at
one time or another have been referred to as 'off-path' and most of
Hancock, et al. Expires August 25, 2006 [Page 3]
Internet-Draft Partly-Decoupled NSIS February 2006
which overlap in some way. However, this draft focusses on a
specific case, based on a modification to the operation of the lower
NSIS protocol layer (GIST). It is likely that this approach could be
captured as an Applicability Statement in the sense of RFC2026 [1].
The remainder of this document is structured as follows. Section 2
gives a very high level outline of the overall problem space and
identifies the aspect we are mainly concerned with, in order to place
this draft in proper context. Next, Section 3 describes the design
approach based on a modification of the usage of GIST (the NTLP).
Necessary supporting protocol functionality is described in
Section 4. Security considerations are given in Section 5, and
finally Section 6 provides conclusions and recommendations.
2. Overview of Off-Path Signalling
Compared to the basic case of path-coupled signalling (which is
recapped in Section 2.1 below), three distinct off-path signalling
scenarios can be distinguished:
o Simple outsourcing: all the signalling is strictly on-path, but an
on-path node is allowed to call out to some other server to
perform part of the control operation. This approach was
initially developed for policy control, the topmost layer of the
signalling protocol stack, but can be applied at any layer.
o Route computation: in this case, the data flow routes themselves
are set up explicitly, according to paths calculated by some off-
path server. This is typically considered in a traffic
engineering context, e.g. for networks based on MPLS or its
extensions.
o Path-decoupled signalling: here, on some segments of the end to
end path, some of the signalling messages are transferred directly
towards nodes off the data path, and are not constrained to pass
through on-path routers. Often, the off-path node is controlling
the set of routers on the path segment bypassed by the signalling.
The first two of these have some relationship to the third "path-
decoupled" case, in that they have similar motivations, and there can
also be operational advantages if they are used together; some
examples are given below. However, the protocol support required is
largely distinct in each case; in that sense, these three problems
are orthogonal. The focus of this draft is on the final (path-
decoupled) case itself, since the other two are already extensively
covered in other work inside and outside the IETF.
Hancock, et al. Expires August 25, 2006 [Page 4]
Internet-Draft Partly-Decoupled NSIS February 2006
2.1. Baseline NSIS Operation
This section describes the baseline NSIS configuration as a starting
point for the following discussions. In this case, a (sub-)set of
routers on the data path also takes part in the signalling protocol,
as shown in Figure 1. This applies both within a single
administrative/operational domain, and also between domains. The
transport of messages along the sequence of on-path nodes is carried
out by GIST, using its default message routing method, the path-
coupled MRM; in other words, these are signalling messages 'about' a
data path. (Here and in what follows the discussion is restricted to
the path-coupled MRM, and ignores other possible GIST MRMs.)
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 interacting with the signalling, in
that 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 covered by the
baseline scenario.
Note that in this scenario (as in the next), we do not distinguish
between the data forwarding elements in the network, and the elements
that set up the forwarding tables (e.g. by operating dynamic routing
protocols or other means). We are considering only 'classical'
routers, where routing protocol operation and data forwarding are
colocated.
Hancock, et al. Expires August 25, 2006 [Page 5]
Internet-Draft Partly-Decoupled NSIS February 2006
2.2. Signalling Protocol Outsourcing
"Outsourcing" is the use of an external server to take responsibility
for certain stages of a signalling transaction, such as the
allocation of some resources to a flow. The prime example is where
the decision about to allow a transaction 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. There may be several
motivations for this, including decoupling the software
implementation and processing load for policy control from the
platform handling the user plane. Many variants can be built on this
basic concept, with different subsets of the NSIS routers calling out
to the policy server. In addition, building on the policy decision
making capabilities, the server can carry out additional
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 application has been proposed to accompany the NSIS
QoS-NSLP for policy support to the AAA function in [12]. The
Diameter approach is also intended to be applicable to RSVP, and in
that sense its use completely hides the details of the signalling
protocol used from the rest of the network.
Hancock, et al. Expires August 25, 2006 [Page 6]
Internet-Draft Partly-Decoupled NSIS February 2006
We consider outsourcing of this type as logically distinct from path-
decoupled signalling. However, the motivation of wanting to be able
to centralise some processing-intensive functions of the control
plane away from the data forwarding (routing) nodes is common to both
cases. There are also related operational and message routing
requirements:
o The on-path nodes need to be able to discover which policy server
to use. Typically this would be done by some kind of external
management configuration.
o The server nodes need to be able to transmit configuration
commands to the data forwarding nodes, which includes determining
which nodes need to be configured in the first place. (This
determination may be implicit, such as where the forwarder
initiated the policy request itself.)
2.3. Route Computation
In some environments, route computation is supported by a signalling
protocol. For example, in the case of PCE, data forwarding nodes are
able to call out to one or more servers which will explicitly compute
the required data path, which is then set up by additional control
plane signalling. The PCE architecture is described in [9], which
also describes motivations for such an approach.
Although the communication between the data forwarding nodes and
external servers could be considered a case of off-path signalling,
it is conceptually quite distinct from the other off-path cases
considered for NSIS. In this case, the signalling is related to the
setting up of the data path itself, and so must take place before (in
time) and below (in the stack) any NSIS flow-related messaging. In
addition, the transactions between the forwarding and computing nodes
are about data flow properties and required/resulting routing
configuration, and therefore live conceptually at the same level of
the protocol stacks as NSIS signalling applications, and there is no
current or proposed NSLP with comparable functionality. Therefore,
this functionality is orthogonal to the NSIS problem space, just as
classical IP routing protocols (OSPF etc.) are.
Despite this protocol independence, there is a relationship between
this scenario and other options for off-path NSIS operation, in that
off-path NSIS has most benefits when there are nodes within the
network with an overall picture of the network topology and resource
management status. This knowledge will typically be available to
nodes performing the route computation function, since it is the same
information that is needed to carry out that function. However, the
relationship would be reflected at the implementation level (e.g.
Hancock, et al. Expires August 25, 2006 [Page 7]
Internet-Draft Partly-Decoupled NSIS February 2006
sharing of information between route computation and signalling
functions within a server node) rather than in the protocol
specifications themselves.
A similar argument about the relationship with NSIS applies in two
other cases:
o Signalling on a backup path (cf. [18]). The data forwarding plane
has to have the concept of a backup path compared to an active
path, and such a path must have been installed, but once this has
been done, signalling messages can be made to follow that path
without changing the fundamental NSIS concepts.
o Signalling on a predicted path for a mobile flow. The data
forwarding plane (typically using some mobility tunneling
protocol) must be aware of the future path and has knowledge of
how it will be configured, but given this information, NSIS
messages can be made to follow the future path as normal.
We consider all these cases as actually being extensions to the
routing functionality, which NSIS runs over the top of, rather than
part of the off-path signalling problem in their own right.
2.4. 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. No separate policy protocol is shown;
the NSIS controller might use such a protocol to call out to another
server node, or integrate the policy control functions itself. The
diagram shows only NSIS messages between the on-path routers and
controller; these might need to be complemented by additional control
messages, depending on the level of signalling that is interpreted in
the router. There are several variants of this basic concept, such
as the use of multiple controllers to handle a particular domain
which then need to 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.
The motivations for such an approach are varied and quite dependent
on operational scenario. There is some overlap with the
considerations that apply to policy outsourcing and route computation
(see above); also, if a single off-path node handles several routers
in a domain, there are performance advantages in being able to
parallelise the signalling transactions for each router rather than
requiring them to be serialised as would be necessary for strictly on
Hancock, et al. Expires August 25, 2006 [Page 8]
Internet-Draft Partly-Decoupled NSIS February 2006
path signalling. Most significantly, allowing some type of off-path
approach eases several deployment problems, such as avoiding the need
to replace or upgrade legacy routers, and allowing interworking with
other networks which use off-path signalling without being forced to
deploy another (non-NSIS) protocol to do so.
Administrative Domain
+-------------------------------------------------+
| +----------+ |
| ---------| NSIS |--------- |
| / |Controller| \ |
| / +----------+ \ |
| / * * \ |
| / * * \ |
| +------+ +--*---+ +---*--+ +------+ |
-----| NSIS | | | | | | NSIS |-----
#####|Router|#####|Router|####|Router|#####|Router|#####
| +------+ +------+ +------+ +------+ |
+-------------------------------------------------+
######### = data path
--------- = signalling messages
********* = configuration commands
Figure 3: A Single Off-Path NSIS Node
These benefits must be weighed against the cost of the additional
functionality needed compared to standard path-coupled NSIS
signalling. The main issue here is the need for the NSIS routers to
discover the NSIS controller (in the figure, on ingress), and, more
significantly, for the NSIS controller to discover an on-path node to
re-attach the signalling to the data path (in the figure, on egress).
Furthermore, the solution must adapt to route changes, including
those caused by data path failures. In general, these problems are
very hard to solve without requiring detailed and up-to-date topology
knowledge in the central controller, which then introduces its own
scalability and resilience problems. However, it is possible to
develop a mode of GIST operation which avoids these problems, while
still providing the benefits of off-path operation to signalling
applications. This approach is described in the next section.
3. A Partly-Decoupled GIST
In this section we consider how to handle the additional requirements
for path-decoupled operation compared to the current operation of
GIST. The discussion is divided into a summary of the requirements,
the basic implementation options, and the specific approach of
modifying the implementation of GIST itself.
Hancock, et al. Expires August 25, 2006 [Page 9]
Internet-Draft Partly-Decoupled NSIS February 2006
3.1. Requirements at the NTLP Level
These requirements can be summarised as follows:
1. Transfer of signalling messages between on- and off-path nodes,
with a service that preserves the transport and security
semantics of the GIST API.
2. Off-path 'server' discovery given an on-path node as context.
3. Off-path 'server' discovery from another off-path node.
4. On-path node discovery from an off-path node (reattachment).
Of these requirements, the message transfer is not conceptually
difficult, since GIST itself already provides the necessary
functionality. The most challenging parts of the problem are the
node discovery aspects. The two basic options are:
1. to intercept and modify the existing RSVP-like discovery
mechanism. These discovery messages are still sent along the
data flow path, but the responses 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.
2. 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, unless they
are restricted to particular topologies such as stub (single-
homed) networks.
An additional problem is the discovery of the routers to be
controlled. In the case where the controlled router is directly
selecting the off-path node or is the re-attachment point, this
functionality is provided as a side effect of the router-controller
interaction. Discovery of additional routers to be controlled (e.g.
between ingress and egress) is considered below in (Section 4.3).
3.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 GIST. There are three
Hancock, et al. Expires August 25, 2006 [Page 10]
Internet-Draft Partly-Decoupled NSIS February 2006
possible approaches.
Conceptually the simplest is to make a new off-path NTLP which
exposes the same API as GIST. This is at least theoretically
possible within the overall NSIS architecture, because the NTLP has
only single-hop scope. Relationships along the sequence of NTLP hops
are seen only by signalling applications, and even then only via the
GIST 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 GIST to replace
only the parts directly affected by the off-path operation. Based on
the above discussion in Section 3.1, the main changes are needed in
the message routing area. GIST 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). The disadvantage of this
approach is that a new MRM would have to be distinguished at the API
level (and hence have to be explicitly selected by signalling
applications at the API), which leads to several of the same problems
as in the off-path NTLP case.
The third approach is to modify the processing of the GIST path-
coupled MRM, to give a similar effect as path-decoupled operation.
This requires a minimal GIST implementation in 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 GIST is decomposed into datagram-
(D-) and connection- (C-) modes. A worked example of the use of GIST
in this way is given in the next subsection.
3.3. Modifying the GIST Path-Coupled MRM
This section shows two cases of GIST 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 GIST-Query and receives a normal GIST-Response containing
Hancock, et al. Expires August 25, 2006 [Page 11]
Internet-Draft Partly-Decoupled NSIS February 2006
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 GIST-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 learns directly which on-path node is responsible for the
flow being signalled about.)
On the assumption that all further signalling application
communication takes place over the messaging association that has
been set up, this results in something functionally equivalent to
off-path signalling with a specific framework for the discovery
process, namely any rule that can be configured into the downstream
on-path node for selecting a server.
+----------+
| NSLP |
Messaging association +----------+
##########################>>| GIST |
# ....................| C/D-mode |
# . GIST-Response +----------+
+----------+ # . ^ *
| NSLP | # . . *
+----------+ # . . *
| |<<########## . . V
| GIST | . +-.--------+
| C/D-mode |<................... GIST-Query | . GIST |
| |.......................................... D-mode|
+----------+ +----------+ +----------+ +----------+
| IP | | IP | | IP | | IP |
|Forwarding| |Forwarding| |Forwarding| |Forwarding|
---------------------------------------------------------------------->
+----------+ +----------+ +----------+ +----------+
---------> = Data flow (and direction)
.........> = GIST D-mode messages (and direction)
<<######>> = GIST 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
Hancock, et al. Expires August 25, 2006 [Page 12]
Internet-Draft Partly-Decoupled NSIS February 2006
from the off-path node but routed via its on-path node for that flow
(i.e. the node that originally called out to it). 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 GIST-
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.
+----------+
| NSLP |
+----------+ Messaging Association
| GIST |<<##########################
| C/D-mode | #
+----------+ #
* . ^ #
* . . # +----------+
* . . # |Signalling|
V . . # | Appl. |
+-------.-.+ # +----------+
| . .| GIST-Response ##########>>| |
| GIST . .........................................| GIST |
|D-mode . | GIST-Query | C/D-mode |
| ...|......................................>| |
+----------+ +----------+ +----------+ +----------+
| IP | | IP | | IP | | IP |
|Forwarding| |Forwarding| |Forwarding| |Forwarding|
---------------------------------------------------------------------->
+----------+ +----------+ +----------+ +----------+
---------> = Data flow (and direction)
.........> = GIST D-mode messages (and direction)
<<######>> = GIST 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 a form of off-path
signalling can be achieved within the current GIST design in a way
which allows transparent interworking with pure on-path
configurations. At least some GIST 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
very simple backhaul techniques as discussed below in Section 4.1.
3.4. Discussion
The previous section outlined an approach for off-path transport of
Hancock, et al. Expires August 25, 2006 [Page 13]
Internet-Draft Partly-Decoupled NSIS February 2006
the bulk of the signalling messages. The presentation was in the
context of a single off-path node controlling a single router;
however, the same approach can clearly be used in a more general way.
Where NSIS (GIST and signalling applications) are deployed in this
way, it also highlights some questions about how the hop counts at
the various NSIS layers should be interpreted.
The simplest configuration, of a single off-path node invoked by a
single router, is conceptually the same as the on-path case where all
NSIS processing takes place on the router in question. The NSLP will
be a single GIST hop from its upstream and downstream peers, and each
GIST hop will equate to some number of IP hops upstream and
downstream of the router. (This requires the hop count information
in the IP and GIST headers to be transferred unchanged by the Query
backhaul protocol, see Section 4.1.) The routers either side of the
on-path node will be detected as normal, as NSIS-unaware hops.
One generalisation is that there could be more than one on-path node
in sequence which calls out to an off-path server. Two cases then
arise, depending on which off-path node is invoked. In the first
case, each router calls out to the same off-path node. This could be
done for all routers in a network domain, in which case we would then
have the scenario of a single controlling node handling NSIS
signalling for every router along the path. (Note that in this case
there is no need for a separate router discovery solution as in
Section 4.3, because the call-out process identifies each router
explicitly.) The ideal signalling flow would then be as follows:
o Query messages follow a 'zig-zag' pattern through the network,
going from each router to the off-path node and back again before
going to the next router where the process is repeated, until the
data path exits the domain.
o Routing state from outside the domain points directly to the off-
path node on ingress, and originates directly from the off-path
node on egress. There would be a single inbound and outbound
messaging association to carry the signalling.
Logically, the off-path node would host a number of instances of the
same NSLP, each a single GIST hop apart, and this is how it should be
presented to the outside world. (However, note that typically
signalling applications only interact with their direct peers and do
not care about the signalling configuration beyond anyway.)
Internally, one would expect an implementation to have a more
optimised structure, carrying out parallelised resource
configurations on all the routers under its control; in particular,
there would be no need for them to use GIST to exchange application
messages within the node. All that is required is the implementation
Hancock, et al. Expires August 25, 2006 [Page 14]
Internet-Draft Partly-Decoupled NSIS February 2006
of the GIST routing state maintenance procedures, which are necessary
for route change detection.
The second possible configuration is that more than one off-path node
is invoked in sequence, for example one for ingress and one for
egress. In this case, the Query messages follow a 'U-shaped'
pattern, being forwarded to the off-path nodes after visiting each
router, while the routing state and messaging associations form a
'tent' shape, with the two off-path nodes communicating directly with
each other. As in the previous case, the configuration in terms of
GIST hops and number of NSLP instances is fully determined by the set
of routers which invoke the call-out process. However, here we would
also expect GIST itself to be used between the two off-path nodes.
This draft makes no statements about which configuration of all the
many possibilities should be preferred. This depends on deployment
and operational considerations, and also the capabilities and scaling
properties of the NSLP implementations being used. Provided that
GIST is used as described in Section 3.3 above, and no assumptions
about configuration or deployment are hard-wired into the
implementations, the GIST handshake process will allow all the
different possibilities to co-exist and be discovered automatically
(assuming the routers are configured with the identity of the server
they should call out to), as well as maintaining compatibility with
the on-path case.
4. Supporting Protocol Functionality
The previous sections, in particular Section 3.3 and Section 3.4,
presented a mode of operation for GIST supporting 'partially
decoupled' signalling. This section discusses in more detail the
components that are needed to complete such a solution in a real
deployment. It can be seen solutions for the other functions are
already available in existing protocols or are provided as a side
effect of the basic off-path operation, and so no additional
specification development is strictly required. However, the
discussion notes some options for further protocol work which may be
desirable in some scenarios.
4.1. GIST Backhaul
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.
Hancock, et al. Expires August 25, 2006 [Page 15]
Internet-Draft Partly-Decoupled NSIS February 2006
IP Level: The IP packets carrying the signalling messages are
intercepted by the on-path router and forwarded to the server with
some additional encapsulation. This approach is particularly
appropriate for legacy environments, since it minimises the 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 GIST API.
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. This is essentially the policy outsourcing approach
already discussed (see Section 2.2).
The partly-decoupled approach is compatible with either of the first
two, depending on whether or not the on-path node interprets the GIST
D-mode messages involved, or just recognises them as having a
particular IP and transport level encapsulation. Given the
motivation to be able to support legacy environments, the first
approach seems most appropriate; the second would impose some
additional requirements on state synchronisation between the on- and
off-path nodes (e.g. for cookie generation and validation). The
first approach can easily be supported with the current GIST design,
since the only message type that needs to be intercepted is the GIST-
Query and these have a fixed UDP destination port as well as being
sent with a Router Alert option at the IP level.
4.2. Network Element Control
The network configurations require the ability to transport element
control commands from an off-path entity to routers on the data path.
Hancock, et al. Expires August 25, 2006 [Page 16]
Internet-Draft Partly-Decoupled NSIS February 2006
Where the signalling backhaul takes place at the IP or NTLP level,
the routers to be controlled include the nodes at which signalling
leaves and joins the data path as well as the nodes between them.
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 [13] or a
proprietary command line interface); or, for particular applications,
a more specialised configuration protocol, such as COPS in
provisioning mode [14] or the protocols under development in netconf
[15], ForCES [16] and GSMP [17]. It appears that such protocols are
outside the scope of NSIS.
4.3. Router Determination
An element control protocol needs to operate on a target router. If
the target router is a location from which on-path signalling
messages are being forwarded, this identification takes place
automatically as a side effect of the off-path deployment approach
described, and no additional functionality is required.
If the intention is to control a complete set of routers along a path
segment (e.g. between ingress and egress nodes within a single
domain), a second possibility is to use existing (non-NSIS)
functionality to identify the target set, such as IP-layer route
recording or traceroute initiated from the ingress router, or to
calculate the target set from knowledge of the network topology,
which could be determined by participating in the interior routing
protocol. Such techniques have deployment limitations but may be
attractive in special scenarios.
The final possibility is to use a specific NSIS extension, such as 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 [19] - 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.
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. The requirements on the transfer mechanism are not
Hancock, et al. Expires August 25, 2006 [Page 17]
Internet-Draft Partly-Decoupled NSIS February 2006
distinct from the transfer requirements on the 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. In the architecture proposed here, GIST is re-used unchanged
for this off-path transport.
5. 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.
6. 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 can be satisfied using existing protocols. A minimal
solution is 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.)
Hancock, et al. Expires August 25, 2006 [Page 18]
Internet-Draft Partly-Decoupled NSIS February 2006
2. The ability to deploy GIST such that its routing state and hence
C-mode connections refer directly to off-path nodes.
3. A mechanism to discover the sequence of routers between two on-
path nodes.
It is our conclusion that a small number of relatively precisely
scoped modifications to GIST implementation can be used to enhance
the performance and usability of the NSIS protocol suite in several
important networking environments, and in particular can ease
deployment and interworking with other networks that attach to the
Internet. We therefore recommend that the working group should
consider taking on this task.
7. References
7.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signaling Transport", draft-ietf-nsis-ntlp-09 (work in
progress), February 2006.
7.2. Informative References
[3] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004.
[4] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
"Middlebox Communications (midcom) Protocol Requirements",
RFC 3304, August 2002.
[5] Chaskar, H., "Requirements of a Quality of Service (QoS)
Solution for Mobile IP", RFC 3583, September 2003.
[6] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005.
[7] Manner, J., "NSLP for Quality-of-Service signalling",
draft-ietf-nsis-qos-nslp-09 (work in progress), February 2006.
[8] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in progress),
February 2006.
Hancock, et al. Expires August 25, 2006 [Page 19]
Internet-Draft Partly-Decoupled NSIS February 2006
[9] Farrel, A., "A Path Computation Element (PCE) Based
Architecture", draft-ietf-pce-architecture-04 (work in
progress), January 2006.
[10] Fessi, A., "Framework for Metering NSLP",
draft-fessi-nsis-m-nslp-framework-02 (work in progress),
October 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-05 (work in progress), October 2005.
[13] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing Simple Network Management Protocol (SNMP)
Management Frameworks", STD 62, RFC 3411, December 2002.
[14] 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.
[15] Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-11 (work in progress), February 2006.
[16] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding
and Control Element Separation (ForCES) Framework", RFC 3746,
April 2004.
[17] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
"General Switch Management Protocol (GSMP) V3", RFC 3292,
June 2002.
[18] 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.
[19] Juchem, I., "A stateless Ping tool for simple tests of GIMPS
implementations", draft-juchem-nsis-ping-tool-02 (work in
progress), July 2005.
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
Hancock, et al. Expires August 25, 2006 [Page 20]
Internet-Draft Partly-Decoupled NSIS February 2006
fundamental architectural implications of off-path approaches. Jerry
Ash, Eleanor Hepworth, Andrew McDonald and Al Morton also provided
review comments.
Hancock, et al. Expires August 25, 2006 [Page 21]
Internet-Draft Partly-Decoupled NSIS February 2006
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
Hancock, et al. Expires August 25, 2006 [Page 22]
Internet-Draft Partly-Decoupled NSIS February 2006
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 (2006). 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 August 25, 2006 [Page 23]