Network Working Group Zhong Ren Internet Draft NUS Expiration Date: December 2000 Chen-Khong Tham NUS Chun-Choong Foo NUS Chi-Chung Ko NUS July 2000 The Integration of Mobile IP and MPLS draft-ietf-mobile-ip-mpls-00.txt Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Zhong, et al. [Page 1] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 Abstract Multiprotocol Label Switching (MPLS) combines the efficiency and simplicity of IP routing together with the high-speed switching of ATM. Mobile IP is a protocol that allows mobile users to maintain continuous IP network connectivity. In this document, we propose a scheme to integrate both the Mobile IP and MPLS protocols. The integration of both these protocols improves the scalability of the Mobile IP data forwarding process by leveraging on the features of MPLS which are fast switching, small state maintenance and high scalability. In addition, we have removed the need for IP-in-IP tunneling from HA to FA under this scheme. This document covers some issues regarding Mobile IP scalability and also defines the signaling and control mechanisms required to integrate MPLS and Mobile IP. Contents 1 Introduction ........................................... 3 2 Single Domain Integration Scheme ....................... 4 2.1 Architectural Overview ................................. 4 2.2 Registration Procedure ................................. 5 2.3 Datagram Delivery Procedure ............................. 6 2.4 Multiple Foreign Agents ................................ 7 2.5 Mobile Node Homing ..................................... 8 2.6 Multiple Correspondent Nodes ........................... 9 3 Multiple Domains Integration Scheme .................... 10 3.1 Multiple MPLS Domains .................................. 10 3.2 An IP Cloud in Between ................................. 11 3.3 Scheme Implication ..................................... 12 4 References ............................................. 13 5 Author's Addresses ..................................... 13 Zhong, et al. [Page 2] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 1. Introduction MPLS is a packet forwarding scheme [1]. A label-switched router (LSR) examines only the label when forwarding the packet and the IP packet header analysis is done only once when the packet enters the network. Since labels have only local significance between two adjacent LSRs on a route, MPLS has high scalability. Moreover, the local significance makes it almost impossible to run out of labels. This characteristic is essential to implementing advanced IP services such as QoS and traffic engineering. Mobile IP is a mobile version of existing IP for supporting mobile computing over the Internet [2]. It is designed to serve the mobile users who wish to connect to the Internet and maintain communications as they move around. Mobile IP is based on the idea of encapsulation and use of a home agent to forward packets from a mobile host's original location to its current location. The operation of Mobile IP involves three different activities, which are the agent advertisement process, the registration process and the data forwarding process. It is crucial that these three different activities operate efficiently in order for the Mobile IP protocol to be scalable to systems consisting of huge numbers of mobile hosts. The data forwarding process of a Mobile IP Home Agent (HA) involves the IP tunnelling operations. That means the HA needs to search the IP routing table twice to tunnel the packet out. The amount of processing required by the HA in this data forwarding process depends on the number of Mobile Nodes (MNs) belonging to the home network that are currently registered in a foreign network. If there are many such kind of MNs, the forwarding process will take very long. Considering that every packet forwarded by the HA has to undergo this forwarding process, the overhead of this packet forwarding process may be too much even after optimizing the matching process through the use of appropriate data structures and lookup algorithms. This poses a scalability concern that affects the use of the Mobile IP protocol in future wireless mobile systems. Currently there are proposals to incorporate IP-based technologies into the core networks of future wireless cellular systems such as Universal Mobile Telecommunications System (UMTS), Iceberg Project and Cellular IP. Mobile IP could potentially provide host mobility solution in these future networks. Since the number of users and terminals connected to these future systems would be very huge, the scalability of the Mobile IP solution is of great concern and interest. There have also been work in integrating ATM as the transport provider into these core networks. Since MPLS and ATM are Zhong, et al. [Page 3] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 very closely related, it could be desirable to incorporate MPLS into these core network too. Our proposal here integrates both the Mobile IP and MPLS solutions together, allowing both these technologies to Work together in the future core networks, and also provide mobility support for MPLS. The purpose of this document is to propose a scheme to integrate both the Mobile IP and MPLS protocols. The integration of both these protocols improves the scalability of the Mobile IP data forwarding process by leveraging on the features of MPLS which are fast switching, small state maintenance and high scalability. In addition, we have removed the need for IP-in-IP tunneling from HA to FA under this scheme. Our proposal here paves the way for the use and incorporation of both the Mobile IP and MPLS protocols into these future IP-based core networks. 2. Single Domain Integration Scheme 2.1. Architectural Overview The single domain architecture is shown in Figure 1. HA and Foreign Agent (FA) are edge LSRs and belong to the same MPLS domain. They support both MPLS and Mobile IP functionality. LSR1 is the ingress LSR and Correspondent Node (CN) sends packet to MN. LSR2 is an intermediate LSR. We assume that the MN home address is a.b.c.d and the HA address is a.b.c.e. In addition, we assume that FA Care-of-address (COA) is x.y.w.z. -------------------------------------- +----+ | +------+ +------+ +----+ | +----+ | MN |--|---| LSR1 |----| LSR2 |-----| FA |--|----| MN | +----+ | |------| +------+ +----+ | +----+ | \ | | \ | | \ | | \ +----+ 2| | 1\| HA |--|-- | +----+ | | | | MPLS Network | -------------------------------------- Figure 1. Single Domain Architecture Zhong, et al. [Page 4] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 2.2. Registration Procedure MN determines whether it is at home or in a foreign network when it receives agent advertisement messages broadcast by the mobility agents. If the MN determines that it is in a foreign network, the MN acquires a temporary COA from FA and sends registration request to FA. Since FA is an edge LSR, it will analyze the incoming registration request message and get the destination address of the request. Then FA updates its routing table and adds a host specific row with the value of MN home address. In addition, it sets the outgoing port value of this entry to be the incoming port number from which it received the registration request. Based on the IP routing table, FA forwards the registration request message toward HA. The packet is forwarded to HA hop-by-hop using normal IP routing. When HA gets the registration request message and learns the COA, it searches its label table to find the row with the MN home address as Forwarding Equivalence Class (FEC). The second row in Table 1 is that one. Then, it will send a label request using Label Distribution Protocol (LDP) [3] to FA with the COA as FEC. FA replies with an LDP label mapping message to HA. When this label mapping message arrives at HA, the LSP would have been established (the first row in Table 1 is created by LDP). In the case of the topology-driven scheme, the best effort LSPs from FA to HA and from HA to FA would have already been established using conventional IP routing. So, for best effort traffic, we can use that best effort LSP in order to reduce the registration time. After that, HA changes the row in its label table that uses the MN home address as FEC. It sets the empty out label and outgoing port entries to the values of out label and outgoing port of the LSP from HA to FA. In this way, HA can relay the packets destined to MN home address to its current location in the foreign network. Finally, HA sends a registration reply to FA along the LSP from HA to FA. When FA receives the registration reply, it records the incoming port number and in label value of the reply message. Then it adds a new row in its label table. Table 2 illustrates the example label table of FA after receiving the registration reply message. Table 1 is an example label table of HA after registration. In the architecture shown in Figure 1, the FA COA is x.y.w.z and MN home address is a.b.c.d. The out label value and outgoing port number of LSP from HA to FA are 5 and 1 respectively. The first row of Table 1 is the label binding for the LSP from HA to FA mentioned above. Since HA is the ingress LSR, the in label value entry is empty. The second row is the label binding for the LSP from CN to MN. Since HA is the egress LSR of this LSP, originally the outgoing port and out label Zhong, et al. [Page 5] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 entries are both empty. But HA has set these two entries to the values of out label and outgoing port of the LSP from HA to FA after receiving registration request. +----------+-------+---------+----------+-------+ | Incoming | In | FEC | Outgoing | Out | | Port | Label | | Port | Label | +----------+-------+---------+----------+-------+ | 2 | - | x.y.w.z | 1 | 5 | +----------+-------+---------+----------+-------+ | 1 | 9 | a.b.c.d | 1 | 5 | +----------+-------+---------+----------+-------+ | ... | ... | ... | ... | ... | +----------+-------+---------+----------+-------+ Table 1. Example Label Table of HA after registration Table 2 is an example label table of FA after receiving the registration reply. The port entry contains the port number from which it received the registration reply. The label entry contains the label value of the incoming registration reply. The FEC entry is the FA COA. And the outgoing port entry and the out label entry are empty. +----------+-------+---------+----------+-------+ | Incoming | In | FEC | Outgoing | Out | | Port | Label | | Port | Label | +----------+-------+---------+----------+-------+ | 1 | 7 | x.y.w.z | - | - | +----------+-------+---------+----------+-------+ | ... | ... | ... | ... | ... | +----------+-------+---------+----------+-------+ Table 2. Example Label Table of FA after Receiving Registration Reply 2.3. Datagram Delivery Procedure Packets from a CN to the MN are addressed to the MN home address. If the MN is located in a foreign network, packets are intercepted by the HA. HA uses the incoming label value as an index to look up its label table. According to Table 1, HA inserts the label value in the second row of the label table into packet and sends it out through Zhong, et al. [Page 6] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 the port indicated in the same row. If MN is still in the home network, then out label and outgoing port entries are empty. The packet will be sent to the IP layer and sent out from the port indicated in the corresponding routing table entry to MN. The packet is delivered from HA to FA along the LSP by label swapping. FA receives the packet and looks up its label table. Since it is the egress of the LSP from HA to FA and the out label and outgoing port entries are empty, FA strips off the label and sends the packet to the IP layer. Finally, FA forwards the packet to MN based on the information in the newly-added host specific row of the routing table. MN receives the packet sent by CN. As noted above, integrating MPLS and Mobile IP makes IP-in-IP tunneling unnecessary in the data forwarding process. Instead we use MPLS to switch the packet to the foreign network. Switching is much faster than conventional IP forwarding. The whole forwarding process is done at the MPLS layer and HA doesn't need to involve the IP layer in forwarding the packet to a mobile node. This improves the scalability of the Mobile IP protocol. In addition, since label header is much smaller than IP header, the traffic overhead from HA to FA is also reduced. Moreover, with Constraint-Based Label Distribution Protocol (CR-LDP) [4] we can setup an LSP satisfying the QoS requirements of the traffic and do traffic engineering [5]. 2.4. Multiple Foreign Agents ---------------------------------------- | +------+ | +----+ | /|New FA|---|---| MN | | / +------+ | +----+ | / | | / | +----+ | +------+ +------+ +------+ | | MN |--|---| LSR1 |----| LSR2 |-----|Old FA|--|---- +----+ | |------| +------+ +------+ | | \ | | \ | | \ +----+ 2 | | 1\| HA |-----|-- | +----+ | | | | MPLS Network | ---------------------------------------- Figure 2. Multiple Foreign Agents Architecture Zhong, et al. [Page 7] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 In this section, we describe the registration and data delivery schemes for MN movement from one FA to another FA. As shown in Figure 2, we assume that the IP address of the new FA COA is a.s.d.f. Once the MN moves to a new FA, the registration procedure described in the previous section is repeated once between the HA and new FA. After registration, there is a new row in Table 3. The third row is new: it is the label binding for the LSP from HA to new FA. The outgoing port number and out label value in the second row are changed to the corresponding values of the second one so that the packets destined to MN home address can be relayed to the new foreign network. At the New FA, it adds a host specific row with the value of MN home address in its routing table. +----------+-------+---------+----------+-------+ | Incoming | In | FEC | Outgoing | Out | | Port | Label | | Port | Label | +----------+-------+---------+----------+-------+ | 2 | - | x.y.w.z | 1 | 5 | +----------+-------+---------+----------+-------+ | 1 | 9 | a.b.c.d | 1 | 6 | +----------+-------+---------+----------+-------+ | 2 | - | a.s.d.f | 1 | 6 | +----------+-------+---------+----------+-------+ | ... | ... | ... | ... | ... | +----------+-------+---------+----------+-------+ Table 3. Example Label Table of HA after MN moves to a new foreign network Packets from a CN to the MN are intercepted by the HA. HA uses the incoming label value as an index to look up its label table. Then it inserts the label value in the second row of the label table into packet and sends it out from the port indicated in the same row. Packet is delivered from HA to new FA along the LSP by label swapping. New FA receives the packet and looks up its label table. Since it is the egress of the LSP from HA to new FA, HA strips off the label and sends the packet to the IP layer. Finally new FA forwards the packet to MN based on the information in the newly added host specific row of routing table. MN receives the packet sent by CN. 2.5. Mobile Node Homing This section we describe the registration and data delivery schemes Zhong, et al. [Page 8] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 for MN movement from the foreign network back to its home network. MN finds it is back to home network after receiving agent advertisement messages broadcast by its home agent. It sends a deregistration request message to the home agent with registration lifetime field equal to zero. The COA in this message is the COA of the HA. HA deletes the out label value and outgoing port number from the second row of its label table that are added during the last registration with the FA. As illustrated in Table 4, these two entries are left empty. The first row is the label binding for the LSP from HA to FA and the second one is the label binding for the LSP from CN to HA. When packets destined to MN home address arrive at HA, it strips off the label and sends the packets to the IP layer. Then it searches the IP routing table to find the MN home address entry. The packets will be sent out to MN based directly on the information in the routing table. MN receives the packet sent by CN. +----------+-------+---------+----------+-------+ | Incoming | In | FEC | Outgoing | Out | | Port | Label | | Port | Label | +----------+-------+---------+----------+-------+ | 2 | - | x.y.w.z | 1 | 5 | +----------+-------+---------+----------+-------+ | 1 | 9 | a.b.c.d | - | - | +----------+-------+---------+----------+-------+ | ... | ... | ... | ... | ... | +----------+-------+---------+----------+-------+ Table 4. Example Label Table of HA after MN Moves back to Home Network 2.6. Multiple Correspondent Nodes If there are multiple CNs communicating with MN, once the MN moves from its home network to a foreign network, all traffic from those CNs need to be relayed to the current location of MN. In best effort case, the registration procedure is the same as the procedure in the case of one CN. The sample label table of HA after registration is illustrated in Table 5. The first row is the label binding for the LSP from HA to FA. The second, third and fourth rows are the label bindings for the LSPs from each CN to HA. Outgoing port and out label in these three rows have been set to the out label value and outgoing port number of the first row. So packets arriving along these three LSPs are all sent out from the same port with the Zhong, et al. [Page 9] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 same label value to foreign network. That is, all packets arriving with the MN home address as destination address will be sent out from port 1 with label value 5. +----------+-------+---------+----------+-------+ | Incoming | In | FEC | Outgoing | Out | | Port | Label | | Port | Label | +----------+-------+---------+----------+-------+ | 2 | - | x.y.w.z | 1 | 5 | +----------+-------+---------+----------+-------+ | 1 | 9 | a.b.c.d | 1 | 5 | +----------+-------+---------+----------+-------+ | 1 | 8 | a.b.c.d | 1 | 5 | +----------+-------+---------+----------+-------+ | 1 | 7 | a.b.c.d | 1 | 5 | +----------+-------+---------+----------+-------+ | ... | ... | ... | ... | ... | +----------+-------+---------+----------+-------+ Table 5. Example Label Table of HA after Registration in Multiple CN Case If the traffic from different CNs have different QoS requirements, HA needs to establish a new LSP from HA to FA for each class of service. That means that HA must know the number of classes of service of the traffic destined to MN home address. When packets arrive at HA, it needs to classify the packets to identify its class of service and destination. Then, HA maps them to the corresponding LSP based on the combination of class of service and destination address of the packets. Using such mechanism, we can support differentiated services in MPLS networks [6]. 3. Multiple Domains Integration Scheme Multiple domain connectivity needs to be considered in our scheme as there is a possibility of mobile nodes crossing from its home domain into other domains. There are some specific requirements on the border routers of these domains depending on the nature of the inter-domain connections as described in the following subsections. 3.1. Multiple MPLS Domains In the architecture shown in Figure 3, HA and FA are edge LSRs and Zhong, et al. [Page 10] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 belong to two different MPLS domains which are directly connected. They support both MPLS and Mobile IP functionality. --------------------------- ------------------ | | | | | | | | +----+ | +----+ +----+ | | +----+ +--+ | +--+ | MN |--|--|LSR1|---|LSR2|--------|--|-|LSR3|---|FA|--|--|MN| +----+ | |----| +----+ | | +----+ +--+ | +--+ | \ | | MPLS Network 2| | \ +--+ | ------------------ | \|HA|-|-- | +--+ | | MPLS Network 1 | --------------------------- Figure 3. Multiple MPLS Domains Architecture Here the two edge LSRs(LSR2 and LSR3) are LDP Border Gateway Protocol (BGP) peers. That means they can exchange label information between them. So in this case, we can establish a LSP from HA to FA across the link connecting these two different MPLS domains. Our registration and data delivery schemes described in previous sections can be used here without any modification. 3.2. An IP Cloud in Between ------------------------ ---------- ---------------- | MPLS Network 1 | | IP | | | | | | Cloud | | | +----+ | +----+ +----+ | | +----+ | | +----+ +--+ | +--+ | MN |--|--|LSR1|---|LSR2|-----|--|-|LSR3|-|--|-|LSR4|--|FA|-|--|MN| +----+ | |----| +----+ | | +----+ | | +----+--+--+ | +--+ | | | | | | | | | | | | | | | | | +--+ | | +--+ | |MPLS Network 2| | |HA| | | |FA| | | | | +--+ | | +--+ | | | --------------|--------- -----|---- ---------------- | | +--+ |MN| +--+ Figure 4. Multiple MPLS Domains Architecture Zhong, et al. [Page 11] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 When there is an IP cloud between the HA domain and the FA, an IP tunnel is needed to carry the data packets to the FA. In this case, LSR3 will act as an interchange between the LSP and the IP tunnel, acting as the FA from the viewpoint of the HA. Here the hierarchical FA management scheme can be a solution [7]. Slight modification can be made if the FA is in a MPLS domain. The IP tunnel can be terminated at LSR4. A LSP will continue the data forwarding task from LSR4 to the FA. This modification requires LSR4 to be Mobile IP enabled. In this case, the performance of the proposed scheme become worse than all previous cases. But it's still better than conventional Mobile IP. Anyway we shorten the IP tunnel. Since switching is faster than conventional IP forwarding, the transmission delay is improved. 3.3. Scheme Implication There are still some other different multiple domain cases. But they all belong to the above two situations. Here the key of different inter domain connectivity is whether the HA packet processing needs to go up to the IP layer. If it does, then IP tunneling has to be used to extend the LSP to FA. The performance of our integration scheme become worse compared to the pure MPLS domain case. So we assume each Internet Service Provider (ISP) network is a MPLS domain. This requirement is not demanding. Currently Virtual Private Network (VPN) is a hot technology and all ISPs are very interested in providing this service. There have been several internet drafts [8] [9] about how to implement VPN with MPLS since MPLS has some features that are very useful to VPN. The schemes proposed in these drafts also assume the ISP network is a MPLS capable network and BGP is used to distribute the routing information across domains. This is quite similar to the requirement of our multiple MPLS domains case. So if the backbone networks of all ISPs are MPLS capable networks, our integration scheme can be expanded to multiple domains without any modification and any performance deterioration. Zhong, et al. [Page 12] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 4. References [1] E.Rosen, A. Viswanathan, R. Callon, et al., Multiprotocol Label Switching Architecture, Internet Draft, draft-ietf-mpls-arch-06 .txt, Aug. 1999. [2] C. Perkins, IPv4 Mobility Support, RFC 2002, Oct. 1996. [3] L. Andersson, P. Doolan, N. Feldman, Fredette, B.Thomas, et al., Label Distribution Protocol, Internet Draft, draft-ietf-mpls-ldp -06.txt, Oct. 1999. [4] L. Andersson, A. Fredette, B. Jamoussi, R.Callon, P. Doolan, et al., Constraint-Based LSP Setup using LDP, Internet Draft, draft-ietf-mpls-cr-ldp-03.txt, Sept. 1999. [5] D. Awduche, J. Malcolm, J. Agogbua, et al., Requirements for Traffic Engineering Over MPLS, RFC 2702, Sept. 1999. [6] J. Heinanen , Differentiated Services in MPLS Networks, Internet Draft, draft-heinanen-diffserv-mpls-00.txt, Jun. 1999. [7] Charles E. Perkins, Mobile-IP Local Registration with Hierarchical Foreign Agents, Internet Draft, Feb. 1996. [8] D. Jamieson, B. Jamoussi, G. Wright, P. Beaubien, MPLS VPN Architecture, Internet Draft, draft-jamieson-mpls-vpn-00.txt, Aug. 1998. [9] E.C. Rosen, Y. Rekhter, S.J. Brannon, et al., BGP/MPLS VPNs, Internet Draft, draft-rosen-rfc2547bis-00.txt, Mar 2000. 5. Author's Addresses Zhong Ren National University of Singapore 10 Kent Ridge Crescent Singapore 119260 E-mail: engp9021@nus.edu.sg Zhong, et al. [Page 13] Internet Draft draft-ietf-mobile-ip-mpls-00.txt July 2000 Chen-Khong Tham National University of Singapore 10 Kent Ridge Crescent Singapore 119260 E-mail: eletck@nus.edu.sg Chun-Choong Foo National University of Singapore 10 Kent Ridge Crescent Singapore 119260 E-mail: engp7643@nus.edu.sg Chi-Chung Ko National University of Singapore 10 Kent Ridge Crescent Singapore 119260 E-mail: elekocc@nus.edu.sg Zhong, et al. [Page 14]