A MPLS Framework for Macro- and Micro-Mobility ... - CiteSeerX

A MPLS Framework for Macro- and Micro-Mobility Management Kaiduan Xie and Victor C.M. Leung Department of Electrical & Computer Engineering The University of British Columbia Vancouver, BC, Canada V6T 1Z4

Abstract Mobile IP (MIP) provides a global framework for IP mobility management; however, it is not suitable for micro-mobility environments. Many domain-based micromobility management schemes have been proposed to overcome the limit of MIP. All these scheme delegate to MIP for inter-domain mobility. Recently there is a trend to use Multiple Protocol Label Switching (MPLS) to deal with mobility management. However, macro- and micromobility functions are treated separately. In this paper, we propose an architecture using MPLS for integrated macroand micro-mobility management. Novel techniques are proposed to facilitate Label Switch Path (LSP) setup to support Differentiated and Integrated Services. Based on the proposed architecture, we also present route optimization and paging methods.

Key Words MPLS, IP mobility management

1. Introduction Due to increasing demand for ubiquitous access to the Internet, wireless Internet access is gaining more and more attention in the academic and industrial research community. One problem with wireless Internet access is that in order to meet the ever-increasing demand for bandwidth and to maximize the utilization of precious and scarce wireless frequency resource, the cell size is becoming smaller resulting a higher cell crossing probability. Currently there are many proposals to deal with the disruptions caused by the frequent handoffs. Mobile IP (MIP) [1] is the current standard for supporting macro-mobility in IP networks, which provides transparent mobility by hiding the change of IP address when a mobile host moves between IP subnets, thus providing a good framework that allows users to roam outside their home network. However, it has some deficiencies in supporting fast handoff and seamless mobility in handoff-intensive environments. Many micromobility protocols [2-4] have been proposed in recent years aiming to remove such deficiencies as frequent reregistrations and triangular routing. Most of these

protocols adopt a hierarchical model that divides the network into domains. MIP is used to deal with the mobility between two domains while inter-domain mobility is handled by a micro-mobility scheme. Multi-Protocol Label Switching (MPLS) [5] is a labelswitching scheme that employs fast switching methods of ATM switches for IP routing. In MPLS each packet is assigned a label, and packet forwarding is performed by means of label swapping instead of routing using the IP address. The label is the only information used to derive a packet’s next hop. Since labels are short and have fixed length, MPLS can achieve high efficiency compared with conventional IP routing where longest prefix matching is used. Besides, MPLS also facilitates qualify of service (QoS) provisioning. Recently there is growing interest in applying MPLS in IP mobility management. An architecture integrating MPLS and MIP thus obviating the needs for IP-in-IP tunneling is presented in [6]. [7] proposes a MPLS based micromobility management scheme, which improves the system efficiency and facilitates QoS provisioning in the wireless IP access network. However, in these two papers, macro- and mico- mobility managements are treated separately. When MPLS is applied in an integrated mobility management environment, some interesting problems arise. We address these problems in this paper. In this paper, we make three important contributions. First, the new segmented Label Switch Paths (LSPs) are proposed to forward data packets to mobile hosts. Second, the novel Explicit Route Object (ERO) swapping method is proposed to setup the LSPs for Integrated Services (IntServ), allowing reserved resources to be reused for reduced handoff latency. Third, we propose route optimization and paging methods for our integrated MPLS micro-/macro-mobility management architecture. The remaining sections are organized as follows. Section 2 describes mobility management for Differentiated Service (DiffServ) in terms of LSP setup, packet forwarding and handoff processing. Section 3 shows how IntServ can be supported, extending RSVP for LSP setup with ERO swapping. Sections 4 and 5 consider paging and route optimization, respectively. Section 6 summarizes the paper.

2. Differentiated Service 2.1 Power Up Upon powering up, the mobile host (MH) detects the beacon signals from the surrounding base stations (BSs), and selects the BS with the strongest signal as its serving BS. From the BS’s address, the MH knows whether it is in its home domain or not. If the MH is in the home domain, it sends a MIP registration message to the Home Agent (HA). After receiving the MIP registration message, the HA creates an entry for the MH in its Label Forwarding Information Base (LFIB), the entry for the MH is as shown in Table 11. I/F i-if-0

I/L i-1

FEC 1.1.1/24

O/F o-if-1

O/L -

S 0

T -

Note CHÆHA

