| softwire | R. Maglione, Ed. |
| Internet-Draft | W. Dec |
| Intended status: Informational | Cisco Systems |
| Expires: April 16, 2016 | I. Leung |
| Rogers Communications | |
| E. Mallette | |
| Bright House Networks | |
| October 14, 2015 |
Use cases for MAP-T
draft-maglione-softwire-map-t-scenarios-06
The Softwire working group standardized both encapsulation and translation based stateless IPv4/IPv6 solutions in order to be able to provide IPv4 connectivity to customers in an IPv6-Only environment.
The purpose of this document is to describe some operational use cases that would benefit from a translation based approach and highlights the operational benefits that a translation based solution would allow.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Softwire working group standardized both encapsulation [RFC7597] and translation [RFC7599] based stateless IPv4/IPv6 solutions developed for the purposes of offering IPv4 connectivity to the customers in an IPv6-Only environment.
There are deployment scenarios that may benefit equally from an encapsulated or translated form of an IPv4/IPv6 stateless addressing solution. There are, however, use cases where using a translation approach could lead to significant operational benefits and potential savings for the operators.
This document describes some use cases that would take advantage of a translation based solution, by highlighting the operational benefits that a translation based approach would allow.
In Broadband Networks it is common practice for Operators to apply per-subscriber policies on subscriber traffic at the network edge such as a BNG ( Broadband Network Gateway), CMTS (Cable Modem Termination System), PGW (PDN Gateway) or like device. Various services may require the application of different policies at these services edges.
Typically a policy would include a classification function and an action function.
The rationale for applying such policy at the network edge is based on how tightly coupled this layer of the network is with many key systems within the operators network such as RADIUS, DHCP, access technology awareness and ability to implement subscriber awareness.
In many common deployments today, the customer's policies are maintained in RADIUS server or enforced through other provisioned data in co-operation with service activation such as DHCP and bootstrap configuration. In a cable operator network, while much of the heavily lifting of subscriber management is embedded on the CMTS or OLT, the reality is that classification is shared across CMTS and cable-modem (CM) or across OLT and optical network unit (ONU.) The CM and ONU classification capabilities are not as robust and flexible as the upstream CMTS, OLT and/or assisting edge router. The implications of that are that the CPE may need to be replaced with a device that has the capability to classify on a larger packet header.
An additional point to consider is that the edge network nodes are also often fitted with, or co-located with higher functioning appliances that employ Deep Packet Inspection and distributed caches used to enhance service performance.
Most of the policies described in Section 2 require the use of network and transport layer classification and filtering mechanisms such as classifiers at the network edge. The application of classifiers and other network layer classification functions on selected subscriber flows are often applied by a AAA server, gleaned from configuration information, provisioned from per-CM DOCSIS configuration files generated from the operator OSS, or sent by a policy control function (PCRF, PCMM, etc).
This section will explain why the application of some types of classifiers (like Layer 3 destination based classifiers and - Layer 3 plus Layer 4 - classifiers,) can be deployed in a more simplistic fashion when using a translated form of a stateless IPv4/IPv6 transition technology such as MAP-T [RFC7599].
A key characteristic of MAP-T is the mapping of the IPv4 address of any destination into the IPv6 destination address, by means of IPv4 to IPv6 mapping rules. This mapping means that the subscriber flows are native IPv6 flows within the operators network. The ability to use a standard IPv6 classifier to identify interesting traffic for classification is well aligned with traditional traffic identification capabilities using IPv4 based classifiers. Such classifiers can be easily applied at the access edge as a standard function commonly available on most platforms deployed.
In contrast, a solution utilizing an IP tunnel based transport (MAP-E [RFC7597] or DS-Lite [RFC6333]), effectively hides the payload's IP layer information, making it difficult to identify by means of an IPv6 classifier . The operator in the latter case (tunneled option) would need additional functionality to classify the same subscriber flows which may not be available on the deployed platforms.
The classifier use case is further extended when considering that many traffic classifications are made using transport layer (Layer 4) information. This is common in operator networks that often apply differential traffic treatment to different services that typically operate using well defined TCP/UDP ports. In the MAP-T deployment case, these ports are available for classification matching using the same standard access edge node capabilities using IPv6 classifiers. In the case where tunneled forms of a solution are used, these higher layer ports are hidden from the network (base IP layer) and special functionality to correctly classify these service flows is required.
The ability to apply classifiers at the access edge node allows the operator to not only use standard IPv6 classifier functionality, but also use same mechanisms (RADIUS interface parameters/system, or DOCSIS configuration classifier parameters) for applying such classifiers. I.e. custom RADIUS interface extensions or custom DOCSIS classifier extensions to deal with the classifier semantics of an IP tunnel based transport are not required.
Some access technologies, like DOCSIS, require a modem configuration file for network operation. These configuration files often contain access control and classification information that uses IPv4 and/or IPv6 network and transport layer information.
MAP-T allows use of standard IPv6 classifiers within these configuration files permitting the continued use of the well-known service architecture. Translation technologies which use tunneling may require the operator to update how services are managed as information needed to enforce policy is not longer viewable by the Cable Modem or upstream CMTS. The operator in this case may need to build new service capabilities higher up in the network after the network translator to apply the full range of polices for the subscriber base.
Several Service Providers today use Deep Packet Inspection devices located at the network edge (such as a BNG) in order to inspect the subscriber's traffic for different purposes: profiling the user's behavior, and classifying the traffic based on higher layer information and/or traffic signatures.
Deep packet inspection devices available today in the market and, more importantly, those already deployed in operator's network may not be able to analyze encapsulated traffic, like IPinIP, and to correlate the inner packet's contents to the outer packet's "subscriber" context - this limitation is consistent across multiple vendors. In order to overcome this limitation when using IP tunnel based transports, without resorting to costly network upgrades, dedicated DPI devices need to be applied at a point in the network where the IP tunnel transport has been stripped and the payload is directly available for native processing. This not only changes the network architecture, but it increases the number of DPI's devices required: one for IPv6 traffic at the access edge, the other at a location where the IPv4 traffic is exposed (typically a separate Location). In addition the operator would need to enforce policies at two architecturally separate places in the network. Furthermore, even with these changes enacted, there remains a critical problem of correlating traffic to a given subscriber: in encapsulation based solutions, the IPv4 address information in the payload is not sufficient to uniquely identify a subscriber given that an IPv4 address will not be unique. As such, additional mechanisms and changes to the accounting infrastructure need to be introduced which when combined with all the previous aspects makes this solution operationally complex.
With MAP-T operators can continue using the current architectural model with DPI devices installed at the access edge; the only requirement would be to have the same device able to recognize specific applications on the native IPv6 transport, which DPI devices based on application signatures are capable of doing. Thus with MAP-T it doesn’t matter that an operator might provision the same IPv4 address across multiple subscribers. In addition with MAP-T the access edge would remain the single enforcement point for all user's policies for all traffic. This would allow the operators to continue using a consistent architecture and set of accounting tools for their network.
Redirecting the user's traffic to web portal is a common practice in Service Provider networks. For example, it is common for operators to inform users about new services, service advisories and/or access to account changes using web-reduction techniques activated on http traffic. In current deployments web-redirection occurs at the Edge node level, where the subscriber's traffic first hits the IP network. The activation/de- activation of redirection policy on selected subscribers may be driven by the AAA/RADIUS through specific RADIUS attributes. In current deployments web-redirection occurs at the Edge node level, where the subscriber's traffic first hits the IP network. The activation/de- activation of redirection policy on selected subscribers may be driven by the AAA/RADIUS through specific RADIUS attributes.
If MAP-T is used the redirection of both IPv6 and IPv4 traffic can be kept at the Edge of the network with the same configuration currently used and by simply translating the Server's address in IPv6 with known mapping rules. In case of tunnel based solution the redirection of IPv6 and IPv4 cannot occur in a single place, because the redirection of IPv4 traffic must be implemented at or after the v4/v6 gateway responsible for de-encapsulating the traffic. This approach not only would require deploying two separate infrastructures located in different places in order to achieve the redirection for both IPv6 and IPv4 traffic, but also it would not allow continuing using the AAA/RADIUS Server infrastructure in order to enforce the redirect policy at the subscriber's session.
With the continuing growing of video traffic, especially considering the increase of http video traffic (YouTube like,) it is useful for the Service Providers to be able to cache the video stream at the Edge of the network in order to save bandwidth on upstream links. Using cache devices together with tunnel solutions would introduce similar challenges/issues as the ones described for DPI scenarios, in particular it would require applying caching functionality after the decapsulation point. Obviously this would not eliminate the benefits of the cache. Instead a MAP-T approach would allow caching the subscriber traffic at the edge of the network and gaining the bandwidth savings introduced by the caching. Crucially, any native IPv6 web-caches would be capable of processing IPv6 MAP-T traffic as fully native traffic.
In addition in some deployments today, Web Cache Control Protocol (WCCP) feature is used in order to redirect subscriber’s traffic to the cache devices. When a subscriber requests a page from a web server (located in the Internet, in this case), the network node where the WCCP is active, sends the request to a Cache Engine. If the cache engine has a copy of the requested page in storage, the engine sends the user that page. Otherwise, the engine gets the requested page and the objects on that page from the web server, stores a copy of the page and its objects (caches them), and forwards the page and objects to the user. WCCP is another example of web redirect thus, the same considerations described in section Section 2.4 and the benefits introduced by MAP-T also apply here.
There are additional technological considerations which need to be analyzed by the operator when choosing which transition technology option they would like to deploy. This section describes some of those considerations.
MAP-E adds an encapsulation tax of 40 bytes, while MAP-T adds a translation tax of 20 bytes (translating from a 20-byte IPv4 header to a 40-byte IPv6 header.) In the downstream direction (from network toward the CPE), with an average packet size of 1000-1100 bytes, the added encapsulation is under 4% in the case of MAP-E. In the case of MAP-T that encapsulation tax drops to about 2%.
In the upstream direction, with an average packet size of ~400 bytes, the effects of the encapsulation tax is more pronounced with an added 10% overhead for MAP-E and 5% additional overhead for MAP-T. As the upstream direction tends to be both (a) more heavily oversubscribed than is the downstream and (b) of lower performance, the greater the header tax the more it upsets the precariously balanced upstream/ downstream network loading models.
Point-to-Multipoint access networks are common across network operators - DOCSIS (1.0, 1.1, 2.0, 3.0), EPON, 10G-EPON, GPON, XGPON,XGPON2, etc. This network type has been incredibly successful, as attested to by all the variants of point-to-multipoint networks deployed, primarily because of their cost effectiveness.
There are a couple challenges that are introduced by adding a significant amount of encapsulation overhead. These challenges affect MAP-T and MAP-E similarly; the effects from MAP-E are simply more pronounced.
The first challenge is that, commonly, point-to-multipoint networks have limited support for jumbo frames. The second challenge is one that results in reduction in effective capacity on the wire, which yields higher cost.
Some access technologies natively support fragmentation, and as a result, can support "jumbo frames" up to a point. A max size IPv4 packet that fits into the payload of a standard-compliant Ethernet frame is 1500 bytes. In the context of this discussion a "jumbo frame" is any Ethernet frame that has more than 1500 bytes in the Ethernet payload. IEEE Std. 802.3 now specifies a larger frame size of up to 2000 bytes, referred to as an envelope frame, where the envelope frame, quoting from IEEE Std.802.3-2012 "is intended to allow inclusion of additional prefixes and suffixes required by higher layer encapsulation protocols. The encapsulation protocols may use up to 482 octets."
In the network access space, particularly one filled with legacy access products which may be 10 years old (or perhaps older), it is not uncommon to find products that just only support a max 1500 byte Ethernet payload. Some may support up to 1532 byte payload (1550 byte Ethernet frame), some 1582 byte payload (1600 byte Ethernet frame), though there's certainly not a uniform supported frame size past the 1500 byte payload.
Since MTU discovery isn't typically used for IPv4 in operator networks and since MTU discovery for IPv6 is not implemented on the IPv4 host stack requesting the communication, there's no effective way to tell the host stack to reduce the size of its IPv4 frame to accommodate the MAP-T or MAP-E overhead with the MTU frame size limitation of the specific access products. There are tools like Maximum Segment Size rewrite that can be implemented to help address the issue for a TCP payload but UDP payload will continue to be impaired.
Thus MAP-T is preferred as there are more deployed access products that could support a 1534-byte or 1538-byte Ethernet frame than can support a 1554-byte or 1558-byte Ethernet frame, which mandates fewer access product replacements.
One of the traditional challenges with adding additional packet overhead to a customer frame is that it becomes more challenging to provide customer the last-mile bandwidth in their SLA. This is a very simple overprovisioning problem when the maximum size frame is used, as the overhead in that case is a fixed ~1.5% or ~3% for MAP-T and MAP-E respectively.
However in the case of variable packet sizes, the added overhead from either MAP-T or MAP-E can become very significant - from a worse case of ~31% (MAP-T) and ~63% (MAP-E) to the ~1.5% or ~3%. This means that to provide the customer what they purchased operators will either provision more than the customer SLA to account for the added overhead or abide by the "not guaranteed" bandwidth response.
With the average upstream packet sizes being smaller, the 5% (MAP-T) or 10% (MAP-E) added overhead for the average upstream packet size could find itself in an overprovisioned QoS profile.
Many customers, particularly business customers, are very savvy and have a strong belief that when a network operator offers them an SLA, it's not an SLA at a specific packet size. This can be a significant operational difficulty for network operators, one with a real operational cost.
The use cases described in this document have highlighted a clear need for a MAP-T solution based on Service Providers’ operational requirements.
This document showed that a MAP-T approach is not a duplication of any other existing IPv4/IPv6 migration mechanisms based on IP tunneling, but actually has capabilities to solve Service Provider’s problems.
The authors would like to thank Victor Kuarsingh for his valuable comments and inputs to this document.
This document does not require any action from IANA.
This document has no additional security considerations beyond those already identified in section 11 of [RFC7599]
| [RFC6333] | Durand, A., Droms, R., Woodyatt, J. and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011. |
| [RFC7597] | Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T. and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015. |
| [RFC7599] | Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S. and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015. |