Management-aware inter-domain routing for end-to-end quality of service

60

International Journal on Advances in Internet Technology, vol 4 no 1 & 2, year 2011, http://www.iariajournals.org/internet_technology/

2011, © Copyright by authors, Published under agreement with IARIA - www.iaria.org

Management-aware Inter-Domain Routing for End-to-End Quality of Service

Mark Yampolskiy1,2,4, Wolfgang Hommel2,4, Vitalian A. Danciu3,4, Martin G. Metzker3,4, Matthias K. Hamm4

1 German Research Network (DFN), Alexanderplatz 1, 10170 Berlin, Germany2 Leibniz Supercomputing Centre (LRZ), Boltzmannstr. 1, 85748 Garching, Germany

3 Ludwig-Maximilians-Universitat Munich (LMU), Oettingenstr. 67, 80538 Munich, Germany4 Munich Network Management (MNM) Team, Oettingenstr. 67, 80538 Munich, Germany

[email protected], [email protected], [email protected], [email protected], [email protected]

Abstract—Services sensitive to network quality convergeonto general-purpose data networks which, in contrast tospecial-purpose (e.g., public telephony) networks, lack built-in quality control functions needed by many applications,like Internet telephony or video conferencing. High-volume,high-performance applications such as those in Grid andCloud computing may be too important for customers torely on mere promises of network quality, while at thesame time requiring connections traversing multiple networkoperators’ domains. Thus, in addition to end-to-end QoSassurances, customers of these applications demand man-agement functionality for those connections made availableto them. Traditional routing procedures are insufficient toselect paths according to these requirements, as they relyon evaluation of only one parameter (e.g., hop count), whileQoS parameters alone will account for multiple independentmetrics.

We present a solution that addresses these issues bycombining a routing procedure, a common set of QoSoperations, and an information model for the representationof connection properties within and across administrativedomains.

Keywords-end-to-end; quality of service (QoS); inter-domain routing; network management

I. INTRODUCTION

Today’s convergent or converged networks are intendedto support a growing number of major services withhighly varying requirements on the transport system. Suchservices include end-user facing services, such as voiceand video telephony and their conferencing counterparts,but also high-capacity interconnects between the scientificsites of grid installations or the provisioning of cloudservices, co-provided in different administrative domains,as well as connections between parts of virtual privatenetworks (VPN links).

The inter-networking layer (i.e., the Internet protocols)does not support quality management inherently. Instead,many different Quality of Service (QoS) schemes havebeen implemented by different network operators. They doassure a stated quality of the transport, but typically omitcustomer-facing management capabilities. At the sametime, the scope of network management is limited to singleadministrative domains.

Nevertheless, customers of important and expensiveapplications require network management facilities as partof the service being provided. Their capabilities rangefrom read-only inspection functions (e.g., performance

monitoring) to functions that alter the state of the network(e.g., adjustments of communication channel parameters).

Such capabilities are readily provided within singledomains, but inter-domain communication channels (i.e.,connections spanning multiple autonomous administrativedomains) will require the co-operation of all domains inorder to achieve end-to-end quality guarantees as wellas an aggregate management function presented to thecustomer as part of the service. Such communicationchannels, provided as a service to a (paying) customer,we call concatenated services (CS).

A. Concatenated services

Combining the outlined demand and focus, our workspecializes on the development of a solution for concate-nated services, which are probably the most challengingtype of point-to-point connections with respect to planningand operation. The following properties are characteristicfor CS [24]:

• User perspective: a guarantee for the E2E quality ofthe connection and its management is required;

• Service composition: the E2E service is composedof horizontally (i.e., at the same network layer) con-catenated connection segments, which are realized bydifferent SPs;

• Organizational relationships: all SPs involved in theservice’s provisioning are independent organizationsand are considered equal partners.

Due to high complexity of such connections, somescenarios exhibit unacceptable connection planning andestablishment delays, especially when preparing a connec-tion with non-trivial QoS requirements. In some cases, theplanning phase, i.e., the identification of path segmentsthat adhere to such requirements, may take up to severalweeks (e.g., [36]). This is due to the lack of standardisationand automation of a planning process spanning multipleadministrative domains. Each leg of the route must benegotiated with the owner/operator, including the accessi-bility of a suitable next hop and the QoS and managementrequirements for the connection. While this concerns long-term connections (i.e., of longer duration than the planningphase), it is obvious that such planning times cannot bealways tolerated.

The algorithms underlying common routing protocols(link state, distance vector) are not applicable, as they relyon fulfilment of the optimality criterion. In contrast, the set

61



of routing metrics dictated by QoS parameter thresholdsnot necessarily holds this criterion, leading to undecidablechoices. For example, assuming the requirements for aconnection were minimum bandwidth b and maximumdelay d with (b, d) = (1Mbit, 100ms), the choice betweentwo alternatives (1Mbit, 50ms) and (2Mbit, 75ms) can-not be made by “shortest” path semantics alone: the firstalternative is better in terms of delay, while the secondone is better in terms of bandwidth.

A standardisation solution may equally prove unfea-sible: Allowing the requester of the connection (user,customer) to specify the kinds and values of the QoSparameters obviates the use of a linear projection functionthat might calculate “best” values from values of known,i.e., pre-defined, QoS parameters.

In addition, several connection topologies are conceiv-able. Even though the necessity for QoS assurance existsfor different connection types, in the presented work wefocus specifically on dedicated point-to-point connections.A discussion of application areas and aspects of differentconnection types, e.g., point-to-multipoint, is explicitlyomitted. Furthermore, from the customer point of viewas well as from the perspective of services built on topof network connections, the quality of the connection isimportant, but not the technology used for its realiza-tion. As the bridging between different network layersand technologies is very well understood and is broadlyapplied, e.g., in the Internet, we assume in our work thatnetwork connections are realized on the same ISO/OSIreference model network layer, and consider in our furtherdiscussion only the quality of connections and connectionsegments.

Finally, when devising a routing procedure for useacross multiple independent carriers, acceptance of theprocedure is crucial for its success: providers may residein different legal domains, they may have different levelsof interest in providing such services (depending on theirbusiness model, the state and load of their network, theirmanagement capabilities, etc.), and they may have differ-ent views on sharing the network management informationrequired by the service (i.e., the managed connection) thatis to be provided.

Consider the example sketched in Figure 1. SP1’scustomer requires an end-to-end link between a start end-point within SP1’s domain and another end-point (target)within the domain of a different service provider SP3,which is not a neighbour of SP1. The customer specifiescertain properties with regard to the quality of the transport(minimum bandwidth, maximum delay) as well as require-ments on the management of the link during its operationphase (monitoring, constraints on maintenance windows).Via an agreed-upon customer service management (CSM)interface the customer formulates a request to SP1 toaggregate and to deliver such an end-to-end link.

The customer’s knowledge of the topology shown inthe upper part of the figure is limited to the end-points inthe domains of SP1 and SP3, respectively. Each serviceproviders’ knowledge is limited to its own domain, and

Customer CSM

SP-Domain SP1

SP-Domain SP2

SP-Domain SP3

SP-Domain SP4

SP-Domain SP5

Pro

vid

er

Vie

w

Cu

sto

mer

Vie

w

E2E-Requirements:

• Bandwidth: 1Gbps • Delay: max. 40 ms • Maintenance

• Window: 600 – 1000 GMT • Duration: max. 1 hr.

• Monitoring

Figure 1. Example request for a concatenated service with QoS andmanagement requirements

the identity of their neighbour SPs. Starting with only thisinformation, the service provider SP1 needs to find a routeto the target end-point in SP3’s domain, such that theaggregate link adheres to the specification of bandwidthand delay and at the same time fulfils the managementrequirements specified by the customer. Thus, to deliverthe link according to specification, SP1 needs the co-operation of the other SPs in order to select the parts ofthe route (hops) to the remote end-point and to ascertainthe quality and management properties of each part ofthe link. It is understood that during operation/use of thelink each SP will be responsible for the parts of the linkthat pertains to its own domain. The monitoring has toreflect information from all participating domains in orderto provide an end-to-end view to SP1’s customer, and allparticipating domains need to comply with the customer’srequirement on maintenance windows.

In this work, we address the setup of such multi-partconnections that involve multiple services providers, eachof which is responsible only for parts of the overallnetwork connection. In particular, we focus on the provi-sioning of high-quality, managed communication channelsacross multiple autonomous administrative domains; wespecifically include operations support in our QoS con-siderations. The idea underlying this work is to establishtransport quality and management properties at the timeof routing.

B. Line switching

Experience gained with circuit and packet switchednetworks has provided deep insights into details aboutwhich technical and organizational measures are neededfor quality assurance, and about which real-world chal-lenges have to be overcome.

Circuit-switching technology, which is used, e.g., inPublic Switched Telephone Networks (PSTN), has proven

2

62



Information Model

• Objects

• Properties

Operations

• Aggregation

• Comparison

Routing Procedure

• Routing Algorithm

• Communication Model

Figure 2. Three inter-operating conceptual building blocks

to be a viable solution for quality assurance, but atthe same time it is not truly optimal regarding resourceutilization. Packet-switched networks on the contrary haveturned out to utilize the available resources much better,but at the same time the parallel communication flowscan interfere with each other and consequently affect thequality of each other, for example due to overload packetdrops.

Experience gathered in both types of networks typesshows that the quality assurance first and foremost requiresa thorough planning of the resources needed to meet thequality goals. Furthermore, the desired quality can only beachieved if the necessary amount of resources is allocatedto each connection instance. Finally, resource reservationalone does not necessarily guarantee that the goals aremet during the service instance operation. Regarding thisaspect, current best practices suggest the establishment ofmanagement procedures for all life cycle phases of theservice instances.

Based on this experience, we focus on concatenatedservices realized via line switching concepts, because thistechnique has proven to be a viable solution for qualityassurance. As line switching can be emulated in a packetswitched network, e.g., applying a combination of MPLSand RSVP in IP networks, our choice of the switchingparadigm imposes no practical limitation regarding its ap-plication to the infrastructure used by real-world networkoperators.

C. Contribution

In this article, we explain the inter-operation of threeconceptual building blocks that address the problem athand, as sketched in Figure 2: a procedure relying on amanagement-aware inter-domain routing algorithm, whichhas been presented in [1], a dedicated information model(IM) for network connections and their QoS-specificproperties. This IM, first described in [3], defines thestructure and semantics of the information necessary to therouting algorithm. The last building block is a generic QoS

