idnits 2.17.1 draft-xue-netext-flowmo-multilma-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 6) being 73 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: In multi-LMA environment, we assume that traffic flows distributed on different interfaces can be anchored in different LMAs. Each LMA logically manages a different group of MAGs, however it is unaware of the MAGs registered on other LMAs and the corresponding interfaces attached. Thus, one LMA SHALL NOT communicate with the MAG under another LMA without the help of this LMA. In this specification, selected flows after flow mobility SHALL not change the anchored LMA but MN's interfaces and corresponding MAGs SHOULD adjust accordingly. Policy Profile SHOULD exist in a PMIPv6 domain implemented in AAA server, which maintains addresses of all the LMAs in the same domain on a per-interface basis. This specification uses the default behavior in basic PMIPv6[RFC5213], in which the MN obtains a prefix or a new set of prefixes for the new session at the time of a new interface attachment. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Figure 2 shows Case 1 of scenario-(a), in which both different physical interfaces of the MN are initially both powered on. Flow X(bound to pref1::/64) goes through if1-MAG-LMA1 and flow Y(bound to pref2::/64) goes through if2-MAG-LMA2. At a certain time, MAG detects the congestion of if2, and flow Y is decided to be moved to if1. Flow Y can be moved just by updating the routing state at MAG locally, binding pref2 with if1. No signaling exchange between LMA and MAG is needed. The binding cache entry at LMA SHOULD not make any change. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: As the prefixes assigned to these sessions are only maintained in LMA2, the anchor of flow Y MUST not change at all. Both in these two cases, the path of flow Y between MAG and MN's interfaces is changeable, meanwhile the tunnel used to transmit the packets of flow Y between MAG and LMA2 is unaltered. And in both cases, only MAG is REQUIRED to update routing state, no more signaling exchange between LMA and MAG is needed. The binding cache entry at LMA SHOULD not make any change unless a PBU requests it to. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Figure 4 shows an example of Scenario 2. MN is implemented with two different physical interfaces (if1 and if2), grouped in a logical one (lif).Each physical interface is attached to a different MAG and anchored in a different LMA. Initially, flow X(bound to pref1::/64) goes through path if1-MAG1-LMA1 and flow Y(bound to pref2::/64) goes through path if2-MAG2-LMA2. At a certain time, flow Y needs to be moved to the path if1-MAG1-LMA2. The anchor MUST not change after flow mobility. A new tunnel SHOULD be established between LMA2 and MAG1 to transmit packets of flow Y. But initially the LMA in one path has no knowledge of the interface and corresponding MAG in another path, and it needs the help of another LMA. To enable flow mobility, LMA2 MUST send request to Policy Profile to search for LMA information of a proper interface under the same MN-ID. LMA2 gets the address of LMA1 and IF1-ID after REQ-ACK message exchanging with policy profile. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 20, 2013) is 3955 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: 'RFC 6463' is mentioned on line 97, but not defined == Missing Reference: 'I-D.draft-jeyatharan-netlmm-multi-interface-ps' is mentioned on line 99, but not defined == Missing Reference: 'RFC 5213' is mentioned on line 139, but not defined == Missing Reference: 'RFC5648' is mentioned on line 154, but not defined == Missing Reference: 'MN1-ID' is mentioned on line 512, but not defined == Missing Reference: 'IF1-ID' is mentioned on line 512, but not defined == Missing Reference: 'RFC4301' is mentioned on line 812, but not defined == Unused Reference: 'RFC5846' is defined on line 828, but no explicit reference was found in the text == Unused Reference: 'RFC6463' is defined on line 841, but no explicit reference was found in the text == Unused Reference: 'I-D.bernardos-dmm-distributed-anchoring' is defined on line 847, but no explicit reference was found in the text == Unused Reference: 'I-D.jeyatharan-netlmm-multi-interface-ps' is defined on line 862, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-bernardos-dmm-distributed-anchoring-02 == Outdated reference: A later version (-14) exists of draft-ietf-netext-logical-interface-support-07 == Outdated reference: A later version (-18) exists of draft-ietf-netext-pmipv6-flowmob-06 Summary: 1 error (**), 0 flaws (~~), 21 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG K. Xue 3 Internet-Draft D. Ni 4 Intended status: Standards Track P. Hong 5 Expires: December 22, 2013 USTC 6 H. Chan 7 Huawei 8 June 20, 2013 10 Flow Mobility In Multi-LMA Environment 11 draft-xue-netext-flowmo-multilma-02.txt 13 Abstract 15 PMIPv6 allows multiple Local Mobility Anchors(LMA) to exist in a 16 PMIPv6 domain, it MAY cause that different interfaces of a mobile 17 node(MN) are anchored in different LMAs. This document proposes the 18 extensions of Proxy Mobile IPv6 protocol to support flow mobility in 19 multi-LMA environment. Among all the scenarios discussed here, the 20 scenario in which different interfaces with different MAGs in multi- 21 LMA environment cannot use traditional ways to realize flow mobility 22 to an existing interface. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 22, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 72 2.1. Conventions Used in This Document . . . . . . . . . . . . 3 73 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Overview of PMIPv6-based Flow Mobility Extensions in Multi- 75 LMA Environment . . . . . . . . . . . . . . . . . . . . . . . 4 76 3.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5 78 3.2.1. Different Interfaces with a Shared MAG . . . . . . . 5 79 3.2.2. Different Interfaces with Different MAGs . . . . . . 7 80 4. Select the Target Interface . . . . . . . . . . . . . . . . . 13 81 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 13 82 5.1. Enhanced Flow Mobility Initiate(eFMI) . . . . . . . . . . 14 83 5.2. Enhanced Flow Mobility Acknowledge(eFMA) . . . . . . . . 15 84 6. Conceptual Data Structures . . . . . . . . . . . . . . . . . 16 85 6.1. Multiple Care-of Address Registration . . . . . . . . . . 16 86 6.2. Flow Mobility Cache . . . . . . . . . . . . . . . . . . . 16 87 6.3. Mobile Node's policy profile . . . . . . . . . . . . . . 18 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 8.2. Informative References . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 95 Since single LMA environment MAY cause single point failure, multi- 96 LMA environment is proposed and some documents have discussed issues 97 in such environment. In [RFC 6463], runtime LMA assignment is 98 proposed for the purpose of load sharing in multi-LMA environment. 99 [I-D.draft-jeyatharan-netlmm-multi-interface-ps] also introduces the 100 scenario in which MN's multiple interfaces are attached to the same 101 MAG but anchored in different LMAs. 103 In the architecture of 3GPP, P-GW plays the role of LMA. There are 104 two real deployment examples in 3GPP architecture to support multi- 105 LMA environment. 1) In the flow based mobility scenarios, UE can use 106 local P-GW to carry new generated flow and home P-GW to carry former 107 flow simultaneously; 2)UE can use different P-GWs to access different 108 services. 110 Also in the discussion of distributed mobility management [I-D.draft- 111 bernardos-dmm-distributed-anchoring], with mobility different 112 sessions of a MN MAY be anchored in different D-MAG. This scenario 113 is similar to multi-LMA environment. 115 PMIPv6 allows a MN to access Internet services through different 116 interfaces in the same PMIPv6 domain, and it also allows multiple 117 LMAs to exist in the same domain. In such environment, MN's multiple 118 interfaces can be controlled by multiple LMAs. However, the existing 119 flow mobility technology [I-D.ietf-netext-pmipv6-flowmob] is not 120 complete, it is only applicable to the scenario with a single LMA. 121 This document specifies protocol extensions to enable flow mobility 122 on different physical interfaces in multi-LMA environment. This 123 document assumes that the mobile node(MN) implements the logical 124 interface model [I-D.ietf-netext-logical-interface-support], prefixes 125 of specific flows are transferred on different physical interfaces in 126 a loose way regardless of the assigned prefixes on these interfaces. 128 2. Conventions and Terminology 130 2.1. Conventions Used in This Document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2.2. Terminology 138 The following terms used in this document are defined in the Proxy 139 Mobile IPv6 [RFC 5213]: 141 Local Mobility Agent (LMA). 143 Mobile Access Gateway (MAG). 145 Proxy Mobile IPv6 Domain (PMIPv6-Domain). 147 LMA Address (LMAA). 149 Proxy Care-of Address (Proxy-CoA). 151 Home Network Prefix (HNP). 153 The following terms used in this document are defined in the Multiple 154 Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile 155 IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]: 157 Binding Identification Number (BID). 159 Flow Identifier (FID). 161 Traffic Selector (TS). 163 The following terms are defined and used in this document: 165 eFMI (enhanced Flow Mobility Initiate). Message sent by the LMA to 166 the MAG, may be forwarded by another LMA managing this MAG, conveying 167 the information required to enable flow mobility in a PMIPv6-Domain. 169 eFMA (enhanced Flow Mobility Acknowledge). Message sent by the MAG 170 in reply to an eFMI message. 172 FMC(Flow Mobility Cache). Conceptual data structure maintained by 173 the LMA and the MAG to support the flow mobility management 174 operations described in this document. 176 3. Overview of PMIPv6-based Flow Mobility Extensions in Multi-LMA 177 Environment 179 3.1. Scenarios 181 In multi-LMA environment, we assume that traffic flows distributed on 182 different interfaces can be anchored in different LMAs. Each LMA 183 logically manages a different group of MAGs, however it is unaware of 184 the MAGs registered on other LMAs and the corresponding interfaces 185 attached. Thus, one LMA SHALL NOT communicate with the MAG under 186 another LMA without the help of this LMA. In this specification, 187 selected flows after flow mobility SHALL not change the anchored LMA 188 but MN's interfaces and corresponding MAGs SHOULD adjust accordingly. 189 Policy Profile SHOULD exist in a PMIPv6 domain implemented in AAA 190 server, which maintains addresses of all the LMAs in the same domain 191 on a per-interface basis. This specification uses the default 192 behavior in basic PMIPv6[RFC5213], in which the MN obtains a prefix 193 or a new set of prefixes for the new session at the time of a new 194 interface attachment. 196 There are two different scenarios of flow mobility in multi-LMA 197 environment as the following: 199 (a) MN's different interfaces are attached to the same MAG, but the 200 flows through different interfaces are anchored in different LMAs. 202 (b)The different interfaces of MN are attached to different MAGs, and 203 anchored in different LMAs. 205 3.2. Basic Operation 207 3.2.1. Different Interfaces with a Shared MAG 209 It is corresponding to Scenario-(a). A MN can access Internet in a 210 PMIPv6 domain through different interfaces. The sessions of each 211 interface are anchored in a separate LMA, whereas all different 212 interfaces are attached to a single shared MAG. An example of this 213 scenario is showed in Figure 1, where a mobile node (MN) has two 214 different physical interfaces (if1 and if2), grouped in a logical one 215 (lif). Both interfaces are attached to the same MAG, and each of 216 them is anchored in a different LMA. These two interfaces are 217 assigned with different set of prefixes upon attachment to MAG. 218 There are 2 cases in this scenario. 220 LMA1 Binding Cache 221 +----+ +----+ ==================== 222 |LMA1| |LMA2| MN, if1, pref1, MAG 223 +----+ +----+ 224 \\ // 225 +------\\----------//--------+ LMA2 Binding Cache 226 ( \\ PMIPv6 // ) ==================== 227 ( \\domain// ) MN, if2, pref2, MAG 228 +---------\\----//-----------+ 229 \\ // 230 \\// 231 +----+ 232 | MAG| 233 +----+ 234 | | 235 |-------| |------| 236 | +-------+ | 237 | | I P | | 238 | +-------+ | 239 | | lif | | 240 | +---+---+ | 241 |---|if1|if2|----| 242 +---+---+ 243 MN 245 Figure 1: Different interfaces with single shared MAG and different 246 LMAs. 248 Figure 2 shows Case 1 of scenario-(a), in which both different 249 physical interfaces of the MN are initially both powered on. Flow 250 X(bound to pref1::/64) goes through if1-MAG-LMA1 and flow Y(bound to 251 pref2::/64) goes through if2-MAG-LMA2. At a certain time, MAG 252 detects the congestion of if2, and flow Y is decided to be moved to 253 if1. Flow Y can be moved just by updating the routing state at MAG 254 locally, binding pref2 with if1. No signaling exchange between LMA 255 and MAG is needed. The binding cache entry at LMA SHOULD not make 256 any change. 258 +-----+ +-----+ +------+ +-----+ 259 Internet | LMA1| | LMA2| | MAG | | MN | 260 +-----+ +-----+ +------+ +-----+ 261 | | | | | 262 | flow X to | flow X to | flow X to | 263 | pref1::lif | pref1::lif | pref1::lif | 264 |<----------->|<-------------------------->|<----------->if1 265 | flow Y to | flow Y to | flow Y to | 266 | pref2::lif | pref2::lif | pref2::lif | 267 |<------------------------->|<------------>|<----------->if2 268 | | | | | 269 | ======================================================== 270 | || decision to move flow Y || 271 | ======================================================== 272 | | | | | 273 | flow Y to | flow Y to | flow Y to | 274 | pref2::lif | pref2::lif | pref2::lif | 275 |<------------------------->|<------------>|<----------->if1 276 | | | | | 278 Figure2: Flow mobility signaling process of Scenario-(a) when both 279 interfaces are powered on initially.(no signaling) 281 Case 2 of Scenario-(a) is showed in Figure 3, flow mobility happens 282 when a new interface if2 is just powered on. In this case, MAG 283 detects L2 attachment of if2 and sends PBU to register in LMA2. LMA2 284 uses this request as a trigger to enable flow mobility. Flow Y is 285 bound to pref2::/64, and MAG updates routing state binding the 286 prefix2 with if2. This is done by including the related prefixes in 287 the PBU/PBA message. 289 +-----+ +-----+ +------+ +-----+ 290 Internet | LMA1| | LMA2| | MAG | | MN | 291 +-----+ +-----+ +------+ +-----+ 292 | | | | | 293 | flow X to | flow X to | flow X to | 294 | pref1::lif | pref1::lif | pref1::lif | 295 |<----------->|<-------------------------->|<----------->if1 296 | flow Y to | flow Y to | flow Y to | 297 | pref2::lif | pref2::lif | pref2::lif | 298 |<------------------------->|<------------>|<----------->if1 299 | | | | | 300 | | | | | 301 | | | MN powers on if2 and 302 | | | performs L2 attachment 303 | | | | | 304 | | | |<------------if2 305 | | | PBU | | 306 | | |<-------------| | 307 | | | PBA | | 308 | | |------------->| | 309 | flow Y to | flow Y to | flow Y to | 310 | pref2::lif | pref2::lif | pref2::lif | 311 |<------------------------->|<------------>|<----------->if2 312 | | | | | 314 Figure 3: Flow mobility signaling process of Scenario-(a) when a new 315 attachment occurs.(PBU/PBA message) 317 As the prefixes assigned to these sessions are only maintained in 318 LMA2, the anchor of flow Y MUST not change at all. Both in these two 319 cases, the path of flow Y between MAG and MN's interfaces is 320 changeable, meanwhile the tunnel used to transmit the packets of flow 321 Y between MAG and LMA2 is unaltered. And in both cases, only MAG is 322 REQUIRED to update routing state, no more signaling exchange between 323 LMA and MAG is needed. The binding cache entry at LMA SHOULD not 324 make any change unless a PBU requests it to. 326 3.2.2. Different Interfaces with Different MAGs 327 It is corresponding to Scenario-(b). It happens when different 328 interfaces are attached to different MAGs and anchored in different 329 LMAs. Each MAG only has the location knowledge of the interfaces 330 attached to it, and each LMA only maintains the MAGs registered on 331 it. In this scenario, source LMA, in which the selected flow is 332 anchored, needs to send message to the target MAG beyond the charge 333 to inform flow mobility, thus the LMA in charge of the target MAG can 334 help forward the message sent by the source LMA. The communication 335 between LMAs MUST be with the help of Mobile Node's Policy Profile 336 existing in the PMIPv6 domain, which keeps the storage of Mobile 337 Node's Identifier and the addresses of the LMAs on a per-interface 338 basis, the mandatory fields of policy profile here SHOULD be extended 339 as following: 341 o The mobile node's identifier (MN-ID).It is unique for MN despite of 342 the different interfaces. 344 o The interface identifier (IF-ID). Under a MN-ID, it is unique for 345 each interface. 347 o The IPv6 address of the local mobility anchor(LMAA) 349 When source LMA enables flow mobility, it firstly checks whether MN's 350 other interfaces under the same LMA can take over these selected 351 flows. If not, flow mobility in multi-LMA environment is enabled. 353 Figure 4 shows an example of Scenario 2. MN is implemented with two 354 different physical interfaces (if1 and if2), grouped in a logical one 355 (lif).Each physical interface is attached to a different MAG and 356 anchored in a different LMA. Initially, flow X(bound to pref1::/64) 357 goes through path if1-MAG1-LMA1 and flow Y(bound to pref2::/64) goes 358 through path if2-MAG2-LMA2. At a certain time, flow Y needs to be 359 moved to the path if1-MAG1-LMA2. The anchor MUST not change after 360 flow mobility. A new tunnel SHOULD be established between LMA2 and 361 MAG1 to transmit packets of flow Y. But initially the LMA in one path 362 has no knowledge of the interface and corresponding MAG in another 363 path, and it needs the help of another LMA. To enable flow mobility, 364 LMA2 MUST send request to Policy Profile to search for LMA 365 information of a proper interface under the same MN-ID. LMA2 gets 366 the address of LMA1 and IF1-ID after REQ-ACK message exchanging with 367 policy profile. 369 LMA1 Binding Cache 370 +----+ +----+ ==================== 371 |LMA1| |LMA2| MN, if1, pref1, MAG1 372 +----+ +----+ 373 || || LMA2 Binding Cache 374 +----||--------------||----+ ==================== 375 ( || PMIPv6 || ) MN, if2, pref2, MAG2 376 ( || domain || ) 377 +----||--------------||----+ 378 || || 379 +----+ +----+ 380 |MAG1| |MAG2| 381 +----+ +----+ 382 | | 383 | +-------+ | 384 | | I P | | 385 | +-------+ | 386 | | lif | | 387 | +---+---+ | 388 |---|if1|if2|----| 389 +---+---+ 390 MN 392 Figure4: Different interfaces with different MAGs and different LMAs. 394 Figure 5 gives the first possible signaling process. LMA2 sends eFMI 395 to LMA1, eFMI carries mobile node's identifier, interface identifier 396 and the Flow Identification Mobility option (specified in [RFC6089]) 397 which can convey prefix or full flow information, and the type of 398 flow mobility operation (add flow). LMA1 picks the entry of Binding 399 Cache Entry(BCE), matching the MN-ID and IF-ID carried in the 400 request, and locates the corresponding MAG1. LMA1 simply forwards 401 eFMI to MAG1. MAG1 constructs the reply eFMA with all the options 402 that a PBU MUST contain, which is used for a new mobile access 403 gateway MAG1 to register in LMA2. Optionally, LMA2 sends FMI, which 404 is defined in[I-D.ietf-netext-pmipv6-flowmob], to remove the flow Y 405 state at MAG2. Otherwise, the flow state at MAG2 will be removed 406 upon timer expiration. 408 +-----+ +-----+ +------+ +------+ +-----+ 409 Internet | LMA1| | LMA2| | MAG1 | | MAG2 | | MN | 410 +-----+ +-----+ +------+ +------+ +-----+ 411 | | | | | | 412 |flow X to | flow X to | flow X to | 413 |pref1::lif| pref1::lif | pref1::lif | 414 |<-------->|<---------------------->|<---------------------->if1 415 | flow Y to | flow Y to | flow Y to | 416 | pref2::lif | pref2::lif | pref2::lif| 417 |<--------------------->|<---------------------->|<--------->if2 418 | | | | 419 | =========================================================== 420 | || decision to move flow Y || 421 | =========================================================== 422 | | | | | | 423 | |eFMI[MN1-ID,IF-ID,flow_info(Y),add] | | 424 | |<-----------| | | | 425 | | eFMI | | | 426 | |------------------------>| | | 427 | |eFMA[CoA1,ATT1,LL-ID...] | | | 428 | |<------------------------| | | 429 | | eFMA | | | | 430 | |----------->| | | | 431 | | | optional | | 432 | | | FMI[MN1-ID,flow_info(Y),lft=0 | 433 | | |----------------------->| | 434 | | | FMA | | 435 | | |------------------------| | 436 | flow Y to | flow Y to | flow Y to | 437 | pref2::lif | pref2::lif| pref2::lif | 438 |<--------------------->|<---------->|<-------------------->if1 439 | | | | | | 441 Figure5: Flow mobility signaling process 1 of Scenario-(b) when both 442 interfaces are powered on initially.(eFMI signaling) 444 Figure 6 gives the second possible signaling process. The LMA2 still 445 needs to acquire the address of LMA1 and sends eFMI to inform flow 446 mobility, however eFMA replied by MAG1 is sent to LMA2 straightly 447 without the help of LMA1. MAG1 SHOULD query for the address of LMA2 448 from policy profile before it sends back eFMA. Optionally, LMA2 449 sends FMI, which is defined in[I-D.ietf-netext-pmipv6-flowmob], to 450 remove the flow Y state at MAG2. Otherwise, the flow state at MAG2 451 will be removed upon timer expiration. 453 +-----+ +-----+ +------+ +------+ +-----+ 454 Internet | LMA1| | LMA2| | MAG1 | | MAG2 | | MN | 455 +-----+ +-----+ +------+ +------+ +-----+ 456 | | | | | | 457 |flow X to | flow X to | flow X to | 458 |pref1::lif| pref1::lif | pref1::lif | 459 |<-------->|<---------------------->|<---------------------->if1 460 | flow Y to | flow Y to | flow Y to | 461 | pref2::lif | pref2::lif | pref2::lif| 462 |<--------------------->|<---------------------->|<--------->if2 463 | | | | 464 | ============================================================ 465 | || decision to move flow Y || 466 | ============================================================= 467 | | | | | | 468 | | eFMI[MN1-ID,IF1-ID,flow_info(Y),add]| | 469 | |<-----------| | | | 470 | | eFMI | | | 471 | |----------------------->| | | 472 | | | eFMA[CoA1,ATT1,LL-ID...] | 473 | | |<----------| | | 474 | | | optional | | 475 | | | FMI[MN1-ID,flow_info(Y),lft=0] | 476 | | |----------------------->| | 477 | | | FMA | | 478 | | |<-----------------------| | 479 | flow Y to | flow Y to | flow Y to | 480 | pref2::lif | pref2::lif| pref2::lif | 481 |<--------------------->|<--------->|<---------------------->if1 482 | | | | | | 484 Figure6: Flow mobility signaling process 2 of Scenario-(b) when both 485 interfaces are powered on initially.(eFMI signaling) 487 Figure7 gives the third possible signaling process. After acquiring 488 the address of LMA1 and IF1-ID, LMA2 sends the request to LMA1, LMA1 489 picks the entry that matches the MN-ID and IF1-ID in the request and 490 locates MAG1. It replies with the address of MAG1 directly to LMA2. 491 Then LMA2 can communicate with MAG1 straightly, without the help of 492 LMA1. Optionally, LMA2 sends FMI, which is defined in[I-D.ietf- 493 netext-pmipv6-flowmob], to remove the flow Y state at MAG2. 494 Otherwise, the flow state at MAG2 will be removed upon timer 495 expiration. 497 +-----+ +-----+ +------+ +------+ +-----+ 498 Internet | LMA1| | LMA2| | MAG1 | | MAG2 | | MN | 499 +-----+ +-----+ +------+ +------+ +-----+ 500 | | | | | | 501 |flow X to | flow X to | flow X to | 502 |pref1::lif| pref1::lif | pref1::lif | 503 |<-------->|<---------------------->|<---------------------->if1 504 | flow Y to | flow Y to | flow Y to | 505 | pref2::lif | pref2::lif | pref2::lif| 506 |<--------------------->|<---------------------->|<--------->if2 507 | | | | 508 | ============================================================ 509 | || decision to move flow Y || 510 | ============================================================ 511 | | | | | | 512 | | eFMI[MN1-ID,IF1-ID] | | | 513 | |<-----------| | | | 514 | | eFMA[CoA1]| | | | 515 | |----------->| | | | 516 | | | eFMI[MN1-ID,IF1-ID,flow_info(Y),add]| 517 | | |---------->| | | 518 | | | eFMA[CoA1,ATT1,LL-ID...] | 519 | | |<----------| | | 520 | | | optional | | 521 | | | FMI[MN1-ID,flow_info(Y),lft=0] | 522 | | |----------------------->| | 523 | | | FMA | | 524 | | |<-----------------------| | 525 | flow Y to |flow Y to | flow Y to | 526 | pref2::lif |pref2::lif | pref2::lif | 527 |<--------------------->|<--------->|<---------------------->if1 528 | | | | | | 530 Figure7: Flow mobility signaling process 3 of Scenario-(b)when both 531 interfaces are powered on initially.(eFMI signaling) 533 There is another case in Scenario-(b) showed in Figure 8 when a new 534 interface if2 is powered on. Initially, Flow X goes through 535 if1-MAG1-LMA1 and flow Y goes through if1-MAG1-LMA2. When MAG2 536 detects the new attachment, it sends PBU to LMA2 to create a new 537 binding entry. Since LMA2 manages both MAG1 and MAG2 after the 538 registration, it becomes the case that already has been discussed in 539 [I-D.ietf-netext-pmipv6-flowmob]. 541 +-----+ +-----+ +------+ +------+ +-----+ 542 Internet | LMA1| |LMA2 | | MAG1 | | MAG2 | | MN | 543 +-----+ +-----+ +------+ +------+ +-----+ 544 | | | | | | 545 |flow X to | flow X to | flow X to | 546 |pref1::lif| pref1::lif | pref1::lif | 547 |<-------->|<---------------------->|<---------------------->if1 548 | flow Y to | flow Y to | flow Y to | 549 | pref2::lif | pref2::lif| pref2::lif | 550 |<--------------------->|<--------->|<---------------------->if1 551 | | | | | | 552 | | | | | | 553 | | | | MN powers on if2 and 554 | | | | performs L2 attachment 555 | | | | |<----------if2 556 | | | PBU | | 557 | | |<-----------------------| | 558 | | | PBA (pref2) | | 559 | | |----------------------->| | 560 | | LMA moves pref2 to new| | | 561 | |binding cache entry for if2 | | 562 | | | | | | 563 | | | | | | 564 | | | (optional)| | | 565 | | | BRI[pref2]| | | 566 | | |---------->| | | 567 | | | BRA | | | 568 | | |<----------| | | 569 | flow Y to | flow Y to | flow Y to | 570 | pref2::lif | pref2::lif | pref2::lif| 571 |<--------------------->|<---------------------->|<--------->if2 572 | | | | | | 574 Figure 8: Flow mobility signaling process of Scenario-(b)when a new 575 attachment occurs.(PBU signaling) 577 4. Select the Target Interface 579 When MN has more than 2 different interfaces, the policy profile can 580 selects an available target interface of the same MN for source LMA 581 according to some rules, here we propose two possible ways: 583 o Select an interface arbitrarily. 585 Policy profile selects the first interface of all the other available 586 interfaces under the same MN-ID as target interface. Source LMA 587 sends request to the target LMA controlling the selected interface, 588 the acknowledge contains the status of flow mobility. If the code 589 indicates failure, then source LMA SHOULD send request to policy 590 profile to ask for another interface and repeat the steps until find 591 a proper one. 593 o Select all the available interfaces as target ones. 595 Policy profile selects all the other available interfaces under the 596 same MN-ID as target interfaces. Source LMA sends request to each 597 target LMA managing each interface, asking for the load information. 598 The acknowledge MUST contains Load Information Mobility Options to 599 report the priority and key load information to source LMA. Then 600 source LMA orders all the available target interfaces and picks a 601 proper one. 603 5. Message Format 604 5.1. Enhanced Flow Mobility Initiate(eFMI) 606 The LMA sends an eFMI message to a MAG to enable flow mobility. eFMI 607 is enhanced FMI, adding new bit M to indicate multi-LMA flow 608 mobility, and the options it carries are more. It is a Mobility 609 Header message. 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Sequence # | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 |I|M| Reserved | Lifetime | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | | 619 . . 620 . Mobility options . 621 . . 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Sequence Number: 627 A monotonically increasing integer. Set by the LMA sending then 628 initiate message, and used to match a reply in the acknowledge. 630 'I' (initiate) flag: 632 Set to 1, indicates it is an eFMI message. 634 'M' (multiple) flag: 636 Set to 1, indicates it is multi-LMA flow mobility. 638 Reserved: 640 This field is unused. MUST be set to zero by the sender. 642 Lifetime: 644 The requested time in seconds for which the LMA asks the MAG keep 645 flow-specific state. A value of all one bits (0xffff) represent 646 infinity. If set to 0, it indicates a request to remove state about 647 the flow (cancel flow mobility). 649 Mobility Options: 651 MUST contain the MN-ID, IF-ID, followed by one or more Flow 652 Identification Mobility options [RFC6089]. 654 5.2. Enhanced Flow Mobility Acknowledge(eFMA) 656 The MAG sends an eFMA message to the LMA as a response to the eFMI 657 message. eFMA is enhanced FMI, adding new bit M to indicate multi-LMA 658 flow mobility, the status and options are more. It is a Mobility 659 Header message. 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Sequence # | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 |I|M| Reserved | Status | Lifetime | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | | 669 . . 670 . Mobility options . 671 . . 672 | | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 Sequence Number: 677 A monotonically increasing integer. Set by the LMA sending then 678 initiate message, and used to match a reply in the acknowledge. 680 'I' (initiate) flag: 682 Set to 0, indicates it is an eFMA message. 684 'M' (multiple) flag: 686 Set to 1, indicates it is multi-LMA flow mobility. 688 Reserved: 690 This field is unused. MUST be set to zero by the sender. 692 Status(values to be assigned by IANA): 694 Despite of the already defined values in eFMI, the new values defined 695 in multi-LMA environment are as following: 697 ??: Target LMA not support flow mobility 699 ??: No existing MAG 701 ??: No existing interface 703 Lifetime: 705 The requested time in seconds for which the MAG keeps flow-specific 706 state. A value of all one bits (0xffff) represents infinity. 708 Mobility Options: 710 When Status code is 0, MUST contain the MN-ID, followed by one or 711 more Flow Identification Mobility options [RFC6089], and MUST include 712 other regular options in a normal PBU. 714 6. Conceptual Data Structures 716 6.1. Multiple Care-of Address Registration 718 The LMA is extended to allow a mobile node to register multiple proxy 719 care of address (Proxy-CoA). The LMA maintains multiple binding 720 cache entries for an MN. The number of binding cache entries for an 721 MN is equal to the number of the MN's interfaces attaching to any 722 MAGs. 724 +---------+-----+-------+------+-----------+------------+ 725 | BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | 726 +---------+-----+-------+------+-----------+------------+ 727 | 20 | 1 | MN | WiFi | HNP1,HNP2 | IP1 (MAG1) | 728 | 30 | 2 | MN | 3GPP | HNP1,HNP3 | IP2 (MAG2) | 729 +---------+-----+-------+------+-----------+------------+ 731 Figure 9: Extended Binding Cache 733 Figure 9 shows two Binding Cache Entries of the MN when it is 734 attached to the network using two different access technologies. 735 Both of the two attachments share HNP1 and are bounded to two 736 different Proxy-CoAs. 738 6.2. Flow Mobility Cache 739 Each LMA MUST maintain a flow mobility cache (FMC) as shown in Figure 740 10. This table MUST contain an entry for each flow sent from the MN. 741 A flow binding entry includes the following fields: 743 o Flow Identifier Priority (FID-PRI). 745 o Flow Identifier (FID). 747 o Traffic Selector (TS). 749 o Binding Identifier (BID). 751 o Action. 753 o Active/Inactive. 755 +---------+-----+-----+------+---------+----------+ 756 | FID-PRI | FID | TS | BIDs | Action | A/I | 757 +---------+-----+-----+------+---------+----------+ 758 | 10 | 2 | TCP | 1 | Forward | Active | 759 | 20 | 4 | UDP | 1,2 | Forward | Inactive | 760 +---------+-----+-----+------+---------+----------+ 762 Figure 10: Flow Mobility Cache 764 The BID field contains the identifier of the binding cache entry 765 which packets matching the flow information described in the TS field 766 will be forwarded to. When a flow is decided to be moved, the 767 affected BID(s) of the table are updated. 769 Similar to flow binding described in [RFC6089], each flow binding 770 entry points to a specific binding cache entry identifier (BID). 771 When a flow is moved, the LMA simply updates the pointer of the flow 772 binding entry with the BID of the interface to which the flow will be 773 moved. The traffic selector (TS) in flow binding table is defined as 774 in [RFC6088]. TS is used to classify the packets of flows basing on 775 specific parameters such as service type, source and destination 776 address, etc. The packets matching with the same TS will be applied 777 the same forwarding policy. FID-PRI is the order of precedence to 778 take action on the traffic. Action may be forward or drop. If a 779 binding entry becomes 'Inactive' it does not affect data traffic. An 780 entry becomes 'Inactive' only if all of the BIDs are deregistered. 782 The Mobile Access Gateway MAY also maintain a similar data structure. 783 In case no full flow mobility state is required at the MAG, the 784 Binding Update List (BUL) data structure is enough and no extra 785 conceptual data entries are needed. In case full per-flow state is 786 required at the MAG, it SHOULD also maintain a Flow Mobility Cache 787 structure. 789 6.3. Mobile Node's policy profile 791 There is Mobile Node's policy profile in a PMIPv6-Domain, MAY be 792 implemented in AAA server. The mandatory fields of it SHOULD be 793 extended as following: 795 o The mobile node's identifier (MN-ID).It is unique for MN despite of 796 the different interfaces. 798 o The interface identifier (IF-ID). Under a MN-ID, it is unique for 799 each interface. 801 o The IPv6 address of the local mobility anchor(LMAA). 803 7. Security Considerations 805 Security threats for flow mobility management in multi-LMA 806 environment comprise the danger of unauthorized signallings launched 807 by a malicious node. Signaling messages of this protocol between 808 LMAs, or between MAG and LMA MUST be authenticated by means of IPsec 809 [RFC4301]. 811 Protection of signaling messages between LMAs uses the mechanisms of 812 Encapsulating Security Payload (ESP) [RFC4301] in transport mode with 813 mandatory data origin authentication by means of a non-null payload 814 authentication algorithm. The use of encryption is optional. A 815 tunnel needs to be set up between MAG and LMA in Figure 4, which can 816 follow the process in PMIPv6[RFC5213]. 818 8. References 820 8.1. Normative References 822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 823 Requirement Levels", BCP 14, RFC 2119, March 1997. 825 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 826 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 828 [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., 829 and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC 830 5846, June 2010. 832 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 833 "Traffic Selectors for Flow Bindings", RFC 6088, January 834 2011. 836 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 837 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 838 Network Mobility (NEMO) Basic Support", RFC 6089, January 839 2011. 841 [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, 842 "Runtime Local Mobility Anchor (LMA) Assignment Support 843 for Proxy Mobile IPv6", RFC 6463, February 2012. 845 8.2. Informative References 847 [I-D.bernardos-dmm-distributed-anchoring] 848 Bernardos, C. and J. Zuniga, "PMIPv6-based distributed 849 anchoring", draft-bernardos-dmm-distributed-anchoring-02 850 (work in progress), April 2013. 852 [I-D.ietf-netext-logical-interface-support] 853 Melia, T. and S. Gundavelli, "Logical Interface Support 854 for multi-mode IP Hosts", draft-ietf-netext-logical- 855 interface-support-07 (work in progress), April 2013. 857 [I-D.ietf-netext-pmipv6-flowmob] 858 Bernardos, C., "Proxy Mobile IPv6 Extensions to Support 859 Flow Mobility", draft-ietf-netext-pmipv6-flowmob-06 (work 860 in progress), February 2013. 862 [I-D.jeyatharan-netlmm-multi-interface-ps] 863 Jeyatharan, M., Ng, C., Devarapalli, V., and J. Hirano, 864 "Multiple Interfaced Mobile Nodes in NetLMM", draft- 865 jeyatharan-netlmm-multi-interface-ps-03 (work in 866 progress), October 2008. 868 Authors' Addresses 870 Kaiping Xue 871 USTC 872 Room 305, EEIS Department, USTC West Campus 873 Shushan District , Hefei 230027 874 P. R. China 876 Phone: +86-551-3601334 877 Email: kpxue@ustc.edu.cn 878 Dan Ni 879 USTC 880 Room 305, EEIS Department, USTC West Campus 881 Shushan District , Hefei 230027 882 P. R. China 884 Phone: +86-551-3601334 885 Email: nidan@mail.ustc.edu.cn 887 Peilin Hong 888 USTC 889 Room 305, EEIS Department, USTC West Campus 890 Shushan District , Hefei 230027 891 P. R. China 893 Phone: +86-551-3601334 894 Email: plhong@ustc.edu.cn 896 H Anthony Chan 897 Huawei 898 5340 Legacy Dr. Building 3 899 Plano , TX 75024 900 USA 902 Email: h.a.chan@ieee.org