idnits 2.17.1 draft-cui-netext-pmipv6-shpmipv6-00.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 abstract seems to contain references ([RFC5213], [RFC5949]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 2, 2012) is 4223 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) == Outdated reference: A later version (-18) exists of draft-ietf-netext-pmipv6-flowmob-04 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft Tsinghua University 4 Intended status: Standards Track X. Xu 5 Expires: April 5, 2013 WD. Wang 6 XM. Li 7 Beijing University of Posts and 8 Telecommunications 9 YZ. Huo 10 W. Luo 11 ZTE Corporation 12 October 2, 2012 14 Seamless Handover for Multiple-Access Mobile Node in PMIPv6 15 draft-cui-netext-pmipv6-shpmipv6-00 17 Abstract 19 Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provide a mobile 20 node(MN) which requires no additional modification to MN with IP 21 mobility. Fast Handover for Proxy Mobile IPv6 (FHPMIPv6), specified 22 in[RFC5949], proposed two modes of fast handover, both of them use 23 single interface to transmate packets during handover, which requires 24 it to buffer packets in MAGs when interface performs handover. 25 Buffer packets in MAGs result in additional overhead, and increase 26 packets transmission delay. Unlike FHPMIPv6, this document proposed 27 a seamless handover scheme for multi-access mobile node with IP 28 mobility when one of MN's network interface performs handover from 29 one MAG to another. This scheme uses some other interface of the 30 multi-access mobile node to help process packets while handovering. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 5, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 4 70 4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 5 71 4.2. Mobile Node considerations . . . . . . . . . . . . . . . . 7 72 4.3. Mobile Access Gateway considerations . . . . . . . . . . . 7 73 4.4. Local Mobility Anchor considerations . . . . . . . . . . . 8 74 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 75 5.1. Streamless Handover Initiate (SHI) message . . . . . . . . 8 76 5.2. Streamless Handover Acknowledge (SHAck) message . . . . . 9 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 With the development of internet access technologies and mobile 84 terminal equipment, more and more hosts are operating in multiple- 85 interfaces, thus a terminal having access to multiple heterogeneous 86 network domain simultaneously has become possible. Proxy Mobile IPv6 87 is a network-based mobility protocol, it provids mobility support for 88 mobile node and requires no additional modification. 90 RFC 5949 FHPMIPv6 is a fast handover extension for PMIPv6, the 91 document proposed two modes of fast handover: reactive mode and 92 predictive mode. The main idea of the two modes of operations is to 93 establish a bi-directional tunnel between the Previous Mobile Access 94 Gateway (PMAG) and the New Mobile Access Gateway (NMAG). So, packets 95 destined for the Mobile Node are forward from the PMAG to the NMAG 96 over this tunnel. Both of the two modes of fast handover improve the 97 handover performance in terms of packet loss and latency, while none 98 of them takes full advantage of multi-access features of the mobile 99 node, as in both of the two handover modes, packets transmission on 100 the handover interface should be buffered at the PMAG or NMAG which 101 increases the requirement of storage volume forthe MAG. When there 102 are many MNs are handovering within the coverage area of the same 103 MAG, some packets may be lost due to cache insufficiency. The two 104 modes adopt cached and forwarded to deal with the packet while 105 handover will greatly increase the transmission delay, that may be 106 deadlly to delay-sensitive applications. 108 This document propose a seamless handover scheme for multiple-access 109 mobile node in PMIPv6, compared with the two kinds of handover modes 110 mentioned above.This seamless handover scheme doesn't need to buffer 111 the packets in MAG, which reduces the requirements on the MAG cache, 112 while reducing the transmission delay at the same time. 114 2. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Terminology 122 The following terminologys used in this document are define in 123 RFC5213: 125 Local Mobility Anchor (LMA). 127 Mobile Access Gateway (MAG). 129 Proxy Mobile IPv6 Domain (PMIPv6-Domain). 131 The following terminologys used in this document are define in 132 RFC5949: 134 Previous Mobile Access Gateway (PMAG). 136 New Mobile Access Gateway (NMAG). 138 The following terminologys are define and used in this document: 140 Stable Mobile Access Gateway (SMAG) 142 while one of MN's interface is handovering, The MAGs that connect 143 with some other interface of MN are called SMAG. 145 4. Protocol overview 147 +----------+ 148 | LMA | 149 +----------+ 150 | 151 | 152 +-----------+ 153 | Router | 154 +-----------+ 155 / | \ 156 / | \ 157 / | \ 158 / | \ 159 / | \ 160 +-----------+ +-----------+ +-----------+ 161 | PMAG | | SMAG | | NMAG | 162 +-----------+ +-----------+ +-----------+ 163 \ / \ / 164 \ / \ / 165 \ / \ / 166 \ / \ / 167 IF1 | | IF2 IF2 | | IF1 168 +-----------+ +-----------+ 169 | MN |---->| MN | 170 +-----------+ +-----------+ 172 Figure 1 reference network for Multiple-Access Mobile Node handover 174 In order to alleviate the packet loss during handover, RFC5949 175 propsoed two kinds of fast handover schemes. In both of the two 176 handover scheme, the downlink packets need to be buffered either at 177 the PMAG or NMAG, depending on when the packet forwarding is 178 performed. This buffer and forwarding mechanism increase the cache 179 overhead in MAG and increase the data transmission delay. In this 180 document, we assume that mobile node have multiple network interface 181 access different MAG in the same PMIPv6-Domain and support weak host 182 model,that means MN can receive any locally destined packet 183 regardless of the network interface on which the packet was received. 184 The deployment scenario is illustrated in Figure 1. 186 In order to improve the performance during handover and reduce the 187 demand of the MAG buffer capacity, this document specifies a bi- 188 directional tunnel between the PMAG and SMAG to forward packets for 189 mobile node. If an interface is handovering, the packets 190 transmission on this interface was forwarded to SMAG then forwarded 191 to some other interface of MN. In order to build a bi-directional 192 tunnel between the PMAG and the SMAG, a new message called Streamless 193 Handover Initiate(SHI) and Streamless Handover Acknowledge (SHIA) was 194 define in Section 5. When multi-interface MN attach to MAG, MAG will 195 send PBU register message to LMA, then recevie a PBA message if 196 register succeeded, MAG will send SHI message to MAGs that connect 197 with MN's interface. Necessary extensions to LMA and MAG need to 198 support this handover scheme and the extentions are define in section 199 4.3 and section 4.4. 201 4.1. Protocol Operation 203 Unlike Predictive Fast Handover and Reactive Fast Handover, this 204 protocol build a bi-directional tunnel between MAGs that different 205 interfaces of the mobile node connects to. The sequence of event for 206 the seamless handover scheme for Multiple-Access Mobile Node is 207 illustrated in Figure 2. 209 +-----+ +------+ +------------+ +------+ +----+ 210 | MN | | PMAG | | SMAG | | LMA | | CN | 211 +-----+ +------+ +------------+ +------+ +----+ 212 IF1 IF2 | | | | 213 | | | | Flow X | | 214 |<--------------->|<--------------------------- --->|<-------->| 215 | | | | | | 216 | |------Router Solicitation-->| | | 217 | | | |---PBU(MN-ID)--->| | 218 | | | | | | 219 | | | | +----------------------+| 220 | | | | |Detect whether the MN || 221 | | | | |have other interface || 222 | | | | |has registered || 223 | | | | +----------------------+| 224 | | | | | | 225 | | | |<-PBA(PMAG-Addr)-| | 226 | | | | | | 227 | |<----Router Advertisement---| | | 228 | | | |==Bi-Dir Tunnel==| | 229 | | | | | | 230 | | |<---SHI(MN-ID)-| | | 231 | | | | | | 232 | | |------SHIA---->| | | 233 | | | | | | 234 | | |=Bi-Dir Tunnel=| | | 235 +--------+| | | | | 236 |handover|| |<----------------------Flow X---------------| 237 +--------+| +-----------------------+| | | 238 | | | detection IF1 is || | | 239 | | | unreachable forword || | | 240 | | | Flow X to SMAG || | | 241 | | +-----------------------+| | | 242 | | | | | | 243 | | |-----Flow X--->| | | 244 | | | | | | 245 | |<---------Flow X------------| | | 246 | | | | | | 247 | | |------------PBU(dereg)---------->| | 248 | | | | | | 249 | | | | +----------------+ | 250 | | | | |forword Flow X | | 251 | | | | |to MAG2 | | 252 | | | | +----------------+ | 253 | | | | | | 254 | | | |<------------Flow X---------| 255 | |<---------Flow X------------| | | 256 | | | | | | 257 | | |<--------------PBA---------------| | 258 | | | | | | 260 Figure 2 the signaling process of streamless handover scheme for 261 Multiple-Access Mobile Node 263 The detailed descriptions are as follows: 265 o In the proxy mobile ipv6 network domain, MN has multiple interface 266 as illustrated in Figure 1, assumes that interface 1(IF1) has 267 already accessed PMIPv6 domain and data flow X transmitted through 268 the interface. 270 o IF2 accesses SMAG, and SMAG sends PBU message to LMA. If register 271 success, LMA send back PBA message to SMAG. 273 o When SMAG receives PBA message, it sends SHI message to PMAG, 274 noticing that the SHI message must include the MN-ID option. when 275 PMAG receives SHI message and finds that the MN connects to it, 276 PMAG sends a SHIA message to SMAG, otherwise PMAG send back MN not 277 attached SHIA message. When all this done, PMAG and SMAG detect 278 whether there exists any tunnel between them, if not, it will 279 build a bi-directional tunnel between them.notice that the tunnel 280 between MAGs are per-MAG-MAG. 282 o When IF1 performs a handover, first, if PMAG detects IF1 is 283 unreachable, it change the router and forwords the packet that 284 destination address is IF1 to SMAG. In this case , the 285 transmission path of flow X is LMA->PMAG->SMAG->IF2. Then PMAG 286 sends the DeReg PBU message to LMA. 288 o LMA receives the DeReg PBU message, first it changes the router 289 and forwards the packet of destination address IF1 to SMAG,.In 290 this case, the transmission path of flow X is LMA->SMAG->IF2. 291 Then LMA sends back DeReg PBA message to PMAG. 293 4.2. Mobile Node considerations 295 In this document, we assume that mobile node has multiple network 296 interfaces, and those interfaces access to the same PMIPv6-domain. 297 and all of the MN's network interfaces configuration the same home 298 network prefix. In order to support MNs that receive any locally 299 destined packet regardless of the network interface on which the 300 packet is received, the mobile node must support the weak host model. 301 While interface is handovering, it may re-config its IP address and 302 MN may not accept the packet that the destination address is the 303 handover interface, in this document, we assume MN can accept the 304 packet that the destination address is the handover interface's IP 305 address emporarily while the interface is handovering(details are out 306 of the scope of this document). 308 4.3. Mobile Access Gateway considerations 310 In the seamless handover scheme, when MAG receive a PBA message, it 311 need to send SHI message to some other MAGs that connect to MN, in 312 this document we assume that MAG knows the ip address of those MAG. 313 Notice that the SHI message at least includes MN-Id option. When MAG 314 receives SHI message, it detects whether the MN has a interface 315 connected with it, if so, MAG sends SHIA response message, and bulids 316 a bi-directional tunnel, otherwise, sends the response message of no 317 such node. 319 When MAG detects the departure of the MN's network interface, it 320 configures routing manner, the packets that sent to the interface are 321 forwarded through to SMAG through tunnels. As all the network 322 interfaces of MN's configured the same home network prefix, MAG can 323 forward packets to MN by prefix match. 325 4.4. Local Mobility Anchor considerations 327 When LMA receives a PBU message, it needs to detect wehther the MN 328 has another interface accessed the PMIPv6-domain, and associate all 329 MN's interface, in this document, we assume that LMA support flow 330 mobility, as [I-D.ietf-netext-pmipv6-flowmob] described 332 5. Message Formats 334 This section defines new mobility header messages for seamless 335 handover . 337 5.1. Streamless Handover Initiate (SHI) message 339 This message is created to bulid associate between MAGs that 340 different interfaces of MN connect to. The format of the Message 341 Data field in the Mobility Header is as follows: 343 0 1 2 3 344 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Sequence # | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 |A| Reserved | Lifetime | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 | Mobility options | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Sequence # 356 Must be set by the sender so replies can be matched to this message. 358 'A' flag 360 The Acknowledge (A) bit is set to request a Streamless Handover 361 Acknowledge be returned upon receipt of the SHI message. 363 Reserved 365 These fields are unused. They MUST be initialized to zero by the 366 sender and MUST be ignored by the receiver 367 Lifttime 369 16-bit unsigned integer. It represents the tunnel survival time. 371 Mobility Option 373 Same as [RFC5213] 375 5.2. Streamless Handover Acknowledge (SHAck) message 377 The Streamless Handover Acknowledge is used to acknowledge receipt of 378 a SHI message. The format of the Message Data field in the Mobility 379 Header is as follows: 381 0 1 2 3 382 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Sequence # | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Reserved | Status | Lifetime | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | | 389 | Mobility options | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Sequence# 394 The Sequence Number in the Streamless Handover Acknowledge is copied 395 from the Sequence Number field in the SHI message. 397 Reserved 399 These fields are unused. They MUST be initialized to zero by the 400 sender and MUST be ignored by the receiver. 402 Lifetime 404 16-bit unsigned integer. It represents the tunnel survival time. 406 Status 408 0: successed 410 128: Reason unspecfied 412 129: MN not attached 414 6. IANA Considerations 416 TBD 418 7. Security Considerations 420 TBD 422 8. Normative References 424 [I-D.ietf-netext-pmipv6-flowmob] Bernardos, C., "Proxy Mobile IPv6 425 Extensions to Support Flow 426 Mobility", 427 draft-ietf-netext-pmipv6-flowmob-04 428 (work in progress), July 2012. 430 [RFC2119] Bradner, S., "Key words for use in 431 RFCs to Indicate Requirement 432 Levels", BCP 14, RFC 2119, 433 March 1997. 435 [RFC5213] Gundavelli, S., Leung, K., 436 Devarapalli, V., Chowdhury, K., and 437 B. Patil, "Proxy Mobile IPv6", 438 RFC 5213, August 2008. 440 [RFC5949] Yokota, H., Chowdhury, K., Koodli, 441 R., Patil, B., and F. Xia, "Fast 442 Handovers for Proxy Mobile IPv6", 443 RFC 5949, September 2010. 445 Authors' Addresses 447 Yong Cui 448 Tsinghua University 449 Department of Computer Science, Tsinghua University 450 Beijing 100084 451 P.R.China 453 Phone: +86-10-6260-3059 454 EMail: cuiyong@tsinghua.edu.cn 456 Xin Xu 457 Beijing University of Posts and Telecommunications 458 Tsinghua University FIT Building 4-103 459 Beijing 100084 460 P.R.China 461 EMail: xuxin1988@gmail.com 463 Wendong Wang 464 Beijing University of Posts and Telecommunications 465 Room 609, teaching building 3,BUPT 466 Beijing 100876 467 P.R.China 469 EMail: wdwang@bupt.edu.cn 471 XiMing Li 472 Beijing University of Posts and Telecommunications 473 Tsinghua University FIT Building 4-103 474 Beijing 100084 475 P.R.China 477 EMail: xml@bupt.edu.cn 479 Yuzhen Huo 480 ZTE Corporation 481 No.68 Zijinghua Rd.,Yuhuatai District 482 Nanjing 210012 483 P.R.China 485 EMail: huo.yuzhen@zte.com.cn 487 Wen Luo 488 ZTE Corporation 489 No.68 Zijinghua Rd.,Yuhuatai District 490 Room 609, teaching building 3,BUPT 210012 491 P.R.China 493 EMail: EMail:luo.wen@zte.com.cn