idnits 2.17.1 draft-bernardos-netext-pmipv6-flowmob-03.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 (March 14, 2011) is 4785 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-01 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 March 14, 2011 5 Expires: September 15, 2011 7 Proxy Mobile IPv6 Extensions to Support Flow Mobility 8 draft-bernardos-netext-pmipv6-flowmob-03 10 Abstract 12 Proxy Mobile IPv6 (PMIPv6) is a network-based localized mobility 13 management protocol that enables mobile devices to connect to a 14 PMIPv6 domain and roam across gateways without changing their IP 15 addresses. PMIPv6 basic specification also provides limited multi- 16 homing support to multi-mode mobile devices. The ability of movement 17 of selected flows from one access technology to another is missing in 18 basic PMIPv6. This document describes enhancements to the Proxy 19 Mobile IPv6 protocol that are required to support flow mobility over 20 multiple physical interfaces. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 15, 2011. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Overview of the PMIPv6 flow mobility extensions . . . . . . . 4 65 3.1. Use case scenarios . . . . . . . . . . . . . . . . . . . . 4 66 3.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5 67 4. Message formats . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.1. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . . 11 69 4.2. Flow Mobility Acknowledge (FMA) . . . . . . . . . . . . . 13 70 5. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 14 71 5.1. Multiple Care-of Address Registration . . . . . . . . . . 14 72 5.2. Flow Mobility Cache . . . . . . . . . . . . . . . . . . . 14 73 6. Mobile Node considerations . . . . . . . . . . . . . . . . . . 16 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 80 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 81 Appendix A. Discussion items for IETF 80th . . . . . . . . . . . 18 82 A.1. Summary of the ML discussion . . . . . . . . . . . . . . . 19 83 A.2. Proposed changes for -04 version . . . . . . . . . . . . . 19 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network 89 based mobility management to hosts connecting to a PMIPv6 domain. 90 PMIPv6 introduces two new functional entities, the Local Mobility 91 Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the 92 entity detecting Mobile Node's (MN) attachment and providing IP 93 connectivity. The LMA is the entity assigning one or more Home 94 Network Prefixes (HNPs) to the MN and is the topological anchor for 95 all traffic belonging to the MN. 97 PMIPv6 allows an MN to connect to the same PMIPv6 domain through 98 different interfaces. The "logical interface" at the IP layer may 99 enable packet transmission and reception over different physical 100 media. This technique can be used to achieve flow mobility, i.e., 101 the movement of selected flows from one access technology to another. 102 It is assumed that an IP layer interface can simultaneously and/or 103 sequentially attach to multiple MAGs (possibly over multiple media). 104 This document specifies protocol extensions to Proxy Mobile IPv6 105 between the LMA and MAGs for distributing specific traffic flows on 106 different physical interfaces. This document assumes that a "logical 107 interface" at the Mobile Node is capable of supporting traffic flows 108 from different physical interfaces regardless of the assigned 109 prefixes on those physical interfaces. 111 In particular, this document specifies how to manage "flow mobility" 112 state in the PMIPv6 network (i.e. LMAs and MAGs), namely creation, 113 refresh and cancel operation. Flow mobility is controlled by the 114 LMA. The trigger causing the LMA to initiate a flow mobility 115 operation is out of scope of this specification. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC2119 [RFC2119]. 123 The following terms used in this document are defined in the Proxy 124 Mobile IPv6 [RFC5213]: 126 Local Mobility Agent (LMA). 128 Mobile Access Gateway (MAG). 130 Proxy Mobile IPv6 Domain (PMIPv6-Domain). 132 LMA Address (LMAA). 134 Proxy Care-of Address (Proxy-CoA). 136 Home Network Prefix (HNP). 138 The following terms are defined and used in this document: 140 FMI (Flow Mobility Initiate). Message sent by the LMA to create, 141 refresh or cancel flow mobility state in the MAG. It conveys the 142 information required to manage the flow mobility in a PMIPv6- 143 Domain. This message is only needed when the flow mobility 144 operation is not triggered by the attachment of a new interface of 145 the mobile node. 147 FMA (Flow Mobility Acknowledge). Message sent by the MAG in reply to 148 an FMI message. It provides feedback about the result of a flow 149 mobility creation, refresh or cancel operation requested in the 150 FMI message. 152 FMC (Flow Mobility Cache). Conceptual data structure maintained by 153 the LMA and the MAG to support the flow mobility management 154 operations described in this document. 156 3. Overview of the PMIPv6 flow mobility extensions 158 3.1. Use case scenarios 160 Flow mobility assumes simultaneous access to more than one network, 161 in a contrast to a typical handover where connectivity to a physical 162 medium is relinquished, and is re-established with another. In order 163 to support flow mobility in a PMIPv6 network, it is required to be 164 able to to tie the different PMIPv6 mobility sessions (one per 165 interface) to a logical interface which is hiding one or more 166 physical interfaces. The different mobility sessions in which a 167 mobile node may be involved can share the same set of prefixes or 168 have different ones: 170 1. At the time of a new network attachment, the MN obtains a new 171 prefix or a new set of prefixes for the new session. This is the 172 default behavior with RFC 5213. 174 2. At the time of a new network attachment, the MN obtains the same 175 prefix or the same set of prefixes as already assigned to an 176 existing session. This is not the default behavior in RFC 5213, 177 and the LMA needs to be able to provide the same assignment even 178 for the simultaneous attachment (as opposed to the handover 179 scenario only). It is assumed for the sake of this specification 180 that the LMA has the knowledge if the MN supports the logical 181 interface and if to assign the same prefix(es) or different 182 prefix(es) to both access networks. How this is done is outside 183 of the scope of this specification. 185 3. At the time of a new network attachment, the MN obtains a 186 combination of prefix(es) in use and new prefix(es). This is a 187 hybrid of the above two scenarios. The local policy determines 188 whether the new prefix is exclusive to the new attachment or it 189 can be assigned to an existing attachment as well. 191 Among the above, scenario 2 MAY need extensions to RFC 5213 signaling 192 at the time of a new attachment, to ensure that the same prefix (or 193 set of prefixes) is assigned to all the interfaces of the same mobile 194 node that are simultaneously attached. Subsequently, no further 195 signaling may be necessary between the LMA and the MAG. 197 The scenario 1 requires flow mobility signaling whenever the LMA 198 determines the need for relocating flows between the different 199 attachments, so the MAGs are aware of the prefixes for which the MN 200 is going to receive traffic, and local routing entries are configured 201 accordingly. 203 The scenario 3 requires flow mobility signaling whenever the LMA 204 determines the need for relocating flows for the new prefix(es) which 205 are not shared across attachments. 207 In all the scenarios, the MAGs should be aware of the prefixes for 208 which the MN is going to receive traffic. As a result of a flow 209 mobility operation, these prefixes might not be limited to those 210 delegated by the MAG upon attachment of the connected interface, and 211 therefore in these cases, signaling is required. 213 The extensions described in this document support any of these 214 aforementioned scenarios. 216 3.2. Basic Operation 218 This section describes how the PMIPv6 extensions described in this 219 document provide flow mobility support. 221 When a multi-interfaced mobile node connects to a PMIPv6-domain, it 222 performs regular attachment and as a result is able to configure an 223 IP address (or a set of IP addresses) on the logical interface hiding 224 the different physical interfaces. If the LMA assigns a common 225 prefix (or set of prefixes) to the different physical interfaces 226 attached to the domain, then all the MAGs have already all the 227 routing knowledge required to forward packets to the mobile node, and 228 the LMA does not need to perform any kind of signaling in order to 229 move flows across the different physical interfaces. Note that there 230 should be a local policy in place that ensures that the mobile node 231 sends outbound packets using the same physical interface from which 232 packets belonging to the same flow are being received (the used 233 interface might change during the lifetime of a communication). This 234 SHOULD be enforced by the logical interface engine, and the details 235 about how this is done are out of the scope of this document). For 236 unidirectional outbound communications, there SHOULD be a policy at 237 the mobile node defining which physical interface is used to send the 238 traffic. For bidirectional outbound communications, there SHOULD be 239 also such a policy, but its content must be consistent with the 240 policy at the network-side (the details about how this consistency is 241 ensured are out of the scope of this document). 243 In case the MAGs needs to be informed about flow mobility decisions, 244 because of packet policing, packet enforcement, charging or similar 245 reasons, the LMA MAY re-use the signaling defined later in this 246 document to convey this information. 248 LMA Binding Cache 249 +---+ ======================= 250 |LMA| MN1, if1, pref1, MAG1 251 +---+ MN1, if2, pref1, MAG2 252 //\\ 253 +---------//--\\-------------+ 254 ( // \\ ) PMIPv6 domain 255 ( // \\ ) 256 +------//--------\\----------+ 257 // \\ 258 // \\ 259 +----+ +----+ 260 |MAG1| |MAG2| 261 +----+ +----+ 262 | | 263 | +-------+ | 264 | | I P | | 265 | +-------+ | 266 | | lif | | 267 | +---+---+ | 268 |---|if1|if2|----| 269 +---+---+ 270 MN1 272 Figure 1: Shared prefix across physical interfaces scenario 274 Next, an example of how flow mobility works in this case is shown. 276 In Figure 1, a mobile node (MN1) has two different physical 277 interfaces (if1 and if2), grouped in a unique logical interface 278 (lif). Each physical interface is attached to a different MAG, both 279 of them anchored and controlled by the same LMA. Since both physical 280 interfaces are assigned the same prefix (pref1) upon attachment to 281 the MAGs, the mobile node has one single IPv6 addresses configured on 282 the logical interface: pref1::lif. Initially, flow X goes through 283 MAG1 and flow Y through MAG2. The LMA, at a certain point, decides 284 to move flow Y, so it also goes through MAG1. As show in Figure 2, 285 no signaling between the LMA and the MAGs is needed. 287 +-----+ +------+ +------+ +-----+ 288 Internet | LMA | | MAG1 | | MAG2 | | MN1 | 289 +-----+ +------+ +------+ +-----+ 290 | | | | | 291 | flow X to | flow X to | flow X to | 292 | pref1:lif | pref1:lif | pref1:lif | 293 |<----------->|<--------------->|<-------------------------->if1 294 | flow Y to | flow Y to | flow Y to | 295 | pref1:lif | pref1:lif | pref1:lif | 296 |<----------->|<------------------------------->|<---------->if2 297 | | | | | 298 | LMA decision | | | 299 | to move flow Y | | | 300 | | | | | 301 | flow Y to | flow Y to | flow Y to | 302 | pref1:lif | pref1:lif | pref1:lif | 303 |<----------->|<--------------->|<-------------------------->if1 304 | | | | | 306 Figure 2: Flow mobility message sequence when the LMA assigns a 307 common set of prefixes 309 Figure 3 shows the state of the different network entities after 310 moving flow Y in the previous example. 312 LMA Binding Cache LMA flowmob state 313 (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) 314 +---+ ========================== =================== 315 |LMA| 1, MN1, if1, pref1, MAG1 1, flow X 316 +---+ 2, MN1, if2, pref1, MAG2 1, flow Y 317 //\\ 318 +---------//--\\-------------+ 319 ( // \\ ) PMIPv6 domain 320 ( // \\ ) 321 +------//--------\\----------+ 322 // \\ 323 // \\ MAG1 routing state 324 +----+ +----+ ================================ 325 |MAG1| |MAG2| (dest) (next hop) 326 +----+ +----+ pref1::/64 p2p-iface-with-MN1 327 | | ::/0 LMA 328 | +-------+ | 329 | | I P | | MAG2 routing state 330 | +-------+ | ================================ 331 | | lif | | (dest) (next hop) 332 | +---+---+ | pref1::/64 p2p-iface-with-MN1 333 |---|if1|if2|----| ::/0 LMA 334 +---+---+ 335 MN1 337 Figure 3: Data structures when the LMA assigns a common set of 338 prefixes 340 A different flow mobility scenario happens when the LMA assigns 341 different set of prefixes to physical interfaces of the same mobile 342 node. In this case specific signaling is required between the LMA 343 and the MAG to support this scenario. Two different possibilities 344 are considered next. 346 One first possible case is the following (shown in Figure 4). The 347 mobile node is already attached to the PMIPv6-Domain via MAG1. At a 348 certain moment, the mobile node attaches a new interface (if2) to 349 MAG2. MAG2 sends a PBU which is then used as a trigger by the LMA to 350 decide perform a flow mobility decision. In this case, we consider 351 that flows are moved with a prefix granularity, meaning that the LMA 352 moves flows by moving prefixes among the different MAGs the mobile 353 node is attached to. In this example, flow Y is bound to pref2::/64 354 and therefore the LMA can move the flow by just binding pref2::/64 to 355 MAG2. This is done by including the prefix in the PBA message, and 356 optionally sending a message to MAG1 to remove the transferred 357 prefix(es). This message can be a Binding Revocation Indication 358 message [RFC5846] with the P bit set to indicate that this is 359 revocation of PMIP prefix(es). After processing BRI, the source MAG 360 will send a Binding Revocation Acknowledgement (BRA) message back to 361 LMA. 363 Note that this specification also supports flow mobility at a finer 364 granularity (not just on a prefix level). This is done by including 365 in the PBA a Flow Identification Mobility option (specified in 366 [RFC6089]) which can convey full flow information. The MAG can also 367 include the Flow Identification Mobility option in the PBU message 368 that it sends to the LMA. This serves as a request for the LMA to 369 consider the flow policy rules specified in the option. 371 +-----+ +------+ +------+ +-----+ 372 Internet | LMA | | MAG1 | | MAG2 | | MN | 373 +-----+ +------+ +------+ +-----+ 374 | | | | | 375 | flow X to | flow X to | flow X to | 376 | pref1:lif | pref1:lif | pref1:lif | 377 |<----------->|<--------------->|<-------------------------->if1 378 | flow Y to | flow Y to | flow Y to | 379 | pref2:lif | pref2:lif | pref2:lif | 380 |<----------->|<--------------->|<-------------------------->if1 381 | | | | | 382 | | | | | 383 | | | MN powers on if2 and 384 | | | perform a L2 attachment 385 | | | |<-----------if2 386 | | | PBU | | 387 | |<--------------------------------| | 388 | | PBA (pref2) | | | 389 | |-------------------------------->| | 390 | LMA moves pref2 to new | | | 391 | binding cache entry for if2 | | | 392 | | | | | 393 | | | | | 394 | | (optional) | | | 395 | | BRI[pref2] | | | 396 | |---------------->| | | 397 | | BRA | | | 398 | |<----------------| | | 399 | flow y to | flow y to | flow y to | 400 | pref2:lif | pref2:lif | pref2:lif | 401 |<----------->|<------------------------------->|<---------->if2 402 | | | | | 404 Figure 4: Flow mobility message sequence when the LMA assigns 405 different set of prefixes per physical interface (PBU trigger) 407 A second possible scenario is the following. A multi-interfaced 408 mobile node is attached to a PMIPv6-Domain and the LMA, at a given 409 moment, decides to move a flow. The LMA can decide to move a flow as 410 a result of a policy change or upon receiving a trigger either based 411 on network status or based on an event detected at the mobile node 412 and transported via old or new MAG. How this decision is taken is 413 out of scope of this specification. Since the LMA cannot send a PBA 414 message which has not been triggered in response to a received PBU 415 message, new signaling messages are defined to cover this case. 417 +-----+ +------+ +------+ +-----+ 418 Internet | LMA | | MAG1 | | MAG2 | | MN1 | 419 +-----+ +------+ +------+ +-----+ 420 | | | | | 421 | flow X to | flow X to | flow X to | 422 | pref1:lif | pref1:lif | pref1:lif | 423 |<----------->|<--------------->|<-------------------------->if1 424 | flow Y to | flow Y to | flow Y to | 425 | pref2:lif | pref2:lif | pref2:lif | 426 |<----------->|<------------------------------->|<---------->if2 427 | | | | | 428 | LMA decision | | | 429 | to move flow Y | | | 430 | | FMI[MN1-ID,flow_info(Y),add] | | 431 | |---------------->| | | 432 | | FMA | | | 433 | |<----------------| | | 434 | LMA moves | | | 435 | flow Y | | | 436 | | (optional) | | 437 | | FMI[MN1-ID,flow_info(Y),del] | | 438 | |-------------------------------->| | 439 | | | FMA | | 440 | |<--------------------------------| | 441 | flow Y to | flow Y to | flow Y to | 442 | pref2:lif | pref2:lif | pref2:lif | 443 |<----------->|<--------------->|<-------------------------->if1 444 | | | | | 446 Figure 5: Flow mobility message sequence when the LMA assigns 447 different set of prefixes per physical interface (FMI trigger) 449 If the LMA decides to move a particular flow from its default path 450 (which is determined by the destination prefix) to a different one, 451 it constructs a Flow Mobility Initiate (FMI) message. This message 452 is sent to the new target MAG, i.e. the one selected to be the used 453 in the forwarding of the flow. The FMI message contains (as 454 explained in further detail in Section 4.1), the MN-Identifier, the 455 Flow Identification Mobility option (specified in [RFC6089]) which 456 can convey prefix or full flow information, and the type of flow 457 mobility operation (add flow). Optionally, the LMA may send another 458 FMI message, this time to remove the flow Y state at MAG2. Otherwise 459 the flow state at MAG2 will be removed upon timer expiration. The 460 message sequence is shown in Figure 5. 462 The state in the network after moving a flow, for the case the LMA 463 assigns a different set of prefixes is shown in Figure 6. 465 LMA Binding Cache LMA flowmob state 466 (BID, MN-ID, ATT, HNP, PCoA) (BID, TS) 467 +---+ ========================== =================== 468 |LMA| 1, MN1, if1, pref1, MAG1 1, flow X 469 +---+ 2, MN1, if2, pref2, MAG2 2, flow Y 470 //\\ 471 +---------//--\\-------------+ 472 ( // \\ ) PMIPv6 domain 473 ( // \\ ) 474 +------//--------\\----------+ 475 // \\ 476 // \\ MAG1 routing state 477 +----+ +----+ ================================ 478 |MAG1| |MAG2| (dest) (next hop) 479 +----+ +----+ pref1::/64 p2p-iface-with-MN1 480 | | ::/0 LMA 481 | +-------+ | 482 | | I P | | MAG2 routing state 483 | +-------+ | ================================ 484 | | lif | | (dest) (next hop) 485 | +---+---+ | pref2::/64 p2p-iface-with-MN1 486 |---|if1|if2|----| ::/0 LMA 487 +---+---+ 488 MN1 490 Figure 6: Data structures when the LMA assigns a different set of 491 prefixes 493 4. Message formats 495 4.1. Flow Mobility Initiate (FMI) 497 The LMA sends an FMI message to a MAG to inform about a particular 498 flow movement (LMA initiated). It is a Mobility Header message. 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Sequence # | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 |I|C|R| Reserved | Lifetime | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | | 508 . . 509 . Mobility options . 510 . . 511 | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Sequence Number: 516 A monotonically increasing integer. Set by the LMA sending then 517 initiate message, and used to match a reply in the acknowledge. 519 'I' (initiate) flag: 521 Set to 1, indicates it is an FMI message. 523 'C' (cancel) flag: 525 When set to 1, indicates a request to remove state about the flow 526 (cancel flow mobility). If set to 1, the Lifetime field MUST be 527 set to 0. 529 'R' (refresh) flag: 531 When set to 1, indicates a request to refresh state about the 532 flow. If the 'C' flag is set to 1, this flag should be set to 0 533 by the sender and ignored by the receiver. 535 Reserved: 537 This field is unused. MUST be set to zero by the sender. 539 Lifetime: 541 The requested time in seconds for which the LMA asks the MAG keep 542 flow-specific state. A value of all one bits (0xffff) represents 543 infinity. 545 Mobility Options: 547 MUST contain the MN-ID, followed by one or more Flow 548 Identification Mobility options [RFC6089]. 550 4.2. Flow Mobility Acknowledge (FMA) 552 The MAG sends an FMI message to the LMA as a response to the FMI 553 message. It is a Mobility Header message. 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Sequence # | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 |I| Reserved | Status | Lifetime | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | | 563 . . 564 . Mobility options . 565 . . 566 | | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Sequence Number: 571 A monotonically increasing integer. Copied from the value set by 572 the sending LMA in the FMI message being acknowledged by this FMA 573 message. 575 'I' flag: 577 Set to 0, indicates it is an FMA message. 579 Reserved: 581 This field is unused. MUST be set to zero by the sender. 583 Status: 585 0: Success. 587 128: Reason unspecified. 589 129: MN not attached. 591 130: Sequence number out of window. 593 131: Traffic Selector format unsupported. 595 132: No existing Flow Mobility Cache entry. 597 133: Already existing Flow Mobility Cache entry. 599 Lifetime: 601 The requested time in seconds for which the MAG keeps flow- 602 specific state. A value of all one bits (0xffff) represents 603 infinity. 605 Mobility Options: 607 When Status code is 0, MUST contain the MN-ID, followed by one or 608 more Flow Identification Mobility options [RFC6089]. 610 5. Conceptual Data Structures 612 5.1. Multiple Care-of Address Registration 614 The LMA is extended to allow a mobile node to register multiple proxy 615 care of address (Proxy-CoA). The LMA maintains multiple binding 616 cache entries for a MN. The number of binding cache entries of a MN 617 is equal to the number of the MN's interfaces attaching to the MAG. 619 +---------+-----+-------+------+-----------+------------+ 620 | BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | 621 +---------+-----+-------+------+-----------+------------+ 622 | 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) | 623 | 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) | 624 +---------+-----+-------+------+-----------+------------+ 626 Figure 7: Extended Binding Cache 628 Figure 7 shows two Binding Cache Entries of the MN1 when it attaches 629 to the network using two different access technologies. Both of the 630 two attachments share HNP1 and are bounded to two different Proxy- 631 CoAs. 633 5.2. Flow Mobility Cache 635 Each LMA must maintain a flow mobility cache (FMC) as shown in 636 Figure 8. This table contains entry for each flow sent from the MN. 637 A flow binding entry includes the following fields: 639 o Flow Identifier - Priority (FID-PRI)- 641 o Flow Identifier (FID). 643 o Traffic Selector (TS). 645 o Binding Identifier (BID). 647 o Action. 649 o Active/Inactive. 651 +---------+-----+-----+------+---------+----------+ 652 | FID-PRI | FID | TS | BIDs | Action | A/I | 653 +---------+-----+-----+------+---------+----------+ 654 | 10 | 2 | TCP | 1 | Forward | Active | 655 | 20 | 4 | UDP | 1,2 | Forward | Inactive | 656 +---------+-----+-----+------+---------+----------+ 658 Figure 8: Flow Mobility Cache 660 The BIDs field contains the identifier of the binding cache entry 661 that all of the packets matching the flow information described in 662 the TS field will be forwarded to. When the flow mobility occurs, 663 the BIDs will be updated with new binding cache entry identifier. 665 Similar to flow binding described in [RFC6089], each flow binding 666 entry points to a specific binding cache entry identifier (BID). 667 When the LMA decides to move a flow, it simply updates the pointer of 668 the flow binding entry with the BID of the interface to which the 669 flow will be moved. The traffic selector (TS) in flow binding table 670 is defined as in [RFC6088]. TS is used to classify the packets of 671 flows basing on specific parameters such as service type, source and 672 destination address, etc. The packets matching with the same TS will 673 be applied the same forwarding policy. FID-PRI is the order of 674 precedence to take action on the traffic. Action may be forward or 675 drop. If a binding entry becomes 'Inactive' it does not affect data 676 traffic. An entry becomes 'Inactive' only if all of the BIDs are 677 deregistered. 679 The Mobile Access Gateway MAY also maintain a similar data structure. 680 In case no full flow mobility state is required at the MAG, the 681 Binding Update List (BUL) data structure is enough and no extra 682 conceptual data entries are needed. In case full per-flow state is 683 required at the MAG, it should keep a similar structure to the FMC 684 (details TBD). 686 6. Mobile Node considerations 688 This specification assumes the MN implements the logical interface 689 model. The "logical interface" at the IP layer hides the use of 690 different physical media from the IP stack, enabling the MN to send 691 and receive packets over different interfaces. This document assumes 692 the MN behaves as stated in the applicability statement document 693 [I-D.ietf-netext-logical-interface-support]. In particular, it is 694 assumed that -- for the case of bidirectional traffic -- the logical 695 interface at the MN "replicates" the behavior observed for downlink 696 packets on a per-flow basis. This means that the MN sends UL Flow X 697 on the same interface which received the DL Flow X. It also means 698 that if the LMA moves flow X during its lifetime, the MN will follow 699 that change, upon the reception of packets of flow X via a different 700 interface. 702 This specification only supports flow mobility between different 703 physical interfaces belonging to the same logical interface. If an 704 MN has several logical interfaces, flow mobility across different 705 logical interfaces is not supported. 707 7. IANA Considerations 709 TBD. 711 8. Security Considerations 713 TBD. 715 9. Authors 717 This document reflects contributions from the following authors (in 718 alphabetical order). 720 Kuntal Chowdhury 722 E-mail: Kchowdhu@cisco.com 724 Vijay Devarapalli 726 E-mail: vijay@wichorus.com 728 Sri Gundavelli 729 E-mail: sgundave@cisco.com 731 Youn-Hee Han 733 E-mail: yhhan@kut.ac.kr 735 Yong-Geun Hong 737 E-mail: yonggeun.hong@gmail.com 739 Mohana Dahamayanthi Jeyatharan 741 E-mail: mohana.jeyatharan@sg.panasonic.com 743 Rajeev Koodli 745 E-mail: rkoodli@cisco.com 747 Kent Leung 749 E-mail: kleung@cisco.com 751 Telemaco Melia 753 E-mail: Telemaco.Melia@alcatel-lucent.com 755 Bruno Mongazon-Cazavet 757 E-mail: Bruno.Mongazon-Cazavet@alcatel-lucent.com 759 Chan-Wah Ng 761 E-mail: chanwah.ng@sg.panasonic.com 763 Behcet Sarikaya 765 E-mail: sarikaya@ieee.org 767 Tran Minh Trung 769 E-mail: trungtm2909@gmail.com 771 Frank Xia 773 E-mail: xiayangsong@huawei.com 775 10. Acknowledgments 777 The authors would like to thank Juan-Carlos Zuniga, Pierrick Seite, 778 Julien Laganier for all the discussions on this topic. 780 11. References 782 11.1. Normative References 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, March 1997. 787 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 788 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 790 [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., 791 and P. Yegani, "Binding Revocation for IPv6 Mobility", 792 RFC 5846, June 2010. 794 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 795 "Traffic Selectors for Flow Bindings", RFC 6088, 796 January 2011. 798 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 799 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 800 Network Mobility (NEMO) Basic Support", RFC 6089, 801 January 2011. 803 11.2. Informative References 805 [I-D.ietf-netext-logical-interface-support] 806 Melia, T. and S. Gundavelli, "Logical Interface Support 807 for multi-mode IP Hosts", 808 draft-ietf-netext-logical-interface-support-01 (work in 809 progress), October 2010. 811 Appendix A. Discussion items for IETF 80th 813 This appendix tries to serve as basis for the discussion in the IETF 814 80th on flow mobility. It includes a summary of the major issues/ 815 comments raised on the NETEXT mailing list, as well as a proposed 816 plan for a future revision of the document. 818 A.1. Summary of the ML discussion 820 Here we list (in no particular order) some of the issues raised on 821 the NETEXT mailing list: 823 o Lack of realistic scenario for applicability: no use-case/client 824 for LMA-initiated mobility, no real-life scenario where the LMA 825 would receive flow mobility policies. 827 o Consistency of policy rules between the MN and LMA does not ensure 828 that the LMA knows what decision the MN took because the LMA does 829 not necessarily knows the context in which the MN is. 831 o Discrepancies on the solution approach: dynamic attachment/ 832 dettachment of interfaces from sessions (new prefixes cannot be 833 added to sessions) vs dynamic prefix management. It's being 834 argued that the draft changes the basics of RFC5213 session 835 management. 837 o Discrepancies on the solution approach: requirement on the 838 existance of L2 triggers to aid in the dynamic attachment/ 839 dettachment of interfaces from sessions for flow mobility 840 purposes. 842 o How does the LMA know channel condition of each radio, 843 applications requirements of apps running in the UE?. 845 o Source of triggers for flow mobility: MAG, LMA or both? 847 A.2. Proposed changes for -04 version 849 Based on the discussion on the ML list, a possible way to modify this 850 document in -04 version is the following. We define two different 851 approaches, based on the L2 signaling support: 853 1. L2 signaling based. When an MN attaches to a new MAG, it can use 854 extended L2 signaling (e.g., HI=FM) to indicate that the 855 attachment is for flow mobility. In this case, same prefix is 856 assigned to the new interface (which is added to the existing 857 mobility session). Alternatively, a new prefix can also be added 858 to the session (this is up to the policy configured). Now new 859 signaling is required between MAG and LMA, just a new HI value, 860 the extended L2 signaling in place and updating the state 861 machines of MAG and LMA to support this new behavior. 863 2. IP based. If no extended L2 signaling is available (i.e., no 864 HI=FM), MAGs create new sessions upon new MN interface 865 attachment. The LMA manages the prefixes of the session (decides 866 to assign the same of an already attached interface or a new one) 867 as well as the movement of them (with a prefix/flow granularity). 868 The trigger for the movement of a flow is out of scope (MAG 869 triggers are considered). This is basically the operation 870 described in the current version of the draft. 872 Author's Address 874 Carlos J. Bernardos (editor) 875 Universidad Carlos III de Madrid 876 Av. Universidad, 30 877 Leganes, Madrid 28911 878 Spain 880 Phone: +34 91624 6236 881 Email: cjbc@it.uc3m.es 882 URI: http://www.it.uc3m.es/cjbc/