MPLS Working Group Jun Kyun Choi Internet Draft ICU Document: draft-choi-mobileip-ldpext-00.txt Yoo Kyoung Lee ETRI Sun Hee Yang ETRI Eun Ah Kim ETRI December 2000 Extension of LDP for Mobile IP Service through the MPLS Network Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as 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." 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 IP network through the MPLS network. One small-scale mobile IP network could be connected to other networks through the MPLS backbone network. It proposes the MPLS network architecture to provide the large- scale mobile IP network. Specifically, it proposes that the label distribution protocol (LDP) can be applied to set up the Label switched path (LSP) tunnels between the mobile agents (that is, Foreign Agents and Home Agents)[3]. It means that the IP-in-IP tunnels can be replaced by one or multiple Label switched paths (LSPs) on the MPLS network. Choi et al. Expires July 2001 [Page 1] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 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 [2]. Table of Contents 1. Introduction 2. The MPLS Network Architecture with Mobility Support 2.1. Assumptions and Requirements 2.2. Network Architecture and Service Scenarios 2.3. Routing considerations 2.4. Interworking of existing Mobile IP network 3. Description of the Protocol 3.1. General Assumptions 3.2. LSP Tunnels for Mobility Support 3.3. Registration of Mobile Node 3.4. Agent Advertisement and Solicitation 3.5. Location Query of Mobile Node 3.6. LSP Extension for Handover 3.7. LSP Recalculation 4. Required Messages and TLVs 4.1. Required Messages and TLVs 4.2. Registration Message 4.3. Agent Advertisement and Solicitation Messages 4.4. Location Query and Response Messages 4.5. LSP Extension Message 4.6. LSP Recalculation Message 5. IANA Considerations 6. Security Considerations 7. References 8. Author's Addresses 9. Full Copyright Statement Choi, et al. Expires July 2001 [Page 2] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 1. Introduction A mobile node of a Mobile IP network may be connected to Foreign Mobile IP networks with a distance. The MPLS network can provide the backbone solution for high speed IP forwarding. The relevant label switched paths on the MPLS network can support proper quality-of- service (QoS) paths for differentiated mobile IP services. This document proposes the MPLS network architecture and tunneling procedures to support the mobile IP network. Similar concerns on the integration of MPLS network and Mobile IP network are also investigated in [8]. The MPLS backbone network can build the large-scale mobile IP network. A mobile IP network is connected to other mobile IP network via the Label Edge Router (LER). To support Mobile IP services, The MPLS network have to accommodate Foreign Agent and Home Agent. The LER is capable of forwarding Mobile IP packets by encapsulating with relevant label header. The LER (Label Edge Router) would be a Foreign Agent or its corresponding node. For mobility support, the LER will be a gateway router for the corresponding mobile IP network. To support the hierarchical architecture, the Gateway FA or Regional FA could be defined on the MPLS network [4]. For the control procedure, the label distribution protocol (LDP) may be extended to set up the Label switched path (LSP) tunnel between the mobile agents (that is, Foreign Agents and Home Agents) through the MPLS network [3]. The IP-in-IP tunnels of Mobile IP Network can be provided by the one or multiple LSPs through the MPLS network. When a mobile node is moving to the foreign area, the existing LSPs may be extended without service interrupt. The short-cut LSPs between source and destination mobile nodes may be recalculated to avoid the long cascaded connections. The Home Agent can be implemented on the relevant MPLS routers according to geographical area and routing path. There may be two types of scenarios according to location of Home Agent (HA). Scenario 1 (we call it, Tunnel Extension) is a natural extension of the existing mobile IP protocol through the MPLS network. The MPLS network provides the LSP tunnels replaced by the IP-in-IP tunnels. Scenario 2 (we call it, Query Before Tunneling) is that the HA is attached at the LSR like a server since it couldnÆt intercept the incoming IP packets to forward the destination FA belonging to the visiting area of a mobile node. Scenario 1 (Tunnel Extension) is based on the existing scenario of Mobile IP service and the HA should be located at the LER [5],[6]. In this scenario, the IP-in-IP tunnels between HA and FA could be done with help of the LDP operation. There is no additional constraints on the existing protocols of mobile IP. Scenario 2 (Query Before Tunneling) is that the HA is attached or located at the Label Switching Router (LSR). It assumes that the LSR is not directly connected to the regional mobile IP network and the Choi, et al. Expires July 2001 [Page 3] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 HA doesnÆt be capable to intercept the mobile IP packets for tunneling. In this case, the similar scenario with the existing cellular or IMT-2000 network using home location register/visit location register (HLR/VLR) can be applied. The ingress LER may query the care-of-address (CoA) of the egress LER/FA from the HA to find the direct short-cut path. The forwarding path should be pre- calculated by query process. The cache imposition or label binding operation may be done at the LER/FA. To deliver the mobile IP packets through the MPLS network, it requires the IP encapsulation [7]. Far from home location, the mobile node should be registered to the foreign LER with proper agent discovery process. The registration process should be also needed between the HA and the corresponding FA through the MPLS network. While a node tries to call the mobile node, data forwarding path with help of HA should be established between the source LER and the destination LERs. The label switched path (LSP) by the LDP operation would enable to label the IP packets and forwards them at the destination mobile node via the MPLS network. 2. The MPLS Network Architecture with Mobility Support 2.1. Assumptions and Requirements In order to provide the backbone solution for Mobile IP network, it considers the following assumptions on the MPLS network. - There is no additional requirements on the existing mobile IP protocol such as agent discovery, registration, and routing. - All the regional mobile IP networks should be connected at the LER which will be a external gateway router to communicate the external world. - In the MPLS backbone network, all the LERs are equipped with FA to identify the visiting mobile nodes. In case that a number of FAs are in a Mobile IP network, the FA attached to the LER has a responsibility to communicate to the external world. - The HA should be located at the LER or the LSR. If a small-scale mobile IP network already has a number of HAs to cover their own regional area, it should discriminate from the HAs interfaced to the MPLS network. The relevant registration procedure is required for the mobile IP network on a number of HA. A mobile node should register the HA interfaced to the MPLS network while moving to external world. It can extend the registration procedure of mobile IP service [5],[6]. - The forwarding process on the MPLS network should be taken on the datagram IP traffic (the UDP traffic) as well as the stream-like IP traffic (the TCP traffic). Depending on the location of HA on the MPLS network, the following assumptions are required. Choi, et al. Expires July 2001 [Page 4] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 - In Scenario 1 (Tunnel Extension), all the LERs have to operate the HA. It means that a mobile node should be identified both from the HA and the FA at visiting area while moving to foreign area [5],[6]. - When a node sends the IP packets to the mobile node, the LER with HA intercepts and forward them to the corresponding LER/FA on temporarily visiting area. - In Scenario 2 (Query Before Tunneling), the HA is not located at the home LER. It means that the HA couldnÆt intercept IP packets. For this scenario, we assume that the data forwarding paths should be pre-calculated at the originating LER. When a node sends IP packets to the destination mobile IP node, the ingress LER has to decide whether forwarding to home area or not. Otherwise, it have to query from the HA to get the IP address of the destination LER/FA at a temporarily visit area. 2.2. Network Architecture and Service Scenarios The MPLS network to support mobile IP service doesnÆt use IP in IP encapsulation. The label switched path (LSP) tunnel provides a lower layer tunneling scheme independent on high layer applications. It notes that the IP-in-IP tunneling utilizes the layer 3 forwarding capability in IP routing. The ingress LER forwards IP packets all the way to the HA to the egress LER to the foreign mobile node. The whole forwarding process is done at the MPLS layer. The HA doesn't need to involve the IP layer forwarding to a mobile node. Since label header is much smaller than IP encapsulation header, the header overhead from HA to FA is also reduced. It can improve the scalability of mobile IP protocol. Moreover, an LSP satisfying the quality-of-service (QoS) requirements and traffic engineering could be set up with Constraint-Based Label Distribution Protocol (CR-LDP) or RSVP-TE [9],[10]. Figure 1 shows the MPLS network architecture using Scenario 1 (Tunnel Extension). In this scenario the HA is located at the LER1 and has a capability to intercept IP packets for a mobile node. When a mobile node from the LER1/HA area is temporarily moving to the LER2 area, the registration is required to HA via LER2/FA2. When a node at LER3 sends IP packets to a current mobile node, the LSP tunnels would be established from LER3 to LER1 and cascading from LER1 to LER2. The relevant LDP operations will be taken with associations of Forwarding Equivalence Class (FEC). When a mobile node is moving to the LER4/FA2 area during active service time, the LSP tunnel from LER1 to LER2 should be extended or re-configured to LER4 with update on HA, FA1 and FA2. The seamless LSP tunnel to LER4 may be required for the real-time applications. To encapsulate IP packets with a MPLS header, the destination address of the MPLS header is initially the LER2. The MPLS label stack operation may cut through the corresponding address of the tunnel's receive endpoint. If the ingress point of the LSP tunnel wishes to Choi, et al. Expires July 2001 [Page 5] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 put a labeled packet into the MPLS network, it should replace the label value at the top of the stack with a label value that was distributed to it by the tunnel's receive endpoint. Then it must push on the label which corresponds to the tunnel itself, as distributed to it by the next hop along the tunnel. To allow this, the tunnel endpoints should be explicit label distribution peers. +----------+ | Foreign | +------------------------------+ | Mobile IP| | The MPLS Network +-+--+ | Network | | with Mobility Support | FA1| | +------+ | +---------+ +----+ /|LER2|--+-|old MN| | |Home | | HA | +------+ +------+ / +--+-+ | +------+ | |Mobile IP+-+LER1|--| LSR1 +--+ LSR2 |--+ | +----------+ |Network | |----+ +------+ +------+ \ | +---------+ | \ | \ | +----------+ | \ | \ | | Foreign | | \ | \ | | Mobile IP| | \ | +-++-+ | Network | | +-+-+--+ | FA2| | +------+ | +----| LER3 |----------------|LER4|--+-|New MN| | +---+--+ +----+ | +------+ | | +----------+ +-+--+ | FN | +----+ LER: Label Edge Router LSR: Label Switching Router HA: Home Agent FA: Foreign Agent MN: Mobile Node FN: Fixed Node Figure 1. The MPLS Network Architecture with Mobility Support (Scenario 1 : Tunnel Extension) In this scenario, the functions of correspondent agents, FA, can be located in the LERs. The LSPs can be setup the same way as "tunnels" are setup between correspondent agents and foreign agents. Since an LSP can be setup between a correspondent agent and a foreign agent (the LERs), this allows for traffic aggregation between the LERs. In addition it allows constrained based routing and the QoS path between the agents can be guaranteed. The establishment of these LSPs can be triggered by the Binding Update messages, by data transmitted, configured a priori or by other means. In the registration procedure, the mobile node (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 Choi, et al. Expires July 2001 [Page 6] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 temporary CoA from FA and sends a registration request to FA. Since FA is an edge LER, it will analyze the incoming registration request message and get the destination address of the request. Then, FA updates its routing table 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 registration request message is forwarded to HA using normal IP hop-by-hop routing. When HA gets the registration request message and learns the CoA, it searches its label table to find the table with the MN home address as Forwarding Equivalence Class (FEC). Then, it will send a label request using CR-LDP 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. After that, HA changes its label table that uses the MN home address as FEC. It sets the outgoing port entries 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. Packets from a node 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. HA inserts the label value in the label table into packet and sends it out through the port indicated in the table. If MN is still in the home network, then 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. The first packet is delivered from HA to FA along the LSP (LER1-LSR1-LSR2-LER2) by label swapping. FA receives the first packet and looks up its label table. Since it is the egress of the LSP from HA to FA and the outgoing port entries are empty, FA strips off the label and sends the packets to the IP layer. Finally, FA forwards the packet to MN based on the newly-added host specific routing table. MN receives the packet sent by a originating node. Directly after delivering the first packet, HA transmits the CoA of MN to the ingress LER. After the LER of FN receives the CoA of MN form HA, the new LSP (LER3-LSR1- LSR2-LER2) between the LER and FA is established. From the next packet, the LER is directly delivered to FA using the newly- established LSP tunnel which is reduced the distance of FN and MN. When MN moves from one FA to another, the registration procedure is repeated once between the HA and new FA. The existing LSP should be changed to the new FA. The following issues are further considered on the MPLS network. - Path rerouting - Path extension Choi, et al. Expires July 2001 [Page 7] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 - Label binding for the LSP from FN to new FA +------------------------------+ | The MPLS Network | +----------+ | with Mobility Support | | Foreign | | +----+ | | Mobile IP| | | HA | +-+--+ | Network | | +-+--+ | FA1| | +------+ | +---------+ | | /|LER2+--+-|old MN| | |Home | |-+--+ +--+---+ +------+ / +--+-+ | +------+ | |Mobile IP+-+LER1+--+ LSR1 +--+ LSR2 +--+ | +----------+ |Network | |----+ +--+---+ +------+ \ | +---------+ | \ | \ | +----------+ | \ | \ | | Foreign | | \ | \ | | Mobile IP| | \ | +-++-+ | Network | | +-+-+--+ | FA2| | +------+ | +----+ LER3 +----------------+LER4+--+-|New MN| | +---+--+ +----+ | +------+ | | +----------+ +-+--+ | FN | +----+ Figure 2. The MPLS Network Architecture with Mobility Support (Scenario 2 : Query Before Tunneling) Figure 2 shows the MPLS network architecture using Scenario 2 (Query Before Tunneling). In this scenario, the HA is attached at the LSR and is not capable to intercept IP packets. But, the registration procedure is the same with Scenario 1. According to geographical area and routing path, HA may cover more than one regional Mobile IP networks. The tunneling procedure of this model might be different from that of Scenario 1. When a FN at LER3 sends packets to a MN located in the foreign area, the ingress LER (LER3) has to decide the relevant forwarding path depending on routing information. There are three alternatives to forward IP packets. case (a) home IP address of a MN as default forwarding path case (b) HA address of the MN case (c) CoA address of the MN, that is, egress LER/FA as tunneling receive endpoint of MN For the case (a), the additional processing on the home LER is required since the UDP traffic tries to take the default path without reservation of label flow. In case (b), the HA address should be already known by all network elements and there is no advantage to locate at the LSR. It requires for further study. Choi, et al. Expires July 2001 [Page 8] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 It is preferable of case (c) that the forwarding path from ingress LER should be cut through the egress LER/FA, the CoA of the MN. For all the cases, the ingress LER should find forwarding path with relevant query process. The query process is depending on whether the destination is a mobile user or not. It may cause that this scenario is not applicable to IPv4 network without relevant procedure since the IPv4 address structure is not capable of identifying mobile terminal. For IPv6, it seems to be applicable when some address spaces are dedicated for mobile. One possible application for this scenario may be the MPLS-based IMT-2000 Network using Ipv6. For this scenario, it requires the query process to find the destination tunnel endpoints on the MPLS network. The LER decides whether destinations are for mobile application. And it tries to look up their label table for incoming packets. When the relevant port entries and labels are found, it sends them to the output port with a label header. If no entry is returned, it sends the query messages to the HA dealing with destination IP address. For the UDP traffic, it also requires the query process on destination address to assign the default label value. Then, the incoming IP packets may wait for several seconds to get the address of egress LER/FA. For the matters of QoS and traffic control, it should investigate whether the bandwidths between ingress LER and egress LER are available or not. With these concerns, the CR-LDP or RSVP-TE may be useful to take a relevant forwarding path. The detail discussions on Query Before Tunneling scenario require for further study. 2.3. Routing Considerations The routing on the MPLS network is depending on locations of HA and FA. In MPLS network, through flow classification, each flow may be different in grades of service. An LSP should meet certain QoS requirements of differential flows using CR-LDP or RSVP-TE. The detail discussions on routing issues of the MPLS network with mobility support are further study. 2.4. Interworking of existing Mobile IP network It requires for further study. Choi, et al. Expires July 2001 [Page 9] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 3. Description of the Protocol 3.1. General Assumptions In this draft, the main issues of MPLS network architecture with mobility support are focused on the control procedure such as registration, agent discovery, LSP establishment and LSP Extension, etc. Agent advertisement and discovery within the scope of regional mobile IP network are beyond the scope of this document. We assume that the FAs support security associations We also assume on the mobile wireless IP networks that are divided into a number of cell regions according to geographical area. Each cell is covered by a Base Station (BS) which provides wireless IP access to the MN. The BS is connected to the LER to support mobility. 3.2. LSP Tunnels for Mobility Support There requires two types of LSP tunnels in the MLPS network with mobility support; - LSP tunnels between the ingress LER and HA - LSP tunnels between HA and egress LER/FA - Direct LSP tunnels between ingress LER and egress LER/FA (scenario 2) The existing LDP specification is well described to establish LSP tunnels for mobility. The address of HA and FA for LSP tunnels will be given by the Agent Discovery Procedure within the MPLS network. The LSP with QoS constraints will be contained in the CR-LDP or RSVP- TE specification [9],[10]. 3.3. Registration of Mobile Node 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 LER, it will analyze the incoming registration request message and get the destination address of the HA. Then FA updates its routing table and adds a host specific row with the label 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. MN FA1(LER2) HA | | | |---------------------------->| | Choi, et al. Expires July 2001 [Page 10] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 | Broadcast Agent | | | Solicitation Message(ICMP) | | |<----------------------------| | | Broadcast Agent | | | Advertisement Message(ICMP) | | | | | |---------------------------->| | | MN Registration Request(UDP)|------------------------------->| | | MN Registration Request (UDP) | | | | | |<-------------------------------| |<----------------------------| MN Registration Reply (UDP) | | MN Registration Reply (UDP) | | | | | | | (no entry between HA and FA)| | |<-------------------------------| | | Label Request Message(CR-LDP) | | | | | |------------------------------->| | | Label mapping Message(CR-LDP) | | | | Figure 3. Registration of Mobile Node at the MPLS Network Based on the IP routing table, FA forwards the registration request message toward HA. The request message is forwarded to HA in a hop- by-hop manner 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). Then, it will send a label request using CR-LDP 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. 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. 3.4. Agent Advertisement and Solicitation Choi, et al. Expires July 2001 [Page 11] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 Mobile agents (i.e., foreign agents and home agents) advertise their presence via Agent Advertisement messages. A mobile node may optionally solicit an Agent Advertisement message from any locally attached mobility agents through an Agent Solicitation message. A mobile node receives these Agent Advertisements and determines whether it is on its home network or a foreign network. FA+HA MN | | |---------------------------------->| | Agent Advertisement Message | | | |<----------------------------------| | Agent Solicitation Message | | | Figure 4. Agent Discovery of Mobile Node at the MPLS Network If sent periodically, the nominal interval at which Agent Advertisements are sent SHOULD be 1/3 of the advertisement Lifetime given in the MPLS shim header. This allows a mobile node to miss three successive advertisements before deleting the agent from its list of valid agents. The actual transmission time for each advertisement SHOULD be slightly randomized [11] in order to avoid synchronization and subsequent collisions with other Agent Advertisements that may be sent by other agents. 3.5. Location Query of Mobile Node This procedure may be OPTIONALLY used for Scenario 2 (Query Before Tunneling) to find the direct short-cut path of egress LER or the default forwarding path of UDP traffic. When a MN moves to foreign mobile IP network, LER3 queries HA for the location of MN. HA responses to LER3 whether it has the information of it. LER3 HA |---------------------------------->| | Location Query Message | | | |<----------------------------------| | Location Response Message | | | Figure 5. Location Query of Mobile Node at the MPLS Network Choi, et al. Expires July 2001 [Page 12] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 With Query information from HA, LER initiates the label binding process to the egress LER2/FA1 to a MN. After that, LER3 updates the row in its label table that uses the CoA of a MN as FEC. It sets a label value and outgoing port entries. In case that a FN sends IP packets to LER3 without any request message, LER3 searches for forwarding label entries to the destination MN. If not found, it sends the location query messages to HA to get the CoA of a MN. After that, it initiates the Label request message to the egress LER2/FA1 destined to a MN. FN LER3 HA LSR FA1(LER2) MN | | | | | | |------------>| | | | | |User Packets |(no entry) | | | | | |---------------->| | | | | |Location Query | | | | | | | | | | | |<----------------| | | | | |Location Response| | | | | | | | | | |-------------------->| | | | | Label Request |------------->| | | | | Label Request| | | | |<-------------| | | |<--------------------| Label Mapping| | | | Label Mapping | | | | | | | | | |-------------------->| | | | | User Packets |------------->| | | | | User Packets |----------->| | | | |User Packets| | | | | | Figure 6. User Data Delivery using Location Query at the MPLS Network 3.6. LSP Extension for Handover There are two phases in handover scheme, we call it LSP Extension and LSP Recalculation. When a mobile node moves from Foreign IP Network FA1 to FA2, it sends a message to register the new FA. Signaling messages should be exchanged between old FA and new FA to extend the LSP tunnel. It extends the current LSP by establishing a LSP between current FA and new FA. During that time, old FA buffers all the packets from and to the mobile node. Once the LSP is established, packets are sent along the new path to the mobile node. Choi, et al. Expires July 2001 [Page 13] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 _ Existing +----+ LSP +----+ | HA | +------+ +------+ | FA1| +--------+ _ |LER1+----+ LSR1 +---+ LSR2 +-----+LER2+---+ old MN | +--+-+ +------+ +------+ +--+-+ +--------+ \ | | \ Extended | | +-+----+ LSP | | | LER3 | | | +--+---+ +--+-+ V | | FA2| +--------+ +-+--+ |LER4+---+ New MN | | FN | +----+ +--------+ +----+ Figure 7. LSP Extension for Mobile IP MN New FA Old FA HA ... FN | | | | | |-------------->| | | | | Reg. Request |------------------------------>| | | | Reg. Request | | | |<------------------------------| | | | Reg. Reply | | | | | | | | |-------------->| | | | |LSP Extension +| | | | | LSP Request | | | | |<--------------| | | |<--------------|LSP Ext. Reply+| | | | Reg. Reply | LSP Mapping | | | | | | | |-------------->| | | | User Messages |-------------->| | | | User Messages |---------------------------->| | | | User Messages | | | | | Figure 8. Message Sequence for LSP Extension The LSP extension procedures in Figure 8 are as follows. - MN moves to a new FA and sends a Registration Request message to New FA. - New FA sends a Registration Request message to HA. - HA sends Registration Reply message in response to the Registration Request. - If new FA receives Registration Reply message, new FA sends the Label Request and LSP Extension Message to old FA. Choi, et al. Expires July 2001 [Page 14] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 - A LSP is established between old FA and new FA when new FA receives Label Mapping message. - Then the new FA sends Registration Reply message to the MN 3.7. LSP Recalculation In LSP Recalculation, LSP tunnels between ingress LER and old FA are branched to the new FA. The LSR to perform branching function is usually referred to as the crossover LSR. After LSP Recalculation, the route between ingress LER and new FA can be optimized. Old path is torn down and new path is set up. LSP Recalculation is triggered by the MN. It can happen when the QoS of LSP tunnel is temporarily degraded. The major steps of LSP Recalculation involves: 1. Determining the location of the crossover switch. 2. Setting up a new branch LSP. 3. Terminating the old branch LSP. +----+ +----+ | HA | +------+ +------+ | FA1| +--------+ _ |LER1+----+ LSR1 +---+ LSR2 | |LER2| | old MN | +--+-+ +------+ +----+-+ +----+ +--------+ \ \ | \ Recalculated \ | +-+----+ LSP \ | | LER3 | \ | +--+---+ \ +----+ V | \| FA2| +--------+ +-+--+ +LER4+---+ New MN | | FN | +----+ +--------+ +----+ Figure 9. LSP Recalculation for Mobile IP MN New FA Old FA Crossover HA ... FN | | | LSR | | |Reg. Request| | | | | |----------->| Reg. Request | | | |------------------------------------->| | | | Reg. Reply | | | |<-------------------------------------| | | | LSP Ext. + | | | | | | LSP Request| | | | | |----------->| | | | | | LSP Mapping| | | | | |<-----------| | | | Choi, et al. Expires July 2001 [Page 15] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 | Reg. Reply | | | | | |<-----------| | | | | | | | | Messages | | | | Messages |<----------------------| | | Messages |<-----------| | | | Messages |<-----------| | | | |<-----------| | | | | | | | | | | | LSP Recal. | | | | | |----------->| Label Req. + LSP Recal. | | | | |------------------------>| | | | | LSP Mapping | | | | |<------------------------| | | | | | | | | | | |Label Rel. | | | | | Label Rel. |<-----------| | | | |<-----------| | | | | | Label Rel. | | | | | | Reply | Label Rel. | | | | |----------->| Reply | | | | LSP Recal. | |----------->| | | | Reply | | | | | |<-----------| | | Messages | | | Messages |<----------------------| | Messages |<------------------------| | |<-----------| | | | | | | | | | | Figure 10. Message Sequence for LSP Recalculation The LSP Recalculation procedures in Figure 10 are as follows. - LSP Recalculation is triggered by the MN when QoS of channel of the mobile node is degraded. - New FA sends LSP Recalculation and Label Request message to the Crossover LSR when it receives LSP Recalculation message. - The Crossover LSR sends Label Mapping message to the new FA and releases existing LSP to the new FA via the old FA. - Then, FA sends LSP Recalculation message to the MN. 4. Required Messages and TLVs 4.1. Required Messages and TLVs Choi, et al. Expires July 2001 [Page 16] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 Any Messages, TLVs, and procedures not defined explicitly in this document are defined in the LDP Specification [3] and IP Mobility Support [4]. It can use Constraint-Based LSP Setup using LDP [2] as an informational document related to CR-LDP. 4.1.1. LDP PDUs Each LDP PDU is an LDP header followed by one or more LDP messages. The LDP header is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | PDU Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LDP Identifier | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version Two octet unsigned integer containing version number PDU Length Two octet integer specifying the total length of this PDU in octets LDP Identifier Six octet field that uniquely identifies the label space of the sending LSR 4.1.2. Type-Length-Value Encoding LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of the information carried in LDP messages. An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify a Type and 2 bits to specify behavior when an LSR doesn't recognize the Type, followed by a 2 octet Length Field, followed by a variable length Value field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | ~ ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Choi, et al. Expires July 2001 [Page 17] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown TLV bit. As defined in [3] F bit Forward unknown TLV bit. As defined in [3] Type Encodes how the Value field is to be interpreted. Length Specifies the length of the Value field in octets. Value Octet string of Length octets that encodes information to be interpreted as specified by the Type field. 4.1.3. Message Format and Protocol Extensibility Mobility Support of Constraint-based LDP defines a set of new control messages. Currently, the following two message types are defined: 0x3F01 Registration Request 0x3F02 Registration Reply 0x3F03 Location Query 0x3F04 Location Response 0x3F05 LSP Extension Request 0x3F06 LSP Extension Reply 0x3F07 LSP Recalculation Request 0x3F08 LSP Recalculation Reply This draft defines a general Extension mechanism to allow optional information to be carried by LDP messages to support mobility. Each of these Extensions is encoded in the TLV format. Extensions allow variable amounts of information to be carried within each LDP Message. Currently, the following TLV are defined for Extensions appearing in LDP Mobility messages: 0x3F11 Registration Request Data TLV 0X3F12 Registration Reply Data TLV 0x3F13 Location Query Data TLV Format 0x3F14 Location Query Data TLV Format 0x3F15 LSP Extension Request Date TLV Format 0x3F16 LSP Extension Reply Data TLV Format 0x3F17 LSP Recalculation Request Data TLV Format 0x3F18 LSP Recalculation Reply Data TLV Format 4.2. Registration Message Choi, et al. Expires July 2001 [Page 18] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 A mobile node registers with its home agent using a Registration Request message of LDP so that its home agent can create or modify a mobility binding for that mobile node (e.g., with a new lifetime). The Request may be relayed to the home agent by the foreign agent through which the mobile node is registering. 4.2.1. Registration Request Message Format The encoding for the Registration Request Message is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Message Type (0x3F01) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Mandatory Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown message bit. Message Type Identifies the type of message Message Length Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters. Message ID 32-bit value used to identify this message. Mandatory Parameters Variable length set of required message parameters. Optional Parameters Variable length set of optional message parameters. 4.2.1.1. Registration Request Data TLV Format Choi, et al. Expires July 2001 [Page 19] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 Registration Request Data TLV is Mandatory Parameter of Registration Request Message. The encoding for Registration Request Data TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type (0x3F11) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|B|D|M|G|V| reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown TLV bit. F bit Forward unknown TLV bit. Type 0x3F11 Length Specifies the length of the Value field in octets. S bit Simultaneous bindings. As described in [5]. B bit Broadcast datagrams. As described in [5]. D bit Decapsulation by mobile node. As described in [5]. M bit Minimal encapsulation. As described in [5]. G bit GRE encapsulation. As described in [5]. V bit As described in [5]. Choi, et al. Expires July 2001 [Page 20] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 resered Reserved bits; sent as zero Lifetime As described in [5]. Home Address The IP address of the mobile node. Home Agent The IP address of the mobile node's home agent. Care-of Address The IP address for the end of the LSP tunnel. Identification As described in [5]. 4.2.2. Registration Reply A mobility agent returns a Registration Reply message to a mobile node which has sent a Registration Request message. If the mobile node is requesting service from a foreign agent, that foreign agent will receive the Reply from the home agent and subsequently relay it to the mobile node. The Reply message contains the necessary codes to inform the mobile node about the status of its Request, along with the lifetime granted by the home agent, as described in [5]. 4.2.2.1. Registration Reply Message Format Registration Reply Message has following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Message Type (0x3F02) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Mandatory Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Choi, et al. Expires July 2001 [Page 21] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 U bit Unknown message bit. Message Type Identifies the type of message Message Length Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters. Message ID 32-bit value used to identify this message. Mandatory Parameters Variable length set of required message parameters. Optional Parameters Variable length set of optional message parameters. 4.2.2.2 Registration Reply Data TLV Format The encoding for the Registration Reply Data TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type (0x3F12) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown TLV bit. F bit Forward unknown TLV bit. Type 0x3F12 Length Specifies the length of the Value field in octets. Choi, et al. Expires July 2001 [Page 22] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 Code A value indicating the result of the Registration Request Message. Lifetime As described in [5]. Home Address The IP address of the mobile node. Home Agent The IP address of the mobile node's home agent. Identification As described in [5]. The following values are defined for use within the Code field. Registration successful: 0 registration accepted 1 registration accepted, but simultaneous mobility bindings unsupported Registration denied by the foreign agent and the home agent is specified in [5]. 4.3. Agent Advertisement and Solicitation Messages The Agent Advertisement and Solicitation Messages are encapsulated by the MPLS shim header while a MN tries to discover the HA or FA through the MPLS network. (It may be optionally applied to Scenario 2.) MPLS shim header 20 3 1 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | Exp |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label Some reserved value for Mobile IP Exp experimental use S bottom of stack TTL the Time to live for all Agent Advertisements MUST be set to 1. Choi, et al. Expires July 2001 [Page 23] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 ICMP Agent Advertisement Message 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num Addrs |Addr Entry Size| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference Level[1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference Level[2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ICMP Fields: Type 9 Code 1 (note: extended for Agent Discovery) Checksum As described in [11]. Num Addrs The number of router addresses advertised in this message. Addr Entry Size As described in [11]. Lifetime The maximum number of seconds that the router addresses may be considered valid. Router Address[i], Mobile AgentÆs IP address. i=1..Num Addrs Preference Level[i], As described in [11]. i=1..Num Addrs ICMP Agent Solicitation Message 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 | Code | Checksum | Choi, et al. Expires July 2001 [Page 24] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ICMP Fields: Type 10 Code 1 (note: extended for Agent Discovery) Checksum As specified in [11]. Reserved Sent as 0; ignored on reception. 4.4. Location Query and Response Messages A LER wishing to send a packet to the mobile node for the first time must first discover the IP address of the mobile host's HA. The LER then issues a query to the HA, which returns the mobile host's Location as well as the remaining registration Lifetime. The LER cashes the mobile node's Location and uses the cached binding for subsequent packets destined to the mobile node. The LER Must refresh its binding cache by querying the HA again before the mobile node's remaining registration Lifetime expires. 4.4.1. Location Query Message Format The encoding for the Location Query Message is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Message Type (0x3F03) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Mandatory Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Choi, et al. Expires July 2001 [Page 25] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 U bit Unknown message bit. Message Type Identifies the type of message Message Length Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters. Message ID 32-bit value used to identify this message. Mandatory Parameters Variable length set of required message parameters. Optional Parameters Variable length set of optional message parameters. 4.4.2. Location Query Data TLV Format Location Query Data TLV is Mandatory Parameter of Location Query Message. The encoding for Location Query Data TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type (0x3F13) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown TLV bit. F bit Forward unknown TLV bit. Type Identifies the type of message Length Specifies the length of the Value field in octets. Home Address The IP address of the mobile node. 4.4.3. Location Response Message Format The encoding for the Location Response Message is: Choi, et al. Expires July 2001 [Page 26] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Message Type (0x3F04) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Mandatory Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown message bit. Message Type Identifies the type of message Message Length Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters. Message ID 32-bit value used to identify this message. Mandatory Parameters Variable length set of required message parameters. Optional Parameters Variable length set of optional message parameters. 4.4.4. Location Response Data TLV Format Location Response Data TLV is Mandatory Parameter of Location Response Message. The encoding for Location Response Data TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type (0x3F14) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | Choi, et al. Expires July 2001 [Page 27] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown TLV bit. F bit Forward unknown TLV bit. Type Identifies the type of message Length Specifies the length of the Value field in octets. Lifetime The number of seconds remaining before the registration is considered expired. Home Address The IP address of the mobile node. Care-of Address The IP address for the end of the LSP tunnel. 4.5. LSP Extension Message The encoding for the LSP Extension Message is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Mandatory Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown message bit. Choi, et al. Expires July 2001 [Page 28] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 Message Type Identifies the type of message In the case of LSP Extension Request, Message Type value is 0x3F05. If Message Type field valued is 0x3F06, then this message is LSP Extension Reply Message in response to LSP Extension Request. Message Length Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters. Message ID 32-bit value used to identify this message. Mandatory Parameters Variable length set of required message parameters. Optional Parameters Variable length set of optional message parameters. 4.5.1. LSP Extension Data TLV Format LSP Extension Data TLV is Mandatory Parameter of LSP Extension Message. The encoding for LSP Extension Data TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Old FA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New FA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown TLV bit. F bit Forward unknown TLV bit. Type Identifies the type of message In the case of LSP Extension Request Data TLV, Type value is 0x3F15. If Type field valued is 0x3F16, then this TLV is LSP Extension Reply Data TLV in response to LSP Extension Request Data TLV. Length Choi, et al. Expires July 2001 [Page 29] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 Specifies the length of the Value field in octets. Home Address The IP address of the mobile node. Old FA Address The IP address of the old FA. New FA Address The IP address of the New FA. 4.6. LSP Recalculation Message The encoding for the LSP Recalculation Message is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Mandatory Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown message bit. Message Type Identifies the type of message In the case of LSP Recalculation Request Message, Message Type value is 0x3F07. If Message Type field valued is 0x3F08, then this message is LSP Recalculation Reply Message in response to LSP Recalculation Request. Message Length Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters. Message ID 32-bit value used to identify this message. Choi, et al. Expires July 2001 [Page 30] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 Mandatory Parameters Variable length set of required message parameters. Optional Parameters Variable length set of optional message parameters. 4.6.1. LSP Recalculation Data TLV Format LSP Recalculation Data TLV is Mandatory Parameter of LSP Recalculation Message. The encoding for LSP Recalculation Data TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New FA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Crossover LSR Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit Unknown TLV bit. F bit Forward unknown TLV bit. Type Identifies the type of message. In the case of LSP Recalculation Request Data TLV, Message Type value is 0x3F17. If Type field value is 0x3F18, then this TLV is LSP Recalculation Reply Data TLV in response to LSP Extension Request Data TLV. Length Specifies the length of the Value field in octets. Home Address The IP address of the mobile node. New FA Address The IP address of the new FA. Crossover LSR Address The IP address of the Crossover LSR. Choi, et al. Expires July 2001 [Page 31] Internet Draft Draft-choi-mobileip-ldpext-00.txt December 2000 5. IANA Considerations This draft does not create any new number spaces for IANA administration. 6. Security Considerations This document does not have any security concerns. The security requirements using this document are described in the referenced documents. 7. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] Andersson L., et. al, ôLDP Specification,ö , Auguest 2000 [4] Gustafsson E., et al., ôMobile IP Regional Registration,ö , 13 July 2000 [7] Perkins C., ôMinimal Encapsulation within IP,ö RFC 2004, October 1996 [8] Ren Z., et al., ôIntegration of Mobile IP and MPLSö, , July 2000. [9] Jamoussi B., et al., ôConstraint-based LSP Setup using LDP,ö , July 2000 [10] Awduche D. O., et al., ôREVP-TE: Extensions to RSVP for LSP Tunnels,ö , July 2000 [11] Deering S., Editor, "ICMP Router Discovery Messages", RFC 1256, September 1991. [12] Gustafsson E., et al. "Mobile IP Regional Registration" work in progress, . July 2000 [13] Rivest R., "The MD5 Message-Digest Algorithm", RFC 1321 April 1992 Choi, et al. Expires July 2001 [Page 32] 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 Yoo Kyoung Lee Electronics and Telecommunication Research Institute (ETRI) 161 Kajung Dong Yusong, Taejon Korea 305-305 Phone: +82-42-860-6120 Email: leeyk@etri.re.kr Sun Hee Yang Electronics and Telecommunication Research Institute (ETRI) 161 Kajung Dong Yusong, Taejon Korea 305-305 Phone: +82-42-860-5231 Email: shyang@etri.re.kr Eun Ah Kim Electronics and Telecommunication Research Institute (ETRI) 161 Kajung Dong Yusong, Taejon Korea 305-305 Phone: +82-42-860-4820 Email: eakim@etri.re.kr 9. 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 implementation 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.