idnits 2.17.1 draft-ietf-nsis-signalling-analysis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RFC3474], [Berg02], [RFC3477], [RSVP-TRANS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 477: '...L_REQUEST object MUST be ready to acce...' RFC 2119 keyword, line 1685: '... 5.1.1 NSIS SHOULD provide availa...' RFC 2119 keyword, line 1691: '... 5.1.2 NSIS MUST be designed modu...' RFC 2119 keyword, line 1697: '... 5.1.3 NSIS MUST decouple protoco...' RFC 2119 keyword, line 1703: '... 5.1.4 NSIS MUST support independ...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RSVP-TRANS' is mentioned on line 58, but not defined == Missing Reference: 'Berg02' is mentioned on line 66, but not defined == Unused Reference: 'BGP4' is defined on line 1437, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 1592, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3726 == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-23 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-01 -- No information found for draft-ietf-ccamp-gmpls-overlay- - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2751 (Obsoleted by RFC 3181) -- Obsolete informational reference (is this intentional?): RFC 2752 (Obsoleted by RFC 3182) -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-06) exists of draft-ietf-nsis-rsvp-sec-properties-04 Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Manner (ed.) 3 Internet-Draft X. Fu 4 Expires: November, 2004 P. Pan 5 May, 2004 7 Analysis of Existing Quality of Service Signaling Protocols 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 This Internet-Draft will expire in November, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2000). All Rights Reserved. 37 All comments to this work should be directed to the NSIS mailing at 38 nsis@ietf.org. 40 Abstract 42 This document reviews some of the existing QoS signaling protocols 43 for an IP network. The goal here is to learn from them and to avoid 44 common misconceptions. Further, we need to avoid the mistakes during 45 the design and the implementation of any new protocol in this area. 47 Changes since -03 48 - Removed subjective comments about using TCP with RSVP in Section 3 49 - Updated the parts about RSVP and MPLS as suggested by 50 Kompella & Farrel 51 - Checked and updated references 53 Changes since -02 54 - Various editorial changes 55 - Added SICAP and DARIS 57 Changes since -01 58 - Merged with [RSVP-TRANS], 59 - Added a very preliminary Appendix that compares RSVP to the NSIS 60 requirements, 61 - Restructured the document for easier reading, and 62 - Minor reference updates. 64 Changes since -00 65 - More text on RFC2207, 2961, 3175, 3209, 66 - Added [Berg02], [RFC3477], [RFC3474], RFC2379, 2380 and extensions 67 proposed by ITU-T, OIF, 3GPP, 68 - Re-wrote text on RSVP processing overhead, 69 - Updated text on RSVP security, 70 - Removed section on ITSUMO as it was mostly an architectural 71 discussion, rather than a protocol review, 72 - Updates various other parts of the document based on feedback, 73 - Re-structured the document. 75 Table of Contents 77 1 Background ................................................... 4 78 2 RSVP and RSVP Extensions ..................................... 5 79 2.1 Basic Design ............................................... 5 80 2.2 RSVP Extensions ............................................ 6 81 2.2.1 Simple Tunneling ......................................... 7 82 2.2.2 IPSEC Interface .......................................... 7 83 2.2.3 Policy Interface ......................................... 7 84 2.2.4 Refresh Reduction ........................................ 8 85 2.2.5 RSVP over RSVP ........................................... 8 86 2.2.6 IEEE 802-style LAN Interface ............................. 9 87 2.2.7 ATM Interface ............................................ 9 88 2.2.8 DiffServ Interface ....................................... 9 89 2.2.9 Null Service Type ........................................ 9 90 2.2.10 MPLS Traffic Engineering ................................ 10 91 2.2.11 GMPLS and RSVP-TE ....................................... 11 92 2.2.12 GMPLS Operation at UNI and E-NNI Reference Points ....... 12 93 2.2.13 MPLS and GMPLS Future Extensions ........................ 12 94 2.2.14 ITU-T H.323 Interface ................................... 12 95 2.2.15 3GPP Interface .......................................... 13 96 2.3 Extensions For New Deployment Scenarios .................... 13 97 2.4 Conclusion ................................................. 14 98 3 RSVP Transport Mechanism Issues .............................. 15 99 3.1 Messaging Reliability ...................................... 15 100 3.2 Message Packing ............................................ 16 101 3.3 MTU Problem ................................................ 16 102 3.4 RSVP-TE vs. Signaling Protocol for RT Applications ......... 17 103 3.5 What will be a better alternative? ........................ 17 104 4 RSVP Protocol Performance Issues ............................. 18 105 4.1 Processing Overhead ........................................ 18 106 4.2 Bandwidth Consumption ...................................... 19 107 5 RSVP Security and Mobility ................................... 19 108 5.1 Security ................................................... 19 109 5.2 Mobility Support ........................................... 20 110 6 Other QoS Signaling Proposals ................................ 21 111 6.1 Tenet and ST-II ............................................ 21 112 6.2 YESSIR ..................................................... 22 113 6.2.1 Reservation Functionality ................................ 22 114 6.2.2 Conclusion ............................................... 23 115 6.3 Boomerang .................................................. 23 116 6.3.1 Reservation Functionality ................................ 23 117 6.3.2 Conclusions .............................................. 24 118 6.4 INSIGNIA ................................................... 24 119 7 Inter-domain Signaling ....................................... 25 120 7.1 BGRP ....................................................... 25 121 7.2 SICAP ...................................................... 25 122 7.3 DARIS ...................................................... 26 123 8 Security Considerations ...................................... 27 124 9 Summary ...................................................... 27 125 10 Contributors ................................................ 28 126 11 Acknowledgment .............................................. 28 127 12 Normative References ........................................ 28 128 13 Non-Normative References .................................... 28 129 14 Authors' Information ........................................ 33 130 15 Appendix A - Comparison of RSVP to the NSIS Requirements 132 1. Background 134 This document reviews some of the existing QoS signaling protocols 135 for an IP network. The goal here is to learn from them and to avoid 136 common misconceptions. Further, we need to avoid the mistakes during 137 the design and the implementation of any new protocol in this area. 139 There have been a number of historic attempts in delivering QoS or 140 generic signaling into the Internet. In the early years, multicast 141 was believed to be going to be popular for the majority of 142 communications, hence, both RSVP and earlier ST-II were designed in a 143 way which is multicast-oriented. 145 ST-II was developed as a reservation protocol for point-to-multipoint 146 communication. However, since it is sender-initiated, it does not 147 scale with the number of receivers in a multicast group. Its 148 processing is fairly complex. Since every sender needs to set up its 149 own reservation, the total amount of reservation states is large. 150 RSVP was then designed to provide support for multipoint-to- 151 multipoint reservation setup in a more efficient way, however its 152 complexity, scalability and ability to meet new requirements have 153 been criticized. 155 YESSIR [PS98] and Boomerang [FNM+99] are examples of protocols 156 designed after RSVP. Both protocols were meant to be simpler than 157 RSVP. YESSIR is an extension to RTCP, while Boomerang is used with 158 ICMP. 160 Previously, there has been a lot of work targeted at creating a new 161 signaling protocol for resource control. Istvan Cselenyi suggested 162 to request for QoSSIG BOF in IETF#47 (http://www-nrg.ee.lbl.gov/diff- 163 serv-arch/msg05055.html), for identifying problems in QoS signaling, 164 but failed. Some people argued, "in many ways, RSVP improved upon 165 ST-2, and it did start out simpler, but resulting a design with 166 complexity and scalability", while some others thought it is "new 167 knowledge and requirements" that made RSVP insufficient (http://www- 168 nrg.ee.lbl.gov/diff-serv-arch/msg05066.html), and there is no simpler 169 way to handle the same problem as RSVP. 171 Michael Welzl organized a special session "ABR to the Internet" in 172 SCI 2001, and gathered some inputs for requesting an "ABR to the 173 Internet" BOF in IETF#51, which was intended to introduce explicit 174 rate feedback related mechanisms for the Internet (e2e, edge2edge) 175 but failed because of "missing community interest". 177 OPENSIG (http://comet.columbia.edu/opensig/) has been involved in the 178 Internet signaling for years. Ping Pan initiated a SIGLITE 179 (http://www.cs.columbia.edu/~pingpan/projects/siglite.html) BOF 180 mailing list to investigate light-weight Internet signaling. Finally, 181 NSIS BOF was successful and the NSIS WG was formed. 183 The most mature and original protocols are presented in their own 184 sections and other QoS signaling protocols are presented in later 185 subsections. The presented protocols are chosen based on relevance to 186 the work within NSIS. The aim is not to review every existing 187 protocol. 189 2. RSVP and RSVP Extensions 191 RSVP (the Resource Reservation Protocol) [ZDSZ93] [RFC2205] [BEBH96] 192 has evolved from ST-II to provide end-to-end QoS signaling services 193 for application data streams. Hosts use RSVP to request a specific 194 quality of service (QoS) from the network for particular application 195 flows. Routers use RSVP to deliver QoS requests to all routers along 196 the data path. RSVP also can maintain and refresh states for a 197 requested QoS application flow. 199 By original design, RSVP fits well into the framework of the 200 Integrated Services (IntServ) [RFC2210] [BEBH96] with certain 201 modularity and scalability. 203 RSVP carries QoS signaling messages through the network, visiting 204 each node along the data path. To make a resource reservation at a 205 node, the RSVP module communicates with two local decision modules, 206 admission control and policy control. Admission control determines 207 whether the node has sufficient available resources to supply the 208 requested QoS. Policy control provides authorization for the QoS 209 request. If either check fails, the RSVP module returns an error 210 notification to the application process that originated the request. 211 If both checks succeed, the RSVP module sets parameters in a packet 212 classifier and packet scheduler to obtain the desired QoS. 214 2.1. Basic Design 216 The design of RSVP distinguished itself by a number of fundamental 217 ways, particularly, soft state management, two-pass signaling message 218 exchanges, receiver-based resource reservation and separation of QoS 219 signaling from routing. 221 Signaling Model: The RSVP signaling model is based on a special 222 handling of multicast. The sender of a multicast flow advertises the 223 traffic characteristics periodically to the receivers via "Path" 224 messages. On receipt of an advertisement, a receiver may generate a 225 "Resv" message to reserve resources along the flow path from the 226 sender. Receiver reservations may be heterogeneous. To accommodate 227 the multipoint-to-multipoint multicast applications, RSVP was 228 designed to support a vector of reservation attributes called the 229 "style". A style describes whether all senders of a multicast group 230 share a single reservation and which receiver is applied. The "Scope" 231 object additionally provides the explicit list of senders. 233 Soft State: Because the number of receivers in a multicast flow is 234 likely to change, and the flow of delivery paths might change during 235 the life of an application flow, RSVP takes a soft-state approach in 236 its design, creating and removing the protocol states (Path and Resv 237 states) in routers and hosts incrementally over time. RSVP sends 238 periodic refresh messages (Path and Resv) to maintain its states and 239 to recover from occasional lost messages. In the absence of refresh 240 messages, the RSVP states automatically time out and are deleted. 241 States may also be deleted explicitly by PathTear, PathErr with 242 Path_State_Removed flag, or ResvTear Message. 244 Two-pass Signaling Message Exchanges: The receiver in an application 245 flow is responsible for requesting the desired QoS from the sender. 246 To do this, the receiver issues an RSVP QoS request on behalf of the 247 local application. The request propagates to all routers in reverse 248 direction of the data paths toward the sender. In this process, RSVP 249 requests might be merged, resulting in a protocol that scales well 250 when there are a large number of receivers. 252 Receiver-based Resource Reservation: Receiver-initiation is critical 253 for RSVP to setup multicast sessions with a large number of 254 heterogeneous receivers. A receiver initiates a reservation request 255 at a leaf of the multicast distribution tree, traveling toward the 256 sender. Whenever a reservation is found to already exist in a node in 257 the distribution tree, the new request will be merged with the 258 existing reservation. This could result in fewer signaling operations 259 for the RSVP nodes in the multicast tree close to the sender, but 260 introduce a restriction to receiver-initiation. 262 Separation of QoS Signaling from Routing: RSVP messages follow normal 263 IP routing. RSVP is not a routing protocol, but rather is designed to 264 operate with current and future unicast and multicast routing 265 protocols. The routing protocols are responsible for choosing the 266 routes to use to forward packets, and RSVP consults local routing 267 tables to obtain routes. RSVP is responsible only for reservation 268 setup along a data path. 270 A number of messages and objects have been defined for the protocol. 271 A detailed description is given in [RFC2205]. 273 2.2. RSVP Extensions 275 RSVP [RFC2205] was originally designed to support real-time 276 applications over the Internet. Over the past several years, the 277 demand for multicast-capable real-time teleconferencing, which many 278 people had envisioned to be one of the key Internet applications that 279 could benefit from network-wide deployment of RSVP, has never 280 materialized. Instead, RSVP-TE [RFC3209], a RSVP extension for 281 traffic engineering, has been widely deployed by a large number of 282 network providers to support MPLS applications. 284 There are a large number of protocol extensions based on RSVP. Some 285 provide additional features, such as security and scalability, to the 286 original protocol. Some introduce additional interfaces to other 287 services, such as DiffServ. And some simply define new applications, 288 such as MPLS and GMPLS, that are completely irrelevant from 289 protocol's original intent. 291 In this section, we list only IETF-based RFCs and a limited set of 292 other organizations' specifications. Informational RFCs (e.g., 293 RFC2998 [RFC2998]) and work-in-progress I-Ds (e.g., proxy) are not 294 covered here. 296 2.2.1. Simple Tunneling 298 [RFC2746] describes an IP tunneling enhancement mechanism that allows 299 RSVP to make reservations across all IP-in-IP tunnels, basically, by 300 way of recursively applying RSVP over the tunnel portion of the path. 302 2.2.2. IPSEC Interface 304 RSVP can support IPsec on a per address, per protocol basis instead 305 of on a per flow basis. [RFC2207] extends RSVP by using the IPSEC 306 Security Parameter Index (SPI) in place of the UDP/TCP-like ports. 307 This introduces a new FILTER_SPEC object, which contains the IPSEC 308 SPI, and a new SESSION object. 310 2.2.3. Policy Interface 312 [RFC2750] specifies the format of POLICY_DATA objects and RSVP 313 handling of policy events. It introduces objects which are 314 interpreted only by policy aware nodes (PEPs) which interact with 315 policy decision points (PDPs). Nodes which are unable to interpret 316 the POLICY_DATA objects are called policy ignorant nodes (PINs). The 317 content of the POLICY_DATA object itself is protected only between 318 PEPs and therefore provides end-to-middle or middle-to-middle 319 security. 321 [RFC2749] specifies the usage of COPS policy services in RSVP 322 environments. [RFC2751] specifies a preemption priority policy 323 element (PREEMPTION_PRI) for use by RSVP POLICY_DATA Object. 324 [RFC3520] describes how authorization provided by a separate protocol 325 (such as SIP) can be reused with the help of an authorization token 326 within RSVP. The token might therefore contain either the authorized 327 information itself (e.g. QoS parameters) or a reference to those 328 values. The token might be unprotected (which is strongly 329 discouraged) or protected based on symmetric or asymmetric 330 cryptography. Moreover, the document describes how to provide the 331 host with encoded session authorization information as a POLICY_DATA 332 object. 334 2.2.4. Refresh Reduction 336 [RFC2961] describes mechanisms to reduce processing overhead 337 requirements of refresh messages, eliminate the state synchronization 338 latency incurred when an RSVP message is lost and, refreshing state 339 without the transmission of whole refresh messages. It defines the 340 following objects: MESSAGE_ID, MESSAGE_ID_ACK, MESSAGE_ID_NACK, 341 MESSAGE_ID LIST, MESSAGE_ID SRC_LIST and MESSAGE_ID MCAST_LIST 342 objects. Three new RSVP message types are defined: 344 1) Bundle message, which consists of a bundle header followed by a 345 body consisting one or more standard RSVP messages. Bundle messages 346 help in scaling RSVP in reducing processing overhead and bandwidth 347 consumption. 349 2) ACK message, which carries one or more MESSAGE_ID_ACK or 350 MESSAGE_ID_NACK objects. ACK messages are sent between neighboring 351 RSVP nodes to detect message loss and support reliable RSVP message 352 delivery on a per hop basis. 354 3) Srefresh message, which carries one or more MESSAGE_ID LIST, 355 MESSAGE_ID SRC_LIST and MESSAGE_ID MCAST_LIST objects. correspondent 356 to Path and Resv messages that establish the states. Srefresh 357 messages are used to refresh RSVP states without transmitting 358 standard Path or Resv messages. 360 2.2.5. RSVP over RSVP 362 [RFC3175] allows to install one or more aggregated reservations in an 363 aggregation region, thus the number of individual RSVP sessions can 364 be reduced. The protocol type is swapped from RSVP to RSVP-E2E-IGNORE 365 in E2E (standard) Path, PathTear and ResvConf messages when they 366 enter the aggregation region, and swapped back when they leave. In 367 addition to a new PathErr code (NEW_AGGREGATE_NEEDED), three new 368 objects are introduced: 370 1) SESSION object, which contains two values: the IP Address of the 371 aggregate session destination, and the DSCP that it will use on the 372 E2E data the reservation contains. 374 2) SENDER_TEMPLATE object, which identifies the aggregating router 375 for the aggregate reservation. 377 3) FILTER_SPEC object, which identifies the aggregating router for 378 the aggregate reservation, and is syntactically identical to the 379 SENDER_TEMPLATE object. 381 From the perspective of RSVP signaling and the handling of data 382 packets in the aggregation region, these cases are equivalent to the 383 case of aggregating E2E RSVP reservations. The only difference is 384 that E2E RSVP signaling does not take place and cannot therefore be 385 used as a trigger, so some additional knowledge is required in 386 setting up the aggregate reservation. 388 2.2.6. IEEE 802-style LAN Interface 390 [RFC2814] introduces an RSVP LAN_NHOP address object that keeps track 391 of the next L3 hop as the PATH message traverses an L2 domain between 392 two L3 entities (RSVP PHOP and NHOP nodes). Both layer-2 and layer-3 393 addresses are included in the LAN_NHOP; the RSVP_HOP_L2 object is 394 used to include the Layer 2 address (L2ADDR) of the previous hop, 395 complementing the L3 address information included in the RSVP_HOP 396 object (RSVP_HOP_L3 address). 398 To provide sufficient information for debugging or resource 399 management, RSVP diagnostic messages (DREQ and DREP) are defined in 400 [RFC2745] to collect and report RSVP state information along the path 401 from a receiver to a specific sender. 403 2.2.7. ATM Interface 405 [RFC2379] and [RFC2380] define RSVP over ATM implementation 406 guidelines and requirements to interwork with the ATM (Forum) UNI 407 3.x/4.0. [RFC2380] states that the RSVP (control) messages and RSVP 408 associated data packets must not be sent on the same VCs, and an 409 explicit release of RSVP associated QoS VCs must be performed once 410 the VC for forwarding RSVP control messages terminated. While a 411 separate control VC is also possible for forwarding RSVP control 412 messages, [RFC2379] recommends to create a best-effort short-cut (a 413 short-cut is a point-to-point VC where the two end-points locate in 414 different IP subnets) first (if not exist), which can allow setting 415 up RSVP triggered VCs to use the best-effort end-point. For data 416 flows, the subnet senders must establish all QoS VCs and the RSVP 417 enabled subnet receiver must be able to accept incoming QoS VCs. RSVP 418 must request the configurable inactivity timers of VCs be set to 419 "infinite", and if it is too complex to do this at the VC receiver, 420 RSVP over ATM implementations are required not to use an inactivity 421 timer to clear any received connections. In case of dynamic QoS, the 422 replacement of VC should be done gracefully. 424 2.2.8. DiffServ Interface 426 RFC2996 [RFC2996] introduces a DCLASS Object to carry Differentiated 427 Services Code Points (DSCPs) in RSVP message objects. If the network 428 element determines that the RSVP request is admissible to the 429 DiffServ network, one or more DSCPs corresponding to the behavior 430 aggregate are determined, and will be carried by the DCLASS Object 431 added to the RESV message upstream toward the RSVP sender. 433 2.2.9. Null Service Type 435 For some applications, service parameters are specified by the 436 network, not by the application (e.g. ERP applications). The Null 437 Service [RFC2997] allows applications to identify themselves to 438 network QoS policy agents using RSVP signaling, but does not require 439 them to specify resource requirements. QoS policy agents in the 440 network respond by applying QoS policies appropriate for the 441 application (as determined by the network administrator). The RSVP 442 sender offers the new service type, 'Null Service Type' in the ADSPEC 443 that is included with the PATH message. A new TSPEC corresponding to 444 the new service type is added to the SENDER_TSPEC. In addition, the 445 RSVP sender will typically include with the PATH message policy 446 objects identifying the user, application and sub-flow, which will be 447 used for network nodes to manage the correspondent traffic flow. 449 2.2.10. MPLS Traffic Engineering 451 RSVP-TE [RFC3209] specifies the core extensions to RSVP for 452 establishing constraint-based explicitly routed LSPs in MPLS networks 453 using RSVP as a signaling protocol. RSVP-TE is intended for use by 454 label switching routers (as well as hosts) to establish and maintain 455 LSP-tunnels and to reserve network resources for such LSP-tunnels. 457 RFC3209 defines a new Hello message (for rapid node failure 458 detection). 460 RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and 461 LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC 462 objects. Here a session is the association of LSPs that support the 463 LSP-tunnel. The traffic on an LSP can be classified as the set of 464 packets that are assigned the same MPLS label value at the 465 originating node of an LSP-tunnel. 467 The following 5 new objects are also defined. 469 1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path 470 messages, encapsulating a concatenation of hops which constitutes the 471 explicitly routed path. Using this object, the paths taken by label- 472 switched RSVP-MPLS flows can be pre-determined, independent of 473 conventional IP routing. 475 2) LABEL_REQUEST object. To establish an LSP tunnel, the sender can 476 create a Path message with a LABEL_REQUEST object. A node that sends 477 a LABEL_REQUEST object MUST be ready to accept and correctly process 478 a LABEL object in the corresponding Resv messages. 480 3) LABEL object. Each node that receives a Resv message containing a 481 LABEL object uses that label for outgoing traffic associated with 482 this LSP tunnel. 484 4) SESSION_ATTRIBUTE object, which can be added to Path messages to 485 aid in session identification and diagnostics. Additional control 486 information, such as setup and holding priorities, resource 487 affinities and local-protection, are also included in this object. 489 5) RECORD_ROUTE object (RRO). The RECORD_ROUTE object may appear in 490 both Path and Resv messages. It is used to collect detailed path 491 information and is useful for loop detection and for diagnostics. 493 Section 5 of [RFC3270] further specifies the extensions to RSVP to 494 establish LSPs supporting DiffServ in MPLS networks, introducing a 495 new DIFFSERV Object (applicable in the Path messages) and using pre- 496 configured or (e.g. RFC3270) signaled "EXP<-->PHB mapping". 498 RSVP-TE provides a way to indicate an unnumbered link in its Explicit 499 Route and Record Route Objects through [RFC3477]. This specifies the 500 following extensions. 502 - An Unnumbered Interface ID Subobject, which is a subobject of the 503 Explicit Route Object (ERO) used to specify unnumbered links; 505 - An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to 506 form or use an identifier for an unnumbered Forwarding Adjacency; 508 - A new subobject of the Record Route Object, used to record that the 509 LSP path traversed an unnumbered link. 511 2.2.11. GMPLS and RSVP-TE 513 GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE. It enables the 514 provisioning of data-paths within networks supporting a variety of 515 switching types including packet and cell switching networks, layer 516 two networks, TDM networks and photonic networks. 518 It defines the new Notify message (for general event notification), 519 which may contain notifications being sent, with respect to each 520 listed LSP, both upstream and downstream. Notify messages can be used 521 for expedited notification of failures and other events to nodes 522 responsible for restoring failed LSPs. A Notify message is sent 523 without the router alert option. 525 A number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for 526 general uses of MPLS: 528 - a Generalized Label Request Object; 529 - a Generalized Label Object; 530 - a Suggested Label Object; 531 - a Label Set Object; (to restrict label choice) 532 - an Upstream_Label object; (to support bi-directional LSPs) 533 - a Label ERO subobject; 534 - IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in 535 out of band signaling or in bundled links); 536 - IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify interfaces in 537 out of band signaling or in bundled links); 538 - an Acceptable Label Set object (to support negotiation of label 539 values in particular for bidirecitonal LSPs) 540 - a Notify Request object (may be inserted in a Path or Resv message 541 to indicate to where a notification of LSP failure is to be sent) 542 - a Restart_Cap Object (used on Hello messages to identify recovery 543 capabilities) 544 - an Admin Status Object (to notify each node along the path of the 545 status of the LSP, and to control that state). 547 2.2.12. GMPLS Operation at UNI and E-NNI Reference Points 549 The ITU-T defines nework reference points that separate 550 administrative or operational parts of the network. The reference 551 points are designated as: 553 - User to Network Interfaces (UNIs) if they lie between the user 554 or user network and the core network. 555 - External Network to Network Interfaces (E-NNIs) if they lie 556 between peer networks, network domains, or subnetworks. 558 GMPLS is applicable to the UNI and E-NNI without further 559 modification, and no new messages, objects or C-Types are required. 560 See [OVERLAY]. 562 2.2.13. MPLS and GMPLS Future Extensions 564 At the time of writing MPLS and GMPLS are being extended by the MPLS 565 and CCAMP Working Groups to support additional sophisticated 566 functions. This will inevitably lead to the introduction of new C- 567 Types for existing objects, and to the requirement for new objects 568 (CNums). It is possible that new messages will also be introduced. 570 Some of the key features and functions being introduced include: 572 - Protection and restoration. Features will be developed to provide 573 - end-to-end protection 574 - segment protection 575 - various protection schemes (1+1, 1:1, 1:n) 576 - support of extra traffic on backup LSPs 577 - Diverse path establishment for protection and load sharing 578 - Point-to-mulitpoint path establishment 579 - Inter-area and inter-AS path establishment 580 - with explicit path control 581 - with bandwidth reservation 582 - with path diversity 583 - Support for the requirements of ASON signaling as defined by the 584 ITU-T, including call and connection separation 585 - Crankback during LSP setup. 587 2.2.14. ITU-T H.323 Interface 589 ITU-T H.323 ([H.323]) recommends the IntServ resource reservation 590 procedure using RSVP. The information whether an endpoint supports 591 RSVP should be conveyed during the H.245 [H.245] capability exchange 592 phase, by setting appropriate qOSMode fields. If both endpoints are 593 RSVP-capable, when opening an H.245 logical channel, a receiver port 594 ID should be conveyed to the sender by the openLogicalChannelAck 595 message. Only after that, can a "Path - Resv - ResvConf" process 596 take place. The timer of waiting for ResvConf message will be set by 597 the endpoint. The action in case of this timer expires, as well as 598 RSVP reservation fails in any point during an H.323 call, is up to 599 the vendor to take. Once a ResvConf message is sent or received, the 600 endpoints should stop reservation timers and resume with the H.323 601 call procedures. Only explicit release of reservations are supported 602 in [H.323]: before sending a closeLogicalChannel message for a 603 stream, a sender should send a PathTear message if an RSVP session 604 has been previous created for that stream; after receiving a 605 closeLogicalChannel, a receiver should send a ResvTear similarly. 606 Only the FF style is supported, even for point-to-multipoint calls. 608 2.2.15. 3GPP Interface 610 3GPP TS 23.207 ([3GPP-TS23207]) specifies the QoS signaling procedure 611 with policy control within the UMTS end-to-end QoS architecture. When 612 using RSVP, the signaling source and/or destination are the User 613 Equipments (UEs, devices that allow users access to network services) 614 that locate in the Mobile Originating (MO) side and the Mobile 615 Terminating (MT) side, and an RSVP signaling process can either 616 trigger or be triggered by the (COPS) PDP Context 617 establishment/modification process. The operation of refreshing 618 states is not specified in [3GPP-TS23207]. If bidirectional 619 reservation is needed, the RSVP signaling should be proceeded twice 620 between the signaling source and the destination. The authorization 621 token and flow identifier(s) in a policy data object should be 622 included in the RSVP messages sent by the UE, if the token is 623 available in the UE. When both RSVP and Service-based Local Policy 624 are used, the Gateway GPRS Support Node (GGSN, the access point of 625 the network) should use the policy information to decide whether to 626 accept and forward Path/Resv messages. 628 2.3. Extensions For New Deployment Scenarios 630 As a well-acknowledged protocol in the Internet, RSVP is being more 631 and more expected to provide a more generic service for various 632 signaling applications. However, RSVP messages were designed in a way 633 to optimally support end-to-end QoS signaling. To meet with the 634 increasing demand for a signaling protocol to also operate in host- 635 to-edge and edge-to-edge ways, and serve for some other signaling 636 purposes in addition to end-to-end QoS signaling, RSVP needs to be 637 developed more flexible and applicable for more generic signaling. 639 RSVP proxies [BEGD02] extends RSVP by being able to originates or 640 receive the RSVP message on behalf of the end node(s), so that 641 applications may still benefit from reservations that are not truly 642 end-to-end. However, there are certainly scenarios where an 643 application would want to explicitly convey its non-QoS purposed (as 644 well as QoS) data from a host into the network, or from an ingress 645 node to an egress node of an administrative domain, but it must do so 646 without burdening the network with excess messaging overhead. Typical 647 examples are an end host desiring a firewall service from its 648 provider's network and MPLS label setup within an MPLS domain. 650 RSVP requires support from network routers and user space 651 applications. Domains not supporting RSVP are traversed 652 transparently. Unfortunately, like other IP options, RSVP messages 653 implemented by way of IP alert option may result in themselves being 654 dropped by some routers [FJ02]. Although applications need to be 655 built with RSVP libraries, one article presents a mechanism that 656 would allow any host to benefit from RSVP mechanisms without 657 applications awareness [MHS02]. 659 A somewhat similar deployment benefit can be gained from the 660 Localized RSVP (LRSVP) [JR03] [MSK+04]. The documents present the 661 concept of local RSVP-based reservation that can be used to trigger 662 reservation within an access network alone. In those cases, an end- 663 host may request QoS from its own access network without the co- 664 operation of a correspondent node outside the access network - this 665 would be especially helpful when the correspondent node is unaware of 666 RSVP. A proxy node responds to the messages sent by the end host and 667 enables both upstream and downstream reservations. Furthermore, the 668 scheme allows for faster reservation repairs following a handover by 669 triggering the proxy to assist in an RSVP local repair. 671 Still, in end-hosts which are low in processing power and 672 functionality, having an RSVP daemon running and taking care of the 673 signaling may introduce unnecessary overhead. One article [Kars01] 674 proposes to create a remote API so that the daemon would in fact be 675 running on the end-host's default router and the end-host application 676 would send its requests to that daemon. 678 Another potential problem lies in the limited sized of signaled data 679 due to the limitation of message size. RSVP message must fit entirely 680 into a single non-fragmented IP datagram. Bundle messages [RFC2961] 681 can aggregate multiple RSVP messages within a single PDU, but still 682 only occupy one IP datagram (i.e., approximately 64K); if it exceeds 683 the MTU, the datagram is fragmented by IP and reassembled at the 684 recipient node. 686 2.4. Conclusion 688 A good signaling protocol should be transparent or oblivious to the 689 applications. RSVP has proven to be a very well designed protocol. 690 However, it has a number of fundamental protocol design issues that 691 requires more careful re-evaluation. 693 The design of RSVP was originally targeted at multicast applications. 694 The result has been that the message processing within nodes is 695 somewhat heavy, mainly due to flow merging. Still, merging rules 696 should not appear in the specification as they are QoS-specific. 698 RSVP has a comprehensive set of filtering rules (WF,FF, shared) and 699 is not tied to certain QoS objects (RSVP is not tied to IntServ GS/CL 700 specifications). Objects were designed to be modular, but Xspecs 701 (TSPEC, etc) are more or less QoS-specific and should be more 702 generalized; there is no clear layering/separation between the 703 signaled data and signaling protocol. 705 RSVP uses a soft state mechanism to maintain states and allows each 706 node to define its own refresh timer. The protocol is also 707 independent of underlying routing protocols. Still, in mobile 708 networks the movement of the mobile nodes may not properly trigger a 709 reservation refresh for the new path and therefore a mobile node may 710 be left without a reservation up to the length of the refresh timer. 711 Furthermore, RSVP does not work properly with changing end-point 712 identifiers, that is, if one of the IP addresses of a mobile node 713 changes, the filters may not be able to identify the flow that had a 714 reservation. 716 From the security point of view, RSVP does provide the basic building 717 blocks for deploying the protocol in various environments to protect 718 its messages from forgery and modification. Hop-by-hop protection is 719 provided. However, current RSVP security mechanism does not provide 720 non-repudiation and protection against message deletion; the two-way 721 peer authentication and key management procedures are still missing. 723 Finally, since the publication of the RSVP standard, tens of 724 extensions have emerged that allow for much wider deployment than 725 RSVP was originally designed for, as for instance, the Subnet 726 Bandwidth Manager, the NULL service type, aggregation, operation over 727 tunneling and MPLS as well as diagnostic messages. 729 Domains not supporting RSVP are traversed transparently by default. 730 Unfortunately, like other IP options, RSVP messages implemented by 731 way of IP alert option may result in themselves being dropped by some 732 routers. Also, the maximal size of RSVP message is limited. 734 The transport mechanisms, performance, security and mobility issues 735 are detailed in the following sections. 737 3. RSVP Transport Mechanism Issues 739 3.1. Messaging Reliability 741 RSVP messages are defined as a new IP protocol (that is, a new ptype 742 in the IP header). RSVP Path messages must be delivered end-to-end. 743 In order for the transit routers to intercept the Path messages, a 744 new IP Router Alert option [RFC2113] was introduced. This design is 745 simple to implement and efficient to run. As shown from the 746 experiments in [PS00], IP option processing introduces very little 747 overhead on a Free BSD box with minor kernel changes. 749 However, RSVP does not have a good message delivery mechanism. If a 750 message is lost on the wire, the next re-transmit cycle by the 751 network would be one soft-state refresh interval later. By default, 752 a soft-state refresh interval is 30 seconds. 754 To overcome this problem, [PS97] introduced a staged refresh timer 755 mechanism, which has been defined as a RSVP extension in [RFC2961]. 756 The staged refresh timer mechanism retransmits RSVP messages until 757 the receiving node acknowledges. It can address the reliability 758 problem in RSVP. 760 However, during its implementation, a lot of effort had to be spent 761 on per-session timer maintenance, message retransmission (e.g., avoid 762 message bursts) and message sequencing. In addition, we have to make 763 an effort to try to separate the transport functions from protocol 764 processing. For example, if a protocol extension requires a natural 765 RSVP session time-out (such as RSVP-TE one-to-one fast-reroute [FAST- 766 REROUTE]), we have to turn off the staged refresh timers. 768 3.2. Message Packing 770 According to RSVP [RFC2205], each RSVP message can only contain 771 information for one session. In a network that has a reasonably large 772 number of RSVP sessions, this constraint imposes a heavy processing 773 burden on the routers. Many router OS is based on UNIX. [PS00] showed 774 that the UNIX socket I/O processing is not very sensitive to packet 775 size. In fact, processing small packets takes almost as much CPU 776 overhead as processing large ones. However, processing too many 777 individual messages can easily cause congestion at socket I/O 778 interfaces. 780 To overcome this problem, RFC2961 introduced the message bundling 781 mechanism. The bundling mechanism packs multiple RSVP messages 782 between two adjacent nodes into a single packet. In one deployed 783 router platform, the bundling mechanism has improved the number of 784 RSVP sessions that a router can handle from 2,000 to over 7,000. 786 3.3. MTU Problem 788 RSVP does not support message fragmentation and reassembly at 789 protocol level. If the size of a RSVP message is larger than the 790 link MTU, the message will be fragmented. And the routers simply 791 cannot detect and process RSVP message fragments. 793 There is no solution for the MTU problem. Fortunately, at places 794 where RSVP-TE has been used, either the amount of per-session RSVP 795 data is never too large, or the link MTU is adjustable - PPP and 796 Frame Relay can always increase or decrease the MTU sizes. For 797 example, on some routers, a Frame Relay interface can support the 798 link MTU size up to 9600 bytes. Currently, the RSVP MTU problem is 799 not a realistic concern in MPLS networks. 801 However, when and if RSVP is used for end-user applications, where 802 network security is an essential and critical concern, it is possible 803 that the size of RSVP messages can be larger than the link MTU. It is 804 important to notice that end-users are most likely to have to deal 805 with a small 1500-byte Ethernet MTU. 807 3.4. RSVP-TE vs. Signaling Protocol for RT Applications 809 RSVP-TE works in an environment that is different from what the 810 original RSVP has been designed for: in MPLS networks, the RSVP 811 sessions that are used to support Label-Switched-Paths (LSP's) do not 812 change frequently. 814 In fact, the network operators typically set up the MPLS LSP's in 815 such a way that they cannot switch too quickly. For example, the 816 operators often regulate the CSPF (Constraint-based Shortest Path 817 First, a routing algorithm operates from the network edge to compute 818 the "most" optimal routes for the LSP's) computation interval to 819 prevent or delay large volume of user traffic to shift from one 820 session to the other during LSP path optimization. As a result, RSVP- 821 TE does not have to handle a large amount of "triggered" (new or 822 modified) messages. Most of the messages are refresh messages, which 823 can be handled by the mechanisms introduced in RFC2961. In 824 particular, in the Summary Refresh extension [RFC2961], each RSVP 825 refresh message can be represented as a 4-byte ID. The routers can 826 simply exchange the ID's to refresh RSVP sessions. With the full 827 implementation of RFC2961, MPLS routers do not have any RSVP scaling 828 issue. On one deployed router platform, it can support over 50,000 829 RSVP sessions in a stable backbone network. 831 On the other hand, in many of the new applications where a signaling 832 protocol is required, the user session duration can be relatively 833 short. The dynamics of adding/dropping user sessions could introduce 834 a large number of "triggered" messages in the network. This can 835 clearly introduce a substantial amount of processing overhead to the 836 routers. This is one area where a new signaling protocol may be 837 needed to reduce the processing complexity in the resource 838 reservation process. 840 3.5. What will be a better alternative? 842 A good signaling protocol should be transparent or oblivious to the 843 applications. On the other hand, the design of a signaling protocol 844 must take the intended and potential applications into consideration. 846 With the addition of RFC2961, RSVP-TE is sufficient to support its 847 intended application, MPLS, within the backbone. There is no 848 significant transport-layer problem that needs to be solved. 850 In the last several years, a number of new applications has been 851 developed and they require the use of IP signaling. One example is 852 midcom, which has been designed for firewall control. There are also 853 some far-out applications such as depositing active network code on 854 network devices. It is likely that the next-generation signaling 855 protocols will have to deal with the network security problems. The 856 MTU problem prevents the re-use of the existing RSVP transport 857 mechanism. 859 If a new transport protocol is needed, the protocol must be able to 860 handle the following: 862 - reliable messaging; 864 - message packing; 866 - the MTU problem; 868 - small triggered message volume. 870 4. RSVP Protocol Performance Issues 872 4.1. Processing Overhead 874 By processing overhead we mean the amount of processing required to 875 handle messages belonging to a reservation session. This is the 876 processing required in addition to the processing needed for routing 877 an (ordinary) IP packet. The processing overhead of RSVP originates 878 from two major issues: 880 1) Complexity of the protocol elements. First, RSVP itself is 881 per-flow based, thus the number of states is proportional to RSVP 882 session number. Path and Resv states have to be maintained in each 883 RSVP router for each session (and Path state also record the 884 reverse route for the correspondent Resv message). Second, being 885 receiver-initiated, RSVP optimizes various merging operations for 886 multicast reservations while the Resv message is processed. To 887 handle multicast, other mechanisms like reservation styles, scope 888 object, and blockade state, are also required to present in the 889 basic protocol. This not only adds sources of failures and errors, 890 but also complicates the state machine [Fu02]. Third, the same RSVP 891 signaling messages are not only used for maintaining the state, but 892 also dealing with recovery of signaling message loss and discovery 893 of route change. Thus, although protocol elements that represent 894 the actual data (e.g., QoS parameters) specification are separated 895 from signaling elements, the processing overhead needed for all 896 RSVP messages is not marginal. Finally, the possible variations of 897 the order and existence of objects increases the complexity of 898 message parsing and internal message and state representation. 900 2) Implementation-specific Overhead. There are two ways to send and 901 receive RSVP messages, either as "raw" IP datagrams with protocol 902 number 46, or as encapsulated UDP datagrams, the latter of which 903 increase the efficiency of RSVP processing. Typical RSVP 904 implementations are user-space daemons interacting with the 905 kernel, hence state management, message sending and reception 906 would affect the efficiency of the protocol processing. For 907 example, in the recent version of the implementation described in 908 [KSS01], the relative execution costs for message 909 sending/reception system calls "sendto", "select", "recvmsg" were 910 14-16%, 6-7%, 9-10%, individually, of the total execution cost; 911 [KSS01] also found that state (memory) management can use up to 912 17-18% of the total execution cost, but it is possible to decrease 913 that cost to 6-7%, if appropriate action is taken to replace the 914 standard memory management with dedicated memory management for 915 state information. RSVP/routing, RSVP/policy control, and 916 RSVP/traffic control interfaces can also pose different overhead 917 dependent on implementation. For example, the RSVP/routing 918 overhead has been measured to be approximately 11-12% of the total 919 execution cost [KSS01]. 921 4.2. Bandwidth Consumption 923 By bandwidth consumption we mean the amount of bandwidth used to 924 during the lifetime of a session: set up a reservation session, keep 925 the session alive, and finally close it. 927 RSVP messages are sent either to trigger a new reservation or refresh 928 an existing reservation. In standard RSVP, Path/Resv messages are 929 used for triggering and refreshing/recovering reservations, 930 identically, which results in an increased size of refresh messages. 931 The hop-by-hop refreshment may reduce the bandwidth consumption for 932 RSVP, but could result in more sources of error/failure events. 933 [RFC2961] presents a way to bundle standard RSVP messages and reduces 934 the refreshment redundancy by Srefresh message. 936 Thus, the signaling for an RSVP session uses for a session lasting n 937 seconds: 939 F(n) = (bP + bR) + ((n/Ri) * (bP + bR)) + bPt ,where 941 bP IP payload size of Path message 942 bR IP payload size of Resv message 943 bPt IP payload size of Path Tear message 944 Ri refresh interval 946 For example, for a simple Controlled Load reservation without 947 security and identification requirements the bandwidth consumption 948 would be (bP is 172 bytes, bR is 92, and bPt is 44 bytes and Ri is 30 949 seconds): 951 F(n): (172 + 92) + (n/30) * (172 + 92)) + 44 = 308 + (264n/30) bytes 953 5. RSVP Security and Mobility 955 5.1. Security 957 To allow a process on a system to securely identify the owner and the 958 application of the communicating process (e.g. user id) and convey 959 this information in RSVP messages (PATH or RESV) in a secure manner, 960 [RFC2752] specifies the encoding of identities as RSVP POLICY_DATA 961 Object. However, to provide iron-clad security protection 962 cryptographic authentication combined with authorization has to be 963 provided. Such a functionality is typically offered by authentication 964 and key exchange protocols. Solely including a user identifier is 965 insufficient. 967 To provide hop-by-hop integrity and authentication of RSVP messages, 968 RSVP message may contain an INTEGRITY object ([RFC2747]) using a 969 keyed message digest. Since intermediate routers need to modify and 970 process the content of the signaling message a hop-by-hop security 971 architecture based on a chain-of-trust is used. However, with the 972 different usage of RSVP as described throughout this document and 973 with new requirements a re-evaluation of the original assumptions 974 might be necessary. 976 RFC2747 provides protection against forgery and message modification. 977 However this does not provide non-repudiation and protect against 978 message deletion. In current RSVP security scheme, the two-way peer 979 authentication and key management procedures are still missing. 981 The security issues have been well analyzed in [Tsch03]. 983 5.2. Mobility Support 985 Two issues raise concern when RSVP is used by a mobile node (MN): the 986 flow identifier and reservation refresh. When an MN changes 987 locations, it may need to change one of its assigned IP address. An 988 MN may have an IP address by which it is reachable by nodes outside 989 the access network and an IP address used to support local mobility 990 management. Depending on the mobility management mechanism, a 991 handover may force a change in any of these addresses. As a 992 consequence the filters associated with a reservation may not 993 identify the flow anymore and the resource reservation is 994 ineffective, until a refresh with a new set of filters is 995 initialized. 997 The second issue is about following the movement of a mobile node. 998 RFC2205 defines that Path messages can perform a local repair of 999 reservation paths. When the route between the communicating end hosts 1000 changes, a Path message will set the state of the reservation on the 1001 new route and a subsequent Resv message will make the resource 1002 reservation. Therefore, by sending a Resv message a host cannot alone 1003 update the reservation, and thus perform a local repair, before a 1004 Path message has passed. Also, in order to provide fast adaptation to 1005 routing changes without the overhead of short refresh periods, the 1006 local routing protocol module can notify the RSVP process of route 1007 changes for particular destinations. The RSVP process should use this 1008 information to trigger a quick refresh of state for these 1009 destinations, using the new route (Chapter 3.6, RFC2205). However, 1010 not all local mobility protocols, or even Mobile IP, affect routing 1011 directly in routers, and thus mobility may not be noticed at RSVP 1012 routers. Thus, it may take a relatively long time before a 1013 reservation is refreshed following a handover. 1015 There have been several designs for extensions to RSVP to allow for 1016 more seamless mobility. One solution is presented in [MSK+04], which 1017 discusses in one section the coupling of RSVP and the mobility 1018 management mechanisms and proposes small extensions to RSVP to better 1019 handle the handover event, among other things. The extension allows 1020 the mobile host to request a Path for the downstream reservation when 1021 a handover has happened. 1023 Another example is Mobile RSVP (MRSVP) [TBA01], which is an extension 1024 to standard RSVP. It is based on advance reservations, where 1025 neighboring access points keep resources reserved for mobile nodes 1026 moving to their coverage area. When a mobile node requests resources, 1027 the neighboring access points are checked too and a passive 1028 reservation is done around the mobile nodes current location. 1030 The problem with the various 'advance reservation' schemes is that 1031 they require topological information of the access network and 1032 usually advance knowledge of the handover event. Furthermore, the way 1033 the resource reserved in advance are used in the neighboring service 1034 areas is an open issue. A good overview of these different schemes 1035 can be found in [MA01]. 1037 The interactions of RSVP and Mobile IP have been well documented in 1038 [Thom02]. 1040 6. Other QoS Signaling Proposals 1042 6.1. Tenet and ST-II 1044 Tenet and ST-II are two original QoS signaling protocols for the 1045 Internet. 1047 In the original Tenet architecture [BFM+96], the receiver sends a 1048 reservation request toward the source. Each network node along the 1049 way makes the reservation. Upon arriving at the source, the source 1050 sends another Relax message back toward to the receiver, and has the 1051 option to modify the previous reservation at each node. 1053 ST-II [RFC1819] basically works as the following: a sender originates 1054 a Connect message to a set of receivers. Each intermediate node 1055 determines the next hop subnets, and makes reservations on the links 1056 going to these next hops. Upon receiving a Connect indication, a 1057 receiver must send back either an Accept or a Refuse message to the 1058 sender. In the case of an Accept, the receiver may further reduce 1059 the resource request by updating the returned flow specifications. 1061 ST-II consists of two protocols: ST for the data transport and SCMP, 1062 the Stream Control Message Protocol, for all control functions. ST 1063 is simple and contains only a single PDU format that is designed for 1064 fast and efficient data forwarding in order to achieve low 1065 communication delays. SCMP packets are transferred within ST packets. 1067 ST-II has no built-in soft states, thus requires that the network be 1068 responsible for correctness. It is sender-initiated, and the overhead 1069 for ST-II to handle group membership dynamics is higher than RSVP 1070 [MESZ94]. ST-II does not provide security but RFC 1819 describes 1071 some objects related to charging. 1073 6.2. YESSIR 1075 YESSIR (YEt another Sender Session Internet Reservations) [PS98] is a 1076 resource reservation protocol that seeks to simplify the process of 1077 establishing reserved flows while preserving many unique features 1078 introduced in RSVP. Simplicity is measured in terms of control 1079 message processing, data packet processing, and user-level 1080 flexibility. Features such as robustness, advertising network service 1081 availability and resource sharing among multiple senders are also 1082 supported in the proposal. 1084 The proposed mechanism generates reservation requests by senders to 1085 reduce the processing overhead. It is built as an extension to the 1086 Real-Time Transport Control Protocol (RTCP), taking advantages of 1087 Real-Time Protocol (RTP). YESSIR also introduces a concept called 1088 partial reservation, where, for certain types of applications, the 1089 reservation requests can be passed to the next hop, even though there 1090 is not enough resources on a local node. The local node can rely on 1091 optimized retries to complete the reservations. 1093 6.2.1. Reservation Functionality 1095 YESSIR [PS98] was designed for one-way, sender-initiated end-to-end 1096 resource reservation. It also uses soft state to maintain states. It 1097 supports resource query (similar to RSVP diagnosis message), 1098 advertising (similar to RSVP ADSPEC), shared reservation, partial 1099 reservations and flow merging. 1101 To support multicast, YESSIR simplifies the reservation styles to 1102 individual and shared reservation styles. Individual reservations are 1103 made separately for each sender, whereas shared reservations allocate 1104 resources that can be used by all senders in an RTP session. While 1105 RSVP supports shared reservation (SE and WF styles) from the 1106 receiver's direction, YESSIR handles the shared reservation style 1107 from the sender's direction, thus new receivers can re-use the 1108 existing reservation of the previous sender. 1110 It has been shown that the YESSIR one-pass reservation model has 1111 better performance and lower processing cost, comparing with a 1112 regular two-way signaling protocol, such as RSVP [PS98]. The 1113 bandwidth consumption of YESSIR is somewhat lower than that of, for 1114 example, RSVP, because it does not require additional IP and 1115 transport headers. Bandwidth consumption is limited to the extension 1116 header size. 1118 YESSIR does not have any particular support for mobility and the 1119 security of YESSIR relies on RTP/RTCP security measures. 1121 6.2.2. Conclusion 1123 YESSIR requires support in applications since it is an integral part 1124 of RTCP. Similarly, it requires network routers to inspect RTCP 1125 packets to identify reservation requests and refreshes. Routers 1126 unaware of YESSIR forward the RTCP packets transparently. 1128 6.3. Boomerang 1130 Boomerang [FNM+99] is a another resource reservation protocol for IP 1131 networks. The protocol has only one message type and a single 1132 signaling loop for reservation set-up and tear-down, has no 1133 requirements on the far end node, but, instead, concentrates the 1134 intelligence in the Initiating Node (IN). 1136 In addition, the Boomerang protocol allows for sender- or receiver- 1137 oriented reservations and resource query. Flows are identified with 1138 the common 5-tuple and the QoS can be specified with various means, 1139 e.g.. service class and bit rate. Boomerang messages are in the 1140 initial implementation transported in ICMP ECHO / REPLY messages. 1142 6.3.1. Reservation Functionality 1144 Boomerang can only be used for unicast sessions, no support for 1145 multicast exists. The requested QoS can be specified with various 1146 methods and both ends of a communication session can make a 1147 reservation for their transmitted flow. 1149 The authors of Boomerang show in [FNS02] that the processing of the 1150 protocol is considerably lower than with the ISI RSVP daemon 1151 implementation. However, this is mainly due to the limited 1152 functionality provided by the protocol compared to RSVP. 1154 Boomerang messages are quite short and consume a relatively low 1155 amount of link bandwidth. This is due to the limited functionality of 1156 the protocol, for example, no security specific information or 1157 policy-based interaction are provided. Being sender oriented, the 1158 bandwidth consumption mostly affects the downstream direction, from 1159 the sender to the receiver. 1161 As Boomerang is sender oriented, there is no need to store backward 1162 information. This reduces the signaling required. The rest of the 1163 issues that were identified with RSVP apply with Boomerang. No 1164 security mechanism is specified for Boomerang. 1166 The Boomerang protocol has similar deployment issues as any host- 1167 network-host protocol. It requires an implementation at both 1168 communicating nodes and in routers. Boomerang-unaware routers should 1169 be able to forward Boomerang messages transparently. Still, often 1170 firewalls drop ICMP packets making the protocol useless. 1172 6.3.2. Conclusions 1174 Boomerang seems to be a very lightweight protocol and efficient in 1175 its own scenarios. Still, the apparent low processing overhead and 1176 bandwidth consumption results from the limited functionality. No 1177 support for multicast or any security features are present which 1178 allows for a different functionality than RSVP, which the authors 1179 like to compare Boomerang to. 1181 6.4. INSIGNIA 1183 INSIGNIA [LGZC00] is proposed as a very simple signaling mechanism 1184 for supporting QoS in mobile ad-hoc networks. It avoids the need for 1185 separate signaling by carrying the QoS signaling data along with the 1186 normal data in IP packets using IP packet header options. This 1187 approach, known as "in-band signaling" is proposed as more suitable 1188 in the rapidly changing environment of mobile networks since the 1189 signaled QoS information is not tied to a particular path. It also 1190 allows the flows to be rapidly established and, thus, is suitable for 1191 short lived and dynamic flows. 1193 INSIGNIA aims to minimize signaling by reducing the number of 1194 parameters that are provided to the network. It assumes that real- 1195 time flows may tolerate some loss, but are very delay sensitive so 1196 that the only QoS information needed is the required minimum and 1197 maximum bandwidth. 1199 The INSIGNIA protocol operates at the network layer and assumes that 1200 link status sensing and access schemes are provided by lower layer 1201 entities. The usefulness of the scheme depends upon the MAC layers 1202 but this is undefined so that INSIGNIA can run over any MAC layer. 1203 The protocol requires that each router maintains per-flow state. 1205 The INSIGNIA system implicitly supports mobility. A near-minimal 1206 amount of information is exchanged with the network. To achieve this, 1207 INSIGNIA makes many assumptions about the nature of traffic that a 1208 source will send. This may also simplify admission control and buffer 1209 allocation. The system basically assumes that "real-time" will be 1210 defined as a maximum delay and the user can simply request real-time 1211 service for a particular quantity of traffic. 1213 After handover, data that was transmitted to the old base station can 1214 be forwarded to the new base station so that no data loss should 1215 occur. However, there is no way to differentiate between re-routed 1216 and new traffic so priority cannot be given to handover traffic, for 1217 example. 1219 INSIGNIA, however, (completely) lacks a security framework and does 1220 not investigate how to secure signaled QoS data in ad-hoc network 1221 where relatively weak trust or even no trust exists between the 1222 participating nodes. Hence authorization and charging especially 1223 might be a challenge. The security protection of in-band signaling is 1224 costly since the data delivery itself experiences increased latency 1225 if security processing is done hop-by-hop. Since the QoS signaling 1226 information is encoded into the flow label and end-to-end addressing 1227 is used, it is very difficult to provide security other than IPsec in 1228 tunnel mode. 1230 7. Inter-domain Signaling 1232 This section gives a short overview of protocols designed for inter- 1233 domain signaling. 1235 7.1. BGRP 1237 Border Gateway Reservation Protocol (BGRP) [BGRP] is a signaling 1238 protocol for inter-domain aggregated resource reservation for unicast 1239 traffic. BGRP builds a sink tree for each of the stub domains. Each 1240 sink tree aggregates bandwidth reservations from all data sources in 1241 the network. BGRP maintains these aggregated reservations using soft 1242 state and relies on Differentiated Services for data forwarding. 1244 BGRP scales in terms of message processing load, state storage and 1245 bandwidth. Since backbone routers only maintain the sink tree 1246 information, the total number of reservations at each router scales 1247 linearly with the number of Internet domains. 1249 7.2. SICAP 1251 SICAP (Shared-segment Inter-domain Control Aggregation protocol) 1252 [SGV03] is an inter-domain signaling solution that performs shared- 1253 segment aggregation [SGV02] on the Autonomous System (AS) level with 1254 the purpose of reducing state required at Boundary Routers (BRs). 1255 SICAP performs aggregation based on path segments that different 1256 reservations share. Thus, reservations may be merged into aggregates 1257 that do not extend necessarily all the way until the reservation's 1258 destination. The motivation for creating "shorter" aggregates is, on 1259 the one hand, their ability to more easily accommodate future 1260 requests, and on the other hand, the minimization of aggregates 1261 created and consequently, the reduction of state required to manage 1262 established reservations. However, and in contrast to the sink-tree 1263 approach (used by BGRP [BGRP]), the shared-segment approach 1264 introduces intermediate de-aggregation locations: these are ASes 1265 where aggregates may experience "re-aggregation". At these locations, 1266 routers that perform aggregation (AS egress routers) have to keep 1267 track of the mapping between reservations and aggregates. One 1268 possible way of doing this is to keep each reservation identifier and 1269 corresponding resources stored at each aggregator. However, this 1270 solution incurs a high state penalty on state. SICAP avoids this 1271 state penalty by keeping track of the mapping between aggregates and 1272 reservations at the level of destination domains rather than 1273 explicitly mapping individual reservations to aggregates. In other 1274 words, SICAP maintains per aggregate a list of the destination 1275 prefixes advertised by the destination AS an aggregate provides 1276 access to. 1278 Pan et al. show that BGRP scales well in terms of control state, 1279 message processing, and bandwidth efficiency, when compared to RSVP 1280 without aggregation. However, and partially given that it was the 1281 first approach to explore in detail the issue of inter-domain control 1282 aggregation, they did not provide a comparison with other aggregation 1283 protocols. 1285 SICAP and BGRP messaging sequences are similar and consequently, 1286 these protocols attain the same signaling load. Such load is exactly 1287 the same attained by proposals that do not perform aggregation, given 1288 that SICAP and BGRP exchange messages per individual reservation. In 1289 terms of bandwidth, both protocols provision aggregates with the 1290 exact bandwidth required by their merged reservations. Therefore, the 1291 major difference between SICAP and BGRP is state maintained at BRs, 1292 which is significantly reduced by SICAP. We consider this to be of 1293 importance not so much to offer a better performing alternative to 1294 BGRP, but to quantify the performance improvements that might still 1295 be available in the research field of control path aggregation. 1296 Finally, to deal with the possible problem of the signaling load, 1297 SICAP uses an over-reservation mechanism[SGV03b], whose design took 1298 into consideration a possible support for BGRP. 1300 7.3. DARIS 1302 Dynamic Aggregation of Reservations for Internet Services (DARIS) 1303 [Bless02] [Bless04] defines an inter-domain aggregation scheme for 1304 resource reservations. Basically, it aggregates reservations along 1305 Autonomous System (AS) paths (or parts thereof). A set of 1306 reservations whose data paths share a common sequence of ASes are 1307 integrated into a joint reservation aggregate along that shared sub- 1308 path. All entities within the aggregate, except aggregate starting 1309 and end point, can remove state information of the included 1310 individual reservations, thereby saving states. They just need to 1311 hold the necessary information about the encompassing aggregate. 1312 Moreover, these intermediate ASes are no longer involved in signaling 1313 that is related to the aggregated reservations. If more aggregate 1314 resources are reserved than were actually required, the capacity of 1315 the aggregate does not need to be adapted with every new or released 1316 reservation (thereby reducing the number of message exchanges). 1318 An aggregate between two ASes is created as soon as a threshold k is 1319 exceeded that describes the active number of unidirectional 1320 reservations between them. It is, however, possible to apply 1321 different aggregation triggers. Furthermore, DARIS allows to nest 1322 aggregates hierarchically. Therefore, the existence of shorter 1323 aggregates does not prevent the creation of longer (and thus more 1324 efficient) aggregates and vice versa. An evaluation of recent BGP 1325 routing information in [Bless02] showed that 92% of all end-to-end 1326 paths contain at least four ASes. Consequently, an aggregate from 1327 edge AS to edge AS can span four or more ASes, thus saving states and 1328 signaling message processing in at least two ASes. 1330 There is, however, a small chance that a reservation cannot be 1331 included into a new aggregate, because it was already aggregated 1332 elsewhere. This so-called "aggregation conflict" is caused by the 1333 fact that state information related to individual reservations was 1334 already removed within intermediate ASes of the encompassing 1335 aggregate. This may also bring difficulties in case that reservations 1336 or aggregates are re-routed between ASes. One must be careful when 1337 considering to define sophisticated adaptation techniques for these 1338 special cases, because they seem to become very complex. 1340 The signaling protocol DMSP (Domain Manager Signaling Protocol) 1341 supports aggregation by special extensions which reduce the 1342 reservation setup time for more than one round-trip time in some 1343 cases (e.g., if an aggregate's capacity must be increased before a 1344 new reservation can be included). Details can be found in [Bless02]. 1346 The DARIS concept was evaluated by using a simulation with a topology 1347 that was derived from real BGP routing table information and 1348 comprised more than 5500 ASes. In comparison to a non-aggregated 1349 scenario the number of saved states lay in the range of one to two 1350 orders of magnitude and similar results were obtained with respect to 1351 the number of signaling messages. Though [Bless02] describes DARIS in 1352 the context of distributed Domain Management entities (similar to a 1353 bandwidth broker) it can be applied in a router-based resource 1354 management environment, too. This will achieve a higher degree of 1355 distribution which is beneficial for large ASes which are highly 1356 interconnected. 1358 A general issue with aggregation is that not the aggregating and de- 1359 aggregating ASes profit from their initiated aggregates, but all 1360 intermediate ASes within an aggregate. Therefore, some incentive for 1361 aggregate creation has to be given. This may lead to novel cost 1362 models that have to be developed for aggregation concepts in the 1363 future. 1365 8. Security Considerations 1367 This document does not present new technology or protocols, thus, 1368 there are no explicit security issues. Still, individual protocols 1369 include different levels of security issues and those are highlighted 1370 in the relevant sections and references. 1372 9. Summary 1374 Supporting flow-based soft state reservations has been proven useful. 1375 Still, there have been different ways of improving the performance, 1376 including refresh reduction and aggregation. However, some of the 1377 main concerns with these signaling protocols are the complexity of 1378 the protocol, which affects implementations and processing overhead, 1379 and the security of the signaling. Especially, a proper scheme to 1380 handle authentication, authorization of QoS resource requests and a 1381 framework for providing signaling message security seems to be 1382 missing from most protocols. RSVP has a mechanism to protect 1383 signaling messages based on manually distributed keys and concepts 1384 for authorization but they seem to be insufficient for a dynamic and 1385 mobile environment. [Tsch03] provides more details on security 1386 properties provided by RSVP. Moreover, secure and efficient signaling 1387 to and from mobile nodes has been one of the critical challenges not 1388 fully met by existing protocols. 1390 Moving QoS signaling protocols into a generic messenger can provide 1391 much adoption. It is expected that the development of future 1392 protocols should learn from the lessons of existing ones. 1393 Nevertheless, the tradeoffs between the expected functionality, 1394 protocol complexity/performance would still be taken into account. 1395 For example, RSVP uses the two-way signaling mechanism, where as 1396 YESSIR employs only one-pass signaling. Both can be shown to out- 1397 perform the other in specific carefully chosen signaling scenarios. 1399 10. Contributors 1401 This document is part of the work done in the NSIS Working Group. The 1402 draft was initially written by Jukka Manner and Xiaoming Fu. Since 1403 the first version, Martin Karsten has provided text about the 1404 processing overhead of RSVP and Hannes Tschofenig has provided text 1405 about various security issues in the protocols. Henning Schulzrinne 1406 and Ping Pan have provided more information on RSVP transportation 1407 after the second revision. Kireeti Kompella and Adrian Farrel 1408 provided a review and updates to the discussion on RSVP-TE and GMPLS. 1410 11. Acknowledgment 1412 We would like to acknowledge Bob Braden and Vlora Rexhepi for their 1413 useful comments. 1415 12. Normative References 1417 [RFC3726] M. Brunner, "Requirements for Signaling Protocols", RFC 1418 3726, April 2004. 1420 13. Non-Normative References 1422 [3GPP-TS23207] 3GPP TS 23.207 V5.6.0, End-to-end Quality of Service 1423 (QoS) Concept and Architecture, Release 5, Dec. 2002. 1425 [BEBH96] Braden, R., Estrin, D., Berson, S., Herzog, and D. Zappala, 1426 "The Design of the RSVP Protocol", ISI Final Technical Report, Jul 1427 1996. 1429 [BEGD02] Y. Bernet, N. Elfassy, S. Gai, and D. Dutt, "RSVP Proxy", 1430 draft-ietf-rsvp-proxy-03 (work in progress), March 2002. 1432 [BFM+96] A. Banerjea, D. Ferrari, B. Mah, M. Moran, D. Verma, and H. 1433 Zhang, "The Tenet Real-Time Protocol Suite: Design, Implementation, 1434 and Experiences", IEEE/ACM Transactions on Networking, Volume 4, 1435 Issue 1, February 1996, pp. 1-10. 1437 [BGP4] Y. Rekhter, T. Li, and S. Hares, "A Border Gateway Protocol 4 1438 (BGP-4)", Internet Draft, Work in Progress, November 2003 (draft- 1439 ietf-idr-bgp4-23.txt). 1441 [BGRP] P. Pan, E, Hahne, and H. Schulzrinne, "BGRP: A Tree-Based 1442 Aggregation Protocol for Inter-domain Reservations", Journal of 1443 Communications and Networks, Vol. 2, No. 2, June 2000, pp. 157-167. 1445 [Bless02] R. Bless, "Dynamic Aggregation of Reservations for Internet 1446 Services", Proceedings of the Tenth International Conference on 1447 Telecommunication Systems - Modeling and Analysis (ICTSM 10), Vol. 1, 1448 pp. 26-38, October 3-6 2002, Monterey California, slightly revised 1449 version available under http://www.tm.uka.de/doc/2003/ictsm-daris- 1450 journal-crc-web.pdf 1452 [Bless04] R. Bless, "Towards Scalable Management of QoS-based End-to- 1453 End Services" (PDF), Proceedings of NOMS 2004 (IEEE/IFIP 2004 Network 1454 Operations and Management Symposium), April 2004, Seoul, Korea. 1456 [FAST-REROUTE] P. Pan, G. Swallow, and A. Atlas, "Fast Reroute 1457 Extensions to RSVP-TE for LSP Tunnels", Internet Draft, Work in 1458 Progress, January 2004 (draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt). 1460 [FNM+99] G. Feher, K. Nemeth, M. Maliosz, I. Cselenyi, J. Bergkvist, 1461 D. Ahlard, T. Engborg, "Boomerang A Simple Protocol for Resource 1462 Reservation in IP Networks", IEEE RTAS, 1999. 1464 [FNS02] G. Feher, K. Nemeth, and I. Cselenyi, "Performance evaluation 1465 framework for IP resource reservation signalling". Performance 1466 Evaluation 48 (2002), pp. 131-156. 1468 [FJ02] P. Fransson and A. Jonsson, "The need for an alternative to 1469 IPv4-options", in RVK (RadioVetenskap och Kommunikation), Stockholm, 1470 Sweden, pp. 162-166, June 200. 1472 [Fu02] X. Fu, C. Kappler, and H. Tschofenig, "Analysis on RSVP 1473 Regarding Multicast". Technical Report No. IFI-TB-2002-001, ISSN 1474 1611-1044, Institute for Informatics, University of Goettingen, Oct 1475 2002. 1477 [H.245] ITU-T Recommendation H.245, Control Protocol for Multimedia 1478 Communication, July 2000. 1480 [H.323] ITU-T Recommendation H.323, Packet-based Multimedia 1481 Communications Systems, Nov. 2000. 1483 [JR03] Jukka Manner, Kimmo Raatikainen, "Localized QoS Management for 1484 Multimedia Applications in Wireless Access Networks". IASTED 1485 International Conference on Internet and Multimedia Systems and 1486 Applications (IMSA 2003), August, 2003, pp. 193 - 200. 1488 [Kars01] M. Karsten, "Experimental Extensions to RSVP -- Remote 1489 Client and One-Pass Signalling". IWQoS 2001, Karlsruhe, Germany, June 1490 2001. 1492 [KSS01] M. Karsten, Jens Schmitt, Ralf Steinmetz, "Implementation and 1493 Evaluation of the KOM RSVP Engine". IEEE Infocom 2001. 1495 [LGZC00] S. Lee, A. Gahng-Seop, X. Zhang, A. Campbell,"INSIGNIA: An 1496 IP-Based Quality of Service Framework for Mobile Ad Hoc Networks". 1497 Journal of Parallel and Distributed Computing (Academic Press), 1498 Special issue on Wireless and Mobile Computing and Communications, 1499 Vol. 60, Number 4, April, 2000, pp. 374-406. 1501 [MA01] B. Moon, and H. Aghvami, "RSVP Extensions for Real-Time 1502 Services in Wireless Mobile Networks". IEEE Communications Magazine, 1503 December 2001, pp. 52-59. 1505 [MESZ94] D. Mitzel, D. Estrin, S. Shenker, and L. Zhang, "An 1506 Architectural Comparison of ST-II and RSVP", INFOCOM'94. 1508 [MHS02] Y Miao, W. Hwang, and C. Shieh, "A transparent deployment 1509 method of RSVP-aware applications on UNIX". Computer Networks, 40 1510 (2002), pp. 45-56. 1512 [MSK+04] J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K. Raatikainen, 1513 "Localized RSVP". Internet Draft, Work in Progress, January 2004 1514 (draft-manner-lrsvp-03.txt) 1516 [OVERLAY] G. Swallow, J. Drake, H. Ishimatsu, and Y. Rekhter, "GMPLS 1517 UNI: RSVP Support for the Overlay Model", draft-ietf-ccamp-gmpls- 1518 overlay- 03.txt, February 2004, work in progress. 1520 [PS97] P. Pan, and H. Schulzrinne, "Staged refresh timers for RSVP", 1521 Global Internet, Phoenix, Arizona, Nov. 1997. 1523 [PS98] P. Pan, and H. Schulzrinne, "YESSIR: A Simple Reservation 1524 Mechanism for the Internet". Proceedings of NOSSDAV, Cambridge, UK, 1525 July 1998. 1527 [PS00] P. Pan, and H. Schulzrinne, "PF_IPOPTION: A kernel extension 1528 for IP option packet processing", Technical Memorandum 10009669-02TM, 1529 Bell Labs, Lucent Technologies, Murray Hill, NJ, June 2000. 1531 [RFC1819] L. Delgrossi, and L. Berger, "Internet Stream Protocol 1532 Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, 1533 August 1995. 1535 [RFC2113] D. Katz, "IP Router Alert Option", RFC 2113, February 1997. 1537 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, 1538 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1539 Specification", RFC 2205, Sep 1997. 1541 [RFC2207] L. Berger, and T. O'Malley, "RSVP Extensions for IPSEC Data 1542 Flows", RFC 2207, September 1997. 1544 [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 1545 Services", RFC 2210, September 1997. 1547 [RFC2379] L. Berger, "RSVP over ATM Implementation Guidelines", RFC 1548 2379, August 1998. 1550 [RFC2380] L. Berger, "RSVP over ATM Implementation Requirements", RFC 1551 2380, August 1998. 1553 [RFC2745] A. Terzis, B. Braden, S. Vincent, and L. Zhang, "RSVP 1554 Diagnostic Messages", RFC 2745, January 2000. 1556 [RFC2746] A. Terzis, J. Krawczyk, J. Wroclawski, and L. Zhang, "RSVP 1557 Operation Over IP Tunnels", RFC 2746, January 2000. 1559 [RFC2747] F. Baker, B. Lindell, and M. Talwar, "RSVP Cryptographic 1560 Authentication", RFC 2747, January 2000. 1562 [RFC2749] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Raja, and A. 1563 Sastry, "COPS usage for RSVP", RFC 2749, January 2000. 1565 [RFC2750] S. Herzog, "RSVP Extensions for Policy Control", RFC 2750, 1566 January 2000. 1568 [RFC2751] S. Herzog, "Signaled Preemption Priority Policy Element", 1569 RFC 2751, January 2000. 1571 [RFC2752] S. Yadav, "Identity Representation for RSVP", RFC 2752, 1572 January 2000. 1574 [RFC2814] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, and M. Speer, 1575 "SBM (Subnet Bandwidth Manager): A Protocol for Admission Control 1576 over IEEE 802-style Networks", RFC 2814, May 2000. 1578 [RFC2961] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, and S. 1579 Molendini, "RSVP refresh overhead reduction extensions", RFC 2961, 1580 April 2001. 1582 [RFC2996] Y. Bernet, "Format of the RSVP DCLASS Object", RFC 2996, 1583 November 2000. 1585 [RFC2997] Y. Bernet, A. Smith, and B. Davie, "Specification of the 1586 Null Service Type", RFC 2997, November 2000. 1588 [RFC2998] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. 1589 Speer, R. Braden, and B. Davie, "Integrated Services Operation over 1590 Diffserv Networks", RFC 2998, November 2000. 1592 [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, and B. 1593 Thomas, "LDP Specification", RFC 3036, January 2001. 1595 [RFC3175] F. Baker, C. Iturralde, F. Le Faucheur, and B. Davie, 1596 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 1597 September 2001. 1599 [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. 1600 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, 1601 December 2001. 1603 [RFC3270] F. Le Faucheur (ed), "Multi-Protocol Label Switching (MPLS) 1604 Support of Differentiated Services", RFC 3270, May 2002. 1606 [RFC3473] L. Berger (ed), "Generalized MPLS Signaling - RSVP-TE 1607 Extensions". RFC 3473, January 2003. 1609 [RFC3474] Z. Lin, and D. Pendarakis, "Documentation of IANA 1610 assignments for Generalized MultiProtocol Label Switching (GMPLS) 1611 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage 1612 and Extensions for Automatically Switched Optical Network (ASON)", 1613 RFC3474, March 2003. 1615 [RFC3477] K. Kompella, and Y. Rekhter, "Signalling Unnumbered Links 1616 in Resource Reservation Protocol - Traffic Engineering (RSVP-TE)", 1617 RFC 3477, January 2003. 1619 [RFC3520] L-N. Hamer, B. Gage, B. Kosinski, and H. Shieh, "Session 1620 Authorization Policy Element", RFC 3520, April 2003. 1622 [SGV02] R. Sofia, R. Gu�rin, and P. Veiga, "An Investigation of 1623 Inter-Domain Control Aggregation Procedures", International 1624 Conference on Networking Protocols, ICNP'02, Paris, France, November 1625 2002. 1627 [SGV03] R. Sofia, R. Gu�rin, and P. Veiga. SICAP, a Shared-segment 1628 Inter-domain Control Aggregation Protocol. High Performance Switching 1629 and Routing, HPSR 2003, Turin, Italy, June 2003. 1631 [SGV03b] R. Sofia, R. Gu�rin, and P. Veiga. A Study of Over- 1632 reservation for Inter-Domain Control Aggregation Protocols. Technical 1633 report (short version under submission), University of Pennsylvania, 1634 May 2003. Available at 1635 http://einstein.seas.upenn.edu/mnlab/publications.html. 1637 [TBA01] A. Talukdar, B. Badrinath, and A. Acharya, "MRSVP: A Resource 1638 Reservation Protocol for an Integrated Services Network with Mobile 1639 Hosts", Wireless Networks, vol. 7, no. 1, pp. 5-19. 2001. 1641 [Thom02] M. Thomas, "Analysis of Mobile IP and RSVP Interactions". 1642 Internet draft, Work in Progress, October 2002 (draft-thomas-nsis- 1643 rsvp-analysis-00.txt). 1645 [Tsch03] H. Tschofenig, "RSVP Security Properties". Internet Draft, 1646 Work in Progress, February 2004 (draft-ietf-nsis-rsvp-sec- 1647 properties-04.txt). 1649 [ZDSZ93] L. Zhang, S. Deering, D. Estrin, and D. Zappala, "RSVP: A 1650 New Resource Reservation Protocol", IEEE Network, Volume 7, Pages 1651 8-18, Sep 1993. 1653 14. Authors' Information 1655 Jukka Manner 1656 Department of Computer Science 1657 University of Helsinki 1658 P.O. Box 26 (Teollisuuskatu 23) 1659 FIN-00014 HELSINKI 1660 Finland 1662 Voice: +358-9-191-44210 1663 Fax: +358-9-191-44441 1664 E-Mail: jmanner@cs.helsinki.fi 1666 Xiaoming Fu 1667 Institute for Informatics 1668 Georg-August-University of Goettingen 1669 Lotzestrasse 16-18 1670 37083 Goettingen 1671 Germany 1673 Voice: +49-551-39-14411 1674 Fax: +49-551-39-14403 1675 E-Mail: fu@cs.uni-goettingen.de 1677 15. Appendix A - Comparison of RSVP to the NSIS Requirements 1679 This section provides a comparison of RSVP to the requirements 1680 identified as part of the work in NSIS [RFC3726]. The numbering 1681 follows the division in the requirements document. 1683 5.1 Architecture and Design Goals 1685 5.1.1 NSIS SHOULD provide availability information on request 1687 RSVP itself does not support query-type of operations. However, 1688 the RSVP diagnosis messages extension [RFC2745] provides a means 1689 to query resource availability. 1691 5.1.2 NSIS MUST be designed modularly 1693 RSVP was designed to be modular by way of TLV objects, however 1694 it is regarded being lack of sufficient extensibility in various 1695 kind of signalling applications. 1697 5.1.3 NSIS MUST decouple protocol and information 1699 RSVP is decoupled from the IntServ QoS specifications. Still, 1700 the concept of sessions in RSVP are somewhat coupled to the 1701 information it carries. 1703 5.1.4 NSIS MUST support independence of signaling and network 1704 control paradigm 1706 The IntServ information carried by RSVP does not tie the QoS 1707 provisioning mechanisms. 1709 5.1.5 NSIS SHOULD be able to carry opaque objects 1711 RSVP supports this. 1713 5.2 Signaling Flows 1715 5.2.1 The placement of NSIS Initiator, Forwarder, and Responder 1716 anywhere in the network MUST be allowed 1718 Standard RSVP works only end-to-end, although the RSVP proxy 1719 [BEGD02] and the Localized RSVP [MSK+04] have relaxed this 1720 assumption. RSVP relies on receiver-initiation way to perform 1721 QoS reservations. 1723 5.2.2 NSIS MUST support path-coupled and MAY support path- 1724 decoupled signaling 1726 Standard RSVP is path-coupled, but the SBM work makes RSVP 1727 somewhat path-decoupled. 1729 5.2.3 Concealment of topology and technology information SHOULD be 1730 possible 1732 RSVP itself does not provide such capability. 1734 5.2.4 Transparent signaling through networks SHOULD be possible 1736 RSVP messages are intecepted and evaluated in each RSVP router, 1737 and thus they may not cross certain RSVP-routers unnoticed. 1738 Still, the message processing rules allow unknown RSVP messages 1739 to be forwarded unharmed. 1741 5.3 Messaging 1743 5.3.1 Explicit erasure of state MUST be possible 1745 Supported by the PathTear and ResvTear messages. 1747 5.3.2 Automatic release of state after failure MUST be possible 1749 On error reservation states are torn down with PathTear 1750 messages. 1752 5.3.3 NSIS SHOULD allow for sending notifications upstream 1754 There are two notifications in RSVP, confirm of a reservation 1755 set-up and tear down of reservation states as a result of 1756 errors. 1758 5.3.4 Establishment and refusal to set up state MUST be notified 1760 PathErr and ResvErr messages provide refusal to set up state in 1761 RSVP. 1763 5.3.5 NSIS MUST allow for local information exchange 1765 RSVP NULL service type [RFC2997] provides such a feature. 1767 5.4 Control Information 1769 5.4.1 Mutability information on parameters SHOULD be possible 1771 Rspec and Adspec are mutable; Tspec is (generally) end-to-end 1772 not mutable. 1774 5.4.2 It SHOULD be possible to add and remove local domain 1775 information 1777 RSVP aggregation [RFC3175] and NULL service type [RFC2997] can 1778 provide such a feature. 1780 5.4.3 State MUST be addressed independent of flow identification 1781 RSVP states are tied to the flows, thus this requirement is not 1782 met. 1784 5.4.4 Modification of already established state SHOULD be seamless 1786 Modifications of a reservation is possible with RSVP. 1788 5.4.5 Grouping of signaling for several micro-flows MAY be 1789 provided 1791 Aggregated RSVP and RFC2961 allow this. 1793 5.5 Performance 1795 5.5.1 Scalability 1797 RSVP scales linearly to the number of reservation states. 1799 5.5.2 NSIS SHOULD allow for low latency in setup 1801 Setting up an RSVP reservation takes one round-trip time and the 1802 processing times are each RSVP router. 1804 5.5.3 NSIS MUST allow for low bandwidth consumption for the 1805 signaling protocol 1807 The initial reservations messages can not be compressed, but the 1808 refresh interval can be adjusted to consume less bandwidth, at 1809 the expense of possible inefficient resource usage. 1811 5.5.4 NSIS SHOULD allow to constrain load on devices 1813 See discussions on RSVP performance (section 4). 1815 5.5.5 NSIS SHOULD target the highest possible network utilization 1817 This dedends on the IntServ service types, Controlled Load can 1818 provide better overall utilization than Guaranteed Service. 1820 5.6 Flexibility 1822 5.6.1 Flow aggregation 1824 Aggregated RSVP and RFC2961 allow this. 1826 5.6.2 Flexibility in the placement of the NSIS Initiator/Responder 1828 RSVP allows receiver as initiator of reservations. 1830 5.6.3 Flexibility in the initiation of state change 1832 RSVP receivers can initiate the state change during its 1833 refreshment. 1835 5.6.4 SHOULD support network-initiated state change 1837 As RSVP supports hop-by-hop refreshment, this is made possible. 1839 5.6.5 Uni / bi-directional state setup 1841 RSVP is only uni-directional. 1843 5.7 Security 1845 5.7.1 Authentication of signaling requests 1847 Authentication is available in RSVP. 1849 5.7.2 Request Authorization 1851 Authorization with a PDP is possible in RSVP. 1853 5.7.3 Integrity protection 1855 The INTEGRITY Object is available in RSVP. 1857 5.7.4 Replay protection 1859 The INTEGRITY Object to replay protect the content of the 1860 signaling messages between two RSVP nodes. 1862 5.7.5 Hop-by-hop security 1864 The RSVP security model works only hop-by-hop. 1866 5.7.6 Identity confidentiality and network topology hiding 1868 The INTEGRITY Object can be used for this purpose. 1870 5.7.7 Denial-of-service attacks 1872 Challenging with RSVP. 1874 5.7.8 Confidentiality of signaling messages 1876 Not supported by RSVP. 1878 5.7.9 Ownership of state 1880 Challenging with RSVP. 1882 5.8 Mobility 1884 5.8.1 Allow efficient service re-establishment after handover 1885 Works for upstream but may not be achieved for the downstream 1886 if mobility is not noticed at the cross-over router. 1888 5.9 Interworking with other protocols and techniques 1890 5.9.1 MUST interwork with IP tunneling 1892 RFC 2746 discusses these issues. 1894 5.9.2 MUST NOT constrain either to IPv4 or IPv6 1896 RSVP supports both IP versions. 1898 5.9.3 MUST be independent from charging model 1900 RSVP does not discuss this. 1902 5.9.4 SHOULD provide hooks for AAA protocols 1904 COPS and RSVP work together. 1906 5.9.5 SHOULD work with seamless handoff protocols 1908 Not supported by RSVP. Still, RFC2205 suggests that route 1909 changes should be indicated to the local RSVP daemon, which can 1910 then initiate state refresh. 1912 5.9.6 MUST work with traditional routing 1914 RSVP expects traditional routing. 1916 5.10 Operational 1918 5.10.1 Ability to assign transport quality to signaling messages 1920 This is a network design issue, but is possible with DiffServ. 1922 5.10.2 Graceful fail over 1924 RSVP supports this. 1926 5.10.3 Graceful handling of NSIS entity problems 1928 RSVP itself does not supports this. 1930 Full Copyright Statement 1932 Copyright (C) The Internet Society (2001). All Rights Reserved. 1934 This document and translations of it may be copied and furnished to 1935 others, and derivative works that comment on or otherwise explain it 1936 or assist in its implementation may be prepared, copied, published 1937 and distributed, in whole or in part, without restriction of any 1938 kind, provided that the above copyright notice and this paragraph are 1939 included on all such copies and derivative works. However, this 1940 document itself may not be modified in any way, such as by removing 1941 the copyright notice or references to the Internet Society or other 1942 Internet organizations, except as needed for the purpose of 1943 developing Internet standards in which case the procedures for 1944 copyrights defined in the Internet Standards process must be 1945 followed, or as required to translate it into languages other than 1946 English. The limited permissions granted above are perpetual and 1947 will not be revoked by the Internet Society or its successors or 1948 assigns. This document and the information contained herein is 1949 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1950 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1951 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1952 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1953 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.