function scheme, i.e., a collection of operations which isneeded during the routing in order to operate on customer-and user-specific QoS parameters (cf. [2]). During the de-fined routing procedure, the connection parts are selectedand the required quality of all parts is defined. Further,during routing the management functionality from allinvolved domains can be integrated into the managementfunctionality of a service instance. As the later aspect ofrouting as well as the interplay of all solution buildingblocks has not been published so far, we discuss it inmore detail.

We summarise the requirements on such an approachin the Section II and proceed to outline our approachin Section III. Thereafter, we describe each of the threebuilding blocks in Sections V, VI, and VII, respectively.Subsequently, in Section VIII, we illustrate the inter-operation of the building blocks by an example beforediscussing the properties and limitations of the approach inSection IX. We conclude the article with ideas for furtherinvestigations in Section X.

II. REQUIREMENTS

The challenges which have to be overcome in order torealize CS are manyfold. Partially they are caused by CScharacteristic properties.

A. Fundamental assumptions

The case described in the Introduction implies that ourapproach is supported by a set of assumptions, as follows:a) SPs are independent organisations; they are not

obliged to participate in the provisioning of a ser-vice/connection.

b) A service instance (connection) cannot be realised byone SP alone.

c) Information about the network topology within an SP’sdomain is not available.

d) Reliable information about an SP’s network capabilitiesis not available.

e) Management functions and management informationare not offered by SPs without prior agreement.

f) Multiple independent QoS parameters will be speci-fied for a connection according to the user/customerdemands.

g) There is no fixed set of QoS parameters that willbe requested by customers; and there is no fixedcombination of parameters.

h) There is no fixed set of management operations thatwill be requested by customers.

i) Requirements on an existing service instance maychange during its life-time.

An important challenge for our approach was to avoid aviolation of any one of these assumptions. For this reason,the approach must fulfil the requirements formulated in thefollowing.

B. Collection of requirements

The foremost requirements are those pertaining to theaim of our work:

3

63



1) The approach shall determine a path across multipleautonomous SPs’ domains.

2) The approach shall ensure that QoS parameter thresh-olds are respected for the end-to-end service.

3) The approach shall ensure that management capabil-ities are provided for the end-to-end service.

4) Where necessary, management information shall beaggregated in a manner opaque to the customer.

5) Multiple independent QoS parameters shall be speci-fiable for a service instance.

6) Multiple independent management functions shall bespecifiable for a service instance.

In addition, several requirements originate from thesettings of concatenated services.

Participation of multiple SPs: Globalization of busi-ness and research collaborations has the consequencethat the communication partners, which are using thesame network connection, can be spread over the entireworld. Due to economic and often also legal reasons, suchconnections usually cannot be realized by only a singleService Provider (SP). Similar to services in the Internetand in PSTN areas, multiple SPs have to be involved inthe realization of a single network connection, leading tothe following requirements:

7) No requirements shall be imposed on items withinSPs’ domains.

8) The approach shall not be dependent on the numberof SPs that co-provide the service.

9) The approach shall not be dependent on global up-to-date information or on a central instance.

Customer-specific QoS-combinations: The quality ofthe customer-faced services in general depends on thedifferent quality parameters of the underlying connections.Furthermore, in general it does not only depend on asingle QoS parameter, but rather on the service-specificcombination of multiple independent QoS parameters. Forexample, a video streaming service might be insensitive todelay and jitter as long as the connection bandwidth en-ables the pre-buffering of content that is not yet displayedto the user. However, for an internet-telephony service, thedelay and jitter of the underlying connection might lead toa negative user experience. During video-telephony and -conferencing, also the synchronization between video andaudio signals becomes important. In summary:

10) The customer shall have only one point of contact,her original SP.

11) The customer shall be given means for managing theservice, once established.

12) The customer shall be allowed to specify QoS pa-rameters and management capabilities.

Highly dynamic environment: The rapid developmentof new services as well as the very high dynamics ofchanges is characteristic for modern IT services. As thequality requirements on the underlying network connec-tions might differ between services, also the high adaptiv-ity and extensibility of solutions becomes a critical successfactor. Especially the extensibility of support for new QoS

parameters is needed, which have not been consideredbefore:

13) The approach shall be extensible regarding the QoSparameters supported.

14) The approach shall be extensible regarding the man-agement capabilities provided to customers.

15) Service planning shall be automatable.

III. APPROACH OUTLINE

We argue that user- and customer-tailored requirementsfor connection services can be only truly fulfilled, whenalready considered during the ordering process. Our ap-proach is a routing process, consisting of three conceptualparts: a routing procedure, a generic function scheme andan information model (see section I-C). A routing proce-dure satisfying the requirements we laid out in Section IItakes into account all known existing connections withtheir properties and end-to-end requirements when findinga path between two end-points.

By employing line switching to realize concatenatedservices, our algorithm may regard the path through anSP’s domain as an atomic link, defined by its ingress andegress points. Based on this decision, our algorithm doesnot require knowledge of every SP’s network topology.This reduces the problem-space and leaves it entirely tothe SP to realize the link. As a result, our informationmodel may describe links, properties and functions in atechnology agnostic way. Abstracting from componentsand technologies, it is easier to model inter-domain links,where the end-points are in domains of different SPs.

Connection requirements directly affect the tasks of therouting procedure, which in the case of line switching are:the selection of the path between the two end-points, thedesignation of all connection segments and interconnect-ing all points along the chosen path [35]. QoS routing (alsoreferred to as QoS-aware routing) extends this definitionby taking into account end-to-end user requirements. QoSrequirements are defined for all connection parts and haveto be guaranteed by all SPs, in order to meet the givenend-to-end goals.

As discussed in the requirements section, for true qual-ity assurance the management of service instances by thecustomer has to be considered. Therefore in our workwe introduce management-aware routing as a QoS-awarerouting with additional tasks, namely:

• the definition of management functionality, whichhave to be provided for each involved connectionsegment and

• the integration of specified functionalities into multi-domain management functionality of the whole ser-vice instance.

As management processes are specified as an interactionbetween roles with specific responsibilities, the assignmentof roles to the involved SPs must be considered as anintegral part of the overall management-aware routingprocedure. The mentioned routing types and their tasksare depicted in Figure 3.

4

64



Management-aware Routing

QoS-aware Routing

*

Routing (line switching)

•Finding a path between endpoints

•Defining all segments along the path

•Defining all connection points of segments

•Defining QoS requirements for all segments

•Considering E2E requirements

•Considering relevant QoS parameters

•Defining required management functionality for all segments

•Integration management functionality into multi-domain processes

•Definition of roles and responsibilities of involved SPs

Figure 3. Routing types and corresponding tasks

In our approach the algorithm is designed to splitthe planning and evaluation of (sub-)paths into multiplesmaller tasks, which we see as the key to having ageneric set of functions. By breaking down these twoproblems into smaller parts, our algorithm can be seenas a framework where each metric may provide its ownfunctions and rule sets. Our goal is to describe this genericapproach, not to provide an explicit formulation of QoS-requirements and metrics. An example of how our conceptmay be instantiated will be given in Section VIII.

A. Routing procedure

The routing procedure consists of a routing algorithm,which is broadly seen as the very core of every routingapproach, and communication patterns in the form of acommunication model. The purpose of a routing algorithmis to choose between different available connection seg-ments and select those, which will form a path betweentwo endpoints. The details of our algorithm can be foundin [1]. In this paper our focus lies on the interactionbetween components of proposed solution.

Our routing procedure is dedicated to find and establisha path in advance, with an explicit planning phase, beforeuser data can be sent.

As our approach shall not require SPs to share theirentire topology knowledge with each other, there needsto be interaction between SPs so that viable paths can befound, requested and managed. Communication patternsdescribe how routing instances interact with each otherand when information is to be requested from another SP,as we aim to keep information exchange to a minimum.Communication relationships also describes how manage-ment functions of involved connection segments will beconnected and consolidated in order to be offered to thecustomer.

Basically, we distinguish between source routing androuting by delegation. While source routing in its extremeform means that the entire routing is performed by thecustomer’s service provider, routing by delegation allowsan SP to ask another SP to find a (sub-) path for theremaining part of the route. Through the combination ofthese two techniques the routing procedure can adapt to

policy constraints, concerning the information exchangeof SPs.

B. Operations on properties

A generic function scheme is required to specify andevaluate boundaries and optimality criteria for differentkinds of quality requirements. The example in Section I-Aincludes bandwidth and maintenance window as qualityrequirements on the requested connection. Bandwidth islimited by the capacities of involved physical links. Thelink with the lowest capacity determines the maximumbandwidth achievable on a path. Requirements on main-tenance windows are less straight forward than on band-width. In the case of maintenance windows upper andlower boundaries for maintenance planning as well as theduration of maintenance work are specified. Clearly, analgorithm needs a different set of operations to reasonon maintenance windows in contrast to bandwidth. Thegeneric function scheme provides a common interface,so that specialized operations for each parameter may beaccessed by the algorithm in a unified manner.

Thus the main goal of our function scheme is toenable the algorithm to take all possible kinds of metricsinto account. The most important part of this task isdefining the semantics of our proposed generic functionsto ensure compatibility of metrics and interoperabilitybetween communication partners. Another part of this taskis providing a method for representing QoS-requirementsin our information model.

C. Information model

Existing information models (IM) often neglect theimportance of inter-domain connections. Even thoughinter-domain connections are comparatively small partsof the overall path, their quality is indispensable for thecomputation of the overall end-to-end quality. Due to veryrestrictive SP policies, each SP usually has access only toits end of an inter-domain connections. There are cases inwhich it is possible to derive the properties of inter-domainlinks from two partial views onto the same physical link,like available resources on that link. For such cases ourIM provides the possibility to describe partial views ofdifferent SPs and means to correlate these views.

We designed our information model to describe linkproperties similarly to connection requirements, whichallows us to use the same data model for both. This easesinteraction between peer entities as a conversion fromrequirements to resources is not required, thus leaving lessroom for misunderstandings and different interpretations.Also, to uniform information exchange, our informationmodel includes management functions so that they canbe treated like any other QoS-parameter in the routingprocedure.

IV. RELATED WORK

Our presented work covers many aspects in orderto provide end-to-end links with user-defined quality-requirements and management-functions. Even thoughmost of the problems outlined in Section II have been

5

65



addressed in previous work, none of them covers the topicin a full extend.

