MPLS Working Group Jun Kyun Choi Internet Draft ICU Document: Myoung Hun Kim ICU Tai Won Um ICU March 2001 Mobile IPv6 support in MPLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses how to build the large-scale mobile IPv6 network along with the MPLS network. It proposes that CR-LDP/RSVP-TE can be applied to set up the QoS guaranteed Label switched path (LSP) tunnels between an LER of mobile node and an LER of correspondent node. It means that the IPv6-in-IPv6 tunnels can be replaced by one or multiple LSPs on the MPLS network. This follows design principles such as idle mobile node consideration and QoS guarantee, smooth handoff, no change of Mobile IPv6 etc. Choi, et al. Expires October 2001 [page 1] Internet Draft draft-choi-mobileip-ipv6-mpls-00.txt October 2001 Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Introduction ................................................ 2 2. Features of Mobile IPv6 with MPLS ........................... 3 3. Description of Operation .................................... 4 3.1. When MN initiates data transmission ..................... 4 3.2. When CN initiates data transmission ..................... 5 3.3. Smooth Handoff .......................................... 6 4. Required Messages and TLVs ................................... 7 5. Conclusion .................................................. 7 6. Security considerations ..................................... 7 7. References .................................................. 8 8. Author's Addresses .......................................... 8 1. Introduction Mobile IPv6 [1] allows a mobile node to be always addressable by its home address, whether it is currently attached to its home link or is away from home. While a mobile node is attached to some foreign link away from home, it is also addressable by one or more care-of addresses, in addition to its home address. A care-of address is an IP address associated with a mobile node while visiting a particular foreign link. The subnet prefix of a mobile node's care- of address is the subnet prefix (or one of the subnet prefixes) on the foreign link being visited by the mobile node; if the mobile node is connected to this foreign link while using that care-of address, packets addressed to this care-of-address will be routed to the mobile node in its location away from home. The MPLS network provides the backbone solution for high-speed IP forwarding and large scalability. And also the MPLS network support appropriate quality-of-service paths for differentiated mobile IP services. The initial MPLS effort will be focused on IPv4. However, the core technology will be extendible to new network layer protocols (e.g., Ipv6). MPLS is not confined to any specific link layer technology. It can work with any media over which Network Layer packets can be passed between network layer entities. MPLS provides connection-oriented (label based) switching based on IP routing and control protocols. This document proposes the MPLS network architecture and tunneling procedures to support the mobile IPv6 network. Similar concerns on the integration of MPLS network and Mobile IP network are also investigated in [2][3]. However those documents are lack of Mobile IPv6 consideration. Choi, et al. Expires October 2001 [page 2] Internet Draft draft-choi-mobileip-ipv6-mpls-00.txt October 2001 In terms of control plane concern, both CR-LDP and RSVP-TE are applicable to set up the QoS guaranteed Label Switched Path (LSP) tunnel between a router of the mobile hosts and a router of the correspondent node. When the integration of wired and wireless network is designed, there are thins to consider. For example, idle mobile node, smooth handoff, QoS guarantee, etc. Next part describes those design principles. 2. Features of Mobile IPv6 with MPLS I. QoS guaranteed LSP setup It is required to program appropriate QoS support for the MN's packets in the intermediate network domains, so that the performance of QoS-sensitive applications running on the MN is maintained at desired level. To achieve this, our model adopts QoS Object [4] to interoperate with CR-LDP/RSVP-TE. II. Idle mobile node consideration We imagine that wireless IP communicators will be turned around the clock, ready to receive or initiate services. In fact, the vast majority of subscribers will not be actively communicating most of the time. Rather, wireless IP communicators will be switched on, ready for service, constantly reachable by the wireless Internet. In essence, MN will be in an idle state but passively connected to the network infrastructure. Thus design principle is that only active data are supposed to traverse over QoS guaranteed LSP. This will prevent LSP abusing that can be caused by lots of control packets. Thus an LSP is established only between MN's router and CN's router other than LSP via HA. This would be efficient scheme to save bandwidth on network and to reduce end-to-end delay. III. Smooth handoff support There are two goals in term of handoff; the first, to reduce the latency or interruption due to handoffs; and second, to reduce the signaling load. Mobile IPv6 is considered as optimal solution for those needs. Use of more than on care-of-address by a MN may be useful to improve smooth handoff when the MN moves from on wireless link to another. Our suggested model supports the smooth handoff scheme of Mobile IPv6 and gives solution to QoS consideration with providing QoS guaranteed multiple LSP for the number of MN's care-of- addres. IV. Bi-directional LSP extensible While traditional traffic engineered MPLS are unidirectional, generalized MPLS [5] supports the establishment of bi-directional LSP. Bi-directional LSP has the benefit of lower setup latency and lower number of messages required during setup. It takes only one initiator-eliminator round trip time. The suggested model is possible to be expended to generalized MPLS. Choi, et al. Expires October 2001 [page 3] Internet Draft draft-choi-mobileip-ipv6-mpls-00.txt October 2001 V. No obligation of MPLS signaling on MN Mobile IPv6 embedded MN and CN doesn't need to install CR-LDP/RSVP-TE at all. CR-LDP/RSVP runs on a router or switch of MNs and CNs. This will reduce memory cost and complexity of a MN device. VI. No additional messages on legacy MPLS signaling There is no additional Message or TLV/Object on existing CR-LDP/RSVP- TE to setup QoS guaranteed LSP between CN's LER and MN's LER. The suggested model adopts data-driven LSP setup. VII. Stream-like IP traffic support only If LSP is established for the datagram IP traffic (the UDP traffic), LSP setup and release repetition would occur because the traffic are generated sparsely. So our model considers only TCP traffic. 3. Description of Operation 3.1 When MN initiates data transmission We assume a MN has already done new default router finding [6], Address auto-configuration [7], Registration, and Biding Acknowledgement reception as Mobile IPv6 procedures. +----------+ | Foreign | +------------------------------+ | Mobile IP| | The MPLS Network +-+--+ | Network | | with Mobility Support | | | +------+ | +---------+ +----+ /|LER2|--+-|old MN| | |Home | | HA | +------+ +------+ / +--+-+ | +------+ | |Mobile IP+-+LER1|--| LSR1 +--+ LSR2 |--+ | +----------+ |Network | |----+ +------+ +------+ \ | +---------+ | \ | \ | +----------+ | \ | \ | | Foreign | | \ | \ | | Mobile IP| | \ | +-++-+ | Network | | +-+-+--+ | | | +------+ | +----| LER3 |-----------------|LER4|--+-|New MN| | +---+--+ +----+ | +------+ | | +----------+ +-+--+ | CN | +----+ LER: Label Edge Router LSR: Label Switching Router HA: Home Agent MN: Mobile Node FN: Correspondent Node Figure 1. The MPLS Network with Mobile IPv6 Support Choi, et al. Expires October 2001 [page 4] Internet Draft draft-choi-mobileip-ipv6-mpls-00.txt October 2001 When the MN sends packets to any other correspondent node, it sends packets directly to the destination. The MN sets the source address of this packet to the care-of-address and includes a "Home Address" destination option. Then the correspondent node must process the option in a manner consistent with exchanging the Home Address field from the Home Address option into the IPv6 header. Since the home address is static (in contrast to the care-of-address), this allows every correspondent node the transparent use of the care-of-address for layers above the Mobile IPv6 support. Higher layers including applications do not recognize the care-of-address. They only notice the home address. Then the packets from the correspondent node are routed to the HA and tunneled to MN by IPv6-in-IPv6. This routing is called Triangle Routing. The MN's LER should add the inner transport protocol information of original IPv6 packet and source address (Correspondent Node address) in an LCIB (Label Candidate Information Base). To avoid triangle routing a MN sends Binding Update that may be together with QoS Object to correspondent node. The MN's LER receiving the Binding Update message should determine whether to initiate REQUEST/PATH message or not. The LER having the LCIB consisting of transport protocol field and Candidate FEC elements should match Destination address of Binding Update message and LCIB's FEC. If any exists and the transport protocol field indicates TCP, the LER will initiates REQUEST/PATH message for the found FEC. Now the correspondent IPv6 node receiving the Binding Update message is able to send packets to MN directly. Newly established QoS guaranteed LSP provides tunnel for packets to traverse. MN MN's LER2 HA CN's LER3 CN | | | | | | | packet | | |------------------------------------------------------------>| | | | packet | | IPv6-in-IPv6 tunneling |<----------------------------| |<------------------------------| | | | | | | | Binding update with QoS Object | | |-------------->|-------------------------------------------->| | | REQUEST/PATH | | | |------------------------------>| | | | MAPPING/RESV | | | |<------------------------------| | | | | | | | QoS gurantted LSP | | |<------------->|<----------------------------->|<----------->| | | | | | Figure 2. MN initiates data transmission Choi, et al. Expires October 2001 [page 5] Internet Draft draft-choi-mobileip-ipv6-mpls-00.txt October 2001 3.2 When CN initiates data transmission We assume a MN has already done new default router finding, Address auto-configuration, Registration, and Biding Acknowledgement reception as Mobile IPv6 procedures. Before a CN sends any packet to the MN, the CN should examine its Binding Cache for an entry for an entry for the destination address (Home address) to which the packet is being sent. If the CN has a Binding Cache entry for this address, the CN should use a Routing header to route the packet to the MN by way of the care-of-address in the binding recorded in that Binding Cache entry. We assume that a CN has no Binding Cache entry for the MN in this part. The packet sent by the CN will be intercepted by the MN's HA and tunneled (using IPv6 encapsulation) to the MN's current primary care-of-address. The MN's LER receiving the tunnel packet should add the inner transport protocol information of original IPv6 packet and source address (Correspondent Node address) in an LCIB (Label Candidate Information Base). To avoid triangle routing a MN sends Binding Update that may be together with QoS Object to correspondent node. The MN's LER receiving the Binding Update message should determine whether to initiate REQUEST/PATH or not. The LER having the LCIB consisting of transport protocol field and Candidate FEC elements should match Destination address of Binding Update message and LCIB's FEC. If any exists and the transport protocol field indicates TCP, the LER will initiates REQUEST/PATH for the found FEC. Now the correspondent IPv6 node receiving the Binding Update message is able to send packets to MN directly. Newly established QoS guaranteed LSP provides tunnel for packets to traverse. MN MN's LER2 HA CN's LER3 CN | | | | | | | | packet | | IPv6-in-IPv6 tunneling |<----------------------------| |<------------------------------| | | | | | | | Binding update with QoS Object | | |-------------->|-------------------------------------------->| | | REQUEST/PATH | | | |------------------------------>| | | | MAPPING/RESV | | | |<------------------------------| | | | | | | | QoS guaranteed LSP | | |<------------->|<----------------------------->|<----------->| | | | | | Figure 3. CN initiates data transmission Choi, et al. Expires October 2001 [page 6] Internet Draft draft-choi-mobileip-ipv6-mpls-00.txt October 2001 3.3 Smooth Handoff Use of more than on care-of-address by a MN may be useful to improve smooth handoff when the MN moves from on wireless link to another. If each of these wireless links is connected to the Internet through a separate base station, such that the wireless transmission range from the two base stations overlap, the mobile node may be able to remain connected to both links while in the area of overlap. In this case, the MN could acquire a new care-of-address on the new link before moving out of transmission range and disconnecting from the old link. The MN may thus still accept packets at its old care-of-address while it works to update its HA and CNs, notifying them of its new CoA on the new link. When a MN acquires new CoA while communicating with CN over legacy LSP, The MN sends Binding Update along with QoS Object to the CN for Route Optimization. The MN's LER receiving the Binding Update message will initiates REQUEST/PATH. Now the correspondent IPv6 node receiving the Binding Update message is able to send packets to MN directly while previous flow have been traversed over the legacy LSP. Which supports smooth handoff scheme over both legacy LSP and newly established QoS guaranteed LSP. The old LSP will be released automatically as time goes by because no more data transmitted over the LSP. New CoA New LER4 Old LER2 CN's LER3 CN | | | | | | | | Legacy LSP | | | | |<------------->|<----------->| | Binding update with QoS Object | | |-------------->|-------------------------------------------->| | | REQUEST/PATH | | | |------------------------------>| | | | MAPPING/RESV | | | |<------------------------------| | | | | | | | New QoS guaranteed LSP | | |<------------->|<----------------------------->|<----------->| | | | | | Figure 4. Smooth handoff 4. Required messages and TLVs There are no additional messages and TLVs to existing Mobile IPv6 [1], CR-LDP/RSVP-TE, and Generalized MPLS [5] to operate the suggested model. In order to support QoS guaranteed communication in Mobile IPv6, QoS object described in [4] is required. Choi, et al. Expires October 2001 [page 7] Internet Draft draft-choi-mobileip-ipv6-mpls-00.txt October 2001 5. Conclusion We have proposed a scheme to integrate Mobile IPv6 and MPLS. This scheme eliminates usages of IP-in-IP tunneling in the data forwarding. Switching is much faster than hop-by-hop IP forwarding, so the transmission delay and packet processing overhead is reduced. We have designed principles such as No change to Mobile IPv6, Idle node consideration, smooth handoff, bi-directional LSP, short UDP data consideration, and QoS guaranteed service. This document will be divided by RSVP-TE centered memo and CR-LDP centered one. And parameters mapping issue between QoS Object of Binding Update message and CR-LDP/RSVP-TE related QoS field is for further study. 6. Security Considerations The Mobile IPv6 and MPLS scheme described in this document is subject to the same security considerations that apply to draft-ietf- mobileip-ipv6-13.txt[1], RFC3031[8], RFC3036[9]. 7. References [1] D. Johnson, Mobility Support in IPv6, draft-ietf-mobileip-ipv6- 13.txt, November, 2000. [2] Choi, Extension of LDP for Mobile IP Service through the MPLS Network, draft-choi-mobileip-ldpext-00.txt, December, 2000. [3] R, Zhong, Integration of Mobile IP and MPLS, draft-zhong-mobile- ip-mpls-01.txt July, 2000. [4] H. Chaskar, Framework for QoS Support in Mobile IPv6, draft- chaskar-mobileip-qos-00.txt, 2000 [5] P. Ashwood, Generalized MPLS - Signaling Functional Description, draft-ietf-mpls-generalized-signaling-00.txt, October, 2000. [6] Thomas Narten, Erik Nordmark, Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, December, 1998. [7] S. Thomson and T. Narten, IPv6 Stateless Address Autoconfiguration, RFC 2462, 1998. [8] E. Rosen, Multiprotocol Label Switching Architecture, RFC3031, January, 2001. [9] L. Andersson, LDP Specification, RFC3036, January, 2001. 8. Author's Addresses Jun Kyun Choi Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yusong, Taejon Korea 305-732 Phone: +82-42-866-6122 Email: jkchoi@icu.ac.kr Myoung Hun Kim Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yusong, Taejon Korea 305-732 Phone: +82-42-866-6198 Choi, et al. Expires October 2001 [page 8] Internet Draft draft-choi-mobileip-ipv6-mpls-00.txt October 2001 Email: fiaa@icu.ac.kr Tai Won Um Information and Communications University (ICU) 58-4 Hwa Ahm Dong, Yusong, Taejon Korea 305-732 Phone: +82-42-866-6198 Email: twum@icu.ac.kr Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Choi, et al. Expires October 2001 [page 9]