End-to-end flexible transport service provisioning in inter-CSP environments [Next-Generation Telco IT Architectures]

IEEE Communications Magazine • August 2010118 0163-6804/10/$25.00 © 2010 IEEE

This research was fundedby the European Commu-nity Seventh FrameworkProgramme [FP7/2007-2013] under grant agree-ment 215462; theparticipants were fromBritish Telecom, NokiaSiemens Networks, TKK,and BGU.

INTRODUCTIONThe traditional model that considers a communi-cation service provider (CSP) solely as a purvey-or of bespoken stovepipe network connectivity isno longer sustainable. To survive and prosper,CSPs must extend their traditional businessmodel to embrace service hosting and outsourc-ing. This shift of emphasis will require a reusablecapability to support existing emerging andfuture services. This in turn, requires carefulreflection on the requirements and capabilitiesof the underlying transport network. The trans-port network must be sufficiently agile to pro-

vide the transport services required to support abroad mix of value-added services.

Ethernet technology has improved significantlyin recent years, especially in leveraging this technol-ogy for CSPs and carrier grade networks [1–3], widearea networks, and backbone infrastructure. Recentstandards, in particular IEEE 802.1ad (providerbridges network [PB]) [4], IEEE 802.1ah (providerbackbone bridges [PBB]) [5], IEEE 802.1Qay(PBBTE, i.e., with traffic engineering) [6], IEEE802.1ag (connectivity fault management [CFM]),and the maturity of the technology make this tech-nology a valid choice for CSP infrastructures.

CSPs that use Ethernet technology can offer avariety of Ethernet transport services to their sub-scribers, such as various layer 2 (L2) and L3 virtu-al private networks (VPNs), E-LINE, E-LAN,and E-TREE services that interconnect remotesites with a defined service level agreement(SLA), IPTV, mobile and wholesale backhaul,leased lines, and more [7]. Additionally, next-gen-eration value-added (application) services can beoffered over these Ethernet transport services,including storage, content, e-commerce, socialnetworks, messaging, videoconferencing andwebinars, semantic web, software as a service(SAAS), mobile applications, and so on.

However, when it comes to inter-CSP serviceprovisioning, transport services become complex,and current solutions are basically manually setup and managed, which takes lots of time andwork, and are very expensive as a result. Thereare several proposals in the research communityand from the standards organizations trying tocope with this issue in various ways. These pro-posals include some native approaches based onEthernet PBB-TE, virtual LAN (VLAN) switch-ing, or variants of multiprotocol label switching(MPLS), such as transport MPLS (T-MPLS) orMPLS — transport profile (MPLS-TP), whichmight not be compatible with non-IP networks.Such an example was introduced by CELTIC’s100 Gigabit Ethernet Technologies (100GET),which is an end-to-end service provisioning inEthernet-core carrier-grade networks (100GET-E3) [8]. Other proposals are based on general-ized MPLS with traffic engineering (GMPLS-TE)in the control plane, for either single-CSP [3] orinter-CSP [9]. These proposals are either IP-based or enable end-to-end service provisioningonly on the technical aspects, not decision-wise,service, or business-level provisioning.

ABSTRACT

Communication service providers delivervalue-added services to customers based on theiravailable network transport services. Some ser-vices extend beyond the boundaries of a singleCSP and require the collaboration of severalCSPs to provide inter-CSP services. Transportservices for next-generation value-added servicesare currently based on expensive connection ori-ented technologies such as synchronous digitalhierarchy and optical transport networks. Data-oriented technologies have recently been consid-ered for transport networks (e.g., Ethernet andMPLS variants) due to their efficiency, simplicity,and better suitability for data traffic, which domi-nates the transport networks. Currently, CSPtransport networks are isolated and inter-CSPtransport service provisioning involves human-to-human negotiations and manual setup of net-work devices. Next-generation CSPs must provideQoS intra-service-to-customer, inter-CSP, andcustomer-to-customer transport services that aregeneric, automatically provisioned, and based onbusiness logic that can be expressed easily anduniformly. A transport service layer architecturefor automatic provisioning of inter-CSP transportservices is suggested here, based on standardEthernet technology. This transport service layerarchitecture is part of the Ethernet transport net-work architecture that takes into account busi-ness relations among carriers. It enables variousclass-of-service transport services based on multi-constraint matching and optimizations. Theresulting transport service provisioning is auto-mated and optimized, and significantly decreasesthe involved inter-CSP service setup operations.

