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