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