Table 1. LFIB in Home Agent

In this case, in the downlink direction, there is only one MPLS LSP segment for the MH, from the correspondence host (CH) to MH. In the uplink direction, the HA has a LSP to the CH’s label switch router (LSR). Here the Label Distribution Protocol (LDP) [8] can be used to establish the downlink and uplink LSPs. One observation about MPLS supporting DiffServ is that, in a network that supports fewer than eight per hop behavior (PHBs), the Exp field is sufficient, and one LSP can be used for all PHBs based on the E-LSP method. Just as a conventional DiffServ router maintains a mapping from the possible values of the DiffServ code point (DSCP) to the PHBs it supports, a LSR can maintain a mapping from Exp values to PHBs. When the number of service classes is greater than eight, L-LSP is used. Usually, eight PHBs are enough for the network to provide DiffServ, so in our architecture we assume that E-LSP is used. Note that in DiffServ mode each LSR only has one LSP for any LSR with which it communicates directly, shared by all PHBs. Like the downlink LSP, there is an uplink LSP from the HA to the CH established by the LDP. If the MH is not in the home domain, it sends a MIP registration message to the HA to inform it of the foreign domain it is visiting. The HA then sets the segmented flag (S) in the entry for all the downlink LSPs the HA will communicate on. At the same time, the HA puts the MH’s address in the FEC column of the entry for the LSP to the gateway (GA). This LSP can be setup via LDP. After registration, in the HA’s LFIB, the entry for the MH is as illustrated in Table 2. I/F i-if-0 -

I/L i-1 -

FEC 1.1.1/24 Gateway 1.1.1.1/32

O/F o-if-1 o-if-2 o-if-2

O/L o-2 o-2

S 1 0 0

T -

Note CHÆHA HAÆGA HAÆGA

Table 2. HA’s LFIB when MH moves out of home domain 1

I/F: Incoming interface; I/L: Incoming Label; O/F: Outgoing interface; O/L: Outgoing Label; S: Segmented flag; T: Timer; FEC: Forward Equivalence Class

Upon powering up, the MH also sends a MIP registration message to the GA to inform it about the BS serving the MH. After receiving the registration message from the MH, the GA puts the MH’s address in the FEC column of the entry for the LSP to the BS serving the MH. This is illustrated in Table 3. I/F i-if-1

I/L i-if-0

FEC Gateway

O/F -

O/L -

S 1

T -

Note HAÆGA

-

-

BS2 1.1.1.1

o-if-1 o-if-1

o-2 o-2

0 0

Tactive time

GAÆBS2 GAÆBS2

Table 3 Downlink LSP in LFIB in gateway

In our architecture, we uses the Tactive time to decide whether user is active or not since there is no counterpart concept of “busy” for traditional circuit switch network in IP network which is connection-less oriented, so you cannot explicitly know whether the user is in active or idle. When user have a data to send or to arrival, it starts the Tactive time, each data packet refresh the Tactive time, when the timer expires, the network thinks the user is “idle”. Ingress LSR

Home Agent

LSP segment 1

LSP Segment 2

LSP segment

Gateway CH

BS 1

BS 2

MH

Figure 1.

BS 4

BS 3

CH

MH 2

DiffServ support

2.2 Packet Forwarding In the downlink direction, if a CH wants to communicate with the MH, the CH first uses the pre-configured LSP between the CH’s LSR and the MH’s HA. The HA checks the segmented flag in the LFIB and knows that the MH has moved away from the home domain. After striping the label and getting the destination address, the HA again uses the destination address as index to look for the LSP for the MH, then uses this LSP to reach the GA using the normal label forwarding scheme. The GA strips the label for the LSP from the HA and checks the segmented flag in the label. If the segmented flag is set, the GA then uses the destination address as an index to look for the LSP to the BS serving the MH. Finally, the BS strips the label, uses the destination address in the IP 2 To prevent from cluttering the figure, interface is ignored. Please note that our architecture can accommodate any network topologies, here tree network is just used for illustration.

