draft-ietf-dmm-distributed-mobility-anchoring-06.txt   draft-ietf-dmm-distributed-mobility-anchoring-07.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: January 4, 2018 J. Lee Expires: May 16, 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
July 3, 2017 November 12, 2017
Distributed Mobility Anchoring Distributed Mobility Anchoring
draft-ietf-dmm-distributed-mobility-anchoring-06 draft-ietf-dmm-distributed-mobility-anchoring-07
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 may be mobility needs in 5G Wireless and beyond. A network may be
configured with distributed mobility anchoring functions according to configured with distributed mobility anchoring functions according to
the needs of mobility support. In the distributed mobility anchoring the needs of mobility support. In the distributed mobility anchoring
environment, multiple anchors are available for mid-session switching environment, multiple anchors are available for mid-session switching
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 https://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 January 4, 2018. This Internet-Draft will expire on May 16, 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 (https://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
skipping to change at page 4, line 24 skipping to change at page 4, line 24
Section 3.1.1, Section 3.1.2, Section 3.1.3 and Section 3.1.4. Section 3.1.1, Section 3.1.2, Section 3.1.3 and Section 3.1.4.
Required operations and parameters for distributed mobility anchoring Required operations and parameters for distributed mobility anchoring
are presented in Section 3.2. For instance, location management is are presented in Section 3.2. For instance, location management is
described in Section 3.2.1, forwarding management is described in described in Section 3.2.1, forwarding 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 its correspondent
correspondent node (CN). When there are multiple mobility anchors, node (CN). When there are multiple mobility anchors, an address
an address selection for a given flow is first required before the selection for a given flow is first required before the flow is
flow is initiated. Using an anchor in an MN's network of attachment initiated. Using an anchor in an MN's network of attachment has the
has the advantage that the packets can simply be forwarded according advantage that the packets can simply be forwarded according to the
to the forwarding table. However, after the flow has been initiated, forwarding table. However, after the flow has been initiated, the MN
the MN may later move to another network, so that the IP address no may later move to another network, so that the IP address no longer
longer belongs to the current network of attachment of the MN. 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 mobility support is needed as shown in Section 4.2. A network
supporting a mix of flows both requiring and not requiring IP supporting a mix of flows both requiring and not requiring IP
mobility support will need to distinguish these flows. The mobility support will need to distinguish these flows. The
skipping to change at page 10, line 14 skipping to change at page 10, line 14
In Figure 2 the LMs is separated out, and a proxy LMp at the CPA is In Figure 2 the LMs is separated out, and a proxy LMp at the CPA is
added between the separate LMs and LMc at the CPN. Then, LMs may be added between the separate LMs and LMc at the CPN. Then, LMs may be
centralized whereas the LMp may be distributed or centralized centralized whereas the LMp may be distributed or centralized
according to whether the CPA is distributed or centralized. according to whether the CPA is distributed or centralized.
In a particular case (not shown), LMs and LMp may co-locate. In a particular case (not shown), LMs and LMp may co-locate.
3.1.3. Host-based Mobility Support 3.1.3. Host-based Mobility Support
Host-based mobility function configurations as variants from Figures Host-based mobility function configurations as variants from Figure 2
2 is shown in Figure 3 where the role to perform mobility functions is shown in Figure 3 where the role to perform mobility functions by
by CPN and DPN are now taken by the MN. The MN then needs to possess CPN and DPN are now taken by the MN. The MN then needs to possess
the mobility functions FM and LMc. the mobility functions FM and LMc.
+-----+ +-----+
|LMs | |LMs |
+-.---+ +-.---+
+--------.---+ +--------.---+
|CPA: . | |CPA: . |
|FM-CP, LMp | |FM-CP, LMp |
+------------+ +------------+
. . . .
skipping to change at page 10, line 49 skipping to change at page 10, line 49
|FM, LMc |anchored to |FM, LMc |anchored to
+------------+DPA(IPa1) +------------+DPA(IPa1)
Figure 3. Configuration of host-based mobility management. The Figure 3. Configuration of host-based mobility management. The
mobility management functions in the network include LMs in control mobility management functions in the network include LMs in control
plane, FM-CP and LMp at CPA, FM-DP at DPA. The mobility management plane, FM-CP and LMp at CPA, FM-DP at DPA. The mobility management
functions FM and LMc are also at the host (MN). functions FM and LMc are also at the host (MN).
Figure 3 shows configurations of host-based mobility management with Figure 3 shows configurations of host-based mobility management with
multiple instances of DPA for a distributed mobility anchoring multiple instances of DPA for a distributed mobility anchoring
environment. Figures 3 can be obtained by simply collapsing CPN, DPN environment. Figure 3 can be obtained by simply collapsing CPN, DPN
and MN from the Figures 2 into the MN in Figure 3 which now possesses and MN from the Figure 2 into the MN in Figure 3 which now possesses
the mobility functions FM and LMc that were performed previously by the mobility functions FM 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 the configurations of NEMO basic support for a mobile Figure 4 shows the configurations of NEMO basic support for a mobile
router. router.
+-----+ +-----+
|LMs | |LMs |
skipping to change at page 11, line 39 skipping to change at page 11, line 39
|MR(IP1) |using IP1 |MR(IP1) |using IP1
|delegated IPn1|anchored to |delegated IPn1|anchored to
|FM, LMc |DPA(IPa1) |FM, LMc |DPA(IPa1)
+--------------+ +--------------+
+------------+Mobile network node +------------+Mobile network node
|MNN(IPn1) |using IPn1 |MNN(IPn1) |using IPn1
|flow(IPn1,.)|attached to MR(IP1) |flow(IPn1,.)|attached to MR(IP1)
+------------+ +------------+
Figure 4. Configurations of NEMO basic support for a MR which is Figure 4. Configurations of NEMO basic support for an MR which is
attached to a network. The mobility management functions in the attached to a network. The mobility management functions in the
network are a separate LMs, FM-CP and LMp at CPA, FM-DP at DPA. The 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 mobility management functions FM and LMc are also at the MR to which
MNN is attached. MNN is attached.
Figure 4 shows configurations of host-based mobility management for a Figure 4 shows configurations of host-based mobility management for
MR with multiple instances of DPA for a distributed mobility an MR with multiple instances of DPA for a distributed mobility
anchoring environment. Figure 4 can be obtained by simply changing anchoring environment. Figure 4 can be obtained by simply changing
the MN from the Figures 3 into the MR carrying a mobile network the MN from the Figure 3 into the MR carrying a mobile network
consisting of mobile network nodes (MNNs) in Figure 4. consisting of mobile network nodes (MNNs) in Figure 4.
An IP prefix/address IPn1 delegated 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 assign the IP prefix IPn1, the DPA delegates the To enable the MR to assign the IP prefix IPn1, the DPA delegates the
prefix using DHCPv6-PD to the MR. prefix using DHCPv6-PD to the MR.
skipping to change at page 17, line 11 skipping to change at page 17, line 11
general be any node in the original forwarding path from general be any node in the original forwarding path from
the CN to the home network DPA. The packet is forwarded the CN to the home network DPA. The packet is forwarded
to the MN for host-based mobility and to a node in the to the MN for host-based mobility and to a node in the
network which will deliver the packets to the MN for network which will deliver the packets to the MN for
network-based mobility. The near-end is generally a DPN network-based mobility. The near-end is generally a DPN
with a hierarchical network but may also be another node with a hierarchical network but may also be another node
with DPA capability in a flattened network. with DPA capability in a flattened network.
FM-path:3 The mechanisms to accomplish such changes may include FM-path:3 The mechanisms to accomplish such changes may include
changes to the forwarding table and indirection such as changes to the forwarding table and indirection such as
tunneling, rewriting packet header, or NAT. tunneling, rewriting packet header, segment routing
[I-D.matsushima-spring-dmm-srv6-mobile-uplane], or NAT.
Note: An emphasis in this document in distributed mobility Note: An emphasis in this document in distributed mobility
anchoring is to explain the use of multiple anchors to anchoring is to explain the use of multiple anchors to
avoid unnecessarily long route which may be encountered in avoid unnecessarily long route which may be encountered in
centralized mobility anchoring. It is therefore not the centralized mobility anchoring. It is therefore not the
emphasis of this document on which particular mechanism to emphasis of this document on which particular mechanism to
choose from. choose from.
FM-path-tbl:4 The objective of forwarding table updates is to change FM-path-tbl:4 The objective of forwarding table updates is to change
the forwarding path so that the packets in the flow the forwarding path so that the packets in the flow
skipping to change at page 27, line 45 skipping to change at page 27, line 45
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
table entries will also occur at AR1 and the far end DPA as table entries will also occur at AR1 and the far end DPA as
well as other affected switches/routers between them so well as other affected switches/routers between them so
that if these packets ever reaches any of them, they will that if these packets ever reach any of them, they will not
not traverse towards AR1 but will traverse towards AR2 (see traverse towards AR1 but will traverse towards AR2 (see
Section 3.2.2). Section 3.2.2).
GL-mix:9 Alternatively when using a mechanism of indirection, the FM GL-mix:9 Alternatively when using a mechanism of indirection, the FM
operations and mobility message parameters are described in operations and mobility message parameters are described in
FM-path, FM-path-ind, FM-DPA, and FM-DPA-ind in FM-path, FM-path-ind, FM-DPA, and FM-DPA-ind in
Section 3.2.2. Section 3.2.2.
GL-mix:10 If there are in-flight packets toward the old anchor while GL-mix:10 If there are in-flight packets toward the old anchor while
the MN is moving to the new anchor, it may be necessary to the MN is moving to the new anchor, it may be necessary to
buffer these packets and then forward to the new anchor buffer these packets and then forward to the new anchor
skipping to change at page 39, line 38 skipping to change at page 39, line 38
+...............+ =======> +---------------+ +...............+ =======> +---------------+
.FM, LMc . |FM, LMc | .FM, LMc . |FM, LMc |
.delegated IPn1 . |delegated 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 an MR to
which an MNN is attached. which an MNN is attached.
As the MR with source IP prefix IP1 moves from AR1 to AR2, mobility As the MR with source IP prefix IP1 moves from AR1 to AR2, mobility
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.
skipping to change at page 40, line 23 skipping to change at page 40, line 23
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 supporting a mix of flows both requiring and IPv6 nodes for a network supporting a mix of flows 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 an 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 MNNs attaching to the MR. Here there are also
no MNN using a prefix delegated to the MR. Therefore the no MNNs 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 MR, 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 an 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
and mobility message parameters as described in FM-mr in and mobility message parameters as described in FM-mr in
Section 3.2.2. Section 3.2.2.
GL-switch:10 The following changes to forwarding table entries are GL-switch:10 The following changes to forwarding table entries are
needed: needed:
New entries to the forwarding tables are added at AR2 New entries to the forwarding tables are added at AR2
and the aggregate router as well as other affected and the aggregate router as well as other affected
skipping to change at page 41, line 22 skipping to change at page 41, line 22
network, the security policy must allow the anchor node network, the security policy must allow the anchor node
to advertise the prefix of the original IP address and to advertise the prefix of the original IP address and
also allow the MNN to send and receive data packets with also allow the MNN to send and receive data packets with
the original IP address. the original IP address.
GL-switch:12 The security policy must allow the mobile router to GL-switch:12 The security policy must allow the mobile router to
configure the original IP prefix/address delegated to configure the original IP prefix/address delegated to
the MR from the previous (original) network when the the MR from the previous (original) network when the
original IP prefix/address is being delegated to the MR original IP prefix/address is being delegated to the MR
in the new network. The security policy must also in the new network. The security policy must also
allows to use the original IP address by the MNNs for allows to use the original IP address by the MNN for the
the previous flow in the new network. previous flow in 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 42, line 47 skipping to change at page 42, line 47
Pierrick Seite, Carlos Bernardos have generously provided careful Pierrick Seite, Carlos Bernardos have generously provided careful
review with helpful corrections and suggestions. review with helpful corrections and suggestions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.bernardos-dmm-cmip] [I-D.bernardos-dmm-cmip]
Bernardos, C., Oliva, A., and F. Giust, "An IPv6 Bernardos, C., Oliva, A., and F. Giust, "An IPv6
Distributed Client Mobility Management approach using Distributed Client Mobility Management approach using
existing mechanisms", draft-bernardos-dmm-cmip-07 (work in existing mechanisms", draft-bernardos-dmm-cmip-08 (work in
progress), March 2017. progress), September 2017.
[I-D.bernardos-dmm-pmip] [I-D.bernardos-dmm-pmip]
Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based
solution for Distributed Mobility Management", draft- solution for Distributed Mobility Management", draft-
bernardos-dmm-pmip-08 (work in progress), March 2017. bernardos-dmm-pmip-09 (work in progress), September 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-03 (work in progress), November 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-09
(work in progress), March 2017. (work in progress), October 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-11 (work in progress), June 2017. ondemand-mobility-12 (work in progress), July 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.
[I-D.liu-dmm-deployment-scenario] [I-D.liu-dmm-deployment-scenario]
Liu, V., Liu, D., Chan, A., Lingli, D., and X. Wei, Liu, V., Liu, D., Chan, A., Lingli, D., and X. Wei,
"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-spring-dmm-srv6-mobile-uplane]
Matsushima, S., Filsfils, C., Kohno, M., and d.
daniel.voyer@bell.ca, "Segment Routing IPv6 for Mobile
User-Plane", draft-matsushima-spring-dmm-srv6-mobile-
uplane-03 (work in progress), November 2017.
[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-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] [I-D.sarikaya-dmm-for-wifi]
Sarikaya, B. and L. Xue, "Distributed Mobility Management Sarikaya, B. and L. Li, "Distributed Mobility Management
Protocol for WiFi Users in Fixed Network", draft-sarikaya- Protocol for WiFi Users in Fixed Network", draft-sarikaya-
dmm-for-wifi-04 (work in progress), March 2016. dmm-for-wifi-05 (work in progress), October 2017.
[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-75 (work in progress), May (AERO)", draft-templin-aerolink-75 (work in progress), May
2017. 2017.
[I-D.yhkim-dmm-enhanced-anchoring] [I-D.yhkim-dmm-enhanced-anchoring]
Kim, Y. and S. Jeon, "Enhanced Mobility Anchoring in Kim, Y. and S. Jeon, "Enhanced Mobility Anchoring in
Distributed Mobility Management", draft-yhkim-dmm- Distributed Mobility Management", draft-yhkim-dmm-
enhanced-anchoring-05 (work in progress), July 2016. 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>. <https://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>. <https://www.rfc-editor.org/info/rfc3753>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008, RFC 5213, DOI 10.17487/RFC5213, August 2008,
<http://www.rfc-editor.org/info/rfc5213>. <https://www.rfc-editor.org/info/rfc5213>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <http://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)", Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, DOI 10.17487/RFC6459, January 2012, RFC 6459, DOI 10.17487/RFC6459, January 2012,
<http://www.rfc-editor.org/info/rfc6459>. <https://www.rfc-editor.org/info/rfc6459>.
[RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and
J. Korhonen, "Update Notifications for Proxy Mobile IPv6", J. Korhonen, "Update Notifications for Proxy Mobile IPv6",
RFC 7077, DOI 10.17487/RFC7077, November 2013, RFC 7077, DOI 10.17487/RFC7077, November 2013,
<http://www.rfc-editor.org/info/rfc7077>. <https://www.rfc-editor.org/info/rfc7077>.
[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
Korhonen, "Requirements for Distributed Mobility Korhonen, "Requirements for Distributed Mobility
Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
<http://www.rfc-editor.org/info/rfc7333>. <https://www.rfc-editor.org/info/rfc7333>.
[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and
CJ. Bernardos, "Distributed Mobility Management: Current CJ. Bernardos, "Distributed Mobility Management: Current
Practices and Gap Analysis", RFC 7429, Practices and Gap Analysis", RFC 7429,
DOI 10.17487/RFC7429, January 2015, DOI 10.17487/RFC7429, January 2015,
<http://www.rfc-editor.org/info/rfc7429>. <https://www.rfc-editor.org/info/rfc7429>.
9.2. Informative References 9.2. Informative References
[Paper-Distributed.Mobility] [Paper-Distributed.Mobility]
Lee, J., Bonnin, J., Seite, P., and H. Chan, "Distributed Lee, J., Bonnin, J., Seite, P., and H. Chan, "Distributed
IP Mobility Management from the Perspective of the IETF: IP Mobility Management from the Perspective of the IETF:
Motivations, Requirements, Approaches, Comparison, and Motivations, Requirements, Approaches, Comparison, and
Challenges", IEEE Wireless Communications, October 2013. Challenges", IEEE Wireless Communications, October 2013.
[Paper-Distributed.Mobility.PMIP] [Paper-Distributed.Mobility.PMIP]
 End of changes. 35 change blocks. 
50 lines changed or deleted 57 lines changed or added

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