Internet DRAFT - draft-xiong-dmm-ip-reachability
draft-xiong-dmm-ip-reachability
DMM C. Xiong
INTERNET-DRAFT J. Liu
Intended Status: Informational Huawei Technologies
Expires: August 16, 2014 February 12, 2014
MN IP reachability for the DMM
draft-xiong-dmm-ip-reachability-01
Abstract
In distributed mobility management (DMM) environment, the mobile node
(MN) has more than one IP addresses and can use different IP address
to communicate with different hosts.
When a new correspondent node (CN) initials an IP session with MN,
the CN needs to find and select one of the MN's IP addresses to
provide best performance (e.g. with low delay) for the IP session.
This draft analyses the existing mechanisms for IP reachability in a
distributed mobility management environment, and identifies the key
procedures or enhancements to support the routing-optimized IP
reachability in a distributed mobility management environment.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Xiong & Liu Expires August 16, 2014 [Page 1]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Solutions Analysis . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Solution1 Analysis: DDNS server-based solution . . . . . . 5
4.2 Solution2 Analysis : Application Server
Registration-based solution . . . . . . . . . . . . . . . . 6
4.2.1 P2P mode . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2 Server Central mode . . . . . . . . . . . . . . . . . . 8
4.2.3 Combined mode . . . . . . . . . . . . . . . . . . . . . 10
4.3 Analysis Summary . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 Normative References . . . . . . . . . . . . . . . . . . . 12
7.2 Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Xiong & Liu Expires August 16, 2014 [Page 2]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
1. Introduction
In distributed mobility management (DMM) environment, the mobile node
(MN) has more than one IP addresses and can use different IP address
to communicate with different hosts. When a new correspondent node
(CN) initials an IP session with MN, the CN needs to find and select
one of the MN's IP addresses to best (e.g. with low delay) for the IP
session.
This draft analyses the existing mechanisms for IP reachability in a
distributed mobility management environment, and identifies the key
procedures or enhancements to support the routing-optimized IP
reachability in a distributed mobility management environment. This
draft tries to find out whether there are technical issues blocking
the current existing IP reachability mechanism to be routing-
optimized in a distributed mobility management environment, then try
to find out how to change or enhance the current existing IP
reachability mechanism to be routing-optimized if there are some
technical issues. This draft does not define or provide new IP
reachability mechanism for the distributed mobility management
environment but can provide some guidance to define new IP
reachability mechanisms for the distributed mobility management
environment.
Currently, there are two main IP reachability solutions to find and
select of MN's IP Addresses, one is DDNS[RFC 2136]-based solution
that MN registers its new IP address to a DDNS server, and CN obtains
the MN's new IP address info from the DDNS server, and then initials
an IP session to the MN. The other is Application Server Register-
based solution that MN and CN both register their new IP addresses
and ports info to the same application server for a given service or
application, e.g., MSN messenger and there are three sub-methods for
CN to obtain the MN's IP address info and initial an IP session to
the MN, which are P2P mode, server central mode, and combined mode.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
this draft introduces the following terms.
MR: Mobile Router
CN: Correspondent Node
Xiong & Liu Expires August 16, 2014 [Page 3]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
DDNS: Distributed DNS
GUID: Global Unique ID
P2P: Peer To Peer
3. Problem Statement
In distributed mobility management (DMM) environment, the mobile node
(MN) has more than one IP addresses to communicate with other hosts.
The MN initials a new IP session with a new CN via the MN's latest IP
address and the IP path between the MN and CN are routing-
optimized[I-D.ietf-dmm-requirements].However, when a new
correspondent node(CN) initials a new IP session with the MN, the CN
doesn't know how to choose the MN's latest IP address to ensure the
IP path between the CN and the MN is routing-optimized. so the IP
reachability in the distributed mobility management is how a new CN
finds out and chooses the MN's latest IP address to initial a new
routing-optimized IP session with the MN.
As described in figure 1, firstly the MN attaches to the MR1 and
address IP1 is allocated to the MN by the MR1, then the MN initials a
new IP session with the CN1 through the MR1 via the address IP1.after
the MN moves to the MR2 and IP2 is allocated to the MN by the MR2,the
MN initials another new IP session with CN2 using IP2, at the same
time, the IP session between the MN's IP1 and CN1 are kept
continuity, after that, a new CN3 wants to initial a new IP session
with the MN, the IP reachability issue needs to be solved: How the
CN3 to get the MN's latest IP address to ensure the new IP session
between the CN3 and the MN is routing-optimized ?
+----+ +----+ +----+
|CN1 | |CN2 | |CN3 |
+--+-+ +--+-+ +--+-+
IP1 | |IP2 |
| | |
+--+--+ IP1 +---+-+ ? ---+
| MR1 +-----------+ MR2 |
+--+--+ +-+-+-+
| | |
|IP1 IP1| |IP2
| | |
+-+--+ move ++-+-+
| MN | ---------- | MN |
+----+ +----+
Figure 1: MN routing with multiple IP addresses
Xiong & Liu Expires August 16, 2014 [Page 4]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
4. Solutions Analysis
Currently, there are two main IP reachability solutions to find and
select of MN's latest IP Address, one is DDNS[RFC 2136]-based
solution that MN registers its new IP address to a DDNS server, and
CN obtains the MN's latest IP address info from the DDNS server. The
other is Application Server Register-based solution that MN and CN
both register their latest IP address and ports info to the same
application server for a given service or application, then the CN
obtains the MN's latest IP address info from the application server.
4.1 Solution1 Analysis: DDNS server-based solution
In this solution, each MN has a global unique ID (GUID), e.g. FQDN
[RFC4703] , and a DDNS server stores the MN's latest IP address with
the MN's GUID.As described in figure 2, when the MN attaches to MR1
and gets an IP address IP1 from the MR1, the MN registers its latest
IP address i.e. IP1,and MN's GUID to the DDNS server. The MN initials
a new IP session with CN1 via its latest IP address IP1, after the MN
moves and attaches to the MR2, and gets a new IP address IP2 from the
MR2, the MN immediately refreshes its DDNS registration with its
latest IP address IP2 and the same MN GUID to the DDNS server, If the
MN initials a new IP session with the new CN2, the MN uses its latest
IP address IP2 to setup the IP session to the CN2 to ensure the new
IP session is routing-optimized. At the same time, the IP session
between the MN's IP1 and CN1 are kept IP session continuity via the
distributed mobility management procedure.
If a new CN3 initials a new IP session with the MN, firstly CN3 has
to requests the MN's IP address from DDNS server with the MN GUID,
and DDNS Server responses with the registered MN's IP address, then
the CN3 directly initials to setup a new IP session to the MN with
the retrieved MN's IP address. If the retrieved MN's IP address is
the latest IP address of the MN, then the new IP session between the
CN3 and MN is routing-optimized, otherwise, it is not. So the key
requirement for the DDNS-based IP reachability solution is that the
MN needs to register its latest IP address to the DDNS server.
But the DNS cache mechanism to improve the DNS query speed makes the
things more complex. For example, after the CN3 has got the MN IP
address IPx from the DDNS Server with the MN GUID, the CN3 usually
caches the IPx with MN GUID with a defined timer, if before the timer
expires, the MN has refreshed the DDNS server with its new latest IP
address IPy and the CN3 initials another new IP session, the CN3
still uses the cached IPx to setup the new IP session, this new IP
session is not routing-optimized, for the DDNS-based IP reachability
solution either the CN3 disable its DNS cache function or the DDNS
server indicates that the DNS response can't be cached or is with a
Xiong & Liu Expires August 16, 2014 [Page 5]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
very short validate time (e.g. 200ms).
It seems that the DDNS-based IP reachability solution is very simple
and workable in the distributed mobility management, but there still
needs some additional functions or mechanism to support for this
solution:
1) There needs a mechanism/procedure to allocate a permanent GUID for
each MN, currently, not each GUID is allocated for a MN permanently.
In the mobile telecommunication system, e.g. 3GPP system, a global
unique MSISDN (Mobile Station Integrated Services Data Network) is
allocated to each mobile node.
2) A reliable DDNS Server is needed for the MN to register its latest
IP address and for the CN to query the MN's latest IP address.
3) There still needs a way (out scope of this draft) for a CN to
acquire the MN GUID and the MN registered-DDNS server address before
the CN wants to initial a new IP session to the MN.
+------------+____Req_____+----+
| DNS Server |____Res_____|CN3 |
+-----+------+ +--+-+
/ /\ \ #
/ / \ \ #
+-+--+ / \ +--+-+ #
|CN1 | / \ |CN2 | #
+--+-+ / \ +--+-+ #
IP1 # / \ IP2# #
# / \ # to IPx
+--++-+ Tunnel ++--+-+
| MR1 +===========+ MR2 |
+--+--+ ++--+-+
# # #
IP1 # IP1# # IP2
# # #
+-+--+ move +--+-+
| MN | ---------> | MN |
+----+ +----+
Figure 2: MN's IP reachability with DDNS server
4.2 Solution2 Analysis : Application Server Registration-based solution
In this solution, for an application or service, e.g., MSN Messenger,
the MN and the CN both register their IP address and (TCP/UDP) port
info to the same (virtual or physical) application server. After
Xiong & Liu Expires August 16, 2014 [Page 6]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
moving and attaching to a new MR, the MN gets a new and latest IP
address from the new MR, the MN refreshes its registration with its
new IP address and port info to the application server immediately or
some time later again depended on the application status of the MN.
There are three mode for the CN to initial a new IP session with the
MN, which is including P2P mode[RFC 5694], Server central mode and
Combined mode.
4.2.1 P2P mode
As described in figure 3, firstly the CN3 has registered its IP
address and Port info to the same application server as the MN. If
the CN3 wants to initial a new IP session with the MN, the CN3 sends
"service request to the MN" message to the application server. In
this request message, the MN is identified by the application-
specific ID, e.g. Messenger Name of the MN. The application server
searches and finds out the MN application context indexed by the MN's
application ID and gets the MN's registered IP address and port info
and responses the MN registered IP address and port info to the CN3,
then the CN3 directly setup a new IP session to the MN by connecting
to the retrieved MN's IP address and port info. When the MN moves and
attaches to a new MR2 and get a new IP address IP2 from the MR2, the
MN can immediately refreshes the application server with the new IP
address IP2 even when the established IP session between the CN3 and
the MN is still running and the IP session continuity is kept.
However, a lot of applications have a separate user plane and control
plane, i.e. a different IP + Port is used for the application's user
plane and control plane respectively. For example, the MN can
register IP1+Port1 for the control plane and dynamically allocates
IP2+Port2 for the user plane with a host (e.g. SIP/WebRTC/IMS
service), or the MN can register the IP2+Port1 for the control plane
and dynamically allocates IP2+Port2 for the user plane with a host.
For Application Server Registration-based P2P mode, it is required
that the MN registers the same latest IP address and port number for
the control plane.
It seems that the Application Server Registration-based P2P solution
is almost the same as the DDNS-based solution, As described in the
DDNS-based solution, the CN needn't to cache the retrieved MN IP
address and Port info, if the CN wants to initial another new IP
session with the MN, the CN just request the application server and
gets the MN's latest registered IP address and port info from the
application server.
Based on the above description, it can found out that the Application
Server Registration-based solution has more advantages than the DDNS-
Xiong & Liu Expires August 16, 2014 [Page 7]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
based solution:
1)In DDNS-based solution, there needs a mechanism/procedure to
allocate a permanent GUID for each MN. In Application Server
Registration-based solution, the MN (also the CN) is assigned a
unique ID by the application server.
2) In DDNS-based solution, a reliable DDNS Server is needed for the
MN to register its latest IP address and for the CN to query the MN's
latest IP address. In Application Server Registration-based solution,
the Application server is always available for the MN and the CN.
3)In DDNS-based solution, there still needs a way (out scope of this
draft) for a CN to acquire the MN GUID and the MN registered-DDNS
server address before the CN wants to initial a new IP session to the
MN. In Application Server Registration-based solution, the MN and the
CN can be included in each other's buddy list or can be found out
each other by the search function of the application.
+------------+____Req_____+----+
| Server |____Res_____|CN3 |
+-----+------+ +--+-+
/ / \ #
/ / \ #
+-+--+ / +--+-+ #
|CN1 | / |CN2 | #
+--+-+ / +--+-+ #
IP1 # / IP2# #
# / # to IPx
+--++-+ Tunnel ++--+-+
| MR1 +===========+ MR2 |
+--+--+ ++--+-+
# # #
IP1 # IP1# # IP2
# # #
+-+--+ move +--+-+
| MN | ---------> | MN |
+----+ +----+
Figure 3: MN's reachability with Server Registration by P2P mode
4.2.2 Server Central mode
As described in figure 4, firstly the CN3 has registered its IP
address and Port info to the same application server as the MN. If
the CN3 wants to initial a new IP session with the MN, the CN3 sends
Xiong & Liu Expires August 16, 2014 [Page 8]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
"Service Request to the MN" message to the application server. In
this request message, the MN is identified by the application-
specific ID, e.g. Messenger Name of the MN. The application server
responses the server's IP address and port info to the CN3, the CN3
initiate a new IP session to the received the application server's IP
address and the port info. At the same time, the application server
searches and finds out the MN application context indexed by the MN's
application ID, and gets the MN's registered IP address and port info
and initiates a new IP session to the MN via the MN's registered IP
address and port info. After both the IP session between the CN3 and
the Server and the IP session between the application server are
established, and the application server forwarding the application
data between the two IP sessions, the communication between the CN3
and the MN is established. From the CN3 side, it thinks it setups a
new IP session with the MN, and for the MN side, it thinks a new IP
session is established with the CN3, in fact, the IP session is not
directly established, the application server acts as an application
proxy for the CN3 and the MN's IP session. So this method of
establishing a new IP session between the CN and the MN is named as
Application Server Registration-based server central solution.
If a server-central mode IP session between MN and CN1 is established
via the MN's IP1 when the MN attaches to the MR1, after the MN moves
and attaches to a new MR2 and get a new IP address IP2 from the MR2,
the MN can't immediately refreshes the registration to the
application server with the new IP address IP2 if there is a
established IP session for the MN, otherwise the established server-
central mode IP session between CN1 and MN is interrupted. So if the
CN3 wants to initiate a new server-central mode IP session to the MN,
the new IP session is established via the MN's old IP1 instead of the
new IP2, so the new IP session isn't routing optimized. However, for
the application with a separate user plane and control plane, the MN
can't immediately refreshes the registration to the application
server with the new IP address IP2 if there is a established IP
session for the MN , but the MN can dynamically allocates IP2+Port2
for the user plane with the CN3,i.e. that the new IP session with CN3
are combined with IP1+Port1 in control plane and IP2+Port2 in user
plane, in this method, the new IP session is partly routing-optimized
between the application server and the MN. Because the Application
Server Registration-based server central solution can't provide
routing optimization or only provide partly routing optimization, it
is not preferred method to establish an IP session in a distributed
mobility management environment.
Xiong & Liu Expires August 16, 2014 [Page 9]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
+------------+____Req1____+----+
| Server | |CN3 |
+-----+------+ +--+-+
/ / \ \
/ Req2/ \ \
+----+ / \ +----+
|CN1 | / \ |CN2 |
+--+-+ / \ +-+--+
/ \
/ IP1 \ IP2
+--++-+ +--+-++
| MR1 +===========+ MR2 |
+--+--+ ++-+-++
| | |
IP1 | IP1| | IP2
| | |
+-+--+ move +-+-++
| MN | ---------> | MN |
+----+ +----+
Figure 4: MN's reachability with Server Registration by
Server central mode
4.2.3 Combined mode
The Application Server Registration-based Combined mode is using the
Server Central mode to discover the MN's control plane IP and port
info and using P2P mode to establish the user plan IP session. As
described in figure 5, firstly the CN3 has registered its IP address
and Port info to the same application server as the MN. If the CN3
wants to initial a new IP session with the MN, the CN3 sends "Service
Request to the MN" message to the application server (in this control
plane). In this request message, the MN is identified by the
application-specific ID, e.g. Messenger Name of the MN. Then the
application server forwards the request message to the MN based on
the MN's registration information (in the MN's control plane),the MN
responses to the application server with MN's user plane IP and Port
info and the application server forwards the MN's responses to the
CN3, the CN3 initiate a new IP session for the user plane data and
keeps the control IP session with the application server and the MN.
If a Combined mode user plane IP session between MN and CN1 is
established via the MN's IP1 when the MN attaches to the MR1, after
the MN moves and attaches to a new MR2 and get a new IP address IP2
from the MR2, the MN can't immediately refreshes the registration to
the application server with the new IP address IP2 if there is a
established IP session for the MN, otherwise the established server-
central mode IP session between CN1 and MN is interrupted. So if the
CN3 wants to initiate a new combined mode IP session to the MN, the
Xiong & Liu Expires August 16, 2014 [Page 10]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
MN's uses the old and shared control plane IP session with CN1 to
provide the MN's user plane IP2+Port2 info to the CN3, then the new
user plane IP session between the CN3 and MN is established via the
MN's latest IP2.In Combined method, the new user plane IP session is
routing-optimized but the control plane is not routing optimized, and
because the traffic in the control plane is some minor, so the
control plane's non-routing optimization can be ignored.
+------------+____1.Req __+----+
| Server |____4.Res___|CN3 |
+-----+------+ +--+-+
/ 2.Req/ \ #
/ / \ #
+-+--+ / +--+-+ #
|CN1 | /3.Res |CN2 | #
+--+-+ / +--+-+ #
IP1 # / IP2# #
# / # to IPx
+--++-+ Tunnel ++--+-+
| MR1 +===========+ MR2 |
+--+--+ ++--+-+
# # #
IP1 # IP1# #IP2
# # #
+-+--+ move +--+-+
| MN | ---------> | MN |
+----+ +----+
Figure 5: MN's reachability with Server Registration by Combined mode
4.3 Analysis Summary
Based on the above analysis, most of the current IP reachability
solution can be used in a distributed mobility management
environment. The main conclusion are: 1)The DDNS-based and
Application Server Registration-based P2P mode solution can provide
IP session routing optimization if the MN refreshes the registration
of the DDNS/application server immediately after the latest IP
address is allocated to the MN.
2)The Application Server Registration-based Combined mode solution
can provide user plane IP session routing optimization and the
control plane isn't routing optimized if the MN provides the latest
IP address for the user plane IP session. Since the traffic of the
control plane is minor, so the Application Server Registration-based
Combined mode solution is regard as a good routing optimization
solution.
Xiong & Liu Expires August 16, 2014 [Page 11]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
3)The Application Server Registration-based Server central solution
can't provide routing optimization or only provide half segmentation
routing optimization between the application server and the MN, so
this method should not be used.
This draft only analyzes the current well-known IP reachability
methods without considering the special DMM framework or DMM
protocols or any special application (e.g. broadcast or multicast).
The draft needs to be updated with new and good IP reachability
methods or after DMM protocols are defined or some special
applications are supported in the DMM environment.
5. Security Considerations
Security related issues are not considered in current document.
6. IANA Considerations
None
7. References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified
Domain Name (FQDN) Conflicts among Dynamic Host
Configuration Protocol (DHCP) Clients", RFC 4703, October
2006.
[RFC5694] Camarillo, G., Ed., and IAB, "Peer-to-Peer (P2P)
Architecture: Definition, Taxonomies, Examples, and
Applicability", RFC 5694, November 2009.
7.2 Informative References
[I-D.ietf-dmm-requirements] Chan, A., Liu, D., Seite, P., Yokota, H.,
Xiong & Liu Expires August 16, 2014 [Page 12]
INTERNET DRAFT MN IP reachability for the DMM February 12, 2014
and J. Korhonen, "Requirements for Distributed Mobility
Management", draft-ietf-dmm-requirements-14 (work in
progress),February 2014.
Authors' Addresses
Chunshan Xiong
Huawei Technologies
BeiQing Road No.156
HaiDian District , Beijing 100095
China
Email: sam.xiongchunshan@huawei.com
Jianning Liu
Huawei Technologies
BeiQing Road No.156
HaiDian District , Beijing 100095
China
Email: liujianning.liu@huawei.com
Xiong & Liu Expires August 16, 2014 [Page 13]
