idnits 2.17.1 draft-maglione-softwire-map-t-scenarios-06.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 (October 14, 2015) is 3116 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: April 16, 2016 I. Leung 6 Rogers Communications 7 E. Mallette 8 Bright House Networks 9 October 14, 2015 11 Use cases for MAP-T 12 draft-maglione-softwire-map-t-scenarios-06 14 Abstract 16 The Softwire working group standardized both encapsulation and 17 translation based stateless IPv4/IPv6 solutions in order to be able 18 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 April 16, 2016. 43 Copyright Notice 45 Copyright (c) 2015 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 . . . . . . . . . 8 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 standardized both encapsulation [RFC7597] 83 and translation [RFC7599] based stateless IPv4/IPv6 solutions 84 developed for the purposes of offering IPv4 connectivity to the 85 customers in an 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), PGW (PDN Gateway) or like device. Various 103 services may require the application of different policies at these 104 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 [RFC7599]. 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 [RFC7597] or DS-Lite [RFC6333]), effectively hides the payload's IP 184 layer information, making it difficult to identify by means of an 185 IPv6 classifier . The operator in the latter case (tunneled option) 186 would need additional functionality to classify the same subscriber 187 flows which may not be available on the deployed platforms. 189 The classifier use case is further extended when considering that 190 many traffic classifications are made using transport layer (Layer 4) 191 information. This is common in operator networks that often apply 192 differential traffic treatment to different services that typically 193 operate using well defined TCP/UDP ports. In the MAP-T deployment 194 case, these ports are available for classification matching using the 195 same standard access edge node capabilities using IPv6 classifiers. 196 In the case where tunneled forms of a solution are used, these higher 197 layer ports are hidden from the network (base IP layer) and special 198 functionality to correctly classify these service flows is required. 200 The ability to apply classifiers at the access edge node allows the 201 operator to not only use standard IPv6 classifier functionality, but 202 also use same mechanisms (RADIUS interface parameters/system, or 203 DOCSIS configuration classifier parameters) for applying such 204 classifiers. I.e. custom RADIUS interface extensions or custom 205 DOCSIS classifier extensions to deal with the classifier semantics of 206 an IP tunnel based transport are not required. 208 2.2. Device Configuration (DOCSIS) 210 Some access technologies, like DOCSIS, require a modem configuration 211 file for network operation. These configuration files often contain 212 access control and classification information that uses IPv4 and/or 213 IPv6 network and transport layer information. 215 MAP-T allows use of standard IPv6 classifiers within these 216 configuration files permitting the continued use of the well-known 217 service architecture. Translation technologies which use tunneling 218 may require the operator to update how services are managed as 219 information needed to enforce policy is not longer viewable by the 220 Cable Modem or upstream CMTS. The operator in this case may need to 221 build new service capabilities higher up in the network after the 222 network translator to apply the full range of polices for the 223 subscriber base. 225 2.3. Service Flow management using Deep Packet Inspection 227 Several Service Providers today use Deep Packet Inspection devices 228 located at the network edge (such as a BNG) in order to inspect the 229 subscriber's traffic for different purposes: profiling the user's 230 behavior, and classifying the traffic based on higher layer 231 information and/or traffic signatures. 233 Deep packet inspection devices available today in the market and, 234 more importantly, those already deployed in operator's network may 235 not be able to analyze encapsulated traffic, like IPinIP, and to 236 correlate the inner packet's contents to the outer packet's 237 "subscriber" context - this limitation is consistent across multiple 238 vendors. In order to overcome this limitation when using IP tunnel 239 based transports, without resorting to costly network upgrades, 240 dedicated DPI devices need to be applied at a point in the network 241 where the IP tunnel transport has been stripped and the payload is 242 directly available for native processing. This not only changes the 243 network architecture, but it increases the number of DPI's devices 244 required: one for IPv6 traffic at the access edge, the other at a 245 location where the IPv4 traffic is exposed (typically a separate 246 Location). In addition the operator would need to enforce policies 247 at two architecturally separate places in the network. Furthermore, 248 even with these changes enacted, there remains a critical problem of 249 correlating traffic to a given subscriber: in encapsulation based 250 solutions, the IPv4 address information in the payload is not 251 sufficient to uniquely identify a subscriber given that an IPv4 252 address will not be unique. As such, additional mechanisms and 253 changes to the accounting infrastructure need to be introduced which 254 when combined with all the previous aspects makes this solution 255 operationally complex. 257 With MAP-T operators can continue using the current architectural 258 model with DPI devices installed at the access edge; the only 259 requirement would be to have the same device able to recognize 260 specific applications on the native IPv6 transport, which DPI devices 261 based on application signatures are capable of doing. Thus with 262 MAP-T it doesn't matter that an operator might provision the same 263 IPv4 address across multiple subscribers. In addition with MAP-T the 264 access edge would remain the single enforcement point for all user's 265 policies for all traffic. This would allow the operators to continue 266 using a consistent architecture and set of accounting tools for their 267 network. 269 2.4. Service Flow Redirection Policies (Web-redirection) 271 Redirecting the user's traffic to web portal is a common practice in 272 Service Provider networks. For example, it is common for operators 273 to inform users about new services, service advisories and/or access 274 to account changes using web-reduction techniques activated on http 275 traffic. In current deployments web-redirection occurs at the Edge 276 node level, where the subscriber's traffic first hits the IP network. 277 The activation/de- activation of redirection policy on selected 278 subscribers may be driven by the AAA/RADIUS through specific RADIUS 279 attributes. In current deployments web-redirection occurs at the 280 Edge node level, where the subscriber's traffic first hits the IP 281 network. The activation/de- activation of redirection policy on 282 selected subscribers may be driven by the AAA/RADIUS through specific 283 RADIUS attributes. 285 If MAP-T is used the redirection of both IPv6 and IPv4 traffic can be 286 kept at the Edge of the network with the same configuration currently 287 used and by simply translating the Server's address in IPv6 with 288 known mapping rules. In case of tunnel based solution the 289 redirection of IPv6 and IPv4 cannot occur in a single place, because 290 the redirection of IPv4 traffic must be implemented at or after the 291 v4/v6 gateway responsible for de-encapsulating the traffic. This 292 approach not only would require deploying two separate 293 infrastructures located in different places in order to achieve the 294 redirection for both IPv6 and IPv4 traffic, but also it would not 295 allow continuing using the AAA/RADIUS Server infrastructure in order 296 to enforce the redirect policy at the subscriber's session. 298 2.5. Service Flow Caching 300 With the continuing growing of video traffic, especially considering 301 the increase of http video traffic (YouTube like,) it is useful for 302 the Service Providers to be able to cache the video stream at the 303 Edge of the network in order to save bandwidth on upstream links. 304 Using cache devices together with tunnel solutions would introduce 305 similar challenges/issues as the ones described for DPI scenarios, in 306 particular it would require applying caching functionality after the 307 decapsulation point. Obviously this would not eliminate the benefits 308 of the cache. Instead a MAP-T approach would allow caching the 309 subscriber traffic at the edge of the network and gaining the 310 bandwidth savings introduced by the caching. Crucially, any native 311 IPv6 web-caches would be capable of processing IPv6 MAP-T traffic as 312 fully native traffic. 314 In addition in some deployments today, Web Cache Control Protocol 315 (WCCP) feature is used in order to redirect subscriber's traffic to 316 the cache devices. When a subscriber requests a page from a web 317 server (located in the Internet, in this case), the network node 318 where the WCCP is active, sends the request to a Cache Engine. If 319 the cache engine has a copy of the requested page in storage, the 320 engine sends the user that page. Otherwise, the engine gets the 321 requested page and the objects on that page from the web server, 322 stores a copy of the page and its objects (caches them), and forwards 323 the page and objects to the user. WCCP is another example of web 324 redirect thus, the same considerations described in section 325 Section 2.4 and the benefits introduced by MAP-T also apply here. 327 3. Technological Considerations 329 There are additional technological considerations which need to be 330 analyzed by the operator when choosing which transition technology 331 option they would like to deploy. This section describes some of 332 those considerations. 334 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 The authors would like to thank Victor Kuarsingh for his valuable 445 comments and inputs to this document. 447 6. IANA Considerations 449 This document does not require any action from IANA. 451 7. Security Considerations 453 This document has no additional security considerations beyond those 454 already identified in section 11 of [RFC7599] 456 8. Informative References 458 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 459 Stack Lite Broadband Deployments Following IPv4 460 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 461 . 463 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 464 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 465 Port with Encapsulation (MAP-E)", RFC 7597, 466 DOI 10.17487/RFC7597, July 2015, 467 . 469 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 470 and T. Murakami, "Mapping of Address and Port using 471 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 472 2015, . 474 Authors' Addresses 475 Roberta Maglione (editor) 476 Cisco Systems 477 Via Torri Bianche 8 478 Vimercate 20871 479 Italy 481 Email: robmgl@cisco.com 483 Wojciech Dec 484 Cisco Systems 485 Haarlerbergweg 13-19 486 1101 CH Amsterdam 487 The Netherlands 489 Email: wdec@cisco.com 491 Ida Leung 492 Rogers Communications 493 8200 Dixie Road 494 Brampton, ON L6T 0C1 495 CANADA 497 Email: Ida.Leung@rci.rogers.com 499 Edwin Mallette 500 Bright House Networks 501 4145 S. Faulkenburg Road 502 Riverview, Florida 33578 503 USA 505 Email: edwin.mallette@gmail.com