idnits 2.17.1 draft-manner-lrsvp-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. 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.) -- The document date (May 14, 2002) is 8018 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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 2990 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2638 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-03) exists of draft-ietf-rsvp-proxy-02 -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 2326 (ref. '12') (Obsoleted by RFC 7826) == Outdated reference: A later version (-03) exists of draft-ietf-issll-rsvp-cap-02 -- Possible downref: Normative reference to a draft: ref. '14' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 6 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: November, 2002 M. Kojo 5 M. Liljeberg 6 K. Raatikainen 7 May 14, 2002 9 Localized RSVP 10 12 Status of this Memo 14 This document is a submission to the NSIS Working Group of the 15 Internet Engineering Task Force (IETF). Comments should be submitted 16 to the nsis@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 This Internet-Draft will expire in November, 2002. 39 Copyright Notice 41 Copyright (C) The Internet Society (2000). All Rights Reserved. 43 Abstract 45 Guaranteed QoS for multimedia applications is based on reserved 46 resources in each node on the end-to-end path. For stationary nodes 47 this may be achieved but not so easily for mobile nodes. Many 48 multimedia applications become less useful if the continuity of QoS 49 is disturbed due to end-to-end signalling or slow re-reservations of 50 resources after each handover. Additionally, if the correspondent 51 node does not support QoS, it would be useful to be able to reserve 52 at least local resources, especially wireless link resources. This 53 draft proposes small modifications to RSVP, so that initial resource 54 reservations and re-reservations due to host mobility can be done 55 locally in an access network. 57 Table of Contents 59 1 Introduction ................................................. 2 60 1.1 Related work ............................................... 3 61 2 Local QoS Support ............................................ 4 62 2.1 Upstream transfers ......................................... 4 63 2.2 Downstream transfers ....................................... 5 64 2.3 Additional functionality ................................... 5 65 3 Fast local repair ............................................ 7 66 4 Issues with the localized signalling ......................... 8 67 5 Signalling diagrams .......................................... 10 68 6 Security Consideration ....................................... 10 69 7 Summary and Future Work ...................................... 11 70 8 References ................................................... 12 71 9 Author's Addresses ........................................... 13 73 1. Introduction 75 Future mobile networks will be based on IP technology. This implies 76 that, on the network layer, all traffic, both traditional data and 77 streamed data like audio or video, is transmitted as packets without 78 knowledge of any higher layer data flows. At the same time different 79 multimedia applications are becoming increasingly popular. These 80 applications require better than best-effort service from the 81 connecting network. They require strict Quality of Service (QoS) with 82 guaranteed minimum bandwidth and maximum delay. Other applications, 83 such as electronic commerce, network control and managment, and 84 telnet-type applications, would also benefit from a differentiated 85 treatment. 87 The Internet Engineering Task Force (IETF) has proposed two main 88 models for providing differentiated treatment of packets in routers. 89 The Integrated Services (IntServ) model [1] together with the 90 Resource Reservation Protocol (RSVP) [2] [3] provides per-flow 91 guaranteed end-to-end transmission service. The Differentiated 92 Services (DiffServ) framework [4] provides non-signaled flow 93 differentiation that usually provides but does not guarantee proper 94 transmission service. These architectures, however, have problems, 95 for example, RSVP requires support from both communication end points 96 and from the intermediate nodes. DiffServ, on the other hand, 97 requires support from the sender of a stream and from the network 98 nodes. The Internet Architecture Board has outlined additional issues 99 related to these two architectures [5]. 101 Let's consider a scenario, where a fixed network correspondent node 102 (CN) would be sending a data stream to a mobile node behind a 103 wireless link. If the correspondent node does not support RSVP it 104 cannot signal its traffic characteristics to the network and request 105 specific forwarding services. Likewise, if the correspondent node is 106 not able to mark its traffic with a DiffServ Code Point (DSCP) to 107 trigger service differentiation, the multimedia stream will get only 108 best-effort service which may result in poor visual and audio quality 109 in the receiving application. Even if the connecting wired network is 110 over-provisioned, reserving local resources is especially important 111 in wireless access networks, where the bottleneck resource is most 112 probably the wireless link. For illustration purposes, we will only 113 consider a scenario with a mobile access network that is aware of the 114 proposed signaling mechanism and has mobile nodes as its clients. 116 In the absence of end-to-end QoS support, a mobile node could still 117 want to reserve resources from the access network for both outgoing 118 and incoming traffic. We propose a signaling mechanism based on a 119 slightly modified RSVP. Access network specific reservations would be 120 distinguished from the end-to-end reservations. The mobile node does 121 not need to know the access network topology or the nodes that will 122 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. However, the scheme is 125 not tied to only mobile networks but can be used in any network that 126 needs flexible local resource allocations. 128 This would be very beneficial, even if the QoS support is only 129 available in the access network. Furthermore, the same solution saves 130 us from end-to-end signaling even if all intermediate nodes on the 131 transmission path would support standard RSVP. This would allow, for 132 example, the mobile node to reserve wireless resources separately 133 from end-to-end resources. 135 1.1. Related work 137 Currently we can identify two ways to signal QoS requirements to an 138 access network: DiffServ Code Points (DSCP) and RSVP with IntServ. In 139 the DiffServ-based solution the mobile node can mark the upstream 140 packets with proper DSCP values, but for the downstream the gateway 141 on the edge of the access network must be able to identify and handle 142 the prefered streams. This can be accomplished with default values 143 for different micro flows in the Service Level Agreement negotiated 144 between the client and the access network service provider. 146 A second way to make use of DiffServ could be through a Bandwidth 147 Broker [6] [7] [8] that dynamically returns the proper code point for 148 each flow: when the first packet of a flow arrives at the access 149 network edge router, it requests the proper code point from the 150 Bandwidth Broker. The router maintains a mapping from micro flow 151 identification to the DiffServ code point (soft state) so that future 152 packets can be directly identified and labeled. Still, this would 153 require a protocol that the mobile node could use to dynamically 154 adjust the mapping information stored at the access network edge for 155 the incoming traffic. 157 RSVP can provide the signalling mechanism for QoS requirements to the 158 access network. For upstream reservations, the mobile node would send 159 the PATH message to the access network edge router, which would 160 return the RESV message and set up the reservations. The edge router 161 would act as an RSVP proxy [9]. However, the reservation in the 162 downlink direction is not as straightforward since the downlink 163 reservation needs to be initiated by the RSVP proxy. We would need a 164 way to trigger the proxy to initiate the RSVP signalling for a 165 downlink flow. 167 Thus, these mechanisms do not seem to solve the problem entirely. The 168 DiffServ mechanisms cannot provide explicit resource reservations. 169 The problem with the RSVP proxy approach is that the proxy cannot 170 automatically distinguish reservations that would be answered by the 171 correspondent node and reservations that would require interception. 172 Additionally, the RSVP proxy needs a way to know when to allocate 173 resources for incoming flows. Mobile access networks also add to the 174 problems, since mobile nodes can frequently change their point of 175 attachment in the network and resource allocations need to be re- 176 arranged, including changing the serving RSVP proxy. 178 2. Local QoS Support 180 Our solution to the problem of localized QoS co-ordination is based 181 on proxies and the RSVP local repair mechanism [2]. The proxy is 182 running on an RSVP node and is called the Localized RSVP Proxy server 183 (LRSVP proxy). In addition, we need a way to differentiate 184 reservations that are internal to the access network. We suggest 185 using one bit of the eight flag bits in the RSVP Session object for 186 this purpose. We use the bit 0x8 and call the flag a Local Indication 187 (LI). We also add a new message type called "Path Request" message 188 with an initial message type number 8 and a message called "Path 189 Request Tear" with an initial message type number 9. The first sketch 190 of this solution appeared in [10] and [11], although some 191 implementation ideas have changed since. 193 When a mobile node wants to reserve resources in the local network, 194 it uses the LI flag in RSVP messages to indicate a local reservation. 195 The structure of the RSVP messages follow the RSVP standard. The 196 LRSVP proxy that receives an RSVP message with the LI bit set will 197 notice that the flag was set, does not forward the message further to 198 the next hop and responds according to the following description. 200 2.1. Upstream transfers 202 Setting upstream reservations is straightforward and follows the 203 standard RSVP functionality. The mobile node sends the usual Path 204 message, but sets the LI flag. The Session Object defines the 205 destination of the flow that will eventually be transmitted from the 206 mobile, and the Sender Template provides information about the mobile 207 itself. 209 When the LRSVP proxy receives the Path message, it notes due to the 210 LI bit that the reservation is meant to stay within the access 211 network and responds with a Resv message. It will not forward the 212 Path message further to the next hop. If a Resv message arrives at 213 the mobile, the resources for the session defined in the Path message 214 have been allocated. 216 2.2. Downstream transfers 218 Before setting a downstream resource reservation, the mobile needs to 219 be aware of the data senders. For multimedia communications, a 220 session is usually initiated up with application layer protocols like 221 SIP or RTSP [12]. From that correspondence, the mobile knows the 222 necessary information about the sender. Another, more coarse 223 reservation could be set, for example, for browsing different audio 224 servers; the mobile node would indicate in the RSVP messages that the 225 sender will use UDP. It is thus possible to make resource 226 reservations for any sender that wants to communicate with the 227 mobile. However, in order to allow for more accurate QoS support, 228 more information should be given. 230 In order to set up the downstream reservation we need a way to signal 231 the LRSVP proxy to initiate the RSVP reservation setup on behalf of 232 the sender(s), that is, to send a Path message. To achieve this, the 233 mobile node sends the Path Request message with the LI flag set. The 234 Path Request message is identical to a standard Path message apart 235 from the message type field. The Session Object must include 236 information about the recipient, the mobile in this case, and the 237 Sender Template must define expected sender(s). The Traffic 238 specification (TSpec) can either be based on the mobile users wishes 239 or a best estimate of the incoming traffic characteristics, or on 240 application level session signalling prior to the transfer. 242 When the LRSVP proxy receives this message, it detects that the 243 message is meant to stay within the access network. The message type 244 indicates that the proxy should initiate an RSVP reservation for a 245 downstream flow and use the information in the message to fill the 246 field in a Path message. The proxy can now change the message type 247 from Path Request to Path, keep the LI flag, and send this Path 248 message towards the mobile node. Since the Session Object and Sender 249 Template were originally set "backwards", the proxy can copy these 250 entries directly as-is to the Path message. 252 When the mobile node receives the Path message, it responds with a 253 Resv message with the LI flag set. This reserves the downstream 254 resources within the access network for the senders originally 255 identified by the mobile. 257 2.3. Additional functionality 259 All the other features of RSVP are used with LRSVP in the standard 260 way including the local repair mechanism and reservation tear down. 262 Downstream reservations are torn down with the Path Request Tear 263 message. All messages used for local reservations must have the LI 264 flag set in order to keep the signaling within the access network. 265 Intermediate RSVP routers between the mobile node and the LRSVP proxy 266 must not process the Path Request message and they must forward it as 267 an ordinary IP packet. 269 The proposed scheme also allows RSVP to be used to signal DiffServ 270 Code Points in a DiffServ access network using the RSVP DCLASS object 271 [13]. The DCLASS object is used to represent and carry DiffServ code 272 points within RSVP messages. The mobile node can use the DCLASS 273 object to instruct the LRSVP proxy to mark incoming traffic with 274 certain DiffServ code points to trigger different forwarding behavior 275 within the DiffServ access network. The mobile node, however, needs 276 to be aware of the different code point values and the related 277 services, especially if other than standardized code points are used. 278 This information can be part of host auto-configuration, for example. 280 In addition, the LRSVP proxy may need information on how to map RSVP 281 requests to proper DiffServ classes if it wants to have closer 282 control of downstream resource allocations. This can be accomplished 283 by using standardized code point values for the DiffServ Assured 284 Forwarding service. Thus, our signalling mechanism can also be used 285 to give relative priority to specific flows without explicit resource 286 reservations. 288 Furthermore, the proposed signalling can be used at both ends of a 289 data stream. For example, if two mobile nodes in different access 290 networks are communicating with each other, both of them could use 291 the mechanism to allocate resources, for example on their own access 292 networks, independently of each other. This could happen, if the two 293 access networks had a different view of QoS, one uses only IntServ 294 and RSVP, while the other also uses DiffServ. In such a scenario, 295 however, it may be more practical to use RSVP end-to-end, even if the 296 core network connecting the two access networks does not support 297 RSVP. 299 If the reserved bits in the RSVP Session Object are deemed too 300 valuable to be used for this kind of signaling, the RSVP CAP-object 301 [14] could be used to carry the bit that identifies the signaling as 302 local. The CAP object can be used in the RSVP Path message to convey 303 end host/upstream node capabilities to the downstream network/nodes. 304 This would, however, add another eight bytes of headers in order to 305 carry a single bit of information. In addition, the processing of the 306 messages is more time consuming due to the extra header. In any 307 case, a new Path Request message is still needed, because it would 308 complicate the message processing in routers if the "request to send 309 a Path" was indicated as another bit in the CAP object. With the new 310 message type intermediate routers on the uplink can forward the RSVP 311 packet to the LRSVP proxy faster, since the router does not need to 312 examine the whole packet and the CAP object in order to find the same 313 information, just the message type. 315 3. Fast local repair 317 The RSVP standard [2] defines that Path messages can perform a local 318 repair of reservation paths. When the route between the communicating 319 end hosts changes, a Path message will set the state of the 320 reservation on the new route and a subsequent Resv message will make 321 the resource reservation. Therefore, by sending a Resv message a host 322 cannot alone update the reservation, and thus perform a local repair, 323 before a Path message has passed. It is also said in the RSVP 324 specification that in order to provide fast adaptation to routing 325 changes without the overhead of short refresh periods, the local 326 routing protocol module can notify the RSVP process of route changes 327 for particular destinations. The RSVP process should use this 328 information to trigger a quick refresh of state for these 329 destinations, using the new route (Chapter 3.6, RFC2205 [2]). 330 However, not all local mobility protocols, or even Mobile IP, affect 331 routing directly in routers, and thus mobility may not be noticed at 332 RSVP routers. 334 When the mobile has moved, it can send a Path message for each 335 upstream resource reservation and initiate the local repair 336 mechanism. But for the downstream, the mobile will need to wait until 337 it receives a Path message, refreshing the reservation states on the 338 new route. Only after receiving the Path message, the mobile can send 339 a Resv message to re-reserve the downstream resources. The Path 340 Request message could potentially be used in mobile networks to 341 initiate a faster local repair on behalf of a mobile node that 342 changed access points during an ongoing RSVP session. 344 When the mobile node changes its access point in the network, it 345 should send the Path Request message immediately after the handover. 346 The Path Request message is forwarded through the intermediate RSVP 347 routers until it arrives at the cross-over RSVP router that has the 348 reservation for the mobile node stored on a different interface. The 349 message would then instruct the cross-over router to initiate a local 350 repair by sending the needed Path message. 352 The cross-over router may be located between the LRSVP proxy and the 353 mobile node and will therefore respond to the message. Otherwise, the 354 Path Request message will arrive at an LRSVP proxy, which will 355 initiate a reservation refresh for the mobile. Thus, the closest 356 node to the mobile, the LRSVP proxy or cross-over router, will 357 respond to the routing change. 359 In some access networks, the access network gateways could also act 360 as LRSVP proxies. If the movement of the mobile node results in 361 packets to flow through a new gateway (and new proxy), the Path 362 Request message would re-reserve the local resources for the new 363 path. 365 However, the faster local repair scheme has the requirement that the 366 RSVP daemon running on the mobile needs to get an indication when a 367 handover has occurred. The change of access points is best noticed by 368 the link layer, through the actual wireless device. When the link 369 layer address of the access point changes, this event could trigger a 370 signal to the higher layers, including the RSVP-daemon that a 371 handover has happened. The way the higher layers then take this 372 signaling into account is not a concern of the link layer. 374 Initiation of the local repair must be done every time the access 375 point changes, regardless of whether the access router changes or 376 remains the same after the handover. If the access router remains the 377 same, the access router itself is the crossover router. The Path 378 Request message sent will be intercepted by this access router, which 379 will reply with the Path message and therefore initialize the 380 resource sharing through its new interface. (Note, that we make the 381 assumption, that each access point has its own dedicated network 382 interface on the access router.) If the access router changes, the 383 local repair mechanism will eventually arrive at either the crossover 384 router or at the access network gateway. 386 If the whole access network changes as a result of a handover, the 387 situation becomes more complex, and may require a full authentication 388 and admission control procedure to be initiated. From the QoS point 389 of view, the situation does not differ from a situation, where both 390 the access router and the network gateway changed. 392 The LI flag must be set in all RSVP refresh messages if the 393 reservation is set for the local access network. This will prevent 394 refresh message, like the Path Request message, to be routed out of 395 the access network. 397 4. Issues with the localized signalling 399 An important question remains with the localized signalling 400 mechanism: what destination address should the mobile use, when 401 initiating a downstream reservation setup? This has implications on 402 the network path, on which the reservation will be set up. 404 The Session object and the Sender Template define the parties 405 involved in the reservation. Thus, the destination IP address is not 406 needed in the reservation set up but has an effect on the routing of 407 the packets. The issue concerns the situations, where there are 408 several ingress routes to the access network. In such a scenario, 409 LRSVP proxies might be situated further away from the access routers, 410 closer to the edge of the access network, for example. 412 There are two fundamentally different options for the IP destination 413 address. The first option is that the mobile node can use the IP 414 address of the host that it intends to communicate with. This has the 415 benefit that a Path message will be routed according to the usual IP 416 routing mechanisms. Thus, the Path message will be routed to the 417 proxy that will eventually also receive the upstream data flow. 419 However, if the mobile wants to set up a reservation for the 420 downlink, on behalf of the correspondent node, there is a potential 421 problem. If the access network has several ingress routes, and hence, 422 most probably, several LRSVP proxies, the data flow may eventually 423 arrive through a path different from the path that had the 424 reservation in place. This can happen due to the basic property of 425 asymmetricy in IP routing. 427 The mobile node might set up a reservation on behalf of the 428 correspondent node through a path using LRSVP proxy A but the data 429 will actually arrive through a path using proxy B. A same problem 430 arises if the mobile node wants to reserve resources without an exact 431 sender IP address. The mobile might want resources for audio streams 432 initiated while browsing the Internet without specifying all possible 433 web servers that it may be using. 435 A solution to this problem is, that the mobile directs the localized 436 RSVP messages to all LRSVP proxies. This can be achieved using a 437 multicast address of all the LRSVP proxies. As a result, each LRSVP 438 in the access network would receive the RSVP packets, a Path or a 439 Path Request, and respond to the mobile. Since resource reservations 440 are set up on several paths but only some are actually needed in the 441 end, we need a way to remove unnecessary reservations. This can be 442 accomplished through the RSVP soft state mechanism: Unused 443 reservations are revoked using a timeout mechanism, no refresh 444 messages are sent for those paths. This is possible if the 445 reservation refresh is coupled with actual data transfered through 446 that reservation. Reservations are only kept alive if data is 447 actually sent through a particular path. 449 The multicast functionality can be further modified, so that a proxy 450 will not even send the Path message if it does not receive packets 451 from the specified sender within a timeout. Thus, no downstream 452 reservations are initialized for paths that are not carrying packets 453 belonging to the request. 455 It seems that there is no best solution to the destination problem. 456 Both solutions have their benefits and drawbacks. The first solution 457 has problems with asymmetric routing and undefined IP destinations 458 (the data senders). The second solution can create a lot more 459 signalling messages and a lot of unnecessary resource reservations. 460 The second solution also requires that the access network supports 461 multicast. Furthermore, one of the original design criteria for the 462 localized signalling was to make the design to transparently co- 463 operate with standard end-to-end RSVP. Now it seems that the 464 localized signalling needs a separate mechanism although the changes 465 required in standard RSVP routers and mobile nodes RSVP daemons are 466 small. 468 Regardless of the exact solution, an important functionality is that 469 the implementation should be transparent to the mobile node. The 470 mobile node would always operate in the same way when it wants to 471 setup QoS for downstream flows. The access router can help in 472 supporting the localized RSVP scheme. 474 Thus, when the mobile node wants to reserve resources for the 475 downstream, it will should as IP destination address either an LRSVP 476 proxy address provided as part of host autoconfiguration or the 477 default router address. The LRSVP proxy address can be a unicast or 478 multicast address, and it is up to the access network to take care of 479 removing unneeded reservations. If the mobile node does not have the 480 LRSVP proxy address configured, it will use the default router 481 address, which all IP hosts know. The access router can then perform 482 routing lookup and address translation and forward the Path Request 483 message to the correct proxy. Alternatively, it can just forward the 484 message as any IP packet. Thus, the mobile node will always have an 485 address to use as the recipient of the Path Request and the access 486 network nodes will take care of proxy discovery. 488 Similarly, in an unlikely but still possible case that a mobile would 489 want to set QoS parameters for several upstream paths, it can use the 490 configured LRSVP proxy address or the default router address in the 491 Path message. The access router can then forward the Path to the 492 correct number of LRSVP proxies, and these can then respond with the 493 Resv message. However, how the unneeded reservations are rewoked is 494 unknown. Thus, it seems, that an access network should consider 495 allowing multiple local upstream reservations. 497 Furthermore, if the host is mobile and is using Mobile IP to acquire 498 the address, it must use the Care-of-Address as the address in the 499 Session Object address field. If the CoA changes after a handover, 500 the mobile node must create a new Path message, and hence Path state, 501 to set up new upstream reservations. A new Path state is needed, if 502 the filters in the old Path state used the mobile node's CoA as 503 partial information. 505 For local downstream reservations, the mobile node can send a new 506 Path Request with the new CoA in the Session Object, and 507 simultaneously send a Path Request Tear for the old reservation. The 508 LRSVP proxy will thus create a new downstream reservation and must 509 remove the old reservation state. For end-to-end reservations, an 510 IPv6 correspondent node should use the MIPv6 Binding Update message 511 as an indication to re-establish the Path state using a new 512 destination address in the Session Object. 514 5. Signalling diagrams 516 518 6. Security Consideration 520 The localized signalling does not raise new securiy issues. The 521 security considerations with standard RSVP apply. 523 7. Summary and Future Work 525 In summary, the Localized RSVP requires the following changes in the 526 standard RSVP protocol: 528 a) A new message type and number, named Path Request, number 8. 530 b) A new message type and number, named Path Request Tear, number 9. 532 c) One bit from the Session Object for the use as the Local 533 Indication (LI), bit 0x8 535 d) An RSVP router must keep the LI bit set in all messages belonging 536 to that session, if it encounters packets with the bit set. 538 e) An RSVP router that is not also a proxy, must forward an RSVP 539 packet with a message type "Path Request" without storing state. 541 f) An AN RSVP router should be able to use the Path Request as an 542 indication of the need for a local repair. This can enable faster 543 reservation set up following a handover. This affect point e), 544 because the router that receives a Path Request must first check if 545 it has the Path state stored on another network interface. If one is 546 present, the Path Request message must not be forwarded to the next 547 hop and instead the router must send a Path message towards the 548 mobile node. 550 g) Refresh of the soft state for downstream reservations should be 551 tied to actual data flow. Alternatively, the soft state can be kept 552 up by periodic Path Request messages sent by the mobile node. 554 To summarize, these changes are small and would make RSVP more 555 appealing as a signalling protocol for IP access networks. 557 We still have to study the interactions between local and end-to-end 558 reservations, for example, whether an existing local reservation 559 could be upgraded into a full end-to-end reservation. Similary, we 560 need to study whether an initial end-to-end reservation attempt could 561 be changed flexibly into a local reservation in case the end-to-end 562 reervation was not succesfull, for example, within the core network 563 connecting the two access networks. 565 Furthermore, we need to study, whether there could be need for nested 566 proxies, so more than one proxy per path. In addition, a possibility 567 to manage the communication between the end host and the LRSVP 568 proxies would be to use UDP and a wellknown port number. Thus, 569 "local" messages would be sent encapsulated in UDP packets. 571 8. References 573 [1] R. Braden, D. Clark, S. Shenker, "Integrated Services in the 574 Internet Architecture: an Overview". Internet Engineering Task Force, 575 Request for Comments 1633, June 1994. 577 [2] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. "Resource 578 ReSerVation Protocol (RSVP), Version 1 Functional Specification. 579 Internet Engineering Task Force, Request for Comments 2205, 580 September, 1997. 582 [3] J. Wroclawski, "The Use of RSVP with IETF Integrated Services. 583 Internet Engineering Task Force, Request for Comments 2210, 584 September, 1997. 586 [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An 587 Architecture for Differentiated Services", Internet Engineering Task 588 Force, Request for Comments 2475, December, 1998. 590 [5] G. Huston, "Next Steps for the IP QoS Architecture". Internet 591 Engineering Task Force, Request for Comments 2990, November 2000. 593 [6] K. Nichols, V. Jacobson, L. Zhang, "A Two-bit Differentiated 594 Services Architecture for the Internet". Internet Engineering Task 595 Force, Request for Comments 2638, July 1999. 597 [7] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer,"SBM 598 (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission 599 Control over IEEE 802-style networks". Internet Engineering Task 600 Force, Request for Comments 2814, May 2000. 602 [8] Phil Chimento and Ben Teitelbaum, "QBone Bandwidth Broker 603 Architecture". The Internet2 initiative, June 2000. 604 (http://qbone.internet2.edu/bb/bboutline2.html). 606 [9] S. Gai, D. G. Dutt, N. Elfassy, Y. Bernet, "RSVP Proxy". Internet 607 Draft (work in progress), July 2001 (draft-ietf-rsvp-proxy-02.txt). 609 [10] Jukka Manner and Kimmo Raatikainen, "Extended Quality-of-Service 610 for Mobile Networks". Proceedings of the 9th International Workshop 611 on Quality of Service (IWQoS), June 2001, pp. 275-280. Published in 612 the series Springer Lecture Notes in Computer Science (LNCS) 2092. 614 [11] IST-BRAIN Project, "Deliverable D2.2: BRAIN architecture 615 specifications and models, BRAIN functionality and protocol 616 specification". March 2001, (available at: http://www.ist- 617 brain.org). 619 [12] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 620 Protocol (RTSP)". Internet Engineering Task Force, Request for 621 Comments 2326, April 1998. 623 [13] Y. Bernet,"Format of the RSVP DCLASS Object". Internet 624 Engineering Task Force, Request for Comments 2996, November 2000. 626 [14] Hamid Sued, "Capability Negotiation: The RSVP CAP Object". 627 Internet Draft (work in progress), February 2001 (draft-ietf-issll- 628 rsvp-cap-02.txt). 630 9. Author's Addresses 632 Questions about this document may be directed to: 634 Jukka Manner 635 Department of Computer Science 636 University of Helsinki 637 P.O. Box 26 (Teollisuuskatu 23) 638 FIN-00014 HELSINKI 639 Finland 641 Voice: +358-9-191-44210 642 Fax: +358-9-191-44441 643 E-Mail: jmanner@cs.helsinki.fi 645 Markku Kojo 646 Department of Computer Science 647 University of Helsinki 648 P.O. Box 26 (Teollisuuskatu 23) 649 FIN-00014 HELSINKI 650 Finland 652 Voice: +358-9-191-44179 653 Fax: +358-9-191-44441 654 E-Mail: kojo@cs.helsinki.fi 656 Kimmo Raatikainen 657 Department of Computer Science 658 University of Helsinki 659 P.O. Box 26 (Teollisuuskatu 23) 660 FIN-00014 HELSINKI 661 Finland 663 Voice: +358-50-483-6275 664 Fax: +358-9-191-44441 665 E-Mail: kraatika@cs.helsinki.fi 667 Tapio Suihko 668 VTT Information Technology 669 P.O. Box 1203 670 FIN-02044 VTT 671 Finland 673 Voice: +358-9-456-6078 674 Fax: +358-9-456-7028 675 E-Mail: tapio.suihko@vtt.fi 676 Mika Liljeberg 677 Nokia Research Center 678 P.O. Box 407 679 FIN-00045 Nokia Group 680 Finland 682 Voice: +358-50-4836791 683 Fax: +358- 684 E-Mail: Mika.Liljeberg@nokia.com 686 Acknowledgement 688 This work has been partially performed in the framework of the IST project 689 IST-2000-28584 MIND, which is partly funded by the European Union. 690 The authors would like to acknowledge the help of their colleagues 691 in preparing this document, in particular Eleanor Hepworth and 692 Alberto Lopez. 694 Full Copyright Statement 696 Copyright (C) The Internet Society (2000). All Rights Reserved. 698 This document and translations of it may be copied and furnished to 699 others, and derivative works that comment on or otherwise explain it 700 or assist in its implementation may be prepared, copied, published 701 and distributed, in whole or in part, without restriction of any 702 kind, provided that the above copyright notice and this paragraph are 703 included on all such copies and derivative works. However, this 704 document itself may not be modified in any way, such as by removing 705 the copyright notice or references to the Internet Society or other 706 Internet organizations, except as needed for the purpose of 707 developing Internet standards in which case the procedures for 708 copyrights defined in the Internet Standards process must be 709 followed, or as required to translate it into languages other than 710 English. 712 The limited permissions granted above are perpetual and will not be 713 revoked by the Internet Society or its successors or assigns. 715 This document and the information contained herein is provided on an 716 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 717 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 718 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 719 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 720 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.