Originally, physical line switching technologies wereused in PSTN networks. In ATM, logical line switch-ing in combination with resource reservation has beenimplemented. As these technologies were tailored to fitthe needs of the voice-only telephony, they do not offerthe required flexibility of novel services provided over,for example, the Internet. In this area of (virtual) circuitswitching, the Dynamic Circuit Network (DCN) coopera-tion is probably the most advanced research project. Themain focus of this project is on the dynamic provision-ing of dedicated paths, literally guaranteeing bandwidthto customers [4], [5]. Among others, projects like OS-CARS [6], DRAGON [7], Phosphorus [8], and the Geant-developed AutoBAHN [9] are involved in this cooperationand several successful demonstrations have been presentedto the research community [10]. Another approach toon-demand circuit provisioning is the DICE (DANTE–Internet2–CANARIE–ESnet) [11] collaboration of Euro-pean and North American research networks, where anarchitectural concept, based on the experience gained inprevious projects has already been elaborated and pub-lished [12].

The mentioned projects and collaborations are focusedprimarily on two aspects:

1) various techniques and technologies for dynamiccircuit switching and resource reservation within a singleadministrative domain and

2) interoperability between the developed managementsystems as well as between networking technologies usedin these domains in order to automatically switch multi-domain network connections.

Plans for the consideration of QoS parameters arelimited to sole connection propert – its bandwidth. Man-agement aspects in dynamically provisioned circuits arelimited to circuit monitoring, mostly reusing praxis ap-proved concepts of the Geant E2E Link Monitoring Sys-tem (E2Emon) [13]. DICE plans to extend this monitoringconcept with a combination of measurements at differentnetwork layers and with different monitoring techniques.

An advanced example of network connections withcustomer-tailored properties is the Geant E2E Links ser-vice (also referred to as Geant Lambda) [16], [17]. Amongother scenarios, Geant E2E Links have been used to real-ize challenging connections for the international researchproject Large Hadron Collider (LHC) [14] and for the Gridcooperation DEISA [15]. These links were establishedconsidering multiple QoS parameters as well as manage-ment aspects, like inter-domain trouble-shooting proce-dures or the coordination of maintenance windows amongmultiple SPs. The biggest drawback of this approach isvery long connection establishment time, as these linksare planned and set up manually. As planning of GeantE2E Links might consider potential possible connectionsfor which infrastructure still have to be procured, installed,and configured, estimating the time necessary to find andset up a path between two endpoints is very difficult. In

the case of Geant E2E Links, the time between circuitordering and service production start – influenced bydifferent factors – can vary between a few weeks andseveral months [36].

Management of end-to-end multi-domain network con-nections is mostly limited to monitoring in the form oftechnology specific solutions, e.g., the well-establishedmonitoring in SDH networks [21]. Another, still emergingtechnique is OAM (Operations, Administration, and Man-agement) for Ethernet [22], which aims at a wider scopethan merely end-to-end monitoring. For example, failuresignaling has already become part of OAM for Ethernet,which allows for quicker detection of and reaction tocomponent failures along the entire path. The more genericmulti-domain solutions, like the E2E Monitoring System(E2Emon) for Geant E2E Links, are currently limited to aproject-specific combination of technology-agnostic QoSparameters [13].

The routing is mostly covered in the graph theory. In agraph that models a network as vertices and edges, QoS-parameters on path segments are usually represented asedge-weights. Established routing algorithms are based onBellman’s optimality principle and find paths between twovertices. Bellman’s optimality principle is valid for theclass of functional equations of finding the maximum, theminimum or the k-th element [25]. As this class requires(at least) a partial ordering of the domain, these algorithmsare not applicable for multi-dimensional search-spaces andespecially multi-weighted graphs. The different weightson a single edge cannot always be merged to a singleone. The example in Section I-A includes requirementson bandwidth and maintenance windows. As bandwidthrequirements cannot be converted to maintenance windowrequirements and vice versa, a partial ordering over bothweights cannot be found and Bellman’s optimality princi-ple cannot be applied here.

Proposed algorithms that are capable of searching high-dimensional spaces, e.g., SAMCRA [27] or H MCOP[28], require full information about network topology, linkproperties and connection properties. This make them in-applicable for multi-domain routing, as it collides with therestrictive information policies of most SPs and maximisessearch-space.

Routing algorithms operate on information about avail-able connections or connectivity possibilities. One of thebiggest problems of information models (IM) for networkdescription is data-hiding. For instance, the CommonInformation Model (CIM) [31] focuses on the descriptionof relations between services and underlying networktechnologies. While the CIM is a very good basis for man-aging single networks it cannot be used for our purposes.Modelling a connection segment with QoS-parametersrequires modelling of the entire network the segmentresides in. In order to comply with the strict informationpolicies in multi-domain environments, networks needto be modelled abstractly with hardly any information.This cannot be accomplished using the CIM and otherinformation models.

6

66



Furthermore, almost none of the IMs used for networkdescriptions associates multiple abstract properties withconnections. One noticeable exception is the ITU-T rec-ommendation G.805 for the description of optical transportnetworks [30], where multiple technical connection prop-erties can be associated with a single connection. In therecommendation these are only technical parameters thatare needed to interconnect the segments, e.g., multiplex-ing of different channels. Especially this recommendationdoes not consider connection’s quality and managementfunctionality properties.

V. INTER-DOMAIN MANAGEMENT-AWARE ROUTING

The main task of routing is always path selection. Asmentioned at the beginning of this paper, in order toguarantee end-to-end requirements, the required propertiesof all segments have to be planned. This includes con-sidering the management functionality needed in furtherphases of the service instance’s life cycle. Our proposalfor routing and defining of quality targets for the chosensegments is presented in Section V-A. As has already beenpointed out, an integral part of management-aware routingis the integration of management functionality providedby involved domains into integrated overall managementfunctionality for the whole service instance. We analysethese integration aspects in Section V-B.

A. Connection planning

As the routing procedure operates on knowledge aboutavailable potential connection segments, we introduce ourinformation representation to the extent we deem neededto understand our routing proposal. An elaborated discus-sion of our information model and an elaboration of ourdecisions will be given in Section VII.

The routing procedure we propose operates on semi-global knowledge about available connections. All thisinformation is represented at the abstraction level of anSP’s organizational domain. This means that we lookonly at connections between network equipment installedat administrative edges of provider networks. In general,all connections which can be realized either within asingle SP’s domain or interconnecting two neighboringSPs are potential connection segments of an end-to-endconnection. As from an SP’s point of view every realizedconnection segment is a provided service, we refer to anendpoint of a segment as Service Connection Point (SCP).We choose this abstraction in order to be independent ofnetwork technologies and of application areas in which ourrouting concept can be applied. A SCP can be mappedto various “edge-components”, from a logical UNI/NNIinterface when looking at paths through the Internet,to a Point of Presence (POP) when planning backboneconnections.

Semi-global knowledge means that for routing we needinformation over multiple, but not necessarily all, SP-domains. This knowledge can be extended on demand, byrequesting additional information from other SPs. Con-sequently, during routing we distinguish between already

Service Provider (SP) boundary

Known Service Connection Point (SCP)

Unknown Service Connection Point (SCP)Known connection segment, part of route Known realizable connection segment

Unknown realizable connection segment

1,3

1,1

1,2

2,12,2

2,3

2,4

2,5

3,13,2

3,3

5,1

4,2

SP1

SP4

SP2

SP3

SP5

4,1

Figure 4. Semi-global knowledge about available connection segmentsat the beginning of routing [1]

known connection segments and existing but not (yet)known connection segments. The same applies to SCPsof those segments. Further, some of the known connectionsegments can be considered by the routing algorithm as apart of the planned route.

Corresponding to the example presented at the beginof this paper, Figure 4 presents a possible initial semi-global knowledge of SP1. In this figure, SCPs are labeledwith IDs. These IDs consist of two numbers, where thefirst number identifies the SP to which a SCP belongsand the second number is a sequential numbering of SCPswithin an SP. Please note that we have chosen this IDrepresentation only for the sake of better readability andreference in this paper.

Due to various factors, e.g., steady ordering of newand decommissioning of existing end-to-end connections,the resources available to possible end-to-end connectionschanges constantly. The consequence is that an SP cannotexpect to have up-to-date knowledge about all availableconnection segments. At the same time every SP alwayshas exact knowledge about its own network equipment andavailable capacities. We further assume that every SP canobtain information about capacities available to intercon-nections with neighboring SPs. We see this as a commonsituation for most SPs, as such information is requiredfor proper management of the own network infrastructure.Further, we assume that every SP can determine the qualityproperties that can be guaranteed over all available ownlinks.

For instance, in Figure 4 SP1 is in charge of routingbetween SCPs with IDs ”1,3” and ”3,2”, it can choosewhich connection segments should be considered as a partof the path. When selecting these segments SP1 relies onknowledge about available capacities and own preferencesregarding which neighbouring SP to use. At the same timeSP1 has to consider customer requirements, i.e., for allconsidered paths the realizable connection properties must

7

67



be computed and compared with the user-provided end-to-end requirements. If, at least, one of the end-to-endrequirements cannot be fulfilled, another (for the SP lesserpreferable) alternative must be considered in the same way.

In the case when SP1 selects the way through SCPs”1,1” and ”2,1”, it also implies that the next segmentis realized by SP2. In [1] we discuss advantages anddrawbacks of different routing strategies. Based on thisdiscussion, we recommend the source routing strategy aslong as possible. This means that, in this particular case,despite the fact that the next segment is realized by SP2,the selection of this segment for the end-to-end connectionshould be done by SP1. This in turn means that SP1

has to obtain actual information from SP2, containingthe “remote” SCPs through which SP2 is willing torealize connection segments and which properties can beguaranteed for these segments.

We see two main advantages in using source routingstrategies: 1) avoiding (or reduction of) nested communi-cation relationships speeds up the overall communicationprocesses and decision propagation, and 2) retrieved in-formation about available connection segments and theirproperties can be reused, if alternatives have to be exam-ined. Nevertheless, employing source routing requires hightrust relationships between communicating SPs. Especiallyin big open provider collaborations, e.g., the Internet or thePSTN-network, this is not always the case. To meet thisproblem we propose on-demand delegation of the routingtask for the remaining part of a path. This is based on thepraxis approved theory, that SPs are more likely to trusttopologically closer SPs and especially all neighbouringSPs.

Similar to a CSM interface (see Section I), whichis commonly referred to as the management interfacebetween provider and customer, we introduce the DomainService Management (DSM) interface as a means forcommunication between independent SPs interested ina collaborative realization of end-to-end network con-nections. Communication between SPs should always beperformed through the DSM interface.

