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