idnits 2.17.1 draft-gundavelli-netext-pmipv6-sipto-option-01.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 (July 5, 2011) is 4672 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) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG S. Gundavelli, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track X. Zhou 5 Expires: January 6, 2012 ZTE Corporation 6 J. Korhonen 7 Nokia Siemens Networks 8 G. Feige 9 R. Koodli 10 Cisco 11 July 5, 2011 13 IP Traffic Offload Selector Option for Proxy Mobile IPv6 14 draft-gundavelli-netext-pmipv6-sipto-option-01.txt 16 Abstract 18 This specification defines a mechanism and a related mobility option 19 for carrying IP Offload traffic selectors between a mobile access 20 gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. 21 Based on the received offload flow selectors from the local mobility 22 anchor, a mobile access gateway can enable offload traffic rule on 23 the selected IP flows. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 6, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 61 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. LMA Considerations . . . . . . . . . . . . . . . . . . . . 5 65 3.2. MAG Considerations . . . . . . . . . . . . . . . . . . . . 6 66 4. IP Traffic Offload Selector Option . . . . . . . . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Mobile Operators are expanding their network coverage by integrating 78 various access technology domains into a common IP mobile core. For 79 providing IP mobility support to a mobile node irrespective of the 80 access network to which it is attached, the 3GPP S2/a Proxy Mobile 81 IPv6 [TS23402] interface, specified by the 3GPP system architecture, 82 is providing the needed protocol glue. When this protocol interface 83 based on Proxy Mobile IPv6 [RFC5213] is used, the mobile node is 84 topologically anchored on the local mobility anchor [RFC5213] in the 85 home network. The mobile node's IP traffic is always tunneled back 86 from the mobile access gateway [RFC5213] in the access network to the 87 local mobility anchor in the home network. 89 However, with the exponential growth in the mobile data traffic, 90 mobile operators are exploring new ways to offload some of the IP 91 traffic flows at the nearest access edge where ever there is an 92 internet peering point, as supposed to carrying it all the way to the 93 mobility anchor in the home network. Not all IP traffic needs to be 94 routed back to the home network, some of the non-essential traffic 95 which does not require IP mobility support can be offloaded at the 96 mobile access gateway in the access network. This approach provides 97 greater leverage and efficient usage of the mobile packet core with 98 increased overall network capacity and by lowering transport costs. 99 The local mobility anchor in the home network can potentially deliver 100 the IP flow selectors to the mobile access gateway in the access 101 network, for identifying the IP flows that needs to be offloaded. 103 This document defines a new mobility option, IP Traffic Offload 104 Selector option for Proxy Mobile IPv6 (PMIPv6). This option can be 105 used by the local mobility anchor for notifying the flow selectors 106 for that can be used by the local mobility anchor for notifying the 107 mobile access gateway flows that can be offloaded at the access edge. 108 Since, the mobile node's IP address topologically belongs to the home 109 network, the offloaded IP traffic flows need to be NAT [RFC2663] 110 translated. Given this NAT translation requirement for the offloaded 111 traffic, this approach will be limited to mobile node's IPv4 flows. 112 There are better ways to solve this problem for IPv6 and with the 113 goal not to create NAT66 requirement, this specification does not 114 support traffic offload support for IPv6 flows. This document also 115 does not define any new semantics for flow selectors. The flow 116 identification and the related semantics are all leveraged from 117 [RFC6088]. 119 2. Conventions and Terminology 120 2.1. Conventions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2.2. Terminology 128 All the mobility related terms used in this document are to be 129 interpreted as defined in the base Proxy Mobile IPv6 specifications 130 [RFC5213] and [RFC5844]. Additionally, this document uses the 131 following abbreviations: 133 IP Flow 135 IP Flow represents a set of IP packets that match a traffic 136 selector. The selector is typically based on the source IP 137 address, destination IP address, source port, destination port and 138 other fields in upper layer headers. 140 Selective IP Traffic Offload (SIPTO) 142 Ability to select specific IP flows and route them to the local 143 network, as supposed to tunneling them to the home network. 145 NAT (Network Address Translation) 147 Network Address Translation [RFC2663] is a method by which IP 148 addresses are mapped from one address realm to another, providing 149 transparent routing to end hosts. 151 3. Solution Overview 153 The following illustrates the scenario where the mobile access 154 gateway in an access network having the ability to offload some of 155 the IPv4 traffic flows, based on the traffic selectors it received 156 from the local mobility anchor in the home network. 158 _----_ 159 _( )_ 160 ( Internet ) 161 (_ _) 162 '----' 163 | 164 (IP Traffic Offload Point 165 at access edge gateway for 166 non-essential traffic) 167 | 168 ...................................................... 169 | . +----------------+ 170 +---+ . | Operator Value | 171 |NAT| . | Added Services | 172 +---+ . +----------------+ 173 | _----_ | 174 +-----+ _( )_ +-----+ 175 [MN]----| MAG |======( IP )======| LMA |-- Internet 176 +-----+ (_ _) +-----+ 177 '----' 178 . 179 . 180 . 181 [Access Network] . [Home Network] 182 ...................................................... 184 Figure 1: Access Networks attached to MAG 186 3.1. LMA Considerations 188 The following considerations apply to the local mobility anchor and 189 the mobile access gateway. 191 Figure 1 explains the operational sequence of the IP Traffic Offload 192 selectors between the mobile access gateway and the local mobility 193 anchor. 195 MN MAG(NAT) LMA 196 |------>| | 1. Mobile Node Attach 197 | |------->| 2. Proxy Binding Update 198 | |<-------| 3. Proxy Binding Acknowledgement (IPTS Option) 199 | |========| 4. Tunnel/Route Setup 200 | + | 5. Installing the traffic offload rules 201 |------>| | 6. IPv4 packet from mobile node 202 | | | 7. Forwarding rule - Tunnel home/offload 203 | | | 204 Figure 2: Exchange of IP Traffic Offload Selectors 206 o If the received Proxy Binding Update includes the IP Traffic 207 Offload Selector Option Section 4, but if the local mobility 208 anchor either does not have the SIPTO capability, or it chooses to 209 deny the SIPTO request, the local mobility anchor MUST ignore the 210 IP Traffic Offload Selector Option and this would have no effect 211 on the operation of the rest of the protocol. 213 o If the local mobility anchor has the SIPTO capability and chooses 214 to deliver the flow policies, the local mobility anchor can 215 construct the traffic selectors based on the routing policy and 216 deliver those selectors in the Proxy Binding Acknowledgement 217 message using the IP Traffic Offload Selector Option. If the 218 received Proxy Binding Update included a proposed Offload traffic 219 selectors, the local mobility anchor MAY choose to honor that 220 request. 222 3.2. MAG Considerations 224 o The mobile access gateway MAY choose to notify the local mobility 225 anchor about its SIPTO capability by including the IP Traffic 226 Offload Selector Option Section 4 in the Proxy Binding Update 227 message. The included option MAY include the proposed offload 228 selectors which the local mobility anchor may choose to override. 229 If the mobile access gateway cannot does not have SIPTO 230 capability, this option MUST NOT be included in the Proxy Binding 231 Update. 233 o If there is no IP Traffic Offload Selector Option in the 234 corresponding Proxy Binding Acknowledgement message, it is 235 considered that the local mobility anchor does not support SIPTO 236 capability, specifically, it cannot deliver selectors for IP 237 traffic offload flows. 239 o If there IP Traffic Offload Selector Option in the corresponding 240 Proxy Binding Acknowledgement message, it serves as an hint that 241 the local mobility anchor can support SIPTO and the included 242 traffic spec MUST be applied by the mobile access gateway. 244 4. IP Traffic Offload Selector Option 246 A new option, IP Traffic Offload Selector option, is defined for 247 using it in Proxy Binding Update (PBU) and Proxy Binding 248 Acknowledgement (PBA) messages exchanged between a local mobility 249 anchor and a mobile access gateway. This option is used for carrying 250 the flow selectors for supporting IP traffic offload function at the 251 mobile access gateway. The option includes the parameters for 252 selecting IP flows for offload. 254 The alignment requirement for this option is 4n. 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type | Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 |O| Reserved | TS Format | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Traffic Selector ... 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 3: IP Traffic Offload Selector Option 268 Type 269 271 Length 272 8-bit unsigned integer indicating the length in octets of the 273 option, excluding the type and length fields. 275 Reserved This field is unused for now. The value MUST be 276 initialized to 0 by the sender and MUST be ignored by the 277 receiver. 279 TS Format An 8-bit unsigned integer indicating the Traffic Selector 280 Format. Value "0" is reserved and MUST NOT be used. The value of 281 (1) is assigned for IPv4 Binary Traffic Selector [RFC6088]. 283 TS Selector A variable-length opaque field for including the traffic 284 specification identified by the TS format field. When the value 285 of TS Format field is set to (1), the format that follows is the 286 IPv4 Binary Traffic Selector specified in section 3.1 of 287 [RFC6088]. 289 5. IANA Considerations 291 This document requires the following two IANA actions. 293 o Action-1: This specification defines a new Mobility Header option, 294 IP Traffic Offload Selector option. This option is described in 295 Section 4. The Type value for this option needs to be assigned 296 from the same numbering space as allocated for the other mobility 297 options [RFC3775]. 299 o Action-2: The Sub-type field of the IP Traffic Offload Selector 300 option introduces a new number space. This number space needs to 301 be managed by IANA, under the Registry, IP Traffic Offload 302 Selector Type Registry. This specification reserves the sub-type 303 value of (1) and (2). Approval of new sub-type values are to be 304 made through IANA Expert Review. 306 6. Security Considerations 308 The IP Traffic Offload Selector option defined in this specification 309 is for use in Proxy Binding Update and Proxy Binding Acknowledgement 310 messages. This option is carried like any other mobility header 311 option as specified in [RFC5213] and does not require any special 312 security considerations. Carrying IP traffic offload selectors does 313 not introduce any new security vulnerabilities. 315 7. Acknowledgements 317 The authors would like to thank Rajesh Pazhyannur, Kent Leung, Mark 318 Grayson, Frank Brockners, Woj Dec, and Steve Wood for all the 319 discussions related to the topic of IP traffic offload. The authors 320 would like to acknowledge the work related SIPTO in 3GPP SA2 working 321 group. 323 8. References 325 8.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 331 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 333 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 334 Mobile IPv6", RFC 5844, May 2010. 336 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 337 "Traffic Selectors for Flow Bindings", RFC 6088, 338 January 2011. 340 8.2. Informative References 342 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 343 Translator (NAT) Terminology and Considerations", 344 RFC 2663, August 1999. 346 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 347 in IPv6", RFC 3775, June 2004. 349 [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 350 2010. 352 Authors' Addresses 354 Sri Gundavelli (editor) 355 Cisco 356 170 West Tasman Drive 357 San Jose, CA 95134 358 USA 360 Email: sgundave@cisco.com 362 Xingyue Zhou 363 ZTE Corporation 364 No.68 Zijinghua Rd 365 Nanjing 366 China 368 Email: zhou.xingyue@zte.com.cn 370 Jouni Korhonen 371 Nokia Siemens Networks 372 Linnoitustie 6 373 Espoo FIN-02600 374 Finland 376 Email: jouni.nospam@gmail.com 378 Gaetan 379 Cisco 380 France 382 Email: gfeige@cisco.com 383 Rajeev Koodli 384 Cisco 385 3650 Cisco Way 386 San Jose, CA 95134 387 USA 389 Email: rkoodli@cisco.com