NEXT-GENERATION TELCO IT ARCHITECTURES

Eliav Menachi and Ran Giladi, Ben-Gurion University of the Negev

End-to-End Flexible Transport ServiceProvisioning in Inter-CSP Environments

MENACHI LAYOUT 7/20/10 12:26 PM Page 118

IEEE Communications Magazine • August 2010 119

Next-generation CSPs must provide QoSintra-service-to-customer, inter-CSP, and cus-tomer-to-customer transport services that aregeneric, automatically provisioned, and based onbusiness logic that can be expressed easily anduniformly. Next-generation operation supportsystems (NG-OSSs) should provision and man-age such transport service layers.

The transport service layer architecture forautomatic provisioning of inter-CSP transport ser-vices that is suggested here is based on standardEthernet technology. This transport service layerarchitecture is part of the Ethernet transport net-work architecture (ETNA) that takes into accountbusiness relations among carriers. This architec-ture enables CSPs to publish their Ethernet trans-port services, and then calculate and construct themost suitable service according to customerrequirements. It enables various class-of-servicetransport services based on multi-constraintmatching and optimizations. The resulting trans-port service provisioning is automated and opti-mized, and decreases the involved inter-CSPservice setup and modifications significantly.

We begin with a description of the network ser-vices and their properties; the business model of thenetwork is then presented, followed by an overviewof the suggested transport service layer architecture.We then present our addressing scheme and thedata model (templates), followed by the principlesof network operations. We close the discussion bydescribing the simulation and prototype of the ser-vice layer, and summarize our conclusions.

THE NETWORK SERVICES MODELThe network model presented here comprisesthree distinct service layers: transport, transportservices, and value-added services. The transportlayer handles the transmission of packetsbetween network endpoints. The transport ser-vices layer is built on primitives provided by thetransport layer, and provides transport servicessuch as E-LINE, E-LAN, or E-TREE with spe-cific quality of service (QoS), which are theinfrastructure of the value-added services.

The value-added services provide the meansto offer NGN services that are dependent on thenetwork layer functionality or primitives. Thevalue-added services can be categorized intonext-generation (application) services and tradi-tional services (wholesale, business, and residen-tial). As noted above, the application servicesinclude storage, content, e-commerce, social net-works, messaging, videoconferencing and webi-nars, semantic web, software as a service(SAAS), and mobile applications. The tradition-al value-added services are summarized in Table1 according to their category, their properties,and the equivalent transport services required toimplement those services. We continue bydescribing the business model for establishinginter-CSP transport services followed by thearchitecture of the transport service layer.

BUSINESS MODELOperation of inter-CSP transport servicesrequires a common business model betweenCSPs. This model includes a suite of agreements

including billing, trust, security, common defini-tion of SLA, and so on. Unlike Internet service,which usually offers global connectivity at a flatrate, transport services define connectivitybetween specific endpoints with specific QoSattributes, and the price is per specific service.We use peering models to describe the commer-cial relationship between CSPs that provideinter-CSP transport services. We identify fivetypes of peering models between CSPs:• Adjacent peering, in which the CSP has a

business partnership only with its adjacentCSPs.

• Alliance peering, in which the business part-nership is between all the CSPs that aremembers in the alliance.

• Hybrid peering is the combination of adja-cent peering and alliance peering.

• Ethernet exchange peering is similar to avoice over IP (VoIP) peering point or an IPexchange; this would be a place where CSPnetworks intersect, and where Ethernet ser-vices could be handed off from one opera-tor to another.

• Neutral exchange (NE) peering is describedbelow.The NE, illustrated in Fig. 1, is a central mar-

ket place for transport services; each CSP pub-lishes its offers and prices in the exchange, andthe retail CSP can choose and buy the appropri-ate services. An end-to-end customer service isadministered by an administrative owner (AO)who has business partnerships with several ele-ment owners (EOs) via the exchange. All EOssubmit standard templates defined by theexchange, which describe the service capabilitiesthey offer and their border peering points withneighboring EOs.

