draft-ietf-dmm-distributed-mobility-anchoring-09.txt   draft-ietf-dmm-distributed-mobility-anchoring-10.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: January 3, 2019 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
July 2, 2018 July 2, 2018
Distributed Mobility Anchoring Distributed Mobility Anchoring
draft-ietf-dmm-distributed-mobility-anchoring-09 draft-ietf-dmm-distributed-mobility-anchoring-10
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 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 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. Nomadic case (no need of IP mobility): Changing to new IP
4.2. Need of IP Mobility . . . . . . . . . . . . . . . . . . . 9 prefix/address . . . . . . . . . . . . . . . . . . . . . 8
5. IP Mobility Handling in Distributed Mobility Anchoring 4.2. Mobility case, traffic redirection . . . . . . . . . . . 10
Environments - Anchor Switching to the New Network . . . . . 11 4.3. Mobility case, anchor relocation . . . . . . . . . . . . 12
5.1. IP Prefix/Address Anchor Switching for Flat Network . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 5, line 44 skipping to change at page 5, line 44
consider architectures in which the control and data planes are consider architectures in which the control and data planes are
separated, as described in [I-D.ietf-dmm-deployment-models]. separated, as described in [I-D.ietf-dmm-deployment-models].
3.1.1. Network-based DMM 3.1.1. Network-based DMM
Figure 1 shows a general scenario for network-based distributed Figure 1 shows a general scenario for network-based distributed
mobility management. mobility management.
The main characteristics of a network-based DMM solution are: The main characteristics of a network-based DMM solution are:
There are multiple data plane anchors (i.e., DPA instances), each o There are multiple data plane anchors (i.e., DPA instances), each
with an FM-DP function. with an FM-DP function.
The control plane may either be distributed (not shown in the o The control plane may either be distributed (not shown in the
figure) or centralized (as shown in the figure). figure) or centralized (as shown in the figure).
The control plane and the data plane (Control Plane Anchor -- CPA o 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 o 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 o 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. may be distributed or centralized.
____________ Network ____________ Network
___/ \___________ ___/ \___________
/ +-----+ \___ / +-----+ \___
( |LMs | Control \ ( |LMs | Control \
/ +-.---+ plane \ / +-.---+ plane \
/ +--------.---+ functions \ / +--------.---+ functions \
skipping to change at page 7, line 34 skipping to change at page 7, line 34
|flow(IP1,..)|using IP1 |flow(IP1,..)|using IP1
|FM, LMc |anchored to |FM, LMc |anchored to
+------------+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. Three cases can be considered:
o Nomadic case: no address continuity is required. The IP address
used by the MN changes after movement and traffic using old
address is disrupted. If session continuity is required, then it
needs to be provided by a solution running at L4 or above.
o Mobility case, traffic redirection: address continuity is
required. When the MN moves, the previous anchor still anchors
traffic using the old IP address, and forwards it to the new MN's
location. The MN obtains a new IP address anchored at the new
location, and preferably uses it for new communications,
established while connected at the new location.
o Mobility case, anchor relocation: address continuity is required.
In this case the route followed by the traffic is optimized, by
using some means for traffic indirection to deviate from default
routes.
A straightforward choice of mobility anchoring is the following: the A straightforward choice of mobility anchoring is the following: the
MN's choses as source IP address of packets belonging to an IP flow, MN's choses as source IP address of packets belonging to an IP flow,
an address allocated by the network the MN is attached to when the an address allocated by the network the MN is attached to when the
flow was initiated. As such, traffic belonging to this flow flow was initiated. As such, traffic belonging to this flow
traverses the MN's mobility anchor [I-D.seite-dmm-dma] 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
skipping to change at page 8, line 15 skipping to change at page 8, line 29
There may be multiple IP prefixes/addresses that an MN can select There may be multiple IP prefixes/addresses that an MN can select
when initiating a flow. They may be from the same access network or when initiating a flow. They may be from the same access network or
different access networks. The network may advertise these prefixes different access networks. The network may advertise these prefixes
with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node
may choose the one with the least cost. In addition, these IP may choose the one with the least cost. In addition, these IP
prefixes/addresses may be of different types regarding whether prefixes/addresses may be of different types regarding whether
mobility support is needed [I-D.ietf-dmm-ondemand-mobility]. A flow mobility support is needed [I-D.ietf-dmm-ondemand-mobility]. A flow
will need to choose the appropriate one according to whether it needs will need to choose the appropriate one according to whether it needs
IP mobility support. IP mobility support.
4.1. No Need of IP Mobility: Changing to New IP Prefix/Address 4.1. Nomadic case (no need of IP mobility): Changing to new IP prefix/
address
When IP mobility support is not needed for a flow, the LM and FM When IP mobility support is not needed for a flow, the LM and FM
functions are not utilized so that the configurations in Section 3.1 functions are not utilized so that the configurations in Section 3.1
are simplified as shown in Figure 3. are simplified as shown in Figure 3.
Net1 Net2 Net1 Net2
+---------------+ +---------------+ +---------------+ +---------------+
|AR1 | AR is changed |AR2 | |AR1 | AR is changed |AR2 |
+---------------+ -------> +---------------+ +---------------+ -------> +---------------+
skipping to change at page 9, line 43 skipping to change at page 10, line 31
|<--------------RA(IP2)-------------| | |<--------------RA(IP2)-------------| |
| | | | | | | |
Assigned prefix IP2 | | | Assigned prefix IP2 | | |
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. Mobility case, traffic redirection
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. There are two possible cases: (i) the Section 3.1 are utilized. There are two possible cases: (i) the
initial anchor remains the anchor and forwards traffic to a new initial anchor remains the anchor and forwards traffic to a new
locator in the new network, and (ii) the mobility anchor (data plane locator in the new network, and (ii) the mobility anchor (data plane
function) is changed but binds the MN's transferred IP address/ function) is changed but binds the MN's transferred IP address/
prefix. The latter enable optimized routes but requires some data prefix. The latter enables optimized routes but requires some data
plane node that enforces rules for traffic indirection. plane node that enforces rules for traffic indirection. Next, we
focus on the first case.
The first case identified above (mobility support provided by IP Mobility support can be provided by using mobility management methods
prefix anchor switching to the new network) can be performed as such as ([Paper-Distributed.Mobility],
described in Section 5 or by using other mobility management methods [Paper-Distributed.Mobility.PMIP] and
([Paper-Distributed.Mobility], [Paper-Distributed.Mobility.PMIP] and [Paper-Distributed.Mobility.Review]). After moving, a certain MN's
[Paper-Distributed.Mobility.Review]). Then the flow may continue to traffic flow may continue using the IP prefix from the prior network
use the IP prefix from the prior network of attachment. Yet some of attachment. Yet some time later, the user application for the
time later, the user application for the flow may be closed. If the flow may be closed. If the application is started again, the new
application is started again, the new flow may not need to use the flow may not need to use the prior network's IP address to avoid
prior network's IP address to avoid having to invoke IP mobility having to invoke IP mobility support. This may be the case where a
support. This may be the case where a dynamic IP prefix/address dynamic IP prefix/address rather than a permanent one is used. The
rather than a permanent one is used. The flow may then use the new flow may then use the new IP prefix in the network where the flow is
IP prefix in the network where the flow is being initiated. Routing being initiated. Routing is again kept simpler without employing IP
is again kept simpler without employing IP mobility and will remain mobility and will remain so as long as the MN which is now in the new
so as long as the MN which is now in the new network has not moved 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. In this An example call flow in this case is outlined in Figure 6. In this
example, the AR1 plays the role of FM-DP entity and redirects the 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 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 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 steering to deviate from default routes (which will bring the packet
to AR1 per default routing). to AR1 per default routing). The LM and FM functions are implemented
as shown in Figure 5.
Net1 Net2
+---------------+ +---------------+
|AR1 | |AR2 |
+---------------+ +---------------+
|CPA: | |CPA: |
| | |LM:IP1 at IPa1 |
|---------------| IP1 (anchored at Net1) |---------------|
|DPA(IPa1): | is redirected to Net2 |DPA(IPa2): |
|anchors IP1 | =======> |anchors IP2 |
+---------------+ +---------------+
+...............+ +---------------+
.MN(IP1) . MN moves |MN(IP2,IP1) |
.flow(IP1,...) . =======> |flow(IP1,...) |
. . |flow(IP2,...) |
+...............+ +---------------+
Figure 5: Anchor redirection
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 | |
skipping to change at page 11, line 36 skipping to change at page 12, line 36
|<-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 6: A flow continues to use the IP prefix from its home network
after MN has moved to a new network after MN has moved to a new network
Multiple instances of DPAs (at access routers), which are providing Multiple instances of DPAs (at access routers), which are providing
IP prefix to the MNs, are needed to provide distributed mobility IP prefix to the MNs, are needed to provide distributed mobility
anchoring in an appropriate configuration such as those described in anchoring in an appropriate configuration such as those described in
Figure 1 (Section 3.1.1) for network-based distributed mobility or in Figure 1 (Section 3.1.1) for network-based distributed mobility or in
Figure 2 (Section 3.1.2) for client-based distributed mobility. Figure 2 (Section 3.1.2) for client-based distributed mobility.
5. IP Mobility Handling in Distributed Mobility Anchoring Environments 4.3. Mobility case, anchor relocation
- Anchor Switching to the New Network
We focus next on the case where the mobility anchor (data plane
function) is changed but binds the MN's transferred IP address/
prefix. This enables optimized routes but requires some data plane
node that enforces rules for traffic indirection.
IP mobility is invoked to enable IP session continuity for an ongoing IP mobility is invoked to enable IP session continuity for an ongoing
flow as the MN moves to a new network. Here the anchoring of the IP flow as the MN moves to a new network. Here the anchoring of the IP
address of the flow is in the home network of the flow, which is not address of the flow is in the home network of the flow, which is not
in the current network of attachment. A centralized mobility in the current network of attachment. A centralized mobility
management mechanism may employ indirection from the anchor in the management mechanism may employ indirection from the anchor in the
home network to the current network of attachment. Yet it may be home network to the current network of attachment. Yet it may be
difficult to avoid unnecessarily long route when the route between difficult to avoid unnecessarily long route when the route between
the MN and the CN via the anchor in the home network is significantly the MN and the CN via the anchor in the home network is significantly
longer than the direct route between them. An alternative is to longer than the direct route between them. An alternative is to
switch the IP prefix/address anchoring to the new network. switch the IP prefix/address anchoring to the new network.
5.1. IP Prefix/Address Anchor Switching for Flat Network
The IP prefix/address anchoring may move without changing the IP The IP prefix/address anchoring may move without changing the IP
prefix/address of the flow. Here the LM and FM functions in Figure 1 prefix/address of the flow. Here the LM and FM functions in Figure 1
in Section 3.1 are implemented as shown in Figure 6. in Section 3.1 are implemented as shown in Figure 7.
Net1 Net2 Net1 Net2
+---------------+ +---------------+ +---------------+ +---------------+
|AR1 | |AR2 | |AR1 | |AR2 |
+---------------+ +---------------+ +---------------+ +---------------+
|CPA: | |CPA: | |CPA: | |CPA: |
|LM:IP1 at IPa1 | |LM:IP1 at IPa2 | |LM:IP1 at IPa1 | |LM:IP1 at IPa2 |
| changes to | | | | changes to | | |
| IP1 at IPa2 | | | | IP1 at IPa2 | | |
|---------------| |---------------| |---------------| |---------------|
|DPA(IPa1): | IP1 anchoring is effectively moved|DPA(IPa2): | |DPA(IPa1): | IP1 anchoring is effectively moved|DPA(IPa2): |
|anchored IP1 | =======> |anchors IP2,IP1| |anchored IP1 | =======> |anchors IP2,IP1|
+---------------+ +---------------+ +---------------+ +---------------+
+...............+ +---------------+ +...............+ +---------------+
.MN(IP1) . MN moves |MN(IP2,IP1) | .MN(IP1) . MN moves |MN(IP2,IP1) |
skipping to change at page 12, line 35 skipping to change at page 13, line 41
|---------------| |---------------| |---------------| |---------------|
|DPA(IPa1): | IP1 anchoring is effectively moved|DPA(IPa2): | |DPA(IPa1): | IP1 anchoring is effectively moved|DPA(IPa2): |
|anchored IP1 | =======> |anchors IP2,IP1| |anchored IP1 | =======> |anchors IP2,IP1|
+---------------+ +---------------+ +---------------+ +---------------+
+...............+ +---------------+ +...............+ +---------------+
.MN(IP1) . MN moves |MN(IP2,IP1) | .MN(IP1) . MN moves |MN(IP2,IP1) |
.flow(IP1,...) . =======> |flow(IP1,...) | .flow(IP1,...) . =======> |flow(IP1,...) |
+...............+ +---------------+ +...............+ +---------------+
Figure 6: Anchor mobility Figure 7: Anchor mobility
As an MN with an ongoing session moves to a new network, the flow may As an MN with an ongoing session moves to a new network, the flow may
preserve IP session continuity by moving the anchoring of the preserve IP session continuity by moving the anchoring of the
original IP prefix/address of the flow to the new network. original IP prefix/address of the flow to the new network.
One way to accomplish such move is to use a centralized routing One way to accomplish such move is to use a centralized routing
protocol, but note that this solution presents some scalability protocol, but note that this solution presents some scalability
concerns and its applicability is typically limited to small concerns and its applicability is typically limited to small
networks. networks.
6. Security Considerations 5. 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]. required to support them [RFC7333].
In a DMM deployment [I-D.ietf-dmm-deployment-models] various attacks In a DMM deployment [I-D.ietf-dmm-deployment-models] various attacks
such as impersonation, denial of service, man-in-the-middle attacks such as impersonation, denial of service, man-in-the-middle attacks
need to be prevented. need to be prevented.
7. IANA Considerations 6. IANA Considerations
This document presents no IANA considerations. This document presents no IANA considerations.
8. Contributors 7. Contributors
Alexandre Petrescu and Fred L. Templin had contributed to earlier Alexandre Petrescu and Fred L. Templin had contributed to earlier
versions of this document regarding distributed anchoring for versions of this document regarding distributed anchoring for
hierarchical network and for network mobility, although these hierarchical network and for network mobility, although these
extensions were removed to keep the document within reasonable extensions were removed to keep the document within reasonable
length. length.
This document has benefited from other work on mobility support in This document has benefited from other work on mobility support in
SDN network, on providing mobility support only when needed, and on SDN network, on providing mobility support only when needed, and on
mobility support in enterprise network. These works have been mobility support in enterprise network. These works have been
skipping to change at page 13, line 36 skipping to change at page 14, line 42
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. Marco Liebsch also performed a very corrections and suggestions. Marco Liebsch also performed a very
detailed and helpful review of this document. detailed and helpful review of this document.
9. References 8. References
9.1. Normative References 8.1. Normative References
[I-D.bernardos-dmm-pmipv6-dlif] [I-D.bernardos-dmm-pmipv6-dlif]
Bernardos, C., Oliva, A., Giust, F., Zuniga, J., and A. Bernardos, C., Oliva, A., Giust, F., Zuniga, J., and A.
Mourad, "Proxy Mobile IPv6 extensions for Distributed Mourad, "Proxy Mobile IPv6 extensions for Distributed
Mobility Management", draft-bernardos-dmm-pmipv6-dlif-01 Mobility Management", draft-bernardos-dmm-pmipv6-dlif-01
(work in progress), March 2018. (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-
skipping to change at page 15, line 26 skipping to change at page 16, line 31
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,
<https://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,
<https://www.rfc-editor.org/info/rfc7429>. <https://www.rfc-editor.org/info/rfc7429>.
9.2. Informative References 8.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]
Chan, H., "Proxy Mobile IP with Distributed Mobility Chan, H., "Proxy Mobile IP with Distributed Mobility
Anchors", Proceedings of GlobeCom Workshop on Seamless Anchors", Proceedings of GlobeCom Workshop on Seamless
 End of changes. 27 change blocks. 
53 lines changed or deleted 93 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/