As mentioned in Section III, obtaining informationabout SPs’ available capacities, as well as making de-cisions about segments from outside an SP will mostprobably violate domain policies. In order to avoid or atleast minimize violations of these policies, we proposeto specify always strict boundaries for requests. Whenrequesting a segment, the requesting SP provides informa-tion about the remaining part of the end-to-end path, i.e.,the two determining SCPs between which the path still hasto be established, and about the connection properties theend-to-end path has to comply to. Such procedures allowqueried SPs to provide only few alternatives matchingthe specified restrictions, as opposed to providing fulland unreflected information about an SPs infrastructure.Furthermore, we propose that the queried SPs providethese alternatives in the most-to-least preferable order.Even though misuse cannot be fully avoided, we proposethat the SP responsible for routing (in the example SP1)

1,3 3,2E2E-QoS

DSM

SP-DomainSP1

REQUEST SERVICE ROUTING

SP-DomainSP2

DSM1,3

SP1SP-DomainSP3

DSMTopology:

•From (SCP): 3,1•To (SCP)….: 3,2

E2E-Requirements:

•Bandwidth: 1Gbps•Delay: 40 ms•…

Intermediate :•Bandwidth: 1Gbps•Delay: 35 ms•…

Figure 5. On-demand delegation of the routing task [1]

tries the alternatives in the specified order.In our example, if SP3 refuses to provide information

about available connection segments, SP1 can delegate therouting task to SP2 (see Figure 5). In this case topologyrestrictions, customer specific end-to-end requirements aswell as properties realizable by the found partial path arepassed to SP2. Advantages and disadvantages of routing-by-delegation are opposite to those of source routing:information about SPs’ available capacities are hidden andthe selection of the most preferable route is guaranteed.On the other hand, communication becomes to be nestedand information about previously checked alternate routescannot be re-used, which might lead to redundant checks.

Our proposed routing procedure incorporates not onlythe principles for the selection of the next connectionsegment, but also communication between SPs neededfor information requests and delegation of the routingtask. These advanced considerations make it impossibleto describe our procedure as a pure pseudo code alone.Instead we define a state-machine (see Figure 6), showingplanning-phases as states and outcomes as transitions.Beginning with an intermediate SCP that is at the end ofthe path considered so far, the next connection segment isdetermined. If required information is missing, a plannerenters an information-retrieval phase (A2) where the miss-ing information is requested from a SP. After calculatingthe properties of the entire path, including the new nextsegment, these properties are evaluated against end-to-endrequirements. If at least one of specified requirements isviolated, an alternative segment has to be considered. Ifrequirements are fulfilled, the distant SCP of the newsegment is considered as a new intermediate SCP andthe planner returns to the starting state (A1). We need tosupport the case that an information request is rejected. Inthis case, the routing task is delegated by a FINDROUTE-request to the last SP in the considered path (A5). Ourprocedure terminates, i.e., reaches an accepted end-state,either when the desired endpoint is reached or no morealternative connection segments are available.

As it is very common for the description of an algorithmto discuss its runtime analysis, please note that the main

8

68



Figure 6. Routing processes

purpose of any algorithm is to achieve its goals. Thereforethe quality of an algorithm should not only be evaluatedthrough the performance of an implementation, but primar-ily through the quality and the properties of the yieldedresult. In order to provide such an evaluation of our pro-posal, we point at the order in which connection segmentsare considered for a new route. Regardless whether sourcerouting or routing by delegation is used, consideration ofavailable segments is identical to the Depth First Searchprocedure. In this procedure, alternatives are consideredin an SP-specific order of preference. A criterion forconsidering an alternative is not fulfillment of at leastone specified end-to-end requirement. Consequently, theproposed procedure is nothing else but an inter-domainpolicy-based routing procedure considering end-to-end re-quirements.

B. Tying management functionality together

Experience shows that quality guarantees are only pos-sible to hold if the planned quality targets are leveragedby management procedures. The management of a serviceinstance is in turn only possible if the management of allits integral parts is possible. Therefore two of the centralpurposes of management-aware routing are the definitionof management functionality of each involved connectionsegment and its integration into the overall managementof new multi-domain service instances.

In a multi-domain environment, direct access to thenetwork infrastructure of any SP is in general not possible,as this is very likely to violate provider policies. There-fore the integration of management functionality meansnegotiation of communication interfaces and responsibilityareas as well as communication relationships with allinvolved SPs. The possibility to negotiate communicationrelationships and responsibility areas for each connectionshould influence the acceptance of our approach positively,as we give SPs a framework through which they can con-trol information- and command-flows. Negotiating DSM

interfaces is an essential part of integrating managementfunctionality and should be performed during the negoti-ation of other relevant connection segment properties likeQoS parameters and management functionality.

Very important for tying together management func-tionality is the possibility to specify one or more DSMaddresses by information requests. Representation of infor-mation by inter-domain communication will be discussedin Section VII. DSM address is presented in class COM-MUNICATIONDSM (see Figure 11). This enables SPs tospecify multiple communication interfaces for differentpurposes, e.g., regular information requests, monitoring orevent-triggered notifications. Concerning the confirmationof requests, SPs providing connection segments shouldalso specify communication interfaces for their manage-ment functionalities. Furthermore, this will guarantee flex-ibility to SPs to separate interfaces for service instancenegotiation and operation, as well as to specify differentinterfaces for different customers and/or service instances.

Every SP providing a connection segment as a part ofoverall end-to-end service, is responsible to ensure theagreed quality targets are met and to provide managementfunctionality through the negotiated interfaces. For theintegration of management functionality we define thateach SP is in charge, i.e., responsible, for the area forwhich it has performed the routing task. To illustrate thiswe refer to the example in Figure 4, outlined before. In theexample the final path is going through the SCPs with IDs”1,3”, ”1,1”, ”2,1”, ”2,2”, ”3,1”, and ”3,2”. Since routinghas been delegated to SP2, the example has multipleresponsibility areas, depicted in Figure 7.

We propose to distinguish between two types of re-sponsibility delegation. Following the first option, whichwe call FullProxy, in our example SP2 would build anabstraction layer, hiding the entire remaining part of thepath from SP1. This means that both, build-up and tying ofmanagement functionality, is hidden by the proxy-SP andSP1 has no direct control over them. The main advantage

9

69



SP-Domain SP1

SP-Domain SP2

SP-Domain SP3

Responsibility: SP1

Responsibility: SP2

Figure 7. Responsibilities for function integration in example

SCP1,3 – SCP1,1 SCP1,1 – SCP2,1 SCP2,1 – SCP2,2 SCP2,2 – SCP3,1 SCP3,1 – SCP3,2

SP-Domains Integrating Management Functionality

SP-Domain SP1

SP-Domain SP1

Proxy-SP SP2

SP-Domain SP2

SP-Domain SP3

SP-Domains Providing Management Functionality

Co

nn

ecti

on

Se

gm

ents

Figure 8. Communication relationships by FullProxy option

of this option is the best possible compliance with re-strictive SP policies. Therefore we see this option (similarto the applicability of the routing-by-delegation) as analways feasible one. The disadvantages of this option areillustrated in Figure 8. The most apparent disadvantage ofthis option is the increase of communication hops betweenSPs, due to nested communication relationships, whichwill lead to increased reaction times. Another significantdisadvantage is the increase of intermediate processing byproxy-SPs. Finally we want to point out the inevitabledeviation of reaction time by connection parts with directconnection of management functionality, e.g., negotiatedusing source routing, and connection parts with nestedintegration of management functionality, e.g., negotiatedusing routing-by-delegation with FullProxy option. Suchdeviation not only decreases the overall end-to-end per-formance, but also might require special treatment withrespect to the realization of such a solution.

Therefore we see the necessity to introduce a seconddelegation option, which we call TransparentProxy. Usingthis option it is possible to signal the proxy-SP that thecommunication interfaces for management functionalityspecified by the requester should be re-used during reser-vation and ordering of the delegated part of the path.The biggest advantage of this option is the possibilityto keep communication relationships as flat as possible.As SP-policies might restrict acceptable communicationrelationships, e.g., only to neighboring SPs, this optionmay not always be feasible. Therefore, we see the Full-Proxy option as a fallback solution, similar to routing-by-delegation being a fall-back solution for the case whensource routing is not applicable.

VI. GENERIC QOS-OPERATIONS

During the routing two operations are needed: 1) thevalues of connection segments considered as a part of theroute should be aggregated; and 2) the aggregated valueshould be compared with the E2E requirements. All theseoperations have to be performed on the properties (andproperty combinations), which are relevant for the partic-ular customer request. In Section VII we will show, howvarious connection properties (and their combinations) canbe described in a similar fashioned way. Unfortunately,the similar fashioned description alone is not enough forthe similar fashioned operations on those properties. Thereason is the various semantics of the values related tovarious connection properties. For example, operationsneeded for aggregation and comparison of delay valuesare not applicable for other very important QoS parameter– bandwidth. The same can be said about operations onother properties, e.g., on maintenance window.

In order to deal with this problem, in [2] we havedefined a generic function schema, which enables treat-ment of various connection properties and their combina-tions in a similar fashioned way. The basic idea is thatall parameters are distinguished bases on global uniqueIDs. Further, all IDs for every supported qualitative andquantitative QoS parameter as well as for managementfunctionality and its property should be defined in aregistration tree. This opens possibilities to specify forevery property ID a set of functions needed for operationson it (see Figure 9). The functions AGGREGATE LINKSand ORDER COMPARE are used to aggregate and com-pare values of a single property. These functions operateon properties of connection segments, and are thereforerelevant for the routing procedure described in Section V.The reasons for the remaining three functions are slightlymore complex. Due to restrictive SP policies, access to thenetwork equipment is generally impossible from outsideof one’s own SP. Function AGGREGATE LINKPARTSis needed for computation of properties by segmentsinterconnecting two neighbor SPs (so called Inter-DomainLinks). This function is needed because in general nodirect access to the network infrastructure of the neighborSP is possible, and consequently both SPs have only own(partial) knowledge about properties, which can be guar-anteed by a particular Inter-Domain Link. The remainingtwo functions ( SELECT BEST and SELECT WORST)are needed for operation on value ranges, which can bespecified by SP as realizable connection property. Valueranges can be used instead of specifying multiple connec-tion segments between same two SCPs with associatedfixed values. For a more elaborated discussion about theneeds and application areas of these functions please see[2] and [3].

