idnits 2.17.1 draft-ietf-netext-pmipv6-flowmob-10.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 : ---------------------------------------------------------------------------- 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 date (June 25, 2014) is 3591 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: 'MN1-ID' is mentioned on line 458, but not defined == Missing Reference: 'HNPs' is mentioned on line 458, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-netext-logical-interface-support-09 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT Working Group CJ. Bernardos, Ed. 3 Internet-Draft UC3M 4 Intended status: Standards Track June 25, 2014 5 Expires: December 27, 2014 7 Proxy Mobile IPv6 Extensions to Support Flow Mobility 8 draft-ietf-netext-pmipv6-flowmob-10 10 Abstract 12 Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy 13 Mobile IPv6 domain through different interfaces. This document 14 describes extensions to the Proxy Mobile IPv6 protocol that are 15 required to support network based flow mobility over multiple 16 physical interfaces. 18 The extensions described in this document consist on the operations 19 performed by the local mobility anchor and the mobile access gateway 20 to manage the prefixes assigned to the different interfaces of the 21 mobile node, as well as how the forwarding policies are handled by 22 the network to ensure consistent flow mobility management. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 27, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Overview of the PMIPv6 flow mobility 67 extensions . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Use case scenarios . . . . . . . . . . . . . . . . . . . 4 69 3.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5 70 3.2.1. MN sharing a common 71 set of prefixes on all MAGs . . . . . . . . . . . . . 5 72 3.2.2. MN with different 73 sets of prefixes on each MAG . . . . . . . . . . . . 9 74 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.1. Home Network Prefix . . . . . . . . . . . . . . . . . . . 13 76 4.2. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . 14 77 4.3. Flow Mobility Acknowledgement (FMA) . . . . . . . . . . . 15 78 5. Conceptual Data Structures . . . . . . . . . . . . . . . . . 16 79 5.1. Multiple Proxy Care-of Address Registration . . . . . . . 16 80 5.2. Flow Mobility Cache . . . . . . . . . . . . . . . . . . . 17 81 6. Mobile Node considerations . . . . . . . . . . . . . . . . . 18 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 88 11.2. Informative References . . . . . . . . . . . . . . . . . 21 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network 94 based mobility management to hosts connecting to a PMIPv6 domain. 95 PMIPv6 introduces two new functional entities, the Local Mobility 96 Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the 97 entity detecting Mobile Node's (MN) attachment and providing IP 98 connectivity. The LMA is the entity assigning one or more Home 99 Network Prefixes (HNPs) to the MN and is the topological anchor for 100 all traffic belonging to the MN. 102 PMIPv6 allows a mobile node to connect to the same PMIPv6 domain 103 through different interfaces. This document specifies protocol 104 extensions to Proxy Mobile IPv6 between the local mobility anchor and 105 mobile access gateways to enable "flow mobility" and hence distribute 106 specific traffic flows on different physical interfaces. It is 107 assumed that the mobile node IP layer interface can simultaneously 108 and/or sequentially attach to multiple MAGs, possibly over multiple 109 media. One form to achieve this multiple attachment is described in 110 [I-D.ietf-netext-logical-interface-support], which allows the mobile 111 node supporting traffic flows on different physical interfaces 112 regardless of the assigned prefixes on those physical interfaces. 114 In particular, this document specifies how to enable "flow mobility" 115 in the PMIPv6 network (i.e., local mobility anchors and mobile access 116 gateways). In order to do so, two main operations are required: i) 117 proper prefix management by the PMIPv6 network, ii) consistent flow 118 forwarding policies. This memo analyzes different potential use case 119 scenarios, involving different prefix assignment requirements, and 120 therefore different PMIPv6 network extensions to enable "flow 121 mobility". 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC2119 [RFC2119]. 129 The following terms used in this document are defined in the Proxy 130 Mobile IPv6 [RFC5213]: 132 Local Mobility Agent (LMA). 134 Mobile Access Gateway (MAG). 136 Proxy Mobile IPv6 Domain (PMIPv6-Domain). 138 LMA Address (LMAA). 140 Proxy Care-of Address (Proxy-CoA). 142 Home Network Prefix (HNP). 144 The following terms used in this document are defined in the Multiple 145 Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile 146 IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]: 148 Binding Identification Number (BID). 150 Flow Identifier (FID). 152 Traffic Selector (TS). 154 The following terms are defined and used in this document: 156 FMI (Flow Mobility Initiate). Message sent by the LMA to the MAG 157 conveying the information required to enable flow mobility in a 158 PMIPv6-Domain. This message is only needed when the prefixes 159 initially assigned by the different MAGs to the mobile node are 160 different. 162 FMA (Flow Mobility Acknowledgement). Message sent by the MAG in 163 reply to an FMI message. 165 FMC (Flow Mobility Cache). Conceptual data structure maintained by 166 the LMA and the MAG to support the flow mobility management 167 operations described in this document. 169 3. Overview of the PMIPv6 flow mobility extensions 171 3.1. Use case scenarios 173 In contrast to a typical handover where connectivity to a physical 174 medium is relinquished and then re-established, flow mobility assumes 175 a mobile node can have simultaneous access to more than one network. 176 In this specification, it is assumed that the local mobility anchor 177 is aware of the mobile node's capabilities to have simultaneous 178 access to both access networks and it can handle the same or a 179 different set of prefixes on each access. How this is done is 180 outside the scope of this specification. 182 There are different flow mobility scenarios. In some of them the 183 mobile node might share a common set of prefixes among all its 184 physical interfaces, whereas in others the mobile node might have a 185 different subset of prefixes configured on each of the physical 186 interfaces. The different scenarios are the following: 188 1. At the time of a new network attachment, the MN obtains the same 189 prefix or the same set of prefixes as already assigned to an 190 existing session. This is not the default behavior with basic 191 PMIPv6 [RFC5213], and the LMA needs to be able to provide the 192 same assignment even for the simultaneous attachment (as opposed 193 to the handover scenario only). 195 2. At the time of a new network attachment, the MN obtains a new 196 prefix or a new set of prefixes for the new session. This is the 197 default behavior with basic PMIPv6 [RFC5213]. 199 A combination of the two above-mentioned scenarios is also possible. 200 At the time of a new network attachment, the MN obtains a combination 201 of prefix(es) in use and new prefix(es). This is a hybrid of the two 202 scenarios described before. The local policy determines whether the 203 new prefix is exclusive to the new attachment or it can be assigned 204 to an existing attachment as well. 206 The operational description of how to enable flow mobility in each of 207 these scenarios is provided in Section 3.2.1 and Section 3.2.2. 209 The extensions described in this document support all the 210 aforementioned scenarios. 212 3.2. Basic Operation 214 This section describes how the PMIPv6 extensions described in this 215 document enable flow mobility support. 217 Both the mobile node and the local mobility anchor MUST have local 218 policies in place to ensure that packets are forwarded coherently for 219 unidirectional and bidirectional communications. The details about 220 how this consistency is ensured are out of the scope of this 221 document. The MN makes the final IP flow mobility decision, and then 222 the LMA follows that decision and update its forwarding state 223 accordingly. Note that this does not prevent network initiated 224 mobility, the network still could trigger mobility on the MN side via 225 out-of-band mechanisms (e.g., 3GPP/ANDSF sends updated routing 226 policies to the MN). In a given scenario and mobile node, the 227 decision on IP flow mobility MUST be taken either by the MN or the 228 LMA, but not by both. 230 3.2.1. MN sharing a common set of prefixes on all MAGs 232 This scenario corresponds to the first use case scenario described in 233 Section 3.1. Extensions to basic PMIPv6 [RFC5213] signaling at the 234 time of a new attachment are needed to ensure that the same prefix 235 (or set of prefixes) is assigned to all the interfaces of the same 236 mobile node that are simultaneously attached. Subsequently, no 237 further signaling is necessary between the local mobility anchor and 238 the mobile access gateway and flows are forwarded according to policy 239 rules on the local mobility anchor and the mobile node. 241 If the local mobility anchor assigns a common prefix (or set of 242 prefixes) to the different physical interfaces attached to the 243 domain, then every MAG already has all the routing knowledge required 244 to forward uplink or downlink packets, and the local mobility anchor 245 does not need to send any kind of signaling in order to move flows 246 across the different physical interfaces. 248 The local mobility anchor needs to know when to assign the same set 249 of prefixes to all the different physical interfaces of the mobile 250 node. This can be achieved by different means, such as policy 251 configuration, default policies, etc. In this document a new Handoff 252 Indicator (HI) value ("Attachment over a new interface sharing 253 prefixes", value {IANA-0}) is defined, to allow the mobile access 254 gateway indicate to the local mobility anchor that the same set of 255 prefixes MUST be assigned to the mobile node. The considerations of 256 Section 5.4.1 of [RFC5213] are updated by this specification as 257 follows: 259 o If there is at least one Home Network Prefix option present in the 260 request with a NON_ZERO prefix value, there exists a Binding Cache 261 entry (with one all home network prefixes in the Binding Cache 262 entry matching the prefix values of all Home Network Prefix 263 options of the received Proxy Binding Update message), and the 264 entry matches the mobile node identifier in the Mobile Node 265 Identifier option of the received Proxy Binding Update message, 266 and the value of the Handoff Indicator of the received Proxy 267 Binding Update is equal to "Attachment over a new interface 268 sharing prefixes". 270 1. If there is an MN-LL-Identifier Option present in the request 271 and the Binding Cache entry matches the Access Technology Type 272 (ATT), and MN-LL-Identifier, the request MUST be considered as 273 a request for updating that Binding Cache entry. 275 2. If there is an MN-LL-Identifier Option present in the request 276 and the Binding Cache entry does not match the Access 277 Technology Type (ATT), and MN-LL-Identifier, the request MUST 278 be considered as a request for creating a new mobility session 279 sharing the same set of Home Network Prefixes assigned to the 280 existing Binding Cache entry found. 282 3. If there is not an MN-LL-Identifier Option present in the 283 request, the request MUST be considered as a request for 284 creating a new mobility session sharing the same set of Home 285 Network Prefixes assigned to the existing Binding Cache entry 286 found. 288 LMA Binding Cache 289 +---+ ======================= 290 |LMA| MN1, if1, pref1, MAG1 291 +---+ MN1, if2, pref1, MAG2 292 //\\ 293 +---------//--\\-------------+ 294 ( // \\ ) PMIPv6 domain 295 ( // \\ ) 296 +------//--------\\----------+ 297 // \\ 298 // \\ 299 +----+ +----+ 300 |MAG1| |MAG2| 301 +----+ +----+ 302 | | 303 | +-------+ | 304 | | I P | | 305 | +---+---+ | 306 |---|if1|if2|----| 307 +---+---+ 308 MN1 310 Figure 1: Shared prefix across physical interfaces scenario 312 Next, an example of how flow mobility works in this case is shown. 313 In Figure 1, a mobile node (MN1) has two different physical 314 interfaces (if1 and if2). Each physical interface is attached to a 315 different mobile access gateway, both of them controlled by the same 316 local mobility anchor. Both physical interfaces are assigned the 317 same prefix (pref1) upon attachment to the MAGs. If the IP layer at 318 the mobile node shows one single logical interface (e.g., as 319 described in [I-D.ietf-netext-logical-interface-support]), then the 320 mobile node has one single IPv6 address configured at the IP layer: 321 pref1::mn1. Otherwise, per interface IPv6 addresses (e.g., 322 pref1::if1 and pref1::if2) would be configured; each address MUST be 323 valid on every interface. We assume the first case in the following 324 example (and in the rest of this document). Initially, flow X goes 325 through MAG1 and flow Y through MAG2. At certain point, flow Y can 326 be moved to also go through MAG1. As shown in Figure 2, no signaling 327 between the local mobility anchor and the mobile access gateways is 328 needed. 330 Note that if different IPv6 addresses are configured at the IP layer, 331 IP session continuity is still possible (for each of the configured 332 IP addresses). This is achieved by the network delivering packets 333 destined to a particular IP address of the mobile node to the right 334 MN's physical interface where the flow is selected to be moved, and 335 the MN also selecting the same interface when sending traffic back up 336 link. 338 +-----+ +------+ +------+ +-----+ 339 Internet | LMA | | MAG1 | | MAG2 | | MN1 | 340 +-----+ +------+ +------+ +-----+ 341 | | | | | 342 | flow X to | flow X to | flow X to | 343 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 344 |<----------->|<------------->|<-------------------------->if1 345 | flow Y to | flow Y to | flow Y to | 346 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 347 |<----------->|<----------------------------->|<---------->if2 348 | | | | | 349 | ============ | | ============ 350 | || flow || | | || flow || 351 | || policy || | | || policy || 352 | || update || | | || update || 353 | ============ | | ============ 354 | | | | | 355 | flow Y to | flow Y to | flow Y to | 356 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 357 |<----------->|<------------->|<-------------------------->if1 358 | | | | | 360 Figure 2: Flow mobility message sequence with common set of prefixes 362 Figure 3 shows the state of the different network entities after 363 moving flow Y in the previous example. This document re-uses some of 364 the terminology and mechanisms of the flow bindings and multiple 365 care-of address registration specifications. Note, that in this case 366 the BIDs shown in the figure are assigned locally by the LMA, since 367 there is no signaling required in this scenario. In any case, 368 alternative implementations of flow routing at the LMA MAY be used, 369 as it does not impact on the operation of the solution in this case. 371 LMA Binding Cache LMA flowmob state 372 (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) 373 +---+ ========================== =================== 374 |LMA| 1, MN1, if1, pref1, MAG1 1, flow X 375 +---+ 2, MN1, if2, pref1, MAG2 1, flow Y 376 //\\ 377 +---------//--\\-------------+ 378 ( // \\ ) PMIPv6 domain 379 ( // \\ ) 380 +------//--------\\----------+ 381 // \\ 382 // \\ MAG1 routing state 383 +----+ +----+ ================================ 384 |MAG1| |MAG2| (dest) (next hop) 385 +----+ +----+ pref1::/64 p2p-iface-with-MN1 386 | | ::/0 LMA 387 | | 388 | | MAG2 routing state 389 | +-------+ | ================================ 390 | | I P | | (dest) (next hop) 391 | +---+---+ | pref1::/64 p2p-iface-with-MN1 392 |---|if1|if2|----| ::/0 LMA 393 +---+---+ 394 MN1 396 Figure 3: Data structures with common set of prefixes 398 3.2.2. MN with different sets of prefixes on each MAG 400 A different flow mobility scenario happens when the local mobility 401 anchor assigns different sets of prefixes to physical interfaces of 402 the same mobile node. This covers the second case, or a combination 403 of scenarios, described in Section 3.1. In this case, additional 404 signaling is required between the local mobility anchor and the 405 mobile access gateway to enable relocating flows between the 406 different attachments, so the MAGs are aware of the prefixes for 407 which the MN is going to receive traffic, and local routing entries 408 are configured accordingly. 410 Two different, but related, approaches are considered next. 412 The first approach corresponds to the second use case scenario 413 described in Section 3.1, in which a multi-interfaced mobile node 414 obtains a different set of prefixes on each attachment. Signaling is 415 required when a flow is to be moved from its original interface to a 416 new one. Since the local mobility anchor cannot send a PBA message 417 which has not been triggered in response to a received PBU message, 418 the solution defined in this specification makes use of two mobility 419 messages: Flow Mobility Indication and Flow Mobility Acknowledgement, 420 which actually use the format of the Update Notifications for Proxy 421 Mobile IPv6 defined in [RFC7077]. The trigger for the flow movement 422 can be on the mobile node (e.g., by using layer-2 signaling with the 423 MAG) or on the network (e.g., based on congestion and measurements) 424 which then notifies the MN for the final IP flow mobility decision 425 (as stated in section 3.1). Policy management function (e.g., 3GPP/ 426 ANDSF) can be used for that purpose, however, how the network notify 427 the MN is out of the scope of this document. 429 If the flow is being moved from its default path (which is determined 430 by the destination prefix) to a different one, the local mobility 431 anchor constructs an Flow Mobility Indication (FMI) message. This 432 message includes a Home Network Prefix for each of the prefixes that 433 requested to be provided with flow mobility support on the new MAG 434 (note that these prefixes are not anchored by the target MAG, and 435 therefore the MAG MUST NOT advertise them on the MAG-MN link), with 436 the off-link bit (L) set to one. This message MUST be sent to the 437 new target mobile access gateway, i.e. the one selected to be used in 438 the forwarding of the flow. The MAG replies with a Flow Mobility 439 Ackwnoledgement (FMA). The message sequence is shown in Figure 4. 441 +-----+ +------+ +------+ +-----+ 442 Internet | LMA | | MAG1 | | MAG2 | | MN1 | 443 +-----+ +------+ +------+ +-----+ 444 | | | | | 445 | flow X to | flow X to | flow X to | 446 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 447 |<----------->|<------------->|<-------------------------->if1 448 | flow Y to | flow Y to | flow Y to | 449 | pref2::mn1 | pref2::mn1 | pref2::mn1 | 450 |<----------->|<----------------------------->|<---------->if2 451 | | | | | 452 | ============ | | ============ 453 | || flow || | | || flow || 454 | || policy || | | || policy || 455 | || update || | | || update || 456 | ============ | | ============ 457 | | | | | 458 | | FMI[MN1-ID, HNPs] | | 459 | |-------------->| | | 460 | | FMA | | | 461 | |<--------------| | | 462 | flow Y to | flow Y to | flow Y to | 463 | pref2::mn1 | pref2::mn1 | pref2::mn1 | 464 |<----------->|<------------->|<-------------------------->if1 465 | | | | | 467 Figure 4: Flow mobility message sequence when the LMA assigns 468 different sets of prefixes per physical interface 470 The state in the network after moving a flow, for the case the LMA 471 assigns a different set of prefixes is shown in Figure 5. 473 LMA Binding Cache LMA flowmob state 474 (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) 475 +---+ ============================ =================== 476 |LMA| 1, MN1, if1, pref1, 1, flow X 477 +---+ pref2, MAG1 1, flow Y 478 //\\ 2, MN1, if2, pref2, MAG2 479 +---------//--\\-------------+ 480 ( // \\ ) PMIPv6 domain 481 ( // \\ ) 482 +------//--------\\----------+ 483 // \\ 484 // \\ MAG1 routing state 485 +----+ +----+ ================================ 486 |MAG1| |MAG2| (dest) (next hop) 487 +----+ +----+ pref1::/64 p2p-iface-with-MN1 488 | | pref2::/64 p2p-iface-with-MN1 489 | | ::/0 LMA 490 | | 491 | +-------+ | MAG2 routing state 492 | | I P | | ================================ 493 | +---+---+ | (dest) (next hop) 494 |---|if1|if2|----| pref2::/64 p2p-iface-with-MN1 495 +---+---+ ::/0 LMA 496 MN1 498 Figure 5: Data structures when the LMA assigns a different set of 499 prefixes 501 The second approach corresponds to the combination of the two prefix 502 management models described in Section 3.1, in which upon new 503 physical interface attachment, the MN obtains both prefix(es) in use 504 and new prefix(es). Here, the mobile node is already attached to the 505 PMIPv6-Domain via MAG1. At a certain moment, the mobile node 506 attaches a new interface (if2) to MAG2. MAG2 sends a PBU which is 507 then used by the LMA to enable flow mobility. In this case, we 508 consider that flows are moved with a prefix granularity, meaning that 509 flows are moved by moving prefixes among the different MAGs the 510 mobile node is attached to. In this example, flow Y is bound to 511 pref2::/64 and therefore the flow can be moved by just binding 512 pref2::/64 to MAG2. This is done by including the prefix in the PBA 513 message. The scenario is shown in Figure 6. 515 Optionally, a Binding Revocation Indication message [RFC5846] with 516 the P bit set MAY be sent to MAG1 to indicate that this is a 517 revocation of PMIP prefix(es). After processing BRI, the source MAG 518 MUST send a Binding Revocation Acknowledgement (BRA) message back to 519 the LMA. 521 +-----+ +------+ +------+ +-----+ 522 Internet | LMA | | MAG1 | | MAG2 | | MN | 523 +-----+ +------+ +------+ +-----+ 524 | | | | | 525 | flow X to | flow X to | flow X to | 526 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 527 |<----------->|<--------------->|<-------------------------->if1 528 | flow Y to | flow Y to | flow Y to | 529 | pref2::mn1 | pref2::mn1 | pref2::mn1 | 530 |<----------->|<--------------->|<-------------------------->if1 531 | | | | | 532 | | | | | 533 | | | MN powers on if2 and 534 | | | performs L2 attachment 535 | | | |<-----------if2 536 | | | PBU | | 537 | |<--------------------------------| | 538 | | PBA (pref2) | | | 539 | |-------------------------------->| | 540 | LMA moves pref2 to new | | | 541 | binding cache entry for if2 | | | 542 | | | | | 543 | flow y to | flow y to | flow y to | 544 | pref2::mn1 | pref2::mn1 | pref2::mn1 | 545 |<----------->|<------------------------------->|<---------->if2 546 | | | | | 547 | | (optional) | | | 548 | | BRI[pref2] | | | 549 | |---------------->| | | 550 | | BRA | | | 551 | |<----------------| | | 552 | | | | | 554 Figure 6: Flow mobility message sequence with different set of 555 prefixes per physical interface (PBU signaling) 557 4. Message Formats 559 This section defines modifications to the Proxy Mobile IPv6 [RFC5213] 560 protocol messages. 562 4.1. Home Network Prefix 564 A new flag (L) is included in the Home Network Prefix mobility option 565 to indicate to the Mobile Access Gateway whether the conveyed prefix 566 has to be hosted on-link or not on the point-to-point interface with 567 the mobile node. A prefix is hosted off-link for the flow mobility 568 purposes defined in this document. The rest of the Home Network 569 Prefix mobility option format remains the same as defined in 570 [RFC5213]. 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Type | Length |L| Reserved | Prefix Length | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | | 578 + + 579 | | 580 + Home Network Prefix + 581 | | 582 + + 583 | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Off-link Home Network Prefix Flag (L): 588 The Off-link Home Network Prefix Flag is set to indicate to the 589 Mobile Access Gateway that the Home Network Prefix conveyed in the 590 option is not to be hosted on-link, but has to be considered for 591 flow mobility purposes and therefore added to the Mobile Access 592 Gateway routing table. If the flag is set to 0, the Mobile Access 593 Gateway assumes that the Home Network Prefix has to be hosted on- 594 link. 596 4.2. Flow Mobility Initiate (FMI) 598 The FMI message (Figure 7) used in this specification is the Update 599 Notification (UPN) messages specified in [RFC7077]. The message 600 format, transport and security consideration are as specified in 601 [RFC7077]. The format of the message is specified in Section 4.1 of 602 [RFC7077] and is shown below for completeness. This specification 603 does not modify the UPN message, however, it defines a new 604 Notification Reason value for use in this specification. 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Sequence # | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Notification Reason |A|D| Reserved | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | | 614 . . 615 . Mobility options . 616 . . 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Figure 7: Flow Mobility Initiate message format 622 This document defines the following new Notification Reason value for 623 use in Update Notification message: 625 Notification Reason: 627 {IANA-1} - FLOW-MOBILITY-ADD. Request to add the prefix(es) 628 conveyed in the home network prefix mobility options included in 629 the message to the set of prefixes for which flow mobility is 630 provided. 632 {IANA-2} - FLOW-MOBILITY-REMOVE. Request to remove the prefix(es) 633 conveyed in the home network prefix mobility options included in 634 the message to the set of prefixes for which flow mobility is 635 provided. 637 The Mobility Options field of an FMI MUST contain the MN-ID, followed 638 by one or more Home Network Prefixes Mobility options. 640 4.3. Flow Mobility Acknowledgement (FMA) 642 The FMA message (Figure 8) used in this specification is the Update 643 Notification Ack (UPA) messages specified in Section 4.2 of 644 [RFC7077]. The message format, transport and security consideration 645 are as specified in [RFC7077]. The format of the message is 646 specified in Section 4.2 of [RFC7077] and is shown below here for 647 completeness. This specification does not modify the UPA message, 648 however, it defines a new Status value for use in this specification. 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Sequence # | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Status Code | Reserved | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | | 658 . . 659 . Mobility options . 660 . . 661 | | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 Figure 8: Flow Mobility Acknowledgement message format 666 This document defines the following new status code values for use in 667 Update Notification Acknowledgement message. 669 Status Code: 671 0: Success. 673 {IANA-3}: Reason unspecified. 675 {IANA-4}: MN not attached. 677 {IANA-5}: No existing Flow Mobility Cache entry. 679 When Status code is 0. the Mobility Options field of an FMA MUST 680 contain the MN-ID, followed by one or more Home Network Prefixes 681 Mobility options. 683 5. Conceptual Data Structures 685 This section summarizes the extensions to Proxy Mobile IPv6 that are 686 necessary to manage flow mobility. 688 5.1. Multiple Proxy Care-of Address Registration 690 The binding cache structure of the local mobility anchor is extended 691 to allow multiple proxy care of address (Proxy-CoA) registrations, 692 and support the mobile node use the same address (prefix) beyond a 693 single interface and mobile access gateway. The LMA maintains 694 multiple binding cache entries for an MN. The number of binding 695 cache entries for a mobile node is equal to the number of the MN's 696 interfaces attached to any MAGs. 698 This specification re-uses the extensions defined in [RFC5648] to 699 manage multiple registrations, but in the context of Proxy Mobile 700 IPv6. The binding cache is therefore extended to include more than 701 one proxy care-of addresses and to associate each of them with a 702 binding identifier (BID). Note that the BID is a local identifier, 703 assigned and used by the local mobility anchor to identify which 704 entry of the flow mobility cache is used to decide how to route a 705 given flow. 707 +---------+-----+-------+------+-----------+------------+ 708 | BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | 709 +---------+-----+-------+------+-----------+------------+ 710 | 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) | 711 | 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) | 712 +---------+-----+-------+------+-----------+------------+ 714 Figure 9: Extended Binding Cache 716 Figure 9 shows an example of extended binding cache, containing two 717 binding cache entries (BCEs) of a mobile node MN1 attached to the 718 network using two different access technologies. Both of the two 719 attachments share the same prefix (HNP1) and are bounded to two 720 different Proxy-CoAs (two MAGs). 722 5.2. Flow Mobility Cache 724 Each local mobility anchor MUST maintain a flow mobility cache (FMC) 725 as shown in Figure 10. The flow mobility cache is a conceptual list 726 of entries that is separate from the binding cache. This conceptual 727 list contains an entry for each of the registered flows. This 728 specification re-uses the format of the flow binding list defined in 729 [RFC6089]. Each enty includes the following fields: 731 o Flow Identifier Priority (FID-PRI). 733 o Flow Identifier (FID). 735 o Traffic Selector (TS). 737 o Binding Identifier (BID). 739 o Action. 741 o Active/Inactive. 743 +---------+-----+-----+------+---------+----------+ 744 | FID-PRI | FID | TS | BIDs | Action | A/I | 745 +---------+-----+-----+------+---------+----------+ 746 | 10 | 2 | TCP | 1 | Forward | Active | 747 | 20 | 4 | UDP | 1,2 | Forward | Inactive | 748 +---------+-----+-----+------+---------+----------+ 750 Figure 10: Flow Mobility Cache 752 The BID field contains the identifier of the binding cache entry 753 which packets matching the flow information described in the TS field 754 will be forwarded to. When a flow is decided to be moved, the 755 affected BID(s) of the table are updated. 757 Similar to flow binding described in [RFC6089], each entry of the 758 flow mobility cache points to a specific binding cache entry 759 identifier (BID). When a flow is moved, the local mobility anchor 760 simply updates the pointer of the flow binding entry with the BID of 761 the interface to which the flow will be moved. The traffic selector 762 (TS) in flow binding table is defined as in [RFC6088]. TS is used to 763 classify the packets of flows basing on specific parameters such as 764 service type, source and destination address, etc. The packets 765 matching with the same TS will be applied the same forwarding policy. 766 FID-PRI is the order of precedence to take action on the traffic. 767 Action may be forward or drop. If a binding entry becomes 'Inactive' 768 it does not affect data traffic. An entry becomes 'Inactive' only if 769 all of the BIDs are deregistered. 771 The mobile access gateway MAY also maintain a similar data structure. 772 In case no full flow mobility state is required at the MAG, the 773 Binding Update List (BUL) data structure is enough and no extra 774 conceptual data entries are needed. In case full per-flow state is 775 required at the mobile access gateway, it SHOULD also maintain a flow 776 mobility cache structure. 778 6. Mobile Node considerations 780 This specification assumes that the mobile node IP layer interface 781 can simultaneously and/or sequentially attach to multiple MAGs, 782 possibly over multiple media. The mobile node MUST be able to 783 enforce uplink policies to select the right outgoing interface. One 784 form to achieve this multiple attachment is described in 785 [I-D.ietf-netext-logical-interface-support], which allows the mobile 786 node supporting traffic flows on different physical interfaces 787 regardless of the assigned prefixes on those physical interfaces. 789 7. IANA Considerations 791 This specification defines new value for the Handoff Indicator 792 {IANA-0} and a new flag (L) in the Home Network Mobility Option. New 793 Notification Reason values for use in Update Notification message 794 ({IANA-1} and {IANA-2}) and new Status Values for use in Update 795 Acknowledgement message ({IANA-3} to {IANA-5}) are also defined.. 797 8. Security Considerations 799 The protocol signaling extensions defined in this document share the 800 same security concerns of Proxy Mobile IPv6 [RFC5213] and do not pose 801 any additional security threats to those already identified in 802 [RFC5213] and [RFC7077]. 804 The mobile access gateway and the local mobility anchor MUST use the 805 IPsec security mechanism mandated by Proxy Mobile IPv6 [RFC5213] to 806 secure the signaling described in this document. 808 9. Authors 810 This document reflects contributions from the following authors (in 811 alphabetical order). 813 Kuntal Chowdhury 815 E-mail: Kchowdhu@cisco.com 817 Vijay Devarapalli 819 E-mail: vijay@wichorus.com 821 Sri Gundavelli 823 E-mail: sgundave@cisco.com 825 Youn-Hee Han 827 E-mail: yhhan@kut.ac.kr 829 Yong-Geun Hong 831 E-mail: yonggeun.hong@gmail.com 833 Mohana Dahamayanthi Jeyatharan 835 E-mail: mohana.jeyatharan@sg.panasonic.com 837 Rajeev Koodli 839 E-mail: rkoodli@cisco.com 841 Kent Leung 843 E-mail: kleung@cisco.com 845 Telemaco Melia 847 E-mail: Telemaco.Melia@alcatel-lucent.com 849 Bruno Mongazon-Cazavet 851 E-mail: Bruno.Mongazon-Cazavet@alcatel-lucent.com 853 Chan-Wah Ng 855 E-mail: chanwah.ng@sg.panasonic.com 857 Behcet Sarikaya 859 E-mail: sarikaya@ieee.org 861 Tran Minh Trung 863 E-mail: trungtm2909@gmail.com 865 Frank Xia 867 E-mail: xiayangsong@huawei.com 869 10. Acknowledgments 871 The authors would like to thank Juan-Carlos Zuniga, Pierrick Seite, 872 Julien Laganier for all the useful discussions on this topic. 874 The authors would also like to thank Marco Liebsch and Juan-Carlos 875 Zuniga for their reviews of this document. 877 The work of Carlos J. Bernardos has also been partially supported by 878 the European Community's Seventh Framework Programme under grant 879 agreement n. FP7-317941 (iJOIN project). 881 11. References 883 11.1. Normative References 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", BCP 14, RFC 2119, March 1997. 888 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 889 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 891 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 892 and K. Nagami, "Multiple Care-of Addresses Registration", 893 RFC 5648, October 2009. 895 [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., 896 and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC 897 5846, June 2010. 899 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 900 "Traffic Selectors for Flow Bindings", RFC 6088, January 901 2011. 903 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 904 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 905 Network Mobility (NEMO) Basic Support", RFC 6089, January 906 2011. 908 [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and 909 J. Korhonen, "Update Notifications for Proxy Mobile IPv6", 910 RFC 7077, November 2013. 912 11.2. Informative References 914 [I-D.ietf-netext-logical-interface-support] 915 Melia, T. and S. Gundavelli, "Logical Interface Support 916 for multi-mode IP Hosts", draft-ietf-netext-logical- 917 interface-support-09 (work in progress), March 2014. 919 Author's Address 920 Carlos J. Bernardos (editor) 921 Universidad Carlos III de Madrid 922 Av. Universidad, 30 923 Leganes, Madrid 28911 924 Spain 926 Phone: +34 91624 6236 927 Email: cjbc@it.uc3m.es 928 URI: http://www.it.uc3m.es/cjbc/