Mobile IP Working Group Shaji Radhakrishnan Internet Draft Yingchun Xu September, 2001 Ellis Wong WaterCove Networks Mobile IP Generic Label Distribution Extensions 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 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 obsolete by other documents at anytime. 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 is regarding extended label distribution method using Mobile IP registration and binding protocols. The document specifies a novel method in which the label mapping information for a particular mobile registration is piggybacked or placed in the same Mobile IP registration request and response message. To apply this same method to the route optimization protocol in Mobile IP, the label mapping information is piggybacked or placed in the binding update request message. The label mapping information is carried using Mobile IP registration extensions. The document also addresses the applicability of this label distribution method in GRE, MPLS and IPv6 networks. 1. Introduction Mobile IP facilitates mobility of nodes that move from one network to another network without changing the IP address of the node. When mobile node moves to a foreign network, a router in the foreign network, named as the foreign agent (FA), provides the routing capability to the mobile node. The router in its home network, named Radhakrishnan & Xu & Wong Expires Feb. 2002 1 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 as the home agent (HA), intercepts the topologically routed packets destined for the mobile node (MN) and tunnels them to the mobile node. The Home Agent uses a binding entry to find the end point of the tunnel. The tunnel end point could be the Mobile Node itself (when using co-located care-of-address) or the Foreign Agent (when using the care-of-address of the Foreign Agent). When the MN moves to a foreign network, it registers its current point of attachment with the HA so that HA can correctly deliver the packets to the MN. The registration procedure is done using a Mobile IP registration request and reply message exchange. The MN sends a registration request message containing itÆs care-of-address to the HA. Up on receiving the registration request, the HA updates its binding list entry (which is an association of MN home address and its care-of-address) and sends a successful registration reply message back to the MN. Packets sent by the Correspondent Node (the node with which the mobile node is communicating) will always get topologically routed to the HA and the HA refers to the binding cache list to obtain forwarding information for sending packets to the MN. This could be avoided by updating the binding cache in the Correspondent Node (CN) or the router to which the CN is connected, with the new care-of- address of the MN. In this way the CN can send packets directly to the MN using the binding cache. In order to facilitate this, the HA should send a binding update to the CN or the attached router. This is the route optimization technique. The table lookup function performed in every network node based on the destination IP address and other parameters, in conventional IP routing implementations is computationally a very expensive and complex operation. This has led to the introduction of MPLS in IP networks. The main concept behind MPLS is to append fixed-length labels on each packet to be forwarded by a network node. The label summarizes all the forwarding information about how to forward the packet on each next hop along the path towards a destination. Forwarding decisions based on a combination of different sources of information can be achieved with a single table lookup from a fixed- length label, resulting in a much more efficient and feasible forwarding operation. All other MPLS nodes which forward this packet always look up the label and then forward the packet to the next hop by inserting another appropriate label. The label, which has to be placed along with the packet when the packet is forwarded, is distributed using label distribution protocols, such as LDP. Other protocols, such as BGP4, PIM and RSVP, can be used to piggyback the label. This explained method is concerned with forwarding packets between adjacent nodes. In certain cases, like VPNs, there will be forwarding requirements between nodes, which are not adjacent. Such nodes are known as explicit label distribution pair-nodes. In such cases, CRLDP and RSVP are used to explicitly setup a label switched path (LSP) [10][11] with constraints, to support traffic engineering, QoS, etc. Radhakrishnan & Xu & Wong Expires Feb. 2002 2 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 For Mobile IP networks, it is possible to set up an LSP between the Home agent and the mobile node care-of-address (foreign agent) (and between the correspondent node or the router to which it is connected and the mobile node care-of-address) using existing label distribution protocols [8][9]. These protocols talk about the label distribution only for the LSP tunnel between HA and FA. However, for the explicit label distribution for the mobile node connections, these protocols require a separate invocation and control processing step to be taken after the Mobile IP registration process is completed. This sequential processing dependency introduces additional overhead and is vulnerable to errant generation of inconsistent forwarding information due to the dynamic mobility of routing destinations in a Mobile IP network environment. In this document, we describe an explicit label distribution method using Mobile IP protocol. The advantages of using this protocol are: (1) Improve the scalability of Mobile IP networks by simplifying the data forwarding process leveraging on the features of MPLS, such as fast switching and small state maintenance. (2) Synchronize label switch path set up with Mobile Node registration process. (3) Simplify control state machine by eliminating a separate signaling protocol transaction to establish label switch path. MPLS is not the only mechanism which can carry labeled packets. GRE and Ipv6 packets can also carry labels. GRE packets has a 32-bit session key to carry the labels. Ipv6 flow-labels or destination headers options can carry labels. We also discuss the applicability of label distribution and forwarding for GRE tunnels, IPv6 networks and MPLS networks. 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]. 2. Glossary FA Foreign Agent HA Home Agent MN Mobile Node CN Correspondent Node 3. Label assignment and applicability 3.1 Foreign Agent One of the key advantages presented here is an efficient label lookup and switching mechanism to select the outbound network interface and apply label information for forwarding data packets Radhakrishnan & Xu & Wong Expires Feb. 2002 3 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 along a path towards the mobile node when the foreign agent receives a packet from the Home Agent. This draft proposes the label switching approach instead of conventional IP packet forwarding approach based on the IP address and port lookup mechanism. The foreign agent could assign unique label to each mobile node and communicate the label information to the home agent or correspondent node while performing the mobile IP registration process. Specifically, foreign agent places a label extension field in the registration request message when forwarding to the home agent. The home agent or correspondent node could label the packet when forwarding data packets to the foreign agent; which could use the label for forwarding to the correct mobile node. The label is placed either as MPLS label, or GRE key field or IPv6 flow-label id or destination option, whichever is supported. If MPLS is supported on the path between the Mobile Node and the Foreign Agent, then MPLS label swapping can be used to switch traffic between these two systems. In this case, the foreign agent will be a custom LSR implementation having the capability of distributing explicit labels. If the network between mobile node and foreign agent is not MPLS capable, the label could be used to search for index of the network interface and route to be used to forward data packets to the mobile node using conventional IP routing method. In this case, foreign agent will be a LER having capability to pass this explicit label for finding mobile node interface. On the other hand, if GRE or Ipv6 data packet forwarding is used, foreign agent implementation should be able to pass the session key or label to the appropriate searching module for finding the mobile node interface. 3.2 Home Agent The home agent assigns a label for the MN and places it in the label extension field in the registration reply message when the HA receives a registration request message from the MN containing a label extension field. In reverse tunneling mode, the HA should distribute labels to each MN sessions. Two possible cases of label assignment distributed by the HA to each MN up on registration request are: (1) Home agent can apply QoS/IPSec/NAT policies to each of these mobile nodes. (2) Home agent can establish a L2TP session and bind it to each MN. In either case, Home agent can identify each of these mobile sessions using the label, which is present in the user traffic datagram header. The HA can also do label switching for the received packets from the FA, depending upon the network between HA and correspondent node. If MPLS is supported on the path between CN and HA, then MPLS label swapping can be used to switch traffic received Radhakrishnan & Xu & Wong Expires Feb. 2002 4 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 from FA. In this case, the home agent will be a custom LSR implementation having the capability of distributing explicit labels. If the network between CN and HA is not MPLS capable, the label could be used to search the session entry and associated route to be used to forward data packets to the correspondent node. In this case, home agent will be a LER having capability to pass this explicit label for finding the session entry and associated route. On the other hand, if GRE or Ipv6 data packet forwarding is used, home agent implementation should be able to pass the session key or label to the appropriate searching module for finding the session and route to forward the data to the correspondent node. 3.3 Correspondent node The scenario is used when route optimization is used in mobile IP. This case has still unresolved issues like security in sending binding updates to the correspondent node or router to which it is connected. The home agent can place the label extension (provided by the foreign agent in the registration request) in the binding registration entry, when sending a binding update to the correspondent node. The correspondent node can label the packet using the label present in the binding entry when forwarding any traffic to mobile node, in the same way that the home agent does when forwarding traffic to mobile node. 4. Label distribution using Mobile IP The mobile IP label distribution is done in registration request, registration reply and binding update. 4.1 Label extension The label extension in the mobile IP registration messages explained below. This extension is non-skippable. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |L|G|P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | Exp |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Identify the extension as a label (50 û to be assigned) Length: Length of this extension in bytes excluding Type and Length (i.e. this will be 6 bytes) L bit: This bit says that sender of this extension uses MPLS label Encoding. If this bit is set, the 32-bit label will be encode as 20bit label, Exp bits, S-bit, and TTL format. Radhakrishnan & Xu & Wong Expires Feb. 2002 5 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 G bit: This bit says that sender of this extension uses GRE session key for label encoding. If this bit is set, the label will be a 32-bit GRE session key. P bit: This bit says that sender of this extension uses Ipv6 destination option for label encoding. If this bit is set, the label will be in MPLS-label format. Reserved: These bits will be set to zero by the sender and ignored by the receiver. The below will be the fields when MPLS label encoding format is used. Label: Label Value, 20 bits Exp: Experimental Use, 3 bits S: Bottom of Stack, 1 bit TTL: Time To Live field The foreign agent should place the label extension after the fixed part of mobile Home extensions. The FA-HA authentication extension is placed after the label extension so that security is applied to label extension. Similarly, the Home agent should place the label extension after the Mobile-Home Authentication and before any HA-FA authentication extension. If æSÆ bit is set, normal MPLS label stacking is used. Home agent MUST place the same label extension, received in the registration request, in the registration reply. If home agent does so, the label extension assigned by the home agent MUST be placed after the label extension present in the request message. Placing the same label extension, present in the request, in the registration reply helps foreign agent to easily identify the pending registration entry. Different Type Values are assigned for each type of labels. 4.2 Label distribution by foreign agent Foreign agent assigns unique label to each of the mobile node connected. When foreign agent relays the registration request to the home agent, it places the label extension (with the label value for the mobile node) in the registration request. When the home agent receives this registration request, it updates the binding table with the label. A sample registration request relayed by FA to HA is shown below. æLmÆ is the label assigned by the FA for the mobile session. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 |S|B|D|M|G|r|T|x| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Radhakrishnan & Xu & Wong Expires Feb. 2002 6 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Non-Auth Extensions for HA ... | | ( variable length ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =32 | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (cont..) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : MN-HA Authenticator ( variable length ) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 50 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label (Lm)_ | Exp |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Other Optional Extensions used by HA......... : Optional FA-HA Authentication Extension... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3 Label distribution by home agent The home agent can assign unique labels to each of the L2TP sessions for the VPNs. Home Agent can also assign labels for each mobile node for QoS support. HA needs not assign any such labels, if it cannot identify the session or flow associated with the correspondent node. Home agent sends these label information in the registration reply. The foreign agent when accepts successful reply from the home agent, updates the registration table with the new label received in the reply. A sample registration reply from HA to FA is shown below. æLhÆ is the label assigned by the HA for the mobile initiated session. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Radhakrishnan & Xu & Wong Expires Feb. 2002 7 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 | Optional HA Non-Auth Extensions ... | | ( variable length ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =32 | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (cont...) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : MN-HA Authenticator ( variable length ) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 50 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label(Lm) | Exp |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 51 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label(Lh) | Exp |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Other Optional Extensions used by FA......... : Optional HA-FA Authentication Extension... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.4 Label distribution for route optimization When the home agent sends the binding update request to the correspondent node (or the router to which it is attached), it includes the label extension, assigned by the foreign agent, with the label value found in the binding entry for mobile node. The correspondent node uses this label when forwarding any traffic to the mobile node. 4.5 Label distribution between foreign agent and mobile node The problem and solution stated in this section is when mobile node uses IPv4 co-located care-of-address. In this case, the FA acts as a default router, and FA always insists registration to be done with FA (due to billing or accounting issues). In this case FA will be doing normal routing for the co-located care-of address for traffic from Internet to MN. FA does the following additional functions to this traffic. (1) If the network between mobile node and FA uses GRE encapsulation for packet delivery, FA uses the GRE session key to select the interface port for the mobile node. This essentially requires snooping of IP packets for GRE session key before forwarding to the mobile node. (2) If the network between mobile node and FA is MPLS capable, and the tunnel end-point is mobile node and the LSP terminate in mobile node. In this case, FA does label switching/swapping functioning as a normal LSR. (3) If the network between mobile node and FA is not MPLS capable, and mobile node uses co-located care-of-address. In this case, the LSP should terminate in FA, and the label used to select the interface for the mobile node. Here FA function as custom Radhakrishnan & Xu & Wong Expires Feb. 2002 8 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 LER capable of providing label to the module, which does a fast lookup based on the label, to find out the mobile node interface. The third case is supported by terminating the LSP in the FA; and home agent is completely transparent to this. Two possible approaches to identify the capability of the mobile node are as follows. The first approach is to use a bit flag, to inform that Foreign Agent is MPLS capable, in agent advertisement. The mobile node could place its MPLS capability in registration request using an unused bit. That is, use bit flags in agent advertisement and registration requests. Second approach is to place a label extension in agent advertisement and return the same label extension in registration request by the mobile node. If the mobile node is not returning the same label extension, FA can assume that it is not MPLS path and could use proxy-MPLS service for the mobile node. Since both the explained above approaches require a change in the mobile node, these may not be recommended to do so. Hence, foreign agent may be statically configured to recognize the capabilities. 5. User Traffic Processing Considerations 5.1 Packet forwarding by foreign agent When the foreign agent sends a packet to the home agent (reverse tunnels), if any label exists (i.e. home agent sends the label in the Registration Reply), the FA places the label before forwarding the packet. Depending upon the tunneling mechanisms used between FA and HA, three possible cases of placing the label are: (1) If the foreign agent and home agent use Ipv4 GRE tunnels, the label is placed in the GRE session Id. (2) If the foreign agent and home agent are MPLS capable, this label is pushed into the label stack, followed by the normal MPLS labels for the LSP between FA and HA. ----> user traffic forwarding +----+ +----+ +----+ | MN |----------| FA |-----------| HA | +----+ +----+ +----+ |Lt| +--+ ---> to HA |Lh| +--+ Lt : Is the label for the tunnel Lh : is the explicit label for the mobile session for HA Figure: FA forwarding traffic to HA Radhakrishnan & Xu & Wong Expires Feb. 2002 9 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 (3) If the foreign agent and home agent are Ipv6 capable (not MPLS capable), the label is placed in the flow-label id or Ipv6 Destination options. In the case of open Internet traffic, where reverse tunneling is not done, it may not able to place the explicit labels, unless otherwise negotiated an explicit LSP between FA and the communicating node. 5.2 Packet forwarding by home agent When the home agent sends a packet to the care-of-address (foreign agent), if a label exist in the binding entry, the HA places the label before sending out the packet. Depending upon the tunneling method used, three possible cases of placing the label are: (1) If the foreign agent and home agent use Ipv4 GRE tunnels, the label is placed in the GRE key field. (2) If the foreign agent and home agent are MPLS capable, this label is pushed into the label stack, followed by the normal MPLS label for the LSP. <---- user traffic forwarding +----+ +----+ +----+ | MN |----------| FA |-----------| HA | +----+ +----+ +----+ |Lt| <----- +--+ HA to FA |Lm| +--+ Lt : Is the label for the tunnel Lm : is the explicit label for the mobile session for FA Figure: FA forwarding traffic to HA (3) If the foreign agent and home agent are Ipv6 capable (not MPLS capable), the label is placed in the flow-label id or destination options. 5.3 Packet forwarding for Route Optimization When route optimization is used, the correspondent node or the attached router places the label information present in the binding entry when sending any traffic to the mobile node, in a similar way home agent does. 5.4 Packet reception by foreign agent When foreign agent receives a packet from the HA, it uses the MPLS label for the following: Radhakrishnan & Xu & Wong Expires Feb. 2002 10 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 (1) If the mobile node network side supports MPLS, the label is swapped (normal MPLS processing). Here, as explained before, Foreign agent will be a custom LSR capable of distributing explicit labels. (2) If the mobile node side only supports normal IP processing, the label is used to select the appropriate mobile node session. If the label is the GRE session key in the GRE tunneled packets from the home agent, this session is used to select the appropriate mobile node interface for tunneling the packets to the mobile node. Similar approach is done for tunneled Ipv6 packets also. 5.5 Packet reception by home agent The home agent can be either a custom LSR which should be able to receive labeled packets from the FA and forward them to the correspondent node. In this case, both sides of HA are MPLS networks. If the network between HA and correspondent node is not MPLS capable, where the network between FA and HA is MPLS capable, then when home agent receives a packet from the FA (which are reverse tunneled), it uses the inner MPLS label for the following: (1) Home agent could select the appropriate L2TP sessions, if the label is allocated for each L2TP session. (2) If the label is allocated for QoS for the mobile node, the label is used to apply appropriate QoS policies. (3) If the label is allocated for Ipsec or NAT for the mobile node, the label is used to apply appropriate IpSec or NAT policies. Similarly, on the other hand if GRE (or Ipv6) is tunneling is used by FA to reverse tunnel the packets to HA, when HA receives the GRE tunneled packets, the GRE session key (or Ipv6 label) is used to do any one of the above 3 selection of appropriate sessions. 6. Advantages of mobile IP label distribution The following are the advantages of using mobile IP for label distribution over conventional label distribution methods. (a) It is less overhead and fast; since label distribution is done as part of mobile IP registration. (b) No separate label distribution protocol is needed for explicit label negotiation. (c) Negotiating explicit label distribution using a different protocol is not recommended since mobile IP registration is very dynamic in nature. (d) The mobile node information and label will always be synchronized since mobile IP is used for label distribution. (e) Label distribution is implicitly secure by Mobile IP. (f) Label release is done by mobile IP when binding expires By comparison, if label distribution (for mobile IP) using conventional MPLS LDP protocol is used to support Mobile IP, the following sequence of steps has to be performed in sequence: Radhakrishnan & Xu & Wong Expires Feb. 2002 11 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 (1) First do mobile IP registrations (2) Negotiate explicit label between HA and FA using existing protocol. (3) Extra security needs to be introduced for step (2). (4) Negotiate MPLS labels between neighbors Now steps (1) and (2) are required for every mobile node registrations. Also step (2) & (3) for each mobile IP registration introduces lots of overhead for conventional label distribution. But using mobile IP label distribution, step (1) and step (2) are combined to just one step. 7. Summary A new mobile IP label extension is proposed to distribute labels using mobile IP registration request/reply and binding update message exchanges. These labels are places as GRE sessions key, or MPLS labels or Ipv6 labels when packets are forwarded using respective technology. 8. IANA Considerations The label extension placed by the foreign agent in the registration request (defined in section 4.1) SHOULD be assigned the Type value of 50 (to be assigned by IANA). The label extension placed by the home agent in the registration reply SHOULD be assigned the Type value of 51 (to be assigned by IANA). With this assignment, the Type value assigned to the label extension have been identified as not conflicting with any numbers defined for Mobile IP to date and documented at http://www.isi.edu/in- notes/iana/assignments/mobileip-numbers. 9. Security Considerations There no additional security required for label distribution since it is covered by the mobile IP registration messages. 10. References [1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 1996. [2] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC2344, May 1998. [3] Charles E. Perkins and David B. Johnson. "Route Optimization in Mobile IP". draft-ietf-mobileip-optim-08.txt, February 1999. (work in progress). Radhakrishnan & Xu & Wong Expires Feb. 2002 12 < draft-shaji-mobileip-generic-label-ext-00.txt > Sept. 2001 [4] J. Reynolds and J. Postel. "ASSIGNED NUMBERS". RFC1700, October 1994. [5] Gopal Dommety. "Key and Sequence Number Extensions to GRE". RFC2890, September 2000. [6] E. Rosen et.al ôMPLS Label Stack Encodingö. RFC3032, January 2001. [7] E. Rosen et.al ôMultiprotocol Label Switching Architectureö. RFC3031 [8] Ren Z., et.al, ôIntegration of Mobile IP and MPLSö, draft-zhing-mobile-ip-mpls-01.txt, July 2000 [9] Jun Kyun Chio, et.al, ôExtension of LDP for Mobile IP Service through the MPLS Networkö, draft-choi-mobile-ip-ldpext-01.txt, October 2001. [10] Bilel Jamoussi, et.al, ôConstraint-Based LSP Setup using LDPö, draft-ietf-mpls-cr-ldp-05.txt, August 2001 [11] Daniel O. Awduche, et.al, ôRSVP-TE: Extensions to RSVP for LSP Tunnelsö, draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, August 2001 Author's Addresses Shaji Radhakrishnan WaterCove Networks 285 Billerica Road Chelmsford, MA, USA 01824 Phone: (847) 621-8913 Email: sradhakrishnan@watercove.com Yingchun Xu WaterCove Networks 285 Billerica Road Chelmsford, MA, USA 01824 Phone: (847) 477-9280 Email: yxu@watercove.com Ellis Wong WaterCove Networks 285 Billerica Road Chelmsford, MA - 01824 Phone: (978) 608-2089 Email: ewong@watercove.com Radhakrishnan & Xu & Wong Expires Feb. 2002 13