Next Steps in Signaling R. Hancock Internet-Draft Siemens/RMR Intended status: Informational C. Kappler Expires: April 26, 2007 Siemens AG J. Quittek M. Stiemerling NEC October 23, 2006 A Problem Statement for Partly-Decoupled Signalling in NSIS draft-hancock-nsis-pds-problem-04 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 26, 2007. 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 April 26, 2007 [Page 1] Internet-Draft Partly-Decoupled NSIS October 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 intrinsically provided by the baseline path- coupled solution. 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 . . . . . . . . . . . . . . . . . 17 4.3. Router Determination . . . . . . . . . . . . . . . . . . . 17 4.4. Off-Path Transport . . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Hancock, et al. Expires April 26, 2007 [Page 2] Internet-Draft Partly-Decoupled NSIS October 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 signalling 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 Hancock, et al. Expires April 26, 2007 [Page 3] Internet-Draft Partly-Decoupled NSIS October 2006 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, based on a modification to the operation of the lower NSIS protocol layer (GIST). It is the intention 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 April 26, 2007 [Page 4] Internet-Draft Partly-Decoupled NSIS October 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 April 26, 2007 [Page 5] Internet-Draft Partly-Decoupled NSIS October 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. We consider outsourcing of this type as logically distinct from path- Hancock, et al. Expires April 26, 2007 [Page 6] Internet-Draft Partly-Decoupled NSIS October 2006 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. sharing of information between route computation and signalling Hancock, et al. Expires April 26, 2007 [Page 7] Internet-Draft Partly-Decoupled NSIS October 2006 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 path signalling. Most significantly, allowing some type of off-path Hancock, et al. Expires April 26, 2007 [Page 8] Internet-Draft Partly-Decoupled NSIS October 2006 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 April 26, 2007 [Page 9] Internet-Draft Partly-Decoupled NSIS October 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 April 26, 2007 [Page 10] Internet-Draft Partly-Decoupled NSIS October 2006 possible approaches. Conceptually the simplest approach 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 April 26, 2007 [Page 11] Internet-Draft Partly-Decoupled NSIS October 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 from the off-path node but routed via its on-path node for that flow Hancock, et al. Expires April 26, 2007 [Page 12] Internet-Draft Partly-Decoupled NSIS October 2006 (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 the bulk of the signalling messages. The presentation was in the Hancock, et al. Expires April 26, 2007 [Page 13] Internet-Draft Partly-Decoupled NSIS October 2006 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 of the GIST routing state maintenance procedures, which are necessary Hancock, et al. Expires April 26, 2007 [Page 14] Internet-Draft Partly-Decoupled NSIS October 2006 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 April 26, 2007 [Page 15] Internet-Draft Partly-Decoupled NSIS October 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 usually being sent with a Router Alert option at the IP level. This last point depends on some details of the GIST design which are still open; however, the need for a precise characterisation of the set of packets that can be intercepted in this way is a long term requirement on the GIST design for archictectural reasons, and it is that property that is required here. Hancock, et al. Expires April 26, 2007 [Page 16] Internet-Draft Partly-Decoupled NSIS October 2006 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. 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. An applicability statement for partly- decoupled signalling would not define precisely the protocols to be used for this purpose; however, it would indicate the considerations that had to be taken into account in selecting or adapting such protocols. 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 Hancock, et al. Expires April 26, 2007 [Page 17] Internet-Draft Partly-Decoupled NSIS October 2006 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 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 Hancock, et al. Expires April 26, 2007 [Page 18] Internet-Draft Partly-Decoupled NSIS October 2006 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.) 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-11 (work in progress), August 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. Hancock, et al. Expires April 26, 2007 [Page 19] Internet-Draft Partly-Decoupled NSIS October 2006 [7] Manner, J., "NSLP for Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-11 (work in progress), June 2006. [8] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-12 (work in progress), June 2006. [9] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [10] Fessi, A., "Framework for Metering NSLP", draft-fessi-nsis-m-nslp-framework-03 (work in progress), June 2006. [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-tschofenig-dime-diameter-qos-00 (work in progress), March 2006. [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-12 (work in progress), March 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", RFC 4090, May 2005. [19] Juchem, I., "A stateless Ping tool for simple tests of GIMPS implementations", draft-juchem-nsis-ping-tool-02 (work in progress), July 2005. Hancock, et al. Expires April 26, 2007 [Page 20] Internet-Draft Partly-Decoupled NSIS October 2006 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, Ted Hardie, Eleanor Hepworth, Hui-Lan Lu, Andrew McDonald, Paulo Mendes and Al Morton also provided review comments. 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 Hancock, et al. Expires April 26, 2007 [Page 21] Internet-Draft Partly-Decoupled NSIS October 2006 Martin Stiemerling NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Email: stiemerling@netlab.nec.de Hancock, et al. Expires April 26, 2007 [Page 22] Internet-Draft Partly-Decoupled NSIS October 2006 Full 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hancock, et al. Expires April 26, 2007 [Page 23]