The association of these functions with property IDsenables the similar fashioned operations on various prop-erties. This means that during the routing for every relevantproperty the corresponding functions can be obtainedbased on property ID. Subsequently, these functions canbe used to operate on the values of the properties, which

10

70



have been specified for connection segments.

Associated Functions_Order_Compare

_Select_Best

_Select_Worst

_Aggregate_Links

_Aggregate_LinkParts

Figure 9. Association of functions with a property ID in the registrationtree [2]

The described functions are always associated witha single property. In order to operate on the customerspecific property combinations, we derive operations onmultiple properties based on single-property operations.The aggregation of multiple properties is straight forwardand is defined as a combination of per-property aggre-gations. The comparisons of property combinations is,however, more complicated. The reason is the possibilitythat by comparison of two value-combinations some ofthe properties in the first and some other of the secondcombination are better. This situation is reflected in thedefinition for comparison of value combinations (see Fig-ure 10). The ”≺” symbol is used here to denote whichvalue is better.

route has to be compared to these constraints during the pathfinding process. For path optimization it is also necessary tocompare the values of two alternatives in order to choosethe better one. In opposite to the case classically treated ingraph theory, the meaning of what is ”better” might varybetween different QoS parameters. Regarding the examplesmentioned above, for bandwidth a bigger value can beconsidered as a better one, however for delay a smaller valueis the more preferred one.

Consequently, with each supported connection propertyoperations for value aggregation and comparison have to beassociated.

B. Associating operations with properties

In IT industry, new technologies and services are evolvingvery fast. Therefore prior the association of operations withproperties, a distinction between existing and upcomingproperties is needed. We propose to assign a globally uniqueID to each supported property. In order to ensure the globaluniqueness of IDs, we propose to use a registration tree.Additionally to the distinction between properties, using aregistration tree has another very important advantage. Asmultiple functions have to be associated with each supportedproperty, it can be realized by the definition of the functionstogether with the registration of their property-ID (see Figure2). Additionally this will ensure the identity of functionsused among multiple SPs.

Associated Functions_Compare

_Aggregate

Figure 2. Registration tree example

C. Comparison and aggregation of multiple properties

Based on the previous definition, we introduce an ap-proach for the handling of m different properties with theglobal unique IDs ID1, . . . , IDm. In graph theory, it is acommon practice to use vectors in order to describe multipleweights associated with a single edge or a path in general.For any path in a graph with m properties, the weight canbe specified as

−→U ::= (u1, . . . , um) ∈ Rm. In this definition,

uj is the weight of the jth property with IDj . The order ofproperties in the weight vector can be arbitrary, as long asthe placement of the properties is identical among all weightvectors. Further, for the edges of a path being enumeratedfrom 1 to n, the weight of an edge with index i will bereferred to as follows

−→W i ::= (wi

1, . . . , wim) ∈ Rm.

In order to calculate the weight vector−→P of the path

consisting of n edges with weights−→W 1, . . . ,

−→Wn, we first

introduce an aggregation function for two weight vectors asfollows:−−→

Aggr(−→U ,−→V)::= (Aggr1(u1, v1), . . . ,Aggrm(um, vm))

This definition is based on m aggregation func-tions for each property. The aggregation functions Aggri(i = 1, . . . ,m) are functions associated with the propertyID in the registration tree. We assume that all propertiesare independent of each other, i.e., they can vary withoutinfluencing the values of other properties. Furthermore, weassume that the binary operations defined by aggregationfunctions fulfill associative and commutative laws. Then weinductively define the computation of the whole path weightfrom weights of involved segments as follows:−−→Aggr

(−→W 1, ...,

−→Wn

)::=−−→Aggr

(−−→Aggr

(−→W 1,−→W 2), ...,−→Wn

)

Similar to the aggregation, we define the comparison ofproperty vectors based on the comparison between identicalproperties. Corresponding to the non-dominance concept asit is described in [4], we define that vector

−→U is better than−→

V if and only if all properties in the first vector are betterthan the corresponding properties of the second vector. Inorder to depict that property ui of vector

−→U is better than the

corresponding property vi of vector−→V , we use the symbol

”≺”. In contrast to the comparison of single values, it ispossible that some properties of the first vector are betterand some others are worse than of the second vector. Thissituation should be treated as indefinite. We depict this withsymbol ” 6=”. The comparison of two property sets can thusbe defined as follows:

−−−−−−→Compare(

−→U ,−→V ) ::=

=, if ∀1 ≤ i ≤ m : ui = vi

≺, if ∀1 ≤ i ≤ m : (ui ≺ vi

∨ ui = vi) ∧∃1 ≤ j ≤ m : uj ≺ vj

�, if ∀1 ≤ i ≤ m : (ui � vi

∨ ui = vi) ∧∃1 ≤ j ≤ m : uj � vj

6=, if ∃1 ≤ i ≤ m : ui ≺ vi ∧∃1 ≤ j ≤ m : uj � vj

IV. TREATMENT OF VALUE RANGES

Some important aspects that are typical for computer net-works are not directly addressed by classical graph theory. Inthis section we propose the treatment of value ranges, whichcan be associated with connection segments (graph edges)instead of multigraphs with multiple alternative connectionsegments with different fixed values.

Figure 10. Comparison of property-combinations [2]

Even though in the presented paper these functions havebeen motivated by their necessity during the routing, theirapplication area is much broader. For instance, they can beused for the monitoring of already established connectionsand the comparison of monitored values against designatedtargets.

The definition of similar fashioned operations on con-nection properties has several advantages. Among the mostimportant is the easiness of extensibility for the supportof new connection properties. Furthermore, by extendingproperty support no changes or adaptation in implementedrouting algorithm will be needed. And finally, if a globalregistration tree is used among all SPs for property IDsand function definition, operations on property values andtheir combinations will be identically among all SPs.

VII. INFORMATION MODEL

The basis for every routing is the knowledge aboutavailable connection segments and their properties. Asdescribed in Section V, during the routing missing infor-mation has to be requested from the other SPs. In orderto comply with SP’s information policies, the requestedinformation has to be restricted strictly to the neededinformation. Figure 11 describes how the requested prop-erties of the segment can be specified. In order to supportuser-specific E2E requirements, various combinations ofrelevant properties can be used within the REQUESTED-PROPERTIES class. We distinguish between tree kindsof properties: Qualitative QoS parameters, quantitativeQoS parameters, and management functionality (reflectedcorrespondingly in classes QUALITATIVEQOS, QUANTI-TATIVEQOS, MANAGEMENTFUNCTIONALITY). The dis-tinction between various properties is made based onglobally-unique IDs. This is a basis for a similar-fashionedtreatment of various parameters, as it is described inSection VI. With management functionality class combi-nation of properties (class PROPERTY) can be associated.This class is used for specification of different manage-ment function specific properties, e.g., polling interval formonitoring. Similarly to QoS parameters, the distinctionbetween properties is made based on its IDs. Finally,values (class ASSOCIATEDVALUE) can be associated withquantitative QoS parameters and with properties of man-agement functionality.

AssociatedValue

+ ValuesType_ID

SingleValue

+ Value+ Me tric

Quali tativeQoS

+ QoS_ID

QuantitativeQoS

+ QoS_ID

ManagementFunctionality

+ Function alit y_ID

Property

+ Property_ID

RequestedProperties

+ Service_ID+ UncertainityTyp e_ID

TimePeriod

+ Be gin+ En d

CommunicationDSM

+ DSM_ Addr

1

***

1 *

1

Figure 11. Specifying properties by service instance requests

If SP which can provide connection segments acceptinformation request, it has to provide own up-to-dateinformation. In our work we assume that every SP hasexact knowledge about its own network equipment and

11

71



available capacity. We further assume that every SP canobtain information about capacity available for intercon-nection with the neighboring SPs. We see this as a veryrealistically assumption for most SPs, as such information– among other – is required for proper management ofthe own network infrastructure. Further we assume thatevery SP can determine the quality properties which canbe guaranteed over available own connections.

The description of information is significantly morecomplex then information request, as it also should de-scribe various topological properties (see Figure 12). Ashas been discussed at the beginning of this article, anexpectation that SPs will share the information neededfor management of the own infrastructure (i.e., detailednetwork topology representation as well as capacity andusage of particular physical network connections) can beseen as a very unrealistic one. One of the most criticalaspects in a multi-domain environment is very restrictiveinformation policies. The omission of the collision withthose policies is the main reason, why the proposed routingprocedure operates on information at the abstraction levelof an SP’s organizational domain. Such a representationhides most realization aspects, like network topology,which strongly complies with the mentioned informationpolicies.

For the description of available connections threeclasses are used: COMPOUNDLINK, COMPONENTLINK,and COMPONENTLINKPART. The class COMPOUNDLINKis used as a wrapper for multiple alternative connectionsegments connecting the same two SCPs. Such a situa-tion can occur, for instance, due to alternative physicalconnections available between these SCPs. Even thoughsuch details are hidden from SP’s outsiders, they can resultin connection segments with different properties. Theclass COMPONENTLINK, which represents the connectionsegments, is associated with the class LINKPROPERTIES,which specify segment’s properties. The structuring ofconnection segment properties is identical to the one ofinformation request (see Figure 11). Finally, the classCOMPONENTLINKPART represents the SP’s view at anInter-Domain Link. As discussed in Section VI, every SPhas only information about quality guarantees realizableat the SP-facing side of an inter-domain connection.Therefore, the whole quality of such connections has tobe calculated from two views on it of involved SPs. Forthis purpose function AGGREGATE LINKPARTS has tobe associated with connection properties (see Section VI).

Every of these three connection classes interconnecttwo SCPs, which contain their globally-unique IDs neededfor segment stitching as described above. Further, everySCP is associated with a SP Domain in which it islocated. The reason is the necessity of SP responsible forrouting to communicate with those SPs, which can provideconnection segments. During the routing, considering anew connection segment as a part of the route impliesthat the next connection segment should be adjacent tothe distant SCP of the considered route. Information aboutsuch an adjacent segment can only be obtained from an

SP owning the mentioned SCP. In close collaborationsof very limited amount of SPs it can be assumed thatevery SP knows the interface to communicate with everyother SP. In open and/or highly dynamic collaborationsthis is not the case. We however assume that every SPcan maintain up-to-date information about communicationinterfaces of all its neighbors. Therefore by specifyingthe domain owning the SCP, a communication interfaceDSM ADDR of this SP should always be provided.

Domain

+ Domain _ID+ DSM_ Addr

SCP

