One document matched: draft-hancock-nsis-pds-problem-02.txt
Differences from draft-hancock-nsis-pds-problem-01.txt
Next Steps in Signaling R. Hancock
Internet-Draft Siemens/RMR
Expires: April 27, 2006 C. Kappler
Siemens AG
J. Quittek
M. Stiemerling
NEC
October 24, 2005
A Problem Statement for Partly-Decoupled Signalling in NSIS
draft-hancock-nsis-pds-problem-02
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 April 27, 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 April 27, 2006 [Page 1]
Internet-Draft Partly-Decoupled NSIS October 2005
the data 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 . . . . . . . . . . . . . . . . . 4
2.2. Signalling Protocol Outsourcing . . . . . . . . . . . . . 5
2.3. Route Computation . . . . . . . . . . . . . . . . . . . . 7
2.4. Off-Path NSIS . . . . . . . . . . . . . . . . . . . . . . 8
3. A Partly-Decoupled NTLP . . . . . . . . . . . . . . . . . . . 9
3.1. Requirements at the NTLP Level . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . 17
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Hancock, et al. Expires April 27, 2006 [Page 2]
Internet-Draft Partly-Decoupled NSIS October 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 GIST [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. 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 which overlap in some way;
however, this draft focusses on a specific case. 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
Hancock, et al. Expires April 27, 2006 [Page 3]
Internet-Draft Partly-Decoupled NSIS October 2005
we are mainly concerned with, in order to place this draft in proper
context. Next, Section 3 describes a design approach based on a
modification of the usage of GIST (the NTLP). Necesary 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 families of 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 generally 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, without being constrained to pass
through on-path routers. Often, the off-path node is responsible
for a whole set of routers.
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, the problems are
orthogonal. The focus of this draft is on the path-decoupled case
itself, since the other two are already extensively covered in other
work inside and outside the IETF.
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 is true both within a single
Hancock, et al. Expires April 27, 2006 [Page 4]
Internet-Draft Partly-Decoupled NSIS October 2005
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 excludes 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 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.
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.
2.2. Signalling Protocol Outsourcing
"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
Hancock, et al. Expires April 27, 2006 [Page 5]
Internet-Draft Partly-Decoupled NSIS October 2005
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 reasons
to do 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, as 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 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.
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:
Hancock, et al. Expires April 27, 2006 [Page 6]
Internet-Draft Partly-Decoupled NSIS October 2005
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
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, 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 [13], 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 above and below. 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) NSIS flow-related
messaging can take place. 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 signalling is
orthogonal to the NSIS problem space, just in the same way as
classical IP routing protocols (OSPF etc.) are.
Despite this independence at the protocol level, there is a
relationship between this scenario and 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
essentially the information that is needed to carry out that
function. However, the relationship would be reflected at the
implementation level (e.g. 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:
Hancock, et al. Expires April 27, 2006 [Page 7]
Internet-Draft Partly-Decoupled NSIS October 2005
o Signalling on a backup path for an active flow (cf. [19]). 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, NSIS messages can be made
to follow that path without changing the fundamental protocol
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 make 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. Note that, unlike the policy
outsourcing case, there is no separate policy protocol shown. There
are several variants of this basic concept, for example the use of
multiple controllers to handle a particular domain which 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
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.
Hancock, et al. Expires April 27, 2006 [Page 8]
Internet-Draft Partly-Decoupled NSIS October 2005
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 absolutely requiring detailed and up-to-
date topology knowledge in the central controller, which then
introduces its own scalability and resilience problems. However, it
appears that 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 NTLP
In this section we consider how to handle the additional requirements
on the NTLP for path-decoupled operation compared to the current
functionality of GIST. The discussion is divided into a summary of
the requirements, the basic implementation options, and specific
considerations for modifying GIST itself.
3.1. Requirements at the NTLP Level
These requirements can be summarised as follows:
Hancock, et al. Expires April 27, 2006 [Page 9]
Internet-Draft Partly-Decoupled NSIS October 2005
1. Transfer of signalling messages between off-path nodes, with a
service that preserves the transport and security semantics of
the GIST 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 GIST itself already provides the necessary
functionality.
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.
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
possible approaches.
Hancock, et al. Expires April 27, 2006 [Page 10]
Internet-Draft Partly-Decoupled NSIS October 2005
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, 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 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 some level of GIST 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 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 modes 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
addressing information about the downstream signalling peer with whom
it subsequently sets up a messaging association. The modification
Hancock, et al. Expires April 27, 2006 [Page 11]
Internet-Draft Partly-Decoupled NSIS October 2005
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 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).
+----------+
| 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
from the off-path node but routed via its on-path node for that flow
Hancock, et al. Expires April 27, 2006 [Page 12]
Internet-Draft Partly-Decoupled NSIS October 2005
(i.e. the one 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 implemented within the current GIST design in a way
which eases 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 low-level backhaul techniques as
discussed in Section 4.1.
3.4. Discussion
The previous section outlined an approach for off-path transport of
the bulk of the signalling messages. The presentation was in the
Hancock, et al. Expires April 27, 2006 [Page 13]
Internet-Draft Partly-Decoupled NSIS October 2005
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 application) 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 are only related to their direct peers and do
not care about the signalling configuration beyond their direct peer
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
of the GIST routing state maintenance procedures, which are necessary
Hancock, et al. Expires April 27, 2006 [Page 14]
Internet-Draft Partly-Decoupled NSIS October 2005
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 section presented a mode of operation for GIST
supporting 'partially decoupled' signalling. This section discusses
in more detail the supporting protocol components that would be
needed to complete such a solution.
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.
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
Hancock, et al. Expires April 27, 2006 [Page 15]
Internet-Draft Partly-Decoupled NSIS October 2005
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. 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 partly-decoupled architecture described above is compatible with
either of the first two approaches, 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).
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 as 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.
Hancock, et al. Expires April 27, 2006 [Page 16]
Internet-Draft Partly-Decoupled NSIS October 2005
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. The functionality could be provided
in 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.
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
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.
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
Hancock, et al. Expires April 27, 2006 [Page 17]
Internet-Draft Partly-Decoupled NSIS October 2005
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 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 GIST 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.
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.
7. References
Hancock, et al. Expires April 27, 2006 [Page 18]
Internet-Draft Partly-Decoupled NSIS October 2005
7.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.
7.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, "GIST: General Internet
Signaling Transport", draft-ietf-nsis-ntlp-08 (work in
progress), September 2005.
[6] Bosch, S., "NSLP for Quality-of-Service signalling",
draft-ietf-nsis-qos-nslp-08 (work in progress), October 2005.
[7] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-07 (work in progress),
July 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,
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-04 (work in progress), September 2005.
[13] Farrel, A., "Path Computation Element (PCE) Architecture",
draft-ietf-pce-architecture-02 (work in progress),
September 2005.
Hancock, et al. Expires April 27, 2006 [Page 19]
Internet-Draft Partly-Decoupled NSIS October 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-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
fundamental architectural implications of off-path approaches. Jerry
Ash, Eleanor Hepworth, Andrew McDonald and Al Morton also provided
review comments.
Hancock, et al. Expires April 27, 2006 [Page 20]
Internet-Draft Partly-Decoupled NSIS October 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
Hancock, et al. Expires April 27, 2006 [Page 21]
Internet-Draft Partly-Decoupled NSIS October 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 April 27, 2006 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 08:59:45 |