Network Working Group V.Liu Internet Draft H.Deng Intended status: Standards Track China Mobile Expires: Nov 15, 2015 D.Liu Alibaba X.Wei Huawei J.Liu ZTE July 6, 2015 Address Selection for DMM draft-liu-dmm-address-selection-02 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 November 6, 2015. Copyright Notice Copyright (c) 2015 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. Liu, et al. Expires Nov 15, 2015 [Page 1] Internet-Draft liu-dmm-address-selection July 2015 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. Abstract In DMM scenario, it is possible for the MN to use multiple mobility anchor points and corresponding prefixes. In that case, MN needs to know the property of the addresses then it can select the optimized one for application to use. This document defines new IP network prefix types to assist address selection for applications. Table of Contents 1. Introduction ................................................ 2 2. Definition of New Prefix Types ............................... 3 3. Mobile Node Operation ........................................ 3 4. An Example of How This Draft Works ........................... 3 4.1. MN Handoffs From MAR to a Next MAR ...................... 3 4.2. MN Handoffs From MAR Back to Its Previous MAR ........... 5 5. Security Considerations ...................................... 6 6. IANA Considerations ......................................... 6 7. References .................................................. 6 7.1. Normative References .................................... 6 7.2. Informative References .................................. 6 1. Introduction In DMM scenario, mobility anchors would be deployed in a distributed manner, and as specified in RFC7333 [RFC7333], one of the aims of DMM is to reduce the routing redundancy between mobile node and correspondent node, which means providing a more optimal communication path for application traffic between mobile node and correspondent node. To achieve routing optimization for specific application traffic, the basic idea is to make the traffic using IP address(s) anchored at current anchor, so that downlink traffic from correspondent node to mobile node will go directly to mobile node. Different application sessions could require different IP address consistency support from network layer, for example, if the application layer cannot bear the IP address to be changed during the session, then the IP address for the session should be kept unchanged; but if the application layer could provide mechanism to deal with IP Liu, et al. Expires Nov 15, 2015 [Page 2] Internet-Draft liu-dmm-address-selection July 2015 address change, then the application could choose select a new optimal address during the session, to get reduce routing redundancy. This document defines new IP network prefix types to assist address selection for applications. 2. Definition of New Prefix Types Two types of IP network prefix are defined in this section. The extension of specific protocol to convey the defined new types of IP network prefix to MN is out of scope of this document. Local home network prefix. It means that this prefix is allocated and advertised by current router which the MN attaches to. Remote home network prefix. It means that this prefix is allocated by another router instead of the router that the MN currently attaches to. 3. Mobile Node Operation This section describes how the applications on the mobile node could select the optimal IP address based on different types of prefixes. For example, for on-going session, application always choose to use the prefix that it used before it handovers to a new location. For the newly initiate application, it will use the prefix that allocated by current router, e.g. local home network prefix. The mobile node can use advanced socket API to select the proper prefix, for example, extension to RFC 5014.The detail mechanism is out the scope of this document. 4. An Example of How This Draft Works This section describes how the prefix types defined above solves the source address selection. Two different use cases are presented below. We assume a new Type flag "T" in Prefix Information option is used to indicate the new defined prefix type. 4.1. MN Handoffs From MAR to a Next MAR Liu, et al. Expires Nov 15, 2015 [Page 3] Internet-Draft liu-dmm-address-selection July 2015 _______ _______ _______ | | | | | | | CN1 | | CN2 | | CN3 | |_______| |_______| |_______| ' . . Flow#1 ' Flow#2 . | Flow#3 ' ...'''''.'''''''.... . ..''' . '''.. .' ' IP network . '. : ' . | : '..' +-------+ . ..' '''... | |.......''' ' | MAR2 | \ . ' | |. \ | ' | | . \ . ' +-------+\ .\ | +-------+ HNP2(L) \ + ------+ | | HNP1(R) \ | | HNP3(L) | MAR1 |-----------------| MAR3 | HNP2(R) | | ''''''''''''''''| | HNP1(R) | |-----------------| | +-------+ +-------+ HNP1(L) ' . | Flow#1 ' . . Flow#3 ' . | +-----+ Flow#2 +-----+ | MN | -----move-------> | MN | +-----+ +-----+ Liu, et al. Expires Nov 15, 2015 [Page 4] Internet-Draft liu-dmm-address-selection July 2015 T=L: Local home network prefix using common IP forwarding and routing mechanisms T=R: Remote home network prefix using mobility anchoring and tunneling to maintain communications Figure 1: Source address selection in DMM As shown in figure1, flow#1, flow#2 and flow#3 are initiated and anchored at MAR1, MAR2 and MAR3 respectively. When MN attaches to MAR1, MAR1 sends Router Advertisement messages(RA) containing MN's home network prefix(HNP1) in Prefix Information option with T=L. This indicates that HNP1 is local home network prefix which is allocated and advertised by current router(MAR1). MN can initiate a session with CN1 (i.e. flow#1 in figure1) by using IPv6 addresses derived from HNP1. Common IPv6 routing mechanism will be applied for flow#1 as long as MN remains attached to MAR1. When MN handoffs to MAR2(flow#1 continues while MN handoffs), MAR2 sends RA messages containing MN's new prefix(HNP2) in Prefix Information option with T=L together with old prefix (i.e. HNP1) with T=R. MN will learn that HNP2 is local home network prefix and HNP1 is remote home network prefix. At this moment, MN can initiate a new sessions with CN2 (i.e. flow#2 in the figure1) by using IPv6 addresses derived from HNP2 as its source address. Because this IPv6 address is derived from a local home network prefix (i.e. HNP2), common IPv6 routing mechanism will be applied for flow#2. For flow#1, MAR1 plays role of LMA and MAR2 plays role of MAG. When MN handoffs to MAR3(flow#1 and flow#2 continue while MN handoffs), MAR3 sends RA messages containing MN's new prefix(HNP3) and previous prefixes (HNP1 and HNP2) in Prefix Information option with T=L for HNP3 and T=R for HNP1 and HNP2. This indicates HNP3 is local home network prefix, and HNP1 and HNP2 are remote home network prefixes. At this moment, MN can initiates new sessions with CN3 (i.e. flow#3 in figure1) by using IPv6 addresses derived from HNP3 as its source address. And Common IPv6 routing mechanism will be applied for flow#3. 4.2. MN Handoffs From MAR Back to Its Previous MAR MN could also handoff back from MAR3 to MAR2 again (assuming flow#1, flow#2 and flow#3 continue while MN handoffs). In this case, as described above, MAR2 will send RA messages containing HNP1, HNP2 and HNP3 in Prefix Information option with T=L Liu, et al. Expires Nov 15, 2015 [Page 5] Internet-Draft liu-dmm-address-selection July 2015 for HNP2 and T=R for HNP1 and HNP3. This indicates HNP2 is local home network prefix; HNP1 and HNP3 are remote home network prefixes. Assuming that MN initiates a new sessions with a new communication node (e.g. with CN4 which is not shown in figure1) by using IPv6 addresses derived from HNP2 as its source address. Because this IPv6 address is derived from a local home network prefix (i.e. HNP2), common IPv6 routing mechanism will be applied for this session. 5. Security Considerations TBD 6. IANA Considerations This document makes no request of IANA. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 7.2. Informative References [3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 1583. [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-1583. [I-D.draft-seite-dmm-dma-00] Seite, P. and P. Bertin, "Distributed Mobility Anchoring,draft-seite-dmm-dma-00", February 2012. Liu, et al. Expires Nov 15, 2015 [Page 6] Internet-Draft liu-dmm-address-selection July 2015 Authors' Addresses Vic Liu China Mobile 32 Xuanwumen West AVE, Xicheng, Beijing Email: liuzhiheng@chinamobile.com Hui Deng China Mobile 32 Xuanwumen West AVE, Xicheng, Beijing Email: denglingli@chinamobile.com Dapeng Liu Alibaba Email: max@dotalks.com Xinpeng Wei Huawei Email: Weixinpeng@huawei.com Juan Liu ZTE No.68, Zijinhua RD,Yuhuatai District,Nanjing Email: liu.juan45@zte.com.cn Liu, et al. Expires Nov 15, 2015 [Page 7]