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
Section 5.1.1 on this point). Note that securing messages sent this way raises some interesting security issues (these are discussed in ). 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.
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 ) 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  for RSVP; see also the more general analysis of ). 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
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 . 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. 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
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.
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.
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.
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. 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.
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 . 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).
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
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) . 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.
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 ), but also in that of other types of network (e.g., ). A general review of the fundamental interactions is given in , 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 .) 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-
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, ), and for transferring state information to avoid having to regenerate it in the new access router after handover (for example, ). 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
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. 24]) as well as some IPv4/v6 transition mechanisms, such as Stateless IP/ICMP Translation (SIIT) . In the simplest case of an NSIS-unaware NAT in the path, payloads will be uncorrected, and signaling will refer to the flow incorrectly. Applications could attempt to use STUN  or similar techniques to detect and recover from the presence of the NAT. Even then, NSIS protocols would have to use a well-known encapsulation (TCP/UDP/ICMP) to avoid being dropped by more cautious low-end NAT devices. A simple 'NSIS-aware' NAT would require flow identification information to be in the clear and not 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.
It is assumed that the NSIS approach will be similar to that of , where the signaling for the end-to-end data flow is tunneled along with that data flow and is invisible to nodes along the path of the tunnel (other than the endpoints). This provides backwards compatibility with networks where the tunnel endpoints do not support the NSIS protocols. We assume that NEs will not unwrap tunnel encapsulations to find and process tunneled signaling messages. To signal for the packets carrying the tunneled data, the tunnel is considered 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. 28] and middlebox communication . 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.
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. Section 6.1.2) | +-----------+-----------+-------------------------------------------+
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  or RMD  (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. Figure 7, where the reserved resources match the data path. reserved +-----+ reserved +-----+ =========>| QNF |===========>| QNF | +-----+ +-----+ ---------------------------------------> data path Figure 7: Normal NSIS Protocol Operation
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  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 . This solution adapts to a route change when a route change creates congestion on the new routed path.
10], , and  for a discussion of similar architectures.) Given that NSIS signaling is already supposed to be able to support multiple instances of NSLPs for a given flow and limited scope (e.g., edge-to-edge) operation, it is not currently clear that supporting the multi-level model leads to any new protocol requirements for the QoS NSLP. The RMF may or may not be co-located with 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
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. 4]. Other examples include network monitoring and testing, and tunnel endpoint discovery. 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  and also influences many parts of the threat analysis . 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.
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 .  Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.  Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.  Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3583, September 2003.  Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002.
 Manner, J. and X. Fu, "Analysis of Existing Quality of Service Signaling Protocols", Work in Progress, December 2004.  Tschofenig, H., "RSVP Security Properties", Work in Progress, February 2005.  Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.  Katz, D., "IP Router Alert Option", RFC 2113, February 1997.  Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.  Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.  Tschofenig, H., "NSIS Authentication, Authorization and Accounting Issues", Work in Progress, March 2003.  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.  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.  Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.  Apostolopoulos, G., Kamat, S., Williams, D., Guerin, R., Orda, A., and T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC 2676, August 1999.  Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.  Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.
 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.  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.  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.  Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", Work in Progress, May 2005.  Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002.  Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.  Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.  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.  Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.  Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service signaling", Work in Progress, February 2005.  Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, February 2005.  Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
 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.  Ferrari, D., Banerjea, A., and H. Zhang, "Network Support for Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92-072, November 1992.  Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.
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.
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- firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.