packet header as an index to look for the MH’s physical identity in its IP address-physical link table, and sends the packet to the MH via the wireless physical link. From the above description, we see that there are 3 LSP segments from the CH to the MH: CH’s LSR to HA, HA to GA, and GA to MH’s current BS. In the HA and GA, the segmented flag is set to indicate the need for two LFIB look-up to forward each packet from the CH to the MH. In the uplink direction, from the MH to the CH, there are two LSP segments: one from the MH’s BS to the GA, and the other from GA to CH’s LSR. Unlike the downlink direction where the LSP is determined by the destination address, in the uplink direction, all packets from the MH will be passed to the GA for forwarding to the destination. Each BS has an uplink LSP to the GA with the segmented flag set. When the MH has a packet to send to a CH, the packet is first forwarded via the serving BS’s LSP to the GA. The GA checks the segmented flag in the LFIB, strips the label, and if the segmented flag is set, uses the destination (CH’s) address in the IP header as an index to look up the LFIB and get the label of the LSP from the GA to the CH’s LSR. Finally, the packet is forwarded to the CH on the latter LSP. Thus, in the uplink direction, packets will traverse two LSP segments, one from the MH to the GA and the other from the GA to the CH’s LSR.

2.3 Handoff When a MH handoffs from one BS to another in the same domain, e.g., moving from BS2 to BS3 in Figure 1, the MH informs the GA of the new BS via route-update; at the same time the MH also informs the old BS of new BS serving the MH so that the old BS can forward packets for the MH to the new BS. Upon receiving the route-update message, the GA updates the entry for the MH in its LFIB, puts the MH on the FEC column of the entry for the new BS, BS3. The updated entries of the LFIB in the GA are illustrated in Table 4. I/F i-if-0 -

I/L i-0 -

FEC Gateway BS2 BS3 1.1.1.1

O/F o-if-1 o-if-2 o-if-2

O/L o-2 o-3 o-3

S 1 0 0 0

T Tactive time

Note HAÆGA GAÆBS2 GAÆBS3 GAÆBS3

Table 4. LFIB in new BS after domain handoff

Upon receiving the route-update message from the MH, the old BS adds an entry for the MH by adding the MH’s address to the FEC column of the entry for the new BS and starts the active timer Tactive time. At the same time, it sets the segmented flag to 1 in the entry for the LSP from the GA to itself and starts Tactive time. The updated entries of the LFIB in the old BS, BS2, are shown in Table 5. I/F i-if-0 -

I/L i-1 -

FEC BS2 BS3 MH

O/F o-if-1 o-if-1

O/L o-2 0-2

S 1 0 0

T Tactive time Tactive time

Note GAÆBS2 BS2ÆBS3 BS2ÆBS3

From this point on, the old BS will divert packets destined for the MH to the new BS on the appropriate LSP until the timer Tactive time expires. Each forwarded packets will refresh the Tactive time timer. If Tactive time times out, then the old BS will reset the segmented flag and clear the MH’s entry in its LFIB. The handoff process is illustrated in Figure 1.

3.

3.1 Power Up Upon powering up, the MH detects the beacon signals from the surrounding BSs, and selects the BS with the strongest signal as its serving BS. From the identity of the BS, the MH then determines whether it is in the home domain. If the MH is not in the home domain, it sends a MIP registration message to the HA via the GA to inform the HA and GA where it resides. After receiving the MIP registration message, the HA constructs an Explicit Route to the GA that includes the sequence of routers to traverse from HA to GA, and keeps the mapping between Explicit Route and GA in its Explicit Route Object Information Base (EROIB). At the same time, the HA puts the MH’s address in the destination address column of the entry for the GA in the EROIB. The GA also puts the MH’s address in the destination address column of the EROIB entry for the MH’s serving BS, i.e., BS2 in Figure 2. The EROIB entries for the MH in the HA and GA are illustrated in Table 6. The Explicit Route can be derived using Open Short Path First-Traffic Engineering extension (OSPFTE) [9]. Node HA HA GA GA

Destination address GA’s address MH’s address BS-2’s address MH’s address

ERO ERO-2 ERO-2 ERO-3 ERO-3

Timer -

Note HAÆGA HAÆGA GAÆBS2 GAÆBS2

Table 6. EROIB in GA and HA after registration

3.2 LSP Setup If a CH wants to communicate with a MH that is away from its home domain and is served by in BS2 (see Figure 2), the CH first requests to reserve the required resource by sending an RSVP message to the MH. The RSVP message is routed to the MH hop by hop via constraintbased routing [5] instead of plain IP routing3. In the constraint-based routing, RSVP is augmented by a new object, the Explicit Route Object (ERO). This object is carried in the PATH message and contains the explicit route that the message will take. The PATH message also includes a LABEL_REQUEST object. Forwarding of such a message by a router is determined not by the destination address in the IP header of the packet that carries the message, but rather by the content of the ERO 3

