draft-ietf-dmm-distributed-mobility-anchoring-08.txt   draft-ietf-dmm-distributed-mobility-anchoring-09.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: September 3, 2018 J. Lee Expires: January 3, 2019 J. Lee
Sangmyung University Sangmyung University
S. Jeon S. Jeon
Sungkyunkwan University Sungkyunkwan University
CJ. Bernardos, Ed. CJ. Bernardos, Ed.
UC3M UC3M
March 2, 2018 July 2, 2018
Distributed Mobility Anchoring Distributed Mobility Anchoring
draft-ietf-dmm-distributed-mobility-anchoring-08 draft-ietf-dmm-distributed-mobility-anchoring-09
Abstract Abstract
This document defines distributed mobility anchoring in terms of the This document defines distributed mobility anchoring in terms of the
different configurations and functions to provide IP mobility different configurations and functions to provide IP mobility
support. A network may be configured with distributed mobility support. A network may be configured with distributed mobility
anchoring functions for both network-based or host-based mobility anchoring functions for both network-based or host-based mobility
support according to the needs of mobility support. In the support according to the needs of mobility support. In the
distributed mobility anchoring environment, multiple anchors are distributed mobility anchoring environment, multiple anchors are
available for mid-session switching of an IP prefix anchor. To start available for mid-session switching of an IP prefix anchor. To start
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 https://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 September 3, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Distributed Mobility Anchoring . . . . . . . . . . . . . . . 5 3. Distributed Mobility Anchoring . . . . . . . . . . . . . . . 5
3.1. Configurations for Different Networks . . . . . . . . . . 5 3.1. Configurations for Different Networks . . . . . . . . . . 5
3.1.1. Network-based DMM . . . . . . . . . . . . . . . . . . 5 3.1.1. Network-based DMM . . . . . . . . . . . . . . . . . . 5
3.1.2. Client-based DMM . . . . . . . . . . . . . . . . . . 6 3.1.2. Client-based DMM . . . . . . . . . . . . . . . . . . 6
4. IP Mobility Handling in Distributed Anchoring Environments - 4. IP Mobility Handling in Distributed Anchoring Environments -
Mobility Support Only When Needed . . . . . . . . . . . . . . 7 Mobility Support Only When Needed . . . . . . . . . . . . . . 7
4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 8 4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 8
4.2. Need of IP Mobility . . . . . . . . . . . . . . . . . . . 9 4.2. Need of IP Mobility . . . . . . . . . . . . . . . . . . . 9
5. IP Mobility Handling in Distributed Mobility Anchoring 5. IP Mobility Handling in Distributed Mobility Anchoring
Environments - Anchor Switching to the New Network . . . . . 11 Environments - Anchor Switching to the New Network . . . . . 11
5.1. IP Prefix/Address Anchor Switching for Flat Network . . . 11 5.1. IP Prefix/Address Anchor Switching for Flat Network . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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. This document defines different configurations, an optimal route. This document defines different configurations,
functional operations and parameters for distributed mobility functional operations and parameters for distributed mobility
anchoring and explains how to use them to make the route changes to anchoring and explains how to use them to make the route changes to
avoid unnecessarily long routes. avoid unnecessarily long routes.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
data plane functions and be centralized but may also be co-located data plane functions and be centralized but may also be co-located
with the data plane functions at the distributed anchors. Different with 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. Section 3.1.
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 its correspondent source IP address in a flow to communicate with its correspondent
node (CN). When there are multiple mobility anchors, an address node (CN). When there are multiple mobility anchors assigned to the
selection for a given flow is first required before the flow is same MN, an address selection for a given flow is first required
initiated. Using an anchor in an MN's network of attachment has the before the flow is initiated. Using an anchor in an MN's network of
advantage that the packets can simply be forwarded according to the attachment has the advantage that the packets can simply be forwarded
forwarding table. However, after the flow has been initiated, the MN according to the forwarding table. However, after the flow has been
may later move to another network, so that the IP address no longer initiated, the MN may later move to another network which assigns a
belongs to the current network of attachment of the MN. new mobility anchor to the MN. Since the new anchor is located in a
different network, the MN's assigned prefix and the built MN IP
address does not belong to the network where the MN is currently
attached.
The IP session continuity needs of a flow (application) determines When the MN wants to continue using its assigned prefix and IP
the how the IP address used by the traffic of this flow has to be address, e.g., to complete ongoing data sessions after it moved to a
anchored. If the ongoing IP flow can cope with an IP prefix/address new network, the network needs to provide support for IP address- and
change, the flow can be reinitiated with a new IP address anchored in session continuity, since routing packets to the MN through the new
the new network. On the other hand, if the ongoing IP flow cannot network deviates from applying default routes. The IP session
cope with such change, mobility support is needed. A network continuity needs of a flow (application) determines the how the IP
supporting a mix of flows both requiring and not requiring IP address used by the traffic of this flow has to be anchored. If the
mobility support will need to distinguish these flows. ongoing IP flow can cope with an IP prefix/address change, the flow
can be reinitiated with a new IP address anchored in the new network.
On the other hand, if the ongoing IP flow cannot cope with such
change, mobility support is needed. A network supporting a mix of
flows both requiring and not requiring IP mobility support will need
to distinguish these flows.
2. Conventions and Terminology 2. Conventions and Terminology
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)
specification [RFC5213], the "Mobility Related Terminologies" specification [RFC5213], the "Mobility Related Terminologies"
[RFC3753], and the DMM current practices and gap analysis [RFC7429]. [RFC3753], and the DMM current practices and gap analysis [RFC7429].
These include terms such as mobile node (MN), correspondent node These include terms such as mobile node (MN), correspondent node
(CN), home agent (HA), home address (HoA), care-of-address (CoA), (CN), home agent (HA), home address (HoA), care-of-address (CoA),
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 a home address: the network that has assigned the
network that has assigned the HoA used as the session identifier HoA used as the session identifier by the application running in
by the application running in an MN. The MN may be running an MN. The MN may be running multiple application sessions, and
multiple application sessions, and each of these sessions can have each of these sessions can have a different home network.
a different home network.
Anchoring (an IP prefix/address): An IP prefix, i.e., Home Network Anchor (of an IP prefix/address): An IP prefix, i.e., Home Network
Prefix (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. The traffic using the
assigned IP address/prefix must traverse the anchor node. We can
refer to the function performed by IP anchor node as anchoring,
which is a data plane function.
Location Management (LM) function: that keeps and manages the Location Management (LM) function: control plane function that keeps
network location information of an MN. The location information and manages the network location information of an MN. The
may be a binding of the advertised IP address/prefix, e.g., HoA or location information may be a binding of the advertised IP
HNP, to the IP routing address of the MN or of a node that can address/prefix, e.g., HoA or HNP, to the IP routing address of the
forward packets destined to the MN. MN or of a node that can 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.
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), where the location (LMc) and a Location Management server (LMs), where the location
information can be updated to or queried from the LMs. information can be updated to or queried from the LMc.
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 5, line 48 skipping to change at page 6, line 12
The control plane and the data plane (Control Plane Anchor -- CPA The control plane and the data plane (Control Plane Anchor -- CPA
-- and Data Plane Anchor -- DPA) may be co-located or not. If the -- and Data Plane Anchor -- DPA) may be co-located or not. If the
CPA is co-located with the distributed DPAs, then there are CPA is co-located with the distributed DPAs, then there are
multiple co-located CPA-DPA instances (not shown in the figure). multiple co-located CPA-DPA instances (not shown in the figure).
An IP prefix/address IP1 (anchored to the DPA with IP address An IP prefix/address IP1 (anchored to the DPA with IP address
IPa1) is assigned for use by an MN. The MN uses this IP1 address IPa1) is assigned for use by an MN. The MN uses this IP1 address
to communicate with CNs (not shown in the figure). to communicate with CNs (not shown in the figure).
The location management (LM) function may be co-located or split The location management (LM) function may be co-located or split
(as shown in the figure) into a separate server (LMs) and a client (as shown in the figure) into a separate server (LMs) and a client
(LMc). In this case, the LMs may be centralized whereas the LMc (LMc). In this case, the LMs may be centralized whereas the LMc
may be distributed or centralized, according to whether the CPA is may be distributed or centralized.
distributed or centralized.
____________ Network ____________ Network
___/ \___________ ___/ \___________
/ +-----+ \___ / +-----+ \___
( |LMs | Control \ ( |LMs | Control \
/ +-.---+ plane \ / +-.---+ plane \
/ +--------.---+ functions \ / +--------.---+ functions \
( |CPA: . | in the ) ( |CPA: . | in the )
( |FM-CP, LMc | network ) ( |FM-CP, LMc | network )
( +------------+ \ ( +------------+ \
skipping to change at page 7, line 36 skipping to change at page 7, line 36
+------------+DPA(IPa1) +------------+DPA(IPa1)
Figure 2: Client-based DMM configuration Figure 2: Client-based DMM configuration
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. provided by default.
A straightforward choice of mobility anchoring is for a flow to use A straightforward choice of mobility anchoring is the following: the
the IP prefix of the network to which the MN is attached when the MN's choses as source IP address of packets belonging to an IP flow,
flow is initiated [I-D.seite-dmm-dma] an address allocated by the network the MN is attached to when the
flow was initiated. As such, traffic belonging to this flow
traverses the MN's mobility anchor [I-D.seite-dmm-dma]
[I-D.bernardos-dmm-pmipv6-dlif]. [I-D.bernardos-dmm-pmipv6-dlif].
The IP prefix/address at the MN's side of a flow may be anchored at The IP prefix/address at the MN's side of a flow may be anchored at
the access router to which the MN is attached. For example, when an the access router to which the MN is attached. For example, when an
MN attaches to a network (Net1) or moves to a new network (Net2), an MN attaches to a network (Net1) or moves to a new network (Net2), an
IP prefix from the attached network is assigned to the MN's IP prefix from the attached network is assigned to the MN's
interface. In addition to configuring new link-local addresses, the interface. In addition to configuring new link-local addresses, the
MN configures from this prefix an IP address which is typically a MN configures from this prefix an IP address which is typically a
dynamic IP address. It then uses this IP address when a flow is dynamic IP address. It then uses this IP address when a flow is
initiated. Packets to the MN in this flow are simply forwarded initiated. Packets to the MN in this flow are simply forwarded
skipping to change at page 9, line 44 skipping to change at page 9, line 46
IP2 address configuration | | IP2 address configuration | |
| | | | | | | |
|<-new Flow(IP2,IPcn,...)-----------+---------------------------->| |<-new Flow(IP2,IPcn,...)-----------+---------------------------->|
| | | | | | | |
Figure 4: Re-starting a flow with new IP prefix/address Figure 4: Re-starting a flow with new IP prefix/address
4.2. Need of IP Mobility 4.2. Need of IP Mobility
When IP mobility is needed for a flow, the LM and FM functions in When IP mobility is needed for a flow, the LM and FM functions in
Section 3.1 are utilized. The mobility support may be provided by IP Section 3.1 are utilized. There are two possible cases: (i) the
prefix anchor switching to the new network to be described in initial anchor remains the anchor and forwards traffic to a new
Section 5 or by using other mobility management methods locator in the new network, and (ii) the mobility anchor (data plane
function) is changed but binds the MN's transferred IP address/
prefix. The latter enable optimized routes but requires some data
plane node that enforces rules for traffic indirection.
The first case identified above (mobility support provided by IP
prefix anchor switching to the new network) can be performed as
described in Section 5 or by using other mobility management methods
([Paper-Distributed.Mobility], [Paper-Distributed.Mobility.PMIP] and ([Paper-Distributed.Mobility], [Paper-Distributed.Mobility.PMIP] and
[Paper-Distributed.Mobility.Review]). Then the flow may continue to [Paper-Distributed.Mobility.Review]). Then the flow may continue to
use the IP prefix from the prior network of attachment. Yet some use the IP prefix from the prior network of attachment. Yet some
time later, the user application for the flow may be closed. If the time later, the user application for the flow may be closed. If the
application is started again, the new flow may not need to use the application is started again, the new flow may not need to use the
prior network's IP address to avoid having to invoke IP mobility prior network's IP address to avoid having to invoke IP mobility
support. This may be the case where a dynamic IP prefix/address support. This may be the case where a dynamic IP prefix/address
rather than a permanent one is used. The flow may then use the new rather than a permanent one is used. The flow may then use the new
IP prefix in the network where the flow is being initiated. Routing IP prefix in the network where the flow is being initiated. Routing
is again kept simpler without employing IP mobility and will remain is again kept simpler without employing IP mobility and will remain
so as long as the MN which is now in the new network has not moved so as long as the MN which is now in the new network has not moved
again and left to another new network. again and left to another new network.
An example call flow in this case is outlined in Figure 5. An example call flow in this case is outlined in Figure 5. In this
example, the AR1 plays the role of FM-DP entity and redirects the
traffic (e.g., using an IP tunnel) to AR2. Another solution could be
to place an FM-DP entity closer to the CN network to perform traffic
steering to deviate from default routes (which will bring the packet
to AR1 per default routing).
MN AR1 AR2 CN MN AR1 AR2 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)---| | |
| | | | | | | |
Assigned prefix IP1 | | | Assigned prefix IP1 | | |
IP1 address configuration | | IP1 address configuration | |
| | | | | | | |
|<-Flow(IP1,IPcn,...)-+------------------------------------------>| |<-Flow(IP1,IPcn,...)-+------------------------------------------>|
| | | | | | | |
|MN detach from AR1 | | | |MN detach from AR1 | | |
|MN attach to AR2 | | | |MN attach to AR2 | | |
| | | | | | | |
|--RS------------------------------>| | |--RS------------------------------>| |
IP mobility support such as that described in next sub-section IP mobility support such as that described in next sub-section
|<--------------RA(IP2,IP1)---------| | |<--------------RA(IP2,IP1)---------| |
| | | | | | | |
|<-Flow(IP1,IPcn,...)---------------+---------------------------->| | +<-Flow(IP1,IPcn,...)---------------------->|
| +<===========>+ |
|<-Flow(IP1,IPcn,...)-------------->+ |
| | | | | | | |
Assigned prefix IP2 | | | Assigned prefix IP2 | | |
IP2 address configuration | | IP2 address configuration | |
| | | | | | | |
Flow(IP1,IPcn) terminates | | Flow(IP1,IPcn) terminates | |
| | | | | | | |
|<-new Flow(IP2,IPcn,...)-----------+---------------------------->| |<-new Flow(IP2,IPcn,...)-----------+---------------------------->|
| | | | | | | |
Figure 5: A flow continues to use the IP prefix from its home network Figure 5: A flow continues to use the IP prefix from its home network
skipping to change at page 12, line 41 skipping to change at page 13, line 33
mobility support in enterprise network. These works have been mobility support in enterprise network. These works have been
referenced. While some of these authors have taken the work to referenced. While some of these authors have taken the work to
jointly write this document, others have contributed at least jointly write this document, others have contributed at least
indirectly by writing these drafts. The latter include Philippe indirectly by writing these drafts. The latter include Philippe
Bertin, Dapeng Liu, Satoru Matushima, Pierrick Seite, Jouni Korhonen, Bertin, Dapeng Liu, Satoru Matushima, 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 have generously provided careful review with helpful
corrections and suggestions. corrections and suggestions. Marco Liebsch also performed a very
detailed and helpful review of this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.bernardos-dmm-pmipv6-dlif] [I-D.bernardos-dmm-pmipv6-dlif]
Bernardos, C., Oliva, A., Giust, F., and J. Zuniga, "Proxy Bernardos, C., Oliva, A., Giust, F., Zuniga, J., and A.
Mobile IPv6 extensions for Distributed Mobility Mourad, "Proxy Mobile IPv6 extensions for Distributed
Management", draft-bernardos-dmm-pmipv6-dlif-00 (work in Mobility Management", draft-bernardos-dmm-pmipv6-dlif-01
progress), October 2017. (work in progress), March 2018.
[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-03 (work in progress), November 2017. models-04 (work in progress), May 2018.
[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-09 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12
(work in progress), October 2017. (work in progress), June 2018.
[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-13 (work in progress), January 2018. ondemand-mobility-14 (work in progress), March 2018.
[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
 End of changes. 24 change blocks. 
58 lines changed or deleted 84 lines changed or added

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