Internet Engineering Task Force Yujun Kuang Internet Draft Keping Long Expires: August 2005 Qianbin Chen Yun Li Special Research Centre for Optical Internet and Wireless Information Networks (COIWIN) Chongqing University of Post & Telecommunications February 2005 Fast Handoff by L2 Trigger in MPLS-based Mobile IP Networks Status of Memo By submitting this I nternet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3667. This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document extends the integration of Mobile IP (MIP) and Multi- Protocol Label Switch (MPLS) with Layer2 Triggers (L2T) to expedite handoff and route optimization procedures. In the proposal, MPLS acts as only a fast second layer switch technique to setup a connection-oriented communication network, while MIP or IP acts as a signaling protocol to operate, administrate and manage MPLS network. L2Ts in this proposal are introduced to trigger signaling process of rerouting, extension and recovery of label switch paths (LSP) rather than to trigger registration or binding update of new care-of address (CoA), in traditional MIP. Moreover, in the proposed architecture, IP-in-IP tunneling is replaced by LSPs to support mobility, which reduces packet overhead thus mitigates network burden and makes it easy to support quality-of-service (QoS) or class-of-service (CoS). Therefore, the proposed scheme is well suited for time-constrained or delay-sensitive applications. Conventions The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC 2119]. Table of Contents 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. GENERAL DESCRIPTION . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Summary of Integrated MPLS-based MIP . . . . . . . . . . 5 2.2. Summary of L2Triggers . . . . . . . . . . . . . . . . . . 5 2.3. Reference Model . . . . . . . . . . . . . . . . . . . . . 7 2.4. Overview of the proposed scheme . . . . . . . . . . . . . 8 3. PROCEDURES OF L2 TRIGGER FOR LDP OPERATION . . . . . . . . . . 8 3.1. A SIMPLE NETWORK TOPOLOGY . . . . . . . . . . . . . . . . 8 3.2. Generic L2T Message Format . . . . . . . . . . . . . . . . 9 3.3. PROPOSED L2 TRIGGER OPERATION . . . . . . . . . . . . . . 11 3.3.1. Mobility Detection by MN . . . . . . . . . . . . . 11 3.3.2. Mobility Detection by Network . . . . . . . . . . . 12 4. ROUTE OPTIMIZATION CONSIDERATION . . . . . . . . . . . . . . . 13 4.1. WHEN LSP-PRE-SETUP SCHEME USED . . . . . . . . . . . . . . 14 4.2. WHEN LSP-POST-SETUP SCHEME USED . . . . . . . . . . . . . 14 4.3. COMBINED LSP-SETUP SCHEME . . . . . . . . . . . . . . . . 15 5. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 15 6. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . 15 7. CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . . 15 9. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 16 9.2. INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . 16 10. AUTHORS' ADDRESSES . . . . . . . .. . . . . . . . . . . . . . 16 11. IPR DISCLOSURE . . . . . . . . . . . . . . . . . . . . . . . . 17 12. IPR NOTICE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. FULL COPYRIGHT STATEMENT . . . . . . . . . . . . . . . . . . . 18 1. INTRODUCTION Thanks to much progress of communication technologies, people can new afford so many accesses to versatile services. However, there are still many challenges to operators, service providers and equipment suppliers to provide us services that can be easily configured/managed/controlled, broadband, efficient, and can be accessed seamlessly, universally. The best choice acknowledged is to integrate the versatile wireless accesses with the existing prevalent TCP/IP technologies - which provide universal and easy to use interface for various applications - into broadband core networks. IETF has defined Mobile IP (MIP) [RFC 2002] protocol suite to adapt TCP/IP for mobile communication nodes and networks. However, MIP uses traditional hop-by-hop routing schemes, which are basically connectionless, thus cannot provide Quality-of-Services (QoS) guarantees [RFC 2212], especially for time-constrained or delay- sensitive services. DiffServ [RFC 2475] and InteServ [RFC 1633] frameworks have been proposed to support QoS or Class-of-Services (CoS) for IP networks, but DiffServ and InteServ are not well supported by IP technologies because IP network is per-hop oriented and connectionless while per- service oriented DiffServ and per-flow oriented InteServ are both inherently connection-oriented schemes. Multi-protocol Label Switching (MPLS) [RFC 3031] is a good choice for both DiffServ and InteServ because MPLS is a inherently connection- oriented technique which enables a single converged network for easy and efficient migration to IP-based network with traffic engineering, QoS support, better scalability and reduced router processing requirements. Integration [Zhong][Choi] of MIP and MPLS (IMM) improves the scalability of the Mobile IP data forwarding process by exploring the features of MPLS - which are fast switching, small state maintenance and high scalability - and by extending label distributing protocols for MIP services over MPLS networks. The integrated architecture has removed the need for IP-in-IP tunneling from Home Agent (HA) to Foreign Agent (FA). However, for high mobility users or mobile nodes, IP-layer handoffs may involve too much latency that is above threshold when time-constrained or delay- sensitive services are active. Therefore, Karim El Malki et al proposed two methods and their combination for low latency handoffs in MIP networks [Malki], where layer2 triggers (L2T) are introduced to trigger registration or binding update of new CoA. The aim of this document is to present a new usage of L2Ts to expedite handoffs in the IMM wireless network. We use L2Ts to trigger LDP messages rather than MIP messages to reroute, to extend or to optimize LSPs between correspondent node (CN) and mobile node (MN) and/or that between MN and foreign agents (FA) or gateway foreign agents (GFA). 1.1. Terminology Frequently used terms are as follows: LSR - Label Switching Routers LER - Label Edge Routers LDP - Label Distribution Protocol LSP - Label Switching Path MN - Mobile Node CN - Correspondent Node CoA - Care-of Address HA - Home Agent FA - Foreign Agent oFA - old Foreign Agent, the FA involved in handling a MN's care of address prior to an L3 handoff nFA - new Foreign Agent, the FA anticipated to be handling a MN's care of address after completion of an L3 handoff aFA - anchor Foreign Agent, the FA that is currently handling the network end of the BET in POST-REGISTRATION L2T - Layer 2 Triggers, Information from L2 that informs L3 of particular events before and after L2 handoff LT-UP - Layer 2 Triggers for Link Up LT-DN - Layer 2 Triggers for Link Down L2-MT - An L2 trigger that occurs at the MN informing of movement to a certain nFA (Mobile Trigger) L2-ST - An L2 trigger that occurs at oFA, or source trigger informing the oFA that L2 handoff is about to occur L2-TT - An L2 trigger that occurs at nFA, or target trigger informing the nFA that a MN is about to be handed off to nFA L2-LU - An L2 trigger that occurs at the MN or nFA, informing that the L2 link between MN and nFA is established L2-LD - An L2 trigger that occurs at the oFA, informing the oFA that the L2 link between MN and oFA is lost L2-CANCEL - An L2 trigger message to cancel the previously sent L2 trigger L2 handoff - Movement of a MN's point of Layer 2 (L2) connection from one wireless access point to another L3 handoff - Movement of a MN between FAs, which involves changing the care-of address (CoA) at Layer 3 (L3) Low latency handoff L3 handoff in which the period of time during which the MN is unable to receive packets is minimized Low loss handoff L3 handoff in which the number of packets dropped or delayed is minimized. Low loss handoff is often called smooth handoff Seamless handoff L3 handoff that is both low latency and low loss Bi-directional edge tunnel (BET) A bidirectional tunnel established between two FAs for purposes of temporarily routing a MN's traffic to/from it on a new subnet without requiring the MN to change CoA Ping ponging Rapid back and forth movement between two wireless access points often due to failure of L2 handoff Network-initiated handoff L3 handoff in which oFA or nFA initiates the handoff Mobile-initiated handoff L3 handoff in which the MN initiates the handoff Base Station an MPLS node that owns an IP address, or a base station controller that owns an IP address in some networks, therein handoffs between base stations - which is out of our scope - are performed at link layer and unnoticed by IP layer. 2. GENERAL DESCRIPTION 2.1. Summary of Integrated MPLS-based MIP In [Zhong][Choi], Zhong et al have proposed integrated architecture of MPLS and MIP, which is redrawn here in Figure 1, where subplots are given to illustrate three different scenarios, 1) single MPLS domain architecture where MIP functionalities are located on HA and FAs that are located in the same MPLS domain and act as LERs; 2) multiple-MPLS-domain situation; 3) a more complex architecture where an IP cloud lies between two MPLS domains to which HA and FA belongs. When MN moves within the MPLS domain, it anchors to the nearest FA or its HA and communicates with CN by LSPs setup by FA, HA and LSR1. LSR1 is the ingress/egress LSR for CN. Therefore, although FA and HA are MIP enabled, the IP packets between CN and MN are forwarded by LSP directly rather than by IP-in-IP tunnel in traditional MIP. For wireless networks, registration or rebinding of new CoA of MN during handoffs would induce latency that may not be allowed for some time critical services such as wireless phone over IP, which is not covered in [Zhong] and [Choi]. Moreover, cases when the oFA and nFA belong to different MPLS domain makes handoffs even more complicate and induces much longer delay and degrades service quality. 2.2. Summary of L2Triggers In [Malki], K. E. Malki et al have defined five L2Triggers and three handoff approaches - that are Pre-registration, Post-registration and Combined dual registration - to explore L2T messages for fast low latency handoffs in MIPv4. Table 1 gives a summarized list of the 5 L2Triggers, their receiver/trigger, trigger time and associated parameters. -------------------------------------- +----+ | +------+ +------+ +----+ | +----+ | CN |--+---| LSR1 |----| LSR2 |----| FA |---+---| MN | +----+ | +--+---+ +------+ +----+ | +----+ | | \ | | | | \ | |(moving) | +--+--+ \ +----+ | V | | HA | \| FA |---+-- | +--+--+ MPLS Network +----+ | | | | -------|------------------------------ | a) Single MPLS Domain Architecture supporting MIP --------------------------- ------------------ | | | | +----+ | +----+ +----+ | | +----+ +--+ | +--+ | CN |--|--|LSR1|---|LSR2|--------|--|-|LSR3|---|FA|--|--|MN| +----+ | |----| +----+ | | +----+ +--+ | +--+ | \ | | MPLS Network 2| | \ +--+ | ------------------- | \|HA|-|-- | +--+ | | MPLS Network 1 | --------------------------- b) Multiple MPLS Domain Architecture ---------------------- ---------- ---------------- | MPLS Network 1 | | IP | | | | | | Cloud | | | +----+ | +----+ +----+ | | +----+ | | +----+ +--+ | +--+ | CN |--|--|LSR1|---|LSR2|---|--|-| R1 |-|--|-|LSR3|--|FA|-|--|MN| +----+ | |----| +----+ | | +----+ | | +----+ +--+ | +--+ | | | | | | | | | | | | | | | | | +--+ | | +--+ | |MPLS Network 2| | |HA| | | |FA| | | | | +--+ | | +--+ | | | --------------|------- -----|---- ---------------- | | +--+ |MN| +--+ c) Architecture of Multiple MPLS Domains with IP cloud in between Figure 1. Integrated Architecture of MPLS and MIP [Zhong] Table 1. L2Triggers [Malki] -------~-----------~----------------~---------------~------------ L2T | Receiver | Handoff Method | Trigger Time | Parameters -------+-----------+----------------+---------------+------------ L2-MT | MN | Pre-by-MN | Before L2H | IP-nFA -------|-----------+----------------+---------------+------------ L2-ST | oFA | Pre-by-NET or | Before L2H | IP-nFA&MN | | Post-by-MN | | -------+-----------+----------------+---------------+------------ L2-TT | nFA | Pre-by-NET or | Before L2H | IP-oFA&MN | | Post-by-MN | | -------+-----------+----------------+---------------+------------ L2-LU | MN or | Pre or Post | MN&nFA LNK-UP | IP-oFA&MN | nFA | | | -------+-----------+----------------+---------------+------------ L2-LD | nFA | Post | MN&oFA LNK-DN | IP-MN ----------------------------------------------------------------- Notes: Pre-by-<.> or Pre : Pre-registration (initiated by <.>) Post-by-<.> or Post: Post-registration (initiated by <.>) L2H : Layer2 Handoff IP-<.> : IP address of <.> In the proposed scheme, we will utilize L2T to trigger LDP messages, which are part of LSR/LER function. The receiver of L2T can be at the oFA or nFA and resides in the LDP engine on Foreign Agents to receive L2T messages. And when the sender is MN, MN might send the Layer2 Event Report to FA through layer2 link or TCP/IP link, which is a matter of implementation choice. Detection of MN Mobility can be performed either on MN or on the network, or on both. But the trigger receivers in this document will be only the nodes that are MPLS-enabled which can therefore start LDP procedure to re-establish LSP or reroute part of the LSP. Note that, for some wireless network mechanism where MN should always sweep beams from base stations one by one to detect their mobility, Layer 2 Triggering scheme might be of no effect when the beaming interval is too long which introduces large delay for MN to contact with new base station, thus delay of Layer 2 handoff is much longer compared to that of handoff in IP layer or MPLS layer. Therefore, other means must be studied for smooth L3 handoff, which is out of scope of this document. 2.3. Reference Model Figure 2 illustrates the reference model of the proposed scheme. The data path between CN and MN can be divided into three segments: 1) segment between CN and the MPLS domain, which ends at LER1; 2) segment in MPLS domain, which is mainly built by LSPs, starts at LER1 and ends at LER2; 3) segment between MPLS domain and MN, which ends at LER2 from MN. The medial part might be in a single MPLS domain or across several MPLS domains. The FA and HA might in a single MPLS domain or separate MPLS domains, or neither belongs to an MPLS domain. Moreover, the HA or FA might be or not be MPLS enabled, which will further make integration of MPLS and Mobile IP more complex. However, we will only consider scenarios wherein HA and FA are MPLS- enabled (or LER-enabled, FA/HA acts as an LER) and FAs belong to the same MPLS domain because the extension to multiple MPLS situation is quite trivial. +----------+ +----+ +----------+ | LDP |<-->|LDP |<--------->| LDP | +----+ +----------+ +----+ +----------+ +----+ |UDP | | UDP | |UDP | | UDP | |UDP | |TCP | | TCP | |TCP | | TCP | |TCP | +----+ +----------+ +----+------| +----------+ +----+ | |****| IP |****| |****| IP |****| | | IP | | +------+ | IP +------+ +------+ | | IP | | |<==>| | MPLS |<==>| | MPLS |<==>| MPLS | |<==>| | +----+ +---+------+ +----+------+ +------+---+ +----+ |LINK| | LINK | | LINK | | LINK | |LINK| +----+ +----------+ +-----------+ +----------+ +----+ CN LER1 LSR LER2 MN /--- Segment1 ---/----------- Segment2 ---------/--- Segment3 ---/ <----> LDP Messages **** LDP or L2T Messages <====> LSP or IP Datagrams to-fro LER Figure 2. System Reference Model 2.4. Overview of the proposed scheme Karim El Malki et al [Malki] have defined Layer Triggers and low latency handoff schemes for MIP to improve handoff performance in MIP. But if L2T is directly applied to the integrated architecture, because L2T and the related messages are defined for MIP only, the triggers would be will be received by MIP functional entities and processed in MIP layer for MIP re-registration. After the MIP re- registration process completes, LER-enabled FAs will setup or reroute the old LSP to MN's new destination. The whole process described will take a lot of time due to its verbosity. Therefore, in the proposed scheme, L2Ts are utilized directly to trigger LDP messages will obviously expedite the LSP diversion or rerouting. In this document, we borrow the concept of L2T from [Malki] and make use of L2T defined in [Malki] for LSP setup or rerouting rather than MIP network layer registration of CoAs to improve handoff proficiency, that is, L2T messages carry handoff-required information about MN moving around the MPLS domain or even among MPLS multi-domains which initiate LDP messages to setup LSP to MN's new destination before or just when the Layer2 handoff completes. In a few words, Layer2 Triggers serve as special events to trigger LDP messages rather than MIP messages to setup LSPs, to reroute or to extend existing LSPs. However, the L2 triggers can also be used for MIP Pre-Registration, Post-Registration and Combined Registration that are described in [Malki]. The joint optimization of L2T for both LDP and MIP are under future study. 3. PROCEDURES OF L2 TRIGGER FOR LDP OPERATION 3.1. A SIMPLE NETWORK TOPOLOGY Figure 3 shows simplified network architecture and also its topology for the integrated MIP and MPLS. In the MPLS domain, only two kinds of data pipes exist: 1) LSPs that are setup to transmit labeled data packets; 2) hop-by-hop IP streamlines for signaling datagram such as LDP messages, route messages or else. The network can be viewed as three-layer structured (See Figure 2). The bottom layer is the link layer, which provides segmented links for data transmission, monitors, and reports link status to upper layer. The mid layer is the MPLS transmission network joined by label switch paths (LSP) - note that the IP cloud is actually invisible to MPLS nodes other than LSR2 and LSR3 (see Figure 2). The top layer, including IP layer and Transmission Control Layer, is mainly for signaling purpose, for example, to deliver LDP messages between LSRs, or deliver MIP messages, which can also be tunneled by LSPs. In Figure 3, the CN is out of the MPLS domain where MN roams, but in the following it makes no differences where CN locates. .-------------------. | LDP |<-------------------+ ~-------------------~ | | .---. .---. .---. .---. .---. | | |====|LSR|====|LSR|====|LER|====|LER| | |LER| | | | | | | | | | | |****| 1 |****| 2 |****|FA1|****|FA2| | ~-+-~ ~-+-~ ~---~ ~-+-~ ~-+-~ | | | | | .-+-. .-+-. .-+-. | | |L2T| |CN | |LER| .-+-. ~---~ ~---~ | | |MN | ---> |HA | ~---~ ~---~ ---: data stream to-fro CN, MN, HA ===: LSP communications ***: IP communications Figure 3. A Simple Network Topology 3.2. Generic L2T Message Format The L2T message should at least contain the following information: 1) Trigger Message Type, which indicates it is an LT-MN trigger or else (See below); 2) IP Address of both nFA and oFA, and IP address of MN when handoff is network aided; 3) Forecasted Layer 2 handoff instant and handoff delay, which might be useful for nFA or oFA to decide whether or not to trigger LDP messages for this Layer2 event referring to the instant when the message being sent; 4) Random signature generated by MN to prevent replay cheating (24 -bit); Figure 4 illustrates a generic L2T message format. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 |R|TType|Unused | NONCE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | IP Address of oFA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | IP Address of nFA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | IP Address of MN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | IP Address of CoA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | IP Address of HA, Power Strength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | L2 Handoff start instant | L2 Handoff Complete instant | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . + Additional Signature or Authentication Data Required + . | | . + +-+-+-+-+-+-+-+-+-+-+-+-+ . | | PADDING | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. Generic L2T Message Format R Response Bit, set to zero when MN sends L2T message to FA, while inversed to 1 by FA when it send response back to MN. TType L2T message type, which might be one of the following: ------------------------------------------------------------------ L2T Type| L2-MT | L2-ST | L2-TT | L2-LU | L2-LD | LT-REP | CANCEL --------+-------+-------+-------+-------+-------+--------+-------- Value(B)| 000 | 001 | 010 | 011 | 100 | 101 | 111 ------------------------------------------------------------------ Unused 4 bits reserved for future use, must be zeros here. NONCE A 24-bit integer, generated by the MN or FA. IP Address of nFA, oFA, HA, CoA of MN and MN's home address The IP addresses of nFA, oFA, HA, MN's CoA and home address are all included for simplifying process of message management on each FA/LER. Note that, when TTYPE is LT-REP then the 6th 32-bit field stands for Signal Strength in dB of MN measured by nFA (See Section 3.3.2). The IP address field should be set all zero if the IP address is not available or not usefull. L2 Handoff Start Instant & L2 Handoff Complete Instant The estimated L2 handoff start instant and its complete instant estimated in unit of ms. If necessary, additional signature or authentication data should be piggybacked in the L2T messages for much strong security requirement and when no signature or authentication data exist, the L2T message is 28-byte in length. 3.3. PROPOSED L2 TRIGGER OPERATION To apply L2 Triggers in the integrated architecture of MPLS and MIP [Zhong][Choi], the MN or the network should detect or forecast the mobility of MN and utilize L2T to trigger LDP messages which start re- establishment or rerouting of LSP before L2 handoff and get LSP ready at the instant as close as possible to that when link layer handoff completes. And concurrently, the registration of MN's new CoA with its HA is also started before L2 handoff and should be completed almost at the same time L2 handoff completes. Mobility of MN can be detected by MN or by network and thus the handoff. 3.3.1. Mobility Detection by MN In this case, MN receives signals from FA1 and FA2 simultaneously or alternatively by sweeping and searching for surrounding base stations and judge whether or not a link layer handoff is necessary by comparing their signal strength or by other means. If an upcoming link layer handoff would take place, the MN compares the current Agent IP address with the learned destined FA/HA for mobility detection from link layer (See Figure 3) to decide whether IP handoff is necessary. And if it is TRUE, the MN sent an L2T message with TYPE set as L2-MN to the oFA or nFA whose signal strength is stronger or to both of them to alert an upcoming L2 handoff event. By any means, the MN can forecast a future handoff event, it generates a L2-MN trigger to advance the process of LSP re - establishment or re-route (LSP-UPDATE). Although TCP supports more reliable transmission than UDP, it introduces more delay in session setup. Therefore, the L2T messages shall be sent by UDP message. In this situation, the MN obtains a CoA from the FA (oFA) it anchors and registers it with its HA; then the oFA negotiates with HA or the LER in the same MPLS domain of oFA which connects to HA the LSPs - optimization of LSP or MIP routes is out of scope. Figure 5 illustrates the procedure for MN to send L2T messages and the correspond action taken by FA/LER. The oFA or nFA listens to a known UDP port for the L2-MN messages. The UDP port number shall be assigned by IANA. The UDP port on the MN might be any unused port for its current trigger session, that is, the MN should initiate its UDP port and a NONCE for each trigger session to prevent replay cheating. +------------------+ MN +------------------+ FA | | | | | ----------V----------- | ----------V----------- |<-------|L2 Handoff Detection| |<-------|Listening L2 Message| |FALSE ----------+----------- |FALSE ---------------------- | |TRUE | | TRUE | -----------V------------ | ------V----- <-------|L3 Mobility Detection | | |validation| FALSE -----------+------------ | ----+--+---- |TRUE |FALSE | |TRUE --------V-------- <----------------+ | | LT-MT Report& | -------V------- | Wait Resp. | |Respond to MN| ----------------- -------+------- | -------------- +-----+-----+-----+-----+------+ Link_UP---> |LT-LU Report| LT-MT|LT-ST|LT-TT|LT-LU|LT-LD|CANCEL| -------------- v v v v v v -------------- +--------------------------------+ Link_Down-> |LT-LD Report| | LDP Procedures | -------------- +--------------------------------+ Figure 5. Flowchart on MN & FA for L2T When MN detects its upcoming mobility, it sends the L2-MN to the oFA or nFA, which in turn starts LSP-UPDATE process where which LDP message to be sent to its peer LSR is of local importance in specific LER implementation and out of the text scope. The MN might start a timer to wait for a response from FA, and if no response received when the timer overflows, it may choose to resend a L2T with NONCE and time related to its link layer handoff recalculated, or to send a CANCEL message corresponding to the previous L2T message when it finds that condition of the previous Trigger becomes void, using NONCE as a indication. How to keep track of the NONCE is not covered in this document. When link is up or down, the MN sends LT-LU or LT-LD respectively to inform FA of such events. Upon receiving L2T from MN, the FA shall validate the received L2T by checking IP address fields or by verifying the additional security data attached to the L2T. If the L2T is valid, it should send a response back to the sender, which is simply a copy of the 32-bit beginning of the L2T with the MSB inversed. Then FA initiates LDP procedure for LSP-UPDATE. During the LSP-UPDATE process, the FA might receive a CANCEL message from MN, then FA must break the LSP- UPDATE procedure if the CANCEL message contains a matching NONCE and sends back the CANCEL message with R bit set to 1. Both oFA and nFA may be the actual receiver of the MN's trigger messages and they can start their LDP procedure independently. When MN decides to CANCEL the previous L2T, it must send CANCEL to all successful receivers of that L2T. 3.3.2. Mobility Detection by Network For network-aided handoff, the LER/FA should be capable of detecting mobile nodes approaching to or leaving from it, and this might be a link layer function or/and IP layer function. When MN roams into another FA's (nFA) coverage, the nFA hears the transmission between MN and the oFA, and figures out the signal strength, IP address (both CoA and home address) and oFA IP address. Then the nFA reports this messages to oFA by UDP whenever it hears from MN together with a new CoA that will be assigned to MN when it registers with nFA. The oFA is listening to a known UDP port to collect the transmission status information. When it forefeels an upcoming link layer handoff of MN between oFA and nFA, it may send a L2T to its L2T receiver UDP port that is an embedded entity of its LDP protocol. Upon receiving the L2T the oFA starts LDP procedure to request a LABEL from nFA with the FEC associated with that CoA to be assigned by nFA. If successful, the LSP is extended to nFA before the MN actually switches to nFA. It is likely that the extended LSP is not optimized, and even worse to be gyroidally lengthy. But the optimization of LSP is out of scope of this text. It is required that oFA setup a timer to keep the path to and fro MN alive even after it receives a LT-LD message to reduce IP layer delay when ping-pong occurs. And it is also required that nFA setup a timer to keep the extended path available just long enough, and if no LT-LU received before the timer is out, it is assumed that the MN ping-pongs back or roams into another nFA's coverage. Figure 6 illustrates the network-aided handoff procedure on MN, oFA and nFA. oFA MN nFA | +------------+ | |<----------|Transmission|-.-.-.-.->| +-----V-----+ +------+-----+ +-----V-----+ |Messurement|<-----------+----------|Messurement| +-----------+ LT-REP(CoA,Power,MN) +-----------+ | | | +-----V------+ LDP Label|Request | |L2-ST by oFA|-----------.--------------->| | |<----------.----------------| +-----+------+ LDP Label|Assignment | | | +------v-----+ | +------V-----+ |L2-LU by nFA| +-----V------+ | Obtain CoA | +------------+ |L2-LD by oFA| +------------+ | +------------+ +------------+ | |<-.-.-.-.-.|Transmission|--------->| | +------+-----+ | V V Figure 6. Flowchart of Network-aided Handoff and L2 Triggers 4. ROUTE OPTIMIZATION CONSIDERATION As described above, to expedite the handoff process in MPLS layer, we simply partially reroute the LSP or just extend the existing LSP to MN's new location (new CoA), which may result non-optimized route that induces a larger end-to-end delay. However, without L2T directly to advance the LDP message in [Zhong][Choi], the MN would perform handoff first, register new CoA with HA by MIP, and then the HA or nFA initiates LSP reroute procedure to rebuild the LSP tunnel between MN and HA, which takes time much more than that of the proposed scheme. Moreover, LSP optimization can be performed for better performance when the LSP setup process finished. Here are two choices. Actually, there are three methods to setup LSP required for MN mobility, one of which is LSP-pre-setup scheme, another is LSP-post- setup scheme and a combination of the previous two methods. 4.1. WHEN LSP-PRE-SETUP SCHEME USED In this scheme, LSP are setup in advance according to the topology information of the MPSL network. However, only necessary LSPs are setup between the LERs or LSRs. Therefore, LSPs have already been setup even when data transmission between CN and MN does not start. Figure 7 illustrates a simple network with 5 routers and their label switch paths that are setup before MN's existence, note that there would be more than one LSP among LSRs. In Figure 7, 7, 8, 9 are normal IP or MIP paths. When MN is anchored on oFA, CN communicates with MN through the path 7-1-8. When MN approaches to the new domain that belongs to nFA, MN or the network will detect its mobility and exchange L2 and L3 information by L2 Triggers to start LDP procedures, where nFA also assign new CoA for the incoming MN. Since the LSP 2, 3, 4, 5 or the LSP 6 have already been setup, to switch communication between CN and MN from oFA to nFA, we can directly join LSPs: 2-3-4-5 with previous path 7-1, or 6 with 7-1 to get LSP tunnel ready for MN before it moves to its new location. It obvious that the rejoined LSP might not be an optimized route, for example the path 7-1-2-3-4- 5-9 in Figure 7 can be optimized to 7-3-4-5-9 or 7-2-6-9. However, it is more important to handoff smoothly and quickly, and optimization of the new route can be performed even after MN begins communication at its new location (nFA). ----- 7 ----- 3 ----- 4 ----- |C N|-----|LER|-----|LSR|-----|LSR| ----- ----- ----- ----- 1| |2 +---/ \---+ |5 | | | | | | | | | | ----- |(6) 6| ----- |oFA|-+ +-|nFA| ----- ----- 8| |9 ----- |M N|--------------> (*) ----- Figure 7. Illustration of LSPs in topology-driven scheme 4.2. WHEN LSP-POST-SETUP SCHEME USED In this scheme, LSP are not setup in advance. When MN is anchored on oFA, CN communicates with MN through path 7- 1-8. When MN or network detects MN mobility L2 Triggers can be used to trigger LDP procedures which is responsible to setup or reroute LSP to MN's new location before or just when MN moves there. Since no ready-to-use LSP available, the current LSP must be extended or new LSP must be setup from CN-attached LER to nFA, see Figure 7. When MN moves to its new location, nFA, the new LSP route negotiated between nFA and oFA or LER can be optimized during the LSP setup process. But to setup such optimized LSP, say in Figure 7, 7-3-4-5-9 or 7-3-6-9, there would be much delay to transmit L2 handoff information to-and-fro among LER, oFA and nFA, and to negotiate required labels among LER, LSRs, and nFA, thus makes POST -SETUP involve more delay than PRE-SETUP scheme. 4.3. COMBINED LSP-SETUP SCHEME As stated above, LSP-Post-Setup scheme can offer optimized LSP route for communication between CN and can achieve better overall MPLS network performance, which is much dependent upon optimization algorithms adopted and will induce much more delay during MPLS handoff. Note that, in all schemes, to reduce packet loss and handoff delay in ping-pong situation when MN moves to and fro or when MN resides in the crossover area of several FAs, the previous data path (for example, 7-1 in Figure 7) and the old CoA should be preserved until its associated timer runs over. And now there are several LSP optimization scheme proposed or being studied, so LSP optimization is not covered in this document. 5. SECURITY CONSIDERATIONS Security issues are under further consideration. 6. IANA CONSIDERATIONS The UDP port required for L2T transmission among MN, oFA and nFA should be assigned by IANA. 7. CONCLUSION In this document, L2 Triggers are utilized to trigger LDP procedures in the integrated MPLS MPLS-based MIP architecture. Thus, the L2 triggered LDP messages flows among LSR/LERs rebuild, reroute or extend the LSPs to-and-fro MN such that LSP would be ready before or when MN just moves to its new location (new CoA), which expedite handoff and route optimization procedures in the integration of MPLS-based MIP with Layer2 Triggers. In the proposal, MPLS acts as only a fast second layer switch technique to setup a connection-oriented communication network, while MIP or IP acts as a signaling protocol to operate, administrate and manage MPLS network. Furthermore, IP-in-IP tunneling is replaced by LSPs to support mobility, which reduces packet overhead thus mitigates network burden and makes it easy to support quality-of-service (QoS) or class-of-service (CoS). Therefore, the proposed scheme is well suited for time-constrained or delay-sensitive applications. In the near future, much study will be conducted on performance of the proposed L2T scheme in different scenarios as described above. 8. ACKNOWLEDGEMENTS This research is funded by the National High Technology Research and Development Program of China (863 Program), Grant No. 2003AA121540. The authors are grateful to other colleagues and post-graduated students for their simulation works and useful suggestions. 9. REFERENCES 9.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC 2212] S. Shenker, C. Partridge, R. Guerin, Specification of Guaranteed Quality of Service, RFC2212, September 1997 [RFC 2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architecture for Differentiated Service, RFC 2475, December 1998 [RFC 1633] R. Braden, D. Clark, S. Shenker, Integrated Services in the Internet Architecture: an Overview, RFC1633, June 1994 [RFC 3031] E. Rosen, A. Viswanathan, R. Callon, Multi-protocol Label Switching Architecture, RFC3031, January 2001 [RFC 2002] C. Perkins (Ed.), "IP Mobility Support", RFC2002, October 1996 [Tai] Tai Won Um, Jun Kyun Choi, A Study on Path Re-routing Algorithms at the MPLS-based Hierarchical Mobile IP Network, Proceedings of IEEE Region 10 International Conference on Electrical and Electronic Technology, 2001. Vol. 2: 691-697, 19-22 Aug. 9.2. Informative References [Zhong] Zhong Ren, Chen-Khong Tham, Chun-Choong Foo, Chi-Chung Ko, Integration of Mobile IP and MPLS, Internet Draft, draft-zhong-mobile-ip-mpls-01.txt, July 2000, Work in Progress [Choi] Jun Kyun Choi, Yoo Kyoung Lee, Sun Hee Yang, Tai Won Um, Myoung Hun Kim, Extension of LDP for Mobile IP service through the MPLS Network, Internet Draft, draft-choi-mobileip-ldpext-01.txt, February 2001, Work in Progress [Malki] Karim El Malki (Editor), Pat R. Calhoun, Tom Hiller, James Kempf, Peter J. McCann, Ajoy Singh, Hesham Soliman, Sebastian Thalanany, Low Latency Handoffs in Mobile IPv4, IETF draft, draft-ietf-mobileip-lowlatency-handoffs-v4-09.txt, June 2004, work in progress 10. AUTHORS' ADDRESSES Questions about this memo can be directed to: Yujun Kuang Special Research Centre for Optical Internet & Wireless Information Networks (COIWIN), Chongqing University of Post & Telecommunications Chongqing, 400065 P.R. China Phone: +86 23 6246 0223 Fax: +86 23 6246 0220 E-Mail: Kuangyj@cqupt.edu.cn Keping Long Special Research Centre for Optical Internet & Wireless Information Networks (COIWIN), Chongqing University of Post & Telecommunications Chongqing, 400065 P.R. China Phone: +86 23 6246 0218 Fax: +86 23 6246 0220 E-Mail: Longkp@cqupt.edu.cn Qianbin Chen Special Research Centre for Optical Internet & Wireless Information Networks (COIWIN), Chongqing University of Post & Telecommunications Chongqing, 400065 P.R. China Phone: +86 23 6246 0219 Fax: +86 23 6246 0220 E-Mail: Chenqb@cqupt.edu.cn Yun Li Special Research Centre for Optical Internet & Wireless Information Networks (COIWIN), Chongqing University of Post & Telecommunications Chongqing, 400065 P.R. China Phone: +86 23 6246 0222 Fax: +86 23 6246 0220 E-Mail: Liyun@cqupt.edu.cn 11. IPR DISCLOSURE By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 12. IPR NOTICE The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 13. FULL COPYRIGHT STATEMENT Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 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. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.