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/