Internet Draft
Network Working Group                                        Zhong Ren
Internet Draft                                               NUS
Expiration Date: January 2001
                                                        Chen-Khong Tham
                                                             NUS

                                                        Chun-Choong Foo
                                                             NUS

                                                           Chi-Chung Ko
                                                             NUS

                                                              July 2000



                      Integration of Mobile IP and MPLS


                      draft-zhong-mobile-ip-mpls-01.txt

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.











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 describe
   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 Home Agent (HA) to Foreign Agent (FA) under this
   scheme. This document 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  .................................   4
    2.3    Datagram Delivery Procedure .............................   6
    2.4    MN Moves from One FA to Another  ........................   7
    2.5    MN Moves Back Home  .....................................   8
    3      Multiple Domains Integration Scheme  ....................   9
    3.1    Multiple MPLS Domains  ..................................   9
    3.2    An IP Cloud in Between  .................................  10
    3.3    Implication of Schemes  .................................  11
    4      Experiment Results  .....................................  11
    4.1    Processing Delay at HA  .................................  12
    4.2    TCP Performance  ........................................  13
    4.3    Round-trip Delay  .......................................  13  
    5      Conclusion  .............................................  14 
    6      Security Consideration  .................................  14        
    7      References  .............................................  14
    8      Author's Addresses  .....................................  15










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. 
 
   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 large 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 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
   high 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
   [3] and Cellular IP [4]. 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 large,
   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
   very closely related, it would be desirable to incorporate MPLS into
   these core networks too. Our proposal here integrates both the Mobile 
   IP and MPLS solutions together, allowing both these technologies to




Zhong, et al.                                                   [Page 3]


Internet Draft        draft-ietf-mobile-ip-mpls-00.txt         July 2000


   
   work together in the future core networks, and also provide mobility
   support for MPLS. 
   The purpose of this document is to describe 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 the 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 w.x.y.z.



		   --------------------------------------
       +----+  |   +------+    +------+     +----+  |    +----+    
       | CN |--|---| LSR1 |----| LSR2 |-----| FA |--|----| MN |
       +----+  |   |------|    +------+     +----+  |    +----+
               |                       \   	    |
               |                        \           |
               |                         \          | 
               |                          \ +----+ 2|  
               |                          1\| HA |--|--
 	       |			    +----+  |  
 	       |				    |	
 	       |            MPLS Network  	    |
	       --------------------------------------

			Figure 1. Single Domain Architecture


2.2. Registration Procedure




Zhong, et al.                                                   [Page 4]


Internet Draft        draft-ietf-mobile-ip-mpls-00.txt         July 2000



   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 a 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 request message 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). This is shown in the
   second row in Table 1. Then, it will send a label request using Label 
   Distribution Protocol (LDP) [5] 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 w.x.y.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
   entries are both empty. But HA will set these two entries to the
   values of out label and outgoing port of the LSP from HA to FA after 



Zhong, et al.                                                   [Page 5]


Internet Draft        draft-ietf-mobile-ip-mpls-00.txt         July 2000

   
 
   receiving the registration request.

 
    		+----------+-------+---------+----------+-------+
    		| Incoming |  In   |   FEC   | Outgoing |  Out  |
    		|   Port   | Label |         |   Port   | Label |
    		+----------+-------+---------+----------+-------+
    		|    2     |   -   | w.x.y.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   | w.x.y.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
   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 



Zhong, et al.                                                   [Page 6]


Internet Draft        draft-ietf-mobile-ip-mpls-00.txt         July 2000


 
   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 all the way from the
   first ingress LSR to the HA to the FA. 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) [6] we can setup an LSP satisfying the QoS requirements of
   the traffic and do traffic engineering [7].