In this model a customer requests a servicefrom an AO. The AO has visibility, via theexchange, of all offered segments that couldconstitute the full end-to-end service. The AOchooses the segments according to segmentproperties, routing, and business considera-tions. This model promotes market efficiencythrough price transparency and competition.The customer pays the AO for the end-to-endservice; the AO, in turn, pays each EO for thesegments that are used according to the agreedprice.

TRANSPORT SERVICE LAYERThe proposed transport service layer is an inter-CSP layer that interconnects all the CSPs’ OSSs,and enables them to exchange service-relatedinformation and requests. The transport servicelayer defines a data model and a protocol fordescribing Ethernet transport services offered byevery CSP, and provides a method of exchangingthis information. Consequently, each CSP canautomatically calculate the optimal Ethernettransport service path when requested by its cus-tomers, according to QoS parameters, trafficconditions, and CSPs’ agreements. Once such aservice path is calculated, the transport servicelayer automatically provisions this service usingan inter-CSP signaling protocol executed by theOSSs and the interdomain bridges (IDBs). Thetransport service layer also enables inter-CSP

This model promotes

market efficiency

through price

transparency and

competition.

The Customer pays

the AO for the

end-to-end service;

the AO, in turn,

pays each EO for the

segments that are

used according to

the agreed price.


IEEE Communications Magazine • August 2010120

end-to-end service protection, which is requiredfor carrier-grade Ethernet transport services.

The transport service layer includes severalfunctionalities that facilitate automatic provisionof inter-CSP transport services, such as resourceallocation and signaling, topology discovery andcross-CSP confidentiality, unique addressing andidentification, multiple constraints service pathcalculation, and a generic means of servicedescription and information exchange. All thesefunctionalities have to be scalable, distributed,real-time, resilient, efficient, and robust.

The following subsections describe the mainnetwork elements that use the transport servicelayer, the addressing scheme, and the data modelused, that is, the unique identification of everyentity in the architecture and the use of tem-plates for describing services and requirements.

NETWORK ELEMENTS

Every CSP domain in our network modelincludes at least one OSS, an OSS repository,interdomain path calculation entity (IPCE), acustomer portal, and an IDB as illustrated inFig. 2. The CSP domain can be implemented byany technology (e.g., Ethernet, MPLS, syn-chronous digital hierarchy [SDH], or IP), and itcontains management and control functions incorresponding management and control layersabove the physical data layer.

The customer portal is a secure web applica-tion/service, which provides the customer withan interface to log into its provider system andmanage its services. Customer requests, whichmay include defining and requesting new ser-vices, monitoring, modifying, and terminating

Table 1. Value-added services properties.

Value added service Transport service type Bandwidth Class of service CommitmentW

ho

lesa

le

Wholesale backhaul E-Line 100 Mb/s –10 Gb/s EF CIR = 100%EIR = 0%

Broadcast video (RT) E-Tree SDTV < 300 Mb/sHDTV < 3 Gb/s EF (RT) CIR = 100%

EIR = 0%

Content distribution E-Tree 1 Mb/s–3 Gb/s AF/BE (non-RT) CIR = 100%EIR = 0%

Partial private circuit Multiple E-Lines 10 Mb/s–10 Gb/s EF CIR = 100%EIR = 0%

Mobile backhaul E-Line and E-LAN 10 Mb/s–50 Mb/s EF/BE CIR = 100%EIR = 0%

Bu

sin

ess

Leased line (uncontended) E-Line 10 Mb/s–10 Gb/s EF CIR = 100%EIR = 0%

Leased line (contended) E-Line and E-Tree 10 Mb/s–10 Gb/s EF/AF/BE BE: CIR = 50%EF/AF: CIR = 100%

VPN (L2 and L3) E-LAN 10 Mb/s–10 Gb/s EF/AF/BE BE: CIR = 50%EF/AF: CIR = 100%

Internet access E-Line < 25 Mb/s BE EIR > 0EIR < line rate

Res

iden

tial

/SM

E