+ SCP_ID

CompoundLink

ComponentLink

+ Componen tLink_ID+ Compone ntLinkType_ID

QuantitativeQoS

+ QoS_ID

Quali tativeQoS

+ QoS_ID

ManagementFunctionality

+ Function alit y_ID

TimePeriod

+ Be gin+ En d

AllowedValues

+ Allowed ValuesType_ID

Property

+ Property_ID

LinkProperties

+ Service_ID+ UncertaintyType_ID

ComponentLinkPart

+ Componen tLink_ID

MultiDomainManagementFunctionality1..*

*2

1

*

2

*

1..*

1

10, 2

*

1

1,2

*

2

def ine

*

*

Conne cted with

*

* *

0. .1

*

1..*

1

Figure 12. IM for available connections and properties of a single SP[3]

Finally, the MULTIDOMAINMANAGEMENTFUNC-TIONALITY class has to be mentioned. This class isderived from MANAGEMENTFUNCTIONALITY, whichenables the specification of multi-domain managementfunctionality in a similar fashioned way as it is done bythe management functionality of connection segments.This description is needed by the delegation of multi-domain management functionality, as it will be describedin Section IX-A.

The inter-domain routing procedure, which we havedescribed in Section V, operates on a semi-global knowl-edge, i.e., the knowledge spanning over multiple – butnot necessarily all – SP domains. At the same time, eachSP is only able to provide information about connectionsegments in which realization it is involved. This raisesthe question, how such single-domain views of differentSPs can be combined to semi-global multi-domain view?

If every SP can provide its view at the connection

12

72



segments it is involved in, deriving a multi-domain viewfrom a multiple single-domain views can be realized rel-atively easily. We propose that every SP, when specifyingsegments, always provides the IDs of two SCPs at itsends. It is necessary that these IDs are globally unique.Only then the SP responsible for routing can ”stitch” thesesegments at the SCPs with identical IDs together (seeFigure 13).

IdA1 IdA2

IdB2 IdB1

IdB3

Domain A Domain B

IdA1 IdA2 IdB2

IdB1

IdB3

Domain A Domain B

IdA2 IdB2 IdB2

IdA1 IdA2 IdB2 IdB1

IdB3

IdA2 IdB2

IdB2

(a) Single-Domain View

(b) Matching SCP-IDs

(c) Aggregated Multi-Domain View

Figure 13. Deriving a multi-domain view from single-domain views[3]

A more elaborated discussion about details of infor-mation model as well as about reasons for the selectedrepresentation can be found in [3].

VIII. PUTTING IT ALL TOGETHER

In in Sections V, VI, and VII we have described thethree building blocks of our proposal. In order to illustratehow elaborated concepts can be applied, we reuse theexample outlined at the beginning of this article. We recallthat in the example the customer has contacted SP1 andhas requested a connection between SCPs with IDs ”1,3”and ”3,2” with following properties:

• Bandwidth: 1 Gbps• Delay: max 40 ms• Maintenance

– Window: 600 – 1000 GMT– Duration: max 1 hr.

• MonitoringFrom the customer’s point of view, SP1 is the sole

provider of the E2E connection with the mentioned prop-erties. For the planning of a corresponding multi-domain

path SP1 needs routing functionality. Furthermore, inorder to comply with the outlined parameters also multi-domain Monitoring functionality is needed. As SP1 canprovide both functionalities, it can start the process offinding the route fulfilling all end-to-end customer require-ments.

DSM DSM

SP5

2,1

CSM

SP-Domain SP1

SP-Domain SP2

3,2

SP2

SP4

SP1

1,1

1,2

4,1

2,5 SP3

1,3

Figure 14. Global view at the available services

Figure 14 presents the situation after SP1 chose thepath through its own network. It still has to find theroute between SCPs ”2,1” and ”3,2”, but has no up-to-date knowledge about connections available in SP2.Consequently a request for information should be sendto SP2. As proposed in Section V-A, this informationrequest should be accompanied by the topology- andproperty-restriction. We recall that the main motivationof restricting requested information was the necessityto comply with very restrictive information policies. Anadditional positive effect is the significant reduction ofconnection segments, which have to be considered for theroute. This in turn speeds up the overall routing process.

1D:\Papers\IntTech11 (IARIA Journal)\inttech11‐git\pictures\unused\RequestInfoXML.xml

<RequestedProperties Service_ID="CS" UncertainityType_ID="Guaranteed"> <TimePeriod Begin="Now" End="OpenEnd"/>

<QuantitativeQoS QoS_ID="Bandwidth"> <AssociatedValue ValueType_ID="SingleValue" Value="1" Metric="Gbps"/> </QuantitativeQoS>

<QuantitativeQoS QoS_ID="Delay"> <AssociatedValue ValueType_ID="SingleValue" Value="140" Metric="ms"/> </QuantitativeQoS>

<ManagementFunctionality Funcitonality_ID="Maintenance"> <Property Property_ID="Window"> <AssociatedValue ValueType_ID="ValueRange" Min="0300" Max="0700" Metric="GMT"/> </Property> <Property Property_ID="Duration"> <AssociatedValue ValueType_ID="SingleValue" Value="1" Metric="hr"/> </Property> </ManagementFunctionality>

<ManagementFunctionality Funcitonality_ID="Monitoring"> <Property Property_ID="CommunicationDSM"> <CommunicationDSM DSM_Addr="dsm.domainSP1.com/mon/instance932/"/> </Property> </ManagementFunctionality>

</RequestedProperties>

Figure 15. Specifying needed properties in information requests

In Section VII we have presented how requested proper-ties can be structured (see Figure 11). For communicationbetween SPs, this structure has to be encoded. Currently,application-layer protocols are often built on top of SOAPcommunication. As the information in such communica-tion is encoded in a human-readable XML format, thissuits very well for illustration of concepts. Figure 15presents how the example specific information restrictionscan be represented in XML according to the proposedstructure. Please note that the proposed property structurecan be encoded differently.

13

73



DSM DSM

SP5

SP1

1,3

1,1

1,2

4,1

CSM

SP-Domain SP1

SP-Domain SP2

3,2

SP2

2,1

2,5

2,2

2,3

SP4

SP3


The structuring of the requested information has beendescribed in Section VII (see especially Figure 13). Byinformation request SP1 also specify its DSM addressfor monitoring functionality. This is a crucial aspect inorder to tie functionality together, as it has been describedin Section V-B. The representation in XML format canbe done similarly to the presented request. Please notethat regarding the answer, SP2 should provide own DSM-address(es) through which the monitoring functionalityof available connection segments can be reached duringinstance operation. These addresses might vary betweendefferent service instances due to various SP-internalreasons.

From To Route-Part? Property Value

SCP1,3 SCP1,1

Bandwidth 1 Gbps Delay 19 ms Maintenance Window 06:00-10:00 GMT Maintenance Duration 1 hr

SCP1,3 SCP1,2 -


SCP1,1 SCP2,1


SCP1,2 SCP2,5 -


SCP1,2 SCP4,1 -


SCP2,1 SCP2,3 -

Bandwidth 1 Gbps Delay 20 ms Maintenance Window 06:00-08:00 GMT Maintenance Duration 40 min

SCP2,1 SCP2,2 -


Table I

KNOWLEDGE TABLE OF SP1

According to the routing process specified in Figure6, up to now we have selected SCP ”2,1” as the nextintermediate SCP (action A1), have recognized that someinformation is missing, and therefore requested this infor-mation (action A2). Now we have to determine, whichconnection segment should be considered as next sectionin the path (action A3). Figure 16 depicts graphically theknowledge of SP1 after SP2 has provided the requested

information. Please note that the information about irrel-evant connection segments has not been provided at all.In order to illustrate the follow-up actions of the definedrouting procedure, in Table I we present the knowledgebase available to SP1 at this point of procedure. It containsimaginary values associated with properties of availablesegments as well as the flag whether the particular segmentis considered as a part of the route or not. Please note thatfor SP2 there is no need to provide information which isnot fulfilling the restriction.

According to the information provided by SP2, twoconnection segments are available. The most preferableone is the connection between SCPs ”2,1” and ”2,3”.According to the defined routing procedure, the SP re-sponsible for routing has to consider available connectionpossibilities in the most-to-less preferable order of theSP providing them. Therefore SP1 has first to considerthis connection possibility and therefore calculate theaggregated value of the partial route (action A4 in Figure6).

In order to calculate the path properties, aggregationfunctions for the relevant properties have to be accessedfirst. As described in Section VI, these functions areassociated with the property IDs. These functions can beused for semantic-aware operations on the values of par-ticular connection properties. This means that aggregationfunction is:

• min for the Bandwidth• addition for Delay• intersection for Maintenance window• max for Maintenance duration• Logical AND for availability of MonitoringUsing these functions and values from the knowledge

table we can calculate the properties of the intermediatepath going through SCPs ”1,3”, ”1,1”, ”2,1”, and ”2,3”(Action A4 in Figure 6). Now we have to compare the cal-culated multi-property value with the end-to-end customerrequirements. This is done again based on the functionsdefined for the particular properties (see Section V). Theresult of the comparison will be 6=, as the all propertiesexcept delay are better than the requirements, but therequirement for delay cannot be fulfilled by this path.Consequently, the next alternative connection segment,e.g., between SCPs ”2,1” and ”2,2” has to be consideredaccording. As the path going through SCPs ”1,3”, ”1,1”,”2,1”, and ”2,2” hold the requirements, its last SCP ”2,2”is chosen as next intermediate SCP (action A1) and theoutlined procedure can be repeated.

Let us assume that with the above outline procedurethe path fulfilling all end-to-end requirements and goingthrough SCPs ”1,3”, ”1,1”, ”2,1”, ”2,2”, and ”3,1” havebeen found (see Figure 17). This means that the followingsegment(s) can be only provided by SP3. As the infor-mation about available connection segments is missing,SP1 has to request this information from SP3 (action A2in Figure 6). Let us further assume that SP3 rejects thisinformation request due to some internal reasons. For thiscase our proposal foresees a delegation (action A5) of a

14

74



routing task to the last SP in the already found path, i.e.,in this case to SP2. Graphically this situation is depictedin the Figure 5.

DSM DSM

SP5

SP1

1,3

1,1

1,2

4,1

SP2

2,1

2,2

2,3 2,5

CSM DSM

3,1

SP-Domain SP1

SP-Domain SP2

SP-Domain SP3

SP3

SP4

3,2


