Skip to main content

Uses cases for MAP-T
draft-maglione-softwire-map-t-scenarios-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Roberta Maglione , Wojciech Dec
Last updated 2012-10-03
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-maglione-softwire-map-t-scenarios-00
softwire                                                     R. Maglione
Internet-Draft                                            Telecom Italia
Intended status: Informational                                    W. Dec
Expires: April 6, 2013                                             Cisco
                                                         October 3, 2012

                          Uses cases for MAP-T
               draft-maglione-softwire-map-t-scenarios-00

Abstract

   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 translations based approach would allow.

Status of this Memo

   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 6, 2013.

Copyright Notice

   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

Maglione & Dec            Expires April 6, 2013                 [Page 1]
Internet-Draft              MAP-T uses cases                October 2012

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Application of Service Policies to the subscriber's
       sessions  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Application of Access Control Lists . . . . . . . . . . . . 4
     2.2.  Application of policies based on Deep Packet Inspection . . 5
     2.3.  Application of web-redirection policies . . . . . . . . . . 6
     2.4.  Caching . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   3.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Maglione & Dec            Expires April 6, 2013                 [Page 2]
Internet-Draft              MAP-T uses cases                October 2012

1.  Introduction

   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 translations based approach would allow.

2.  Application of Service Policies to the subscriber's sessions

   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:
   o  the classification of the traffic not only based on layer 3
      identifiers, but also based on layer 4 fields, like TCP and/or UDP
      ports;
   o  the classification of traffic based on destination;
   o  the application of different QoS treatment (could be rate-limit,
      drop, redirect,.. etc) on selected types of traffic based on layer
      4-7 classification done by deep packet inspection appliances;
   o  the redirection of selected types of traffic to a Web portal;
   o  the caching of selected types of traffic.

   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

Maglione & Dec            Expires April 6, 2013                 [Page 3]
Internet-Draft              MAP-T uses cases                October 2012

   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.

2.1.  Application of Access Control Lists

   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.

   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 or DS-Lite),
   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

Maglione & Dec            Expires April 6, 2013                 [Page 4]
Internet-Draft              MAP-T uses cases                October 2012

   ACL semantics of an IP tunnel based transport are not required.

2.2.  Application of policies based on Deep Packet Inspection

   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.

Maglione & Dec            Expires April 6, 2013                 [Page 5]
Internet-Draft              MAP-T uses cases                October 2012

2.3.  Application of web-redirection policies

   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 expires, 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.

2.4.  Caching

   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

Maglione & Dec            Expires April 6, 2013                 [Page 6]
Internet-Draft              MAP-T uses cases                October 2012

   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.

3.  Conclusions

   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.

4.  Acknowledgements

   TBD

5.  IANA Considerations

   This document does not require any action from IANA.

6.  Security Considerations

   TBD

Authors' Addresses

   Roberta Maglione
   Telecom Italia
   Via Reiss Romoli 274
   Torino  10148
   Italy

   Phone:
   Email: roberta.maglione@telecomitalia.it

Maglione & Dec            Expires April 6, 2013                 [Page 7]
Internet-Draft              MAP-T uses cases                October 2012

   Wojciech Dec
   Cisco
   Haarlerbergweg 13-19
   1101 CH Amsterdam,
   The Netherlands

   Phone:
   Fax:
   Email: wdec@cisco.com
   URI:

Maglione & Dec            Expires April 6, 2013                 [Page 8]