Premium VoIP E-Line < 100 kb/s EF CIR = 100%EIR = 0%

Mobile point-to-pointvideo E-LAN Burst to 10 Mb/s BE EIR > 0

EIR < line rate

Point-to-point video E-LAN Burst to 10 Mb/s BE EIR > 0EIR < line rate

Premium VoD (unicast) E-Line SDTV 5 Mb/sHDTV 20 Mb/s AF CIR = 100%

EIR < line rate

Premium IPTV (multicast) E-Tree SDTV 5 Mb/sHDTV 20 Mb/s AF CIR = 100%

EIR < line rate

Bandwidth: The approximate bandwidth required for each instance of the serviceClass of service: Uses IETF DiffServ traffic type definition: expedited forwarding (EF), assured forwarding (AF), and best effort (BE)Commitment: Committed information rate (CIR), excess information rate (EIR)



existing services, are forwarded from the cus-tomer portal to the OSS for handling.

The OSS is a software module that initiallyestablishes connectivity with other OSSs by run-ning an inter-CSP link state protocol betweenthe CSPs’ OSSs. Then the OSS collects andmaintains the service offerings from other CSPs’OSSs, which are stored in the OSS repository,performs the services provisioning process, andservices fault management activities. The OSSuses the IPCE to perform multiple-constraintpath calculations for the required service, andestablishes the path using an interdomain signal-ing protocol executed by the OSSs and IDBs.

The IDB provides the connection points betweenCSP domains for setting up transport tunnels andmaintaining these tunnels. The IDBs are also usedfor topology discovery and operations, administra-tion, and maintenance (OAM) operations, by peri-odic OAM frame exchanges that are used tomonitor the availability of inter-domain links, andnew or failed links are reported to the OSSs. Thecurrent MEF’s suggested 802.1ad-based E-NNI(network–network interface) frame is replaced withan 802.1ah-based frame, in order to extend thenumber of services available between the CSPs. TheIDB converts the CSP’s internal tunneling protocolsto 802.1ah frame format and vice versa.

ADDRESSING SCHEMEIn order to enable connectivity between networkelements of different CSPs, there is a need for aglobal unique identification (GUID). Such anaddress should be technology-independent, andhave a global and hierarchical meaning. IPaddresses are unique and hierarchical but thereis no private (global) IP range, so there is noway to distinguish between IP addresses belong-ing to private inter-CSP networks and thosebelonging to the Internet. MPLS and medium

access control (MAC) addresses are neitherunique nor hierarchical.

The proposed GUID has a fixed length andconsists of three fields. The first corresponds tothe geographic partitioning of the network (coun-try code, state, and city); the second field is a CSPidentifier inside the geographic location; and thethird field identifies the network element insidethe domain (IDB, OSS, customer port, etc.). Thefirst two fields identify a CSP in a region andmust be globally unique; therefore, they are man-aged by a global addressing authority. The thirdfield of the address is under the CSP’s responsi-bility, which assigns unique identifiers to its net-work elements. It should be hierarchical withgeographic notation of the location of the net-

Figure 1. Neutral exchange.

EO4

NE

Segment 1

AO

Exchange offers to sell

Exchange “buy”

request

EO1

EO2 EO3 Inter carrier service

Branch 1 Branch 2

Service initiator

Service

request

Segment 2 Segment 3

Segment 4

Figure 2. Service layer architecture.

OSS DB

Management layer and control layer

OSS Other OSSs

Transport service layer

IPCE

Physical layer

Domain D Domain C Domain B

Domain A

Customer portal

CSP network

IDB IDB IDB


work element inside the domain, to enable speci-fication of different services to customers accord-ing to their physical location inside the domain.

ACCESS AND SERVICE TEMPLATESThe service offering mechanism is based on tem-plates similar to those in IPsphere [9, 10]. Themain differences are the use of Ethernet-basedtemplates and the support of various networktopologies (which reflect inter-CSP business rela-tions, as well as E-Line, E-LAN, and E-tree). Theproposed templates define the service contractbetween the CSP and the service recipient. Thetemplates contain information about the servicesprovided by the CSP and describe these services,their attributes, and their price. There are twotypes of templates: service template and accesstemplate. A service template describes the charac-teristics of a service segment that traverses a CSP,while an access template describes the source anddestination segments of the service. A completeinter-CSP service is constructed from a sourceaccess template, one or more service templates,and a destination access template. We refer to thiscombination of templates as a service path (Fig. 3).

