idnits 2.17.1 draft-jaehwoon-dmm-pmipv6-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 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 == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (June 18, 2015) is 3235 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) == Outdated reference: A later version (-17) exists of draft-ietf-dmm-requirements-03 ** Obsolete normative reference: RFC 3315 (ref. '7') (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DMM Working Group Jaehwoon Lee 2 Internet-Draft Dongguk University 3 Intended status: Informational Younghan Kim 4 Expires: December 17, 2015 Soongsil University 5 June 18, 2015 7 PMIPv6-based Distributed Mobility Management 8 draft-jaehwoon-dmm-pmipv6-04 10 Abstract 12 Proxy Mobile IPv6 (PMIPv6) is the network-based mobility management 13 protocol where access network supports the mobility of a mobile node 14 on behalf of the MN. In PMIPv6, the location information of the MN 15 should be registered to Localized Mobility Anchor and communication 16 must be established via the LMA. Therefore, the performance can be 17 degraded due to traffic concentration and congestion possibility. 18 One method to overcome the above problems is to exploit the 19 distributed mobility management (DMM) mechanism to distribute the 20 LMA function to all access routers within the PMIPv6 domain. This 21 document presents a fully distributed mobility management mechanism 22 in PMIPv6-based network. In this mechanism, there is no need for 23 the location management function to register the location of the MN. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 17, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 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 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction.................................................3 60 2. Conventions and Terminology..................................3 61 2.1. Conventions used in this document........................3 62 2.2. Terminology ............................................3 63 3. Protocol Operation...........................................3 64 4. Security Considerations......................................7 65 5. IANA Considerations..........................................7 66 6. References....................................................7 67 Author's Address.................................................7 69 1. Introduction 71 Centralized mobility management protocols such as MIPv6 [1] and 72 PMIPv6 [2] have several problems such as single-node failure, 73 congestion possibility, scalability issues and non-optimal 74 routes [3]. One method to resolve such problems is to use the 75 distributed mobility management (DMM) mechanism to distribute mobile 76 agent function to access routers [4]. Especially, in PMIPv6-based 77 DMM, when an MN moves one network to another, a new access router 78 that the MN moves and connects should know (1) whether the MN firstly 79 enters the PMIPv6 domain and (2) the address information of the LMA 80 for the MN when the access router knows that the MN moves from 81 another network. 83 This document presents a fully distributed mobility management 84 mechanism which does not need the control function for managing 85 MN-LMA address binding information. 87 2. Conventions and Terminology 89 2.1. Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [5]. 95 2.2 Terminology 97 TBD. 99 3. Protocol Operation 101 Figure 1 shows the message exchange procedure between network 102 entities to provide fully distributed mobility management in PMIPv6 103 environment presented in this document. A network prefix "PREF" is 104 allocated to the PMIPv6 domain. However, a different sub-network 105 prefix belonging to the same network prefix "PREF" is allocated to 106 a different mobility access gateway (MAG) in PMIPv6 domain. 107 For example, a sub-network prefix "PREF1" belonging to "PREF" is 108 allocated to MAG1 and a different sub-network prefix "PREF2" 109 belonging to the same "PREF" is allocated to MAG2. Even though a 110 different sub-network prefix is allocated to a different MAG, all 111 MAGs advertise the same network prefix "PREF" through the interfaces 112 providing PMIPv6 service. 114 MN MAG1 MAG2 MAG3 CN 115 | | | | | 116 |*** L2 attachment ***>| | | | 117 |<----- RA(PREF) ------| | | | 118 |---DHCP request msg-->| | | | 119 |<--DHCP reponse msg---| | | | 120 | (MN's address) | | | | 121 (Configure IPv6 address) | | | | 122 |<-------------------- exchange IP traffic ------------------->| 123 (Move from MAG1 to MAG2) | | | | 124 |************ L2 attachment **************>| | | 125 |<-------------- RA(PREF) -----------------| | | 126 |--------------- IP packet --------------->| | | 127 | | (packet buffering) | | 128 | |<----DPBU msg------| | | 129 | (create BCE and est. tunnel) | | | 130 | |-----DPBA msg----->| | | 131 | | (create BUL and est. tunnel)| | 132 | |<====IP packet=====| | | 133 | |--------------- IP packet ------------>| 134 (Move from MAG2 to MAG3) | | | | 135 | | (packet buffering) | | 136 | |<----DPBRU msg-----| | | 137 | |----DPBRA msg----->| | | 138 |****************** L2 attachment ******************>| | 139 |<------------------- RA (PREF) ---------------------| | 140 |------------------- IP pkt ------------------------>| | 141 | | (pkt bufferring) | 142 | |<-- exchange DPBU/DPBA msg ->| | 143 | |<========= IP packet ========| | 144 | |-------------- IP packet ------------->| 146 (a) MN to CN packet transmission scenario 148 MN MAG1 MAG2 MAG3 CN 149 | | | | | 150 |*** L2 attachment ***>| | | | 151 |<----- RA(PREF) ------| | | | 152 |---DHCP request msg-->| | | | 153 |<--DHCP reponse msg---| | | | 154 | (MN's address) | | | | 155 (Configure IPv6 address) | | | | 156 |<-------------------- exchange IP traffic ------------------->| 157 (Move from MAG1 to MAG2) | | | | 158 | |<----------- IP packet ----------------| 159 | (packet buffering) | | | 160 |************ L2 attachment **************>| | | 161 |<-------------- RA(PREF) -----------------| | | 162 | |<----DPBU msg------| | | 163 | (create BCE and est. tunnel) | | | 164 | |-----DPBA msg----->| | | 165 | | (create BUL and est. tunnel)| | 166 | |=====IP packet====>| | | 167 |<--------------- IP packet ---------------| | | 168 (Move from MAG2 to MAG3) | | | | 169 | | (packet buffering) | | 170 | |<----DPBRU msg-----| | | 171 | |<= Buffered IP pkt=| | | 172 | (packet bufffering) | | | 173 | |<--- FLUSH msg ----| | | 174 | |----DPBRA msg----->| | | 175 |****************** L2 attachment ******************>| | 176 |<------------------- RA (PREF) ---------------------| | 177 | |<-- exchange DPBU/DPBA msg ->| | 178 | |==== buffered IP packet ====>| | 179 | |====== IP packet ===========>| | 180 |<----------------- IP packet -----------------------| | 182 (b) CN to MN packet transmission scenario 184 Figure 1: Message exchange scenario 186 When an MN firstly enters the PMIPv6 domain and connects to a MAG 187 (say, MAG1), MAG1 transmits to the MN a Router Advertisement (RA) 188 message by setting "M (Managed address configuration)" flag in 189 order to configure an address to the MN by using the stateful 190 address configuration method [6]. The network prefix "PREF" is set 191 to the prefix option information field in the RA message. The MN 192 having received the RA message transmits the dynamic host 193 configuration protocol (DHCP) request message to the MAG1 [7]. The 194 MAG1 considers that the MN firstly connects to the PMIPv6 domain and 195 transmits the DHCP response message containing an address belonging 196 to the "PREF1" to the MN. The MN sets the address contained in the 197 DHCP response message to its interface. After that, the MN can 198 communicate to a CN within the Internet. 200 When the MN moves MAG1 to MAG2 while communicating with a CN, the 201 MAG1 begins to perform the LMA function for the MN and stores 202 packets sent from the CN into the buffer. The MAG1 stores the MM's 203 information into its Binding Cache Entry (BCE). When the MN connects 204 to MAG2, the MAG2 transmits the RA message containing network prefix 205 set to "PREF" to the MN. The MN having received the RA message 206 considers that it connects to the same network by using the "PREF" 207 network prefix in prefix information option of RA message. It 208 continues to use the address configured previously and transmits IP 209 packets as usual. MAG2 checks the first packet transmitted by the MN. 210 If the first packet contains the DHCP request packet, then MAG2 211 considers that the MN firstly connects to the PMIPv6 domain. 212 Otherwise, MAG2 considers that the MN moves from another MAG area and 213 creates the Binding Update List (BUL) for the MN. And then, MAG2 214 transmits the Distributed Proxy Binding Update (DPBU) message. The 215 source address of the packet containing the DPBU message is set to 216 the address of the MAG2 (say, Proxy-CoA2) and the destination address 217 is set to the address of the MN. Here, MAG2 can know the address of 218 the MN by using the source address of the IP packet sent by the MN. 219 Moreover, MAG2 stores packets sent by the MN. DPBU message is 220 transmitted to the MAG1 through the Internet topologically correct 221 routing path. MAG1 having received the DPBU message stores the 222 Proxy-CoA2 address to its BCE for the MN, establishes the tunnel with 223 MAG2, and transmits the Distributed Proxy Binding Acknowledgement 224 (DPBA) message to MAG2. The source and destination addresses of the 225 packet containing the DPBA message are set to the address of MAG1 226 (say, Proxy-CoA1) and Proxy-CoA2, respectively. The DPBA message 227 contains the address of the MN in its option field. MAG2 receiving 228 the PBA message stores the Proxy-CoA1 address to its BUL and 229 establishes the tunnel with MAG1. And then, MAG1 transmits the 230 packets stored in the buffer to MAG2, and MAG2 would the received 231 packets to the MN. After that, the MN continues to communicate with 232 the CN. 234 Packets sent from MAG1 to MAG2 might be lost if the MN moves from 235 MAG2 to another MAG (MAG3 for example in this draft). It is because 236 MAG1 cannot know the fact that the MN moves and connects to MAG3. 237 In order to avoid the packet loss, When MAG2 knows to disconnect to 238 the MN, MAG2 transmits the Distributed Proxy Binding Release Update 239 (DPBRU) message to MAG1. Moreover, MAG2 transmits packets for the MN 240 to MAG1 again. When MAG1 receives the DPBRU message, MAG1 transmits 241 FLUSH message to the MAG2 and stores packets sent from the CN in its 242 buffer. MAG2 having received the FLUSH message considers that the 243 message is the final packet sent from the MAG1 and retransmits the 244 FLUSH message. And then, MAG2 removes the entry related the MN in the 245 BUL. MAG1 having received the FLUSH message having sent from MAG2 246 considers that themessage is the final packet sent from MAG2. MAG1 247 transmits the Distributed Proxy Binding Release Acknowledgement 248 (DPBRA) message to MAG2. When MAG1 receives the DPBU message from 249 MAG3, MAG1 transmits the DPBA message to MAG3, update its BCE related 250 to the MN, transmits the stored packets sent from MAG2, and then 251 transmits packets sent from the CN. 253 4. Security Considerations 255 TBD 257 5. IANA Considerations 259 TBD 261 6. References 263 [1] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in 264 IPv6", IETF RFC 3775, June 2004. 266 [2] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and 267 B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, Aug. 2008. 269 [3] H. Chan, D. Liu, P. Seite, H. Yokota and J. Korhonen, 270 "Requirements for Distributed Mobility Management", 271 draft-ietf-dmm-requirements-03 (work in progress), Dec. 2012. 273 [4] IETF dmm working group, 274 http://datatracker.ietf.org/wg/dmm/charter. 276 [5] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [6] T. Narten, E. Nordmark, W. Sompson and H. Soliman, "Neighbor 280 Discovery for IP version 6 (IPv6), IETF RFC 4861, Sep. 2007. 282 [7] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney, 283 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 284 IETF RFC 3315, July 2003. 286 Author's Address 288 Jaehwoon Lee 289 Dongguk University 290 26, 3-ga Pil-dong, Chung-gu 291 Seoul 100-715, KOREA 292 Email: jaehwoon@dongguk.edu 293 Younghan Kim 294 Soongsil University 295 369, Sangdo-ro, Dongjak-gu, 296 Seoul 156-743, Korea 297 Email: younghak@ssu.ac.kr