idnits 2.17.1 draft-xue-dmm-routing-optimization-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 16) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 20, 2013) is 3956 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: 'RFC4301' is mentioned on line 936, but not defined == Unused Reference: 'I-D.chan-dmm-architecture' is defined on line 998, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-bernardos-dmm-distributed-anchoring-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM K. Xue 3 Internet-Draft L. Li 4 Intended status: Standards Track P. Hong 5 Expires: December 22, 2013 USTC 6 P. McCann 7 Huawei 8 June 20, 2013 10 Routing optimization in DMM 11 draft-xue-dmm-routing-optimization-02.txt 13 Abstract 15 This draft proposes a PMIP-based routing optimization method in 16 distributed anchor architecture. The anchor of the mobile node is 17 able to communicate with the anchor of corresponding node directly 18 using optimized routing. In this draft, there are two modes for the 19 setup of routing optimization: the direct mode and the relay mode. 20 The difference between them lies in that whether the routing 21 optimization is set up directly or under the assistance of a third 22 anchor. The situation that Communication Node(CN) is a fixed 23 terminal or a content server is also considered and 3 solutions are 24 provided correspondingly. The method proposed in this draft can 25 reduce the delay and save signaling overhead in the current scheme. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 22, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 75 2.1. Conventions Used in This Document . . . . . . . . . . . . 4 76 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3.1. Long Routing in Current Distributed Anchor Scenario . . . 4 79 3.2. Signaling Overhead Analysis . . . . . . . . . . . . . . . 5 80 4. The Function of D-MAG . . . . . . . . . . . . . . . . . . . . 6 81 5. Overview of the Proposed Protocol . . . . . . . . . . . . . . 6 82 5.1. The Direct Mode . . . . . . . . . . . . . . . . . . . . . 7 83 5.2. The Relay Mode . . . . . . . . . . . . . . . . . . . . . 9 84 6. CN considerations . . . . . . . . . . . . . . . . . . . . . . 11 85 6.1. The Direct Mode . . . . . . . . . . . . . . . . . . . . . 11 86 6.2. The Relay Mode . . . . . . . . . . . . . . . . . . . . . 13 87 6.2.1. P-D-MAG as A Relay . . . . . . . . . . . . . . . . . 13 88 6.2.2. F-D-MAG as A Relay . . . . . . . . . . . . . . . . . 14 89 7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 16 90 7.1. Enhanced Proxy Binding Update Message . . . . . . . . . . 16 91 7.2. Enhanced Proxy Binding Acknowledgement Message . . . . . 17 92 7.3. Mobility option . . . . . . . . . . . . . . . . . . . . . 18 93 7.3.1. Corresponding node address option . . . . . . . . . . 18 94 7.3.2. D-MAG address option . . . . . . . . . . . . . . . . 19 95 7.3.3. Former tunnels information option . . . . . . . . . . 20 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 100 11.1. Normative Reference . . . . . . . . . . . . . . . . . . 22 101 11.2. Informative Reference . . . . . . . . . . . . . . . . . 22 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 104 1. Introduction 106 The original centralized mobility management methods (such as the 107 Mobile IPv6, 3GPP EPS etc.) have many drawbacks including the long 108 routing problem, non- optimal architecture, heavy signaling overhead 109 etc. Therefore, distributed mobility managements are discussed and 110 studied widely. 112 In the current research of distributed mobility management (DMM), the 113 method that the anchor undertakes the role of both LMA and MAG 114 simultaneously is called the fully distributed mobility management 115 scheme. The distributed anchor 116 [I-D.bernardos-dmm-distributed-anchoring] is one of the fully 117 distributed mobility management methods. The distributed anchor 118 means that the newly generated communication sessions are anchored by 119 mobile node's current anchor. For example, when the mobile node 120 moves from one anchor to another anchor (handover), the communication 121 sessions generated after the handover are anchored by the new anchor. 123 Under the current distributed anchor schemes, when mobile node moves 124 to a new anchor, the former flow is forwarded by the former anchor to 125 the new anchor. Therefore, the long routing problem still exists. 126 In the existing work of PMIPv6 as [I-D.ietf-netext-pmip-lr], the 127 communication between LMAs is not involved since it assumes the 128 mobility management function should be accomplished under the 129 centralized architecture. However, in the distributed architecture 130 aforementioned, each distributed anchor could be regarded as the LMA 131 for the communication session generated on it. Therefore, it is 132 necessary to have communications between distributed anchors but 133 current schemes in PMIPv6 do not support such scenario. In this 134 draft, we propose a routing optimization scheme in distributed anchor 135 scenario based on PMIPv6 to solve the non-optimization routing 136 problem in the current work. 138 2. Conventions and Terminology 139 2.1. Conventions Used in This Document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 2.2. Terminology 147 The following terms are defined and used in this document: 149 Distributed MAG (D-MAG). It is the distributed anchor in our method 150 and it provides mobility management function. 152 First D-MAG (F-D-MAG). It is the first hop D-MAG where the sessions 153 firstly start. F-D-MAG assigns IPv6 prefixes and provides mobility 154 management function for the registered mobile node. 156 Previous D-MAG (P-D-MAG). It is the D-MAG that mobile node attaches 157 before handover. 159 New D-MAG (N-D-MAG). It is the D-MAG that mobile node attaches 160 currently. 162 Enhanced Proxy Binding Update (ePBU). It is the enhanced PBU 163 designed for optimized routing tunnel setup, state update, etc. It 164 contains Routing Optimization Indicator (ROI) as a 2-bit state flag 166 Enhanced Proxy Binding Acknowledge (ePBA). It is the enhanced PBA 167 designed for optimized routing tunnel setup, state update, etc. It 168 contains Routing Optimization Indicator (ROI) as a 2-bit state flag 170 3. Motivations 172 3.1. Long Routing in Current Distributed Anchor Scenario 174 In current DMM approaches, when the mobile node moves to a new 175 anchor, the communication session generated before MUST be forwarded 176 to the new D-MAG by the original anchor. Therefore, there is still a 177 long routing problem in such schemes and it MAY bring in delay and 178 jitter. As Figure.1 shows, in the current approaches, when the 179 mobile node (MN) moves from P-Anchor(the previous anchor) to 180 N-Anchor(the new anchor), the communication session generated before 181 handover (On P-Anchor) will be forwarded to the new anchor (N-Anchor 182 in Figure.1) by the previous anchor (P-Anchor). The problem would 183 become more severe when the mobile node (MN) moves across multiple 184 anchors with the original communication sessions still going. It is 185 because the distance between the original anchor and the new anchor 186 MAY be rather long for a certain communication session. 188 +----------+ +----------+ 189 | CN | | CN | 190 | | | | 191 +----/-----+ +----/-----+ 192 | | 193 | _,,,.-----..,,| 194 ,-|` |``-. 195 / | Core Network | \ 196 \ | | / 197 '-|, |_,-' 198 Old session | ``''''----'''`| New session 199 | | 200 | | 201 +----|-----+ +----------+ 202 | +-----------+ | 203 | P-Anchor | || N-Anchor| 204 +----------+ +|---|-----+ 205 | | 206 | | 207 +------+ 208 ---Move--> | MN | 209 +------+ 211 Figure 1: Data flow in the current DMM approaches 213 3.2. Signaling Overhead Analysis 215 In this section, the analysis of the signaling overhead by simply 216 adopting current routing optimization schemes in PMIPv6 is given 217 briefly. 219 The routing optimization or local routing schemes in current PMIPv6 220 MAY bring in much more signaling overhead when applied in the 221 distributed anchor scenario. The procedure of local routing is 222 showed in Figure.2. The LMA (Local Mobility Anchor) of MN sends 223 routing optimization trigger to the LMA of CN to start the routing 224 optimization. The LMA of MN also needs to send the address of MN's 225 MAG to the LMA of CN. Afterwards, the LMA of CN sends routing 226 optimization initiation command to the MAG of CN. Then the MAG of CN 227 sets up tunnel with the MAG of MN and the routing optimization is 228 established [I-D.loureiro-netext-pmipv6-ro]. 230 +-------+ +-------+ +-------+ +-------+ 231 |MAG(MN)| |LMA(MN)| |LMA(CN)| |MAG(CN)| 232 +---/---+ +---/---+ +---/---+ +---/---+ 233 | | | | 234 | | | | 235 | |-1.RO Trigger----->| | 236 | | | | 237 | | |-2.RO Init----->| 238 | | | | 239 |<-------------3.RO Setup----------------------| 240 | | | | 241 |--------------4.RO Setup Ack----------------->| 242 | | | | 243 | | |<-5.RO Init Ack-| 244 | | | | 245 | |<-6.RO Trigger Ack-| | 246 | | | | 248 Figure 2: The procedure of local routing in PMIPv6 250 If it is adopted in the distributed anchor scenario, each anchor 251 could be regarded as a LMA for the communication sessions generated 252 on it. The mobile node MAY have multiple communication sessions 253 generated on different anchors. When the mobile node moves, each 254 anchor of MN needs to send messages to each CN's anchor. Since the 255 mobile node moves across multiple anchors, there would be multiple 256 LMAs of MN and multiple LMAs of CN. Therefore, the signaling 257 overhead is large. Secondly, these signalings are distributed across 258 the Internet, so the delay would be longer for all of these messages. 260 4. The Function of D-MAG 262 D-MAG(Distributed MAG) is the distributed anchor in this draft. It 263 is in charge of the prefix allocation and the mobility management for 264 a specific communication session generated on it. It runs the 265 functionalities of PMIP's MAG and LMA based on communication 266 sessions. It is a logical entity that could be integrated into the 267 access router. 269 5. Overview of the Proposed Protocol 271 We propose two solutions to optimize the routing. The first solution 272 is the Direct Mode which means that the routing optimization is set 273 up between the MN's D-MAG and CN's D-MAG by exchanging messages 274 between the two entities directly. The second solution is the Relay 275 Mode which means that the routing optimization between the MN's D-MAG 276 and CN's D-MAG SHALL be set up under the assistance of a third D-MAG. 278 There are two stages in our protocol. The first stage is the 279 initiation of the routing optimization and the second stage is the 280 maintenance of the routing optimization. The initiation is the setup 281 procedure of the routing optimization when mobile node moves to a new 282 anchor from the first anchor. The maintenance stage is the 283 maintenance of routing optimization when the mobile node moves from 284 the previous anchor to the new anchor after the setup of routing 285 optimization. 287 5.1. The Direct Mode 289 (a)Initiation of Routing Optimization 291 Figure 3 illustrates the initiation of routing optimization. The 292 original communication session for MN is generated in F-D-MAG and 293 uses the prefix it assigns. The F-D-MAG is the first hop D-MAG where 294 the session firstly starts. 296 When MN moves to its N-D-MAG, MN's N-D-MAG sends enhanced PBU (ePBU) 297 with ROI (Routing Optimization Indicator) = 01 to its F-D-MAG to 298 inform that the prefixes it assigns are still being used. ePBU is an 299 enhanced proxy binding update (ePBU) with a 2-bit state flag ROI. 300 This message is OPTIONAL because there is already a prefix lifetime 301 extension message in the protocol of PMIPv6 as [RFC5213]. 303 MN's N-D-MAG sends ePBU with ROI= 10 to CN's F-D-MAG to query the 304 address of CN's current D-MAG. We MAY assume the address of CN's 305 F-D-MAG is known to MN's N-D-MAG. Even if it is unknown to MN's 306 N-D-MAG, the ePBU to CN's F-D-MAG could be delivered in the following 307 way. Firstly, MN's D-MAG intercepts the first uplink packet of MN 308 and gets the address of CN which is the destination address of the 309 packet. Then, it sends ePBU to the address of CN and the ePBU would 310 be intercepted by CN's F-D-MAG. Afterwards, CN's F-D-MAG would 311 recognize the ePBU and sends back enhanced PBA (ePBA) which includes 312 the address of CN's current D-MAG. 314 MN's N-D-MAG sends ePBU with ROI=11 to CN's current D-MAG to execute 315 the routing optimization. Under this circumstance, a bi-directional 316 tunnel will be established between MN's N-D-MAG and CN's D-MAG. 318 +------+ +---------+ +---------++---------++---------+ +------+ 319 | MN | | N-D-MAG | | F-D-MAG || F-D-MAG || D-MAG | | CN | 320 | | | (MN) | | (MN) || (CN) || (CN) | | | 321 +--/---+ +----/----+ +----/----++----/----++----/----+ +--/---+ 322 | | | | | | 323 |<-1.Attach-| | | | | 324 | /RS | | | | | 325 | 2.Registration | | | | 326 | | | | | | 327 | |-3.ePBU(ROI)->| | | | 328 | | | | | | 329 | |<-4.ePBA(ROI)-| | | | 330 | | | | | | 331 | |-----5.ePBU(ROI)-------->| | | 332 | | | | | | 333 | |<----6.ePBA(ROI)---------| | | 334 | | | | | | 335 | |-----------7.ePBU(ROI)------------->| | 336 | | | | | | 337 | |<----------8.ePBA(ROI)--------------| | 338 | | | | | | 339 |<-9.RA-----| | | | | 340 | | | | | | 341 |<-10A.IP-->|<---------10B.IP Packet------------>|<-10A.IP->| 342 | packet | | | | packet | 344 Figure 3: The initiation of routing optimization for DM 346 (b)Maintenance of routing optimization 348 Figure 4 illustrates procedure of the maintenance for routing 349 optimization 351 When MN moves from previous D-MAG(P-D-MAG) to another new D-MAG 352 (N-D-MAG in Figure 4), N-D-MAG sends ePBU with ROI = 01 to F-D-MAG in 353 order to announce the prefixes that F-D-MAG assigns are still being 354 used. It is also OPTIONAL and the reason is the same with that in 355 section 5.1(a). 357 N-D-MAG sends ePBU with ROI=00 to P-D-MAG to request former tunnel 358 information on P-D-MAG. The tunnel information contains all the 359 addresses of CNs' current D-MAGs. P-D-MAG sends back ePBA with 360 ROI=00 which includes the former tunnel information. The mobile node 361 MAY move across multiple D-MAGs, therefore, it could have multiple 362 routing optimization tunnels on P-D-MAG. The information of all the 363 tunnels could be obtained through one exchange of message (message 6 364 and 7 in Figure 4). In this way, the signaling overhead mentioned in 365 Section 3.2 can be reduced. The former tunnels on P-D-MAG could be 366 deleted explicitly through the exchange of ePBU/ePBA between N-D-MAG 367 and P-D-MAG, or they would be deleted upon timer expiration. 369 Then N-D-MAG of MN sends ePBU with ROI=11 to each CN's D-MAG of CN to 370 maintain routing optimization. Under this circumstance, a bi- 371 directional tunnel would be established between the N-D-MAG(MN) and 372 each D-MAG(CN). Consequently, the routing optimization could be 373 continued. 375 +------+ +---------+ +---------++---------++---------+ +------+ 376 | MN | | N-D-MAG | | F-D-MAG || P-D-MAG || D-MAG | | CN | 377 | | | (MN) | | (MN) || (MN) || (CN) | | | 378 +--/---+ +----/----+ +----/----++----/----++----/----+ +--/---+ 379 |<----------1A.IP packet------------->|<-1B.IP-->|<-1C.IP-->| 380 |<-2.Attach-| | | packet | packet | 381 | /RS | | | | | 382 | 3.Registration | | | | 383 | | | | | | 384 | |-4.ePBU(ROI)->| | | | 385 | | | | | | 386 | |<-5.ePBA(ROI)-| | | | 387 | | | | | | 388 | |-----6.ePBU(ROI)-------->| | | 389 | | | | | | 390 | |<----7.ePBA(ROI)---------| | | 391 | | | | | | 392 | |-----------8.ePBU(ROI)------------->| | 393 | | | | | | 394 | |<----------9.ePBA(ROI)--------------| | 395 | | | | | | 396 |<-10.RA----| | | | | 397 | | | | | | 398 |<-11A.IP-->|<---------11B.IP packet------------>|<-11A.IP->| 399 | packet | | | | packet | 401 Figure 4: The maintenance of routing optimization for direct mode 403 5.2. The Relay Mode 405 (a)Initiation of routing optimization 407 In relay mode, the initiation of routing optimization is the same 408 with that in the direct mode described in section 5.1(a). 410 (b)Maintenance of routing optimization 412 Figure 5 illustrates the procedure of maintenance stage for relay 413 mode. 415 +------+ +---------+ +---------++---------++---------+ +-----+ 416 | MN | | N-D-MAG | | F-D-MAG || P-D-MAG || D-MAG | | CN | 417 | | | (MN) | | (MN) || (MN) || (CN) | | | 418 +--/---+ +----/----+ +----/----++----/----++----/----+ +--/--+ 419 |<----------1A.IP packet------------->|<-1B.IP-->|<-1C.IP-->| 420 |<-2.Attach-| | | packet | packet | 421 | /RS | | | | | 422 | 3.Registration | | | | 423 | | | | | | 424 | |-4.ePBU(ROI)->| | | | 425 | | | | | | 426 | |<-5.ePBA(ROI)-| | | | 427 | | | | | | 428 | |-----6.ePBU(ROI)-------->| | | 429 | | | |-7.ePBU-->| | 430 | | | | (ROI) | | 431 | | | |<-8.ePBA--| | 432 | | | | (ROI) | | 433 | |<----9.ePBA(ROI)---------| | | 434 | | | | | | 435 |<-10.RA----| | | | | 436 | | | | | | 437 |<-11A.IP-->|<---------11B.IP Packet------------>|<-11A.IP->| 438 | packet | | | | packet | 440 Figure 5: The maintenance of routing optimization for relay mode 442 When MN moves from previous D-MAG(P-D-MAG) to another new 443 D-MAG(N-D-MAG), namely the N-D-MAG in Figure 5, N-D-MAG sends ePBU 444 with ROI = 01 to F-D-MAG in order to announce the prefixes that 445 F-D-MAG assigns are still being used. It is also OPTIONAL and the 446 reason is the same with that in section 5.1(a). 448 N-D-MAG of MN sends ePBU with ROI=00 to P-D-MAG of MN to request the 449 context transfer of routing optimization. 451 P-D-MAG of MN sends ePBU with ROI=11 to each D-MAG of CN to maintain 452 routing optimization. P-D-MAG of MN works as a relay for the request 453 of routing optimization maintenance. 455 Finally, P-D-MAG of MN sends back the ePBA to MN's N-D-MAG. The ePBA 456 contains the address of CN's D-MAG. Therefore, the data could be 457 transmitted using optimized routing. 459 When there are multiple tunnels established in the P-D-MAG, only one 460 pair of ePBU/ePBA (message 6 and 9) exchange between the N-D-MAG (MN) 461 and P-D-MAG (MN) is needed to acquire all the tunnel information. In 462 this way, we save the signaling overhead. Besides, the message 463 querying for the tunnel information from N-D-MAG to P-D-MAG does not 464 need to be delivered through the Internet, which would reduce the 465 signaling delay than querying from the F-D-MAG of CN over the 466 Internet. 468 6. CN considerations 470 CN could also be a fixed terminal or a content server and it is 471 capable to set up tunnels with the MN's D-MAG. For such CN, we also 472 provide two modes, the direct mode and the relay mode. Likewise, 473 there are also two stages. The first one is the initiation stage and 474 the other one is the maintenance stage. This consideration requires 475 CN to support the ability of tunnel setup like exchanging message 476 with D-MAG. 478 6.1. The Direct Mode 480 (a) Initiation of routing optimization 482 +------+ +---------+ +---------+ +-----+ 483 | MN | | N-D-MAG | | F-D-MAG | | CN | 484 | | | (MN) | | (MN) | | | 485 +--/---+ +----/----+ +----/----+ +--/--+ 486 | | | | 487 |<-1.Attach-| | | 488 | /RS | | | 489 | 2.Registration | | 490 | | | | 491 | |-3.ePBU(ROI)->| | 492 | | | | 493 | |<-4.ePBA(ROI)-| | 494 | | | | 495 | |-----5.ePBU(ROI)------->| 496 | | | | 497 | |<----6.ePBA(ROI)--------| 498 | | | | 499 |<-7.RA-----| | | 500 | | | | 501 |<--8A.IP-->|<---8B.IP packet------->| 502 | packet | | | 504 Figure 6: The initiation stage for direct mode 506 Figure 6 illustrates the initiation stage for these special CNs in 507 the direct mode. 509 The original session is generated in F-D-MAG and uses the prefixes it 510 assigns. When MN moves, N-D-MAG sends ePBU (set ROI = 01) to F-D-MAG 511 to inform that the prefixes it assigns are still being used. This 512 step is optional and the reason is the same with that in section 513 5.1(a). 515 N-D-MAG sends ePBU (set ROI = 11) to all CNs to inform of the 516 execution of routing optimization. Under this circumstance, a bi- 517 directional tunnel will be established between N-D-MAG and CN. 519 (b) Maintenance of routing optimization 521 +------+ +---------+ +---------++---------+ +-----+ 522 | MN | | N-D-MAG | | F-D-MAG || P-D-MAG | | CN | 523 | | | (MN) | | (MN) || (MN) | | | 524 +--/---+ +----/----+ +----/----++----/----+ +--/--+ 525 |<----------1A.IP packet------------->|<-1B.IP-->| 526 |<-2.Attach-| | | packet | 527 | /RS | | | | 528 | 3.Registration | | | 529 | | | | | 530 | |-4.ePBU(ROI)->| | | 531 | | | | | 532 | |<-5.ePBA(ROI)-| | | 533 | | | | | 534 | |-----6.ePBU(ROI)-------->| | 535 | | | | | 536 | |<----7.ePBA(ROI)---------| | 537 | | | | | 538 | |----------8.ePBU(ROI)-------------->| 539 | |<---------9.ePBA(ROI)---------------| 540 |<-10.RA----| | | | 541 | | | | | 542 |<-11A.IP-->|<---------11B.IP Packet------------>| 543 | packet | | | | 545 Figure 7: The maintenance stage for direct mode 547 Figure 7 illustrates the maintenance stage for these special CNs in 548 direct mode. 550 The original session is generated in F-D-MAG and uses the prefixes 551 F-D-MAG assigns. 553 When MN moves from P-D-MAG to N-D-MAG, N-D-MAG sends ePBU (set ROI = 554 01) to F-D-MAG to inform that the prefixes it assigns are still being 555 used. This step is optional and the reason is the same with that in 556 section 5.1(a). 558 N-D-MAG optionally sends ePBU (set ROI = 00) to P-D-MAG to delete all 559 the former tunnels related to that MN explicitly. For multiple 560 tunnels related to the MN，only one pair of ePBU/ePBA is 561 required. 563 N-D-MAG sends ePBU (set ROI = 11) to all CNs to inform of the 564 execution of routing optimization. Under this circumstance, a bi- 565 directional tunnel will be established between N-D-MAG and CNs. 567 6.2. The Relay Mode 569 There are two types of relays, the first type is the P-D-MAG relay 570 and the other one is the F-D-MAG relay. The difference lies in that 571 the routing optimization request is relayed by different D-MAGs. 573 6.2.1. P-D-MAG as A Relay 575 +------+ +---------+ +---------++---------+ +-----+ 576 | MN | | N-D-MAG | | F-D-MAG || P-D-MAG | | CN | 577 | | | (MN) | | (MN) || (MN) | | | 578 +--/---+ +----/----+ +----/----++----/----+ +--/--+ 579 |<----------1A.IP packet------------->|<-1B.IP-->| 580 |<-2.Attach-| | | packet | 581 | /RS | | | | 582 | 3.Registration | | | 583 | | | | | 584 | |-4.ePBU(ROI)->| | | 585 | | | | | 586 | |<-5.ePBA(ROI)-| | | 587 | | | | | 588 | |-----6.ePBU(ROI)-------->| | 589 | | | |-7.ePBU-->| 590 | | | | (ROI) | 591 | | | | | 592 | | | |<-8.ePBA--| 593 | |<----9.ePBA(ROI)---------| (ROI) | 594 |<-10.RA----| | | | 595 | | | | | 596 |<-11A.IP-->|<---------11B.IP Packet------------>| 597 | packet | | | | 598 Figure 8: The maintenance stage for P-D-MAG relay. 600 Like the relay mode described in section 5.2, the P-D-MAG works as a 601 relay in the stage of routing optimization maintenance. 603 (a) Initiation of routing optimization 605 The initiation stage is the same with that in direct mode of section 606 6.1(a). 608 (b) Maintenance of routing optimization 610 Figure 8 illustrates the procedure of maintenance stage for P-D-MAG 611 relay. 613 When MN moves, N-D-MAG sends ePBU with ROI=01 to F-D-MAG to inform 614 that the prefixes it assigns are still being used. This step is 615 optional and the reason is the same with that in section 5.1(a). 617 N-D-MAG sends ePBU to P-D-MAG with ROI=00 to request the transferring 618 of former tunnels. P-D-MAG sends ePBU with ROI = 11 to CNs to inform 619 of the execution of routing optimization. The address of N-D-MAG is 620 included in this ePBU (message 7). In this way, P-D-MAG works as a 621 relay. P-D-MAG deletes the former tunnels and sends ePBA with ROI = 622 11 back to N-D-MAG. Under this circumstance, a bi-directional tunnel 623 will be established between N-D-MAG and CNs and data is transmitted 624 in optimized routing. 626 6.2.2. F-D-MAG as A Relay 628 In this section, the F-D-MAG works as the relay for both the 629 initiation and maintenance stage of routing optimization. 631 (a) Initiation of routing optimization 632 +------+ +---------+ +---------+ +-----+ 633 | MN | | N-D-MAG | | F-D-MAG | | CN | 634 | | | (MN) | | (MN) | | | 635 +--/---+ +----/----+ +----/----+ +--/--+ 636 | | | | 637 |<-1.Attach-| | | 638 | /RS | | | 639 | 2.Registration | | 640 | |-3.ePBU(ROI)->| | 641 | | | | 642 | | |-4.ePBU->| 643 | | | (ROI) | 644 | | | | 645 | | |<-5.ePBA-| 646 | |<-6.ePBA(ROI)-| (ROI) | 647 |<-7.RA-----| | | 648 | | | | 649 |<--8A.IP-->|<---8B.IP packet------->| 650 | packet | | | 652 Figure 9: The initiation stage of F-D-MAG relay 654 Figure 9 illustrates the initiation stage of F-D-MAG relay. 656 The original session is generated in F-D-MAG and uses the prefixes 657 F-D-MAG assigns. When MN moves, N-D-MAG sends ePBU with ROI = 01 to 658 F-D-MAG to inform that the prefixes it assigns are still being used 659 and that the Routing Optimization Communication mode is used. 661 F-D-MAG sends ePBU with set ROI = 11 to CN to inform the execution of 662 routing optimization. In this message (message 4), it tells CN the 663 address of N-D-MAG which is the new care of address of MN. In this 664 way, F-D-MAG works as a relay for the request of routing optimization 665 for N-D-MAG. Afterwards, the data could be transmitted between 666 N-D-MAG and CN using optimized routing. 668 (b) Maintenance of routing optimization 670 Figure 10 illustrates the maintenance stage when F-D-MAG works as a 671 relay. When MN moves from P-D-MAG to N-D-MAG, N-D-MAG sends ePBU 672 with ROI =01 to F-D-MAG to inform that the prefixes it assigns are 673 still being used and inform to keep using the Routing Optimization 674 Communication mode. 676 +------+ +---------+ +---------++---------+ +-----+ 677 | MN | | N-D-MAG | | F-D-MAG || P-D-MAG | | CN | 678 | | | (MN) | | (MN) || (MN) | | | 679 +--/---+ +----/----+ +----/----++----/----+ +--/--+ 680 |<----------1A.IP packet------------->|<-1B.IP-->| 681 |<-2.Attach-| | | packet | 682 | /RS | | | | 683 | 3.Registration | | | 684 | |-4.ePBU(ROI)->| | | 685 | | |----5.ePBU(ROI)----->| 686 | | |<---6.ePBA(ROI)------| 687 | |<-7.ePBA(ROI)-| | | 688 | | | | | 689 |<-10.RA----| | | | 690 | |-----9.ePBU(ROI)-------->| | 691 | |<---10.ePBA(ROI)---------| | 692 | | | | | 693 | | | | | 694 |<-11A.IP-->|<---------11B.IP Packet------------>| 695 | packet | | | | 697 Figure 10: The maintenance stage for F-D-MAG relay 699 F-D-MAG sends ePBU with set ROI = 11 to CN to inform the execution of 700 routing optimization. In this message (message 5), it tells CN the 701 address of N-D-MAG which is the new care of address of MN. In this 702 way, F-D-MAG works as a relay for the request of routing optimization 703 for N-D-MAG. 705 N-D-MAG optionally informs P-D-MAG to delete the former tunnel 706 explicitly or wait upon timer expiration. For multiple sessions 707 related to the MN，only one pair of ePBU/ePBA is required. So 708 it MAY save the signaling overhead. 710 7. Message Format 712 7.1. Enhanced Proxy Binding Update Message 714 0 1 2 3 715 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 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Sequence # | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 |A|H|L|K|M|R|P|ROI| Reserved | Lifetime | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | | 722 . . 723 . Mobility options . 724 . . 726 | | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 The enhanced PBU (ePBU) is the original proxy binding update added 730 with 2-bit ROI state flag. 732 ROI: 734 2-bit state flag. 736 Mobility options: 738 A variable-length field of such length that the complete Mobility 739 Header is an integer multiple of 8 octets long. This field contains 740 zero or more TLV-encoded mobility options. The encoding and format 741 of defined options are described in Section 6.2 of [RFC6275]. The 742 distributed mobile access gateway MUST ignore and skip any options 743 that it does not understand. 745 As per this specification, the following mobility options are valid 746 in an Enhanced Proxy Binding Update message. These options can be 747 present in the message in any order. There cannot be more than one 748 instance of any of the following options: 750 Corresponding node's address option 752 D-MAG address option 754 Former tunnels information option 756 7.2. Enhanced Proxy Binding Acknowledgement Message 758 The enhanced PBA (ePBA) is the original proxy binding acknowledgement 759 added with 2-bit ROI state flag. 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Status |K|R|P|ROI| Rev | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Sequence # | Lifetime | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | | 769 . . 770 . Mobility options . 771 . . 772 | | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 ROI: 777 2-bit state flag. 779 Mobility options: 781 A variable-length field of such length that the complete Mobility 782 Header is an integer multiple of 8 octets long. This field contains 783 zero or more TLV-encoded mobility options. The encoding and format 784 of defined options are described in Section 6.2 of [RFC6275]. The 785 distributed mobile access gateway MUST ignore and skip any options 786 that it does not understand. 788 As per this specification, the following mobility options are valid 789 in an Enhanced Proxy Binding Acknowledgement message. These options 790 can be present in the message in any order. There cannot be more 791 than one instance of any of the following options: 793 Corresponding node address option 795 D-MAG address option 797 Former tunnels information option 799 7.3. Mobility option 801 7.3.1. Corresponding node address option 803 A new option, corresponding node address option is defined for use 804 with the Enhanced Proxy Binding Update and Enhanced Proxy Binding 805 Acknowledgement messages exchanged between the distributed mobile 806 access gateways. This option is used for exchanging the 807 corresponding node's address. 809 The format of the corresponding node address option is shown below. 810 Based on the size of the identifier, the option MUST be aligned 811 appropriately, as per mobility option alignment requirements 812 specified in [RFC6275]. 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Type | Length | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | | 820 + Corresponding Node's Address + 821 | | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 Type: 826 Approval of new corresponding node address option type value is to be 827 made through IANA Expert Review. 829 Length: 831 8-bit unsigned integer, representing the length in octets of the 832 mobility option, not including the Option Type and Option Length 833 fields. 835 Corresponding Node's Address: 837 A variable length field containing the corresponding node's address. 839 7.3.2. D-MAG address option 841 A new option, D-MAG address option is defined for use with the 842 Enhanced Proxy Binding Acknowledgement messages exchanged between the 843 distributed mobile access gateways. This option is used for 844 exchanging current D-MAG address of the corresponding node. 846 The format of the D-MAG address option is shown below. Based on the 847 size of the identifier, the option MUST be aligned appropriately, as 848 per mobility option alignment requirements specified in [RFC6275]. 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Type | Length | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | | 856 + D-MAG's Address + 857 | | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Type: 862 Approval of new D-MAG address option value is to be made through IANA 863 Expert Review. 865 Length: 867 8-bit unsigned integer, representing the length in octets of the 868 mobility option, not including the Option Type and Option Length 869 fields. 871 D-MAG's Address: 873 A variable length field containing the D-MAG's address. 875 7.3.3. Former tunnels information option 877 A new option, former tunnels information option is defined for use 878 with the Enhanced Proxy Binding Update and Enhanced Proxy Binding 879 Acknowledgement messages exchanged between the distributed mobile 880 access gateways. This option is used for exchanging the information 881 of former tunnels. 883 The format of the former tunnels information option is shown below. 884 Based on the size of the identifier, the option MUST be aligned 885 appropriately, as per mobility option alignment requirements 886 specified in [RFC6275]. 888 Type: 890 Approval of former tunnels information option type value is to be 891 made through IANA Expert Review. 893 Length: 895 8-bit unsigned integer, representing the length in octets of the 896 mobility option, not including the Option Type and Option Length 897 fields. This field can also indicate the number of former tunnels 898 listed in the option. 900 The Destination Address of The Xth Tunnel: 902 It indicates the address of the Xth tunnel. 904 The SPI value of The Xth Tunnel: 906 It indicates the SPI value of the Xth tunnel. 908 0 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Type | Length | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | The Destination Address of The 1st Tunnel | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | The SPI value of The 1st Tunnel | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | The Destination Address of The 2nd Tunnel | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | The SPI value of The 2nd Tunnel | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | ....... | 922 . ....... . 923 . ....... . 924 | | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 8. Security Considerations 929 Security threats for routing optimization in network-based 930 distributed mobility management comprise the danger of unauthorized 931 set up or redirect of an established forwarding path by a malicious 932 node. Signaling messages of this protocol between D-MAGs must be 933 authenticated by means of IPsec [RFC4301]. 935 Protection of signaling messages between D-MAGs uses the mechanisms 936 of Encapsulating Security Payload (ESP) [RFC4301] in transport mode 937 with mandatory data origin authentication by means of a non-null 938 payload authentication algorithm. The use of encryption is optional. 939 In particular, if the network which interconnects two D-MAGs is not 940 trusted, the use of encryption is recommended to support 941 confidentiality protection between MAGs respectively. 943 9. IANA Considerations 945 This document defines three new Mobility Header options, the 946 Corresponding Node Address option, the D-MAG Address option, the 947 Former Tunnels Information option. These options are described in 948 Section 7.3 The new Mobility Header Type values for the ePBU/ePBA 949 should be allocated and the approval of new type values is to be made 950 through IANA Expert Review. 952 The Corresponding Node Address option, defined in Section 7.3.1, is 953 used to exchange Corresponding Node Address between distributed 954 mobile access gateways. The approval of new type value is to be made 955 through IANA Expert Review. 957 The D-MAG Address option, defined in Section 7.3.2, is used to 958 exchange the current D-MAG address of the corresponding node between 959 distributed mobile access gateways. The approval of new type value 960 is to be made through IANA Expert Review. 962 The Former Tunnels Information option, defined in Section 7.3.3, is 963 used to exchange Former Tunnels Information between distributed 964 mobile access gateways. The approval of new type value is to be made 965 through IANA Expert Review. 967 This document also creates a 2-bit status flag in the Proxy Binding 968 Update/Proxy Binding Acknowledgement message called the "Routing 969 Optimization Indicator" in Section 7. 971 10. Acknowledgements 973 The authors would like to specially thank Peter J. McCann for his 974 thorough reviews of this document.The authors would also like to 975 thank Lei Zhu, Ning He and Dan Ni for all the discussions on this 976 topic. 978 11. References 980 11.1. Normative Reference 982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 983 Requirement Levels", BCP 14, RFC 2119, March 1997. 985 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 986 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 988 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 989 in IPv6", RFC 6275, July 2011. 991 11.2. Informative Reference 993 [I-D.bernardos-dmm-distributed-anchoring] 994 Bernardos, C. and J. Zuniga, "PMIPv6-based distributed 995 anchoring", draft-bernardos-dmm-distributed-anchoring-02 996 (work in progress), April 2013. 998 [I-D.chan-dmm-architecture] 999 Chan, A., "A architecture of distributed mobility 1000 management using mip and pmip", draft-chan-dmm- 1001 architecture-00 (work in progress), March 2012. 1003 [I-D.ietf-netext-pmip-lr] 1004 Krishnan, S., Koodli, R., Loureiro, P., Wu, W., and A. 1005 Dutta, "Localized Routing for Proxy Mobile IPv6", draft- 1006 ietf-netext-pmip-lr-10 (work in progress), May 2012. 1008 [I-D.loureiro-netext-pmipv6-ro] 1009 Loureiro, P. and M. Liebsch, "Proxy Mobile IPv6 Localized 1010 Routing", draft-loureiro-netext-pmipv6-ro-02 (work in 1011 progress), March 2010. 1013 Authors' Addresses 1014 Kaiping Xue 1015 USTC 1016 Room 305, EEIS Department, USTC West Campus 1017 Shushan District, Hefei , Anhui 230027 1018 P. R. China 1020 Phone: +86-551-3601334 1021 Email: kpxue@ustc.edu.cn 1023 Lin Li 1024 USTC 1025 Room 305, EEIS Department, USTC West Campus 1026 Shushan District, Hefei , Anhui 230027 1027 P. R. China 1029 Phone: +86-551-3601334 1030 Email: linl@mail.ustc.edu.cn 1032 Peilin Hong 1033 USTC 1034 Room 305, EEIS Department, USTC West Campus 1035 Shushan Distric, Hefei , Anhui 230027 1036 P. R. China 1038 Phone: +86-551-3601334 1039 Email: plhong@ustc.edu.cn 1041 Peter J. McCann 1042 Huawei 1043 400 Crossing Blvd, 2nd Floor 1044 Bridgewater , NJ 08807 1045 USA 1047 Phone: +1-908-541-3563 1048 Email: peter.mccann@huawei.com