SERVICE TEMPLATESThe service templates describe the basic servicecomponents that are offered by each CSP. Theservice template covers a segment that begins atthe ingress IDB of the offering CSP domain to theingress IDB of the next CSP domain. Every ser-vice segment is specified by three IDBs: Thedomain’s ingress IDB, the domain’s egress IDB,and the next domain’s ingress IDB. CSP 2 in Fig.3 publishes service template B1, which describesthe service that transverses domain B and reachesdomain C; this service is defined by IDB 2 as itsstarting point, IDB 3, and IDB 4 as its terminationpoint, which is the entrance point into domain C.

Three service templates are currently pro-posed:• The E-Line service template describes a

point-to-point service component (e.g., B1in Fig. 3); the properties of the E-Line ser-vice template are described in Fig. 4.

• The E-LAN service template describes a point-to-multipoint service component. The E-LANservice is composed of E-Line services and E-LAN properties that include MAC learningand MAC forwarding functionalities.

• The E-Tree service template is an Ethernetservice that is based on rooted-multipointEthernet. An E-Tree service provides con-nectivity between single or multiple roots andmultiple leaves. Each leaf can exchange datawith only the roots (e.g., broadcast TV). TheE-Tree template is composed of E-Line ser-vices and a component in which frame repli-cation takes place. The template describesthe replication capabilities and its price.

ACCESS TEMPLATESThe access templates describe the available ser-vices between a CSP customer and the CSPdomain borders; the customer can be the sourcecustomer requesting the service or the targetcustomer. This type of template is used for thefirst and last segments of a service path. Sinceaccess templates reveal internal information ofthe publishing CSP, there are three levels ofgranularity that can be used by the publishingCSP, allowing the CSP to control the level of itstopology exposure:• Flat rate: The CSP declares that access ser-

vices contained in the published templateare valid for all customers in its domain,disregarding the customer location withinthe domain.

• Zone rate: The published services are validonly for users that are located in specifiedzones that are listed in the template.

• Customer rate: The specified services arevalid only to the customer specified in thetemplate.

PRINCIPLES OFNETWORK OPERATIONS

This section briefly outlines the basic principlesof the transport service layer procedures and theOSS operations. These include topology andOAM, service and customer request descrip-tions, optimal resource allocation, and transportservice provisioning. The general operation isillustrated in Fig. 5.

GENERAL NETWORK OPERATIONIt is assumed that the OSS interfaces with themanagement and control functions of its domainas customary, and there are communicationprimitives that are supported in this interface


Figure 3. Access and service templates.

CSP 2

CSP 1 CSP 4

Domain B

Domain A

Domain D

Access template A1

Source ID

Target ID

IDB 2

IDB 1

IDB 4

IDB 3

CSP 3

Domain C IDB 6

IDB 5

Access template D1

Service template B1

Service template C1

The service template

covers a segment

that begins at the

ingress IDB of the

offering CSP domain

to the ingress IDB in

the next CSP

domain. Every service

segment is specified

by three IDBs: The

domain’s ingress IDB,

the domain’s egress

IDB, and the next

domain’s ingress IDB.



(e.g., establishing a point-to-point tunnel withanother entity). The OSS periodically queries thecontrol plane of its domain to discover IDBs, andstores their identities and properties in its localrepository. (For example, when open systeminterconnect’s [OSI’s] intermediate-system-to-intermediate-system [IS-IS] routing protocol, isused in the control plane, IDBs can be identifiedby their interfaces with entities that are not inthe CSP domain.) Once the OSS finds a newIDB, it establishes a control channel (e.g., a tun-nel) with that IDB using the domains’ manage-ment and control functions. After such a controlchannel is established, the OSS can start execut-ing the service layer link-state protocol over theintra-CSP control channel, the inter-CSP linkthat binds the two IDBs, and the neighbor’sintra-CSP control channel between the neighborIDB and its OSS. The IDBs simply forward theservice layer link-state frames transparentlybetween their OSS and their neighboring IDB.This in-band OSS subnetwork runs the link-stateprotocol, which enables the OSSs to identify theirneighbor OSSs, and share information regardingtheir services as well as services from other CSPsthat they possess and are willing to share.

