MN IP reachablility for the DMM
draft-xiong-dmm-ip-reachability-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Chunshan Xiong , Liu Jianning | ||
| Last updated | 2013-09-27 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xiong-dmm-ip-reachability-00
dmm C. Xiong
Internet-Draft J. Liu
Intended status: Informational Huawei Technologies
Expires: March 31, 2014 September 27, 2013
MN IP reachablility for the DMM
draft-xiong-dmm-ip-reachability-00
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 best
(e.g. with low delay) for the IP session..
This draft provides two solutions to find and select of MN's IP
addresses, one is DDNS[rfc 2136]-based solution, the other is Server
Register-based solution.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 31, 2014.
Copyright Notice
Copyright (c) 2013 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
Xiong & Liu Expires March 31, 2014 [Page 1]
Internet-Draft MN IP reachablility for the DMM September 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Abbreviation . . . . . . . . . . . . . . . . 3
2.1. Conventions Used in This Document . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Solution1: DDNS server . . . . . . . . . . . . . . . . . 4
4.2. Solution2: Server Registeration . . . . . . . . . . . . . 5
4.2.1. P2P mode . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. Server Central mode . . . . . . . . . . . . . . . . . 6
4.2.3. Combined mode . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative Reference . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 provides two 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 DDNS server, and CN obtains the MN's new IP address
info from DDNS server, then initials an IP session to the MN. The
other is Server Register-based solution that MN and CN both register
their new IP addresses and ports info to the same server for a given
service, e.g., MSN messenger and there are three 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.
P2P mode: CN directly initials a new IP session to MN with the help
of retrieved info from server.
Xiong & Liu Expires March 31, 2014 [Page 2]
Internet-Draft MN IP reachablility for the DMM September 2013
Server central mode: CN initials a new IP session to MN, which has to
pass through the server.
Combined mode: for control plane, CN initials the connection to MN by
Server central mode. For user plane, CN initials the IP session to
MN by P2P mode.
2. Terminology and Abbreviation
2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
thisdocument are to be interpreted as described in [RFC2119].
2.2. Terminology
MR: Mobile Router
CN: Correspondent Node
DDNS: Distributed DNS
GUID: Global Unique ID
P2P: Peer To Peer
3. Problem Statement
In distributed mobility management (DMM) environment, mobile node(MN)
always has more than one IP addresses to communicate with other ends.
There is no problem for MN to initial a new IP session with any other
CN by using MN's latest IP address, so we provide solutions below
based on requirement initialed by CN. However, when a new
correspondent node(CN) initials an IP session with MN, CN doesn't
know how to choose MN's IP address and which one to choose.
MN attached to MR1, and MN initials the IP1 session with CN1 through
MR1 using IP1 allocated by MR1. When MN moves, and attaches to MR2,
MN1 initials the IP2 session with CN2 using IP2 allocated by MR2, IP1
session continuty is still kept .
Then, a new CN3 initials a new IP session with MN1, there are some
problems to be solved.
1) How CN3 to get MN1's IP address?
2) Which IP address for CN3 to choose? Why?
Xiong & Liu Expires March 31, 2014 [Page 3]
Internet-Draft MN IP reachablility for the DMM September 2013
+----+ +----+ +----+
|CN1 | |CN2 | |CN3 |
+--+-+ +--+-+ +--+-+
IP1 | |IP2 |
| | |
+--+--+ IP1 +---+-+ ? ---+
| MR1 +-----------+ MR2 |
+--+--+ +-+-+-+
| | |
|IP1 IP1| |IP2
| | |
+-+--+ move ++-+-+
|MN1 | ---------- |MN1 |
+----+ +----+
Figure 1: MN routing with multiple IP addresses
4. Solutions
4.1. Solution1: DDNS server
In this solution, each MN has a global unique ID (GUID), e.g. FQDN
[RFC4703] , and DDNS server are needed to store MN's latest IP
address and port info. When MN1 attached to MR1, MN1 registers its
new IP1 address, port info and MN1 ID to DDNS server, and MN1
initials the IP1 session with CN1, as described in Fig2. When MN1
moves and attaches to MR2, MN1 registers its new IP2 address, port
info and MN1 ID to DDNS server, and MN1 initials the IP2 session with
CN2; IP1 session continuity is kept.
At the moment, CN3 initials a new IP session with MN1, firstly CN3
has to requests MN1's latest IP address and port info from DDNS
server, and DDNS Server responses with MN1's latest IP address and
port info, then CN3 directly initials to setup the IPx session
between CN3 with returing info above. If CN3 cached MN1 IP address,
CN3 initials to setup IP session with MN1 using the cached IP
address.
However, There still needs some additional functions or mechnism to
support for this solution:
1) There needs a mechnism to allocate a permanent GUID for MN,
because currently, not each GUID is allocated for a MN permanently.
Xiong & Liu Expires March 31, 2014 [Page 4]
Internet-Draft MN IP reachablility for the DMM September 2013
2) There still needs a way (out scope of this draft) for CN3 to
acquire MN ID and DDNS server address.
+------------+____Req_____+----+
|DDNS Server |____Res_____|CN3 |
+-----+------+ +--+-+
/\ |
/ \ |
+----+ / \ +----+ |
|CN1 | / \ |CN2 | |
+--+-+ / \ +--+-+ |
IP1| / \ |IP2 |
| / \ | to IPx
+--++-+ IP1 ++--+-+
| MR1 +-----------+ MR2 |
+--+--+ ++----+
| | |
IP1| IP1| | IP2
| | |
+-+--+ move +--+-+
|MN1 | ---------- |MN1 |
+----+ +----+
Figure 2: MN's IP reachability with DDNS server
4.2. Solution2: Server Registeration
In this solution, for some special service, e.g., MSN Messenger, MN1
and CN3 both register their IP addresses and posts info to the same
server, after attaching to new MR, they register their new IP
addresses and ports info to server again. There are three mode for
CN to initial a new IP session with MN, which is including P2P
mode[RFC5694], Server central mode and Combined mode.
4.2.1. P2P mode
At the beginning, CN3 registered its new IP address to Server. When
CN3 initials a new IP session with MN1, firstly, CN3 sends "service
request to MN1" message to server, and server retures MN1's latest IP
address and port info to CN3, CN3 directly initials to setup the new
IP session with MN1 using the returing info above, as described in
Fig3.
Xiong & Liu Expires March 31, 2014 [Page 5]
Internet-Draft MN IP reachablility for the DMM September 2013
When MN1 attaches to a new MR, and updates the server with a new IP
address, the established IP session between MN1 and CN3 is unaffected
and IP session continuity is kept. The CN3 does not need to cache
MN1 IP address, since if CN3 initials a new IP session with MN1
again, the server will provide MN1's latest IP address and port info
to CN3 by sending the "Service Request to MN1" message to server.
+------------+____Req_____+----+
| Server |____Res_____|CN3 |
+-----+------+ +--+-+
/\ |
/ \ |
+----+ / \ +----+ |
|CN1 | / \ |CN2 | |
+--+-+ / \ +--+-+ |
IP1| / \ |IP2 |
| / \ | to IPx
+--++-+ IP1 ++--+-+
| MR1 +-----------+ MR2 |
+--+--+ ++--+-+
| | |
IP1| IP1| | IP2
| | |
+-+--+ move +--+-+
|MN1 | ---------- |MN1 |
+----+ +----+
Figure 3: MN's reachability with Server Registeration by P2P mode
4.2.2. Server Central mode
At the beginning, CN3 registered its new IP address and port info to
Server. When CN3 initials a new IP session with MN1, as described in
Fig4, firstly, CN3 sends "service request to MN1" message to server,
and then, server sends "service request from CN3" message to MN1.
After that CN3 initial to setup the path "CN3 --- Server --- MN1" for
user and control plane.
In this mode, MN1 can use another IP address to setup the user plane,
in this case the MN1 does not need to immediately update the server
with new IP address . In this way, the session continuity is kept but
the servicer (e.g. IMS ) must supports two user plane.
Xiong & Liu Expires March 31, 2014 [Page 6]
Internet-Draft MN IP reachablility for the DMM September 2013
+------------+____Req1____+----+
| Server | |CN3 |
+-----+------+ +--+-+
/\ \
/ \ \
+----+ / \ \Req2 +----+
|CN1 | / \ \ |CN2 |
+--+-+ / \ \ +-+--+
IP1| / \ \ /IP2
| / \ \ /
+--++-+ IP1 +--+-++
| MR1 +-----------+ MR2 |
+--+--+ ++-+-++
| | | IP2
IP1| IP1| | |
| |Req2
+-+--+ move +-+-++
|MN1 | ---------- |MN1 |
+----+ +----+
Figure 4: MN's reachability with Server Registeration by Server
central mode
4.2.3. Combined mode
Combined mode: combining P2P mode and Server Central mode.
In this mode, for control plane, CN3 sends "service request to MN1"
message to server, and server sends "service request from MN1"
message to MN1, the server is in the path of the signaling path
between the CN3 and MN1, as described in Fig5. For data plane, MN1
responses the request from server with MN1's latest IP address and
port info, and the server retures the info to CN3, and CN3 directly
initial to setup new IP session between CN3 and MN1 with the returing
info above.
+------------+____Req1____+----+
| Server | |CN3 |
+-----+------+ +--+-+
/ \ |
/ \ |
+----+ / \Req2 +----+ |
|CN1 | / \ |CN2 | |
+--+-+ / \ +-+--+ |
Xiong & Liu Expires March 31, 2014 [Page 7]
Internet-Draft MN IP reachablility for the DMM September 2013
IP1| / \ / |
| / \ /IP2 to IPx
+--++-+ IP1 +-+--++
| MR1 +-----------+ MR2 |
+--+--+ ++-+-++
| | | |IP2
IP1| IP1| | |
| |Req2
+-+--+ move +-+-++
|MN1 | ---------- |MN1 |
+----+ +----+
Figure 5: MN's reachability with Server Registeration by Combined
mode
5. Security Considerations
TBD.
6. IANA Considerations
This document needs a mechanism to allocate permanent GUID for a MN
decribed in Section 4.1, which is to be made through IANA Expert
Review.
7. Acknowledgments
Thanks to my colleagues for their sincerely help and comments when
drafting this document.
8. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., 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.
Xiong & Liu Expires March 31, 2014 [Page 8]
Internet-Draft MN IP reachablility for the DMM September 2013
[RFC5694] Camarillo, G. IAB, "Peer-to-Peer (P2P) Architecture:
Definition, Taxonomies, Examples, and Applicability", RFC
5694, November 2009.
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 March 31, 2014 [Page 9]