A Framework for End-to-End Service Differentiation: Network Planes and Parallel Internets

Abstract

This article presents a technology-agnostic and a multi-dimensional (i.e., routing, forwarding, and traffic management dimensions) approach for the management of IP network resources to ensure service differentiation with both intra- and inter-domain scope. This article introduces the network plane (NP) and parallel Internets (PI) concepts for achieving service differentiation. Based on these concepts, a functional architecture together with a business model is presented. In addition, this article describes how the proposed approach can become a promising platform for the IP multimedia subsystem (IMS), with the objective of providing end-to-end QoS-enabled multimedia delivery across multiple providers to replace the flow-based reservation mode known as the VoIP resource reservation framework.

Full text

Page 1

IEEE Communications Magazine • September 2007
134
0163-6804/07/$20.00 © 2007 IEEE
1Few organizations have
enabled DiffServ in their
networks as reflected by
the presentation, “CoS:
Service Provider Perspec-
tive,” given by S. Amante
from Level3 during the
first Inter-Provider QoS
Workshop held at MIT in
October 2004.
2Within this article, we
use the same terminology
for both IMS and
TISPAN.
GENERAL CONTEXT
The emergence of new services such as video
streaming and IP telephony requires IP networks
to provide stringent guarantees — not only in
terms of traditional quality of service (QoS) met-
rics — but also in terms of availability (e.g., five
nines for telephony) and robustness during emer-
gency situations. From the earliest stage of IP
networking, proposals have aimed to capture and
support the requirements of various services,
especially in the realm of forwarding and routing.
In 1994, the Nimrod initiative [1] was launched
within the Internet Engineering Task Force
(IETF) with the goal of providing service-specific
routing in the presence of multiple constraints
imposed by operators and end users. RFC1992,
one of the key documents produced by the Nim-
rod initiative, states that inter-network connectiv-
ity and services should be represented by maps at
multiple levels of abstraction. Nevertheless, this
recommendation was never implemented. Addi-
tionally, QoS forwarding mechanisms such as
IntServ [2] and DiffServ [3] were proposed but
were not widely introduced into operational net-
works.1The exceptions are practices adopted by
operators, such as enforcing shaping and policing
rules and using marking techniques to distinguish
flows only at the access segments of their IP net-
works. This is due to the complexity and the lack
of clear views on the manageability of such mech-
anisms and also to the fact that operators are not
ready to refrain from their practices related to
over-provisioning in favor of sophisticated traffic
engineering techniques.
QOS HURDLES IN 3GPP ARCHITECTURES
Today, voice over IP (VoIP) is one of the major
fields of service innovation, and most service
providers plan (if they have not yet started) to
migrate their public switched telephone network
(PSTN) infrastructures to IP. For this goal, IP
multimedia subsystem (IMS) [4], telecoms, Inter-
net converged services, and protocols for
advanced network [5] (TISPAN) architectures
have been specified by the 3rd Generation Part-
nership Project (3GPP) community to meet the
requirements of service providers.2As far as
QoS requirements are concerned, 3GPP docu-
mentation introduces the notion of QoS class
but does not clearly define this notion. TS 23.107
identifies four QoS classes: conversational class,
streaming class, interactive class, and back-
ground best effort. But TS 22.105 makes use of
four groups of applications in terms of QoS
requirements and points out that there is no strict
one-to-one mapping between these groups and
the classes as defined in TS 23.107. However TS
22.105 uses exactly the same names for its taxon-
ABSTRACT
This article presents a technology-agnostic
and a multi-dimensional (i.e., routing, forward-
ing, and traffic management dimensions)
approach for the management of IP network
resources to ensure service differentiation with
both intra- and inter-domain scope. This article
introduces the network plane (NP) and parallel
Internets (PI) concepts for achieving service dif-
ferentiation. Based on these concepts, a func-
tional architecture together with a business
model is presented. In addition, this article
describes how the proposed approach can
become a promising platform for the IP multi-
media subsystem (IMS), with the objective of
providing end-to-end QoS-enabled multimedia
delivery across multiple providers to replace the
flow-based reservation mode known as the VoIP
resource reservation framework.
QOS CONTROL IN NEXT-GENERATION
MULTIMEDIA NETWORKS
M. Boucadair and P. Lévis, France Telecom
D. Griffin, University College London
N. Wang, M. Howarth, and G. Pavlou, University of Surrey
E. Mykoniati and P. Georgatsos, Algonet
B. Quoitin, Université Catholique de Louvain
J. Rodríguez Sánchez and M. L. García-Osma, Telefónica
A Framework for End-to-End Service
Differentiation: Network Planes and
Parallel Internets

Page 2

