idnits 2.17.1 draft-ietf-netext-pmipv6-flowmob-16.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 (January 8, 2016) is 3031 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-12 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 January 8, 2016 5 Expires: July 11, 2016 7 Proxy Mobile IPv6 Extensions to Support Flow Mobility 8 draft-ietf-netext-pmipv6-flowmob-16 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 of 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 July 11, 2016. 47 Copyright Notice 49 Copyright (c) 2016 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 3.3. Use of PBU/PBA signaling . . . . . . . . . . . . . . . . 11 75 3.4. Use of flow-level information . . . . . . . . . . . . . . 12 76 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.1. Home Network Prefix . . . . . . . . . . . . . . . . . . . 12 78 4.2. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . 13 79 4.3. Flow Mobility Acknowledgement (FMA) . . . . . . . . . . . 14 80 5. Conceptual Data Structures . . . . . . . . . . . . . . . . . 15 81 5.1. Multiple Proxy Care-of Address Registration . . . . . . . 15 82 5.2. Flow Mobility Cache . . . . . . . . . . . . . . . . . . . 16 83 6. Mobile Node considerations . . . . . . . . . . . . . . . . . 17 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 90 11.2. Informative References . . . . . . . . . . . . . . . . . 20 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network 96 based mobility management to hosts connecting to a PMIPv6 domain. 97 PMIPv6 introduces two new functional entities, the Local Mobility 98 Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the 99 entity detecting the Mobile Node's (MN) attachment and providing IP 100 connectivity. The LMA is the entity assigning one or more Home 101 Network Prefixes (HNP) to the MN and is the topological anchor for 102 all traffic belonging to the MN. 104 PMIPv6 allows a mobile node to connect to the same PMIPv6 domain 105 through different interfaces. This document specifies protocol 106 extensions to Proxy Mobile IPv6 between the local mobility anchor and 107 mobile access gateways to enable "flow mobility" and hence distribute 108 specific traffic flows on different physical interfaces. It is 109 assumed that the mobile node IP layer interface can simultaneously 110 and/or sequentially attach to multiple MAGs, possibly over multiple 111 media. One form to achieve this multiple attachment is described in 112 [I-D.ietf-netext-logical-interface-support], which allows the mobile 113 node supporting traffic flows on different physical interfaces 114 regardless of the assigned prefixes on those physical interfaces. 116 In particular, this document specifies how to enable "flow mobility" 117 in the PMIPv6 network (i.e., local mobility anchors and mobile access 118 gateways). In order to do so, two main operations are required: i) 119 proper prefix management by the PMIPv6 network, and, ii) consistent 120 flow forwarding policies. This memo analyzes different potential use 121 case scenarios, involving different prefix assignment requirements, 122 and therefore different PMIPv6 network extensions to enable "flow 123 mobility". 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC2119 [RFC2119]. 131 The following terms used in this document are defined in the Proxy 132 Mobile IPv6 [RFC5213]: 134 Local Mobility Agent (LMA). 136 Mobile Access Gateway (MAG). 138 Proxy Mobile IPv6 Domain (PMIPv6-Domain). 140 LMA Address (LMAA). 142 Proxy Care-of Address (Proxy-CoA). 144 Home Network Prefix (HNP). 146 The following terms used in this document are defined in the Multiple 147 Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile 148 IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]: 150 Binding Identification Number (BID). 152 Flow Identifier (FID). 154 Traffic Selector (TS). 156 The following terms are defined and used in this document: 158 FMI (Flow Mobility Initiate). Message sent by the LMA to the MAG 159 conveying the information required to enable flow mobility in a 160 PMIPv6-Domain. 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 to support the 166 flow mobility management operations described in this document. 168 3. Overview of the PMIPv6 flow mobility extensions 170 3.1. Use case scenarios 172 In contrast to a typical handover where connectivity to a physical 173 medium is relinquished and then re-established, flow mobility assumes 174 a mobile node can have simultaneous access to more than one network. 175 In this specification, it is assumed that the local mobility anchor 176 is aware of the mobile node's capabilities to have simultaneous 177 access to both access networks and it can handle the same or a 178 different set of prefixes on each access. How this is done is 179 outside the scope of this specification. 181 There are different flow mobility scenarios. In some of them the 182 mobile node might share a common set of prefixes among all its 183 physical interfaces, whereas in others the mobile node might have a 184 different subset of prefixes configured on each of the physical 185 interfaces. The different scenarios are the following: 187 1. At the time of a new network attachment, the MN obtains the same 188 prefix or the same set of prefixes as already assigned to an 189 existing session. This is not the default behavior with basic 190 PMIPv6 [RFC5213], and the LMA needs to be able to provide the 191 same assignment even for the simultaneous attachment (as opposed 192 to the handover scenario only). 194 2. At the time of a new network attachment, the MN obtains a new 195 prefix or a new set of prefixes for the new session. This is the 196 default behavior with basic PMIPv6 [RFC5213]. 198 A combination of the two above-mentioned scenarios is also possible. 199 At the time of a new network attachment, the MN obtains a combination 200 of prefix(es) in use and new prefix(es). This is a hybrid of the two 201 scenarios described before. The local policy determines whether the 202 new prefix is exclusive to the new attachment or it can be assigned 203 to an existing attachment as well. 205 The operational description of how to enable flow mobility in each of 206 these scenarios is provided in Section 3.2.1 and Section 3.2.2. 208 The extensions described in this document support all the 209 aforementioned scenarios. 211 3.2. Basic Operation 213 This section describes how the PMIPv6 extensions described in this 214 document enable flow mobility support. 216 Both the mobile node and the local mobility anchor MUST have local 217 policies in place to ensure that packets are forwarded coherently for 218 unidirectional and bidirectional communications. The details about 219 how this consistency is ensured are out of the scope of this 220 document. The MN makes the final IP flow mobility decision, and then 221 the LMA follows that decision and updates its forwarding state 222 accordingly. Note that this does not prevent network initiated 223 mobility, the network still could trigger mobility on the MN side via 224 out-of-band mechanisms (e.g., 3GPP/ANDSF sends updated routing 225 policies to the MN). In a given scenario and mobile node, the 226 decision on IP flow mobility MUST be taken either by the MN or the 227 LMA, but MUST NOT be taken by both. 229 3.2.1. MN sharing a common set of prefixes on all MAGs 231 This scenario corresponds to the first use case scenario described in 232 Section 3.1. Extensions to basic PMIPv6 [RFC5213] signaling at the 233 time of a new attachment are needed to ensure that the same prefix 234 (or set of prefixes) is assigned to all the interfaces of the same 235 mobile node that are simultaneously attached. Subsequently, no 236 further signaling is necessary between the local mobility anchor and 237 the mobile access gateway and flows are forwarded according to policy 238 rules on the local mobility anchor and the mobile node. 240 If the local mobility anchor assigns a common prefix (or set of 241 prefixes) to the different physical interfaces attached to the 242 domain, then every MAG already has all the routing knowledge required 243 to forward uplink or downlink packets after the PBU/PBA registration 244 for each MAG, and the local mobility anchor does not need to send any 245 kind of signaling in order to move flows across the different 246 physical interfaces (because moving flows is a local decision of the 247 LMA). Optionally, signaling MAY be exchanged in case the MAG needs 248 to know about flow level information (e.g., to link flows with proper 249 QoS paths and/or inform the mobile node) [RFC7222]. 251 The local mobility anchor needs to know when to assign the same set 252 of prefixes to all the different physical interfaces of the mobile 253 node. This can be achieved by different means, such as policy 254 configuration, default policies, etc. In this document a new Handoff 255 Indicator (HI) value ("Attachment over a new interface sharing 256 prefixes", value {IANA-0}) is defined, to allow the mobile access 257 gateway to indicate to the local mobility anchor that the same set of 258 prefixes MUST be assigned to the mobile node. The considerations of 259 Section 5.4.1 of [RFC5213] are updated by this specification as 260 follows: 262 o If there is at least one Home Network Prefix option present in the 263 request with a NON_ZERO prefix value, there exists a Binding Cache 264 entry (with all home network prefixes in the Binding Cache entry 265 matching the prefix values of all Home Network Prefix options of 266 the received Proxy Binding Update message), and the entry matches 267 the mobile node identifier in the Mobile Node Identifier option of 268 the received Proxy Binding Update message, and the value of the 269 Handoff Indicator of the received Proxy Binding Update is equal to 270 "Attachment over a new interface sharing prefixes". 272 1. If there is an MN-LL-Identifier Option present in the request 273 and the Binding Cache entry matches the Access Technology Type 274 (ATT), and MN-LL-Identifier, the request MUST be considered as 275 a request for updating that Binding Cache entry. 277 2. If there is an MN-LL-Identifier Option present in the request 278 and the Binding Cache entry does not match the Access 279 Technology Type (ATT), and MN-LL-Identifier, the request MUST 280 be considered as a request for creating a new mobility session 281 sharing the same set of home network prefixes assigned to the 282 existing Binding Cache entry found. 284 3. If there is not an MN-LL-Identifier Option present in the 285 request, the request MUST be considered as a request for 286 creating a new mobility session sharing the same set of home 287 network prefixes assigned to the existing Binding Cache entry 288 found. 290 LMA Binding Cache 291 +---+ ======================= 292 |LMA| MN1, if1, pref1, MAG1 293 +---+ MN1, if2, pref1, MAG2 294 //\\ 295 +---------//--\\-------------+ 296 ( // \\ ) PMIPv6 domain 297 ( // \\ ) 298 +------//--------\\----------+ 299 // \\ 300 // \\ 301 +----+ +----+ 302 |MAG1| |MAG2| 303 +----+ +----+ 304 | | 305 | +-------+ | 306 | | I P | | 307 | +---+---+ | 308 |---|if1|if2|----| 309 +---+---+ 310 MN1 312 Figure 1: Shared prefix across physical interfaces scenario 314 Next, an example of how flow mobility works in this case is shown. 315 In Figure 1, a mobile node (MN1) has two different physical 316 interfaces (if1 and if2). Each physical interface is attached to a 317 different mobile access gateway, both of them controlled by the same 318 local mobility anchor. Both physical interfaces are assigned the 319 same prefix (pref1) upon attachment to the MAGs. If the IP layer at 320 the mobile node shows one single logical interface (e.g., as 321 described in [I-D.ietf-netext-logical-interface-support]), then the 322 mobile node has one single IPv6 address configured at the IP layer: 323 pref1::mn1. Otherwise, per interface IPv6 addresses (e.g., 324 pref1::if1 and pref1::if2) would be configured; each address MUST be 325 valid on every interface. We assume the first case in the following 326 example (and in the rest of this document). Initially, flow X goes 327 through MAG1 and flow Y through MAG2. At a certain point, flow Y can 328 be moved to also go through MAG1. Figure 2 shows the scenario in 329 which no flow-level information needs to be exchanged, so there is no 330 signaling between the local mobility anchor and the mobile access 331 gateways. 333 Note that if different IPv6 addresses are configured at the IP layer, 334 IP session continuity is still possible (for each of the configured 335 IP addresses). This is achieved by the network delivering packets 336 destined to a particular IP address of the mobile node to the right 337 MN's physical interface where the flow is selected to be moved, and 338 the MN also selecting the same interface when sending traffic back up 339 link. 341 +-----+ +------+ +------+ +-----+ 342 Internet | LMA | | MAG1 | | MAG2 | | MN1 | 343 +-----+ +------+ +------+ +-----+ 344 | | | | | 345 | flow X to | flow X to | flow X to | 346 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 347 |<----------->|<------------->|<-------------------------->if1 348 | flow Y to | flow Y to | flow Y to | 349 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 350 |<----------->|<----------------------------->|<---------->if2 351 | | | | | 352 | ============ | | ============ 353 | || flow || | | || flow || 354 | || policy || | | || policy || 355 | || update || | | || update || 356 | ============ | | ============ 357 | | | | | 358 | flow Y to | flow Y to | flow Y to | 359 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 360 |<----------->|<------------->|<-------------------------->if1 361 | | | | | 363 Figure 2: Flow mobility message sequence with common set of prefixes 365 Figure 3 shows the state of the different network entities after 366 moving flow Y in the previous example. This document re-uses some of 367 the terminology and mechanisms of the flow bindings and multiple 368 care-of address registration specifications. Note that, in this case 369 the BIDs shown in the figure are assigned locally by the LMA, since 370 there is no signaling required in this scenario. In any case, 371 alternative implementations of flow routing at the LMA MAY be used, 372 as it does not impact on the operation of the solution in this case. 374 LMA Binding Cache LMA flowmob state 375 (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) 376 +---+ ========================== =================== 377 |LMA| 1, MN1, if1, pref1, MAG1 1, flow X 378 +---+ 2, MN1, if2, pref1, MAG2 1, flow Y 379 //\\ 380 +---------//--\\-------------+ 381 ( // \\ ) PMIPv6 domain 382 ( // \\ ) 383 +------//--------\\----------+ 384 // \\ 385 // \\ MAG1 routing state 386 +----+ +----+ ================================ 387 |MAG1| |MAG2| (dest) (next hop) 388 +----+ +----+ pref1::/64 p2p-iface-with-MN1 389 | | ::/0 LMA 390 | | 391 | | MAG2 routing state 392 | +-------+ | ================================ 393 | | I P | | (dest) (next hop) 394 | +---+---+ | pref1::/64 p2p-iface-with-MN1 395 |---|if1|if2|----| ::/0 LMA 396 +---+---+ 397 MN1 399 Figure 3: Data structures with common set of prefixes 401 3.2.2. MN with different sets of prefixes on each MAG 403 A different flow mobility scenario happens when the local mobility 404 anchor assigns different sets of prefixes to physical interfaces of 405 the same mobile node. This covers the second case, or a combination 406 of scenarios, described in Section 3.1. In this case, additional 407 signaling is required between the local mobility anchor and the 408 mobile access gateway to enable relocating flows between the 409 different attachments, so the MAGs are aware of the prefixes for 410 which the MN is going to receive traffic, and local routing entries 411 are configured accordingly. 413 In this case, signaling is required when a flow is to be moved from 414 its original interface to a new one. Since the local mobility anchor 415 cannot send a PBA message which has not been triggered in response to 416 a received PBU message, the solution defined in this specification 417 makes use of two mobility messages: Flow Mobility Indication and Flow 418 Mobility Acknowledgement, which actually use the format of the Update 419 Notifications for Proxy Mobile IPv6 defined in [RFC7077]. The 420 trigger for the flow movement can be on the mobile node (e.g., by 421 using layer-2 signaling with the MAG) or on the network (e.g., based 422 on congestion and measurements) which then notifies the MN for the 423 final IP flow mobility decision (as stated in section 3.1). Policy 424 management functions (e.g., 3GPP/ANDSF) can be used for that purpose, 425 however, how the network notifies the MN is out of the scope of this 426 document. 428 If the flow is being moved from its default path (which is determined 429 by the destination prefix) to a different one, the local mobility 430 anchor constructs a Flow Mobility Indication (FMI) message. This 431 message includes a Home Network Prefix option for each of the 432 prefixes that are requested to be provided with flow mobility support 433 on the new MAG (note that these prefixes are not anchored by the 434 target MAG, and therefore the MAG MUST NOT advertise them on the MAG- 435 MN link), with the off-link bit (L) set to one. This message MUST be 436 sent to the new target mobile access gateway, i.e. the one selected 437 to be used in the forwarding of the flow. The MAG replies with a 438 Flow Mobility Acknowledgement (FMA). The message sequence is shown 439 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 3.3. Use of PBU/PBA signaling 503 This specification introduces the FMI/FMA signaling so the LMA can 504 exchange with the MAG information required to enable flow mobility 505 without waiting for receiving a PBU. There are however scenarios in 506 which the trigger for flow mobility might be related to a new MN's 507 interface attachment. In this case, the PBA sent in response to the 508 PBU received from the new MAG can convey the same signaling that the 509 FMI does. In this case the LMA MUST include in the PBA a Home 510 Network Prefix option for each of the prefixes that are requested to 511 be provided with flow mobility support on the new MAG with the off- 512 link bit (L) set to one. 514 3.4. Use of flow-level information 516 This specification does not mandate flow-level information to be 517 exchanged between the LMA and the MAG to provide flow mobility 518 support. It only requires the LMA to keep flow-level state 519 (Section 5.2). However, there are scenarios in which the MAG might 520 need to know which flow(s) is/are coming within a prefix that has 521 been moved, to link it/them to proper QoS path(s) and optionally 522 inform the MN about it. This section describes the extensions used 523 to include flow-level information in the signaling defined between 524 the LMA and the MAG. 526 This specification re-uses some of the mobility extensions and 527 message formats defined in [RFC5648] and [RFC6089], namely the Flow 528 Identification Mobility Option and the Flow Mobility Sub-Options. 530 In case the LMA wants to convey flow-level information to the MAG, it 531 MUST include in the FMI (or the PBA) a Flow Identification Mobility 532 Option for all the flows that the MAG needs to be aware with flow 533 granularity. Each Flow Identification Option MUST include a Traffic 534 Selector Sub-Option including such flow-level information. 536 To remove a flow binding state at the MAG, the LMA simply sends a FMI 537 (or PBA if it is in response to a PBU) message that includes flow 538 identification options for all the flows that need to be refreshed, 539 modified, or added, and simply omits those that need to be removed. 541 Note that even if a common set of prefixes is used, providing the MAG 542 with flow-level information requires signaling to be exchanged in 543 this case between the LMA and the MAG. This is done sending a FMI 544 message (or a PBA if it is sent in response to a PBU). 546 4. Message Formats 548 This section defines modifications to the Proxy Mobile IPv6 [RFC5213] 549 protocol messages. 551 This specification requires implementation of UPN [RFC7077] and UPA 552 [RFC7077] messages with the specific Notification Reason and Status 553 Code values as defined by this document. This document does not 554 require implementation of any other aspects of [RFC7077]. 556 4.1. Home Network Prefix 558 A new flag (L) is included in the Home Network Prefix option to 559 indicate to the Mobile Access Gateway whether the conveyed prefix has 560 to be hosted on-link or not on the point-to-point interface with the 561 mobile node. A prefix is hosted off-link for the flow mobility 562 purposes defined in this document. The rest of the Home Network 563 Prefix option format remains the same as defined in [RFC5213]. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type | Length |L| Reserved | Prefix Length | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | 571 + + 572 | | 573 + Home Network Prefix + 574 | | 575 + + 576 | | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Off-link Home Network Prefix Flag (L): 581 The Off-link Home Network Prefix Flag is set to indicate to the 582 Mobile Access Gateway that the home network prefix conveyed in the 583 option is not to be hosted on-link, but has to be considered for 584 flow mobility purposes and therefore added to the Mobile Access 585 Gateway routing table. If the flag is set to 0, the Mobile Access 586 Gateway assumes that the home network prefix has to be hosted on- 587 link. 589 4.2. Flow Mobility Initiate (FMI) 591 The FMI message (Figure 6) used in this specification is the Update 592 Notification (UPN) message specified in [RFC7077]. The message 593 format, transport and security consideration are as specified in 594 [RFC7077]. The format of the message is specified in Section 4.1 of 595 [RFC7077] and is shown below for completeness. This specification 596 does not modify the UPN message, however, it defines new Notification 597 Reason values for use in this specification. 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Sequence # | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Notification Reason |A|D| Reserved | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | | 607 . . 608 . Mobility options . 609 . . 610 | | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Figure 6: Flow Mobility Initiate message format 615 This document defines the following new Notification Reason value for 616 use in Update Notification message: 618 Notification Reason: 620 {IANA-1} - FLOW-MOBILITY. Request to add/refresh the prefix(es) 621 conveyed in the Home Network Prefix options included in the 622 message to the set of prefixes for which flow mobility is 623 provided. 625 The Mobility Options field of an FMI MUST contain the MN-ID, followed 626 by one or more Home Network Prefixes options. Prefixes for which 627 flow mobility was provided that are not present in the message MUST 628 be removed from the set of flow mobility enabled prefixes. 630 4.3. Flow Mobility Acknowledgement (FMA) 632 The FMA message (Figure 7) used in this specification is the Update 633 Notification Ack (UPA) message specified in Section 4.2 of [RFC7077]. 634 The message format, transport and security consideration are as 635 specified in [RFC7077]. The format of the message is specified in 636 Section 4.2 of [RFC7077] and is shown below here for completeness. 637 This specification does not modify the UPA message, however, it 638 defines new Status Code values for use in this specification. 640 0 1 2 3 641 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 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Sequence # | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Status Code | Reserved | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | | 648 . . 649 . Mobility options . 650 . . 651 | | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Figure 7: Flow Mobility Acknowledgement message format 656 This document defines the following new status code values for use in 657 Update Notification Acknowledgement message. 659 Status Code: 661 0: Success. 663 {IANA-2}: Reason unspecified. 665 {IANA-3}: MN not attached. 667 When Status code is 0, the Mobility Options field of an FMA MUST 668 contain the MN-ID, followed by one or more Home Network Prefixes 669 options. 671 5. Conceptual Data Structures 673 This section summarizes the extensions to Proxy Mobile IPv6 that are 674 necessary to manage flow mobility. 676 5.1. Multiple Proxy Care-of Address Registration 678 The binding cache structure of the local mobility anchor is extended 679 to allow multiple proxy care-of address (Proxy-CoA) registrations, 680 and support the mobile node use the same address (prefix) beyond a 681 single interface and mobile access gateway. The LMA maintains 682 multiple binding cache entries for an MN. The number of binding 683 cache entries for a mobile node is equal to the number of the MN's 684 interfaces attached to any MAGs. 686 This specification re-uses the extensions defined in [RFC5648] to 687 manage multiple registrations, but in the context of Proxy Mobile 688 IPv6. The binding cache is therefore extended to include more than 689 one proxy care-of address and to associate each of them with a 690 binding identifier (BID). Note that the BID is a local identifier, 691 assigned and used by the local mobility anchor to identify which 692 entry of the flow mobility cache is used to decide how to route a 693 given flow. 695 +---------+-----+-------+------+-----------+------------+ 696 | BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | 697 +---------+-----+-------+------+-----------+------------+ 698 | 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) | 699 | 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) | 700 +---------+-----+-------+------+-----------+------------+ 702 Figure 8: Extended Binding Cache 704 Figure 8 shows an example of extended binding cache, containing two 705 binding cache entries (BCEs) of a mobile node MN1 attached to the 706 network using two different access technologies. Both of the two 707 attachments share the same prefix (HNP1) and are bound to two 708 different Proxy-CoAs (two MAGs). 710 5.2. Flow Mobility Cache 712 Each local mobility anchor MUST maintain a flow mobility cache (FMC) 713 as shown in Figure 9. The flow mobility cache is a conceptual list 714 of entries that is separate from the binding cache. This conceptual 715 list contains an entry for each of the registered flows. This 716 specification re-uses the format of the flow binding list defined in 717 [RFC6089]. Each entry includes the following fields: 719 o Flow Identifier Priority (FID-PRI). 721 o Flow Identifier (FID). 723 o Traffic Selector (TS). 725 o Binding Identifier (BID). 727 o Action. 729 o Active/Inactive. 731 +---------+-----+-----+------+---------+----------+ 732 | FID-PRI | FID | TS | BIDs | Action | A/I | 733 +---------+-----+-----+------+---------+----------+ 734 | 10 | 2 | TCP | 1 | Forward | Active | 735 | 20 | 4 | UDP | 1,2 | Forward | Inactive | 736 +---------+-----+-----+------+---------+----------+ 738 Figure 9: Flow Mobility Cache 740 The BID field contains the identifier of the binding cache entry 741 which packets matching the flow information described in the TS field 742 will be forwarded to. When a flow is decided to be moved, the 743 affected BID(s) of the table are updated. 745 Similar to flow binding described in [RFC6089], each entry of the 746 flow mobility cache points to a specific binding cache entry 747 identifier (BID). When a flow is moved, the local mobility anchor 748 simply updates the pointer of the flow binding entry with the BID of 749 the interface to which the flow will be moved. The traffic selector 750 (TS) in flow binding table is defined as in [RFC6088]. TS is used to 751 classify the packets of flows based on specific parameters such as 752 service type, source and destination address, etc. The packets 753 matching with the same TS will be applied the same forwarding policy. 754 FID-PRI is the order of precedence to take action on the traffic. 755 Action may be forward or drop. If a binding entry becomes 'Inactive' 756 it does not affect data traffic. An entry becomes 'Inactive' only if 757 all of the BIDs are de-registered. 759 The mobile access gateway MAY also maintain a similar data structure. 760 In case no full flow mobility state is required at the MAG, the 761 Binding Update List (BUL) data structure is enough and no extra 762 conceptual data entries are needed. In case full per-flow state is 763 required at the mobile access gateway, it SHOULD also maintain a flow 764 mobility cache structure. 766 6. Mobile Node considerations 768 This specification assumes that the mobile node IP layer interface 769 can simultaneously and/or sequentially attach to multiple MAGs, 770 possibly over multiple media. The mobile node MUST be able to 771 enforce uplink policies to select the right outgoing interface. One 772 form to achieve this multiple attachment is described in 773 [I-D.ietf-netext-logical-interface-support], which allows the mobile 774 node supporting traffic flows on different physical interfaces 775 regardless of the assigned prefixes on those physical interfaces. 777 7. IANA Considerations 779 This specification defines new value for the Handoff Indicator {IANA- 780 0} and a new flag (L) in the Home Network Prefix option. A new 781 Notification Reason value for use in Update Notification message 782 ({IANA-1}) and new Status Values for use in Update Notification 783 Acknowledgement message ({IANA-2} to {IANA-4}) are also defined. 785 8. Security Considerations 787 The protocol signaling extensions defined in this document share the 788 same security concerns of Proxy Mobile IPv6 [RFC5213] and do not pose 789 any additional security threats to those already identified in 790 [RFC5213] and [RFC7077]. 792 The mobile access gateway and the local mobility anchor MUST use the 793 IPsec security mechanism mandated by Proxy Mobile IPv6 [RFC5213] to 794 secure the signaling described in this document. 796 9. Authors 798 This document reflects contributions from the following authors (in 799 alphabetical order). 801 Kuntal Chowdhury 803 E-mail: kc@altiostar.com 805 Sri Gundavelli 807 E-mail: sgundave@cisco.com 809 Youn-Hee Han 811 E-mail: yhhan@kut.ac.kr 813 Yong-Geun Hong 815 E-mail: yonggeun.hong@gmail.com 817 Rajeev Koodli 819 E-mail: rajeevkoodli@google.com 821 Telemaco Melia 823 E-mail: telemaco.melia@googlemail.com 825 Frank Xia 827 E-mail: xiayangsong@huawei.com 829 10. Acknowledgments 831 The authors would like to thank Vijay Devarapalli, Mohana 832 Dahamayanthi Jeyatharan, Kent Leung, Bruno Mongazon-Cazavet, Chan-Wah 833 Ng, Behcet Sarikaya and Tran Minh Trung for their valuable 834 contributions which helped generating this document. 836 The authors would also like to thank Juan-Carlos Zuniga, Pierrick 837 Seite, Julien Laganier for all the useful discussions on this topic. 839 Finally, the authors would also like to thank Marco Liebsch, Juan- 840 Carlos Zuniga, Dirk von Hugo, Fabio Giust and Daniel Corujo for their 841 reviews of this document. 843 The work of Carlos J. Bernardos has been partially performed in the 844 framework of the H2020-ICT-2014-2 project 5G NORMA. 846 11. References 848 11.1. Normative References 850 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 851 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 852 RFC2119, March 1997, 853 . 855 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 856 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 857 5213, DOI 10.17487/RFC5213, August 2008, 858 . 860 [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, 861 T., and K. Nagami, "Multiple Care-of Addresses 862 Registration", RFC 5648, DOI 10.17487/RFC5648, October 863 2009, . 865 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 866 "Traffic Selectors for Flow Bindings", RFC 6088, DOI 867 10.17487/RFC6088, January 2011, 868 . 870 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 871 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 872 Network Mobility (NEMO) Basic Support", RFC 6089, DOI 873 10.17487/RFC6089, January 2011, 874 . 876 [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and 877 J. Korhonen, "Update Notifications for Proxy Mobile IPv6", 878 RFC 7077, DOI 10.17487/RFC7077, November 2013, 879 . 881 11.2. Informative References 883 [I-D.ietf-netext-logical-interface-support] 884 Melia, T. and S. Gundavelli, "Logical-interface Support 885 for Multi-access enabled IP Hosts", draft-ietf-netext- 886 logical-interface-support-12 (work in progress), November 887 2015. 889 [RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. 890 Gundavelli, "Quality-of-Service Option for Proxy Mobile 891 IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014, 892 . 894 Author's Address 896 Carlos J. Bernardos (editor) 897 Universidad Carlos III de Madrid 898 Av. Universidad, 30 899 Leganes, Madrid 28911 900 Spain 902 Phone: +34 91624 6236 903 Email: cjbc@it.uc3m.es 904 URI: http://www.it.uc3m.es/cjbc/