If SP2 accepts the request for routing delegation, ittakes over the routing for the remaining part. It receivesinformation about end-to-end requirements, values whichcan be guaranteed by the intermediate route and two SCPsbetween which it has to perform routing. SP2 choses SCP”3,1” as its intermediate SCP (action A1) and proceeds asoutlined before. If the end point is reached, SP2 reportsthe properties of the whole found path to the requester ofthe routing task.

Please note that in order to tie management functionalitytogether, SP2 has to specify to SP3 the communicationDSM (see Section V-B). In the case of FULLPROXYdelegation, SP2 specifies its own address. In this case,if the route could be found, it also has to report its ownDSM to SP1. The provider SP2 should further aggregatemonitoring information of all following segments in itsown responsibility area. By this delegation option, SP2

provides SP1 exactly with the aggregated view.Regarding the delegation by using the TRANSPARENT-

PROXY option, during the routing in its own responsibilityarea, SP2 should specify for monitoring purposes theDSM address of SP1. Also, concerning the acceptanceof SP3 to provide the last segment, SP2 should report theDSM of SP3’s monitoring instance to SP1. In this caseSP1 is only responsible for routing but not for aggregationof monitoring information.

IX. DISCUSSION

In this section we will outline our thoughts aboutaspects going beyond the scope of the presented paper, buthighly related to the presented solution. At first we willdiscuss the delegation of management tasks to the trustedthird party SPs. Then in Section IX-B we will presentour thoughts about reservation and ordering of plannedroute. Section IX-C is dedicated to outline our view at theacceptance of the presented solution by SPs. Finally, inSection IX-D we will present positioning of our solutionamong other existing alternatives.

A. Delegating Multi-Domain Management Tasks

The discussion up to now has implicitly presumed thatevery SP-domain approached by the customer as well asevery proxy-SP can take over the whole functionality, like

routing and integration of needed management functional-ity. The practicability of such solution depends on differentfactors. Most important are the complexity and costs forthe development and maintenance of such solution byevery SP. To a large extent this might be influenced bythe utilization of the multi-domain functionality throughrequests for new and operation of established E2E con-nections.

In practice, two concepts have been often successfullycombined in order to cope with high complexity andcosts: specialization and sharing. A per se example is theDNS service, which is realized by specialized SPs andshared among SPs specializing on, e.g., content provi-sioning. Therefore we propose to support the delegationof multi-domain management tasks. As most commonmulti-domain management tasks, the following shouldbe mentioned: routing, monitoring, accounting, or outagelocalization. Figure 18 depicts the delegation of the routingtask. Instead of performing routing by themselves, asthis was defined in our original proposal, provider SP1

can delegate this task to SPR which should follow themanagement-aware routing procedure. Please note thateven if the trustworthiness of such specialized multi-domain management service providers might be very high,especially in large collaborations it does not necessaryeliminate the necessity of task-delegation to proxy-SPs.

SP-Domain Providing Multi-Domain Service

SPR

Multi-Domain Routing

SP-Domain Requesting Service

SP-Domain Providing Service

SP-Domain Providing Service

Customer CSM

DSM DSM DSM

SP1 SP2 SP3

Figure 18. Delegating multi-domain functionality to a third party

B. Route Reservation and Ordering

In packet switching, like in IP-networks, the routingis an all-including procedure, as it is combined with thepacket forwarding to the next hop which will be then incharge for further routing and forwarding. In line switch-ing, the situation is more complex and routing can be seenas a general plan which still has to be implemented. If theplan is not sufficient, than even perfect implementations ofit will not lead to the desired result; but even if the plan isperfect, it can be undermined by its bad implementation.Therefore we see the described management-aware routingas the most critical – but not sole – prerequisite for pro-visioning of multi-domain network connections compliantwith user-specific E2E requirements.

As we consider a multi-domain environment, the in-formation which is used during the routing is not only

15

75



semi-global, but also can be considered as not 100% up-to-date. This is mainly caused by concurrent requests, whichcan come from (in general various) SPs responsible forrouting of different connections. On the one hand, variousconnection segments considered for these connectionsmight be realized upon the same physical infrastructure.On the other hand, as a means for reduction of capitalexpenditure for infrastructure, every SP is interested inmaximizing resource usage. Consequently, in the timebetween the information request and the actual orderingof the selected connection segments, the needed physicalresources might be assigned to other service instances. Inother words, we face the multi-domain concurrency forthe same limited resources.

Various elaborated techniques are available for dealingwith the concurrency issue. The most common way toavoid conflicts and/or minimize deadlocks is the reserva-tion of the resources before their ordering. This techniquecan be also applied to concatenated services at the SPabstraction layer (see Figure 19). Every node in Figure 19represents the state of one service part, e.g., a connectionsegment, from the perspective of SPs responsible for theprovisioning of service instance. As the communicationbetween different SPs can only be performed via somecommunication protocol, the transitions arrows betweenstates are described with different kinds of requests. Pleasenote that these names only reflect the semantics of requestsand do not imply any suggestions for protocol implemen-tation.

Available

Reserved

InService

CHANGE

RESERVEDSERVICE

SERVICE

RESERVATION

DECOMISSIONING

CANCELRESERVATIONINFORMATION

MGMTFKT

Figure 19. State transition at multi-domain abstraction level

Even though the state transition by itself is quitecommon, two additional aspects have to be specified:1) behavior of SPs regarding requests for state transitionof a single service part; and 2) the way to apply suchrequests to multiple service parts.

Concerning the definition of SP’s behavior we proposeto reuse elements of bilateral and trilateral negotiationmodels, as they are described in [34]. More precisely, ifSPRS (RS for ”Requesting Service”) requests from SPPS

(PS for ”Providing Service”) the reservation of connectionsegment with a certain quality, SPPS should be able toconfirm the reservation with equal or smaller quality asrequested. This should cover the case if SPPS in thetime between information- and reservation-requests hasalready reserved some needed resources for a differentservice instance. After the reservation is confirmed, foreach reserved service part, SPRS should be able to requestits ordering. In this case, however, SPPS should be either

able to provide the quality equal or better than the oneconfirmed by reservation, or report the failure of ordering.

The outcome of the management-aware routing pro-cedure is a combination of connection segments alongthe route associated with the apparently feasible QoSthresholds. As all SPs providing those segments are alsoknown, simultaneous communication with all those SPswould be possible. Concerning the reservation of servicesegments we however argue against the simultaneouscommunication with all SPs. In this case, reduced qualityby reservation of a sole segment would automaticallylead to a violation of the E2E user requirements. In-stead, we propose to reserve segments sequential one-by-one from one endpoint to another one. In the casethat SPPS confirms reduced qualities, SPRS can try tobalance the performance degradation in one segment byincreasing the planned thresholds of remaining segments.For this purpose information obtained during the routingby information requests can be reused. If the balancingis not possible, a re-routing for the remaining part of thepath can be performed. If even this fails, SPRS shouldcancel reservations of all connection segments which havebeen already successfully reserved. In order to minimizereservation time, messages about cancelling reservationcan be sent simultaneously to all relevant SPs.

If reservation of all segments has been successful andE2E requirements are met, requests for ordering of thesesegments can be sent to corresponding SPs. As – corre-sponding to the proposed behavior – SPs may only pro-vide better quality than the confirmed by the reservation,requests for ordering can be sent simultaneously to all SPs.If at least one of SPs cannot fulfill its commitment, it willreport failure to SPRS . In this case SPRS has to cancelreservations of all remaining segments immediately.

Leveraging the proposed procedure for reservation andordering of connection segments along the found routewe score two goals: 1) first of all the fulfillment ofE2E requirements; and 2) minimizing the time neededfor resource reservation before a new service instance canbecome operational.

C. Examine SP-Acceptance for Elaborated Solution

As discussed in Sections I and II, the most criticalrequirement for an inter-domain routing approach is itsacceptance by SPs. In our proposal, this real world re-quirement has been reflected by considering SP interestsand restrictions.

As a proof of concept we refer to our experiencewithin the context of the Information Sharing acrossHeterogeneous Administrative Regions (I-SHARe) activ-ity [32]. This activity has been established in Geant inorder to foster information exchange during the manualplanning and operation of E2E Links. During the firstphase of this activity, requirements and constraints forthe (back then) upcoming tool had to be captured andcategorized. This has provided us with a deep insight intodemands and concerns of network service providers.

First of all the sharing of detailed network information

16

76



(such as network topology or overall available capacity)is commonly seen as unacceptable. At the same timeit is acceptable for SPs to exchange information aboutconnection segments at SP abstraction level, which arepossible for a particular planned E2E Link. Also exchangeof more detailed information with neighboring SPs is verycommon by connection planning. The information modeldescribed in Section VII directly reflect these aspects.As our proposal strives for automatic route planning, weexpect that multiple alternative service parts should bespecified in the order of the SPs’ preferences. Primarily, itshould simplify information management and also reducethe necessary number of communication steps. Severalinterviews with operators involved in the planning ofGeant E2E Links have shown the acceptance of SPs toprovide information about multiple service parts duringthe routing process, even it is not used in the establishedmanual processes.

By gathering of established in Geant manual routeplanning processes one further very important constrainthas been identified. The only true concern that has beenrepeatedly mentioned by operations of different SPs is thecompliance of the service part choice to the SP prefer-ences. The enforcement of this aspect has been reflectedin both routing modes outlined in Section V.

As our proposal can provide routing planning underconsideration of SP constraints, we are confident thatour solution can be broadly accepted by SPs. As it alsoconsiders the customer-specific E2E requirements andmanagement functionality, our solution opens for SPspossibility for delivering of high-quality network servicesto the customers.

D. Application areas and possible adaptations

Compared to the established connectivity-oriented rout-ing approaches, the proposed solution requires signifi-cantly more information, computations, and – which is themost time-consuming part – inter-domain communication.This statement is applicable not only to routing, but also tothe subsequent reservation and ordering processes. There-fore, it cannot be considered as a routing procedure for amass service, as it is the case by IP routing in Internet.Instead we suppose the application area of the developedalgorithm to be in the middle-scale niche between massservices, which are focused on a pure connectivity withbest-effort quality, and carrier-grade connections, whichare mainly manually planned very-long-term connectionswith dedicated quality specified in contracts (see Figure20).

The proposed solution can provide near-real-time plan-ning and ordering of a route with customer-tailored E2Econnection properties. This solution is applicable to sce-narios like video-on-demand, video-conferencing, on de-mand connectivity for Grid or cloud collaborations, andother areas in which customers demand (and often arewilling to pay) not only for the pure connectivity but alsofor the connection quality. Especially this is applicablefor scenarios like video-conferencing, where bad quality

