idnits 2.17.1 draft-fhns-rsvp-support-in-mipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 17) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** There are 359 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 287: '... routers MUST be changed but changes are not needed at CNs[2] and MNs....' RFC 2119 keyword, line 433: '... MNs MUST be changed and RSVP im...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 17 has weird spacing: '... ments of t...' == Line 22 has weird spacing: '... and may be...' == Line 23 has weird spacing: '...me. It is i...' == Line 26 has weird spacing: '... please check...' == Line 28 has weird spacing: '...ctories on f...' == (354 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '12' on line 967 looks like a reference -- Missing reference section? '13' on line 970 looks like a reference -- Missing reference section? '7' on line 947 looks like a reference -- Missing reference section? '6' on line 943 looks like a reference -- Missing reference section? '9' on line 955 looks like a reference -- Missing reference section? '18' on line 991 looks like a reference -- Missing reference section? '10' on line 959 looks like a reference -- Missing reference section? '5' on line 940 looks like a reference -- Missing reference section? '1' on line 924 looks like a reference -- Missing reference section? '2' on line 928 looks like a reference -- Missing reference section? '8' on line 951 looks like a reference -- Missing reference section? '3' on line 932 looks like a reference -- Missing reference section? '17' on line 988 looks like a reference -- Missing reference section? '16' on line 984 looks like a reference -- Missing reference section? '15' on line 980 looks like a reference -- Missing reference section? '4' on line 936 looks like a reference -- Missing reference section? '14' on line 974 looks like a reference -- Missing reference section? '11' on line 961 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Mobile IP Working Group 2 INTERNET-DRAFT George Fankhauser 3 draft-fhns-rsvp-support-in-mipv6-00.txt ETH Zurich 4 November 98 Stathes Hadjiefthymiades 5 Expires: May 99 University of Athens 6 Neda Nikaein 7 Eurecom 8 Lorraine Stacey 9 Lucent Technologies 11 RSVP Support for Mobile IP Version 6 12 in Wireless Environments 14 STATUS OF THIS MEMO 16 This document is an Internet-Draft. Internet-Drafts are working docu- 17 ments of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute work- 19 ing documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress''. 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Distribution of this document is unlimited. 34 Abstract 36 This draft describes a specific problem encountered when using RSVP 37 (Resource Reservation Protocol) over optimised routes in MIPv6 38 (Mobile IP Version 6). The address translation in the MIP's binding 39 cache creates a mismatch between the flow-id of the packets sent from 40 correspondent node to mobile node and the flow-id signalled by RSVP. 42 Internet Draft RSVP Support for MIPv6 November 98 44 We discuss several solutions to this problem: (1) By modifying RSVP 45 at mobile and correspondent nodes to become aware of MIPv6 address- 46 ing, we provide a simple repair that allows RSVP flows to be esta- 47 blished between the fixed network and mobiles; (2a) By adding 48 optional objects to RSVP messages, a performance enhancement is pro- 49 posed to make handovers smooth and seamless; (2b) A different tech- 50 nique with the same goal is called flow extension and it provides 51 flows with fixed flow-ids from the correspondent node into the wire- 52 less access network at the expense of forwarding traffic inside the 53 access network, whenever the mobile node moves. 55 We conclude that the minimal solution (1) is a requirement in order 56 to make MIPv6 and RSVP interoperable; our favored approach requires 57 only minor changes to the correspondent and mobile node's RSVP and 58 MIP specification. However, for well performing and uninterrupted 59 operation we strongly recommend one of the solutions (2a or 2b) that 60 support fast re-establishment or preservation of resource reserva- 61 tions when mobile nodes move. 63 1 Introduction 65 Wireless access to the Internet is becoming more and more popular due 66 to the rapid spread of wireless LANs and other wireless access tech- 67 nologies with various speeds and ranges (IRDA-LANs, IEEE 802.11, 68 Wireless ATM, CDPD, etc.). Devices used include mobile phones, PDAs, 69 and notebook computers. Mobile IP could become a common platform for 70 mobile access (regardless of the underlying access technology), pro- 71 viding solutions to the many security, routing, and addressing prob- 72 lems. For a good introduction to Mobile IP see [12]. 74 More traditional services like telephony, radio and TV broadcasting, 75 and other new Internet applications that require more than best- 76 effort service are increasingly being carried on the Internet. Mobile 77 users also want to enjoy multimedia and other realtime services. 78 Therefore it is important to design Mobile IP to interoperate seam- 79 lessly with protocols that provide real-time services in the Inter- 80 net. 82 This draft focuses on issues of MIPv6 and RSVP interoperability, more 83 precisely on the operation phase where optimised routing between 84 fixed and mobile hosts is used. We apply our considerations to MIPv6 85 because it uses route optimisation by default. However MIPv4 may also 86 use this technique [13]. 88 Although RSVP is standardised [7] it currently looks like it is going 89 to be employed for access networks but not necessarily for end-to-end 90 connections through the backbone networks. Solutions for bridging 91 RSVP across the backbone are under development [6] and are being 93 Internet Draft RSVP Support for MIPv6 November 98 95 discussed in the IETF intserv and diffserv working groups. We assume 96 here the usage of RSVP for wireless and fixed access networks and its 97 transparent operation over the backbone. 99 1.1 Terms 101 This draft uses the terms as defined in section "Mobile IPv6 Terms" 102 in the Internet Draft "Mobility Support in IPv6" [9]. 104 1.2 Problem statement 106 1.2.1 The Unicast Case 108 An integral part of MIPv6 is the use of optimised paths between a 109 mobile node and correspondent nodes. Routing of packets via the Home 110 Agent is typically only a transient phase in MIPv6. If the mobile 111 node has one or more packet streams (flows) controlled via RSVP, the 112 PATH and RESV messages will also be transmitted via the direct route 113 between the mobile node (MN) and correspondent node (CN). When a MN 114 moves, the optimised route between the MN and CN will change. Furth- 115 ermore the MN's care-of address will also change. Both the route and 116 care-of address change impact the operation of RSVP. 118 In RSVP, PATH messages are sent end-to-end and RESV messages are sent 119 hop-by-hop. When the CN is a sender it will transmit a PATH message 120 where the address details are based on the MN's home address. However 121 the outer header details will be modified by the MIPv6 binding cache 122 to contain the MN's care-of address as the destination address. Even 123 more importantly, to ensure PATH and RESV messages follow the same 124 route, the PATH messages contain a RSVP_HOP object which collects the 125 address of each outgoing interface the message traverses. The 126 correspondent node and intermediate routers will each determine the 127 outgoing interface based on the MN's home address. However the packet 128 will actually be routed based on the MN's care-of address. Thus when 129 the PATH message reaches the MN the routing information stored in the 130 RSVP_HOP object will not correctly reflect the route followed by the 131 PATH messages. Hence RESV messages can not be routed back to the CN 132 and therefore RSVP state will not be created between the MN and the 133 CN. Additionally, RESV messages sent back from the MN reference the 134 home address of the MN as the flow's destination in the SESSION 135 object. Again, this is not the real flow-id of the flow's data pack- 136 ets, it should rather reference the MN's care-of address. 138 For the unicast case, the problem of a flow-mismatch occurs when the 139 CN is the sender. When the MN is the sender, the PATH message will 140 contain correct routing information when it reaches the CN because 141 the MN directly addressed it to the CN. Hence the RESV message can be 142 forwarded correctly along the reverse path to the MN. Also, the RESV 144 Internet Draft RSVP Support for MIPv6 November 98 146 message's SESSION object sent by the CN contains correctly its own 147 (fixed!) address as the flow's destination. However, the PATH mes- 148 sages also contain the sender's address (MN) in the SENDER_TEMPLATE 149 object. This address would be normally the home address of the MN and 150 has to be changed to its care-of address. 152 Solutions to these 'change of route' and 'flow-mismatch' problems are 153 described in this Internet Draft. Another important issue is that 154 when the MN moves to a new subnetwork its care-of address changes. In 155 standard RSVP state information is based on the MN's home address. 156 However the data packets this state needs to apply to will be 157 addressed with the MN's care-of address. Hence there is an issue of 158 matching RSVP flow state with the data packets belonging to that flow 159 at intermediate routers. 161 Yet another difficulty with MIPv6 is its applicability to wireless 162 environments where the MN moves to new subnetworks in real time. In 163 wireless environments the speed of re-routing is of major concern. 164 The objectives are to minimise the loss of packets, and restore the 165 end-to-end RSVP state as quickly as possible. 167 1.2.2 The Multicast Case 169 For the multicast case, there are two options for MNs to receive 170 data. The first option is via its Home Agent. In this case the HA is 171 also a multicast router. The HA tunnels the multicast packets to the 172 MN. The second option is for the MN to join its groups directly in 173 its foreign network. This option allows the MN to receive the multi- 174 cast packets directly without passing by its HA. Since this draft 175 considers the problem of using RSVP over optimised routes in MIPv6, 176 only the second option is studied here. 178 Let's consider the case where the CN sends multicast data and at 179 least one of the receiver's is a MN. An RSVP session is identified by 180 the triple !!. The destination address of a multicast group remains 182 fixed regardless of the mobility of its receivers. In other words, 183 the MN's exact address and its mobility have no impact on the multi- 184 cast group address. Therefore, an MN making a handover to another 185 network can be considered as a new node joining the group. That is, 186 each time the MN moves to a new subnetwork it must leave and re-join 187 the multicast group. The process of leaving and re-joining the multi- 188 cast groups can be done as part of the handover procedure. 190 Now, we consider the case where the MN sends multicast data. IP uni- 191 cast routing protocols depend only on the IP destination address. 192 Some multicast routing protocols such as DVMRP [18] and MOSPF [10] 193 build a multicast tree per source. These routing protocols construct 195 Internet Draft RSVP Support for MIPv6 November 98 197 the multicast tree depending on the source address as well as the 198 destination address. Other algorithms like CBT [5] build a single 199 shared tree per group. These protocols use only the IP destination 200 address for packet forwarding. 202 Using the home address as the IP source address of the datagram leads 203 the routers executing DVMRP or MOSPF to expect the datagram from the 204 link used to reach the MN's home address. Therefore, sending multi- 205 cast traffic in a foreign network using the MN's home address as the 206 IP source address means that these routers receive the traffic via 207 unexpected links. DVMRP drops such datagrams because it expects the 208 packet to arrive to the router on the shortest path from the router 209 to the MN's home address. MOSPF forwards the traffic based on an 210 incorrect information. In both cases, some destinations may not be 211 reached. In order to overcome such routing problems, we must use the 212 MN's care-of-address in the IP source address. 214 RSVP is not aware of mobility. When building a PATH message, the IP 215 source address of the filter specification is filled by the the MN's 216 home address. However the IP source address of the outer IP header 217 must be modified to the MN's care-of-address because of the routing 218 problems described above. Therefore, there is a mismatch between the 219 information in the RSVP message and in the outer IP header. The PATH 220 message can be routed correctly thanks to the care-of-address in the 221 outer IP header. The problem is RSVP_HOP object's last-hop-address 222 field which has to be changed at the MN's RSVP daemon because it has 223 been calculated based on the MN's home address and the group destina- 224 tion address. 226 1.2.3 Summary 228 Summarising, the following issues have to be addressed: 230 o Most importantly, we need a working solution, i.e., MIPv6 and 231 RSVP need to be integrated. MIP provides transport layer tran- 232 sparency but does not work with protocols like RSVP. Since this 233 requires changes to either MIP or RSVP, we would like to keep 234 them as minimal as possible. We also favor a modular solution 235 that allows for incremental deployment (e.g., hosts first, 236 routers later). 238 o Multicast aspects of all possible solutions and extensions 239 (even if optional) have to be considered. 241 o Performance aspects for wireless operation and their respec- 242 tive applications (e.g. mobile IP phones) are an important fac- 243 tor when evaluating the pros and cons of a mobile integrated 244 services solution. 246 Internet Draft RSVP Support for MIPv6 November 98 248 2 Possible Solutions 250 This section describes solutions and enhancements that resolve the 251 flow-id mismatch between RSVP messages and the flow's data packets. 252 The first solution provides a basic fix and some optional enhance- 253 ments to restore reservations in a quick and efficient manner. The 254 second proposal builds partially on top of the first and provides 255 advantages to fast moving terminals inside wireless access networks 256 by extending flows to new routers while keeping the RSVP session 257 through the backbone unchanged. This approach makes use of RSVP tun- 258 nels. 260 2.1 Mobility Enhanced RSVP 262 2.1.1 Changing End-Nodes 264 A possible solution to the problem of correctly routing RSVP messages 265 between CNs and MNs is to modify the RSVP daemon at the CN and MN to 266 operate on the MN's care-of address instead of its home address. The 267 RSVP daemons could learn the care-of address by consulting its MIPv6 268 binding cache. This means that RSVP state would be created based on 269 the care-of address, and thus the path the traffic actually follows. 271 There are two ways that the care-of address can be obtained. One 272 option is to modify MIP to provide an interface [1] that allows the 273 RSVP module to look up the care-of address of a mobile node. An 274 alternative is to modify MIP at the CN and MN only. In this case the 275 MIP module needs to become RSVP aware and swap the home address in 276 the PATH and RESV messages SESSION objects with the mobile nodes 277 care-of address (among other fields, see Section A for details). 279 We recommend here the implementation of a clean interface in MIPv6 280 which must be used by the RSVP daemon. As we will see in the next 281 subsection, this interface may also be extended for triggering PATH 282 messages when mobiles change their location. 284 2.1.2 Changing Intermediate Routers (Alternative Approach) 286 An alternative, but similar approach means RSVP implementations at 287 routers MUST be changed but changes are not needed at CNs[2] and MNs. 288 _________________________ 289 [1] It is current practice of MIPv4 implementors to 290 use the routing table to store the MN's location at 291 home agents [12]. If MIPv6 would use the same technique 292 consistently , a simple routing socket lookup 293 (PF_ROUTE) would reveal the care-of address when fed 294 with the home address of the MN. 296 Internet Draft RSVP Support for MIPv6 November 98 298 In this solution outer header address information is passed up to the 299 RSVP module at each router (outer header means the IP header tran- 300 sporting the PATH or RESV message, i.e., the whole packet and not 301 only the payload is forwarded to the RSVP daemon). This allows the 302 RSVP daemon in each intermediate router to learn the mapping between 303 the mobile node's home address and current care-of address. The RSVP 304 daemon should then base its calculation of the RSVP-HOP and filters 305 on the care-of address. Given the router RSVP daemon maintains a map- 306 ping between the home and care-of address when the care-of address 307 changes the router will still recognise the RSVP messages and traffic 308 as belonging to the same reservation. 310 2.1.3 Evaluation of the two Alternatives 312 Our preferred solution, however, is the first approach. This is 313 because it requires less changes. It requires to make a small change 314 at CNs and MNs only, to enable the RSVP daemon to learn the MN's 315 care-of address. This solution can be optimised by adding new RSVP 316 objects. However these are not essential to the operation of RSVP 317 with MIPv6. In contrast the second, alternative solution requires all 318 routers to change their RSVP implementations. 320 2.1.4 Performance Enhancements 322 One minor disadvantage of this approach (using either implementation 323 alternative) is that when the mobile node moves and thus obtains a 324 new care-of address, all of the intermediate routers will assume this 325 is a new RSVP reservation flow. Hence there may be situations where 326 the new reservation is denied because the old reservation is still 327 active and blocks resources. This problem could be overcome by intro- 328 ducing a new RSVP object to the RSVP messages the MN sends (that is, 329 if the MN is a receiver, it will place the RSVP object in the RESV 330 message). This would allow intermediate routers to recognise the 331 reservation is the same even though the care-of address has changed. 332 A key point to note is that if some or even all intermediate routers 333 do not recognise this RSVP object this solution will still work. At 334 those routers that don't understand the RSVP object the RSVP state 335 with the new care-of address will be treated as a new independent 336 flow and the previously reserved flow expires later. 338 Note if the home address was kept as the destination address, and the 339 care-of address was stored in the new RSVP object this solution would 340 require all intermediate routers to understand the new RSVP object 341 _________________________ 342 [2] If a CN as a flow's sender exercises traffic 343 control, it has, of course, to apply the same changes 344 as intermediate routers. 346 Internet Draft RSVP Support for MIPv6 November 98 348 instead of just changing the CNs and MNs and treat the new RSVP 349 object as an option. 351 Another concern is the time required to modify the RSVP state so that 352 traffic flows along the optimal path to the MN's new care-of address. 353 In standard RSVP operation PATH and RESV messages are transmitted 354 periodically. Hence there can be a significant delay between the MN's 355 care of address changing and the next PATH message being sent. This 356 extra delay can be avoided by having the arrival of a binding update 357 message at the CN, trigger the transmission of a PATH message. Again, 358 an interface between MIP and RSVP daemon should be used for this 359 triggering. 361 2.1.5 Use of IPv6 Flow Label 363 One could argue that the mechanism described above is not required, 364 since IPv6 flow labels (in conjunction with the source IP address) 365 uniquely identify the traffic flow. If non-zero flow labels are 366 employed it is still possible to identify the traffic flow. However, 367 this won't solve the routing problem of PATH messages. Moreover IPv6 368 flow labels are optional and hence they can often be zero. If this is 369 the case the flow-id mismatch problem still exists. Furthermore, if 370 the flow-id is created by hashing on the destination address, it may 371 also change when the care-of address changes. 373 2.1.6 Required or Optional Changes 375 To summarise the key components of this solution are: 377 o At correspondent nodes 379 -RSVP daemon can obtain the mobile node care-of address from 380 the binding cache 382 -RSVP daemon places the mobile node care-of address as the PATH 383 message's SESSION object's destination address 385 o At the MIP information aware intermediate router 387 -On receipt of a PATH message store the mobile node care-of 388 address (standard RSVP operation) and home address (optional 389 for mobility support) in the RSVP daemons flow table. 391 -Create a classifier entry based on the mobile node's care-of 392 address (standard RSVP operation). 394 -When a PATH message arrives with the same home address but a 395 different care-of address update the flow state and filter 397 Internet Draft RSVP Support for MIPv6 November 98 399 information with the new care-of address (optional for mobil- 400 ity support). 402 o At standard intermediate routers 404 -On receipt of a PATH message store the mobile node's care-of 405 address in the flow state information. 407 -Create a classifier entry based on the mobile node's care-of 408 address 410 -On receipt of a PATH message with a different care-of address 411 for the mobile node create new flow state information and 412 filters. 414 -Remove the old flow state information on receipt of a PATHTear 415 or when it times out. 417 o At mobile nodes 419 -Since the MN is reachable under its care-of address, PATH mes- 420 sages that arrive with the care-of address as the SESSION 421 object's destination address should not disturb regular RSVP 422 operation 424 -When an MN sends RESV messages the SESSION object must also 425 contain the care-of address in order to correctly identify the 426 flow on the optimised route. 428 -RSVP daemon places the mobile node's home address in a new 429 RESV MIP RSVP object (optional) for efficient recycling of 430 resources. 432 The solution described above means RSVP implementations at CNs and 433 MNs MUST be changed and RSVP implementations at routers SHOULD be 434 changed. 436 2.1.7 Multicast Support 438 The same approach can be used to resolve the problem of multicast 439 reservation when an MN is a sender. In this case, we can also use the 440 care-of-address in the IP source address field of the 441 SENDER_TEMPLATE. Therefore, the RSVP_HOP object of the PATH message 442 is calculated correctly. However, this can cause the intermediate 443 routers to consider the MN as a different source. In order to over- 444 come this problem, we use the same approach as described above. We 445 add a new RSVP object to the PATH message which contains the MN's 446 home address. To summarise, we propose the following solution: 448 Internet Draft RSVP Support for MIPv6 November 98 450 o At mobile nodes 452 -When an MN sends PATH messages the SENDER_TEMPLATE object must 453 contain the care-of address. 455 -RSVP daemon places the mobile node's home address in a new 456 PATH MIP RSVP object. 458 o At the MIP information aware intermediate router 460 -On receipt of a PATH message store the mobile node care-of 461 address (standard RSVP operation) and home address (optional 462 for mobility support) in the RSVP daemons flow table. 464 -Create a filter spec entry based on the mobile node's care-of 465 address (standard RSVP operation). 467 -When a PATH message arrives with the same home address but a 468 different care-of address update the flow state and filter 469 information with the new care-of address (optional for mobil- 470 ity support). 472 o At standard intermediate routers 474 -On receipt of a PATH message store the mobile node's care-of 475 address in the flow state information. 477 -Create a filter spec entry based on the mobile node's care-of 478 address 480 -On receipt of a PATH message with a different care-of address 481 for the mobile node create new flow state information and 482 filters. 484 -Remove the old filter spec information when it times out. 486 o At correspondent nodes 488 -The CN is aware of the MN's care-of address via the binding 489 cache. RSVP operates regularly by sending the RESV message. 491 2.2 Flow Extension 493 This section describes an alternative approach for the efficient 494 operation of RSVP on top of MIPv6. This approach proposes an alterna- 495 tive to the use of new RSVP objects for the fast update of end-to-end 496 RSVP connections. It mainly refers to the time periods following the 497 occurrence of active terminal relocations in the network (i.e., 499 Internet Draft RSVP Support for MIPv6 November 98 501 handovers). It is also assumed that, prior to terminal relocations, 502 RSVP flows have been established between the CN and the MN using the 503 basic approach discussed in Section 2.1 (the MN is assumed to be in a 504 foreign subnetwork). 506 When an MN attaches to a new subnetwork and acquires a new IP care-of 507 address, the MIP-capable router in this subnetwork intercepts and 508 suppresses the MIPv6 binding update message sent to the CN (we use 509 the term MIP-router here for a router serving wireless access net- 510 works and performing the flow extension tasks). This causes the CN 511 not to update its Binding Cache. This strategy is not applied to the 512 Binding Update sent to the former MIP-router. This information can be 513 used in rerouting best effort traffic destined to the old location of 514 the MN, to its current location (through the use of an IP tunnel 515 between former and current MIP router). The MN is then capable of 516 receiving datagrams destined to its current IP address as well as the 517 previous IP address. For best effort traffic destined to the MN, the 518 previous IP address should be used. This packet forwarding technique 519 is an enhancement to support loss-less handovers [8]. 521 Prior to or during the relocation of the terminal, the old MIP-router 522 also extends the existing RSVP flows to the new MIP-router. This task 523 is performed by a mobility management (MM) entity operating within 524 the router. The extension of downlink (CN ---> MN) flows is per- 525 formed by the old MIP-router while the uplink flows (MN ---> CN) 526 are handled by the new MIP router. For this last step, the new MIP- 527 router needs to receive the characteristics of existing flows from 528 the old router. For this task, specialised signaling between MIP- 529 routers (MM entities in particular) is introduced (it is assumed that 530 such signaling is treated as best effort traffic in the access net- 531 work). The elongation of flows by the old MIP router to the current 532 avoids the invalidation of existing flows caused by changes in the IP 533 addresses of connection endpoints. [3] 535 The proposed elongation of the CN-MN path causes the route of the 536 communication to be sub-optimal and, consequently, imposes addi- 537 tional, but relatively small, time delays. It was shown that consecu- 538 tive elongations (leading to increased sub-optimality) will be needed 539 rarely, as the number of inter-subnet MN relocations (i.e., handovers 540 to subnetworks controlled by different MIP-routers; and hence changes 541 in addresses) is very small during the lifetime of IP connections in 542 _________________________ 543 [3] If Guaranteed Service is employed as a service 544 model the end-to-end delay calculation may have to be 545 performed across the entire path between the CN and MN 546 to take into account extra nodes and links that have 547 been added to the communication path. 549 Internet Draft RSVP Support for MIPv6 November 98 551 a CPN environment [17]. Most relocations will result in attachments 552 of the MN to base stations (radio transceivers) in the same subnet- 553 work (also termed intra-subnet handovers). Such mobility events can 554 be handled at the local addressing-level without affecting the com- 555 munication path beyond the router, i.e. the care-of address of the MN 556 remains the same. This elongation of data paths has been adopted in 557 Wireless ATM technology for the handling of connections (VCs) during 558 the occurrence of handovers. Relevant information can be found in 559 [2], [3], [8]. 561 2.2.1 Required or Optional Changes 563 Due to the flow extension approach modifications are confined to the 564 end-nodes and mobile/wireless access network routers. Intermediate 565 routers along the transmission path do not need to be changed. 567 o At correspondent nodes 569 -The same basic modifications as described in Section 2.1 are 570 needed. 572 o At standard intermediate routers 574 -No changes needed here (of course, one could think of a combi- 575 nation of the two performance enhancment approaches, i.e., 576 flow extension is used for high-frequent movements and path 577 triggers and RSVP objects are used, e.g. when roaming between 578 provider networks). 580 o At wireless access network routers (MIP-routers) 582 -Communicating the IP address of the new MIP-router to the old 583 MIP-router. 585 -Transmitting the existing RSVP flow characteristics (flowspec) 586 to the new MIP-router from the old MIP-router. To elongate the 587 RSVP state from the old MIP-router to the new MIP-router 588 (i.e., extend the flow) an RSVP tunnel could be used. 590 -Control and suppression of binding update transmission from 591 MNs. If the design alternative mentioned below is used, this 592 point becomes obsolete. 594 o At mobile nodes 596 -The same basic modifications as described in Section 2.1 are 597 needed. 599 Internet Draft RSVP Support for MIPv6 November 98 601 -However, since the flow will retain its flow-id over a long 602 time period, binding updates do not need to trigger RESV mes- 603 sages, nor do we need to insert special RSVP objects. 605 -Design alternative: It is also possible to suppress the bind- 606 ing update messages at the MN without considerable modifica- 607 tions to its MIPv6 module. Such approach improves bandwidth 608 efficiency at the radio interface and reduces the complexity 609 of MIP routers. One additional advantage of this alternative 610 is that it does not cause disruptions in IP communication if 611 the Binding Update message is included (as Destination Option 612 header) in IP packets having, besides headers, standard pay- 613 load data such as TCP/UDP. Disabling the transmission of Bind- 614 ing Update messages at the MN is also adopted in the MRSVP 615 approach discussed in Section 3.2. 617 2.2.2 Using RSVP Tunnels for Flow Extension 619 Lastly, we are considering how the extension of RSVP flows could be 620 accomplished in light of existing protocol specifications, (i.e., 621 RSVP, MIPv6, IP encapsulation). RSVP operation over IP tunnels [16] 622 provides a good basis for the implementation of the proposed scheme 623 (see also Section 3.3). The old MIP-router uses regular IP tunnels 624 for forwarding best effort traffic and RSVP tunnels for handling the 625 extension of RSVP flows. The old MIP-router serves as the RSVP tunnel 626 entry point in the downlink direction while the new MIP-router plays 627 the role of the tunnel exit point (roles are inverted in uplink com- 628 munication). The tunnel session is a separate RSVP session between 629 the involved routers. Its characteristics are dictated by the charac- 630 teristics of the flows that need to be extended. The original session 631 (CN ---> MN / MIP-router) views the tunnel as a single communica- 632 tion link. The PATH and RESV messages of the end-to-end session are 633 encapsulated at one tunnel end-point and decapsulated at the other. 634 The end-to-end session and the tunnel session are associated at the 635 entry/exit points of the tunnel. The tunnel may encompass one or more 636 RSVP-capable nodes. 638 The overall scheme is based on the assumption that the new MIP-router 639 is aware of the existence of RSVP flows and thus, suppresses only the 640 binding update messages for active RSVP flows When the entire set of 641 RSVP flows is terminated, the new MIP-router allows the propagation 642 of the binding update signal to the fixed network. This restores the 643 optimal communication between the MN and the CN regarding best effort 644 traffic. (We might also propose to do this whenever flow extension 645 has become too long or too slow). 647 2.2.3 Multicast Support 649 Internet Draft RSVP Support for MIPv6 November 98 651 As we said before, if the MN, which is the receiver of the multicast 652 data, changes its subnetwork, it must rejoin its groups in the new 653 subnet. Now, if the new subnetwork already has members of the MN's 654 groups with the same reservations, the MN can receive the data 655 without any delay. If this is not the case, the MN can receive data 656 from its old MIP-router by using an RSVP tunnel. The new MIP-router 657 knows about the MN's group list and also about the presence of groups 658 and their reservation style in its local network. Therefore, instead 659 of trying to graft a path to the multicast tree, the new MIP-router 660 asks the old MIP-router to forward the traffic destinated to this 661 group via an RSVP tunnel. The same thing happens, if the new MIP- 662 router has a member of the group but not with the specified reserva- 663 tion style. 665 Now if the MN is the sender of the multicast traffic (uplink direc- 666 tion), we always pass by the RSVP tunnel to reach the old MIP-router. 668 3 Previous Work 670 This section summarises selected recent research on providing QoS 671 support in mobile and wireless networks and serves as a starting 672 point for further reading. 674 3.1 Mobile IP Version 6 676 The description MIPv6 [9] encompasses a streamlined version of Mobile 677 IP that makes use of new IPv6 features that help to improve mobility 678 support. Most notable, foreign agents could be replaced by stateless 679 address autoconfiguration and neighbor discovery. As stated earlier, 680 optimised routes between CN and MN are the default operation in 681 MIPv6. They can be implemented properly by using IPv6 routing 682 headers. 684 3.2 Mobile RSVP (MRSVP) 686 MRSVP has been proposed in [15], as an extension to conventional 687 RSVP, for the provision of QoS guarantees to MNs independently of 688 their movement throughout the access network. MRSVP suggests making 689 the required resource reservations in all the locations expected to 690 be visited by the MN (mobility specification). MRSVP supports two 691 service classes. The first one, called Mobility Independent, provides 692 the agreed service in every location visited by the MN. The second, 693 called Mobility Dependent, provides a high probability, but no 694 guarantee, to receive the agreed service in the locations the MN may 695 visit. 697 MRSVP supports two different reservation styles. The MN makes active 698 reservations from its present location towards all the CNs it is 700 Internet Draft RSVP Support for MIPv6 November 98 702 communicating with. It also triggers the establishment of passive 703 reservations from all the locations it may visit. Such reservations 704 are made by proxy agents (remote), operating on the behalf of the MN 705 which is not present at their subnetwork. As passive reservations are 706 not used by the MN (data is not flowing through them) they may be 707 used temporarily by other connections of the Mobility Dependent 708 class. When the MN roams, passive reservations are switched to active 709 and vice versa. 711 The MRSVP scheme provides mobility support for both unicast and mul- 712 ticast traffic. 714 3.3 Supporting RSVP/MIP Integration with RSVP-Tunnels 716 RSVP tunnels [16] provide signalling of RSVP messages in tunnels. 717 Normally, RSVP messages in tunnels are not visible to routers due to 718 encapsulation. This problem is similar to the MIP flow-mismatch prob- 719 lem, but with the difference, that in MIP the RSVP daemon is provided 720 with the wrong information and in tunnels, the encapsulated RSVP mes- 721 sages feature the wrong protocol id (next header field) which makes 722 them invisible. 724 The proposed solution for RSVP tunnels is to establish nested RSVP 725 sessions between the tunnel's entry and exit points, i.e. new PATH 726 and RESV messages (without the encapsulation headers!) are being sent 727 between entry and exit point. This solution also focuses on modifica- 728 tions at the entry/exit points and tries to avoid changes to the 729 intermediate routers along the tunnel path. 731 RSVP tunnels were already proposed to support RSVP connections in 732 MIPv4 as a replacement for the regular IP tunnel between HA and MN. 733 They could serve also as a basis for the various forwarding connec- 734 tions needed in our flow extension approach (Section 2.2). 736 RSVP tunnels could also be employed in our RSVP object approach (Sec- 737 tion 2.1) for the transient phase where the MN has moved to a new 738 care-of address and the old router is forwarding traffic to the new 739 router, but the end-to-end state hasn't been adjusted yet. Thus com- 740 monality with MIPv4 - RSVP integration in terms of the use of RSVP 741 tunneling is true for both approaches. 743 3.4 IPSOFACTO: IP Multicast over Wireless ATM 745 [1] describes how IP multicast can be natively supported in wireless 746 networks over ipsofacto. To differentiate different types of traffic 747 VCs are classified as unicast, multicast and broadcast VCs. Small 748 extensions to the IGMP protocol are proposed. In addition, a cell- 749 level error recovery scheme at the data link layer is described to 751 Internet Draft RSVP Support for MIPv6 November 98 753 enhance the packet-level throughput of the transport layer. 755 3.5 Designing a Wireless Broadband IP System with QoS Guarantees 757 [4] describes a wireless broadband IP system where a solution such as 758 those described in this Internet Draft is required. This system, 759 specified within the ACTS Magic WAND project is a native IP wireless 760 access system providing 20Mbits/s, 5GHz radio access to an IP back- 761 bone. The objective of this system is to allow full exploitation of 762 real-time IP applications in a mobile environment. This system 763 comprises a mobile node, access point (implementing all radio depen- 764 dent control functionality) and a mobility enhanced IPv6 router. 766 This work is also described in [14]. In this report, in addition to 767 the overall design of the wireless broadband IP system, some of the 768 MIP/RSVP integration problems are described in greater detail, 769 including diagrams and message sequence charts. 771 3.6 Mobility Management in an IP-based Wireless ATM Network 773 In [8], Hadjiefthymiades et al. studied mobility management issues in 774 a WATM architecture exclusively intended and optimised for IP traffic 775 support. The considered system is a variation of the Magic WAND 776 architecture. It is capable of supporting IP applications with 777 specific QoS requirements in light of terminal mobility. The proposed 778 architecture is based on specifications/standards like RSVP, MIPv6 779 and IFMP. 781 The architecture assumes two types of terminal relocations (hand- 782 overs). Handovers confined to the same MIP router are treated at L2 783 (ATM in the case of a WATM system). Handovers involving more than one 784 MIP routers (intersubnet handovers), necessitate the use of resource 785 and mobility management schemes. The paper identifies the problems 786 encountered in MIP-RSVP interaction and presents some initial 787 thoughts for their resolution. 789 3.7 Wireless Multicasting in an IP Environment 791 [11] describes a framework for multicast communication in a wireless 792 IP environment. It presents a group membership management mechanism 793 optimised for wireless networks. It also studies the effect of termi- 794 nal mobility on the multicast communications in a mobile IPv6 795 environment. 797 4 Conclusion 799 As stated in Section 2.1 the minimal solution to the problem of 800 MIP/RSVP integration requires the modification and the interfacing of 802 Internet Draft RSVP Support for MIPv6 November 98 804 the RSVP daemon and MIP's binding cache at CNs and MNs. This solution 805 requires less changes when compared to an approach that tries to fix 806 flow-ids at intermediate routers. It is important to note that inter- 807 facing MIP and RSVP implementations requires changes to both stan- 808 dards. For proper multicast operation the same changes as for unicast 809 are sufficient. 811 For advanced solutions, where performance and smooth handovers in 812 wireless environments are considered, we have proposed two solutions: 814 1. Triggers/Objects: PATH messages are triggered on binding 815 updates and home address objects in RESV messages enable 816 intermediate routers to recognise connections and to reuse 817 resources even when the care-of address (destination 818 address of flow) changes. 820 2. Flow Extension: This approach keeps the reservation 821 unchanged until it reaches the wireless access network. 823 A qualitative comparison of the two approaches shows the following 824 result: 826 Triggers/Objects Flow extension 827 ___________________________________________________________________ 828 Changes to CN yes (needed for yes (needed for 829 minimal solution) minimal solution) 831 ___________________________________________________________________ 832 Changes to yes (RSVP MIP no 833 intermediate object extension 834 routers and reuse of 835 flow's resources) 836 ___________________________________________________________________ 837 Changes to no (forwarding of yes (binding 838 MIP-router late packets is update interception, 839 also an option here) flow forwarding) 841 ___________________________________________________________________ 842 Changes to MN yes yes 843 ___________________________________________________________________ 844 Changes to HA no no 846 ___________________________________________________________________ 847 Supports yes yes 848 multicast 849 delivery 850 ___________________________________________________________________ 851 Bandwidth yes yes (we assume 852 efficient overprovisioning in) 853 the access network) 855 ___________________________________________________________________ 856 End-to-end delay always shortest path slightly 857 (but re-establishment incr. delay 858 of resources 859 requires a round-trip) 861 Internet Draft RSVP Support for MIPv6 November 98 863 ___________________________________________________________________ 864 Lossless HO yes (with forwarding yes 865 of late packets) 867 ___________________________________________________________________ 868 HO delay roundtrip faster 869 ___________________________________________________________________ 870 Impl. moderate higher 871 complexity 873 ___________________________________________________________________ 875 A quantitative evaluation of these advanced solutions depends on 876 traffic characteristics, network topologies, etc. and is subject to 877 future investigations. 879 Although a minimalist solution would enable the operation of RSVP 880 over MIP, we strongly recommend one of the solutions (2) that support 881 fast re-establishment or preservation of resource reservations when 882 mobile nodes move. Only such enhancements can guarantee well perform- 883 ing and uninterrupted operation. 885 Without quantitative evaluation we can just observe that 886 Triggers/Objects is a quick and low complex solution that might be 887 able to provide sufficiently good service, e.g. for mobile IP phones. 888 The flow extension approach is a little more complex but has the 889 advantage of faster deployment. In multi-provider environments, where 890 we cannot control the whole path end-to-end, a solution that modifies 891 only CNs, access network routers and MNs has a big advantage. 893 We should also mention, that a combination of the two enhancements is 894 possible and useful for large wireless networks, roaming services 895 etc. 897 Furthermore, the two performance enhancement approaches described in 898 this draft could also be applied to the MIPv4 route optimisation 899 approach since it is based on the same principles as used in MIPv6. 900 However, we do not provide a detailed description of this topic and 901 more study of the applicability of this draft to MIPv4 is required. 903 Acknowledgements 905 We would like to thank the following people for commenting and dis- 906 cussing early versions of this draft: Juha Ala-Laurila, Sarantis 907 Paskalis, and Jukka Seppala. Part of this work has been performed in 908 the framework of the project ACTS AC085 The Magic WAND, which is 909 partly funded by the European Community and the Swiss BBW (Bundesamt 910 fur Bildung und Wissenschaft). The authors would like to acknowledge 911 the contributions of their colleagues from Ascom Systec AG, Compagnie 912 IBM France, IBM Zurich Research Laboratory, Institut Eurecom, France, 914 Internet Draft RSVP Support for MIPv6 November 98 916 INTRACOM Hellenic Telecommunications, Lucent Technologies WCND, Nokia 917 Mobile Phones and Nokia Research Center, Robert BOSCH GmbH, Swiss 918 Federal Institute of Technology (ETH) Zurich, Tampere University of 919 Technology, University of Athens, University of Lancaster, University 920 of Ulm, and VTT Technical Research Center Finland. 922 5 Bibliography 924 [1] A. Acharya, R. Dighe, and F. Ansari. IP Switching over Fast ATM 925 Cell Transport (IPSOFACTO): IP Multicast over Wireless ATM. In 926 Proceedings of IEEE ICUPC '98 , October 1998. 928 [2] A. Acharya, J. Lin, B. Rajagopalan, and D. Raychaydhuri. Mobil- 929 ity Management in Wireless ATM Networks. IEEE Communications Maga- 930 zine , 35(11):100--109, November 1997. 932 [3] P. Agrawal, E. Hyden, P. Krzyzanowski, P. Misthra, M. Srivastava, 933 and J. Trotter. SWAN: A Mobile Multimedia Wireless Network. IEEE 934 Personal Communications , April 1996. 936 [4] Juha Ala-Laurila, Lorraine Stacey, Neda Nikaein, and Jukka Sep- 937 pala. Designing a Wireless Broadband IP System with QoS Guarantees. 938 In Proceedings of ACTS Mobile Summit '98 , June 1998. 940 [5] A. Ballardie. Core Based Trees (CBT version 2) Multicast Routing 941 - Protocol Specification. RFC 2189, September 1997. 943 [6] S. Berson and S. Vincent. Aggregation of Internet Integrated 944 Services State. In Proceedings of IWQoS 98 , Napa Valley, USA, May 945 1998. 947 [7] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. 948 Resource Reservation Protocol (RSVP) - Version 1 Functional Specifi- 949 cation. RFC 2205, September 1997. 951 [8] Stathes Hadjiefthymiades, Sarantis Paskalis, George Fankhauser, 952 and Lazaros Merakos. Mobility Management in an IP-based Wireless ATM 953 Network. In Proceedings of ACTS Mobile Summit '98 , June 1998. 955 [9] David B. Johnson and Charles Perkins. Mobility Support in IPv6. 956 Internet Draft, draft-ietf-mobileip-ipv6-06.txt, work in progress, 957 August 1998. 959 [10] J. Moy. Multicast Extensions to OSPF. RFC 1584, March 1994. 961 [11] N. Nikaein and C. Bonnet. Wireless Multicasting in an IP 962 Environment. In Proceedings 5th Intl. Workshop on Mobile Multimedia 963 Communication MoMuc '98 , October 1998. 965 Internet Draft RSVP Support for MIPv6 November 98 967 [12] C. Perkins. Mobile Networking Through Mobile IP. IEEE Internet 968 Computing , January 1998. 970 [13] Charles Perkins and David B. Johnson. Route Optimization in 971 Mobile IP. Internet Draft, draft-ietf-mobileip-optim-07.txt, work in 972 progress, August 1998. 974 [14] Lorraine Stacey, Juha Ala-Laurila, Jouni Mikkonen, Jukka 975 Seppala, Stathes Hadjiefthymiades, Neda Nikaein, George Fankhauser, 976 and Sarantis Paskalis. ACTS Project AC085 "Magic WAND", Deliverable 977 1D6 "IP Over Wireless ATM", 978 http://www.tik.ee.ethz.ch/~gfa/papers/AC085_1D6.pdf, August 1998. 980 [15] A. Talukdar, B. Badrinath, and A. Acharya. MRSVP: A Resource 981 Reservation Protocol for an Integrated Services Packet Network with 982 Mobile Hosts. Technical report DCS-TR-337, Rutgers University, 1997. 984 [16] A. Terzis, J. Krawczyk, J. Wroclawski, and L. Zhang. RSVP 985 Operation Over IP Tunnels. Internet Draft, draft-ietf-rsvp-tunnel- 986 03.txt, work in progress, August 1998. 988 [17] M. Veeraraghavan and G. Dommety. Mobile Location Management in 989 ATM Networks. IEEE JSAC , October 1997. 991 [18] D. Waitzman, C. Patridge, and S. Deering. Distance Vector Mul- 992 ticast Routing Protocol. RFC 1075, November 1988. 994 A List of Modified RSVP Objects 996 A.1 Minimal Changes to RSVP Objects for Correct MIP/RSVP Operation 998 o SESSION objects: All of these (i.e. in PATH and RESV messages 999 need to make reference to the MN's care-of address (flow direc- 1000 tion CN ---> MN). Flows to CNs keep CNs' address as a flow 1001 destination. 1003 o RSVP_HOP objects: In PATH messages sent to MNs must contain 1004 the care-of address of the MN. 1006 o FILTER_SPEC objects: Sender addresses in filter specs ori- 1007 ginated from MN's in RESV messages must contain care-of 1008 addresses. 1010 o SENDER_TEMPLATE objects: In PATH messages sent to the CN must 1011 contain the sender's (MN) care-of address. 1013 A.2 Changes to RSVP Objects with Triggers/Objects 1015 Internet Draft RSVP Support for MIPv6 November 98 1017 o MIP_HOME_ADDR objects: Needed in RESV messages sent to CNs. 1018 They could be optionally replaced by constant IPv6 flow labels 1019 for flow recognition. 1021 Authors' addresses 1023 George Fankhauser 1024 Computer Engineering and Networks Laboratory 1025 ETH Zurich 1026 ETH Zentrum 1027 CH-8092 Zurich 1028 Switzerland 1029 email: gfa@acm.org 1031 Stathes Hadjiefthymiades 1032 Communication Networks Laboratory 1033 Department of Informatics 1034 University of Athens 1035 TYPA Building, Panepistimioupolis, 1036 Ilisia, Athens 15784 1037 Greece 1038 email: shadj@di.uoa.gr 1040 Neda Nikaein 1041 Mobile Communication Department 1042 Institut Eurecom 1043 2229, Route des Crete 1044 B.P. 193 1045 F-06904 Sophia Antipolis 1046 France 1047 email: nikaein@eurecom.fr 1049 Internet Draft RSVP Support for MIPv6 November 98 1051 Lorraine Stacey 1052 Lucent Technologies 1053 Sigma, Windmill Hill Business Park, 1054 Swindon, Wiltshire SN5 7EP 1055 United Kingdom 1056 email: lstacey@lucent.com