SERVICE DEFINITION AND OFFERINGThe Ethernet transport services that are offeredby a provider are defined manually by the EO of

the domain, or automatically by specifying poli-cies in the OSS, which generates the service tem-plates accordingly. There are two options fordistributing the templates between the OSSs: thein-band OSS subnetwork (i.e., the subnetworkcomposed of the intradomain control channelsand the interdomain links that connect the IDBs)and an out-of-band network (e.g., an IP networkthat interconnects all OSSs). In the latter case, acentralized repository entity can be used to storeall service and access templates and make themavailable for any OSS (or directly respond toqueries for optimal service paths, i.e., neutralexchange), similar to the IPSphere proposal.

Once the OSS collects all the templates fromother OSSs, it has a complete view of the ser-vices offered by all other domains.

SERVICE PROVISIONINGWe distinguish five functional steps correspond-ing to the different phases of the lifecycle of aninter-CSP service. The service provisioning pro-cess begins with a service request, which is initi-ated by a customer; the request is thenforwarded to the IPCE for path calculation, andthen to the OSS for service-establishing proce-dures. After the service is activated the serviceenters the maintenance phase until it is termi-nated. These functional steps are describedbelow.

Figure 4. E-Line service template. BW: bandwidth.

Service template

Template number

Template expiration

Maximum delay

Maximum jitter

Maximum PBS

Maximum CBS

Packet loss

Service availability

Mean time to repair

Minimum duration

Guaranteed BW price per kb/s:Tariff 1 (min BW, max BW, step,duration)Protected priceUnprotected priceTariff n (min BW, max BW, step)Protected priceUnprotected price ...

Connection points(includes 3 GUIDs)

Globally unique: composed of the domain GUIDand a suffix allocated by the domain

Template’s expiration date

Important in real-time services

Important in real-time services

Maximum allowed burst size for peak information rate

Maximum committed burst size for peak information rate

Committed max packet loss

The service availability in percentage

Minimum duration for service

Price per Mb/sThe price depends, among others, on:1. Committed bandwidth2. Guaranteed or not3. Type of protection4. Duration of service

Domain entrance point IDB(GUID)Domain exit point IDB(GUID)Next domain entrance point IDB(GUID)

This in-band OSS

sub-network runs

the link-state

protocol, which

enables the OSSs to

identify their

neighbor OSSs, and

share information

regarding their

services as well as

services from other

CSPs that they

possess and are

willing to share.



Service Request — A service request isreceived from the customer through the publicsecured Internet connection to the customerportal and from there to the domain’s OSS. Aservice request is associated with a GUID of thesource and destination ports, and QoS parame-ters of the requested service. The customer por-tal provides security means to authenticate andverify the customer request and approve therequest with the destination CSP.

Path Computation — The IPCE calculates theservice path according to the service requirementsreceived from the customer. The path is a selec-tion of the most suitable service segments fromthe available templates the OSS collected, whichare required to create the service. When end-to-end protection is required, the IPCE calculatesthe additional protection path, which is a disjointpath from the source to the target. The servicepath is reported to the OSS, for service setup.

Service Establishment — The service establish-ment process reserves and activates the service ineach of the participating domains. We presentthree main approaches to performing the reser-vation and activation of a service: approve firstservice establishing (AFSE), forward serviceestablishing reservation (FSER), and backwardservice establishing reservation (BSER).

AFSE — The AFSE approach simultaneouslyreserves all relevant service segments at the partici-pating CSPs, and after all the segments are

reserved, it performs simultaneous activation of theservice at all participating CSPs. The biggest advan-tage of this approach is in the duration of the estab-lishment process, which is shorter than in the othertwo approaches, while the disadvantage is that alarge number of false reservations might occur.