Table 5. LFIB in the old base station BS2 after handoff

Integrated Service

Here, we refer to conventional IP routing as plain IP routing to make a clear seperation from the constraint-based IP routing.

GA crosses, as shown in the Figure 2, LSR 2, noted as COLSR (Cross Over LSR - in the worst case, the GA is COLSR), simply uses the previously allocated label for the micro-flow as the outgoing label and grabs the existing LSP between the COLSR and the GA for use as part of the route between the new BS and the GA. We called this process LSP grab. PATH (ERO1) LSR1

Home Agent

RESV (5)

EROIB

PATH(ERO2) CH

LSR4

PATH (ERO3)

RESV(4) LSR3

X

PATH (ERO3)

RESV(1)

EROIB IP address ERO3

RESV(3) COLSR

LSR2 RESV(2)

IP address ERO2

Gateway

PATH(ERO3)

X

carried in the message. After the RSVP PATH message reaches the HA, the HA uses the destination address in the IP header as index in its EROIB to check whether it has another ERO for this address or not; if yes, it replaces the ERO in the EROIB. Like label swapping, we call this process ERO swapping. Note that ERO swapping occurs in the RSVP label setup phase whereas label swapping occurs in the packet forwarding phase. From this point on, the PATH message is routed to the GA according to the new ERO. In the GA, the same process applies, swapping the ERO for the MH and sending the PATH to the next hop designated by the new ERO. In this way, the RSVP PATH message can be routed to the BS for delivery to the MH. After receiving the RSVP PATH message, the MH replies with a RSVP RESV message to the serving BS, which allocates a label for this micro-flow and reserves corresponding resource to meet the QoS requirement for the micro-flow. Then the hosting BS uses the label to construct a LABEL MAPPING object for including in the RSVP RESV message that it sends to the next hop designated by the ERO. This process repeats in each node between the CH and the serving BS, allocating a label as the outgoing label, constructing the LABEL-MAPPING object and sending the RESV message to the next hop designated by the ERO. Table 7 gives an example of the labels in each LSR.

RESV(5) BS 2

BS 1

BS 3

BS 4

MH

MH

Figure 2. Handoff in IntServ Node LSR1 HA GA LSR2 LSR3 BS2

I/L i-5 i-4 i-3 i-2 i-1

I/F i-if-0 i-if-0 i-if-0 i-if-0 i-if-0

FEC FEC1 FEC1 FEC1 FEC1 FEC1 FEC1

O/L o-5 o-4 o-3 o-2 o-1 -

O/F o-if-0 o-if-0 o-if-0 o-if-0 o-if-0 -

S 0 0 0 0 0 0

Timer Tactive time Tactive time Tactive time Tactive time Tactive time Tactive time

Table 7. Downlink LSP for FEC1

Here, FEC1 is a five tuple consisting of . Usually, the protocol is UDP. So, the LSP from the CH to the MH is: ÆÆÆÆ. The uplink LSP for the MH to CH is set up like the downlink LSP with the only difference being that ERO swapping occurs only once in the GA compared to twice in the downlink LSP setup process.

3.3 Handoff When the MH determines that a handoff has occurred in the same domain, say from BS2 to BS1 in Figure 2, it informs the GA of its current location and requests to reserve the same resource from the GA to the new BS for this micro-flow. This works as follows. The new BS allocates a label for the micro-flow, uses it to construct a LABLE-MAPPING object that it puts in the RSVP RESV message for transmission to the next hop designated by the ERO the GA. Each LSR on the Explicit Route from the new BS to the GA receiving the RSVP RESV message applies the same process. Here, when the RESV message reaches a node where the Explicit Route for the new BS to GA and the Explicit Route for the old BS to the

Node LSR1 HA GA LSR2 LSR4 BS1

I/L 5 4 3 2 1

I/F i-if-0 i-if-0 i-if-0 i-if-0 i-if-0

FEC FEC1 FEC1 FEC1 FEC1 FEC1 FEC1

O/L 5 4 3 2 1 -

O/F o-if-0 o-if-0 o-if-0 o-if-1 o-if-0 -

S 0 0 0 0 0 0

T -

Table 8. LSP for micro-flow after handoff

