2008 IEEE Workshop on Policies for Distributed Systems and Networks
Policy Peering for Next-Generation Networks
Kalyani Bogineni
Verizon Communications
kalyani.bogineni@verizon.com
Abstract
This paper discusses policy architecture for
converged service provider networks and the need for
policy peering. A policy peering architecture is
proposed. The design principles and requirements for
the peering interface and its use for static and dynamic
policies across service providers are explained.
1. Introduction
Networks have evolved from separate networks for
voice and data towards converged IP networks that can
support applications with differing requirements. The
stringent requirements of voice and video applications
created the need for differential treatment in the IP
network. This led to the introduction of the general
policy architecture shown in Figure 1, where one or
more Application Functions (AFs), e.g. a Voice over
IP call control server, interacts with a Policy Decision
Point (PDP), when the application requires Quality of
Service (QoS) for a particular flow of IP traffic. The
PDP has access to a user's policy profile, which
contains information about services subscribed to, etc.
The PDP interacts with a Policy Enforcement Point
(PEP), e.g. an edge router, which helps ensure that the
IP flow(s) in question receive the authorized QoS.
Application
Function (AF)
Policy
Decision Policy
Profile
Point (PDP)
Policy
Enforcement
Point (PEP)
Figure 1 - Traditional Policy Architecture
This type of policy architecture was adopted by the
major types of access networks, i.e., cellular [1, 2],
wireline [3], and cable [4]. This policy architecture
978-0-7695-3133-5/08 $25.00 © 2008 IEEE
DOI 10.1109/POLICY.2008.27
Flemming Andreasen
Cisco Systems, Inc.
fandreas@cisco.com
laid the foundation for future converged service
provider networks, however the currently specified
policy solutions have some important limitations.
The network relationship between the AF, PDP, and
PEP depends on the type of access network. In some
access networks, they must all belong to the same
service provider. In others, two or more providers may
be involved, however there is generally limited
treatment of the implications of that. In particular, with
only a single PDP, policy control is handled by one
provider only, yet resources may be provided by
another. This is problematic for various mobility and
roaming scenarios in future converged networks with a
need to support policy control for a wide range of
applications and network resources.
Another limitation is the lack of integration between
the policy infrastructure and the authentication and
authorization infrastructure. Traditionally, static
subscriber policies are handled by an authentication
and authorization infrastructure but dynamic subscriber
policies are handled by the policy infrastructure.
Exchange of subscriber service profiles between
service providers is another issue. The home and
visited provider must agree on the allowable contents
of the subscriber's service profile and they may also
need to deploy the same services, thereby limiting
rapid innovation by either. Exchange of complete
service profile information also raises privacy and
competitive concerns for providers.
The final limitation involves the areas for which
policy is provided. Currently, only QoS, charging and
Network Address Translator (NAT) traversal have
been considered, however there are other resources to
consider for policy control.
In the next section, we describe a policy architecture
for the future converged networks based on current
architectures. In Section 3, we focus on the policy
peering interface and describe the proposed
requirements and design principles.
211
2. Policy Architecture
The future converged network architecture should
have an access network agnostic core network. This
enables fixed/mobile convergence, allows service
providers to evolve their access networks
independently from their core infrastructure, and
supports different types of access networks. These
future networks also need an access agnostic policy
core that can communicate with other service providers
through the use of policy peering, irrespective of which
type of access network (wireless, wireline, cable) the
peer supports.
The converged network architecture must also
consider the role of the home and the visited network
(which is the network into which a user roams).
Traditionally, the visited network has provided the
access network connectivity, but the IP mobility
anchor point (e.g. Home Agent) and the policy control
have been provided by the home network. This model
is too restrictive for the converged network. Some
applications will require very low latency and hence
cannot have traffic backhauled to the home network.
Also, there is a cost associated with backhauling traffic
to the home network (the home network can be in
another continent across the world). Conversely, the
home network provider may want to provide value-
added services for some traffic, e.g. Virtual Private
Network service, deep packet inspection (DPI), etc.
which may require provider specific processing. Such
traffic will have to be backhauled to the home network.
In either case, the subscriber's policy profile should
determine how the traffic is handled. However, the
visited network provider's resources are being used,
and hence the visited network provider should be able
to provide policies too. The solution involves use of
multiple IP anchor points: one in the visited network
and one in the home network, both under policy
control by the home and visited network, as illustrated
in Figure 2.
The architecture is based on the following main
requirements for services delivery in the visited
network.
• Policy should be provided for all types of
applications while roaming for both home and
visited network services.
• The visited network provider should manage usage
of resources in its network for roaming
subscribers.
• The visited network provider should be able to
override the home network provider policies on
usage of network resources by a roaming user.
212
• The visited network provider should account for
the usage of resources in their network, so that
appropriate billing and reconciliation can occur.
To address the policy overlap between the
authentication and authorization infrastructure and the
policy infrastructure, the authorization part is relegated
to the policy infrastructure: When a user gets access to
the network, the policy enforcement point (e.g. access
gateway) is involved in the authentication procedure.
Following successful authentication, the PEP contacts
the PDP to request (pull) the user's static policies,
which apply to the user's overall IP session. The visited
PDP (v-PDP) contacts the home PDP (h-PDP) to
obtain the subscriber-specific policies, and the v-PDP
installs those policies on the visited PEP (v-PEP),
subject to any local network policies it may have.
Dynamic policies may be installed subsequently. When
the user invokes an application, it interacts with the
PDP to have flow-specific policies installed. The PDP
may now push these policies to the PEP, where they
govern authorization of the user's request for resources.
Provider B Provider A
(Visited) (Home)
Authentication
Function
Authentication
Function
Application
Function (AF)
Application
Function (AF)
Policy Policy
Network
Policies
Decision
Point
Decision
Point
Subscriber
Policies
(PDP) (PDP)
Policy Policy
Enforcement Enforcement
Point Point
(PEP) (PEP)
Figure 2 – Future Converged Network
Architecture
The policy peering interface is here used when the
roaming user invokes a home network provided
application that uses the v-PEP for traffic (e.g. an audio
stream for a voice call). The user will attempt to use
resources in the visited network (e.g. QoS), and in
order to authorize such use, an interaction with the h-
PDP will be needed (via the v-PDP) to install a
dynamic policy decision for the flow.
Application Functions may reside in both the home
and the visited network, however they always interact
with the PDP in the same network (unless the AF is
provided by a third party). When the AF resides in the
visited network, the v-PDP may still have an
interaction with the h-PDP; this enables the home
network to always apply policies in accordance with
the user's policy profile, irrespective of whether the
home network resources are being used or not.
3. Peering Interface Design Principles
This section provides the design principles and
requirements for the policy peering interface.
3.1 Uniform Policy Peering Interface
There should be a single uniform policy peering
interface that can be used by all providers, irrespective
of the types of access networks they support. Similarly,
the interface must accommodate providers with
varying policy capabilities.
Today, different access network types define their
own policy architectures and interfaces. Ideally, we
would have a common policy peering protocol defined
for all access network types. More importantly though,
we need universal support for the same underlying
policy information and flows; protocol differences can
then be handled by interworking functions.
Policy information types include static, dynamic,
per-session/per-flow QoS and charging policies. Policy
objects must be defined in an access network agnostic
manner, and we must support new policy objects (e.g.
DPI control) as extensions. This does not preclude the
use of access network specific policy objects for more
detailed control, but a basic level of interoperability
requires access network agnostic parameters.
The basic flows needed to be supported are policy
capabilities exchange, policy pull, and policy push. A
policy capabilities exchange informs each network of
the peer network's policy capabilities. This way, the
home network learns which policies it can ask the
visited network to enforce (and vice versa), and which
policies will require traffic to be routed to the home
network for policy enforcement. Once learned, the
home network can inform the user's device of which
applications require use of the home anchor point. In
“policy pull”, the PEP requests policy from the PDP
and in “policy push” the PDP proactively installs
policies in the PEP.
3.2 Consistent User Experiences and
Application Aware Policy Decisions
There should be a consistent user experience
between the roaming and non-roaming case,
irrespective of the services supported by the visited
network. At the same time, the visited network should
control use of its own resources and be able to make
application aware policy decisions.
213
Traditionally, services have been provided by the
visited network, however this requires standardization
and deployment of said services in the visited network.
Due to the need for service provider differentiation,
services are often provided by the home network. To
enable visited network control of resources, the home
PDP controls the subscriber specific policies and
communicates the resulting policy decisions to the
visited network, where they are installed in the PEP,
subject to any visited network policy modifications.
While this may seem straightforward, it is
challenging to enable both the home and visited
network to make application aware policy decisions
without standardizing services. For example, a roaming
agreement between provider A and B may allow A's
subscribers to use up to 10 percent of B's access
network resources when placing Voice over IP (VoIP)
calls served by A's home VoIP infrastructure. To
address this, we require the policy peering interface to
inform the peer provider of the "name" of the
application being used as well as "names" of its
constituent flows and associated policy parameters.
The names are simple text-strings that can be
established as part of the roaming agreement. Although
B's infrastructure does not support these applications,
B's PDPs can still make application aware policy
decisions and perform application-specific charging for
use of B's resources. Similarly, applications deployed
in B's network and used by roaming subscribers from
A are assigned a "name" to enable application aware
policy decisions from the subscriber's home network.
The visited network has important information for
the home network policy decision; in particular the
access network characteristics and available network
resources. The policy peering interface needs to inform
the home network of the current type of access network
and its associated bandwidth characteristics. Available
bandwidth is another issue. Communicating such
continuously changing information would be chatty
and may divulge more detailed information than the
visited network would like. Instead, the policy peering
interface should propose alternative policies when a
given request cannot be satisfied. For example, if
provider A asks for a 200 kb/s flow, provider B may
reject that while indicating support for a 100 kb/s flow.
3.3 Real-Time Policy Decisions and Policy
Peering
The policy peering interface must provide an
efficient interface that can support real-time
applications.
Policy interactions may occur at different points in
time and for different purposes. Some of these involve
real-time interactions where a minimal delay is
important. Two strategies are proposed for dealing
with that. First, the policy peering interface should
allow for policy delegation, whereby the home PDP
can push policy decisions to the visited network ahead
of time instead of always having policies pulled from
the visited network. Those policies should include
authorization guidelines such that subsequent requests
for resources in the visited network do not need
interaction with the home PDP. Secondly, the peering
interface should allow for opportunistic and
asynchronous policy interactions by use of a
provisional policy decision, which may be changed
following the completion of the policy interaction.
3.4 Expanded Policy Control
As the role of policy expands, it must be possible to
extend the set of policy objects from the current QoS,
charging, and NAT focus. The peering interface must
be extensible, but, to accommodate service providers
with different capabilities and avoid the need to
standardize services, a capabilities exchange and a
flexible approach to extension policies should be used.
Existing service provider policy architectures have
focused on policy control of QoS and charging, and in
one case NAT traversal as well. The future converged
networks however have additional functions and
resources that benefit from integrated policy control.
Access policies for example govern which entities a
user device is allowed to communicate with. Mobility
policies govern the mobility operations that are
performed, e.g. whether reauthentication is needed on
handover, restrictions on the types of access networks
to use or handover to, etc. DPI control and other policy
objects can be envisioned as well.
3.5 Policy Peering Connections, Security and
Privacy
The policy peering interface must support peering
between many providers while addressing security and
privacy concerns.
Providers may have many PDPs peering internally
or externally. For typical nationwide networks, the
number of security associations required to fully
interconnect all PDPs between providers can be large.
This complexity must be reduced while providing
secure interfaces. This can be done by use of a policy
border element whose role is to peer with partner
networks. This well-defined point of interconnect
reduces the complexity and number of security
associations between partners (and/or clearing houses).
This border element can also provide necessary border
security, topology hiding of the providers deployed
214
PDPs and PEPs, and perform any policy protocol
interworking necessary.
4. Conclusions
We examined the existing service provider policy
architectures across the cellular, wireline and cable
segments. We found them to be architecturally similar
but largely without inter-provider policy support and
access network independence. Initial work has started
addressing that, which is necessary in the future
converged network architecture, which we believe
should incorporate dual IP anchor points and policy
peering. To date, limited work has been done on the
policy peering details. We proposed a number of
design principles and requirements for this starting
with uniformity for different access networks and
support for a common set of policy flows and basic
policy objects. We proposed use of symbolic "names"
and access network information over the interface and
policy delegation and opportunistic policy interactions
for real-time applications, whereas extensibility allows
for new policy objects to be supported. Finally, we
proposed use of policy border elements to aid with
secure and manageable peering interconnects while
supporting service provider privacy.
5. References
[1] 3GPP TS 23.203 V7.5.0 (2007-12), 3rd Generation
Partnership Project; Technical Specification Group Services
and System Aspects; Policy and charging control architecture
(Release 7)
[2] 3GPP2 X.S0013-0012-0 Version 1.0 (Draft Version
0.21.0), 3rd Generation Partnership Project 2 "3GPP2", All-
IP Core Network Multimedia Domain, Service Based Bearer
Control - Stage 2
[3] ETSI ES 282 003 v1.1.1 (2006-06), Telecommunications
and Internet converged Services and Protocols for Advanced
Networking (TISPAN); Resource and Admission Control
Sub-system (RACS)' Functional Architecture
[4] PacketCableTM Technical Report, Multimedia
Architecture Framework, PKT-TR-MM-ARCH-V02, 051221
[5] 3GPP TS 23.401 V8.1.0 (2008-03), 3rd Generation
Partnership Project; Technical Specification Group Services
and System Aspects; GPRS Enhancements for E-UTRAN
Access (Release 8)
[6] 3GPP TS 23.402 V8.1.1 (2008-03), 3rd Generation
Partnership Project; Technical Specification Group Services
and System Aspects; Architecture Enhancements for non-
3GPP Accesses (Release 8)