FSER — The FSER approach iteratively reservesall relevant service segments at the participatingdomains, and after all segments are reserved, itactivates the service. The reservation and activa-tion of the service is executed by forwarding a sin-gle path message between the domains. Theadvantage of this approach is minimized falsereservations, but the duration of the service estab-lishing process depends on the service path length.

BSER — The BSER approach is similar toFSER, but the source sends the service pathmessage to the target OSS, which initiates thereservation process. This approach is preferredwhen the target holds additional informationregarding the service path, such as the last accesstemplate.

SERVICE MAINTENANCEThe transport service layer introduces an end-to-end protection mechanism, where the intra-CSPprotection, maintenance, and administrationactivities are performed by the intra-CSP domainmechanisms, and inter-CSP protection is per-formed by the transport service layer. Each CSPspecifies its level of protection for its providedservices in its templates. End-to-end protection

Figure 5. Discovery, offering, and provisioning of a service.

OSS

dis

cove

ry

NEAO

Edge EdgeIDB IDBOSS OSS

Customer A Customer B

EOEO

Carrier A Carrier B

Seri

ce p

rovi

sion

ing

NEAO



EOEO

Carrier A Carrier B

Serv

ice

defin

itio

n an

dof

feri

ng NEAO



EOEO

Carrier A Carrier B

We present three

main approaches to

performing the

reservation and

activation of a

service: Approve First

Service Establishing

(AFSE), Forward


Reservation (FSER),

and Backward


Reservation (BSER).



is provided by adding distinct routes, multicasts,or aggregation functionalities.

The transport service layer supports two typesof end-to-end protection, 1+1 protection and 1:1protection. Both types of protection use a disjointpath as the secondary path of the service. In 1:1protection the backup path is used after the mainpath fails; in 1+1 protection the traffic is multi-cast on both paths, and the target CSP combinesthe traffic and forwards it to the target client.

Inter-CSP link-state monitoring is performedby the IDB, which notifies the OSS when a failureis detected. The CSP’s internal service segmentsare monitored by the CSP’s control plane entities,which notify the OSS of failures. In either case,the OSS that identifies a failure signals the sourceand target OSSs, which perform a rerouting.

SERVICE TEARDOWNService teardown is initiated when the servicetime expires, or upon an explicit customerrequest. The termination process is managed bythe OSS, which signals the new status of the ser-vice to the participating OSSs, which theninstruct the CSP’s control plane entities and theIDBs to free the reserved resources.

SIMULATION AND PROTOTYPEThe transport service layer architecture was sim-ulated using the OMNET++ framework to vali-date the OSS interfaces, templates usage, andservice establishment processes. The simulation,based on real Internet topology of 69 domainsand random service requests and traffic, validat-ed the architecture, and enabled us to comparetwo service reservation methods (AFSE andSEFR). The simulation showed that AFSE is notfeasible due to false reservations and overhead,and that SEFR reduces the false reservationsand overhead. In addition, a multi-CSP proto-type was constructed and demonstrated at theBritish Telecom laboratories. The prototypeincluded a data plane, control plane, manage-ment plane, and transport service layer. The ser-vice layer includedan OSS for each CSP and acentral NE. The OSS introduced a new exten-sion of IS-IS for the inter-CSP link-state proto-col. In addition, a new inter-CSP signalingprotocol was designed to reserve, activate, main-tain, and terminate the services across thedomains. The prototype demonstrated automaticprovisioning of different inter-CSP transport ser-vices with different characteristics of bandwidth,latency, cost, and protection.

CONCLUSIONSAutomatic provisioning of inter-CSP services issuggested for IP networks in various ways. Eth-ernet technology is not scalable and is limited tointernal CSP domains, although many attemptsare proposed for using Ethernet outside theCSPs’ domains and for inter-CSP communica-tions. Extending Ethernet beyond the CSPs’ bor-ders and enabling automatic provisioning ofinter-CSP Ethernet-based transport servicesrequires additional extensions to the currentstandards and protocols.

In this article we outline a feasible solutionthat enables a CSP to automatically provision

