A Management Architecture for Layer
1VPN Services
Neumar
Malheiros,
Edmundo Madeira,
Institute of Computing
State
University of Campinas (UNICAMP)
PO 6176
-13083-970
-Campinas SP, Brazil
{ncm, edmundo}@ic.unicamp.br
Abstract
A distributed control plane architecture enhances
trans-portnetworks with dynamic andflexible connection
con-trol. As aresult, itallows theprovisioning ofadvanced
con-nectivity services,like Virtual Private Networks (VPNs), on
layer 1 switching networks. Such Layer 1 VPN(LIVPN)
services enablemultiplecustomernetworks to share a
sin-gletransportnetwork. In this
work',
we propose anarchi-tectureforLiVPNmanagement. Our approach has been
to use Policy-Based Management (PBM) toprovide
cus-tomers with some level ofcontrol and management over
their
Li
VPNs. Wealso present a prototype implementedtovalidate theproposedarchitecture and discussimplications
ofpoliciesforLI VPNconfigurationmanagement.
1
Introduction
Traditional transport networks must be enhanced in
or-der to deal with increasing growth in traffic, service
net-work convergence, and the stringent quality of service
re-quirements ofnew advanced applications. Inthis context,
the Automatic Switched Transport Network(ASTN)
archi-tecture, specified bytheInternationalTelecommunications
Union(ITU),has emergedas akey approachto designthe
nextgenerationtransportnetworks. ASTN enhances
trans-portnetworks withacontrolplanearchitecture that enables
dynamic topology andresource discovery, automated
con-nection provisioning, and efficient recovery mechanisms.
Onesuch architecture is the Generalized Multi-Protocol
La-bel Switching (GMPLS) [9], defined within the Internet
Engineering Task Force(IETF). GMPLS extends IP-based
routingandsignaling protocolstobuild a distributed control
planearchitecture which supportsmultiple switching
tech-nologies.
1The authors would liketothank CAPES, CNPq,FAPESPand Ericsson Brazil forsupporting this work.
Fabio Verdi, Mauricio Magalhaes
School of Electrical and Computer
Engineering
State
University of Campinas (UNICAMP)
PO 6101
-13083-970
-Campinas SP, Brazil
{verdi, mauricio}@dca.fee.unicamp.br
I
}
Ll VPN ATopology L1lVPNBTopology
Figure 1. LlVPN service reference model.
The control plane allowstransportnetworksto
dynam-ically provide connectionsto customernetworks. As a
re-sult, it ispossibleforproviderstooffermoreadvanced
con-nectivity services suchasVirtual Private Networks (VPNs)
onlayer 1transportnetworks likeoptical and time division
multiplexing (TDM) networks. TheLayer 1VPN[16]
ser-vice enablesmultiplecustomerservice networksto sharea
single layer1 transportnetwork. It allowscustomers to
es-tablish connections between their sites by dynamically
al-locating resources from the provider network. A primary
requirement is thatcustomersshould begivensomelevel of
managementand controlovertheirLayer1 VPN(L1VPN),
which includesmodifyingthetopology.
TheFig. 1shows the basic elements oftheL1VPN
refer-encemodel[16]and alsopossible topologiesoftwoL1VPN
services (A and B). A Customer Edge (CE) is a device
within thecustomernetwork that receives LI VPN services
from theprovider network. A ProviderEdge (PE) is a
de-vice within the provider to which at least one CE is
con-nected. Itprovides LIVPN service functionalities to CEs
throughthe L1VPN service interface. A Provider(P)node
isadevice within theprovidernetwork that isnotconnected
to anyCE, butonlyto PEand P devices. Control and data
connectivity is restricted to LIVPNmembership which is
thesetof CEs under control of thesamecustomer. LIVPN
is a port-based provider provisioned VPN. The Customer Port Identifier (CPI) and the Provider Port Identifier (PPI)
arethe logical endpoints of the link between CE and PE
re-spectively. A VPN member is identified by a CPI-PPI pair. With the advances in layer 1 networks and the
devel-opmentof intelligent IP-based control plane architectures,
Layer 1 VPN defines an interface by which providers can offer cost effective, flexible and on demand bandwidth ser-vices to multiple customers. Recently, standardization or-ganizations have worked on LIVPN services. The ITU has specified generic service requirements and service architec-tural elements [6], as well as functions and architectures to
supportLIVPN[7]. Moreover,theIETFhas created a
spe-cific working group which is aimed at specifying how to
provide LIVPN services over GMPLS enabled networks.
The first steps concern service requirements and
frame-work [13], and theanalysis of applying GMPLS protocols
and mechanisms in the support of LlVPN services [14].
Wehave beeninvestigating how to provide LIVPN
ser-vices on transport networks enhanced with a distributed
controlplane. Inthis paper we are concerned withL1VPN
configuration management issues. We propose an
archi-tecture for LIVPN service management. The main
prob-lem here is how a single provider network supports
mul-tiple LIVPN services, whileprovidingcustomers with
in-dependentcontrol and management over their LIVPN. In
order to meet suchrequirementthe architecture is built on
thePolicy-BasedManagement(PBM) approach [20]. The
main focus of interest is to discuss LIVPN policy classes
and how theproposedarchitecture supportsPBMinstead of
defining specific policiesforL1VPNmanagement.
Further-more,the design of the architecture makes the assumption
that the provider network controlplane supports dynamic
connection setup andtopologyinformationdiscovery.
First, we present related work. InSection 3, we describe
how theIETFPolicy Framework has been used in the
con-text of LIVPN management and define major classes of
policies for LIVPN service management. Then, we
pro-pose an architecture for LIVPN service management in
Section 4. We describe the architecture functional model
and usage scenarios for different LIVPN service models.
Then we discuss the prototypeimplementationinSection 5
and evaluate the implications ofusing policies in LIVPN
managementinSection6. Finally,weconclude andpresent
future work in Section7.
2 Related work
Research work havemainlyfocused on controlplane
is-sues intheprovisioning of LIVPN services. Indeed, most
work have investigatedhowtoprovide
L1VPN
servicesonGMPLSenabled transport networks and evaluated the
nec-essaryextensions in the controlplane protocols inorderto
supportL1VPN. The work presented in [12] proposes the so
called Generalized VPNs (GVPNs) services. Such services
usethe Border Gateway Protocol (BGP) as a VPN
member-ship auto-discovery mechanism and the GMPLS signaling and routing mechanisms to establish VPN connections.
The work presented in [17] compares types of LIVPN architectures namely, centralized, distributed and hybrid ar-chitectures. It focus on the management-based service
in-terface as a suitable approach for initial steps in LIVPN
servicedeployment. In this context, it evaluates centralized
andhybrid architectures and argues that the last achieves
more scalable, resilient and fast operations. Then it
pro-poses a hybrid architecture that combines centralized and
distributed functions to support theL1VPN service. Inthat
case, VPN specific functions are centralized and common
signaling and routing functions are distributed.
A discussion on existing GMPLS mechanisms for
real-izingL1VPNfunctionalities is presented in [15]. That work
describes management and control-based LIVPN service models taking into consideration the service interface by
which the customer accessesLIVPNfunctionality.
Further-more, it explains how LIVPN services can be performed
by GMPLS in terms ofaddressing, membership
discov-eryandsignalingaspects. Finally, it discusses open issues
in LIVPNprovisioning. Such ones mainly include
man-agementfunctionalities like per-VPN resource management
and VPNconfigurationmanagement.
Differently from aforementioned work, our contribution
focus onconfigurationmanagementofL1 VPN services.
In-stead of compete withthem, the presentproposal
comple-mentthat work in order todeploy
L1VPN
services in afullyfunctional way.
3
Policy
framework
Wehave decidedon apolicy-based approachinorderto
achieve thatcustomershavesomelevel of control and
man-agementovertheirL1VPNservice. Indeed, anL1VPN
re-quirementis thatcustomers mustbe abletospecify policies
tocontrol theirLIVPNoperation. Therefore, Policy-Based
Management(PBM)emergesas asuitableapproachto meet
theserequirements.
PBMhas beenwidelyused to address thecomplexityof
network and service management. Morespecifically, some
research work haveproposed policy-basedarchitectures to
manage VPN services onIP networks. PBMprovides
dy-namic network-wide management. InaPolicy Framework,
anadministrator defines policiestobe enforced within the
network in order to control the behavior of the system as a
whole. Policies are a setof rules that define how network
resources and services can be used. Each rule consists of
conditions and actions. If the conditionsareevaluated true,
3.2 Policy classes
We have adapted the IETF policy framework [20]
tak-ing intoaccountLlVPNmanagement aspects. The adapted
framework is presented in Fig. 2. Inthis framework, the
provider networkoperatorshould firstly specify policiesto
manage the LIVPN services basedon administrative and
business goals. This is represented by the Modeling
pro-cess. Policies aremodeledinaccordance with theprovider
network infrastructure, the LlVPN service framework
sup-ported by the provider, and customer requirements.
Fur-thermore, defined policies should be incompliance with a
policy information modelto assure interoperability. There
isaneed forapolicymanagementtool that should provide
policy modeling, including syntax check, conflict
resolu-tion, andso on. The definedpolicies forLI VPNcontrol and
managementarerepresented in the figureasService
Config-urationPolicies.
A Policy Decision Point (PDP) should evaluate the
ser-viceconfiguration policiesinordertodecide which actions
mustbe enforced. Decisionsmaybe requestedortriggered
by theoccurrenceofspecificevents. Such decisions should
consider the current network conditions. PDP also may
translateconfiguration policiestoconfiguration information
specifictothe network nodes basedonspecific capabilities
of each node. Finally,aPolicy Enforcement Point (PEP) is
responsible for performing configuration changes according
toactionssentby thePDP.Theyarealsoresponsible for the
reportof devicecapabilities and networkstatus tothePDP.
TheDecisionprocessperformed by thePDPislogically
centralized. The Enforcement process is distributed over
the networkby implementing thePEPfunctionality onthe
managed entities. However, DecisionandEnforcement
pro-cesses may be implemented in a centralizedmanagement
system.
Figure 2. Policy-based framework for Layer 1
VPN management.
Wehave defined three major categories of LlVPN
poli-cies, namely, configuration, admissioncontrol, and routing
policies. Configuration Policies are used to define
configu-ration parameters which controlLlVPN service operation.
Main serviceoperational aspects to which thatpoliciesmay
be applied are described as follows:
* There are two LlVPN resource allocation models.
In the dedicated model, provider network resources
are exclusively reserved for a specific LlVPN and
they can not be allocated by another LlVPN. In the
shared model, resources can be allocated by
differ-entLlVPNs in a time-sharing manner. Configuration
policies can be used to configure resource allocation
managementand control the specificationof allocation
models for the severalLlVPNcustomers.
* Configuration policiescanalso beappliedinfault
han-dling [3]. The providernetwork may support several restoration and protection schemes to recover from
link and node failures. Such policies may
deter-mine which recovery scheme should be used for each
LlVPNoreachLlVPNmember.
* The provider network may support differentiated
classes of LIVPN services. Provider network
opera-tors canspecify configuration policiestodetermine the
class of service for each
L1VPN.
* Configuration policies can also define routing
algo-rithm parameters, since eachLI VPN service may use
different path computation algorithms, link weights,
and otherroutingattributes in connectionrouting.
Admission Control Policies are used in the LIVPN con-nection admission control which also considers
member-ship information. Beyondcommon admission control
as-pects,likeresourceavailability,thosepoliciesallowto
spec-ify additional constraints on admission control asfollowing:
* Such policies can enhance membership control with
additionalconnectivityrestrictions. Theyallowto
de-fine restrictions within an LIVPNby definingwhich
members can establish connections to each other. * Admission control policies can also be usedto limit
resources per LIVPN service, as well asto limit the
number of connections perLIVPNserviceormember.
* Inthe admission of customer connection requests,
pre-provisionedconnections in theprovidernetwork may
be used in the establishment of the LIVPN
connec-tions. Admission controlpolicies canbe usedto
op-timize the selection of the pre-provisionedcore
con-nection. Inaprevious work,wehave describedan
ar-chitecture forpolicy-based grooming responsible for
managing the installation and aggregation of customer traffic flows within core optical connections [19]. Routing Policies aim to control path computation for LIVPN connections. The major applications of these poli-cies are described as follows:
* Routing policies can be applied in support of
Constraint-BasedRouting (CBR). CBR is mainly used
in traffic engineering and fast connection reroute
mechanisms. In this case, path computation is subject to resourceand administrative constraints like route
re-strictions [1]. Those policies can be used to specify
such constraints onLIVPNconnectionrouting.
* Routing policies can also be used in resource
manage-ment as a way to supportdedicated and shared
alloca-tion models whenpath computationis centralized.
* When there are several suitable routes for a
connec-tion,
routing policiescanbe used tooptimizeroute se-lection, for instance, in terms of resource utilization.4
Proposed architecture
In this section, we propose a management architecture
for LIVPN services. Firstly, we describe the architecture
functionalities and how its modules interact with each other.
Then we discussoperational aspects ofthe architecture with
respect todifferent LlVPN service models.
4.1
Functional model
The architecturedesign is based on the assumption that
the transport network is enhanced with a control plane
which provides dynamic connection setup and network
topology discovery. Theproposedarchitecture ispresented
inFig. 3. It defines a user interface represented by the
Ac-cessInterfacemodule. Throughthis interface thecustomer ortheprovidernetwork operatorcanrequest LlVPN con-nections, define policies or receive performance
informa-tion about therespectiveL1VPNservice. On the otherhand,
the Control PlaneInterfacemodule is the interface between
the management system and the control plane. The core
modules are isolatedbythe interfaces. This designis aimed
atachieving flexibilityandmaking interoperabilityeasier.
The AccessInterfacemodule isresponsible for
process-ingthe requests from customers andprovidernetwork
oper-ators,aswellasfor authentication and authorization
proce-dures. Accordingtothe requests it invokesoneof the three
modules described as follows. The Service Monitoris
re-sponsible forproviding performanceand fault information
about LIVPN services for theircustomers. Some of those
informationcan be obtained from the control plane. The
Customer /
Provider NetworkOperator
Network Control Plane
Figure 3. LlVPN managementarchitecture.
ServiceProvider is the main module. It isresponsible for
the configuration andaccounting management of LIVPN
services. Itperforms admission control on customer
con-nection requests considering policies andmembership
in-formation. It is also responsible for connection control
by requestingthe controlplaneto create, modify ordelete
layer 1 connections according to the desired LlVPN
topol-ogy. The PolicyManager allows customers andprovider
network operators to add, edit, remove, and activate
poli-cies. It isresponsibleformanaging policiesandprocessing
decision requestsfrom the other modules.
The Membership Manager is responsible for managing
LIVPNmembership information. It includes functions for
addingorremovingLI VPNmembers andverifying
mem-bership. The Resource Manager is responsible for
man-aging providernetworkresources. It shouldprovide
sup-port for shared and dedicatedresource allocation models.
The Routing Controller is responsible for computing the
routefor LlVPN connection requestsby making use of
re-sourceavailabilityinformation from theResourceManager
andcollecting topologyinformation from therouting
mech-anism of the controlplane.
Someofthe functionalitiesare not VPNspecificand may
have already been implemented on the provider network.
However,such functionalities may need extensions in order
to support LIVPNservices. Furthermore,LIVPNpolicies
may bespecified by providernetwork operatorsaccording
to aService Level Agreement(SLA)andcustomer
require-ments. Also, the customers should be allowed to specify
high-level policies to configure and control their LIVPN
services. As a result, separate LIVPN control and
man-agementisprovidedto customers.
The operation of the Service Provider, Routing
Con-troller, andResourceManagermodules is subjectedtothe
rules definedbythepoliciesfrom thePolicyManager. The
Fig.4illustrates how the architecture modules interact in the
provisioning ofLIVPNconnections. The AccessInterface
Ser-|SPI |MM |PM| RC|0 RM| |CPI| (1):~~~~~~~~~~~~~~~4 _ l l~~~~~~~~(5 i~~~~~~~~~~~~~~5 retur :~~~~~~~~~~~~~~~~~_6return : : (1return trn : I I (8): (7)return:|
Figure4. Connection setup.
viceProvider module to establish the connection (1). This
module retrieves configuration information from the Policy
Manager (2). Such information is used to configure
con-nection setup. The Service provider also requests policy
decisions for connection admission control. In addition, it
communicates with theMembership Manager in order to
verifywhether theendpoints specifiedinthe connection
re-quest aremembers of the same VPN(3). Then, the Service
provider requests the Routing Controller to compute a route
for therequested connection (4). The Routing Controller
requests the Policy Manager for routing policy decisions
which will controlpath computation (5). This computation
requires resource availability information which is obtained from the the Resource Manager (6). Since the Service Provider has received a route for the connection, it requests
connection setup to the network controlplane throughthe
Control PlaneInterface (7). The connection setup bythe
controlplane signaling isrepresented bystep (8).
Finally,
the customer is reported on the connection establishment
throughthe AccessInterface.
4.2
Usage scenarios
There are twoL1VPN service models based on the
ser-vice interface. In the management-based service model,
LIVPN service is provided on a management interface
bywhich the customermanagement system communicates
with the providermanagement system in order to control
and manage therespective
L1VPN.
Inthis case, there isnoexchangeof controlplanemessagesbetweencustomerand
provider. Inthe control-basedmodel, LIVPNservice
pro-visioningis achievedthroughcontrolplanecommunication
between CE and PE.Inthis casethereare twoapproaches.
First, the service interface is based only on control plane signaling between CE and PE devices. Second, routing
mechanisms can be supported on the service interface in
Management Based - - gLIVPNManagemntSystem
Serviceinterface '
Distributed Control Plane CustomerNetwork
ManagementSystem
CE _ m
SiteAl 1 r C D
Figure 5. Management-based LlVPN service.
addition tosignalingmechanisms. Inthe last case, there is
exchangeofroutinginformation between CE and PE. Thus
CEmayobtainprovidernetworktopology and remote site
reachability information.
Here we describe usage scenarios in terms of the two
LIVPN service models take into account the proposed
ar-chitecture functionalities. Inboth scenarios we consider a
GMPLSenabledprovidernetwork. Inthis context,dynamic
connection setup can beperformedby GMPLS RSVP-TE
(Resource Reservation Protocol-Traffic Engineering) sig-naling mechanism [2] and automatic topology discovery
canbe achievedthrough GMPLS OSPF-TE (Open
Short-estPath First-TrafficEngineering) routingmechanism [8].
The Fig. 5 shows LIVPN service deployment scenario
consideringthe management-basedservice model. Inthis
case,the serviceprovisioningis based on ahybrid
architec-turewhich combines distributed and centralized functions.
The control plane functions are distributed since they are
performed bythe GMPLS architecture. Distributed
connec-tion setup signaling andtopology discoverycontribute for
scalability and fast connection recovery mechanisms. The
managementfunctionalities are centralized and may be
im-plemented in anL1VPNmanagement system orintegrated
into theproviderNetwork Management System(NMS).
Inorder to establish anLIVPNconnection, the customer
sendsaconnection requesttotheL1VPNmanagement
sys-tem. Afterprocessingthe request, the management system
invokes the GMPLS controlplane to setup a connection
acrosstheprovidernetworkonbehalfofthecustomer. Then
the CE nodes can establishrouting adjacencies oversuch
connection, as in an overlay scenario. GMPLS signaling
mechanisms are usedto establish the connection between
PE devices. Such connection initiated by a management
systemis namedasoft permanent connection(SPC).After
a routeiscomputedfor the connection request, theL1VPN
management system requeststhe SPC to theingressPE.
In the control-based service model scenario, several of
theproposedarchitecture functionalitiesarealso distributed
beyond the control plane ones. This usage scenario
im-proves scalability and robustness in service provisioning.
proto-Figure 6. Control-based LlVPN service.
colextensions and ever new solutions are needed. Namely,
membership information management, admission and
con-nection control, route computation and resource
manage-mentfunctions, before implemented in thecentralized
sys-tem, are nowperformed on the PE device. Some functions
like policy management remain centralized. Also, a
central-ized management system may be used toprovide customer
with servicemonitoring functions asreportingLIVPN
ser-viceperformance and fault information.
Furthermore, in this LIVPN deployment scenario, PE
devices need to implement PEP functionality in order to
supportpolicy-based management, as illustrated inFig. 6.
PE devices communicate with a Policy Server to request
policy decisions. This server supports policy modeling
andperforms PDPfunctionality. Itis logicallycentralized
and can beimplementedin acentralized management
sys-tem. Inthis context, LIVPN control and managementare
achievedthrough policies since operations on PE devices
aresubjecttopolicyrules specifiedinthepolicyserver. In
order to support communication between PEPs onPE
de-vices and a policy server there is a need for a policy
in-formation exchange protocol like COPS (Common Open
Policy Service) [5]. This is a query and responseprotocol
which allows on demandpolicydecision requests.
Further-more, such protocol could be used to provision PE devices
withL1VPNserviceconfigurationinformation[4].
5
Prototype
implementation
We have implemented and tested an LIVPN
manage-mentprototype system inorder to validate theproposed
ar-chitecture. Theimplementationconsiders the
management-based service model and LIVPN configuration policies.
The main modules of the architecture were developed
us-ing the Java Remote Method Invocation (JavaRMI)
tech-nology. The Service Provider module includes two
sub-modules which are responsible for connection control and
admission control. Route computation forrequested
con-nections are performed bythe Routing Controller. It
im-plementstheDijkstra's Shortest Pathalgorithm. TheFig. 7
Signaling MechanismI
Si
SimulatedOpticalNetworlK
I___________________________-Figure 7. Implemented prototype.
depicts the structure of the prototype. Currently, the
Ser-vice Monitor isbeing implementedand it is not showed in
thefigure.Also thepoliciesarespecifiedin astatic way(in compilation time)within the Service Provider which is then responsible for the policy management and enforcement.
Inorder to provide a high level offlexibility to access the
management system, the Access Interface module was
im-plemented as a Web Service. The main objective ofthe Web
Services technology is to provide interoperability and
au-tomated communication between distributed and
heteroge-neousapplications using XML standards andInternet
proto-cols. The web interface is illustrated inFig. 8which shows
the definition of aconfiguration policy. Inthis case, the
con-figuration policy specifies a resourceallocation model and apath computationscheme for the LIVPN service whose identifier is "100". If the dedicated model is chosen, then
it ispossible todefine how manywavelengths mustbe
re-served in each link.Twopath computationschemesare
pos-sible: find the shortestpathintermsof number ofhops or
thepathwithmostavailable bandwidth intermsof number
of availablewavelengths.
Wehave alsodevelopedasimulation environment where
L1VPN
services areprovidedover anopticaltransportnet-work. Inthisenvironment,
L1VPN
servicecustomerscon-currentlysend connection requeststothe LIVPN
manage-mentsystem. Then the system attempts to establish the
re-quested connections overthe opticalnetwork. Therefore,
the LI VPNconnections are optical connectionsthrough a
single provider network. An optical connection is
estab-lished by allocating an available wavelength in each link
from the source to the destination node. The connection
establishment is donebya simplifieddistributedsignaling
mechanism. Such mechanism isperformed bycontrolplane
agents which are implemented in each node. It includes
messagestorequestand confirmwavelengthallocation.
LlVPNManagement System UyFt-5rMr ConurationPolcy
MembeveShip Poikies
Adhssirii ResourceAIlon Mod Atin
LAI
IFdloEtjia,A fwdl- Shared
Dedicated (esece
COMM PA "mWi1utatiehowsArflom P
hhCbwrpuailnrwhae;- M W,gll..
w|kgths anr-hMRink)
Figure 8. Web-based managementinterface.
|PlcCndition |Poiyction|
|PolicyVariable oiyValue |CoSAction AcceptAction| llngressMemberlDVaralel VNervicelDVariable Reoeycinl eetci
|EgressMemberlDVariable Rout gC
-II IAIoct-oModeIAct-Io
NumberConnVariable AllocationModeAction] Figure 9. LlVPN policy model.
connectionsetup by sending arequest tothecontrolplane
agentintheingress node. Then the controlagents
commu-nicate with each otherto setuptheoptical connections.
In addition,wehave investigated theuse ofXML
tech-nologies for policy representation mainly due tothe
flexi-bility, interoperabilityandavailability ofsyntaxchecktools.
ToillustrateXMLpoliciesweconsider thesimplified policy
modelpresentedinFig. 9. This model is basedonthe
Pol-icy Core Information Model (PCIM) defined within IETF
[11, 10]. Itwas specified according to the policy classes
defined in Section 3 andcovers configuration policies and
admission controlpoliciesrelatedto connectionrestriction and control of number of connections. In thiscontext,
vari-ables are associated with values to define conditions and
conditionsareassociated with actionstodefinepolicyrules.
Thespecified policy actionscanbe usedtorejectoraccept
connections andtodefine VPNconfigurationparametersas
those discussed in thedescriptionofconfiguration policies.
An XML policy example is illustrated inFig. 10
con-sideringthepolicymodel. Suchpolicy specifies a
configu-ration andan admission control rule. Both rulesshould be
appliedto"LIVPN serviceA" as expressedinthe
respec-tive conditions (lines 7-8, and lines 18-19). The first rule
defines actions to configure theresource allocation model
1 <?xml version='1.0'?>
2 <!DOCTYPE Policy SYSTEM -llvpnPolicy.dtd-> 3<POliCy id= 001''>
4 <PolicySet>
5 <PolicyRule type=- configuration ">
6 <PolicyCondition > 7 <VPNServiceIDVariable/> 8 <PolicyValue>vpnA</PolicyValue > 9 </PolicyCondition > 10 <PolicyAction> 11 <ResourceAllocationAction allocationModel dedicated''/>
12 <CoSAction model=' 'basic' ' class =''gold
II/>
13 <RecoveryAction recoveryScheme=' protection:1+1'' />
14 </PolicyAction>
15 </PolicyRule>
16 <PolicyRule type=' 'admissionControl ">
17 <PolicyCondition >
18 <VPNServiceIDVariable/>
19 <PolicyValue >vpnA</PolicyValue >
20 <IngressMemberlDVariable />
21 <PolicyValue >CPI1-PPI1</PolicyValue>
22 <EgressMemberlDVariable/>
23 <PolicyValue >CPI2-PPI2</PolicyValue>
24 </PolicyCondition > 25 <PolicyAction> 26 <RejectAction/> 27 </PolicyAction> 28 </PolicyRule> 29 </PolicySet> 30 </Policy>
Figure 10. XML policy example.
as dedicated,the class ofservice, and the recovery scheme (lines 11 to 13). The second one is an example of
connec-tivityrestriction. Itspecifiesthat connections from member
CPI1-PPI1 tomemberCPI2-PPI2,as expressedinthe
con-dition(lines20to23),mustberejected (line 26).
6 Evaluation
The simplification and automation of the service
man-agement process are the main advantages of the
policy-based approach [20]. Simplification is achievedthrough
twokeyfactors. First,allconfigurationis defined ina cen-tralized way instead ofconfiguringeach device itself. Inthis
way, when a new CEdevice is connectedto aPE, the PE
can be provisioned withrespective LIVPN configuration through the policy protocol. Second, high-level
abstrac-tions simplify policy definition. Administrators can
spec-ifyservice-levelpolicies taking into consideration LIVPN
service aspects rather thentechnology specificdetails.
Au-tomation is achieved since administrators do not need to
configurethe service themselves. They onlystate system-wide policies which shouldguide the entities involved in theprovisioningofLlVPNservices.
Wehaveperformedsimulations in orderto evaluate the
effects andimplicationsofconfiguration policies. Fromthe
con-0.18 0.16 0.14 0.12 O ProviderEdge (PE) device
Q Provider(P)device
Figure 11. Simulated topology.
nection blocking rate. A connection is blocked if there are
notenough available wavelengths. From the perspective of
the service providerwe measurethe network resource
uti-lization rate, where resource means wavelengths.
Inall simulatedscenarios, the connection request arrival
rate is based on a Poisson distribution where the average
number of connections per second is 100 or a fraction of 100 whenexplicitly mentioned (e.g. "Arrival Rate = 0.4"
means the average is 40). The connection holding time
and the interval betweentwoconnection requestsarebased
on anexponentialdistribution. The topology of the
simu-latedprovider optical network is presented in Fig. 11 which
shows the PE and P devices. For each LIVPN customer
there isone CEconnectedtoeach PE. The sourceand
des-tination nodes of the connections arerandomlyselected
ac-cordingto auniform distribution. The simulations are
re-peated 100times and thepresentedresultsarethe average.
A customer should be able to specify policies to
man-agetheirLIVPNservices. Howeverprovidersmust
super-vise that task sincea customerpolicyinfluences the overall
provider network performance and may affect another
cus-tomer service. Therefore LIVPN service provisioning is
managed bya combination ofproviderand customer
poli-cies. Furthermore, providerscan usepoliciestodefine
dif-ferentiated classes of LIVPN services. Thefollowing
sce-narios illustrate these aspects.
In a first scenario we consider four LIVPN services
(LIVPN 0-3). Each customer requests a total of 2500
con-nections and eachopticallinkhas 32wavelengths.
Config-urations policies define high priority and lowpriority
ser-vices: (1) Highpriorityservice: Resourceallocation model
is dedicated and 10wavelengths oneach link are reserved
for the LIVPN service. Route computation involves only
dedicatedresources andmustselect thepathwith the
max-imum availableresource. This is achievedby considering
theweightofalinkis
1,
wherewis the number ofavailablewavelengths. (2)Lowpriorityservice: Resourceallocation
model is shared. Pathcomputationinvolves sharedprovider
networkresources andmustfind the shortestpathinterms
of the number ofhops.
The Fig. 12 shows the blockingrate of the LIVPN 0
and the averageblockingrateof the other
L1VPNs
when allLIVPNs are definedas lowpriority services. TheFig. 13
LlVPN 0 LlVPNs 1-3 0.08 0.06 0.04 0.02 0 500 1000 1500 2000 2500
Number ofrequested connections
Figure 12. Blocking rate.
0.18 LlVPN 0 016 LlVPNs 1-3 0.146 -~ 0.14 0.12 0.1 0.08 0.06 0.04 0.02 0 0 500 1000 1500 2000
Number ofrequested connections
2500
Figure 13. Differentiated blocking rate.
showsnew rateswhen LIVPN 0 is assignedashigh
prior-ityand the other LIVPNs remain as lowpriority services.
The results demonstrate that the serviceprovidermay
de-fineconfiguration policies to differentiateLIVPNservices.
Moreover, thechangesonblockingrateshow howpolicies
foraservicecanaffect otherones.
A similar scenario illustrates how policies can be used
inreaction to specific network conditions. Fig. 14 shows
the improvement on LIVPN 0 blocking rate when a
pol-icyis activated in order toassign
L1VPN
0 ashigh priority.Inthis case, before such policy is activated, wavelengths
ineach link are dedicated for theL1VPN 0. Thepolicyis
activated after the LIVPN 0 hadrequestedhalf of the
to-tal number of connections. Moreelaborated conditionsare
possible, forinstance, suchpoliciescanbe activated in the
occurrenceofspecificevents orwhenaperformance
degra-dation threshold is reached. This way,L1VPNmanagement
automation isimproved.
Inprevious scenarios, policy configurationdefined
dedi-cated modeltohigh priority L1VPNservices in orderto
im-prove serviceblockingrate. However, dedicatedresources
may degradethe overallperformance. This is illustrated in
Fig. 15.Here,it iscomparedthe averageblockingrateof all
LIVPN services whentheyuse thesame allocation model
co
0.2 0.18 0.16 otherLlVPNs LlVPN 0 0.14 0.12 -0.1 0°08 -0.06 -0.04 -0.02 -01 0 500 1000 1500 2000 2500
Number ofrequested connections
1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 20 40 Shared Dedicated 60 80 100 120 Time (s)
Figure14. Policyactivation effect. 1 Shared 0.9 Dedicated 0.8 0.7 0.6 _1 I_ 0.4 0.3 0.2 0.1 0L 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Arrival Rate
Figure 16. Arrival rate= 0.4.
7--- --- rS hared r 0.9 Dedicated 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 0 5 10 15 20 25 30 35 40 45 Time(s)
Figure 15. Blocking rate: sharedxdedicated.
atdifferent connectionrequestarrivalrates. The blocking
rate is measured with dedicated allocation model for all
LIVPNs and thenthe blockingrate is measured again but
with shared allocation model for all LIVPNs. The graph
shows the average blocking rate of all LIVPNs in both
cases. When allLIVPNsusethededicated model the
net-work resources (wavelengths) are equally distributed and
reservedto eachone. The results show the sharedresource
allocation modeloutperforms the dedicated model.
Moreover, the customer configuration policies can
im-pactontheoverallprovider network performance. We
eval-uated the effectontheprovider networkresourceutilization
at different connectionrequest arrival rates. Here, the re-sourceutilizationrate is measured interms of the number
of allocatedwavelengths. Foreacharrivalrate,the
utiliza-tionrate is firstmeasured withdedicated allocationmodel
for all L1VPNsand then with shared allocation model for
all L1VPNs. Asshown inFig. 16 and17, the results
demon-strate that the dedicated model is less efficient than the
shared model. With low arrivalrate there isno significant
difference,asshown inFig. 16.However, when thenetwork
loadincreases, the shared model outperforms the dedicated
model,as shown inFig. 17.
Figure 17.Arrival rate= 1.0.
Theresults show how policiesmaybe usedto offer
dif-ferentiatedclasses for LIVPN services andto control
ser-vice behaviorandperformance. Providersmustanalyzeand
elaborateonwhichconfiguration policiescustomersshould
be allowedto specify, since the same policymay benefit
a customerwhile degrading the overall provider network
performance. Moreover,apolicy that improves the
perfor-mance ofanLIVPNservicemaydegrade the performance
ofanotherservice, dependingonthe network conditionsand
theconfigurationof other services. Forinstance,inthecase
of theresource allocation configuration policy, the results
showedadvantagesanddisadvantagesatdifferent
perspec-tives. In the scenario presentedinFig. 13 and Fig. 14, the
dedicatedmodelwassuccessfully usedtoimprove the
per-formance of theLIVPN0 by decreasing its blockingrate.
Nevertheless,theaverageblockingrateofthe otherservices
wasincreased. Also,we sawthatthe dedicatedresource
al-location model provedto be less efficient with respect to
theblockingratewhen all serviceswereconfiguredtouse
the same model, as shown in Fig. 15. However, in
dedi-catedmodel thepathcomputation algorithm canoptimize
resource allocation since resources are notshared and
de-tailed availabilityinformation is possible. The work
pre-sented in [18] proposespath computation algorithms and
140 _o .N U() ao u. co _o .N U1) ao u. co
describe a multilayer scenario in which dedicated model outperforms shared model in terms of blocking rate. The authors argue that the efficiency of optimized path
compu-tation algorithms in dedicated modelcan overcomethe
dis-advantage ofnotsharing provider networkresources.
In summary,the simulatedscenarios demonstrate that by
supporting policy-based management the proposed
archi-tecture is a suitable and flexible approach to provide
sep-arateLIVPNmanagement for customers. However, a
chal-lenge issue is how to estimate theoverall effect of policies.
It is a difficult task to evaluate howconfiguration policies
for oneLIVPNservice can affect the behavior of others and
theprovider network. The providers must develop
mech-anisms and tools to simulate and evaluate policy effects.
Also there can be conflict between policies of customers
andprovider network administrators. Priority mechanisms
canbe used to resolvepolicy conflicts andregulatethe level
ofpolicy control that is given tocustomers.
7
Conclusion
Wehave described apolicy-based framework forLlVPN
managementand proposed major classes for LIVPN
poli-cies. Moreover, we haveproposedapolicy-basedLIVPN
managementarchitecture. A prototype system has been
im-plemented in order to validate this architecture. The
sim-ulations have demonstrated the feasibility of the
architec-tureand the effects andimplications ofconfiguration
poli-ciesconsideringdifferentpoints of view. Wehave
demon-strated howPolicy-BasedManagement canbe used in the
configurationmanagementofLIVPNservices. Indeed,the
proposed management architecture is a suitable approach
to enablemultiple customers tomanage their LIVPN
ser-vices. However, it isnoteasytoserviceprovidersthe task
ofsupervisingandisolatingthecustomercontrol.
Future work will include to investigate how to provide
Layer 1VPNservices overmultiplerouting domains,
eval-uatetheimpactof other LlVPNpoliciesovertheprovider network, and investigate how LIVPN resource allocation
canbenefit frompolicy-basedmanagement. Other
interest-ingwork is toimplementaprototypeof theproposed
archi-tectureconsideringthe control-based LIVPNservice model
and evaluatescalabilityissues.
References
[1] A. Banerjee, J. Drake, J. Lang, B. Turner, K. Kompella,
and Y Rekhter. GeneralizedMultiprotocolLabelSwitching:
An Overview ofRoutingand Management Enhancements,
2001.
[2] L. Berger. GMPLS Signaling Resource ReserVation Protocol-TrafficEngineering(RSVP-TE)Extensions. IETF RFC3473,January 2003.
[3] C. Carvalho, E. Madeira, F. Verdi, and M. Magalhaes.
Policy-Based Fault Management for Integrating IP over Op-tical Networks. In 5th IEEE International Workshop on IP Operations and Management, IPOM 2005, volume 3751 of Lecture Notes inComputer Science, pages 88-97. 2005. [4] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie,
F. Reichmeyer, J. Seligson, A. Smith, and R. Yavatkar. COPS Usage for Policy Provisioning (COPS-PR). IETF RFC 3084,March 2001.
[5] D.Durham, R. Cohen, J. Boyle, S. Herzog, R. Rajan, and A. Sastry. The COPS (Common Open Policy Service) Pro-tocol. IETF RFC 2748, January 2000.
[6] ITU. Layer 1 Virtual Private Networkgeneric requirements
and architecture elements. ITU-T Recommendation Y 1312,
September2003.
[7] ITU. Layer 1 Virtual Private Network service and network architectures. ITU-T Recommendation Y 1313,July2004. [8] K.Kompellaand Y Rekhter. OSPF Extensions in Support
of GMPLS. IETF RFC 4203, October 2005.
[9] E.Mannie. Generalized Multi-Protocol LabelSwitching Ar-chitecture. IETF RFC3945,October 2004.
[10] B. Moore. PolicyCoreInformation Model(PCIM) Exten-sions. IETF RFC3460,January 2003.
[11] B.Moore, E.Ellesson,J. Strassner,and A. Westerinen.
Pol-icyCoreInformation Model-Version 1 Specification.IETF
RFC3060,February2001.
[12] H. Ould-Brahim. GVPN Services: Generalized VPN Ser-vicesusingBGPand GMPLS Toolkit. IETFInternet-Draft,
work in progress,February2005.
[13] T. Takeda, R. Aubin, M. Carugi, I. Inoue, and H. Ould-Brahim. Framework andRequirementsfor Layer 1 Virtual Private Networks. IETFInternet-Draft, work in progress, August 2005.
[14] T. Takeda, D. Brungard, A. Farrel, H. Ould-Brahim, and
D. Papadimitriou. Applicability analysis of GMPLS
pro-tocolstoLayer 1 Virtual Private Networks. IETF
Internet-Draft,work in progress,September2005.
[15] T. Takeda, D. Brungard, D. Papadimitriou, and H. Ould-Brahim. Layer 1 Virtual Private Networks: drivingforces and realization by GMPLS. Communications Magazine,
IEEE,43(7):60-67,2005.
[16] T. Takeda, I. Inoue, R. Aubin, and M. Carugi. Layer 1 Virtual Private Networks: service concepts, architecture
re-quirements, and related advances in standardization. Com-municationsMagazine, IEEE,42(6):132-138, 2004.
[17] T.Takeda, H.Kojima,andI.Inoue. Layer 1 VPN architec-tureand its evaluation. InCommunications, and the 5th In-ternationalSymposiumonMulti-Dimensional Mobile Com-munications.JointConferenceofthe 10thAsia-Pacific
Con-ferenceon,volume2,pages612-616,2004.
[18] T.Takeda, H.Kojima,N.Matsuura,andI.Inoue. Resource allocation method foropticalVPN. InOpticalFiber Com-municationConference,2004. OFC2004,volume1,2004.
[19] F. Verdi, C. Carvalho, M. Magalhaes, and E. Madeira.
Policy-based GroominginOpticalNetworks. In 4th Latin American Network Operations and Management
Sympo-sium,LANOMS2005,pages 125-136,Brazil, August2005.
[20] D. C. Verma. SimplifyingNetwork Administration Using
Policy-Based Management. Network, IEEE, 16(2):20-26,
