idnits 2.17.1 draft-ietf-netext-pmipv6-flowmob-18.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 (Using the creation date from RFC5213, updated by this document, for RFC5378 checks: 2007-04-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 18, 2016) is 2960 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 462, but not defined == Missing Reference: 'HNPs' is mentioned on line 462, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-netext-logical-interface-support-13 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 Updates: 5213 (if approved) March 18, 2016 5 Intended status: Standards Track 6 Expires: September 19, 2016 8 Proxy Mobile IPv6 Extensions to Support Flow Mobility 9 draft-ietf-netext-pmipv6-flowmob-18 11 Abstract 13 Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy 14 Mobile IPv6 domain through different interfaces. This document 15 describes extensions to the Proxy Mobile IPv6 protocol that are 16 required to support network based flow mobility over multiple 17 physical interfaces. 19 This document updates RFC 5213. The extensions described in this 20 document consist of the operations performed by the local mobility 21 anchor and the mobile access gateway to manage the prefixes assigned 22 to the different interfaces of the mobile node, as well as how the 23 forwarding policies are handled by the network to ensure consistent 24 flow mobility management. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 19, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Overview of the PMIPv6 flow mobility 69 extensions . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Use case scenarios . . . . . . . . . . . . . . . . . . . 4 71 3.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5 72 3.2.1. MN sharing a common 73 set of prefixes on all MAGs . . . . . . . . . . . . . 5 74 3.2.2. MN with different 75 sets of prefixes on each MAG . . . . . . . . . . . . 9 76 3.3. Use of PBU/PBA signaling . . . . . . . . . . . . . . . . 11 77 3.4. Use of flow-level information . . . . . . . . . . . . . . 12 78 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.1. Home Network Prefix . . . . . . . . . . . . . . . . . . . 12 80 4.2. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . 13 81 4.3. Flow Mobility Acknowledgement (FMA) . . . . . . . . . . . 14 82 5. Conceptual Data Structures . . . . . . . . . . . . . . . . . 14 83 5.1. Multiple Proxy Care-of Address Registration . . . . . . . 14 84 5.2. Flow Mobility Cache . . . . . . . . . . . . . . . . . . . 15 85 6. Mobile Node considerations . . . . . . . . . . . . . . . . . 16 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 88 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 92 11.2. Informative References . . . . . . . . . . . . . . . . . 19 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network 98 based mobility management to hosts connecting to a PMIPv6 domain. 99 PMIPv6 introduces two new functional entities, the Local Mobility 100 Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the 101 entity detecting the Mobile Node's (MN) attachment and providing IP 102 connectivity. The LMA is the entity assigning one or more Home 103 Network Prefixes (HNP) to the MN and is the topological anchor for 104 all traffic belonging to the MN. 106 PMIPv6 allows a mobile node to connect to the same PMIPv6 domain 107 through different interfaces. This document specifies protocol 108 extensions to Proxy Mobile IPv6 between the local mobility anchor and 109 mobile access gateways to enable "flow mobility" and hence distribute 110 specific traffic flows on different physical interfaces. It is 111 assumed that the mobile node IP layer interface can simultaneously 112 and/or sequentially attach to multiple MAGs, possibly over multiple 113 media. One form to achieve this multiple attachment is described in 114 [I-D.ietf-netext-logical-interface-support], which allows the mobile 115 node supporting traffic flows on different physical interfaces 116 regardless of the assigned prefixes on those physical interfaces. 117 Another alternative is to configure the IP stack of the mobile node 118 to behave according to the weak host model [RFC1122]. 120 In particular, this document specifies how to enable "flow mobility" 121 in the PMIPv6 network (i.e., local mobility anchors and mobile access 122 gateways). In order to do so, two main operations are required: i) 123 proper prefix management by the PMIPv6 network, and, ii) consistent 124 flow forwarding policies. This memo analyzes different potential use 125 case scenarios, involving different prefix assignment requirements, 126 and therefore different PMIPv6 network extensions to enable "flow 127 mobility". 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC2119 [RFC2119]. 135 The following terms used in this document are defined in the Proxy 136 Mobile IPv6 [RFC5213]: 138 Local Mobility Agent (LMA). 140 Mobile Access Gateway (MAG). 142 Proxy Mobile IPv6 Domain (PMIPv6-Domain). 144 LMA Address (LMAA). 146 Proxy Care-of Address (Proxy-CoA). 148 Home Network Prefix (HNP). 150 The following terms used in this document are defined in the Multiple 151 Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile 152 IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]: 154 Binding Identification Number (BID). 156 Flow Identifier (FID). 158 Traffic Selector (TS). 160 The following terms are defined and used in this document: 162 FMI (Flow Mobility Initiate). Message sent by the LMA to the MAG 163 conveying the information required to enable flow mobility in a 164 PMIPv6-Domain. 166 FMA (Flow Mobility Acknowledgement). Message sent by the MAG in 167 reply to an FMI message. 169 FMC (Flow Mobility Cache). Conceptual data structure to support the 170 flow mobility management operations described in this document. 172 3. Overview of the PMIPv6 flow mobility extensions 174 3.1. Use case scenarios 176 In contrast to a typical handover where connectivity to a physical 177 medium is relinquished and then re-established, flow mobility assumes 178 a mobile node can have simultaneous access to more than one network. 179 In this specification, it is assumed that the local mobility anchor 180 is aware of the mobile node's capabilities to have simultaneous 181 access to both access networks and it can handle the same or a 182 different set of prefixes on each access. How this is done is 183 outside the scope of this specification. 185 There are different flow mobility scenarios. In some of them the 186 mobile node might share a common set of prefixes among all its 187 physical interfaces, whereas in others the mobile node might have a 188 different subset of prefixes configured on each of the physical 189 interfaces. The different scenarios are the following: 191 1. At the time of a new network attachment, the MN obtains the same 192 prefix or the same set of prefixes as already assigned to an 193 existing session. This is not the default behavior with basic 194 PMIPv6 [RFC5213], and the LMA needs to be able to provide the 195 same assignment even for the simultaneous attachment (as opposed 196 to the handover scenario only). 198 2. At the time of a new network attachment, the MN obtains a new 199 prefix or a new set of prefixes for the new session. This is the 200 default behavior with basic PMIPv6 [RFC5213]. 202 A combination of the two above-mentioned scenarios is also possible. 203 At the time of a new network attachment, the MN obtains a combination 204 of prefix(es) in use and new prefix(es). This is a hybrid of the two 205 scenarios described before. The local policy determines whether the 206 new prefix is exclusive to the new attachment or it can be assigned 207 to an existing attachment as well. 209 The operational description of how to enable flow mobility in each of 210 these scenarios is provided in Section 3.2.1 and Section 3.2.2. 212 The extensions described in this document support all the 213 aforementioned scenarios. 215 3.2. Basic Operation 217 This section describes how the PMIPv6 extensions described in this 218 document enable flow mobility support. 220 Both the mobile node and the local mobility anchor MUST have local 221 policies in place to ensure that packets are forwarded coherently for 222 unidirectional and bidirectional communications. The details about 223 how this consistency is ensured are out of the scope of this 224 document. Either the MN or the LMA can initiate IP flow mobility. 225 If the MN makes the flow mobility decision, then the LMA follows that 226 decision and updates its forwarding state accordingly. The network 227 can also trigger mobility on the MN side via out-of-band mechanisms 228 (e.g., 3GPP/ANDSF sends updated routing policies to the MN). In a 229 given scenario and mobile node, the decision on IP flow mobility MUST 230 be taken either by the MN or the LMA, but MUST NOT be taken by both. 232 3.2.1. MN sharing a common set of prefixes on all MAGs 234 This scenario corresponds to the first use case scenario described in 235 Section 3.1. Extensions to basic PMIPv6 [RFC5213] signaling at the 236 time of a new attachment are needed to ensure that the same prefix 237 (or set of prefixes) is assigned to all the interfaces of the same 238 mobile node that are simultaneously attached. Subsequently, no 239 further signaling is necessary between the local mobility anchor and 240 the mobile access gateway and flows are forwarded according to policy 241 rules on the local mobility anchor and the mobile node. 243 If the local mobility anchor assigns a common prefix (or set of 244 prefixes) to the different physical interfaces attached to the 245 domain, then every MAG already has all the routing knowledge required 246 to forward uplink or downlink packets after the PBU/PBA registration 247 for each MAG, and the local mobility anchor does not need to send any 248 kind of signaling in order to move flows across the different 249 physical interfaces (because moving flows is a local decision of the 250 LMA). Optionally, signaling MAY be exchanged in case the MAG needs 251 to know about flow level information (e.g., to link flows with proper 252 QoS paths and/or inform the mobile node) [RFC7222]. 254 The local mobility anchor needs to know when to assign the same set 255 of prefixes to all the different physical interfaces of the mobile 256 node. This can be achieved by different means, such as policy 257 configuration, default policies, etc. In this document a new Handoff 258 Indicator (HI) value ("Attachment over a new interface sharing 259 prefixes", value {IANA-0}) is defined, to allow the mobile access 260 gateway to indicate to the local mobility anchor that the same set of 261 prefixes MUST be assigned to the mobile node. The considerations of 262 Section 5.4.1 of [RFC5213] are updated by this specification as 263 follows: 265 o If there is at least one Home Network Prefix option present in the 266 request with a NON_ZERO prefix value, there exists a Binding Cache 267 entry (with all home network prefixes in the Binding Cache entry 268 matching the prefix values of all Home Network Prefix options of 269 the received Proxy Binding Update message), and the entry matches 270 the mobile node identifier in the Mobile Node Identifier option of 271 the received Proxy Binding Update message, and the value of the 272 Handoff Indicator of the received Proxy Binding Update is equal to 273 "Attachment over a new interface sharing prefixes". 275 1. If there is an MN-LL-Identifier Option present in the request 276 and the Binding Cache entry matches the Access Technology Type 277 (ATT), and MN-LL-Identifier, the request MUST be considered as 278 a request for updating that Binding Cache entry. 280 2. If there is an MN-LL-Identifier Option present in the request 281 and the Binding Cache entry does not match the Access 282 Technology Type (ATT), and MN-LL-Identifier, the request MUST 283 be considered as a request for creating a new mobility session 284 sharing the same set of home network prefixes assigned to the 285 existing Binding Cache entry found. 287 3. If there is not an MN-LL-Identifier Option present in the 288 request, the request MUST be considered as a request for 289 creating a new mobility session sharing the same set of home 290 network prefixes assigned to the existing Binding Cache entry 291 found. 293 LMA Binding Cache 294 +---+ ======================== 295 |LMA| MN1, ATT1, pref1, MAG1 296 +---+ MN1, ATT2, pref1, MAG2 297 //\\ 298 +---------//--\\-------------+ 299 ( // \\ ) PMIPv6 domain 300 ( // \\ ) 301 +------//--------\\----------+ 302 // \\ 303 // \\ 304 +----+ +----+ 305 |MAG1| |MAG2| 306 +----+ +----+ 307 | | 308 | +-------+ | 309 | | I P | | 310 | +---+---+ | 311 |---|if1|if2|----| 312 +---+---+ 313 MN1 315 Figure 1: Shared prefix across physical interfaces scenario 317 Next, an example of how flow mobility works in this case is shown. 318 In Figure 1, a mobile node (MN1) has two different physical 319 interfaces (if1 of access technology type ATT1, and if2 of access 320 technology type ATT2). Each physical interface is attached to a 321 different mobile access gateway, both of them controlled by the same 322 local mobility anchor. Both physical interfaces are assigned the 323 same prefix (pref1) upon attachment to the MAGs. If the IP layer at 324 the mobile node shows one single logical interface (e.g., as 325 described in [I-D.ietf-netext-logical-interface-support]), then the 326 mobile node has one single IPv6 address configured at the IP layer: 327 pref1::mn1. Otherwise, per interface IPv6 addresses (e.g., 328 pref1::if1 and pref1::if2) would be configured; each address MUST be 329 valid on every interface. We assume the first case in the following 330 example (and in the rest of this document). Initially, flow X goes 331 through MAG1 and flow Y through MAG2. At a certain point, flow Y can 332 be moved to also go through MAG1. Figure 2 shows the scenario in 333 which no flow-level information needs to be exchanged, so there is no 334 signaling between the local mobility anchor and the mobile access 335 gateways. 337 Note that if different IPv6 addresses are configured at the IP layer, 338 IP session continuity is still possible (for each of the configured 339 IP addresses). This is achieved by the network delivering packets 340 destined to a particular IP address of the mobile node to the right 341 MN's physical interface where the flow is selected to be moved, and 342 the MN also selecting the same interface when sending traffic back up 343 link. 345 +-----+ +------+ +------+ +-----+ 346 Internet | LMA | | MAG1 | | MAG2 | | MN1 | 347 +-----+ +------+ +------+ +-----+ 348 | | | | | 349 | flow X to | flow X to | flow X to | 350 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 351 |<----------->|<------------->|<-------------------------->if1 352 | flow Y to | flow Y to | flow Y to | 353 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 354 |<----------->|<----------------------------->|<---------->if2 355 | | | | | 356 | ============ | | ============ 357 | || flow || | | || flow || 358 | || policy || | | || policy || 359 | || update || | | || update || 360 | ============ | | ============ 361 | | | | | 362 | flow Y to | flow Y to | flow Y to | 363 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 364 |<----------->|<------------->|<-------------------------->if1 365 | | | | | 367 Figure 2: Flow mobility message sequence with common set of prefixes 369 Figure 3 shows the state of the different network entities after 370 moving flow Y in the previous example. This document re-uses some of 371 the terminology and mechanisms of the flow bindings and multiple 372 care-of address registration specifications. Note that, in this case 373 the BIDs shown in the figure are assigned locally by the LMA, since 374 there is no signaling required in this scenario. In any case, 375 alternative implementations of flow routing at the LMA MAY be used, 376 as it does not impact on the operation of the solution in this case. 378 LMA Binding Cache LMA flowmob state 379 (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) 380 +---+ =========================== =================== 381 |LMA| 1, MN1, ATT1, pref1, MAG1 1, flow X 382 +---+ 2, MN1, ATT2, pref1, MAG2 1, flow Y 383 //\\ 384 +---------//--\\-------------+ 385 ( // \\ ) PMIPv6 domain 386 ( // \\ ) 387 +------//--------\\----------+ 388 // \\ 389 // \\ MAG1 routing state 390 +----+ +----+ ================================ 391 |MAG1| |MAG2| (dest) (next hop) 392 +----+ +----+ pref1::/64 p2p-iface-with-MN1 393 | | ::/0 LMA 394 | | 395 | | MAG2 routing state 396 | +-------+ | ================================ 397 | | I P | | (dest) (next hop) 398 | +---+---+ | pref1::/64 p2p-iface-with-MN1 399 |---|if1|if2|----| ::/0 LMA 400 +---+---+ 401 MN1 403 Figure 3: Data structures with common set of prefixes 405 3.2.2. MN with different sets of prefixes on each MAG 407 A different flow mobility scenario happens when the local mobility 408 anchor assigns different sets of prefixes to physical interfaces of 409 the same mobile node. This covers the second case, or a combination 410 of scenarios, described in Section 3.1. In this case, additional 411 signaling is required between the local mobility anchor and the 412 mobile access gateway to enable relocating flows between the 413 different attachments, so the MAGs are aware of the prefixes for 414 which the MN is going to receive traffic, and local routing entries 415 are configured accordingly. 417 In this case, signaling is required when a flow is to be moved from 418 its original interface to a new one. Since the local mobility anchor 419 cannot send a PBA message which has not been triggered in response to 420 a received PBU message, the solution defined in this specification 421 makes use of two mobility messages: Flow Mobility Indication and Flow 422 Mobility Acknowledgement, which actually use the format of the Update 423 Notifications for Proxy Mobile IPv6 defined in [RFC7077]. The 424 trigger for the flow movement can be on the mobile node (e.g., by 425 using layer-2 signaling with the MAG) or on the network (e.g., based 426 on congestion and measurements) which then notifies the MN for the 427 final IP flow mobility decision (as stated in section 3.1). Policy 428 management functions (e.g., 3GPP/ANDSF) can be used for that purpose, 429 however, how the network notifies the MN is out of the scope of this 430 document. 432 If the flow is being moved from its default path (which is determined 433 by the destination prefix) to a different one, the local mobility 434 anchor constructs a Flow Mobility Indication (FMI) message. This 435 message includes a Home Network Prefix option for each of the 436 prefixes that are requested to be provided with flow mobility support 437 on the new MAG (note that these prefixes are not anchored by the 438 target MAG, and therefore the MAG MUST NOT advertise them on the MAG- 439 MN link), with the off-link bit (L) set to one. This message MUST be 440 sent to the new target mobile access gateway, i.e. the one selected 441 to be used in the forwarding of the flow. The MAG replies with a 442 Flow Mobility Acknowledgement (FMA). The message sequence is shown 443 in Figure 4. 445 +-----+ +------+ +------+ +-----+ 446 Internet | LMA | | MAG1 | | MAG2 | | MN1 | 447 +-----+ +------+ +------+ +-----+ 448 | | | | | 449 | flow X to | flow X to | flow X to | 450 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 451 |<----------->|<------------->|<-------------------------->if1 452 | flow Y to | flow Y to | flow Y to | 453 | pref2::mn1 | pref2::mn1 | pref2::mn1 | 454 |<----------->|<----------------------------->|<---------->if2 455 | | | | | 456 | ============ | | ============ 457 | || flow || | | || flow || 458 | || policy || | | || policy || 459 | || update || | | || update || 460 | ============ | | ============ 461 | | | | | 462 | | FMI[MN1-ID, HNPs] | | 463 | |-------------->| | | 464 | | FMA | | | 465 | |<--------------| | | 466 | flow Y to | flow Y to | flow Y to | 467 | pref2::mn1 | pref2::mn1 | pref2::mn1 | 468 |<----------->|<------------->|<-------------------------->if1 469 | | | | | 471 Figure 4: Flow mobility message sequence when the LMA assigns 472 different sets of prefixes per physical interface 474 The state in the network after moving a flow, for the case the LMA 475 assigns a different set of prefixes is shown in Figure 5. 477 LMA Binding Cache LMA flowmob state 478 (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) 479 +---+ ============================ =================== 480 |LMA| 1, MN1, ATT1, pref1, 1, flow X 481 +---+ pref2, MAG1 1, flow Y 482 //\\ 2, MN1, ATT2, pref2, MAG2 483 +---------//--\\-------------+ 484 ( // \\ ) PMIPv6 domain 485 ( // \\ ) 486 +------//--------\\----------+ 487 // \\ 488 // \\ MAG1 routing state 489 +----+ +----+ ================================ 490 |MAG1| |MAG2| (dest) (next hop) 491 +----+ +----+ pref1::/64 p2p-iface-with-MN1 492 | | pref2::/64 p2p-iface-with-MN1 493 | | ::/0 LMA 494 | | 495 | +-------+ | MAG2 routing state 496 | | I P | | ================================ 497 | +---+---+ | (dest) (next hop) 498 |---|if1|if2|----| pref2::/64 p2p-iface-with-MN1 499 +---+---+ ::/0 LMA 500 MN1 502 Figure 5: Data structures when the LMA assigns a different set of 503 prefixes 505 3.3. Use of PBU/PBA signaling 507 This specification introduces the FMI/FMA signaling so the LMA can 508 exchange with the MAG information required to enable flow mobility 509 without waiting for receiving a PBU. There are however scenarios in 510 which the trigger for flow mobility might be related to a new MN's 511 interface attachment. In this case, the PBA sent in response to the 512 PBU received from the new MAG can convey the same signaling that the 513 FMI does. In this case the LMA MUST include in the PBA a Home 514 Network Prefix option for each of the prefixes that are requested to 515 be provided with flow mobility support on the new MAG with the off- 516 link bit (L) set to one. 518 3.4. Use of flow-level information 520 This specification does not mandate flow-level information to be 521 exchanged between the LMA and the MAG to provide flow mobility 522 support. It only requires the LMA to keep flow-level state 523 (Section 5.2). However, there are scenarios in which the MAG might 524 need to know which flow(s) is/are coming within a prefix that has 525 been moved, to link it/them to proper QoS path(s) and optionally 526 inform the MN about it. This section describes the extensions used 527 to include flow-level information in the signaling defined between 528 the LMA and the MAG. 530 This specification re-uses some of the mobility extensions and 531 message formats defined in [RFC5648] and [RFC6089], namely the Flow 532 Identification Mobility Option and the Flow Mobility Sub-Options. 534 In case the LMA wants to convey flow-level information to the MAG, it 535 MUST include in the FMI (or the PBA) a Flow Identification Mobility 536 Option for all the flows that the MAG needs to be aware with flow 537 granularity. Each Flow Identification Option MUST include a Traffic 538 Selector Sub-Option including such flow-level information. 540 To remove a flow binding state at the MAG, the LMA simply sends a FMI 541 (or PBA if it is in response to a PBU) message that includes flow 542 identification options for all the flows that need to be refreshed, 543 modified, or added, and simply omits those that need to be removed. 545 Note that even if a common set of prefixes is used, providing the MAG 546 with flow-level information requires signaling to be exchanged in 547 this case between the LMA and the MAG. This is done sending a FMI 548 message (or a PBA if it is sent in response to a PBU). 550 4. Message Formats 552 This section defines modifications to the Proxy Mobile IPv6 [RFC5213] 553 protocol messages. 555 This specification requires implementation of UPN [RFC7077] and UPA 556 [RFC7077] messages with the specific Notification Reason and Status 557 Code values as defined by this document. This document does not 558 require implementation of any other aspects of [RFC7077]. 560 4.1. Home Network Prefix 562 A new flag (L) is included in the Home Network Prefix option to 563 indicate to the Mobile Access Gateway whether the conveyed prefix has 564 to be hosted on-link or not on the point-to-point interface with the 565 mobile node. A prefix is hosted off-link for the flow mobility 566 purposes defined in this document. The rest of the Home Network 567 Prefix option format remains the same as defined in [RFC5213]. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type | Length |L| Reserved | Prefix Length | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | | 575 + + 576 | | 577 + Home Network Prefix + 578 | | 579 + + 580 | | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Off-link Home Network Prefix Flag (L): 585 The Off-link Home Network Prefix Flag is set to indicate to the 586 Mobile Access Gateway that the home network prefix conveyed in the 587 option is not to be hosted on-link, but has to be considered for 588 flow mobility purposes and therefore added to the Mobile Access 589 Gateway routing table. If the flag is set to 0, the Mobile Access 590 Gateway assumes that the home network prefix has to be hosted on- 591 link. 593 4.2. Flow Mobility Initiate (FMI) 595 The FMI message used in this specification is the Update Notification 596 (UPN) message specified in [RFC7077]. The message format, transport 597 and security consideration are as specified in [RFC7077]. The format 598 of the message is specified in Section 4.1 of [RFC7077] . This 599 specification does not modify the UPN message, however, it defines 600 the following new notification reason value for use in this 601 specification: 603 Notification Reason: 605 {IANA-1} - FLOW-MOBILITY. Request to add/refresh the prefix(es) 606 conveyed in the Home Network Prefix options included in the 607 message to the set of prefixes for which flow mobility is 608 provided. 610 The Mobility Options field of an FMI MUST contain the MN-ID, followed 611 by one or more Home Network Prefixes options. Prefixes for which 612 flow mobility was provided that are not present in the message MUST 613 be removed from the set of flow mobility enabled prefixes. 615 4.3. Flow Mobility Acknowledgement (FMA) 617 The FMA message used in this specification is the Update Notification 618 Ack (UPA) message specified in Section 4.2 of [RFC7077]. The message 619 format, transport and security consideration are as specified in 620 [RFC7077]. The format of the message is specified in Section 4.2 of 621 [RFC7077]. This specification does not modify the UPA message, 622 however, it defines the following new status code values for use in 623 this specification: 625 Status Code: 627 0: Success. 629 {IANA-2}: Reason unspecified. 631 {IANA-3}: MN not attached. 633 When Status code is 0, the Mobility Options field of an FMA MUST 634 contain the MN-ID, followed by one or more Home Network Prefixes 635 options. 637 5. Conceptual Data Structures 639 This section summarizes the extensions to Proxy Mobile IPv6 that are 640 necessary to manage flow mobility. 642 5.1. Multiple Proxy Care-of Address Registration 644 The binding cache structure of the local mobility anchor is extended 645 to allow multiple proxy care-of address (Proxy-CoA) registrations, 646 and support the mobile node use the same address (prefix) beyond a 647 single interface and mobile access gateway. The LMA maintains 648 multiple binding cache entries for an MN. The number of binding 649 cache entries for a mobile node is equal to the number of the MN's 650 interfaces attached to any MAGs. 652 This specification re-uses the extensions defined in [RFC5648] to 653 manage multiple registrations, but in the context of Proxy Mobile 654 IPv6. The binding cache is therefore extended to include more than 655 one proxy care-of address and to associate each of them with a 656 binding identifier (BID). Note that the BID is a local identifier, 657 assigned and used by the local mobility anchor to identify which 658 entry of the flow mobility cache is used to decide how to route a 659 given flow. 661 +---------+-----+-------+------+-----------+------------+ 662 | BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | 663 +---------+-----+-------+------+-----------+------------+ 664 | 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) | 665 | 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) | 666 +---------+-----+-------+------+-----------+------------+ 668 Figure 6: Extended Binding Cache 670 Figure 6 shows an example of extended binding cache, containing two 671 binding cache entries (BCEs) of a mobile node MN1 attached to the 672 network using two different access technologies. Both of the two 673 attachments share the same prefix (HNP1) and are bound to two 674 different Proxy-CoAs (two MAGs). 676 5.2. Flow Mobility Cache 678 Each local mobility anchor MUST maintain a flow mobility cache (FMC) 679 as shown in Figure 7. The flow mobility cache is a conceptual list 680 of entries that is separate from the binding cache. This conceptual 681 list contains an entry for each of the registered flows. This 682 specification re-uses the format of the flow binding list defined in 683 [RFC6089]. Each entry includes the following fields: 685 o Flow Identifier Priority (FID-PRI). 687 o Flow Identifier (FID). 689 o Traffic Selector (TS). 691 o Binding Identifier (BID). 693 o Action. 695 o Active/Inactive. 697 +---------+-----+-----+------+---------+----------+ 698 | FID-PRI | FID | TS | BIDs | Action | A/I | 699 +---------+-----+-----+------+---------+----------+ 700 | 10 | 2 | TCP | 1 | Forward | Active | 701 | 20 | 4 | UDP | 1,2 | Forward | Inactive | 702 +---------+-----+-----+------+---------+----------+ 704 Figure 7: Flow Mobility Cache 706 The BID field contains the identifier of the binding cache entry 707 which packets matching the flow information described in the TS field 708 will be forwarded to. When a flow is decided to be moved, the 709 affected BID(s) of the table are updated. 711 Similar to flow binding described in [RFC6089], each entry of the 712 flow mobility cache points to a specific binding cache entry 713 identifier (BID). When a flow is moved, the local mobility anchor 714 simply updates the pointer of the flow binding entry with the BID of 715 the interface to which the flow will be moved. The traffic selector 716 (TS) in flow binding table is defined as in [RFC6088]. TS is used to 717 classify the packets of flows based on specific parameters such as 718 service type, source and destination address, etc. The packets 719 matching with the same TS will be applied the same forwarding policy. 720 FID-PRI is the order of precedence to take action on the traffic. 721 Action may be forward or drop. If a binding entry becomes 'Inactive' 722 it does not affect data traffic. An entry becomes 'Inactive' only if 723 all of the BIDs are de-registered. 725 The mobile access gateway MAY also maintain a similar data structure. 726 In case no full flow mobility state is required at the MAG, the 727 Binding Update List (BUL) data structure is enough and no extra 728 conceptual data entries are needed. In case full per-flow state is 729 required at the mobile access gateway, it SHOULD also maintain a flow 730 mobility cache structure. 732 6. Mobile Node considerations 734 This specification assumes that the mobile node IP layer interface 735 can simultaneously and/or sequentially attach to multiple MAGs, 736 possibly over multiple media. The mobile node MUST be able to 737 enforce uplink policies to select the right outgoing interface. One 738 alternative to achieve this multiple attachment is described in 739 [I-D.ietf-netext-logical-interface-support], which allows the mobile 740 node supporting traffic flows on different physical interfaces 741 regardless of the assigned prefixes on those physical interfaces. 742 Another alternative is configuring the IP stack of the mobile node to 743 behave according to the weak host model [RFC1122]. 745 7. IANA Considerations 747 This specification establishes new assignments to the IANA mobility 748 parameters registry: 750 o Handoff Indicator Option type: the value {IANA-0} has to be 751 assigned from the "Handoff Indicator Option type values" registry 752 defined in http://www.iana.org/assignments/mobility-parameters/ 753 mobility-parameters.xhtml#mobility-parameters-9. 755 o Update Notification Reason: the value ({IANA-1}) has to be 756 assigned from the "Update Notification Reasons Registry" defined 757 in http://www.iana.org/assignments/mobility-parameters/mobility- 758 parameters.xhtml#upn-reasons. 760 o Update Notification Acknowledgement Status: values ({IANA-2} and 761 {IANA-3}) have to be assigned fom the "Update Notification 762 Acknowledgement Status Registry". Since {IANA-2} and {IANA-3} are 763 used in error messages, their values have to be greater than 128 764 from the range defined in http://www.iana.org/assignments/ 765 mobility-parameters/mobility-parameters.xhtml#upa-status. 767 8. Security Considerations 769 The protocol signaling extensions defined in this document share the 770 same security concerns of Proxy Mobile IPv6 [RFC5213] and do not pose 771 any additional security threats to those already identified in 772 [RFC5213] and [RFC7077]. 774 The mobile access gateway and the local mobility anchor MUST use the 775 IPsec security mechanism mandated by Proxy Mobile IPv6 [RFC5213] to 776 secure the signaling described in this document. 778 9. Authors 780 This document reflects contributions from the following authors (in 781 alphabetical order). 783 Kuntal Chowdhury 785 E-mail: kc@altiostar.com 787 Sri Gundavelli 789 E-mail: sgundave@cisco.com 791 Youn-Hee Han 793 E-mail: yhhan@kut.ac.kr 795 Yong-Geun Hong 797 E-mail: yonggeun.hong@gmail.com 799 Rajeev Koodli 801 E-mail: rajeevkoodli@google.com 803 Telemaco Melia 805 E-mail: telemaco.melia@googlemail.com 807 Frank Xia 809 E-mail: xiayangsong@huawei.com 811 10. Acknowledgments 813 The authors would like to thank Vijay Devarapalli, Mohana 814 Dahamayanthi Jeyatharan, Kent Leung, Bruno Mongazon-Cazavet, Chan-Wah 815 Ng, Behcet Sarikaya and Tran Minh Trung for their valuable 816 contributions which helped generating this document. 818 The authors would also like to thank Juan-Carlos Zuniga, Pierrick 819 Seite, Julien Laganier for all the useful discussions on this topic. 821 Finally, the authors would also like to thank Marco Liebsch, Juan- 822 Carlos Zuniga, Dirk von Hugo, Fabio Giust and Daniel Corujo for their 823 reviews of this document. 825 The work of Carlos J. Bernardos has been partially performed in the 826 framework of the H2020-ICT-2014-2 project 5G NORMA. 828 11. References 830 11.1. Normative References 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 834 RFC2119, March 1997, 835 . 837 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 838 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 839 5213, DOI 10.17487/RFC5213, August 2008, 840 . 842 [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, 843 T., and K. Nagami, "Multiple Care-of Addresses 844 Registration", RFC 5648, DOI 10.17487/RFC5648, October 845 2009, . 847 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 848 "Traffic Selectors for Flow Bindings", RFC 6088, DOI 849 10.17487/RFC6088, January 2011, 850 . 852 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 853 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 854 Network Mobility (NEMO) Basic Support", RFC 6089, DOI 855 10.17487/RFC6089, January 2011, 856 . 858 [RFC7077] Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and 859 J. Korhonen, "Update Notifications for Proxy Mobile IPv6", 860 RFC 7077, DOI 10.17487/RFC7077, November 2013, 861 . 863 11.2. Informative References 865 [I-D.ietf-netext-logical-interface-support] 866 Melia, T. and S. Gundavelli, "Logical-interface Support 867 for Multi-access enabled IP Hosts", draft-ietf-netext- 868 logical-interface-support-13 (work in progress), February 869 2016. 871 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 872 Communication Layers", STD 3, RFC 1122, DOI 10.17487/ 873 RFC1122, October 1989, 874 . 876 [RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. 877 Gundavelli, "Quality-of-Service Option for Proxy Mobile 878 IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014, 879 . 881 Author's Address 883 Carlos J. Bernardos (editor) 884 Universidad Carlos III de Madrid 885 Av. Universidad, 30 886 Leganes, Madrid 28911 887 Spain 889 Phone: +34 91624 6236 890 Email: cjbc@it.uc3m.es 891 URI: http://www.it.uc3m.es/cjbc/