2

Required

Time

Proposed

Solution

[seconds /

minutes]

Figure 20. Positioning of proposed solution

of one parameter (e.g., jitter) cannot be covered by anotherone (e.g., bandwidth).

Depending on the offered service and/or the specificsof the SP cooperation, the proposed algorithm can bemodified in order to improve its scalability. Particularly,we would like to outline the following two cases:

• If the connection service is only offered with QoSparameters that do not require E2E consideration ofall involved parts, e.g., bandwidth or data encryption,a routing-by-delegation approach can generally beused. Especially in combination with the simulta-neous resource reservation, it can prove to be veryscalable. A very good example for this strategy can beseen in telephone connections, which offer constantbit rate and low jitter.

• In the case of a small and especially very tight SPcooperation, the routing instance can be centralized.In this case only this instance performs the wholeE2E routing for all new connection requests, whichneglects the concurrence between simultaneously or-dered service instances. Consequently, the servicepart reservation can be omitted or performed simul-taneously. A similar strategy with a two-level routinginstances is used, e.g., in the DCN cooperation. Thisapproach corresponds to the source routing approach(see Section V), in which the routing task is alwaysdelegated to a central instance. The applicability ofthis approach, however, depends directly on the will-ingness of SPs to provide complete information aboutall available service parts to the routing instance andto accept its inter-domain manager role.

A further simplification can be applied for operationson supported properties. If only few properties have to besupported and no extension of support is planned for thefuture, the usage of a registration tree for the definitionof operations on properties can be omitted. This shouldsignificantly improve the performance of the implementedsolution. On the other hand, support of not yet consideredproperties becomes an issue again.

As a conclusion, the proposed solution is applicable inthe most challenging case of an open SP collaboration aswell as with a variety of customer-specific QoS parame-ters.

17

77



X. FUTURE WORK

As a mean to quality assurance for Concatenated Ser-vices, we have elaborated a novel conceptual solution con-sisting of three technology-independent building blocks.As the next logical step we see the evaluation of exist-ing technologies, whether and how they can be used toimplement the proposed solution. The desired outcome ofthis evaluation is a proposal for implementation of thepresented solution and its building blocks. In the case ifnot all concepts can be implemented, the missing func-tionality can be seen as requirements for future technologydevelopment.

The proposed solution covers only the connection plan-ning aspect during the ordering phase of service instancelife cycle. In order to support SP collaboration duringfurther phases, we plan to elaborate a proposal for inter-domain management processes. For instance, the method-ologies for E2E monitoring have to be defined, which isneeded for both monitoring of commitments’ fulfillmentand for problem localization. We see such processes as anessential part of the overall solution for CSs.

As the occurrence of outages cannot be fully excluded,strategies for handling them have to be elaborated. There-fore we plan to investigate the applicability of self-adaptation techniques as a strategy for the multi-domaincompensation of a single-domain quality reduction oroutages of service parts.

An additional aspect, which should not be neglected,is the consideration of security in multi-domain environ-ments. Therefore the integration of federated identity andtrust management into the management of CSs will be apart of our future research.

As stated at the beginning of this article, our work hasfocused on dedicated point-to-point connections. For thefuture, we also plan to evaluate the applicability of thedeveloped solutions to the establishment and managementof point-to-multipoint as well as multipoint-to-multipointnetwork connections with quality assurance.

ACKNOWLEDGMENT

The authors wish to thank the members of the MunichNetwork Management Team (MNM Team) for helpfuldiscussions and valuable comments on previous versionsof this paper. The MNM Team directed by Prof. Dr.Dieter Kranzlmuller and Prof. Dr. Heinz-Gerd Hegering isa group of researchers at Ludwig-Maximilians-UniversitatMunchen, Technische Universitat Munchen, the Universityof the Federal Armed Forces and the Leibniz Supercom-puting Centre of the Bavarian Academy of Science. Seehttp://www.mnm-team.org.

REFERENCES

[1] Yampolskiy, M., Hommel, W., Lichtinger, B., Fritz, W.,Hamm, M.K. Multi-Domain End-to-End (E2E) Routing withmultiple QoS Parameters. Considering Real World User Re-quirements and Service Provider Constraints. In ProceedingsThe Second International Conference on Evolving Internet,2010. INTERNET 2010, Valencia, 2010.

[2] Yampolskiy, M., Hommel, W., Schmitz, D., Hamm, M.K.Generic Function Schema for Operation on multiple Net-work QoS-Parameters. Submitted to The Second Interna-tional Conference on Advanced Service Computing, 2010.SERVICE COMPUTATION 2010, Lisbon, 2010.

[3] Yampolskiy, M., Hommel, W., Marcu, P., Hamm, M.K. Aninformation model for the provisioning of network connec-tions enabling customer-specific End-to-End QoS guaran-tees. In Proceedings 7th IFIP/IEEE International Conferenceon Services Computing, 2010. SCC 2010, Miami, 2010.

[4] Dynamic Circuit Network, Publications.http://www.internet2.edu/network/dc/publications.html [10May 2010].

[5] Internet2 How to Connect: Internet2’s Dynamic Circuit Net-work. http://www.internet2.edu/pubs/DCN-howto.pdf Whitepaper 2008.

[6] ESnet On-demand Secure Circuits and Advance ReservationSystem (OSCARS), Publications.http://www.es.net/OSCARS/ [10 May 2010].

[7] Dynamic Resource Allocation via GMPLS optical Networks(DRAGON), Publications.http://dragon.maxgigapop.net/twiki/bin/view/DRAGON/Publi-cations [10 May 2010].

[8] Phosphorus, Publications.http://www.ist-phosphorus.eu/publications.php [10 May2010].

[9] Automated Bandwidth Allocation across HeterogeneousNetworks (AutoBAHN), Bandwidth on Demand Deliver-ables.http://www.geant2.net/server/show/nav.1914 [10 May 2010].

[10] Joint Techs Winter 2009 TAMU DCN Demo.https://spaces.internet2.edu/display/DCN/Joint+Techs+Winter+2009++TAMU+DCN+Demo [28 May 2010].

[11] DICE (DANTE-Internet2-CANARIE-ESnet)Collaboration.http://www.geant2.net/server/show/conWebDoc.1308 [28May 2010].

[12] Proposed architecture for inter-domain circuit monitoring.http://code.google.com/p/perfsonar-ps/wiki/CircuitMonitoring [28 May 2010].

[13] Yampolskiy, M., Hamm, M.K. Management of Multido-main End-to-End Links; A Federated Approach for the Pan-European Research Network Geant 2. In Proceedings 10thIFIP/IEEE International Symposium on Integrated NetworkManagement, 2007. IM’07, Munich, 2007; 189-198.

[14] LHC - The Large Hadron Collider Homepage.http://lhc.web.cern.ch/lhc/ [10 May 2010].

[15] DEISA - Distributed European Infrastructure for Super-computing Applications Homepage.http://www.deisa.eu/ [10 May 2010].

[16] Aptet, E., Chevers, J, Garcia Vidondo, M., Tyley, S. GeantDeliverable DS2.0.3,3: Report on GEANT2 Ad-vanced Ser-vices - Lambdas and Switched Optical Geant2 technicalpaper 2009.

18

78



[17] Schauerhammer, K., Ullmann, K. OperationalModel for E2E links in the NREN/GEANT2 andNREN/Cross-Border-Fibre supplied optical platform.www.geant2.net/upload/pdf/GN2-06-119-OPConcept.pdfGeant2 technical paper 2006.

[18] Office of Governance Commerce (OGC) IT InfrastructureLibrary (ITIL). London, 2007.

[19] TeleManagement Forum (TMF) New Generation Opera-tions Systems and Software (NGOSS). 2004.

[20] Hamm, M.K. Eine Methode zur Spezifikation der IT-Service-Managementprozesse Verketteter Dienste 2009;

[21] Khurram, K. (Editor) Optical Networking Stan-dards: AComprehensive Guide for Professionals (1st edn). 2006;

[22] Brockners, F. Ethernet OAM Overview: Making EthernetManageable. In Proceedings 1. DFN Forum Kommunikation-stechnologien, Muller P, Neumair B, Dreo Rodesek G (eds).Kaiserslautern, 2008; 35-44.

[23] Ziegelmann, M. Constrained shortest paths and relatedproblems 2004;

[24] Hamm, M. K., Yampolskiy, M. IT Service Managementverketteter Dienste in Multi-Domain Umgebungen. Model-lierung und Teilaspekte. PIK Praxis der Informationsverar-beitung und Kommunikation 2008; 31(2):82-89.

[25] Bellman, R. The theory of dynamic programming. In Pro-ceedings of the National Academy of Sciences of the UnitedStates of America, 1952; 716-719.

[26] Jaffe, J.M. Algorithms for finding paths with multipleconstraints. Networks 1984; 14(1):95-116.

[27] Kuipers, F.A. Quality of service routing in the internet:Theory, complexity and algorithms 2004;

[28] Feng, G. A multi-constrained multicast QoS routing algo-rithm. Computer Communications 2006; 29(10):1811-1822.

[29] Castineyra, I. and Chiappa, N. and Steenstrup, M. TheNimrod routing architecture. RFC-1992 [1996].

[30] ITU-T Generic functional architecture of transport net-works. ITU-T: G.805 [2000].

[31] TeleManagement Forum (TMF) Common InformationModel (CIM). [2009].

[32] Hamm, M. K., Yampolskiy, M., Hanemann, A. I-SHARe.DFN Mitteilungen 2008; 74:39-41.

[33] De Marinis, E. and Hamm, M. and Hanemann, A. andVuagnin, G. and Yampolskiy, M. and Cesaroni, G. andThomas, S.-M. Deliverable DS3.16.1: Use Cases and Re-quirements Analysis for I-SHARe Geant2 technical paper2008.

[34] Steinmetz, R. Multimedia-Technologie. Grundlagen, Kom-ponenten und Systeme 2000;

[35] M. Yampolskiy. Maßnahmen zur Sicherung von E2E–QoS bei Verketteten Diensten. Ph.D. Thesis, Ludwig–Maximilians–Universitat Munchen, December 2009.

[36] Geant SA2-T1 working group Static Dedicated WavelengthService: Joint Infrastructure and Operational Level Agree-ment Geant2 technical paper, Draft 2010.

19

Documents

Management-aware inter-domain routing for end-to-end quality of service