From Table 8, we can obtain the new LSP for the microflow as: ÆÆÆÆ. Since the micro-flow has stringent requirements on latency, the old BS does not need to be concerned with forwarding packets to the new BS.

4. Paging In order to reduce the power consumption of MHs and signaling load in the access network caused by periodic route updates, we propose to employ paging in our mobility management architecture. The whole domain is divided into differently paging areas. When an idle MH crosses a cell boundary but stays within the same paging area, it needs not send a route-update message to the GA to report its location; thus the GA only keeps approximate location information for the MH given by the current paging area. For each paging area, there is a Paging Area Root (PAR), the root node for the multicast tree formed by all the cells within the paging area. Currently, only Protocol Independent Multicast (PIM) is being considered for multicasting in MPLS [10]. Thus we use PIM to

multicast a paging message to the MH when its accurate location needs to be determined for packet reception. When a MH crosses a paging boundary while in idle state, it should report its current paging area to the GA using a route-update message. When the MH is in active state, its accurate location is reported to the GA upon every cell boundary crossing. We use the DiffServ as an illustration, and assume that the LSP between the CH and HA has been configured with segmented flag on. In order to discriminate between active and idle states, we divide the LFIB into two parts, the active LFIB for active MHs, and the idle LFIB for the idle MHs. The only difference in these two LFIBs is that in the active LFIB, the MH’s address is put in the FEC column of the entry for the current BS serving the MH, whereas in the idle LFIB, the MH’s address is put in the FEC column of the entry for the PAR of the current paging area in which the MH currently resides. The active and idle LFIBs are illustrated in Tables 9 and 10, respectively. I/F i-if-0 -

I/L 1 -

FEC HA BS1 BS2 BS3 BS4

O/F o-if-0 o-if-0 o-if-1 o-if-1

O/L o-1 o-2 o-3 o-4

S flag 1 0 0 0 0

T -

Note CHÆHA HAÆBS1 HAÆBS2 HAÆBS3 HAÆBS4

Table 9. Active LFIB in HA I/F -

I/L -

FEC PAR1 idle MH PAR2

O/F o-if-0 o-if-0 o-if-1

O/L o-5 o-5 o-6

S 0 0 0

T -

Note HAÆPAR 1 HAÆPAR1 HAÆPAR2

Table 10. Idle LFIB in HA

After receiving the first packet from a CH destined for a MH, the HA checks the segmented flag in its active LFIB using the incoming label as an index; if the segmented flag is set, the HA strips the incoming label and checks whether the MH is active or idle by searching its active LFIB. If the HA cannot find the MH in the active LFIB, the HA buffers the first packet and sends a paging packet to the PAR via the LSP indicated in the idle LFIB. Upon receiving the paging packet, the PAR multicasts the paging packet to the BSs within the paging area using PIM in MPLS. When the MH receives the paging packets, it sends a paging response to the HA directly via the LSP pre-established to the HA. The HA puts the MH’s address in the FEC column for the serving BS indicated by the MH, say BS2 in Figure 2, in its active LFIB. After paging the HA’s active LFIB entries are shown in Table 11. I/F i-if-0 -

I/L 1 -

FEC HA BS2 MH

O/F o-if-0 o-if-0

Table 11.

O/L o-2 o-2

S 1 0 0

T Tactive time

Active LFIB after paging

Note CHÆHA HAÆBS2 HAÆBS2

5. Route Optimization In the MPLS-based IP mobility scheme described above, all packets from a MH are routed to the destination via the GA regardless of whether the destination is in the same domain or not. Normally, when a MH moves to another domain, most of its traffic is exchanged with hosts in the same domain. In order to reduce the load of the GA and shorten the latency, when the MH communicates with a CH in the same domain, the traffic should not traverse the GA. We called this route optimization. When a MH wants to send a packet to a CH, the first packet uses the default LSP from the BS to GA to reach the GA. The GA then strips the label and uses the destination address in the IP header as an index to look up the LFIB. If the destination is also in the LFIB, it means that the CH is in the same domain as the MH. The GA then informs the MH the BS serving the CH (assuming it is also mobile) by means of a route-notification message. At the same time, the GA also sends a route-notification message to the CH to identify the BS serving the MH. Upon receiving the GA’s notification, the MH’s serving BS puts the CH’s address in the FEC column of the entry for the CH’s serving BS in its LFIB and starts the associated timer Tactive time. Subsequently, all packets will follow the LSP between the BSs serving the MH and the CH. The same updating process takes place at the LFIB of the BS serving the CH. Here, we use the DiffServ mode as an illustration. For example, in Figure 1, the MH served by BS3 wants to communicate with the CH served by BS4. After the route optimization process, the relevant entries in the LFIBs in BS3 and BS4 are shown in Tables 12 and 13, respectively. I/F -