IEEE Communications Magazine • September 2007
135
omy as those of TS 23.107. The following key
issue results: is a QoS class defined in terms of
QoS parameter values, or is it defined in terms
of QoS requirements for a group of applica-
tions?
In addition, 3GPP relies on DiffServ to pro-
vide network services with the requested QoS
parameters. Unfortunately, the statement Diff-
Serv is used to provide QoS says very little about
how the network actually can be engineered to
deliver the requested QoS. It is true that it has
never been the intent of QoS standards to pro-
vide information on how the actual network
engineering is to be done. However, a significant
gap does exist between the way network objec-
tives are presented in terms of numerical values
for delay, jitter, and loss and the way DiffServ
per hop behaviors (PHBs) are defined. Creating
best current practices (BCP)-type documents
could provide valuable information to try to nar-
row this gap. The engineering of QoS require-
ments, as well as robustness and availability
requirements, do not appear to be addressed by
3GPP, although the assumption is made that a
QoS-enabled network is available and that QoS
can be requested on a per application-flow basis,
especially during the session establishment,
which is expressed as a session description pro-
tocol (SDP) offer. The success of such a session
is a necessary condition for the reservation of
appropriate resources in both directions of the
call. An example of implementing this mode is
the QoS preconditions as defined in [6]. This
mode has several drawbacks, such as increasing
the connection set up and release times, espe-
cially when crossing multiple telephony domains.
Moreover, 3GPP specifications do not detail
how to check the validity of the QoS require-
ments enclosed in SDP offers, what the interface
between the VoIP signaling protocols and the
QoS enforcement mechanisms is, how to vali-
date the required QoS in both call directions,
how requested QoS will be guaranteed, or how
to ensure coherency of multimedia treatment
when crossing several autonomous systems and
IP telephony domains.
ARTICLE STRUCTURE
To handle the aforementioned challenges, main-
ly QoS and robustness, the A liGhtweight
approach for viable end-to-end IP-based QoS
services (AGAVE) project introduces the con-
cepts of network plane (NP) and parallel Inter-
nets (PI) [7, 8], a novel transport platform that
offers end-to-end service differentiation across
the Internet. The proposed approach does not
require a single Internet-wide architecture or
universal deployment. This article presents these
concepts and associated functions. The article
also describes how IMS can make use of the
AGAVE platform to offer QoS-enabled multi-
media services.
This article is structured as follows. We pre-
sent the adopted business model. We define net-
work plane and parallel Internet concepts and
provide examples of techniques to implement
them. We describe the AGAVE functional archi-
tecture. Finally, we highlight the invoked
AGAVE functional blocks when deploying two
scenarios of NP/PI realization.
REFERENCE BUSINESS MODEL
The emergence of new players, such as Skype
and Yahoo! in the telephony service market, as
well as the trend for traditional telcos to migrate
their services to run over all-IP networks, is
indicative of the separation of service and net-
work planes. This is leading to a distinction
between the service provider (SP) and the IP
network provider (INP) business roles (Fig. 1).
It should be noted that business roles do not
necessarily map one-to-one to distinct business
entities; a business entity may implement more
than one role.
INPs offer IP connectivity to SPs and do not
offer their services directly to end customers.
For expanding the scope of their IP connectivity,
INPs interact with each other on a one-to-one
relationship basis regulated by INP interconnec-
tion agreements (NIAs). An NIA specifies the
QoS and availability performance of the traffic
exchanged between the INPs, the scope and the
profile of the traffic entitled to the agreed per-
formance, and identifiers to capture distinct
flows for providing differentiated treatment.
SPs offer IP-based services to end customers.
SPs deploy the infrastructure required for the
provisioning of the offered services, for example,
VoIP gateways or IP video-servers. To fulfill the
IP connectivity aspects of their services, SPs
establish connectivity provisioning agreements
(CPAs) with underlying INPs. Similarly to NIAs,
CPAs specify the performance, constraints, and
identifiers of the service traffic entering the INP
network from the SP sites. Beyond the connec-
tivity specified therein, the INP offers to the SP
the means to control the connectivity provision-
ing, such as setting policing and routing rules
and receiving feedback reports. The specific pro-
visioning rules and required feedback also are
agreed upon during the CPA negotiation.
To expand the scope of offered services, SPs
interact with each other on the basis of SP inter-
connection agreements (SIAs). The content of
an SIA is service-specific, for example, a VoIP
SIA may include telephony performance metrics,
such as average success rate or simultaneous
calls capacity.
Customers are the target recipients of the
services offered by an SP. Services are offered
on the basis of service level agreements (SLAs),
capturing the terms and conditions for the provi-
sion and use of the services.
I Figure 1. Business model.
CPA
IP network provider
SIA
NIA
SLA
Service provider
Customer
The emergence of
new players, such as
Skype and Yahoo! in
the telephony service
market, as well as
the trend for
traditional telcos to
migrate their services
to run over all-IP
networks, is
indicative of the
separation of service
and network planes.