2.4. MN Moves from One FA to Another
 
	       ----------------------------------------
	       |			   +------+   |   +----+
	       |			  /|New FA|---|---| MN |
	       |	                 / +------+   |   +----+
	       |			/             |
               |                       /              |
       +----+  |   +------+    +------+     +------+  | 
       | CN |--|---| 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     |   -   | w.x.y.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. MN Moves Back Home

   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     |   -   | w.x.y.z |    1     |   5   |
    		+----------+-------+---------+----------+-------+
    		|    1     |   9   | a.b.c.d |    -     |   -   |
    		+----------+-------+---------+----------+-------+
		|   ...    |  ...  |   ...   |   ...    |  ...  |
    		+----------+-------+---------+----------+-------+

		   Table 4. Example Label Table of HA after 
	               MN Moves back to Home Network


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
   belong to two different MPLS domains which are directly connected.
   They support both MPLS and Mobile IP functionality.



Zhong, et al.                                                  [Page 9]


Internet Draft        draft-ietf-mobile-ip-mpls-00.txt         July 2000



             ---------------------------  ------------------
	     |			       |  |		   |	
             |                         |  |		   |	
     +----+  |  +----+   +----+        |  | +----+   +--+  |  +--+
     | CN |--|--|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 |  |		  |
     +----+  |  +----+   +----+     |  | +----+ |  | +----+  +--+ |  +--+
     | CN |--|--|LSR1|---|LSR2|-----|--|-| R1 |-|--|-|LSR3|--|FA|-|--|MN|
     +----+  |  |----|   +----+     |  | +----+ |  | +----+  +--+ |  +--+  
             |             |        |  |    |   |  |              |
	     |             |        |  |    |   |  |		  |
             |            +--+      |  |   +--+ |  |MPLS Network 2|	
 	     |		  |HA|      |  |   |FA| |  |		  |
	     |            +--+      |  |   +--+ |  |		  |
	     --------------|---------  -----|----  ----------------  
		 	   |		    |
					   +--+
					   |MN|
					   +--+	

		         Figure 4. An IP Cloud in Between

   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,



Zhong, et al.                                                  [Page 10]


Internet Draft        draft-ietf-mobile-ip-mpls-00.txt         July 2000


 
   LSR2 will act as an interchange between the LSP and the IP tunnel,
   acting as the FA from the viewpoint of the HA. Packet is switched
   from the HA to LSR2 and tunnelled from LSR2 to the FA. Here the
   hierarchical FA management scheme can be a solution [9], where every
   edge router has to be a hierarchical FA. Slight modification can be
   made if the FA is in a MPLS domain. The IP tunnel can be terminated
   at LSR3. A LSP will continue the data forwarding task from LSR3 to
   the FA. This modification requires LSR3 to be Mobile IP enabled.

   In this case, the performance of the proposed scheme become worse
   than all previous cases. But it is still better than conventional
   Mobile IP. In any case, the IP tunnel is shorten in the proposed
   scheme. Since switching is faster than conventional IP forwarding,
   the transmission delay is improved.


3.3. Implication of Schemes

   We have considered the case where the whole network in question is a
   single MPLS domain, multiple MPLS domains and the case where there
   are non-MPLS clouds present. There are still some other different
   multiple domain cases. But they all belong to the two situations
   described above. 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 tunnelling has to be used to tunnel the packet to
   the FA. Our scheme works in all these possible cases. However, our
   scheme works best in the case where the whole network is MPLS
   capable, the scalability performance benefits are offset in the other
   cases.

4. Experiment Results
 
   To evaluate the MPLS and Mobile IP integration scheme performance, we
   built a testbed and designed a set of experiments to analyze the
   scheme. In what follows we describe our MPLS and Mobile IP
   integration testbed and experimental results.

   The goal of the experiments is to evaluate the performance of the
   MPLS and Mobile IP integration. The single domain case has been
   implemented and evaluated on Linux 2.3.30 software platform. The
   testbed consists of four PC routers based on multi-homed 133MHz
   Pentium PCs hardware. They are CN, HA, FA and one intermediate LSR
   between HA and FA respectively. All of them are interconnected using
   100Mbps full duplex links. MN is a 133 MHz Pentium PC. HA and FA runs
   Mobile IP implementation in user space. The MPLS switching function
   Is implemented in Linux kernel.




