NSIS Working Group Internet Draft Robert Hancock (editor) Siemens/Roke Manor Research Ilya Freytsis Cetacean Networks Georgios Karagiannis University of
TwenteTwente/Ericsson John Loughney Nokia Sven Van den Bosch Alcatel Document: draft-ietf-nsis-fw-03.txtdraft-ietf-nsis-fw-04.txt Expires: December 2003 JuneMarch 2004 September 2003 Next Steps in Signaling: Framework Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract The Next Steps in Signaling working group is considering protocols for signaling information about a data flow along its path in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for such signaling protocols. This document provides a model for the network entities that take part in such signaling, and the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with a separate upper layers for each specific signaling application. An initial proposal for the split between these layers is given, describing the overall functionality of the lower layer, and discussing the ways that upper layer behavior can be adapted to specific signaling application requirements. This framework also considers the general interactions between signaling and other network layer functions, specifically routing, mobility, and address translators. The different events that impact signaling operation are described, along with how their handling should be divided between the generic and application-specific layers. Finally, an example signaling application (for Quality of Service) is described in more detail. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 . [Editor's note: if - as is likely - we don't end up using these words in the framework, this paragraph will disappear.]Table of Contents 1 Introduction ...................................................3 1.1 Definition of the NSIS Signaling Problem .................3 1.2 Scope and Structure of the NSIS Framework ................4 2 Terminology ....................................................5 3 Overview of Signaling Scenarios and Protocol Structure .........6 3.1 Fundamental Signaling Concepts ...........................6 3.1.1 Simple Network and Signaling Topology ..................6 3.1.2 Path-Coupled and Path-Decoupled Signaling ..............7 3.1.3 Signaling to Hosts, Networks and Proxies ...............8 3.1.4 Signaling Messages and Network Control State ..........10 3.1.5 Data Flows and Sessions ...............................10 3.2 Layer Model for the Protocol Suite ......................11 3.2.1 Layer Model Overview ..................................11 3.2.2 Layer Split Concept ...................................13...................................12 3.2.3 Bypassing Intermediate Nodes ..........................13 3.2.4 Core NTLP Functionality ...............................14 3.2.4...............................15 3.2.5 State Management Functionality ........................14 3.2.5........................15 3.2.6 Path De-Coupled Operation .............................15.............................16 3.3 Signaling Application Properties ........................16........................17 3.3.1 Sender/Receiver Orientation ...........................16...........................17 3.3.2 Uni- and Bi-Directional Operation .....................17.....................18 3.3.3 Heterogeneous Operation ...............................18...............................19 3.3.4 Aggregation ...........................................19 3.3.5 Peer-Peer and End-End Relationships ...................18 3.3.5...................20 3.3.6 Acknowledgements and Notifications ....................19 3.3.6....................20 3.3.7 Security and Other AAA Issues .........................19.........................21 4 The NSIS Transport Layer Protocol .............................20.............................21 4.1 Internal Protocol Components ............................20............................22 4.2 Addressing ..............................................21..............................................22 4.3 Classical Transport Functions ...........................22...........................23 4.4 Lower Layer Interfaces ..................................23..................................25 4.5 Upper Layer Services ....................................24....................................25 4.6 Identity Elements .......................................24.......................................26 4.6.1 Flow Identification ...................................24...................................26 4.6.2 Session Identification ................................25................................27 4.6.3 Signaling Application Identification ..................25..................27 4.7 Security Properties .....................................26.....................................28 5 Interactions with Other Protocols .............................26.............................28 5.1 IP Routing Interactions .................................26.................................28 5.1.1 Load Sharing and Policy-Based Forwarding ..............27..............29 5.1.2 Route Changes .........................................28 5.1.3 Router Redundancy .....................................29.........................................29 5.2 Mobility Interactions ...................................29 5.2.1 Addressingand Encapsulation ..........................30 5.2.2 Localized Path Repair .................................31 5.2.3 Update on the Unchanged Path ..........................31 5.2.4 Interaction with Mobility SignalingMultihoming Interactions ...................31 5.2.5 Interaction with Seamless Handover Protocols ..........335.3 Interactions with NATs ..................................33 5.4 Interactions with IP Tunneling ..........................34 6 Signaling Applications ........................................34........................................35 6.1 Signaling for Quality of Service ........................34........................35 6.1.1 Protocol Messages .....................................34Message Semantics ............................36 6.1.2 State Management ......................................35......................................36 6.1.3 QoS Forwarding ........................................36 6.1.4Route Changes and QoS Reservations ....................36 6.1.5....................37 6.1.4 Resource Management Interactions ......................38 6.2 Other Signaling Applications ............................39............................40 7 Security Considerations .......................................39.......................................40 8 Change History ................................................40................................................41 8.1 Changes from draft-ietf-nsis-fw-02.txt ..................40draft-ietf-nsis-fw-03.txt ..................41 8.2 Changes from draft-ietf-nsis-fw-02.txt ..................42 8.3 Changes from draft-ietf-nsis-fw-01.txt ..................40 References.......................................................41 Acknowledgments..................................................43..................42 References.......................................................43 Acknowledgments..................................................45 Authors' Addresses...............................................44Addresses...............................................46 Intellectual Property Considerations.............................45Considerations.............................46 Full Copyright Statement.........................................45Statement.........................................47 1 Introduction 1.1 Definition of the NSIS Signaling Problem The NSIS working group is considering protocols for signaling information about a data flow along its path in the network. It is assumed that the path taken by the data flow is already determined by network configuration and routing protocols, independent of the signaling itself; that is, signaling to set up the routes themselves is not considered. Instead, the signaling simply interacts with nodes along the data flow path. Additional simplifications are that the actual signaling messages pass directly through these nodes themselves (i.e. the 'path-coupled' case, see section 3.1.2) and that only unicast data flows are considered. The signaling problem in this sense is very similar to that addressed by RSVP .. However, there are two generalizations. Firstly, the intention is that components of the NSIS protocolsprotocol suite will be usable in different parts of the Internet, for different needs, without requiring a complete end-to-end deployment (in particular, the signaling protocol messages may not need to run all the way between the data flow endpoints). Secondly, the signaling is intended for more purposes than just QoS (resource reservation). The basic mechanism to achieve this flexibility is to divide the signaling protocol stack into two layers: a generic (lower) layer, and an upper layer specific to each signaling application. The scope of NSIS work is to define both the generic protocol, and initially anupper layerlayers suitable for QoS signaling similar(similar to the corresponding functionality in RSVP. Further signaling applications, such asRSVP) and middlebox signaling,signaling. Further applications may be considered later. 1.2 Scope and Structure of the NSIS Framework The underlying requirements for signaling in the context of NSIS are defined in  and a separate security threats document ;; other related requirements can be found in  and .. This framework does not replace or update these requirements. Discussions about lessons to be learned from existing signaling and resource management protocols are contained in separate analysis documents , ., . The role of this framework is to explain how NSIS signaling should work within the broader networking context, and how the signaling protocols should be structured atto describe the overall level.structure of the protocol suite itself. Therefore, it discusses important protocol considerations, such as routing, mobility, security, and interactions with network 'resource' management (in the broadest sense). The basic context for NSIS protocols is given in section 3. Section 3.1 describes the fundamental elements of NSIS protocol operation in comparison to RSVP; in particular, section 3.1.3 describes more general signaling scenarios, and 3.1.4 defines a broader class of signaling applications for which the NSIS protocols should be useful. The two-layer protocol architecture that supports this generality is described in section 3.2, and section 3.3 gives examples of the ways in which particular signaling application properties can be accommodated within signaling layer protocol behavior. The overall functionality required from the lower (generic) protocol layer is described in section 4. This is not intended to define the protocoldetailed design of the protocol or even design options, although some are described as examples. It describes the interfaces between this lower layer protocol and the IP layer (below) and signaling application protocols (above), including the identityidentifier elements that appear on these interfaces.interfaces (section 4.6). Following this, section 5 describes how signaling applications that use the NSIS protocols can interact sensibly with network layer operations, specifically routing (and re-routing), IP mobility, and network address translation. Section 6 describes particular signaling applications. The example of signaling for QoS (comparable to core RSVP QoS signaling functionality) is given in detail in section 6.1, which describes both the signaling application specific protocol and example modes of interaction with network resource management and other deployment aspects. However, note that these examples are included only as background and for explanation; it is not intended to define an over- arching architecture for carrying out resource management in the Internet. Further possible signaling applications are outlined in section 6.2. 2 Terminology [Editor's note: it is a matter of taste where we put this.]Classifier - an entity which selects packets based on their contents according to defined rules. [Data] flow - a stream of packets from sender to receiver which is a distinguishable subset of a packet stream. Each flow is distinguished by some flow identifier (see section 4.6.1). Edge node - aan (NSIS-capable) node on the boundary of some administrative domain. Interior nodes - the set of (NSIS-capable) nodes which form an administrative domain, excluding the edge nodes. NSIS Entity (NE) - the function within a node which implements an NSIS protocol. In the case of path-coupled signaling, the NE will always be on the data path. NSIS Signaling Layer Protocol (NSLP) - generic term for an NSIS protocol component that supports a specific signaling application. See also section 3.2.1. NSIS Transport Layer Protocol (NTLP) - placeholder name for the NSIS protocol component that will support lower layer (signaling application independent) functions. See also section 3.2.1. Path-coupled signaling - a mode of signaling where the signaling messages follow a path that is tied to the data messages. Path-decoupled signaling - signaling - signalingfor state manipulation related to data flows, but only loosely coupled to the data path, e.g. at the AS level. Peer discovery - the act of locating and/or selecting which NSIS peer to carry out signaling exchanges with for a specific data flow. Peer relationship - signaling relationship between two adjacent NSIS entities (i.e. NEs with no other NEs between them). Receiver - the node in the network which is receiving the data packets in a flow. Sender - the node in the network which is sending the data packets in a flow. Session - application layer flow of information for which some network control state information is to be manipulated or monitored (see section 4.6.2). Signaling application - the purpose of the NSIS signaling: a service could be QoS management, firewall control, and so on. Totally distinct from any specific user application. 3 Overview of Signaling Scenarios and Protocol Structure 3.1 Fundamental Signaling Concepts 3.1.1 Simple Network and Signaling Topology The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate state in the network. This state is related to a data flow and is installed and maintained on the NSIS Entities (NEs) along the data flow path through the network; not every node has to contain an NE. The basic protocol concepts do not depend on the signaling application, but the details of operation and the information carried do. This section discusses the basic entities involved with signaling as well as interfaces between them. Two NSIS entities that communicate directly are said to be in a 'peer relationship'. This concept might loosely be described as an 'NSIS hop'; however, there is no implication that it corresponds to a single IP hop. Either or both NEs might store some state information about the other, but there is no assumption that they necessarily establish a long-term signaling connection between themselves. It is common to consider a network as composed of various domains, e.g. for administrative or routing purposes, and the operation of signaling protocols may be influenced by these domain boundaries. However, it seems there is no reason to expect that an 'NSIS domain' should exactly overlap with an IP domain (AS, area) but it is likely that its boundaries would consist of boundaries (segments) of one or several IP domains. Figure 1 shows a diagram of nearly the simplest possible signaling configuration. A single data flow is running from an application in the sender to the receiver via routers R1, R2 and R3. Each host and two of the routers contain NEs which exchange signaling messages - possibly in both directions - about the flow. This scenario is essentially the same as that considered by RSVP for QoS signaling; the main difference is that we make no assumptions here about the particular sequence of signaling messages that will be invoked. Sender Receiver +-----------+ +----+ +----+ +----+ +-----------+ |Application|----->| R1 |----->| R2 |----->| R3 | ---->|Application||----->|Application| | +--+ | |+--+| |+--+| +----+ | +--+ | | |NE|====|======||NE||======||NE||==================|===|NE| | | +--+ | |+--+| |+--+| | +--+ | +-----------+ +----+ +----+ +-----------+ +--+ |NE| = NSIS ==== = Signaling ---> = Data flow messages +--+ Entity Messages (unidirectional) Figure 1: Simple Signaling and Data Flows 3.1.2 Path-Coupled and Path-Decoupled Signaling We can consider two basic paradigms for resource reservation signaling, which we refer to as "path-coupled" and "path-decoupled". In the path-coupled case, signaling messages are routed only through nodes (NEs) that are in the data path. They do not have to reach all the nodes on the data path (for example, there could be proxies distinct from the sender and receiver as described in section 3.1.3, or intermediate signaling-unaware nodes); and between adjacent NEs, the route taken by signaling and data might diverge. The path-coupled case can be supported by various addressing styles, with messages either explicitly addressed to the neighbor on-path NE, or routedaddressed identically to the data packets but also with the router alert option (see  and ) and intercepted. These cases are considered in section 4.2. In the second case, some network configurations may split the signaling and data paths (see section 5.1.1); this is considered an error case for path-coupled signaling. In the path-decoupled case, signaling messages are routed to nodes (NEs) which are not assumed to be on the data path, but which are (presumably) aware of it. Signaling messages will always be directly addressed to the neighbor NE, and the signaling endpoints may have no relation at all with the ultimate data sender or receiver. The implications of path-decoupled operation for the NSIS protocols are considered briefly in section 3.2.5;3.2.6; however, the initial goal of NSIS and this framework is to concentrate mainly on the path-coupled case. 3.1.3 Signaling to Hosts, Networks and Proxies There are different possible triggers for the signaling protocols. Amongst them are user applications (that are using NSIS signaling services), other instances of the signaling,signaling applications, network management actions, some network events, and so on. The variety of possible triggers requires that the signaling can be initiated and terminated in the different parts of the network - hosts, domain boundary nodes (edge nodes) or interior domain nodes. The NSIS protocol suite extends the RSVP model to consider this wider variety of possible signaling exchanges. As well as the basic end-to- end model already described, examples such as end-to-edge and edge- to-edge can be considered. The edge-to-edge case might involve the edge nodes communicating directly, as well as via the interior nodes. While the end-to-edge (host-to-network) scenario requires only intra- domain signaling, the other cases might need inter-domain NSIS signaling as well if the signaling endpoints (hosts or network edges) are connected to different domains. Depending on the trust relation between concatenated NSIS domains the edge-to-edge scenario might cover single domain or multiple concatenated NSIS domains. The latter case assumes the existence of thetrust relationrelations between domains. In some cases it is desired to be able to initiate and/or terminate NSIS signaling not from the end host that sends/receives the data flow, but from the some other entities in the network that can be called signaling proxies. There could be various reasons for this: signaling on behalf of the end hosts that are not NSIS-aware, consolidation of the customer accounting (authentication, authorization) in respect to consumed application and transport resources, security considerations, limitation of the physical connection between host and network and so on. This configuration can be considered as a kind of "proxy on the data path", see Figure 2. Proxy1 Proxy2 +------+ + + + ---- ----++----+ +----+ +----+ +----+ +--------+ |Sender|-...->|Appl|---->| R |-.->| R |--->|Appl|-...->|Receiver| | | |+--+| |+--+| |+--+| +----+ | | +------+ ||NE||=====||NE||=.==||NE||====||NE|| +--------+ |+--+| |+--+| |+--+| |+--+| +----+ +----+ +----+ +----+ +--+ |NE| = NSIS ==== = Signaling ---> = Data flow messages +--+ Entity Messages (unidirectional) Appl = signaling application Figure 2: "On path" NSIS proxy This configuration presents 2 specific challenges for the signaling: *) TheA proxy that terminates signaling on behalf of the NSIS-unaware host (or part of the network) should be able to make determination that it is a last NSIS aware node along the path. *) Where a proxy initiates NSIS signaling on behalf of the NSIS unaware host, interworking with some other "local" technology might be required, for example to provide QoS reservation from proxy to the end host in the case of QoS signaling application. +------+ +----+ +----+ +----+ +-----------+ |Sender|----->| PA |----->| R2 |----->| R3 | ---->| Receiver | | | |+--+| |+--+| +----+ | +--+ | +------+ ||NE||======||NE||==================|===|NE| | |+--+| |+--+| | +--+ | +-..-+ +----+ +-----------+ .. .. +-..-+ |Appl| +----+ Appl = signaling PA = Proxy for signaling application application Figure 3: "Off path" NSIS proxy Another possible configuration, shown in Figure 3, is where an NE can send and receive signaling information to a remote processor. The NSIS protocols may or may not be suitable for this remote interaction, but in any case it is not currently part of the NSIS problem. This configuration is supported by considering the NE as a proxy at the signaling application level. This is a natural implementation approach for some policy control and centralized control architectures, see also section 6.1.5. +------+ +----+ +----+ +----+ +-----------+ |Sender|----->| PA |----->| R2 |----->| R3 | ---->| Receiver | | | |+--+| |+--+| +----+ | +--+ | +------+ ||NE||======||NE||==================|===|NE| | |+--+| |+--+| | +--+ | +-..-+ +----+ +-----------+ .. .. +-..-+ |Appl| +----+ Appl = signaling PA = Proxy for signaling application application Figure 3: "Off path" NSIS proxy6.1.4. 3.1.4 Signaling Messages and Network Control State The distinguishing features of the signaling supported by the NSIS protocols are that it is related to specific flows (rather than to network operation in general), and that it involves nodes in the network (rather than running transparently between the end hosts). Therefore, each signaling application (upper layer) protocol must carry per-flow information for the aspects of network-internal operation interesting to that signaling application. An example for the case of an RSVP-like QoS signaling application would be state data representing resource reservations. However, more generally, the per-flow information might be related to some other control function in routers and middleboxes along the path. Indeed, the signaling might simply be used to gather per-flow information, without modifying network operation at all. We call this information generically 'network control state'. Signaling messages may install, modify, refresh, or simply read this state from network elements for particular data flows. Usually a network element will also manage this information at the per-flow level, although coarser-grained ('per-class') state management is also possible. 3.1.5 Data Flows and Sessions Formally, a data flow is a (unidirectional) sequence of packets between the same endpoints which all follow a unique path through the network (determined by IP routing and other network configuration). A flow is defined by a packet classifier (in the simplest cases, just the destination address and topological origin are needed). In general we assume that when discussing only the data flow path, we only need to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple or equivalent). A session is an application layer concept for a (unidirectional) flow of information between two endpoints, for which some network state is to be allocated or monitored. (Note that this use of the term 'session' is not identical to the usage in RSVP. It is closer to the session concept of, for example, the Session Initiation Protocol.) The simplest service provided by NSIS signaling protocols is management of network control state at the level of a specific flow, as described in the previous subsection. In particular, it should be possible to monitor routing updates as they change the path taken by a flow and, for example, update network state appropriately. This is no different from the case for RSVP (local path repair). Where there is a 1:1 flow:session relationship, this is all that is required. However, for some more complex scenarios (especially mobility and multihoming related ones, see  and the mobility discussion of )) it is desirable to update the flow:session mapping during the session lifetime. For example, a new flow can be added, and the old one deleted (and maybe in that order, for a 'make-before-break' handover), effectively transferring the network control state between data flows to keep it associated with the same session. Such updates are best managed by the end systems (generally, systems which understand the flow:session mapping and are aware of the packet classifier change). To enable this, it must be possible to relate signaling messages to sessions as well as data flows. A session identifier (section 4.6.2) is one component of the solution. 3.2 Layer Model for the Protocol Suite 3.2.1 Layer Model Overview In order to achieve a modular solution for the NSIS requirements, the NSIS protocol suite will be structured in 2 layers: *) a 'signaling transport' layer, responsible for moving signaling messages around, which should be independent of any particular signaling application; and *) a 'signaling application' layer, which contains functionality such as message formats and sequences, specific to a particular signaling application. For the purpose of this document, we use the term 'NSIS Transport Layer Protocol' (NTLP) to refer to the component that will be used in the transport layer. We also use the term 'NSIS Signaling Layer Protocol' (NSLP) to refer generically to any protocol within the signaling application layer; in the end, there will be several NSLPs, largely independent of each other. These relationships are illustrated in Figure 4. Note that the NTLP may or may not have an interesting internal structure (e.g. including existing transport protocols) but that is not relevant at this level of description. ^ +-----------------+ | | NSIS Signaling | | | Layer Protocol | NSIS | +----------------| for middleboxes | Signaling | | NSIS Signaling | +-----------------+ Layer | | Layer Protocol +--------| NSIS Signaling | | | for QoS | | Layer Protocol | | +-----------------+ | for ... | V +-----------------+ ============================================= NSIS ^ +--------------------------------+ Transport | | NSIS Transport Layer Protocol | Layer V +--------------------------------+ ============================================= +--------------------------------+ . IP and lower layers . . . Figure 4: NSIS Protocol Components Note that not every generic function has to be located in the NTLP. Another option would be to have re-usable components within the signaling application layer. Functionality within the NTLP should be restricted to that which interacts strongly with other transport and lower layer operations. +------+ +------+ +------+ +------+ | NE | | NE | | NE | | NE | |+----+| | | |+----+| |+----+| ||NSLP|| | | ||NSLP|| ||NSLP|| || 1 || | | || 2 || || 1 || |+----+| | | |+----+| |+----+| | || | | | | | | || | |+----+| |+----+| |+----+| |+----+| ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== |+----+| |+----+| |+----+| |+----+| +------+ +------+ +------+ +------+ Figure 5: Signaling with Heterogeneous NSLPs Because NSIS problem includes multiple signaling applications, it is very likely that a particular NSLP will only be implemented on a subset of the NSIS-aware nodes on a path, as shown in Figure 5. Messages for unrecognized NSLPs are forwarded at the NTLP level.3.2.2 Layer Split Concept This section describes the basic concepts underlying the functionality of the NTLP. Firstly, we make a working assumption that the protocol mechanisms of the NTLP operate only between adjacent NEs (informally, the NTLP is a 'hop-by-hop' protocol), whereas any larger scope issues (including e2e aspects) are left to the upper layers. The way in which the NTLP works can be described as follows: When a signaling message is ready to be sent from one NE, it is given to the NTLP along with information about what flow it is for; it is then up to the NTLP to get it to the next NE along the path (up- or down- stream), where it is received and the responsibility of the NTLP ends. Note that there is no assumption here about how the messages are actually addressed (this is a protocol design issue, and the options are outlined in section 4.2). The key point is that the NTLP for a given NE does not use any knowledge about addresses, capabilities, or status of any NEs other than its direct peers. The NTLP in the receiving NE either forwards the message directly, or, if there is an appropriate signaling application locally, passes it upwards for further processing; the signaling application can then generate another message to be sent via the NTLP. In this way, larger scope (including end-to-end) message delivery is achieved. This definition relates to NTLP operation. It does not restrict the ability of an NSLP to send messages by other means. For example, an NE in the middle or end of the signaling path could send a message directly to the other end as a notification of or acknowledgement for some signaling application event. However, the issues in sending such messages (endpoint discovery, security, NAT traversal and so on) are so different from the direct peer-peer case that there is no benefit in extending the NTLP to include such non-local functionality; instead, an NSLP which requires such messages and wants to avoid traversing the path of NEs should use some other existing transport protocol - for example, UDP or DCCP would be a good match for many of the scenarios that have been proposed. Acknowledgements and notifications of this type are considered further in section 220.127.116.11.3.6. One motivation for restricting the NTLP to only peer-relationship scope is that if there are any options or variants in design approach - or, worse, in basic functionality - it is easier to manage the resulting complexity if it only impacts direct peers rather than potentially the whole Internet. 3.2.3 Core NTLP Functionality This section describes the basic functionality to be supported by the NTLP. Note thatBypassing Intermediate Nodes Because the overallNSIS problem includes multiple signaling solutionapplications, it is very likely that a particular NSLP will alwaysonly be the resultimplemented on a subset of joint NSLP and NTLP operation; for example, we can always assume that an NSLP is operating abovethe NTLP and taking care of end-to-end issues (e.g. recovery of messages after restarts). Therefore, NTLP functionality is essentially just efficient upstream and downstream peer-peer message delivery,NSIS-aware nodes on a path, as shown in Figure 5. In addition, a wide variety of network scenarios. Message delivery includes the act of locating and/or selecting which NTLP peernode inside an aggregation region will still wish to carry outignore signaling exchanges withmessages which are per-flow, even if they are for a specific data flow. This discovery might be an activesignaling application which the node is able to process (using specificin general. +------+ +------+ +------+ +------+ | NE | | NE | | NE | | NE | |+----+| | | |+----+| |+----+| ||NSLP|| | | ||NSLP|| ||NSLP|| || 1 || | | || 2 || || 1 || |+----+| | | |+----+| |+----+| | || | | | | | | || | |+----+| |+----+| |+----+| |+----+| ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== |+----+| |+----+| |+----+| |+----+| +------+ +------+ +------+ +------+ Figure 5: Signaling with Heterogeneous NSLPs Where signaling packets) or a passivemessages traverse such NSIS-aware intermediate nodes, it is desirable to process (a side effect of using a particular addressing mode).them at the lowest level possible (in particular, on the fastest path). In addition,order to offer a non-trivial message transfer service (in terms of security, reliability and so on) to the peer NSLP nodes, it appearsis important that theNTLP can sensibly carryat intermediate nodes is as transparent as possible, that is, it carries out minimal processing. In addition, if intermediate nodes have to do slow-path processing of all NSIS messages, this eliminates many of the functionsscaling benefits of enabling signaling messages to pass through middleboxes, since thisaggregation, unless tunneling is closely related toused. Considering first the problemcase of routing the signalingmessages insent with the first place. Further details about NTLP functionalityrouter alert option, there are contained in sections 3.2.4 and 4.3. 3.2.4 State Management Functionality Internet signaling requires the existence and managementtwo complementary methods to achieve this bypassing of state withinintermediate NEs: *) At the network for several reasons. This section describes how state management functionality is split across the NSIS layers. 0. How the NTLP internal state is managed isIP layer, a matter for its design and indeed implementation. 1. Conceptually, the NTLP providesset of protocol numbers can be used, or a uniform message delivery service. It is unawarerange of the differencevalues in state semantics between different types of signaling application message (e.g. whether a message changes or just refreshes signaling application state, or even has nothing to with signaling application state at all). 2. An NTLP instance processes and if necessary forwards all signaling applicationthe router alert option. In this way, messages "immediately". (It might offer different service classes, but these wouldcan be distinguished e.g. by reliability or priority, not state aspects.)marked with an implied granularity, and routers can choose to apply further slow-path processing only to configured subsets of messages. This means thatis the method used in  to distinguish per-flow and per- aggregate signaling. *) The NTLP does not know explicit timer or message sequence information forcould process the signaling application; andmessage but determine that there was no local signaling application messages pass immediately through an NSLP-unaware node (they can'tit was relevant to. At this stage, the message can be jittered there, or re- sent onto alternative paths if re-routing takes place later). 3. Within any node, it's an implementation decision whetherreturned unchanged to generate/jitter/filter refreshes either separately within each signaling application that needs this functionality, or as part of generic/shared code (a "soft-state management toolbox") more closely associated withthe NTLP. The choice doesn't affectIP layer for normal forwarding; the NTLP specification at all. Implementations might piggy-back NTLP soft- state refresh information (ifintermediate NE has effectively chosen to be transparent to the NTLP works this way) on signaling application messages, or even combine soft-state management between layers. The state machinesmessage in question. In both cases, the existence of the NTLP and NSLPs remain logically independent, but an implementationintermediate NE is free to allow them to interact to reducetotally hidden from the load onNSLP nodes. If later stages of the network tosignaling use directly addressed messages (e.g. for reverse routing), they will not involved the same levelintermediate NE at all, except perhaps as would be achieved bya monolithic model. 4. Itnormal router. There may be helpful for signaling applications to receive state- management related 'triggers' fromcases where the NTLP, that a peer has failed or become available ("down/up notifications"). These triggersintermediate NE would like to do some restricted protocol processing, for example: *) Translating addresses in message payloads (compare section 4.6.1); note this would have to be about adjacent NTLP peers, rather thandone to messages passing both directions through a node. *) Updating signaling application peers. Wepayloads with local status information (e.g. path property measurement inside a domain). If this can considerbe done without fully terminating the NSIS protocols, this as another casewould allow a more lightweight implementation of route change detection/notification (whichthe intermediate NE, and a more direct 'end-to-end' NTLP association between the peer NSLPs where the signaling application is also allowed to do anyway). However, apart from generating such triggers,fully processed. On the NTLP takes no action itself on such events,other thanhand, this is only possible with a limited class of possible NTLP designs, and makes it harder for the NTLP to ensure that subsequent signalingoffer a security service (since messages are correctly routed. 5.have to be partially protected). The existencefeasibility of these triggers doesn't replace NSLP refreshes as the mechanism for maintaining liveness at the signaling application level. Inthis sense, up/down notifications are advisories which allow faster reaction to events in the network, but shouldn'tapproach will be built into NSLP semantics. (This is essentially the same distinction - withevaluated during the same rationale - as SNMP makes between traps and normal message exchanges.) 3.2.5 Path De-Coupled Operation Path-decoupled signaling is defined as signaling for state installation alongNTLP design. 3.2.4 Core NTLP Functionality This section describes the data path, withoutbasic functionality to be supported by the restriction of passing only through nodesNTLP. Note that are located onthe data path. Signaling messages canoverall signaling solution will always be routed to nodes offthe data path, but which are (presumably) awareresult of it. This allows a looser coupling between signalingjoint NSLP and data plane nodes, e.g. atNTLP operation; for example, we can always assume that an NSLP is operating above the autonomous system level. The main advantages of path-decoupled signaling are ease of deploymentNTLP and supporttaking care of additional functionality. The easeend-to-end issues (e.g. recovery of deployment comes frommessages after restarts). Therefore, NTLP functionality is essentially just efficient upstream and downstream peer-peer message delivery, in a restrictionwide variety of network scenarios. Message delivery includes the number of impacted nodes in caseact of deploymentlocating and/or upgrade of an NSLP. It would allow,selecting which NTLP peer to carry out signaling exchanges with for instance, deployinga solution without upgrading any of the routers in thespecific data plane. Additional functionality that canflow. This discovery might be supported includes the use of off-path proxies to support authorization or accounting architectures. There are potentially significant differences in the way that the twoan active process (using specific signaling paradigms should be analyzed. Usingpackets) or a single centralized off-path NE may increase the requirements in termspassive process (a side effect of message handling; onusing a particular addressing mode). In addition, it appears that the other hand, path-decoupled signaling is equally applicable to distributed off-path entities. Failure recovery scenarios need to be analyzed differently because fate-sharing between data and control planeNTLP can no longer be assumed. Furthermore, the interpretation of sender/receiver orientation becomes less natural. With the local operation of NTLP, the impactsensibly carry out many of path- decoupled signaling onthe routingfunctions of enabling signaling messages to pass through middleboxes, since this is presumably restrictedclosely related to the problem of peer determination. The assumption thatrouting the off-path NSIS nodes are loosely tied tosignaling messages in the data path suggests, however, that peer determination can still be based on L3 routing information. This means that a path-decoupledfirst place. Further details about NTLP functionality are contained in sections 3.2.5 and 4.3. 3.2.5 State Management Functionality Internet signaling solution could be implemented using a lower layer protocol presentingrequires the same service interface to NSLPs asexistence and management of state within the path-coupled NTLP. 3.3 Signaling Application Properties It is clear that many signaling applications will require specific protocol behavior in their NSLP.network for several reasons. This section outlines some ofdescribes how state management functionality is split across the optionsNSIS layers. (Note that how the NTLP internal state is managed is a matter for NSLP behavior; further work on selecting from these options would depend on detailed analysis ofits design and indeed implementation.) 1. Conceptually, the signaling application in question. 3.3.1 Sender/Receiver Orientation In some signaling applications,NTLP provides a node at one enduniform message delivery service. It is unaware of the data flow takes responsibility for requesting special treatment - such asdifference in state semantics between different types of signaling application message (e.g. whether a resource reservation - from the network. Which end may depend on themessage changes or just refreshes signaling application,application state, or characteristics of the network deployment. A sender-initiated approach is when the sender of the data flow requests and maintains the treatment for that flow. In a receiver- initiated approach the receiver of the data flow requests and maintains the treatment for that flow. The NTLP itselfeven has no freedom in this area: next NTLP peers have to be discovered in the sendernothing to receiver direction, but after that time the default assumption is thatwith signaling is possible both upstreamapplication state at all). 2. An NTLP instance processes and downstream (unless possibly aif necessary forwards all signaling application specifically indicates this ismessages "immediately". (It might offer different service classes, but these would be distinguished e.g. by reliability or priority, not required).state aspects.) This impliesmeans that backward routing state must be maintained bythe NTLP does not know explicit timer or that backward routingmessage sequence information must be available infor the signaling message. The senderapplication; and receiver initiated approaches have several differences in their operational characteristics. The main ones are as follows: *) In a receiver-initiated approach, thethat signaling application messages traveling from the receiverpass immediately through an NSLP-unaware node (their timing cannot be jittered there, nor can messages be stored up to the sender mustbe backward routed suchre-sent on a new paths in case of a later re-routing event). 3. Within any node, it is an implementation decision whether to generate/jitter/filter refreshes either separately within each signaling application that they follow exactlyneeds this functionality, or to integrate it with the same pathNTLP implementation as was followed bya generic "soft-state management toolbox"; the signaling messages belonging tochoice doesn't affect the same flow traveling fromNTLP specification at all. Implementations might piggy-back NTLP soft-state refresh information (if the sender toNTLP works this way) on signaling application messages, or even combine soft-state management between layers. The state machines of the receiver. In a sender-initiated approach, provided acknowledgementsNTLP and notifications can be securely delivered to the sending node, backward routingNSLPs remain logically independent, but an implementation is not necessary, and nodes do not havefree to maintain backward routing state. *) In a sender-initiated approach, a mobile node can initiate a reservation for its outgoing flows as soon as it has movedallow them to another roaming subnetwork. In a receiver-initiated approach, a mobile node hasinteract to informreduce the receiver about its handover, thus allowingload on the receivernetwork to initiatethe same level as would be achieved by a reservationmonolithic model. 4. It may be helpful for these flows. For incoming flows, the reverse argument applies. *) A sender- (receiver-) initiated approach will allow faster setup and modification if the sender (receiver) is also authorizedsignaling applications to carry out the operation. A mismatch between authorizing and initiating NEs will cause additional message exchanges either inreceive state- management related 'triggers' from the NSLP or in a protocol executed prior to NSIS invocation. NoteNTLP, that a peer has failed or become available ("down/up notifications"). These triggers would be about adjacent NTLP peers, rather than signaling application peers. We can consider this may complicate modificationsas another case of network control state for existing flows. *) Whereroute change detection/notification (which the signalingNTLP is looking for the last (nearestalso allowed to receiver) NEdo anyway). However, apart from generating such triggers, the NTLP takes no action itself on such events, other than to ensure that subsequent signaling messages are correctly routed. 5. The existence of these triggers doesn't replace NSLP refreshes as the mechanism for maintaining liveness at the data path, receiver orientedsignaling is most efficient; sender orientation would be possible, but take more messages. *)application level. In either case,this sense, up/down notifications are advisories which allow faster reaction to events in the initiator can generallynetwork, but shouldn't be informed faster about reservation failures thanbuilt into NSLP semantics. (This is essentially the remote end. 3.3.2 Uni-same distinction - with the same rationale - as SNMP makes between traps and Bi-Directionalnormal message exchanges.) 3.2.6 Path De-Coupled Operation For somePath-decoupled signaling applications and scenarios,is defined as signaling may only be consideredfor a unidirectional data flow. However, in other cases, there may be interesting relationships betweenstate installation along the signaling fordata path, without the two flowsrestriction of a bi-directional session; an example is QoS for a voice call. Notepassing only through nodes that are located on the path in the two directions may differ due to asymmetric routing. In the basic case, bi-directional signalingdata path. Signaling messages can simply use a separate instance of the same signaling mechanism in each direction. In constrained topologies where parts of the route are symmetric, it maybe possible to use a more unified approachrouted to bi-directional signaling, e.g. carryingnodes off the two signaling directions in common messages.data path, but which are (presumably) aware of it. This optimization might be used for example to make mobile QoSallows a looser coupling between signaling more efficient. In either case,and data plane nodes, e.g. at the correlationautonomous system level. The main advantages of thepath-decoupled signaling forare ease of deployment and support of additional functionality. The ease of deployment comes from a restriction of the two flow directions is carried outnumber of impacted nodes in thecase of deployment and/or upgrade of an NSLP. The NTLP would simply be enabled to bundle the messages together. 3.3.3 Heterogeneous OperationIt is likely that the appropriate way to describe the state NSIS is signalingwould allow, for will vary from one partinstance, deploying a solution without upgrading any of the network to another (depending on signaling application). For examplerouters in the QoS case, resource descriptionsdata plane. Additional functionality that are valid for inter-domain links will probablycan be different from those useful for intra-domain operation (andsupported includes the latter will differ from one domainuse of off-path proxies to another). Onesupport authorization or accounting architectures. There are potentially significant differences in the way to address this issue is to considerthat the state description used withintwo signaling paradigms should be analyzed. Using a single centralized off-path NE may increase the NSLP as carriedrequirements in globally-understood objects and locally-understood objects. The local objects are onlyterms of message handling; on the other hand, path-decoupled signaling is equally applicable for intra-domain signaling, whileto distributed off-path entities. Failure recovery scenarios need to be analyzed differently because fate-sharing between data and control plane can no longer be assumed. Furthermore, the global objects are mainly used in inter-domain signaling. Note thatinterpretation of sender/receiver orientation becomes less natural. With the local objects are still partoperation of NTLP, the protocol but are inserted, used and removed by one single domain. The purposeimpact of this divisionpath- decoupled signaling on the routing of signaling messages is presumably restricted to provide additional flexibility in defining the objects carried bythe NSLP suchproblem of peer determination. The assumption that onlythe objects applicable in a particular settingoff-path NSIS nodes are used. One approach for reflectingloosely tied to the distinction isdata path suggests, however, that local objects couldpeer determination can still be put into separate local messages that are initiated and terminated within one single domain; an alternative isbased on L3 routing information. This means that theya path-decoupled signaling solution could be "stacked" withinimplemented using a lower layer protocol presenting the same service interface to NSLPs as the path-coupled NTLP. A new message transport protocol (possibly derived from the path-coupled NTLP) would be needed, but NSLP messages that are used anyway for inter-domain signaling. 3.3.4 Peer-Peerspecifications and End-End Relationships The assumption in this framework is thatthe NTLP will operate 'locally', that is, just overinter-layer interaction would be unchanged from the scope of a single peer relationship. End-to-end operationpath-coupled case. 3.3 Signaling Application Properties It is built up by concatenating these relationships. Non-local operation (if any)clear that many signaling applications will take placerequire specific protocol behavior in NSLPs. The peering relations may also have an impact ontheir NSLP. This section outlines some of the required amountoptions for NSLP behavior; further work on selecting from these options would depend on detailed analysis of statethe signaling application in question. 3.3.1 Sender/Receiver Orientation In some signaling applications, a node at each NSIS entity. When direct interaction with remote peers is not allowed, it may be required to keep trackone end of the path thatdata flow takes responsibility for requesting special treatment - such as a message has followed throughresource reservation - from the network. This can be achieved by keeping per-flow state atWhich end may depend on the NSIS entitiessignaling application, or by maintaining a record route object incharacteristics of the messages. Notenetwork deployment. A sender-initiated approach is when the sender of the data flow requests and maintains the treatment for that NSLP peers are not always NTLP peers (section 3.2.1). This hasflow. In a numberreceiver- initiated approach the receiver of implications forthe relationship betweendata flow requests and maintains the signaling layers, intreatment for that NSLPflow. The NTLP itself has no freedom in this area: next NTLP peers may depend onhave to be discovered in the service provided by a concatenation of NTLP peer relationships rather than a single one, which makes it hardersender to depend strongly on some NTLP properties (e.g. channel security, reliability). 3.3.5 Acknowledgements and Notifications We are assumingreceiver direction, but after that time the NTLP provides a simple message transfer service, and any acknowledgements or notifications it generates are handled purely internally (and apply within the scope of a single NTLP peer relationship). However, we expectdefault assumption is that somesignaling applications will requires acknowledgements regarding the failure/success of state installation along the data path,is possible both upstream and downstream (unless possibly a signaling application specifically indicates this will be an NSLP function. Acknowledgements canis not required). This implies that backward routing state must be sent alongmaintained by the sequence ofNTLP peer relationships towardsor that backward routing information must be available in the signaling initiator, which relievesmessage. The sender and receiver initiated approaches have several differences in their operational characteristics. The main ones are as follows: *) In a receiver-initiated approach, the requirements onsignaling messages traveling from the security associations that needreceiver to the sender must be maintainedbackward routed such that they follow exactly the same path as was followed by NEs and can allow NAT traversal in both directions. (If this direction is towardsthe sender, it implies maintaining reverse routing state insignaling messages belonging to the NTLP).same flow traveling from the sender to the receiver. In certain circumstances (e.g. trusted domains), an optimizationa sender-initiated approach, provided acknowledgements and notifications can be securely delivered to send acknowledgements directly to the signaling initiator outsidethe NTLP (see section 3.2.2). The semantics of the acknowledgement messages are of particular importance. An NEsending a message could assume responsibility for the entire downstream chain of NEs, indicating for instance the availability of reserved resources for the entire downstream path. Alternatively, the message couldnode, backward routing is not necessary, and nodes do not have to maintain backward routing state. *) In a more local meaning, indicating for instance thatsender-initiated approach, a certain failure or degradation occurred atmobile node can initiate a particular point in the network. Notifications differ from acknowledgements because they are not (necessarily) generated in response to other signaling messages. This means thatreservation for its outgoing flows as soon as it may not be obvioushas moved to determine whereanother roaming subnetwork. In a receiver-initiated approach, a mobile node has to inform the notification should be sent. Other than that,receiver about its handover, thus allowing the same considerations apply as for acknowledgements. One useful distinction to make would bereceiver to differentiate between notifications that triggerinitiate a signaling action and others that don't. The security requirementsreservation for these flows. For incoming flows, the latter are less stringent, which means they couldreverse argument applies. *) In general, setup and modification will be sent directly tofastest if the NE they are destinednode responsible for (provided this NEauthorizing these actions can be determined). 3.3.6 Securityinitiate them directly within the NSLP. A mismatch between authorizing and Other AAA Issues In some cases itinitiating NEs will be possiblecause additional message exchanges either in the NSLP or in a protocol executed prior to achieveNSIS invocation. Depending on how the necessary level ofauthorization for a particular signaling security by using basic 'channel security' mechanisms  at the levelapplication is done, this may favor either sender or receiver initiated signaling. Note that this may complicate modifications of network control state for existing flows. *) Where the NTLP, and the possibilities are described in section 4.7. In other cases,signaling applications may have specific security requirements, in which case they are free to invoke their own authentication and key exchange mechanisms and apply 'object security'is looking for the last (nearest to specific fields withinreceiver) NE on the NSLPdata path, receiver oriented signaling is most efficient; sender orientation would be possible, but take more messages. *) In addition to authentication,either case, the authorisation (to manipulate network control state) has toinitiator can generally be considered as functionality aboveinformed faster about reservation failures than the NTLP level, since it will be entirely application specific. Indeed, authorisation decisionsremote end. 3.3.2 Uni- and Bi-Directional Operation For some signaling applications and scenarios, signaling may only be handed off toconsidered for a third partyunidirectional data flow. However, in other cases, there may be interesting relationships between the protocol (e.g.signaling for QoS, the resource management function as described in section 6.1.5). Many different authorisation models are possible, andthe variations impact: *) what messagetwo flows take place - for example, whether authorisation information is carried along withof a control state modification request, orbi-directional session; an example is sent inQoS for a voice call. Note that the reverse directionpath in response to it; *) what administrative relationships are required - for example, whether authorisation takes place only between peer signaling applications, or over longer distances. Becausethe NTLP operates only between adjacent peers, and places no constraints ontwo directions may differ due to asymmetric routing. In the direction or order in whichbasic case, bi-directional signaling applicationscan send messages, these authorisation aspects are left open to be defined bysimply use a separate instance of the same signaling mechanism in each NSLP. Further background discussiondirection. In constrained topologies where parts of this issue is containedthe route are symmetric, it may be possible to use a more unified approach to bi-directional signaling, e.g. carrying the two signaling directions in . 4 The NSIS Transport Layer Protocolcommon messages. This section describes the overall functionality required fromoptimization might be used for example to make mobile QoS signaling more efficient. In either case, the NTLP. It mentions possible protocol components withincorrelation of the NTLP layer andsignaling for the different possible addressing modes that can be utilized, as well astwo flow directions is carried out in the assumed transport and state management functionality.NSLP. The interfaces betweenNTLP and the layers above and below it are identified, with a description ofwould simply be enabled to bundle the identity elements that appear on these interfaces.messages together. 3.3.3 Heterogeneous Operation It is notlikely that the intention of this discussionappropriate way to designdescribe the NTLP or even to enumerate design options, although some are included as examples. The goalstate NSIS is to provide a general discussionsignaling for will vary from one part of required functionality andthe network to highlight some ofanother (depending on signaling application). For example in the issues associated with this. 4.1 Internal Protocol Components The NTLP includes all functionality below the signaling application layer and above the IP layer. The functionalityQoS case, resource descriptions that are valid for inter-domain links will probably be different from those useful for intra-domain operation (and the latter will differ from one domain to another). One way to address this issue is requiredto consider the state description used within the NTLP is outlined in section 3.2.3, with some more detailsNSLP as carried in sections 3.2.4globally-understood objects and 4.3. Some NTLP functionality could be provided via components operating as sublayers withinlocally-understood objects. The local objects are only applicable for intra-domain signaling, while the NTLP design. For example, if specific transport capabilitiesglobal objects are required, such as congestion avoidance, retransmission, security and so on, then existing protocols, such as TCP+TLS or DCCP+IPsec, could be incorporated intomainly used in inter-domain signaling. Note that the NTLP. This possibility is not required or excludedlocal objects are still part of the protocol but are inserted, used and removed by one single domain. The purpose of this framework. If peer-peer addressing (section 4.2)division is used for some messages, then active next-peer discovery functionality will be required within the NTLPto supportprovide additional flexibility in defining the explicit addressing of these messages. This could use message exchanges for dynamic peer discovery asobjects carried by the NSLP such that only the objects applicable in a sublayer withinparticular setting are used. One approach for reflecting the NTLP; theredistinction is that local objects could alsobe put into separate local messages that are initiated and terminated within one single domain; an interface to external mechanisms to carry out this function. ==================== =========================== ^ +------------------+ +-------------------------+ | | | | NSIS Specific Functions | | | | | .............| NSIS | | Monolithic | |+----------+. Peer .| Transport | | Protocol | || Existing |. Discovery .| Layer | | | || Protocol |. Aspects .| | | | |+----------+.............| V +------------------+ +-------------------------+ ==================== =========================== Figure 6: Options for NTLP Structure 4.2 Addressing Therealternative is that they could be "stacked" within the NSLP messages that are two ways to addressused anyway for inter-domain signaling. 3.3.4 Aggregation It is a well known problem that per-flow signaling message being transmitted between NTLP peers: *) peer-peer, wherein large-scale networks present scaling challenges because of the message is addressed to a neighboring NSIS entitylarge number of flows that is known to be closer tomay traverse individual nodes. The possibilities for aggregation at the destination NE. *) end-to-end, wherelevel of the messageNTLP are quite limited; the primary scaling approach for path-coupled signaling is addressedfor a signaling application to the flow destination directly,group flows together and intercepted by an intervening NE. With peer-peer addressing, an NE will determine the address ofperform signaling for the next NE based onaggregate, rather than for the payloadflows individually. The aggregate may be created in a number of ways: for example, the message (and potentially on the previous NE). This requires the address ofindividual flows may be sent down a tunnel, or given a common DSCP marking. The aggregation and deaggregation points perform per flow signaling, but nodes within the destination NE toaggregation region should only be derivable fromforced to process signaling messages for the information present inaggregate, somehow ignoring the payload, either by using some local routing table or through participationper-flow signaling (see section 3.2.3). Individual NSLPs will need to specify what aggregation means in active peer discovery message exchanges. Peer-peer addressing inherently supports tunneling of messages between NEs,their context, and how it should be performed. For example, in the QoS context it is equally applicablepossible to add together the path-coupled and path-decoupled cases.resources specified in a number of separate reservations. In the case of end-to-end addressing, the message is addressedother applications, such as signaling to the data flow receiver,NATs and (some of)firewalls, the NEs along the data path interceptfeasibility (and even the messages. The routingmeaning) of the messages should follow exactly the same path as the associated data flow (but see section 5.1.1 on this point). Note that securing messages sent this way raises some interesting security issues (these are discussed in ). Itaggregation is not possible atless clear. 3.3.5 Peer-Peer and End-End Relationships The assumption in this stage to mandate one addressing mode or the other. Indeed, eachframework is necessary for some aspects ofthat the NTLP operation: in particular, initial discovery ofwill operate 'locally', that is, just over the next downstreamscope of a single peer relationship. End-to-end operation is built up by concatenating these relationships. Non-local operation (if any) will usually require end-to-end addressing, whereas reverse routing will always require peer-peer addressing. For other message types,take place in NSLPs. The peering relations may also have an impact on the choice is a matterrequired amount of protocol design. The mode usedstate at each NSIS entity. When direct interaction with remote peers is not visibleallowed, it may be required to keep track of the NSLP, and the information needed in each case is available frompath that a message has followed through the network. This can be achieved by keeping per-flow state at the flow identifier (section 4.6.1) or locally stored NTLP state. 4.3 Classical Transport Functions TheNSIS signaling protocolsentities or by maintaining a record route object in the messages. 3.3.6 Acknowledgements and Notifications We are responsible for transporting (signaling) data aroundassuming that the network; in general, this requires functionality such as congestion management, reliability,NTLP provides a simple message transfer service, and so on. This section discusses how muchany acknowledgements or notifications it generates are handled purely internally (and apply within the scope of a single NTLP peer relationship). However, we expect that some signaling applications will require acknowledgements regarding the failure/success of state installation along the data path, and this functionality shouldwill be provided withinan NSLP function. Acknowledgements can be sent along the NTLP. It appearssequence of NTLP peer relationships towards the signaling initiator, which relieves the requirements on the security associations that need to be maintained by NEs and can allow NAT traversal in both directions. (If this doesn't affectdirection is towards the basic waysender, it implies maintaining reverse routing state in whichthe NSLP/NTLP layers relate to each otherNTLP). In certain circumstances (e.g. in terms oftrusted domains), an optimization can be to send acknowledgements directly to the signaling initiator outside the NTLP (see section 3.2.2). The semantics of the inter-layer interaction); it is much moreacknowledgement messages are of particular importance. An NE sending a questionmessage could assume responsibility for the entire downstream chain of NEs, indicating for instance the overall performance/complexity tradeoff implied by placing certain functions within each layer. The following functionality is assumed to lie within the NTLP: 1. Bundling togetheravailability of small messages (comparable to ) can be provided locally byreserved resources for the NTLP as an option if desired; it doesn't affectentire downstream path. Alternatively, the operation ofmessage could have a more local meaning, indicating for instance that a certain failure or degradation occurred at a particular point in the network elsewhere. The NTLP should always support unbundling,network. Notifications differ from acknowledgements because they are not (necessarily) generated in response to avoid the cost of negotiating the feature as an option. Noteother signaling messages. This means that end-to-end addressed messages for different flows cannotit may not be bundled safely unlessobvious to determine where the next node onnotification should be sent. Other than that, the outgoing interface is knownsame considerations apply as for acknowledgements. One useful distinction to make would be NSIS-aware. 2. Message fragmentation shouldto differentiate between notifications that trigger a signaling action and others that don't. The security requirements for the latter are less stringent, which means they could be provided bysent directly to the NTLP when needed. For NSLPs that generate large messages,NE they are destined for (provided this NE can be determined). 3.3.7 Security and Other AAA Issues In some cases it will be necessarypossible to fragment them efficiently withinachieve the network, wherenecessary level of signaling security by using basic 'channel security' mechanisms  at the uselevel of IP fragmentation may lead to reduced reliabilitythe NTLP, and be incompatible with some addressing schemes. To avoid imposingthe cost of reassembly on intermediate nodes, the fragmentation scheme used should allow forpossibilities are described in section 4.7. In other cases, signaling applications may have specific security requirements, in which case they are free to invoke their own authentication and key exchange mechanisms and apply 'object security' to specific fields within the independent forwarding of individual fragments towards a node hosting an interested NSLP. The placement ofNSLP messages. In addition to authentication, the followingauthorisation (to manipulate network control state) has to be considered as functionality is still open: 1. Overload detection and control. Here, the question is whetherabove the NTLP should include common mechanismslevel, since it will be entirely application specific. Indeed, authorisation decisions may be handed off to handle overload at the IP layer ("congestion control") and NTLP/NSLP layers (loosely "flow control"). The arguments here are complex and somewhat interrelated;a temporary summary can be foundthird party in . 2. Local retransmission to improve reliability. The argumentthe protocol (e.g. for QoS, the resource management function as described in favor is thatsection 6.1.4). Many different authorisation models are possible, and the NTLP can recover from congestive lossvariations impact: *) what message flows take place - for example, whether authorisation information is carried along with a control state modification request, or corruption much more rapidly than end-to-end (NSLP) mechanisms; the argument againstis that the additional complexitysent in the NTLP is not neededreverse direction in response to it; *) what administrative relationships are required - for allexample, whether authorisation takes place only between peer signaling applications. (It's assumed thatapplications, or over longer distances. Because the NTLP is not actually providing perfect message delivery guarantees or notifications, for example because NSLP peers may be separated by more than one NTLP peer relationship. A signaling application that needs peer-peer acknowledgements of this nature should define them within the NSLP.) In-order message delivery and duplicate detection are related functions. 3. Message summarization. Benefits have been found (see ) in having the signaling protocol transportoperates only 'tags' for refresh signaling messages rather than the full messages themselves. Inbetween adjacent peers, and places no constraints on the more flexible NSISdirection or order in which signaling environment, it is not clear if this functionalityapplications can be provided correctly by the NTLP, or whether it hassend messages, these authorisation aspects are left open to be done (less efficiently)defined by each NSLP. These open issues will be resolved in a future versionFurther background discussion of this document. 4.4 Lowerissue is contained in . 4 The NSIS Transport Layer InterfacesProtocol This section describes the overall functionality required from the NTLP. It mentions possible protocol components within the NTLP layer and the different possible addressing modes that can be utilized, as well as the assumed transport and state management functionality. The interfaces between NTLP interactsand the layers above and below it are identified, with 'lower layers'a description of the protocol stack foridentity elements that appear on these interfaces. It is not the purposesintention of sending and receiving signaling messages. This framework placesthis discussion to design the lower boundaryNTLP or even to enumerate design options, although some are included as examples. The goal is to provide a general discussion of required functionality and to highlight some of the issues associated with this. 4.1 Internal Protocol Components The NTLP atincludes all functionality below the signaling application layer and above the IP layer. The interface to the lower layerfunctionality that is therefore very simple: *) The NTLP sends raw IP packets *) The NTLP receives raw IP packets. In the case of peer-peer addressing, they have been addressed directly to it. Inrequired within the case of end-to-end addressing, this will be achieved by intercepting packets that have been markedNTLP is outlined in section 3.2.4, with some special way (by special protocol number or by some option interpretedmore details in sections 3.2.5 and 4.3. Some NTLP functionality could be provided via components operating as sublayers within the IP layer,NTLP design. For example, if specific transport capabilities are required, such as the Router Alert option  and ). *) The NTLP receives indications from the IP layer regarding route changescongestion avoidance, retransmission, security and similar events (see section 5.1). For correct message routing,so on, then existing protocols, such as TCP+TLS or DCCP+IPsec, could be incorporated into the NTLP needs to haveNTLP. This possibility is not required or excluded by this framework. If peer-peer addressing (section 4.2) is used for some information about link and IP layer configuration ofmessages, then active next-peer discovery functionality will be required within the local networking stack. In general, it needs to know howNTLP to selectsupport the outgoing interfaceexplicit addressing of these messages. This could use message exchanges for dynamic peer discovery as a signaling message, where this must match the interface that will be used bysublayer within the corresponding flow. This mightNTLP; there could also be as simple as just allowing the IP layeran interface to handle the message using its own routing table.external mechanisms to carry out this function. ==================== =========================== ^ +------------------+ +-------------------------+ | | | | NSIS Specific Functions | | | | | .............| NSIS | | Monolithic | |+----------+. Peer .| Transport | | Protocol | || Existing |. Discovery .| Layer | | | || Protocol |. Aspects .| | | | |+----------+.............| V +------------------+ +-------------------------+ ==================== =========================== Figure 6: Options for NTLP Structure 4.2 Addressing There are two ways to address a signaling message being transmitted between NTLP peers: *) peer-peer, where the message is no intentionaddressed to do something differenta neighboring NSIS entity that is known to be closer to the destination NE. *) end-to-end, where the message is addressed to the flow destination directly, and intercepted by an intervening NE. With peer-peer addressing, an NE will determine the address of the next NE based on the payload of the message (and potentially on the previous NE). This requires the address of the destination NE to be derivable from IPthe information present in the payload, either by using some local routing (fortable or through participation in active peer discovery message exchanges. Peer-peer addressing inherently supports tunneling of messages between NEs, and is equally applicable to the path-coupled and path-decoupled cases. In the case of end-to-end addressing, the message is addressed messages); however, some hosts allow applicationsto bypass routing for theirthe data flows,flow receiver, and (some of) the NTLP processing must account for this. Further network layer information would be needed to handled scoped addresses (if such things ever will exist). ConfigurationNEs along the data path intercept the messages. The routing of the messages should follow exactly the same path as the associated data flow (but see section 5.1.1 on this point). Note that securing messages sent this way raises some interesting security issues (these are discussed in ). It is not possible at this stage to mandate one addressing mode or the other. Indeed, each is necessary for some aspects of NTLP operation: in particular, initial discovery of the next downstream peer will usually require end-to-end addressing, whereas reverse routing will always require peer-peer addressing. For other message types, the choice is a matter of protocol design. The mode used is not visible to the NSLP, and the information needed in each case is available from the flow identifier (section 4.6.1) or locally stored NTLP state. 4.3 Classical Transport Functions The NSIS signaling protocols are responsible for transporting (signaling) data around the network; in general, this requires functionality such as congestion management, reliability, and so on. This section discusses how much of this functionality should be provided within the NTLP. It appears that this doesn't affect the basic way in which the NSLP/NTLP layers relate to each other (e.g. in terms of the semantics of the inter-layer interaction); it is much more a question of the overall performance/complexity tradeoff implied by placing certain functions within each layer. Note that, following the discussion at the end of section 3.2.3, there may be cases where intermediate nodes wish to modify messages in transit even though they do not perform full signaling application processing. In this case, not all of the following functionality would be invoked at every intermediate node. The following functionality is assumed to lie within the NTLP: 1. Bundling together of small messages (comparable to ) can be provided locally by the NTLP as an option if desired; it doesn't affect the operation of the network elsewhere. The NTLP should always support unbundling, to avoid the cost of negotiating the feature as an option. (The related function of refresh summarization - where objects in a refresh message are replaced with a reference to a previous message identifier - is left to NSLPs which can then do this in a way tuned to the state management requirements of lower layer operationthe signaling application. Additional transparent compression functionality could be added to handlethe NTLP design later as a local option.) Note that end-to-end addressed messages for different flows in particular wayscannot be bundled safely unless the next node on the outgoing interface is handledknown to be NSIS-aware. 2. Message fragmentation should be provided by the signaling application. 4.5 Upper Layer Services TheNTLP offers transport layer services to higher layer signaling applications for two purposes: sending and receiving signaling messages, and exchanging control and feedback information.when needed. For sending and receivingNSLPs that generate large messages, two basic control primitives are required: *) Send Message,it will be necessary to allowfragment them efficiently within the signaling application to pass data tonetwork, where the NTLP for transport. *) Receive Message,use of IP fragmentation may lead to allowreduced reliability and be incompatible with some addressing schemes. To avoid imposing the NTLP to pass received data tocost of reassembly on intermediate nodes, the fragmentation scheme used should allow for the independent forwarding of individual fragments towards a node hosting an interested NSLP. 3. There can be significant benefits for signaling application. The NTLP and signaling application mayapplications if state-changing messages are delivered reliably (as introduced in  for RSVP; see also wantthe more general analysis of ). This does not change any assumption about the use of soft-state by NSLPs to exchange other control information, such as: *) Signaling application registration/de-registration, so that particularmanage signaling application instances can register their presence withstate, and leaves the responsibility for detecting and recovering from application layer error conditions in the transport layer. This may also require some identifierNSLP. However, it means that such functionality does not need to be agreed betweentuned to handle fast recovery from message loss due to congestion or corruption in the NTLPlower layers, and signaling application to allow supportalso means that the exchangeNTLP can prevent the amplification of further control informationmessage loss rates caused by fragmentation. Reliable delivery functionality is invoked by the NSLP on a message-by-message basis and is always optional to use. 4. The NTLP should not allow signaling messages to cause congestion in the de-multiplexingnetwork (i.e. at the IP layer). Congestion could be caused by retransmission of incoming data. *) NTLP configuration, allowinglost signaling applications to indicate what optional NTLP features they want to use, and to configure NTLP operation, such as controlling what transportpackets or by upper layer state shouldactions (e.g. a flood of signaling updates to recover from a route change). In some cases it may be maintained. *) Error messages,possible to allowengineer the NTLP to indicate error conditionsnetwork to theensure that signaling applicationcannot overload it; in other cases, the NTLP would have to detect congestion and vice versa. *) Feedback information, such as route change indications so thatadapt the rate at which it allows signaling application can decide what actionmessages to take. 4.6 Identity Elements 4.6.1 Flow Identification The flow identification is a methodbe transmitted. Principles of identifying a flowcongestion control in a unique way. All packets associatedInternet protocols are given in . The NTLP may or may not be able to detect overload in the control plane itself (e.g. an NSLP-aware node several NTLP- hops away which cannot keep up with the same flow will be identified byincoming message rate) and indicate this as a flow-control condition to local signaling applications. However, for both the congestion and overload cases, it is up to the same flow identifier.signaling applications themselves to adapt their behavior accordingly. 4.4 Lower Layer Interfaces The key aspectNTLP interacts with 'lower layers' of the flow identifier is to provide enough information such thatprotocol stack for the purposes of sending and receiving signaling flow receivesmessages. This framework places the same treatment alonglower boundary of the data path as that actual data itself, i.e. consistent behavior is appliedNTLP at the IP layer. The interface to the signaling and data flows by a NAT or policy-based forwarding engine. Information that could be used in flow identification may include:lower layer is therefore very simple: *) sourceThe NTLP sends raw IP address;packets *) destinationThe NTLP receives raw IP address; *) protocol identifier and higher layer (port) addressing; *) flow label (typical for IPv6); *) SPI field for IPSec encapsulated data; *) DSCP/TOS field It is assumed that wildcarding on these identifiers is not needed (further analysis maypackets. In the case of peer-peer addressing, they have been addressed directly to it. In the case of end-to-end addressing, this will be required). We've assumed hereachieved by intercepting packets that the flow identification is not hiddenhave been marked in some special way (by special protocol number or by some option interpreted within the NSLP, but is explicitly part ofIP layer, such as the NTLP.router alert option). *) The justification for this is that it might be valuable to be able to do NSIS processing even at a node which was unaware ofNTLP receives indications from the specific signaling applicationIP layer regarding route changes and similar events (see section 3.2.1): an example scenario would be messages passing through an addressing boundary where the flow identification had to be re-written. 4.6.2 Session Identification There are circumstances where it is important to be able to refer to signaling application state independently of the underlying flow.5.1). For example, ifcorrect message routing, the address of oneNTLP needs to have some information about link and IP layer configuration of the flow endpoints changes due to a mobility event,local networking stack. In general, it is desirableneeds to be ableknow how to changeselect the flow identifier without having to install a completely new reservation. The session identifier providesoutgoing interface for a method to correlate thesignaling about the different flows withmessage, where this must match the same network control state. The session identifier is essentially a signaling application concept, since it is only used in non-trivial state management actions that are application specific. However, we assume hereinterface that it shouldwill be visible withinused by the NTLP.corresponding flow. This enables it tomight be usedas simple as just allowing the IP layer to controlhandle the message using its own routing table. There is no intention to do something different from IP routing (for end-to-end addressed messages); however, some hosts allow applications to bypass routing for their data flows, and the NTLP behavior,processing must account for example,this. Further network layer information would be needed to handled scoped addresses (if such things ever will exist). Configuration of lower layer operation to handle flows in particular ways is handled by controlling howthe signaling application. 4.5 Upper Layer Services The NTLP offers transport layer should forward packets belonging to this session (as opposedservices to thishigher layer signaling application). In addition, the session identifier can be used by the NTLP to demultiplex receivedapplications for two purposes: sending and receiving signaling messages between multiple instances ofmessages, and exchanging control and feedback information. For sending and receiving messages, two basic control primitives are required: *) Send Message, to allow the same signaling application, if such an operational scenario is supported (see section 4.6.3 for more information onsignaling application identification). To be useful for mobility support, the session identifier should be globally unique, and it should not be modified end-to-end. It is well known that it is practically impossibleto generate identifiers in a way which guarantees this property; however, using a large random number makes it highly likely. In any case,pass data to the NTLP ascribes no valuable semanticsfor transport. *) Receive Message, to allow the identifier (such as 'session ownership'); this problem is leftNTLP to pass received data to the signaling application, whichapplication. The NTLP and signaling application may be able to secure italso want to use for this purpose. 4.6.3exchange other control information, such as: *) Signaling Application Identification Since the NTLP can be used to support several NSLP types, there is a need to identify which type aapplication registration/de-registration, so that particular signaling message exchange is being used for.application instances can register their presence with the transport layer. This ismay also require some identifier to be agreed between the NTLP and signaling application to allow support the exchange of further control information and to support: *) processingallow the de-multiplexing of incoming messages - thedata. *) NTLP configuration, allowing signaling applications to indicate what optional NTLP features they want to use, and to configure NTLP operation, such as controlling what transport layer state should be ablemaintained. *) Error messages, to allow the NTLP to indicate error conditions to demultiplex these towardsthe appropriatesignaling applications;application and vice versa. *) processing of general messages at an NSIS aware intermediate node - if the node does not handleFeedback information, such as route change indications so that the specificsignaling application, it should be able to make a forwarding decision without havingapplication can decide what action to parse upper layer information. No positiontake. 4.6 Identity Elements 4.6.1 Flow Identification The flow identification is taken on the forma method of identifying a flow in a unique way. All packets associated with the signaling application identifier, or evensame flow will be identified by the structuresame flow identifier. The key aspect of the flow identifier is to provide enough information such that the signaling application 'space' - free-standing applications, potentially overlapping groups of capabilities, etc. These details should not influenceflow receives the rest of NTLP design. 4.7 Security Propertiessame treatment along the data path as that actual data itself, i.e. consistent behavior is applied to the signaling and data flows by a NAT or policy-based forwarding engine. Information that could be used in flow identification may include: *) source IP address; *) destination IP address; *) protocol identifier and higher layer (port) addressing; *) flow label (typical for IPv6); *) SPI field for IPsec encapsulated data; *) DSCP/TOS field It is assumed that wildcarding on these identifiers is not needed (further analysis may be required). We've assumed here that the only security service requiredflow identification is not hidden within NTLPthe NSLP, but is channel security. Channel security requires a security association to be established betweenexplicitly part of the signaling endpoints, whichNTLP. The justification for this is carried out via some authentication and key management exchange. This functionality couldthat it might be provided by reusing a standard protocol. In ordervaluable to protectbe able to do NSIS processing even at a particularnode which was unaware of the specific signaling exchange,application (see section 3.2.3): an example scenario would be messages passing through an addressing boundary where the NSIS entity needsflow identification had to select the security association thatbe re-written. 4.6.2 Session Identification There are circumstances where it has in place with the next NSIS entity that willis important to be receiving theable to refer to signaling message. The easeapplication state independently of doing this depends onthe addressing model in use byunderlying flow. For example, if the NTLP (see section 4.2). Channel security can provide many different typesaddress of protection to signaling exchanges, including integrity and replay protection and encryption. It is not clear whichone of these is required atthe NTLP layer, although most channel security mechanisms support them all. Channel security can alsoflow endpoints changes due to a mobility event, it is desirable to be appliedable to change the flow identifier without having to install a completely new reservation. The session identifier provides a method to correlate the signaling messages with differing granularity, i.e. all or parts ofabout the signaling message may be protected. For example, ifdifferent flows with the flowsame network control state. The session identifier is traversingessentially a NAT,signaling application concept, since it is only the parts of the messageused in non-trivial state management actions that do not needare application specific. However, we assume here that it should be visible within the NTLP. This enables it to be processedused to control NTLP behavior, for example, by controlling how the NATtransport layer should be protected. It is an open question asforward packets belonging to which parts ofthis session (as opposed to this signaling application). In addition, the session identifier can be used by the NTLP to demultiplex received signaling messages need protecting, and what typebetween multiple instances of protection should be applied to each. 5 Interactions with Other Protocols 5.1 IP Routing Interactions The NSIS Transport Layer (NTLP)the same signaling application, if such an operational scenario is responsiblesupported (see section 4.6.3 for discovering the next node tomore information on signaling application identification). To be visited byuseful for mobility support, the signaling protocol. For path-coupled signaling, this next nodesession identifier should be one that willglobally unique, and it should not be visited by the data flow. In practice,modified end-to-end. It is well known that it is practically impossible to generate identifiers in a way which guarantees this peer discovery will be approximate, as any node could useproperty; however, using a large random number makes it highly likely. In any feature ofcase, the NTLP ascribes no valuable semantics to the peer discovery packetidentifier (such as 'session ownership'); this problem is left to route it differently thanthe corresponding data flow packets. Divergence between data andsignaling path can occur dueapplication, which may be able to load sharing or load balancing (section 5.1.1). An example specificsecure it to use for this purpose. 4.6.3 Signaling Application Identification Since the case of QoSNTLP can be used to support several NSLP types, there is given in section 6.1.1. Route changes causea temporary divergence between the data path and the path onneed to identify which type a particular signaling state has been installed. The occurrence, detection and impact of route changes is described in section 5.1.2. A description of this issue in the context of QoSmessage exchange is given in section 6.1.2. 5.1.1 Load Sharing and Policy-Based Forwarding Load sharing or load balancingbeing used for. This is a network optimization technique that exploits the existence of multiple pathsto support: *) processing of incoming messages - the same destination in orderNTLP should be able to obtain benefits in terms of protection, resource efficiency or network stability. The significance of load sharing indemultiplex these towards the contextappropriate signaling applications; *) processing of general messages at an NSIS is that,aware intermediate node - if the load sharing mechanism in use will forward packetsnode does not handle the specific signaling application, it should be able to make a forwarding decision without having to parse upper layer information. No position is taken on any basis other thanthe destination address, routingform of the signaling application identifier, or even the structure of the signaling messages using end-to-end addressing doesapplication 'space' - free-standing applications, potentially overlapping groups of capabilities, etc. These details should not guarantee that the messages will followinfluence the data path. Policy-based forwarding for data packets - whererest of NTLP design. 4.7 Security Properties It is assumed that the outgoing linkonly security service required within NTLP is selected based on policy information about fields additionalchannel security. Channel security requires a security association to the packet destination address - has the same impact. Signaling and data flow packets may diverge because of these techniques. In OSPF, load balancing canbe usedestablished between equal cost paths  or unequal cost paths. An example ofthe latter approachsignaling endpoints, which is Optimized Multi Path (OMP). OMP discovers multiple paths, not necessarily equal cost paths,carried out via some authentication and key management exchange. This functionality could be provided by reusing a standard protocol. In order to any destinations in the network, but based on the load reported fromprotect a particular path,signaling exchange, the NSIS entity needs to select the security association that it determines which fractionhas in place with the next NSIS entity that will be receiving the signaling message. The ease of doing this depends on the data to direct toaddressing model in use by the given path. Incoming packets are subjectNTLP (see section 4.2). Channel security can provide many different types of protection to a (source, destination address) hash computation,signaling exchanges, including integrity and effective load sharingreplay protection and encryption. It is accomplished by meansnot clear which of adjusting the hash thresholds. BGP  advertises the routes chosen bythese is required at the BGP decision processNTLP layer, although most channel security mechanisms support them all. Channel security can also be applied to other BGP speakers. Inthe basic specification, routessignaling messages with differing granularity, i.e. all or parts of the same Network Layer reachability information (NLRI) as previously advertised routes implicitly replacesignaling message may be protected. For example, if the original advertisement, which means that multiple paths forflow is traversing a NAT, only the same prefix cannot exist. This restriction couldparts of the message that do not need to be removedprocessed by suitable extensions to BGP. Ifthe routing decision is based on both source and destination address, signaling and data flow packets may still diverge because of layer 4 load-balancing (based on protocol or port number). Such techniques would, however, constrainNAT should be protected (alternatively, if the use of proxies. Proxies would cause ICMP errorsNAT takes part in NTLP security procedures, it only needs to be misdirectedgiven access to the source of the data because of source address spoofing. Ifmessage fields containing addresses, often just the routing decisionflow id). It is based on the complete five-tuple, divergence may still occur becausean open question as to which parts of the presenceNTLP messages need protecting, and what type of router alert options. In this case, the same constraint on proxy use applies as above. Additionally, it becomes difficultprotection should be applied to each. 5 Interactions with Other Protocols 5.1 IP Routing Interactions The NTLP is responsible for determining the end systemsnext node to distinguish between data andbe visited by the signaling packets. Finally, QoS routing techniques (section 6.1.3) may baseprotocol. For path-coupled signaling, this next node should be one that will be visited by the routing decision ondata flow. In practice, this peer discovery will be approximate, as any field in the packet header (e.g. DSCP, ...). Most load-balancing techniquesnode could use the first n bytesany feature of the peer discovery packet header (including SA, DA and protocol field) in the hashing function. In this case,to route it differently from the above considerations regarding source/destination addresscorresponding data flow packets. Divergence between data and signaling path can occur due to load sharing or five-tuple based forwarding apply. 5.1.2 Route Changes In a routed network, each packet is independently routed based on its header information. Whenever a better route towardsload balancing (section 5.1.1). An example specific to the destination becomes available, this routecase of QoS is installedgiven in the forwarding table and will be used for all subsequent (data and signaling) packets. This cansection 6.1.1. Route changes cause a temporary divergence between the data path along which state has been installedand the path alongon which forwarding will actually take place. The possibility of route changes requires the presence of three processes in thesignaling protocol 1. route change detection 2. installation of state on the new path 3. removal ofstate on the old path Many route change detections methods can be used, some of which need explicit protocol support and some of which are implementation- internal. They differ in their speed of reactionhas been installed. The occurrence, detection and the types of change they can detect. In rough orderimpact of increasing applicability, they can be summarized as: a) monitoring changes in local interface state b) monitoring network-wide topologyroute changes is described in a link-state routing protocol c) inference from changessection 5.1.2. A description of this issue in data packet TTL d) inference from lossthe context of packet streamQoS is given in section 6.1.2. 5.1.1 Load Sharing and Policy-Based Forwarding Load sharing or load balancing is a downstream flow-aware router e) inference from changesnetwork optimization technique that exploits the existence of multiple paths to the same destination in signaling packet TTL f) changed routeorder to obtain benefits in terms of a PATH-like (end-to-end addressed) signaling packet g) changed routeprotection, resource efficiency or network stability. The significance of a specific end-to-end addressed probe packet There are essentially three waysload sharing in which detection can happen: basedthe context of NSIS is that, if the load sharing mechanism in use will forward packets on network monitoring (method a-b),any basis other than the destination address, routing of signaling messages using end-to-end addressing does not guarantee that the messages will follow the data path. Policy-based forwarding for data packets - where the outgoing link is selected based on datapolicy information about fields additional to the packet monitoring (method c-d)destination address - has the same impact. Signaling and based on monitoring signaling protocol messages (method e-g). Methods contingent on monitoring signaling messages become less effective as refresh reductiondata packets may diverge because of both of these techniques. Load balancing techniques are used. When a route change hashave been detected, it is important that state is installed as quicklyproposed for a number of routing protocols, such as possible along the new path. It is not guaranteed thatOSPF equal cost paths  and others. Typically, based on the new path will be able to provideload reported from a particular path, load balancing determines which fraction of the same characteristicsdata to direct to that were available on the oldpath. In order to be ableIncoming packets are subject to avoid duplicate state installation or, worse, rejectiona (source, destination address) hash computation, and effective load sharing is accomplished by means of adjusting the hash thresholds. If signaling messagepackets are given source and destination addresses identical to data packets, signaling and data packets may still diverge because of previously installed state, it is importantlayer 4 load-balancing (based on protocol or port number). Such techniques would also cause ICMP errors to be ablemisdirected to recognizethe new signaling message as belonging to an existing session. In this respect, we distinguish between route changes with associated changesource of the flow identification (e.g. in casedata because of a mobility event whenthe IPsource might change) and route changes without change of the flow identification (e.g.address spoofing. If signaling packets are made identical in case of a link failure alongthe path). The former case requires an identifier independent fromcomplete five-tuple, divergence may still occur because of the flow identification, i.e.presence of router alert options. In this case, the session identifier (section 4.6.2). When state has been installed alongsame ICMP misdirection applies. Additionally, it becomes difficult for the new path,end systems to distinguish between data and signaling packets. Finally, QoS routing techniques may base the existing staterouting decision on any field in the old path needs to be removed. Withpacket header (e.g. DSCP, ...). Many load-balancing implementations use the soft-state principle, this will happen automatically becausefirst n bytes of the lack of refresh messages. Dependingpacket header (including SA, DA and protocol) in the hash function. In this case, the general considerations above regarding SA/DA or five-tuple based forwarding continue to apply. 5.1.2 Route Changes In a connectionless network, each packet is independently routed based on its header information. Whenever a better route towards the refresh timer, however, it may be required to tear downdestination becomes available, this state much faster (e.g. because itroute is tied to an accounting record). In that case,installed in the teardown message needs toforwarding table and will be able to distinguishused for all subsequent (data and signaling) packets. This can cause a divergence between the newpath along which state has been installed and the old path. Thepath along which forwarding will actually take place. (The problem of route changes would not occuris reduced if there was a way to doroute pinning.pinning is performed. Route pinning refers to the independence of the path taken by certain data packets from reachability changes caused by routing updates from an Interior Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP). 5.1.3 Router Redundancy In some environments,Nothing about NSIS signaling prevents route pinning being used as a network engineering technique, provided it is desired to provide connectivity and per flow or per class flow management with high-availability characteristics, i.e. with rapid transparent recovery evendone in the presence of route changes. This may need interactions with protocolsa way which are used to managepreserves the common routing in this case, such as VRRP . A future versionof this document might consider interactions between NSISsignaling and such protocolsdata. However, even if route pinning is used, it cannot be depended on to support high availability functionality. 5.2 Mobility Interactions Mobility,prevent all route changes (for example in most cases, causesthe case of link failures). Handling route changes torequires the presence of three processes in the data path that packets take. Assuming thatsignaling has already taken place to establish someprotocol: 1. route change detection 2. installation of state alongon the data path,new signaling may be needed in order to (re)establishpath 3. removal of state alongon the changed data path. The interactions between mobilityold path Many route change detection methods can be used, some needing explicit protocol support and signaling protocols have been extensively analyzed in recent years, primarilysome of which are implementation- internal. They differ in the contexttheir speed of RSVPreaction and Mobile IP interaction (e.g.the mobility discussion of ), but also in the context of othertypes of network (e.g. ); a general reviewchange they can detect. In rough order of the fundamental interactions is givenincreasing applicability, they can be summarized as: a) monitoring changes in , which provides further details on many of the subjects consideredlocal interface state b) monitoring topology changes in these sections. This analysis work has shown that some difficultiesa link-state routing protocol c) inference from changes in the interactions are quite deeply rooteddata packet TTL d) inference from loss of packet stream in the detailed designa flow-aware router e) inference from changes in signaling packet TTL f) changed route of these protocols; however, the problemsan end-to-end addressed signaling packet g) changed route of a specific end-to-end addressed probe packet These methods can be categorized as being based on network monitoring (method a-b), based on data packet monitoring (method c-d) and theirbased on monitoring signaling protocol messages (method e-g); method f is the baseline method of RSVP. Methods contingent on monitoring signaling messages become less effective as soft state refresh rates are reduced. When a route change has been detected, it is important that state is installed as quickly as possible solutions fall under five broad headings. The main issues for a resource signaling application are limiting the period after handovers during whichalong the resources arenew path. It is not available alongguaranteed that the path; and avoiding double reservations (reservationsnew path will be able to provide the same characteristics that were available on boththe old and new path). Similar issues may applypath. In order to other typesbe able to avoid duplicate state installation or, worse, rejection of signaling application. 5.2.1 Addressing and Encapsulation A mobility solution typically involves address reallocation on handover (unless a network supports per host routing) and may involve special packet formats (e.g.the routing header and Home Address option of MIPv6). Since signaling may depend on end system addresses for forwardingsignaling messages and defining flows (section 4.6.1), the special implicationsmessage because of mobility for addressing needpreviously installed state, it is important to be considered. The two possible approaches areable to recognize the new signaling message as follows: *) Use abelonging to an existing session. In this respect, we distinguish between route changes with associated change of the flow identification based on low level IP addresses(e.g. the Care of Address) and other 'standard' fieldsin case of a mobility event when the IP header. This makes least demands on the packet classification engines withinsource might change) and route changes without change of the network. However, it means that even on a partflow identification (e.g. in case of a link failure along the path). The former case requires an identifier independent from the flow path that is unchanged,identification, i.e. the session will need to be modified to reflectidentifier (section 4.6.2). Mobility issues are discussed in more detail in section 5.2. When state has been installed along the new path, the changed flow identification (see section 5.2.3). *) Use a flow identification that does not change (e.g. basedexisting state on Home Address). This simplifiesthe problem of session update, atold path needs to be removed. With the likely costsoft-state principle, this will happen automatically because of considerably complicatingthe flow identification requirements and making stronger demandslack of refresh messages. Depending on packet classification. Inthe first approach,refresh timer, however, it may be required to prevent double reservation, NSIS entities needtear down this state much faster (e.g. because it is tied to an accounting record). In that case, the teardown message needs to be able to recognize that a session withdistinguish between the new flow identifierpath and the old path. In some environments, it is desired to be correlatedprovide connectivity and per flow or per class state management with an existing one. A session identifier (section 4.6.2) could behigh-availability characteristics, i.e. with rapid transparent recovery even in the presence of route changes. This may need interactions with protocols which are used forto manage the routing in this purpose,case, such as VRRP . Our basic assumption about such interactions is that the NTLP would be responsible for detecting the route change and ensuring that signaling messages were re-routed appropriately along with data traffic; but it needs to have global semantics. Whilethat the feasibility offurther state re-synchronization (including failover between 'main' and 'standby' nodes in the first approach needs tohigh availability case) would be proven,the responsibility of the signaling application and its NSLP, possibly triggered by the NTLP. 5.2 Mobility and Multihoming Interactions The issues associated with mobility and multihoming are a generalization of the basic route change case of the previous section. As well as the fact that packets for a given session are no longer traveling over a single topological path, the impactfollowing extra considerations arise: 1) The use of requiring more sophisticated packet classifiers, it still seems more plausible than the second. ThisIP-layer mobility and multihoming means that signaling applications should define flows in terms of real, routable (care of) addresses rathermore than virtual (home) addresses. 5.2.2 Localized Path Repair In any mobility approach, a handoverone IP source or destination address will cause at least some changes in the path of upstreambe associated with a single session. The same applies if application layer solutions (e.g. SIP- based approaches) are used. 2) Mobile IP and downstream packets. Atassociated protocols use some point alongspecial encapsulations for some segments of the joined path, an NSIS entity should be able to recognize this situation, based upon session identification. State needs to be installed ondata path. 3) The double route may persist for some time in the new path, and removed fromnetwork (e.g. in the old. Who triggerscase of a 'make-before-break' handover being done by a multihomed host). 4) Conversely, the new statere-routing may be constrained by which entities are authorised to carry out which state manipulations, which is then a signaling application question. A critical point here israpid and routine (unlike network internal route changes), increasing the importance of rapid state release on old paths. The interactions between mobility and signaling that is used to discoverhave been extensively analyzed in recent years, primarily in the crossover node. This is a generalizationcontext of RSVP and Mobile IP interaction (e.g. the problemmobility discussion of finding next-NSIS peer: it requires extending), but also in the new path until it intersectscontext of other types of network (e.g. ); a general review of the old one. Thisfundamental interactions is easy for the uplink direction (wheregiven in , which provides further details on many of the mobile issubjects considered in this section. We are assuming that the sender), but much harder for downlink withoutsignaling viawill refer to 'outer' IP headers when defining the correspondent. Thereflows it is no reasoncontrolling. There two main reasons for this. The first is that the crossover node todata plane will usually be the same for uplink and downlink flows, even for the same correspondent.unable to work in terms of anything else when implementing per-flow treatment (e.g. we cannot expect a router will analyse inner headers to decide how to schedule packets). The problemsecond reason is discussed further in . 5.2.3 Updatethat we are implicitly relying on the Unchanged Path Onsecurity provided by the path betweennetwork infrastructure to ensure that the crossover node(s) andcorrect packets are given the correspondent, itspecial treatment being signaled for, and this is necessary to avoid, if possible, double reservations, but also to updatebuilt on the relationship between packet source and destination addresses and network control state to reflect new flow identificationtopology (this is needed, byessentially the default assumption of section 5.2.1). Examples of approachessame approach that could beis used to solve this problem areas the following: *) Use a session state identificationbasis of route optimization security in Mobile IPv6 ). The consequence of this assumption is that does not change even ifwe see the packet streams to (or from) different addresses as different flows, and where a flow definition changes (see Section 4.6.2). Signalingis still needed to updatecarried inside a changedtunnel this is seen as a different flow identification, but it should be possibleagain. The encapsulation issues (point (2) above) are therefore to avoid AAA and admission control processing. *) Use an NSIS-capable crossover routerbe handled the same way as other tunneling cases (section 5.4). The most critical aspect is therefore the fact that manages this update autonomously (more efficiently thanmultiple flows are being used, and the end nodes could), with similar considerationssignaling for them needs to be correlated together. This is the local path repair case. Note that inintended role of the casesession identifier (see section 4.6.2, which also describes some of the security requirements for such an address change, end to end message exchanges will be requiredidentifier). Although the session identifier is visible at the NTLP, it is the signaling application layer anyway,which is responsible for performing the correlation (and doing so signalingsecurely). The NTLP responsibility is limited to updatedelivering the signaling messages for each flow identifier does not necessarily add tobetween the handover latency. 5.2.4 Interaction with Mobility Signaling In existing work on mobility protocol andcorrect signaling protocol interactions, several framework proposals describingapplication peers. The locations at which the protocol interactions have been made. Usually they have taken existing protocols (Mobile IPcorrelation takes place are the end system and RSVP respectively)the signaling application aware node in the network where the flows meet (this node is generally referred to as the starting point;"crossover router"; it shouldcan be noted that an NSIS protocol might operateanywhere in quite a different way. In this section, we provide an overview of how these proposals fit withinthe rest of this framework. The mobility aspects are described using MIP terminology, but are generally applicable to other network layernetwork). Although much work has been done in the past on finding the crossover router directly from information held in particular mobility solutions. The purposesignaling protocols, the initial focus of this overviewNSIS work should be to have a solution which is not tightly bound to selectany particular approach, but simplysingle mobility approach. In other words, it should be possible to pointdetermine the crossover router based on NSIS signaling. (This doesn't rule out how they would fit into our framework and any major issuesthe possibility that some implementations may be able to do this discovery faster, e.g. by being tightly integrated with them. We can consider that two signaling processes are active:local mobility signaling and NSIS signaling. The discussion so far considered how NSIS signaling should operate. Theremanagement protocols; this is still a question of howdirectly comparable to spotting route changes in fixed networks by being routing aware.) Note that the interactions betweencrossover router discovery may involve end-to-end signaling exchanges (especially for flows towards the NSIS and mobilitymobile or multihomed node) which raises a latency concern; on the other hand, end to end signaling should be considered. The basic case of totally independent specificationwill have been necessary in any case, both at the application level (to communicate changed addresses) and implementation can leadalso to ambiguities and even interoperability problems. At least,update packet classifiers along the addressing and encapsulation issuespath. It is a matter for mobility solutions that use virtual links or their equivalents needfurther analysis to decide how these exchanges could be specifiedcombined or carried out in an implementation-neutral way. A typeparallel. On the shared part of 'loose' integrationthe path, signaling is needed at least to have independent protocols, but to define how they trigger each other - in particular, howupdate the mobility protocol triggers sending of refresh/modify/tear messages. A pair of implementations could use these triggerspacket classifiers to improve performance, primarily reducing latency. (Existing RSVP modifications considerinclude the closer interaction of makingnew flow, although if correlation with the RSVP implementation mobility routing aware, e.g. so itexisting flow is able to localize refresh signaling; this wouldpossible it should be a self contained aspect of NSIS.) An even tighter levelpossible to bypass any policy or admission control processing. State installation on the new path (and possibly release on the old one) are also required. Which entity (one of integration isthe end hosts or the crossover router) controls all these procedures depends on which entities are authorised to consider a single protocol carrying both mobility andcarry out network controlstate information. Logically, there are two cases: 1. Carry mobility routing information (a 'mobility object') in the signaling messages. (The prime purpose inmanipulations, so this approachis to enable crossover router discovery.) 2. Carry signaling in the mobility messages, typically as a new extension header. In our framework, we could consider thistherefore a special casematter of NSIS layering, with the mobility protocol playingsignaling application and NSLP design. The approach may depend on the rolesender/receiver orientation of the original signaling transport. Other modes of interaction might also(see section 3.3.1). In addition, in the mobility case, the old path may no longer be possible. The critical point with all these models is thatdirectly accessible to the general solutions developed by NSIS shouldmobile node; inter-access-router communication may be independent of choice of mobility protocols. Tight integration would have major deployment issues especiallyrequired to release state in interdomain cases. Therefore, any tightly integrated solution is considered out of scopethese circumstances. The frequency of initial development. 5.2.5 Interaction with Seamless Handover Protocols Inhandovers in some network types encourages the contextconsideration of mobility between different access routers, it is common to consider performance optimizations in two areas:fast handover support protocols, for selection of the optimal access router to handover to,hand over to (for example, ), and transfer of state information between the access routersto avoid having to regenerate it in the new access router after handover. The Seamoby Working Group is developing solutions forhandover (for example, ). Both these protocols (CARD  and Context Transfer  respectively); alternative approachesprocedures could have strong interactions with similar characteristics are also possible. As these solutions are still under development, it is premature to specify detailssignaling protocols, the former because a selection criterion might be what network control state could be supported on the interaction. It is thought that Context Transfer transferspath through the new access router, the latter because signaling application state between access routers based upon changes caused by mobility. NSISor NTLP/NSLP protocol state may be a candidate for context transfer. Such work, should it be undertaken, will be done in the Seamoby working group.5.3 Interactions with NATs Because at least some messages will almost inevitably contain addressaddresses and possibly higher layer information as payload, we must consider the interaction with address translation devices (NATs). As well asThese considerations apply both to 'traditional' NATs of various types (as defined in ) very similar considerations would apply to) as well as some IPv4/v6 transition mechanisms such as SIIT .. In the simplest case of an NSIS unaware NAT in the path, payloads will be uncorrected and signaling will refer to the flow incorrectly. Applications could attempt to use STUN  or similar techniques to detect and recover from the presence of the NAT. Even then, NSIS protocols would have to use a well known encapsulation (TCP/UDP/ICMP) to avoid being dropped by more cautious low-end NAT devices. A simple 'NSIS-aware' NAT would require flow identification information to be in the clear and not integrity protected. An alternative conceptual approach is to consider the NAT functionality being part of message processing itself, in which case the translating node can take part natively in any NSIS protocol security mechanisms. Depending on NSIS protocol layering, it would be possible for this processing to be done in an NSIS entity which was otherwise ignorant of any particular signaling applications. This is the motivation for including basic flow identification information in the NTLP (section 4.6.1). Note that all of this discussion is independent of the use of a specific NSLP for general control of NATs (and firewalls). This is considered in section 6.2. 5.4 Interactions with IP Tunneling Tunneling is used in the Internet for a number of reasons such as flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual private networking, and so on. An NSIS solution must continue to work in the presence of these techniques, i.e. the presence of the tunnel should not cause problems for end-to-end signaling, and it should also be possible to use NSIS signaling to control the treatment of the packets carrying the tunneled data. It is assumed that the NSIS approach will be similar to that of , where the signaling for the end-to-end data flow is tunneled along with that data flow, and is invisible to nodes along the path of the tunnel (other than the endpoints). This provides backwards compatibility with networks where the tunnel endpoints do not support the NSIS protocols. We assume that NEs will not unwrap tunnel encapsulations to find and process tunneled signaling messages. To signal for the packets carrying the tunneled data, the tunnel is considered as a new data flow in its own right, and NSIS signaling is applied recursively to it. This requires signaling support in at least one tunnel endpoint. In some cases (where the signaling initiator is at the opposite end of the data flow from the tunnel initiator - i.e. in the case of receiver initiated signaling), there needs to be the ability to provide a binding between the original flow identification and that for the tunneled flow. It is left open here whether this should be an NTLP or an NSLP function. 6 Signaling Applications This section describesgives an overview of NSLPs for particular signaling applications. The assumption is that the NSLP uses the generic functionality of the NTLP given earlier; this section describes specific aspects of NSLP operation. It is intended to clarify by example how NSLPs fit into the framework; formal NSLP protocol designs will be contained in separate documents. 6.1 Signaling for Quality of Service In the case of signaling for QoS, all the basic NSIS concepts of section 3.1 apply. In addition, there is an assumed directionality of the signaling process, in that one end of the signaling flow takes responsibility for actually requesting the resource. This leads to the following definitions: *) QoS NSIS Initiator (NI):(QNI): the signaling entity which makes the resource request, usually as a result of user application request. *) QoS NSIS Responder (NR):(QNR): the signaling entity that acts as the endpoint for the signaling and can optionally interact with applications as well. *) QoS NSIS Forwarder (NF):(QNF): the signaling entity between an NIa QNI and NRQNR which propagates NSIS signaling further through the network. Each of these entities will interact with a resource management function (RMF) which actually allocates network resources (router buffers, interface bandwidth and so on). Note that there is no constraint on which end of the signaling flow should take the NSIS InitiatorQNI role: with respect to the data flow direction it could be at the sending or receiving end. Note the continued assumption is that the NTLP works with standard (i.e. best-effort) layer 3 routing. There are, however, several proposals for the introduction of QoS awareness in routing protocols. All of these essentially lead to the existence of multiple paths (with different QoS) towards the same destination. As such, they also contain an inherent risk for a divergence between control plane and data plane, similar to the load sharing case. Clearly, any QoS NSLP needs to be able to handle this type of routing, although, provided the NTLP continues to deliver signaling messages correctly, the impact on the QoS NSLP protocol design itself should be limited. 6.1.1 Protocol MessagesMessage Semantics The QoS NSLP will include a set of messages to carry out resource reservations along the signaling path. A messagepossible set of message semantics for the QoS NSLP is shown below (a very similar set of messages was generated in ).below. Note that the 'direction' column in the table below only indicates the 'orientation' of the message. The messagesMessages can be originated and absorbed at NFQNF nodes as well as the NIQNI or NR;QNR; an example might be NFsQNFs at the edge of a domain exchanging messages to set up resources for a flow across a it. Note the working assumptionthat responder as well as the initiator can release a reservation (comparable to rejectingit in the first place). Itis left open if the responder can release or modify a reservation, during or after setup. This seems mainly a matter of assumptions about authorization, and the possibilities might depend on resource type specifics. +-------+---------+---------------------------------------------+The table also explicitly includes a refresh operation. This does nothing to a reservation except extend its lifetime, and is one possible state management mechanism (see next section). +-----------+---------+--------------------------------------------+ | NameOperation |Direction| Semantics | +-------+---------+---------------------------------------------+ |Request|+-----------+---------+--------------------------------------------+ | Request | I-->R | Create a new reservation for a flow | +-------+---------+---------------------------------------------+ |Modify+-----------+---------+--------------------------------------------+ | Modify | I-->R | Modify an existing reservation | | |(&R-->I?)| | +-------+---------+---------------------------------------------+ |Release|+-----------+---------+--------------------------------------------+ | Release | I-->R &| Delete (tear down) an existing reservation | | |(&R-->I?)| | R-->I+-----------+---------+--------------------------------------------+ | Accept/ | +-------+---------+---------------------------------------------+ |Accept/|R-->I | Confirm (possibly modified?) or reject a | | Reject|Reject | | reservation request | +-------+---------+---------------------------------------------+ |Notify+-----------+---------+--------------------------------------------+ | Notify | I-->R & | Report an event detected within the | | | R-->I | network | +-------+---------+---------------------------------------------+ |Refresh| I-->R | State management (see section 4.4) | +-------+---------+---------------------------------------------+ The table also explicitly includes a refresh message. This does nothing to a reservation except extend its lifetime, and is one possible state| +-----------+---------+--------------------------------------------+ | Refresh | I-->R | State management mechanism(see next section).section 6.1.2) | +-----------+---------+--------------------------------------------+ 6.1.2 State Management The prime purpose of NSIS is to manage state information along the path taken by a data flow. The issues regarding state management within the NTLP (state related to message transport) are described in section 4. The QoS NSLP will typically have to handle additional state related to the desired resource reservation to be made. There two critical issues to be considered in building a robust NSLP to handle this problem: *) The protocol must be scalable. It should allow minimization of the resource reservation state storage demands that it implies for intermediate nodes; in particular, storage of state per 'micro' flow is likely to be impossible except at the very edge of the network. A QoS signaling application might require per flow or lower granularity state; examples of each for the case of QoS would be IntServ  or RMD  (per 'class' state) respectively. *) The protocol must be robust against failure and other conditions, which imply that the stored resource reservation state has to be moved or removed. For resource reservations, soft state management is typically used as a general robustness mechanism. According to the discussion of section 3.2.4, the soft state protocol mechanisms are built into the NSLP for the specific signaling application that needs them; the NTLP sees this simply as a sequence of (presumably identical) messages. 6.1.3 QoS Forwarding The assumption is that the NTLP works with standard (i.e. best- effort) layer 3 routing. There are, however, several proposals for the introduction of QoS awareness in the routing protocols. All of these essentially lead to the existence of multiple paths (with different QoS) towards the same destination. As such, they also contain an inherent risk for a divergence between control plane and data plane, similar to the load sharing case. Clearly, any QoS NSLP needs to be able to handle this type of routing. For intra-domain data flows, the difference in routing may result from a QoS-aware traffic engineering scheme, that e.g. maps incoming flows to LSPs based on multi-field classification. In BGP, several techniques for including QoS information in the routing decision are currently proposed. A first proposal is based on a newly defined BGP- 4 attribute, the QoS_NLRI attribute . The QoS_NLRI attribute is an optional transitive attribute that can be used to advertise a QoS route to a peer or to provide QoS information along with the Network Layer Reachability Information (NLRI) in a single BGP update. A second proposal is based on controlled redistribution of AS routes . It defines a new extended community (the redistribution extended community) that allows a router to influence how a specific route should be redistributed towards a specified set of eBGP speakers. The types of redistribution communities may result in a specific route not being announcedrobustness mechanism. According to a specified setthe discussion of eBGP speakers, that it should not be exported orsection 3.2.5, the soft state protocol mechanisms are built into the NSLP for the specific signaling application that needs them; the route should be prepended n times. 6.1.4NTLP sees this simply as a sequence of (presumably identical) messages. 6.1.3 Route Changes and QoS Reservations In this section, we will explore the expected interworkinginteraction between a signaling forresource BGPsignaling and routing updates, although the same applies for anyupdates (the precise source of routing updates.updates does not matter). The normal operation of the NSIS protocol will lead to the situation depicted in Figure 7, where the reserved resources match the data path. reserved +----++-----+ reserved +----++-----+ ------->| NFQNF |----------->| NFQNF | +----+ +----+ =====================================+-----+ +-----+ ======================================= data path Figure 7: Normal NSIS protocol operation A route change (triggered by a BGP routing update for instance)can occur while such a reservation is in place. In case of RSVP, theThe route change will be installed immediately and any data that is sentwill be forwarded on the new path. This situation is depicted Figure 8. Route update | v reserved +----++-----+ reserved +----++-----+ ------->| NFQNF |----------->| NFQNF | +----+ +----++-----+ +-----+ ========== | || | +----++-----+ || +---------->| NFQNF | || +----++-----+ ============================ data path Figure 8: Route Change Resource reservation on the new path will only be started once the next control message is routed along the new path. This means that there is a certain time interval during which resources are not reserved on (part of) the data path. To minimize this time interval several techniques could be considered. As an example, RSVP  has the concept of local repair, where the router may be triggered by a route change. In that case the RSVP node can start sending PATH messages directly after the route has been changed. Note that this option may not be available if no per-flow state is kept in the NF. It is not guaranteed that the new path will be able to provide the same guarantees that were available on the old path. Therefore, in a more desirable scenario, the NFQNF should wait until resources have been reserved on the new path before installing the route change (unless of course the old path no longer exists). The route change procedure then consists of the following steps: 1. NFQNF receives a route announcement, 2. Refresh messages are forwarded along the current path, 3. A copy of the refresh message is re-marked as a request and sent along the new path that was announced, 4. When the NFQNF has been acknowledged about the reservations on the new path, the route will be installed and data will flow along it. Another example related to route changes is denoted as severe congestion and is explained in .. This solution adapts to a route change, when a route change creates acongestion on the new routed path. 18.104.22.168.4 Resource Management Interactions The QoS NSLP itself is not involved in any specific resource allocation or management techniques. The definition of an NSLP for resource reservation with Quality-of-Service,Quality of Service, however, implies the notion of admission control. For a QoS NSLP, the measure of signaling success will be the ability to reserve resources from the total resource pool that is provisioned in the network. We define the function responsible for allocating this resource pool as the Resource Management Function (RMF). The RMF is responsible for all resource provisioning, monitoring and assurance functions in the network. A QoS NSLP will rely on the RMF to do resource management and to provide inputs for admission control. In this model, the RMF acts as a server towards client NSLP(s). It is noted, however, that the RMF may in turn use another NSLP instance to do the actual resource provisioning in the network. In this case, the RMF acts as the initiator (client) of an NSLP. This essentially corresponds to a multi-level signaling paradigm, with an 'upper' level handling internetworking QoS signaling, possibly running end-to-end, and a 'lower' level handling the more specialisedspecialized intradomain QoS signaling, running between just the edges of the network (see , ,, , and  for a discussion of similar architectures). Given that NSIS signaling is already supposed to be able to support multiple instances of NSLPs for a given flow, and limited scope (e.g. edge-to-edge) operation, it is not currently clear that supporting the multi-level model leads to any new protocol requirements for the QoS NSLP. The RMF may or may not be co-located with an NFa QNF (note that co- location with an NI/NRa QNI/QNR can be handled logically as a combination between NFQNF and NI/NR).QNI/QNR). To cater for both cases, we define a (possibly logical) NF-RMF interface. Over this interface, information may be provided from the RMF about monitoring, resource availability, topology, and configuration. In the other direction, the interface may be used to trigger requests for resource provisioning. One way to formalize the interface between the NFQNF and the RMF is via a Service Level Agreement (SLA). The SLA may be static or it may be dynamically updated by means of a negotiation protocol. Such a protocol is outside the scope of NSIS. There is no assumed restriction on the placement of the RMF. It may be a centralized RMF per domain, several off-path distributed RMFs, or an on-path RMF per router. The advantages and disadvantages of both approaches are well-known. Centralization typically allows decisions to be taken onusing more global information with more efficient resource utilization as a result. It also facilitates deployment or upgrade of policies. Distribution allows local decision processes and rapid response to data path changes. 6.2 Other Signaling Applications As well as the use for 'traditional' QoS signaling, it should be possible to usedevelop NSLPs for other signaling applications which operate on different types of network control state. One specific case is setting up flow-related state in middleboxes (firewalls, NATs, and so on). Requirements for such communication are given in ,, and initial discussions of NSIS-like solutions are contained in  and .. Other examples include network monitoring and testing, and tunnel endpoint discovery. A future version of this document may contain more details on how to build NSLPs for these types of signaling application.7 Security Considerations This document describes a framework for signaling protocols which assumes a two-layer decomposition, with a common lower layer (NTLP) supporting a family of signaling application specific upper layer protocols (NSLPs). The overall security considerations for the signaling therefore depend on the joint security properties assumed or demanded for each layer. Security for the NTLP is discussed in section 4.7. We have assumed that the role of the NTLP will be to provide message protection over the scope of a single peer relationship (betweenrelationship, between adjacent signaling entities), and that thisapplication entities (see section 3.2.3 for a discussion of the case where these entities are separated by more than one NTLP hop). These functions can most likely be provided by some kind of channel security mechanism using an external key management mechanism based on mutual authentication. In addition, the NTLP should be resilient against denial of service attacks on the protocol itself. Security for the NSLPs is entirely dependent on signaling application requirements. In some cases, no additional protection may be required compared to what is provided by the NTLP. In other cases, more sophisticated object-level protection and the use of public key based solutions may be required. In addition, the NSLP needs to consider the authorisation requirements of the signaling application. Authorisation is a complex topic, for which a very brief overview is provided in section 3.3.7. Another factor is that NTLP security mechanisms operate only locally, whereas NSLP mechanisms may also need to operate over larger regions (not just between adjacent peers) especially for authorisation aspects; this complicates the analysisanalysis of basing signaling application security on NTLP protection. An additional concern for signaling applications is the session identifier security issue (sections 4.6.2 and 5.2). The purpose of this identifier is to decouple session identification (as a handle for network control state) from session "location" (i.e. the data flow endpoints). The identifier/locator distinction has been extensively discussed in the user plane for end to end data flows, and is known to lead to non-trivial security issues in binding the two together again; our problem is the analogue in the control plane, and is at least similarly complex, because of the need to involve nodes in the interior of basing signaling application security on NTLP protection.the network as well. Further work on this and other security design will depend on a refinement of the NSIS threats work begun in .. 8 Change History [Editor's note: this section to be removed in final published version.] 8.1 Changes from draft-ietf-nsis-fw-03.txt 1. Added new general section (using part of old content of 3.2.1) about how to handle intermediate nodes which don't really want to process some signaling application messages fully (new section 3.2.3). 2. Added a new section outlining where responsibility for aggregation is placed within the layer split (section 3.3.4). 3. Closed the issue about reliability by saying that the NTLP must provide the ability to deliver a message reliably but that this doesn't mean the same thing as hard state or guaranteed execution at the receiver - essentially the conclusions from draft-hancock- nsis-reliability-00.txt (section 4.3). 4. Removed the issue about summary refreshes (section 4.3), allowing the NSLP to do it by choice and leaving open extension of the NTLP to do more general lower layer compression. 5. Included small notes on route change interactions and layer split assumption, including merging in of VRRP considerations; also some general text tidying (section 5.1.2). 6. Radically shortened and updated the mobility discussion (section 5.2), outlining the layer split assumption but removing most of the analysis and justification, in the hope that a separate document will eventually cover this area. 7. Included new section on tunnel handling (section 5.4). 8. Removed most of the detailed discussion of QoS routing and BGP from section 6.1. Updated terminology in line with current QoS- NSLP design work, and clarified that this is not actually the official protocol design. 9. Updated references and fixed a number of minor typos. 8.2 Changes from draft-ietf-nsis-fw-02.txt 1. Re-instated 'long' definition of path-coupled from -01 version (section 3.1.2). 2. Moved NTLP open issues (transport and state management functionality) to section 22.214.171.124.5 and 4.3, and closed several of them: NTLP does bundling and fragmentation, but is ignorant of NSLP state and vice versa. However, added a new open issue on message summarization. 3. Updated section 5.2 and elsewhere to refer to the WG draft on mobility/RSVP analysis and an external review paper. Updated section 6.2 with references to more recent work on path-coupled signaling to middleboxes. General tidying of other references. 8.28.3 Changes from draft-ietf-nsis-fw-01.txt This -02 version has been very significantly restructured compared to the previous version, and a section by section change history is probably neither possible or useful. Instead, this section lists the major technical and structural changes. 1. The concept of splitting the protocol suite into two layers is now introduced much earlier, and the rest of the framework restructured around it. In general, the content is supposed to be signaling application independent: possibilities for application dependent behavior are described in section 3.3, and the specific case of QoS/resource management is restricted to section 6.1. 2. Sender and receiver orientation is now assumed to be a signaling application protocol property (section 3.3.1), with the NTLP by default operating bidirectionally (section 3.2.3).3.2.4). As a consequence, the initiator, forwarder, and responder concepts only appear in the later sections. 3. In general, the NTLP is now a 'thinner' layer than previously envisaged (e.g. without specific reserve/tear messages), and so the possible inter-layer coupling with the NSLP is much reduced. However, the option of the NTLP providing some kind of generic state management service is still an open issue. 4. In general, authorisation issues are still handled by the NSLP, including the question of which network entities are allowed to modify network state. In particular, the issue of 'session' (previously 'reservation') ownership (section 3.1.5) is assumed to be handled by the NSLP level, although session identification is still visible to the NTLP (section 4.6.2). The implication is that most key aspects of mobility support (section 5.2) are now NSLP responsibilities. 5. Both peer-peer and end-to-end addressing modes are assumed to be needed for the NTLP, and any choice between them is a protocol design issue (not visible externally). References [Editor's note: in a future version, these will be split as Normative and Informative.] 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997 32 Brunner, M., "Requirements for Signaling Protocols", draft-ietf- nsis-req-08.txtnsis-req-09.txt (work in progress), JuneAugust 2003 43 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", draft-ietf-nsis-threats-01.txtdraft-ietf-nsis-threats-02.txt (work in progress), JanuaryJune 2003 54 Chaskar, H. (editor), "Requirements" Requirements of a QoSQuality of Service (QoS) Solution for Mobile IP", draft-ietf-nsis-qos-requirements-01.txt (work in progress), JuneRFC 3583, September 2003 65 Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002 76 Manner, J. andJ., X. Fu, P. Pan, "Analysis of Existing Quality of Service Signaling Protocols", draft-ietf-nsis-signalling-analysis-01.txtdraft-ietf-nsis-signalling-analysis- 02.txt (work in progress), FebruaryJune 2003 87 Tschofenig, H., "RSVP Security Properties", draft-ietf-nsis-rsvp- sec-properties-01.txtsec-properties-02.txt (work in progress), March,June 2003 8 Katz, D., "IP Router Alert Option", RFC2113, February 1997 9 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999 10 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001 11 Rescorla, E. et al.,and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", draft-iab-sec-cons-03.txt (work in progress), JanuaryRFC 3552, July 2003 1012 Tschofenig, H., M. Buechli, S. Van den Bosch, H. Schulzrinne, "NSIS Authentication, Authorization and Accounting Issues", draft- tschofenig-nsis-aaa-issues-01.txt (work in progress), March 2003 1113 Berger, L., D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC2961, April 2001 12 Hancock, R., E. Hepworth, A. McDonald, "Handling Overload Conditions in the NSIS Protocol Suite", draft-hancock-nsis- overload-00.txt (work in progress), June 2003 13 Katz, D., "IP Router Alert Option", RFC2113, February 199714 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711,Ji, P., Z. Ge, J. Kurose, D. Townsley, "A Comparison of Hard-State and Soft-State Signaling Protocols", Computer Communication Review, Volume 33, Number 4, October 19992003 15 Floyd, S., "Congestion Control Principles", RFC 2914, September 2000 16 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda, T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC 2676, August 1999 16 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 199517 Rekhter, Y. T. Li, S.Hares, "A Border Gateway Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-20.txt (work in progress), April 2003 18Knight, S., D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem, "Virtual Router Redundancy Protocol", RFC2338, April 1998 1918 Heijenk, G., G. Karagiannis, V. Rexhepi, L. Westberg, "DiffServ Resource Management in IP-based Radio Access Networks", Proceedings of 4th International Symposium on Wireless Personal Multimedia Communications-WPMC'01, September 9 - 12, 2001 2019 Manner, J., A. Lopez, A. Mihailovic, H. Velayos, E. Hepworth, Y. Khouaja, "Evaluation of Mobility and QoS Interaction", Computer Networks, Volume 38, Issue 2, 5 February 2002, pp 137-163 21 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-01.txt20 Johnson, D., C. Perkins, J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress), JanuaryJune 2003 2221 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in candidate access router discovery for seamless IP-level handoffs", draft-ietf-seamoby-cardiscovery-issues-04.txt (work in progress), October 2002 2322 Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC3374, September 2002 2423 Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC2663, August 1999 2524 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC2765, February 2000 2625 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC3489, March 2003 26 Terzis, A., J. Krawczyk, J. Wroclawski, L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000 27 Westberg, L., et al., "Resource Management in Diffserv (RMD) Framework", draft-westberg-rmd-framework-03.txt (work in progress), June 2003 28Braden, R., D. Clark, S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994 2928 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., Partain, D., Pop, O., Rexhepi, V., Szabó,Szabo, R., Takács,Takacs, A., "Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview", Seventh International Workshop on Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002 3029 Ferrari, D., A. Banerjea, H. Zhang, "Network Support for Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92- 072, November 1992 3130 Nichols, K., V. Jacobson, L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999 32 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001 3331 Brunner, M., M. Stiemerling, M. Martin, H. Tschofenig, H. Schulzrinne, "SIS"NSIS NAT/FW NSLP: Problem Statement and Framework", draft-brunner-nsis-midcom-ps-00.txt (work in progress), June 2003 3432 Aoun, C., "NSIS Network Address Translator implications", draft- aoun-nsis-nat-imps-01.txt (work in progress), March 2003 Acknowledgments The authors would like to thank Bob Braden, Maarten Buchli, Eleanor Hepworth, Andrew McDonald, Melinda Shore and Hannes Tschofenig for significant contributions in particular areas of this draft. In addition, the authors would like to acknowledge Cedric Aoun, Attila Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness, Xiaoming Fu, Ruediger Geib, Danny Goderis, Cornelia Kappler, Sung Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De Neve, Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne, Tom Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars Westberg, and Lixia Zhang for insights and inputs during this and previous framework activities. Authors' Addresses Ilya Freytsis Cetacean Networks Inc. 100 Arboretum Drive Portsmouth, NH 03801 USA email: firstname.lastname@example.orgRobert Hancock (editor) Roke Manor Research Old Salisbury Lane Romsey Hampshire SO51 0ZN United Kingdom email: email@example.com Ilya Freytsis Cetacean Networks Inc. 100 Arboretum Drive Portsmouth, NH 03801 USA email: firstname.lastname@example.org Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE Enschede The Netherlands email: email@example.com John Loughney Nokia Research Center 11-13 Italahdenkatu 00180 Helsinki Finland email: firstname.lastname@example.org Sven Van den Bosch Alcatel Francis Wellesplein 1 B-2018 Antwerpen Belgium email: email@example.com Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement "CopyrightCopyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.