QoS intra-service-to-customer, inter-CSP, andcustomer-to-customer transport services that aregeneric and based on uniformly expressed busi-ness logic. The proposed architecture is entirelylayer 2, Ethernet-based, and supports CSPdomains of various technologies. We focus in thisarticle on the transport service layer, a new layerthat enables the OSSs of the domains to exchangenetwork capabilities and prices in defined tem-plates. These templates are used by these OSSsand their IPCEs, or by an NE, to calculate opti-mal service paths that can be used for customerrequested services. The mechanisms of setting upthese service paths (tunnels) through the appro-priate IDBs, as well as maintaining and protectingthese service paths, are described in this article.

ACKNOWLEDGMENTSThe authors would like to thank David Berechya,Chen Avin, Hayim Porat, Ilya Vershkov, RaimoKantola, Marko Luoma, Paul Gunning, andMark Wilkinson for their contribution to thiswork in the scope of the Ethernet TransportNetwork Architecture (ETNA) project.

REFERENCES[1] P. Bottorff and P. Saltsidis, “Scaling Provider Ethernet,”

IEEE Commun. Mag., vol. 46, no. 9, Sept. 2008, pp.104–9.

[2] R. Sanchez, L. Raptis, and K. Vaxevanakis, “Ethernet asa Carrier Grade Technology: Developments and Innova-tions,” IEEE Commun. Mag., vol. 46, no. 9, Sept. 2008,pp. 88–94.

[3] A. Takacs, H. Green, and B. Tremblay, “GMPLS Con-trolled Ethernet: An Emerging Packet-Oriented Trans-port Technology,” IEEE Commun. Mag., vol. 46, no. 9,Sept. 2008, pp. 118–24.

[4] IEEE 802.1ad-2005, “IEEE Standard for Local andMetropolitan Area Networks: Virtual Bridged Local AreaNetworks, Amendment 4: Provider Bridges.”

[5] IEEE P802.1ah/D4.2, “Draft Standard for Local andMetropolitan Area Networks: Virtual Bridged Local AreaNetworks Amendment 6 to IEEE802.1Q-2005: ProviderBackbone Bridges.”

[6] , IEEE P802.1Qay/D4.5, “Draft Standard for Local andMetropolitan Area Networks: Virtual Bridged Local AreaNetworks Amendment to IEEE802.1Q-2005: ProviderBackbone Bridge Traffic Engineering.”

[7] ETNA, “Ethernet Transport Networks, Architecture ofNetworking, WP1 Requirements Specification and Anal-ysis,” 2008; http://www.ictetna.eu/documents.html

[8] X. Chen, A. Jukan, and T. Fischer, “End-to-End ServiceProvisioning in Carrier Grade Ethernet Networks: The100 Get-E3 Approach,” Proc. Int’l. Conf. Optical Net.Design Modeling, 2008, pp. 1–6.

[9] R. Douville et al., “A Service Plane over the PCE Archi-tecture for Automatic Multidomain Connection-Orient-ed Services,” IEEE Commun. Mag., vol. 46, no. 6, June2008, pp. 94–102.

[10] IPsphere, “IPsphere Framework Technical Specification(Release 1) IPsphere 1.0,” June 2007.

BIOGRAPHIESELIAV MENACHI ([email protected]) received his B.Sc.degree in communication systems engineering from Ben Guri-on University, Israel, in 2000. He is a Ph.D. student in industri-al and management engineering at Ben Gurion University. Hiscurrent research is in Ethernet transport architecture.

RAN GILADI ([email protected]) received a B.A. in physics and anM.Sc. in biomedical engineering from The Technion, IsraelInstitute of Technology, and a Ph.D. in information systemsfrom Tel-Aviv University, Israel. He founded and headed theDepartment of Communication Systems Engineering, BenGurion University. He founded and headed several startups,and he serves as a director in some of them. He hasauthored several books, the most recent of which is Net-work Processors: Architectures, Programming, and Imple-mentation.

The transport service

layer architecture

was simulated using

OMNET++

framework to vali-

date the OSS inter-

faces, the templates

usage, and the

service establishment

processes. The

simulation validated

the architecture, and

enabled us to

compare two service

reservation methods

(AFSE and SEFR).


Documents

End-to-end flexible transport service provisioning in inter-CSP environments [Next-Generation Telco IT Architectures]