| softwire | R. Maglione |
| Internet-Draft | Telecom Italia |
| Intended status: Informational | W. Dec |
| Expires: May 09, 2013 | Cisco |
| November 05, 2012 |
Uses cases for MAP-T
draft-maglione-softwire-map-t-scenarios-01
Softwire working group is currently discussing 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 use cases that would take advantage of a translation based solution, by highlighting the operational benefits that a translation based approach 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 May 09, 2013.
Copyright (c) 2012 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.
Softwire working group is currently discussing both encapsulation and translation based stateless IPv4/IPv6 solutions in order to be able to provide IPv4 connectivity to the customers in an IPv6 only environment. There are scenarios where using encapsulation based or translation based approaches does not make substantial differences, however there are many other cases where using a translation approach could lead to significant operational 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 is common practice for Service Providers to be able to apply per-subscriber policies on customer's traffic at the BNG (Broadband Network Gateway) level. Different services may require the application of different policies.
Examples of policies currently used in today's deployments include:
The reason why in the current Broadband network, it is important to be able to enforce policies at the BNG is because the BNG is the only network element, interacting with the AAA/RADIUS Server, responsible for authentication, authorization and accounting for the subscriber's sessions. In many common deployments today, the customer's policies are maintained in AAA/RADIUS Server together with the customer's profile and they are applied to the subscriber's session by using standardized RADIUS attributes during the authentication/authorization phases.
In addition in today's deployments, the appliances used to provide value added services, like Deep Packet Inspection devices, caching devices, etc., are usually either co-located or integrated with the BNG box. In order to be able to re-use the current network infrastructure and for operational reasons, it is important for the operators to be able to continue having a single enforcement point, at the BNG level, for all the subscriber's policies for both IPv4 and IPv6 traffic, as opposed to distributing such functionality across two or more nodes.
Most of the policies described in section Section 2 require the application of an access control list on the BNG in order to be able to classify the user traffic. The application of ACL’s on selected subscribers it is usually driven by the AAA/RADIUS through specific RADIUS attributes.
This section will explain why the application of some types of ACL’s (like for example Destination based ACL and ACL able to match not only layer 3, but also layer 4 fields) can be simply achieved when using MAP-T [I-D.ietf-softwire-map-t].
A key characteristic of MAP-T is the mapping of the IPv4 address of any destination into the IPv6 destination address, by means of the IPv4 to IPv6 mapping rule. Given that in using a regular IPv6 ACL, an operator's main requirement is to be able to identify interesting traffic by means of IPv6 destination addresses, at the BNG level. MAP-T appears the natural approach to solve the problem, without recourse to any non-commonly found device features. In contrast any solution utilizing an IP tunnel based transport (MAP-E [I-D.ietf-softwire-map] or DS-Lite [RFC6333]), effectively hides the payload's IP layer information, making it difficult to identify by means of an IPv6 ACL.
Another example of application for MAP-T is where Access Control Lists able to match not only layer 3, but also layer 4 fields, are required. This is a quite common scenario as ACL’s matching TCP/UDP ports are widely used in Service Provider's environments in order to classify different traffic types and to apply different qos treatments. In case of an IP tunnel-based transport at the BNG level, the IPv4 traffic is encapsulated inside an IPv6 packet thus the BNG is not able to see the layer 4 fields without either de-encapsulating the packet or by inspecting the IPinIP traffic. On the other hands, using MAP-T, the layer 4 fields would be preserved as the IPv4 traffic is only translated in IPv6 by using the IPv6 MAP rules. With MAP-T the TCP/UDP traffic could be identify at the BNG level by simply using and IPv6 ACL matching the IPv6 prefix and the required TCP/UDP ports.
Being able to apply ACL's at the BNG level would allow the operator to not only use regular IPv6 ACL functionality, but also use throughout the same RADIUS interface parameters/system for applying such ACLs. I.e. custom RADIUS interface extensions to deal with the ACL semantics of an IP tunnel based transport are not required.
Several Service Providers today use deep packet inspection devices located at the BNG level, in order to inspect the subscriber's traffic for different purposes: profiling the user's behavior, for example in order to be able to provide customized advertisement, classifying the traffic not only based on DSPC/TOS, but also based on layer 4-7 identifiers in order to be able to offer different QoS treatments.
Deep packet inspection devices available today in the market and already deployed in operator's network are not 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 BNG level, the other for IPv4 traffic on a separate location. In addition the operator would need to enforce policies on two separate places in the network. Furthermore, even with these changes enacted, there remains a critical problem of correlating traffic to a given subscriber: in the DS-Lite and MAP-E 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, further 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 BNG level; 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. In addition with MAP-T the BNG 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's network. It is widely used today for example in order to inform the user about new service offers, or about temporary unavailable services, or in order to allow the user to re-charge is account after his credit has expired, etc … When web-redirection is activated for a specific subscriber all the http traffic of that customer is the redirected towards an external server. In current deployment web-redirection happens at the BNG 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 BNG 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 happen 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 (you tube 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 in 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.3 and the benefits introduced by MAP-T also apply here.
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.
TBD
This document does not require any action from IANA.
TBD
| [RFC6333] | Durand, A., Droms, R., Woodyatt, J. and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. |
| [I-D.ietf-softwire-map] | Troan, O, Dec, W, Li, X, Bao, C, Zhai, Y, Matsushima, S and T Murakami, "Mapping of Address and Port (MAP)", Internet-Draft draft-ietf-softwire-map-01, June 2012. |
| [I-D.ietf-softwire-map-t] | Li, X, Bao, C, Dec, W, Troan, O, Matsushima, S and T Murakami, "Mapping of Address and Port using Translation (MAP-T)", Internet-Draft draft-ietf-softwire-map-t-00, October 2012. |