diff options
Diffstat (limited to 'doc/rfc/rfc4094.txt')
| -rw-r--r-- | doc/rfc/rfc4094.txt | 2523 |
1 files changed, 2523 insertions, 0 deletions
diff --git a/doc/rfc/rfc4094.txt b/doc/rfc/rfc4094.txt new file mode 100644 index 0000000..aa40abd --- /dev/null +++ b/doc/rfc/rfc4094.txt @@ -0,0 +1,2523 @@ + + + + + + +Network Working Group J. Manner +Request for Comments: 4094 X. Fu +Category: Informational May 2005 + + + Analysis of Existing Quality-of-Service Signaling Protocols + +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 + + This document reviews some of the existing Quality of Service (QoS) + signaling protocols for an IP network. The goal here is to learn + from them and to avoid common misconceptions. Further, we need to + avoid mistakes during the design and implementation of any new + protocol in this area. + +Table of Contents + + 1. Introduction ....................................................3 + 2. RSVP and RSVP Extensions ........................................4 + 2.1. Basic Design ...............................................4 + 2.1.1. Signaling Model .....................................4 + 2.1.2. Soft State ..........................................5 + 2.1.3. Two-Pass Signaling Message Exchanges ................5 + 2.1.4. Receiver-Based Resource Reservation .................5 + 2.1.5. Separation of QoS Signaling from Routing ............5 + 2.2. RSVP Extensions ............................................6 + 2.2.1. Simple Tunneling ....................................6 + 2.2.2. IPsec Interface .....................................6 + 2.2.3. Policy Interface ....................................6 + 2.2.4. Refresh Reduction ...................................7 + 2.2.5. RSVP over RSVP ......................................8 + 2.2.6. IEEE 802-Style LAN Interface ........................8 + 2.2.7. ATM Interface .......................................9 + 2.2.8. DiffServ Interface ..................................9 + 2.2.9. Null Service Type ...................................9 + 2.2.10. MPLS Traffic Engineering ..........................10 + 2.2.11. GMPLS and RSVP-TE .................................11 + + + + +Manner & Fu Informational [Page 1] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + 2.2.12. GMPLS Operation at UNI and E-NNI Reference + Points ............................................12 + 2.2.13. MPLS and GMPLS Future Extensions ..................12 + 2.2.14. ITU-T H.323 Interface .............................13 + 2.2.15. 3GPP Interface ....................................13 + 2.3. Extensions for New Deployment Scenarios ...................14 + 2.4. Conclusion ................................................15 + 3. RSVP Transport Mechanism Issues ................................16 + 3.1. Messaging Reliability .....................................16 + 3.2. Message Packing ...........................................17 + 3.3. MTU Problem ...............................................17 + 3.4. RSVP-TE vs. Signaling Protocol for RT Applications ........18 + 3.5. What Would Be a Better Alternative? .......................18 + 4. RSVP Protocol Performance Issues ...............................19 + 4.1. Processing Overhead .......................................19 + 4.2. Bandwidth Consumption .....................................20 + 5. RSVP Security and Mobility .....................................21 + 5.1. Security ..................................................21 + 5.2. Mobility Support ..........................................22 + 6. Other QoS Signaling Proposals ..................................23 + 6.1. Tenet and ST-II ...........................................23 + 6.2. YESSIR ....................................................24 + 6.2.1. Reservation Functionality ..........................24 + 6.2.2. Conclusion .........................................25 + 6.3. Boomerang .................................................25 + 6.3.1. Reservation Functionality ..........................25 + 6.3.2. Conclusions ........................................26 + 6.4. INSIGNIA ..................................................26 + 7. Inter-Domain Signaling .........................................27 + 7.1. BGRP ......................................................27 + 7.2. SICAP .....................................................27 + 7.3. DARIS .....................................................28 + 8. Security Considerations ........................................30 + 9. Summary ........................................................30 + 10. Contributors ..................................................31 + 11. Acknowledgements ..............................................31 + 12. Appendix A: Comparison of RSVP to the NSIS Requirements .......32 + 13. Normative References ..........................................38 + 14. Informative References ........................................38 + + + + + + + + + + + + +Manner & Fu Informational [Page 2] + +RFC 4094 Analysis of QoS Signaling May 2005 + + +1. Introduction + + This document reviews some of the existing QoS signaling protocols + for an IP network. The goal here is to learn from them and to avoid + common misconceptions. Further, we need to avoid mistakes during the + design and implementation of any new protocol in this area. + + There have been a number of historic attempts to deliver QoS or + generic signaling to the Internet. In the early years, it was + believed that multicast would be popular for the majority of + communications; thus, both RSVP and earlier ST-II were designed in a + way that is multicast-oriented. + + ST-II was developed as a reservation protocol for point-to-multipoint + communication. However, since it is sender-initiated, it does not + scale with the number of receivers in a multicast group. Its + processing is fairly complex. Since every sender needs to set up its + own reservation, the total amount of reservation states is large. + RSVP was then designed to provide support for multipoint-to- + multipoint reservation setup in a more efficient way. However, its + complexity, scalability, and ability to meet new requirements have + been criticized. + + YESSIR (YEt another Sender Session Internet Reservations) [PS98] and + Boomerang [FNM+99] are examples of protocols designed after RSVP. + Both were meant to be simpler than RSVP. YESSIR is an extension to + RTCP, whereas Boomerang is used with ICMP. + + Previously, a lot of work has been targeted at creating a new + signaling protocol for resource control. Istvan Cselenyi suggested + having a QoSSIG BOF in IETF47, for identifying problems in QoS + signaling, but failed to get enough support [URL1]. Some people + argued, "in many ways, RSVP improved upon ST-2, and it did start out + simpler, but it resulted in a design with complexity and + scalability", while others thought that "new knowledge and + requirements" made RSVP insufficient. Some concluded that there is + no simpler way to handle the same problem than RSVP. + + Michael Welzl organized a special session "ABR to the Internet" in + SCI 2001, and gathered some inputs for requesting an "ABR to the + Internet" BOF in IETF#51, which was intended to introduce explicit + rate-feedback-related mechanisms for the Internet (e2e, edge2edge). + This failed because of "missing community interest". + + OPENSIG [URL2] has been involved in the Internet signaling for years. + Ping Pan initiated a SIGLITE [URL3] BOF mailing list to investigate + lightweight Internet signaling. Finally, NSIS BOF was successful, + and the NSIS WG was formed. + + + +Manner & Fu Informational [Page 3] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + The most mature and original protocols are presented in their own + sections, and other QoS signaling protocols are presented in later + subsections. The presented protocols are chosen based on relevance + to the work within NSIS. The aim is not to review every existing + protocol. + +2. RSVP and RSVP Extensions + + RSVP (the Resource Reservation Protocol) [ZDSZ93] [RFC2205] [BEBH96] + has evolved from ST-II to provide end-to-end QoS signaling services + for application data streams. Hosts use RSVP to request a specific + quality of service (QoS) from the network for particular application + flows. Routers use RSVP to deliver QoS requests to all routers along + the data path. RSVP also can maintain and refresh states for a + requested QoS application flow. + + By original design, RSVP fits well into the framework of the + Integrated Services (IntServ) [RFC2210] [BEBH96] with certain + modularity and scalability. + + RSVP carries QoS signaling messages through the network, visiting + each node along the data path. To make a resource reservation at a + node, the RSVP module communicates with two local decision modules, + admission control and policy control. Admission control determines + whether the node has sufficient available resources to supply the + requested QoS. Policy control provides authorization for the QoS + request. If either check fails, the RSVP module returns an error + notification to the application process that originated the request. + If both checks succeed, the RSVP module sets parameters in a packet + classifier and packet scheduler to obtain the desired QoS. + +2.1. Basic Design + + The design of RSVP distinguished itself by a number of fundamental + ways; particularly, soft state management, two-pass signaling message + exchanges, receiver-based resource reservation, and separation of QoS + signaling from routing. + +2.1.1. Signaling Model + + The RSVP signaling model is based on a special handling of multicast. + The sender of a multicast flow advertises the traffic characteristics + periodically to the receivers via "Path" messages. Upon receipt of + an advertisement, a receiver may generate a "Resv" message to reserve + resources along the flow path from the sender. Receiver reservations + may be heterogeneous. To accommodate the multipoint-to-multipoint + multicast applications, RSVP was designed to support a vector of + reservation attributes called the "style". A style describes whether + + + +Manner & Fu Informational [Page 4] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + all senders of a multicast group share a single reservation and which + receiver is applied. The "Scope" object additionally provides the + explicit list of senders. + +2.1.2. Soft State + + Because the number of receivers in a multicast flow is likely to + change, and the flow of delivery paths might change during the life + of an application flow, RSVP takes a soft-state approach in its + design, creating and removing the protocol states (Path and Resv + states) in routers and hosts incrementally over time. RSVP sends + periodic refresh messages (Path and Resv) to maintain its states and + to recover from occasional lost messages. In the absence of refresh + messages, the RSVP states automatically time out and are deleted. + States may also be deleted explicitly by PathTear, PathErr with + Path_State_Removed flag, or ResvTear Message. + +2.1.3. Two-Pass Signaling Message Exchanges + + The receiver in an application flow is responsible for requesting the + desired QoS from the sender. To do this, the receiver issues an RSVP + QoS request on behalf of the local application. The request + propagates to all routers in reverse direction of the data paths + toward the sender. In this process, RSVP requests might be merged, + resulting in a protocol that scales well when there are a large + number of receivers. + +2.1.4. Receiver-Based Resource Reservation + + Receiver-initiation is critical for RSVP to set up multicast sessions + with a large number of heterogeneous receivers. A receiver initiates + a reservation request at a leaf of the multicast distribution tree, + traveling toward the sender. Whenever a reservation is found to + already exist in a node in the distribution tree, the new request + will be merged with the existing reservation. This could result in + fewer signaling operations for the RSVP nodes in the multicast tree + close to the sender but could introduce a restriction to receiver- + initiation. + +2.1.5. Separation of QoS Signaling from Routing + + RSVP messages follow normal IP routing. RSVP is not a routing + protocol, but rather is designed to operate with current and future + unicast and multicast routing protocols. The routing protocols are + responsible for choosing the routes to use to forward packets, and + RSVP consults local routing tables to obtain routes. RSVP is + responsible only for reservation setup along a data path. + + + + +Manner & Fu Informational [Page 5] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + A number of messages and objects have been defined for the protocol. + A detailed description is given in [RFC2205]. + +2.2. RSVP Extensions + + RSVP [RFC2205] was originally designed to support real-time + applications over the Internet. Over the past several years, the + demand for multicast-capable real-time teleconferencing, which many + people had envisioned to be one of the key Internet applications that + could benefit from network-wide deployment of RSVP, has never + materialized. Instead, RSVP-TE [RFC3209], a RSVP extension for + traffic engineering, has been widely deployed by a large number of + network providers to support MPLS applications. + + There are a large number of protocol extensions based on RSVP. Some + provide additional features, such as security and scalability, to the + original protocol. Some introduce additional interfaces to other + services, such as DiffServ. And some simply define new applications, + such as MPLS and GMPLS, that are completely irrelevant from + protocol's original intent. + + In this section, we list only IETF-based RFCs and a limited set of + other organizations' specifications. Informational RFCs (e.g., + RFC2998 [RFC2998]) and work-in-progress I-Ds (e.g., proxy) are not + covered here. + +2.2.1. Simple Tunneling + + [RFC2746] describes an IP tunneling enhancement mechanism that allows + RSVP to make reservations across all IP-in-IP tunnels, basically by + recursively applying RSVP over the tunnel portion of the path. + +2.2.2. IPsec Interface + + RSVP can support IPsec on a per-address, per-protocol basis instead + of on a per flow basis. [RFC2207] extends RSVP by using the IPsec + Security Parameter Index (SPI) in place of the UDP/TCP-like ports. + This introduces a new FILTER_SPEC object, which contains the IPsec + SPI, and a new SESSION object. + +2.2.3. Policy Interface + + [RFC2750] specifies the format of POLICY_DATA objects and RSVP's + handling of policy events. It introduces objects that are + interpreted only by policy-aware nodes (PEPs) that interact with + policy decision points (PDPs). Nodes that are unable to interpret + the POLICY_DATA objects are called policy-ignorant nodes (PINs). The + + + + +Manner & Fu Informational [Page 6] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + content of the POLICY_DATA object itself is protected only between + PEPs and therefore provides end-to-middle or middle-to-middle + security. + + [RFC2749] specifies the usage of COPS policy services in RSVP + environments. [RFC3181] specifies a preemption priority policy + element (PREEMPTION_PRI) for use by RSVP POLICY_DATA Object. + [RFC3520] describes how authorization provided by a separate protocol + (such as SIP) can be reused with the help of an authorization token + within RSVP. The token might therefore contain either the authorized + information itself (e.g., QoS parameters) or a reference to those + values. The token might be unprotected (which is strongly + discouraged) or protected based on symmetric or asymmetric + cryptography. Moreover, the document describes how to provide the + host with encoded session authorization information as a POLICY_DATA + object. + +2.2.4. Refresh Reduction + + [RFC2961] describes mechanisms to reduce processing overhead + requirements of refresh messages, eliminate the state synchronization + latency incurred when an RSVP message is lost, and refresh state + without the transmission of whole refresh messages. It defines the + following objects: MESSAGE_ID, MESSAGE_ID_ACK, MESSAGE_ID_NACK, + MESSAGE_ID LIST, MESSAGE_ID SRC_LIST, and MESSAGE_ID MCAST_LIST + objects. Three new RSVP message types are defined: + + 1) Bundle messages consist of a bundle header followed by a body + consisting one or more standard RSVP messages. Bundle messages + help in scaling RSVP to reduce processing overhead and bandwidth + consumption. + + 2) ACK messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK + objects. ACK messages are sent between neighboring RSVP nodes to + detect message loss and to support reliable RSVP message delivery + on a per-hop basis. + + 3) Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID + SRC_LIST, and MESSAGE_ID MCAST_LIST objects. They correspond to + Path and Resv messages that establish the states. Srefresh + messages are used to refresh RSVP states without transmitting + standard Path or Resv messages. + + + + + + + + + +Manner & Fu Informational [Page 7] + +RFC 4094 Analysis of QoS Signaling May 2005 + + +2.2.5. RSVP over RSVP + + [RFC3175] allows installation of one or more aggregated reservations + in an aggregation region; thus, the number of individual RSVP + sessions can be reduced. The protocol type is swapped from RSVP to + RSVP-E2E-IGNORE in E2E (standard) Path, PathTear, and ResvConf + messages when they enter the aggregation region, and is swapped back + when they leave. In addition to a new PathErr code + (NEW_AGGREGATE_NEEDED), three new objects are introduced: + + 1) SESSION object, which contains two values: the IP Address of the + aggregate session destination, and the Differentiated Services + Code Point (DSCP) that it will use on the E2E data the reservation + contains. + + 2) SENDER_TEMPLATE object, which identifies the aggregating router + for the aggregate reservation. + + 3) FILTER_SPEC object, which identifies the aggregating router for + the aggregate reservation, and is syntactically identical to the + SENDER_TEMPLATE object. + + From the perspective of RSVP signaling and the handling of data + packets in the aggregation region, these cases are equivalent to that + of aggregating E2E RSVP reservations. The only difference is that + E2E RSVP signaling does not take place and cannot therefore be used + as a trigger, so some additional knowledge is required for setting up + the aggregate reservation. + +2.2.6. IEEE 802-Style LAN Interface + + [RFC2814] introduces an RSVP LAN_NHOP address object that keeps track + of the next L3 hop as the PATH message traverses an L2 domain between + two L3 entities (RSVP PHOP and NHOP nodes). Both layer-2 and layer-3 + addresses are included in the LAN_NHOP; the RSVP_HOP_L2 object is + used to include the Layer-2 address (L2ADDR) of the previous hop, + complementing the L3 address information included in the RSVP_HOP + object (RSVP_HOP_L3 address). + + To provide sufficient information for debugging or resource + management, RSVP diagnostic messages (DREQ and DREP) are defined in + [RFC2745] to collect and report RSVP state information along the path + from a receiver to a specific sender. + + + + + + + + +Manner & Fu Informational [Page 8] + +RFC 4094 Analysis of QoS Signaling May 2005 + + +2.2.7. ATM Interface + + [RFC2379] and [RFC2380] define RSVP over ATM implementation + guidelines and requirements to interwork with the ATM (Forum) UNI + 3.x/4.0. [RFC2380] states that the RSVP (control) messages and RSVP + associated data packets must not be sent on the same virtual circuits + (VCs), and that an explicit release of RSVP associated QoS VCs must + be performed once the VC for forwarding RSVP control messages + terminates. Although a separate control VC is also possible for + forwarding RSVP control messages, [RFC2379] recommends creating a + best-effort short-cut first (if one does not exist), which can allow + setting up RSVP-triggered VCs to use the best-effort end-point. (A + short-cut is a point-to-point VC where the two end-points are located + in different IP subnets.) For data flows, the subnet senders must + establish all QoS VCs, and the RSVP-enabled subnet receiver must be + able to accept incoming QoS VCs. RSVP must request that the + configurable inactivity timers of VCs be set to "infinite". If it is + too complex to do this at the VC receiver, RSVP over ATM + implementations are required not to use an inactivity timer to clear + any received connections. For dynamic QoS, the replacement of VC + should be done gracefully. + +2.2.8. DiffServ Interface + + RFC2996 [RFC2996] introduces a DCLASS Object to carry Differentiated + Services Code Points (DSCPs) in RSVP message objects. If the network + element determines that the RSVP request is admissible to the + DiffServ network, one or more DSCPs corresponding to the behavior + aggregate are determined, and will be carried by the DCLASS Object + added to the RESV message upstream toward the RSVP sender. + +2.2.9. Null Service Type + + For some applications, service parameters are specified by the + network, not by the application; e.g., enterprise resource planning + (ERP) applications. The Null Service [RFC2997] allows applications + to identify themselves to network QoS policy agents using RSVP + signaling, but does not require them to specify resource + requirements. QoS policy agents in the network respond by applying + QoS policies appropriate for the application (as determined by the + network administrator). The RSVP sender offers the new service type, + 'Null Service Type', in the ADSPEC that is included with the PATH + message. A new TSPEC corresponding to the new service type is added + to the SENDER_TSPEC. In addition, the RSVP sender will typically + include with the PATH message policy objects identifying the user, + application and sub-flow, which will be used for network nodes to + manage the correspondent traffic flow. + + + + +Manner & Fu Informational [Page 9] + +RFC 4094 Analysis of QoS Signaling May 2005 + + +2.2.10. MPLS Traffic Engineering + + RSVP-TE [RFC3209] specifies the core extensions to RSVP for + establishing constraint-based explicitly routed LSPs in MPLS networks + using RSVP as a signaling protocol. RSVP-TE is intended for use by + label switching routers (as well as hosts) to establish and maintain + LSP-tunnels and to reserve network resources for such LSP-tunnels. + + RFC3209 defines a new Hello message (for rapid node failure + detection). + + RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and + LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC + objects. Here, a session is the association of LSPs that support the + LSP-tunnel. The traffic on an LSP can be classified as the set of + packets that are assigned the same MPLS label value at the + originating node of an LSP-tunnel. + + The following 5 new objects are also defined: + + 1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path + messages, encapsulating a concatenation of hops that constitutes + the explicitly routed path. Using this object, the paths taken by + label-switched RSVP-MPLS flows can be pre-determined independently + of conventional IP routing. + + 2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can + create a Path message with a LABEL_REQUEST object. A node that + sends a LABEL_REQUEST object MUST be ready to accept and correctly + process a LABEL object in the corresponding Resv messages. + + 3) LABEL object. Each node that receives a Resv message containing a + LABEL object uses that label for outgoing traffic associated with + this LSP tunnel. + + 4) SESSION_ATTRIBUTE object, which can be added to Path messages to + aid in session identification and diagnostics. Additional control + information, such as setup and holding priorities, resource + affinities, and local-protection, are also included in this + object. + + 5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object may appear in + both Path and Resv messages. It is used to collect detailed path + information and is useful for loop detection and for diagnostics. + + + + + + + +Manner & Fu Informational [Page 10] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + Section 5 of [RFC3270] further specifies the extensions to RSVP to + establish LSPs supporting DiffServ in MPLS networks, introducing a + new DIFFSERV Object (applicable in the Path messages), and using + pre-configured or signaled "EXP<-->PHB mapping" (e.g., [RFC3270]). + + RSVP-TE provides a way to indicate an unnumbered link in its Explicit + Route and Record Route Objects through [RFC3477]. This specifies the + following extensions: + + - An Unnumbered Interface ID Subobject, which is a subobject of the + Explicit Route Object (ERO) used to specify unnumbered links. + + - An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to + form or use an identifier for an unnumbered Forwarding Adjacency. + + - A new subobject of the Record Route Object, used to record that the + LSP path traversed an unnumbered link. + +2.2.11. GMPLS and RSVP-TE + + GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE. It enables the + provisioning of data-paths within networks supporting a variety of + switching types including packet and cell switching networks, layer + two networks, TDM networks, and photonic networks. + + It defines the new Notify message (for general event notification), + which may contain notifications being sent, with respect to each + listed LSP, both upstream and downstream. Notify messages can be + used for expedited notification of failures and other events to nodes + responsible for restoring failed LSPs. A Notify message is sent + without the router alert option. + + A number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for + general uses of MPLS: + + - a Generalized Label Request Object; + + - a Generalized Label Object; + + - a Suggested Label Object; + + - a Label Set Object (to restrict label choice); + + - an Upstream_Label object (to support bidirectional LSPs); + + - a Label ERO subobject; + + + + + +Manner & Fu Informational [Page 11] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + - IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in + out-of-band signaling or in bundled links); + + - IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify interfaces in + out-of-band signaling or in bundled links); + + - an Acceptable Label Set object (to support negotiation of label + values in particular for bidirectional LSPs) + + - a Notify Request object (may be inserted in a Path or Resv message + to indicate where a notification of LSP failure is to be sent) + + - a Restart_Cap Object (used on Hello messages to identify recovery + capabilities) + + - an Admin Status Object (to notify each node along the path of the + status of the LSP, and to control that state). + +2.2.12. GMPLS Operation at UNI and E-NNI Reference Points + + The ITU-T defines network reference points that separate + administrative or operational parts of the network. The reference + points are designated as: + + - User to Network Interfaces (UNIs) if they lie between the user or + user network and the core network, or + + - External Network to Network Interfaces (E-NNIs) if they lie between + peer networks, network domains, or subnetworks. + + GMPLS is applicable to the UNI and E-NNI without further + modification, and no new messages, objects, or C-Types are required. + See [OVERLAY]. + +2.2.13. MPLS and GMPLS Future Extensions + + At the time of writing, MPLS and GMPLS are being extended by the MPLS + and CCAMP Working Groups to support additional sophisticated + functions. This will inevitably lead to the introduction of new + C-Types for existing objects, and to the requirement for new objects + (CNums). It is possible that new messages will also be introduced. + + + + + + + + + + +Manner & Fu Informational [Page 12] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + Some of the key features and functions being introduced include the + following: + + - Protection and restoration. Features will be developed to provide + - end-to-end protection + - segment protection + - various protection schemes (1+1, 1:1, 1:n) + - support of extra traffic on backup LSPs + - Diverse path establishment for protection and load sharing. + - Establishment of point-to-multipoint paths. + - Inter-area and inter-AS path establishment with + - explicit path control + - bandwidth reservation + - path diversity + - Support for the requirements of Automatic Switched Optical Network + (ASON) signaling as defined by the ITU-T, including call and + connection separation. + - Crankback during LSP setup. + +2.2.14. ITU-T H.323 Interface + + ITU-T H.323 ([H.323]) recommends the IntServ resource reservation + procedure using RSVP. The information as to whether an endpoint + supports RSVP should be conveyed during the H.245 [H.245] capability + exchange phase, by setting appropriate qOSMode fields. If both + endpoints are RSVP-capable, when opening an H.245 logical channel, a + receiver port ID should be conveyed to the sender by the + openLogicalChannelAck message. Only after that can a "Path - Resv - + ResvConf" process take place. The timer of waiting for ResvConf + message will be set by the endpoint. If this timer expires or RSVP + reservation fails at any point during an H.323 call, the action is up + to the vendor. Once a ResvConf message is sent or received, the + endpoints should stop reservation timers and resume with the H.323 + call procedures. Only explicit release of reservations are supported + in [H.323]. Before sending a closeLogicalChannel message for a + stream, a sender should send a PathTear message if an RSVP session + has been previous created for that stream. After receiving a + closeLogicalChannel, a receiver should send a ResvTear similarly. + Only the FF style is supported, even for point-to-multipoint calls. + +2.2.15. 3GPP Interface + + Third Generation Partnership Project (3GPP) TS 23.207 + ([3GPP-TS23207]) specifies the QoS signaling procedure with policy + control within the Universal Mobile Telecommunications System (UMTS) + end-to-end QoS architecture. When using RSVP, the signaling source + and/or destination are the User Equipments (UEs, devices that allow + users access to network services) that locate in the Mobile + + + +Manner & Fu Informational [Page 13] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + Originating (MO) side and the Mobile Terminating (MT) side. An RSVP + signaling process can either trigger or be triggered by the (COPS) + PDP Context establishment/modification process. The operation of + refreshing states is not specified in [3GPP-TS23207]. If a + bidirectional reservation is needed, the RSVP signaling exchange must + be performed twice between the end-points. The authorization token + and flow identifier(s) in a policy data object should be included in + the RSVP messages sent by the UE, if the token is available in the + UE. When both RSVP and Service-based Local Policy are used, the + Gateway GPRS Support Node (GGSN, the access point of the network) + should use the policy information to decide whether to accept and + forward Path/Resv messages. + +2.3. Extensions for New Deployment Scenarios + + As a well-acknowledged protocol in the Internet, RSVP is expected + more and more to provide a more generic service for various signaling + applications. However, RSVP messages were designed in a way to + support end-to-end QoS signaling optimally. To meet the increasing + demand that a signaling protocol also operate in host-to-edge and + edge-to-edge ways, and that it serve for some other signaling + purposes in addition to end-to-end QoS signaling, RSVP needs to be + made more flexible and applicable for more generic signaling. + + RSVP proxies [BEGD02] extend RSVP by originating or receiving the + RSVP message on behalf of the end node(s), so that applications may + still benefit from reservations that are not truly end-to-end. + However, there are certainly scenarios where an application would + want to explicitly convey its non-QoS purposed (as well as QoS) data + from a host into the network, or from an ingress node to an egress + node of an administrative domain. It must do so without burdening + the network with excess messaging overhead. Typical examples are an + end host desiring a firewall service from its provider's network and + MPLS label setup within an MPLS domain. + + RSVP requires support from network routers and user space + applications. Domains not supporting RSVP are traversed + transparently. Unfortunately, like other IP options, RSVP messages + implemented by way of IP alert option may be dropped by some routers + [FJ02]. Although applications need to be built with RSVP libraries, + one article presents a mechanism that would allow any host to benefit + from RSVP mechanisms without applications' awareness [MHS02]. + + A somewhat similar deployment benefit can be gained from the + Localized RSVP (LRSVP) [JR03] [MSK+04]. The documents present the + concept of local RSVP-based reservation that alone can be used to + trigger reservation within an access network. In those cases, an + end-host may request QoS from its own access network without the + + + +Manner & Fu Informational [Page 14] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + cooperation of a correspondent node outside the access network. This + would be especially helpful when the correspondent node is unaware of + RSVP. A proxy node responds to the messages sent by the end host and + enables both upstream and downstream reservations. Furthermore, the + scheme allows for faster reservation repairs following a handover by + triggering the proxy to assist in an RSVP local repair. + + Still, in end-hosts that are low in processing power and + functionality, having an RSVP daemon run and take care of the + signaling may introduce unnecessary overhead. One article [Kars01] + proposes to create a remote API so that the daemon would in fact run + on the end-host's default router and the end-host application would + send its requests to that daemon. + + Another potential problem lies in the limited size of signaled data + due to the limitation of message size. An RSVP message must fit + entirely into a single non-fragmented IP datagram. Bundle messages + [RFC2961] can aggregate multiple RSVP messages within a single PDU, + but they still only occupy one IP datagram (i.e., approximately 64K). + If it exceeds the MTU, the datagram is fragmented by IP and + reassembled at the recipient node. + +2.4. Conclusion + + A good signaling protocol should be transparent to the applications. + RSVP has proven to be a very well designed protocol. However, it has + a number of fundamental protocol design issues that require more + careful re-evaluation. + + The design of RSVP was originally targeted at multicast applications. + The result has been that the message processing within nodes is + somewhat heavy, mainly due to flow merging. Still, merging rules + should not appear in the specification as they are QoS-specific. + + RSVP has a comprehensive set of filtering styles, including + Wildcard-Filter (WF), Fixed-Filter (FF), and Shared-Explicit (SE), + and is not tied to certain QoS objects. (RSVP is not tied to IntServ + Guaranteed Service/Controlled Load (GS/CL) specifications.) Objects + were designed to be modular, but Xspecs (TSPEC, etc.) are more or + less QoS-specific and should be more generalized; there is no clear + layering/separation between the signaled data and signaling protocol. + + RSVP uses a soft state mechanism to maintain states and allows each + node to define its own refresh timer. The protocol is also + independent of underlying routing protocols. Still, in mobile + networks the movement of the mobile nodes may not properly trigger a + reservation refresh for the new path, and therefore a mobile node may + be left without a reservation up to the length of the refresh timer. + + + +Manner & Fu Informational [Page 15] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + Furthermore, RSVP does not work properly with changing end-point + identifiers; that is, if one of the IP addresses of a mobile node + changes, the filters may not be able to identify the flow that had a + reservation. + + From the security point of view, RSVP does provide the basic building + blocks for deploying the protocol in various environments to protect + its messages from forgery and modification. Hop-by-hop protection is + provided. However, the current RSVP security mechanism does not + provide non-repudiation and protection against message deletion; the + two-way peer authentication and key management procedures are still + missing. + + Finally, since the publication of the RSVP standard, tens of + extensions have emerged that allow for much wider deployment than + RSVP was originally designed for -- for instance, the Subnet + Bandwidth Manager, the NULL service type, aggregation, operation over + tunneling, and MPLS, as well as diagnostic messages. + + Domains not supporting RSVP are traversed transparently by default. + Unfortunately, like other IP options, RSVP messages implemented by + way of IP alert option may be dropped by some routers. Also, the + maximal size of RSVP message is limited. + + The transport mechanisms, performance, security, and mobility issues + are detailed in the following sections. + +3. RSVP Transport Mechanism Issues + +3.1. Messaging Reliability + + RSVP messages are defined as a new IP protocol (that is, a new ptype + in the IP header). RSVP Path messages must be delivered end-to-end. + For the transit routers to intercept the Path messages, a new IP + Router Alert option [RFC2113] was introduced. This design is simple + to implement and efficient to run. As shown from the experiments in + [PS00], with minor kernel changes IP option processing introduces + very little overhead on a Free BSD box. + + However, RSVP does not have a good message delivery mechanism. If a + message is lost on the wire, the next re-transmit cycle by the + network would be one soft-state refresh interval later. By default, + a soft-state refresh interval is 30 seconds. + + + + + + + + +Manner & Fu Informational [Page 16] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + To overcome this problem, [PS97] introduced a staged refresh timer + mechanism, which has been defined as a RSVP extension in [RFC2961]. + The staged refresh timer mechanism retransmits RSVP messages until + the receiving node acknowledges. It can address the reliability + problem in RSVP. + + However, during the mechanism's implementation, a lot of effort had + to be spent on per-session timer maintenance, message retransmission + (e.g., avoid message bursts), and message sequencing. In addition, + we have to make an effort to try to separate the transport functions + from protocol processing. For example, if a protocol extension + requires a natural RSVP session time-out (such as RSVP-TE one-to-one + fast-reroute [FAST-REROUTE]), we have to turn off the staged refresh + timers. + +3.2. Message Packing + + According to RSVP [RFC2205], each RSVP message can only contain + information for one session. In a network that has a reasonably + large number of RSVP sessions, this constraint imposes a heavy + processing burden on the routers. Many router OSes are based on + UNIX. [PS00] showed that the UNIX socket I/O processing is not very + sensitive to packet size. In fact, processing small packets takes + almost as much CPU overhead as processing large ones. However, + processing too many individual messages can easily cause congestion + at socket I/O interfaces. + + To overcome this problem, RFC2961 introduced the message bundling + mechanism. The bundling mechanism packs multiple RSVP messages + between two adjacent nodes into a single packet. In one deployed + router platform, the bundling mechanism has improved the number of + RSVP sessions that a router can handle from 2,000 to over 7,000. + +3.3. MTU Problem + + RSVP does not support message fragmentation and reassembly at + protocol level. If the size of a RSVP message is larger than the + link MTU, the message will be fragmented. The routers simply cannot + detect and process RSVP message fragments. + + There is no solution for the MTU problem. Fortunately, at places + where RSVP-TE has been used, either the amount of per-session RSVP + data is never too large, or the link MTU is adjustable; PPP and Frame + Relay can always increase or decrease the MTU sizes. For example, on + some routers, a Frame Relay interface can support a link MTU size up + to 9600 bytes. Currently, the RSVP MTU problem is not a realistic + concern in MPLS networks. + + + + +Manner & Fu Informational [Page 17] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + However, when and if RSVP is used for end-user applications, for + which network security is an essential and critical concern, it is + possible that the size of RSVP messages can be larger than the link + MTU. Note that end-users will most likely have to deal with a small + 1500-byte Ethernet MTU. + +3.4. RSVP-TE vs. Signaling Protocol for RT Applications + + RSVP-TE works in an environment that is different from what the + original RSVP has been designed for: in MPLS networks, the RSVP + sessions that are used to support Label-Switched Paths (LSPs) do not + change frequently. + + In fact, the network operators typically set up the MPLS LSPs so that + they cannot switch too quickly. For example, the operators often + regulate the Constraint-based Shortest Path First (CSPF) computation + interval to prevent or delay a large volume of user traffic from + shifting from one session to another during LSP path optimization. + (CSPF is a routing algorithm that operates from the network edge to + compute the "most" optimal routes for the LSPs.) As a result, RSVP- + TE does not have to handle a large amount of "triggered" (new or + modified) messages. Most of the messages are refresh messages, + which can be handled by the mechanisms introduced in RFC2961. In + particular, in the Summary Refresh extension [RFC2961], each RSVP + refresh message can be represented as a 4-byte ID. The routers can + simply exchange the IDs to refresh RSVP sessions. With the full + implementation of RFC2961, MPLS routers do not have any RSVP scaling + issue. On one deployed router platform, it can support over 50,000 + RSVP sessions in a stable backbone network. + + On the other hand, in many of the new applications for which a + signaling protocol is required, the user session duration can be + relatively short. The dynamics of adding/dropping user sessions + could introduce a large number of "triggered" messages in the + network. This can clearly introduce a substantial amount of + processing overhead to the routers. This is one area where a new + signaling protocol may be needed to reduce the processing complexity + in the resource reservation process. + +3.5. What Would Be a Better Alternative? + + A good signaling protocol should be transparent to the applications. + On the other hand, the design of a signaling protocol must take the + intended and potential applications into consideration. + + With the addition of RFC2961, RSVP-TE is sufficient to support its + intended application, MPLS, within the backbone. There is no + significant transport-layer problem that needs to be solved. + + + +Manner & Fu Informational [Page 18] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + In the last several years, a number of new applications have emerged + that are proposed to need IP signaling, beyond the traditional ones + associated with quality of service and resource allocation. On-path + firewall control/NAT traversal (synergistic with the midcom design of + [RFC3303]) is one of these. There are far-out applications such as + depositing active network code in network devices. Next-generation + signaling protocols dealing with novel applications, with network + security requirements, and with the MTU problems described above, + will prevent the re-use of the existing RSVP transport mechanism. + + If a new transport protocol is needed, the protocol must be able to + handle the following: + + - reliable messaging; + + - message packing; + + - the MTU problem; + + - small triggered message volume. + +4. RSVP Protocol Performance Issues + +4.1. Processing Overhead + + By "processing overhead" we mean the amount of processing required to + handle messages belonging to a reservation session. This is the + processing required in addition to the processing needed for routing + an (ordinary) IP packet. The processing overhead of RSVP originates + from two major issues: + + 1) Complexity of the protocol elements. First, RSVP itself is per- + flow based; thus the number of states is proportional to RSVP + session number. Path and Resv states have to be maintained in + each RSVP router for each session (and Path state also has to + record the reverse route for the correspondent Resv message). + Second, being receiver-initiated, RSVP optimizes various merging + operations for multicast reservations while the Resv message is + processed. To handle multicast, other mechanisms such as + reservation styles, scope object, and blockade state, are also + required to be presented in the basic protocol. This not only + adds sources of failures and errors, but also complicates the + state machine [Fu02]. Third, the same RSVP signaling messages are + used not only for maintaining the state, but also for dealing with + recovery of signaling message loss and discovery of route change. + Thus, although protocol elements that represent the actual data + (e.g., QoS parameters) specification are separated from signaling + elements, the processing overhead needed for all RSVP messages is + + + +Manner & Fu Informational [Page 19] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + not marginal. Finally, the possible variations of the order and + existence of objects increases the complexity of message parsing + and internal message and state representation. + + 2) Implementation-specific Overhead. There are two ways to send and + receive RSVP messages: either as "raw" IP datagrams with protocol + number 46, or as encapsulated UDP datagrams, which increase the + efficiency of RSVP processing. Typical RSVP implementations are + user-space daemons interacting with the kernel; thus, state + management, message sending, and reception would affect the + efficiency of the protocol processing. For example, in the recent + version of the implementation described in [KSS01], the relative + execution costs for the message sending/reception system calls + "sendto", "select", and "recvmsg" were 14-16%, 6-7%, 9-10%, + individually, of the total execution cost. [KSS01] also found + that state (memory) management can use up to 17-18% of the total + execution cost, but it is possible to decrease that cost to 6-7%, + if appropriate action is taken to replace the standard memory + management with dedicated memory management for state information. + RSVP/routing, RSVP/policy control, and RSVP/traffic control + interfaces can also pose different overhead depending on + implementation. For example, the RSVP/routing overhead has been + measured to be approximately 11-12% of the total execution cost + [KSS01]. + +4.2. Bandwidth Consumption + + By "bandwidth consumption" we mean the amount of bandwidth used + during the lifetime of a session: to set up a reservation session, to + keep the session alive, and finally to close it. + + RSVP messages are sent either to trigger a new reservation or to + refresh an existing reservation. In standard RSVP, Path/Resv + messages are used for triggering and refreshing/recovering + reservations, identically, which results in an increased size of + refresh messages. The hop-by-hop refreshment may reduce the + bandwidth consumption for RSVP, but could result in more sources of + error/failure events. [RFC2961] presents a way to bundle standard + RSVP messages and reduces the refreshment redundancy by Srefresh + message. + + + + + + + + + + + +Manner & Fu Informational [Page 20] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + Thus, the following formula represents the bandwidth consumption in + bytes for an RSVP session lasting n seconds: + + F(n) = (bP + bR) + ((n/Ri) * (bP + bR)) + bPt + + bP: IP payload size of Path message + bR: IP payload size of Resv message + bPt: IP payload size of Path Tear message + Ri: refresh interval + + For example, for a simple Controlled Load reservation without + security and identification requirements (where bP is 172 bytes, bR + is 92, bPt is 44 bytes, and Ri is 30 seconds), the bandwidth + consumption would be as follows: + + F(n) = (172 + 92) + ((n/30) * (172 + 92)) + 44 + + = 308 + (264n/30) bytes + +5. RSVP Security and Mobility + +5.1. Security + + To allow a process on a system to securely identify the owner and the + application of the communicating process (e.g., user id) and to + convey this information in RSVP messages (PATH or RESV) in a secure + manner, [RFC3182] specifies the encoding of identities as RSVP + POLICY_DATA Object. However, to provide ironclad security + protection, cryptographic authentication combined with authorization + has to be provided. Such a functionality is typically offered by + authentication and key exchange protocols. Solely including a user + identifier is insufficient. + + To provide hop-by-hop integrity and authentication of RSVP messages, + an RSVP message may contain an INTEGRITY object ([RFC2747]) using a + keyed message digest. Since intermediate routers need to modify and + process the content of the signaling message, a hop-by-hop security + architecture based on a chain-of-trust is used. However, with the + different usage of RSVP as described throughout this document and + with new requirements, a re-evaluation of the original assumptions + might be necessary. + + RFC2747 provides protection against forgery and message modification. + However, this does not provide non-repudiation or protect against + message deletion. In the current RSVP security scheme, the two-way + peer authentication and key management procedures are still missing. + + The security issues have been well analyzed in [Tsch03]. + + + +Manner & Fu Informational [Page 21] + +RFC 4094 Analysis of QoS Signaling May 2005 + + +5.2. Mobility Support + + Two issues raise concern when a mobile node (MN) uses RSVP: the flow + identifier and reservation refresh. When an MN changes locations, it + may need to change one of its assigned IP addresses. An MN may have + an IP address by which it is reachable by nodes outside the access + network, and an IP address used to support local mobility management. + Depending on the mobility management mechanism, a handover may force + a change in any of these addresses. As a consequence, the filters + associated with a reservation may not identify the flow anymore, and + the resource reservation is ineffective until a refresh with a new + set of filters is initialized. + + The second issue relates to following the movement of a mobile node. + RFC2205 defines that Path messages can perform a local repair of + reservation paths. When the route between the communicating end + hosts changes, a Path message will set the state of the reservation + on the new route, and a subsequent Resv message will make the + resource reservation. Therefore, by sending a Resv message a host + cannot alone update the reservation, and thus it cannot perform a + local repair before a Path message has passed. Also, in order to + provide fast adaptation to routing changes without the overhead of + short refresh periods, the local routing protocol module can notify + the RSVP process of route changes for particular destinations. The + RSVP process should use this information to trigger a quick refresh + of state for these destinations, using the new route (Section 3.6, + [RFC2205]). However, not all local mobility protocols affect routing + directly in routers (not even Mobile IP), and thus mobility may not + be noticed at RSVP routers. Therefore, it may take a relatively long + time before a reservation is refreshed following a handover. + + There have been several designs for extensions to RSVP to allow for + more seamless mobility. One solution is presented in [MSK+04], in + which one section discusses the coupling of RSVP and the mobility + management mechanisms and proposes small extensions to RSVP to handle + the handover event better, among other things. The extension allows + the mobile host to request a Path for the downstream reservation when + a handover has happened. + + Another example is Mobile RSVP (MRSVP) [TBA01], which is an extension + to standard RSVP. It is based on advance reservations, where + neighboring access points keep resources reserved for mobile nodes + moving to their coverage area. When a mobile node requests + resources, the neighboring access points are checked, too, and a + passive reservation is done around the mobile nodes' current + location. + + + + + +Manner & Fu Informational [Page 22] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + The problem with the various "advance reservation" schemes is that + they require topological information of the access network and, + usually, advance knowledge of the handover event. Furthermore, the + way the resources reserved in advance are used in the neighboring + service areas is an open issue. A good overview of these different + schemes can be found in [MA01]. + + The interactions of RSVP and Mobile IP have been well documented in + [Thom02]. + +6. Other QoS Signaling Proposals + +6.1. Tenet and ST-II + + Tenet and ST-II are two original QoS signaling protocols for the + Internet. + + In the original Tenet architecture [BFM+96], the receiver sends a + reservation request toward the source. Each network node along the + way makes the reservation. Once the request arrives at the source, + the source sends another Relax message back toward to the receiver, + and has the option to modify the previous reservation at each node. + + ST-II [RFC1819] basically works in the following way: a sender + originates a Connect message to a set of receivers. Each + intermediate node determines the next hop subnets, and makes + reservations on the links going to these next hops. Upon receiving a + Connect indication, a receiver must send back either an Accept or a + Refuse message to the sender. In the case of an Accept, the receiver + may further reduce the resource request by updating the returned flow + specifications. + + ST-II consists of two protocols: ST for the data transport and the + Stream Control Message Protocol (SCMP) for all control functions. + ST is simple and contains only a single PDU format, which is designed + for fast and efficient data forwarding in order to achieve low + communication delays. SCMP packets are transferred within ST + packets. + + ST-II has no built-in soft states; thus, it requires that the network + be responsible for correctness. It is sender-initiated, and the + overhead for ST-II to handle group membership dynamics is higher than + that for RSVP [MESZ94]. ST-II does not provide security, but + [RFC1819] describes some objects related to charging. + + + + + + + +Manner & Fu Informational [Page 23] + +RFC 4094 Analysis of QoS Signaling May 2005 + + +6.2. YESSIR + + YESSIR (YEt another Sender Session Internet Reservations) [PS98] is a + resource reservation protocol that seeks to simplify the process of + establishing reserved flows while preserving many unique features + introduced in RSVP. Simplicity is measured in terms of control + message processing, data packet processing, and user-level + flexibility. Features such as robustness, advertising network + service availability, and resource sharing among multiple senders are + also supported in the proposal. + + The proposed mechanism generates reservation requests by senders to + reduce the processing overhead. It is built as an extension to the + Real-Time Transport Control Protocol (RTCP), taking advantage of + Real-Time Protocol (RTP). YESSIR also introduces a concept called + partial reservation, in which, for certain types of applications, the + reservation requests can be passed to the next hop, even though there + are not enough resources on a local node. The local node can rely on + optimized retries to complete the reservations. + +6.2.1. Reservation Functionality + + YESSIR [PS98] was designed for one-way, sender-initiated end-to-end + resource reservation. It also uses soft state to maintain states. + It supports resource query (similar to RSVP diagnosis message), + advertising (similar to RSVP ADSPEC), shared reservation, partial + reservations, and flow merging. + + To support multicast, YESSIR simplifies the reservation styles to + individual and shared reservation styles. Individual reservations + are made separately for each sender, whereas shared reservations + allocate resources that can be used by all senders in an RTP session. + Although RSVP supports shared reservation (SE and WF styles) from the + receiver's direction, YESSIR handles the shared reservation style + from the sender's direction; thus, new receivers can re-use the + existing reservation of the previous sender. + + It has been shown that the YESSIR one-pass reservation model has + better performance and lower processing cost than a regular two-way + signaling protocol, such as RSVP [PS98]. The bandwidth consumption + of YESSIR is somewhat lower than that of, for example, RSVP, because + it does not require additional IP and transport headers. Bandwidth + consumption is limited to the extension header size. + + YESSIR does not have any particular support for mobility, and the + security of YESSIR relies on RTP/RTCP security measures. + + + + + +Manner & Fu Informational [Page 24] + +RFC 4094 Analysis of QoS Signaling May 2005 + + +6.2.2. Conclusion + + YESSIR requires support in applications since it is an integral part + of RTCP. Similarly, it requires network routers to inspect RTCP + packets to identify reservation requests and refreshes. Routers + unaware of YESSIR forward the RTCP packets transparently. + +6.3. Boomerang + + Boomerang [FNM+99] is a another resource reservation protocol for IP + networks. The protocol has only one message type and a single + signaling loop for reservation setup and teardown, and it has no + requirements on the far end node. Instead, it concentrates the + intelligence in the Initiating Node (IN). + + In addition, the Boomerang protocol allows for sender- or receiver- + oriented reservations and resource query. Flows are identified with + the common 5-tuple, and the QoS can be specified by various means; + e.g., service class and bit rate. In the initial implementation, + Boomerang messages are transported in ICMP ECHO/REPLY messages. + +6.3.1. Reservation Functionality + + Boomerang can only be used for unicast sessions; no support for + multicast exists. The requested QoS can be specified with various + methods, and both ends of a communication session can make a + reservation for their transmitted flow. + + The authors of Boomerang show in [FNS02] that the processing of the + protocol is considerably lower than that of the ISI RSVP daemon + implementation. However, this is mainly due to the limited + functionality provided by the protocol compared to that provided by + RSVP. + + Boomerang messages are quite short and consume a relatively low + amount of link bandwidth. This is due to the limited functionality + of the protocol; for example, no security-specific information or + policy-based interaction is provided. Being sender oriented, the + bandwidth consumption mostly affects the downstream direction, from + the sender to the receiver. + + As Boomerang is sender oriented, there is no need to store backward + information. This reduces the signaling required. The rest of the + issues that were identified with RSVP apply with Boomerang. No + security mechanism is specified for Boomerang. + + + + + + +Manner & Fu Informational [Page 25] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + The Boomerang protocol has deployment issues similar to those of any + host-network-host protocol. It requires an implementation at both + communicating nodes and in routers. Boomerang-unaware routers should + be able to forward Boomerang messages transparently. Still, + firewalls often drop ICMP packets, making the protocol useless. + +6.3.2. Conclusions + + Boomerang seems to be a very lightweight protocol and efficient in + its own scenarios. However, the apparent low processing overhead and + bandwidth consumption results from the limited functionality. No + support for multicast or any security features are present, which + allows for a different functionality than RSVP, which the authors + like to compare Boomerang to. + +6.4. INSIGNIA + + INSIGNIA [LGZC00] is proposed as a very simple signaling mechanism + for supporting QoS in mobile ad-hoc networks. It avoids the need for + separate signaling by carrying the QoS signaling data along with the + normal data in IP packets using IP packet header options. This + approach, known as "in-band signaling", is proposed as more suitable + in the rapidly changing environment of mobile networks since the + signaled QoS information is not tied to a particular path. It also + allows the flows to be rapidly established and, thus, is suitable for + short-lived and dynamic flows. + + INSIGNIA aims to minimize signaling by reducing the number of + parameters that are provided to the network. It assumes that real- + time flows may tolerate some loss, but are very delay sensitive so + that the only QoS information needed is the required minimum and + maximum bandwidth. + + The INSIGNIA protocol operates at the network layer and assumes that + link status sensing and access schemes are provided by lower-layer + entities. The usefulness of the scheme depends on the MAC layers, + but this is undefined, so INSIGNIA can run over any MAC layer. The + protocol requires that each router maintains per-flow state. + + The INSIGNIA system implicitly supports mobility. A near-minimal + amount of information is exchanged with the network. To achieve + this, INSIGNIA makes many assumptions about the nature of traffic + that a source will send. This may also simplify admission control + and buffer allocation. The system basically assumes that "real-time" + will be defined as a maximum delay, and the user can simply request + real-time service for a particular quantity of traffic. + + + + + +Manner & Fu Informational [Page 26] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + After handover, data that was transmitted to the old base station can + be forwarded to the new base station, so no data loss should occur. + However, there is no way to differentiate between re-routed and new + traffic, so priority cannot be given to handover traffic, for + example. + + INSIGNIA, however, (completely) lacks a security framework and does + not investigate how to secure signaled QoS data in an ad-hoc network, + where relatively weak trust or even no trust exists between the + participating nodes. Therefore, authorization and charging + especially might be a challenge. The security protection of in-band + signaling is costly since the data delivery itself experiences + increased latency if security processing is done hop-by-hop. Because + the QoS signaling information is encoded into the flow label and + end-to-end addressing is used, it is very difficult to provide + security other than IPsec in tunnel mode. + +7. Inter-Domain Signaling + + This section gives a short overview of protocols designed for inter- + domain signaling. + +7.1. BGRP + + Border Gateway Reservation Protocol (BGRP) [BGRP] is a signaling + protocol for inter-domain aggregated resource reservation for unicast + traffic. BGRP builds a sink tree for each of the stub domains. Each + sink tree aggregates bandwidth reservations from all data sources in + the network. BGRP maintains these aggregated reservations using soft + state and relies on Differentiated Services for data forwarding. + + In terms of message processing load, BGRP scales state storage and + bandwidth. Because backbone routers only maintain the sink tree + information, the total number of reservations at each router scales + linearly with the number of Internet domains. + +7.2. SICAP + + SICAP (Shared-segment Inter-domain Control Aggregation protocol) + [SGV03] is an inter-domain signaling solution that performs shared- + segment aggregation [SGV02] on the Autonomous System (AS) level in + order to reduce state required at Boundary Routers (BRs). SICAP + performs aggregation based on path segments that different + reservations share. Thus, reservations may be merged into aggregates + that do not necessarily extend all the way to the reservation's + destination. The motivation for creating "shorter" aggregates is + that, on one hand, their ability to accommodate future requests more + easily, and, on the other hand, the minimization of aggregates + + + +Manner & Fu Informational [Page 27] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + created and consequently, the reduction of state required to manage + established reservations. However, in contrast to the sink-tree + approach (used by BGRP [BGRP]), the shared-segment approach + introduces intermediate de-aggregation locations. These are ASes + where aggregates may experience "re-aggregation". At these + locations, routers that perform aggregation (AS egress routers) have + to keep track of the mapping between reservations and aggregates. + One possible way to do this is to keep each reservation identifier + and the corresponding resources stored at each aggregator. However, + this solution incurs a high state penalty. SICAP avoids this state + penalty by keeping track of the mapping between aggregates and + reservations at the level of destination domains rather than + explicitly map individual reservations to aggregates. In other + words, SICAP maintains, per aggregate, a list of the destination + prefixes advertised by the destination AS an aggregate provides + access to. + + Pan et al. show that BGRP scales well in terms of control state, + message processing, and bandwidth efficiency, when compared to RSVP + without aggregation. However, partially given that BGRP was the + first approach to explore the issue of inter-domain control + aggregation in detail, they did not provide a comparison with other + aggregation protocols. + + SICAP and BGRP messaging sequences are similar, and consequently, + these protocols attain the same signaling load. This load is exactly + the same as that attained by proposals that do not perform + aggregation, given that SICAP and BGRP exchange messages per + individual reservation. In terms of bandwidth, both protocols + provision aggregates with the exact bandwidth required by their + merged reservations. Therefore, the major difference between SICAP + and BGRP is state maintained at BRs, which is significantly reduced + by SICAP. We consider this to be of importance not so much for + offering a better-performing alternative to BGRP, but for quantifying + the performance improvements that might still be available in the + research field of control path aggregation. Finally, to deal with + the possible problem of the signaling load, SICAP uses an over- + reservation mechanism [SGV03b], whose design took into consideration + a possible support for BGRP. + +7.3. DARIS + + Dynamic Aggregation of Reservations for Internet Services (DARIS) + [Bless02] [Bless04] defines an inter-domain aggregation scheme for + resource reservations. Basically, it aggregates reservations along + Autonomous System (AS) paths (or parts thereof). A set of + reservations whose data paths share a common sequence of ASes are + integrated into a joint reservation aggregate along that shared sub- + + + +Manner & Fu Informational [Page 28] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + path. All entities within the aggregate, except for aggregate + starting and end point, can remove state information of the included + individual reservations, thereby saving states. They just need to + hold the necessary information about the encompassing aggregate. + Moreover, these intermediate ASes are no longer involved in signaling + that is related to the aggregated reservations. If more aggregate + resources are reserved than were actually required, the capacity of + the aggregate does not need to be adapted with every new or released + reservation (thereby reducing the number of message exchanges). + + An aggregate between two ASes is created as soon as a threshold k is + exceeded that describes the active number of unidirectional + reservations between them. It is, however, possible to apply + different aggregation triggers. Furthermore, DARIS allows aggregates + to be nested hierarchically. Therefore, the existence of shorter + aggregates does not prevent the creation of longer (and thus more + efficient) aggregates, and vice versa. An evaluation of recent BGP + routing information in [Bless02] showed that 92% of all end-to-end + paths contain at least four ASes. Consequently, an aggregate from + edge AS to edge AS can span four or more ASes, thus saving states and + signaling message processing in at least two ASes. + + There is, however, a small chance that a reservation cannot be + included in a new aggregate, because it was already aggregated + elsewhere. This so-called "aggregation conflict" is caused by the + prior removal of state information related to individual reservations + within intermediate ASes of the encompassing aggregate. This may + also bring difficulties if reservations or aggregates are re-routed + between ASes. One must be careful when considering how to define + sophisticated adaptation techniques for these special cases, because + they seem to become very complex. + + The signaling protocol DMSP (Domain Manager Signaling Protocol) + supports aggregation by special extensions that reduce the + reservation setup time for more than one round-trip time in some + cases (e.g., if an aggregate's capacity must be increased before a + new reservation can be included). Details can be found in [Bless02]. + + The DARIS concept was evaluated by using a simulation with a topology + that was derived from real BGP routing table information and + comprised more than 5500 ASes. In comparison to a non-aggregated + scenario, the number of saved states lay in the range of one to two + orders of magnitude, and similar results were obtained with respect + to the number of signaling messages. Though [Bless02] describes + DARIS in the context of distributed Domain Management entities + (similar to a bandwidth broker), it can be applied in a router-based + + + + + +Manner & Fu Informational [Page 29] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + resource management environment, too. This will achieve a higher + degree of distribution, which is beneficial for large ASes, which are + highly interconnected. + + A general issue with aggregation is that it is not the aggregating + and de-aggregating ASes that profit from their initiated aggregates, + but all intermediate ASes within an aggregate. Therefore, some + incentive for aggregate creation has to be given. This may lead to + novel cost models that have to be developed for aggregation concepts + in the future. + +8. Security Considerations + + This document does not present new technology or protocols. Thus, + there are no explicit security issues. Still, individual protocols + include different levels of security issues and those are highlighted + in the relevant sections and references. + +9. Summary + + Supporting flow-based soft state reservations has been proven useful. + Still, there have been different ways to improve the performance, + including refresh reduction and aggregation. However, some of the + main concerns with these signaling protocols are the complexity of + the protocol, which affects implementations and processing overhead, + and the security of the signaling. Especially, a proper scheme to + handle authentication and authorization of QoS resource requests and + a framework for providing signaling message security seem to be + missing from most protocols. RSVP has a mechanism to protect + signaling messages based on manually distributed keys and concepts + for authorization, but they seem to be insufficient for a dynamic and + mobile environment. [Tsch03] provides more details on security + properties provided by RSVP. Moreover, secure and efficient + signaling to and from mobile nodes has been one of the critical + challenges not fully met by existing protocols. + + Moving QoS signaling protocols into a generic messenger can provide + much adoption. It is expected that the development of future + protocols should learn from the lessons of existing ones. + Nevertheless, the tradeoffs between the expected functionality, + protocol complexity/performance would still be taken into account. + For example, RSVP uses the two-way signaling mechanism, whereas + YESSIR employs only one-pass signaling. Both can be shown to out- + perform the other in specific carefully chosen signaling scenarios. + + + + + + + +Manner & Fu Informational [Page 30] + +RFC 4094 Analysis of QoS Signaling May 2005 + + +10. Contributors + + This document is part of the work done in the NSIS Working Group. + The document was initially written by Jukka Manner and Xiaoming Fu. + Since the first version, Martin Karsten has provided text about the + processing overhead of RSVP, and Hannes Tschofenig has provided text + about various security issues in the protocols. Henning Schulzrinne + and Ping Pan have provided more information on RSVP transportation + after the second revision. Kireeti Kompella and Adrian Farrel + provided a review and updates to the discussion on RSVP-TE and GMPLS. + +11. Acknowledgements + + We would like to acknowledge Bob Braden and Vlora Rexhepi for their + useful comments. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Manner & Fu Informational [Page 31] + +RFC 4094 Analysis of QoS Signaling May 2005 + + +12. Appendix A: Comparison of RSVP to the NSIS Requirements + + This section provides a comparison of RSVP to the requirements + identified as part of the work in NSIS [RFC3726]. The numbering + follows the division in the requirements document. + + 5.1. Architecture and Design Goals + + 5.1.1. NSIS SHOULD Provide Availability Information on Request + + RSVP itself does not support query-type of operations. However, + the RSVP diagnosis messages extension [RFC2745] provides a means + to query resource availability. + + 5.1.2. NSIS MUST Be Designed Modularly + + RSVP was designed to be modular by way of TLV objects, however + it is regarded being lack of sufficient extensibility in various + kind of signalling applications. + + 5.1.3. NSIS MUST Decouple Protocol and Information + + RSVP is decoupled from the IntServ QoS specifications. Still, + the concept of sessions in RSVP are somewhat coupled to the + information it carries. + + 5.1.4. NSIS MUST Support Independence of Signaling and Network + Control Paradigm + + The IntServ information carried by RSVP does not tie the QoS + provisioning mechanisms. + + 5.1.5. NSIS SHOULD Be Able To Carry Opaque Objects + + RSVP supports this. + + 5.2. Signaling Flows + + 5.2.1. The Placement of NSIS Initiator, Forwarder, and Responder + Anywhere in the Network MUST Be Allowed + + Standard RSVP works only end-to-end, although the RSVP proxy + [BEGD02] and the Localized RSVP [MSK+04] have relaxed this + assumption. RSVP relies on receiver-initiation way to perform + QoS reservations. + + + + + + +Manner & Fu Informational [Page 32] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + 5.2.2. NSIS MUST support Path-Coupled and MAY Support Path- + Decoupled Signaling + + Standard RSVP is path-coupled, but the Subnet Bandwidth + Manager (SBM) work makes RSVP somewhat path-decoupled. + + 5.2.3. Concealment of Topology and Technology Information SHOULD + Be Possible + + RSVP itself does not provide such capability. + + 5.2.4. Transparent Signaling through Networks SHOULD Be Possible + + RSVP messages are intercepted and evaluated in each RSVP router, + and thus they may not cross certain RSVP-routers unnoticed. + Still, the message processing rules allow unknown RSVP messages + to be forwarded unharmed. + + 5.3. Messaging + + 5.3.1. Explicit Erasure of State MUST Be Possible + + Supported by the PathTear and ResvTear messages. + + 5.3.2. Automatic Release of State After Failure MUST Be Possible + + On error reservation states are torn down with PathTear + messages. + + 5.3.3. NSIS SHOULD Allow for Sending Notifications Upstream + + There are two notifications in RSVP, confirm of a reservation + set-up and tear down of reservation states as a result of + errors. + + 5.3.4. Establishment and Refusal To Set Up State MUST Be Notified + + PathErr and ResvErr messages provide refusal to set up state in + RSVP. + + 5.3.5. NSIS MUST Allow for Local Information Exchange + + RSVP NULL service type [RFC2997] provides such a feature. + + + + + + + + +Manner & Fu Informational [Page 33] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + 5.4. Control Information + + 5.4.1. Mutability Information on Parameters SHOULD Be Possible + + Rspec and Adspec are mutable; Tspec is (generally) end-to-end + not mutable. + + 5.4.2. It SHOULD Be Possible To Add and Remove Local Domain + Information + + RSVP aggregation [RFC3175] and NULL service type [RFC2997] can + provide such a feature. + + 5.4.3. State MUST Be Addressed Independent of Flow Identification + + RSVP states are tied to the flows, thus this requirement is not + met. + + 5.4.4. Modification of Already Established State SHOULD Be + Seamless + + Modifications of a reservation is possible with RSVP. + + 5.4.5. Grouping of Signaling for Several Micro-Flows MAY Be + Provided + + Aggregated RSVP and RFC2961 allow this. + + 5.5. Performance + + 5.5.1. Scalability + + RSVP scales linearly to the number of reservation states. + + 5.5.2. NSIS SHOULD Allow for Low Latency in Setup + + Setting up an RSVP reservation takes one round-trip time and the + processing times are each RSVP router. + + 5.5.3. NSIS MUST Allow for Low Bandwidth Consumption for the + Signaling Protocol + + The initial reservations messages can not be compressed, but the + refresh interval can be adjusted to consume less bandwidth, at + the expense of possible inefficient resource usage. + + + + + + +Manner & Fu Informational [Page 34] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + 5.5.4. NSIS SHOULD Allow To Constrain Load on Devices + + See discussions on RSVP performance (section 4). + + 5.5.5. NSIS SHOULD Target the Highest Possible Network + Utilization + + This depends on the IntServ service types, Controlled Load can + provide better overall utilization than Guaranteed Service. + + 5.6. Flexibility + + 5.6.1. Flow Aggregation + + Aggregated RSVP and RFC2961 allow this. + + 5.6.2. Flexibility in the Placement of the NSIS + Initiator/Responder + + RSVP allows receiver as initiator of reservations. + + 5.6.3. Flexibility in the Initiation of State Change + + RSVP receivers can initiate the state change during its + refreshment. + + 5.6.4. SHOULD Support Network-Initiated State Change + + As RSVP supports hop-by-hop refreshment, this is made possible. + + 5.6.5. Uni / Bi-Directional State Setup + + RSVP is only uni-directional. + + 5.7. Security + + 5.7.1. Authentication of Signaling Requests + + Authentication is available in RSVP. + + 5.7.2. Request Authorization + + Authorization with a PDP is possible in RSVP. + + 5.7.3. Integrity Protection + + The INTEGRITY Object is available in RSVP. + + + + +Manner & Fu Informational [Page 35] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + 5.7.4. Replay Protection + + The INTEGRITY Object to replay protect the content of the + signaling messages between two RSVP nodes. + + 5.7.5. Hop-By-Hop Security + + The RSVP security model works only hop-by-hop. + + 5.7.6. Identity Confidentiality and Network Topology Hiding + + The INTEGRITY Object can be used for this purpose. + + 5.7.7. Denial-Of-Service Attacks + + Challenging with RSVP. + + 5.7.8. Confidentiality of Signaling Messages + + Not supported by RSVP. + + 5.7.9. Ownership of State + + Challenging with RSVP. + + 5.8. Mobility + + 5.8.1. Allow Efficient Service Re-Establishment After Handover + + Works for upstream but may not be achieved for the downstream + if mobility is not noticed at the cross-over router. + + 5.9. Interworking with Other Protocols and Techniques + + 5.9.1. MUST Interwork with IP Tunneling + + RFC 2746 discusses these issues. + + 5.9.2. MUST NOT Constrain either to IPv4 or IPv6 + + RSVP supports both IP versions. + + 5.9.3. MUST Be Independent from Charging Model + + RSVP does not discuss this. + + + + + + +Manner & Fu Informational [Page 36] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + 5.9.4. SHOULD Provide Hooks for AAA Protocols + + COPS and RSVP work together. + + 5.9.5. SHOULD Work with Seamless Handoff Protocols + + Not supported by RSVP. Still, [RFC2205] suggests that route + changes should be indicated to the local RSVP daemon, which can + then initiate state refresh. + + 5.9.6. MUST Work with Traditional Routing + + RSVP expects traditional routing. + + 5.10. Operational + + 5.10.1. Ability to Assign Transport Quality to Signaling Messages + + This is a network design issue, but is possible with DiffServ. + + 5.10.2. Graceful Fail Over + + RSVP supports this. + + 5.10.3. Graceful Handling of NSIS Entity Problems + + RSVP itself does not supports this. + + + + + + + + + + + + + + + + + + + + + + + + +Manner & Fu Informational [Page 37] + +RFC 4094 Analysis of QoS Signaling May 2005 + + +13. Normative References + + [RFC3726] Brunner, M., "Requirements for Signaling Protocols", + RFC 3726, April 2004. + +14. Informative References + + [3GPP-TS23207] 3GPP TS 23.207 V5.6.0, End-to-end Quality of Service + (QoS) Concept and Architecture, Release 5, December + 2002. + + [BEBH96] Braden, R., Estrin, D., Berson, S., Herzog, and D. + Zappala, "The Design of the RSVP Protocol", ISI Final + Technical Report, July 1996. + + [BEGD02] Y. Bernet, N. Elfassy, S. Gai, and D. Dutt, "RSVP + Proxy", Work in Progress, March 2002. + + [BFM+96] A. Banerjea, D. Ferrari, B. Mah, M. Moran, D. Verma, + and H. Zhang, "The Tenet Real-Time Protocol Suite: + Design, Implementation, and Experiences", IEEE/ACM + Transactions on Networking, Volume 4, Issue 1, + February 1996, pp. 1-10. + + [BGRP] P. Pan, E, Hahne, and H. Schulzrinne, "BGRP: A Tree- + Based Aggregation Protocol for Inter-domain + Reservations", Journal of Communications and Networks, + Vol. 2, No. 2, June 2000, pp. 157-167. + + [Bless02] R. Bless, "Dynamic Aggregation of Reservations for + Internet Services", Proceedings of the Tenth + International Conference on Telecommunication Systems + - Modeling and Analysis (ICTSM 10), Vol. 1, pp. 26-38, + October 3-6 2002, Monterey, California, available at + http://www.tm.uka.de/doc/2003/ictsm-daris-journal- + crc-web.pdf. + + [Bless04] R. Bless, "Towards Scalable Management of QoS-based + End-to- End Services" (PDF), Proceedings of NOMS 2004 + (IEEE/IFIP 2004 Network Operations and Management + Symposium), April 2004, Seoul, Korea. + + [FAST-REROUTE] P. Pan, G. Swallow, and A. Atlas, "Fast Reroute + Extensions to RSVP-TE for LSP Tunnels", Work in + Progress, January 2004. + + + + + + +Manner & Fu Informational [Page 38] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + [FNM+99] G. Feher, K. Nemeth, M. Maliosz, I. Cselenyi, J. + Bergkvist, D. Ahlard, T. Engborg, "Boomerang A Simple + Protocol for Resource Reservation in IP Networks", + IEEE RTAS, 1999. + + [FNS02] G. Feher, K. Nemeth, and I. Cselenyi, "Performance + evaluation framework for IP resource reservation + signalling". Performance Evaluation 48 (2002), pp. + 131-156. + + [FJ02] P. Fransson and A. Jonsson, "The need for an + alternative to IPv4-options", in RVK (RadioVetenskap + och Kommunikation), Stockholm, Sweden, pp. 162-166, + June 2002. + + [Fu02] X. Fu, C. Kappler, and H. Tschofenig, "Analysis on + RSVP Regarding Multicast". Technical Report No. IFI- + TB-2002-001, ISSN 1611-1044, Institute for + Informatics, University of Goettingen, Oct 2002. + + [H.245] ITU-T Recommendation H.245, Control Protocol for + Multimedia Communication, July 2000. + + [H.323] ITU-T Recommendation H.323, Packet-based Multimedia + Communications Systems, Nov. 2000. + + [JR03] Jukka Manner, Kimmo Raatikainen, "Localized QoS + Management for Multimedia Applications in Wireless + Access Networks". IASTED International Conference on + Internet and Multimedia Systems and Applications (IMSA + 2003), August, 2003, pp. 193-200. + + [Kars01] M. Karsten, "Experimental Extensions to RSVP -- Remote + Client and One-Pass Signalling". IWQoS 2001, + Karlsruhe, Germany, June 2001. + + [KSS01] M. Karsten, Jens Schmitt, Ralf Steinmetz, + "Implementation and Evaluation of the KOM RSVP + Engine", IEEE Infocom 2001. + + [LGZC00] S. Lee, A. Gahng-Seop, X. Zhang, A. + Campbell,"INSIGNIA: An IP-Based Quality of Service + Framework for Mobile Ad Hoc Networks". Journal of + Parallel and Distributed Computing (Academic Press), + Special issue on Wireless and Mobile Computing and + Communications, Vol. 60, Number 4, April, 2000, pp. + 374-406. + + + + +Manner & Fu Informational [Page 39] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + [MA01] B. Moon, and H. Aghvami, "RSVP Extensions for Real- + Time Services in Wireless Mobile Networks". IEEE + Communications Magazine, December 2001, pp. 52-59. + + [MESZ94] D. Mitzel, D. Estrin, S. Shenker, and L. Zhang, "An + Architectural Comparison of ST-II and RSVP", Infocom + 1994. + + [MHS02] Y Miao, W. Hwang, and C. Shieh, "A transparent + deployment method of RSVP-aware applications on UNIX". + Computer Networks, 40 (2002), pp. 45-56. + + [MSK+04] J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K. + Raatikainen, "Localized RSVP", Work in Progress, + September 2004. + + [OVERLAY] G. Swallow, J. Drake, H. Ishimatsu, and Y. Rekhter, + "GMPLS UNI: RSVP Support for the Overlay Model", Work + in Progress, February 2004. + + [PS97] P. Pan and H. Schulzrinne, "Staged refresh timers for + RSVP", Global Internet, Phoenix, Arizona, November + 1997. + + [PS98] P. Pan, and H. Schulzrinne, "YESSIR: A Simple + Reservation Mechanism for the Internet". Proceedings + of NOSSDAV, Cambridge, UK, July 1998. + + [PS00] P. Pan, and H. Schulzrinne, "PF_IPOPTION: A kernel + extension for IP option packet processing", Technical + Memorandum 10009669-02TM, Bell Labs, Lucent + Technologies, Murray Hill, NJ, June 2000. + + [RFC1819] Delgrossi, L. and L. Berger, "Internet Stream Protocol + Version 2 (ST2) Protocol Specification - Version + ST2+", RFC 1819, August 1995. + + [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February + 1997. + + [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- + Version 1 Functional Specification", RFC 2205, + September 1997. + + [RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC + Data Flows", RFC 2207, September 1997. + + + + +Manner & Fu Informational [Page 40] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated + Services", RFC 2210, September 1997. + + [RFC2379] Berger, L., "RSVP over ATM Implementation Guidelines", + BCP 24, RFC 2379, August 1998. + + [RFC2380] Berger, L., "RSVP over ATM Implementation + Requirements", RFC 2380, August 1998. + + [RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang, + "RSVP Diagnostic Messages", RFC 2745, January 2000. + + [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. + Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, + January 2000. + + [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP + Cryptographic Authentication", RFC 2747, January 2000. + + [RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, + R., and A. Sastry, "COPS usage for RSVP", RFC 2749, + January 2000. + + [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC + 2750, January 2000. + + [RFC2814] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., and + M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol + for RSVP-based Admission Control over IEEE 802-style + networks", RFC 2814, May 2000. + + [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, + F., and S. Molendini, "RSVP Refresh Overhead Reduction + Extensions", RFC 2961, April 2001. + + [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC + 2996, November 2000. + + [RFC2997] Bernet, Y., Smith, A., and B. Davie, "Specification of + the Null Service Type", RFC 2997, November 2000. + + [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, + L., Speer, M., Braden, R., Davie, B., Wroclawski, J., + and E. Felstaine, "A Framework for Integrated Services + Operation over Diffserv Networks", RFC 2998, November + 2000. + + + + + +Manner & Fu Informational [Page 41] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. + Davie, "Aggregation of RSVP for IPv4 and IPv6 + Reservations", RFC 3175, September 2001. + + [RFC3181] Herzog, S., "Signaled Preemption Priority Policy + Element", RFC 3181, October 2001 + + [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, + T., Herzog, S., and R. Hess, "Identity Representation + for RSVP", RFC 3182, October 2001. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, + V., and G. Swallow, "RSVP-TE: Extensions to RSVP for + LSP Tunnels", RFC 3209, December 2001. + + [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., + Vaananen, P., Krishnan, R., Cheval, P., and J. + Heinanen, "Multi-Protocol Label Switching (MPLS) + Support of Differentiated Services", RFC 3270, May + 2002. + + [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., + and A. Rayhan, "Middlebox communication architecture + and framework", RFC 3303, August 2002. + + [RFC3473] Berger, L., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", + RFC 3473, January 2003. + + [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered + Links in Resource ReSerVation Protocol - Traffic + Engineering (RSVP-TE)", RFC 3477, January 2003. + + [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, + "Session Authorization Policy Element", RFC 3520, + April 2003. + + [SGV02] R. Sofia, R. Guerin, and P. Veiga, "An Investigation + of Inter-Domain Control Aggregation Procedures", + International Conference on Networking Protocols, ICNP + 2002, Paris, France, November 2002. + + [SGV03] R. Sofia, R. Guerin, and P. Veiga. SICAP, a Shared- + segment Inter-domain Control Aggregation Protocol. + High Performance Switching and Routing, HPSR 2003, + Turin, Italy, June 2003. + + + + +Manner & Fu Informational [Page 42] + +RFC 4094 Analysis of QoS Signaling May 2005 + + + [SGV03b] R. Sofia, R. Guerin, and P. Veiga. A Study of Over- + reservation for Inter-Domain Control Aggregation + Protocols. Technical report (short version under + submission), University of Pennsylvania, May 2003, + available at http://einstein.seas.upenn.edu/mnlab/ + publications.html. + + [TBA01] A. Talukdar, B. Badrinath, and A. Acharya, "MRSVP: A + Resource Reservation Protocol for an Integrated + Services Network with Mobile Hosts", Wireless + Networks, vol. 7, no. 1, pp. 5-19, 2001. + + [Thom02] M. Thomas, "Analysis of Mobile IP and RSVP + Interactions", Work in Progress, October 2002. + + [Tsch03] H. Tschofenig, "RSVP Security Properties", Work in + Progress, February 2004. + + [ZDSZ93] L. Zhang, S. Deering, D. Estrin, and D. Zappala, + "RSVP: A New Resource Reservation Protocol", IEEE + Network, Volume 7, Pages 8-18, September 1993. + + [URL1] http://www.atm.tut.fi/list-archive/diffserv/thrd3.html + + [URL2] OPENSIG http://comet.columbia.edu/opensig/ + + [URL3] SIGLITE http://www1.cs.columbia.edu/~pingpan/projects/ + siglite.html + + + + + + + + + + + + + + + + + + + + + + + +Manner & Fu Informational [Page 43] + +RFC 4094 Analysis of QoS Signaling May 2005 + + +Authors' Addresses + + Jukka Manner + Department of Computer Science + University of Helsinki + P.O. Box 68 (Gustav Hallstrominkatu 2b) + FIN-00014 HELSINKI + Finland + + Phone: +358-9-191-51298 + Fax: +358-9-191-51120 + EMail: jmanner@cs.helsinki.fi + + + Xiaoming Fu + Institute for Informatics + Georg-August-University of Goettingen + Lotzestrasse 16-18 + 37083 Goettingen + Germany + + Phone: +49-551-39-14411 + Fax: +49-551-39-14403 + EMail: fu@cs.uni-goettingen.de + + + + + + + + + + + + + + + + + + + + + + + + + + + +Manner & Fu Informational [Page 44] + +RFC 4094 Analysis of QoS Signaling May 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. + + + + + + + +Manner & Fu Informational [Page 45] + |