Zhong, et al.                                                  [Page 11]


Internet Draft        draft-ietf-mobile-ip-mpls-00.txt         July 2000



                 +----+            +-----+
                 | CN |            | LSR |
                 +----+		   +-----+
                   |                  |
		   |     Ethernet     |
	          -------------------------
		   |		      |
		   |		      |
	         +----+		   +----+       +----+
 	         | HA |	           | FA |-------| MN |
	         +----+	           +----+       +----+

			  Figure 5. Testbed


4.1. Processing Delay at HA

   During this experiment, we increase the routing and label table size
   from 5 entries to 8000 entries. The measurements are showed in Table
   5. Each result in the table was obtained by averaging 50 consecutive
   measurements. From the results in Table 5 we can find that the HA
   processing delays in Mobile IP and Mobile IP over MPLS schemes
   increase with the increasing routing table size. But in the 
   MPLS-Mobile IP integration scheme, the HA processing delay is almost
   constant. It is much lower than the values in Mobile IP and Mobile IP
   over MPLS schemes. The lower value is the result of having the entire
   HA data forwarding process executed in the MPLS layer after Mobile IP
   and MPLS are integrated. So no IP routing table search is executed.
   Since label table search is much faster than longest-bit-matching
   routing table search and IP tunneling needs to search routing table
   twice, much processing time is saved and HA performance is much
   improved. We also can find that Mobile IP over MPLS has poorer
   performance than pure Mobile IP. This is caused by the additional
   processing at MPLS layer before the packet goes up to the IP layer.


         +---------------+----+----+---+---+---+----+----+----+----+
         |Num. Of Entries| 50 | 80 |100|200|500|1000|2000|4000|8000|
    	 +---------------+----+----+---+---+---+----+----+----+----+
    	 |Pure Mobile IP | 272| 273|276|282|296| 315| 336| 379| 450|
    	 +---------------+----+----+---+---+---+----+----+----+----+
    	 | MIP over MPLS | 346| 348|350|357|370| 389| 411| 452| 525|
    	 +---------------+----+----+---+---+---+----+----+----+----+
	 |   MIP-MPLS    | 46 | 45 | 47| 46| 47| 48 | 45 | 46 | 47 |
    	 +---------------+----+----+---+---+---+----+----+----+----+

	     Table 5. HA Performances of Different Schemes (usec)



Zhong, et al.                                                  [Page 12]


Internet Draft        draft-ietf-mobile-ip-mpls-00.txt         July 2000



4.2. TCP Performance

   In this experiment, we study the impact of the number of table
   entries on Mobile IP forwarding scalability. We also increase the
   routing and label table size from 5 entries to 8000 entries. We
   measure TCP throughput using ttcp by downloading data from CN to MN.
   Each result is an average of 5 independent measurements. From the
   values in Table 6, we can find that the TCP throughput in Mobile IP
   scheme drops with the increasing routing table size. In MIP-MPLS
   integration scheme, the throughput is constant. The reason for this
   phenomenon is as explained in the last experiment.

         +---------------+-----+-----+-----+-----+-----+-----+-----+
         |Num. Of Entries| 10  | 100 | 500 | 1000| 2000| 4000| 8000|
    	 +---------------+-----+-----+-----+-----+-----+-----+-----+
    	 |Pure Mobile IP | 468 | 467 |465.5|463.5| 461 | 458 | 454 | 
    	 +---------------+-----+-----+-----+-----+-----+-----+-----+
	 |   MIP-MPLS    |481.5|481.6|481.5|481.7|481.4|481.5|481.5|
    	 +---------------+-----+-----+-----+-----+-----+-----+-----+

	 Table 6. TCP Performances of Different Schemes (KBytes/sec)


