Next Steps in Signaling R. Hancock Internet-Draft Siemens/RMR Expires: November 18, 2005 C. Kappler Siemens AG J. Quittek M. Stiemerling NEC May 17, 2005 A Problem Statement for Path-Decoupled Signalling in NSIS draft-hancock-nsis-pds-problem-00 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 November 18, 2005. 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 November 18, 2005 [Page 1] Internet-Draft Path-Decoupled NSIS May 2005 the data flows themselves ("path-coupled signalling"). This document discusses motivations for a relaxation of this constraint, allowing the signalling and data paths to be decoupled. It includes several scenarios and pointers to related work elsewhere in the IETF and in other standardisation bodies, and includes a recommendation that the NSIS work should be extended to cover these types of architectures. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Centralised Policy Control . . . . . . . . . . . . . . . . 4 2.2 Intradomain Centralised Monitoring and Resource Management . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Interdomain Off-Path Signalling . . . . . . . . . . . . . 6 2.4 3rd Party Signalling Initiation . . . . . . . . . . . . . 6 2.5 Signalling on multiple (candidate) paths . . . . . . . . . 7 2.6 Architectures of Other SDOs . . . . . . . . . . . . . . . 8 3. Network Configurations . . . . . . . . . . . . . . . . . . . . 8 3.1 Baseline NSIS Operation . . . . . . . . . . . . . . . . . 9 3.2 NSIS with Policy Outsourcing . . . . . . . . . . . . . . . 9 3.3 Off-Path Intradomain NSIS . . . . . . . . . . . . . . . . 10 3.4 Interdomain Off-Path Signalling . . . . . . . . . . . . . 11 3.5 Signalling on Multiple Candidate Paths . . . . . . . . . . 12 3.6 Off-path NSIS Initiator and Responder . . . . . . . . . . 12 4. Problem Structure . . . . . . . . . . . . . . . . . . . . . . 13 4.1 Signalling Backhaul . . . . . . . . . . . . . . . . . . . 14 4.2 Network Element Control . . . . . . . . . . . . . . . . . 15 4.3 Router Determination . . . . . . . . . . . . . . . . . . . 15 4.4 Off-Path Transport . . . . . . . . . . . . . . . . . . . . 15 4.5 Signalling Node Identification . . . . . . . . . . . . . . 16 4.6 Host Proxy Triggering . . . . . . . . . . . . . . . . . . 17 4.7 Multi-Path Selection . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1 Normative References . . . . . . . . . . . . . . . . . . . 19 7.2 Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . 23 Hancock, et al. Expires November 18, 2005 [Page 2] Internet-Draft Path-Decoupled NSIS May 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]), where 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 (see Section 2.6). 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. 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 these scenarios in a set of concrete network configurations, showing the entities involved and listing the components needing to make a complete solution. Section 4 describes these components in more detail. Security considerations are given Hancock, et al. Expires November 18, 2005 [Page 3] Internet-Draft Path-Decoupled NSIS May 2005 in Section 5, and finally Section 6 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). However, it does include references to the signalling architectures of other Standards Development Organisations (SDOs) which use such approaches. 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 these solutions where possible. 2.2 Intradomain Centralised 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 Hancock, et al. Expires November 18, 2005 [Page 4] Internet-Draft Path-Decoupled NSIS May 2005 assumption in PCE work [19], 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 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 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 - parallelisation of the per-on-path node operation and 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. Hancock, et al. Expires November 18, 2005 [Page 5] Internet-Draft Path-Decoupled NSIS May 2005 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. 2.3 Interdomain Off-Path Signalling In principle, centralised resource management approaches can be deployed internally as a matter of network operator choice, while still using 'classic' NSIS on-path signalling on external links. However, where neighbouring domains are both using such centralised approaches, there may be benefits if they are able to signal directly to each other rather than stepping back to on-path signalling for the single inter-domain hop. The main point is that such interdomain signalling is likely to be associated with other interdomain 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. Another issue is that operators may wish to segregate such control traffic from user traffic physically for security reasons (e.g. continued operation under overload) and this is much harder in the pure on-path case. 2.4 3rd Party Signalling Initiation In this scenario, the signalling is not directly initiated by the flow endpoint but rather by an off-path node having enough knowledge to initiate the signalling. Examples for this include where an end node cannot be trusted to start and control the signalling, where a 3rd party off-path node is interested in on-path information, or where the flow end node does not have the necessary information or ability to operate the complete signalling exchange. This scenario also covers the case of a domain recently migrated to NSIS, but supporting legacy non-NSIS aware devices. An example of operation is that the flow endpoint requests an application-specific service by sending a "Service Request" (for example a SIP message) to a service controller. It is then the service controller's responsibility to determine the resource needs of the requested service, and to communicate these needs to a proxy which then initiates signalling on behalf of the flow endpoint. Such scenarios are described by 3GPP [11] and ETSI [12]. In fact, the QoS management in current xDSL networks is in conformance with this Hancock, et al. Expires November 18, 2005 [Page 6] Internet-Draft Path-Decoupled NSIS May 2005 scenario. A typical scenario for a NAT/Firewall environment is the use of this proxy initiated signalling in large enterprise networks running already SIP-based telephony. It is expected that the installed SIP phones would be upgraded only gradually to support NSIS signalling. Another example is metering configuration [13]. Usually, the flow endpoint doesn't have the knowledge or the authorization to configure meters to measure the flow. However, the knowledgeable node, the proxy, is not necessarily located on the data path. The proxy can initiate the signaling by sending it to the first network-owner controlled metering on the data path, from where the signalling proceeds on-path as normal. Yet another example is that of RSVP Diagnostic Messages [14]. Here a 3rd party node ("Requester") that is not part of the actual session wishes to diagnose the RSVP state installed along a data path. It therefore issues a RSVP DREQ message towards the Sender, which joins the data path at the node at which diagnosis should start. The DREQ message is forwarded hop-by-hop collecting state information for a specified number of hops. The Sender returns the collected information in a DREP message to the Requester. The DREP message can travel directly, or it can reverse the path taken by the DREQ message based on information in ROUTE object collected in the DREQ packet. Note the off-path node needs to determine the appropriate NSIS Entity at which to rejoin the data path. In constrained topologies (e.g. tree-like access networks) this is not too difficult. If the initiator is actually on the data path, the NSIS signaling in these scenarios is normal on-path NSIS signaling. However, generally, it may not be located on the data path. 2.5 Signalling on multiple (candidate) paths The current NSIS protocol suite does not support signalling on multiple (candidate) paths. These paths are sets of routers that are not currently on the data path but that may end up on the data path in the future as a result of a network event, such as a node or link failure, an interdomain route change or a policy change. This scenario is particularly useful for make-before-break reservation on back-up paths that are non-shortest path under the current routing and policy configurations, or to support seamless handover in mobility scenarios (see for example [16]). Make-before-break allows pre-reservation of resources on candidate back-up paths in order to allow for fast failover. Hancock, et al. Expires November 18, 2005 [Page 7] Internet-Draft Path-Decoupled NSIS May 2005 2.6 Architectures of Other SDOs Other SDOs, particularly those originating from the "telecommunications world" typically assume a centralized controller, e.g. for resource management, in each domain. For example, the QoS architecture for Next Generation Networks of ETSI [12], features a Service Control Function which is responsible in each domain for controlling service requests initiated by a flow senders. This Service Control Function sends resource requests on behalf of the flow sender to a central resource controller (the Network Resource Control Function) in the same domain. The resource controller subsequently initiates a controller-to-controller QoS signaling exchange through all domains along the data path up to the receiving domain. 3GPP is currently specifying an end-to-end QoS solution [15] for interworking with external non-3GPP IP networks. For the external IP networks a variety of QoS architectures are described, both centralized controller-type architectures and distributed IntServ/ DiffServ-type architectures. At this point, however, only QoS procedures for scenarios featuring centrally-managed external networks are specified in detail. One of the problems that need to be solved is the interworking of on-path and off-path QoS signaling in scenarios featuring domains with both centralized and distributed QoS control on the same data path. 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 operational model and indicates where additional functions are needed. Hancock, et al. Expires November 18, 2005 [Page 8] Internet-Draft Path-Decoupled NSIS May 2005 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 and network management transactions are not directly interdependent). 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 are 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 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. Hancock, et al. Expires November 18, 2005 [Page 9] Internet-Draft Path-Decoupled NSIS May 2005 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 [17], and a Diameter extension has been proposed to accompany the NSIS QoS- NSLP for policy support to the AAA function in [18]. However, policy outsourcing concepts (and solution components) are relevant to support some of the broader off-path scenarios considered below. 3.3 Off-Path Intradomain NSIS In this configuration, the signalling itself is allowed to go off- path directly 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 discover and signal directly to each other. However, the interdomain link here uses 'standard' NSIS and so the multi-domain configuration is simply a concatenation of several copies of the above picture. Hancock, et al. Expires November 18, 2005 [Page 10] Internet-Draft Path-Decoupled NSIS May 2005 Administrative Domain +-------------------------------------------------+ | +----------+ | | ---------| NSIS |--------- | | / |Controller| \ | | / +----------+ \ | | / * * \ | | / * * \ | | +------+ +--*---+ +---*--+ +------+ | -----| NSIS | | | | | | NSIS |----- #####|Router|#####|Router|####|Router|#####|Router|##### | +------+ +------+ +------+ +------+ | +-------------------------------------------------+ ######### = data path --------- = signalling messages ********* = configuration commands Figure 3: A Single Off-Path NSIS Node 3.4 Interdomain Off-Path Signalling This configuration is an extension of the previous case. Formally, the requirements to support this are no different (mutual discovery of the on- and off- path nodes by each other). However, there is an extra requirement that the inter-controller discovery procedure must operate between domains, which imposes extra security and operational constraints. Administrative Domain 1 Administrative Domain 2 +--------------------------+ +----------------------------+ | +----------+ | | +----------+ | | .------| NSIS |-----------| NSIS |-------. | | | |Controller| | | |Controller| | | | | +----------+ | | +----------+ | | | | * | | * | | | +------+ +---*--+ | | +--*---+ +------+ | -----| NSIS | | | | | | | | NSIS |----- #####|Router|####|Router|#################|Router|#####|Router|##### | +------+ +------+ | | +------+ +------+ | +--------------------------+ +----------------------------+ ######### = data path --------- = signalling messages ********* = configuration commands Figure 4: Interdomain Off-Path Signalling Hancock, et al. Expires November 18, 2005 [Page 11] Internet-Draft Path-Decoupled NSIS May 2005 3.5 Signalling on Multiple Candidate Paths In this network configuration, there are several candidate paths, and the signalling must be able to follow all of them (and also distinguish between current and candidate paths). The additional requirements here depend quite strongly on how the candidate paths are being created and configured. If they are visible somehow in the user plane (e.g. by using a different tunnel address or codepoint etc.), and can be mimicked by GIMPS Query messages, then no additional functionality is required except for the signalling messages to identify explicitly the status of the path they are signalling about. If the candidate paths are known only in some control plane entities, probably those entities need to be queried to provide the information for explicit routing of the messages. Administrative Domain +----------------------------------------------------+ | | | +------+ +------+ | | %%%%%%%%%%%| NSIS |%%%%%%| NSIS |%%%%%%%%%%% | | %.---------|Router|------|Router|---------.% | | %| +------+ +------+ |% | | %| |% | | %| |% | | +------+ +------+ +------+ +------+ | -----| NSIS |------| NSIS |------| NSIS |------| NSIS |----- #####|Router|######|Router|######|Router|######|Router|##### | +------+ +------+ +------+ +------+ | +----------------------------------------------------+ ######### = data path (current) %%%%%%%%% = data path (candidate) --------- = signalling messages 3.6 Off-path NSIS Initiator and Responder This network configuration is supporting migration and other scenarios and is shown in Figure 6. The main requirement on the signalling is discovery of an on-path node, which is common to the various centralised resource management cases; in addition, extensions to the application layer protocols may be needed to convey additional signalling-related information (this depends on the scenario). Similar considerations apply to non-NSIS hosts that are addressed by NSIS signalling messages. Here the proxy takes over the role of the NSIS Responder, see Figure 7. The proxy interacts with the service controller in order to notify the application of incoming requests and to respond to the NSIS Initiator depending on input from the Hancock, et al. Expires November 18, 2005 [Page 12] Internet-Draft Path-Decoupled NSIS May 2005 service controller. Administrative Domain +-----------------------------------+ | +-----------+ +-----------+ | | | Service @@@@@@@ NSIS | | | | Controller| | Initiator | | | +----@------+ | (Proxy) | | | @ +-----------+ | | @ | | | @ | | | +---@----+ +------+ | | |non-NSIS| | NSIS |------------ | | Host |#######|Router|############ | +--------+ +------+ | +-----------------------------------+ ######### = data path --------- = signalling messages @@@@@@@@@ = application layer signalling (possibly several protocols) Figure 6: Off-Path Signalling Initiator Proxy Administrative Domain +-----------------------------------+ | +-----------+ +-----------+ | | | NSIS @@@@@@@ Service | | | | Responder | | Controller| | | | (Proxy) | +------@----+ | | +-----------+ @ | | | @ | | | @ | | +------+ +----@---+ | ------------| NSIS | |non-NSIS| | ############|Router|#######| Host | | | +------+ +--------+ | +-----------------------------------+ ######### = data path --------- = signalling messages @@@@@@@@@ = application layer signalling (possibly several protocols) Figure 7: Off-Path Signalling Responder Proxy 4. Problem Structure The previous sections have outlined several possible network Hancock, et al. Expires November 18, 2005 [Page 13] Internet-Draft Path-Decoupled NSIS May 2005 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 the NSIS problem space, while others may use existing protocols or require additional work in some other forum. This section presents a decomposition of the problem space into several independent parts. 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). Hancock, et al. Expires November 18, 2005 [Page 14] Internet-Draft Path-Decoupled NSIS May 2005 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. 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. 4.2 Network Element Control Element control is essentially a management operation. Here, a general network management protocol might be used (such as SNMP [20] or a proprietary command line interface); or, for particular applications, a more specialised configuration protocol, such COPS in provisioning mode [21] or the protocols under development in netconf [22] and ForCES [23]. 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. 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 Hancock, et al. Expires November 18, 2005 [Page 15] Internet-Draft Path-Decoupled NSIS May 2005 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. 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. 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 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. Hancock, et al. Expires November 18, 2005 [Page 16] Internet-Draft Path-Decoupled NSIS May 2005 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. 4.6 Host Proxy Triggering In at least one configuration, the signalling is initiated off-path, typically because the end-host is NSIS-unaware. (This might be the case for either end of a data flow, sending or receiving.) As well as the general problems of transporting the signalling off-path (see Section 4.4) and determining the next peer to signal to (see Section 4.5), this scenario raises an addition special requirement: the need to interact with the user application for whose flows the signalling is being performed. The implication of this is that the signalling node in question can be assumed to taking part in the user application protocols which are setting up the flows themselves. How the signalling node and flow endpoint determine each other and communicate at this application level can be assumed to be outside the scope of NSIS; a typical case would be where the signalling node was also a proxy for the user application protocol. The signalling specific requirement is that the host and proxy should not initiate colliding signalling sessions. 4.7 Multi-Path Selection One scenario considers the use of NSIS to signal for state management on alternate paths that a flow would take under certain conditions. (The typical case is for pre-installation of state on backup paths Hancock, et al. Expires November 18, 2005 [Page 17] Internet-Draft Path-Decoupled NSIS May 2005 that would be selected in network failure situations.) In so far as signalling is not following the current flow, this can be considered a case of path-decoupled signalling. The requirements for this type of signalling are very similar to the normal path-coupled case, and a very similar split of responsibilities between network, common signalling layer (NTLP), and signalling application is possible. The extra sophistication needed is two-fold: o The underlying network layer must have the concept of multiple routes of different status (primary, backup, etc.) When the NTLP is establishing the peer node for signalling about a certain flow, the ideal case is that it can do so by using the normal path- coupled discovery process using signalling packets which emulate that flow, but explicitly invoking the routing infrastructure to treat those packets according to its alternate routing algorithms (however those are identified). o The application which generates the signalling must indicate and be aware of what class of route a signalling message is about. (This information must be agreed between signalling application peers, and also exchanged with the NTLP.) This implies an extension to the API to the common layer in order to carry these indications, in some near-standardised syntax. The standardised syntax of the second requirement must match the network capabilities of the first; one example is the extensions to MPLS of [24]. Once that extension is in place, the operation of the NTLP to invoke the underlying network appropriately seems to be mainly a node-internal (implementation) issue. 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 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. Hancock, et al. Expires November 18, 2005 [Page 18] Internet-Draft Path-Decoupled NSIS May 2005 The other main technical difference between path-coupled and decoupled signalling is that there are no longer well-defined constraints on the topological path taken by the signalling messages themselves. In the path-coupled case, these constraints can be used to eliminate certain attacks by off-path nodes on the NTLP operation, for example by ingress filtering. However, the strength of the protection possible always depends on the physical and topological characteristics of the network and is never perfect; most likely in the path-decoupled case, their place would have to be taken by other mechanisms. Details are for further study. 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 initial discussion for each of whether these require new development or could be satisfied using existing protocols. It is our conclusion that a small number of relatively precisely scoped extensions to existing NSIS (in particular, NTLP) functionality could be used to enhance the performance and usability of the NSIS protocol suite in several important networking environments, and in particular could ease deployment and interworking with other networks that attach to the Internet. We therefore recommend that the working group should consider taking on this work. 7. References 7.1 Normative References [1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004. [2] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002. [3] Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3583, September 2003. 7.2 Informative References [4] Hancock, R., "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-07 (work in progress), December 2004. Hancock, et al. Expires November 18, 2005 [Page 19] Internet-Draft Path-Decoupled NSIS May 2005 [5] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-05 (work in progress), February 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, http://www.ietf.org/html.charters/psamp-charter.html", 2005. [11] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 5.13.0, January 2005. [12] "NGN QoS Framework and Requirements", DTS/TISPAN-05009-NGN. [13] Dressler, F., "NSLP for Metering Configuration Signaling", draft-dressler-nsis-metering-nslp-01 (work in progress), February 2005. [14] Terzis, A., Braden, B., Vincent, S., and L. Zhang, "RSVP Diagnostic Messages", RFC 2745, January 2000. [15] 3GPP, "Architectural enhancements for end-to-end Quality of Service (QoS)", 3GPP TR 23.802 0.4.0, February 2005. [16] Lee, S., "Applicability Statement of NSIS Protocols in Mobile Environments", draft-ietf-nsis-applicability-mobility-signaling-01 (work in progress), February 2005. [17] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000. [18] Alfano, F., "Diameter Quality of Service Application", draft-alfano-aaa-qosprot-02 (work in progress), February 2005. [19] Farrel, A., "Path Computation Element (PCE) Architecture", Hancock, et al. Expires November 18, 2005 [Page 20] Internet-Draft Path-Decoupled NSIS May 2005 draft-ietf-pce-architecture-00 (work in progress), March 2005. [20] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [21] 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. [22] "Network Configuration (netconf) Charter, http://www.ietf.org/html.charters/netconf-charter.html", 2005. [23] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. [24] 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. 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 Hancock, et al. Expires November 18, 2005 [Page 21] Internet-Draft Path-Decoupled NSIS May 2005 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. Hancock, et al. Expires November 18, 2005 [Page 22] Internet-Draft Path-Decoupled NSIS May 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 November 18, 2005 [Page 23]