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]