4.3. Round-trip Delay

   In this experiment, we measure the roundtrip delay. We also increase
   the routing and label table size from 5 entries to 8000 entries. We
   measure the roundtrip delay using ping from CN to MN. We set the
   packet size as 1000 bytes. Each result is an average of 20 
   consecutive measurements. From the values in Table 7, we can find
   that the round-trip delay in Mobile IP scheme increases with the
   increasing routing table size. In MIP-MPLS integration scheme, the
   delay is constant. The reason for this phenomenon is as explained in
   the first experiment. In addition to the HA performance improvement,
   it also benefits from fast switching because packet is label switched
   along the whole path from CN to FA and back to CN.


         +---------------+-----+-----+-----+-----+-----+-----+-----+
         |Num. Of Entries| 10  | 100 | 500 | 1000| 2000| 4000| 8000|
    	 +---------------+-----+-----+-----+-----+-----+-----+-----+
    	 |Pure Mobile IP | 12.4| 12.4| 12.5| 12.6| 12.7| 12.9| 13.2| 
    	 +---------------+-----+-----+-----+-----+-----+-----+-----+
	 |   MIP-MPLS    | 12.1| 12.1| 12.1| 12.1| 12.1| 12.1| 12.1|
    	 +---------------+-----+-----+-----+-----+-----+-----+-----+

	    Table 7. Round-trip Delay of Different Schemes (msec)



Zhong, et al.                                                  [Page 13]


Internet Draft        draft-ietf-mobile-ip-mpls-00.txt         July 2000



5. Conclusion

   We have proposed a scheme to integrate Mobile IP and MPLS. This
   integration makes IP-in-IP tunneling in the data forwarding process
   unnecessary. Instead we use MPLS to switch the packet from the HA to
   the foreign network. Switching is much faster than conventional IP
   forwarding, so the transmission delay and packet processing overhead
   is reduced. The whole forwarding process is done at the MPLS layer
   and HA doesn't need to go up to the IP layer to do the IP tunneling.
   So the scalability of Mobile IP is much improved. In addition, since
   label header is much smaller than IP header, the traffic overhead

   from HA to FA is also reduced. Preliminary experimental results using
   an implementation of our looks very promising, giving much better
   performance than a normal MIP case.


6. Security Consideration

   The Mobile IP and MPLS integration scheme described in this memo is
   subject to the same security considerations that apply to RFC2002,
   draft-ietf-mpls-framework-05.txt, draft-ietf-mpls-arch-06.txt and 
   draft-ietf-mpls-ldp-07.txt.



7. 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] Randy H. Katz, et al., ICEBERG: An Internet-core Network
	 Architecture for Integrated Communications, IEEE Personal
	 Communication.

   [4] Andrew T. Campbell, Javier Gomez, Andras G. Valko, An Overview
	 of Cellular IP, IEEE Wireless Communications and Networking 
	 Conference, New Orleans, Sept. 1999.

   [5] L. Andersson, P. Doolan, N. Feldman, Fredette, B.Thomas, et al.,
       Label Distribution Protocol, Internet Draft, draft-ietf-mpls-ldp
       -06.txt, Oct. 1999.




Zhong, et al.                                                  [Page 14]


Internet Draft        draft-ietf-mobile-ip-mpls-00.txt         July 2000



[6] 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.

[7] D. Awduche, J. Malcolm, J. Agogbua, et al., Requirements for
       Traffic Engineering Over MPLS, RFC 2702, Sept. 1999.

[8] J. Heinanen , Differentiated Services in MPLS Networks, Internet
       Draft, draft-heinanen-diffserv-mpls-00.txt, Jun. 1999.

[9] Charles E. Perkins, Mobile-IP Local Registration with 
       Hierarchical Foreign Agents, Internet Draft, Feb. 1996. 


8. Author's Addresses


   Zhong Ren
   National University of Singapore
   10 Kent Ridge Crescent 
   Singapore 119260 

   E-mail: engp9021@nus.edu.sg

   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 15]