idnits 2.17.1 draft-liu-dmm-address-selection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 42 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 192 has weird spacing: '... option with ...' -- The document date (July 6, 2015) is 3189 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC7333' is mentioned on line 79, but not defined == Unused Reference: '1' is defined on line 228, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 231, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 235, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 238, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'Fab1999' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-seite-dmm-dma-00' is defined on line 252, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) == Outdated reference: A later version (-07) exists of draft-seite-dmm-dma-00 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group V.Liu 2 Internet Draft H.Deng 3 Intended status: Standards Track China Mobile 4 Expires: Nov 15, 2015 D.Liu 5 Alibaba 6 X.Wei 7 Huawei 8 J.Liu 9 ZTE 10 July 6, 2015 12 Address Selection for DMM 13 draft-liu-dmm-address-selection-02 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on November 6, 2015. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents carefully, 41 as they describe your rights and restrictions with respect to this 42 document. Code Components extracted from this document must include 43 Simplified BSD License text as described in Section 4.e of the Trust 44 Legal Provisions and are provided without warranty as described in 45 the Simplified BSD License. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents carefully, 51 as they describe your rights and restrictions with respect to this 52 document. 54 Abstract 56 In DMM scenario, it is possible for the MN to use multiple mobility 57 anchor points and corresponding prefixes. In that case, MN needs to 58 know the property of the addresses then it can select the optimized 59 one for application to use. This document defines new IP network 60 prefix types to assist address selection for applications. 62 Table of Contents 64 1. Introduction ................................................ 2 65 2. Definition of New Prefix Types ............................... 3 66 3. Mobile Node Operation ........................................ 3 67 4. An Example of How This Draft Works ........................... 3 68 4.1. MN Handoffs From MAR to a Next MAR ...................... 3 69 4.2. MN Handoffs From MAR Back to Its Previous MAR ........... 5 70 5. Security Considerations ...................................... 6 71 6. IANA Considerations ......................................... 6 72 7. References .................................................. 6 73 7.1. Normative References .................................... 6 74 7.2. Informative References .................................. 6 76 1. Introduction 78 In DMM scenario, mobility anchors would be deployed in a distributed 79 manner, and as specified in RFC7333 [RFC7333], one of the aims of DMM 80 is to reduce the routing redundancy between mobile node and 81 correspondent node, which means providing a more optimal 82 communication path for application traffic between mobile node and 83 correspondent node. To achieve routing optimization for specific 84 application traffic, the basic idea is to make the traffic using IP 85 address(s) anchored at current anchor, so that downlink traffic from 86 correspondent node to mobile node will go directly to mobile node. 88 Different application sessions could require different IP address 89 consistency support from network layer, for example, if the 90 application layer cannot bear the IP address to be changed during the 91 session, then the IP address for the session should be kept unchanged; 92 but if the application layer could provide mechanism to deal with IP 93 address change, then the application could choose select a new 94 optimal address during the session, to get reduce routing redundancy. 96 This document defines new IP network prefix types to assist address 97 selection for applications. 99 2. Definition of New Prefix Types 101 Two types of IP network prefix are defined in this section. The 102 extension of specific protocol to convey the defined new types of IP 103 network prefix to MN is out of scope of this document. 105 Local home network prefix. It means that this prefix is allocated 106 and advertised by current router which the MN attaches to. Remote 107 home network prefix. It means that this prefix is allocated by 108 another router instead of the router that the MN currently attaches 109 to. 111 3. Mobile Node Operation 113 This section describes how the applications on the mobile node could 114 select the optimal IP address based on different types of prefixes. 115 For example, for on-going session, application always choose to use 116 the prefix that it used before it handovers to a new location. For 117 the newly initiate application, it will use the prefix that allocated 118 by current router, e.g. local home network prefix. The mobile node 119 can use advanced socket API to select the proper prefix, for example, 120 extension to RFC 5014.The detail mechanism is out the scope of this 121 document. 123 4. An Example of How This Draft Works 125 This section describes how the prefix types defined above solves the 126 source address selection. Two different use cases are presented below. 127 We assume a new Type flag "T" in Prefix Information option is used to 128 indicate the new defined prefix type. 130 4.1. MN Handoffs From MAR to a Next MAR 131 _______ _______ _______ 132 | | | | | | 133 | CN1 | | CN2 | | CN3 | 134 |_______| |_______| |_______| 135 ' . . 136 Flow#1 ' Flow#2 . | Flow#3 137 ' ...'''''.'''''''.... . 138 ..''' . '''.. 139 .' ' IP network . '. 140 : ' . | : 141 '..' +-------+ . ..' 142 '''... | |.......''' 143 ' | MAR2 | \ . 144 ' | |. \ | 145 ' | | . \ . 146 ' +-------+\ .\ | 147 +-------+ HNP2(L) \ + ------+ 148 | | HNP1(R) \ | | HNP3(L) 149 | MAR1 |-----------------| MAR3 | HNP2(R) 150 | | ''''''''''''''''| | HNP1(R) 151 | |-----------------| | 152 +-------+ +-------+ 153 HNP1(L) ' . | 154 Flow#1 ' . . Flow#3 155 ' . | 156 +-----+ Flow#2 +-----+ 157 | MN | -----move-------> | MN | 158 +-----+ +-----+ 160 T=L: Local home network prefix using common IP forwarding and routing 161 mechanisms 163 T=R: Remote home network prefix using mobility anchoring and 164 tunneling to maintain communications 166 Figure 1: Source address selection in DMM 168 As shown in figure1, flow#1, flow#2 and flow#3 are initiated and 169 anchored at MAR1, MAR2 and MAR3 respectively. 171 When MN attaches to MAR1, MAR1 sends Router Advertisement 172 messages(RA) containing MN's home network prefix(HNP1) in Prefix 173 Information option with T=L. This indicates that HNP1 is local home 174 network prefix which is allocated and advertised by current 175 router(MAR1). MN can initiate a session with CN1 (i.e. flow#1 in 176 figure1) by using IPv6 addresses derived from HNP1. Common IPv6 177 routing mechanism will be applied for flow#1 as long as MN remains 178 attached to MAR1. 180 When MN handoffs to MAR2(flow#1 continues while MN handoffs), MAR2 181 sends RA messages containing MN's new prefix(HNP2) in Prefix 182 Information option with T=L together with old prefix (i.e. HNP1) with 183 T=R. MN will learn that HNP2 is local home network prefix and HNP1 is 184 remote home network prefix. At this moment, MN can initiate a new 185 sessions with CN2 (i.e. flow#2 in the figure1) by using IPv6 186 addresses derived from HNP2 as its source address. Because this IPv6 187 address is derived from a local home network prefix (i.e. HNP2), 188 common IPv6 routing mechanism will be applied for flow#2. For flow#1, 189 MAR1 plays role of LMA and MAR2 plays role of MAG. When MN handoffs 190 to MAR3(flow#1 and flow#2 continue while MN handoffs), MAR3 sends 191 RA messages containing MN's new prefix(HNP3) and previous prefixes 192 (HNP1 and HNP2) in Prefix Information option with T=L for HNP3 and 193 T=R for HNP1 and HNP2. This indicates HNP3 is local home network 194 prefix, and HNP1 and HNP2 are remote home network prefixes. At this 195 moment, MN can initiates new sessions with CN3 (i.e. flow#3 in 196 figure1) by using IPv6 addresses derived from HNP3 as its source 197 address. And Common IPv6 routing mechanism will be applied for 198 flow#3. 200 4.2. MN Handoffs From MAR Back to Its Previous MAR 202 MN could also handoff back from MAR3 to MAR2 again (assuming flow#1, 203 flow#2 and flow#3 continue while MN handoffs). 205 In this case, as described above, MAR2 will send RA messages 206 containing HNP1, HNP2 and HNP3 in Prefix Information option with T=L 207 for HNP2 and T=R for HNP1 and HNP3. This indicates HNP2 is local home 208 network prefix; HNP1 and HNP3 are remote home network prefixes. 210 Assuming that MN initiates a new sessions with a new communication 211 node (e.g. with CN4 which is not shown in figure1) by using IPv6 212 addresses derived from HNP2 as its source address. Because this IPv6 213 address is derived from a local home network prefix (i.e. HNP2), 214 common IPv6 routing mechanism will be applied for this session. 216 5. Security Considerations 218 TBD 220 6. IANA Considerations 222 This document makes no request of IANA. 224 7. References 226 7.1. Normative References 228 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 229 Levels", BCP 14, RFC 2119, March 1997. 231 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 232 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 233 Demon Internet Ltd., November 1997. 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 239 Syntax Specifications: ABNF", RFC 2234, Internet Mail 240 Consortium and Demon Internet Ltd., November 1997. 242 7.2. Informative References 244 [3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP 245 and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 246 1583. 248 [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in 249 TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 250 1573-1583. 252 [I-D.draft-seite-dmm-dma-00] Seite, P. and P. Bertin, "Distributed 253 Mobility Anchoring,draft-seite-dmm-dma-00", February 2012. 255 Authors' Addresses 257 Vic Liu 258 China Mobile 259 32 Xuanwumen West AVE, Xicheng, Beijing 260 Email: liuzhiheng@chinamobile.com 262 Hui Deng 263 China Mobile 264 32 Xuanwumen West AVE, Xicheng, Beijing 265 Email: denglingli@chinamobile.com 267 Dapeng Liu 268 Alibaba 270 Email: max@dotalks.com 272 Xinpeng Wei 273 Huawei 275 Email: Weixinpeng@huawei.com 277 Juan Liu 278 ZTE 279 No.68, Zijinhua RD,Yuhuatai District,Nanjing 280 Email: liu.juan45@zte.com.cn