idnits 2.17.1 draft-ietf-netext-pmipv6-flowmob-08.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 (October 21, 2013) is 3832 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-netext-logical-interface-support-08 Summary: 0 errors (**), 0 flaws (~~), 2 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 October 21, 2013 5 Expires: April 24, 2014 7 Proxy Mobile IPv6 Extensions to Support Flow Mobility 8 draft-ietf-netext-pmipv6-flowmob-08 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 April 24, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Overview of the PMIPv6 flow mobility extensions . . . . . . . 4 66 3.1. Use case scenarios . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5 68 3.2.1. MN sharing a common set of prefixes on all MAGs . . . 5 69 3.2.2. MN with different sets of prefixes on each MAG . . . . 9 70 3.2.3. MN with combination of prefix(es) in use and new 71 prefix(es) on each MAG . . . . . . . . . . . . . . . . 12 72 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.1. Home Network Prefix . . . . . . . . . . . . . . . . . . . 13 74 5. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 13 75 5.1. Multiple Proxy Care-of Address Registration . . . . . . . 14 76 5.2. Flow Mobility Cache . . . . . . . . . . . . . . . . . . . 14 77 6. Mobile Node considerations . . . . . . . . . . . . . . . . . . 15 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 84 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network 90 based mobility management to hosts connecting to a PMIPv6 domain. 91 PMIPv6 introduces two new functional entities, the Local Mobility 92 Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the 93 entity detecting Mobile Node's (MN) attachment and providing IP 94 connectivity. The LMA is the entity assigning one or more Home 95 Network Prefixes (HNPs) to the MN and is the topological anchor for 96 all traffic belonging to the MN. 98 PMIPv6 allows a mobile node to connect to the same PMIPv6 domain 99 through different interfaces. This document specifies protocol 100 extensions to Proxy Mobile IPv6 between the local mobility anchor and 101 mobile access gateways to enable "flow mobility" and hence distribute 102 specific traffic flows on different physical interfaces. It is 103 assumed that the mobile node IP layer interface can simultaneously 104 and/or sequentially attach to multiple MAGs, possibly over multiple 105 media. One form to achieve this multiple attachment is described in 106 [I-D.ietf-netext-logical-interface-support], which allows the mobile 107 node supporting traffic flows on different physical interfaces 108 regardless of the assigned prefixes on those physical interfaces. 110 In particular, this document specifies how to enable "flow mobility" 111 in the PMIPv6 network (i.e., local mobility anchors and mobile access 112 gateways). In order to do so, two main operations are required: i) 113 proper prefix management by the PMIPv6 network, ii) consistent flow 114 forwarding policies. This memo analyzes different potential use case 115 scenarios, involving different prefix assignment requirements, and 116 therefore different PMIPv6 network extensions to enable "flow 117 mobility". 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC2119 [RFC2119]. 125 The following terms used in this document are defined in the Proxy 126 Mobile IPv6 [RFC5213]: 128 Local Mobility Agent (LMA). 130 Mobile Access Gateway (MAG). 132 Proxy Mobile IPv6 Domain (PMIPv6-Domain). 134 LMA Address (LMAA). 136 Proxy Care-of Address (Proxy-CoA). 138 Home Network Prefix (HNP). 140 The following terms used in this document are defined in the Multiple 141 Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile 142 IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]: 144 Binding Identification Number (BID). 146 Flow Identifier (FID). 148 Traffic Selector (TS). 150 3. Overview of the PMIPv6 flow mobility extensions 152 3.1. Use case scenarios 154 In contrast to a typical handover where connectivity to a physical 155 medium is relinquished and then re-established, flow mobility assumes 156 a mobile node can have simultaneous access to more than one network. 157 In this specification, it is assumed that the local mobility anchor 158 is aware of the mobile node's capabilities to have simultaneous 159 access to both access networks and it can handle the same or a 160 different set of prefixes on each access. How this is done is 161 outside the scope of this specification. 163 There are different flow mobility scenarios. In some of them the 164 mobile node might share a common set of prefixes among all its 165 physical interfaces, whereas in others the mobile node might have a 166 different subset of prefixes configured on each of the physical 167 interfaces. The different scenarios are the following: 169 1. At the time of a new network attachment, the MN obtains the same 170 prefix or the same set of prefixes as already assigned to an 171 existing session. This is not the default behavior with basic 172 PMIPv6 [RFC5213], and the LMA needs to be able to provide the 173 same assignment even for the simultaneous attachment (as opposed 174 to the handover scenario only). 176 2. At the time of a new network attachment, the MN obtains a new 177 prefix or a new set of prefixes for the new session. This is the 178 default behavior with basic PMIPv6 [RFC5213]. 180 3. At the time of a new network attachment, the MN obtains a 181 combination of prefix(es) in use and new prefix(es). This is a 182 hybrid of the two above-mentioned scenarios. The local policy 183 determines whether the new prefix is exclusive to the new 184 attachment or it can be assigned to an existing attachment as 185 well. 187 The operational description of how to enable flow mobility in each of 188 these scenarios is provided in Section 3.2.1, Section 3.2.2 and 189 Section 3.2.3. 191 The extensions described in this document support all the 192 aforementioned scenarios. 194 3.2. Basic Operation 196 This section describes how the PMIPv6 extensions described in this 197 document enable flow mobility support. 199 Both the mobile node and the local mobility anchor MUST have local 200 policies in place to ensure that packets are forwarded coherently for 201 unidirectional and bidirectional communications. The details about 202 how this consistency is ensured are out of the scope of this 203 document. The MN makes the final IP flow mobility decision, and then 204 the LMA follows that decision and update its forwarding state 205 accordingly. Note that this does not prevent network initiated 206 mobility, the network still could trigger mobility on the MN side via 207 out-of-band mechanisms (e.g., 3GPP/ANDSF sends updated routing 208 policies to the MN). In a given scenario and mobile node, the 209 decision on IP flow mobility MUST be taken either by the MN or the 210 LMA, but not by both. 212 3.2.1. MN sharing a common set of prefixes on all MAGs 214 This scenario corresponds to the use case scenario number 1 described 215 in Section 3.1. Extensions to basic PMIPv6 [RFC5213] signaling at 216 the time of a new attachment are needed to ensure that the same 217 prefix (or set of prefixes) is assigned to all the interfaces of the 218 same mobile node that are simultaneously attached. Subsequently, no 219 further signaling is necessary between the local mobility anchor and 220 the mobile access gateway and flows are forwarded according to policy 221 rules on the local mobility anchor and the mobile node. 223 If the local mobility anchor assigns a common prefix (or set of 224 prefixes) to the different physical interfaces attached to the 225 domain, then every MAG already has all the routing knowledge required 226 to forward uplink or downlink packets, and the local mobility anchor 227 does not need to send any kind of signaling in order to move flows 228 across the different physical interfaces. 230 The local mobility anchor needs to know when to assign the same set 231 of prefixes to all the different physical interfaces of the mobile 232 node. This can be achieved by different means, such as policy 233 configuration, default policies, etc. In this document a new Handoff 234 Indicator (HI) value ("Attachment over a new interface sharing 235 prefixes", value {IANA-1}) is defined, to allow the mobile access 236 gateway indicate to the local mobility anchor that the same set of 237 prefixes MUST be assigned to the mobile node. The considerations of 238 Section 5.4.1 of [RFC5213] are updated by this specification as 239 follows: 241 o If there is at least one Home Network Prefix option present in the 242 request with a NON_ZERO prefix value, there exists a Binding Cache 243 entry (with one all home network prefixes in the Binding Cache 244 entry matching the prefix values of all Home Network Prefix 245 options of the received Proxy Binding Update message), and the 246 entry matches the mobile node identifier in the Mobile Node 247 Identifier option of the received Proxy Binding Update message, 248 and the value of the Handoff Indicator of the received Proxy 249 Binding Update is equal to "Attachment over a new interface 250 sharing prefixes". 252 1. If there is an MN-LL-Identifier Option present in the request 253 and the Binding Cache entry matches the Access Technology Type 254 (ATT), and MN-LL-Identifier, the request MUST be considered as 255 a request for updating that Binding Cache entry. 257 2. If there is an MN-LL-Identifier Option present in the request 258 and the Binding Cache entry does not match the Access 259 Technology Type (ATT), and MN-LL-Identifier, the request MUST 260 be considered as a request for creating a new mobility session 261 sharing the same set of Home Network Prefixes assigned to the 262 existing Binding Cache entry found. 264 3. If there is not an MN-LL-Identifier Option present in the 265 request, the request MUST be considered as a request for 266 creating a new mobility session sharing the same set of Home 267 Network Prefixes assigned to the existing Binding Cache entry 268 found. 270 LMA Binding Cache 271 +---+ ======================= 272 |LMA| MN1, if1, pref1, MAG1 273 +---+ MN1, if2, pref1, MAG2 274 //\\ 275 +---------//--\\-------------+ 276 ( // \\ ) PMIPv6 domain 277 ( // \\ ) 278 +------//--------\\----------+ 279 // \\ 280 // \\ 281 +----+ +----+ 282 |MAG1| |MAG2| 283 +----+ +----+ 284 | | 285 | +-------+ | 286 | | I P | | 287 | +---+---+ | 288 |---|if1|if2|----| 289 +---+---+ 290 MN1 292 Figure 1: Shared prefix across physical interfaces scenario 294 Next, an example of how flow mobility works in this case is shown. 295 In Figure 1, a mobile node (MN1) has two different physical 296 interfaces (if1 and if2). Each physical interface is attached to a 297 different mobile access gateway, both of them controlled by the same 298 local mobility anchor. Both physical interfaces are assigned the 299 same prefix (pref1) upon attachment to the MAGs. If the IP layer at 300 the mobile node shows one single logical interface (e.g., as 301 described in [I-D.ietf-netext-logical-interface-support]), then the 302 mobile node has one single IPv6 address configured at the IP layer: 303 pref1::mn1. Otherwise, per interface IPv6 addresses (e.g., pref1:: 304 if1 and pref1::if2) would be configured; each address MUST be valid 305 on every interface. We assumme the first case in the following 306 example (and in the rest of this document). Initially, flow X goes 307 through MAG1 and flow Y through MAG2. At certain point, flow Y can 308 be moved to also go through MAG1. As shown in Figure 2, no signaling 309 between the local mobility anchor and the mobile access gateways is 310 needed. 312 Note that if different IPv6 addresses are configured at the IP layer, 313 IP session continuity is still possible (for each of the configured 314 IP addresses). This is achieved by the network delivering packets 315 destined to a particular IP address of the mobile node to the right 316 MN's physical interface where the flow is selected to be moved, and 317 the MN also selecting the same interface when sending traffic back up 318 link. 320 +-----+ +------+ +------+ +-----+ 321 Internet | LMA | | MAG1 | | MAG2 | | MN1 | 322 +-----+ +------+ +------+ +-----+ 323 | | | | | 324 | flow X to | flow X to | flow X to | 325 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 326 |<----------->|<------------->|<-------------------------->if1 327 | flow Y to | flow Y to | flow Y to | 328 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 329 |<----------->|<----------------------------->|<---------->if2 330 | | | | | 331 | ============ | | ============ 332 | || flow || | | || flow || 333 | || policy || | | || policy || 334 | || update || | | || update || 335 | ============ | | ============ 336 | | | | | 337 | flow Y to | flow Y to | flow Y to | 338 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 339 |<----------->|<------------->|<-------------------------->if1 340 | | | | | 342 Figure 2: Flow mobility message sequence with common set of prefixes 344 Figure 3 shows the state of the different network entities after 345 moving flow Y in the previous example. This documents re-uses some 346 of the terminology and mechanisms of the flow bindings and multiple 347 care-of address registration specifications. Note, that in this case 348 the BIDs shown in the figure are assigned locally by the LMA, since 349 there is no signaling required in this scenario. In any case, 350 alternative implementations of flow routing at the LMA MAY be used, 351 as it does not impact on the operation of the solution in this case. 353 LMA Binding Cache LMA flowmob state 354 (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) 355 +---+ ========================== =================== 356 |LMA| 1, MN1, if1, pref1, MAG1 1, flow X 357 +---+ 2, MN1, if2, pref1, MAG2 1, flow Y 358 //\\ 359 +---------//--\\-------------+ 360 ( // \\ ) PMIPv6 domain 361 ( // \\ ) 362 +------//--------\\----------+ 363 // \\ 364 // \\ MAG1 routing state 365 +----+ +----+ ================================ 366 |MAG1| |MAG2| (dest) (next hop) 367 +----+ +----+ pref1::/64 p2p-iface-with-MN1 368 | | ::/0 LMA 369 | | 370 | | MAG2 routing state 371 | +-------+ | ================================ 372 | | I P | | (dest) (next hop) 373 | +---+---+ | pref1::/64 p2p-iface-with-MN1 374 |---|if1|if2|----| ::/0 LMA 375 +---+---+ 376 MN1 378 Figure 3: Data structures with common set of prefixes 380 3.2.2. MN with different sets of prefixes on each MAG 382 A different flow mobility scenario happens when the local mobility 383 anchor assigns different sets of prefixes to physical interfaces of 384 the same mobile node. This covers the second and third use case 385 scenarios described in Section 3.1. In this case, additional 386 signaling is required between the local mobility anchor and the 387 mobile access gateway to enable relocating flows between the 388 different attachments, so the MAGs are aware of the prefixes for 389 which the MN is going to receive traffic, and local routing entries 390 are configured accordingly. Two different, but related, approaches 391 are considered next. 393 The first approach corresponds to the use case scenario number 2 394 described in Section 3.1, in which a multi-interfaced mobile node 395 obtains a different set of prefixes on each attachment. Signaling is 396 required when a flow is to be moved from its original interface to a 397 new one. Since the local mobility anchor cannot send a PBA message 398 which has not been triggered in response to a received PBU message, 399 the solution defined in this specification makes use of the Update 400 Notifications for Proxy Mobile IPv6 defined in 402 [I-D.ietf-netext-update-notifications]. The trigger for the flow 403 movement can be on the mobile node (e.g., by using layer-2 signaling 404 with the MAG) or on the network (e.g., based on congestion and 405 measurements). 407 If the flow is being moved from its default path (which is determined 408 by the destination prefix) to a different one, the local mobility 409 anchor constructs an Update Notification (UPN) message, of type (2) 410 "UPDATE-SESSION-PARAMETERS" (NOTE from the Editor: a new Notification 411 Reason value might be defined for just flow mobility purposes if it 412 proves to be cleaner). This message includes a Home Network Prefix 413 for each of the prefixes that requested to be provided with flow 414 mobility support on the new MAG (note that these prefixes are not 415 anchored by the target MAG, and therefore the MAG MUST NOT advertise 416 them on the MAG-MN link), with the off-link bit (L) set to one. This 417 message MUST be sent to the new target mobile access gateway, i.e. 418 the one selected to be used in the forwarding of the flow. This UPN 419 message has the Acknowledgement Requested Flag ('A' Flag) set to 1, 420 so the MAG replies with an Update Notification Acknowledgement (UPA) 421 message. The message sequence is shown in Figure 4. 423 +-----+ +------+ +------+ +-----+ 424 Internet | LMA | | MAG1 | | MAG2 | | MN1 | 425 +-----+ +------+ +------+ +-----+ 426 | | | | | 427 | flow X to | flow X to | flow X to | 428 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 429 |<----------->|<------------->|<-------------------------->if1 430 | flow Y to | flow Y to | flow Y to | 431 | pref2::mn1 | pref2::mn1 | pref2::mn1 | 432 |<----------->|<----------------------------->|<---------->if2 433 | | | | | 434 | ============ | | ============ 435 | || flow || | | || flow || 436 | || policy || | | || policy || 437 | || update || | | || update || 438 | ============ | | ============ 439 | | | | | 440 | | UPN[UPDATE-SESSION-PARAMETERS, MN1-ID, HNPs]| 441 | |-------------->| | | 442 | | UPA | | | 443 | |<--------------| | | 444 | flow Y to | flow Y to | flow Y to | 445 | pref2::mn1 | pref2::mn1 | pref2::mn1 | 446 |<----------->|<------------->|<-------------------------->if1 447 | | | | | 449 Figure 4: Flow mobility message sequence when the LMA assigns 450 different sets of prefixes per physical interface 452 The state in the network after moving a flow, for the case the LMA 453 assigns a different set of prefixes is shown in Figure 5. 455 LMA Binding Cache LMA flowmob state 456 (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) 457 +---+ ============================ =================== 458 |LMA| 1, MN1, if1, pref1, 1, flow X 459 +---+ pref2, MAG1 1, flow Y 460 //\\ 2, MN1, if2, pref2, MAG2 461 +---------//--\\-------------+ 462 ( // \\ ) PMIPv6 domain 463 ( // \\ ) 464 +------//--------\\----------+ 465 // \\ 466 // \\ MAG1 routing state 467 +----+ +----+ ================================ 468 |MAG1| |MAG2| (dest) (next hop) 469 +----+ +----+ pref1::/64 p2p-iface-with-MN1 470 | | pref2::/64 p2p-iface-with-MN1 471 | | ::/0 LMA 472 | | 473 | +-------+ | MAG2 routing state 474 | | I P | | ================================ 475 | +---+---+ | (dest) (next hop) 476 |---|if1|if2|----| pref2::/64 p2p-iface-with-MN1 477 +---+---+ ::/0 LMA 478 MN1 480 Figure 5: Data structures when the LMA assigns a different set of 481 prefixes 483 The second approach corresponds to the use case scenario number 3 484 described in Section 3.1, in which upon new physical interface 485 attachment, the MN obtains a combination of prefix(es) in use and new 486 prefix(es). Here, the mobile node is already attached to the PMIPv6- 487 Domain via MAG1. At a certain moment, the mobile node attaches a new 488 interface (if2) to MAG2. MAG2 sends a PBU which is then used by the 489 LMA to enable flow mobility. In this case, we consider that flows 490 are moved with a prefix granularity, meaning that flows are moved by 491 moving prefixes among the different MAGs the mobile node is attached 492 to. In this example, flow Y is bound to pref2::/64 and therefore the 493 flow can be moved by just binding pref2::/64 to MAG2. This is done 494 by including the prefix in the PBA message. The scenario is shown in 495 Figure 6. 497 Optionally, a Binding Revocation Indication message [RFC5846] with 498 the P bit set MAY be sent to MAG1 to indicate that this is a 499 revocation of PMIP prefix(es). After processing BRI, the source MAG 500 MUST send a Binding Revocation Acknowledgement (BRA) message back to 501 the LMA. 503 +-----+ +------+ +------+ +-----+ 504 Internet | LMA | | MAG1 | | MAG2 | | MN | 505 +-----+ +------+ +------+ +-----+ 506 | | | | | 507 | flow X to | flow X to | flow X to | 508 | pref1::mn1 | pref1::mn1 | pref1::mn1 | 509 |<----------->|<--------------->|<-------------------------->if1 510 | flow Y to | flow Y to | flow Y to | 511 | pref2::mn1 | pref2::mn1 | pref2::mn1 | 512 |<----------->|<--------------->|<-------------------------->if1 513 | | | | | 514 | | | | | 515 | | | MN powers on if2 and 516 | | | performs L2 attachment 517 | | | |<-----------if2 518 | | | PBU | | 519 | |<--------------------------------| | 520 | | PBA (pref2) | | | 521 | |-------------------------------->| | 522 | LMA moves pref2 to new | | | 523 | binding cache entry for if2 | | | 524 | | | | | 525 | flow y to | flow y to | flow y to | 526 | pref2::mn1 | pref2::mn1 | pref2::mn1 | 527 |<----------->|<------------------------------->|<---------->if2 528 | | | | | 529 | | (optional) | | | 530 | | BRI[pref2] | | | 531 | |---------------->| | | 532 | | BRA | | | 533 | |<----------------| | | 534 | | | | | 536 Figure 6: Flow mobility message sequence with different set of 537 prefixes per physical interface (PBU signaling) 539 3.2.3. MN with combination of prefix(es) in use and new prefix(es) on 540 each MAG 542 This scenario is a hybrid of the ones described in Section 3.2.1 and 543 Section 3.2.2. It requires flow mobility signaling to enable 544 relocating flows for the new prefix(es) which are not shared across 545 attachments. 547 4. Message Formats 549 This section defines modifications to the Proxy Mobile IPv6 [RFC5213] 550 protocol messages. 552 4.1. Home Network Prefix 554 A new flag (L) is included in the Home Network Prefix mobility option 555 to indicate to the Mobile Access Gateway whether the conveyed prefix 556 has to be hosted on-link or not on the point-to-point interface with 557 the mobile node. A prefix is hosted off-link for the flow mobility 558 purposes defined in this document. The rest of the Home Network 559 Prefix mobility option format remains the same as defined in 560 [RFC5213]. 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type | Length |L| Reserved | Prefix Length | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | | 568 + + 569 | | 570 + Home Network Prefix + 571 | | 572 + + 573 | | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Off-link Home Network Prefix Flag (L): 578 The Off-link Home Network Prefix Flag is set to indicate to the 579 Mobile Access Gateway that the Home Network Prefix conveyed in the 580 option is not to be hosted on-link, but has to be considered for 581 flow mobility purposes and therefore added to the Mobile Access 582 Gateway routing table. If the flag is set to 0, the Mobile Access 583 Gateway assumes that the Home Network Prefix has to be hosted on- 584 link. 586 5. Conceptual Data Structures 588 This section summarizes the extensions to Proxy Mobile IPv6 that are 589 necessary to manage flow mobility. 591 5.1. Multiple Proxy Care-of Address Registration 593 The binding cache structure of the local mobility anchor is extended 594 to allow multiple proxy care of address (Proxy-CoA) registrations, 595 and support the mobile node use the same address (prefix) beyond a 596 single interface and mobile access gateway. The LMA maintains 597 multiple binding cache entries for an MN. The number of binding 598 cache entries for a mobile node is equal to the number of the MN's 599 interfaces attached to any MAGs. 601 This specification re-uses the extensions defined in [RFC5648] to 602 manage multiple registrations, but in the context of Proxy Mobile 603 IPv6. The binding cache is therefore extended to include more than 604 one proxy care-of addresses and to associate each of them with a 605 binding identifier (BID). Note that the BID is a local identifier, 606 assigned and used by the local mobility anchor to identify which 607 entry of the flow mobility cache is used to decide how to route a 608 given flow. 610 +---------+-----+-------+------+-----------+------------+ 611 | BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | 612 +---------+-----+-------+------+-----------+------------+ 613 | 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) | 614 | 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) | 615 +---------+-----+-------+------+-----------+------------+ 617 Figure 7: Extended Binding Cache 619 Figure 7 shows an example of extended binding cache, containing two 620 binding cache entries (BCEs) of a mobile node MN1 attached to the 621 network using two different access technologies. Both of the two 622 attachments share the same prefix (HNP1) and are bounded to two 623 different Proxy-CoAs (two MAGs). 625 5.2. Flow Mobility Cache 627 Each local mobility anchor MUST maintain a flow mobility cache (FMC) 628 as shown in Figure 8. The flow mobility cache is a conceptual list 629 of entries that is separate from the binding cache. This conceptual 630 list contains an entry for each of the registered flows. This 631 specification re-uses the format of the flow binding list defined in 632 [RFC6089]. Each enty includes the following fields: 634 o Flow Identifier Priority (FID-PRI). 636 o Flow Identifier (FID). 638 o Traffic Selector (TS). 640 o Binding Identifier (BID). 642 o Action. 644 o Active/Inactive. 646 +---------+-----+-----+------+---------+----------+ 647 | FID-PRI | FID | TS | BIDs | Action | A/I | 648 +---------+-----+-----+------+---------+----------+ 649 | 10 | 2 | TCP | 1 | Forward | Active | 650 | 20 | 4 | UDP | 1,2 | Forward | Inactive | 651 +---------+-----+-----+------+---------+----------+ 653 Figure 8: Flow Mobility Cache 655 The BID field contains the identifier of the binding cache entry 656 which packets matching the flow information described in the TS field 657 will be forwarded to. When a flow is decided to be moved, the 658 affected BID(s) of the table are updated. 660 Similar to flow binding described in [RFC6089], each entry of the 661 flow mobility cache points to a specific binding cache entry 662 identifier (BID). When a flow is moved, the local mobility anchor 663 simply updates the pointer of the flow binding entry with the BID of 664 the interface to which the flow will be moved. The traffic selector 665 (TS) in flow binding table is defined as in [RFC6088]. TS is used to 666 classify the packets of flows basing on specific parameters such as 667 service type, source and destination address, etc. The packets 668 matching with the same TS will be applied the same forwarding policy. 669 FID-PRI is the order of precedence to take action on the traffic. 670 Action may be forward or drop. If a binding entry becomes 'Inactive' 671 it does not affect data traffic. An entry becomes 'Inactive' only if 672 all of the BIDs are deregistered. 674 The mobile access gateway MAY also maintain a similar data structure. 675 In case no full flow mobility state is required at the MAG, the 676 Binding Update List (BUL) data structure is enough and no extra 677 conceptual data entries are needed. In case full per-flow state is 678 required at the mobile access gateway, it SHOULD also maintain a flow 679 mobility cache structure. 681 6. Mobile Node considerations 683 This specification assumes that the mobile node IP layer interface 684 can simultaneously and/or sequentially attach to multiple MAGs, 685 possibly over multiple media. The mobile node MUST be able to 686 enforce uplink policies to select the right outgoing interface. One 687 form to achieve this multiple attachment is described in 688 [I-D.ietf-netext-logical-interface-support], which allows the mobile 689 node supporting traffic flows on different physical interfaces 690 regardless of the assigned prefixes on those physical interfaces. 692 7. IANA Considerations 694 This specification defines a new value for the Handoff Indicator 695 {IANA-1} and a new flag (L) in the Home Network Mobility Option. 697 8. Security Considerations 699 The protocol signaling extensions defined in this document share the 700 same security concerns of Proxy Mobile IPv6 [RFC5213] and do not pose 701 any additional security threats to those already identified in 702 [RFC5213] and [I-D.ietf-netext-update-notifications]. 704 The mobile access gateway and the local mobility anchor MUST use the 705 IPsec security mechanism mandated by Proxy Mobile IPv6 [RFC5213] to 706 secure the signaling described in this document. 708 9. Authors 710 This document reflects contributions from the following authors (in 711 alphabetical order). 713 Kuntal Chowdhury 715 E-mail: Kchowdhu@cisco.com 717 Vijay Devarapalli 719 E-mail: vijay@wichorus.com 721 Sri Gundavelli 723 E-mail: sgundave@cisco.com 725 Youn-Hee Han 727 E-mail: yhhan@kut.ac.kr 729 Yong-Geun Hong 731 E-mail: yonggeun.hong@gmail.com 733 Mohana Dahamayanthi Jeyatharan 735 E-mail: mohana.jeyatharan@sg.panasonic.com 737 Rajeev Koodli 739 E-mail: rkoodli@cisco.com 741 Kent Leung 743 E-mail: kleung@cisco.com 745 Telemaco Melia 747 E-mail: Telemaco.Melia@alcatel-lucent.com 749 Bruno Mongazon-Cazavet 751 E-mail: Bruno.Mongazon-Cazavet@alcatel-lucent.com 753 Chan-Wah Ng 755 E-mail: chanwah.ng@sg.panasonic.com 757 Behcet Sarikaya 759 E-mail: sarikaya@ieee.org 761 Tran Minh Trung 763 E-mail: trungtm2909@gmail.com 765 Frank Xia 767 E-mail: xiayangsong@huawei.com 769 10. Acknowledgments 771 The authors would like to thank Juan-Carlos Zuniga, Pierrick Seite, 772 Julien Laganier for all the useful discussions on this topic. 774 The authors would also like to thank Marco Liebsch and Juan-Carlos 775 Zuniga for their reviews of this document. 777 The work of Carlos J. Bernardos has also been partially supported by 778 the European Community's Seventh Framework Programme under grant 779 agreement n. FP7-317941 (iJOIN project). 781 11. References 783 11.1. Normative References 785 [I-D.ietf-netext-update-notifications] 786 Krishnan, S., Gundavelli, S., Liebsch, M., Yokota, H., and 787 J. Korhonen, "Update Notifications for Proxy Mobile IPv6", 788 draft-ietf-netext-update-notifications-12 (work in 789 progress), October 2013. 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, March 1997. 794 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 795 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 797 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 798 and K. Nagami, "Multiple Care-of Addresses Registration", 799 RFC 5648, October 2009. 801 [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., 802 and P. Yegani, "Binding Revocation for IPv6 Mobility", 803 RFC 5846, June 2010. 805 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 806 "Traffic Selectors for Flow Bindings", RFC 6088, 807 January 2011. 809 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 810 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 811 Network Mobility (NEMO) Basic Support", RFC 6089, 812 January 2011. 814 11.2. Informative References 816 [I-D.ietf-netext-logical-interface-support] 817 Melia, T. and S. Gundavelli, "Logical Interface Support 818 for multi-mode IP Hosts", 819 draft-ietf-netext-logical-interface-support-08 (work in 820 progress), October 2013. 822 Author's Address 824 Carlos J. Bernardos (editor) 825 Universidad Carlos III de Madrid 826 Av. Universidad, 30 827 Leganes, Madrid 28911 828 Spain 830 Phone: +34 91624 6236 831 Email: cjbc@it.uc3m.es 832 URI: http://www.it.uc3m.es/cjbc/