idnits 2.17.1 draft-manner-lrsvp-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 873. ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'END HOST' on line 633 -- Looks like a reference, but probably isn't: 'X-OVER ROUTER' on line 633 -- Looks like a reference, but probably isn't: 'PROXY' on line 633 -- Looks like a reference, but probably isn't: 'CN' on line 314 -- Looks like a reference, but probably isn't: 'NEW AR' on line 633 -- Looks like a reference, but probably isn't: 'RSVP ROUTER' on line 583 ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2209 (ref. '18') -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '12') (Obsoleted by RFC 7826) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 11 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 T. Suihko 3 Expires: March, 2005 M. Kojo 4 M. Liljeberg 5 K. Raatikainen 6 September, 2004 8 Localized RSVP 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This document is a submission to the Transport Area Working Group of 35 the Internet Engineering Task Force (IETF). Comments should be 36 submitted to the tsvwg@ietf.org mailing list. 38 Abstract 40 Guaranteed QoS for multimedia applications is based on reserved 41 resources in each node on the end-to-end path. Even if the 42 correspondent node does not support QoS, it would be useful to be 43 able to reserve at least local resources at the access network, 44 especially wireless link resources. Additionally, for mobile nodes 45 the continuity of QoS is disturbed due to end-to-end signaling or 46 slow re-reservations of resources after each handover. This draft 47 proposes a simple enhancement to RSVP, so that initial resource 48 reservations and re-reservations due to host mobility can be done 49 locally in an access network. 51 Changes since -03 52 - Updated boilerplates 53 - Removed discussion on using the CAP Object (not really an option) 54 - Removed discussion and suggestion on using anycast or multicast 55 addresses when sending the initial Path Request. This is more 56 like a hack and trick, and not really good and clear engineering. 57 - Updated references and author information 59 Changes since -02 60 - Clarified parts of the text, e.g. Section 2.4 62 Changes since -01 63 - Some clarifications and editorial changes 65 Table of Contents 67 1 Introduction ................................................. 2 68 1.1 Related work ............................................... 3 69 2 Local QoS Support ............................................ 4 70 2.1 Upstream transfers ......................................... 5 71 2.2 Downstream transfers ....................................... 6 72 2.3 Additional functionality ................................... 7 73 2.4 Addressing Issues .......................................... 8 74 2.5 Interworking Issues ........................................ 9 75 3 Fast local repair for mobile nodes ........................... 11 76 4 Security Consideration ....................................... 13 77 5 IANA Considerations .......................................... 14 78 6 Summary ...................................................... 14 79 7 Normative References ......................................... 15 80 8 Non-Normative References ..................................... 15 81 9 Authors' Addresses ........................................... 16 83 1. Introduction 85 Future mobile access networks will be based on IP technology. This 86 implies that, on the network layer, all traffic, both traditional 87 data and streamed data like audio or video, is transmitted as 88 packets. Increasingly popular multimedia applications would benefit 89 from better than best-effort service from the network, a forwarding 90 service with strict Quality of Service (QoS) with guaranteed minimum 91 bandwidth and bounded delay. Other applications, such as electronic 92 commerce, network control and management, and remote login 93 applications, would also benefit from a differentiated treatment. 95 The IETF has two main models for providing differentiated treatment 96 of packets in routers. The Integrated Services (IntServ) model [1] 97 together with the Resource Reservation Protocol (RSVP) [2] [3] 98 provides per-flow guaranteed end-to-end transmission service. The 99 Differentiated Services (DiffServ) framework [4] provides non- 100 signaled flow differentiation that usually provides, but does not 101 guarantee, proper transmission service. 103 However, these architectures have weaknesses, for example, RSVP 104 requires support from both communication end points and from the 105 intermediate routers, and the protocol has performance issues in 106 mobile environments. DiffServ can only provide statistical 107 guarantees and is not well suited for dynamic environments. The 108 Internet Architecture Board has outlined additional issues related to 109 these two architectures [5]. 111 Let us consider a scenario, where a fixed network correspondent node 112 (CN) would be sending a multimedia stream to an end host behind a 113 wireless link. If the correspondent node does not support RSVP it 114 cannot signal its traffic characteristics to the network and request 115 specific forwarding services. Likewise, if the correspondent node is 116 not able to mark its traffic with a proper DiffServ Code Point (DSCP) 117 to trigger service differentiation, the multimedia stream will get 118 only best-effort service which may result in poor visual and audio 119 quality in the receiving application. Even if the connecting wired 120 network is over-provisioned, an end host would still benefit from 121 local resource reservations, especially in wireless access networks, 122 where the bottleneck resource is most probably the wireless link. 124 We propose a slight modification to RSVP that allows distinguishing 125 local network reservations from the end-to-end reservations. The end 126 host does not need to know the access network topology or the nodes 127 that will reserve the local resources. The reservation message itself 128 identifies the intention and the access network will find the correct 129 network node(s) to respond to the reservation. Note that the scheme 130 is not tied to only mobile networks but can be used in any access 131 network that needs flexible local resource allocations. The first 132 sketch of this solution appeared in [10] and [11], although some 133 implementation ideas have changed since. 135 The localized RSVP signaling would fit well, for example, with a SIP 136 session, where a call set up can have a pre-condition: if the request 137 for local resources is successful, the end-host can send the COMET 138 message and make the call "ring" [15]. Both ends would use their own 139 local reservations. 141 All mobility-related terminology in this document are taken from 142 [16]. Therefore, the commonly used term 'access router' (AR) means 143 the 'default router'. 145 1.1. Related work 147 Currently we can identify two ways to signal QoS requirements to an 148 access network: DiffServ Code Points (DSCP) and RSVP with IntServ. In 149 the DiffServ-based solution an end host can mark the upstream packets 150 with proper DSCP values, but for the downstream the gateway on the 151 edge of the access network must be able to identify and handle the 152 preferred streams. This can be accomplished with default values for 153 different micro flows in the Service Level Agreement negotiated 154 between the client and the access network service provider. 156 An alternative way to make use of DiffServ could be through a 157 Bandwidth Broker [6] [7] [8] that dynamically returns the proper code 158 point for each flow: when the first packet of a flow arrives at the 159 access network edge router, it requests the proper code point from 160 the Bandwidth Broker. The router maintains a mapping from micro flow 161 identification to the DiffServ code point (soft state) so that future 162 packets can be directly identified and labeled. Still, this would 163 require a protocol that the end host could use to dynamically adjust 164 the mapping information stored at the access network edge for the 165 incoming traffic. 167 RSVP can provide the signaling mechanism for QoS requirements to the 168 access network. For upstream reservations, the end host would send 169 the Path message to the access network edge router, which would 170 return the Resv message and set up the reservations. The edge router 171 would act as an RSVP proxy [9]. However, the reservation in the 172 downlink direction is not as straightforward since the downlink 173 reservation needs to be initiated by the RSVP proxy. We would need a 174 way to trigger the proxy to initiate the RSVP signaling for a 175 downlink flow. 177 Thus, these mechanisms do not seem to solve the problem entirely. The 178 DiffServ mechanisms cannot provide explicit resource reservations. 179 The problem with the RSVP proxy approach is that the proxy cannot 180 automatically distinguish reservations that would be answered by the 181 correspondent node and reservations that would require interception. 182 Additionally, the RSVP proxy needs a way to know when to allocate 183 resources for incoming flows. Mobile access networks also add to the 184 problems, since mobile nodes can frequently change their point of 185 attachment in the network and resource allocations need to be re- 186 arranged, including changing the serving RSVP proxy. 188 2. Local QoS Support 190 The usual signaling model of RSVP includes the data sender and 191 receiver, and a network of RSVP routers. The data sender initiates 192 the RSVP signaling by sending the Path message. This message is 193 routed through the network, setting states in RSVP routers, and 194 finally arriving at the data receiver. The receiver then responds to 195 the signaling by sending the Resv message, which applies the 196 reservation for the data stream. 198 If the data receiver is not RSVP-aware, it can not respond to the 199 signaling and make the resource reservation happen. Similarly, if the 200 receiver is RSVP-aware, but the sender is not, the sender can not 201 initiate the signaling for the resource reservation. 203 In the Localized RSVP scheme, we expect the local end host to be 204 RSVP-aware and we add an RSVP-aware application to a router in the 205 local access network. This 'proxy' is called the Localized RSVP Proxy 206 server (LRSVP proxy) and is located somewhere within the local access 207 network - a good place would be the access network gateway. For local 208 reservations, the proxy acts on behalf of correspondent nodes. In 209 this discussion, from a software engineering point of view, the proxy 210 is its own process running on the router. Thus, the following three 211 logical functions are kept separate: basic IP routing, basic RSVP 212 message processing, and LRSVP proxy functionality. 214 Now, in order to distinguish local reservations from end-to-end 215 reservations, we use one bit in the unused Flags field in the RSVP 216 Session Object. The Local Indication (LI) bit (currently we use bit 217 0x8) is used to differentiate reservations that are internal to the 218 access network. When the bit is set the RSVP message is part of local 219 resource signaling and the RSVP router running the proxy will not 220 forward the message to the next hop but instead give the message to 221 the RSVP-application running on the router. A default value of zero 222 indicates standard end-to-end signaling, where the proxy application 223 is not concerned. 225 We also need a second bit, the Expedited Refresh (ER) bit (currently 226 we use bit 0x4), to indicate that a Path message is sent as a refresh 227 to a broken path and must be forwarded immediately. This indication 228 is needed because each RSVP hop propagates a Path message before a 229 timeout only if the Path state has changed - when a route changes at 230 the receiver end of the data flow, a Path message is needed to set up 231 again the Path state. This is discussed in more detail later. 233 When the local end host wants to make a resource reservation for a 234 downstream flow, it needs a Path message from a node on the data 235 path. If the data sender is not RSVP-aware, the local end host can 236 trigger the LRSVP proxy to send the Path message on behalf of the 237 data sender. A new message type called "Path Request", with an 238 initial message type number 8, is used to request a Path message from 239 the local RSVP proxy. This message has the same structure as a 240 standard Path message. 242 A second message called "Path Request Tear", with an initial message 243 type number 9, is used to tear down a downstream reservation. Note 244 that due to the new bits and message types, all RSVP routers inside 245 the access network must be upgraded with the LRSVP extension. 247 When a local end host wants to reserve resources in the local access 248 network, it uses the LI flag in RSVP messages to indicate a local 249 reservation. The structure of the RSVP messages follows the RSVP 250 standard. When the router running the LRSVP proxy receives an RSVP 251 message with the LI bit set it will notice that the flag was set and 252 does not forward the message further to the next hop. The RSVP daemon 253 on the router gives the message to the local RSVP application, which 254 responds according to the following description. 256 2.1. Upstream transfers 258 Setting local upstream reservations is straightforward and follows 259 closely the standard RSVP functionality. The local end host sends the 260 usual Path message, but sets the LI flag bit in the Session Object. 261 The Session Object of the message defines the destination of the flow 262 that will eventually be transmitted from the local end host, and the 263 Sender Template provides information about the local end host itself. 265 [END HOST] [Access Router] [X-OVER ROUTER] [PROXY] [CN] 266 | | | | | 267 |------------- Path towards CN (LI) ---------->| | 268 | | | | | 269 | | | (proxy intercepts) | 270 | | | | | 271 | | |<---- Resv ----| | 272 | |<---- Resv ----| | | 273 |<---- Resv ---| | | | 274 | | | | | 276 Figure 1: Local Upstream reservation 278 The Path message is routed within the access network and sets the 279 Path state in RSVP routers. When the LRSVP proxy receives the Path 280 message, it notes due to the LI bit that the reservation is meant to 281 stay within the access network and responds with a Resv message. It 282 will not forward the Path message further to the next hop. When a 283 Resv message arrives at the local end host, the resources for the 284 session defined in the Path message have been allocated. 286 2.2. Downstream transfers 288 Before setting a downstream resource reservation, the local end host 289 needs to be aware of the data senders. For multimedia communications, 290 a session is usually initiated with application layer protocols like 291 SIP [15] or RTSP [12]. Based on this correspondence, the local end 292 host knows the necessary information about the sender. Another, more 293 coarse reservation could be set, for example, for browsing different 294 audio servers; the local end host would indicate in the RSVP messages 295 that the sender will use UDP. It is, therefore, possible to make 296 resource reservations for any sender that wants to communicate with 297 the local end host. However, in order to allow for more accurate QoS 298 support, more information should be given. The way to find this 299 information is out of scope of this document. 301 In order to set up a local downstream reservation we need a way to 302 signal the LRSVP proxy to initiate the RSVP reservation set up on 303 behalf of the sender(s), that is, to send a Path message. To achieve 304 this, the local end host sends the Path Request message with the LI 305 flag bit set (Fig. 2). The Path Request message is identical to a 306 standard Path message apart from the message type field. The Session 307 Object must include information about the recipient, the local end 308 host in this case, and the Sender Template must define the expected 309 sender(s). The Traffic specification (Tspec) can either be based on 310 the local end user's wishes, a best estimate of the incoming traffic 311 characteristics, or on application level session signaling prior to 312 the transfer. 314 [END HOST] [Access Router] [X-OVER ROUTER] [PROXY] [CN] 315 | | | | | 316 |------------ Path Request towards CN (LI) --->| | 317 | | | | | 318 | | | (proxy intercepts) | 319 | | | | | 320 | | |<- Path (LI) --| | 321 | |<- Path (LI) --| | | 322 |<- Path (LI) -| | | | 323 | | | | | 324 |- Resv (LI) ->| | | | 325 | |-- Resv (LI) ->| | | 326 | | |-- Resv (LI) ->| | 327 | | | | | 329 Figure 2: Local downstream reservation 331 When the LRSVP proxy receives this message, it detects that the 332 message is meant to stay within the access network. The message type 333 indicates that the proxy should initiate an RSVP reservation for a 334 downstream flow and use the information in the message to fill the 335 objects in a Path message. The proxy now generates a Path message 336 that includes the parameter values in the Path Request message and 337 sends it towards the local end host. 339 When the local end host receives the Path message, it responds with a 340 Resv message with the LI flag set. This reserves the downstream 341 resources within the access network for the senders originally 342 identified by the local end host. 344 The Path Request message can also be used end-to-end, to request the 345 correspondent node to initiate a resource reservation. In this case, 346 the LI bit must not be set, since it would stop the message at the 347 local access network. 349 2.3. Additional functionality 351 All the other features of RSVP are used with LRSVP in the standard 352 way including the local repair mechanism and reservation tear down. 353 Downstream reservations are torn down with the Path Request Tear 354 message. The operation follows that of the Path Request: the message 355 does not change states within the network, but only triggers the 356 proxy to send a Path Tear message towards the end host for the 357 specified session. 359 All messages used for local reservations must have the LI flag set in 360 order to keep the signaling within the access network. Intermediate 361 RSVP routers between the local end host and the LRSVP proxy should 362 not process the Path Request message and they should forward it as an 363 ordinary IP packet. An enhancement to the local repair changes this 364 operation and is discussed later. 366 The proposed scheme also allows RSVP to be used to signal DiffServ 367 Code Points in a DiffServ access network using the RSVP DCLASS object 368 [13]. The DCLASS object is used to represent and carry DiffServ code 369 points within RSVP messages. The local end host can use the DCLASS 370 object to instruct the LRSVP proxy to mark incoming traffic with 371 certain DiffServ code points to trigger different forwarding behavior 372 within the DiffServ access network. The local end host, however, 373 needs to be aware of the different code point values and the related 374 services, especially if other than standardized code points are used. 375 This information can be part of host auto-configuration, for example. 377 Furthermore, the proposed signaling can be used at both ends of a 378 data stream. For example, if the two end hosts in different access 379 networks are communicating with each other, both of them could use 380 the mechanism to allocate resources, for example, in their own access 381 networks, independently of each other. This could happen, if the two 382 access networks had a different view of QoS, one uses only IntServ 383 and RSVP, while the other also uses DiffServ. In such a scenario, 384 however, it may be more practical to use RSVP end-to-end, even if the 385 core network connecting the two access networks does not support 386 RSVP. 388 2.4. Addressing Issues 390 When the local end host sends Path or Path Request messages, it needs 391 to use some IP address as the destination in the IP header. There are 392 various options about which address the local end host can or can not 393 use. The local end host must use in priority order (if known): 395 1. The address of the correspondent host, 396 2. The address of a proper LRSVP proxy, 397 3. The address of the next-hop RSVP router, or 398 4. The address of the default router. 400 The first option may not be possible, if the end host wants to 401 allocate resources only for certain services regardless of the 402 sender, HTTP, for example. The second possible address could be given 403 through auto-configuration. The third option would be to send the IP 404 packet to the next-hop RSVP router, if the end host has knowledge of 405 it - ideally, this would be the default router, in a mobile access 406 network, it would be the access router. 408 Finally, if any of the earlier addresses are not known, the end host 409 may try to send the RSVP packet to the default router, and see if the 410 router is also running an RSVP daemon and could handle the 411 reservation attempt. If the default router is not running an RSVP 412 daemon, it will return an ICMP error message. 414 A further concern arises if the access network has several inbound 415 routes. It is possible that the local downstream reservation 416 initiated by the end host is set on a wrong LRSVP proxy, one that 417 will not get the packets arriving to the end host. This seems more of 418 a network design issue and therefore the access network operator must 419 locate the LRSVP proxies based on the packet routing - the proxies 420 could even be co-located at the access routers. 422 2.5. Interworking Issues 424 The Localized RSVP makes use of two bits in the Session Object and 425 adds two new message types. There can be situations where such a 426 currently non-standard message arrives at a standard RSVP router. 428 According to the message processing rules in RFC2209 [18], the Path 429 Request and Path Request Tear messages would be forwarded intact by 430 standard RSVP routers. However, for standard RSVP message, the bits 431 used by LRSVP may or may not be kept between RSVP hops, and, thus, 432 the indication of local signaling or the need for an expedited 433 refresh may be lost. Therefore, all RSVP routers within an access 434 network wanting to support local reservations must be set to keep the 435 bits intact. 437 In one scenario, the local network of the end host would not 438 understand the LRSVP extension or even standard RSVP. Thus, Path 439 messages with the LI bit and Path Request message can be routed out 440 of the local network. If the local network of the correspondent node 441 has support for LRSVP, that LRSVP proxy gets the Path or Path Request 442 message with the LI bit set from the external network. The proxy must 443 drop the message and respond with a PathErr message and use a new 444 error code called "LRSVP not supported". This would inform the host 445 that LRSVP is not supported and it still can try end-to-end 446 signaling. 448 Another interesting scenario arises when the correspondent node is a 449 mobile node and the parties use route optimization. It can happen, 450 that the correspondent node is actually in the same access network as 451 the end host using LRSVP, and either or both nodes try to reserve 452 local resources independently of each other. Now it is possible that 453 Path and Path Request messages with the LI bit set are routed 454 directly to the correspondent node, without going through a local 455 network LRSVP proxy. 457 A solution would be that end hosts can also perform the same 458 functions as an LRSVP proxy, that is, answer to Path messages with 459 the LI bit set and, most importantly, handle Path Request messages as 460 well: 462 o If an end host receives an unsolicited Path message with the LI bit 463 set, it should respond with a Resv message and not set the LI bit. 464 The reason is that that if the LRSVP proxies drop Path messages with 465 the LI bit set coming from external networks, the local end hosts can 466 trust that if they receive such a message, it must have (if the 467 network is properly configured) arrived from a node in the local 468 access network. Now, if our end host that sent the Path message 469 receives the Resv without the LI bit, it can use this as an 470 indication that the correspondent node is in the local access network 471 and may remove the LI bit in subsequent messages belonging to the 472 same session. 474 o Similarly, if the correspondent node receives a Path Request 475 message, it should respond with a Path message that does not have the 476 LI bit set. Again, if our end host receives a Path message without 477 the LI bit set in response to the local Path Request sent earlier, it 478 can use this as an indication that the correspondent node is in the 479 local domain and it may remove the LI bit in subsequent messages 480 belonging to the same session. 482 Now, if the correspondent node moves again and changes access 483 networks, the signaling is already set to standard end-to-end mode 484 and reservations in the new RSVP-aware access network would be set in 485 place. However, changing access networks implies most probably a 486 change in the IP address assigned to the CN, which forces a re- 487 reservation of resources. 489 In the latter scenario, it is quite possible, that the mobile 490 correspondent node, located in the same access network as our end 491 host, is not (L)RSVP aware. Thus, it cannot respond to the RSVP 492 messages and local, actually, any kind of RSVP-based, reservations 493 are not possible. 495 Moreover, the location of the LRSVP proxy may yet affect the 496 signaling of two nodes within the same access network. Consider the 497 case where each access router would also host an LRSVP proxy. Now if 498 the two communicating nodes are connected to different access 499 routers, the two nodes may use their own local reservations on the 500 last-hop link, but also a standard end-to-end reservation is 501 possible. 503 A further issue concerns the interactions between local and end-to- 504 end reservations: could a local reservation be 'upgraded' into an 505 end-to-end reservation? This should be possible for both directions: 507 o If the proxy receives a fully standard Path message from the local 508 network with the same session information as an existing local 509 reservation, it must forward the message as usual, but set a pending 510 Path state indication for the end-to-end reservation. If a Resv 511 arrives from the external network for this same session, it must 512 change the reservation to an end-to-end reservation. 514 o If the proxy receives a Path Request message from the local network 515 without the LI bit set, it must forward the message to the IP 516 destination address. If the proxy receives later a Path message from 517 the external network for an existing local session, it must set a 518 pending state for the end-to-end reservation. If a Resv is received 519 from the local end host without the LI bit set, the proxy must change 520 its state for the session to 'end-to-end' (by removing a local- 521 indication from its session structures) and forward the Resv message 522 further to the external network. 524 Thus, it would be possible to upgrade a local session to end-to-end 525 status. It is not clear whether there is a need for an end-to-end 526 session to be 'downgraded' into a local session. 528 Note that when the resource signaling is going end-to-end, the local 529 repair functionality may be affected. If both nodes use only local 530 reservations, the local repair at either end is propagated at most to 531 the local LRSVP proxy. With end-to-end reservations, the local repair 532 may be propagated further away from the moving node and its access 533 network. 535 3. Fast local repair for mobile nodes 537 The RSVP standard [2] defines that Path messages can perform a local 538 repair of reservation paths. When the route between the communicating 539 end hosts changes, a Path message will set the Path state of the 540 reservation on the new route and a subsequent Resv message will apply 541 the resource reservation. Therefore, by sending a Resv message a host 542 cannot alone update the reservation, and thus perform a local repair, 543 before a Path message has passed. The RSVP specification also says 544 that in order to provide fast adaptation to routing changes without 545 the overhead of short refresh periods, the local routing protocol 546 module can notify the RSVP process of route changes for particular 547 destinations. The RSVP process should use this information to trigger 548 a quick refresh of state for these destinations, using the new route 549 (Chapter 3.6, RFC2205 [2]). However, for example, Mobile IP, does not 550 affect routing directly in routers, and thus mobility may not be 551 noticed at intermediate RSVP routers. 553 When the mobile node has moved, it can send a Path message for each 554 upstream resource reservation and initiate the standard local repair 555 mechanism (Fig. 3). If there is no cross-over router, and the Path 556 message arrives at a new LRSVP proxy, the proxy will reply to the 557 Path with a Resv, similarly as it would for a new resource 558 reservation request (what this actually looks like to the new proxy). 560 [END HOST] [NEW AR] [X-OVER ROUTER] [RSVP ROUTER] [PROXY] 561 | | | | | 562 |-- Path towards CN (LI)---->| | | 563 | | | | | 564 | | (X-over router intercepts) | | 565 | | | | | 566 | |<- Resv (LI) -| | | 567 |<- Resv (LI)-| | | | 568 | | | | | 570 Figure 3: Fast upstream reservation 572 For the downstream, the mobile node will need to wait until it 573 receives a Path message, setting up the Path state on the new route. 574 Only after receiving the Path message, the mobile can send a Resv 575 message to re-reserve the downstream resources. 577 The Path Request message can be used in mobile networks to initiate a 578 faster local repair of downstream reservations on behalf of a mobile 579 node that changed access routers during an ongoing RSVP session. When 580 the mobile node changes its access router in the network, it should 581 send the Path Request message immediately after the handover (Fig 4). 583 [END HOST] [NEW AR] [X-OVER ROUTER] [RSVP ROUTER] [PROXY] 584 | | | | | 585 |-------------- Path Request towards CN (LI,ER) --------------->| 586 | | | | | 587 | | | |<-Path (LI,ER)-| 588 | | |<-Path (LI,ER)-| | 589 | |<-Path (LI,ER)-| | | 590 |<-Path (LI,ER)-| | | | 591 | | | | | 592 |- Resv (LI) -->| | | | 593 | |- Resv (LI) -->| | | 594 | | | | | 596 Figure 4: Fast downstream reservation 598 The message must have the ER bit set to indicate that the request is 599 for an existing session and triggered due to movement. The Path 600 Request message is forwarded through the intermediate RSVP routers 601 until it arrives at the LRSVP proxy. The message would then instruct 602 the proxy to initiate a local repair by sending the needed Path 603 message. The proxy must set the ER bit in the Session Object to 604 indicate that this Path message is not an ordinary refresh message 605 but instead triggered by a routing change and therefore must be 606 forwarded immediately to the next hop. If the ER bit is not set, the 607 RSVP router in Fig. 4 would not forward the Path message immediately 608 towards the mobile node but, instead, would wait until its own 609 scheduled refresh timeout. 611 If the movement of the mobile node results in packets to flow through 612 a new LRSVP proxy, the Path Request message would re-reserve the 613 local resources for the new path. In this case, the proxy notes that 614 the ER bit is set, but, since there is no existing state, it will 615 initiate a new reservation. The ER bit must not be set in the 616 following Path message since the reservation is a new one for this 617 route. 619 A enhancement to the scheme would allow a cross-over RSVP router that 620 has the reservation for the mobile node stored on a different 621 interface to send the needed Path message (Fig. 5). RSVP routers 622 inside the access network would look into Path Request messages. If 623 the router notices it is the cross-over router, it sends a Path 624 message towards the local end host. If an RSVP router sends the Path 625 message, it must not send the Path Request message any further. This 626 requires more processing from intermediate RSVP routers, but allows 627 for faster state updates. This functionality would be especially 628 important when the session is end-to-end instead of local: the Path 629 Request message would not go to the correspondent node, but trigger 630 the closer cross-over router to repair the local path of the 631 reservation. 633 [END HOST] [NEW AR] [X-OVER ROUTER] [PROXY] 634 | | | | 635 |- Path Request towards CN (LI,ER) ->| | 636 | | | | 637 | | (X-over router intercepts) | 638 | | | | 639 | |<--- Path (LI) ---| | 640 |<-- Path (LI) ---| | | 641 | | | | 642 |--- Resv (LI) -->| | | 643 | |--- Resv (LI) --->| | 644 | | | | 646 Figure 5: Enhancement of the fast downstream reservation 648 The LI flag must be set in all RSVP refresh messages if the 649 reservation is set for the local access network. This will prevent a 650 refresh message, like the Path Request message, to be routed out of 651 the access network. 653 4. Security Consideration 655 The Path Request message triggers most processing at the LRSVP proxy. 656 This could potentially be used for Denial of Service attacks. A 657 possible solution is to make RSVP daemons located on access routers 658 make a sanity check on all Path Request (and Path Request Tear) 659 messages: the receiver of the stream must be a node on a link 660 connected to the AR. This has the benefit that the proxy may trust 661 that the access router has validated the message; this can be seen as 662 distributed processing of the authentication and authorization data. 663 The same considerations apply for the Path message. In order to 664 secure any RSVP signaling, a security association must be set up 665 between the local end hosts and the access routers. 667 The RSVP daemon at the end hosts and LRSVP proxy must also modify 668 their security/sanity checks to allow the end host to send the Path 669 Request with apparently suspicious session information (identifying 670 the correspondent node(s)). Also, the proxy must be able to send RSVP 671 messages "on-behalf" of external network nodes. 673 The LRSVP proxy must be configured to identify its ingress and egress 674 interfaces. If the proxy receives a Path or a Path Request message 675 with the LI bit set from outside the access network, it must drop the 676 message. 678 The two new messages can make use of the standard RSVP INTEGRITY and 679 POLICY objects. This requires that the MN and ARs share the required 680 keys. For the remaining functionality, the security considerations 681 with standard RSVP apply, which are analyzed well by the NSIS WG in 682 [17]. 684 5. IANA Considerations 686 IANA needs to allocate the two flag bits in the RSVP Session Object, 687 the LI and ER bits. In addition, IANA needs to give two RSVP message 688 type numbers to the Path Request and Path Request Tear messages and 689 one Error Type indicating that a local resource reservation is not 690 allowed. 692 6. Summary 694 In summary, the Localized RSVP requires the following changes in the 695 standard RSVP protocol: 697 a) A new message type and number, named Path Request (initially 698 number 8). 700 b) A new message type and number, named Path Request Tear (initially 701 number 9). 703 c) A bit from the Session Object for the use as the Local Indication 704 (LI) (initially bit 0x8). 706 d) A bit from the Session Object for use as the Expedited Refresh 707 (ER) indication (initially bit 0x4). 709 e) An RSVP router must keep the LI bit set in all messages belonging 710 to that session, if it encounters packets with the bit set. 712 f) An RSVP router that is not also a proxy, must forward an RSVP 713 packet with a message type "Path Request" without storing state. 715 g) An RSVP router that is not also a proxy, must forward an RSVP 716 packet with a message type "Path Request Tear" without affecting the 717 stored state. 719 h) An access network RSVP router should be able to use the Path 720 Request as an indication of the need for a local repair. This can 721 enable faster reservation set up following a handover. This affects 722 point f), because the router that receives a Path Request must first 723 check if it has the Path state stored on another network interface. 724 If one is present, the Path Request message should not be forwarded 725 to the next hop and instead the router must send a Path message 726 towards the mobile node. 728 i) A new error code to indicate that the access network does not 729 support local reservations. If local resources cannot be requested, 730 the end-host can always try to do end-to-end signaling. 732 To summarize, these changes are small and would make RSVP more 733 appealing as a signaling protocol for IP access networks. The changes 734 are required only within access networks, unless the Path Request 735 message is deemed useful to use end-to-end through the Internet. 737 7. Normative References 739 [1] R. Braden, D. Clark, S. Shenker, "Integrated Services in the 740 Internet Architecture: an Overview". RFC 1633, June 1994. 742 [2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. "Resource 743 ReSerVation Protocol (RSVP), Version 1 Functional Specification. RFC 744 2205, September, 1997. 746 [3] J. Wroclawski, "The Use of RSVP with IETF Integrated Services. 747 RFC 2210, September, 1997. 749 [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An 750 Architecture for Differentiated Services". RFC 2475, December, 1998. 752 [13] Y. Bernet,"Format of the RSVP DCLASS Object". RFC 2996, November 753 2000. 755 [18] R. Braden, "Resource ReSerVation Protocol (RSVP) -- Version 1 756 Message P rocessing Rules". RFC 2209, September 1997. 758 8. Non-Normative References 760 [5] G. Huston, "Next Steps for the IP QoS Architecture". RFC 2990, 761 November 2000. 763 [6] K. Nichols, V. Jacobson, L. Zhang, "A Two-bit Differentiated 764 Services Architecture for the Internet". RFC 2638, July 1999. 766 [7] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer, "SBM 767 (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission 768 Control over IEEE 802-style networks". RFC 2814, May 2000. 770 [8] Phil Chimento and Ben Teitelbaum, "QBone Bandwidth Broker 771 Architecture". The Internet2 initiative, June 2000. 772 (http://qbone.internet2.edu/bb/bboutline2.html). 774 [9] S. Gai, D. G. Dutt, N. Elfassy, Y. Bernet, "RSVP Proxy". Internet 775 Draft (work in progress), March 2002 (expired) (draft-ietf-rsvp- 776 proxy-03.txt). 778 [10] Jukka Manner and Kimmo Raatikainen, "Extended Quality-of-Service 779 for Mobile Networks". Proceedings of the 9th International Workshop 780 on Quality of Service (IWQoS), June 2001, pp. 275-280. Published in 781 the series Springer Lecture Notes in Computer Science (LNCS) 2092. 783 [11] IST-BRAIN Project, "Deliverable D2.2: BRAIN architecture 784 specifications and models, BRAIN functionality and protocol 785 specification". March 2001, (available at: http://www.ist- 786 brain.org). 788 [12] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 789 Protocol (RTSP)". RFC 2326, April 1998. 791 [15] J. Rosenberg et al., "SIP: Session Initiation Protocol". RFC 792 3261, June 2002 794 [16] J. Manner, and M. Kojo, "Mobility related terminology". RFC 795 3753, June 2004. 797 [17] H. Tschofenig, "RSVP Security Properties". Internet Draft (work 798 in progress), September 2004. 800 9. Authors' Addresses 802 Questions about this document may be directed to: 804 Jukka Manner 805 Department of Computer Science 806 University of Helsinki 807 P.O. Box 68 808 FIN-00014 HELSINKI 809 Finland 811 Voice: +358-9-191-51298 812 Fax: +358-9-191-51120 813 E-Mail: jmanner@cs.helsinki.fi 815 Markku Kojo 816 Department of Computer Science 817 University of Helsinki 818 P.O. Box 68 819 FIN-00014 HELSINKI 820 Finland 822 Voice: +358-9-191-51305 823 Fax: +358-9-191-51120 824 E-Mail: kojo@cs.helsinki.fi 826 Kimmo Raatikainen 827 Department of Computer Science 828 University of Helsinki 829 P.O. Box 68 830 FIN-00014 HELSINKI 831 Finland 833 Voice: +358-50-483-6275 834 Fax: +358-9-191-51120 835 E-Mail: kraatika@cs.helsinki.fi 837 Tapio Suihko 838 VTT Information Technology 839 P.O. Box 1203 840 FIN-02044 VTT 841 Finland 842 Voice: +358-9-456-6078 843 Fax: +358-9-456-7028 844 E-Mail: tapio.suihko@vtt.fi 846 Mika Liljeberg 847 Nokia Research Center 848 P.O. Box 407 849 FIN-00045 Nokia Group 850 Finland 852 Voice: +358-50-4836791 853 E-Mail: Mika.Liljeberg@nokia.com 855 Acknowledgment 857 This work has been partially performed in the framework of the IST 858 project IST-2000-28584 MIND, which is partly funded by the European 859 Union. The authors would like to acknowledge the help of their 860 colleagues in preparing this document, in particular Eleanor Hepworth 861 and Alberto Lopez. 863 Copyright (C) The Internet Society (2004). This document is subject 864 to the rights, licenses and restrictions contained in BCP 78, and 865 except as set forth therein, the authors retain all their rights. 867 This document and the information contained herein are provided on an 868 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 869 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 870 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 871 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 872 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 873 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.