idnits 2.17.1 draft-xia-netext-flow-binding-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (June 25, 2010) is 5053 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) == Unused Reference: 'RFC3775' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'RFC0792' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 444, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-11) exists of draft-ietf-mext-flow-binding-06 == Outdated reference: A later version (-02) exists of draft-sarikaya-netext-fb-support-extensions-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Xia 3 Internet-Draft B. Sarikaya 4 Expires: December 27, 2010 Huawei USA 5 June 25, 2010 7 Flow Binding in Proxy Mobile IPv6 8 draft-xia-netext-flow-binding-02 10 Abstract 12 This document introduces extensions to Proxy Mobile IPv6 that allows 13 networks dynamically binding IP flows to different interfaces of a 14 mobile node. Mobile Access Gateways can move flows to other mobile 15 access gateways by establishing flow bindings at the local mobility 16 anchor. Local mobility anchor sends packets from the offloaded flow 17 seamlessly to the new mobile access gateway. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 27, 2010. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Design Assumptions and Principles . . . . . . . . . . . . . . 4 57 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 5 58 5.1. Other Enhancements . . . . . . . . . . . . . . . . . . . . 7 59 6. MAG Operation . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. LMA Operation . . . . . . . . . . . . . . . . . . . . . . . . 8 61 8. MN Operation . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 9. Message formats . . . . . . . . . . . . . . . . . . . . . . . 9 63 9.1. Target Care-of-Address sub-option . . . . . . . . . . . . 9 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 66 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 13.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 13.2. Informative references . . . . . . . . . . . . . . . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 Assume a mobile node equipped with two interfaces namely IF1 (e.g. 75 3GPP) and IF2 (e.g WiFi), and IF1 is active while IF2 is not 76 activated. There are two flows running on IF1, that is, VoIP and 77 file downloading. At some time, e.g., the mobile node moves into a 78 WiFi hotspot, IF2 becomes active, and the file downloading flow is 79 then offloaded to IF2 while VoIP flow remains on IF1. When the 80 mobile node moves out of the hotspot, the file downloading flow is 81 moved back to IF1 again. 83 In this document, a flow is defined as one or more connections that 84 are identified by a flow identifier. A single connection is 85 typically identified by the source and destination IP addresses, 86 transport protocol number and the source and destination port 87 numbers. 89 [I-D.ietf-mext-flow-binding] allows a mobile node to bind a 90 particular flow to a care-of address without affecting other flows 91 using the same home address. Flow Identification option is defined 92 and included in Binding Update (BU) / Binding Acknowledgement(BA) 93 messages. However, the mechanism specified in the document can't be 94 directly applied to Proxy Mobile IPv6 in which the mobile node is not 95 involved in mobility management. A Mobile Access Gateway (MAG) is 96 then introduced to take on mobility management on behalf of the 97 mobile node. 99 This document introduces extensions to Proxy Mobile IPv6 that allows 100 networks dynamically bind IP flows to different interfaces of a 101 mobile node. In the aforementioned scenario, the IF1 attaches to a 102 mobile access gateway forwarding VoIP and file downloading flows at 103 the beginning. When the mobile node moves into a WiFi hotspot, IF2 104 becomes active and connects to another mobile access gateway which 105 then takes over file downloading flow. Based on operator policy or 106 the mobile node profile, the mobile access gateways may signal a 107 Local Mobility Anchor (LMA) to redirect flows from one to another. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 The terminology in this document is based on the definitions in 116 [RFC5213], in addition to the ones specified in this section. 118 Serving Interface: a mobile node's interface on which some 119 application flows are running. Based on the MN's profile, 120 operator's policy, or other reasons, some of the flows are 121 supposed to be offloaded to the other interfaces of the mobile 122 node when they become available. 124 Target Interface: a mobile node's interface which is taking over 125 some application flows from a serving interface of the mobile 126 node. 128 Serving IP Address (SIP): an IPv4 or IPv6 address configured on a 129 serving interface. 131 Target IP Address (TIP): an IPv4 or IPv6 address configured on a 132 target interface. 134 Serving Mobile Access Gateway(SMAG): A mobile access gateway which a 135 serving interface attaches to. 137 Target Mobile Access Gateway(TMAG): A mobile access gateway which a 138 target interface attaches to. 140 3. Use Cases 142 Michael is using 3GPP access to different services with different 143 characteristics in terms of QoS requirements and bandwidth: 144 o a VoIP call. 145 o a non-conversational video streaming, e.g.IPTV. 146 o a p2p download. 148 When Michael gets into his home where WiFi access is available, 149 Michael prefers running the p2p download and IPTV through the WiFi 150 network, and leaving the VoIP call still on 3GPP networks. 152 At some time, Michael's device starts ftp file synchronization with a 153 backup server. Due to the synchronization, the WiFi access becomes 154 congested and the IPTV flow is then moved back to 3GPP access. 156 After a while, Michael moves out of his home and loses the WiFi 157 connectivity. Triggered by this event, all the IP flows through the 158 WiFi access need to be moved to the 3GPP access which is the only 159 access available. 161 4. Design Assumptions and Principles 163 The following are assumptions and principles when this solution is 164 proposed. 165 o This document only deals with scenarios that multiple interfaces 166 of a mobile node are registered at the same local mobility anchor. 167 o This document also tries to avoid any new layer 2 or layer 3 168 protocols introduced between a mobile node and a mobile access 169 gateway. 170 o Mobile access gateways can detect attachments or detachments of 171 mobile nodes through existing layer 2 mechanism (e.g. 3GPP, WiMAX, 172 or WiFi). The attachment or detachment events can serve as 173 triggers for mobile access gateways to initiate flow mobility 174 procedure. 175 o There are no direct communications among mobile access gateways to 176 which multiple interfaces of a mobile node attach. One mobile 177 access gateway may be able to learn the presence of another mobile 178 access gateway through message exchanges with the common local 179 mobility anchor. 180 o When a local mobility anchor receives a flow binding request from 181 a mobile access gateway, it can make a decision by itself or 182 consult a mobile access gateway to which the flow will move. 184 5. Protocol Operation 186 +--------+ +------+ +------+ +------+ 187 | MN | | SMAG | | TMAG | | LMA | 188 +--------+ +------+ +------+ +------+ 189 IF1 IF2 | | | 190 | | | | | 191 | 1 Attachment | | | 192 |<-------------->| 2 PBU&PBA | 193 | 3 Addr Cfg |<-------------------------->| 194 |<-------------->| | | 195 Running | | | | 196 Applications | | | 197 | | 4 Attachment/PBU&PBA/Addr Cfg | 198 | |<------------------------>|<----------->| 199 | | | | | 200 | | | 5 PBU(Flow Binding) | 201 | | |--------------------------->| 202 | | | | 203 | | | 6 PBA(Flow Binding) | 204 | | |<---------------------------| 205 | | | | 7 Packets | 206 | | 8 Packets |<============| 207 | |<=========================| | 208 | | | | | 209 Figure 1: Protocol Operation 211 1. A mobile node has two interfaces, IF1 and IF2. At the beginning, 212 only IF1 is activated and attachment procedure is triggered. 213 2. On receiving attachment signaling from the mobile node, a mobile 214 access gateway, acting as a SMAG, sends a PBU to a LMA. Access 215 Technology Type Option defined in [RFC5213] is carried in the 216 PBU. The LMA assigns a unique prefix for the mobile node through 217 a PBA message to the SMAG. 218 3. The SMAG extracts the prefix, and advertises it to the mobile 219 node through Router Advertisement message. The mobile node then 220 configures its address, acting as a SIP, through stateless 221 address configuration procedure specified in [RFC4862]. Then, 222 the mobile node runs applications using this address, such as, 223 VoIP,IPTV, and p2p downloading. 224 4. When the mobile node moves into some other places where IF2 is 225 activated, the mobile node follows similar steps to 1,2,3 to 226 configure IP address for IF2, acting as TIP. According to Proxy 227 Mobile IPv6 specification [RFC5213], this is an attachment over a 228 new interface with the Handoff Indicator field set to a value of 229 1 and the SIP is different from TIP. Here the binding cache 230 entry is modified as described in 231 [I-D.sarikaya-netext-fb-support-extensions]. 232 5. Based on the mobile node's profile, operator's policy, or network 233 status the SMAG decides to offload some traffic flows from IF1 to 234 IF2. The SMAG then sends a PBU with Flow Identification option 235 defined in [I-D.ietf-mext-flow-binding]. This message indicates 236 the LMA to change the direction of the requested flows from the 237 SMAG to the TMAG. SMAG first assigns a Flow Identifier (FID) 238 value to this flow and then sets Action field to Forward. SMAG 239 adds the flow description using the Traffic Selector sub-option. 240 SMAG indicates TMAG address in Target Care-of-Address Sub-option 241 defined in Section 9.1. 242 6. It is the LMA that makes a decision if offloading request is 243 granted or not. The LMA may decide based on local information, 244 such as, access technology types, bandwidth, service types, and 245 so on. The LMA inquires the TMAG of acceptability of the 246 offloading request and establishes this new flow at the TMAG. 247 Section 5.1 explains message exchanges between the LMA and the 248 SMAG. TMAG adds a new entry for this flow in its Flow Binding 249 Entries Table. The LMA sends a PBA to indicate the operation 250 result of the flow binding request. 251 7. All the offloaded packets with SIP as destination address (if it 252 belongs to the home interface as described in 253 [I-D.sarikaya-netext-fb-support-extensions]) received by LMA are 254 encapsulated and sent to the TMAG. 256 8. The TMAG strips the encapsulation, and checks that an entry for 257 this flow exists in the flow binding entries table and then 258 forwards the packets to the mobile node's IF2. The mobile node 259 then processes the packets with SIP as the destination address. 261 5.1. Other Enhancements 263 It is helpful for a SMAG when initiating flow movement if the SMAG is 264 aware of the presence of the potential TMAGs. This awareness can be 265 achieved through notification from a local mobility anchor because 266 all MAGs of mobile node are associated to the same local mobility 267 anchor. 269 The LMA notifies SMAG about IF2's presence through Generic Signaling 270 Request / Generic Signaling Acknowledgement message exchanges 271 specified in [I-D.ietf-mext-generic-signaling-message]. Flow 272 Identification Mobility Option with Target Care-of Address sub-option 273 defined in Section 9.1 is included in the message from the LMA to the 274 SMAG. Through this message exchange, the SMAG has an idea of 275 availability of other interfaces of the mobile node, and the address 276 of the TMAG. 278 To make a better decision, the LMA may send a Generic Signaling 279 Request message to the TMAG for inquiring if the offloading is 280 allowed. Flow Identification option is included in the message. The 281 TMAG responds with a Generic Signaling Acknowledgment message. If 282 the TMAG accepts the flows, the Status field of the message SHOULD be 283 set to 0, otherwise, the field is set to a value of 128 or higher. 285 Flow binding extensions described in 286 [I-D.sarikaya-netext-fb-support-extensions] are assumed. These 287 extensions are needed to avoid LMA sending packets with double 288 encapsulation to MN over LMA-MAG tunnel after a particular flow is 289 moved from one interface to another interface. The extensions 290 require LMA to distinguish the home interface, e.g. 3G interface from 291 the secondary interfaces, e.g. WiFi and the mobile node always uses 292 the home interface address as the source address in the packets it 293 sends over a virtual interface. 295 6. MAG Operation 297 Flow binding is always initiated by a SMAG, that is, the SMAG wants 298 to offload its traffic flow to other MAGs. There are several reasons 299 for triggering flow binding. 300 o The SMAG is notified by a LMA the availability of other MAGs which 301 the same mobile node currently attaches to. 303 o Congestion occurs in the SMAG which knows there are other MAGs 304 connecting to the same mobile node. 305 o The SMAG detects the serving interface of the mobile node is out 306 of service. 307 o ... ... 309 As to Flow Identification option used in this document, there are two 310 fields needing special consideration, that is, Flow ID (FID) and 311 Binding Identification number (BID). BID is mainly defined for 312 multiple-interfaced mobile nodes with Mobile IPv6 functionalities. 313 The BID is an identification number used to distinguish multiple 314 bindings registered by the mobile node. Each BID is generated and 315 managed by a mobile node in Mobile IPv6. In Proxy Mobile IPv6, 316 mobility management of mobile nodes with multiple interfaces is run 317 in different independent MAGs, and BID loses its meaning. All BID 318 fields in Flow Identification option SHOULD be set to 0. In this 319 document flows are identified using FID. FID is set by the 320 initiator, e.g. SMAG. Thereafter it is used by all other entities 321 like LMA and any other MAGs to which this flow is forwarded to. 323 7. LMA Operation 325 The LMA is the center of the flow binding processing. It has 326 following functionalities: 327 o Advertising the availability of a new interface of a mobile node. 328 When an interface of the mobile node becomes active, a 329 corresponding MAG SHOULD sends a PBU to the LMA. Triggered by the 330 PBU, the LMA then notifies all the other MAGs which the mobile 331 node is attaching to. Generic Signalling Request with Flow 332 Identification Mobility Option is used for this notification. The 333 new MAG's address is sent in Target Care-of Address Sub-option. 334 o Deciding if an offloading request is acceptable. On receiving PBU 335 from a SMAG with a flow binding request, the LMA makes a decision 336 based on operator's local policy, mobile node's preference, 337 bandwidth of the flow, and so on. 338 o Inquiring a TMAG for acceptability of the offloaded flows. If the 339 LMA can't decide on accepting offloading request, the LMA SHOULD 340 inquire other MAGs using Generic Signaling Request message with 341 Flow Identification Mobility Option copying the fields from the 342 PBU sent by the originating SMAG. TMAG sends a Generic Signaling 343 Acknowledgement message and sets Status field to 0 indicating 344 acceptance. TMAG also inserts the new flow in its flow binding 345 entries table. 346 o Redirecting upstream packets. In Mobile IPv6, the home agent 347 tunnels the upstream packets to the Care-of Address indicated in 348 the flow binding entry table for this flow. In Proxy Mobile IPv6, 349 LMA keeps a flow binding entry table as in 351 [I-D.ietf-mext-flow-binding] and links binding cache entries for 352 each mobile node to this table. The table contains an entry for 353 each active flow that the mobile node has indicating to which MAG, 354 i.e. Proxy-CoA1 to forward the flow to. LMA first matches the 355 traffic selectors given in the table entry and then tunnels the 356 packet to the corresponding MAG. Together with provisions in 357 [I-D.sarikaya-netext-fb-support-extensions], the destination MAG 358 can simply decapsulate the packet and forward to the mobile node's 359 interface connected to this MAG. 361 8. MN Operation 363 In this document, it is assumed that different interfaces are 364 assigned different prefixes, and the same interface is configured 365 with the same IP address even after resetting of the interface. Once 366 one interface becomes inactive, the software SHOULD map the address 367 to another interface, or to a virtual interface,so that ongoing 368 sessions with the address can survive. When the interface becomes 369 active again, and receive the same prefix from a LMA, the address 370 SHOULD be moved back to the interface. 372 9. Message formats 374 9.1. Target Care-of-Address sub-option 376 This section introduces the Target Care-of-Address, which may be 377 included in the Flow Identification Mobility Option. This sub-option 378 is used by the TMAG to indicate the Local Mobility Anchor to move a 379 flow binding from SMAG to the Target Care-of Address, i.e. TMAG. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Sub-opt Type | Sub-opt Len | Reserved | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Target Care-of-Address | 387 . . 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 2: Target Care-of-Address Sub-option 392 Sub-opt Type 394 To be assigned by IANA 395 Sub-opt Len 397 Length of the sub-option in 8-octet units 398 Reserved 400 This field is unused. It MUST be initialized to zero by the 401 sender and MUST be ignored by the receiver. 402 Target Care-of-Address 404 An IP address of a MAG to which a new interface is attaching. 405 This address could be IPv4 or IPv6 address. 407 10. Security Considerations 409 This specification allows a mobile access gateway to offload traffic 410 to other mobile access gateway. This mechanism facilitate a serving 411 mobile access gateway to launch DoS attacks to a target mobile access 412 gateway. However, a local mobility anchor finally decides 413 acceptability of an offloading request, as mitigates DoS attacks 414 threat. 416 11. IANA considerations 418 A new mobile option, Alternative Interface Indicator, is defined. 419 Option type SHOULD be assigned by IANA. 421 12. Acknowledgements 423 TBD. 425 13. References 427 13.1. Normative References 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, March 1997. 432 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 433 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 435 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 436 in IPv6", RFC 3775, June 2004. 438 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 439 Address Autoconfiguration", RFC 4862, September 2007. 441 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 442 RFC 792, September 1981. 444 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 445 Message Protocol (ICMPv6) for the Internet Protocol 446 Version 6 (IPv6) Specification", RFC 4443, March 2006. 448 13.2. Informative references 450 [I-D.ietf-mext-flow-binding] 451 Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., 452 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO 453 Basic Support", draft-ietf-mext-flow-binding-06 (work in 454 progress), March 2010. 456 [I-D.ietf-mext-generic-signaling-message] 457 Haley, B. and S. Gundavelli, "Mobile IPv6 Generic 458 Signaling Message", 459 draft-ietf-mext-generic-signaling-message-00 (work in 460 progress), August 2008. 462 [I-D.sarikaya-netext-fb-support-extensions] 463 Sarikaya, B. and F. Xia, "PMIPv6 Multihoming Support for 464 Flow Mobility", 465 draft-sarikaya-netext-fb-support-extensions-00 (work in 466 progress), February 2010. 468 Authors' Addresses 470 Frank Xia 471 Huawei USA 472 1700 Alma Dr. Suite 500 473 Plano, TX 75075 475 Phone: +1 972-509-5599 476 Email: xiayangsong@huawei.com 478 Behcet Sarikaya 479 Huawei USA 480 1700 Alma Dr. Suite 500 481 Plano, TX 75075 483 Phone: +1 972-509-5599 484 Email: sarikaya@ieee.org