Page 3

IEEE Communications Magazine • September 2007
136
NETWORK PLANE AND
PARALLEL INTERNETS CONCEPTS
AGAVE introduces network planes to differenti-
ate the delivery behaviors experienced by IP
flows when crossing an IP realm managed by a
single INP. The NP notion is internal to INPs,
and its engineering can be undertaken before or
after the formulation of service requirements as
expressed by SPs. In addition to traditional QoS
metrics, such as delay and packet loss, require-
ments such as availability also are considered. It
is up to the INP to plan/select/(re-)engineer its
NPs to meet these SP requirements. A given NP
can be used to convey service traffic managed by
the same or distinct SPs in an aggregate fashion.
To fulfill the service requirements specified in
the CPA, INPs must engineer corresponding
NPs within their own network. Technically, an
NP can be engineered through the combined
tuning of several processes, which span one or
more of the following dimensions:
• Routing dimension: To support heteroge-
neous service requirements, different paths
can be implemented for individual NPs.
Routing differentiation can be implemented
at several levels, for example:
–Assigning dedicated topologies to maintain
several routing adjacencies towards the des-
tination.
–Assigning dedicated path selection configu-
rations so that multiple path selection con-
figurations (e.g., routing metrics) can be
installed, each dedicated to one specific
NP.3
–Configuring dedicated fast reroute proce-
dures for service resilience purposes, such
as pre-configuring backup paths/topologies
inside high availability NPs.
• Forwarding dimension: At the forwarding
level, an INP can engineer its IP forwarding
mechanisms so as to provide different pack-
et scheduling behaviors by configuring dif-
ferent policies in a common scheduler,
assigning dedicated scheduling resources,
differentiating dropping policies, differenti-
ating failure detection means, and so on.
• Resource management dimension: The treat-
ment experienced by IP packets can be dif-
ferentiated by different shaping and
policing, as well as the degree of traffic
multiplexing, also denoted as the overprovi-
sioning factor.
INPs can select the most appropriate combi-
nation of mechanisms to implement specific NPs
according to the service requirements. Further-
more, an INP takes into account its own opera-
tional objectives such as manageability,
scalability, and resource optimization to provide
cost-efficient NP realization. In the forwarding
dimension, DiffServ is a common platform for
supporting service differentiation. As far as the
routing dimension is concerned, multi-topology
routing mechanisms [9–12] are regarded as suit-
able platforms for supporting service differentia-
tion both within and across NPs. Specifically,
dedicated routing configuration, such as multi-
topology-open shortest path first (OSPF) link
weight setting, multi-protocol-border gateway
protocol (BGP), and QoS-enhanced BGP tweak-
ing, can be performed on top of different rout-
ing topologies, each serving a specific NP.
Additionally, other mechanisms can be applied
for implementing NPs: by using the functionality
of explicit routing and resource reservation of
resource reservation protocol-traffic extension
(RSVP-TE), dedicated label switched paths can
be constructed to support hard QoS guarantees.
Alternatively, QoS overlay routing and IP tun-
neling [13] techniques can be used for realizing
NPs, with less stringent requirements such as
better-than-best-effort services. As far as service
resilience is concerned, IP/multiprotocol label
switching (MPLS) fast rerouting techniques [14]
can be used. A general overview of NP realiza-
tion is described in Fig. 2.
The concept of parallel Internets is introduced
as an innovative way to enable end-to-end ser-
vice differentiation across multiple INPs. Specifi-
cally, PIs are constructed through horizontal
interconnection of NPs across individual INPs.
In doing so, INPs must negotiate and establish
NIAs between each other to bind NPs with simi-
lar service characteristics and apply specific
mechanisms in the control/data plane to enforce
the realization of individual PIs. Each can have a
dedicated inter-domain topology, routing policy,
and forwarding behavior, and so on. A salient
novelty of the proposed approach is that each
instance of PI is not necessarily implemented
with a homogeneous platform across multiple
INPs. This aspect provides high flexibility for
cooperating INPs to make local decisions in
binding their own NPs to the PI. Later, two
examples will be illustrated to show how PIs can
be realized in practice.
AGAVE FUNCTIONAL ARCHITECTURE
OVERVIEW
This section analyzes the interactions between
the business roles of customer, SP, and INP and
describes the functional blocks required to sup-
port these interactions, focusing in particular on
I Figure 2. NP and PI realization.
IP network provider a
Heterogeneous
NP platforms
CPA
NPa 0
NPa 1
NPa k
IP network provider b
NPb 0
NPb 1
NPb j
Service provider
CPA
Service provider
Service
requirements
NIA
CPA
Service provider
Operational objectivesOperational objectives
3In this case, multiple
diverse paths can be
simultaneously main-
tained between individual
ingress/egress pairs to sup-
port different service
requirements from indi-
vidual NPs.

