draft-ietf-dmm-distributed-mobility-anchoring-05.txt   draft-ietf-dmm-distributed-mobility-anchoring-06.txt 
DMM H. Chan, Ed. DMM H. Chan, Ed.
Internet-Draft X. Wei Internet-Draft X. Wei
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: November 10, 2017 J. Lee Expires: January 4, 2018 J. Lee
Sangmyung University Sangmyung University
S. Jeon S. Jeon
Sungkyunkwan University Sungkyunkwan University
A. Petrescu A. Petrescu
CEA, LIST CEA, LIST
F. Templin F. Templin
Boeing Research and Technology Boeing Research and Technology
May 9, 2017 July 3, 2017
Distributed Mobility Anchoring Distributed Mobility Anchoring
draft-ietf-dmm-distributed-mobility-anchoring-05 draft-ietf-dmm-distributed-mobility-anchoring-06
Abstract Abstract
This document defines distributed mobility anchoring in terms of the This document defines distributed mobility anchoring in terms of the
different configurations, operations and parameters of mobility different configurations, operations and parameters of mobility
functions to provide different IP mobility support for the diverse functions to provide different IP mobility support for the diverse
mobility needs in 5G Wireless and beyond. A network or network slice mobility needs in 5G Wireless and beyond. A network may be
may be configured with distributed mobility anchoring functions configured with distributed mobility anchoring functions according to
according to the needs of mobility support. In the distributed the needs of mobility support. In the distributed mobility anchoring
mobility anchoring environment, multiple anchors are available for environment, multiple anchors are available for mid-session switching
mid-session switching of an IP prefix anchor. To start a new flow or of an IP prefix anchor. To start a new flow or to handle a flow not
to handle a flow not requiring IP session continuity as a mobile node requiring IP session continuity as a mobile node moves to a new
moves to a new network, the flow can be started or re-started using a network, the flow can be started or re-started using a new IP address
new IP address configured from the new IP prefix which is anchored to configured from the new IP prefix which is anchored to the new
the new network. For a flow requiring IP session continuity, the network. For a flow requiring IP session continuity, the anchoring
anchoring of the prior IP prefix may be moved to the new network. of the prior IP prefix may be moved to the new network. The mobility
The mobility functions and their operations and parameters are functions and their operations and parameters are general for
general for different configurations. The mobility signaling may be different configurations. The mobility signaling may be between
between anchors and nodes in the network in a network-based mobility anchors and nodes in the network in a network-based mobility
solution. It may also be between the anchors and the mobile node in solution. It may also be between the anchors and the mobile node in
a host-based solution. The mobile node may be a host, but may also a host-based solution. The mobile node may be a host, but may also
be a router carrying a network requiring network mobility support. be a router carrying a network requiring network mobility support.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Distributed Mobility Anchoring . . . . . . . . . . . . . . . 7 3. Distributed Mobility Anchoring . . . . . . . . . . . . . . . 6
3.1. Configurations for Different Networks or Network Slices . 7 3.1. Configurations for Different Networks . . . . . . . . . . 6
3.1.1. Network-based Mobility Support for a Flat Network . . 7 3.1.1. Network-based Mobility Support for a Flat Network . . 7
3.1.2. Network-based Mobility Support for a Hierarchical 3.1.2. Network-based Mobility Support for a Hierarchical
Network . . . . . . . . . . . . . . . . . . . . . . . 8 Network . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3. Host-based Mobility Support . . . . . . . . . . . . . 11 3.1.3. Host-based Mobility Support . . . . . . . . . . . . . 10
3.1.4. NEtwork MObility (NEMO) Basic Support . . . . . . . . 11 3.1.4. NEtwork MObility (NEMO) Basic Support . . . . . . . . 11
3.2. Operations and Parameters . . . . . . . . . . . . . . . . 13 3.2. Operations and Parameters . . . . . . . . . . . . . . . . 12
3.2.1. Location Management . . . . . . . . . . . . . . . . . 13 3.2.1. Location Management . . . . . . . . . . . . . . . . . 12
3.2.2. Forwarding Management . . . . . . . . . . . . . . . . 16 3.2.2. Forwarding Management . . . . . . . . . . . . . . . . 15
4. IP Mobility Handling in Distributed Anchoring Environments - 4. IP Mobility Handling in Distributed Anchoring Environments -
Mobility Support Only When Needed . . . . . . . . . . . . . . 24 Mobility Support Only When Needed . . . . . . . . . . . . . . 21
4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 24 4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 22
4.1.1. Guidelines for IPv6 Nodes: Changing to New IP 4.1.1. Guidelines for IPv6 Nodes: Changing to New IP
Prefix/Address . . . . . . . . . . . . . . . . . . . 26 Prefix/Address . . . . . . . . . . . . . . . . . . . 23
4.2. Need of IP Mobility . . . . . . . . . . . . . . . . . . . 28 4.2. Need of IP Mobility . . . . . . . . . . . . . . . . . . . 25
4.2.1. Guidelines for IPv6 Nodes: Need of IP Mobility . . . 29 4.2.1. Guidelines for IPv6 Nodes: Need of IP Mobility . . . 26
5. IP Mobility Handling in Distributed Mobility Anchoring 5. IP Mobility Handling in Distributed Mobility Anchoring
Environments - Anchor Switching to the New Network . . . . . 31 Environments - Anchor Switching to the New Network . . . . . 28
5.1. IP Prefix/Address Anchor Switching for Flat Network . . . 31 5.1. IP Prefix/Address Anchor Switching for Flat Network . . . 28
5.1.1. Guidelines for IPv6 Nodes: Switching Anchor for Flat 5.1.1. Guidelines for IPv6 Nodes: Switching Anchor for Flat
Network . . . . . . . . . . . . . . . . . . . . . . . 32 Network . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. IP Prefix/Address Anchor Switching for Flat Network with 5.2. IP Prefix/Address Anchor Switching for Flat Network with
Centralized Control Plane . . . . . . . . . . . . . . . . 34 Centralized Control Plane . . . . . . . . . . . . . . . . 30
5.2.1. Additional Guidelines for IPv6 Nodes: Switching 5.2.1. Additional Guidelines for IPv6 Nodes: Switching
Anchor with Centralized CP . . . . . . . . . . . . . 36 Anchor with Centralized CP . . . . . . . . . . . . . 33
5.3. Hierarchical Network . . . . . . . . . . . . . . . . . . 37 5.3. Hierarchical Network . . . . . . . . . . . . . . . . . . 34
5.3.1. Additional Guidelines for IPv6 Nodes: Hierarchical 5.3.1. Additional Guidelines for IPv6 Nodes: Hierarchical
Network with No Anchor Relocation . . . . . . . . . . 39 Network with No Anchor Relocation . . . . . . . . . . 35
5.4. IP Prefix/Address Anchor Switching for a Hierarchical 5.4. IP Prefix/Address Anchor Switching for a Hierarchical
Network . . . . . . . . . . . . . . . . . . . . . . . . . 39 Network . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1. Additional Guidelines for IPv6 Nodes: Switching 5.4.1. Additional Guidelines for IPv6 Nodes: Switching
Anchor with Hierarchical Network . . . . . . . . . . 41 Anchor with Hierarchical Network . . . . . . . . . . 37
5.5. Network Mobility . . . . . . . . . . . . . . . . . . . . 41 5.5. Network Mobility . . . . . . . . . . . . . . . . . . . . 38
5.5.1. Additional Guidelines for IPv6 Nodes: Network 5.5.1. Additional Guidelines for IPv6 Nodes: Network
mobility . . . . . . . . . . . . . . . . . . . . . . 43 mobility . . . . . . . . . . . . . . . . . . . . . . 40
6. Security Considerations . . . . . . . . . . . . . . . . . . . 44 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.1. Normative References . . . . . . . . . . . . . . . . . . 45 9.1. Normative References . . . . . . . . . . . . . . . . . . 42
9.2. Informative References . . . . . . . . . . . . . . . . . 48 9.2. Informative References . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
A key requirement in distributed mobility management [RFC7333] is to A key requirement in distributed mobility management [RFC7333] is to
enable traffic to avoid traversing a single mobility anchor far from enable traffic to avoid traversing a single mobility anchor far from
an optimal route. The traffic of a flow SHOULD then be able to an optimal route. This draft defines different configurations,
change from traversing one mobility anchor to traversing another functional operations and parameters for distributed mobility
mobility anchor as a mobile node (MN) moves, or when changing anchoring and explains how to use them to make the route changes to
operation and management requirements call for mobility anchor avoid unnecessarily long routes.
switching, thus avoiding non-optimal routes.
Companion distributed mobility management documents are already Companion distributed mobility management documents are already
addressing the architecture and deployment addressing the architecture and deployment
[I-D.ietf-dmm-deployment-models], source address selection [I-D.ietf-dmm-deployment-models], source address selection
[I-D.ietf-dmm-ondemand-mobility], and control-plane data-plane [I-D.ietf-dmm-ondemand-mobility], and control-plane data-plane
signaling [I-D.ietf-dmm-fpc-cpdp]. Yet in 5G Wireless and beyond, signaling [I-D.ietf-dmm-fpc-cpdp]. A number of distributed mobility
the mobility requirements are diverse, and IP mobility support is no solutions have also been proposed, for example, in
longer by default with a one-size-fit-all solution. In different [I-D.seite-dmm-dma], [I-D.bernardos-dmm-cmip],
networks or network slices [I-D.geng-netslices-architecture], [I-D.bernardos-dmm-pmip], [I-D.sarikaya-dmm-for-wifi],
different kinds of mobility support are possible depending on the [I-D.yhkim-dmm-enhanced-anchoring], and
needs. It may not always be obvious on how to best configure and use [I-D.matsushima-stateless-uplane-vepc]. Yet in 5G Wireless and
only the needed mobility functions to provide the specific mobility beyond, the mobility requirements are diverse, and IP mobility
support. This draft defines different configurations, functional support is no longer by default with a one-size-fit-all solution. In
operations and parameters for distributed mobility anchoring and different networks, different kinds of mobility support are possible
explains how to use them to make the route changes to avoid depending on the needs. In designing mobility solutions, it may not
unnecessarily long routes. always be obvious on how to best configure and use only the needed
mobility functions to provide the specific mobility support. This
document aims at filling such background.
Distributed mobility anchoring employs multiple anchors in the data Distributed mobility anchoring employs multiple anchors in the data
plane. In general, control plane functions may be separate from data plane. In general, control plane functions may be separate from data
plane functions and be centralized but may also be co-located with plane functions and be centralized but may also be co-located with
the data plane functions at the distributed anchors. Different the data plane functions at the distributed anchors. Different
configurations of distributed mobility anchoring are described in configurations of distributed mobility anchoring are described in
Section 3.1. For instance, the configurations for network-based Section 3.1. For instance, the configurations for network-based
mobility support in a flat network, for network-based mobility mobility support in a flat network, for network-based mobility
support in a hierarchical network, for host-based mobility support, support in a hierarchical network, for host-based mobility support,
and for NEtwork MObility (NEMO) basic support are described and for network mobility basic support are described respectively in
respectively in Section 3.1.1, Section 3.1.2, Section 3.1.3 and Section 3.1.1, Section 3.1.2, Section 3.1.3 and Section 3.1.4.
Section 3.1.4. Required operations and parameters for distributed Required operations and parameters for distributed mobility anchoring
mobility anchoring are presented in Section 3.2. For instance, are presented in Section 3.2. For instance, location management is
location management is described in Section 3.2.1, forwarding described in Section 3.2.1, forwarding management is described in
management is described in Section 3.2.2. Section 3.2.2.
As an MN attaches to an access router and establishes a link between As an MN attaches to an access router and establishes a link between
them, a /64 IPv6 prefix anchored to the router may be assigned to the them, a /64 IPv6 prefix anchored to the router may be assigned to the
link for exclusive use by the MN [RFC6459]. The MN may then link for exclusive use by the MN [RFC6459]. The MN may then
configure a global IPv6 address from this prefix and use it as the configure a global IPv6 address from this prefix and use it as the
source IP address in a flow to communicate with with its source IP address in a flow to communicate with with its
correspondent node (CN). When there are multiple mobility anchors, correspondent node (CN). When there are multiple mobility anchors,
an address selection for a given flow is first required before the an address selection for a given flow is first required before the
flow is initiated. Using an anchor in an MN's network of attachment flow is initiated. Using an anchor in an MN's network of attachment
has the advantage that the packets can simply be forwarded according has the advantage that the packets can simply be forwarded according
to the forwarding table. However, after the flow has been initiated, to the forwarding table. However, after the flow has been initiated,
the MN may later move to another network, so that the IP address no the MN may later move to another network, so that the IP address no
longer belongs to the current network of attachment of the MN. longer belongs to the current network of attachment of the MN.
Whether the flow needs IP session continuity will determine how to Whether the flow needs IP session continuity will determine how to
ensure that the IP address of the flow will be anchored to the new ensure that the IP address of the flow will be anchored to the new
network of attachment. If the ongoing IP flow can cope with an IP network of attachment. If the ongoing IP flow can cope with an IP
prefix/address change, the flow can be reinitiated with a new IP prefix/address change, the flow can be reinitiated with a new IP
address anchored in the new network as shown in Section 4.1. On the address anchored in the new network as shown in Section 4.1. On the
other hand, if the ongoing IP flow cannot cope with such change, other hand, if the ongoing IP flow cannot cope with such change,
mobility support is needed as shown in Section 4.2. A network or mobility support is needed as shown in Section 4.2. A network
network slice supporting a mix of flows both requiring and not supporting a mix of flows both requiring and not requiring IP
requiring IP mobility support will need to distinguish these flows. mobility support will need to distinguish these flows. The
The guidelines for the network or network slice to make such a guidelines for the network to make such a distinction are described
distinction are described in Section 4.1.1. The general guidelines in Section 4.1.1. The general guidelines for such network to provide
for such network or network slice to provide IP mobility support are IP mobility support are described in Section 4.2.1.
described in Section 4.2.1.
Specifically, IP mobility support can be provided by relocating the Specifically, IP mobility support can be provided by relocating the
anchoring of the IP prefix/address of the flow from the home network anchoring of the IP prefix/address of the flow from the home network
of the flow to the new network of attachment. The basic case may be of the flow to the new network of attachment. The basic case may be
with network-based mobility for a flat network configuration with network-based mobility for a flat network configuration
described in Section 5.1 with the guidelines described in described in Section 5.1 with the guidelines described in
Section 5.1.1. This case is discussed further with a centralized Section 5.1.1. This case is discussed further with a centralized
control plane in Section 5.2 with additional guidelines described in control plane in Section 5.2 with additional guidelines described in
Section 5.2.1. A level of hierarchy of nodes may then be added to Section 5.2.1. A level of hierarchy of nodes may then be added to
the network configuration. Mobility involving change in the Data the network configuration as described in Section 5.3 with additional
Plane Node (DPN) without changing the Data Plane Anchor (DPA) is guidelines described in Section 5.3.1. Local Mobility in such
described in Section 5.3 with additional guidelines described in hierarchical network is described in Section 5.4 with additional
Section 5.3.1. Mobility involving change in the DPN without changing guidelines described in Section 5.4.1. Network mobiltiy example is
the DPA is described in Section 5.4 with additional guidelines described in Section 5.5 with additional guidelines described in
described in Section 5.4.1. Section 5.5.1.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "GLUIRED", "SHALL","SHALL NOT", The key words "MUST", "MUST NOT", "GLUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
All general mobility-related terms and their acronyms used in this All general mobility-related terms and their acronyms used in this
document are to be interpreted as defined in the Mobile IPv6 (MIPv6) document are to be interpreted as defined in the Mobile IPv6 (MIPv6)
base specification [RFC6275], the Proxy Mobile IPv6 (PMIPv6) base specification [RFC6275], the Proxy Mobile IPv6 (PMIPv6)
skipping to change at page 5, line 36 skipping to change at page 5, line 35
local mobility anchor (LMA), and mobile access gateway (MAG). local mobility anchor (LMA), and mobile access gateway (MAG).
In addition, this document uses the following terms: In addition, this document uses the following terms:
Home network of an application session or a home address: the Home network of an application session or a home address: the
network that has assigned the HoA used as the session identifier network that has assigned the HoA used as the session identifier
by the application running in an MN. The MN may be running by the application running in an MN. The MN may be running
multiple application sessions, and each of these sessions can have multiple application sessions, and each of these sessions can have
a different home network. a different home network.
IP prefix/address anchoring: An IP prefix, i.e., Home Network Prefix Anchoring (an IP prefix/address): An IP prefix, i.e., Home Network
(HNP), or address, i.e., HoA, assigned for use by an MN is Prefix (HNP), or address, i.e., HoA, assigned for use by an MN is
topologically anchored to an anchor node when the anchor node is topologically anchored to an anchor node when the anchor node is
able to advertise a connected route into the routing able to advertise a connected route into the routing
infrastructure for the assigned IP prefix. infrastructure for the assigned IP prefix.
Location Management (LM) function: managing and keeping track of the Location Management (LM) function: that keeps and manages the
internetwork location of an MN. The location information may be a network location information of an MN. The location information
binding of the advertised IP address/prefix, e.g., HoA or HNP, to may be a binding of the advertised IP address/prefix, e.g., HoA or
the IP routing address of the MN or of a node that can forward HNP, to the IP routing address of the MN or of a node that can
packets destined to the MN. forward packets destined to the MN.
When the MN is a mobile router (MR) carrying a mobile network of When the MN is a mobile router (MR) carrying a mobile network of
mobile network nodes (MNN), the location information will also mobile network nodes (MNN), the location information will also
include the mobile network prefix (MNP), which is the aggregate IP include the mobile network prefix (MNP), which is the aggregate IP
prefix delegated to the MR to assign IP prefixes for use by the prefix delegated to the MR to assign IP prefixes for use by the
MNNs in the mobile network. MNNs in the mobile network.
LM is a control plane function.
In a client-server protocol model, location query and update In a client-server protocol model, location query and update
messages may be exchanged between a Location Management client messages may be exchanged between a Location Management client
(LMc) and a Location Management server (LMs). (LMc) and a Location Management server (LMs), where the location
information can be updated to or queried from the LMs.
Optionally, there may be a Location Management proxy (LMp) between Optionally, there may be a Location Management proxy (LMp) between
LMc and LMs. LMc and LMs.
With separation of control plane and data plane, the LM function With separation of control plane and data plane, the LM function
is in the control plane. It may be a logical function at the is in the control plane. It may be a logical function at the
control plane node, control plane anchor, or mobility controller. control plane node, control plane anchor, or mobility controller.
It may be distributed or centralized. It may be distributed or centralized.
Forwarding Management (FM) function: packet interception and Forwarding Management (FM) function: packet interception and
skipping to change at page 6, line 40 skipping to change at page 6, line 37
separation of control plane and data plane, the FM function may separation of control plane and data plane, the FM function may
split into a FM function in the data plane (FM-DP) and a FM split into a FM function in the data plane (FM-DP) and a FM
function in the control plane (FM-CP). function in the control plane (FM-CP).
FM-DP may be distributed with distributed mobility management. It FM-DP may be distributed with distributed mobility management. It
may be a function in a data plane anchor or data plane node. may be a function in a data plane anchor or data plane node.
FM-CP may be distributed or centralized. It may be a function in FM-CP may be distributed or centralized. It may be a function in
a control plane node, control plane anchor or mobility controller. a control plane node, control plane anchor or mobility controller.
Security Management (SM) function: The security management function
controls security mechanisms/protocols providing access control,
integrity, authentication, authorization, confidentiality, etc.
for the control plane and data plane.
This function resides in all nodes such as control plane anchor,
data plane anchor, mobile node, and correspondent node.
3. Distributed Mobility Anchoring 3. Distributed Mobility Anchoring
3.1. Configurations for Different Networks or Network Slices 3.1. Configurations for Different Networks
The mobility functions may be implemented in different configurations The mobility functions may be implemented in different configurations
of distributed mobility anchoring in architectures separating the of distributed mobility anchoring in architectures separating the
control and data planes. The separation described in control and data planes. The separation described in
[I-D.ietf-dmm-deployment-models] has defined the home control plane [I-D.ietf-dmm-deployment-models] has defined the home control plane
anchor (Home-CPA), home data plane anchor (Home-DPA), access control anchor (Home-CPA), home data plane anchor (Home-DPA), access control
plane node (Access-CPN), and access data plane node (Access-DPN), plane node (Access-CPN), and access data plane node (Access-DPN),
which are respectively abbreviated as CPA, DPA, CPN, and DPN here. which are respectively abbreviated as CPA, DPA, CPN, and DPN here.
Different networks or different network slices may have different Different networks may have different configurations in distributed
configurations in distributed mobility anchoring. mobility anchoring.
The configurations also differ depending on the desired mobility The configurations also differ depending on the desired mobility
supports: network-based mobility support for a flat network in supports: network-based mobility support for a flat network in
Section 3.1.1, network-based mobility support for a hierarchical Section 3.1.1, network-based mobility support for a hierarchical
network in Section 3.1.2, host-based mobility support in network in Section 3.1.2, host-based mobility support in
Section 3.1.3, and NEtwork MObility (NEMO) based support in Section 3.1.3, and NEtwork MObility (NEMO) based support in
Section 3.1.4. Section 3.1.4.
3.1.1. Network-based Mobility Support for a Flat Network 3.1.1. Network-based Mobility Support for a Flat Network
Figure 1 shows two different configurations of network-based Figure 1 show the configurations of network-based distributed
distributed mobility management for a flat network. mobility management for a flat network.
The features common to both Figures 1(a) and 1(b) are: The features in Figure 1 are:
dmm:1 There are multiple instances of DPA, each with an FM-DP dmm:1 There are multiple instances of DPA, each with an FM-DP
function. function.
dmm:2 The control plane may either be distributed (not shown) or dmm:2 The control plane may either be distributed (not shown) or
centralized. The CPA may co-locate with DPA or may separate. centralized. The CPA and DPA may co-locate or may be
When the CPA, each with an FM-CP function, is co-located with separate. When the CPA, each with an FM-CP function, is co-
the distributed DPA there will be multiple instances of the located with the distributed DPA there will be multiple
co-located CPA and DPA (not shown). instances of the co-located CPA and DPA (not shown).
dmm:3 An IP prefix/address IP1, which is anchored to the DPA with dmm:3 An IP prefix/address IP1, which is anchored to the DPA with
the IP prefix/address IPa1, is assigned for use by AN MN. The the IP prefix/address IPa1, is assigned for use by an MN. The
MN uses IP1 to communicate with a CN not shown in the figure. MN uses IP1 to communicate with a CN not shown in the figure.
The flow of this communication session is shown as flow(IP1, The flow of this communication session is shown as flow(IP1,
...), meaning it uses IP1 and other parameters. ...), meaning it uses IP1 and other parameters.
(a) (b) ____________ Network
+-----+ ___/ \___________
|LMs | / +-----+ \___
+-----+ ( |LMs | Control \
+------------+ +------------+ / +-.---+ plane \
|CPA: | |CPA: | / +--------.---+ functions \
|FM-CP, LM | |FM-CP, LMc | ( |CPA: . | in the )
+------------+ +------------+ ( |FM-CP, LMc | network )
+------------+ +------------+ +------------+ +------------+ ( +------------+ \
|DPA(IPa1): | |DPA(IPa2): | |DPA(IPa1): | |DPA(IPa2): | / . . \
|anchors IP1 | |anchors IP2 | ... |anchors IP1 | |anchors IP2 | ... ( . . )
|FM-DP | |FM-DP | |FM-DP | |FM-DP | ( . . )
+------------+ +------------+ +------------+ +------------+ ( . . \
\ +------------+ +------------+Distributed )
( |DPA(IPa1): | |DPA(IPa2): |DPA's )
( |anchors IP1 | |anchors IP2 | _/
\ |FM-DP | |FM-DP | etc. /
\ +------------+ +------------+ /
\___ Data plane _____/
\______ functions /
\__________________/
+------------+ +------------+ +------------+
|MN(IP1) | |MN(IP1) | |MN(IP1) | Mobile node attached
|flow(IP1,..)| |flow(IP1,..)| |flow(IP1,..)| to the network
+------------+ +------------+ +------------+
Figure 1. Configurations of network-based mobility management for a Figure 1. Configurations of network-based mobility management for a
flat network (a) FM-CP and LM at CPA, FM-DP at DPA; (b) Separate LMs, flat network to which MN is attached. The mobility management
FM-CP and LMc at CPA, FM-DP at DPA. functions in the network are LMs in the control plane, LMc at CPA,
and FM-DP at DPA.
In Figure 1(a), LM is at the CPA. Then LM may be distributed or In Figure 1, the LM function is split into a separate server LMs and
centralized according to whether the CPA is distributed (not shown) a client LMc at the CPA. Then, the LMs may be centralized whereas
or centralized. the LMc may be distributed or centralized according to whether the
CPA is distributed (not shown) or centralized.
Figure 1(b) differs from Figure 1(a) in that the LM function is split In a special case (not shown), LMs and LMc may co-locate.
into a separate server LMs and a client LMc at the CPA. Then, the
LMs may be centralized whereas the LMc may be distributed or
centralized according to whether the CPA is distributed (not shown)
or centralized.
3.1.2. Network-based Mobility Support for a Hierarchical Network 3.1.2. Network-based Mobility Support for a Hierarchical Network
Figure 2 shows two different configurations of network-based mobility Figure 2 shows the configurations of network-based mobility
management for a hierarchical network. management for a hierarchical network.
(a) +-----+
+------------+ |LMs |
|CPA: | +-.---+
|FM-CP, LMs | +--------.---+
+------------+ |CPA: . |
+------------+ +------------+ |FM-CP, LMp |
|DPA(IPa1): | |DPA(IPa2): | +------------+
|anchors IP1 | |anchors IP2 | ... . .
|FM-DP | |FM-DP | . .
+------------+ +------------+ . .
. .
+------------+ +------------+ +------------+ Distributed
|CPN: | |DPA(IPa1): | |DPA(IPa2): | DPA's
|FM-CP, LMc | |anchors IP1 | |anchors IP2 | etc.
+------------+ |FM-DP | |FM-DP |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
|DPN(IPn11): | |DPN(IPn12): | |DPN(IPn21): | |DPN(IPn22) |
|FM-DP | |FM-DP | ... |FM-DP | |FM-DP | ...
+------------+ +------------+ +------------+ +------------+
+------------+ +------------+
|MN(IP1) | |MN(IP2) |
|flow(IP1,..)| |flow(IP2,..)|
+------------+ +------------+
Figure 2(a). Configurations of network-based mobility management for
a hierarchical network with FM-CP and LMs at CPA, FM-DP at DPA; FM-CP
and LMc at CPN, FM-DP at DPN.
(b)
+-----+
|LMs |
+-----+
+------------+
|CPA: |
|FM-CP, LMp |
+------------+
+------------+ +------------+
|DPA(IPa1): | |DPA(IPa2): |
|anchors IP1 | |anchors IP2 | ...
|FM-DP | |FM-DP |
+------------+ +------------+
+------------+ ------------+ +------------+
|CPN: | +------------+
|FM-CP, LMc | |CPN: |
+------------+ |FM-CP, LMc |
+------------+ +------------+ +------------+ +------------+ +------------+
|DPN(IPn11): | |DPN(IPn12): | |DPN(IPn21): | |DPN(IPn22) | . .
|FM-DP | |FM-DP | ... |FM-DP | |FM-DP | ... . .
+------------+ +------------+ +------------+ +------------+ . .
. .Distributed DPN's
+------------+ +------------+ +------------+ +------------+
|DPN(IPn11): | |DPN(IPn12): | |DPN(IPn21): | |DPN(IPn22): |
|FM-DP | |FM-DP | etc. |FM-DP | |FM-DP | etc.
+------------+ +------------+ +------------+ +------------+
+------------+ +------------+ ------------+ +------------+ +------------+ +------------+
|MN(IP1) | |MN(IP2) | +------------+Mobile node +------------+Mobile node
|flow(IP1,..)| |flow(IP2,..)| |MN(IP1) |using IP1 |MN(IP2) |using IP1
+------------+ +------------+ |flow(IP1,..)|anchored to |flow(IP2,..)|anchored to
+------------+DPA(IPa1) +------------+DPA(IPa2)
Figure 2(b). Configurations of network-based mobility management for Figure 2. Configurations of network-based mobility management for a
a hierarchical network with separate LMs, FM-CP and LMp at CPA, FM-DP hierarchical network to which MN is attached. The mobility
at DPA; FM-CP and LMc at CPN, FM-DP at DPN. management functions in the network include a separate LMs, FM-CP and
LMp at CPA, FM-DP at DPA; FM-CP and LMc at CPN, FM-DP at DPN.
In addition to the dmm feature already described in Figure 1, In addition to the dmm feature already described in Figure 1,
Figure 2 shows that there may be multiple instances of DPN, each with Figure 2 shows that there may be multiple instances of DPN, each with
an FM-DP function, for each DPA in the hierarchy. Also when the CPN, an FM-DP function, for each DPA in the hierarchy. Also when the CPN,
each with an FM-CP function, is co-located with the distributed DPN each with an FM-CP function, is co-located with the distributed DPN
there will be multiple instances of the co-located CPN and DPN (not there will be multiple instances of the co-located CPN and DPN (not
shown). shown).
In Figure 2(a), LMs is at the CPA and LMc is at the CPN. Then, LMs In Figure 2 the LMs is separated out, and a proxy LMp at the CPA is
may be distributed or centralized according to whether the CPA is added between the separate LMs and LMc at the CPN. Then, LMs may be
distributed or centralized. centralized whereas the LMp may be distributed or centralized
according to whether the CPA is distributed or centralized.
Figure 2(b) differs from Figure 2(a) in that the LMs is separated In a particular case (not shown), LMs and LMp may co-locate.
out, and a proxy LMp at the CPA is added between the seaparate LMs
and LMc at the CPN. Then, LMs may be centralized whereas the LMp may
be distributed or centralized according to whether the CPA is
distributed or centralized.
3.1.3. Host-based Mobility Support 3.1.3. Host-based Mobility Support
Host-based variants of the mobility function configurations from Host-based mobility function configurations as variants from Figures
Figures 2(a) and 2(b) are respectively shown in Figures 3(a) and 3(b) 2 is shown in Figure 3 where the role to perform mobility functions
where the role to perform mobility functions by CPN and DPN are now by CPN and DPN are now taken by the MN. The MN then needs to possess
taken by the MN. The MN then needs to possess the mobility functions the mobility functions FM and LMc.
FM and LMc.
(a) (b) +-----+
+-----+ |LMs |
|LMs | +-.---+
+-----+ +--------.---+
+------------+ +------------+ |CPA: . |
|CPA: | |CPA: | |FM-CP, LMp |
|FM-CP, LMs | |FM-CP, LMp | +------------+
+------------+ +------------+ . .
+------------+ +------------+ +------------+ +------------+ . .
|DPA(IPa1): | |DPA(IPa2): | |DPA(IPa1): | |DPA(IPa2): | . .
|anchors IP1 | |anchors IP2 | ... |anchors IP1 | |anchors IP2 | ... . .
|FM-DP | |FM-DP | |FM-DP | |FM-DP | +------------+ +------------+ Distributed
+------------+ +------------+ +------------+ +------------+ |DPA(IPa1): | |DPA(IPa2): | DPA's
|anchors IP1 | |anchors IP2 |
|FM-DP | |FM-DP | etc.
+------------+ +------------+
+------------+ +------------+ +------------+
|MN(IP1) | |MN(IP1) | |MN(IP1) |Mobile node
|flow(IP1,..)| |flow(IP1,..)| |flow(IP1,..)|using IP1
|FM, LMc | |FM, LMc | |FM, LMc |anchored to
+------------+ +------------+ +------------+DPA(IPa1)
Figure 3. Configurations of host-based mobility management (a) FM-CP Figure 3. Configuration of host-based mobility management. The
and LMs at CPA, FM-DP at DPA, FM and LMc at MN; (b) Separate LMs, FM- mobility management functions in the network include LMs in control
CP and LMp at CPA, FM-DP at DPA, FM and LMc at MN. plane, FM-CP and LMp at CPA, FM-DP at DPA. The mobility management
functions FM and LMc are also at the host (MN).
Figure 3 shows 2 configurations of host-based mobility management Figure 3 shows configurations of host-based mobility management with
with multiple instances of DPA for a distributed mobility anchoring multiple instances of DPA for a distributed mobility anchoring
environment. Figures 3(a) and 3(b) can be obtained by simply environment. Figures 3 can be obtained by simply collapsing CPN, DPN
collapsing CPN, DPN and MN from the respective Figures 2(a) and 2(b) and MN from the Figures 2 into the MN in Figure 3 which now possesses
into the MN in Figure 3 which now possesses the mobility functions FM the mobility functions FM and LMc that were performed previously by
and LMc that were performed previously by the CPN and the DPN. the CPN and the DPN.
3.1.4. NEtwork MObility (NEMO) Basic Support 3.1.4. NEtwork MObility (NEMO) Basic Support
Figure 4 shows two configurations of NEMO basic support for a mobile Figure 4 shows the configurations of NEMO basic support for a mobile
router. router.
(a) (b) +-----+
+-----+ |LMs |
|LMs | +-.---+
+-----+ +--------.---+
+------------+ +------------+ |CPA: . |
|CPA: | |CPA: | |FM-CP, LMp |
|FM-CP, LMs | |FM-CP, LMp | +------------+
+------------+ +------------+ . .
+------------+ +------------+ +------------+ +------------+ . .
|DPA(IPa1): | |DPA(IPa2): | |DPA(IPa1): | |DPA(IPa2): | . .
|anchors IP1 | |anchors IP2 | |anchors IP1 | |anchors IP2 | . .
|DHCPv6-PD | |DHCPv6-PD | ... |DHCPv6-PD | |DHCPv6-PD | ... +--------------+ +--------------+ Distributed
| IPn1| | IPn2| | IPn1| | IPn2| |DPA(IPa1): | |DPA(IPa2): | DPA's
|FM-DP | |FM-DP | |FM-DP | |FM-DP | |anchors IP1 | |anchors IP2 |
+------------+ +------------+ +------------+ +------------+ |DHCPv6-PD IPn1| |DHCPv6-PD IPn2| etc.
|FM-DP | |FM-DP |
+--------------+ +--------------+
+------------+ +------------+ +--------------+Mobile router
|MR(IP1) | |MR(IP1) | |MR(IP1) |using IP1
|anchors IPn1| |anchors IPn1| |delegated IPn1|anchored to
|FM, LMc | |FM, LMc | |FM, LMc |DPA(IPa1)
+------------+ +------------+ +--------------+
+------------+ +------------+ +------------+Mobile network node
|MNN(IPn1) | |MNN(IPn1) | |MNN(IPn1) |using IPn1
|flow(IPn1,.)| |flow(IPn1,.)| |flow(IPn1,.)|attached to MR(IP1)
+------------+ +------------+ +------------+
Figure 4. Configurations of NEMO basic support for a MR. (a) FM-CP Figure 4. Configurations of NEMO basic support for a MR which is
and LMs at CPA, FM-DP at DPA, FM and LMc at MR; (b) Separate LMs, FM- attached to a network. The mobility management functions in the
CP and LMp at CPA, FM-DP at DPA, FM and LMc at MR. network are a separate LMs, FM-CP and LMp at CPA, FM-DP at DPA. The
mobility management functions FM and LMc are also at the MR to which
MNN is attached.
Figure 4 shows 2 configurations of host-based mobility management for Figure 4 shows configurations of host-based mobility management for a
a MR with multiple instances of DPA for a distributed mobility MR with multiple instances of DPA for a distributed mobility
anchoring environment. Figures 4(a) and 4(b) can be obtained by anchoring environment. Figure 4 can be obtained by simply changing
simply changing the MN from the respective Figures 3(a) and 3(b) into the MN from the Figures 3 into the MR carrying a mobile network
the MR carrying a mobile network consisting of mobile network nodes consisting of mobile network nodes (MNNs) in Figure 4.
(MNNs) in Figure 4.
An IP prefix/address IPn1 anchored to the MR is assigned for use by An IP prefix/address IPn1 delegated to the MR is assigned for use by
the MNN in the mobile network. The MNN uses IPn1 to communicate with the MNN in the mobile network. The MNN uses IPn1 to communicate with
a correspondent node (CN) not shown in the figure. The flow of this a correspondent node (CN) not shown in the figure. The flow of this
communication session is shown as flow(IPn1, ...), meaning it uses communication session is shown as flow(IPn1, ...), meaning it uses
IPn1 and other parameters. IPn1 and other parameters.
To enable the MR to anchor and to assign the IP prefix IPn1, the DPA To enable the MR to assign the IP prefix IPn1, the DPA delegates the
delegates the prefix using DHCPv6-PD to the MR. prefix using DHCPv6-PD to the MR.
3.2. Operations and Parameters 3.2. Operations and Parameters
The operations of distributed mobility anchoring are defined in order The operations of distributed mobility anchoring are defined in order
that they might work together to produce a distributed mobility that they might work together to produce a distributed mobility
solution. The needed information is passed as mobility message solution. The needed information is passed as mobility message
parameters, which must be protected in terms of integrity. Some parameters, which must be protected in terms of integrity. Some
parameters may require a means to support privacy of an MN or MR. parameters may require a means to support privacy of an MN or MR.
The mobility needs in 5G Wireless and beyond are diverse. Therefore The mobility needs in 5G Wireless and beyond are diverse. Therefore
skipping to change at page 13, line 44 skipping to change at page 13, line 5
CPA, or may be a separate server. CPA, or may be a separate server.
LMc may be at CPA, CPN, or MN. LMc may be at CPA, CPN, or MN.
LMp may proxy between LMs and LMc. LMp may proxy between LMs and LMc.
Specifically: Specifically:
Location management operations and parameters: Location management operations and parameters:
LM-cfg:1 LMs may be co-located with LMc at CPA in a flat network LM-cfg:1 LMs and LMc may co-locate or may be separate, whereas LMc
with network-based mobility as shown in Figure 1(a) in is implemented in CPA in a flat network with network-based
Section 3.1.1. mobility as shown in Figure 1 in Section 3.1.1.
LM-cfg:2 LMs may be a separate server whereas LMc is implemented in
CPA in a flat network with network-based mobility as shown
in Figure 1(b) in Section 3.1.1.
LM-cfg:3 LMs may be implemented at CPA, whereas LMc is implemented LM-cfg:2 Either LMs may be a separate server with LMp implemented at
CPA, or LMs may be implemented at CPA. LMc is implemented
at CPN in a hierarchical network with network-based at CPN in a hierarchical network with network-based
mobility as shown in Figure 2(a) in Section 3.1.2, at MN mobility as shown in Figure 2 in Section 3.1.2, at MN for
for host-based mobility as shown in Figure 3(a) in host-based mobility as shown in Figure 3 in Section 3.1.3,
Section 3.1.3, or at MR for network mobility as shown in or at MR for network mobility as shown in Figure 4 in
Figure 4(a) in Section 3.1.4. Section 3.1.4.
LM-cfg:4 LMs may be a separate server with LMp implemented at CPA
whereas LMc is implemented at CPN in a hierarchical network
with network-based mobility as shown in Figure 2(b) in
Section 3.1.2, at MN for host-based mobility as shown in
Figure 3(b) in Section 3.1.3, or at MR for network mobility
as shown in Figure 4(b) in Section 3.1.4.
LM-db: LM may manage the location information in a client-server LM-db: LM may manage the location information in a client-server
database system. database system.
Example LM database functions are as follows: Example LM database functions are as follows:
LM-db:1 LMc may query LMs about location information for a prefix of LM-db:1 LMc may query LMs about location information for a prefix of
MN (pull). MN (pull).
Parameters: Parameters:
skipping to change at page 16, line 32 skipping to change at page 15, line 32
FM-CP may be implemented at CPA, CPN, MN depending on the FM-CP may be implemented at CPA, CPN, MN depending on the
configuration chosen. configuration chosen.
FM-DP may also be implemented at CPA, CPN, MN depending on FM-DP may also be implemented at CPA, CPN, MN depending on
the configuration chosen. the configuration chosen.
Specifically: Specifically:
FM-cfg:1 FM-CP and FM-DP may be implemented at CPA and DPA FM-cfg:1 FM-CP and FM-DP may be implemented at CPA and DPA
respectively in a flat network with network-based mobility respectively in a flat network with network-based mobility
as shown in Figure 1(a) and Figure 1(b) in Section 3.1.1. as shown in Figure 1 in Section 3.1.1.
FM-cfg:2 FM-CP may be implemented at both CPA and CPN and FM-DP is FM-cfg:2 FM-CP may be implemented at both CPA and CPN and FM-DP is
implemented at both DPA and DPN in a hierarchical network implemented at both DPA and DPN in a hierarchical network
with network-based mobility as shown in Figure 2(a) and with network-based mobility as shown in Figure 2 in
Figure 2(b) in Section 3.1.2. Section 3.1.2.
FM-cfg:3 FM-CP and FM-DP may be implemented at CPA and DPA FM-cfg:3 FM-CP and FM-DP may be implemented at CPA and DPA
respectively and also both implemented at MN for host-based respectively and also both implemented at MN for host-based
mobility as shown in Figure 3(a) and Figure 3(b) in mobility as shown in Figure 3 in Section 3.1.3.
Section 3.1.3.
FM-cfg:4 FM-CP and FM-DP may be implemented at CPA and DPA FM-cfg:4 FM-CP and FM-DP may be implemented at CPA and DPA
respectively and also both implemented at MR for network respectively and also both implemented at MR for network
mobility as shown in Figure 4(a) and Figure 4(b) in mobility as shown in Figure 4 in Section 3.1.4.
Section 3.1.4.
Forwarding management operations and parameters: Forwarding management operations and parameters:
FM-find:1 An anchor may discover and be discovered such as through FM-find:1 An anchor may discover and be discovered such as through
an anchor registration system as follows: an anchor registration system as follows:
FM-find:2 FM registers and authenticates itself with a centralized FM-find:2 FM registers and authenticates itself with a centralized
mobility controller. mobility controller.
Parameters: Parameters:
skipping to change at page 18, line 37 skipping to change at page 17, line 34
affected forwarding switches will need appropriate affected forwarding switches will need appropriate
changes to its forwarding table. changes to its forwarding table.
Specifically, such forwarding table updates may Specifically, such forwarding table updates may
include: (1) addition of forwarding table entries include: (1) addition of forwarding table entries
needed to forward the packets destined to the MN to needed to forward the packets destined to the MN to
the new AR; (2) deletion of forwarding table entries the new AR; (2) deletion of forwarding table entries
to forward the packets destined to the MN to the home to forward the packets destined to the MN to the home
network anchor or to the previous AR. network anchor or to the previous AR.
FM-path-tbl:5 Forwarding table updates may be triggered using FM-path-tbl:5 With a centralized control plane, forwarding table
DHCPv6-PD prefix delegation to change the role of IP updates may be achieved through messaging between the
anchoring from the home network anchor or previous AR centralized control plane and the distributed
(with FM-DP) to the new anchor (with FM-DP) to which forwarding switches as described above (FM-cpdp) in
the MN is currently attached. The new anchor will this section.
then advertise routes for the delegated prefix.
With a distributed routing protocol, the updates
spread out from neighbors to neighbors and will affect
all the forwarding switches such that the packets sent
from "any" node to MN will go to the new AR.
FM-path-tbl:6 Forwarding table updates may also be achieved through
BGP update as described in [I-D.templin-aerolink],
[I-D.mccann-dmm-flatarch] and also for 3GPP Evolved
Packet Core (EPC) network in
[I-D.matsushima-stateless-uplane-vepc] when the scope
and response time can be managed.
FM-path-tbl:7 Alternatively, with a centralized control plane,
forwarding table updates may be achieved through
messaging between the centralized control plane and
the distributed forwarding switches as described above
(FM-cpdp) in this section.
FM-path-tbl:8 To reduce excessive signaling, the scope of such FM-path-tbl:6 To reduce excessive signaling, the scope of such
updates for a given flow may be confined to only those updates for a given flow may be confined to only those
forwarding switches such that only the packets sent forwarding switches such that only the packets sent
from the "CN" to the MN will go to the new AR. Such from the "CN" to the MN will go to the new AR. Such
confinement may be made when using a centralized confinement may be made when using a centralized
control plane possessing a global view of all the control plane possessing a global view of all the
forwarding switches. forwarding switches.
FM-path-tbl:9 FM reverts the changes previously made to the FM-path-tbl:7 FM reverts the changes previously made to the
forwarding path of a flow when such changes are no forwarding path of a flow when such changes are no
longer needed, e.g., when all the ongoing flows using longer needed, e.g., when all the ongoing flows using
an IP prefix/address requiring IP session continuity an IP prefix/address requiring IP session continuity
have closed. When using DHCPv6-PD, the forwarding have closed.
paths will be reverted upon prefix lease expiration.
FM-path-ind:10 Indirection forwards the incoming packets of the flow FM-path-ind:8 Indirection forwards the incoming packets of the flow
from the DPA at the far end to a DPA/DPN at the near from the DPA at the far end to a DPA/DPN at the near
end of indirection. Both ends of the indirection need end of indirection. Both ends of the indirection need
to know the LM information of the MN for the flow and to know the LM information of the MN for the flow and
also need to possess FM capability to perform also need to possess FM capability to perform
indirection. indirection.
FM-path-ind:11 The mechanism of changing the forwarding path in MIPv6 FM-path-ind:9 The mechanism of changing the forwarding path in MIPv6
[RFC6275] and PMIPv6 [RFC5213] is tunneling. In the [RFC6275] and PMIPv6 [RFC5213] is tunneling. In the
control plane, the FM-CP sets up the tunnel by control plane, the FM-CP sets up the tunnel by
instructing the FM-DP at both ends of the tunnel. In instructing the FM-DP at both ends of the tunnel. In
the data plane, the FM-DP at the start of the tunnel the data plane, the FM-DP at the start of the tunnel
performs packet encapsulation, whereas the FM-DP at performs packet encapsulation, whereas the FM-DP at
the end of the tunnel decapsulates the packet. the end of the tunnel decapsulates the packet.
Note that in principle the ends of the indirection Note that in principle the ends of the indirection
path can be any pair of network elements with the FM- path can be any pair of network elements with the FM-
DP function. DP function.
FM-path-ind:12 FM reverts the changes previously made to the FM-path-ind:10 FM reverts the changes previously made to the
forwarding path of a flow when such changes are no forwarding path of a flow when such changes are no
longer needed, e.g., when all the ongoing flows using longer needed, e.g., when all the ongoing flows using
an IP prefix/address requiring IP session continuity an IP prefix/address requiring IP session continuity
have closed. When tunneling is used, the tunnels will have closed. When tunneling is used, the tunnels will
be torn down when they are no longer needed. be torn down when they are no longer needed.
FM-cpdp: With separation of control plane function and data plane FM-cpdp: With separation of control plane function and data plane
function, FM-CP and FM-DP communicate with each other. Such function, FM-CP and FM-DP communicate with each other. Such
communication may be realized by the appropriate messages in communication may be realized by the appropriate messages in
[I-D.ietf-dmm-fpc-cpdp]. [I-D.ietf-dmm-fpc-cpdp].
skipping to change at page 21, line 45 skipping to change at page 20, line 20
In particular, this DPA role may be moved upstream from the In particular, this DPA role may be moved upstream from the
home network DPA in the original forwarding path from CN to home network DPA in the original forwarding path from CN to
MN. MN.
FM-DPA:4 Optimization of the new forwarding path may be achieved FM-DPA:4 Optimization of the new forwarding path may be achieved
when the path change for the incoming packets begins at a when the path change for the incoming packets begins at a
DPA where the original path and the direct IPv6 path DPA where the original path and the direct IPv6 path
overlap. Then the new forwarding path will resemble the overlap. Then the new forwarding path will resemble the
direct IPv6 path from the CN to the MN. direct IPv6 path from the CN to the MN.
FM-DPA-tbl:5 One method to support IP mobility is through forwarding FM-DPA-ind:5 Another mobility support employs indirection from the
table changes triggered using DHCPv6-PD to change the
role of IP anchoring from the home network anchor (DPA
with FM-DP) to the new anchor (DPA with FM-DP). It
therefore puts the near end of the path change at the
new DPA. Forwarding table updates will subsequently
propagate upstream from this DPA up to a far end DPA
where the original path and the direct IPv6 path
overlap.
When that far end is too far upstream the signaling of
forwarding table updates may become excessive. An
alternative is to use indirection (see FM-DPA-ind) from
that far end to the new DPA at the near end.
Still another alternative is to combine forwarding
table update with indirection.
FM-DPA-tbl:6 Changes made by FM to the forwarding tables, which are
IPv6 nodes, at the ends of the path change for a flow
will be reverted when the mobility support for the flow
is no longer needed, e.g., when the flows have
terminated.
FM-DPA-ind:7 An alternative mobility support is indirection from the
far end DPA to the near end DPA. Both DPAs need to be far end DPA to the near end DPA. Both DPAs need to be
capable to performing indirection. For incoming capable to performing indirection. For incoming
packets from the CN to the MN, the far end DPA needs to packets from the CN to the MN, the far end DPA needs to
start the indirection towards the near end DPA, which start the indirection towards the near end DPA, which
will be the receiving end of indirection. In addition, will be the receiving end of indirection. In addition,
the near end DPA needs to continue the forwarding of the near end DPA needs to continue the forwarding of
the packet towards the MN, such as through L2 the packet towards the MN, such as through L2
forwarding or through another indirection towards the forwarding or through another indirection towards the
MN. MN.
FM-DPA-ind:8 With indirection, locating or moving the FM function to FM-DPA-ind:6 With indirection, locating or moving the FM function to
begin indirection upstream along the forwarding path begin indirection upstream along the forwarding path
from CN to MN again may help to reduce unnecessarily from CN to MN again may help to reduce unnecessarily
long paths. long paths.
FM-DPA-ind:9 Changes made by FM to establish indirection at the DPA FM-DPA-ind:7 Changes made by FM to establish indirection at the DPA
and DPN, which are IPv6 nodes, at the ends of the path and DPN, which are IPv6 nodes, at the ends of the path
change for a flow will be reverted when the mobility change for a flow will be reverted when the mobility
support for the flow is no longer needed, e.g., when support for the flow is no longer needed, e.g., when
the flows have terminated. the flows have terminated.
FM-state:1 In addition to the above, a flow/session may contain
states with the required information for QoS, charging,
etc. as needed. These states need to be transferred from
the old anchor to the new anchor.
FM-buffer: An anchor can buffer packets of a flow in a mobility FM-buffer: An anchor can buffer packets of a flow in a mobility
event: event:
FM-buffer:1 CPA/FM-CP informs DPA/FM-DP to buffer packets of a flow. FM-buffer:1 CPA/FM-CP informs DPA/FM-DP to buffer packets of a flow.
Trigger: Trigger:
- MN leaves DPA in a mobility event. - MN leaves DPA in a mobility event.
Parameters: Parameters:
skipping to change at page 23, line 33 skipping to change at page 21, line 23
- Destination IP prefix of the flow's packets: integrity - Destination IP prefix of the flow's packets: integrity
support required, support required,
- IP address of the new DPA: integrity support required. - IP address of the new DPA: integrity support required.
FM-mr:1 When the MN is a mobile router (MR) the access router FM-mr:1 When the MN is a mobile router (MR) the access router
anchoring the IP prefix of the MR will also own the IP anchoring the IP prefix of the MR will also own the IP
prefix or prefixes to be delegated to the MR. The MNNs in prefix or prefixes to be delegated to the MR. The MNNs in
the network carried by the MR obtain IP prefixes from the the network carried by the MR obtain IP prefixes from the
MR. MR.
FM-mr:2 When the MR moves from a previous AR to a new AR, the MNNs
move with the MR. Network mobility support for these MNNs
may be provided by forwarding table updates such that
packets destined to the MNNs will be forwarded towards the
new AR instead of towards the old AR.
Changes to forwarding table entries may occur at the new AR
and the aggregate router as well as other affected switches/
routers between them such that packets destined to the MNNs
will be forwarded to the new AR.
Meanwhile, changes to forwarding table entries may also
occur at the old AR and the aggregate router as well as
other affected switches/routers between them such that
packets destined to the MNNs will not be forwarded to the
old AR.
4. IP Mobility Handling in Distributed Anchoring Environments - 4. IP Mobility Handling in Distributed Anchoring Environments -
Mobility Support Only When Needed Mobility Support Only When Needed
IP mobility support may be provided only when needed instead of being IP mobility support may be provided only when needed instead of being
provided by default. The LM and FM functions in the different provided by default. The LM and FM functions in the different
configurations shown in Section 3.1 are then utilized only when configurations shown in Section 3.1 are then utilized only when
needed. needed.
A straightforward choice of mobility anchoring is for a flow to use A straightforward choice of mobility anchoring is for a flow to use
the IP prefix of the network to which the MN is attached when the the IP prefix of the network to which the MN is attached when the
skipping to change at page 26, line 35 skipping to change at page 23, line 44
IP2 address configuration | | IP2 address configuration | |
| | | | | | | |
|<-new Flow(IP2,IPcn,...)-----------+------------------------------->| |<-new Flow(IP2,IPcn,...)-----------+------------------------------->|
| | | | | | | |
Figure 6. Re-starting a flow to use the IP prefix assigned from the Figure 6. Re-starting a flow to use the IP prefix assigned from the
network at which the MN is attached. network at which the MN is attached.
4.1.1. Guidelines for IPv6 Nodes: Changing to New IP Prefix/Address 4.1.1. Guidelines for IPv6 Nodes: Changing to New IP Prefix/Address
A network or network slice may not need IP mobility support. For A network may not need IP mobility support. For example, a network
example, a network slice for stationary sensors only will never for stationary sensors only will never encounter mobility.
encounter mobility.
The standard functions in IPv6 already include dropping the old IPv6 The standard functions in IPv6 already include dropping the old IPv6
prefix/address and acquiring new IPv6 prefix/address when the node prefix/address and acquiring new IPv6 prefix/address when the node
changes its point of attachment to a new network. Therefore, a changes its point of attachment to a new network. Therefore, a
network or network slice not providing IP mobility support at all network not providing IP mobility support at all will not need any of
will not need any of the functions with the mobility operations and the functions with the mobility operations and messages described in
messages described in Section 3.2. Section 3.2.
On the other hand, a network or network slice supporting a mix of On the other hand, a network supporting a mix of flows both requiring
flows both requiring and not requiring IP mobility support will need and not requiring IP mobility support will need the mobility
the mobility functions, which it will invoke or not invoke as needed. functions, which it will invoke or not invoke as needed.
The guidelines for the IPv6 nodes in a network or network slice The guidelines for the IPv6 nodes in a network supporting a mix of
supporting a mix of flows both requiring and not requiring IP flows both requiring and not requiring IP mobility support include
mobility support include the following: the following:
GL-cfg:1 A network or network slice supporting a mix of flows both GL-cfg:1 A network supporting a mix of flows both requiring and not
requiring and not requiring mobility support may take any requiring mobility support may take any of the
of the configurations described in Section 3.1 and need to configurations described in Section 3.1 and need to
implement at the appropriate IPv6 nodes the mobility implement at the appropriate IPv6 nodes the mobility
functions LM and FM as described respectively in LM-cfg and functions LM and FM as described respectively in LM-cfg and
FM-cfg in Section 3.2 according to the configuration FM-cfg in Section 3.2 according to the configuration
chosen. chosen.
GL-mix:1 These mobility functions perform some of the operations GL-mix:1 These mobility functions perform some of the operations
with the appropriate messages as described in Section 3.2 with the appropriate messages as described in Section 3.2
depending on which mobility mechanisms are being used. Yet depending on which mobility mechanisms are being used. Yet
these mobility functions must not be invoked for a flow these mobility functions must not be invoked for a flow
that does not need IP mobility support so that it is that does not need IP mobility support so that it is
skipping to change at page 29, line 40 skipping to change at page 26, line 40
| | | | | | | |
|<-new Flow(IP2,IPcn,...)-----------+------------------------------->| |<-new Flow(IP2,IPcn,...)-----------+------------------------------->|
| | | | | | | |
Figure 7. A flow continues to use the IP prefix from its home Figure 7. A flow continues to use the IP prefix from its home
network after MN has moved to a new network. network after MN has moved to a new network.
4.2.1. Guidelines for IPv6 Nodes: Need of IP Mobility 4.2.1. Guidelines for IPv6 Nodes: Need of IP Mobility
The configuration guidelines of distributed mobility for the IPv6 The configuration guidelines of distributed mobility for the IPv6
nodes in a network or network slice supporting a mix of flows both nodes in a network supporting a mix of flows both requiring and not
requiring and not requiring distributed mobility support are as requiring distributed mobility support are as follows:
follows:
GL-cfg:2 Multiple instances of DPAs (at access routers) which are GL-cfg:2 Multiple instances of DPAs (at access routers) which are
providing IP prefix to the MNs are needed to provide providing IP prefix to the MNs are needed to provide
distributed mobility anchoring in an appropriate distributed mobility anchoring in an appropriate
configuration such as those described in Figure 1 configuration such as those described in Figure 1
(Section 3.1.1) for network-based distributed mobility or (Section 3.1.1) for network-based distributed mobility or
in Figure 3 (Section 3.1.3) for host-based distributed in Figure 3 (Section 3.1.3) for host-based distributed
mobility. mobility.
The appropriate IPv6 nodes (CPA, DPA, CPN, DPN) have to The appropriate IPv6 nodes (CPA, DPA, CPN, DPN) have to
implement the mobility functions LM and FM as described implement the mobility functions LM and FM as described
respectively in LM-cfg and FM-cfg in Section 3.2 according respectively in LM-cfg and FM-cfg in Section 3.2 according
to the configuration chosen. to the configuration chosen.
The guidelines of distributed mobility for the IPv6 nodes in a The guidelines of distributed mobility for the IPv6 nodes in a
network or network slice supporting a mix of flows both requiring and network supporting a mix of flows both requiring and not requiring
not requiring distributed mobility support had begun with those given distributed mobility support had begun with those given as GL-mix in
as GL-mix in Section 4.1.1 and continue as follows: Section 4.1.1 and continue as follows:
GL-mix:5 The distributed anchors may need to message with each GL-mix:5 The distributed anchors may need to message with each
other. When such messaging is needed, the anchors may need other. When such messaging is needed, the anchors may need
to discover each other as described in the FM operations to discover each other as described in the FM operations
and mobility message parameters (FM-find) in Section 3.2.2. and mobility message parameters (FM-find) in Section 3.2.2.
GL-mix:6 The anchors may need to provide mobility support on a per- GL-mix:6 The anchors may need to provide mobility support on a per-
flow basis as described in the FM operations and mobility flow basis as described in the FM operations and mobility
message parameters (FM-flow) in Section 3.2.2. message parameters (FM-flow) in Section 3.2.2.
GL-mix:7 Then the anchors need to properly forward the packets of GL-mix:7 Then the anchors need to properly forward the packets of
the flows in the appropriate FM operations and mobility the flows in the appropriate FM operations and mobility
message parameters depending on the specific mobility message parameters depending on the specific mobility
mechanism as described in Section 3.2.2. mechanism as described in Section 3.2.2.
GL-mix:8 When using a mechanism of changing forwarding table GL-mix:8 When using a mechanism of changing forwarding table
entries, the FM operations and mobility message parameters entries, the FM operations and mobility message parameters
are described in FM-path, FM-path-tbl, FM-DPA, and FM-DPA- are described in FM-path, FM-path-tbl, and FM-DPA in
tbl in Section 3.2.2. Section 3.2.2.
The forwarding table updates will take place at AR1, AR2, The forwarding table updates will take place at AR1, AR2,
the far end DPA, and other affected switches/routers such the far end DPA, and other affected switches/routers such
that the packet from the CN to the MN will traverse from that the packet from the CN to the MN will traverse from
the far end DPA towards AR2 instead of towards AR1. the far end DPA towards AR2 instead of towards AR1.
Therefore new entries to the forwarding table will be added Therefore new entries to the forwarding table will be added
at AR2 and the far end DPA as well as other affected at AR2 and the far end DPA as well as other affected
switches/routers between them so that these packets will switches/routers between them so that these packets will
traverse towards AR2. Meanwhile, changes to the forwarding traverse towards AR2. Meanwhile, changes to the forwarding
skipping to change at page 31, line 29 skipping to change at page 28, line 29
management mechanism may employ indirection from the anchor in the management mechanism may employ indirection from the anchor in the
home network to the current network of attachment. Yet it may be home network to the current network of attachment. Yet it may be
difficult to avoid unnecessarily long route when the route between difficult to avoid unnecessarily long route when the route between
the MN and the CN via the anchor in the home network is significantly the MN and the CN via the anchor in the home network is significantly
longer than the direct route between them. An alternative is to longer than the direct route between them. An alternative is to
switch the IP prefix/address anchoring to the new network. switch the IP prefix/address anchoring to the new network.
5.1. IP Prefix/Address Anchor Switching for Flat Network 5.1. IP Prefix/Address Anchor Switching for Flat Network
The IP prefix/address anchoring may move without changing the IP The IP prefix/address anchoring may move without changing the IP
prefix/address of the flow. Here the LM and FM functions in Figures prefix/address of the flow. Here the LM and FM functions in Figure 1
1(a) and 1(b) in Section 3.1 are implemented as shown in Figure 8. in Section 3.1 are implemented as shown in Figure 8.
Net1 Net2 Net1 Net2
+---------------+ +---------------+ +---------------+ +---------------+
|AR1 | |AR2 | |AR1 | |AR2 |
+---------------+ +---------------+ +---------------+ +---------------+
|CPA: | |CPA: | |CPA: | |CPA: |
|LM:IP1 at IPa1 | |LM:IP1 at IPa2 | |LM:IP1 at IPa1 | |LM:IP1 at IPa2 |
| changes to | | | | changes to | | |
| IP1 at IPa2 | | | | IP1 at IPa2 | | |
|---------------| |---------------| |---------------| |---------------|
|DPA(IPa1): | anchoring of IP1 is moved |DPA(IPa2): | |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): |
|anchored IP1 | =======> |anchors IP2,IP1| |anchored IP1 | =======> |anchors IP2,IP1|
|FM:DHCPv6-PD | |FM:DHCPv6-PD |
+---------------+ +---------------+ +---------------+ +---------------+
+...............+ +---------------+ +...............+ +---------------+
.MN(IP1) . MN moves |MN(IP2,IP1) | .MN(IP1) . MN moves |MN(IP2,IP1) |
.flow(IP1,...) . =======> |flow(IP1,...) | .flow(IP1,...) . =======> |flow(IP1,...) |
+...............+ +---------------+ +...............+ +---------------+
Figure 8. IP prefix/address anchor switching to the new network. MN Figure 8. IP prefix/address anchor switching to the new network. MN
with flow using IP1 in Net1 continues to run the flow using IP1 as it with flow using IP1 in Net1 continues to run the flow using IP1 as it
moves to Net2. moves to Net2.
As an MN with an ongoing session moves to a new network, the flow may As an MN with an ongoing session moves to a new network, the flow may
preserve IP session continuity by moving the anchoring of the preserve IP session continuity by moving the anchoring of the
original IP prefix/address of the flow to the new network. BGP original IP prefix/address of the flow to the new network. One way
UPDATE messages may be used to change the forwarding table entries as to accomplish such move is to use a centralized routing protocol to
described in [I-D.templin-aerolink] and [I-D.mccann-dmm-flatarch] if be described in Section 5.2 with a centralized control plane.
the response time of such updates does not exceed the handover delay
requirement of the flow. An alternative is to use a centralized
routing protocol to be described in Section 5.2 with a centralized
control plane.
5.1.1. Guidelines for IPv6 Nodes: Switching Anchor for Flat Network 5.1.1. Guidelines for IPv6 Nodes: Switching Anchor for Flat Network
The configuration guideline for a flat network or network slice The configuration guideline for a flat network supporting a mix of
supporting a mix of flows both requiring and not requiring IP flows both requiring and not requiring IP mobility support is:
mobility support is:
GL-cfg:3 Multiple instances of DPAs (at access routers) which are GL-cfg:3 Multiple instances of DPAs (at access routers) which are
providing IP prefix to the MNs are needed to provide providing IP prefix to the MNs are needed to provide
distributed mobility anchoring according to Figure 1(a) or distributed mobility anchoring according to Figure 1 in
Figure 1(b) in Section 3.1 for a flat network. Section 3.1 for a flat network.
The appropriate IPv6 nodes (CPA, DPA) have to implement the The appropriate IPv6 nodes (CPA, DPA) have to implement the
mobility functions LM and FM as described respectively in mobility functions LM and FM as described respectively in
LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2. LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2.
The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the
IPv6 nodes for a network or network slice supporting a mix of flows IPv6 nodes for a network supporting a mix of flows both requiring and
both requiring and not requiring IP mobility support apply here. In not requiring IP mobility support apply here. In addition, the
addition, the following are required. following are required.
GL-switch:1 The location management provides information about which GL-switch:1 The location management provides information about which
IP prefix from an AR in the original network is being IP prefix from an AR in the original network is being
used by a flow in which AR in a new network. Such used by a flow in which AR in a new network. Such
information needs to be deleted or updated when such information needs to be deleted or updated when such
flows have closed so that the IP prefix is no longer flows have closed so that the IP prefix is no longer
used in a different network. The LM operations are used in a different network. The LM operations are
described in Section 3.2.1. described in Section 3.2.1.
GL-switch:2 The FM functions are implemented through the DHCPv6-PD GL-switch:2 The anchor operations to properly forward the packets
protocol. Here the anchor operations to properly for a flow are described in the FM operations and
forward the packets for a flow as described in the FM mobility message parameters in FM-path, FM-path-tbl, FM-
operations and mobility message parameters in FM-path, cpdp, and FM-DPA in Section 3.2.2. If there are in-
FM-path-tbl, FM-DPA, and FM-DPA-tbl in Section 3.2.2 are flight packets toward the old anchor while the MN is
realized by changing the anchor with DHCPv6-PD and also moving to the new anchor, it may be necessary to buffer
by reverting such changes later after the application these packets and then forward to the new anchor after
has already closed and when the DHCPv6-PD timer expires. the old anchor knows that the new anchor is ready as are
If there are in-flight packets toward the old anchor described in FM-buffer in Section 3.2.2. The anchors
while the MN is moving to the new anchor, it may be may also need to discover each other as described also
necessary to buffer these packets and then forward to in the FM operations and mobility message parameters
the new anchor after the old anchor knows that the new (FM-find).
anchor is ready as are described in FM-buffer in
Section 3.2.2. The anchors may also need to discover
each other as described also in the FM operations and
mobility message parameters (FM-find).
GL-switch:3 The security management function in the anchor node at a GL-switch:3 The security policy must allow to assign to the anchor
new network must allow to assign the original IP prefix/ node at the new network the original IP prefix/address
address used by the mobile node at the previous used by the mobile node at the previous (original)
(original) network. As the assigned original IP prefix/ network. As the assigned original IP prefix/address is
address is to be used in the new network, the security to be used in the new network, the security policy must
management function in the anchor node must allow to allow the anchor node in the new network to advertise
advertise the prefix of the original IP address and also the prefix of the original IP address and also allow the
allow the mobile node to send and receive data packets mobile node to send and receive data packets with the
with the original IP address. original IP address.
GL-switch:4 The security management function in the mobile node must GL-switch:4 The security policy must allow the mobile node to
allow to configure the original IP prefix/address used configure the original IP prefix/address used at the
at the previous (original) network when the original IP previous (original) network when the original IP prefix/
prefix/address is assigned by the anchor node in the new address is assigned by the anchor node in the new
network. The security management function in the mobile network. It must also allow the mobile node to use the
node also allows to use the original IP address for the original IP address for the previous flow in the new
previous flow in the new network. network.
5.2. IP Prefix/Address Anchor Switching for Flat Network with 5.2. IP Prefix/Address Anchor Switching for Flat Network with
Centralized Control Plane Centralized Control Plane
An example of IP prefix anchor switching is in the case where Net1 An example of IP prefix anchor switching is in the case where Net1
and Net2 both belong to the same operator network with separation of and Net2 both belong to the same operator network with separation of
control and data planes ([I-D.liu-dmm-deployment-scenario] and control and data planes ([I-D.liu-dmm-deployment-scenario] and
[I-D.matsushima-stateless-uplane-vepc]), where the controller may [I-D.matsushima-stateless-uplane-vepc]), where the controller may
send to the switches/routers the updated information of the send to the switches/routers the updated information of the
forwarding tables with the IP address anchoring of the original IP forwarding tables with the IP address anchoring of the original IP
prefix/address at AR1 moved to AR2 in the new network. That is, the prefix/address at AR1 moved to AR2 in the new network. That is, the
IP address anchoring in the original network which was advertising IP address anchoring in the original network which was advertising
the prefix will need to move to the new network. As the anchoring in the prefix will need to move to the new network. As the anchoring in
the new network advertises the prefix of the original IP address in the new network advertises the prefix of the original IP address in
the new network, the forwarding tables will be updated so that the new network, the forwarding tables will be updated so that
packets of the flow will be forwarded according to the updated packets of the flow will be forwarded according to the updated
forwarding tables. forwarding tables.
The configurations in Figures 1(a) and 1(b) in Section 3.1 for which The configurations in Figure 1 in Section 3.1 for which the FM-CP and
the FM-CP and the LM are centralized and the FM-DPs are distributed the LM are centralized and the FM-DPs are distributed apply here.
apply here. Figure 9 shows its implementation where the LM is a Figure 9 shows its implementation where the LM is a binding between
binding between the original IP prefix/address of the flow and the IP the original IP prefix/address of the flow and the IP address of the
address of the new DPA, whereas the FM uses the DHCPv6-PD protocol. new DPA, whereas the FM uses appropriate control plane to data plane
messages.
Net1 Net2 Net1 Net2
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| CPA: | | CPA: |
| LM:IP1 at IPa2 | | LM:IP1 at IPa2 |
| FM-CP | | FM-CP |
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
+---------------+ +---------------+ +---------------+ +---------------+
|AR1 | |AR2 | |AR1 | |AR2 |
+---------------+ +---------------+ +---------------+ +---------------+
|DPA(IPa1): | anchoring of IP1 is moved |DPA(IPa2): | |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): |
|anchored IP1 | =======> |anchors IP2,IP1| |anchored IP1 | =======> |anchors IP2,IP1|
|FM:DHCPv6-PD | |FM:DHCPv6-PD |
+---------------+ +---------------+ +---------------+ +---------------+
+...............+ +---------------+ +...............+ +---------------+
.MN(IP1) . MN moves |MN(IP2,IP1) | .MN(IP1) . MN moves |MN(IP2,IP1) |
.flow(IP1,...) . =======> |flow(IP1,...) | .flow(IP1,...) . =======> |flow(IP1,...) |
+...............+ +---------------+ +...............+ +---------------+
Figure 9. IP prefix/address anchor switching to the new network with Figure 9. IP prefix/address anchor switching to the new network with
the LM and the FM-CP in a centralized control plane whereas the FM- the LM and the FM-CP in a centralized control plane whereas the FM-
DPs are distributed. DPs are distributed.
The example call flow in Figure 10 shows that IP1 is assigned to MN The example call flow in Figure 10 shows that IP1 is assigned to MN
when the MN attaches to the AR1 A flow running in MN and needing IP when the MN attaches to the AR1 A flow running in MN and needing IP
mobility may continue to use the previous IP prefix by moving the mobility may continue to use the previous IP prefix by moving the
anchoring of the IP prefix to the new network. Yet a new flow to be anchoring of the IP prefix to the new network. Yet a new flow to be
initiated in the new network may simply use a new IP prefix assigned initiated in the new network may simply use a new IP prefix assigned
from the new network. from the new network.
MN AR1 AR2 DHCPv6 Servers CN MN AR1 AR2 CPA CN
|MN attaches to AR1: | | | | |MN attaches to AR1: | | | |
|acquire MN-ID and profile | | | |acquire MN-ID and profile | | |
|--RS---------------->| | | | |--RS---------------->| | | |
|<----------RA(IP1)---| | | | |<----------RA(IP1)---| | | |
| | | Assign MN:IP1 | | | | Assign MN:IP1 |
IP addr config | | | | IP addr config | | | |
| | | | | | | | | |
|<-Flow(IP1,IPcn,...)-+--------------------------------------------->| |<-Flow(IP1,IPcn,...)-+--------------------------------------------->|
| | | | | | | | | |
|MN detach from AR1 | | | | |MN detach from AR1 | | | |
|MN attach to AR2 | | | | |MN attach to AR2 | | | |
| | | | | | | | | |
|--RS------------------------------>| | | |--RS------------------------------>| | |
| | | | | | | | | |
| |------DHCPv6 release-------------->| | | |<---------------control messages-->| |
| | | | | | | | | |
| | |--DHCPv6 PD request->| | | | |<-control messages-->| |
| | |<-DHCPv6 PD reply--->| |
| | | | | | | | | |
| forwarding table updates | | | forwarding table updates <--------------| |
| | | | | | | | | |
|<--------------RA(IP2,IP1)---------| | | |<--------------RA(IP2,IP1)---------| | |
| | | Assign MN:IP2 | | | | Assign MN:IP2 |
IP addr config | | | | IP addr config | | | |
| | | | | | | | | |
|<-Flow(IP1,IPcn,...)---------------+------------------------------->| |<-Flow(IP1,IPcn,...)---------------+------------------------------->|
| | | | | | | | | |
| Flow(IP1,IPcn,...) terminates | | | | Flow(IP1,IPcn,...) terminates | | |
| | | | | | | | | |
| | DHCPv6-PD timeout | | | forwarding table updates <--------------| |
| | | | |
| forwarding table updates | |
| | | | |
| | | | | | | | | |
|<-new Flow(IP2,IPcn,...)-----------+------------------------------->| |<-new Flow(IP2,IPcn,...)-----------+------------------------------->|
| | | | | | | | | |
Figure 10. DMM solution. MN with flow using IP1 in Net1 continues Figure 10. DMM solution. MN with flow using IP1 in Net1 continues
to run the flow using IP1 as it moves to Net2. to run the flow using IP1 as it moves to Net2.
As the MN moves from AR1 to AR2, the AR1 as a DHCPv6 client may send As the MN moves from AR1 to AR2, the AR1 may exchange messages with
a DHCPv6 release message to release the IP1. It is now necessary for CPA to release the IP1. It is now necessary for AR2 to learn the IP
AR2 to learn the IP prefix of the MN from the previous network so prefix of the MN from the previous network so that it will be
that it will be possible for Net2 to assign both the previous network possible for Net2 to assign both the previous network prefix and the
prefix and the new network prefix. The network may learn the new network prefix. The network may learn the previous prefix in
previous prefix in different methods. For example, the MN may different methods. For example, the MN may provide its previous
provide its previous network prefix information by including it to network prefix information by including it to the RS message
the RS message [I-D.jhlee-dmm-dnpp]. [I-D.jhlee-dmm-dnpp].
Knowing that MN is using IP1, the AR2 sends to a DHCPv6 server a Then forwarding tables updates will take place here.
DHCPv6-PD request to move the IP1 to AR2. The server sends to AR2 a
DHCPv6-PD reply to move the IP1. Then forwarding tables updates will
take place here.
In addition, the MN also needs a new IP in the new network. The AR2 In addition, the MN also needs a new IP in the new network. The AR2
may now send RA to the MN with prefix information that includes IP1 may now send RA to the MN with prefix information that includes IP1
and IP2. The MN may then continue to use IP1. In addition, the and IP2. The MN may then continue to use IP1. In addition, the
prefix IP2 is assigned to the MN which may configure the IP addresses prefix IP2 is assigned to the MN which may configure the IP addresses
of its interface. Now for flows using IP1, packets destined to IP1 of its interface. Now for flows using IP1, packets destined to IP1
will be forwarded to the MN via AR2. will be forwarded to the MN via AR2.
As such flows have terminated and DHCPv6-PD has timed out, IP1 goes As such flows have terminated, IP1 goes back to Net1. MN will then
back to Net1. MN will then be left with IP2 only, which it will use be left with IP2 only, which it will use when it now starts a new
when it now starts a new flow. flow.
5.2.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with 5.2.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with
Centralized CP Centralized CP
The configuration guideline for a flat network or network slice with The configuration guideline for a flat network with centralized
centralized control plane and supporting a mix of flows both control plane and supporting a mix of flows both requiring and not
requiring and not requiring IP mobility support is: requiring IP mobility support is:
GL-cfg:4 Multiple instances of DPAs (at access routers) which are GL-cfg:4 Multiple instances of DPAs (at access routers) which are
providing IP prefix to the MNs are needed to provide providing IP prefix to the MNs are needed to provide
distributed mobility anchoring according to Figure 1(a) or distributed mobility anchoring according to Figure 1 in
Figure 1(b) in Section 3.1 with centralized control plane Section 3.1 with centralized control plane for a flat
for a flat network. network.
At the appropriate IPv6 nodes (CPA, DPA) have to implement At the appropriate IPv6 nodes (CPA, DPA) have to implement
the mobility functions LM and FM as described respectively the mobility functions LM and FM as described respectively
in LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2. in LM-cfg:1 or LM-cfg:2 and FM-cfg:1 in Section 3.2.
The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the The guidelines (GL-mix) in Section 4.1.1 and in Section 4.2.1 for the
IPv6 nodes for a network or network slice supporting a mix of flows IPv6 nodes for a network supporting a mix of flows both requiring and
both requiring and not requiring IP mobility support apply here. The not requiring IP mobility support apply here. The guidelines (GL-
guidelines (GL-mix) in Section 5.1.1 for moving anchoring for a flat mix) in Section 5.1.1 for moving anchoring for a flat network also
network also apply here. In addition, the following are required. apply here. In addition, the following are required.
GL-switch:5 It was already mentioned that the anchor operations to GL-switch:5 It was already mentioned that the anchor operations to
properly forward the packets for a flow as described in properly forward the packets for a flow are described in
the FM operations and mobility message parameters in FM- the FM operations and mobility message parameters in FM-
path, FM-path-tbl, FM-DPA, and FM-DPA-tbl in path, FM-path-tbl, FM-cpdp, and FM-DPA in Section 3.2.2
Section 3.2.2 is realized by changing the anchoring with and such changes are reverted later when the application
DHCPv6-PD and undoing such changes later when its timer has already closed. Here however, with separation of
expires and the application has already closed. Here control and data planes for the anchors and where the
however, with separation of control and data planes for LMs and the FM-CP are centralized in the same control
the anchors and where the LMs and the FM-CP are plane, messaging between anchors and the discovery of
centralized in the same control plane, messaging between anchors become internal to the control plane.
anchors and the discovery of anchors become internal to
the control plane.
GL-switch:6 The centralized FM-CP needs to communicate with the GL-switch:6 The centralized FM-CP needs to communicate with the
distributed FM-DP using the FM operations and mobility distributed FM-DP using the FM operations and mobility
message parameters as described in FM-cpdp in message parameters as described in FM-cpdp in
Section 3.2.2. Such may be realized by the appropriate Section 3.2.2. Such may be realized by the appropriate
messages in [I-D.ietf-dmm-fpc-cpdp]. messages in [I-D.ietf-dmm-fpc-cpdp].
GL-switch:7 It was also already mentioned before that, if there are GL-switch:7 It was also already mentioned before that, if there are
in-flight packets toward the previous anchor while the in-flight packets toward the previous anchor while the
MN is moving to the new anchor, it may be necessary to MN is moving to the new anchor, it may be necessary to
skipping to change at page 37, line 40 skipping to change at page 34, line 24
mobility message parameters as described in mobility message parameters as described in
Section 3.2.2 (FM-buffer) can be realized by the Section 3.2.2 (FM-buffer) can be realized by the
internal operations in the control plane together with internal operations in the control plane together with
signaling between the control plane and distributed data signaling between the control plane and distributed data
plane. These signaling may be realized by the plane. These signaling may be realized by the
appropriate messages in [I-D.ietf-dmm-fpc-cpdp]. appropriate messages in [I-D.ietf-dmm-fpc-cpdp].
5.3. Hierarchical Network 5.3. Hierarchical Network
The configuration for a hierarchical network has been shown in The configuration for a hierarchical network has been shown in
Figures 2(a) and 2(b) in Section 3.1.2. With centralized control Figure 2 in Section 3.1.2. With centralized control plane, CPA and
plane, CPA and CPN, with the associated LM and FM-CP are all co- CPN, with the associated LM and FM-CP are all co-located. There are
located. There are multiple DPAs (each with FM-DP) in distributed multiple DPAs (each with FM-DP) in distributed mobility anchoring.
mobility anchoring. In the data plane, there are multiple DPNs (each In the data plane, there are multiple DPNs (each with FM-DP)
with FM-DP) hierarchically below each DPA. The DPA at each AR hierarchically below each DPA. The DPA at each AR supports
supports forwarding to the DPN at each of a number of forwarding forwarding to the DPN at each of a number of forwarding switches
switches (FWs). A mobility event in this configuration belonging to (FWs). A mobility event in this configuration belonging to
distributed mobility management will be deferred to Section 5.4. distributed mobility management will be deferred to Section 5.4.
In this distributed mobility configuration, a mobility event In this distributed mobility configuration, a mobility event
involving change of FW only but not of AR as shown in Figure 11 may involving change of FW only but not of AR as shown in Figure 11 may
still belong to centralized mobility management and may be supported still belong to centralized mobility management and may be supported
using PMIPv6. This configuration of network-based mobility is also using PMIPv6. This configuration of network-based mobility is also
applicable to host-based mobility with the modification for the MN applicable to host-based mobility with the modification for the MN
directly taking the role of DPN and CPN, and the corresponding directly taking the role of DPN and CPN, and the corresponding
centralized mobility event may be supported using MIPv6. centralized mobility event may be supported using MIPv6.
skipping to change at page 39, line 8 skipping to change at page 35, line 41
+...............+ +---------------+ +...............+ +---------------+
Figure 11. Mobility without involving change of IP anchoring in a Figure 11. Mobility without involving change of IP anchoring in a
network in which the IP prefix assigned to the MN is anchored at an network in which the IP prefix assigned to the MN is anchored at an
AR which is hierarchically above multiple FWs to which the MN may AR which is hierarchically above multiple FWs to which the MN may
connect. connect.
5.3.1. Additional Guidelines for IPv6 Nodes: Hierarchical Network with 5.3.1. Additional Guidelines for IPv6 Nodes: Hierarchical Network with
No Anchor Relocation No Anchor Relocation
The configuration guideline for a hierarchical network or network The configuration guideline for a hierarchical network with
slice with centralized control plane and supporting a mix of flows centralized control plane and supporting a mix of flows both
both requiring and not requiring IP mobility support is: requiring and not requiring IP mobility support is:
GL-cfg:5 Multiple instances of DPAs (at access routers) which are GL-cfg:5 Multiple instances of DPAs (at access routers) which are
providing IP prefix to the MNs are needed to provide providing IP prefix to the MNs are needed to provide
distributed mobility anchoring according to Figure 2(a) or distributed mobility anchoring according to Figure 2 in
Figure 2(b)in Section 3.1.2 with centralized control plane Section 3.1.2 with centralized control plane for a
for a hierarchical network. hierarchical network.
The appropriate IPv6 nodes (CPA, DPA) have to implement the The appropriate IPv6 nodes (CPA, DPA) have to implement the
mobility functions LM and FM as described respectively in mobility functions LM and FM as described respectively in
LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2. LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2.
Even when the mobility event does not involve change of anchor, it is Even when the mobility event does not involve change of anchor, it is
still necessary to distinguish whether a flow needs IP mobility still necessary to distinguish whether a flow needs IP mobility
support. support.
The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the
IPv6 nodes for a network or network slice supporting a mix of flows IPv6 nodes for a network supporting a mix of flows both requiring and
both requiring and not requiring IP mobility support apply here. In not requiring IP mobility support apply here. In addition, the
addition, the following are required. following are required.
GL-switch:8 Here, the LM operations and mobility message parameters GL-switch:8 Here, the LM operations and mobility message parameters
described in Section 3.2.1 provide information of which described in Section 3.2.1 provide information of which
IP prefix from its FW needs to be used by a flow using IP prefix from its FW needs to be used by a flow using
which new FW. The anchor operations to properly forward which new FW. The anchor operations to properly forward
the packets of a flow described in the FM operations and the packets of a flow described in the FM operations and
mobility message parameters (FM-path, FM-path-ind, FM- mobility message parameters (FM-path, FM-path-ind, FM-
cpdp in Section 3.2.2) may be realized with PMIPv6 cpdp in Section 3.2.2) may be realized with PMIPv6
protocol [I-D.korhonen-dmm-local-prefix] or with AERO protocol [I-D.korhonen-dmm-local-prefix] or with AERO
protocol [I-D.templin-aerolink] to tunnel between the AR protocol [I-D.templin-aerolink] to tunnel between the AR
and the FW. and the FW.
5.4. IP Prefix/Address Anchor Switching for a Hierarchical Network 5.4. IP Prefix/Address Anchor Switching for a Hierarchical Network
The configuration for the hierarchical network has been shown in The configuration for the hierarchical network has been shown in
Figures 2(a) and 2(b) in Section 3.1.2. Again, with centralized Figure 2 in Section 3.1.2. Again, with centralized control plane,
control plane, CPA and CPN, with the associated LM and FM-CP are all CPA and CPN, with the associated LM and FM-CP are all co-located.
co-located. There are multiple DPAs (each with FM-DP) in distributed There are multiple DPAs (each with FM-DP) in distributed mobility
mobility anchoring. In the data plane, there are multiple DPNs (each anchoring. In the data plane, there are multiple DPNs (each with FM-
with FM-DP) hierarchically below each DPA. The DPA at each AR DP) hierarchically below each DPA. The DPA at each AR supports
supports forwarding to the DPN at each of a number of forwarding forwarding to the DPN at each of a number of forwarding switches
switches (FWs). (FWs).
A distributed mobility event in this configuration involves change A distributed mobility event in this configuration involves change
from a previous DPN which is hierarchically under the previous DPA to from a previous DPN which is hierarchically under the previous DPA to
a new DPN which is hierarchically under a new DPA. Such an event a new DPN which is hierarchically under a new DPA. Such an event
involving change of both DPA and DPN is shown in Figure 12. involving change of both DPA and DPN is shown in Figure 12.
Net1 Net2 Net1 Net2
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| CPA,CPN,Aggregate Router: LM:IP1 at IPn2 at IPa2 | | CPA,CPN,Aggregate Router: LM:IP1 at IPn2 at IPa2 |
| FM-CP | | FM-CP |
skipping to change at page 40, line 25 skipping to change at page 37, line 20
+-----------------+ +-----------------+
|Aggregate Router | |Aggregate Router |
+-----------------+ +-----------------+
|FM-DP | |FM-DP |
+-----------------+ +-----------------+
+---------------+ +---------------+ +---------------+ +---------------+
|AR1 | |AR2 | |AR1 | |AR2 |
+---------------+ +---------------+ +---------------+ +---------------+
|DPA(IPa1): | anchoring of IP1 is moved |DPA(IPa2): | |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): |
|anchored IP1 | =======> |anchors IP2,IP1| |anchored IP1 | =======> |anchors IP2,IP1|
|FM:DHCPv6-PD | |FM:DHCPv6-PD |
+---------------+ +---------------+ +---------------+ +---------------+
+---------------+ +---------------+ +---------------+ +---------------+
|FW1 | |FW2 | |FW1 | |FW2 |
+---------------+ FW is changed +---------------+ +---------------+ FW is changed +---------------+
|DPN(IPn1): | -------> |DPN(IPn2): | |DPN(IPn1): | -------> |DPN(IPn2): |
|FM-DP | |FM-DP | |FM-DP | |FM-DP |
+---------------+ +---------------+ +---------------+ +---------------+
+...............+ +---------------+ +...............+ +---------------+
skipping to change at page 41, line 5 skipping to change at page 37, line 47
with hierarchy in which the IP prefix assigned to the MN is anchored with hierarchy in which the IP prefix assigned to the MN is anchored
at an Edge Router supporting multiple access routers to which the MN at an Edge Router supporting multiple access routers to which the MN
may connect. may connect.
This deployment case involves both a change of anchor from AR1 to AR2 This deployment case involves both a change of anchor from AR1 to AR2
and a network hierarchy AR-FW. It can be realized by a combination and a network hierarchy AR-FW. It can be realized by a combination
of relocating the IP prefix/address anchoring from AR1 to AR2 with of relocating the IP prefix/address anchoring from AR1 to AR2 with
the mechanism as described in Section 5.2 and then forwarding the the mechanism as described in Section 5.2 and then forwarding the
packets with network hierarchy AR-FW as described in Section 5.3. packets with network hierarchy AR-FW as described in Section 5.3.
To change the anchoring of IP1, AR1 acting as a DHCPv6-PD client may
exchange message with the DHCPv6 server to release the prefix IP1.
Meanwhile, AR2 acting as a DHCPv6-PD client may exchange message with
the DHCPv6 server to delegate the prefix IP1 to AR2.
5.4.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with 5.4.1. Additional Guidelines for IPv6 Nodes: Switching Anchor with
Hierarchical Network Hierarchical Network
The configuration guideline (GL-cfg) for a hierarchical network or The configuration guideline (GL-cfg) for a hierarchical network with
network slice with centralized control plane described in centralized control plane described in Section 5.3.1 applies here.
Section 5.3.1 applies here.
The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the
IPv6 nodes for a network or network slice supporting a mix of flows IPv6 nodes for a network supporting a mix of flows both requiring and
both requiring and not requiring IP mobility support apply here. not requiring IP mobility support apply here.
The guidelines (GL-switch) in Section 5.1.1 for anchoring relocation The guidelines (GL-switch) in Section 5.1.1 for anchoring relocation
and in Section 5.2.1 for a centralized control plane also apply here. and in Section 5.2.1 for a centralized control plane also apply here.
In addition, the guidelines for indirection between the new DPA and In addition, the guidelines for indirection between the new DPA and
the new DPN as described in Section 5.3.1 apply as well. the new DPN as described in Section 5.3.1 apply as well.
5.5. Network Mobility 5.5. Network Mobility
The configuration for network mobility has been shown in Figures 4(a) The configuration for network mobility has been shown in Figure 4 in
and 4(b) in Section 3.1.4. Again, with centralized control plane, Section 3.1.4. Again, with centralized control plane, CPA, with the
CPA, with the associated LM and FM-CP are all co-located. There are associated LM and FM-CP are all co-located. There are multiple DPAs
multiple DPAs (each with FM-DP) in the data plane in distributed (each with FM-DP) in the data plane in distributed mobility
mobility anchoring. The MR possesses the mobility functions FM and anchoring. The MR possesses the mobility functions FM and LMc. The
LMc. The IP prefix IPn1 is delegated to the MR, to which an MNN is IP prefix IPn1 is delegated to the MR, to which an MNN is attached
attached and has an IP address from IPn1 assigned to its interface. and has an IP address from IPn1 assigned to its interface.
Figure 13 shows a distributed mobility event in a hierarchical Figure 13 shows a distributed mobility event in a hierarchical
network with a centralized control plane involving a change of network with a centralized control plane involving a change of
attachment of the MR from a previous DPA to a new DPA while the MNN attachment of the MR from a previous DPA to a new DPA while the MNN
is attached to the MR and therefore moves with the MR. is attached to the MR and therefore moves with the MR.
Net1 Net2 Net1 Net2
+----------------------------------------------------------------------+ +----------------------------------------------------------------------+
| CPA,Aggregate Router: LM:IP1 at IPa2; IPn1 at IP1 | | CPA,Aggregate Router: LM:IP1 at IPa2; IPn1 at IP1 |
| FM-CP, LM | | FM-CP, LM |
skipping to change at page 42, line 20 skipping to change at page 39, line 20
+-----------------+ +-----------------+
|Aggregate Router | |Aggregate Router |
+-----------------+ +-----------------+
|FM-DP | |FM-DP |
+-----------------+ +-----------------+
+---------------+ +---------------+ +---------------+ +---------------+
|AR1 | |AR2 | |AR1 | |AR2 |
+---------------+ +---------------+ +---------------+ +---------------+
|DPA(IPa1): | anchoring of IP1 is moved |DPA(IPa2): | |DPA(IPa1): | anchoring of IP1 is effectively moved|DPA(IPa2): |
|anchored IP1 | =======> |anchors IP2,IP1| |anchored IP1 | =======> |anchors IP2,IP1|
|DHCPv6-PD IPn1 | | | |DHCPv6-PD IPn1 | | |
|FM-DP | |FM-DP | |FM-DP | |FM-DP |
+---------------+ +---------------+ +---------------+ +---------------+
+...............+ +---------------+ +...............+ +---------------+
.MR(IP1) . MR moves |MR(IP2,IP1) | .MR(IP1) . MR moves |MR(IP2,IP1) |
+...............+ =======> +---------------+ +...............+ =======> +---------------+
.FM, LMc . |FM, LMc | .FM, LMc . |FM, LMc |
.anchors IPn1 . |anchors IPn1 | .delegated IPn1 . |delegated IPn1 |
+...............+ +---------------+ +...............+ +---------------+
+...............+ +---------------+ +...............+ +---------------+
.MNN(IPn1) . MNN moves with MR |MNN(IPn1) | .MNN(IPn1) . MNN moves with MR |MNN(IPn1) |
.flow(IPn1,...) . =======> |flow(IPn1,...) | .flow(IPn1,...) . =======> |flow(IPn1,...) |
+...............+ +---------------+ +...............+ +---------------+
Figure 13. Mobility involving change of IP anchoring for a MR to Figure 13. Mobility involving change of IP anchoring for a MR to
which an MNN is attached. which an MNN is attached.
skipping to change at page 43, line 7 skipping to change at page 40, line 7
support may be provided by moving the anchoring of IP1 from AR1 to support may be provided by moving the anchoring of IP1 from AR1 to
AR2 using the mechanism described in Section 5.2. AR2 using the mechanism described in Section 5.2.
The forwarding table updates will take place at AR1, AR2, the The forwarding table updates will take place at AR1, AR2, the
aggregate router, and other affected routers such that the packet aggregate router, and other affected routers such that the packet
from the CN to the MNN will traverse from the aggregate router from the CN to the MNN will traverse from the aggregate router
towards AR2 instead of towards AR1. towards AR2 instead of towards AR1.
5.5.1. Additional Guidelines for IPv6 Nodes: Network mobility 5.5.1. Additional Guidelines for IPv6 Nodes: Network mobility
The configuration guideline for a network or network slice with The configuration guideline for a network with centralized control
centralized control plane to provide network mobility is: plane to provide network mobility is:
GL-cfg:6 Multiple instances of DPAs (at access routers) which are GL-cfg:6 Multiple instances of DPAs (at access routers) which are
providing IP prefix of the MRs are needed to provide providing IP prefix of the MRs are needed to provide
distributed mobility anchoring according to Figure 4(a) or distributed mobility anchoring according to Figure 4 in
Figure 4(b) in Section 3.1. Section 3.1.
The appropriate IPv6 nodes (CPA, DPA) have to implement the The appropriate IPv6 nodes (CPA, DPA) have to implement the
mobility functions LM and FM as described respectively in mobility functions LM and FM as described respectively in
LM-cfg:3 or LM-cfg:4 and FM-cfg:4 in Section 3.2. LM-cfg:3 or LM-cfg:4 and FM-cfg:4 in Section 3.2.
The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the The GL-mix guidelines in Section 4.1.1 and in Section 4.2.1 for the
IPv6 nodes for a network or network slice supporting a mix of flows IPv6 nodes for a network supporting a mix of flows both requiring and
both requiring and not requiring IP mobility support apply here. not requiring IP mobility support apply here.
Here, because the MN is a MR, the following guideline is added: Here, because the MN is a MR, the following guideline is added:
GL-mix:11 There are no flows requiring network mobility support when GL-mix:11 There are no flows requiring network mobility support when
there are no MNN attaching to the MR. Here there are also there are no MNN attaching to the MR. Here there are also
no MNN using a prefix delegated to the MR. Therefore the no MNN using a prefix delegated to the MR. Therefore the
anchor of the MR may change to a new AR. The new AR may anchor of the MR may change to a new AR. The new AR may
delegate new IP prefix to the AR, so that the MR may delegate new IP prefix to the MR, so that the MR may
support potential MNNs to attach to it. On the other hand support potential MNNs to attach to it. On the other hand
the delegation of IP prefix to the MR from the old AR may the delegation of IP prefix to the MR from the old AR may
be deleted. be deleted.
The guidelines (GL-switch) in Section 5.1.1 for anchoring relocation The guidelines (GL-switch) in Section 5.1.1 for anchoring relocation
and in Section 5.2.1 for a centralized control plane also apply here. and in Section 5.2.1 for a centralized control plane also apply here.
Again because the MN is a MR, the following guidelines are added: Again because the MN is a MR, the following guidelines are added:
GL-switch:9 Network mobility may be provided using the FM operations GL-switch:9 Network mobility may be provided using the FM operations
skipping to change at page 44, line 8 skipping to change at page 41, line 8
and the aggregate router as well as other affected and the aggregate router as well as other affected
switches/routers between them so that packets from the switches/routers between them so that packets from the
CN to the MNN destined to IPn1 will traverse towards CN to the MNN destined to IPn1 will traverse towards
AR2. Meanwhile, changes to the forwarding table will AR2. Meanwhile, changes to the forwarding table will
also occur at AR1 and the aggregate router as well as also occur at AR1 and the aggregate router as well as
other affected switches/routers between them so that in other affected switches/routers between them so that in
case such packets ever reach any of these switches/ case such packets ever reach any of these switches/
routers, the packets will not traverse towards AR1 but routers, the packets will not traverse towards AR1 but
will traverse towards AR2. will traverse towards AR2.
GL-switch:11 The security management function in the anchor node at a GL-switch:11 The security policy must allow the MNN to continue to
new network must allow the MNN to continue to own the IP own the IP prefix/address originally delegated to the MR
prefix/address originally delegated to the MR and used and used by the MNN at the prior network. As this
by the MNN at the prior network. As this original IP original IP prefix/address is to be used in the new
prefix/address is to be used in the new network, the network, the security policy must allow the anchor node
security management function in the anchor node must to advertise the prefix of the original IP address and
allow to advertise the prefix of the original IP address also allow the MNN to send and receive data packets with
and also allow the MNN to send and receive data packets the original IP address.
with the original IP address.
GL-switch:12 The security management function in the mobile router GL-switch:12 The security policy must allow the mobile router to
must allow to configure the original IP prefix/address configure the original IP prefix/address delegated to
delegated to the MR from the previous (original) network the MR from the previous (original) network when the
when the original IP prefix/address is being delegated original IP prefix/address is being delegated to the MR
to the MR in the new network. The security management in the new network. The security policy must also
function in the mobile router also allows to use the allows to use the original IP address by the MNNs for
original IP address by the MNNs for the previous flow in the previous flow in the new network.
the new network.
6. Security Considerations 6. Security Considerations
Security protocols and mechanisms are employed to secure the network Security protocols and mechanisms are employed to secure the network
and to make continuous security improvements, and a DMM solution is and to make continuous security improvements, and a DMM solution is
required to support them [RFC7333]. In a DMM deployment required to support them [RFC7333]. In a DMM deployment
[I-D.ietf-dmm-deployment-models] various attacks such as [I-D.ietf-dmm-deployment-models] various attacks such as
impersonation, denial of service, man-in-the-middle attacks need to impersonation, denial of service, man-in-the-middle attacks need to
be prevented. An appropriate security management function as defined be prevented. An appropriate security management function as defined
in Section 2 controls these security protocols and mechanisms to in Section 2 controls these security protocols and mechanisms to
skipping to change at page 44, line 47 skipping to change at page 41, line 45
confidentiality, etc. confidentiality, etc.
Security considerations are described in terms of integrity support, Security considerations are described in terms of integrity support,
privacy support etc. in describing the mobility functions in privacy support etc. in describing the mobility functions in
Section 3.2. Here the mobility message parameters used in DMM must Section 3.2. Here the mobility message parameters used in DMM must
be protected, and some parameters require means to support MN and MR be protected, and some parameters require means to support MN and MR
privacy. The security considerations are also described in the privacy. The security considerations are also described in the
guidelines for IPv6 nodes in various subsections in Section 4, and guidelines for IPv6 nodes in various subsections in Section 4, and
Section 5. Section 5.
The IP address anchoring of an IP prefix is moved from one network to The IP address anchoring of an IP prefix is effectively moved from
another network to support IP mobility Section 5.1. As is considered one network to another network to support IP mobility Section 5.1.
in the guidelines for IPv6 nodes in Section 5.1.1, the security As is considered in the guidelines for IPv6 nodes in Section 5.1.1,
management function needs to enable the use in the new network of the security policy needs to enable the use in the new network of
attachment the IP prefix assigned from another network. Yet it must attachment the IP prefix assigned from another network. Yet it must
do so without compromising on the needed security to prevent the do so without compromising on the needed security to prevent the
possible misuse of an IP prefix belonging to another network. possible misuse of an IP prefix belonging to another network. A
viable solution is likely not be a global solution, but is limited in
scope to within specific regions with the proper trust relationship.
In network mobility, the MNN using an IP prefix assigned to it from In network mobility, the MNN using an IP prefix assigned to it from
the MR when the MR was in a prior network moves with the MR to a new the MR when the MR was in a prior network moves with the MR to a new
network Section 5.5. As is considered in the guidelines for IPv6 network Section 5.5. As is considered in the guidelines for IPv6
nodes in Section 5.5.1 to support IP mobility for an ongoing flow, nodes in Section 5.5.1 to support IP mobility for an ongoing flow,
the security management function needs to enable the continued use of the security management function needs to enable the continued use of
this IP prefix by the MNN with MR in the new network of attachment. this IP prefix by the MNN with MR in the new network of attachment.
Yet it must do so without compromising on the needed security to Yet it must do so without compromising on the needed security to
prevent the possible misuse of an IP prefix belonging to another prevent the possible misuse of an IP prefix belonging to another
network. network. Again, a viable solution is likely not be a global
solution, but is limited in scope to within specific regions with the
proper trust relationship.
7. IANA Considerations 7. IANA Considerations
This document presents no IANA considerations. This document presents no IANA considerations.
8. Contributors 8. Contributors
This document has benefited from other work on mobility solutions This document has benefited from other work on mobility support in
using BGP update, on mobility support in SDN network, on providing SDN network, on providing mobility support only when needed, and on
mobility support only when needed, and on mobility support in mobility support in enterprise network. These works have been
enterprise network. These works have been referenced. While some of referenced. While some of these authors have taken the work to
these authors have taken the work to jointly write this document, jointly write this document, others have contributed at least
others have contributed at least indirectly by writing these drafts. indirectly by writing these drafts. The latter include Philippe
The latter include Philippe Bertin, Dapeng Liu, Satoru Matushima, Bertin, Dapeng Liu, Satoru Matushima, Pierrick Seite, Jouni Korhonen,
Peter McCann, Pierrick Seite, Jouni Korhonen, and Sri Gundavelli. and Sri Gundavelli.
Valuable comments have been received from John Kaippallimalil, Valuable comments have been received from John Kaippallimalil,
ChunShan Xiong, and Dapeng Liu. Dirk von Hugo, Byju Pularikkal, ChunShan Xiong, and Dapeng Liu. Dirk von Hugo, Byju Pularikkal,
Pierrick Seite have generously provided careful review with helpful Pierrick Seite, Carlos Bernardos have generously provided careful
corrections and suggestions. review with helpful corrections and suggestions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.geng-netslices-architecture] [I-D.bernardos-dmm-cmip]
67, 4., Bryant, S., and J. Dong, "Network Slicing Bernardos, C., Oliva, A., and F. Giust, "An IPv6
Architecture", draft-geng-netslices-architecture-00 (work Distributed Client Mobility Management approach using
in progress), March 2017. existing mechanisms", draft-bernardos-dmm-cmip-07 (work in
progress), March 2017.
[I-D.bernardos-dmm-pmip]
Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based
solution for Distributed Mobility Management", draft-
bernardos-dmm-pmip-08 (work in progress), March 2017.
[I-D.ietf-dmm-deployment-models] [I-D.ietf-dmm-deployment-models]
Gundavelli, S. and S. Jeon, "DMM Deployment Models and Gundavelli, S. and S. Jeon, "DMM Deployment Models and
Architectural Considerations", draft-ietf-dmm-deployment- Architectural Considerations", draft-ietf-dmm-deployment-
models-01 (work in progress), February 2017. models-01 (work in progress), February 2017.
[I-D.ietf-dmm-fpc-cpdp] [I-D.ietf-dmm-fpc-cpdp]
Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
Moses, D., and C. Perkins, "Protocol for Forwarding Policy Moses, D., and C. Perkins, "Protocol for Forwarding Policy
Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-07 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-07
(work in progress), March 2017. (work in progress), March 2017.
[I-D.ietf-dmm-ondemand-mobility] [I-D.ietf-dmm-ondemand-mobility]
Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S. Yegin, A., Moses, D., Kweon, K., Lee, J., Park, J., and S.
Jeon, "On Demand Mobility Management", draft-ietf-dmm- Jeon, "On Demand Mobility Management", draft-ietf-dmm-
ondemand-mobility-10 (work in progress), January 2017. ondemand-mobility-11 (work in progress), June 2017.
[I-D.jhlee-dmm-dnpp] [I-D.jhlee-dmm-dnpp]
Lee, J. and Z. Yan, "Deprecated Network Prefix Provision", Lee, J. and Z. Yan, "Deprecated Network Prefix Provision",
draft-jhlee-dmm-dnpp-01 (work in progress), April 2016. draft-jhlee-dmm-dnpp-01 (work in progress), April 2016.
[I-D.korhonen-dmm-local-prefix] [I-D.korhonen-dmm-local-prefix]
Korhonen, J., Savolainen, T., and S. Gundavelli, "Local Korhonen, J., Savolainen, T., and S. Gundavelli, "Local
Prefix Lifetime Management for Proxy Mobile IPv6", draft- Prefix Lifetime Management for Proxy Mobile IPv6", draft-
korhonen-dmm-local-prefix-01 (work in progress), July korhonen-dmm-local-prefix-01 (work in progress), July
2013. 2013.
skipping to change at page 46, line 38 skipping to change at page 43, line 48
"Distributed mobility management deployment scenario and "Distributed mobility management deployment scenario and
architecture", draft-liu-dmm-deployment-scenario-05 (work architecture", draft-liu-dmm-deployment-scenario-05 (work
in progress), October 2015. in progress), October 2015.
[I-D.matsushima-stateless-uplane-vepc] [I-D.matsushima-stateless-uplane-vepc]
Matsushima, S. and R. Wakikawa, "Stateless user-plane Matsushima, S. and R. Wakikawa, "Stateless user-plane
architecture for virtualized EPC (vEPC)", draft- architecture for virtualized EPC (vEPC)", draft-
matsushima-stateless-uplane-vepc-06 (work in progress), matsushima-stateless-uplane-vepc-06 (work in progress),
March 2016. March 2016.
[I-D.mccann-dmm-flatarch]
McCann, P., "Authentication and Mobility Management in a
Flat Architecture", draft-mccann-dmm-flatarch-00 (work in
progress), March 2012.
[I-D.mccann-dmm-prefixcost] [I-D.mccann-dmm-prefixcost]
McCann, P. and J. Kaippallimalil, "Communicating Prefix McCann, P. and J. Kaippallimalil, "Communicating Prefix
Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-03 Cost to Mobile Nodes", draft-mccann-dmm-prefixcost-03
(work in progress), April 2016. (work in progress), April 2016.
[I-D.sarikaya-dmm-for-wifi]
Sarikaya, B. and L. Xue, "Distributed Mobility Management
Protocol for WiFi Users in Fixed Network", draft-sarikaya-
dmm-for-wifi-04 (work in progress), March 2016.
[I-D.seite-dmm-dma] [I-D.seite-dmm-dma]
Seite, P., Bertin, P., and J. Lee, "Distributed Mobility Seite, P., Bertin, P., and J. Lee, "Distributed Mobility
Anchoring", draft-seite-dmm-dma-07 (work in progress), Anchoring", draft-seite-dmm-dma-07 (work in progress),
February 2014. February 2014.
[I-D.templin-aerolink] [I-D.templin-aerolink]
Templin, F., "Asymmetric Extended Route Optimization Templin, F., "Asymmetric Extended Route Optimization
(AERO)", draft-templin-aerolink-74 (work in progress), (AERO)", draft-templin-aerolink-75 (work in progress), May
November 2016. 2017.
[I-D.yhkim-dmm-enhanced-anchoring]
Kim, Y. and S. Jeon, "Enhanced Mobility Anchoring in
Distributed Mobility Management", draft-yhkim-dmm-
enhanced-anchoring-05 (work in progress), July 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related
Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004, Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004,
<http://www.rfc-editor.org/info/rfc3753>. <http://www.rfc-editor.org/info/rfc3753>.
 End of changes. 141 change blocks. 
601 lines changed or deleted 487 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/