idnits 2.17.1 draft-choi-mobileip-ipv6-mpls-02.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 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 670 lines 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 are 19 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 86 has weird spacing: '...ociated with...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (December 2001) is 8167 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) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-14 == Outdated reference: A later version (-03) exists of draft-choi-mobileip-ldpext-02 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-03) exists of draft-ietf-mobileip-qos-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-mobileip-qos-requirements (ref. '5') == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-06 ** Obsolete normative reference: RFC 2461 (ref. '7') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '8') (Obsoleted by RFC 4862) -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' ** Obsolete normative reference: RFC 3036 (ref. '11') (Obsoleted by RFC 5036) Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Jun Kyun Choi 2 Internet Draft ICU 3 Document: Myoung Hun Kim 4 Expires: June 2002 ICU 5 Yoon Ju Lee 6 ETRI 7 December 2001 9 Mobile IPv6 support in MPLS Network 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026 except that the right to 20 produce derivative works is not granted. 22 This document is an Internet-Draft and is NOT offered in accordance 23 with Section 10 of RFC2026, and the author does not provide the IETF 24 with any rights other than to publish as an Internet-Draft 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet- Drafts as reference 32 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document discusses how to build the large-scale mobile IPv6 41 network along with the MPLS network. It proposes that CR-LDP/RSVP-TE 42 can be applied to set up the QoS guaranteed Label switched path (LSP) 43 tunnels between an LER of mobile node and an LER of correspondent 44 node. It means that the IPv6-in-IPv6 tunnels can be replaced by one 45 or multiple LSPs on the MPLS network. This follows design principles 46 such as idle mobile node consideration and QoS guarantee, smooth 47 handoff, no change of Mobile IPv6 etc. 49 Conventions 51 Choi/Kim/Lee 1 Page 52 draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119. 58 Table of Contents 60 1. Introduction ................................................ 2 61 2. Benefits from MPLS ...........................................3 62 2.1. Independency from lower layer technologies .............. 3 63 2.2. IPv6 transition benefit ................................. 3 64 2.3. Connection-Oriented Switching Paradigm .................. 4 65 2.4. Well defined QoS support with DiffServ .................. 4 66 2.5. Secure VPN .............................................. 4 67 3. Features of Mobile IPv6 with MPLS ........................... 5 68 4. Description of Operation .................................... 6 69 4.1. When MN initiates data transmission ..................... 6 70 4.2. When CN initiates data transmission ..................... 7 71 4.3. Smooth Handoff .......................................... 8 72 4.4. QoS supported LSP ....................................... 8 73 5. Required Messages and TLVs ................................... 10 74 6. Conclusion .................................................. 10 75 7. Security considerations ..................................... 11 76 8. References .................................................. 11 77 9. Author's Addresses .......................................... 11 79 1. Introduction 81 Mobile IPv6 [1] allows a mobile node to be always addressable by its 82 home address, whether it is currently attached to its home link or is 83 away from home. While a mobile node is attached to some foreign link 84 away from home, it is also addressable by one or more care-of 85 addresses, in addition to its home address. A care-of address is an 86 IP address associated with a mobile node while visiting a 87 particular foreign link. The subnet prefix of a mobile node's care- 88 of address is the subnet prefix (or one of the subnet prefixes) on 89 the foreign link being visited by the mobile node; if the mobile node 90 is connected to this foreign link while using that care-of address, 91 packets addressed to this care-of-address will be routed to the 92 mobile node in its location away from home. 94 The MPLS network provides the backbone solution for high-speed IP 95 forwarding and large scalability. And also the MPLS network support 96 appropriate quality-of-service paths for differentiated mobile IP 97 services. The initial MPLS effort will be focused on IPv4. However, 98 the core technology will be extendible to new network layer protocols 99 (e.g., IPv6). 101 If IPv6 employs MPLS technology, variable benefit will be expected. 102 Because MPLS is not confined to certain specific link layer 103 technology, it can work with any media over which Network Layer 104 packets can be passed between network layer entities. This aspect 106 Choi/Kim/Lee 2 Page 107 draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002 109 will be applicable to guarantee user's required QoS and Traffic 110 Engineering because MPLS is well suited for DiffServ and sort of ATM 111 Traffic Engineering. In addition, secure VPN and IPv6 transition 112 benefit will be expected. 114 This document proposes the MPLS network architecture and tunneling 115 procedures to support the mobile IPv6 network. Similar concerns on 116 the integration of MPLS network and Mobile IP network are also 117 investigated in [2][3]. However those documents are lack of Mobile 118 IPv6 consideration. 120 In terms of control plane concern, both CR-LDP and RSVP-TE are 121 applicable to set up the QoS guaranteed Label Switched Path (LSP) 122 tunnel between a router of the mobile hosts and a router of the 123 correspondent node. 125 When the integration of wired and wireless network is designed, there 126 are thins to consider. For example, idle mobile node, smooth handoff, 127 QoS guarantee, etc. Next part describes those design principles. 129 2. Benefits from MPLS 131 2.1. Independency from lower layer technologies 133 The MPLS control component centers around IP functionality, which is 134 similar to proprietary multilayer switching solutions. However, MPLS 135 defines new standard-based IP signaling and label distribution 136 protocols, as well as extensions to existing protocols, to support 137 multivendor interoperability. In this way, MPLS brings significant 138 benefits to a packet-oriented Internet. 140 The MPLS forwarding component is based on the label-swapping 141 algorithm. If the Layer 2 technology supports a label field (such as 142 the ATM VPI/VCI or the Frame Relay DLCI fields), the native label 143 field encapsulates the MPLS label. However, if the Layer 2 technology 144 does not support a label field, the MPLS label is encapsulated in a 145 standardized MPLS header that is inserted between the Layer 2 and IP 146 headers. The MPLS header permits any link layer technology to carry 147 an MPLS label so it can benefit from label-swapping across an LSP. 149 2.2. IPv4 to IPv6 transition benefit 151 The ability of the underlying Internet infrastructure to accommodate 152 architectural improvements has proven to be a significant factor in 153 its overall success. Though IPv6 Transition still has lots of 154 scenarios and burdens simultaneously. MPLS, a forwarding and control 155 plane architecture, is a notable example of this. 157 Therefore given the wide-scale backbone adoption of MPLS, it is key 158 that IPv6 integrate with this technology. We believes that both are 159 highly complementary since integrating IPv6 transport services over 160 an MPLS topology requires much less backbone infrastructure upgrades 161 or reconfiguration while also supporting dynamic connectivity between 163 Choi/Kim/Lee 3 Page 164 draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002 166 peripheral IPv6 networks. This results from the fact that with MPLS 167 networks, forwarding is based upon labels rather than the IP header 168 itself. As such, the data plane dependency on being able to support 169 native IPv6 packet forwarding is removed, hence eliminating the need 170 for network core hardware and software upgrades, a likely reality for 171 native end-to-end IPv6 forwarding. 173 2.3. Connection-Oriented Switching Paradigm 175 As a packet of a connectionless network layer protocol travels from 176 one router to the next, each router makes an independent forwarding 177 decision for that packet. That is, each router analyzes the packet's 178 header, and each router runs a network layer routing algorithm. Each 179 router independently chooses a next hop for the packet, based on its 180 analysis of the packet's header and the results of running the 181 routing algorithm. 183 Unlike normal routers MPLS LSRs deliver connection-oriented network 184 service. Rather than determining the path of each packet 185 independently, the LSRs establish a path between the endpoints of a 186 connection in a network and send the packets across that path. That 187 LSP is still a virtual connection, sharing the bandwidth of the 188 physical circuit. In contrast to connectionless routing, the LSRs can 189 define the parameters of the virtual connection, including allowable 190 speed and priority. This is crucial to the LSR's ability to manage 191 bandwidth and QoS. 193 These distinct features give network managers the ability to tailor 194 network service to the specific needs of diverse applications with 195 varying classes of service. Demanded LSPs make use of LSR thus 196 deliver the variable features such as Fault tolerance, Prioritization, 197 QoS Classes. 199 2.4. Well defined QoS support with DiffServ 201 Though IPv6 has QoS consideration, it still has things to be solved 202 such as Flow ID issue. In addition, the MPLS shim header achieves the 203 original goals of the Flow ID field. 205 MPLS allows the precedence or class of service to be fully or 206 partially inferred from the label. In this case, one may say that 207 the label represents the combination of a FEC and a precedence or 208 class of service. 210 In a DiffServ domain all the IP packets crossing a link and requiring 211 the same DiffServ behavior are said to constitute a Behavior 212 Aggregate (BA). At the ingress node of the DiffServ domain the 213 packets are classified and marked with a DiffServ Code Point (DSCP), 214 which corresponds to their Behavior Aggregate. At each transit node, 215 the DSCP is used to select the Per Hop Behavior (PHB) that determines 216 the scheduling treatment and, in some cases, drop probability for 217 each packet. 219 Choi/Kim/Lee 4 Page 220 draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002 222 Recent work [4] allows the MPLS network administrator to select how 223 Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched 224 Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic 225 Engineering and protection objectives within his/her particular 226 network. 228 2.5. Secure VPN 230 The secure VPN, one of major applications of MPLS, is also applicable 231 to IPv6 network. The inherent VPN and Traffic Engineering services 232 available within an MPLS environment could enable IPv6 networks going 233 forward to be combined into virtual private networks or extranets 234 over an infrastructure also supporting IPv4 VPNs and MPLS-TE. 235 Additionally MPLS VPNs offer the same level of security as 236 connection-oriented VPNs. Packets from one VPN do not inadvertently 237 go to another VPN. 239 VPN traffic is kept separate. Malicious spoofing is nearly impossible 240 because the packets received from customers are IP packets. These IP 241 packets must be received on a particular interface or subinterface to 242 be uniquely identified with a VPN label. 244 3. Features of Mobile IPv6 with MPLS 246 3.1. QoS guaranteed LSP setup 247 It is required to program appropriate QoS support for the MN's 248 packets in the intermediate network domains, so that the performance 249 of QoS-sensitive applications running on the MN is maintained at 250 desired level. To achieve this, our model adopts QoS Object [5] to 251 interoperate with CR-LDP/RSVP-TE. 253 3.2. Idle mobile node consideration 254 We imagine that wireless IP communicators will be turned around the 255 clock, ready to receive or initiate services. In fact, the vast 256 majority of subscribers will not be actively communicating most of 257 the time. Rather, wireless IP communicators will be switched on, 258 ready for service, constantly reachable by the wireless Internet. In 259 essence, MN will be in an idle state but passively connected to the 260 network infrastructure. Thus design principle is that only active 261 data are supposed to traverse over QoS guaranteed LSP. This will 262 prevent LSP abusing that can be caused by lots of control packets. 263 Thus an LSP is established only between MN's router and CN's router 264 other than LSP via HA. This would be efficient scheme to save 265 bandwidth on network and to reduce end-to-end delay. 267 3.3. Smooth handoff support 268 There are two goals in term of handoff; the first, to reduce the 269 latency or interruption due to handoffs; and second, to reduce the 270 signaling load. Mobile IPv6 is considered as optimal solution for 271 those needs. Use of more than on care-of-address by a MN may be 272 useful to improve smooth handoff when the MN moves from on wireless 273 link to another. Our suggested model supports the smooth handoff 275 Choi/Kim/Lee 5 Page 276 draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002 278 scheme of Mobile IPv6 and gives solution to QoS consideration with 279 providing QoS guaranteed multiple LSP for the number of MN's care-of- 280 address. 282 3.4. Bi-directional LSP extensible 283 While traditional traffic engineered MPLS are unidirectional, 284 generalized MPLS [6] supports the establishment of bi-directional LSP. 285 Bi-directional LSP has the benefit of lower setup latency and lower 286 number of messages required during setup. It takes only one 287 initiator-eliminator round trip time. The suggested model is possible 288 to be expended to generalized MPLS. 290 3.5. No obligation of MPLS signaling on MN 291 Mobile IPv6 embedded MN and CN doesn't need to install CR-LDP/RSVP-TE 292 at all. CR-LDP/RSVP runs on a router or switch of MNs and CNs. This 293 will reduce memory cost and complexity of a MN device. 295 3.6. No additional messages on legacy MPLS signaling 296 There is no additional Message or TLV/Object on existing CR-LDP/RSVP- 297 TE to setup QoS guaranteed LSP between CN's LER and MN's LER. The 298 suggested model adopts data-driven LSP setup. 300 4. Description of Operation 302 4.1. When MN initiates data transmission 304 We assume a MN has already done new default router finding [7], 305 Address auto-configuration [8], Registration, and Biding 306 Acknowledgement reception as Mobile IPv6 procedures. 308 +----------+ 309 | Foreign | 310 +------------------------------+ | Mobile IP| 311 | The MPLS Network +-+--+ | Network | 312 | with Mobility Support | | | +------+ | 313 +---------+ +----+ /|LER2|--+-|old MN| | 314 |Home | | HA | +------+ +------+ / +--+-+ | +------+ | 315 |Mobile IP+-+LER1|--| LSR1 +--+ LSR2 |--+ | +----------+ 316 |Network | |----+ +------+ +------+ \ | 317 +---------+ | \ | \ | +----------+ 318 | \ | \ | | Foreign | 319 | \ | \ | | Mobile IP| 320 | \ | +-++-+ | Network | 321 | +-+-+--+ | | | +------+ | 322 +----| LER3 |----------------|LER4|--+-|New MN| | 323 +---+--+ +----+ | +------+ | 324 | +----------+ 325 +-+--+ 326 | CN | 327 +----+ 329 LER: Label Edge Router 331 Choi/Kim/Lee 6 Page 332 draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002 334 LSR: Label Switching Router 335 HA: Home Agent 336 MN: Mobile Node 337 FN: Correspondent Node 339 Figure 1. The MPLS Network with Mobile IPv6 Support 341 When the MN sends packets to any other correspondent node, it sends 342 packets directly to the destination. The MN sets the source address 343 of this packet to the care-of-address and includes a 'Home Address' 344 destination option. Then the correspondent node must process the 345 option in a manner consistent with exchanging the Home Address field 346 from the Home Address option into the IPv6 header. Since the home 347 address is static (in contrast to the care-of-address), this allows 348 every correspondent node the transparent use of the care-of-address 349 for layers above the Mobile IPv6 support. Higher layers including 350 applications do not recognize the care-of-address. They only notice 351 the home address. Then the packets from the correspondent node are 352 routed to the HA and tunneled to MN by IPv6-in-IPv6. This routing is 353 called Triangle Routing. 355 To avoid triangle routing a MN sends Binding Update that may be 356 together with QoS Object to correspondent node. The MN's LER 357 receiving the Binding Update message should determine whether to 358 initiate REQUEST/PATH message or not. If the Binding Update message 359 has zero H bit, the LER initiates REQUEST/PATH for a destination 360 address (FEC). Now the correspondent IPv6 node receiving the Binding 361 Update message is able to send packets to MN directly. Newly 362 established QoS guaranteed LSP provides tunnel for packets to 363 traverse. 365 MN MN's LER2 HA CN's LER3 CN 366 | | | | | 367 | | packet | | 368 |------------------------------------------------------------>| 369 | | | packet | 370 | IPv6-in-IPv6 tunneling |<----------------------------| 371 |<------------------------------| | 372 | | | | | 373 | Binding update with QoS Object | | 374 |-------------->|-------------------------------------------->| 375 | | REQUEST/PATH | | 376 | |------------------------------>| | 377 | | MAPPING/RESV | | 378 | |<------------------------------| | 379 | | | | 380 | | QoS guranteed LSP | | 381 |<------------->|<----------------------------->|<----------->| 382 | | | | | 384 Figure 2. MN initiates data transmission 386 Choi/Kim/Lee 7 Page 387 draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002 389 4.2. When CN initiates data transmission 391 We assume a MN has already done new default router finding, Address 392 auto-configuration, Registration, and Biding Acknowledgement 393 reception as Mobile IPv6 procedures. 395 Before a CN sends any packet to the MN, the CN should examine its 396 Binding Cache for an entry for an entry for the destination address 397 (Home address) to which the packet is being sent. If the CN has a 398 Binding Cache entry for this address, the CN should use a Routing 399 header to route the packet to the MN by way of the care-of-address in 400 the binding recorded in that Binding Cache entry. We assume that a CN 401 has no Binding Cache entry for the MN in this part. The packet sent 402 by the CN will be intercepted by the MN's HA and tunneled (using 403 IPv6-in-IPv6 encapsulation) to the MN's current primary care-of- 404 address. 406 To avoid triangle routing a MN sends Binding Update that may be 407 together with QoS Object to correspondent node. The MN's LER 408 receiving the Binding Update message should determine whether to 409 initiate REQUEST/PATH or not. If the Binding Update message has zero 410 H bit, the LER initiates REQUEST/PATH for a destination address (FEC). 411 Now the correspondent IPv6 node receiving the Binding Update message 412 is able to send packets to MN directly. Newly established QoS 413 guaranteed LSP provides tunnel for packets to traverse. 415 MN MN's LER2 HA CN's LER3 CN 416 | | | | | 417 | | | packet | 418 | IPv6-in-IPv6 tunneling |<----------------------------| 419 |<------------------------------| | 420 | | | | | 421 | Binding update with QoS Object | | 422 |-------------->|-------------------------------------------->| 423 | | REQUEST/PATH | | 424 | |------------------------------>| | 425 | | MAPPING/RESV | | 426 | |<------------------------------| | 427 | | | | 428 | | QoS guaranteed LSP | | 429 |<------------->|<----------------------------->|<----------->| 430 | | | | | 432 Figure 3. CN initiates data transmission 434 4.3. Smooth Handoff 436 Use of more than on care-of-address by a MN may be useful to improve 437 smooth handoff when the MN moves from on wireless link to another. If 438 each of these wireless links is connected to the Internet through a 439 separate base station, such that the wireless transmission range from 440 the two base stations overlap, the mobile node may be able to remain 442 Choi/Kim/Lee 8 Page 443 draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002 445 connected to both links while in the area of overlap. In this case, 446 the MN could acquire a new care-of-address on the new link before 447 moving out of transmission range and disconnecting from the old link. 448 The MN may thus still accept packets at its old care-of-address while 449 it works to update its HA and CNs, notifying them of its new CoA on 450 the new link. 452 When a MN acquires new CoA while communicating with CN over legacy 453 LSP, The MN sends Binding Update along with QoS Object to the CN for 454 Route Optimization. The MN's LER receiving the Binding Update message 455 will initiates REQUEST/PATH. Now the correspondent IPv6 node 456 receiving the Binding Update message is able to send packets to MN 457 directly while previous flow have been traversed over the legacy LSP. 458 Which supports smooth handoff scheme over both legacy LSP and newly 459 established QoS guaranteed LSP. The old LSP will be released 460 automatically as time goes by because no more data transmitted over 461 the LSP. 463 New CoA New LER4 Old LER2 CN's LER3 CN 464 | | | | | 465 | | | Legacy LSP | | 466 | | |<------------->|<----------->| 467 | Binding update with QoS Object | | 468 |-------------->|-------------------------------------------->| 469 | | REQUEST/PATH | | 470 | |------------------------------>| | 471 | | MAPPING/RESV | | 472 | |<------------------------------| | 473 | | | | 474 | | New QoS guaranteed LSP | | 475 |<------------->|<----------------------------->|<----------->| 476 | | | | | 478 Figure 4. Smooth handoff 480 There are still lots of discussion to adopt appropriate handoff 481 scheme[9][10]. Our document keeps an eye on those emerging handoff 482 algorithm and will adopt some of them to establish LSP between CN's 483 LSR and MN's one. Thus above handoff support LSP scheme may change. 484 For example, If a Handoff scheme use tunnel method between Old Access 485 Router (AR) and New AR, Our scheme may evolve to setup extended LSP 486 between Old AR and New AR. In this case MN can receive data through 487 old LSP and extended LSP as well as newly established LSP associated 488 new CoA. 490 4.4. QoS supported LSP 492 The composition of a QoS OBJECT is shown in Figure 5. A QoS OBJECT is 493 an extension of RSVP QoS and FILTER_SPEC objects. This is originally 494 from [5]. 496 Choi/Kim/Lee 9 Page 497 draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002 499 0 1 2 3 500 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 1 | Reserved | Object Length |QoS Requirement| 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 2 | Max Delay | Delay Jitter | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 3 | Average Data Rate | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 4 | Burstiness:Token Bucket Size | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 5 | Peak Data Rate | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 6 | Minimum Policed Unit | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 7 | Maximum Packet Size | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 8 | | 517 | | 518 | Values of Packet Classification Parameters | 519 | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Figure 4: Composition of a QoS OBJECT 524 o QoS Requirement: This field describes the QoS requirement of the 525 MN's packet stream in terms of traffic class. An example is 526 specification in terms of DiffServ PHB classes such as EF or AF. 527 IntServ classes such as guaranteed service or controlled load service 528 and UMTS QoS class [11] such as delay sensitivity, interactive-delay 529 sensitive, non-interactive delay sensitive or delay insensitive are 530 also supported. 532 Some examples are, 534 00000xxx: DiffServ EF PHB 535 00001xxx: DiffServ AF PHB 537 After some sort of authentication, which is beyond the scope of this 538 document, MN's LSR can send Label REQUEST/PATH message with DiffServ 539 TLV/DiffServ Object to establish E-LSP or L-LSP. 541 5. Required messages and TLVs 543 There are no additional messages and TLVs to existing Mobile IPv6 [1], 544 CR-LDP/RSVP-TE, and Generalized MPLS [6] to operate the suggested 545 model. In order to support QoS guaranteed communication in Mobile 546 IPv6, QoS object described in [5] is required. 548 6. Conclusion 550 We have proposed a scheme to integrate Mobile IPv6 and MPLS. This 551 scheme eliminates usages of IP-in-IP tunneling in the data forwarding. 553 Choi/Kim/Lee 10 Page 554 draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002 556 Switching is much faster than hop-by-hop IP forwarding, so the 557 transmission delay and packet processing overhead is reduced. We have 558 designed principles such as No change to Mobile IPv6, Idle node 559 consideration, smooth handoff, bi-directional LSP, and QoS guaranteed 560 service. This document will be divided by RSVP-TE centered memo and 561 CR-LDP centered one. 563 7. Security Considerations 565 The Mobile IPv6 and MPLS scheme described in this document is 566 subject to the same security considerations that apply to draft-ietf- 567 mobileip-ipv6-13.txt[1], RFC3036[11], RFC3031[12]. 569 8. References 571 [1] D. Johnson, Mobility Support in IPv6, draft-ietf-mobileip-ipv6- 572 14.txt, July, 2000. 573 [2] Choi, Extension of LDP for Mobile IP Service through the MPLS 574 Network, draft-choi-mobileip-ldpext-02.txt, August, 2001. 575 [3] R, Zhong, Integration of Mobile IP and MPLS, draft-zhong-mobile- 576 ip-mpls-01.txt July, 2000. 577 [4] F. Faucheur, MPLS Support of Differentiated Services, draft-ietf- 578 mpls-diff-ext-09.txt, April, 2001. 579 [5] H. Chaskar, Framework for QoS Support in Mobile IPv6, draft- 580 ietf-mobileip-qos-requirements-01.txt, August, 2001 581 [6] P. Ashwood, Generalized MPLS - Signaling Functional Description, 582 draft-ietf-mpls-generalized-signaling-06.txt, October, 2001. 583 [7] Thomas Narten, Erik Nordmark, Neighbor Discovery for IP Version 6 584 (IPv6). RFC 2461, December, 1998. 585 [8] S. Thomson and T. Narten, IPv6 Stateless Address 586 Autoconfiguration, RFC 2462, 1998. 587 [9] G. Tsirtsis, Fast Handovers for Mobile IPv6, draft-ietf-mobileip- 588 fast-mipv6-02.txt, July, 2001 589 [10] Karim El-Malki, Fast Handoffs in MIPv6, draft-elmalki- 590 handoffsv6-01.txt, November, 2000 591 [11] L. Andersson, LDP Specification, RFC3036, January, 2001. 592 [12] E. Rosen, Multiprotocol Label Switching Architecture, RFC3031, 593 January, 2001. 595 8. Author's Addresses 597 Jun Kyun Choi 598 Information and Communications University (ICU) 599 58-4 Hwa Ahm Dong, Yusong, Taejon 600 Korea 305-732 601 Phone: +82-42-866-6122 602 Email: jkchoi@icu.ac.kr 604 Myoung Hun Kim 605 Information and Communications University (ICU) 606 58-4 Hwa Ahm Dong, Yusong, Taejon 607 Korea 305-732 608 Phone: +82-42-866-6198 610 Choi/Kim/Lee 11 Page 611 draft-choi-mobileip-ipv6-mpls-02.txt Expires June 2002 613 Email: fiaa@icu.ac.kr 615 Yoon Ju Lee 616 Electronics and Telecommunication Research Institute (ETRI) 617 161 Kajung Dong Yusong, Taejon 618 Korea 305-305 619 Phone: +82-42-860-1130 620 Email: yjlee@etri.re.kr 622 Full Copyright Statement 624 "Copyright (C) The Internet Society (date). All Rights Reserved. This 625 document and translations of it may be copied and furnished to others, 626 and derivative works that comment on or otherwise explain it or 627 assist in its implmentation may be prepared, copied, published and 628 distributed, in whole or in part, without restriction of any kind, 629 provided that the above copyright notice and this paragraph are 630 included on all such copies and derivative works. However, this 631 document itself may not be modified in any way, such as by removing 632 the copyright notice or references to the Internet Society or other 633 Internet organizations, except as needed for the purpose of 634 developing Internet standards in which case the procedures for 635 copyrights defined in the Internet Standards process must be followed, 636 or as required to translate it into languages other than English. The 637 limited permissions granted above are perpetual and will not be 638 revoked by the Internet Society or its successors or assigns. 640 Choi/Kim/Lee 12 Page