One document matched: draft-maglione-softwire-map-t-scenarios-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY __reference.RFC.2869__g60i1uxb SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2869.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc category="info" docName="draft-maglione-softwire-map-t-scenarios-00"
ipr="trust200902" updates="">
<front>
<title abbrev="MAP-T uses cases">Uses cases for MAP-T</title>
<author fullname="Roberta Maglione" initials="R." surname="Maglione">
<organization abbrev="">Telecom Italia</organization>
<address>
<postal>
<street>Via Reiss Romoli 274</street>
<city>Torino</city>
<code>10148</code>
<country>Italy</country>
</postal>
<phone></phone>
<email>roberta.maglione@telecomitalia.it</email>
</address>
</author>
<author fullname="Wojciech Dec" initials="W." surname="Dec">
<organization>Cisco</organization>
<address>
<postal>
<street>Haarlerbergweg 13-19</street>
<city>1101 CH Amsterdam</city>
<region></region>
<code></code>
<country>The Netherlands</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>wdec@cisco.com</email>
<uri></uri>
</address>
</author>
<date month="October" year="2012" />
<area>Internet</area>
<workgroup>softwire</workgroup>
<abstract>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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.</t>
<t>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.</t>
</section>
<section anchor="policy"
title="Application of Service Policies to the subscriber’s sessions">
<t>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.</t>
<t>Examples of policies currently used in today's deployments include:
<list style="symbols">
<t>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;</t>
<t>the classification of traffic based on destination;</t>
<t>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;</t>
<t>the redirection of selected types of traffic to a Web portal;</t>
<t>the caching of selected types of traffic.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<section anchor="acl" title="Application of Access Control Lists ">
<t>Most of the policies described in section <xref
target="policy"></xref> 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.</t>
<t>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.</t>
<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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Application of policies based on Deep Packet Inspection">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="redirect"
title="Application of web-redirection policies">
<t>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.</t>
<t>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.</t>
</section>
<section title="Caching ">
<t>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.</t>
<t>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 <xref target="redirect"></xref>
and the benefits introduced by MAP-T also apply here.</t>
</section>
</section>
<section title="Conclusions">
<t>The use cases described in this document have highlighted a clear
need for a MAP-T solution based on Service Providers’ operational
requirements.</t>
<t>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.</t>
</section>
<!-- term -->
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<section anchor="contr" title="Acknowledgements">
<t>TBD</t>
</section>
<section anchor="seccons" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section anchor="IANA" title="Security Considerations">
<t>TBD</t>
</section>
</middle>
<back></back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:15:06 |