idnits 2.17.1 draft-maglione-softwire-map-t-scenarios-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 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 (June 27, 2013) is 3949 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-softwire-map-t-01 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 softwire R. Maglione, Ed. 3 Internet-Draft W. Dec 4 Intended status: Informational Cisco Systems 5 Expires: December 29, 2013 V. Kuarsingh 6 Rogers Communications 7 E. Mallette 8 Bright House Networks 9 June 27, 2013 11 Use cases for MAP-T 12 draft-maglione-softwire-map-t-scenarios-02 14 Abstract 16 The Softwire working group is currently discussing both encapsulation 17 and translation based stateless IPv4/IPv6 solutions in order to be 18 able to provide IPv4 connectivity to customers in an IPv6-Only 19 environment. 21 The purpose of this document is to describe some operational use 22 cases that would benefit from a translation based approach and 23 highlights the operational benefits that a translation based solution 24 would allow. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 29, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Operational Service Policy Use Cases . . . . . . . . . . . . 3 62 2.1. Network/Transport Layer Classification classifiers . . . 4 63 2.2. Device Configuration (DOCSIS) . . . . . . . . . . . . . . 5 64 2.3. Service Flow management using Deep Packet Inspection . . 5 65 2.4. Service Flow Redirection Policies (Web-redirection) . . . 6 66 2.5. Service Flow Caching . . . . . . . . . . . . . . . . . . 7 67 3. Technological Considerations . . . . . . . . . . . . . . . . 7 68 3.1. Encapsulation and Translation Overhead . . . . . . . . . 7 69 3.2. Efficient Utilization of the Access Network . . . . . . . 8 70 3.2.1. Jumbo Frame Support in the Access . . . . . . . . . . 8 71 3.2.2. Operator Added Packet Overhead and Service Level 72 Agreements . . . . . . . . . . . . . . . . . . . . . 9 73 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 8. Informative References . . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 The Softwire working group is currently discussing both encapsulation 83 and translation based stateless IPv4/IPv6 solutions developed for the 84 purposes of offering IPv4 connectivity to the customers in an 85 IPv6-Only environment. 87 There are deployment scenarios that may benefit equally from an 88 encapsulated or translated form of an IPv4/IPv6 stateless addressing 89 solution. There are, however, use cases where using a translation 90 approach could lead to significant operational benefits and potential 91 savings for the operators. 93 This document describes some use cases that would take advantage of a 94 translation based solution, by highlighting the operational benefits 95 that a translation based approach would allow. 97 2. Operational Service Policy Use Cases 99 In Broadband Networks it is common practice for Operators to apply 100 per-subscriber policies on subscriber traffic at the network edge 101 such as a BNG ( Broadband Network Gateway), CMTS (Cable Modem 102 Termination System), Optical Line Terminal (OLT), PGW (PDN Gateway) 103 or like device. Various services may require the application of 104 different policies at these services edges. 106 Typically a policy would include a classification function and an 107 action function. 109 o Service flow classification may occur based on any combination of 110 the following: 112 * Layer-3 identifiers such as source, destination address, 113 protocol or next header, DSCP or Traffic Class; 115 * Layer-4 identifiers such as source or destination port; 117 * service type/destination (i.e. Internet, network service, or 118 other service) 120 o Actions may be provisioned against the classified traffic; the 121 following are some examples of actions: 123 * application of different QoS treatment (could be rate-limit, 124 drop, redirect,.. etc) based on Layer 3 or higher layer (Layer 125 4-7) classification from devices like deep packet inspection 126 appliances; 128 * Service flow redirection on selected types of traffic (i.e. 129 Web portal); 131 * Service flow caching on selected types of traffic. 133 The rationale for applying such policy at the network edge is based 134 on how tightly coupled this layer of the network is with many key 135 systems within the operators network such as RADIUS, DHCP, access 136 technology awareness and ability to implement subscriber awareness. 138 In many common deployments today, the customer's policies are 139 maintained in RADIUS server or enforced through other provisioned 140 data in co-operation with service activation such as DHCP and 141 bootstrap configuration. In a cable operator network, while much of 142 the heavily lifting of subscriber management is embedded on the CMTS 143 or OLT, the reality is that classification is shared across CMTS and 144 cable-modem (CM) or across OLT and optical network unit (ONU.) The 145 CM and ONU classification capabilities are not as robust and flexible 146 as the upstream CMTS, OLT and/or assisting edge router. The 147 implications of that are that the CPE may need to be replaced with a 148 device that has the capability to classify on a larger packet header. 150 An additional point to consider is that the edge network nodes are 151 also often fitted with, or co-located with higher functioning 152 appliances that employ Deep Packet Inspection and distributed caches 153 used to enhance service performance. 155 2.1. Network/Transport Layer Classification classifiers 157 Most of the policies described in Section 2 require the use of 158 network and transport layer classification and filtering mechanisms 159 such as classifiers at the network edge. The application of 160 classifiers and other network layer classification functions on 161 selected subscriber flows are often applied by a AAA server, gleaned 162 from configuration information, provisioned from per-CM DOCSIS 163 configuration files generated from the operator OSS, or sent by a 164 policy control function (PCRF, PCMM, etc). 166 This section will explain why the application of some types of 167 classifiers (like Layer 3 destination based classifiers and - Layer 3 168 plus Layer 4 - classifiers,) can be deployed in a more simplistic 169 fashion when using a translated form of a stateless IPv4/IPv6 170 transition technology such as MAP-T [I-D.ietf-softwire-map-t]. 172 A key characteristic of MAP-T is the mapping of the IPv4 address of 173 any destination into the IPv6 destination address, by means of IPv4 174 to IPv6 mapping rules. This mapping means that the subscriber flows 175 are native IPv6 flows within the operators network. The ability to 176 use a standard IPv6 classifier to identify interesting traffic for 177 classification is well aligned with traditional traffic 178 identification capabilities using IPv4 based classifiers. Such 179 classifiers can be easily applied at the access edge as a standard 180 function commonly available on most platforms deployed. 182 In contrast, a solution utilizing an IP tunnel based transport (MAP-E 183 [I-D.ietf-softwire-map] or DS-Lite [RFC6333]), effectively hides the 184 payload's IP layer information, making it difficult to identify by 185 means of an IPv6 classifier . The operator in the latter case 186 (tunneled option) would need additional functionality to classify the 187 same subscriber flows which may not be available on the deployed 188 platforms. 190 The classifier use case is further extended when considering that 191 many traffic classifications are made using transport layer (Layer 4) 192 information. This is common in operator networks that often apply 193 differential traffic treatment to different services that typically 194 operate using well defined TCP/UDP ports. In the MAP-T deployment 195 case, these ports are available for classification matching using the 196 same standard access edge node capabilities using IPv6 classifiers. 197 In the case where tunneled forms of a solution are used, these higher 198 layer ports are hidden from the network (base IP layer) and special 199 functionality to correctly classify these service flows is required. 201 The ability to apply classifiers at the access edge node allows the 202 operator to not only use standard IPv6 classifier functionality, but 203 also use same mechanisms (RADIUS interface parameters/system, or 204 DOCSIS configuration classifier parameters) for applying such 205 classifiers. I.e. custom RADIUS interface extensions or custom 206 DOCSIS classifier extensions to deal with the classifier semantics of 207 an IP tunnel based transport are not required. 209 2.2. Device Configuration (DOCSIS) 211 Some access technologies, like DOCSIS, require a modem configuration 212 file for network operation. These configuration files often contain 213 access control and classification information that uses IPv4 and/or 214 IPv6 network and transport layer information. 216 MAP-T allows use of standard IPv6 classifiers within these 217 configuration files permitting the continued use of the well-known 218 service architecture. Translation technologies which use tunneling 219 may require the operator to update how services are managed as 220 information needed to enforce policy is not longer viewable by the 221 Cable Modem or upstream CMTS. The operator in this case may need to 222 build new service capabilities higher up in the network after the 223 network translator to apply the full range of polices for the 224 subscriber base. 226 2.3. Service Flow management using Deep Packet Inspection 228 Several Service Providers today use Deep Packet Inspection devices 229 located at the network edge (such as a BNG) in order to inspect the 230 subscriber's traffic for different purposes: profiling the user's 231 behavior, and classifying the traffic based on higher layer 232 information and/or traffic signatures. 234 Deep packet inspection devices available today in the market and, 235 more importantly, those already deployed in operator's network may 236 not be able to analyze encapsulated traffic, like IPinIP, and to 237 correlate the inner packet's contents to the outer packet's 238 "subscriber" context - this limitation is consistent across multiple 239 vendors. In order to overcome this limitation when using IP tunnel 240 based transports, without resorting to costly network upgrades, 241 dedicated DPI devices need to be applied at a point in the network 242 where the IP tunnel transport has been stripped and the payload is 243 directly available for native processing. This not only changes the 244 network architecture, but it increases the number of DPI's devices 245 required: one for IPv6 traffic at the access edge, the other at a 246 location where the IPv4 traffic is exposed (typically a separate 247 Location). In addition the operator would need to enforce policies 248 at two architecturally separate places in the network. Furthermore, 249 even with these changes enacted, there remains a critical problem of 250 correlating traffic to a given subscriber: in encapsulation based 251 solutions, the IPv4 address information in the payload is not 252 sufficient to uniquely identify a subscriber given that an IPv4 253 address will not be unique. As such, additional mechanisms and 254 changes to the accounting infrastructure need to be introduced which 255 when combined with all the previous aspects makes this solution 256 operationally complex. 258 With MAP-T operators can continue using the current architectural 259 model with DPI devices installed at the access edge; the only 260 requirement would be to have the same device able to recognize 261 specific applications on the native IPv6 transport, which DPI devices 262 based on application signatures are capable of doing. Thus with 263 MAP-T it doesn't matter that an operator might provision the same 264 IPv4 address across multiple subscribers. In addition with MAP-T the 265 access edge would remain the single enforcement point for all user's 266 policies for all traffic. This would allow the operators to continue 267 using a consistent architecture and set of accounting tools for their 268 network. 270 2.4. Service Flow Redirection Policies (Web-redirection) 272 Redirecting the user's traffic to web portal is a common practice in 273 Service Provider networks. For example, it is common for operators 274 to inform users about new services, service advisories and/or access 275 to account changes using web-reduction techniques activated on http 276 traffic. In current deployments web-redirection occurs at the Edge 277 node level, where the subscriber's traffic first hits the IP network. 278 The activation/de- activation of redirection policy on selected 279 subscribers may be driven by the AAA/RADIUS through specific RADIUS 280 attributes. In current deployments web-redirection occurs at the 281 Edge node level, where the subscriber's traffic first hits the IP 282 network. The activation/de- activation of redirection policy on 283 selected subscribers may be driven by the AAA/RADIUS through specific 284 RADIUS attributes. 286 If MAP-T is used the redirection of both IPv6 and IPv4 traffic can be 287 kept at the Edge of the network with the same configuration currently 288 used and by simply translating the Server's address in IPv6 with 289 known mapping rules. In case of tunnel based solution the 290 redirection of IPv6 and IPv4 cannot occur in a single place, because 291 the redirection of IPv4 traffic must be implemented at or after the 292 v4/v6 gateway responsible for de-encapsulating the traffic. This 293 approach not only would require deploying two separate 294 infrastructures located in different places in order to achieve the 295 redirection for both IPv6 and IPv4 traffic, but also it would not 296 allow continuing using the AAA/RADIUS Server infrastructure in order 297 to enforce the redirect policy at the subscriber's session. 299 2.5. Service Flow Caching 301 With the continuing growing of video traffic, especially considering 302 the increase of http video traffic (YouTube like,) it is useful for 303 the Service Providers to be able to cache the video stream at the 304 Edge of the network in order to save bandwidth on upstream links. 305 Using cache devices together with tunnel solutions would introduce 306 similar challenges/issues as the ones described for DPI scenarios, in 307 particular it would require applying caching functionality after the 308 decapsulation point. Obviously this would not eliminate the benefits 309 of the cache. Instead a MAP-T approach would allow caching the 310 subscriber traffic at the edge of the network and gaining the 311 bandwidth savings introduced by the caching. Crucially, any native 312 IPv6 web-caches would be capable of processing IPv6 MAP-T traffic as 313 fully native traffic. 315 In addition in some deployments today, Web Cache Control Protocol 316 (WCCP) feature is used in order to redirect subscriber's traffic to 317 the cache devices. When a subscriber requests a page from a web 318 server (located in the Internet, in this case), the network node 319 where the WCCP is active, sends the request to a Cache Engine. If 320 the cache engine has a copy of the requested page in storage, the 321 engine sends the user that page. Otherwise, the engine gets the 322 requested page and the objects on that page from the web server, 323 stores a copy of the page and its objects (caches them), and forwards 324 the page and objects to the user. WCCP is another example of web 325 redirect thus, the same considerations described in section 326 Section 2.4 and the benefits introduced by MAP-T also apply here. 328 3. Technological Considerations 330 There are additional technological considerations which need to be 331 analyzed by the operator when choosing which transition technology 332 option they would like to deploy. This section describes some of 333 those considerations. 335 3.1. Encapsulation and Translation Overhead 336 MAP-E adds an encapsulation tax of 40 bytes, while MAP-T adds a 337 translation tax of 20 bytes (translating from a 20-byte IPv4 header 338 to a 40-byte IPv6 header.) In the downstream direction (from network 339 toward the CPE), with an average packet size of 1000-1100 bytes, the 340 added encapsulation is under 4% in the case of MAP-E. In the case of 341 MAP-T that encapsulation tax drops to about 2%. 343 In the upstream direction, with an average packet size of ~400 bytes, 344 the effects of the encapsulation tax is more pronounced with an added 345 10% overhead for MAP-E and 5% additional overhead for MAP-T. As the 346 upstream direction tends to be both (a) more heavily oversubscribed 347 than is the downstream and (b) of lower performance, the greater the 348 header tax the more it upsets the precariously balanced upstream/ 349 downstream network loading models. 351 3.2. Efficient Utilization of the Access Network 353 Point-to-Multipoint access networks are common across network 354 operators - DOCSIS (1.0, 1.1, 2.0, 3.0), EPON, 10G-EPON, GPON, 355 XGPON,XGPON2, etc. This network type has been incredibly successful, 356 as attested to by all the variants of point-to-multipoint networks 357 deployed, primarily because of their cost effectiveness. 359 There are a couple challenges that are introduced by adding a 360 significant amount of encapsulation overhead. These challenges 361 affect MAP-T and MAP-E similarly; the effects from MAP-E are simply 362 more pronounced. 364 The first challenge is that, commonly, point-to-multipoint networks 365 have limited support for jumbo frames. The second challenge is one 366 that results in reduction in effective capacity on the wire, which 367 yields higher cost. 369 3.2.1. Jumbo Frame Support in the Access 371 Some access technologies natively support fragmentation, and as a 372 result, can support "jumbo frames" up to a point. A max size IPv4 373 packet that fits into the payload of a standard-compliant Ethernet 374 frame is 1500 bytes. In the context of this discussion a "jumbo 375 frame" is any Ethernet frame that has more than 1500 bytes in the 376 Ethernet payload. IEEE Std. 802.3 now specifies a larger frame size 377 of up to 2000 bytes, referred to as an envelope frame, where the 378 envelope frame, quoting from IEEE Std.802.3-2012 "is intended to 379 allow inclusion of additional prefixes and suffixes required by 380 higher layer encapsulation protocols. The encapsulation protocols 381 may use up to 482 octets." 382 In the network access space, particularly one filled with legacy 383 access products which may be 10 years old (or perhaps older), it is 384 not uncommon to find products that just only support a max 1500 byte 385 Ethernet payload. Some may support up to 1532 byte payload (1550 386 byte Ethernet frame), some 1582 byte payload (1600 byte Ethernet 387 frame), though there's certainly not a uniform supported frame size 388 past the 1500 byte payload. 390 Since MTU discovery isn't typically used for IPv4 in operator 391 networks and since MTU discovery for IPv6 is not implemented on the 392 IPv4 host stack requesting the communication, there's no effective 393 way to tell the host stack to reduce the size of its IPv4 frame to 394 accommodate the MAP-T or MAP-E overhead with the MTU frame size 395 limitation of the specific access products. There are tools like 396 Maximum Segment Size rewrite that can be implemented to help address 397 the issue for a TCP payload but UDP payload will continue to be 398 impaired. 400 Thus MAP-T is preferred as there are more deployed access products 401 that could support a 1534-byte or 1538-byte Ethernet frame than can 402 support a 1554-byte or 1558-byte Ethernet frame, which mandates fewer 403 access product replacements. 405 3.2.2. Operator Added Packet Overhead and Service Level Agreements 407 One of the traditional challenges with adding additional packet 408 overhead to a customer frame is that it becomes more challenging to 409 provide customer the last-mile bandwidth in their SLA. This is a 410 very simple overprovisioning problem when the maximum size frame is 411 used, as the overhead in that case is a fixed ~1.5% or ~3% for MAP-T 412 and MAP-E respectively. 414 However in the case of variable packet sizes, the added overhead from 415 either MAP-T or MAP-E can become very significant - from a worse case 416 of ~31% (MAP-T) and ~63% (MAP-E) to the ~1.5% or ~3%. This means 417 that to provide the customer what they purchased operators will 418 either provision more than the customer SLA to account for the added 419 overhead or abide by the "not guaranteed" bandwidth response. 421 With the average upstream packet sizes being smaller, the 5% (MAP-T) 422 or 10% (MAP-E) added overhead for the average upstream packet size 423 could find itself in an overprovisioned QoS profile. 425 Many customers, particularly business customers, are very savvy and 426 have a strong belief that when a network operator offers them an SLA, 427 it's not an SLA at a specific packet size. This can be a significant 428 operational difficulty for network operators, one with a real 429 operational cost. 431 4. Conclusions 433 The use cases described in this document have highlighted a clear 434 need for a MAP-T solution based on Service Providers' operational 435 requirements. 437 This document showed that a MAP-T approach is not a duplication of 438 any other existing IPv4/IPv6 migration mechanisms based on IP 439 tunneling, but actually has capabilities to solve Service Provider's 440 problems. 442 5. Acknowledgements 444 TBD 446 6. IANA Considerations 448 This document does not require any action from IANA. 450 7. Security Considerations 452 This document has no additional security considerations beyond those 453 already identified in section 11 of [I-D.ietf-softwire-map-t] 455 8. Informative References 457 [I-D.ietf-softwire-map-t] 458 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 459 T. Murakami, "Mapping of Address and Port using 460 Translation (MAP-T)", draft-ietf-softwire-map-t-01 (work 461 in progress), February 2013. 463 [I-D.ietf-softwire-map] 464 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 465 Murakami, T., and T. Taylor, "Mapping of Address and Port 466 with Encapsulation (MAP)", draft-ietf-softwire-map-07 467 (work in progress), May 2013. 469 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 470 Stack Lite Broadband Deployments Following IPv4 471 Exhaustion", RFC 6333, August 2011. 473 Authors' Addresses 474 Roberta Maglione (editor) 475 Cisco Systems 476 181 Bay Street 477 Toronto M5J 2T3 478 Canada 480 Email: robmgl@cisco.com 482 Wojciech Dec 483 Cisco Systems 484 Haarlerbergweg 13-19 485 1101 CH Amsterdam 486 The Netherlands 488 Email: wdec@cisco.com 490 Victor Kuarsingh 491 Rogers Communications 492 8200 Dixie Road 493 Brampton, ON L6T 0C1 494 CANADA 496 Email: victor@jvknet.com 498 Edwin Mallette 499 Bright House Networks 500 4145 S. Faulkenburg Road 501 Riverview, Florida 33578 502 USA 504 Email: edwin.mallette@gmail.com