Network Working Group O. Berzin
Internet-Draft A. Malis
Expires: May 2, 2008 Verizon Communications
October 30, 2007
Mobility Support Using MPLS and MP-BGP Signaling
draft-berzin-malis-mpls-mobility-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on May 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Berzin & Malis Expires May 2, 2008 [Page 1]
Internet-Draft Mobility Label Based Network October 2007
Abstract
This document describes a new approach to handling user mobility at
the network layer in the context of Multiprotocol Label Switched
Networks (MPLS). This approach does not rely on the existing IP
mobility management protocols such as Mobile IP, and is instead based
on the combination of Multiprotocol BGP (MP-BGP) and MPLS. This
document proposes to introduce new protocol elements to MP-BGP to
achieve Mobility Label distribution at the network control plane and
the optimal packet delivery to the mobile node by the network
forwarding plane using MPLS.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Architecture Requirements . . . . . . . . . . . . . . . . 6
2.2. Existing Solutions . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Mobile IPv6/HMIP/NEMO . . . . . . . . . . . . . . . . 7
2.2.3. MPLS Micro-Mobility . . . . . . . . . . . . . . . . . 7
2.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
2.4. Architecture Overview . . . . . . . . . . . . . . . . . . 8
2.4.1. Node Roles . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2. Attachment Options . . . . . . . . . . . . . . . . . . 10
2.4.3. Network Hierarchy . . . . . . . . . . . . . . . . . . 13
2.4.4. Interface to Other Networks . . . . . . . . . . . . . 13
3. Mobility Support Function . . . . . . . . . . . . . . . . . . 15
3.1. Mobile Node Discovery, Registration and Status . . . . . . 15
3.1.1. Discovery Process - IPv4 . . . . . . . . . . . . . . . 15
3.1.1.1. MSF Discovery by Mobile Hosts - IPv4 . . . . . . . 17
3.1.1.2. MSF Discovery by Mobile Routers - IPv4 . . . . . . 18
3.1.1.3. MSF Advertisement - IPv4 . . . . . . . . . . . . . 18
3.1.2. Discovery Process - IPv6 . . . . . . . . . . . . . . . 20
3.1.2.1. MSF Discovery by Mobile Hosts - IPv6 . . . . . . . 22
3.1.2.2. MSF Discovery by Mobile Routers - IPv6 . . . . . . 22
3.1.2.3. MSF Advertisement - IPv6 . . . . . . . . . . . . . 22
3.1.3. Registration and Status - IPv4 . . . . . . . . . . . . 22
3.1.3.1. Mobile Host Registration - IPv4 . . . . . . . . . 22
3.1.3.1.1. Lightweight Registration - IPv4 . . . . . . . 22
3.1.3.1.2. Full Registration - IPv4 . . . . . . . . . . . 23
3.1.3.1.3. Group Registration - IPv4 . . . . . . . . . . 25
3.1.3.2. Mobile Router Registration - IPv4 . . . . . . . . 29
3.1.3.2.1. Routing Adjacency Establishment . . . . . . . 29
3.1.4. Registration and Status - IPv6 . . . . . . . . . . . . 30
3.2. Integration with MP-BGP . . . . . . . . . . . . . . . . . 30
3.2.1. Mobility Address Family . . . . . . . . . . . . . . . 30
Berzin & Malis Expires May 2, 2008 [Page 2]
Internet-Draft Mobility Label Based Network October 2007
3.2.2. Mobility Bindings . . . . . . . . . . . . . . . . . . 32
3.2.3. Group Registration Management with MP-BGP . . . . . . 34
3.2.4. BGP Capability Advertisement . . . . . . . . . . . . . 37
3.3. Mobile Application Priority Indication and Recognition . . 37
3.4. Application Service Type Indication . . . . . . . . . . . 38
4. Network Update and Hand-off Processing . . . . . . . . . . . . 39
4.1. Network Update Modes . . . . . . . . . . . . . . . . . . . 39
4.1.1. Unsolicited Downstream Push . . . . . . . . . . . . . 39
4.1.2. Selective Downstream Push . . . . . . . . . . . . . . 39
4.1.3. Predictive Downstream Push . . . . . . . . . . . . . . 39
4.1.4. Hierarchical On-Demand Distribution . . . . . . . . . 40
4.1.4.1. On-Demand Requests for Mobility Binding
Information . . . . . . . . . . . . . . . . . . . 40
4.1.5. Network Hierarchy Considerations . . . . . . . . . . . 43
4.1.6. Regionalization and Scalability . . . . . . . . . . . 43
4.1.6.1. Mobility Information Location System (MILS) . . . 44
4.2. Hand-off Processing . . . . . . . . . . . . . . . . . . . 46
4.3. Micro-Mobility Handling . . . . . . . . . . . . . . . . . 47
4.3.1. Local Micro-Mobility . . . . . . . . . . . . . . . . . 47
4.3.2. Group Micro-Mobility . . . . . . . . . . . . . . . . . 47
5. Datagram Delivery . . . . . . . . . . . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 50
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
9. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 53
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.1. Normative References . . . . . . . . . . . . . . . . . . . 54
10.2. Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 57
Berzin & Malis Expires May 2, 2008 [Page 3]
Internet-Draft Mobility Label Based Network October 2007
1. Requirements notation
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 [RFC2119].
Berzin & Malis Expires May 2, 2008 [Page 4]
Internet-Draft Mobility Label Based Network October 2007
2. Introduction
The requirements to support user mobility range from the physical
aspects of wireless access networks to the logical aspects of the
network control and forwarding plane operation. In the context of
this work the main requirement for the mobility support architecture
is to decouple the network layer addressing and the associated
logical network topology from the ability of the network to optimally
deliver the packets to the mobile user. The optimal traffic delivery
is interpreted as the delivery of packets to the new node location
following the best (often the shortest in terms of the routing
protocol metrics) path between the mobile node and the correspondent
node.
The issue is that this optimal path cannot be used by the network to
communicate with the mobile user based on the IP address and routing
protocols. This is due to the inability of a conventional IP network
to react to the mobile user movements by adjusting the routing and
forwarding information in the network nodes (routers) to reflect the
new location of the mobile user with respect to the IP topology.
Thus a method is required to identify the logical location of the
user in the network topology in such a manner that the traffic
delivery to the user at a new location follows the optimal path in
the context of the routing protocol used in the network. A natural
fit to provide this method is the MPLS architecture. MPLS does not
perform the forwarding of IP traffic based on the IP addresses and
uses labels instead. The important point, however, is that MPLS by
itself cannot solve the mobility problem as ultimately the traffic
must originate from the source IP address and terminate at the
destination IP address (which would still be the old home address).
In order to use MPLS to forward the traffic to the new user location
along the optimal path the labels must be assigned specifically to
the mobile node at the new location and distributed to the network
nodes. These special labels are referred to as Mobility Labels and
are associated (bound) to the mobile node IP address.
This document proposes to use the Mobility Label as a second label in
the MPLS label stack. The first label in the stack is the one that
identifies the LSP (Label Switched Path) between the two Label Edge
Routers and the second label in the stack can be used to identify the
IP address of the mobile node and deliver the traffic to it. The
assignment and the distribution of the first label in the stack is
handled by the conventional MPLS architecture elements and protocols
such as LDP (Label Distribution Protocol [RFC5036]). It is proposed
that the assignment and distribution of the second label - the
Mobility Label - be based on the existing framework of MP-BGP
(Multiprotocol Border Gateway Protocol [RFC4760]). The mobility
Berzin & Malis Expires May 2, 2008 [Page 5]
Internet-Draft Mobility Label Based Network October 2007
management scheme based on MP-BGP at the control plane level and MPLS
at the forwarding plane level represents a system in which both the
control and forwarding processes are integrated to ensure the optimal
traffic delivery that is not fully achieved in the existing network
layer mobility management approaches.
2.1. Architecture Requirements
Integrated control and forwarding plane - the network update process
by the Control Plane must result in the optimal traffic delivery by
the Forwarding Plane.
Robust and flexible protocol framework - the Mobility Management
Control Plane Protocol and the associated functions must be placed at
the intelligent network edges and allow to avoid the need to involve
all nodes in the network (including the core nodes) in the network
update process.
The Mobility Management Control Plane Protocol must allow for
flexible and seamless introduction of new features and for support
for Mobile Hosts and Mobile Routers.
Evolutionary architecture and implementation approach - the Mobility
Management scheme should be based as much as possible on the existing
network architectures and protocol framework. Only minimal changes
to the operation of mobile nodes should be expected.
Efficient network responsiveness - the impact on the mobile
application due to the service disruption caused by the mobile node's
movements and the associated network update and delivery processes
should be reasonably minimal.
Acceptable network scalability and performance - the new requirements
for Mobility Management functions should not result in decreased
network scalability and performance.
2.2. Existing Solutions
2.2.1. Mobile IP
Mobile IP [RFC3344] was developed to provide macro mobility
management for the mobile hosts using IP version 4 (IPv4). It was
subsequently extended to support IPv6. Due to its complete reliance
on the logical network topology determined by the distribution of the
IP subnets Mobile IP solves the mobility problem by using the
following two major techniques: mobile node registration and traffic
tunneling. The main entities in Mobile IP are the Mobile Node (MN)
itself, the Correspondent Node (CN) - the host that is communicating
Berzin & Malis Expires May 2, 2008 [Page 6]
Internet-Draft Mobility Label Based Network October 2007
with the MN, the Home Agent (HA) - this is the router that owns the
original home subnet to which the MN is assigned, the Foreign Agent
(FA) - this is the router that owns the subnet to which the MN has
moved (the foreign subnet), and finally the Care-of-Address (CoA) -
the IP address that belongs to the FA and that is used to represent
the MN while it is located in the foreign subnet. The basic mobility
handling by Mobile IP results in a sub-optimal forwarding path in the
direction of traffic from the CN to the new location of the MN. This
is because the traffic is first sent to the HA and then tunneled to
the FA/MN. Although the route optimization scheme exists where the
mobility bindings are sent by the HA directly to the CN with the CoA
of the MN for direct traffic forwarding, it requires the CN to i)
implement the binding processing and ii) use IP tunneling to send
packets to the MN.
2.2.2. Mobile IPv6/HMIP/NEMO
Mobile IPv6 [RFC3775] provides macro-mobility support for IPv6. It
improves Mobile IPv4 by eliminating the need for the FA, use of the
IPv6 neighbor discovery instead of ARP, use of the IPv6 Link Local
(LLOC) address instead of CoA. It also provides basic support for
mobile routers via NEMO (Network Mobility) [RFC3963] and enables
hierarchical mobility management (HMIP). However MIPv6 does not
provide for the integration of the control and forwarding planes and
still requires the use of the HA which results in sub-optimal traffic
routing. The routing optimization based on the direct binding
exchange between the CN and the MN resolves the sub-optimal routing
but introduces the requirement for the return routability procedure
and the use of a special IPv6 routing header (similar in function to
IPv4 tunneling) directly on the CN and MN. In addition, Hierarchical
MIPv6 requires registrations to multiple entities (MAP - Mobility
Anchor Point, HA) and supports IPv6 only.
2.2.3. MPLS Micro-Mobility
MPLS Micro-Mobility [MM-MPLS] integrates MIP and MPLS traffic
forwarding to provide a solution in which MIP is used for macro
mobility management and MPLS is used to support micro-mobility.
Micro-mobility reflects the mobile host movements that can be handled
without the re-registration with the MIP HA. To achieve this, the MN
registers with a hierarchical set of Label Edge Mobility Agents
(LEMA). The LEMA at the top of the hierarchical set is registered
with the MIP HA as the FA for the MN. The MIP HA tunnels all packets
from the CN to the MN to the top level LEMA as in regular MIP. The
LEMA then sends packets on the MPLS LSP to the network location of
the MN using MPLS labels. As the MN moves to new locations, the
hand-off procedures are invoked that start with the MN requesting the
hand-off and the LEMA(s) performing the set of signaling steps
Berzin & Malis Expires May 2, 2008 [Page 7]
Internet-Draft Mobility Label Based Network October 2007
resulting in the redirection of the MPLS LSP from the old serving
LEMA to the new serving LEMA. If the MN movement results in a
condition in which the old top level LEMA can no longer serve the MN,
the MN re-registers with the new hierarchical set of LEMA(s) and the
top level LEMA is registered as the FA with the Mobile IP HA.
Although MPLS Micro-Mobility makes use of the MPLS traffic forwarding
it still is an extension of Mobile IP and therefore does not result
in the elimination of triangular routing.
2.3. Protocol Overview
MP-BGP and its ability to carry the overlay MPLS label information
[RFC3107] is proposed for the mobility management. Namely when the
mobile hosts or routers change their network locations they can
register with the edge nodes of the MPLS network (LER) and at that
time assigned Mobility Labels. The Mobility Labels in turn are
associated with the IP addresses of mobile hosts or routers thus
forming the Mobility Bindings. These Mobility Bindings are then
encoded in the Multiprotocol BGP Address Family messaging structure
and are distributed among the rest of the MPLS network LER nodes
using the MP-BGP protocol. The Mobility Binding provides an explicit
association between the overlay MPLS label and a single or multiple
individual IP addresses of mobile hosts or IP address ranges
(prefixes) that are served by mobile routers. The MP-BGP NEXT_HOP
attribute associated with the BGP UPDATE message [RFC4271] used to
carry the Mobility Binding provides an implicit association between
the overlay Mobility Label and the infrastructure MPLS label that is
in turn associated with the LSP to reach the LER that sourced the
Mobility Binding. The MPLS LER capability to provide mobility
support can be referred to as the Mobility Support Function (MSF)
(see Section 3). The MSF includes: a) Mobile Host/Router Discovery,
Registration and Status Procedures, b) Mobility Label Association and
de-Association Procedures, c) Integration with MP- BGP and d) Mobile
Application Priority Indication and Recognition.
2.4. Architecture Overview
This mobility architecture is proposed in the context of MPLS
networks. As such it is a requirement of this architecture that all
nodes in the network support MPLS control and forwarding plane
procedures and in particular it is a further requirement that the
edge nodes of the MPLS network implement the Mobility Support
Function described in Section 3. This architecture does not rely on
Mobile IP for macro-mobility support. In other words there is no
concept of a home network that the mobile node belongs to and
therefore there is no requirement to register with the Home Agent.
It is the assumption of this architecture that a mobile host or
router is always identified as being in the foreign network thus
Berzin & Malis Expires May 2, 2008 [Page 8]
Internet-Draft Mobility Label Based Network October 2007
always requiring mobility support. In addition, there is no
requirement for the CoA.
The simplest way to implement this assumption is to administratively
allocate a range of IP addresses for all mobile hosts and routers of
an organization and to implement in the MSF the configurable ability
to recognize the pre-allocated mobility address ranges. As such, a
service provider would assign IP addresses to all of their mobile
subscribers from a pre-allocated address range. This range does not
have to be flat and can be in turn subnetted. The IPv4 or IPv6
mobility address pre-allocation scheme allows utilization of this
mobility management architecture as a separate overlay MPLS service.
The only requirement related to the LER MSF pre-configuration is the
static identification of the overall mobility address range in the
scope of the LER-wide MSF.
Regardless of the static identification of the overall address range
allocated to the mobile devices, the individual mobile nodes identify
themselves dynamically to the MSF. This capability is especially
useful when this architecture is applied to provide mobility support
to both mobile hosts and routers. Specifically, during the
registration procedure a mobile node could identify itself as either
a mobile host or a mobile router. If it is a mobile router the MSF
is expected to establish a routing protocol adjacency with the mobile
router as well as to utilize an extended Mobility Binding structure
in which multiple IP prefixes served by the mobile router may be sent
in a single Mobility Binding optionally associated with a single
Mobility Label.
The mobile node must always register with the serving MSF and thus be
associated with the Mobility Label. This requirement will support
the ability to implement specific mobility features such as the
application sensitivity recognition via the processing prioritization
scheme.
2.4.1. Node Roles
From the network architecture perspective the proposed mobility
solution follows the classical MPLS network architecture with two
major node classes: LSR and LER also known as P and PE respectively.
The LER (PE) nodes reside at the edges of the network and perform the
corresponding edge functions such as the customer interface
management, label stack imposition/deposition and label information
distribution for both the infrastructure MPLS transport and the
overlay MPLS services. In addition to these edge functions we
introduce the Mobility Support Function that integrates directly with
the LER control plane responsible for the overlay MPLS services. The
role of the LSR (P) nodes remains exactly the same as in the
Berzin & Malis Expires May 2, 2008 [Page 9]
Internet-Draft Mobility Label Based Network October 2007
classical MPLS architecture - participate in the infrastructure label
distribution process and switch traffic based on the MPLS labels
(outer labels) between the LER nodes. The LSR (P) nodes need not
implement the MSF. Other aspects of the architecture include the
access interface, the interface to other networks and the network
hierarchy.
2.4.2. Attachment Options
The two major access interface options considered here are: Direct
Attachment of the LER node to the Radio Access Network and Indirect
Attachment of the LER node to the Radio Access Network. The terms
direct and indirect are not used to indicate that the LER node has or
does not have the integrated wireless radio interface. The term
direct is used to reflect that a direct layer 2 path exists between
the mobile node and the MSF enabled LER either via the integrated
radio interface or via the wireline grooming network to the wireline
side of the Radio Access Network Base Stations. The term Indirect is
used to reflect that there is no direct layer 2 path between the
Radio Access Network and the MSF enabled LER node. The Indirect
Attachment means that there is another layer 3 device (such as the
Customer Edge - CE router in the MPLS Architecture terminology)
between the MSF enabled LER and the Radio Access Network. The CE
router in turn connects to the Radio Network via Direct Attachment
(in the sense of the term defined here) by using the integrated
wireless interface or by using the wireline grooming network. The
reason for establishing these two access options relates to the type
of service environments that the proposed architecture will most
likely be applicable to.
The Direct Attachment option is most suitable for the use case where
mobility is offered as an overlay service in a service provider's
mobility enabled MPLS network. In this case the Mobility Support
Function may be viewed as one of the functions in the MPLS for Mobile
Networks Architecture. An example of such a use case is the Wireless
Telephone service with data or multimedia capabilities (such as
EV-DO) in which mobility management is handled by the MSF enabled
MPLS network. The mobile nodes may be the wireless telephone sets
with IPv4 or IPv6 stacks and the corresponding mobility addresses
assigned by the service provider, communicating via the Radio Access
Network Base Stations to the MSF enabled LER nodes. A simple
registration procedure triggers the assignment of the overlay
Mobility Labels and the subsequent mobility management by MP-BGP.
The Indirect Attachment option is most suitable when the mobility
service is integrated with other overlay MPLS services such as Layer
3 VPN [RFC4364]. This use case is applicable for the enterprise
networking where the mobile nodes can be the wireless workstations or
Berzin & Malis Expires May 2, 2008 [Page 10]
Internet-Draft Mobility Label Based Network October 2007
wireless IP telephones, and the enterprise sites connecting to the
service provider's mobility enabled MPLS network via the CE routers.
The simplest way to accommodate the presence of the CE routers is to
implement the MSF function on the CE router and use the MP-BGP and
Mobility Labels between the CE router and the LER (PE) router in the
context of the customer specific MPLS VPN. This also implies the use
of MPLS and MP-BGP between the CE and PE routers for the delivery of
traffic to the mobile nodes behind the CE router, but since there
will be no LSR (P) routers between the MSF enabled CE and the PE
router there is actually no need for the outer stack MPLS labels and
therefore no need to integrate the CE routers with the service
provider's MPLS infrastructure. The MPLS LER (PE) router will need
to accept the Mobility Binding information via the use of MP-BGP from
the CE router within the MPLS VPN and then propagate that information
into the MPLS network using the L3 VPN MPLS overlay service also
based on MP-BGP.
The direct attachment option is shown in Fig.1, where a MSF enabled
LER node interfaces with multiple Radio Cells or Cell Clusters via
the L2 network such as Ethernet. Each Radio Cell Cluster is assigned
into a L2 Virtual LAN and associated with a L3 subnet that is
terminated at a logical interface of the LER node. The logical
interfaces are controlled by the MSF and the associated set of Radio
Cells or Clusters forms a Mobility Region.
In Fig. 2 a similar arrangement is illustrated but in this case there
is no direct L2 path between the Radio Access Network and the MPLS
edge. A CE router provides the MSF and communicates the Mobility
Binding information by means of MP-BGP to the MPLS LER (PE) router.
Berzin & Malis Expires May 2, 2008 [Page 11]
Internet-Draft Mobility Label Based Network October 2007
+-----+
|MSF ++-----------+ +------------+
Radio Cell +----++ | | |
,-----. | LER ........MPLS Network
/ \ | | | |
/ ((++)) \ +--+-+-++-+-++ +------------+
( || ) L3 Logical Interfaces
,----+. +`-._/ / / / / / /
/ \ /`-. +--+-+-+-+-+-++
/ ((++))`+----' `+._ / / /| /| .-----,
( || ,-----. ___|___ / / / `-. / \
\ ++--''''''''' | / | `-. |`. / ((++)) \
\ // ((++)) \ |.-' `. `-. `-. || )
`----(' || .-'+--------+----+`-.\ `-.+ .+----,
\ +_.-'/ L2 Network `+. / \
\ / \ ``-.-+'((++)) \
`-----' `. .----`-. || )
Base Station \ / \\`-.+ /
`. ((++)) \\ /
( \ || `)----'
\ `.++ /
\ /
`-----'
Base Station
Direct Attachment Option
Figure 1
Berzin & Malis Expires May 2, 2008 [Page 12]
Internet-Draft Mobility Label Based Network October 2007
+-----+
|MSF ++-----------+ +-----------+
Radio Cell +----++ | MP-BGP+| |
,-----. | CE .......... MPLS LER |
/ \ | |Mobility| |
/ ((++)) \ +--+-+-++-+-++ +-----------+
( || ) L3 Logical Interfaces
,----+. +`-._/ / / / / / /
/ \ /`-. +--+-+-+-+-+-++
/ ((++))`+----' `+._ / / /| /| .-----,
( || ,-----. ___|___ / / / `-. / \
\ ++--''''''''' | / | `-. |`. / ((++)) \
\ // ((++)) \ |.-' `. `-. `-. || )
`----(' || .-'+--------+----+`-.\ `-.+ .+----,
\ +_.-'/ L2 Network `+. / \
\ / \ ``-.-+'((++)) \
`-----' `. .----`-. || )
Base Station \ / \\`-.+ /
`. ((++)) \\ /
( \ || `)----'
\ `.++ /
\ /
`-----'
Base Station
Indirect Attachment Option
Figure 2
2.4.3. Network Hierarchy
The distribution of the Mobility Binding information using MP-BGP may
be achieved by constructing a flat or hierarchical MP-BGP peering
topology among the participating LER nodes. The flat peering logical
structure requires a full mesh of MP-BGP sessions and the
hierarchical peering structure can make use of the BGP Route
Reflectors in which some LER nodes are designated as the Route
Reflectors and establish peering sessions between themselves and all
other LER supporting MSF (Route-Reflector-Clients). The BGP Route
Reflectors capable of supporting MPLS Mobility are referred to as
Mobility Route Reflectors. It is important to note that the Mobility
Route Reflectors need not support the MSF but must be able to
interpret and relay the MSF related MP-BGP messaging.
2.4.4. Interface to Other Networks
The interface to other networks depends on how the mobility is to be
managed between the interconnecting networks. If all mobility
Berzin & Malis Expires May 2, 2008 [Page 13]
Internet-Draft Mobility Label Based Network October 2007
functions are to be managed by a service provider's network (given
that the network has sufficient coverage) then the interface to other
networks can be as simple as the peering gateway node that connects
the service provider's MPLS network to the rest of the world. In
this case there is no need to extend the MPLS processing over this
interface, and since by construction all mobility IP addresses belong
to the IP address space of the service provider, the general peering
arrangement to other networks where the IP address range of the
service provider is advertised out to the Internet will enable the
communication between the mobile nodes and the outside destinations.
In case of the mobile node roaming, this may be supported between the
service provider networks that both implement the customer facing
Mobility Support Function and the Network-to-Network Interface (NNI)
that employs the use of MPLS label exchange (including the Mobility
Labels).
Berzin & Malis Expires May 2, 2008 [Page 14]
Internet-Draft Mobility Label Based Network October 2007
3. Mobility Support Function
This section describes the proposed set of functional elements of the
MPLS LER node capable of providing mobility management services.
This document refers to these functional elements as a Mobility
Support Function (MSF).
3.1. Mobile Node Discovery, Registration and Status
3.1.1. Discovery Process - IPv4
As in [RFC3344] the discovery of the MSF by the mobile nodes is based
on the ICMP Router Discovery [RFC1256] with specific extensions for
Mobility Label Based Network (MLBN). The format of the extensions
used in this proposal also follows the [RFC3344] section 1.9.
The discovery process should be initiated by a mobile host or router
by sending the ICMP Router Solicitation message with MLBN MSF
Discovery Extension and the TTL set to 1. This ICMP message along
with the MLBN Extension is referred to as the MSF Discovery message.
The MSF Discovery message should carry the information about the type
of the mobile node: Mobile Host or Mobile Router.
Upon receipt of the MSF Discovery message the MSF LER must respond
with the ICMP Router Advertisement including the MLBN specific
Extension. This message is referred to as the MSF Advertisement.
The MSF Advertisement will carry different information depending on
the type of the mobile node and the registration mode.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSF Discovery Extension TLV (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ICMP Router Solicitation with MSF Discovery Extension
Figure 3
Berzin & Malis Expires May 2, 2008 [Page 15]
Internet-Draft Mobility Label Based Network October 2007
Link Layer Fields: Destination Address - This should be the
multicast or broadcast Link Layer Address.
IP Fields: Source Address - IP Address of the Mobile Host or IP
address of the interface of the Mobile Router from which this
message is sent.
Destination Address - This is the all-routers multicast address
224.0.0.2 or the limited broadcast address 255.255.255.255.
TTL - TTL should be set to 1.
ICMP Fields: Type = 10 Router Solicitation.
Code = 1 MLBN MSF Discovery Extension included.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Addrs |Addr Entry Size| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSF Advertisement Extension (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ICMP Router Advertisement with MSF Advertisement Extension
Figure 4
Link Layer Fields: Destination Address - This should be the source
address used to deliver the MSF Discovery message from the mobile
node.
IP Fields: Source Address - IP Address of the MSF.
Destination Address - This is the unicast IP address used in the
IP header of the MSF Discovery message from the mobile node.
TTL - TTL should be set to 1.
Berzin & Malis Expires May 2, 2008 [Page 16]
Internet-Draft Mobility Label Based Network October 2007
ICMP Fields: Type = 9 Router Advertisement.
Code = 1 MLBN MSF Advertisement Extension included.
Please refer to [RFC1256] for the specification of the remaining
fields in both of the above messages.
3.1.1.1. MSF Discovery by Mobile Hosts - IPv4
Mobile hosts should initiate the MSF Discovery process by sending the
MSF Discovery message. The MSF Discovery Extension format for Mobile
Hosts is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |H|Pri. |L|ASTI | Region_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host IPv4 Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Host MSF Discovery Extension for IPv4
Figure 5
Type - 0 = MSF Discovery
Length - Length of the message in octets.
H - Mobile Node Type Indication. 0 = Mobile Host.
Pri. - A 3-bit Priority Code (0-7).
L - Lightweight Registration Requested (1).
ASTI - Application Service Type Indication. This 3-bit field may
be used to indicate to the MSF what type of service is to be used
by the mobile host. For example, "Internet Access Only" or Full
Mobile-to-Mobile Routing". This indication can then be mapped to
the Network Update Mode Code used in the Mobility Binding
structure.
Berzin & Malis Expires May 2, 2008 [Page 17]
Internet-Draft Mobility Label Based Network October 2007
Region_ID - An Identifier (1-255) associated with the Regional
Mobility Route Reflector. Region_ID=0 must be used for initial
registrations by mobile nodes.
Correlation ID - a number used to keep track of the Lightweight
Registration message pairs - MSF Discovery/MSF Advertisement.
3.1.1.2. MSF Discovery by Mobile Routers - IPv4
Mobile routers should initiate the MSF Discovery process by sending
the MSF Discovery message. The MSF Discovery Extension format for
Mobile Routers is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |R|Pri. |L|Res. | Region_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile IPv4 Router-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mobile Router MSF Discovery Extension
Figure 6
Type - 0 = MSF Discovery
Length - Length of the message in octets.
R - Mobile Node Type Indication. 1 = Mobile Router.
Pri. - A 3-bit Priority Code (0-7).
L - Always set to 0 in the MSF Discovery sent by a mobile router.
Res. - Reserved.
Region_ID - An Identifier (1-255) associated with the Regional
Mobility Route Reflector. Region_ID=0 must be used for initial
registrations by mobile nodes.
3.1.1.3. MSF Advertisement - IPv4
After receiving the MSF Discovery message from a mobile host or
router the MSF should reply with the MSF Advertisement message using
extension format shown below.
Berzin & Malis Expires May 2, 2008 [Page 18]
Internet-Draft Mobility Label Based Network October 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |L|R|G|Reserved | Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSF IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSF Virtual Link Layer Address (first 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Last 16 bits | Reserved | Region_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MSF Advertisement Extension
Figure 7
Type - 1 = MSF Advertisement
Length - Length of the message in octets.
Sequence Number - The sequence number of the MSF Advertisement
message sent since the MSF is operational.
Registration Lifetime - the time in seconds until the registration
entry in the MSF database expires.
L - Lightweight Registration Confirmed (1).
R - Full Registration Required (1).
G - Group Registration Supported (1).
Group ID - Unique Registration Group Number. Should be zero if G
= 0
MSF IP Address - Virtual IP Address of the MSF (may be different
from any particular MSF LER interface IP address
MSF Virtual Link Layer Address - a MAC address shared and
recognized by all MPLS LER interfaces participating in the MSF.
This address may specifically be used to support Local Micro-
Mobility (see Section 4.3.1).
Berzin & Malis Expires May 2, 2008 [Page 19]
Internet-Draft Mobility Label Based Network October 2007
Region_ID - An Identifier (1-255) associated with the Regional
Mobility Route Reflector. Region_ID=0 must be used for initial
registrations by mobile nodes.
Correlation ID - a number used to keep track of the registration
requests and the corresponding reply message pairs.
The MSF Advertisement should be sent to the unicast link layer
address and the unicast IP address of the mobile host or router that
were used in the MSF Discovery link layer header and the MSF
Discovery Extension payload respectively.
Upon receipt of the MSF Advertisement mobile hosts should continue to
send the MSF Discovery messages with the interval of 1/3 of the
specified Registration Lifetime. The MSF should send the MSF
Advertisements in response to the periodic MSF Discovery messages
from the mobile hosts using the corresponding Correlation IDs. If a
mobile host does not get responses to three MSF Discovery messages
(serving as the keepalives) the mobile host should initiate a new MSF
Discovery process using a new Correlation ID.
If the L flag in the MSF Advertisement is set, and the R flag is not,
indicating the Lightweight Registration mode (see Section 3.1.3.1),
the mobile hosts may start sending datagrams to their IP destinations
using the link layer address of the MSF. The L and R flags are
mutually exclusive and cannot be set at the same time.
If the R flag is set in the MSF Advertisement, indicating that
explicit registration is required, mobile hosts should transition to
the Full Registration mode (see Section 3.1.3.1.2).
The R flag must always be set in the MSF Advertisement if it is in
reply to the MSF Discovery sent by a mobile router. Upon receipt of
the MSF Advertisement a mobile router must transition to the Routing
Adjacency Establishment mode (see Section 3.1.3.2).
3.1.2. Discovery Process - IPv6
The MSF discovery process for IPv6 is identical to the discovery
process for IPv4 with the exception of the use of IPv6 specific
Router Solicitation and Advertisement messages based on ICMPv6
[RFC4443]. These messages are specified in [RFC4861]. As in the
IPv4 case the Router Solicitation and Advertisement messages carry
the MLBN extensions and are termed the MSF Discovery and the MSF
Advertisement respectively.
Berzin & Malis Expires May 2, 2008 [Page 20]
Internet-Draft Mobility Label Based Network October 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSF Discovery Extension TLV (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Router Solicitation with MSF Discovery Extension
Figure 8
Link Layer Fields: Destination Address - This should be the
multicast or broadcast Link Layer Address.
IP Fields: Source Address - IP Address of the Mobile Host or IP
address of the interface of the Mobile Router from which this
message is sent.
Destination Address - This is the all-routers multicast address
FF02::2
ICMP Fields: Type = 133 Router Solicitation.
Code = 1 MLBN MSF Discovery Extension included.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O| Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSF Discovery Extension TLV (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Router Advertisement with MSF Advertisement Extension
Figure 9
Berzin & Malis Expires May 2, 2008 [Page 21]
Internet-Draft Mobility Label Based Network October 2007
Link Layer Fields: Destination Address - This should be the source
address used to deliver the MSF Discovery message from the mobile
node.
IP Fields: Source Address - IP Address of the MSF.
Destination Address - This is the unicast IP address used in the
IP header of the MSF Discovery message from the mobile node.
ICMP Fields: Type = 134 Router Advertisement.
Code = 1 MLBN MSF Advertisement Extension included.
Please refer to [RFC4861] for the specification of the remaining
fields in both of the above messages.
3.1.2.1. MSF Discovery by Mobile Hosts - IPv6
The MSF Discovery message format for IPv6 mobile hosts is identical
to the IPv4 message with the IPv6 Source Address used instead of the
IPv4 (see Section 3.1.1.1).
3.1.2.2. MSF Discovery by Mobile Routers - IPv6
The MSF Discovery message format for IPv6 mobile routers is identical
to the IPv4 message with the IPv6 Router ID used instead of the IPv4
(see Section 3.1.1.2).
3.1.2.3. MSF Advertisement - IPv6
The MSF Advertisement message format for IPv6 is identical to the
IPv4 message format (see Section 3.1.1.3).
3.1.3. Registration and Status - IPv4
3.1.3.1. Mobile Host Registration - IPv4
3.1.3.1.1. Lightweight Registration - IPv4
MLBN eliminates the need for the registrations with the Home Agent
and Care-of-Addresses. This makes it possible to implement a
Lightweight Registration procedure which is simply the completion of
the MSF Discovery process (Section 3.1.1). The Lightweight
Registration is indicated by the presence of the L flag in the MSF
Advertisement message. With the Lightweight Registration the MSF
should allocate the local Mobility Label and create the Mobility
Binding structure (Section 3.2.2) immediately following the receipt
of the MSF Discovery message from a mobile host. The MSF should also
Berzin & Malis Expires May 2, 2008 [Page 22]
Internet-Draft Mobility Label Based Network October 2007
initiate the network update process (see Section 4) based on the
selected update mode and the indicated mobile application priority.
The network update mode selection may be based on the Application
Service Type Indication (ASTI) from the MSF discovery message sent by
the mobile host. ASTI is a 3-bit field that may be used to indicate
to the MSF what type of service is to be used by the mobile host.
For example, "Internet Access Only" or "Full Mobile-to-Mobile
Routing". This indication can then be mapped to the Network Update
Mode Code used in the Mobility Binding structure.
3.1.3.1.2. Full Registration - IPv4
Full Registration is a registration mode which allows to perform
additional functions as part of the registration process. An example
of such function is the Mobile Host Authentication. Full
registration mode is indicated in the MSF Advertisement by setting
the R flag.
Full Registration messaging makes use of the UDP port RRR and may
provide a mechanism for various functional extensions. Full
Registration uses two message types:
Registration Request - Type 1
Registration Reply - Type 2
The Registration Message formats are shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |H| Rri.|ASTI | Region_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host IPv4 Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSF Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions
+-+-+-+-+-+-+....
Full Registration Request
Figure 10
Berzin & Malis Expires May 2, 2008 [Page 23]
Internet-Draft Mobility Label Based Network October 2007
Type - 1 = Full Registration Request
Length - Length of the message in octets.
H - Mobile Node Type Indication. 0 = Mobile Host
Pri. - A 3-bit priority code (0-7).
ASTI - Application Service Type Indication. This 3-bit field may
be used to indicate to the MSF what type of service is to be used
by the mobile host. For example, "Internet Access Only" or Full
Mobile-to-Mobile Routing". This indication can then be mapped to
the Network Update Mode Code used in the Mobility Binding
structure.
Region_ID - An Identifier (1-255) associated with the Regional
Mobility Route Reflector. Region_ID=0 must be used for initial
registrations by mobile nodes.
Correlation ID - a number used to keep track of the registration
requests and the corresponding reply message pairs.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime | Reserved | Region_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host IPv4 Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSF IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSF Virtual Link Layer Address (first 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Last 16 bits | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions
+-+-+-+-+-+-+....
Full Registration Reply
Figure 11
Berzin & Malis Expires May 2, 2008 [Page 24]
Internet-Draft Mobility Label Based Network October 2007
Type - 2 = Full Registration Reply
Length - Length of the message in octets.
Flags - To be defined
Registration Lifetime - the time in seconds until the registration
entry in the MSF database expires.
Region_ID - An Identifier (1-255) associated with the Regional
Mobility Route Reflector. Region_ID=0 must be used for initial
registrations by mobile nodes.
MSF IP Address - Virtual IP Address of the MSF (may be different
from any particular MSF LER interface IP address
MSF Virtual Link Layer Address - a MAC address shared and
recognized by all MPLS LER interfaces participating in the MSF.
This address may specifically be used to support Local Micro-
Mobility (see Section 4.3.1).
Correlation ID - a number used to keep track of the registration
requests and the corresponding reply message pairs.
3.1.3.1.3. Group Registration - IPv4
Clearly the discovery and registration procedure has a great effect
on the network responsiveness especially when a mobile host moves
from one serving MSF to another. The following enhanced registration
scheme can be implemented to simplify the registrations resulting
from the MSF-to-MSF handoff and therefore improve the network
responsiveness. We refer to it as the Group Registration.
The entire MPLS edge network may be divided in groups or regions
containing the geographically close MSF enabled LER nodes. Each
group should be assigned a unique Group ID (1-255). The mobile host
will register with a LER node within a group using a Group
Registration procedure. The LER node will distribute the
registration information to the rest of the group members using the
established MP-BGP peering sessions. These messages may be coded as
another type of the NLRI in the Address Family structure. The size
of the region should be large enough to ensure a high probability
that the range of movements of a mobile host will be covered by the
service area of the group but at the same time not too large to avoid
a large registration table size shared among the group members. The
group members can be identified administratively and preconfigured in
the MSF serving LER nodes.
Berzin & Malis Expires May 2, 2008 [Page 25]
Internet-Draft Mobility Label Based Network October 2007
During the initial registration process and as part of the
registration acknowledgement the serving LER may indicate to the
mobile host that it is registered to a group and from now on should
use a group virtual link layer address and a group virtual IP address
for further communications (the addresses may be communicated in the
acknowledgement payload).
The group registration allows to implement the implicit logic by
which no further registrations are required from the mobile node due
to its movements once the initial group registration has been
established. The group members may also pre-allocate the Mobility
Labels and have them ready in case the mobile node moves into the
member's serving area. Once the mobile node has moved into the
serving area of the new MSF group member it continues to send packets
to the group virtual link layer address and the virtual IP address.
As soon as the packet from the mobile node is received by the group
member it will forward the packet to its destination and distribute
the new Mobility Binding to the network. A mobile host should
continue to send the MSF Discovery messages destined to the group
link layer address in order to keep the group registration active.
The group member that is servicing the mobile host can periodically
send the registration update messages to the group members in order
to keep the Mobility Bindings in the standby status. If a group
member has not received any keepalives or packets from the mobile
host in a specified period of time it should silently deactivate its
local registration entry and release the Mobility Label. If the
mobile host happens to be serviced by another group member, this
member will be sending the registration update messages to the group
keeping the registration active. If no group member hears from the
mobile node, the registration must be removed from the group database
after a specified time and the associated Mobility Binding may be
withdrawn from the network by means of the MP-BGP update.
Group Registration message formats are very similar to the Full
Registration message formats. The Group Registrations starts with
the mobile host sending the MSF Discovery message and the MSF
replying with the MSF Advertisement having the G flag set, indicating
that the Group Registration is supported. After this the mobile host
must transition to the Group Registration protocol using the same UDP
port RRR as for the Full Registration.
Group Registration uses two message types:
Group Registration Request - Type 3
Berzin & Malis Expires May 2, 2008 [Page 26]
Internet-Draft Mobility Label Based Network October 2007
Group Registration Reply - Type 4
The Group Registration Message formats are shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |H| Rri.|ASTI |G| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host IPv4 Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSF Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Region_ID | Extensions
+-+-+-+-+-+-+-+-+-+-+-+-+-+....
Group Registration Request
Figure 12
Type - 3 = Group Registration Request
Length - Length of the message in octets.
H - Mobile Node Type Indication. 0 = Mobile Host
Pri. - A 3-bit priority code (0-7).
ASTI - Application Service Type Indication. This 3-bit field may
be used to indicate to the MSF what type of service is to be used
by the mobile host. For example, "Internet Access Only" or Full
Mobile-to-Mobile Routing". This indication can then be mapped to
the Network Update Mode Code used in the Mobility Binding
structure.
G - Group Registration Requested (1)
Group ID - Unique Registration Group Number. Should be zero if G
= 0
Correlation ID - a number used to keep track of the registration
requests and the corresponding reply message pairs.
Berzin & Malis Expires May 2, 2008 [Page 27]
Internet-Draft Mobility Label Based Network October 2007
Region_ID - An Identifier (1-255) associated with the Regional
Mobility Route Reflector. Region_ID=0 must be used for initial
registrations by mobile nodes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |G| Reserved | Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host IPv4 Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Virtual IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Virtual Link Layer Address (first 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Last 16 bits | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Region_ID | Extensions
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....
Group Registration Reply
Figure 13
Type - 4 = Group Registration Reply
Length - Length of the message in octets.
Flags - To be defined
Registration Lifetime - the time in seconds until the registration
entry in the MSF database expires.
G - Group Registration Supported (1).
Group ID - Unique Registration Group Number. Should be zero if G
= 0
Group Virtual IP Address - Virtual IP Address that is supported by
all MSF's that belong to the Registration Group identified by the
Group ID. This address may specifically be used to support Group
Micro-Mobility (see Section 4.3.2).
Berzin & Malis Expires May 2, 2008 [Page 28]
Internet-Draft Mobility Label Based Network October 2007
Group Virtual Link Layer Address - a MAC address shared and
recognized by all MPLS LER interfaces of all MSF's that belong to
the Registration Group identified by the Group ID. This address
may specifically be used to support Group Micro-Mobility (see
Section 4.3.2).
Correlation ID - a number used to keep track of the registration
requests and the corresponding reply message pairs.
Region_ID - An Identifier (1-255) associated with the Regional
Mobility Route Reflector. Region_ID=0 must be used for initial
registrations by mobile nodes.
As in the Full Registration case the Group Registration allows to
perform additional functions as part of the registration process by
means of using the functional extensions. An example of such a
function is the Mobile Host Authentication.
After the completion of the Group Registration with the initial MSF
that is part of the Registration Group, the mobile host must send the
MSF Discovery messages destined to the Group Virtual Link Layer
Address listing the Group ID and the Group Virtual IP Address. The
registration information is communicated among the group members
using MP-BGP signaling with the specific SAFI value assigned for this
purpose (see Section 3.2.3). Any group member receiving the MSF
Discovery messages from a mobile host for which the group
registration is active must reply with the MSF Advertisement messages
to the mobile host. When a mobile host moves from one group member
to another it should continue to send packets to its IP destination
using the Group Virtual Link Layer Address.
3.1.3.2. Mobile Router Registration - IPv4
Mobile routers should initiate the registration procedure by sending
the registration message with the mobile router identification flag
set and its Router ID (an IP address that belongs to the router)
specified (see Section 3.1.1.2).
Upon receipt of this registration information the MSF should initiate
the establishment of the dynamic routing protocol adjacency with the
mobile router using protocols such as BGPv4 [RFC4271]. The mobile
router should advertise to the MSF the IP prefixes it serves using
the established routing adjacency.
3.1.3.2.1. Routing Adjacency Establishment
The MSF should receive the routing protocol update from the mobile
router and allocate a single Mobility Label to represent all of the
Berzin & Malis Expires May 2, 2008 [Page 29]
Internet-Draft Mobility Label Based Network October 2007
served prefixes. This label should then be used in the Mobility
Binding structure exported to the network by MP-BGP (see Figure 18).
Optionally, each served IP prefix advertised by the mobile router can
be associated with a separate Mobility Label. This can be used to
provide different mobility processing priority to different IP
prefixes.
The mobile router status detection can be based on the state of the
dynamic routing protocol adjacency maintained by the periodic
keepalive messaging common to the routing protocols.
3.1.4. Registration and Status - IPv6
The registration procedures described for IPv4 in Section 3.1.3 are
fully extended to IPv6 using the same message formats and the UDP
port number. In all messages the IPv4 addresses are replaced with
their IPv6 equivalents (with the corresponding increase in the
required field length).
Thus, for mobile hosts the Lightweight, Full and Group Registration
modes are supported (see Section 3.1.3.1.1, Section 3.1.3.1.2,
Section 3.1.3.1.3), and for mobile routers the same IPv4 procedure
described in Section 3.1.3.2 and modified to include the IPv6
messages should be supported.
In addition to the use of the MSF Discovery/Advertisement message as
keepalives for determining the status of the reachability of the
serving MSF function, mobile nodes may utilize IPv6 Neighbor
Unreachability Detection procedures specified in [RFC4861] section
7.3.
3.2. Integration with MP-BGP
In order to integrate the MSF on the LER with the MP-BGP processing,
a new Address Family must be created. This Address Family must be
assigned a new and unique AFI following the Address Family structure
of MP-BGP. This Address Family may be referred to as the Mobility
Address Family. In fact a number of Mobility Address Families may be
created to support IPv4/IPv6 unicast/multicast protocols. In all
cases the Address Families must use the structure that allows them to
carry the overlay MPLS label information (a specially designated
value of SAFI).
3.2.1. Mobility Address Family
In order to carry the Mobility Binding information the BGP UPDATE
message with the MP_REACH_NLRI and MP_UNREACH_NLRI optional non-
transitive attributes is used as specified in [RFC4760].
Berzin & Malis Expires May 2, 2008 [Page 30]
Internet-Draft Mobility Label Based Network October 2007
For the mobility management purposes a set of new Address Family
Identifiers (AFI) and Subsequent Address Family Identifiers (SAFI)
are defined. Specifically the following new AFI values are defined:
Mobility IPv4 Unicast - AFI X1 SAFI Y1
Mobility IPv6 Unicast - AFI X2 SAFI Y1
The MP_REACH_NLRI attribute is used to update the LER nodes with new
Mobility Binding information. The structure of the attribute is
shown below.
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+---------------------------------------------------------+
| Network Address of Next Hop (variable) |
+---------------------------------------------------------+
| Reserved (1 octet) |
+---------------------------------------------------------+
| Mobility Binding (NLRI) Information (variable) |
+---------------------------------------------------------+
MP_REACH_NLRI with Mobility Binding
Figure 14
The MP_UNREACH_NLRI attribute is used to withdraw the Mobility
Binding information. The structure of the attribute is shown below.
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Mobility Binding (Withdrawn Routes) (variable) |
+---------------------------------------------------------+
MP_UNREACH_NLRI with Mobility Binding
Figure 15
The Mobility Binding itself is encoded in the NLRI format shown
Berzin & Malis Expires May 2, 2008 [Page 31]
Internet-Draft Mobility Label Based Network October 2007
below.
+---------------------------+
| Length (1 octet) |
+---------------------------+
|Mobility Binding (variable)|
+---------------------------+
NLRI Encoding for Mobility Bindings
Figure 16
For the definitions of the fields in the above figures (with the
exception of the Mobility Binding related information) please see
[RFC4760].
3.2.2. Mobility Bindings
Two types of Mobility Binding formats are proposed: Host Mobility
Binding and Router Mobility Binding.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin MP-BGP NEXT_HOP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target MP-BGP NEXT_HOP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| UT |Res. | Mobility Label |Pri. |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NLRI Encoding for the Host Mobility Binding
Figure 17
Origin MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the
Mobility Binding. This address may be carried in the IPv4 or IPv6
format depending on the {AFI, SAFI} pair used.
Target MP-BGP NEXT_HOP - Router ID of the MPLS LER to receive the
Mobility Binding using Selective Downstream Push. For the
Unsolicited Downstream Push this field should be set to 0. This
address may be carried in the IPv4 or IPv6 format depending on the
{AFI, SAFI} pair used.
Berzin & Malis Expires May 2, 2008 [Page 32]
Internet-Draft Mobility Label Based Network October 2007
Mobile Host Address - IPv4 or IPv6 Address of the mobile host.
This address may be carried in the IPv4 or IPv6 format depending
on the {AFI, SAFI} pair used.
H - Mobile Node Type Indication. 0 = Mobile Host
UT - Update Type. This 3-bit code is mapped to the ASTI code in
the MSF Discovery and Registration Request messages to indicate
the Network Update Mode selection (see Section 4).
Res. - Reserved.
Mobility Label - Overlay MPLS Label (20 bits) associated with the
IP address of the mobile host in the MSF database.
Pri. - A 3-bit priority code (0-7).
S - Bottom of Stack.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin MP-BGP NEXT_HOP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target MP-BGP NEXT_HOP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| UT | Res. |No of Prefixes | IP Prefix 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Prefix 1 | Prefix 1 Len. | Variable No. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| of Prefixes/Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility Label |Pri. |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NLRI Encoding for the Router Mobility Binding
Figure 18
Origin MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the
Mobility Binding. This address may be carried in the IPv4 or IPv6
format depending on the {AFI, SAFI} pair used.
Berzin & Malis Expires May 2, 2008 [Page 33]
Internet-Draft Mobility Label Based Network October 2007
Target MP-BGP NEXT_HOP - Router ID of the MPLS LER to receive the
Mobility Binding using Selective Downstream Push. For the
Unsolicited Downstream Push this field should be set to 0. This
address may be carried in the IPv4 or IPv6 format depending on the
{AFI, SAFI} pair used.
Mobile Router ID - IP Address of the mobile router. This address
may be carried in the IPv4 or IPv6 format depending on the {AFI,
SAFI} pair used.
R - Mobile Node Type Indication. 1 = Mobile Router
UT - Update Type. This 3-bit code is mapped to the ASTI code in
the MSF Discovery and Registration Request messages to indicate
the Network Update Mode selection (see Section 4).
Res. - Reserved.
No. of Prefixes - Number of IP Prefixes carried in this Mobility
Binding.
IP Prefix 1 - First IP Prefix (32 bits for IPv4, 128 bits for
IPv6)
Prefix 1 Len. - Length (in number of bits) of the network part of
IP Prefix 1
Mobility Label - Overlay MPLS Label (20 bits) associated with each
of the IP Prefixes served by the mobile router in the MSF database
of the originating LER.
S - Bottom of Stack.
The receiving MSF must read the R flag in the Mobility Binding and
associate the provided Mobility Label with each of the IP prefixes
found in the body of the Mobility Binding. The derived associations
must be installed in the MPLS forwarding table of the MPLS LER and in
turn associated with the infrastructure label assigned to the "Origin
MP-BGP NEXT_HOP" address indicated in the received Mobility Binding
3.2.3. Group Registration Management with MP-BGP
The Group Registration (Section 3.1.3.1.3) information obtained via
the registration messaging with a mobile host is shared among the
group members using existing MP-BGP peering sessions. To achieve
this, the MSF should allow for a configuration capability to identify
the group membership by assigning a Group ID to the MP-BGP peers that
belong to the same group. The same capability should be provided
Berzin & Malis Expires May 2, 2008 [Page 34]
Internet-Draft Mobility Label Based Network October 2007
within the Mobility Route Reflectors in order to be able to
successfully update the group members with the mobile node
registration information.
The mobile host registration information includes the IP address of
the mobile host, the Group ID, the priority and the ASTI codes as
well as the MAC address of the mobile host. This information is
encoded in the Address Family structure using the AFI values
specified in Section 3.2.1 but with a specifically designated value
of SAFI. The encoded information is then carried in the
MP_REACH_NLRI or MP_UNREACH_NLRI.
Specifically the following new SAFI value is defined:
Mobility IPv4 Unicast - AFI X1 SAFI Y2
Mobility IPv6 Unicast - AFI X2 SAFI Y2
The NLRI encoding is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP-BGP NEXT_HOP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |H| Rri.|ASTI |G| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Virtual IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Host MAC Address (first 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last 16 bits | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Group Registration NLRI Encoding
Figure 19
MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the Group
Registration Update. This address may be carried in the IPv4 or
IPv6 format depending on the {AFI, SAFI} pair used.
Berzin & Malis Expires May 2, 2008 [Page 35]
Internet-Draft Mobility Label Based Network October 2007
H - Mobile Node Type Indication. 0 = Mobile Host
Pri. - A 3-bit priority code (0-7).
ASTI - Application Service Type Indication. This 3-bit field may
be used to indicate to the MSF what type of service is to be used
by the mobile host. For example, "Internet Access Only" or Full
Mobile-to-Mobile Routing". This indication can then be mapped to
the Network Update Mode Code used in the Mobility Binding
structure.
G - Group Registration Requested (1)
Group ID - Unique Registration Group Number. Should be zero if G
= 0
Mobile Host IP Address - IPv4 or IPv6 Address of the mobile host.
This address may be carried in the IPv4 or IPv6 format depending
on the {AFI, SAFI} pair used.
Group Virtual IP Address - IPv4 or IPv6 address assigned for the
group and joined by all LER interfaces participating in the MSF.
For IPv6 this may be the Anycast IP address.
Mobile Host MAC Address - MAC address of the mobile host.
Correlation ID - a number used to keep track of the registration
requests and the corresponding reply message pairs.
The group registration information updates may be sent periodically
by the group members. The registration information for multiple
mobile hosts may be aggregated in a single MP-BGP UPDATE message.
The mobile host registration information may be explicitly withdrawn
by the group member that was the last to "hear" from the mobile host.
If a group member receives the MP-BGP registration information update
listing a mobile host that has an active local registration entry,
the local registration information must be silently discarded and the
corresponding local Mobility Binding deleted. The local Mobility
Label should be returned to the local available label pool.
If a local registration entry for a mobile host has expired, and if a
mobile host registration information is not found in the incoming
periodic MP-BGP registration information updates from any of the
group members, the group member should send the MP-BGP registration
information update carrying the host's registration information in
the MP_UNREACH_NLRI attribute. In addition the group member should
initiate a network update using the MP_UNREACH_NLRI with the encoded
Berzin & Malis Expires May 2, 2008 [Page 36]
Internet-Draft Mobility Label Based Network October 2007
Mobility Binding for the host in order to withdraw the Mobility
Binding from the MSF databases of the MPLS LER nodes.
3.2.4. BGP Capability Advertisement
The {AFI, SAFI} pairs defined in this document for mobility
management must be supported by all BGP speakers participating in
mobility management. A BGP Capability Advertisement as specified in
[RFC4760] must be used by the BGP speakers to ensure compatibility.
3.3. Mobile Application Priority Indication and Recognition
Given the sensitivity of applications to the network service
disruption the MSF function should include a mechanism by which an
application may indicate the level of tolerance to the disruption due
to the network handling of the handoff process. This indication may
be encoded in the registration messaging payload and then
incorporated into the Mobility Binding protocol structure. The
application sensitivity prioritization scheme may be used to control
the Mobility Binding processing priority during the distribution
process. For example a mobile host running a real time interactive
application may be given a higher processing priority over the mobile
host running an elastic data transfer application. The
prioritization of processing leads to a differential treatment of the
mobile application at various processing points of the mobile network
such as the ingress MSF, the intermediate hierarchical route
processing by MP-BGP Route Reflectors and the egress MSF.
In addition to the processing priority, the priority indication
mechanism may be used to implement the network update grouping and
timing policies in a manner that could decrease the frequency of the
updates and thus increase the scalability of the network.
Specifically, the indicated application priorities may be mapped into
the network update classes where the top priority may get an
immediate network update and the lower priorities may be organized
into classes. For each class the network update process may be
delayed for a time period that is not expected to result in the
unreasonable disruption to an application of a given priority level.
The network updates for any new registration events of the same
priority level that have occurred during the corresponding delay
period may be grouped in a single MP-BGP update message. If a single
update message cannot carry all of the newly arrived registrations an
additional update should be created and sent. The update mode may be
determined from the Application Service Type Indication communicated
during the registration.
Berzin & Malis Expires May 2, 2008 [Page 37]
Internet-Draft Mobility Label Based Network October 2007
3.4. Application Service Type Indication
Application Service Type Indication (ASTI) is a 3-bit field that may
be used to indicate to the MSF what type of service is to be used by
the mobile host. For example, "Internet Access Only" or "Full
Mobile-to-Mobile Routing". This indication may then be mapped to the
Network Update Type Code used in the Mobility Binding structure. For
example, if ASTI code 001 (binary) is used to indicate the "Internet
Access Only" service, the local MSF may use the Selective Downstream
Push (see Section 4.1.2) Network Update mode. In addition the MSF
may include the corresponding Update Type code in the Mobility
Binding structure in order to indicate to the Mobility Route
Reflectors that the Selective Downstream Push is to be used.
Berzin & Malis Expires May 2, 2008 [Page 38]
Internet-Draft Mobility Label Based Network October 2007
4. Network Update and Hand-off Processing
4.1. Network Update Modes
The following four modes for the Mobility Binding Distribution or
Withdrawal are proposed: i) unsolicited downstream push, ii)
selective downstream push, iii) predictive downstream push, and iv)
hierarchical on-demand distribution.
4.1.1. Unsolicited Downstream Push
In this mode the originating LER node updates all other MSF enabled
LER nodes that are directly peered with it. In case of a
hierarchical topology the originating LER node sends a MP-BGP update
with the Mobility Binding information to a Route Reflector which in
turn updates all of the participating MSF enabled LER Route Reflector
clients. Thus the network wide update can only considered to be
complete if and only if all of the MSF LER nodes are updated.
Clearly this distribution mode has scalability limitations and may be
applicable for a relatively small number of the MSF enabled LER
nodes. The Update Type Code for this mode is binary 000.
4.1.2. Selective Downstream Push
In this mode the Mobility Binding updates are only sent to a select
set of the MSF enabled LER nodes. The underlying idea for this mode
is that it is very likely that the most used destinations from the
mobile host when it communicates with the Internet are the
destinations reachable via a finite set of the service provider's
Internet gateway nodes which are in turn reachable via a finite set
of the MSF enabled LER nodes. As such, when a mobile host registers
with the serving MSF, instead of using the Unsolicited Downstream
Push to all LER nodes, the Mobility Binding update for this mobile
host would be sent to a finite set of the LER nodes connected to the
service provider Internet gateways. This mode can be used for the
initial update process and the Unsolicited Downstream Push can be
used at a later point in time. The Update Type Code for this mode is
binary 001.
4.1.3. Predictive Downstream Push
In this mode the Mobility Binding updates are sent to those MSF
enabled LER nodes which are identified as a NEXT_HOP for the FEC (and
the corresponding LSP) leading to the destination of the packet
originated by a mobile node. This mode is based on the fact that if
the destination FEC exists in the serving MSF LER's routing table,
and the mobile node sends a packet to the FEC, the LER will perform
the label imposition (for the infrastructure label) by selecting the
Berzin & Malis Expires May 2, 2008 [Page 39]
Internet-Draft Mobility Label Based Network October 2007
label corresponding to the FEC NEXT_HOP. This NEXT_HOP in turn
identifies the destination MSF enabled LER node to which the Mobility
Binding update needs to be sent. The predictive feature of this mode
comes from the fact that the Mobility Binding update destination is
predicted as the result of the originating LER's lookup of the
destination FEC and its NEXT_HOP. Clearly it is likely that the LER
node to which the predictive Mobility Binding update is sent may
receive the reply packet from the mobile node's destination before
the Mobility Binding for the originating host is received. In this
case the LER that is being updated may buffer the reply packet for a
reasonable period of time to wait for the mobility update. The
Update Type Code for this mode is binary 010.
4.1.4. Hierarchical On-Demand Distribution
The Mobility Binding update is first sent by a serving MSF LER to a
set of Mobility Route Reflectors using the Selective Downstream Push.
Once the Mobility Route Reflectors have been updated, all other LER
nodes must explicitly request Mobility Labels from the Mobility Route
Reflectors for packets destined to a mobile node. The Update Type
Code for this mode is binary 011.
4.1.4.1. On-Demand Requests for Mobility Binding Information
To support the Hierarchical On-Demand Distribution Network Update
Mode the following explicit Mobility Binding information request
procedure based on MP-BGP may be used. When a MPLS LER supporting
MPLS Mobility receives an IP packet, it first should check if the
Destination Address listed in the IP header belongs to the overall IP
address range assigned to the mobility functions and the
corresponding mobile device fleet. If the Destination Address falls
within this range and the matching Mobility Binding is present in the
LER MSF database, the packet should be encapsulated using the
appropriate MPLS label stack and forwarded on the LSP toward the LER
that is listed as the "Origin MP-BGP NEXT_HOP" in the Mobility
Binding. If the IP address is outside of the mobility fleet range
the packet must be treated in accordance with the conventional rules
based on either the IP or MPLS forwarding tables.
If the packet falls into the mobility fleet range and no matching
Mobility Binding entry exists in the MSF database, the LER should
send an on-demand request for Mobility Binding Information to the
designated Mobility Route Reflector. This request is encoded as a
special type of the MP_REACH_NLRI attribute using a specific SAFI
value and one of the AFI values defined earlier. The Mobility Route
Reflector should process the request and return the Mobility Binding
update to the requesting LER using the NLRI encoding shown in
Section 3.2.2.
Berzin & Malis Expires May 2, 2008 [Page 40]
Internet-Draft Mobility Label Based Network October 2007
Specifically the following new SAFI value is defined for the On-
Demand Mobility Binding Information Request:
Mobility IPv4 Unicast - AFI X1 SAFI Y3
Mobility IPv6 Unicast - AFI X2 SAFI Y3
The NLRI encoding is shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP-BGP NEXT_HOP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Request Type | Region_ID | Number of Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Destination Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
NLRI Encoding for On-Demand Mobility Binding Request
Figure 20
MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the On-
Demand Mobility Binding Information Request. This address may be
carried in the IPv4 or IPv6 format depending on the {AFI, SAFI}
pair used.
Request Type - To be defined (may be "Specific, Partial, ALL or
LRL").
Region_ID - An Identifier (1-255) associated with the Regional
Mobility Route Reflector. Region_ID=0 must be used for initial
registrations by mobile nodes.
Number of Addresses - Number of IP Destination Addresses listed in
the On-Demand Request for which the Mobility Binding Information
is requested
IP Destination Address - The IPv4 or IPv6 address of a mobile host
for which the Mobility Binding Information is requested.
If the Request Type is not equal to LRL - Last Requestor List, the
Mobility Route Reflector (mRR) should reply with a regular Mobility
Berzin & Malis Expires May 2, 2008 [Page 41]
Internet-Draft Mobility Label Based Network October 2007
Binding Update. If the request type is equal to LRL, then the
following reply format should be used:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP-BGP NEXT_HOP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Request Type | Reserved | Number of Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LRL Length | IP Destination + |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Last Requestor + |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router_ID |L.R. Region_ID | Last + |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requestor Router_ID |L.R. Region_ID | LRL + |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | IP Destination + |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Last Requestor + |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router_ID |L.R. Region_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
NLRI Encoding for On-Demand LRL Reply
Figure 21
MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the On-
Demand LRL Reply. This address may be carried in the IPv4 or IPv6
format depending on the {AFI, SAFI} pair used.
Request Type - LRL Reply.
Number of Addresses - LRL's in the reply
IP Destination Address - The IPv4 or IPv6 address of a mobile host
for which the LRL Information is requested.
Last Requestor Router_ID - IP Address of the LER from which the
On-Demand Mobility Binding Information Request for the mobile node
in question was last received (may be more than one).
Berzin & Malis Expires May 2, 2008 [Page 42]
Internet-Draft Mobility Label Based Network October 2007
L.R. Region_ID - ID of the Regional mRR serving the LER from which
the On-Demand Mobility Binding Information Request for the mobile
node in question was last received (may be more than one).
4.1.5. Network Hierarchy Considerations
The first three update modes are directly applicable for the flat MSF
LER peering topology and the fourth to the hierarchical peering
environment. In the hierarchical peering environment only
Unsolicited Downstream Push does not require any modifications to the
Route Reflector operation. The Selective and Predictive modes
require that the Route Reflectors perform selective MP-BGP updates
for the Mobility Bindings distribution. This can be achieved by a
modification of the Route Reflector update process where destinations
of the selective updates indicated by the Update Type Code can be
derived from the "Target NEXT_HOP" parameter in the Mobility Binding
structure. The Hierarchical On-Demand mode requires the Route
Reflectors to store the Mobility Bindings and respond to the on-
demand Mobility Binding requests initiated by the client MSF LER
nodes or other Mobility Route Reflectors.
4.1.6. Regionalization and Scalability
To improve the scalability of the network update process the entire
serving network may be divided into the Registration Regions. Each
registration region is served by a Regional Mobility Route Reflector
(mRR) with the individual MSF LER nodes falling within the region
serving as the Route Reflector Clients. Each MSF LER node in turn
may serve a specific geographic area called a Mobility Region that is
covered by a given set of Radio Access Networks using Direct or In-
direct Attachment options. This type of the regionalized mobility
signaling infrastructure is referred to as the Mobility Information
Location System (MILS) and is shown in the figure below.
Berzin & Malis Expires May 2, 2008 [Page 43]
Internet-Draft Mobility Label Based Network October 2007
mRR1 mRR3
+----+ +----+
| +------------------+ `.
.++-+-+ mRR2 +--+-\ `.
.'//| | +----+ | |`. \
.' /| | +--------+ +---------+ |\ \ `.
Registration Region 1 ++++-\ Registration region 4
.' / / | /\ \ `. | \ \ `.
.' / | | Registration region 2 | \ `. `.
+-.' / +-/ | / | \ \ | | \ \
+-+ +-/ +-+ +-\ | \ \ \ \-+ \ `.-+`.
LER11 +-+ LER13+-+ +-/ | \-+ `. +-+ \-+ +-+ +`.
. LER12 . LER14 +-+ +-\ +-+ +-\ LER31 +-+ LER33+-+
/ \ . / \ . LER21 +-+ LER23+-+ . LER32 . LER34
; : / \ ; : / \ . LER22 . LER24 / \ . / \ .
|11 | ;12 :|13 |;14 : / \ . / \ . ; : / \ ; : / \
| | | || || | ;21 : / \ ; : / \ |31 |;32 :|33 |;34 :
|++ | | || || | | | ;22 :|23 |;24 : | || || || |
:++MN | |: ;| | | | | || || | | || || || |
\ / : ; \ / : ; | | | || || | : ;| |: ;|++ |
' \ / ' \ / : ; | |: ;| | \ / : ; \ / :++CN
' ' \ / : ; \ / : ; ' \ / ' \ /
' \ / ' \ / ' '
' '
Mobility Regions
Regionalized Mobility Information Location System
Figure 22
4.1.6.1. Mobility Information Location System (MILS)
The operation of MILS is based on the Hierarchical On-Demand Network
Update mode and requires the individual MSF LER nodes to only
directly update their respective Regional Mobility Route Reflectors
(using the Selective Update). After the Regional mRR's have been
updated with the Mobility Binding information, these bindings may be
explicitly requested by the MSF LER's in the same Registration Region
or the LER's in other regions via their mRR's. To facilitate the
hand-off process a Last Requestor List (LRL) is introduced and
associated with each Mobility Binding at the Regional mRR level. The
LRL is a list of 2-tuples where each 2-tuple consists of the
Router_ID and Region_ID of the MSF LER nodes that have requested
Mobility Binding information for a particular mobile node. The
logical operation of MILS is described below based on Figure 22.
1. Assume that a previously unknown MN initiated a Discovery and
Berzin & Malis Expires May 2, 2008 [Page 44]
Internet-Draft Mobility Label Based Network October 2007
Registration process in the Mobility Region 11. Upon successful
registration MN communicates its IP address to the MSF in LER11 and
receives the related MSF information including the Region_ID=1.
(During the registration the newly initialized MN should use
Region_ID=0).
2. LER11 creates a local Mobility Binding for the MN and updates
mRR1 using the Selective Mode specifying the MN's IP address, It's
own Router_ID, the Mobility Label and the initial Region_ID=0. LER11
stores the received Mobility Binding and associates an empty LRL with
it.
3. Assume that a Correspondent Node (CN) in the Mobility Region 34
sends a packet to the MN in the Mobility Region 11. The packet
reaches LER34.
4. LER34 identifies that the packet falls into the mobility address
range and requests Mobility Binding information from its Regional
mRR3 using On-Demand Mobility Binding Request (see Figure 20). LER34
uses the value of the Region_ID=3 in the request.
5. Since mRR3 does not have the Mobility Binding for the MN it
forwards the requests to both mRR1 and mRR2. mRR1 replies with the
Mobility Binding and mRR3 forwards the reply to LER34. Both mRR1 and
mRR3 associate an LRL with the Mobility Binding listing the LER34
Router_ID and the Region_ID=3.
6. LER34 forwards the packet to the MN using the LSP between LER11
and LER34 and a stacked Mobility Label extracted from the received
Mobility Binding.
7. Assume that MN now moves into the Mobility Region 22. It
initiates a new Discovery and Registration procedure and registers
with the MSF at LER22 specifying its IP address and the Last
Region_ID=1.
8. LER22 creates a local Mobility Binding for the MN and updates its
regional mRR2 using Selective Mode and sending the Region_ID=1 along
with the Mobility Binding.
9. mRR2 receives the new Mobility Binding and examines the associated
value of Region_ID. If it is not equal to 0 then the LRL for this
binding must be requested from the mRR identified by the Region_ID.
In this case mRR2 sends the On-Demand request to mRR1 asking for the
associated LRL created in step 5.
10. mRR2 receives the LRL={Router_ID=LER34, Region_ID=3} from mRR1
(see Figure 21) and sends a Mobility Binding update to mRR3 using the
Berzin & Malis Expires May 2, 2008 [Page 45]
Internet-Draft Mobility Label Based Network October 2007
Selective Downstream Push Mode with the "Target MP-BGP NEXT_HOP" set
to the LER34 Router_ID.
11. mRR3 receives the updated Mobility Binding and looks up the
"Target MP-BGP NEXT_HOP". In this case it is equal to the LER34
Router_ID. mRR3 updates LER34 with the new Mobility Binding using
Selective Downstream Push. LER34 starts to forward packets to the MN
using the LSP between LER34 and LER22 (listed as the "Origin MP-BGP
NEXT_HOP" in the updated Mobility Binding) and the new overlay
Mobility Label.
4.2. Hand-off Processing
The use of the Multi-Protocol BGP for mobility management allows a
simple basic hand-off processing scheme to be implemented. In
particular, when a mobile node detects that it can no longer receive
the keepalive acknowledgements from the serving MSF it initiates the
new discovery and registration procedure. After the successful
registration the new serving MSF will assign and distribute a new
Mobility Binding to the rest of the participating LER nodes thus
replacing the corresponding old Mobility Binding entries in their MSF
databases. Once the entries have been replaced by the new Mobility
Binding the LER nodes will automatically forward the packets destined
for the mobile node onto the new LSPs connecting to the mobile node's
new serving MSF and the corresponding new Radio Access Network.
The described hand-off procedure provides a basic hand-off handling
in that it requires a new mobile node registration to trigger the
Mobility Binding update to the network. The service disruption due
to the time required to detect the loss of communication and to
discover the new MSF and register with it can be minimized by
selecting the fast keepalive timers but this in turn will result in
the increased processing overhead and a possible impact on
scalability. At the same time the frequency of the hand-offs between
the MSF LER nodes can reasonably be expected to be much lower then
the frequency of the Layer 2 hand-offs because the MSF enabled LER is
expected to serve a large area potentially covered by multiple Radio
Access Networks. Therefore a reasonable configuration of the
keepalive timers and the low frequency of the MSF-to-MSF hand-offs
may result in an acceptable network responsiveness especially for
disruption tolerant applications.
In cases where the application sensitivity requires a better network
responsiveness a number of more sophisticated hand-off methods can be
implemented. One of the methods may make use of the Group
Registration as described above. In this case no discovery or
registration is required from the mobile node when it moves into the
new service area - it simply must continue to send packets to the
Berzin & Malis Expires May 2, 2008 [Page 46]
Internet-Draft Mobility Label Based Network October 2007
group address and whichever group member happens to be serving the
mobile node will distribute the pre-assigned Mobility Label to update
the network. Thus the hand-off latency becomes only a function of
the MP-BGP update processing as opposed to being a function of a
combination of a potentially lengthy discovery and registration as
well as the MP-BGP update procedures. Again, this scheme requires a
trade-off analysis between the gain in the network responsiveness and
the cost in signaling and processing required to maintain the shared
registration table.
4.3. Micro-Mobility Handling
In the context of Mobile IP Micro-Mobility can be defined as a range
of the mobile node movements that do not require re-registrations
with the Mobile IP HA. A number of proposals exist that are targeted
to extend the range of micro-mobility by utilizing the hierarchical
mobility management schemes.
In the context of this document micro-mobility is defined as the
range of the mobile node's movements that do not result in the
registration with a new MSF or the network update by MP-BGP, or both.
As such the following two micro-mobility scenarios are considered by
this proposal.
4.3.1. Local Micro-Mobility
Local micro-mobility is defined as the range of movements of the
mobile node that is contained within the serving area of a given MSF
enabled LER node. Referring to Figure 1 this moving pattern would
correspond to the mobile node transitioning between the radio cells
associated with the L3 logical interfaces local to the serving LER
node. Clearly such a movement pattern should not result in either
the re-registration with the MSF or the network update by MP-BGP.
In order to support Local Micro-Mobility the MSF should have the
capability of "tracking" the mobile node association with the LER L3
logical interfaces. This "tracking" may simply be based on the
reception of the datagrams from the mobile node. If the packets from
the same L2 address and L3 source addresses started arriving on a new
L3 logical interface of the LER and the MSF registration for the
mobile node in question is active the MSF should associate the new L3
logical interface with the existing registration entry and the
corresponding local Mobility Binding.
4.3.2. Group Micro-Mobility
Group Micro-Mobility makes direct use of the Group Registration
described in Section 3.1.3. In this case the Group Micro-Mobility is
Berzin & Malis Expires May 2, 2008 [Page 47]
Internet-Draft Mobility Label Based Network October 2007
defined as the range of the mobile node's movements that do not
result in the MSF re-registration process. Group Micro-Mobility
still requires the network update by MP-BGP.
Berzin & Malis Expires May 2, 2008 [Page 48]
Internet-Draft Mobility Label Based Network October 2007
5. Datagram Delivery
The delivery of packets from the MSF registered mobile node to other
network destinations uses the same processing as in the other MPLS
services. Namely, when a packet is received from the mobile node the
LER looks up the MPLS forwarding database to find a FEC to which the
destination IP address belongs. Once the FEC is identified the
corresponding MPLS label (or label stack) is used to send the packet
on the LSP toward the destination.
For the packets destined to the mobile node, when the packet is
received by the LER the MSF performs a lookup in the overlay MPLS
forwarding table to find the Mobility Binding matching the
destination address of the mobile node (this binding entry was
populated as the result of the Mobility Binding Distribution
process). Once the match is found the inner MPLS label is pushed
onto the MPLS label stack. Then the LER performs an additional
lookup to find a FEC and the corresponding label matching the "Origin
MP-BGP NEXT_HOP" LER IP address associated with this Mobility
Binding. This outer label is then pushed onto the MPLS label stack
and the packet is forwarded on the LSP.
At the receiving MSF enabled LER the packet is processed and the
inner MPLS label is examined to find the reverse Mobility Binding
match in order to identify the IP address of the mobile node. Once
the IP address is identified the corresponding Layer 2 address is
found in the MSF registration database. The packet payload is then
encapsulated into the Layer 2 protocol and delivered to the mobile
node.
In the case when the mobility service is provided to the mobile
router, the forwarding of packets follows the same procedure for the
service provider MPLS network segment. The packet forwarding between
the mobile router and the serving MSF enabled LER does not have to
use MPLS and can be based on IPv4 or IPv6 and the corresponding radio
attachment layer 2 protocol.
Berzin & Malis Expires May 2, 2008 [Page 49]
Internet-Draft Mobility Label Based Network October 2007
6. Security Considerations
The Lightweight Registration procedure (see Section 3.1.3.1.1) and
the associated Network Update and traffic processing provides the
capability to bypass the Full Registration mode in favor of the
ability to significantly decrease the registration processing time.
From the security perspective this procedure should only be allowed
if the layer 2 radio access network provides acceptable mobile node
authentication.
To provide for stronger authentication, the Full or the Group
Registration procedures must be used (see Section 3.1.3.1.2,
Section 3.1.3.1.3). These procedures allow to use additional
authentication procedures by making use of the Registration Request
and Reply message extensions (see Figure 10, Figure 11).
For the Mobile Routers, existing routing protocol security procedures
such as the peer authentication may be used.
Berzin & Malis Expires May 2, 2008 [Page 50]
Internet-Draft Mobility Label Based Network October 2007
7. IANA Considerations
New ICMP code values for message types 9, 10, 133 and 134:
Type=10 - IPv4 Router Solicitation, Code=1 - MLBN MSF Discovery
Extension
Type=9 - IPv4 Router Advertisement, Code=1 - MLBN MSF
Advertisement Extension
Type=133 - IPv6 Router Solicitation, Code=1 - MLBN MSF Discovery
Extension
Type=134 - IPv6 Router Advertisement, Code=1 - MLBN MSF
Advertisement Extension
New UDP port number:
UDP Port RRR for the MLBN Full and Group Registration Protocol.
New {AFI, SAFI} pairs for MP-BGP:
AFI=X1, SAFI=Y1 - MLBN Mobility Binding IPv4 Unicast
AFI=X1, SAFI=Y2 - MLBN Group Registration IPv4 Unicast
AFI=X1, SAFI=Y3 - MLBN On-Demand Binding Information IPv4 Unicast
AFI=X2, SAFI=Y1 - MLBN Mobility Binding IPv6 Unicast
AFI=X2, SAFI=Y2 - MLBN Group Registration IPv6 Unicast
AFI=X2, SAFI=Y3 - MLBN On-Demand Binding Information IPv6 Unicast
Berzin & Malis Expires May 2, 2008 [Page 51]
Internet-Draft Mobility Label Based Network October 2007
8. Acknowledgements
The authors would like to thank Dr. Stuart Elby of Verizon
Communications for his insights and valuable suggestions related to
this work.
Berzin & Malis Expires May 2, 2008 [Page 52]
Internet-Draft Mobility Label Based Network October 2007
9. IPR Notice
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Berzin & Malis Expires May 2, 2008 [Page 53]
Internet-Draft Mobility Label Based Network October 2007
10. References
10.1. Normative References
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4443] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 4443, March 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC4861] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 5036, October 2007.
10.2. Informative References
[MM-MPLS] Langar, L., Toshme, S., and N. Bouabdallah, "An Approach
for Mobility Modeling - Towards an Efficient Mobility
Berzin & Malis Expires May 2, 2008 [Page 54]
Internet-Draft Mobility Label Based Network October 2007
Management Support in Future Wireless Networks", IEEE/
IFIP NOMS, 2006.
Berzin & Malis Expires May 2, 2008 [Page 55]
Internet-Draft Mobility Label Based Network October 2007
Authors' Addresses
Oleg Berzin
Verizon Communications
1717 Arch Street
Philadelphia, PA 19103
US
Phone: +1 215-466-2738
Email: oleg.berzin@verizon.com
Andrew G. Malis
Verizon Communications
40 Sylvan Road
Waltham, MA 02451
US
Phone: +1 781-466-2362
Email: andrew.g.malis@verizon.com
Berzin & Malis Expires May 2, 2008 [Page 56]
Internet-Draft Mobility Label Based Network October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Berzin & Malis Expires May 2, 2008 [Page 57]