I/L -

FEC Gateway BS1 BS2 BS4 CH

O/F o-if-1 o-if-1 o-if-1 o-if-1 o-if-1

O/L 1 o-1 o-2 o-3 0-3

S 0 0 0 0 0

Timer Tactive-time

Note BS3ÆGA BS3ÆBS1 BS3ÆBS2 BS3ÆBS4 BS3ÆBS4

Table 12. LFIB in BS3 after route-optimization I/F -

I/L -

FEC Gateway BS1 BS2 BS3 MH

O/F o-if-1 o-if-1 o-if-1 o-if-1 o-if-1

O/L 1 o-1 o-2 o-3 0-3

S 0 0 0 0 0

Timer Tactive time

Note BS4ÆGA BS4ÆBS1 BS4ÆBS2 BS4ÆBS3 BS4ÆBS3

Table 13 LFIB in BS4 after route-optimization

While the above method facilitates route optimization, it leads to a problem in refreshing the location information of the MH and CH in the GA. With route optimization, packets between the CH and MH no longer traverse the GA, thus no information is available to refresh the location state in the GA, resulting in possible inconsistency in the MH’s state in the GA and the actual

state of the MH and the possibility of unnecessary paging events. One possible solution to this problem is to have the MH/CH periodically send a route-refresh message to the GA to refresh its state, when the MH/CH is in active state as designated by the Tactive time timer. This keeps the state in the GA consistent with the actual state of the MH/CH while minimizing the access network’s traffic load due to route refresh. When the MH hands off to a new BS during active state, the new BS needs to be informed about the BS serving the CH and vice versa. The following four steps ensure that route-optimization is maintained after a handoff. Step-1: The MH sends a route-update message to inform the GA of the new BS serving the MH. Step-2: The MH notifies the old BS about the new BS. Step-3: The old BS notifies each CH’s serving BS of the MH’s new BS, so that each CH’s serving BS can install a path from the CH to MH by adding the MH’s address to the FEC column of the entry for the MH’s new BS. Step-4: The old BS notifies new BS of each CH’s serving BS so that the new BS can install a path from the MH to each CH by adding the CH’s address to the FEC column of the entry for the CH’s serving BS.

6. Summary In this paper, we have proposed an architecture applying MPLS in an integrated macro- and micro-mobility management environment. In order to cope with terminal mobility, we propose novel segmented LSP to support DiffServ and ERO swapping in the LSP setup phase to support IntServ. In addition, routing optimization and paging methods have been proposed to reduce signaling load in the access network and minimize the power consumption of MHs. Further work on quantitative analysis of route optimization, location management cost, etc., is in progress.

Acknowledgments This work was supported by a grant from Motorola Canada Ltd. and by the Canadian Natural Sciences and Engineering Research Council under grant CRDPJ 223095-98.

Reference [1] C. Perkins, Ed., IP Mobility Support, IETF RFC 2002, Oct, 1996 [2] A. Campbell et. al., Design, implementation and evaluation of cellular IP, IEEE Personal Communication, Aug.2000

[3] R. Prasad et. al., IP-Based Access Network Infrastructure for Next-Generation Wireless Data Networks, IEEE Personal Communications, August 2000. [4] S. Das et. al., TeleMIP: telecommunication-enhanced mobile IP architecture for fast intra-domain mobility, IEEE Personal Communications, August 2000. [5] B. Davie and Y. Rekhter, MPLS Technology and Application (Morgan Kaufmann Publishers, 2000). [6] Z. Ren, et. al., Integration of Mobile IP and MultiProtocol Label Switching, ICC 2001 Helsinki, Finland. [7] H. Kim, et. al., Mobility-Aware MPLS in IP-based Wireless Access Networks, IEEE Globecom 2001, San Antonio, TX, 2001 [8] LDP Specification, IETF RFC 3036, January 2001 [9] OSPF-TE: http://www.ietf.org/internet-drafts/draftsrisures-ospf-te-01.txt [10] Framework for IP Multicast in MPLS, draft-ietfmpls-multicast-07.txt, January 2002