Internet DRAFT - draft-choi-mobileip-ldpext
draft-choi-mobileip-ldpext
Internet Draft Jun Kyun Choi (ICU)
Document: draft-choi-mobileip-ldpext-03.txt Tai Won Um (ICU)
Expiration Date: May 2002 Yoo Kyoung Lee (ETRI)
Sun Hee Yang (ETRI)
November 2001
Extension of LDP for Mobile IP Service
through the MPLS Network
<draft-choi-mobileip-ldpext-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 such as CR-LDP and RSVP-TE 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.
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].
Choi et al. Internet-Draft May 2002 [Page 1]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
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
2.5. Interoperability with Micro-mobility Solutions
3. Description of the Protocol
3.1. General Assumptions
3.2. LSP Tunnels for Mobility Support
3.3. Agent Advertisement and Solicitation
3.4. Registration and LSP setup for Mobile Node
3.5. Handoff and LSP Re-routing
4. Required Messages and TLVs
4.1 Required Messages and TLVs
5. IANA Considerations
6. Security Considerations
7. References
8. Author's Addresses
9. Full Copyright Statement
Choi, et al. Internet-Draft May 2002 [Page 2]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
1. Introduction
A mobile node of a Mobile IP network may be connected to foreign
Mobile IP networks with a distance. The Multiprotocol Label Switching
(MPLS) network can provide the backbone solution for high speed IP
forwarding. The relevant label switched paths (LSPs) 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 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 foreign agent or regional
foreign agent could be defined on the MPLS network [4].
For the control procedure, the label distribution protocol such
as CR-LDP and RSVP-TE may be used to set up the 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 MPLS protocol can be applied on the Mobile IP network according
to geographical area and routing path to forward packets from home
agent to foreign agent. There may be three types of scenarios
according to the functionality of Mobile IP protocol in the MPLS-
based network. Scenario 1 applies basic Mobile IP protocol [5] to
MPLS-based network. This scheme uses natural extension of the
existing Mobile IP protocol through the MPLS network. Scenario 2
applies Mobile IP Route Optimization protocol [12] to MPLS-based
network. In this scheme, an ingress LER must intercept the incoming
IP packets to forward the destination foreign agent through the
established LSP. Scenario 3 applies hierarchical Mobile IP protocol
[4] to MPLS-based network. This scheme performs regional registration
locally and LSP re-routing method in a visited domain. In the above
schemes, The MPLS network provides the LSP tunnels replaced by the
IP-in-IP tunnels.
Scenario 1 (MPLS-based Mobile IP) is based on the existing scenario
of Mobile IP service and the home agent and foreign agent should be
located at the LER [5],[6]. In this scenario, the IP-in-IP tunnels
between home agent and foreign agent could be done with help of the
Choi, et al. Internet-Draft May 2002 [Page 3]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
CR-LDP/RSVP-TE operation. There are no additional constraints on
the existing protocols of Mobile IP.
Scenario 2 (MPLS-based Mobile IP Route Optimization) applies Mobile
IP Route Optimization [12] to MPLS-based network. A Mobile IP using
Route Optimization defines Route Optimization messages and extensions
to the base protocol to optimize datagram routing to a mobile node.
using MPLS-based Mobile IP Route Optimization, Ingress LER may cache
the binding of a mobile node, and then tunnel datagrams through the
established LSP for the mobile node directly to the care-of address,
bypassing the mobile node's home agent. This scenario are also
provided to allow datagrams in flight when a mobile node moves, and
datagrams sent based on an out-of-date cached binding, to be
forwarded directly to the mobile node's new binding by using LSP
extension method. In this scheme, the forwarding path should be pre-
calculated by query process. The cache imposition or label binding
operation may be done at the LER/FA.
Scenario 3 (MPLS-based Hierarchical Mobile IP) applies Hierarchical
Mobile IP [4] to MPLS-based network The Hierarchical Mobile IP scheme
introduced in Mobile IP Regional Registration allows a mobile node to
perform registrations locally with a gateway foreign agent (GFA) in
order to reduce the number of signaling messages to the home network.
This achieves a reduction in the signaling delay when a mobile node
moves between foreign agents and therefore improves the performance
of such handoffs. In the MPLS-based Hierarchical Mobile IP scenario,
when a mobile node migrates to the adjacent subnet, it performs
regional registration and partial LSP re-establishment method. In the
partial LSP re-establishment method, a LSP between anchor foreign
agent and new foreign agent is established newly and existing LSP
between home agent and foreign agent remains. So it should reduce LSP
setup latency than conventional integration of Mobile IP and MPLS.
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 home agent and the corresponding foreign agent through
the MPLS network. While a node tries to call the mobile node, data
forwarding path with help of home agent should be established between
the source LER and the destination LERs. The LSP by the LDP operation
would enable to label the IP packets and forwards them at the
destination mobile node via the MPLS network.
In the QoS signaling protocol such as RSVP, if the care-of address
changes upon handover, it will cause double reservations on the part
of end-to-end path that remains unchanged after handover [15]. However,
in this MPLS based Mobile IP schemes, packet stream is not distinguished
by the care-of address but by the label. So, although the care-of address
is changed after a mobile node migrates to the adjacent subnet, packets
can be send through the existing label switched path from the HA to the
anchor LSR by using the label swapping method and the label switched
path between anchor LSR and new FA will be just established.
Choi, et al. Internet-Draft May 2002 [Page 4]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
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 are 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
foreign agent to identify the visiting mobile nodes. In case that
a number of foreign agents are in a Mobile IP network, the foreign
agent attached to the LER has a responsibility to communicate to
the external world.
- The home agent should be located at the LER. If a small-scale
Mobile IP network already has a number of home agents to cover
their own regional area, it should discriminate from the
home agents interfaced to the MPLS network[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).
- We assume that the HAs and FAs support security associations
Depending on the functionalities of Mobile IP protocols on the MPLS
network, the following assumptions are required.
- In Scenario 1 (MPLS-based Mobile IP), all the LERs have to operate
the home agent. It means that a mobile node should be identified
both from the home agent and the foreign agent at visiting area
while moving to foreign area [5],[6].
- When a node sends the IP packets to the mobile node, the LER with
home agent intercepts and forward them to the corresponding LER/FA
on temporarily visiting area.
- In Scenario 2 (MPLS-based Mobile IP Route Optimization), we assume
that the data forwarding paths should be pre-calculated at the
originating LER.
- In Scenario 3 (MPLS-based Mobile IP Regional Registration), we
assume that the foreign agents support Regional Registration and
security associations have been established among a Gateway
foreign Agent (GFA) and all the foreign agents beneath it in the
hierarchy.
- HA, FA and GFA work LER, and RFA works LSR. If home agent and GFA
are located in seperated MPLS network, then labeled packets from
home agent to GFA must be tunneled through the public MPLS network.
- 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). The BS is connected to the
LER to support mobility.
Choi, et al. Internet-Draft May 2002 [Page 5]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
2.2. Network Architecture and Service Scenarios
2.2.1. MPLS-based Mobile IP Scenario
In this section, we propose 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 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 home agent to the egress LER to the foreign mobile node.
The whole forwarding process is done at the MPLS layer. The home
agent 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 home agent to foreign agent 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 CR-LDP or RSVP-TE [9],[10].
Figure 1 shows the MPLS network architecture using Scenario 1 (MPLS-
based Mobile IP). In this scenario, a home agent is located at the
LER1 and has a capability to intercept IP packets for a mobile node.
When a mobile node from the LER2/HA area is temporarily moving to the
LER3 area, the registration is required to home agent via LER3/FA1.
When a correspondent node at LER1 sends IP packets to a current
mobile node, the LSP tunnels would be established from LER1 to
LER2/HA and cascading from LER2/HA to LER3/FA1. 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 may 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 LER3. 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
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.
Choi, et al. Internet-Draft May 2002 [Page 6]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
+----+
+--+ +----+ | HA |
|CN|-------+LER1+xxxxxxxxxxxxx+LER2|
+--+ +----+ ++--++
x \
x \
x \
+---++ ++---+
|LSR1| |LSR2|
++--++ +---++
/ x \
/ x \
/ x \
+----+ +----+ +--+-+
| FA1| | FA2| | FA3|
|LER3| |LER4| |LER5|
+-+--+ +-+--+ +----+
| |
| |
+--+ +--+
|MN| ----> |MN|
+--+ +--+
xxx : Label Switched Path
--- : Route using normal hop-by-hop packet forwarding
LER: Label Edge Router
LSR: Label Switching Router
HA: Home Agent
FA: Foreign Agent
MN: Mobile Node
CN: Correspondent Node
Figure 1. The MPLS Network Architecture with Mobility Support
(Scenario 1 : MPLS-based Mobile IP)
In this scenario, the functions of mobile agents can be located in
the LERs. The LSPs can be setup the same way as "tunnels" are setup
between home agent and foreign agents. In addition it allows
constrained based routing and the QoS path between the agents can be
guaranteed.
2.2.2. MPLS-based Mobile IP Route Optimization Scenario
The Route Optimization scheme introduced Route Optimization in Mobile
IP [12] defines Route Optimization messages and extensions to the
base protocol to optimize datagram routing to a mobile node. This
section provides for a number of additions to Route Optimization in
Mobile IP in terms of functionalities of the MPLS protocol.
It is preferable of case that the forwarding path from ingress LER
should be cut through the egress LER/FA, the care-of address of the
mobile node. For all the cases, the ingress LER should find
Choi, et al. Internet-Draft May 2002 [Page 7]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
forwarding path with relevant query process. For this scenario, it
requires the query process(or binding update) to find the destination
tunnel endpoints on the MPLS network. The LER 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 packets using hop-by-hop
packet forwarding method.
Figure 2 shows the MPLS network architecture using Scenario 2 (MPLS-
based Mobile IP Route Optimization).
+----+
+--+ +----+ | HA |
|CN|--------+LER1+-------+LER2|
+--+ +--+-+ ++-+-+
x / \
x / \
x / \
++--++ +----+
|LSR1| |LSR2|
++--++ +--+-+
/ x \
/ x \
/ x \
+--+-+ +-+--+ +--+-+
| FA1| | FA2| | FA3|
|LER3| |LER4| |LER5|
+-+--+ +-+--+ +----+
| |
| |
+--+ +--+
|MN| ----> |MN|
+--+ +--+
xxx : Label Switched Path
--- : Route using normal hop-by-hop packet forwarding
Figure 2. The MPLS Network Architecture with Mobility Support
(Scenario 2 : MPLS-based Mobile IP Route Optimization)
MPLS-based Mobile IP Route Optimization provides a means for any node
to maintain a binding cache containing the care-of address of one or
more mobile nodes in the Ingress LER. When sending an IP datagram to
a mobile node, if the Ingress LER has a binding cache entry for the
destination mobile node, it may tunnel the datagram directly to the
care-of address indicated in the cached mobility binding by using LDP.
In the absence of any binding cache entry, datagrams destined for a
mobile node will be routed to the mobile node's home network in the
same way as any other IP datagrams, and then tunneled to the mobile
node's current care-of address by the mobile node's home agent. The
original sender of the datagram may be informed of the mobile node's
current mobility binding, giving the sender an opportunity to cache
Choi, et al. Internet-Draft May 2002 [Page 8]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
the binding to optimize this indirect routing of a datagram to a
mobile node. The Binding Update Message which is forwarded to the
correspondent node is intercepted by Ingress LER.
By using the Route Optimization in Mobile IP, The home agent should
then send a Binding Update message to the Ingress LER of
correspondent node, informing it of the mobile node's current
mobility binding. Similarly, when any foreign agent receives a
tunneled datagram, if it has a binding cache entry for the
destination mobile node and thus has no visitor list entry for this
mobile node, the receiving node should send a Binding Warning message
to the mobile node's home agent, advising it to send a Binding Update
message to the Ingress LER that tunneled this datagram.
When sending an IP datagram, if Ingress LER of the sending node has a
binding cache entry for the destination node, it should tunnel the
datagram to the mobile node's care-of address through LSP.
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.
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 foreign agent and new foreign agent to extend
the LSP tunnel. It extends the current LSP by establishing a LSP
between current foreign agent and new foreign agent. During that time,
old foreign agent 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.
2.2.3. MPLS-based Hierarchical Mobile IP network Scenario
If we employ the MPLS-based Mobile IP, whenever it migrates to
adjacent subnet, not only should the mobile node register at the home
agent through the new foreign agent, but also should set LSP up one
more time from the home agent to the foreign agent using a LDP.
Therefore the handover latency is increased, and the signaling
traffic also becomes heavy. If a mobile node migrate high frequency
rate, this scheme induces that signalling bandwidth for registration
and LSP setup is more increased, and packet loss increase during
handover.
The Hierarchical Mobile IPv4 scheme introduced in Mobile IP Regional
Registration [4] allows a mobile node to perform registration locally
in order to reduce the number of signaling message to the home
network. This achieves a reduction in the signaling delay when a
mobile node moves between Foreign Agents and therefore improves the
performance of such handoffs. This section provides for a number of
additions to Hierarchical Mobile IP in terms of functionalities of
the MPLS protocol within the hierarchical domain.
Choi, et al. Internet-Draft May 2002 [Page 9]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
The integration of MPLS and Mobile-IP using Hierarchical foreign
agent that we suggest is shown in Figure 3.
+----+ +----+
| HA | | GFA|
|LER1+xxxxxxxxxxx+LER2|
+-+--+ +-++-+
x x \
x x \
x x \
+--+ +--+-+ +---++ +-+--+
|CN|------+LER3| |RFA1| |RFA2|
+--+ +----+ |LSR1| |LSR2|
++--++ +--+-+
/ x \
/ x \
/ x \
+--+-+ +-+--+ +-+--+
| FA1| | FA2| | FA3|
|LER4| |LER5| |LER6|
++--++ +-+--+ +----+
/ \ \
/ \ \
+-++ ++-+ +-++
|MN| ---> |MN| --> |MN|
+--+ +--+ +--+
xxx : Label Switched Path
--- : Route using normal hop-by-hop packet forwarding
Figure 3. The MPLS Network Architecture with Mobility Support
(Scenario 3 : MPLS-based Hierarchical Mobile IP)
The MPLS-based Hierarchical Mobile IP scheme consists of two major
components: the "MPLS-based Hierarchical Mobile IP architecture" part
which addresses the issues of enhancing MPLS for the support of
terminal and service mobility and the "LSP re-routing schemes" part
which is concerned with handoff.
MPLS-based Hierarchical Mobile IP architecture is constructed to be
distributed the functionality of MPLS based mobility agents to allow
frequent and seamless location management operations while
maintaining ongoing sessions and maximizing data throughput. In this
architecture, the foreign agents are organized into a hierarchy to
handle local movements of mobile nodes within the domain. With a
hierarchy of foreign agents, small changes of location can be handled
by one of the foreign agents in the hierarchy within whose covering
range the mobile node remains. Any correspondent node should be able
to transparently communicate with mobile nodes while mobile nodes are
in the visited networks, that is, without any requirements on the
correspondent nodes.
Choi, et al. Internet-Draft May 2002 [Page 10]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
In the MPLS-based Hierarchical Mobile IP scheme, when a mobile node
migrates to the adjacent subnet, it performs regional registration
and LSP re-routing using partial LSP re-establishment method. In the
partial LSP re-establishment method, LSP between anchor RFA and new
FA is established newly and existing LSP between home agent and
foreign agent remains, where anchor RFA located in upper Hierarchy of
both old foreign agent and new foreign agent. So it should reduce LSP
setup latency than LSP re-establishment method of MPLS-based Mobile
IP scheme.
2.3. Routing Considerations
The routing on the MPLS network is depending on locations of home
agent and foreign agent. In MPLS network, through flow classification,
each flow may be different in grades of service. A 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
The QoS mechanism for Mobile IP should take advantage of a number of
mobility protocols defined in IETF for the optimized operation [15].
This draft proposes three MPLS based Mobile IP schemes such as
MPLS-based Mobile IP, MPLS-based Mobile IP Route Optimization and
MPLS-based Hierarchical Mobile IP. This schemes should support
existing Mobile IP protocol without any additional requirement.
2.5. Interoperability with Micro-mobility Solutions
Because the MPLS protocol operates at the layer two and a half,
it should play a role of "Glue" between layer three protocol of the
Mobile IP working group and layer one or two protocol of the Seamoby
working group.
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, LSP establishment and LSP Extension, etc. Agent
advertisement and discovery procedure is unmodified in the existing
Mobile IP protocol.
It is required to program appropriate QoS support for the MN's
packets in the intermediate network domains, so that the performance
Choi, et al. Internet-Draft May 2002 [Page 11]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
of QoS-sensitive applications running on the MN is maintained at
desired level. To achieve this, our model adopts QoS Object [4] to
interoperate with CR-LDP/RSVP-TE.
In these MPLS-based Mobile IP schemes, wireless IP communicators will
be turned around the clock, ready to receive or initiate services. In
fact, the vast majority of subscribers will not be actively
communicating most of the time. Rather, wireless IP communicators
will be switched on, ready for service, constantly reachable by the
wireless Internet. The MN will be in an idle state but passively
connected to the network infrastructure. Thus design principle is
that only active data are supposed to traverse over QoS guaranteed
LSP. This will prevent LSP abusing that can be caused by lots of
control packets.
If LSP is established for the datagram IP traffic (the UDP traffic),
LSP setup and release repetition would occur because the traffic are
generated sparsely. So our model considers only TCP traffic.
There is no additional Message or TLV/Object on existing CR-LDP/RSVP-
TE to setup QoS guaranteed LSP between CN's LER and MN's LER. The
suggested model adopts data-driven LSP setup.
3.2. LSP Tunnels for Mobility Support
There requires LSP tunnels in the each MPLS-based Mobile IP schemes
The existing LDP specification is well described to establish LSP
tunnels for mobility. The address of home agent and foreign agent for
LSP tunnels will be given by the Registration and Agent Discovery
Procedure within the Mobile IP protocol.
While traditional traffic engineered MPLS are unidirectional,
generalized MPLS [14] supports the establishment of bi-directional
LSP. In our MPLS-based Mobile IP schemes, bi-directional LSP have the
benefit of lower setup latency and lower number of messages required
during setup. It takes only one initiator-eliminator round trip time.
The LSP with QoS constraints is contained in the CR-LDP or RSVP-TE
specification [9],[10].
3.2.1. MPLS-based Mobile IP Scenario
There are LSP tunnels in the MPLS-based Mobile IP network;
- LSP tunnels between the ingress LER and home agent
- LSP tunnels between home agent and egress LER/FA
3.2.2. MPLS-based Mobile IP Route Optimization
There are LSP tunnels in the MPLS-based Mobile IP Route Optimization;
- Direct LSP tunnels between ingress LER and egress LER/FA
- LSP tunnel between old foreign agent and new foreign agent
Choi, et al. Internet-Draft May 2002 [Page 12]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
The tunneling procedure of this model might be different from that of
Scenario 1. When a correspondent node sends packets to a mobile node
located in the foreign area, the ingress LER has to decide the
relevant forwarding path depending on routing information.
3.2.3. MPLS-based Hierarchical Mobile IP Scenario
There are LSP tunnels in the MPLS-based Hierarchical Mobile IP;
- LSP tunnels between the ingress LER and home agent
- LSP tunnels between home agent and GFA
- LSP tunnels between GFA and RFA
- LSP tunnels between RFA and egress LER/FA
The address of GFA, RFA and egress LER/FA for LSP tunnels will be
given by the Registration Procedure within the Mobile IP Regional
Registration [4].
3.3. Agent Advertisement and Solicitation
Agent advertisement and discovery procedure is unmodified in the
existing Mobile IP protocol. 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 Solicitation Message |
| |
|---------------------------------->|
| Agent Advertisemen 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.
3.4. Registration and LSP setup for Mobile Node
3.4.1. MPLS-based Mobile IP scheme Scenario
Choi, et al. Internet-Draft May 2002 [Page 13]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
In the registration procedure, the mobile node determines whether it
is at home or in a foreign network when it receives Agent
Advertisement Messages broadcast by the mobility agents. If the
mobile node determines that it is in a foreign network, the mobile
node acquires a temporary care-of address from foreign agent and
sends a Registration Request to foreign agent. Since foreign agent is
an edge LER, it will analyze the incoming Registration Request
Message and get the destination address of the request. Then, foreign
agent updates its routing table with the value of mobile node 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, foreign agent
forwards the Registration Request Message toward home agent.
MN FA1(LER2) HA
| | |
|---------------------------->| |
| 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) | |
| | |
| ( LSP setup procedure in response to detect packet flow ) |
| | |
| | (no entry between HA and FA)|
| |<-------------------------------|
| | Label Request/Path Message |
| | |
| |------------------------------->|
| | Label Mapping/Resv Message |
| | |
Figure 5. Registration of mobile node at the MPLS-based Mobile IP
network
The Registration Request Message is forwarded to home agent using
normal IP hop-by-hop routing. When home agent gets the Registration
Request Message and learns the care-of address, it sends Registration
Reply Message to the mobile node via foreign agent. In the home agent,
if long lived message exists between same correspondent node and
destination mobile node, then the home agent will send a Label
Request/Path Message to foreign agent with the care-of address
Choi, et al. Internet-Draft May 2002 [Page 14]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
as FEC. A foreign agent replies with an Label Mapping/Resv Message to
the home agent. When this Label Mapping/Resv Message arrives at home agent,
the LSP would have been established.
After that, home agent changes its label table that uses the mobile
node home address as FEC. It sets the outgoing port entries of the
LSP from home agent to foreign agent. In this way, home agent can
relay the packets destined to mobile node home address to its current
location in the foreign network.
When foreign agent receives packets on the LSP, it records the
incoming port number, label value and IP address of the correspondent
node of the packet. Therefore, the foreign agent should send user
packets through the established bi-directional LSP from the mobile
node to the correspondent node because it should know that for which
mobile node the LSP is established.
Packets from a correspondent node to the mobile node are addressed to
the mobile node home address. If the mobile node is located in a
foreign network, packets are intercepted by the home agent. The home
agent uses the incoming label value as an index to look up its label
table. It inserts the label value in the label table into packet and
sends it out through the port indicated in the table. If a mobile
node 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. If a mobile
node is in foreign network and a LSP is established from the home
agent to the foreign agent, then the home agent must send user
packets to the foreign agent by using label swapping method.
3.4.2. MPLS-based Mobile IP Route Optimization Scenario
MPLS-based Mobile IP Route Optimization scheme uses the same
Registration and Advertisement procedure with MPLS-based Mobile IP.
The Registration Request Message is forwarded to home agent using
normal IP hop-by-hop routing. When home agent gets the Registration
Request Message and learns the care-of address, it sends Registration
Reply Message to the mobile node via foreign agent.
Choi, et al. Internet-Draft May 2002 [Page 15]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
MN FA1(LER2) HA Ingress LER CN
| | | | |
|--------------->| | | |
| Agent | | | |
| Solicitation | | | |
|<---------------| | | |
| Agent | | | |
| Advertisement | | | |
| | | | |
|--------------->| | | |
| Registration |---------------->| | |
| Request | Registration | | |
| | Request | | |
| |<----------------| | |
|<---------------| Registration | | |
| Registration | Response | | |
| Response | | | |
| | | | |
| ( Binding Update Procedure of Ingress LER ) |
| | | | |
| | | (no label entry) |
| | | |<-------------|
| | | | User Packets |
| | |<---------------| |
| | | User Packets | |
| |<----------------| | |
| | User Packets |--------------->| |
|<---------------| | Binding Update | |
| User Packets | | | |
| |<---------------------------------| |
| | Label Request/Path Message | |
| | | | |
| |--------------------------------->| |
| | Label Mapping/Resv Message | |
| | | |<-------------|
| | | | User Packets |
| |<---------------------------------| |
| | User Packets (through the LSP) | |
|<---------------| | | |
| User Packets | | | |
| | | | |
Figure 6. Registration and Binding Update at the MPLS-based Mobile IP
Route Optimization
When a mobile node's home agent intercepts a datagram from the home
network and tunnels it to the mobile node, the home agent should then
send a Binding Update Message to the Ingress LER of correspondent
node, informing it of the mobile node's current mobility binding. For
a Binding Update to be authenticated by the Ingress LER of original
correspondent node, the Ingress LER and the home agent must have
established a mobility security association.
Choi, et al. Internet-Draft May 2002 [Page 16]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
When any foreign agent receives a tunneled datagram, if it has a
binding cache entry for the destination mobile node and thus has no
visitor list entry for this mobile node, the node receiving this
tunneled datagram may deduce that the tunneling node has an out-of-
date binding cache entry for this mobile node. In this case, the
receiving node should send a Binding Warning Message to the mobile
node's home agent, advising it to send a Binding Update message to
the Ingress LER that tunneled this datagram. As in the case of a
Binding Update sent by the mobile node's home agent,
Ingress LER may maintain a binding cache to optimize mobile node's
communication with mobile nodes. An Ingress LER may create or update
a binding cache entry for a mobile node only when it has received and
authenticated the mobile node's mobility binding. As before, each
binding in the binding cache also has an associated lifetime,
specified in the Binding Update Message in which the node obtained
the binding. After the expiration of this time period, the binding
is deleted from the cache.
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 MPLS-based Mobile IP Route Optimization
scenario require for further study.
In the absence of any binding cache entry, datagrams destined for a
mobile node will be routed to the mobile node's home network in the
same way as any other IP datagram, and then tunneled to the mobile
node's current care-of address by the mobile node's home agent.
With Binding information received from home agent, Ingress LER
initiates the label binding process to the egress LER/FA to a mobile
node. After that, Ingress LER updates the row in its label table that
uses the care-of address of a mobile node as FEC. It sets a label
value and outgoing port entries.
When a correspondent node sends IP packets to Ingress LER, the
Ingress LER searches for forwarding label entries to the destination
mobile node. If a label entry found, it sends IP packets to the care-
of address of a mobile node through the LSP. If not found, Ingress
LER should send IP packet using normal IP hop-by-hop routing to the
mobile node via home agent.
3.4.3. MPLS-based Hierarchical Mobile IP scheme Scenario
A foreign agent advertises addresses of hierarchical foreign agent in
order between its own address (first) and the GFA address (last) in
the Agent Advertisement. If the mobile node determines that it is in
a foreign network, the mobile node sends a Registration Request, with
the care-of address set to the GFA address announced in the Agent
Advertisement. When the foreign agent closest the mobile node
Choi, et al. Internet-Draft May 2002 [Page 17]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
receives the Regional Registration, because the foreign agent is a
LER, it will analyze the incoming Registration Request message and
relays the Registration Request to the next RFA in the hierarchy
toward the GFA.
The next RFA that is a LSR receives the Registration Request. For
each pending or current registration, an RFA maintains a visitor list
entry. RFA stores mobile node entry its mobile node table, and insert
its own address to the registration packet. This procedure is
repeated to the GFA. When the GFA receives the Registration Request,
it cashes information about the next lower-level RFA in the hierarchy.
It then relays the Registration Request to the home agent. For each
pending or current registration, the GFA maintains a visitor list
entry.
The request message is forwarded to home agent hop-by-hop using
normal IP routing.
When home agent gets the Registration Request message and learns the
care-of address of GFA within the packet, the home agent sends a
Registration Reply to the GFA. When GFA receives the Registration
Reply message, GFA can recognize what the Registration Reply is come
from the specific mobile node that is registered. GFA can know the
lower-level RFA of a registered mobile node by reading the
information of the mobile node entry corresponding to a received
Registration Reply packet. And then GFA sends a Registration Reply to
the RFA. This procedure is repeated in every FA in the hierarchy,
until the Registration Reply message reaches the FA closest to the
mobile node. When the lowest-level FA receives Registration Reply, it
should checks its cached information and relays the Registration
Reply to the mobile node.
Choi, et al. Internet-Draft May 2002 [Page 18]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
MN FA RFA GFA HA
| | | | |
|------------->| | | |
| Registration | | | |
| Request |------------->| | |
| | Registration | | |
| | Request |------------->| |
| | | Registration | |
| | | Request |------------->|
| | | | Registration |
| | | | Request |
| | | |<-------------|
| | | | Registration |
| | |<-------------| Reply |
| | | Registration | |
| |<-------------| Reply | |
| | Registration | | |
|<-------------| Reply | (User packets arrive)
| Registration | | |<-------------|
| Reply | | |Label Req/Path|
| | | |------------->|
| | | |Label Map/Resv|
| | |<-------------| |
| | |Label Req/Path| |
| | |------------->| |
| | |Label Map/Resv| |
| |<-------------| | |
| |Label Req/Path| | |
| |------------->| | |
| |Label Map/Resv| | |
| | | | |
Figure 7. Registration and label establishment procedure
When home agent gets user packets to the mobile node, it will send a
Label Request/Path Message to GFA with the care-of address as
FEC. GFA replies with an label mapping/Resv message to home agent. GFA
should assign labels and keep the Home address of a mobile node and
binding table of a specific label about being registered mobile nodes.
When this Label Mapping/Resv Message arrives at home agent, the LSP would
have been established. Figure 7 shows the registration and LSP
establishment procedure.
After that, a home agent changes the row in its label table that uses
the mobile node home address as FEC. It sets the empty out label and
outgoing port entries to the values of out label and outgoing port.
In this way, home agent can relay the packets destined to mobile node
home address to its GFA in the foreign network. Finally, home agent
sends user packets to GFA along the LSP from home agent to GFA.
Choi, et al. Internet-Draft May 2002 [Page 19]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
When GFA receives the labeled user packets, GFA can recognize what
the Registration Reply is come from the specific mobile node that is
registered after the operation of label pop. GFA writes the label
value attached to user packets on an incoming value of corresponding
mobile node. GFA can know the lower-level RFA of a registered mobile
node by reading the information of the mobile node entry
corresponding to a received user packets. GFA will send a label
request/Path message to next RFA with the care-of address as FEC. RFA
replies with an Label Mapping/Resv Message to the home agent. RFA
should keep the information of binding table and the Home address by
assigning a Label about the registered whole mobile nodes. When this
Label Mapping/Resv Message arrives at GFA, the LSP would have been
established.
After that, GFA changes the row in its label table that uses the
mobile node home address as FEC. It sets the empty out label and
outgoing port entries to the values of out label and outgoing port.
In this way, GFA can relay the packets destined to mobile node home
address from home agent to RFA. Finally, GFA sends user packets to
RFA through the LSP. This procedure is repeated in every FA in the
hierarchy, until the user packets reach the FA closest to the mobile
node.
When the lowest-level FA receives user packets, it should remove its
labels and checks its cached information and relay the user packets
to the mobile node.
If the packet is arrived at ingress LER from a CH, the ingress LER
certifies the destination IP address and find the mapped label in a
label information base (LIB). If a mapped Label is found, the ingress
LER attatchs the label and transmits to downstream LSR. But If the
mapped Label is not found, the ingress LER should set LSP up using
LDP before transmitting packets. The ingress LER transmites the Label
Request Message about host address FEC using Downstream-on-demand
mode to destination IP address of the packet.
The home agent, which receives the Label Request/Path Message about a
mobile node by using Proxy ARP or gratuitous ARP, transmits the Label
Mapping message about home IP address of a mobile node to a upstream
LSR instead of the mobile node. At this time home agent should be
able to recognize the home IP address of corresponding mobile node
using label value that is received from a upstream LSR by the
recorded tabel that is consist of home IP addresses and mapped label.
A home agent records the label about a GFA and a mobile node in label
table, which consists of the upstream LSRs and incoming labels that
are mapped into outgoing labels. The table is composed to be
transmitted to a GFA by swapping the packet about conveyed a mobile
node from ingress LERs through intermediate LSRs. The ingress LER
that receives a packet from a correspondent node recognizes the
destination IP address of the packet and transmits a labeled packet
through corresponding LSP. In the case of the destination IP address
is mobile node, labelled packet is transmitted to a home agent
through a LSP.
Choi, et al. Internet-Draft May 2002 [Page 20]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
In the MPLS Network, the limited label number can make the limitation
of a label distribution. In the case of global network, the
limitation of label number can be fatal. But applying the
piggybacking to the routing protocol to distribute a label about
address prefix can solve the problem. In this case, the FEC in the
network may transmit to an egress LER located on the border. If a
home agent performs as egress LER, the packet can be transmitted to a
home agent, by the reason of merged stream, the home agent can
recognize the mobile node after watching the destination IP address,
that is in the each IP header from FEC. So the delay is larger than
that of using the layer 2 swapping only to transmit to the foreign
agent. Therefore the label distribution method using Host address
prefix is preferred in the MPLS-based Mobile-IP network.
In our MPLS-based Hierarchical Mobile IP scheme, the whole forwarding
process is done at the MPLS layer and home agent and foreign agents
doesn't need to involve the IP layer in forwarding the packet to a
mobile node.
3.5. Handoff and LSP re-routing
3.5.1. MPLS-based Mobile IP scheme Scenario
In the MPLS-based Mobile IP scheme, when mobile node moves from one
foreign agent to another, the registration procedure is repeated once
between the home agent and new foreign agent. The existing LSP should
be changed to the new foreign agent. The following issues are further
considered on the MPLS network.
- LSP rerouting
- LSP extension
- Label binding for the LSP from correspondent node to new
foreign agent
3.5.2. MPLS-based Mobile IP Route Optimization Scenario
IP datagrams intercepted by the home agent after the new registration
are tunneled to the mobile node's new care-of address, but datagrams
in flight that had already been intercepted by the home agent and
tunneled to the old care-of address when the mobile node moved are
likely to be lost.
Route Optimization provides a means for the mobile node's previous
foreign agent to be reliably notified of the mobile node's new
mobility binding, allowing datagrams in flight to the mobile node's
previous foreign agent to be forwarded to its new care-of address.
When old foreign agent received Binding Update Message from the new
foreign agent to notify the mobile node's new location, it looks up
its forwarding information base (FIB) to find a label of mobile node.
If forwarding information base has a label of that mobile node, old
foreign agent set up label switched path with existing traffic
Choi, et al. Internet-Draft May 2002 [Page 21]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
parameters for the mobile node to the new foreign agent. Therefore
existing label switched path from a LER to a foreign agent should be
extended to the new foreign agent.
After signaling messages should be exchanged between old foreign
agent and new foreign agent to extend the LSP tunnel. It extends the
current LSP by establishing a LSP between current foreign agent and
new foreign agent by using above LSP extension method. During that
time, old foreign agent 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.
Any tunneled datagrams for the mobile node that arrive at its
previous foreign agent after the extended LSP has been created can
then be re-tunneled to the mobile node's new care-of address through
the extended LSP.
If there isn't any label to the destination mobile node at the old
foreign agent, the old foreign agent should send user packets which
are received from correspondent node to the new foreign agent by
using IP-in-IP tunneling method.
The MPLS Network
with Mobility Support
Existing
LSP
+---------+ +----+ |
|Home | | HA | +------+ +------+ V +----+ +------+
|Mobile IP+-+LER1+--+ LSR1 +--+ LSR2 +-----+ FA1+----+Old MN|
|Network | +--+-+ +-+----+ +------+ |LER2| +------+
+---------+ \ | +----+ |
\ | Extended| |Handoff
\ | LSP | |
\ | | V
+-+-+--+ +----+ +------+
| LER3 | | FA2+----+New MN|
+---+--+ |LER4| +------+
| +----+
+-+--+
| CN |
+----+
Figure 8. LSP Extension for Mobile IP
Whenever a mobile node migrates to a adjacent subnet, existing LSP
from the ingress LER to the old foreign agent is extended to the new
foreign agent. When an ingress LER receives a Binding Update Message
in response to a Binding Warning Message or Binding Request Message,
the ingress LER should recognize that a destination mobile node
migrate the new foreign agent. However, whenever a destination mobile
node migrates, the ingress LER shouldn't set up new LSP to the new
foreign agent.
Choi, et al. Internet-Draft May 2002 [Page 22]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
When the QoS of LSP tunnel is temporarily degraded, LSP re-
establishment is triggered by the ingress LER. After LSP re-
establishment, the route between ingress LER and new foreign agent
can be optimized. Old path is torn down and new path is set up.
MN New FA Old FA HA ... CN
| | | | |
|-------------->| | | |
| Reg. Request +| | | |
| Binding Update|------------------------------>| |
| | Registration Request | |
| |-------------->| | |
| | Binding Update| | |
| |<--------------| | |
| | Binding Ack. | | |
|<--------------| | | |
| Binding Ack. |<--------------| | |
| |Label Req/Path | | |
| |-------------->| | |
| |Label Map/Resv | | |
| | | | |
| |<------------------------------| |
| | Registration Reply | |
|<--------------| | | |
| Reg. Reply | | | |
Figure 9. Message Sequence for LSP Extension
The LSP extension procedures in Figure 9 are as follows.
- A mobile node moves to a new foreign agent and sends a
Registration Request and Binding Update message to new foreign
agent.
- New foreign agent sends a Registration Request message to home
agent and sends a Binding Update Message to the old foreign agent.
- When the old foreign agent received Binding Update Message, it
responses with Binding Acknowledgement Message to the mobile node
via the new foreign agent. And old foreign agent may send Label
Request Message to the new foreign agent
- A LSP is established between old foreign agent and new foreign
agent when old foreign agent receives Label Mapping/Resv message.
- Then, a home agent sends Registration Reply message in response to
the Registration Request.
3.5.3. MPLS-based Hierarchical Mobile IP Scenario
In a Mobile IP Regional Registration [4], when a handover occurs,
mobile node compares the new vector of care-of address with the old
one. It chooses the lowest-level foreign agent that appears in both
vectors, and sends a Regional Registration Request to that anchor
foreign agent. Any higher-level agent need not be informed of this
movement since the other end of its forwarding LSP tunnel still
points to the current location of the mobile node.
Choi, et al. Internet-Draft May 2002 [Page 23]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
A Registration Request is forwarded to the GFA by way of one or more
intermediate RFA. When the Registration Request message arrives at
the first FA, the foreign agent checks its visitor list to see if
this mobile node is already registered with it. If it is not, the
foreign agent checks which next higher-level RFA to relay the
Registration Request to. The next RFA checks its visitor list to see
if the mobile node is already registered with it. If it is not, the
RFA relays the message to the next higher-level RFA in the hierarchy
toward the GFA.
This process is repeated in each RFA in the hierarchy, until an RFA
recognizes the mobile node as already registered. This RFA may be the
GFA, or any RFA beneath it in the hierarchy.
If the mobile node is already registered with this RFA, it will
transmit the Registration Reply toward the lower-level RFA. When the
lower-level RFA receives the Registration Reply, the RFA is able to
point out the received Registration Reply so that the packet is
associated with which mobile node. The RFA reads the information
about mobile node entry equivalent to received Registration Reply,
and recognizes the mobile node as the registered lower-level one. RFA
will send Registration Reply message to the lower RFA. Above sequence
is repeated up to the new FA of network that mobile node is moved to.
If there is an established LSP about the mobile node to the anchor
RFA, it will send a Label Request/Path Message to the next
lower-level RFA in the hierarchy. The lower-level RFA replies with an
Label Mapping/Resv Message to the upper-level.
The foreign agents should keep the binding table information of a
label and home address of a mobile node about registered whole mobile
nodes by assigning Label. On the all mobile nodes registered to
foreign agent, it is necessary to assign label, and to maintain the
binding table of home address and label of mobile node.
When a Label Mapping/Resv Message from lower-level RFA arrives at upper-
level RFA, the LSP would have been established. After RFA received
the label from the lower-level one, it is necessary to modify the
label mapping/Resv entry on the associated mobile node in the label table.
The incoming label value of label mapping/Resv entry is unchanged as the
received label value form the upper-level RFA, and outgoing label
value is changed into new acquired label value from the new lower-
level RFA through the Regional Registration method.
And then, RFA will send a Label Request/Path Message to next RFA
with the care-of address as FEC. When this Label Mapping/Resv Message
arrives at RFA, the LSP would have been established.
Above sequence is repeated up to the new foreign agent of network
that mobile node is moved to. In this way, the LSP is newly
established from anchor foreign agent to new foreign agent. In this
LSP partial re-establishment method, since the LSP is maintained from
home agent to anchor foreign agent and a new LSP is established from
anchor foreign agent to new foreign agent, the LSP setup time is
reduced compared with the MPLS-based Mobile IP scheme.
Packet is delivered from home agent to new foreign agent along the
LSP by label swapping. New foreign agent receives the packet and
looks up its label table. Since it is the egress of the LSP from home
Choi, et al. Internet-Draft May 2002 [Page 24]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
agent to new foreign agent, home agent strips off the label and sends
the packet to the IP layer. Finally new foreign agent forwards the
packet to mobile node based on the information in the newly added
host specific row of routing table. A mobile node receives the packet
sent by correspondent node. Figure 10 shows a Regional Registration
procedure and a label distribution process from a mobile node to a
RFA.
MN FA RFA GFA HA
| | | | |
|------------->| | | |
| Registration | | | |
| Request |------------->| | |
| | Registration | | |
| | Request | | |
| |<-------------| | |
| | Registration | | |
|<-------------| Request | | |
| Registration | | | |
| Request | | | |
| |<-------------| | |
| |Label Req/Path| | |
| |------------->| | |
| |Label Map/Resv| | |
| | | | |
Figure 10. Regional registration and label distribution
In MPLS-based Hierarchical Mobile IP network, additionally, it is
necessary to clear the registration information on the old foreign
agent and the upper-level RFA, and to release the LSP.
If old locations are not deregistered, it is possible that tunnels
are not correctly redirected when a mobile node moves back to a
previous foreign agent.
The anchor RFA should send a Binding Update with a zero lifetime and
Label Release Message to the previous care-of address it had
registered for the mobile node. Each foreign agent receiving the
Binding Update removes the mobile node from its visitor lists. And
the LSP that is assigned between Upper-level foreign agents is
released. The Binding Update and Label Release Message is relayed
down to the care-of address of the mobile node known to that foreign
agent, and each foreign agent in the hierarchy receiving this
notification removes the mobile node from its visitor list. A LSP
that is established to old foreign agent is released by receiving
binding update and Label Release Messages.
3.5.4 Other Considerations for Handover
At the time of handover, interruption in QoS would occur if the packets
sent by or destined to the MN arrive at the intermediate node without
the information about their QoS forwarding requirement. Such QoS
Choi, et al. Internet-Draft May 2002 [Page 25]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
interruption must be minimized [15]. We consider two schemes, which
should minimize the interruption in QoS. One is the scheme using
multicast LSP. In this method, an anchor LSP establishes a LSP to
the current FA and all FAs in the neighborhoods of the serving FA.
When data arrives for that MN, the anchor LSR will multicast the data
to all the MN's multicast LSP group. If the MN moves to one of the
neighboring BSs, data is immediately available. The other is the method
using bi-directional LSP tunnel between the FA/LER, similar to the
BET [16]. In this scheme, FA/LER will establish bidirectional LSP to
the neighbor FA/LER in advance. If the MN moves to the neighbor subnet,
packets to the MN can be send via bidirectional LSP tunnel between
the FA/LER.
4. Required Messages and TLVs
There is no additional Message or TLV/Object on existing CR-
LDP/RSVP-TE to setup QoS guaranteed LSP between CN's LER and MN's
LER.
4.1 Required Messages and TLVs
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
Choi, et al. Internet-Draft May 2002 [Page 26]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
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 |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
It requires for further study.
5. IANA Considerations
This draft does not create any new number spaces for IANA
administration.
Choi, et al. Internet-Draft May 2002 [Page 27]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
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", RFC 3036, January 2001.
[4] Gustafsson E., et al., "Mobile IP Regional Registration", Internet
draft <draft-ietf-mobileip-reg-tunnel-05.txt, September 2001.
[5] Perkins C., "IP Mobility Support", RFC2002, October 1996.
[6] Perkins C., "IP Mobility Support for IPv4", Internet draft <draft-
ietf-mobileip-rfc2002-bis-02.txt>, July 2000.
[7] Perkins C., "Minimal Encapsulation within IP", RFC 2004, October
1996.
[8] Ren Z., et al., "Integration of Mobile IP and MPLS", Internet draft
<draft-zhong-mobile-ip-mpls-01.txt>, July 2000.
[9] O. Aboul-Magd, et al., "Constraint-based LSP Setup using LDP",
Internet draft <draft-ietf-mpls-crl-ldp-05.txt>, February 2000.
[10] Awduche D. O., et al., "REVP-TE: Extensions to RSVP for LSP
Tunnels", Internet draft <draft-ietf-mpls-rsvp-lsp-tunnel-09.txt>,
August 2001.
[11] Deering S., et al, "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[12] Charles Perkins, et al. "Route Optimization in Mobile IP", Internet
draft <draft-ietf-mobileip-optim-11>, September 2001.
[13] Rivest R. et al., "The MD5 Message-Digest Algorithm", RFC 1321 April
1992.
[14] Ashwood, P. "Generalized MPLS Signaling Functional Description",
Internet draft <draft-ietf-mpls-generalized-signaling-00.txt>,
October, 2000.
[15] Hemant Chaskar, "Requirements of a QoS Solution for Mobile IP",
Internet draft <draft-ietf-mobileip-qos-requirements-01.txt>, August
2001.
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
Choi, et al. Internet-Draft May 2002 [Page 28]
Internet Draft Draft-choi-mobileip-ldpext-03.txt November 2001
Tai Won Um
Information and Communications University (ICU)
58-4 Hwa Ahm Dong, Yusong, Taejon
Korea 305-732
Phone: +82-42-866-6198
Email: twum@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
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.
