Internet DRAFT - draft-chan-dmm-enhanced-mobility-anchoring
draft-chan-dmm-enhanced-mobility-anchoring
DMM H. Chan, Ed.
Internet-Draft Huawei Technologies
Intended status: Informational K. Pentikousis, Ed.
Expires: January 4, 2015 EICT
July 3, 2014
Enhanced mobility anchoring
draft-chan-dmm-enhanced-mobility-anchoring-00
Abstract
This document initiates the discussion on enhanced mobility anchoring
solutions in the context of a distributed mobility management
deployment. Such solutions consider the problem of assigning a
mobility anchor and a gateway at the initiation of a session. In
addition, the mid-session switching of the mobility anchor in a
distributed mobility management environment is considered.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 4, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 1]
Internet-Draft mobility anchor switching July 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
3. Enhanced anchor switching . . . . . . . . . . . . . . . . . . . 4
3.1. Anchor switching between subnets . . . . . . . . . . . . . 4
3.2. Anchor switching between networks . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 2]
Internet-Draft mobility anchor switching July 2014
1. Introduction
A key requirement in distributed mobility management
[I-D.ietf-dmm-requirements] is to enable traffic to avoid traversing
single mobility anchor far from the optimal route. Recent
developments in research and standardization with respect to future
deployment models call for far more flexibility in network function
operation and management. For example, the work on service function
chaining at the IETF (SFC WG) has already identified a number of use
cases for data centers. Although the work in SFC is not primarily
concerned with mobile networks, the impact on IP-based mobile
networks is not hard to see as by now most hosts connected to the
Internet do so over a wireless medium. For instance, as a result of
a dynamic re-organization of service chain a non-optimal route
between mobile nodes may arise if pme relies solely on centralized
mobility management. As discussed earlier in the distributed
mobility management working group (DMM WG) this may also occur when
the mobile node has moved such that both the mobile node and the
correspondent node are far from the mobility anchor via which the
traffic is routed.
Motivated by the above-mentioned developments as well as
[I-D.ietf-dmm-requirements] we aim with this draft to initiate the
discussion on enhanced mobility anchoring. Recall that distributed
mobility management solutions do not make use of centrally deployed
mobility anchor. As such, an application session SHOULD be able to
have its traffic passing from one mobility anchor to another as the
mobile node moves, or when changing operation and management (OAM)
requirements call for mobility anchor switching, thus avoiding non-
optimal routes.
2. Conventions and Terminology
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].
All general mobility-related terms and their acronyms used in this
document are to be interpreted as defined in the Mobile IPv6 base
specification [RFC6275] and in the Proxy Mobile IPv6 specification
[RFC5213]. This includes terms such as mobile node (MN),
correspondent node (CN), home agent (HA), home address (HoA), care-
of-address (CoA), local mobility anchor (LMA), and mobile access
gateway (MAG).
In addition, this document uses the following term:
Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 3]
Internet-Draft mobility anchor switching July 2014
Home network of an application session (or of an HoA) is the network
that has allocated the IP address (HoA) used for the session
identifier by the application running in an MN. An MN may be
running multiple application sessions, and each of these sessions
can have a different home network.
3. Enhanced anchor switching
In this section we consider mid-session mobility anchor switching for
two cases. First we discuss the case where the mobile node moves
from one subnet to another, and then we discuss the case where the
node moves to a different network. Note that although the cases are
described with traditional (read: physical) node mobility in mind,
the proposed mechanism can be triggered for other operational
reasons, such as the redefinition of a service chain graph, due to
mechanisms which indicate that by relocating the mobility anchor for
certain sessions energy and other operation expenditure can be
reduced, or due to emergency situations, such as physical
catastrophes.
3.1. Anchor switching between subnets
First we consider the situation illustrated in Fig. 1: The mobile
node (M) moves from Subnet 1 to Subnet 2. Each of the Network A
Subnets (1, 2, and so on) owns a block of IP addresses. In each
subnet, the corresponding access router (AR1, AR2, ...) advertises
the routes for the block of addresses of that subnet.
Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 4]
Internet-Draft mobility anchor switching July 2014
+----------+
| Network A|
|Controller|
+----------+
+---+ +---+ +---+
|AR1| |AR2| |AR3|
+--------+ +--------+ +--------+
|Subnet 1| |Subnet 2| |Subnet 3| ....
+--------+ +--------+ +--------+
+----+ +----+
| M | =====> | M |
|with| |with|
|IP1 | |IP2 |
| | |IP1 |
+----+ +----+
Figure 1. Movement of M from Subnet 1 to Subnet 2.
Before moving, M is allocated an IP address IP1 from Subnet 1, and it
may run network applications using this IP address.
As M moves to Subnet 2, it obtains a new IP address IP2 from Subnet
2. The applications that can handle a change of IP address will use
the address IP2 [I-D.seite-dmm-dma]. Other ongoing applications that
cannot survive an IP address change will need to continue using IP11
to maintain session continuity. A mobility management protocol may
be used to enable M to use the address IP1 belonging to Subnet 1.
The AR1 access router in Subnet 1 may delegate the IP address (IP1)
to the access router AR2 in Subnet 2. AR2 will then advertise IP1 so
that the routing tables in Network A will be updated and packets
destined to IP1 will be routed to Subnet 2.
Relying on earlier routing table update mechanisms with a distributed
routing protocol may not be fast enough to meet the requirement for a
short handover delay. In the case where a control and data plane
separation model is followed, a logically centralized mechanism can
perform the forwarding table update faster. For example, we can
consider the use of I2RS mechanisms or the possibility to employ
NETCONF [RFC6241] for reconfiguring AR2.
Alternatively, a tunneling mobility management protocol such as MIPv6
[RFC6275] or PMIPv6 [RFC5213] may be used initially [Paper-
Distributed.Mobility.PMIP] to enable M to use the IP address IP1
while IP1 still belongs to Subnet 1. The route may not be optimized
initially, but this is a good tradeoff so that anchor switching can
Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 5]
Internet-Draft mobility anchor switching July 2014
take place. After anchor switching and its subsequent forwarding
table update have been completed, packets destined to IP1 will be
routed directly towards M.
The address delegation of IP1 from Subnet 1 to Subnet 2 may timeout
unless there is request to renew it before it expires. When all
applications using IP1 in M have been terminated, there will be no
longer need for using IP1 in Subnet 2. If there are still such
applications running when the address delegation is about to timeout,
the mobile node may signal with AR1 to request renewal of address
delegation.
3.2. Anchor switching between networks
Fig. 2 illustrates the movement of a mobile node (M) from Subnet a1
of Network A to Subnet b2 of Network B. In this case, each Network
(A, B, and so on) owns the aggregate of IP addresses blocks for its
subnets. The corresponding gateway routers (GWa, GWb, ...) may run
an IBGP among them, and each advertises the aggregate of IP addresses
for its subnets.
+---+ +---+ +---+
|GWa| |GWb| |GWc|
+----------+ +----------+ +----------+
|Network A | |Network B | |Network C | ....
|Controller| |Controller| |Controller|
+----------+ +----------+ +----------+
+----+ +----+
|ARa1| |ARb2|
+---------+ +---------+
|Subnet a1| |Subnet b2| ....
+---------+ +---------+
+-----+ +-----+
| M | =====> | M |
| with| | with|
|IPa11| |IPb21|
| | |IPa11|
+-----+ +-----+
Figure 1. Movement of M from Subnet a1 of Network A to Subnet b2 of
Network B.
Before moving, M is allocated the IP address IPa11 from Subnet a1 of
Network A, and it may run network applications using this IP address.
Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 6]
Internet-Draft mobility anchor switching July 2014
As M moves to Subnet b2, it obtains a new IP address IPb21 from
Subnet b2 of Network B. The applications that can handle a change of
IP address will use this new address IPb21. Other applications with
ongoing sessions that cannot survive an IP address change will need
to continue using IPa11 to maintain session continuity. A mobility
management protocol may be used to enable M to use the address IPa11
belonging to Subnet a1 in Network A.
As the access router ARa1 in Subnet a1 may delegate the address IPa11
to the access router ARb2 in Subnet b2, the gateways GWa, GWb, ...
also need to update the routing information so that GWb will then
advertise IPa11 so that the routing tables in GWa, GWb, ... will
update and packets destined to IPa11 will be routed to Network B.
The routing table update between the gateways MAY be accomplished
using IS-IS. In scenarios where the control plane and the data plane
for these gateways are separate, and there is a controller for these
gateways, a centralized routing protocol can also perform the
forwarding table update for these gateways.
Optionally, a tunneling mobility management protocol such as MIPv6
[RFC6275] or PMIPv6 [RFC5213] may be used to initially enable M to
use the address IPa11 while IPa11 still belongs to Subnet a1 of
Network A. Although such a route may not be optimized initially, it
enables anchor switching to take place. After anchor switching and
its subsequent forwarding table update have been completed, the
packets destined to IPa11 will be routed directly towards M.
The address delegation of IPa11 from Subnet a1 to Subnet b2 may
timeout unless there is request to renew it before it expires. When
the applications uisng IPa11 in M have all been terminated, there
will be no longer need for using IPa11 in Subnet b2. If there are
still such applications running when the address delegation is about
to timeout, the mobile node may signal with ARa1 to request renewal
of address delegation.
4. Security Considerations
TBD
5. IANA Considerations
This document presents no IANA considerations.
6. References
Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 7]
Internet-Draft mobility anchor switching July 2014
6.1. Normative References
[I-D.ietf-dmm-requirements]
Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management",
draft-ietf-dmm-requirements-17 (work in progress),
June 2014.
[I-D.seite-dmm-dma]
Seite, P., Bertin, P., and J. Lee, "Distributed Mobility
Anchoring", draft-seite-dmm-dma-07 (work in progress),
February 2014.
[I-D.yokota-dmm-scenario]
Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case
scenarios for Distributed Mobility Management",
draft-yokota-dmm-scenario-00 (work in progress),
October 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
6.2. Informative References
[Paper-Distributed.Mobility.PMIP]
Chan, H., "Proxy Mobile IP with Distributed Mobility
Anchors", Proceedings of GlobeCom Workshop on Seamless
Wireless Mobility, December 2010.
[Paper-Distributed.Mobility.Review]
Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,
"Distributed and Dynamic Mobility Management in Mobile
Internet: Current Approaches and Issues", February 2011.
Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 8]
Internet-Draft mobility anchor switching July 2014
Authors' Addresses
H Anthony Chan
Huawei Technologies
5340 Legacy Dr. Building 3
Plano, TX 75024
USA
Email: h.a.chan@ieee.org
Kostas Pentikousis
EICT
EUREF-Campus Haus 13
Torgauer Strasse 12-15
10829 Berlin
Germany
Email: k.pentikousis@eict.de
Chan, Ed. & Pentikousis, Ed. Expires January 4, 2015 [Page 9]
