diff options
Diffstat (limited to 'doc/rfc/rfc4080.txt')
| -rw-r--r-- | doc/rfc/rfc4080.txt | 2747 |
1 files changed, 2747 insertions, 0 deletions
diff --git a/doc/rfc/rfc4080.txt b/doc/rfc/rfc4080.txt new file mode 100644 index 0000000..6d455ba --- /dev/null +++ b/doc/rfc/rfc4080.txt @@ -0,0 +1,2747 @@ + + + + + + +Network Working Group R. Hancock +Request for Comments: 4080 Siemens/RMR +Category: Informational G. Karagiannis + University of Twente/Ericsson + J. Loughney + Nokia + S. Van den Bosch + Alcatel + June 2005 + + + Next Steps in Signaling (NSIS): Framework + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The Next Steps in Signaling (NSIS) working group is considering + protocols for signaling information about a data flow along its path + in the network. The NSIS suite of protocols is envisioned to support + various signaling applications that need to install and/or manipulate + such state in the network. Based on existing work on signaling + requirements, this document proposes an architectural framework for + these signaling protocols. + + This document provides a model for the network entities that take + part in such signaling, and for the relationship between signaling + and the rest of network operation. We decompose the overall + signaling protocol suite into a generic (lower) layer, with separate + upper layers for each specific signaling application. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Definition of the Signaling Problem ........................3 + 1.2. Scope and Structure of the NSIS Framework ..................3 + 2. Terminology .....................................................4 + 3. Overview of Signaling Scenarios and Protocol Structure ..........6 + 3.1. Fundamental Signaling Concepts .............................6 + 3.1.1. Simple Network and Signaling Topology ...............6 + + + +Hancock, et al. Informational [Page 1] + +RFC 4080 NSIS Framework June 2005 + + + 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 ................................12 + 3.2.3. Bypassing Intermediate Nodes .......................13 + 3.2.4. Core NSIS Transport Layer Functionality ............15 + 3.2.5. State Management Functionality .....................16 + 3.2.6. Path-Decoupled Operation ...........................17 + 3.3. Signaling Application Properties ..........................18 + 3.3.1. Sender/Receiver Orientation ........................18 + 3.3.2. Uni- and Bi-Directional Operation ..................19 + 3.3.3. Heterogeneous Operation ............................19 + 3.3.4. Aggregation ........................................20 + 3.3.5. Peer-Peer and End-End Relationships ................21 + 3.3.6. Acknowledgements and Notifications .................21 + 3.3.7. Security and Other AAA Issues ......................22 + 4. The NSIS Transport Layer Protocol ..............................23 + 4.1. Internal Protocol Components ..............................23 + 4.2. Addressing ................................................24 + 4.3. Classical Transport Functions .............................24 + 4.4. Lower Layer Interfaces ....................................26 + 4.5. Upper Layer Services ......................................27 + 4.6. Identity Elements .........................................28 + 4.6.1. Flow Identification ................................28 + 4.6.2. Session Identification .............................28 + 4.6.3. Signaling Application Identification ...............29 + 4.7. Security Properties .......................................30 + 5. Interactions with Other Protocols ..............................30 + 5.1. IP Routing Interactions ...................................30 + 5.1.1. Load Sharing and Policy-Based Forwarding ...........31 + 5.1.2. Route Changes ......................................31 + 5.2. Mobility and Multihoming Interactions .....................33 + 5.3. Interactions with NATs ....................................36 + 5.4. Interactions with IP Tunneling ............................36 + 6. Signaling Applications .........................................37 + 6.1. Signaling for Quality of Service ..........................37 + 6.1.1. Protocol Message Semantics .........................38 + 6.1.2. State Management ...................................39 + 6.1.3. Route Changes and QoS Reservations .................39 + 6.1.4. Resource Management Interactions ...................41 + 6.2. Other Signaling Applications ..............................42 + 7. Security Considerations ........................................42 + 8. References .....................................................43 + 8.1. Normative References ......................................43 + 8.2. Informative References ....................................44 + + + +Hancock, et al. Informational [Page 2] + +RFC 4080 NSIS Framework June 2005 + + +1. Introduction + +1.1. Definition of the Signaling Problem + + The Next Steps in Signaling (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, + independently 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. First, the + intention is that components of the NSIS protocol 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). + + Second, 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, upper layers suitable for QoS + signaling (similar to the corresponding functionality in RSVP) and + middlebox 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 [1] and a separate security threats document [2]; other + related requirements can be found in [3] and [4] for QoS/Mobility and + middlebox communication, respectively. 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 [5], [6]. + + The role of this framework is to explain how NSIS signaling should + work within the broader networking context, and to describe the + overall structure of the protocol suite itself. Therefore, it + + + + +Hancock, et al. Informational [Page 3] + +RFC 4080 NSIS Framework June 2005 + + + 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 [7]; in particular, Section 3.1.3 + describes more general signaling scenarios, and Section 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 + detailed 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 identifier elements that + appear on these 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 (NAT). + + 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; we do not intend 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 + + Classifier: an entity that selects packets based on their contents + according to defined rules. + + [Data] flow: a stream of packets from sender to receiver that is a + distinguishable subset of a packet stream. Each flow is + distinguished by some flow identifier (see Section 4.6.1). + + + + + +Hancock, et al. Informational [Page 4] + +RFC 4080 NSIS Framework June 2005 + + + Edge node: an (NSIS-capable) node on the boundary of some + administrative domain. + + Interior nodes: the set of (NSIS-capable) nodes that form an + administrative domain, excluding the edge nodes. + + NSIS Entity (NE): the function within a node that 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 in which the signaling + messages follow a path that is tied to the data messages. + + Path-decoupled signaling: signaling for 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 that is receiving the data packets + in a flow. + + Sender: the node in the network that 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 3.1.5). + + Signaling application: the purpose of the NSIS signaling. A + signaling application could be QoS management, firewall control, + and so on. Totally distinct from any specific user application. + + + + + + + +Hancock, et al. Informational [Page 5] + +RFC 4080 NSIS Framework June 2005 + + +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 that 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 here we make no assumptions about the + particular sequence of signaling messages that will be invoked. + + + + + + + + + + + + +Hancock, et al. Informational [Page 6] + +RFC 4080 NSIS Framework June 2005 + + + Sender Receiver + +-----------+ +----+ +----+ +----+ +-----------+ + |Application|----->| R1 |----->| R2 |----->| R3 |----->|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 + NEs that are on the data path. They do not have to reach all the + nodes on the data path. (For example, there could be intermediate + signaling-unaware nodes, or the presence of proxies such as those + shown in Figure 2 could prevent the signaling from reaching the path + end points.) 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 addressed identically to the data + packets, but also with the router alert option (see [8] and [9]), 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) that are not assumed to be on the data path, but that 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.6; however, the initial goal of + NSIS and this framework is to concentrate mainly on the path-coupled + case. + + + + + + + + +Hancock, et al. Informational [Page 7] + +RFC 4080 NSIS Framework June 2005 + + +3.1.3. Signaling to Hosts, Networks, and Proxies + + There are different possible triggers for the signaling protocols. + Among them are user applications (that are using NSIS signaling + services), other 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. + + Although 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 a single domain or multiple concatenated NSIS domains. The + latter case assumes the existence of trust relations 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 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 a kind of "proxy on the data path"; see Figure 2. + + + + + + + + + + + + + + + + +Hancock, et al. Informational [Page 8] + +RFC 4080 NSIS Framework June 2005 + + + 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 two specific challenges for the + signaling: + + o A proxy that terminates signaling on behalf of the NSIS-unaware + host (or part of the network) should be able to determine that it + is the last NSIS-aware node along the path. + + o 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 a 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 + + + + + + +Hancock, et al. Informational [Page 9] + +RFC 4080 NSIS Framework June 2005 + + + 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 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.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 that are of interest 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 'network control state' generically. + 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 that 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 an exchange of packets + between two endpoints, for which some network state is to be + allocated or monitored. In simple cases, a session may map to a + specific flow; however, signaling applications are allowed to create + + + +Hancock, et al. Informational [Page 10] + +RFC 4080 NSIS Framework June 2005 + + + more flexible flow:session relationships. (Note that this concept of + 'session' is different from that of RSVP, which defines a session as + a flow with a specific destination address and transport protocol. + The NSIS usage is closer to the session concepts of higher-layer + protocols.) + + The simplest service provided by NSIS signaling protocols is the + 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 [1] and the mobility discussion of + [5]), 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 that + 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 to 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 two layers: + + o a 'signaling transport' layer, responsible for moving signaling + messages around, which should be independent of any particular + signaling application; and + + o 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 + + + +Hancock, et al. Informational [Page 11] + +RFC 4080 NSIS Framework June 2005 + + + 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 what interacts strongly with other transport and + lower-layer operations. + +3.2.2. Layer Split Concept + + This section describes the basic concepts underlying the + functionality of the NTLP. First, 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 (upstream or + downstream), 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 + + + + + +Hancock, et al. Informational [Page 12] + +RFC 4080 NSIS Framework June 2005 + + + 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 or acknowledgement of + 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 that 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 3.3.6. + + One motivation for restricting the NTLP to 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. Bypassing Intermediate Nodes + + Because the 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. In + addition, a node inside an aggregation region will still wish to + ignore signaling messages that are per-flow, even if they are for a + signaling application that the node is generally able to process. + + + + + + + + + + + + +Hancock, et al. Informational [Page 13] + +RFC 4080 NSIS Framework June 2005 + + + +------+ +------+ +------+ +------+ + | NE | | NE | | NE | | NE | + |+----+| | | |+----+| |+----+| + ||NSLP|| | | ||NSLP|| ||NSLP|| + || 1 || | | || 2 || || 1 || + |+----+| | | |+----+| |+----+| + | || | | | | | | || | + |+----+| |+----+| |+----+| |+----+| + ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== + |+----+| |+----+| |+----+| |+----+| + +------+ +------+ +------+ +------+ + + Figure 5: Signaling with Heterogeneous NSLPs + + Where signaling messages traverse such NSIS-aware intermediate nodes, + it is desirable to process them at the lowest level possible (in + particular, on the fastest path). In order to offer a non-trivial + message transfer service (in terms of security, reliability and so + on) to the peer NSLP nodes, it is important that the NTLP at + 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 scaling benefits of aggregation, unless tunneling is used. + + Considering first the case of messages sent with the router alert + option, there are two complementary methods to achieve this bypassing + of intermediate NEs: + + o At the IP layer, a set of protocol numbers or a range of values in + the router alert option can be used. In this way, messages can be + marked with an implied granularity, and routers can choose to + apply further slow-path processing only to configured subsets of + messages. This is the method used in [10] to distinguish per-flow + and per-aggregate signaling. + + o The NTLP could process the message but determine that there was no + local signaling application it was relevant to. At this stage, + the message can be returned unchanged to the IP layer for normal + forwarding; the intermediate NE has effectively chosen to be + transparent to the message in question. + + In both cases, the existence of the intermediate NE is totally hidden + from the NSLP nodes. If later stages of the signaling use directly + addressed messages (e.g., for reverse routing), they will not involve + the intermediate NE at all, except perhaps as a normal router. + + + + + + +Hancock, et al. Informational [Page 14] + +RFC 4080 NSIS Framework June 2005 + + + There may be cases where the intermediate NE would like to do some + restricted protocol processing, such as the following: + + o Translating addresses in message payloads (compare Section 4.6.1); + note that this would have to be done to messages passing in both + directions through a node. + + o Updating signaling application payloads with local status + information (e.g., path property measurement inside a domain). + + If this can be done without fully terminating the NSIS protocols, it + would allow a more lightweight implementation of the intermediate NE, + and a more direct 'end-to-end' NTLP association between the peer + NSLPs where the signaling application is fully processed. On the + other hand, this is only possible with a limited class of possible + NTLP designs, and makes it harder for the NTLP to offer a security + service (since messages have to be partially protected). The + feasibility of this approach will be evaluated during the NTLP + design. + +3.2.4. Core NSIS Transport Layer Functionality + + This section describes the basic functionality to be supported by the + NTLP. Note that the overall signaling solution will always be the + result of joint operation of both the NTLP and the signaling layer + protocols (NSLPs); for example, we can always assume that an NSLP is + operating above the 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, in a wide variety of + network scenarios. Message delivery includes the act of locating + and/or selecting which NTLP peer to carry out signaling exchanges + with for a specific data flow. This discovery might be an active + process (using specific signaling packets) or a passive process (a + side effect of using a particular addressing mode). In addition, it + appears that the NTLP can sensibly carry out many of the functions + that enable signaling messages to pass through middleboxes, since + this is closely related to the problem of routing the signaling + messages in the first place. Further details about NTLP + functionality are contained in Sections 3.2.5 and 4.3. + + + + + + + + + + +Hancock, et al. Informational [Page 15] + +RFC 4080 NSIS Framework June 2005 + + +3.2.5. State Management Functionality + + Internet signaling requires the existence and management of state + within the network for several reasons. This section describes how + state management functionality is split across the NSIS layers. + (Note that how the NTLP internal state is managed is a matter for its + design and indeed implementation.) + + 1. Conceptually, the NTLP provides a uniform message delivery + service. It is unaware of the difference in state semantics + between different types of signaling application messages (e.g., + whether a message changes, 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 application messages "immediately". (It might offer + different service classes, but these would be distinguished by, + for example, reliability or priority, not by state aspects.) + This means that the NTLP does not know explicit timer or message + sequence information for the signaling application; and that + signaling application messages pass immediately through an + NSLP-unaware node. (Their timing cannot be jittered there, nor + can messages be stored up to be re-sent on a new path in case of + a later re-routing event.) + + 3. Within any node, it is an implementation decision whether to + generate/jitter/filter refreshes separately within each signaling + application that needs this functionality, or to integrate it + with the NTLP implementation as a generic "soft-state management + toolbox". The choice doesn't affect the NTLP specification at + all. Implementations might piggyback NTLP soft-state refresh + information (if the NTLP works this way) on signaling application + messages, or they might even combine soft-state management + between layers. The state machines of the NTLP and NSLPs remain + logically independent, but an implementation is free to allow + them to interact to reduce the load on the network to the same + level that would be achieved by a monolithic model. + + 4. It may be helpful for signaling applications to receive + state-management related 'triggers' from the NTLP indicating 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 another case + of route change detection/notification (which the NTLP is also + allowed to do anyway). However, apart from generating such + + + + + +Hancock, et al. Informational [Page 16] + +RFC 4080 NSIS Framework June 2005 + + + triggers, the NTLP takes no action itself on such events, other + than to ensure that subsequent signaling messages are routed + correctly. + + 5. The existence of these triggers doesn't replace NSLP refreshes as + the mechanism for maintaining liveness at the signaling + application level. In this sense, up/down notifications are + advisories that allow faster reaction to events in the network, + but that shouldn't be built into NSLP semantics. (This is + essentially the same distinction, with the same rationale, that + SNMP makes between notifications and normal message exchanges.) + +3.2.6. Path-Decoupled Operation + + Path-decoupled signaling is defined as signaling for state + installation along the data path, without the restriction of passing + only through nodes that are located on the data path. Signaling + messages can be routed to nodes that are off the data path, but that + are (presumably) aware of it. This allows a looser coupling between + signaling and data plane nodes (e.g., at the autonomous system + level). Although support for path-decoupled operation is not one of + the initial goals of the NSIS work, this section is included for + completeness and to capture some initial considerations for future + reference. + + The main advantages of path-decoupled signaling are ease of + deployment and support of additional functionality. The ease of + deployment comes from a restriction of the number of impacted nodes + in case of deployment and/or upgrade of an NSLP. Path-decoupled + signaling would allow, for instance, deploying a solution without + upgrading any of the routers in the data plane. Additional + functionality that can 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 two + signaling paradigms should be analyzed. Using a single centralized + off-path NE may increase the requirements in terms of message + handling; on 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 planes can no longer be assumed. + Furthermore, the interpretation of sender/receiver orientation + becomes less natural. With the local operation of the NTLP, the + impact of path-decoupled signaling on the routing of signaling + messages is presumably restricted to the problem of peer + determination. The assumption that the off-path NSIS nodes are + loosely tied to the data path suggests, however, that peer + determination can still be based on L3 routing information. This + + + +Hancock, et al. Informational [Page 17] + +RFC 4080 NSIS Framework June 2005 + + + means that a path-decoupled signaling solution could be implemented + 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 specifications and the inter-layer interaction would be + unchanged from the path-coupled case. + +3.3. Signaling Application Properties + + It is clear that many signaling applications will require specific + protocol behavior in their NSLP. This section outlines some of the + options for NSLP behavior; further work on selecting from these + options would depend on detailed analysis of the signaling + application in question. + +3.3.1. Sender/Receiver Orientation + + In some signaling applications, a node at one end of the data flow + takes responsibility for requesting special treatment (such as a + resource reservation) from the network. Which end may depend on the + signaling application, or on characteristics of the network + deployment. + + In a sender-initiated approach, 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 itself has no freedom in this + area: Next NTLP peers have to be discovered in the sender-to-receiver + direction, but after that the default assumption is that signaling is + possible both upstream and downstream (unless a signaling application + specifically indicates that this is not required). This implies that + backward routing state must be maintained by the NTLP or that + backward routing information must be available in the signaling + message. + + The sender- and receiver-initiated approaches have several + differences in their operational characteristics. The main ones are + as follows: + + o In a receiver-initiated approach, the signaling messages traveling + from the receiver to the sender must be backward routed such that + they follow exactly the same path as was followed by the signaling + messages belonging to the same flow traveling from the sender to + the receiver. In a sender-initiated approach, provided that + acknowledgements and notifications can be delivered securely to + the sending node, backward routing is not necessary, and nodes do + not have to maintain backward routing state. + + + + +Hancock, et al. Informational [Page 18] + +RFC 4080 NSIS Framework June 2005 + + + o In a sender-initiated approach, a mobile node can initiate a + reservation for its outgoing flows as soon as it has moved to + another roaming subnetwork. In a receiver-initiated approach, a + mobile node has to inform the receiver about its handover, thus + allowing the receiver to initiate a reservation for these flows. + For incoming flows, the reverse argument applies. + + o In general, setup and modification will be fastest if the node + responsible for authorizing these actions can initiate them + directly within the NSLP. A mismatch between authorizing and + initiating NEs will cause additional message exchanges, either in + the NSLP or in a protocol executed prior to NSIS invocation. + Depending on how the authorization for a particular signaling + application is done, this may favor either sender- or receiver- + initiated signaling. Note that this may complicate modification + of network control state for existing flows. + +3.3.2. Uni- and Bi-Directional Operation + + For some signaling applications and scenarios, signaling may only be + considered for a unidirectional data flow. However, in other cases, + there may be interesting relationships in the signaling between the + two flows of a bi-directional session; an example is QoS for a voice + call. Note that the path in the two directions may differ due to + asymmetric routing. In the basic case, bi-directional signaling 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 + may be possible to use a more unified approach to bi-directional + signaling; e.g., carrying the two signaling directions in common + messages. This optimization might be used for example to make mobile + QoS signaling more efficient. + + In either case, the correlation of the signaling for the two flow + directions is carried out in the NSLP. The NTLP would simply be + enabled to bundle the messages together. + +3.3.3. Heterogeneous Operation + + It is likely that the appropriate way to describe the state for which + NSIS is signaling will vary from one part of the network to another + (depending on the signaling application). For example, in the QoS + 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). + + + + + +Hancock, et al. Informational [Page 19] + +RFC 4080 NSIS Framework June 2005 + + + One way to address this issue is to consider the state description + used within the NSLP as carried in globally-understood objects and + locally-understood objects. The local objects are only applicable + for intra-domain signaling, while the global objects are mainly used + in inter-domain signaling. Note that the local objects are still + part of the protocol but are inserted, used, and removed by one + single domain. + + The purpose of this division is to provide additional flexibility in + defining the objects carried by the NSLP such that only the objects + applicable in a particular setting are used. One approach for + reflecting the distinction is that local objects could be put into + separate local messages that are initiated and terminated within one + single domain; an alternative is that they could be "stacked" within + the NSLP messages that are used anyway for inter-domain signaling. + +3.3.4. Aggregation + + It is a well-known problem that per-flow signaling in large-scale + networks presents scaling challenges because of the large number of + flows that may traverse individual nodes. + + The possibilities for aggregation at the level of the NTLP are quite + limited; the primary scaling approach for path-coupled signaling is + for a signaling application to group flows together and to perform + signaling for the aggregate, rather than for the flows individually. + The aggregate may be created in a number of ways; for example, the + individual flows may be sent down a tunnel, or given a common + Differentiated Services Code Point (DSCP) marking. The aggregation + and de-aggregation points perform per flow signaling, but nodes + within the aggregation region should only be forced to process + signaling messages for the aggregate. This depends on the ability of + the interior nodes to ignore the per-flow signaling as discussed in + Section 3.2.3. + + Individual NSLPs will need to specify what aggregation means in their + context, and how it should be performed. For example, in the QoS + context it is possible to add together the resources specified in a + number of separate reservations. In the case of other applications, + such as signaling to NATs and firewalls, the feasibility (and even + the meaning) of aggregation is less clear. + + + + + + + + + + +Hancock, et al. Informational [Page 20] + +RFC 4080 NSIS Framework June 2005 + + +3.3.5. Peer-Peer and End-End Relationships + + The assumption in this framework is that the NTLP will operate + 'locally'; that is, just over the scope of a single peer + relationship. End-to-end operation is built up by concatenating + these relationships. Non-local operation (if any) will take place in + NSLPs. + + The peering relations may also have an impact on the required amount + of state at each NSIS entity. When direct interaction with remote + peers is not allowed, it may be required to keep track of the path + that a message has followed through the network. This could be + achieved by keeping per-flow state at the NSIS entities, as is done + in RSVP. Another approach would be to maintain a record route object + in the messages; this object would be carried within the NSIS + protocols, rather than depend on the route-recording functionality + provided by the IP layer. + +3.3.6. Acknowledgements and Notifications + + We are assuming that the NTLP provides a simple message transfer + service, and that any 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 will be an NSLP function. + + Acknowledgements can be sent along the sequence of NTLP peer + relationships towards the signaling initiator, which relieves the + requirements on the security associations that need to be maintained + by NEs and that can allow NAT traversal in both directions. (If this + direction is towards the sender, it implies maintaining reverse + routing state in the NTLP.) In certain circumstances (e.g., trusted + domains), an optimization could be to send acknowledgements directly + to the signaling initiator outside the NTLP (see Section 3.2.2), + although any such approach would have to take into account the + necessity of handling denial of service attacks launched from outside + the network. + + The semantics of the acknowledgement messages are of particular + importance. An NE sending 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 could have a more local meaning, + indicating (for instance) that a certain failure or degradation + occurred at a particular point in the network. + + + +Hancock, et al. Informational [Page 21] + +RFC 4080 NSIS Framework June 2005 + + + Notifications differ from acknowledgements because they are not + (necessarily) generated in response to other signaling messages. + This means that it may not be obvious how to determine where the + notification should be sent. Other than that, the same + considerations apply as for acknowledgements. One useful distinction + to make would be to 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 sent + directly to the NE they are destined for (provided that this NE can + be determined). + +3.3.7. Security and Other AAA Issues + + In some cases, it will be possible to achieve the necessary level of + signaling security by using basic 'channel security' mechanisms [11] + at the level of 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 to apply + 'object security' to specific fields within the NSLP messages. + + In addition to authentication, the authorization (to manipulate + network control state) has to be considered as functionality above + the NTLP level, since it will be entirely application specific. + Indeed, authorization decisions may be handed off to a third party in + the protocol (e.g., for QoS, the resource management function as + described in Section 6.1.4). Many different authorization models are + possible, and the variations impact: + + o what message flows take place -- for example, whether + authorization information is carried along with a control state + modification request or is sent in the reverse direction in + response to it; + + o what administrative relationships are required -- for example, + whether authorization takes place only between peer signaling + applications, or over longer distances. + + Because the NTLP operates only between adjacent peers and places no + constraints on the direction or order in which signaling applications + can send messages, these authorization aspects are left open to be + defined by each NSLP. Further background discussion of this issue is + contained in [12]. + + + + + + + + +Hancock, et al. Informational [Page 22] + +RFC 4080 NSIS Framework June 2005 + + +4. The NSIS Transport Layer Protocol + + 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 and the layers above and below it are + identified, with a description of the identity elements that appear + on these interfaces. + + This discussion is not intended to design the NTLP 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 includes all functionality below the signaling application + layer and above the IP layer. The functionality that is required + within the NTLP is outlined in Section 3.2.4, with some more details + in Sections 3.2.5 and 4.3. + + Some NTLP functionality could be provided via components operating as + sublayers within the NTLP design. For example, if specific transport + capabilities are required (such as congestion avoidance, + retransmission, and security), then existing protocols (such as + TCP+TLS or DCCP+IPsec) could be incorporated into the NTLP. This + possibility is not required or excluded by this framework. + + If peer-peer addressing (Section 4.2) is used for some messages, then + active next-peer discovery functionality will be required within the + NTLP to support the explicit addressing of these messages. This + could use message exchanges for dynamic peer discovery as a sublayer + within the NTLP; there could also be 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 + + + +Hancock, et al. Informational [Page 23] + +RFC 4080 NSIS Framework June 2005 + + +4.2. Addressing + + There are two ways to address a signaling message being transmitted + between NTLP peers: + + o peer-peer, where the message is addressed to a neighboring NSIS + entity that is known to be closer to the destination NE. + + o 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 that the address of the destination NE + be derivable from the information present in the payload, either by + using some local routing table 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 to the + data flow receiver, and (some of) the NEs 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 + [2]). In addition, it is a matter of the protocol design what should + be used as the source address of the message (the flow source or + signaling source). + + 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., + + + +Hancock, et al. Informational [Page 24] + +RFC 4080 NSIS Framework June 2005 + + + 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, per 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 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 [13]) 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 the signaling application. Additional + transparent compression functionality could be added to the NTLP + design later as a local option.) Note that end-to-end addressed + messages for different flows cannot be bundled safely unless the + next node on the outgoing interface is known to be NSIS-aware. + + 2. When needed, message fragmentation should be provided by the + NTLP. The use of IP fragmentation for large messages may lead to + reduced reliability and may be incompatible with some addressing + schemes. Therefore, this functionality should be provided within + the NTLP as a service for NSLPs that generate large messages. + How the NTLP determines and accommodates Maximum Transmission + Unit (MTU) constraints is left as a matter of protocol design. + To avoid imposing the cost 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 applications if + state-changing messages are delivered reliably (as introduced in + [13] for RSVP; see also the more general analysis of [14]). This + does not change any assumption about the use of soft-state by + NSLPs to manage signaling application state, and it leaves the + responsibility for detecting and recovering from application + layer error conditions in the NSLP. However, it means that such + functionality does not need to be tuned to handle fast recovery + from message loss due to congestion or corruption in the lower + layers, and it also means that the NTLP can prevent the + + + +Hancock, et al. Informational [Page 25] + +RFC 4080 NSIS Framework June 2005 + + + amplification of message 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 network (i.e., at the IP layer). Congestion could be + caused by retransmission of lost signaling packets or by upper + layer actions (e.g., a flood of signaling updates to recover from + a route change). In some cases, it may be possible to engineer + the network to ensure that signaling cannot overload it; in + others, the NTLP would have to detect congestion and to adapt the + rate at which it allows signaling messages to be transmitted. + Principles of congestion control in Internet protocols are given + in [15]. 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 that cannot keep up with the incoming 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 signaling applications themselves + to adapt their behavior accordingly. + +4.4. Lower Layer Interfaces + + The NTLP interacts with 'lower layers' of the protocol stack for the + purposes of sending and receiving signaling messages. This framework + places the lower boundary of the NTLP at the IP layer. The interface + to the lower layer is therefore very simple: + + o The NTLP sends raw IP packets + + o The NTLP receives raw IP packets. 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 achieved by intercepting + packets that have been marked in some special way (by special + protocol number or by some option interpreted within the IP layer, + such as the router alert option). + + o The NTLP receives indications from the IP layer (including local + forwarding tables and routing protocol state) that provide some + information about route changes and similar events (see + Section 5.1). + + For correct message routing, the NTLP needs to have some information + about link and IP layer configuration of the local networking stack. + In general, it needs to know how to select the outgoing interface for + a signaling message and where this must match the interface that will + be used by the corresponding flow. This might be as simple as just + allowing the IP layer to handle the message using its own routing + + + +Hancock, et al. Informational [Page 26] + +RFC 4080 NSIS Framework June 2005 + + + 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 processing must account for this. Further network layer + information would be needed to handle scoped addresses (if such + things ever exist). + + Configuration of lower-layer operation to handle flows in particular + ways is handled by the signaling application. + +4.5. Upper Layer Services + + The NTLP offers transport-layer services to higher-layer signaling + applications for two purposes: sending and receiving signaling + messages, and exchanging control and feedback information. + + For sending and receiving messages, two basic control primitives are + required: + + o Send Message, to allow the signaling application to pass data to + the NTLP for transport. + + o Receive Message, to allow the NTLP to pass received data to the + signaling application. + + The NTLP and signaling application may also want to exchange other + control information, such as the following: + + o Signaling application registration/de-registration, so that + particular signaling application instances can register their + presence with the transport layer. This may also require some + identifier to be agreed upon between the NTLP and signaling + application to support the exchange of further control information + and to allow the de-multiplexing of incoming data. + + o 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 maintained. + + o Error messages, to allow the NTLP to indicate error conditions to + the signaling application, and vice versa. + + o Feedback information, such as route change indications so that the + signaling application can decide what action to take. + + + + + + +Hancock, et al. Informational [Page 27] + +RFC 4080 NSIS Framework June 2005 + + +4.6. Identity Elements + +4.6.1. Flow Identification + + The flow identification is a method of identifying a flow in a unique + way. All packets associated with the same flow will be identified by + the same flow identifier. The key aspect of the flow identifier is + to provide enough information such that the signaling flow receives + the same treatment along the data path as the 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: + + o source IP address; + + o destination IP address; + + o protocol identifier and higher layer (port) addressing; + + o flow label (typical for IPv6); + + o SPI field for IPsec encapsulated data; and + + o DSCP/TOS field. + + It is assumed that at most limited wildcarding on these identifiers + is needed. + + We assume here that the flow identification is not hidden within the + NSLP, but is explicitly part of the NTLP. The justification for this + is that being able to do NSIS processing, even at a node which was + unaware of the specific signaling application (see Section 3.2.3) + might be valuable. 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 in which being able to refer to signaling + application state independently of the underlying flow is important. + For example, if the address of one of the flow endpoints changes due + to a mobility event, it is desirable to be able to change the flow + identifier without having to install a completely new reservation. + The session identifier provides a method to correlate the signaling + about the different flows with the same network control state. + + + + + +Hancock, et al. Informational [Page 28] + +RFC 4080 NSIS Framework June 2005 + + + 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 here that + it should be visible within the NTLP. This enables it to be used to + control NTLP behavior; for example, by controlling how the transport + layer should forward packets belonging to this session (as opposed to + this signaling application). In addition, the session identifier can + be used by the NTLP to demultiplex received signaling messages + between multiple instances of the same signaling application, if such + an operational scenario is supported (see Section 4.6.3 for more + information on signaling 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 impossible to generate identifiers + in a way that guarantees this property; however, using a large random + number makes it highly likely. In any case, the NTLP ascribes no + valuable semantics to the identifier (such as 'session ownership'); + this problem is left to the signaling application, which may be able + to secure it to be used for this purpose. + +4.6.3. Signaling Application Identification + + Because the NTLP can be used to support several NSLP types, there is + a need to identify which type a particular signaling message exchange + is being used for. This is to support: + + o processing of incoming messages -- the NTLP should be able to + demultiplex these towards the appropriate signaling applications; + and + + o processing of general messages at an NSIS-aware intermediate node + -- if the node 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 the form of the signaling application + identifier, or even the structure of the signaling application + 'space': free-standing applications, potentially overlapping groups + of capabilities, etc. These details should not influence the rest of + the NTLP design. + + + + + + + + + + +Hancock, et al. Informational [Page 29] + +RFC 4080 NSIS Framework June 2005 + + +4.7. Security Properties + + It is assumed that the only security service required within the NTLP + is channel security. Channel security requires a security + association to be established between the signaling endpoints, which + is carried out via some authentication and key management exchange. + This functionality could be provided by reusing a standard protocol. + + In order to protect a particular signaling exchange, the NSIS entity + needs to select the security association that it has in place with + the next NSIS entity that will be receiving the signaling message. + The ease of doing this depends on the addressing model in use by the + NTLP (see Section 4.2). + + Channel security can provide many different types of protection to + signaling exchanges, including integrity and replay protection and + encryption. It is not clear which of these is required at the NTLP + layer, although most channel security mechanisms support them all. + It is also not clear how tightly an NSLP can 'bind' to the channel + security service provided by the NTLP. + + Channel security can also be applied to the signaling messages with + differing granularity; i.e., all or parts of the signaling message + may be protected. For example, if the flow is traversing a NAT, only + the parts of the message that do not need to be processed by the NAT + should be protected. (Alternatively, if the NAT takes part in NTLP + security procedures, it only needs to be given access to the message + fields containing addresses, often just the flow id.) Which parts of + the NTLP messages need protecting is an open question, as is what + type of protection should be applied to each. + +5. Interactions with Other Protocols + +5.1. IP Routing Interactions + + The NTLP is responsible for determining the next node to be visited + by the signaling protocol. For path-coupled signaling, this next + node should be one that will be visited by the data flow. In + practice, this peer discovery will be approximate, as any node could + use any feature of the peer discovery packet to route it differently + from the corresponding data flow packets. Divergence between the + data and signaling paths can occur due to load sharing or load + balancing (Section 5.1.1). An example specific to the case of QoS is + given in Section 6.1.1. Route changes cause a temporary divergence + between the data path and the path on which 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 QoS is given in Section 6.1.2. + + + +Hancock, et al. Informational [Page 30] + +RFC 4080 NSIS Framework June 2005 + + +5.1.1. Load Sharing and Policy-Based Forwarding + + Load sharing or load balancing is a network optimization technique + that exploits the existence of multiple paths to the same destination + in order to obtain benefits in terms of protection, resource + efficiency, or network stability. It has been proposed for a number + of routing protocols, such as OSPF [16] and others. In general, load + sharing means that packet forwarding will take into account header + fields in addition to the destination address; a general discussion + of such techniques and the problems they cause is provided in [17]. + + The significance of load sharing in the context of NSIS is that + routing of signaling messages using end-to-end addressing does not + guarantee that these messages will follow the data path. Policy- + based forwarding for data packets -- where the outgoing link is + selected based on policy information about fields additional to the + packet destination address -- has the same impact. Signaling and + data packets may diverge because of both of these techniques. + + If signaling packets are given source and destination addresses + identical to data packets, signaling and data may still diverge + because of layer-4 load balancing (based on protocol or port). Such + techniques would also cause ICMP errors to be misdirected to the + source of the data because of source address spoofing. If signaling + packets are made identical in the complete 5-tuple, divergence may + still occur because of the presence of router alert options. The + same ICMP misdirection applies, and it becomes difficult for the end + systems to distinguish between data and signaling packets. Finally, + QoS routing techniques may base the routing decision on any field in + the packet header (e.g., DSCP). + +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 + destination becomes available, this route is installed in the + forwarding table and will be used for all subsequent (data and + signaling) packets. This can cause a divergence between the path + along which state has been installed and the path along which + forwarding will actually take place. The problem of route changes is + reduced if route 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). + Nothing about NSIS signaling prevents route pinning from being used + as a network engineering technique, provided that it is done in a way + + + + + +Hancock, et al. Informational [Page 31] + +RFC 4080 NSIS Framework June 2005 + + + that preserves the common routing of signaling and data. However, + even if route pinning is used, it cannot be depended on to prevent + all route changes (for example, in the case of link failures). + + Handling route changes requires the presence of three processes in + the signaling protocol: + + 1. route change detection + + 2. installation of state on the new path + + 3. removal of state on the old path + + Many route change detection methods can be used, some needing + explicit protocol support, and some of which are implementation- + internal. They differ in their speed of reaction and in the types of + change they can detect. In rough order of increasing applicability, + they can be summarized as follows: + + 1. monitoring changes in local forwarding table state + + 2. monitoring topology changes in a link-state routing protocol + + 3. inference from changes in data packet TTL + + 4. inference from loss of packet stream in a flow-aware router + + 5. inference from changes in signaling packet TTL + + 6. changed route of an end-to-end addressed signaling packet + + 7. changed route of a specific end-to-end addressed probe packet + + These methods can be categorized as being based on network monitoring + (methods 1-2), on data packet monitoring (methods 3-4) and on + monitoring signaling protocol messages (methods 5-7); method 6 is the + baseline method of RSVP. The network monitoring methods can only + detect local changes; in particular, method 1 can only detect an + event that changes the immediate next downstream hop, and method 2 + can only detect changes within the scope of the link-state protocol. + Methods 5-7, which are 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 along the new path. It is not + guaranteed that the new path will be able to provide the same + characteristics that were available on the old path. To avoid + duplicate state installation or, worse, rejection of the signaling + + + +Hancock, et al. Informational [Page 32] + +RFC 4080 NSIS Framework June 2005 + + + message because of previously installed state, it is important to be + able to recognize the new signaling message as belonging to an + existing session. In this respect, we distinguish between route + changes with associated change of the flow identification (e.g., in + case of a mobility event when the IP source might change) and route + changes without change of the flow identification (e.g., in case of a + link failure along the path). The former case requires an identifier + independent from the flow identification; i.e., the session + identifier (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 existing state + on the old path needs to be removed. With the soft-state principle, + this will happen automatically because of the lack of refresh + messages. Depending on the refresh timer, however, it may be + required to tear 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 distinguish between the new path and the old + path. + + In some environments, it is desirable to provide connectivity and + per-flow or per-class state management with high-availability + characteristics; i.e., with rapid transparent recovery, even in the + presence of route changes. This may require interactions with + protocols that are used to manage the routing in this case, such as + Virtual Router Redundancy Protocol (VRRP) [18]. + + 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 consistently (in the same way as + the data traffic). However, further state re-synchronization + (including failover between 'main' and 'standby' nodes in the high + availability case) would be the responsibility of the signaling + application and its NSLP, and would possibly be 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 following extra + considerations arise: + + 1. The use of IP-layer mobility and multihoming means that more than + one IP source or destination address will be associated with a + single session. The same applies if application-layer solutions + (e.g., SIP-based approaches) are used. + + + +Hancock, et al. Informational [Page 33] + +RFC 4080 NSIS Framework June 2005 + + + 2. Mobile IP and associated protocols use some special + encapsulations for some segments of the data path. + + 3. The double route may persist for some time in the network (e.g., + in the case of a 'make-before-break' handover being done by a + multihomed host). + + 4. Conversely, the re-routing may be rapid and routine (unlike + network-internal route changes), increasing the importance of + rapid state release on old paths. + + The interactions between mobility and signaling have been extensively + analyzed in recent years, primarily in the context of RSVP and Mobile + IP interaction (e.g., the mobility discussion of [5]), but also in + that of other types of network (e.g., [19]). A general review of the + fundamental interactions is given in [20], which provides further + details on many of the subjects considered in this section. + + We assume that the signaling will refer to 'outer' IP headers when + defining the flows it is controlling. There are two main reasons for + this. The first is that the data plane will usually be unable to + work in terms of anything else when implementing per-flow treatment + (e.g., we cannot expect that a router will analyze inner headers to + decide how to schedule packets). The second reason is that we are + implicitly relying on the security provided by the network + infrastructure to ensure that the correct packets are given the + special treatment being signaled for, and this is built on the + relationship between packet source and destination addresses and + network topology. (This is essentially the same approach that is + used as the basis of route optimization security in Mobile IPv6 + [21].) The consequence of this assumption is that we see the packet + streams to (or from) different addresses as different flows. Where a + flow is carried inside a tunnel, it is seen as a different flow + again. The encapsulation issues (point (2) above) are therefore to + be handled the same way as other tunneling cases (Section 5.4). + + Therefore, the most critical aspect is that multiple flows are being + used, and the signaling for them needs to be correlated. This is the + intended role of the session identifier (see Section 4.6.2, which + also describes some of the security requirements for such an + identifier). Although the session identifier is visible at the NTLP, + the signaling application is responsible for performing the + correlation (and for doing so securely). The NTLP responsibility is + limited to delivering the signaling messages for each flow between + the correct signaling application peers. The locations at which the + correlation takes place are the end system and the signaling- + + + + + +Hancock, et al. Informational [Page 34] + +RFC 4080 NSIS Framework June 2005 + + + application-aware node in the network where the flows meet. (This + node is generally referred to as the "crossover router"; it can be + anywhere in the network.) + + Although much work has been done in the past on finding the crossover + router directly from information held in particular mobility + signaling protocols, the initial focus of NSIS work should be a + solution that is not tightly bound to any single mobility approach. + In other words, it should be possible to determine the crossover + router based on NSIS signaling. (This doesn't rule out the + possibility that some implementations may be able to do this + discovery faster; e.g., by being tightly integrated with local + mobility management protocols. This is directly comparable to + spotting route changes in fixed networks by being routing aware.) + + Note that the crossover router discovery may involve end-to-end + signaling exchanges (especially for flows towards the mobile or + multihomed node), which raises a latency concern. On the other hand, + end-to-end signaling will have been necessary in any case, at the + application level not only to communicate changed addresses, but also + to update packet classifiers along the path. It is a matter for + further analysis to decide how these exchanges could be combined or + carried out in parallel. + + On the shared part of the path, signaling is needed at least to + update the packet classifiers to include the new flow, although if + correlation with the existing flow is possible it should be possible + 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 the end hosts or the + crossover router) controls all these procedures depends on which + entities are authorized to carry out network state manipulations, so + this is therefore a matter of signaling application and NSLP design. + The approach may depend on the sender/receiver orientation of the + original signaling (see Section 3.3.1). In addition, in the mobility + case, the old path may no longer be directly accessible to the mobile + node; inter-access-router communication may be required to release + state in these circumstances. + + The frequency of handovers in some network types makes fast handover + support protocols desirable, for selecting the optimal access router + for handover (for example, [22]), and for transferring state + information to avoid having to regenerate it in the new access router + after handover (for example, [23]). Both of these procedures could + have strong interactions with signaling protocols. The access router + selection might depend on the network control state that could be + + + + + +Hancock, et al. Informational [Page 35] + +RFC 4080 NSIS Framework June 2005 + + + supported on the path through the new access router. Transfer of + signaling application state or NTLP/NSLP protocol state may be a + candidate for context transfer. + +5.3. Interactions with NATs + + Because at least some messages will almost inevitably contain + addresses and possibly higher-layer information as payload, we must + consider the interaction with address translation devices (NATs). + These considerations apply both to 'traditional' NATs of various + types (as defined in [24]) as well as some IPv4/v6 transition + mechanisms, such as Stateless IP/ICMP Translation (SIIT) [25]. + + 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 [26] 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 to be integrity protected. An + alternative conceptual approach is to consider the NAT functionality + 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 that 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). That case + 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. 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. + + + + + + +Hancock, et al. Informational [Page 36] + +RFC 4080 NSIS Framework June 2005 + + + It is assumed that the NSIS approach will be similar to that of [27], + 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 a new data flow in its own right, and NSIS signaling is + applied to it recursively. 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), the + ability to provide a binding between the original flow identification + and that for the tunneled flow is needed. It is left open here + whether this should be an NTLP or an NSLP function. + +6. Signaling Applications + + This section gives 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 includes simple examples that + are intended to clarify how NSLPs fit into the framework. It does + not replace or even form part of the formal NSLP protocol + specifications; in particular, initial designs are being developed + for NSLPs for resource reservation [28] and middlebox communication + [29]. + +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: + + o QoS NSIS Initiator (QNI): the signaling entity that makes the + resource request, usually as a result of user application request. + + o QoS NSIS Responder (QNR): the signaling entity that acts as the + endpoint for the signaling and that can optionally interact with + applications as well. + + o QoS NSIS Forwarder (QNF): a signaling entity between a QNI and QNR + that propagates NSIS signaling further through the network. + + + + +Hancock, et al. Informational [Page 37] + +RFC 4080 NSIS Framework June 2005 + + + Each of these entities will interact with a resource management + function (RMF) that 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 QNI role: With respect to the data flow direction, it + could be at the sending or receiving end. + +6.1.1. Protocol Message Semantics + + The QoS NSLP will include a set of messages to carry out resource + reservations along the signaling path. A possible set of message + semantics for the QoS NSLP is shown below. Note that the 'direction' + column in the table below only indicates the 'orientation' of the + message. Messages can be originated and absorbed at QNF nodes as + well as the QNI or QNR; an example might be QNFs at the edge of a + domain exchanging messages to set up resources for a flow across a + it. Note that it is 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 it is one + possible state management mechanism (see next section). + + +-----------+-----------+-------------------------------------------+ + | Operation | Direction | Operation | + +-----------+-----------+-------------------------------------------+ + | Request | I-->R | Create a new reservation for a flow | + | | | | + | Modify | I-->R | Modify an existing reservation | + | | (&R-->I?) | | + | | | | + | Release | I-->R | Delete (tear down) an existing | + | | (&R-->I?) | reservation | + | | | | + | Accept/ | R-->I | Confirm (possibly modified?) or reject a | + | Reject | | reservation request | + | | | | + | Notify | I-->R & | Report an event detected within the | + | | R-->I | network | + | | | | + | Refresh | I-->R | State management (see Section 6.1.2) | + +-----------+-----------+-------------------------------------------+ + + + + + + +Hancock, et al. Informational [Page 38] + +RFC 4080 NSIS Framework June 2005 + + +6.1.2. State Management + + The primary 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: + + o 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 [30] or RMD [31] (per 'class' state), + respectively. + + o The protocol must be robust against failure and other conditions + that 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.5, 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. Route Changes and QoS Reservations + + In this section, we will explore the expected interaction between + resource signaling and routing updates (the precise source of routing + 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 +-----+ + =========>| QNF |===========>| QNF | + +-----+ +-----+ + ---------------------------------------> + data path + + Figure 7: Normal NSIS Protocol Operation + + + + + + +Hancock, et al. Informational [Page 39] + +RFC 4080 NSIS Framework June 2005 + + + A route change can occur while such a reservation is in place. The + route change will be installed immediately, and any data will be + forwarded on the new path. This situation is depicted Figure 8. + + 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, and certain delay or + drop-sensitive applications will require that this time interval be + minimized. Several techniques to achieve this could be considered. + As an example, RSVP [7] has the concept of local repair, whereby 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 QNF. Another approach would be to + pre-install backup state, and it would be the responsibility of the + QoS-NSLP to do this. However, mechanisms for identifying backup + paths and routing the necessary signaling messages along them are not + currently considered in the NSIS requirements and framework. + + Route update + | + v + reserved +-----+ reserved +-----+ + =========>| QNF |===========>| QNF | + +-----+ +-----+ + -------- || + \ || +-----+ + | ===========>| QNF | + | +-----+ + +---------------------------> + data path + + Figure 8: Route Change + + The new path might not be able to provide the same guarantees that + were available on the old path. Therefore, it might be desirable for + the QNF to wait until resources have been reserved on the new path + before allowing the route change to be installed (unless, of course, + the old path no longer exists). However, delaying the route change + installation while waiting for reservation setup needs careful + analysis of the interaction with the routing protocol being used, in + order to avoid routing loops. + + Another example related to route changes is denoted as severe + congestion and is explained in [31]. This solution adapts to a route + change when a route change creates congestion on the new routed path. + + + + +Hancock, et al. Informational [Page 40] + +RFC 4080 NSIS Framework June 2005 + + +6.1.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, 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). Note, 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 + specialized intra-domain QoS signaling (running between just the + edges of the network). (See [10], [32], and [33] 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 a QNF (note that + co-location with a QNI/QNR can be handled logically as a combination + between QNF and QNI/QNR). To cater for both cases, we define a + (possibly logical) QNF-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 QNF 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 using more global information, with more + + + +Hancock, et al. Informational [Page 41] + +RFC 4080 NSIS Framework June 2005 + + + 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 develop NSLPs for other signaling applications that + 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 + [4]. Other examples include network monitoring and testing, and + tunnel endpoint discovery. + +7. Security Considerations + + This document describes a framework for signaling protocols that + 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, apart from being resistant to denial of service attacks against + itself, the main role of the NTLP will be to provide message + protection over the scope of a single peer relationship, between + adjacent signaling application 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 ideally be provided by an + existing channel security mechanism, preferably using an external key + management mechanism based on mutual authentication. Examples of + possible mechanisms are TLS, IPsec and SSH. However, there are + interactions between the actual choice of security protocol and the + rest of the NTLP design. Primarily, most existing channel security + mechanisms require explicit identification of the peers involved at + the network and/or transport level. This conflicts with those + aspects of path-coupled signaling operation (e.g., discovery) where + this information is not even implicitly available because peer + identities are unknown; the impact of this 'next-hop problem' on RSVP + design is discussed in the security properties document [6] and also + influences many parts of the threat analysis [2]. Therefore, this + framework does not mandate the use of any specific channel security + protocol; instead, this has to be integrated with the design of the + NTLP as a whole. + + + + + + +Hancock, et al. Informational [Page 42] + +RFC 4080 NSIS Framework June 2005 + + + 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 authorization requirements of the signaling application. + Authorization 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 authorization + aspects. This complicates the analysis 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 the network as well. + + Further work on this and other security design will depend on a + refinement of the NSIS threats work begun in [2]. + +8. References + +8.1. Normative References + + [1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, + April 2004. + + [2] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next + Steps in Signaling (NSIS)", RFC 4081, June 2005. + + [3] Chaskar, H., "Requirements of a Quality of Service (QoS) + Solution for Mobile IP", RFC 3583, September 2003. + + [4] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, + "Middlebox Communications (midcom) Protocol Requirements", + RFC 3304, August 2002. + + + + + + +Hancock, et al. Informational [Page 43] + +RFC 4080 NSIS Framework June 2005 + + +8.2. Informative References + + [5] Manner, J. and X. Fu, "Analysis of Existing Quality of Service + Signaling Protocols", Work in Progress, December 2004. + + [6] Tschofenig, H., "RSVP Security Properties", Work in Progress, + February 2005. + + [7] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, + "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional + Specification", RFC 2205, September 1997. + + [8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. + + [9] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", + RFC 2711, October 1999. + + [10] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, + "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, + September 2001. + + [11] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on + Security Considerations", BCP 72, RFC 3552, July 2003. + + [12] Tschofenig, H., "NSIS Authentication, Authorization and + Accounting Issues", Work in Progress, March 2003. + + [13] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. + Molendini, "RSVP Refresh Overhead Reduction Extensions", + RFC 2961, April 2001. + + [14] Ji, P., Ge, Z., Kurose, J., and D. Townsley, "A Comparison of + Hard-State and Soft-State Signaling Protocols", Computer + Communication Review, Volume 33, Number 4, October 2003. + + [15] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, + September 2000. + + [16] Apostolopoulos, G., Kamat, S., Williams, D., Guerin, R., Orda, + A., and T. Przygienda, "QoS Routing Mechanisms and OSPF + Extensions", RFC 2676, August 1999. + + [17] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and + Multicast Next-Hop Selection", RFC 2991, November 2000. + + [18] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC + 3768, April 2004. + + + + +Hancock, et al. Informational [Page 44] + +RFC 4080 NSIS Framework June 2005 + + + [19] Heijenk, G., Karagiannis, G., Rexhepi, V., and 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. + + [20] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth, + E., and Y. Khouaja, "Evaluation of Mobility and QoS + Interaction", Computer Networks Volume 38, Issue 2, p. 137-163, + 5 February 2002. + + [21] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in + IPv6", RFC 3775, June 2004. + + [22] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and + E. Shim, "Candidate Access Router Discovery (CARD)", Work in + Progress, May 2005. + + [23] Kempf, J., "Problem Description: Reasons For Performing Context + Transfers Between Nodes in an IP Access Network", RFC 3374, + September 2002. + + [24] Srisuresh, P. and M. Holdrege, "IP Network Address Translator + (NAT) Terminology and Considerations", RFC 2663, August 1999. + + [25] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", + RFC 2765, February 2000. + + [26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN + - Simple Traversal of User Datagram Protocol (UDP) Through + Network Address Translators (NATs)", RFC 3489, March 2003. + + [27] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP + Operation Over IP Tunnels", RFC 2746, January 2000. + + [28] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for + Quality-of-Service signaling", Work in Progress, February 2005. + + [29] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol + (NSLP)", Work in Progress, February 2005. + + [30] Braden, R., Clark, D., and S. Shenker, "Integrated Services in + the Internet Architecture: an Overview", RFC 1633, June 1994. + + + + + + + + +Hancock, et al. Informational [Page 45] + +RFC 4080 NSIS Framework June 2005 + + + [31] Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., + Partain, D., Pop, O., Rexhepi, V., Szabo, R., and A. Takacs, + "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. + + [32] Ferrari, D., Banerjea, A., and H. Zhang, "Network Support for + Multimedia - A Discussion of the Tenet Approach", + Berkeley TR-92-072, November 1992. + + [33] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit + Differentiated Services Architecture for the Internet", + RFC 2638, July 1999. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hancock, et al. Informational [Page 46] + +RFC 4080 NSIS Framework June 2005 + + +Appendix A. Contributors + + Several parts of the introductory sections of this document (in + particular, in Sections 3.1 and 3.3) are based on contributions from + Ilya Freytsis, then of Cetacean Networks, Inc. + + Bob Braden originally proposed "A Two-Level Architecture for Internet + Signalling" as an Internet-Draft in November 2001. This document + served as an important starting point for the framework discussed + herein, and the authors owe a debt of gratitude to Bob for this + proposal. + +Appendix B. Acknowledgements + + 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 document. 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, Kim Hui, 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. Dave Oran, Michael Richardson, and + Alex Zinin provided valuable comments during the final review stages. + + + + + + + + + + + + + + + + + + + + + + + + + +Hancock, et al. Informational [Page 47] + +RFC 4080 NSIS Framework June 2005 + + +Authors' Addresses + + Robert Hancock + Siemens/Roke Manor Research + Old Salisbury Lane + Romsey, Hampshire SO51 0ZN + UK + + EMail: robert.hancock@roke.co.uk + + + Georgios Karagiannis + University of Twente + P.O. BOX 217 + 7500 AE Enschede + The Netherlands + + EMail: g.karagiannis@ewi.utwente.nl + + + John Loughney + Nokia Research Center + 11-13 Itamerenkatu + Helsinki 00180 + Finland + + EMail: john.loughney@nokia.com + + + Sven Van den Bosch + Alcatel + Francis Wellesplein 1 + B-2018 Antwerpen + Belgium + + EMail: sven.van_den_bosch@alcatel.be + + + + + + + + + + + + + + + +Hancock, et al. Informational [Page 48] + +RFC 4080 NSIS Framework June 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Hancock, et al. Informational [Page 49] + |