Page 4

IEEE Communications Magazine • September 2007
137
the internal functionality required to plan, engi-
neer, and operate network planes and parallel
Internets within an INP.
Building on the business model discussed pre-
viously and depicted in Fig. 1, each agreement
— CPA, NIA, SIA, and SLA — is supported by
three sets of functional entities corresponding to
the three phases of the contractual relationships
(Fig. 3). Each set is comprised of a pair of corre-
sponding functional blocks in the business enti-
ties operating in the customer and provider roles
pertinent to each agreement. Service advertise-
ment and discovery blocks conduct pre-agree-
ment interactions; agreements are subsequently
negotiated via ordering and order-handling
blocks; and post-agreement, the performance of
the service is monitored by verification and
assurance functions.
This interactions-focused view hides the com-
plexity of internal SP and INP functional blocks
contained in the service/network planning, engi-
neering, and operations meta-blocks. The func-
tional blocks of the INP are further decomposed
as follows.
I Figure 3. AGAVE functional architecture: interactions viewpoint.
SPSP
SP
Interaction
layer
SLA order
handling
Service planning,
engineering
and operations
Service
advertisement
SIA order
handling
SIA
assurance
Service
discovery
SIA ordering
SIA
verification
Network
service
advertisement
CPA
assurance
INPINP
INP
Interaction
layer
Customer
CPA order
handling
Network planning,
engineering
and operations
Network
capabilities
advertisement
NIA order
handling
NIA
assurance
Network
capabilities
advertisement
NIA ordering
NIA
verification
Customer
service
advertisement
SLA
assurance
CPA order
handling
Network
service
advertisement
CPA
assurance

Page 5

IEEE Communications Magazine • September 2007
138
RATIONALE
The rationale behind the decomposition of func-
tionality of the INP is to build a business-process
view of the planning, management, and opera-
tions tasks of the network. The goal is to mirror
the internal organizational structure of a typical
INP, the steps involved in building NPs and PIs
to support CPAs and NIAs with SPs and cus-
tomer INPs, and to model the interactions
between the functional entities.
Three different perspectives of the INP
operational activities are identified. The first is
the commercial view, which focuses on defining
and ultimately selling connectivity services to
SPs and customer INPs. Its main concern is to
maximize the profit of the INP. The second
perspective is concerned with network-wide
optimization of the INP resources; given the
services to be accommodated, their QoS and
availability requirements, and the anticipated
demand. This is where NPs and PIs and their
overall realization objectives are defined. The
third perspective is the one that focuses on
network engineering and the implementation
and configuration details of the NPs/PIs. The
later view is heavily dependent on the techno-
logical aspects of the mechanisms selected for
NP realization.
Although all three business processes are
concerned with INP management and opera-
tions, they each have different perspectives and
concerns as described previously, and they must
communicate with one another to achieve the
network-level configurations that ultimately sup-
port the business objectives of the INP. The
functional architecture facilitates this by defining
clear boundaries between the entities imple-
menting the decision-making processes and spec-
ifying the interactions between them, based on
issues of common concern. The interactions
should be based on information models at an
appropriate level of abstraction but with suffi-
cient detail to enable the delegation of tasks
from the higher to lower levels and the reporting
of state and problems encountered in the reverse
direction. The specification of the information
entities is outside the scope of this article but
can be found in [8].
Figure 4 shows the functional blocks of the
INP. The commercial perspective is handled pri-
marily by the business-based network development
block, supported by NP emulation and network
capabilities discovery/advertisement. Network-wide
optimization concerns are dealt with by NP
design and creation, while the detailed network
engineering and configuration tasks are located
in NP provisioning and maintenance. The func-
tional blocks are described in more detail in the
following paragraphs, and their interactions are
illustrated through two scenarios in the following
section.
FUNCTIONAL BLOCKS DESCRIPTION
Business-based network development sets the tar-
gets for the NP engineering components to fulfill,
specifically, the network services to be supported
and the guidelines for handling the demand for
these services. Target network services are
expressed in terms of QoS and availability per-
I Figure 4. INP functional decomposition.
NP
engineering
NP design
and creation
NP provisioning
and maintenance
NP
mapping
NP
monitoring
NIA
ordering
Resource
availability checking
NP engineering
guidelines
Business based
network development
NP emulation
Network
services/
Capabilities
advertisement
Network
capabilities
discovery
CPA/NIA
assurance
CPA/NIA
order handling
NP engineering
guidelines
Network and interconnection
capabilities
Network configuration
downstream NIAs
CPA/NIA
mappings
Three different
perspectives of the
INP operational
activities are
identified. The first is
the commercial
view; the second is
concerned with
network-wide
optimization of the
INP resources;
the third focuses on
network engineering
and the implementa-
tion and configura-
tion details of the
NPs/PIs.