D1.1: Functional Architecture Definition and Top Level · PDF fileD1.1: Functional Architecture Definition and Top Level Design Page 1 of 172 CEC Deliverable Number: 101/Alcatel/b1

D1.1: Functional Architecture Definition and Top Level Design Page 1 of 172

CEC Deliverable Number: 101/Alcatel/b1 TEQUILA Consortium - September 2000

Project Number: IST-1999-11253-TEQUILA

Project Title: Traffic Engineering for Quality of Service in the Internet, at Large Scale

D1.1: Functional Architecture Definition and Top Level Design

CEC Deliverable No.: 101/Alcatel/b1

Deliverable Type*: Report

Deliverable Nature**: Public

Contractual date: 31 July 2000

Actual date: 11 September 2000

Editor: Danny Goderis

Contributors: Alcatel: Danny Goderis, Geoffrey Cristallo, Yves T’JoensAlgosystems: Panos Georgatsos, Leonidas GeorgiadisFT-R&D: Christian Duret, Jean-Pierre Garbisu, Christian JacquenetIMEC: Steven Van den Berghe, Pim Van HeuvenNTUA: Dimitris Giannakopoulos, Eleni Mykoniati, George MemeniosGlobal Crossing (RACAL): Hamid Asgari, Richard EganUCL: David Griffin, Lionel SacksUniS: Carlos Frederico Cavalcanti, Antonio Liotta, George Pavlou, IliasAndrikopoulos, Paris Flegkas, Panos Trimintzios

Workpackage(s): WP1

Abstract: WP1 is concerned with the functional architecture, the system design andrelated protocols and algorithms for providing End-to-End QoS in theInternet. After summarising the System Requirements, this deliverable detailsthe TEQUILA functional model, defines the SLS-template and -semanticsand specifies the QoS-aware Intra-and Inter-domain Traffic Engineeringapproaches. The theoretical model is completed by outlining the Policy andMonitoring Framework.

Keyword List: CoS, DiffServ, IntServ, Internet, IP, MPLS, QoS, Quality of Service, SystemRequirements, Network Management, Resource Management, RouteManagement, Traffic Engineering, Service Level Specification, SLS, PolicyFramework, Monitoring Framework, Functional Model, Functional BlockDecomposition, Message Sequence Chart.



Project Number: IST-1999-11253-TEQUILA

Project Title: Traffic Engineering for Quality of Service in the Internet, at Large Scale

D1.1: Functional Architecture Definition and Top Level Design

Editor: Danny Goderis

Contributors: Alcatel: Danny Goderis, Geoffrey Cristallo, Yves T’JoensAlgosystems: Panos Georgatsos, Leonidas GeorgiadisFT-R&D: Christian Duret, Jean-Pierre Garbisu, Christian JacquenetIMEC: Steven Van den Berghe, Pim Van HeuvenNTUA: Dimitris Giannakopoulos, Eleni Mykoniati, George MemeniosGlobal Crossing (RACAL): Hamid Asgari, Richard EganUCL: David Griffin, Lionel Sacks

UniS: Carlos Frederico Cavalcanti, Antonio Liotta, George Pavlou,Ilias Andrikopoulos, Paris Flegkas, Panos Trimintzios

Version: Final Version

Date: 11 September 2000

Distribution: TEQUILA, CEC

Copyright by the TEQUILA Consortium, September 2000

The TEQUILA Consortium consists of:

Alcatel Co-ordinator BelgiumAlgosystems S.A. Principal Contractor GreeceFT-R&D Principal Contractor FranceIMEC Principal Contractor BelgiumNTUA Principal Contractor GreeceGlobal Crossing (RACAL) Principal Contractor United KingdomUCL Principal Contractor United KingdomTERENA Assistant Contractor The NetherlandsUniS Principal Contractor United Kingdom



Executive Summary

TEQUILA’s main objective is to study, specify, implement and validate service definition and TrafficEngineering (TE) tools for the Internet. The TEQUILA system should provide both quantitative andqualitative service guarantees through planning, dimensioning and dynamic control of trafficmanagement techniques based on DiffServ.

The DiffServ architecture has been conceived from the beginning to provide Quality of Service (QoS)in a scalable fashion throughout the Internet. The main concept is to maintain state-information andcomplexity only at network edges while the transit routers are responsible for applying appropriateforwarding treatment to incoming IP packets according to their Differentiated Services (DS) field ofthe IP header. The IETF DiffServ Working Group transformed the concept into a true architecture by –amongst others – defining the Per Hop Behaviours (PHB) and designing the functionality of DiffServedge routers, i.e. filters, meters, markers, etc.

The network operator has now at his disposal a series of DiffServ (essentially data-plane) buildingblocks, enabling him to implement relative packet differentiation. However, it is not clear yet how“real” customer services, such as interactive multimedia including voice over IP, can be build on topof this. The DiffServ architecture has some shortcomings at this time. Deploying QoS sensitivecustomer applications over the Internet requires a clear and unique concept of services, service classesand the related technical “IP-parameters” describing these services and their guarantees. Once theservice demands imposed on the network are clearly expressed, advanced “QoS networking” comesinto play for coping with these (ever-changing) demands. In order to provide end-to-end quantitativeservice guarantees, both across single and multiple Internet Service Providers (ISPs), the networkarchitecture should be augmented with intelligent network dimensioning, operational and managementfunctions. This boils down to a fully QoS-aware dynamic inter-working between the Management,Control and Data-plane functions.

The key contribution of this document is a functional architecture that builds upon the DiffServarchitecture so as to obtain a solution framework for end-to-end QoS/CoS provisioning in the Internet,thereby advancing the present State of the Art. The TEQUILA framework is depicted in Figure 4: TheTEQUILA Functional Architecture. D1.1 describes the main architectural (sub-)frameworks exploredwithin the TEQUILA project, including the Service Level Specification definition and handlingframework, the traffic engineering and network dimensioning framework, the monitoring andmeasurement framework and the policy based networking framework.

By adopting a system approach, the overall functionality has been described, by isolating specificfunctionality in functional blocks. This deliverable provides an overview for each identified functionalblock of the origin and semantics of the information required to take specific network related actions,the objective of taking such actions, and a description of the algorithm involved in the decisionprocess.

The purpose of providing such an extensive functional description is twofold. First it allows theproblem of scalable end-to-end IP QoS/CoS provisioning to be decomposed into small and feasiblesub-problems, that will lead to a detailed specification of the protocols and algorithms in D1.2.Secondly it serves as input to the top level design process, undertaken in conjunction with WP2, toseparate complex and time consuming tasks from highly dynamic and, as such, time critical taskswhile constructing the full TEQUILA system.

Based upon this functional architecture, and partly in parallel, the necessary protocol and algorithmicwork is being undertaken and will be documented in D1.2. This should lead to a first complete systemdescription by November 2000. The TEQUILA Functional Model extends the DiffServ architecturemainly in two dimensions.



• The (technical) modelling of the interactions between customers (or other network operators) andthe TEQUILA operator, mainly through the functions SLS Management, Traffic Forecast andNetwork Dimensioning (from left-to-right in Figure 4Figure 4). This deals with functions in theManagement plane (e.g. Service – SLS subscription) and in the Control plane (e.g. admissioncontrol). It addresses static and dynamic, intra- and inter-domain Service Level Specifications(SLSs) for both fixed and nomadic users and the protocols and mechanisms for negotiating,monitoring and enforcing them.

• The provisioning of the contracted SLSs through Network Planning and Dimensioning, DynamicRoute and Resource Management and – finally - the data-plane functions such as routing andDiffServ Traffic Conditioning and PHB enforcement (top-down in Figure 4). The frameworkensures that existing SLSs are adequately provisioned and that future SLSs may be negotiated anddelivered through a combination of static, quasi-static and dynamic Traffic Engineeringtechniques within network domains and on an inter-domain basis. It proposes solutions foroperating networks in an optimal fashion through planning and dimensioning and subsequentlythrough dynamic operations and management functions (“first plan, then take care”).

The structure of this document reflects these two main dimensions of the TEQUILA project. Chapterfour discusses in detail Service Level Specifications, while chapter five brings together everythingconcerning Traffic Engineering. Other chapters include a summary of the System requirements(chapter 2), Description of the Data-plane functions, i.e. Traffic Conditioning and PHB-enforcement,the functional description of the Policy framework (chapter 7) and the Monitoring Framework,including SLS-Monitoring (chapter 8).

Service Level Specifications

The work-in-progress on the SLS-issue so far resulted in a first contribution of the TEQUILAconsortium towards standardisation, i.e. the IETF Internet Draft (I-D) “Service Level SpecificationSemantics, Parameters and negotiation requirements” [TEQUILA-1].

Indeed, the consortium firmly believes that standardisation of the SLS content and format is requiredwhen considering the deployment of value-added IP service offerings over the Internet. Since these IPservices are likely to be provided over the whole Internet, their corresponding QoS will be based upona set of technical parameters that both customers and services providers will have to agree upon. Suchagreements, and especially the negotiations preceding them, will be greatly simplified in the presenceof a standardised set of (technical) SLS parameters. An SLS standard is also necessary to be able toallow for a highly developed level of automation and dynamic negotiation of SLSs between customersand providers.

All TEQUILA partners conceived consensus on the basic parameters of the SLS template proposal.This is now key input for further project work and it will enable the TEQUILA project to prototype allof the above features, especially automation and dynamic SLS-negotiation between customers andISPs. The negotiation protocol itself will be specified in D1.2.

The SLS semantics defined in [TEQUILA-1] allows multi-service deployment over the future Internetby offering a variety of service quality levels. These ranges from those with explicit, hard performanceguarantees for bandwidth, loss and delay characteristics (“Premium services”) down to low-costservices based on best-effort traffic, with a range of services receiving qualitative traffic assurancesoccupying the middle ground.

The TEQUILA SLS format covers the Premium Service Class as it is defined in the Internet2-project[QBONE], enabling e.g. the support of Virtual Leased Lines, but further extends into other QoS/CoScontracts. Qualitative guarantees may be useful for defining “Olympic services”, which should allownetwork operators or business users to e.g. differentiate between traffic of sales people (priority, lessdelay) and research engineers. Another application could be the differentiation between (on-line) web-browsing services and (background) e-mail traffic. Web browsing could be of the “silver class” whilethe e-mail is only tagged as “bronze”.



Besides the SLS format, this document also describes key functions enabling the network toeffectively handle the SLS contracts between customer and (TEQUILA) operator. Such keycomponents include amongst others, SLS-monitoring, SLS Subscription and SLS-Invocation handling,including Admission Control.

An example illustrating the TEQUILA functional model and the SLS format, is the support ofIntegrated Services (IntServ) over the TEQUILA DiffServ network. IntServ Guaranteed Service andControlled Load are “Premium micro-flow services”. It is described how RSVP Messages are capturedby the TEQUILA Functional Model and how the information of the RSVP Objects, e.g. TSpec andRSpec, is mapped onto the DiffServ SLSs. Once these “IntServ” SLSs are created, they are handled bythe TEQUILA management system as all others.

Traffic Engineering

Network Traffic Engineering (TE) is in general the process of specifying the manner in which traffic istreated within a given network. TE has user-oriented as system-oriented objectives. The users expectcertain performance from the network, which in turn should attempt to satisfy these expectations. Theexpected performance depends on the type of traffic that the network carries, and is specified in theSLS contract between customer and ISP. The network operator on the other hand attempts to satisfythe user traffic requirements in a cost-effective manner. Hence he/she attempts to accommodate asmany as possible of the traffic requests by using optimally the available network resources.

Both objectives are far more difficult to realise in a multi-service environment. The main routingmethod used today in the Internet is shortest-path routing with respect to certain link cost, e.g. OSPFfor intra-domain routing. In the framework of multi-service QoS provisioning, however, such anapproach may not be desirable always since it may lead to bottleneck creation and the chosen path maynot represent the best path with respect to the required QoS objective.

The two different intra-domain TE approaches that are explored within this document are MPLS-based(MPLS) and (pure) IP (Layer 3)-based (IP-TE). For each of these methods the resource reservation andprovisioning may – in theory - either be centralised or distributed. However, a pure IP-TE approachwill rather be based on the distributed approach, while the MPLS approach could very well be a mix ofcentralised and distributed computing. Both approaches are explores in the TEQUILA project.Although the IP-TE approach is certainly not the easiest one, it is necessary in those networks whichare not constructed solely from MPLS-capable equipment.

The document also discusses possible QoS-aware inter-domain TE methods based on BGP4extensions. This is a brand new area of research trying to cope with QoS in the Internet at large scale.Several approaches are explained and pros and cons are put forward, without however making adefinite choice at this stage of the project. The models differ depending on what information is floodedthrough the Internet by BGP. The information can be very basic, e.g. just announcing the ServiceCapability of an autonomous system, or a set of QoS parameters (delay, bandwidth) could bedistributed. Two partners introduced an IETF Internet Draft on this topic [JACQ, ABAR].

Conclusions

The expected results of TEQUILA project have previously been summarised as follows:

• A validated framework for the provisioning/definition of end-to-end Quality of Service (QoS)through the Internet

• Models for access and inter-domain SLSs.• Specification and evaluation of intra- and inter-domain SLS negotiation protocols• A validated framework for end-to-end QoS monitoring• Validated intra- and inter-domain traffic engineering methods, tools and algorithms deployable in

DiffServ capable IP networks

This deliverable is a sound theoretical ground for reaching these objects. Concerning the expectedresults, the following can be concluded:



• The framework, i.e. the TEQUILA functional model, is put in place. Functions, semantics andinterfaces are described in sufficient detail to allow the development of the algorithms andprotocols to proceed as planned.

• The SLS format and semantics have been defined and agreed by the project. This work resulted ina TEQUILA contribution towards the IETF [TEQUILA-1]

• Specification of protocols, in particular the SLS negotiation protocol, is now underway and thesewill be documented in Deliverable D1.2.

• The Monitoring and Policy frameworks are part of the overall TEQUILA functional model.

• Several approaches for intra-and inter-domain TE are explored and described according to, andbased on, the functional model. Development of the algorithms, e.g. resource and routecalculations, is now underway and these will be documented in Deliverable D1.2.



Table of Contents

1 INTRODUCTION ........................................................................................................................................ 12

1.1 THE TEQUILA PROJECT ....................................................................................................................... 121.2 ROLE OF WP1 AND THIS DELIVERABLE ................................................................................................. 131.3 STRUCTURE OF THIS DOCUMENT ............................................................................................................ 14

2 REQUIREMENTS, ASSUMPTIONS AND DEFINITIONS OVERVIEW................................................. 16

2.1 GENERIC DEFINITIONS AND REQUIREMENTS .......................................................................................... 162.2 NETWORK ARCHITECTURAL ASSUMPTIONS............................................................................................ 16

2.2.1 The Customer Premises Network Architecture..............................................................................172.2.2 The Access Network Architecture ..................................................................................................172.2.3 The Core Network Architecture .....................................................................................................172.2.4 The Roaming Architecture .............................................................................................................18

2.3 GENERAL END TO END COS/QOS IN THE INTERNET.............................................................................. 182.3.1 Flows vs. MicroFlows .....................................................................................................................182.3.2 CoS vs. QoS.....................................................................................................................................182.3.3 Applications.....................................................................................................................................192.3.4 CoS/QoS architectures....................................................................................................................192.3.5 Basic Traffic Management Blocks .................................................................................................212.3.6 Policy framework ............................................................................................................................21

2.4 INTRA-DOMAIN COS/QOS ASPECTS........................................................................................................ 222.4.1 General TE Requirements ..............................................................................................................222.4.2 Layer 3 TE requirements ................................................................................................................222.4.3 MPLS TE requirements..................................................................................................................232.4.4 Survivability Requirements.............................................................................................................232.4.5 Measurement Requirements ...........................................................................................................232.4.6 Capacity Control and Management Requirements........................................................................23

2.5 INTERDOMAIN QOS ASPECTS .................................................................................................................. 242.6 NON-TECHNICAL REQUIREMENTS........................................................................................................... 24

3 THE TEQUILA FUNCTIONAL MODEL................................................................................................... 25

3.1 POLICY MANAGEMENT ........................................................................................................................... 253.2 NETWORK PLANNING .............................................................................................................................. 263.3 NETWORK DIMENSIONING ...................................................................................................................... 273.4 TRAFFIC FORECAST................................................................................................................................. 273.5 SLS MANAGEMENT ................................................................................................................................. 28

3.5.1 SLS Subscription.............................................................................................................................283.5.2 Admission Control – SLS Invocation.............................................................................................293.5.3 Inter-domain SLS requestor ...........................................................................................................29

3.6 USER & UPSTREAM ISP/AS’S INTER-DOMAIN SLS REQUESTOR .......................................................... 293.7 TRAFFIC CONDITIONING ......................................................................................................................... 303.8 MONITORING ........................................................................................................................................... 303.9 DYNAMIC ROUTE M ANAGEMENT ........................................................................................................... 323.10 DYNAMIC RESOURCE M ANAGEMENT................................................................................................. 323.11 ROUTING.............................................................................................................................................. 323.12 PHB ENFORCEMENT........................................................................................................................... 333.13 OTHER ISP/AS .................................................................................................................................... 333.14 EXAMPLE: BOOTSTRAPPING THE TEQUILA NETWORK..................................................................... 33

3.14.1 Assumptions.................................................................................................................................333.14.2 Zero Phase ...................................................................................................................................333.14.3 Bootstrapping Message Sequence Chart ....................................................................................34

4 SERVICE LEVEL SPECIFICATIONS........................................................................................................ 37

4.1 MOTIVATION AND FRAMEWORK ............................................................................................................. 384.2 SLS CONTENTS & SEMANTICS ................................................................................................................ 39



4.2.1 Scope ...............................................................................................................................................394.2.2 Flow Identification .........................................................................................................................404.2.3 Traffic Conformance Testing .........................................................................................................414.2.4 Marking and shaping services prior to Conformance Testing ......................................................414.2.5 Excess Treatment............................................................................................................................424.2.6 Performance Parameters ................................................................................................................424.2.7 Service schedule..............................................................................................................................444.2.8 Reliability ........................................................................................................................................45

4.3 EXAMPLES: SERVICE TYPES & CUSTOMER SERVICES .......................................................................... 464.3.1 Quantitative (QoS - Premium) services..........................................................................................464.3.2 Qualitative (CoS – Olympic) services .............................................................................................47The Funnel Service......................................................................................................................................484.3.4 Best Effort traffic ............................................................................................................................494.3.5 Bi-directional Virtual Leased Line.................................................................................................494.3.6 “Hose” Virtual Private Networks ...................................................................................................49

4.4 SLS HANDLING – FUNCTIONAL SCENARIOS .......................................................................................... 524.4.1 Introduction on Traffic Forecast & Prediction .............................................................................524.4.2 SLS-Management, Traffic Forecast & Dimensioning ..................................................................534.4.3 Inter-Domain SLS negotiation .......................................................................................................564.4.4 SLS-subscription & -Invocation inter-working .............................................................................594.4.5 SLS Subscription handling.............................................................................................................614.4.6 Admission Control - SLS Invocation handling..............................................................................644.4.7 Examples .........................................................................................................................................66

4.5 INTEGRATED SERVICES SUPPORT ........................................................................................................... 704.5.1 IntServ over DiffServ : General architecture.................................................................................704.5.2 IntServ & the Tequila Functional Model.......................................................................................734.5.3 The Exterior RSVP Gateway Model...............................................................................................754.5.4 Native IntServ support ....................................................................................................................764.5.5 QoS Mapping On DiffServ PHBs...................................................................................................79

SLS MANAGEMENT – FUNCTIONAL BLOCK DECOMPOSITION ...................................................................... 814.6.1 Description of Functions ................................................................................................................814.6.2 Interface semantics and parameters...............................................................................................85

5 TRAFFIC ENGINEERING .......................................................................................................................... 88

5.1 INTRA-DOMAIN TRAFFIC ENGINEERING................................................................................................. 885.1.1 Objectives and Approaches.............................................................................................................885.1.2 Elementary TE Functions and the TEQUILA TE Functional Model ..........................................895.1.3 MPLS-based Traffic Engineering ..................................................................................................905.1.4 Pure IP-based Traffic Engineering................................................................................................95

5.2 TRAFFIC ENGINEERING: FUNCTIONAL BLOCK DECOMPOSITION....................................................... 1015.2.1 Network Dimensioning .................................................................................................................1015.2.2 Dynamic Resource Management .................................................................................................1095.2.3 Dynamic Route Management .......................................................................................................113

5.3 MESSAGE SEQUENCE CHARTS .............................................................................................................. 1185.3.1 MPLS-based TE............................................................................................................................1185.3.2 Link Failure Handling .................................................................................................................119

5.4 INTER-DOMAIN TRAFFIC ENGINEERING............................................................................................... 1235.4.1 Problem Description .....................................................................................................................1235.4.2 Current BGP and inter-domain TE..............................................................................................1255.4.3 TE Extensions of BGP..................................................................................................................1275.4.4 Model 1: “QOS parameters” model .............................................................................................1285.4.5 Model 2: “CoS capability” model.................................................................................................1365.4.6 Single-path BGP versus Multi-path BGP ....................................................................................1365.4.7 Conclusion ....................................................................................................................................138

6 DATA-PLANE FUNCTIONS.................................................................................................................... 139

6.1 TRAFFIC CONDITIONING ....................................................................................................................... 1396.1.1 Overview........................................................................................................................................1396.1.2 Functional Elements.....................................................................................................................1396.1.3 Examples for the Tequila SLSs ....................................................................................................141



6.1.4 Interface semantics and parameters.............................................................................................1426.2 PHB ENFORCEMENT ............................................................................................................................. 143

6.2.1 Description of Functions ..............................................................................................................1436.2.2 Interface semantics and parameters.............................................................................................144

7 POLICY FRAMEWORK ........................................................................................................................... 145

7.1 DESCRIPTION OF FUNCTIONS................................................................................................................ 1457.1.1 Policy Management Tool..............................................................................................................1457.1.2 Policy Storing Service ...................................................................................................................1467.1.3 Policy Consumer ...........................................................................................................................146

INTERFACE SEMANTICS AND PARAMETERS ................................................................................................... 1477.3 FINITE STATE MACHINES...................................................................................................................... 149

7.3.1 The Policy Management Tool FSM .............................................................................................1497.3.2 The Policy Storing Service FSM ..................................................................................................1527.3.3 The Policy Consumer FSM ..........................................................................................................154

8 MONITORING FRAMEWORK................................................................................................................ 157

8.1 INTRODUCTION ...................................................................................................................................... 1578.2 MESSAGE SEQUENCE CHART ................................................................................................................ 1578.3 FUNCTIONAL BLOCK DECOMPOSITION ................................................................................................ 159

Architecture................................................................................................................................................1598.3.2 Functions ......................................................................................................................................1598.3.3 Interfaces.......................................................................................................................................1608.3.4 Finite State Machine.....................................................................................................................1618.3.5 Algorithm and Protocol Problem Description .............................................................................161

8.4 SLS MONITORING ................................................................................................................................. 1618.4.1 Introduction ..................................................................................................................................1618.4.2 Service Subscription......................................................................................................................1618.4.3 SLS Monitoring Framework ........................................................................................................1618.4.4 Functional Block Decomposition of SLS Monitoring .................................................................162

9 REFERENCES .................................................................................................................... ....................... 166

10 ACRONYMS AND ABBREVIATIONS ................................................................................................... 168



List of Figures

Figure 1: The Internet Architecture ...................................................................................................................... 16Figure 2: TEQUILA network architecture ............................................................................................................ 17Figure 3: The generic policy architecture............................................................................................................. 22Figure 4: The TEQUILA Functional Architecture. ............................................................................................... 25Figure 5: The Policy Management Functional Block............................................................................................ 26Figure 6: The SLS Management Functional Block and its interactions with other blocks.................................... 28Figure 7: Decomposition of the User-Upstream ISP/AS functional block and interactions with others............... 30Figure 8: Decomposition of the Monitoring functional block and its interactions with others............................. 31Figure 9: Zero Phase Message Sequence Chart ................................................................................................... 34Figure 10: Bootstrapping Phase Message Sequence Chart .................................................................................. 36Figure 11: the funnel model .................................................................................................................................. 48Figure 12: Four Uni-directional Hoses................................................................................................................. 50Figure 13: VPN with 8 SLSs.................................................................................................................................. 51Figure 14: SLS-Management, Traffic Forecast and NW-Dimensioning (1).......................................................... 53Figure 15: SLS Management, Traffic Forecast & NW Dimensioning (2) ............................................................. 55Figure 16: Hop-by-Hop SLS negotiation .............................................................................................................. 56Figure 17: End-to-End SLS negotiation based on “Internet pipes”...................................................................... 57Figure 18: Local SLS negotiation without guarantees.......................................................................................... 58Figure 19: MSC of the SLS subscription process .................................................................................................. 63Figure 20: Dynamic SLS Invocation MSC ............................................................................................................ 65Figure 21: IntServ support over a DiffServ network ............................................................................................. 70Figure 22: IS-DS functional block diagram .......................................................................................................... 72Figure 23: two business scenarios ........................................................................................................................ 73Figure 24: Native IntServ support......................................................................................................................... 73Figure 25 : The RSVP gateway business scenario ................................................................................................ 75Figure 26: Native IntServ flow support ................................................................................................................. 76Figure 27: SLS Management - Functional Block Decomposition ......................................................................... 81Figure 28: Interaction of the SLS Management Functional Block with others ..................................................... 85Figure 29: Functional blocks involved in intra-domain traffic engineering ......................................................... 90Figure 30: Long-term MPLS Traffic Engineering................................................................................................. 91Figure 31: Bandwidth Allocation Under the Hose Scope Model .......................................................................... 93Figure 32: Functional architecture of the IP-based traffic engineering approach............................................... 97Figure 33: Interaction of the Network Dimensioning Functional Block ............................................................. 102Figure 34: The Finite State Machine of the Dimensioning Functional Block. .................................................... 105Figure 35: Dynamic Resource Management ....................................................................................................... 110Figure 36 Interfaces between Dynamic Resource Management and other functional blocks............................. 111Figure 37: Dynamic Route Management............................................................................................................. 114Figure 38: Dynamic Routing Process ................................................................................................................. 115Figure 39 - Interfaces between Dynamic Route Management and other functional blocks ................................ 116Figure 40: MPLS Traffic Engineering Parameter Updates ................................................................................ 118Figure 41: MPLS Traffic Engineering Triggering of Updates ............................................................................ 119Figure 42: Link usage policy............................................................................................................................... 120Figure 43: Protection Switching MSC ................................................................................................................ 121Figure 44: Restoration MSC ............................................................................................................................... 122Figure 45: The TEQUILA system........................................................................................................................ 123Figure 46: Automated enforcement of a BGP4 routing policy -.......................................................................... 126Figure 47: “QoS parameters” model.................................................................................................................. 128Figure 48: QoS-NLRI attribute ........................................................................................................................... 129Figure 49: code and sub-code combinations....................................................................................................... 130Figure 50: level of aggregation (1) ..................................................................................................................... 131Figure 51: level of aggregation (2) ..................................................................................................................... 132Figure 52: level of aggregation (3) ..................................................................................................................... 132Figure 53: Calculations for delay aggregation................................................................................................... 134Figure 54: Aggregating delays............................................................................................................................ 134Figure 55: “CoS capability” model .................................................................................................................... 136



Figure 56 Policy Management Functional Block Decomposition....................................................................... 145Figure 57: Interaction of the PolicyManagement Functional Block with others ................................................ 147Figure 58: The Policy Management Tool FSM. .................................................................................................. 149Figure 59: The Policy Storing Service FSM........................................................................................................ 152Figure 60: The Policy Consumer FSM................................................................................................................ 154Figure 61: Monitoring feedback MSC................................................................................................................. 158Figure 62: Monitoring Architecture.................................................................................................................... 159Figure 63: Node Monitoring and Ingress/Egress Monitoring............................................................................. 162Figure 64: SLS Monitoring Components and Sequence of Actions..................................................................... 163



1 INTRODUCTION

1.1 The TEQUILA ProjectThe overall objective of TEQUILA is to study, specify, implement and validate service definition andtraffic engineering tools for the Internet. The TEQUILA system should provide qualitative and close toquantitative service guarantees through planning, dimensioning and dynamic control of qualitativetraffic management techniques based on DiffServ. TEQUILA addresses static and dynamic, intra- andinter-domain Service Level Specifications (SLSs) for both fixed and nomadic users and the protocolsand mechanisms for negotiating, monitoring and enforcing them. The other main dimension of theproject studies intra- and inter-domain traffic engineering schemes to ensure that the network can copewith the contracted SLSs - within domains, and in the Internet at large.

This document is a key deliverable for the overall TEQUILA project. The deliverable contains theTEQUILA functional model and the TEQUILA SLS template and its semantics. The deliverable givesa detailed functional decomposition of the system, the specific network functions and the necessaryinformation streams between the functional components.

The overall work in the TEQUILA project is split over 3 WorkPackages (WPs), and follows a phasedapproach: a theoretical phase followed by a refinement phase and then an experimentation anddissemination phase.

WP1 - Functional Architecture and Algorithms - (which is responsible for the production of thisdocument) specifies the system architecture and related protocols and algorithms. WP2 - SystemDesign and Implementation - develops the system components and simulators. WP3 - IntegrationValidation, Assessment and Experimentation - configures the testbed and conducts experiments on theTEQUILA system through the testbed prototypes and the simulators.

During the first phase of the project, WP1 specifies the system functional and architecturalrequirements, while WP2 analyses the capabilities of existing simulation tools, available routers anddevelopment technologies. These results can be found in respectively in the deliverables D1.1 – whichis this document – and deliverable D2.1 Subsequently, WP1 focuses on the system architecture andspecification of protocols and algorithms while WP2 undertakes the adaptation of the selectedsimulation tools, routers and development tools.

In the second phase of the project, WP2 realises appropriate simulation models and prototypes usingthe tools, components and infrastructure as selected in this deliverable. The developed simulationmodels and system prototypes are delivered to WP3 where tests are executed. The test results andexperience are fed back to WP1 for revising accordingly the specified mechanisms, protocols andalgorithms. The revisions are fed to WP2 where the final prototypes are implemented.

During the final phase, the project focuses on evaluation and demonstration of the full TEQUILAsystem by undertaking experimentation and demonstration activities.



1.2 Role of WP1 and this DeliverableWP1 ’Functional Architecture and Algorithms’ is concerned with the specification of the systemarchitecture and related protocols and algorithms. During the first, theoretical phase of the project,WP1 undertakes an analysis of requirements regarding service provisioning, detailing the assumptionsregarding user access means, service provisioning and network capabilities. During the second phaseof the project, WP2 realises appropriate simulation models and prototypes. These are fed to WP3where a set of comprehensive simulation runs and tests are executed. The test results and experienceare fed back to WP1 for revising accordingly the specified mechanisms, protocols and algorithms. Therevisions are fed to WP2 and the final prototypes are implemented.

In the theoretical phase WP1 first concentrated on specifying the requirements. A summary of thiswork and an overview of the system requirements, assumptions and definitions can be found in thisdocument (chapter 2). A detailed description of the requirements, resulting from an in-dept State-of-the Art study of IP QoS in the Internet, per functional are, can be found in the technical annex to thisdocument.

Subsequently WP1 focuses on the system architecture, the definition of a Service Level Specification(SLS) format and its semantics, intra- and inter-domain SLS negotiation protocols and TrafficEngineering schemes and algorithms. The results of this work is documented in two main deliverables:Deliverable D1.1, Functional Architecture Definition and Top Level Design, which is actually thisdocument, and Deliverable D1.2, Protocol and Algorithm Specification [D1.2]. D1.1 describes thefunctional architecture of the TEQUILA system. D1.2 starts where D1.1 ends. Indeed, while D1.1 isstill algorithm- and protocol- transparent, D1.2 aims at a full system design by specifying thealgorithms and protocols. Thus D1.1 specifies the semantics, interactions and interfaces while D1.2will specify the protocols, algorithms and Top Level Design.

This deliverable provides a detailed functional decomposition of the system, thereby identifyingspecific network functions, related problem statements, and the necessary information streams betweenthe identified functional components. The main results of this deliverable can be summarised asfollows:

• Definition of the TEQUILA Functional Model. Starting from a high level view, describing maininteractions and functions, the model is further decomposed into isolated Functional (sub-) Blocks.The document gives a detailed description of each block (interface, semantics, and functions)together with the interactions amongst the functional Blocks. All this results in a description howthe TEQUILA system actually should work.

• Definition of the TEQUILA Service Level Specification and description of its semantics. Thiswork resulted in a first contribution of the TEQUILA consortium towards standardisation, i.e. theIETF Internet Draft (I-D) “Service Level Specification Semantics, Parameters and negotiationrequirements” [TEQUILA-1]. Besides the SLS format, the document also describes key functionsenabling the network to effectively handle the SLS contracts between customer and (TEQUILA)operator. Such key components include amongst others, SLS-monitoring and SLS Subscription andInvocation handling (including Admission Control).

• Description of the QoS-aware Traffic Engineering Operations, based on the (inter-) working ofthe several functional blocks identified by the Functional Model. TE should actually ensure thecustomers that their QoS-requirements, I.e. SLSs, are actually met AND – at the same time – TEshould provide an optimal utilisation of resources in a Multi-service IP network. The documentcontains a description of the intra-and inter-domain Traffic Engineering approaches, which will befollowed in the TEQUILA project. It includes MPLS-based and pure IP-based intra-domain TEapproaches. TE involves amongst others Network Dimensioning, (dynamic) Resource and RouteManagement and the basic packet-routing, -buffering, -scheduling and -forwarding operations.



1.3 Structure of this documentChapter 2 - Requirements, Assumptions and Definitions Overview - introduces and discusses theinitial output from the first few months’ activity in WP1. This is an important chapter, not only for thisdeliverable, but also for the project as a whole. It sets the direction of the theoretical, practical andexperimental work of the consortium and has had a strong influence on the reviews and selectionsmade in this report. More details can be found in the Technical Annex: IP QoS State of the ArtOverview, Requirements and Assumptions. It reviews the current and emerging standardisation workwithin the domain of the TEQUILA project, together with the current state of the art (SoA) as viewedby the Internet industry and research community.

Chapter 3 – The Tequila Functional Model – gives the TEQUILA functional model. Starting from theoverall system architecture, the model is further decomposed into several (sub) Functional Blocks:Policy Management, Traffic Forecast, Network Planning, Network Dimensioning, SLS Management,Monitoring, Dynamic Route and Resource Management, Traffic Conditioning, Routing and PHBEnforcement.

The chapter ends with a Message Sequence Chart (MSC) for the Bootstrapping phase of a TEQUILAnetwork. The MSC describes the interaction between the several function blocks and the bootstrappingexample mainly serves as an illustration for the Functional Model. The next chapters discuss more thedetails of each block and the interaction between them.

Chapter 4 – Service Level Specifications first describes the SLS format and semantics as it is definedand adapted by the TEQUILA consortium. The SLS contains amongst others the essential TrafficConformance Parameters and QoS Performance Guarantees. The chapter also gives some examples ofIP Services, which can be formally described based on the TEQUILA SLS. Examples include the IPPremium Service (similar to the Qbone Internet2 initiative [QBONE]), qualitative Olympic Services,the Funnel Service, bi-directional Virtual Leased Lines (VLL) and Virtual Private Networks (VPN).

A second major part of the chapter, after the SLS content description, is how the TEQUILA DiffServnetwork should actually handle new or modified SLSs. The section SLS handling – Functionalscenarios, is about the interaction of the SLS Management Functional Block with others. Anintroduction discusses the main information streams and interactions between SLS management,Traffic Forecast and Network Dimensioning. It gives a high-level understanding of the SLS-treatmentat an intra-domain level. Inter-domain SLS negotiation is an open area of research and a sub-sectionlists possible SLS-negotiation scenarios: Hop-by-Hop, End-to-End or Local SLS negotiation. Furtherdetails of SLS Management and the Message Sequence Charts are treated in SLS-Subscription andSLS-Invocation handling. Thus, a clear distinction is made between SLS subscription, which resides inthe Management Plane, and SLS invocation, which is a function in the control plane and deals e.g. with(Flow) Admission Control.

The chapter concludes with a contribution on the support of Integrated Services (IntServ) over theTEQUILA DiffServ IP network. The section describes how the TEQUILA DiffServ network is able tosupport the IntServ Guaranteed Service and Controlled Load. The technical framework depends uponthe adapted Business Model, which can either be the “Exterior RSVP Gateway” model or the “NativeIntServ Support” model. The latter one is the real technical challenge. The document describes howRSVP Messages are captured by the TEQUILA Functional Model and how the information of theRSVP Objects, e.g. TSpec and RSpec, is mapped onto the DiffServ SLSs.

Chapter 5 - Traffic Engineering – brings together all TE- related issues. After an overview about theessential QoS TE-objectives and -approaches, i.e. user-oriented versus resource-oriented objectives,centralised versus distributed and connection-oriented versus connectionless, the chapter describeshow basic TE-functions are handled by the TEQUILA functional blocks. Two TE approaches are holdback for Intra-domain TE: connection-oriented TE based on MPLS and pure IP, connectionless TE.

The second section describes in detail the functional decomposition of the blocks involved in Intra-domain Traffic Engineering: Network Dimensioning, Dynamic Resource Management and DynamicRoute Management.



The third section of this chapter discusses possible QoS-aware inter-domain TE methods based onBGP4 extensions. Several approaches are explained and pros and cons are put forward, withouthowever making a definite choice at this stage of the project. The models differ depending on whatinformation is flooded through the Internet by BGP. The information can be very basic, e.g. justannouncing the Service Type Capability (e.g. “Premium” or “Gold Olympic”) of an autonomoussystem, or a set of QoS parameters (delay, bandwidth) could be distributed. Two partners introducedan IETF Internet Draft on this topic [JACQ, ABAR].

The chapter ends with some message sequence charts (MSCs) illustrating the interactions between thefunctional blocks. MSCs are given for long- and short-term MPLS-based Traffic engineering and LinkFailure handling. Some additional notes on Link Failure handling are added here in order to explainhow TE should actually cope with such drastic events.

Chapter 6 gives an overview of the functionality of the Data-plane functions, i.e. the TrafficConditioning at the Edge Routers and the Per-Hop-Behaviour Enforcement (buffering & scheduling ofIP packets) in the core (and edge) routers. The TEQUILA project follows the recommendations of theIETF DiffServ WG on these topics.

Chapter 7 outlines the Policy Framework. The Policy framework consists of the Policy ManagementTool, the Policy Storing Service and the Policy Consumers (also known as Policy Decision Points -PDPs).

Policies are defined in the Policy Management Tool, which is similar to a “policy creationenvironment”. Policies are defined in a high-level language, translated into a object-oriented policyrepresentation (information objects) and finally stored in the policy repository (Policy StoringService).

Policy Consumers (or PDPs) correspond to their associated functional block in the TEQUILA model;e.g. SLS related admission policies with the SLS Management block, dimensioning policies for theDimensioning block, dynamic resource/route management policies for the Dynamic ResourceManagement block, etc. Policy Consumers need also to have direct communication with theMonitoring functional block in order to get information about traffic-based policy-triggering events.

Chapter 8 finally discusses the Monitoring Framework, including SLS-Monitoring. Monitoring is acrucial network function for both the correct functioning of the Tequila system and for the ability toimpose a check on the SLSs, which were agreed with a customer. It is necessary to have a local and anaggregated overall view on the network in terms of the definitions of the IETF IP PerformanceMonitoring (IPPM) Working Group. The Tequila system needs to support two sources of informationas the basis for the monitoring framework. First information gained by inserting (low-impact) teststreams (referred to as active measurements) and the results of the analysis of the traffic passing in thenetwork element (referred to as passive measurements). To have a scaleable system, the information ofthese basic building blocks needs to be aggregated into summarising statistics by some higher levelblocks.



2 REQUIREMENTS, ASSUMPTIONS AND DEFINITIONSOVERVIEW

2.1 Generic definitions and requirementsThe TEQUILA system is being defined as the concatenation of IP-based networks that adopt theprocedures, functionality and/or open interface specifications defined within the TEQUILA project.

The TEQUILA project must concentrate on communication over a public IP-based network, i.e., theInternet. Note that this does not exclude the procedures defined within the context of the TEQUILAproject to apply to intra- or extra-net configurations.

The TEQUILA project must only consider (CoS/QoS enabled) unicast services. As such,investigations of multicast services are out of scope.

The TEQUILA project assumes communication in the context of a single routing and addressingrealm, that is to say, all communicating parties are supplied with public routable addresses, andnetwork address translation is not investigated nor assumed.

The TEQUILA project assumes only IP version 4 technology.

As interoperability is of major concern to the TEQUILA project, a basic requirement for theTEQUILA project is to seek consensus in the wide research community and at the level ofstandardisation (e.g., IETF), for each protocol that would handle information exchange over openinterfaces. This includes semantics and syntax of the interface specification at management, controland datagram forwarding level.

2.2 Network architectural assumptions

+ L3 Router Host (Client /Server)Network Access Server/Customer Aggregation Router

+

+

+ +

+

+

+ +

+

+

+ +

++

+

Internet Backbone Provider

Corporate / Business User / ISP

Enterprise

SOHO

Residential

Subnetwork Layer Connection

++

Server Farms / Content Providers

+

+

+ +

+

+

+ +

Corporate / Business User / ISP

Internet Service Provider (ISP) Internet Service Provider (ISP)

Figure 1: The Internet Architecture



2.2.1 The Customer Premises Network ArchitectureThe TEQUILA assumes the Customer Premises Networks to be client stub networks to the TEQUILAsystem. Although the TEQUILA project takes an ISP perspective to service offering, it is expected thatthe offering of services at the access links of the network can easily be extrapolated to the serviceoffering within customer premises networks for individual host systems. When the latter is the case,the TEQUILA system truly extends from host (application) to host (application).

2.2.2 The Access Network ArchitectureThe TEQUILA project assumes the access link between customer premises network and InternetService Provider to be a point-to-point link with certain static transport characteristics. That is to say,the TEQUILA project will not investigate the specific extensions necessary to the (present dial-in)access network configuration based upon PPP/Ethernet/ATM (etc…) for CoS/QoS enablednetworking.

2.2.3 The Core Network ArchitectureAs shown in Figure 2, the core of the Internet is built upon multiple tiers of connectivity betweencorporate networks, Internet Service Providers and/or backbone providers.

The TEQUILA system must cover both intra-domain and inter-domain operation, where intra domainoperation denotes the operation of network elements under a single administration. Inter-domainoperation denotes the procedures governing the communication amongst intra-domain systems, i.e.between autonomous systems.

The TEQUILA project assumes the TEQUILA system to be composed of several autonomoussystems. A given autonomous system corresponds to a set of IP routers which are interconnectedaccording to a specific mesh topology, and which are managed by a single and globally uniqueadministrative entity. The autonomous system itself can further be decomposed into AS core routers,surrounded by an edge region containing TEQUILA edge or AS border routers. TEQUILA edgerouters connect the TEQUILA system to the client access, while AS border routers connect theAutonomous Systems amongst each other. AS border routers typically communicate by means ofeBGP over the AS to AS links, while communicating by iBGP internally amongst each other withinthe Autonomous System. Edge Routers collect client accesses, and as such can be configured tocommunicate over the access link to the Customer Premises Network by eBGP or OSPF. It may alsobe that no routing information is exchanged dynamically (CPN configured with static route to theprovider).

TEQUILA SYSTEM

TEQUILA edge Router

Autonomous System Autonomous System

AS Core Router

AS Border Router

Autonomous System

ClientAccess

ClientAccess

Figure 2: TEQUILA network architecture



The TEQUILA project will not elaborate on the network topology planning and initial dimensioning ofthe network.

The TEQUILA project must provide mechanisms for both MPLS and IP layer dimensioning, given afixed underlying topology.

Intra-domain operation

The TEQUILA project assumes point to point connectivity with fixed capacity amongst routers, e.g.,PoS, ATM, (channelized) SONET/SDH, etc…

The TEQUILA system focuses on the use of the OSPF IGP routing protocol, while some considerationwill be given to IS-IS As such, RIP is excluded from investigation.

Inter-domain operation

The TEQUILA system assumes peering to happen by means of point-to-point link connectivitybetween border routers at (private, public) peering points.

Routing information exchange between autonomous systems is assumed to be performed by means ofthe BGP4 protocol.

2.2.4 The Roaming ArchitectureThe TEQUILA project will investigate the necessary extensions for the support of roaming (nomadic)users, based upon L2 (PPP) or L3 tunnelling through a portion of the public Internet.

The TEQUILA system should extend the present roaming architecture (as defined in RFC 2477) forroaming access to CoS/QoS enabled networking.

2.3 General End to end CoS/QoS in the Internet

2.3.1 Flows vs. MicroFlowsA micro-flow is defined to be the correlated set of packets that consist of the five-tuple source address,destination address, protocol number, source port and destination port.

A flow is defined to be a correlated set of packets that are treated by the network in a prescribed way.In general, a flow consists of one or more micro-flows, however, correlation may make use ofparameters beyond the five tuple header information. E.g., any information available in the IPdatagram header such as DSCP, labels for Label Switched Paths in an MPLS architecture, ingress oregress interfaces to the system, network of origin or transit, etc.

The way micro-flows get aggregated and de-aggregated in flows is highly dependent on theapplication of dealing with flows (e.g., traffic engineering, or marking, or firewall filtering) and therelative position in the network (e.g., access versus core). Prescribing the aggregation and de-aggregation points and procedures is seen as a consistent part of the TEQUILA project.

2.3.2 CoS vs. QoSIn the TEQUILA project, Quality of Service (QoS) refers to a service offering where one or moretraffic parameters (i.e., throughput, loss, delay and/or jitter) are quantified. The way QoS is offered tothe user by the network can either be by opening the whole spectrum of possible values for one ormore traffic parameters, or by packaging them in a set of discrete parameter values. The latter isdenoted as QoS Classes within TEQUILA.

Further, in the TEQUILA project, Class of Service (CoS) refers to the provisioning of relative levels ofservice amongst different packet flows. The resulting service perceived by a CoS flow is dependent onthe number of other flows that share network resources and are members of the same (or different)CoS.



The TEQUILA project must allow for both quantitative (QoS) and qualitative (CoS) service levels.The offering of quantitative service levels may be by means of discrete QoS classes, the latter ishowever part of the research task within TEQUILA.

2.3.3 ApplicationsThe TEQUILA system should allow for the widest range of possible applications, and should thereforebe application/service independent to the extent possible.

The TEQUILA system functional components should provide the necessary hooks in the system toallow for specific service architectures to make use of or request reservation capabilities for CoS/QoSenabled data transport.

2.3.4 CoS/QoS architectures

2.3.4.1 IntServ and DiffServ networking modelsThe TEQUILA system supports both the integrated services and differentiated services end-to-endmodels.

The TEQUILA system assumes only the RSVP resource reservations protocol in the context of theIntServ model

The TEQUILA system must provide for Best Effort, Controlled Load and Guaranteed Service end-to-end networking in the IntServ model. That is to say, no new Intserv-based service elements will bedefined within the course of the TEQUILA project.

The TEQUILA system assumes only the Expedited Forwarding, Assured Forwarding and Default PerHop Behaviours in the DiffServ model. No new per hop behaviours will be defined in the course of theTEQUILA project.

The TEQUILA project assumes the DiffServ model in the core of the autonomous systems as depictedin Figure 2. This basic assumption stems from the scalability properties of DiffServ enablednetworking. For the same reason of scalability, the DiffServ domain may extend over multipleautonomous systems.

Given the assumption of core DiffServ network operation, the TEQUILA system should manage:

• the IntServ to DiffServ and DiffServ to IntServ interworking at the edge of the network

• the resource management in the DiffServ core network to match the IntServ requirements

• the DiffServ to DiffServ interworking at the border between autonomous systems (ASs) andbetween AS and customer networks.

2.3.4.2 Service Level Specification and NegotiationAt the access to the TEQUILA system, service requests should allow for:

• RSVP-based negotiation of Service Level Specifications that adhere to the IntServ model asdescribed above at the micro-flow level.

• Generic Service Level Specifications applying to a generic flow definition.

SLS negotiations is an area of concern to TEQUILA. SLS negotiations will apply in the TEQUILAsystem for establishing and renegotiating SLSs between users and providers and between providers.

SLS negotiations is a quite new subject, and TEQUILA is expected to contribute.

Since today neither an agreed Service Level Specification format nor a negotiation protocol exists, theTEQUILA project must define them for its own use.

The requirements towards the format and negotiation protocol are the following.



The TEQUILA project should allow for automated, dynamic SLS negotiation. The accepted dynamicsof SLS negotiation will be dependent on the scalability concerns of the system, and will beinvestigated within the context of the TEQUILA project.

The TEQUILA system should allow for Service Levels to be attached to the notion of a flow, theservice level being of CoS or QoS nature. The guarantees implied by the CoS/QoS Service LevelSpecification will be limited to a prescribed scope, however limited to the TEQUILA system. That isto say, the part of the network where the TEQUILA system exercises control over the resources.

The QoS guarantees can apply to the following traffic parameters:

• Throughput

• Maximum Delay

• Maximum packet loss

• Maximum jitter

The relative service level of flows under a CoS contract allows for differentiated treatment levels on

• Throughput

• Delay

• Packet loss

The CoS/QoS guarantees only apply to packets that fit the Traffic Conformance Specification.

The TEQUILA Service Level Specification should allow for indicating behaviour for non-conformingpackets.

Other components of the SLS specific to a flow and considered by the TEQUILA system areAvailability (where availability refers to the time indication when the SLS should apply) andMaximum update frequency. Components such as Reliability, Security (Privacy, Integrity andAuthenticity requirements), Routing Constraints and Cost will be covered in the margin of the projectto the extent needed to cover the former requirements.

The TEQUILA project should specify a formal format for the description of an SLS at the ClientAccess interface, and between autonomous systems of the TEQUILA system.

The TEQUILA SLS negotiation protocol should allow for

• Original service requests, according the components of the specified SLS.

• Service acknowledgement, indicating agreement with the requested service level.

• Service rejection indicating either incapability of providing the service or a hint on closely relatedservice offerings.

• Service modification from both user and provider

The TEQUILA SLS negotiation protocol transport requirements should be lightweight comparable tothe bandwidth available on the access interface.

The TEQUILA framework should allow for feedback of events related to the service.

The TEQUILA framework should preferentially make use of existing specifications protocol designwork available.



2.3.5 Basic Traffic Management BlocksThe TEQUILA project is primarily considered with the study, development and validation ofarchitectures, algorithms and protocols to ensure end-to-end CoS/QoS in the Internet. Adopting theDiffServ architecture approach leads to the necessity of specifying and developing mechanisms for theimplementation of the traffic management capabilities needed to support the required Per HopBehaviours. Thus the focus of the TEQUILA project is to ensure the support of the PHBs rather thanextensively investigate the traffic management mechanisms used to achieve this.

A conclusion drawn from the state of the art capture on this topic is that there are a variety of existingmechanisms capable to support the target PHBs. This allows the project to adopt the optimumcombination of existing traffic classification, conditioning, scheduling, metering and congestionmanagement techniques in order to meet its objectives, saving the effort from studying and developingnew traffic management mechanisms.

Further, it is considered that the TEQUILA project should not commit itself to explicit requirementsregarding the traffic management techniques to be used. It is foreseen though to further investigate theexisting solutions and, under the context of the project’s functional model specification, decide on thespecific techniques to be adopted by the project.

Concerning the Explicit Congestion Notification (ECN), it has been decided that the project should notmake the assumption that all the routers composing the DS domain are ECN-capable, but ratherconsider it as an optional feature which some routers might support while others might not.

2.3.6 Policy frameworkIt is expected that ‘correct’ policy enforcement at the edges of the TEQUILA system (and itsunderlying autonomous systems) will be a prime concern in the provisioning of CoS/QoS guaranteesat a network wide scope. In addition, policy-based management offers potentially a flexible, extensiblevehicle for the realisation of the TEQUILA dynamic resource management aspects.

The IETF today proposes a policy framework for admission control policies that can be used withinthe context of CoS/QoS networking. The framework however requires still substantial work, if it is tobe used in an operational network. The TEQUILA project should start from the present status of thepolicy framework and augment it to enable the service model as prescribed in previous sections.Service level admission is typically governed by decisions at the level of the user subscription profile(as from the business model), and the availability of network resources (bandwidth brokerage), whicheventually lead to a final admission decision.

In addition to admission control policies, TEQUILA should investigate the possibility of using thepolicy framework for dynamic resource management policies. This area has not yet been addressed bythe IETF and investigated principles and accruing results should be fed back to the IETF.



Policy Management Tool

Policy Repository (Directoryserver, Database, etc.)

Policy Consumer

Policy Target

Policy Specifications

Repository AccessProtocol (e.g. LDAP)

Repository AccessProtocol (e.g. LDAP)

Policies

Protocol for affecting PolicyTargets

Figure 3: The generic policy architecture

The TEQUILA system assumes a LDAP-like interface between the Policy management tool, Policyrepository and Policy Consumer (sometimes referred to as Policy Decision Point, PDP). On the otherhand, TEQUILA should concentrate on the essence of the policy framework rather than focusing onopen, standardised repository access.

The TEQUILA system assumes the use of the COPS protocol between the policy consumer (PDP) andpolicy target (sometimes referred to as Policy Enforcement Point, PEP), as only presently standardisedprotocol for CoS/QoS related PDP/PEP communication. The project will however investigate newdevelopments in the context of Policy Enforcement, as under study in the Authentication,Authorisation and Accounting WG of the IETF (AAA).

2.4 Intra-domain CoS/QoS aspectsOne of the primary activities within TEQUILA is the investigation on the use of various traffic-engineering tools towards the provision of end-to-end QoS as specified in SLSs.

2.4.1 General TE RequirementsTEQUILA is required to provide a TE system with traffic-oriented performance objectives to fulfil therequirements of the contracted SLSs.

As outlined by its objectives, TEQUILA assumes a DiffServ-capable IP network infrastructure. Thespecification of a scalable, effective TE system in DiffServ networks is still an open issue andTEQUILA is expected to contribute to the design of architectures and algorithms, which will bevalidated through implementation and experimentation.

TEQUILA is required to investigate all functions involved in achieving the objectives of a TE system;capacity and traffic management.

Of particular interest is the combination of time-dependent and state-dependent capacity managementschemes. TEQUILA will investigate the optimal coupling of these functions by studying the dynamicsof traffic and topology changes in a SLS-based multi-service environment.

As such the TEQUILA project must investigate both connection-less (layer 3) and connection-oriented(MPLS) based traffic engineering approaches, as described in the following sections.

2.4.2 Layer 3 TE requirementsThe routing algorithms and protocols in TEQUILA should at a minimum:



• Be QoS-aware, as part of the OSPF extensions, and from a L3 TE perspective. Therefore, theproject should investigate the use of multiple metrics in (OSPF) type 10 LSA and the appropriateTLVs, as well as investigate the use of the “bw” metric.

• Be configurable on the fly through specific parameter setting or through more abstract policies.Configuration actions will be undertaken by network administrators/managers and higher-levelalgorithms such as network dimensioning.

• Calculate and select feasible paths - not necessarily shortest paths - with the aim of improvingoverall network efficiency and the availability of the various service classes offered by thenetwork.

• Work in conjunction with resource (capacity) reservations and the dynamic management of thosereservations

• Routing protocols and embedded algorithms in TEQUILA may be programmed (in the medium tolong term time scales) by higher level algorithms with network topology/state/routing plans, etc.this information does not always have to be calculated on-the-fly through a (short to medium termtime scale) distributed protocol - it may not be possible when there are different routing plans fordifferent service classes multiplexed on the same network. TEQUILA should consider the relativemerits of both approaches and the combination of the two for TE purposes.

The TEQUILA system assumes only OSPF support in the autonomous system (as well as iBGPpeering relationships).

2.4.3 MPLS TE requirementsAs it has been extensively described in [I1.1], MPLS with its features (especially its support forexplicit routing) constitutes an important tool upon which effective TE solutions can be based.TEQUILA envisions that MPLS forwarding mechanism integrated with a constrained-based routingparadigm is a very important candidate towards specifying an effective TE solution for specific classesof traffic (e.g. of critical delivery).

The TEQUILA system must also provide MPLS traffic-engineering capabilities.

2.4.4 Survivability RequirementsTEQUILA is required to investigate survivability issues in the specified TE solution. At a minimum,link failures should be covered.

2.4.5 Measurement RequirementsTEQUILA is required to consider how its SLSs will be monitored and how network measurements areto be performed.

TEQUILA is required to use the IETF’s IPPM Framework and corresponding metrics, where possible.Tequila is required to use IETF’s standardised MIBs where possible.

TEQUILA is required to consider both passive and active monitoring techniques in its measurementarchitecture.

TEQUILA is required to study the representation (and aggregation) of measurement information to beused as an input to other functional elements.

2.4.6 Capacity Control and Management RequirementsTEQUILA is required to provide capacity management functions for being able to handle SLSrequests and optimising network performance. Both network level and network element resources arein the scope of TEQUILA. Multi-class contention resolution schemes will be investigated.



As already outlined, TEQUILA will pursue optimum coupling of time and state-dependent capacitymanagement schemes.

The Bandwidth Broker (BB) work in the Internet 2 Qbone Bandwidth Broker Advisory Council is ofinterest to TEQUILA, especially as draft protocol specifications for inter-domain BB communicationshave already been published. The architecture is interesting in the sense that, in at least one place intheir documents, they refer to a two level hierarchy of BBs and Subnet Bandwidth Managers (SBMs).Furthermore the concepts of SLS and RAR are used to refer to something similar to the static anddynamic forms of SLSs discussed within the TEQUILA consortium. Both of these concepts –hierarchical BBs and RARs vs. SLS requests – mirror TEQUILA concepts and therefore should be ofinterest. An outstanding issue, at the time of writing, is to identify the maturity of the implementationsfrom UCLA, Merit, BCIT and Telia.

2.5 Interdomain QoS aspectsThe TEQUILA system should allow for SLS agreed at its edge to stretch over Autonomous Systemsunder the control of different administrations. To that end, the TEQUILA system should specify thenecessary extensions on the present best effort inter-domain routing architecture to enable CoS/QoSenabled networking.

The TEQUILA system must allow for routing policies involving CoS/QoS constraints.

The TEQUILA system assumes the use of BGP-IV in the network.

The TEQUILA system should adhere to the scalability requirements attached to the notion of inter-domain networking.

The TEQUILA system should allow for communication with the Internet2 community on the basis ofthe already agreed BB-to-BB communication architecture. It is assumed that this will be a subset of thecapabilities of the TEQUILA system.

2.6 Non-technical requirementsThe TEQUILA system should run on standardised (or to be standardised by the TEQUILA project)open interfaces.

The TEQUILA project should reuse existing software to the extent possible.

The TEQUILA project should seek to reach consensus with other global efforts at the level ofCoS/QoS IP networking.



3 THE TEQUILA FUNCTIONAL MODELIn this section we present the TEQUILA Functional Architecture and describe in detail thefunctionality of each functional block. Figure 4 illustrates the overall Functional Architecture.

7UDIILF

&RQGLWLRQLQJ 5RXWLQJ

3DFNHW�2XWSXW

7UHDWPHQW

0RQLWRULQJ

'\QDPLF�5RXWH

0DQDJHPHQW

'\QDPLF

5HVRXUFH

0DQDJHPHQW

1HWZRUN

'LPHQVLRQLQJ

6/6 0DQDJHPHQW�

�$GPLVVLRQ�&RQWURO�

6XEVFULSWLRQ�

1HWZRUN

3ODQQLQJ

,63�$6

'RZQVWUHDP

,63�$6

8VHU

RU

8SVWUHDP

,63�$6

2YHUDOO�)XQFWLRQDO�$UFKLWHFWXUH

7UDIILF

)RUHFDVW

3ROLF\

0DQDJHPHQW

7UDIILF

&RQGLWLRQLQJ 5RXWLQJ

3+%

(QIRUFHPHQW

0RQLWRULQJ

'\QDPLF�5RXWH

0DQDJHPHQW

'\QDPLF

5HVRXUFH

0DQDJHPHQW

'\QDPLF�5RXWH

0DQDJHPHQW

'\QDPLF

5HVRXUFH

0DQDJHPHQW

1HWZRUN

'LPHQVLRQLQJ

6/6 0DQDJHPHQW�

�$GPLVVLRQ�&RQWURO�

6XEVFULSWLRQ�

1HWZRUN

3ODQQLQJ

,63�$6

'RZQVWUHDP

,63�$6

8VHU

RU

8SVWUHDP

,63�$6

8VHU

RU

8SVWUHDP

,63�$6

2YHUDOO�)XQFWLRQDO�$UFKLWHFWXUH

7UDIILF

)RUHFDVW

3ROLF\

0DQDJHPHQW

Figure 4: The TEQUILA Functional Architecture.

It should be noted that at this level of abstraction we omit the directionality of the interactions betweenthe components, because the interpretation of the semantics of such directionality might vary. Whetherthe interaction is from or to one component will be clearer (independently of the semantics) in thefunctional decomposition section.

3.1 Policy Management• The policy functional block in the functional architecture includes (see figure above) the Policy

Management Tool, the Policy Storing Service (policy repository - which could be distributed, infact this is one of the directory’s advantages as a technology for the repository) and the PolicyConsumers which are mixed with their associated functional blocks (see “A Tequila FunctionalBlock” in the figure), e.g. SLS related (admission) policies with the SLS Management block,dimensioning policies with the Dimensioning block, dynamic resource/route management policieswith the Dynamic Resource Management block, etc.

• In this model there exist many functionally different Policy Consumers, associated with particularfunctional blocks of the hierarchical management structure. Targets can be the managed objects ofthe associated functional block or of lower-level functional blocks (but never of higher blocks).Policy Consumers need also to have direct communication with the Monitoring functional block inorder to get information about the policy-triggering event. Note that Monitoring might not alwaysemit the policy-triggering event but there might be cases where this event is emitted by the specificfunctional block to which the Policy Consumer is associated with.



• Policies are defined in the Policy Management Tool, which provides something like a “policycreation environment”. Policies are defined in a high-level language, are translated to object-oriented policy representation (information objects) and stored in the policy repository (PolicyStoring Service). New policies are checked for conflicts with existing policies, although someconflicts may be only detected during execution time. After the policies are stored, activationinformation may be passed to the associated Policy Consumer.

• The policies in the context of TEQUILA will cover, amongst possibly other areas, the following:

• SLS subscription and admission control policies.

• Planning /dimensioning and traffic forecasting policies.

• Dynamic routing and resource management policies.

• Routing policies.

3ROLF\�0DQDJHPHQW

3ROLF\�

0DQDJHPHQW

7RRO

3ROLF\�

6WRULQJ�

6HUYLFH

3ROLF\�

&RQVXPHU

0RQLWRULQJ

$�7HTXLOD�

)XQFWLRQDO

%ORFN

3ROLF\�0DQDJHPHQW

3ROLF\�

0DQDJHPHQW

7RRO

3ROLF\�

6WRULQJ�

6HUYLFH

3ROLF\�

&RQVXPHU

0RQLWRULQJ

$�7HTXLOD�

)XQFWLRQDO

%ORFN

Figure 5: The Policy Management Functional Block.

Policies allow a flexible system evolution to cope with new needs without re-engineering.

• While the IETF has considered until now a single, centralised Policy Consumer or Policy DecisionPoint, TEQUILA considers a hierarchical approach to policy decomposition, with high levelpolicies including lower level policies, until the latter degenerates at configuration commands atthe lowest level. It is for further investigation to what extent such a hierarchical decomposition canbe supported in an automated manner. Also TEQUILA policy management will consider havingback-up policy consumers in the case of failure.

3.2 Network Planning• Long term planning of physical resources – routers, servers, etc.; links between routers provided

by laying cables or purchasing leased-lines from other network operators.

• Generates requirements for long-term/static SLSs with peer ISPs/Ass.

• Provides details of physical topology to Network Dimensioning –a Topology Database which isnot explicitly shown in the current figure, is used by Network Planning.

• Receives notification from Network Dimensioning when physical resources are insufficient.



• Receives input from Traffic Forecast regarding predicted traffic for long-time periods(months/years).

• Policy Management may drive the planning decisions.

• Operates over long time scale (order of months).

3.3 Network Dimensioning• Maps a collection of SLSs to network resources considering load trends and it might require the

definition of a “network calculus” like the one defined for IntServ (note that such a calculus is alsothe target of the IRTF’s BuDS group).

• Receives input from the Traffic Forecast module about the forecasted load. The forecast of trafficwill be based on the subscribed SLSs but may also include foreseen SLS subscriptions (based onmonitoring and historical data) and factors to take into account dynamic SLS invocations, whichdo not conform to previously, subscribed SLSs.

• Provides SLS subscription with a view of spare network resources to allow the SLS Negotiationcomponent to be knowledgeable about whether the ISP can meet user requests; note these arelong-term SLSs/access control issues – not per flow (the latter will actually be handled by theAdmission Control part of the SLS Management – see the corresponding section). NetworkDimensioning passes the network configuration to SLS Subscription and this functional block”subtracts” the existing SLSs to obtain spare resources. This has the advantage that the SLSinformation does not have to pass through Dimensioning, (only the forecasted demand will needto) therefore leaving Dimensioning completely SLS unaware.

• Informs Planning when physical resources can no longer meet demand, and gets input from itabout new physical resources (connectivity – including link capacities).

• Interacts with the SLS Management (Inter-domain SLS Requestor) when the dimensioning of thenetwork results in needs for aggregate traffic to cross-domain boundaries. This is likely to besignificantly different from current inter-domain SLSs, therefore it might result in initiating inter-domain SLS negotiation/re-negotiation.

• Derives constraints/policies for distributed route/bandwidth management algorithms.

• In case DiffServ is supported over MPLS, there is the capability to organise a logical path networkover the physical underlying network in order to cope better with the expected traffic. Path-basednetworks support traffic-engineering functions better. Network dimensioning might initiate MPLSpath creation, if used.

• It is triggered by the Traffic Forecast and Dynamic Route/Resource Management modules, or in aperiodic way.

• Passes the network configuration to monitoring. This will probably be via the Connectivity andConfiguration Database (see below).

• Includes a Connectivity and Configuration Database.

• Operates with an AS-wide view (this does not rule out the possibility of the functionality beingdecomposed into sub-network dimensioning components, for scalability purposes). Compared todynamic control/management of routes and resources, Network Dimensioning should be much lessdynamic/distributed.

• Operates over a relatively long time scale (order of days/weeks).

3.4 Traffic Forecast• Its objective is to forecast the expected traffic, in the time-scales of both dimensioning and

planning, so it can provide them the appropriate predicted traffic matrices.



• It receives input from the customer subscriptions (SLS Subscription) and dynamic requests(including subscription/requests not accepted), the monitoring/measurements (both SLSMonitoring and Network Monitoring – see sect. Monitoring).

• It includes a Traffic Model Database (e.g. self-similar models).

• It might include some market models for the user behaviour.

• Its forecast might be affected from the administrator’s policies.

• Although it produces results (traffic matrices) in the time-scale of days-weeks for dimensioningand of months for planning it is operating continuously to collect the appropriate data.

3.5 SLS Management• This functional component is responsible for all the SLS-related activities. Due to its complexity it

could be further decomposed as shown in the figure bellow, where we show only the associationbetween the decomposed SLS Management and the other TEQUILA functional blocks.

• Note that functional blocks such as SLS Advertisement, Customer Complaints, Accounting (notshown in Figure 6) might also be considered as SLS Management functionalities. The TEQUILAProject will NOT investigate any of these issues; they are for future study and/or liaison with otherprojects/works.

• All the SLS Management activities can be affected by policies, therefore an appropriate PolicyConsumer must co-exist with each of the decomposed functional blocks.

6/6

6XEVFULSWLRQ

,QWHU�GRPDLQ

6/6 5HTXHVWRU

$GPLVVLRQ

&RQWURO

6/6�0DQDJHPHQW7UDIILF

)RUHFDVW

1HWZRUN

'LPHQVLRQLQJ

'\QDPLF

5RXWH

0DQDJHPHQW

'\QDPLF

5HVRXUFH

0DQDJHPHQW

8VHU

RU

8S�VWUHDP

,63�$6

'RZQ�

VWUHDP

,63�$6

7UDIILF

&RQGLWLRQLQJ

0RQLWRULQJ

6/6

6XEVFULSWLRQ

,QWHU�GRPDLQ

6/6 5HTXHVWRU

$GPLVVLRQ

&RQWURO

6/6�0DQDJHPHQW7UDIILF

)RUHFDVW

1HWZRUN

'LPHQVLRQLQJ

'\QDPLF

5RXWH

0DQDJHPHQW

'\QDPLF

5HVRXUFH

0DQDJHPHQW

'\QDPLF

5RXWH

0DQDJHPHQW

'\QDPLF

5HVRXUFH

0DQDJHPHQW

8VHU

RU

8S�VWUHDP

,63�$6

8VHU

RU

8S�VWUHDP

,63�$6

'RZQ�

VWUHDP

,63�$6

7UDIILF

&RQGLWLRQLQJ

0RQLWRULQJ

Figure 6: The SLS Management Functional Block and its interactions with other blocks.

3.5.1 SLS Subscription• Receives SLS subscription requests from users and from peer ISPs/ASs.

• Intended for customer service subscription and NOT for a per-flow admission control. It operatesin the management plane.



• Delegates policies/downloads rules for each user according to agreed SLSs to Admission Controlwhich, in turn, downloads rules/policies to traffic conditioners as and when necessary. The ruleswhen enforced will ensure that packets are marked with the correct DSCP, that out-of-profilepackets are handled in a certain way, etc.

• Includes an SLS Repository, which stores current and rejected (unable to subscribe) SLSs. Thisrepository is input to Traffic Forecast. Views of this repository might need to visible by theAdmission Control in order to add dynamically accepted (or rejected) SLSs.

• Performs static “admission control” in the sense that it knows whether a requested SLS can besupported or not in the network given the current network configuration – this is not aninstantaneous snapshot of load/spare capacity, but the longer-term configuration provided by theNetwork Dimensioning. It provides a view of the current available resources to Admission Controlfunctional block.

• Might request for further SLSs with other ISP/ASs through the Inter-domain SLS Requestor.

3.5.2 Admission Control – SLS Invocation• Performs admission control requested by the user. Its functionality resides in the control plane.

• Receives input from the SLS Subscription module about the current SLSs (or has a view of theSLS Repository). SLS Subscription will provide Admission Control with the current spareresources, since SLS Subscription will always have the most updated version.

• Also performs dynamic admission control for requests. This functional block uses a signallingprotocol to negotiate these dynamic SLS requests, which can be on a per-flow basis.

• Keeps track of the rejected/accepted admission requests in order to provide info to TrafficForecast.

• Local and/or network-wide load information, provided by monitoring, might be necessary tocome to an admission decision.

• Delegates policies/downloads rules for each user according to the admitted request to trafficconditioner. The rules when enforced will ensure that packets are marked with the correct DSCP,that out-of-profile packets are handled in a certain way, etc.

• Might request for dynamic admission control with other ISP/ASs through the Inter-domain SLSRequestor.

3.5.3 Inter-domain SLS requestor• Handles inter-domain SLS subscriptions/negotiations with peer ISPs/ASs according to requests

from Network Dimensioning (shorter-term modifications to SLSs – days/weeks) or from NetworkPlanning (long term/static SLS issues - months) through Network Dimensioning.

• It handles requests for either changing/renegotiating the SLSs (requested by the SLS Subscriptionmodule) or dynamic requests (requested by the Admission Control module), with the peerISPs/ASs in the case the pre-negotiated requests by the Dimensioning and Planning are notappropriate.

• Also responsible to request new long-term SLS subscriptions with peer ISP/ASs, or to handledynamic SLS requests from Admission Control.

3.6 User & Upstream ISP/AS’s inter-domain SLS requestor• The user/customer can be further decomposed as shown in Figure 7.



8VHU�RU

8SVWUHDP�,63�$6

6/6�6XEVFULSWLRQ

�0DQDJHPHQW�3ODQH�

'\QDPLF�5HTXHVW��

6/6�2SWLRQ�5HTXHVW�

5693�5HTXHVW

�&RQWURO�3ODQH�

'DWD�7UDQVPLVVLRQ

�'DWD�3ODQH�

GDWD

6/6�

6XEVFULSWLRQ

$GPLVVLRQ�

&RQWURO

7UDIILF

&RQGLWLRQLQJ

8VHU�RU

8SVWUHDP�,63�$6

6/6�6XEVFULSWLRQ

�0DQDJHPHQW�3ODQH�

'\QDPLF�5HTXHVW��

6/6�2SWLRQ�5HTXHVW�

5693�5HTXHVW

�&RQWURO�3ODQH�

'DWD�7UDQVPLVVLRQ

�'DWD�3ODQH�

GDWD

6/6�

6XEVFULSWLRQ

$GPLVVLRQ�

&RQWURO

7UDIILF

&RQGLWLRQLQJ

Figure 7: Decomposition of the User-Upstream ISP/AS functional block andinteractions with others.

• Subscribes/negotiates or renegotiates longer-term SLSs (management plane)

• Dynamically invokes SLSs. This may be a selection from a number of previously subscribedoptions or it may request a SLS, which is out-of-scope of the longer-term SLS subscription(control plane). The nature of these requests is for further study: It may be performed by RSVP ora similar protocol, the request may be implicit in the data transmission (e.g. use of particularDSCP), it could be via an XML transaction, or a new protocol could be conceived.

• Requests for traffic to be transmitted e.g. RSVP request (control plane).

• Users can be either organisations generating aggregate traffic or individuals.

• Generates traffic when request is admitted (data plane).

3.7 Traffic Conditioning• Marks packets with a certain DSCP according to negotiated SLS.

• Performs the required metering, policing and shaping. May also re-mark or drop excess traffic.

• Normally it is located at the boundary routers, but part of its functionality (e.g. re-shaping ) mayalso be part of core routers.

3.8 Monitoring• Includes both low-level node monitoring/metering and higher-level network-wide and SLS

monitoring as shown in Figure 8.

• Network Monitoring

• Builds network-wide view of current traffic and quality conditions (operates in themanagement plane).

• Determines what needs to be measured where and directs the monitoring/metering devicesaccordingly – identifies which parameters to measure, sets thresholds.



0RQLWRULQJ

6/6�0RQLWRULQJ

7UDIILF�

)RUHFDVW

$GPLVVLRQ�

&RQWURO

6/6�

6XEVFULSWLRQ

'\QDPLF�

5RXWH

0DQDJHPHQW

'\QDPLF

5HVRXUFH�

0DQDJHPHQW

1HWZRUN

'LPHQVLRQLQJ

1HWZRUN

0RQLWRULQJ

1RGH�

0RQLWRULQJ

0HWHULQJ

0RQLWRULQJ

6/6�0RQLWRULQJ

7UDIILF�

)RUHFDVW

$GPLVVLRQ�

&RQWURO

6/6�

6XEVFULSWLRQ

'\QDPLF�

5RXWH

0DQDJHPHQW

'\QDPLF

5HVRXUFH�

0DQDJHPHQW

'\QDPLF�

5RXWH

0DQDJHPHQW

'\QDPLF

5HVRXUFH�

0DQDJHPHQW

1HWZRUN

'LPHQVLRQLQJ

1HWZRUN

0RQLWRULQJ

1RGH�

0RQLWRULQJ

0HWHULQJ

Figure 8: Decomposition of the Monitoring functional block and its interactions with others.

• Includes database of historical load and quality measurements, in order to assist dimensioningand planning, i.e. it provides information to Traffic Forecast.

• Accepts monitoring/measurement requests by Network Dimensioning, Traffic Forecast andDynamic Route/Resource Management. They may also provide specific thresholds for laternotification.

• It receives the connectivity and configuration information from Network Dimensioning.

• Determines what needs to be measured where and directs the monitoring/metering modulesaccordingly – identifies the type of measurements needed and which nodes need to participatein the measurements. It is important to note that it might determine that there is need forpassive and/or active measurements (see node monitoring bellow for more details on this).

• Notifies/triggers Dynamic Route/Resource Management and/or Dimensioning (thresholdcrossings, link failures).

• Includes database of historical load and quality measurements, in order to provide input trafficforecasting whenever necessary.

• Node Monitoring

• Measures load, losses, etc. at a local level.

• Probes probably downloaded from the network-wide monitor.

• Used for SLS monitoring as well as for general network-wide traffic statistics.

• It should include an active monitoring engine, which performs delay and jitter measurementsnode-to-node within the ISP/ASs limits (Network-wide Monitoring is responsible then tocompute the end-to-end results). This engine puts necessary test streams into the forwardingpath (active probing). It schedules the measurements to comply with the IETF’s IPPM WG. Ituses caching to avoid loading the network with too much test traffic.

• Also the classic passive monitoring is included in this module. Passive monitoring relies oncounters (MIB probing) to perform monitoring. Counters are available in various parts of thenetwork: meters, classifiers and forwarding engines.



• Measures used/available bandwidth, aggregate and SLS (at the edge nodes) traffic statistics(packet lost/dropped etc)

• SLS Monitoring

• Takes as input the current SLSs (SLS repository) and acts as a client to Network and NodeMonitoring requesting specific performance parameters for each SLS. It may not be necessaryto monitor every SLS for every user in the AS - this may not even be feasible/cost-effective.

• Active measurements may not be necessary if metering and passive probing are enough.

• It is point of connection for charging/accounting schemes.

3.9 Dynamic Route Management• Based on constraints/rules/policies from the Network Dimensioning it dynamically modifies

routing parameters in local routers. If MPLS is used it dynamically adds/merges/splits/reroutesLSPs. There is an equivalent behaviour in the case of pure IP routing.

• Adjusts routing parameters (weights, load distribution on equal multi-paths, MPLS LSPs).

• It takes input from Monitoring, Admission Control.

• May trigger (re-) dimensioning when network/traffic conditions are such that its algorithms are nolonger able to operate effectively, e.g. load balancing cannot be achieved due to an insufficientnumber of alternative routes.

• Operates in a distributed fashion – but not necessarily one per router.

• Operates on relatively frequent time-scale (order of minutes).

3.10 Dynamic Resource Management• Sets buffer/scheduling parameters on links according to Network Dimensioning directives,

constraints and rules.

• Adjusts scheduler and buffer management parameters according to its inputs.

• Allocates capacity to existing/newly created paths (i.e. MPLS LSPs). OSPF TE capabilities alongwith the “QoS-routing” capable indication bit might yield the same allocation of capacity in thecase of pure IP routing.

• Ensures link capacity is not wastefully allocated to hard-reserved classes when other classes withan immediate need could better use the bandwidth.

• It takes input from monitoring Admission Control.

• May trigger (re-) dimensioning when network/traffic conditions are such that its algorithms are nolonger able to operate effectively, e.g. due to excessive high priority traffic, link partitioning iscausing lower priority/best effort traffic to be throttled.

• Operates on relatively frequent time-scale (order of minutes).

3.11 Routing• It can be QoS/Constraint-based, DSCP-aware.

• Uses constraints to reduce algorithm complexity – reduce convergence time.

• Dynamic Route Management may set routing rules.

• Coexistence of Layer-3 and LSP routing.



3.12 PHB Enforcement• Implements the defined PHBs (AF, EF, Default and CS PHBs).

• It includes buffer management and scheduling mechanisms.

3.13 Other ISP/AS• ISP/AS can be either upstream or downstream.

• In the case of an upstream ISP the functionality is similar to that of the User.

• Sends/receives requests for inter-domain SLSs.

3.14 Example: Bootstrapping the Tequila NetworkThe following section gives an overview of the bootstrapping scenario for the Tequila system based onthe definitions and inter-dependencies of the functional blocks comprising the Tequila functionalmodel. It is a preliminary example mainly serving as illustration of the Tequila Functional Model.Chapter 4 and following explain into more details the (inter-) working of each block

3.14.1 AssumptionsIn order for the Tequila system to reach the operational phase, the physical network, upon which theTequila system will operate, should be already in place and the appropriate Tequila-relatedinitialisation actions already completed. Thus, we assume two asynchronous phases preceding theoperational phase of the system. The first is called the "Zero Phase" and deals with the long-termnetwork planning from the business perspective and the installation of the physical networkequipment. The second phase deals with the bootstrapping of the Tequila system and uses as input theresults of the Zero phase.

The Zero phase is outside of the scope of the Tequila project. Therefore, no actions investigating theaspects of this phase will be undertaken by the project. However, the outcomes of the Zero phaseshould be described and specified in detail, since these will constitute the input of the bootstrappingphase.

3.14.2 Zero PhaseIt is assumed that the Zero phase is preceded by the business case definition at the business level. Thebusiness case is expressed in terms of:

• SLS Types, referring to the service types supported by the provider,

• Anticipated Traffic Matrix, denoting the prediction of the customer requests for specific SLSs atthe network level,

• Inter-Domain SLSs, that is the contracts with peer ASs/ISPs and

• Business Policies, further decomposed in

• SLS Admission Policies

• Planning/Dimensioning Policies

• Routing Policies



These aspects of the business case are stored in the system’s repositories, using simple data entryinterfaces or more sophisticated tools, as in the case of the Policy Management component. TheNetwork Planning component is then activated. Based on the business case, it calculates the networkphysical topology and stores it in the Topology Repository. The network topology, as resulted by theNetwork Planning, provides information regarding the equipment configuration, connectivity, networkinterfaces and routing.

The need for an SLS Repository has been identified here and thus added to the description of thisscenario. Moreover, there is a de-coupling of the SLS repository, Anticipated Traffic Matrix andTopology Repository. These functions serve requests from multiple clients and might be invoked indifferent phases of the system. For example, during the Zero phase the inter-domain SLSs are specifiedat the business level and thus have to be stored, while the SLS manager is not activated yet.

=HUR�3KDVH�

6/6�7\SHV

5HSRVLWRU\

$QWLFLSDWHG�7UDIILF

0DWUL[�5HSRVLWRU\

6/6

5HSRVLWRU\

3ROLF\

0DQDJHPHQW

1HWZRUN

3ODQQLQJ

7RSRORJ\

5HSRVLWRU\

5HTXHVW�6/6�7\SHV

5HTXHVW�$QWLFLSDWHG�7UDIILF�0DWUL[

5HTXHVW�3ROLFLHV

6WRUH�3K\VLFDO

1HWZRUN7RSRORJ\

6WRUH�3ROLFLHV

5HTXHVW�,QWHU�'RPDLQ�6/6V

6WRUH�6/6�7\SHV

6WRUH�$QWLFLSDWHG

7UDIILF�0DWUL[

6WRUH

,QWHU�'RPDLQ�6/6V

,QSXW�IURP�%XVLQHVV�/HYHO &RPSRQHQW�,QLWLDOLVDWLRQ

Figure 9: Zero Phase Message Sequence Chart

3.14.3 Bootstrapping Message Sequence ChartThe steps of the Tequila system bootstrapping are the following:

1. Activation of the Scheduling/Forwarding, Routing and Traffic Conditioning components per NE.The Routing component uses the information downloaded by the Network Planning during the lastZero phase execution.

2. Activation of the Dynamic Resource Management and Dynamic Route Management components.

3. Activation of the Monitoring component. The Monitoring retrieves initialisation information fromthe Topology Repository.



4. Activation of the Traffic Forecasting Management component. It uses as input the AnticipatedTraffic Matrix.

5. Activation of the SLS Management component.

• The SLS Subscription sub-component is activated and gets the policies it requires to operatefrom the policy management component.

• The Admission Control sub-component is activated.

• The Inter-Domain SLS Requestor sub-component is activated and requests the policies and theinter-domain SLSs decided during the Zero phase from the Policy Management component andthe SLS Repository respectively.

6. The Network Dimensioning component is activated.

• It gets information regarding the network topology, the SLS types, the policies, the inter-domainSLSs and the anticipated traffic matrix.

• It performs a verification test communicating with the NEs to ensure that all the NEs are up andrunning.

• Based on the policies obtained from the Policy Management, it calculates and downloads:

• Routing constraints and/or Explicit Routes to the Dynamic Route Managementcomponent,

• Bandwidth sharing constraints and/or scheduling parameters to the Dynamic ResourceManagement component and

• SLS Admission constraints and parameters to the Admission Control sub-component.

• Based on these constraints and parameters, the Dynamic Resource and Route Managementcomponents configure the Scheduling/Forwarding and the Routing components of the NEs.



'\QDPLF

5HVRXUFH��5RXWH�

0DQDJHPHQW

%RRWVWUDSSLQJ�3KDVH�

5HSRVLWRULHV

6FKHGXOLQJ

)RUZDUGLQJ

5RXWLQJ

7UDIILF

&RQGLWLRQLQJ

1HWZRUN

'LPHQVLRQLQJ

0RQLWRULQJ

7UDIILF

)RUHFDVWLQJ

0DQDJHPHQW

6/6

6XEVFULSWLRQ

$GPLVVLRQ

&RQWURO

,QWHU�'RPDLQ

6/6

5HTXHVWRU

1(V

6/6�0DQDJHPHQW

5HTXHVW�7RSRORJ\

5HTXHVW�$QWLFLSDWHG�7UDIILF�0DWUL[

5HTXHVW�3ROLFLHV

9HULILFDWLRQ�7HVW

5HTXHVW�3ROLFLHV��,QWHU�'RPDLQ�6/6V

&RQILJXUH�7UDIILF�&RQGLWLRQLQJ�

&RPSRQHQW�$FWLYDWLRQ &RPSRQHQW�,QLWLDOLVDWLRQ

5HTXHVW�7RSRORJ\��6/6�7\SHV��3ROLFLHV��,QWHU�'RPDLQ�6/6V��$QWLFLSDWHG�7UDIILF�0DWUL[

&RQILJXUH�5RXWLQJ

&RQILJXUH�6FKHGXOLQJ�)RUZDUGLQJ

'RZQORDG�%DQGZLGWK�6KDULQJ�&RQVWUDLQWV�DQG�RU�6FKHGXOLQJ�3DUDPHWHUV

'RZQORDG�5RXWLQJ�&RQVWUDLQWV�DQG�RU�([SOLFLW�5RXWHV

'RZQORDG�6/6�

$GPLVVLRQ�&RQVWUDLQWV�

DQG�3DUDPHWHUV

Figure 10: Bootstrapping Phase Message Sequence Chart



4 SERVICE LEVEL SPECIFICATIONSThis chapter brings together all issues related to Service Level Specifications (SLS): SLS contents andsemantics, SLS handling and functional scenarios and a further functional decomposition of the SLS-Management functional block. The main contribution of this chapter is the proposal of a template ofthe Service Level Specification (SLS) and the description of the SLS semantics, section 4.2. Theinformation of this section has served as input for the first contribution of the TEQUILA consortiumtowards Standardisation, i.e. an IETF Internet draft submitted to the DiffServ Working Group in July2000 entitled “Service Level Specification Semantics, Parameters and negotiation” [TEQUILA-1].

This chapter consists out of five main sections.

• The first section recalls the basic motivation for defining and standardising an SLS template.

• The second section presents a generic Service Level Specification template and its semantics. Ifthe SLS is seen as an object class, then this section describes the semantics of its attributes. TheSLS contains amongst others the essential Traffic Conformance Parameters and QoS PerformanceGuarantees. The SLS only contains the attributes relevant for traffic purposes and is as such itselfpart of the (broader) ISP/customer contract, i.e. the Service Level Agreement (SLA). The lattercontains e.g. the relevant properties of the customer.

• The third section describes examples of Service Types and introduces the notion of CustomerService. Three relevant service types (or classes) are accepted by the Tequila system. QuantitativeSLSs intended for the description of e.g. real-time services, Virtual Private Networks (VPN).Qualitative SLSs intended for the description of the Olympic service classes for relative delay orpacket loss guarantees (low, medium, and high). Best Effort SLSs describing Best Effort (BE)traffic. It is also described how customer services, such as VPNs or bi-directional VLLs can beconstructed with the SLS types defined in section 2.

• The fourth section handles the interaction of the SLS Management Functional Block with others.The following topics are covered: a high-level description of the main information streams andinteractions between SLS management, Traffic Forecast and Network Dimensioning; how are newor modified actually handled – on a high level – by the Tequila Network. A clear distinction ismade between SLS subscription, which resides in the Management Plane, and SLS invocation,which is a function in the control plane and deals e.g. with (Flow) Admission Control. The sectionalso gives possible scenarios for Inter-domain SLS negotiation and related problems.

• The fifth section discusses the support of Integrated Services (IntServ). The section shows how theTEQUILA functional model and the (DiffServ) SLS format can actually support IntServ. TheIntServ Guaranteed Service and Controlled Load are “Premium micro-flow services”. It isdescribed how RSVP Messages are captured by the TEQUILA Functional Model and how theinformation of the RSVP Objects, e.g. TSpec and RSpec, is mapped onto the DiffServ SLSs. Oncethese “IntServ” SLSs are created, they are handled by the TEQAUILA management system as allothers.

• The sixth section briefly introduces internal functional decomposition of the SLS Managementblock itself.

The Internet Draft covers the first two sections and partially the third (SLS examples). The notion ofbi-directional Customer Service, i.e. bundling of SLSs into a Customer container making up e.g. bi-directional VLLs or VPNs, is still under discussion. The last two sections are TEQUILA-specific.However, it is foreseen that the dynamic SLS-handling, i.e. subscription and invocation, which isfunctionally described here, will require standardised SLS-negotiation protocol(s) between customerand ISPs and between ISPs. These protocols will be further studied in deliverable D1.2 [D1.2].Therefore, it can be expected that the TEQUILA consortium will further contribute on these topicstowards standardisation.



4.1 Motivation and frameworkThis section identifies the basic information to be handled by Service Level Specification (SLS, [RFC2475], [DS-TERMS]) when considering the deployment of value-added IP service offerings over theInternet. Such IP service offerings can be provided together with a given quality of service (QoS),which is expected to be defined in such SLS, from a technical standpoint. Since these IP services arelikely to be provided over the whole Internet, their corresponding QoS will be based upon a set oftechnical parameters that both customers and services providers will have to agree upon. From thisperspective, the Tequila Draft – and the information in this section of the D1.1 deliverable - aims atlisting (and promoting a standard formalism for) a set of basic parameters which will actually composethe elementary contents of a SLS.

Such a specification effort tries to address the following concerns:

- Provide a standard set of information to be negotiated between a customer and a service provideror amongst services providers within the context of processing a SLS;

- Provide the corresponding semantics of such information, so that it might be appropriatelymodelled and processed by the above-mentioned parties (in an automated fashion).

Section 2 presents an outline for the definition of a Service Level Specification format and thesemantics that go behind this representation. The need to have such an agreed set of Service LevelSpecification parameters and semantics is manifold.

First, it is necessary to be able to allow for a highly developed level of automation and dynamicnegotiation of Service Level Specifications between customers and providers. Automation anddynamics are indeed helpful in providing customers (as well as providers) the technical means for thedynamic provisioning of quality of service. The automation in itself is e.g. necessary to allow roaming(dial-in) and to enable mobile users to have access and negotiate a transport Service Level,independent of their point of attachment to the network.

Second, the design and the deployment of Bandwidth Broker capabilities [TWOBIT] in a Multi-vendorenvironment requires a standardised set of semantics for Service Level Specifications being negotiatedat different locations:

- between the customer and the service provider (namely between the Customer Premises Equipment(CPE) and its point of attachment to the IP network managed by the service provider);

- within an administrative domain (for intra-domain SLS negotiation purposes);

- between administrative domains (for inter-domain negotiation purposes).

While the representation and semantics behind a Service Level Specification need to be standardised,this section does not assume that neither the syntax, nor the SLS negotiation protocol needs to beuniquely defined. E.g., the negotiation could make use of various other protocols such as http, RSVP,IPCP, DHCP, etc. The latter is for further study, and will be tackled specifically for the Tequila projectin Deliverable D1.2.

The only assumption in this section is that IP services will be deployed over a public IP infrastructure,which will be (partly if not completely) composed of DiffServ-aware network elements ([RFC-2475],[DS-MODEL]). These network elements are able to process Per Hop Behaviours (PHBs), includingthe Assured Forwarding PHB ([RFC-2597]), and the Expedited Forwarding PHB ([RFC-2598].Clearly the Tequila system, as explained in chapter 2, is an example of these.

Customers of such services include Internet Service Providers (ISP), who may well establish QoS-based peering agreements between themselves, and usual customers of ISPs, like those who composeboth the residential and the corporate market.



4.2 SLS contents & semanticsThe following describes the attributes of the SLS object. It can be expected that, as the project evolvesand further insight is obtained through implementation and simulation, more SLS-attributes couldpossibly be added to the definition. Especially some inter-domain aspects require further study. Forexample, the SLS defined by the Internet2 QοS Working Group, targeting EF-based Premium Services[QBONE], is a special case of our SLS definition below, except for one specific attribute Route. Thisattribute is used for inter-domain routing aspects in the QBONE architecture. Its use in the Tequilaproject is for further study.

4.2.1 ScopeScope = (ingress, egress)

The scope of a SLS (associated to a given service offering) indicates where the Quality of Service(QoS) policy for that specific service offering is to be enforced. Therefore the scope uniquelyidentifies the geographical/topological region over which the QoS is to be enforced by indicating theboundaries of that region.

The associated scope of the SLS MUST be expressed by a couple of ingress and egress interfaces.Ingress/egress denote respectively the entry/exit points of the IP packets relative to the region(network).

• Ingress : * | interface identifier | set of interface identifiers | all

• Egress : * | interface identifier | set of interface identifiers | all

Notations:

- "|" denotes an exclusive OR.

- "all" is logically equal to unspecified.

- “*” denotes that the Ingress and/or Egress identifier is implicitly derived from the by thesource/destination information in the Flow Identification (see next).

An ingress (or egress) interface identifier should uniquely determine the boundary link as defined in[RFC-2475] on which packets arrive/depart at the border of a DS domain. This link identifier MAY bean IP address, but it may also be determined by a layer-two identifier in case of e.g. Ethernet, or forunnumbered links like in e.g., PPP-access configurations.

The semantics allows for the following combinations of the number of (ingress, egress) interfaces:

• (1,1) - one-to-one or Pipe model

• (1,N) – one-to-many or Hose Model (N>1)

• (1,all) – one-to-any or unspecified hose model

• (N,1) – many-to-one or Funnel Model (N>1)

• (all,1) – any-to-one or Unspecified Funnel Model

The formal condition is thus that either egress or ingress interface MUST be specified to exactly oneinterface address. Thus SLSs describe Uni-directional traffic flows. Bi-directional customer servicesare constructed as a set (i.e. two) of SLSs: cf. section 4. Also VPN services allowing traffic to flowbetween N edge points, an (N, N) model, will also be constructed as a set of SLSs.



4.2.2 Flow IdentificationThe flow identification (Flow Id) of an SLS (associated to a given service offering) indicates for whichIP packets the QoS policy for that specific service offering is to be enforced. A Flow Id identifies astream of IP datagrams sharing at least one common characteristic.

An SLS Flow Id MAY formally be specified by setting one or more of the following attributes:

Flow Id = (DSCP, source information, destination information, application information)

• DSCP - Differentiated Services Code Point = specified value [RFC-2474]

• Source information = source address | set of source addresses | set of source prefixes | all

• Destination information = destination address | set of destination addresses | set of destinationprefixes | all

• Application information = protocol number | protocol number and source port, destination port |all

Note: "all" is again logically equal to unspecified.

Thus, the Flow Id may be expressed by information attributes related to the source/destination nodes,the application or the DS field in the IP header.

The Flow Id provides the necessary information for classifying the packets at a DS boundary node.This datagram classification can either be Behaviour Aggregate (BA) or Multi-Field (MF)classification based.

In case of BA-classification [RFC-2475], the DSCP attribute MUST be specified and the otherattributes MUST NOT be specified.

In case of MF-classification all attributes MAY be specified. Remark that MF classification may aswell depict micro-flows as aggregate flows [DS-MODEL].

Note that there are restrictions involved in combining scope and flow identification within a certainSLS instance.

Remark

In the context of SLS services specification, the TEQUILA system offers multiple level of granularitywhat concerns customers services differentiation. Indeed, this concept could be defined at host level,using the IP address as differentiation field, or even at application level. Concerning this last one, aclarification has to be made. Indeed, in order to differentiate an application from another, two schemesare possible. The easiest one is when the application is associated to well known port (thereforeenabling to use that port as discrimination factor). However, this situation is not always the case andapplication may be dynamically assigned ephemeral ports (e.g. via a signalling protocol as H.323) forthe time of the session. In this situation, the system could not use the used port values to distinguish anapplication from another. So, in order to be able to make that distinction, different mechanism arepossible. Some of them are: intercepting the signalling in order to capture the type of application beingnegotiated or even defining traffic patterns which have to be applied to new streams in order todiscover the type of the application being transported.

The detailed study of these applications (and supplementary complexity) is outside the scope of theTequila project; the possibility should however be recognised in the framework.



4.2.3 Traffic Conformance TestingTraffic Conformance Testing is the set of actions which uniquely identities the "in-profile" and "out-ofprofile" (or excess) packets of an IP stream (identified by Flow-Id). Traffic Conformance Testing willusually be done at a DS-boundary node.

The SLS specifies the Traffic Conformance Testing as a combination of the Traffic ConformanceParameters and the Traffic Conformance Algorithm. The Traffic Conformance Parameters describe thereference values the traffic (identified by the Flow ID.) will have to comply with, thus yielding thenotions of "In" and "Out" of profile traffics. The Traffic Conformance Algorithm is the mechanismenabling unambiguously to identify all "in" or "out" of profile packets based on these Conformanceparameters.

The following gives a (non-exhaustive) list of potential conformance parameters.

• Peak rate p

• Token bucket rate r, bucket depth b

• Minimum packet size m, Maximum Transfer Unit (MTU) M

Examples:

- Conformance parameters = token bucket parameters (b, r); conformance algorithm = token bucketalgorithm.

- Conformance parameters = peak rate p; conformance algorithm = (flow) rate must be smaller than p(at all time scales)

- Conformance parameters = maximum MTU; conformance algorithm = all packets allowed withsize smaller than MTU. Packets larger than MTU can be fragmented or dropped

Note on the relation with the Performance parameters.

- The traffic Conformance Algorithm (and parameters) MUST be specified when guaranteeingdelay/jitter or packet loss, i.e. if one of these performance parameters is quantified in the SLS.

- When only guaranteeing a throughput, or if non-of the performance parameters is quantified,the traffic conformance algorithm MAY be specified.

4.2.4 Marking and shaping services prior to Conformance TestingThis subsection indicates what should happen with packets entering the system prior to conformancetesting/traffic conditioning.

The semantics is that the (Tequila) Network may offer a number of services to its customer such asshaping or marking prior to conforming testing. For example if the host of the customer has not theability of marking the DSCP byte, then it could be requested by the SLS.

• Marking parameters

- Request marking (Boolean). If indicated, the customer requests the marking of its packets

- Requested DSCP. May or may not be indicated. If not indicated, and marking is requested, thenetwork marks based on other SLS information:

Marking = F(Flow Id, performance parameters, excess treatment)

- (advanced) Marking methods: e.g., two rate three-colour marker

• Shaping parameters

- Requested Shaping (Boolean). If indicated, the customer requests the shaping of its packets



- Shaping method: e.g. RASshaper (params)

The specification of the parameters and algorithms is subject of Deliverable D1.2.

4.2.5 Excess Treatment

This section describes how the service provider will process excess traffic, i.e. out-of-profile traffic.The process takes place after Traffic Conformance Testing, described previously. Excess traffic maybe dropped, shaped and/or remarked. The SLS MUST specify the appropriate action by the followingattribute.

Parameters & rules

• Excess treatment (integer) values: drop (1), shape (2), remark (3).

If not indicated, then excess traffic is dropped (default is (1)).

Depending on the previous value, more parameters may be required.

If value = dropping, then all packets marked as “out-of-profile” by the Traffic ConformanceAlgorithm are dropped. No extra parameters are needed.

If value = shaping, then all packets marked as “out-of-profile” by the Traffic Conformance Algorithmare delayed until they are “in-profile”. The shaping rate is the policing/token bucket rate. The extraparameter is the buffer size of the shaper.

If value = remarking, then all packets marked as “out-of-profile” by the Traffic ConformanceAlgorithm are (re-) marked with a particular DSCP-value (yellow or red). The extra parameter is theDSCP.

Remark

Treatment of excess traffic is in close relation with the type of service requested and the trafficperformance parameters. The mapping of services on PHBs is not topic of this document, but thegeneral ideas are the following:

If the SLS should be “mapped” on the EF PHB, then excess traffic is NOT allowed into the network.Therefore Excess Treatment Value = shape or drop:

If the SLS should be “mapped” on an AF PHB group, then excess traffic should be coloured (yellow orred). Re-ordering of packets is however not allowed, i.e. in-profile and out-of-profile packets belong tothe same AF-class (1 out of 4) and will be put into the same queue.

4.2.6 Performance Parameters

4.2.6.1 Definition of the parametersThe performance parameters describe the service guarantees the network offers to the customer for thepacket stream described by the Flow Id and over the geographical/topological extent given by thescope. All service guarantees are for the in-profile traffic; no guarantees are given for excess (out-of-profile) packets.

There are four performance parameters:

• delay | optional quantile

• jitter | optional quantile

• packet loss

• throughput



The following definitions always consider the (measurable) performance parameters related to thepacket stream specified by the Flow Id.

- The delay and jitter indicate respectively the maximum packet transfer delay and packet transferdelay variation from ingress to egress. Delay and jitter may either be specified as worst case(deterministic) bounds or as quantiles. Indeed, the worst case delay/jitter bounds will be very rareevents and customers may find measurements of e.g. 99.5th percentile a more relevant empiricalgauge of delay/jitter.

- The packet loss indicates the packet loss probability for in-profile packets from ingress to egress

Lost in-profile packets between ingress and egressPacket loss = ------------------------------------------------------------

Offered (injected) in-profile packets at ingress

- The throughput is the rate measured at egress counting all injected packets at ingress.

Remark on the relation between throughput & conformance parameters

- If there is only a throughput guarantee, then it is not necessary to specify the TrafficConformance Algorithm. Indeed, as the customer is only interested in a throughput it is notrequired to have a distinction between in- and out-of-profile packets. Of course, the operatorwill probably protect his network by implementing a Traffic Conditioner at Ingress andspecifying the token policing rate (r) equal to the throughput guarantee R, R=r. He may ormay not tag/mark excess traffic, according to his own – internal – policy rules.

- If the Traffic Conformance Algorithm, e.g. token bucket (b,r) with r=R is specified then again,excess can or can not be allowed. If excess traffic is allowed (marked), then "throughput"indicates a minimum guarantee. It is the guaranteed throughput for in-profile packets whileextra available resources may eventually be allocated to the out-of-profile traffic. If excesstraffic is dropped/shaped, then "throughput" indicates a maximum guarantee.

4.2.6.2 Qualitative & Quantitative Service ClassesQuantitative performance guarantees

A performance parameter is said to be quantified if its value is specified to a numeric (quantitative)value. The service guarantee offered by the SLS is said to be quantitative IF at least one of the 4performance parameters is quantified.

Qualitative performance guarantees

If non of the SLS performance parameters are quantified, then the performance parameters "delay" and"packet loss" MAY be "qualified".

Possible qualitative values (for delay and/or loss): high, medium, low.The default value is high, i.e. theworst case. Note that the quantification of relative difference between <high/medium/low> is aprovider policy (e.g. high = 2 x medium ; medium = 2 x low).

Relative Delay guarantees:

- gold service : value = low

- silver service : value = medium

- bronze service : value = high or not indicated (default)

Relative loss guarantees

- green service : value = low

- yellow service : value = medium

- red service : value = high or not indicated (default)



This yields the following combinations of relative/qualitative/CoS service classes.

delayloss

low medium high

low gold green silver green bronze green

medium gold yellow silver yellow bronze yellow

high gold red silver red bronze red

The service guarantee offered by the SLS is said to be qualitative if it is NOT quantitative and eitherdelay or loss (non-exclusive) are qualified to "medium" or "low", i.e. excluding bronze/red from theabove.

The service guarantee offered by the SLS is said to be best-effort if it is NOT quantified nor qualified.

4.2.7 Service scheduleThe service schedule indicates the start time and end time of the service, i.e. when is the serviceavailable.

This might be expressed as collection of the following parameters:

� Time of the day range

� Day of the week range

� Month of the year range

� Year range

Some examples:

• Time of the day range

08h00-18h00

• Day of the week range

A single day : Monday

A group of sequential days : [Monday:Friday]

• Month of the year range

A single month : September

A group of sequential months : [January:Jully]

• Year range

A single year : 2000

A group of sequential years: [2000:2002]

Remark: service schedule “from now on” [now, ∞] can be captured as follows:

- Time =[00h00, 23h59]

- Day = [1,7]; where 1=Monday

- Month = [1, 12]; where 1 = January



- Year = [present year, 9999]

4.2.8 ReliabilityReliability indicates the maximum allowed mean downtime per year (MDT) and the maximumallowed time to repair (TTR) in case of service breakdown (e.g. in case of cable cut).

• Mean Down Time (minutes per year)

• Maximum Time To Repair (seconds)



4.3 Examples: Service Types & Customer ServicesThis section gives some examples of IP Services, which can be formally described based on theTEQUILA SLS defined above. Examples include the IP Premium Service (similar to the QboneInternet2 initiative [QBONE]), qualitative Olympic Services, bi-directional Virtual Leased Lines(VLL) and Virtual Private Networks (VPN).

4.3.1 Quantitative (QoS - Premium) services

4.3.1.1 Virtual Leased Line for real-time applicationsThis VLL has a bandwidth guarantee and strict quantified delay and packet loss requirements(guarantees) between the Ingress and Egress point. Excess traffic is dropped at the boundaries.

SLS specification

• Scope: Pipe model (hose model is NOT allowed).

• Flow Id: set of (source information, destination information, application information) OR DSCP-value (e.g. standardised DSCP indicating the EF-PHB).

• Traffic Conformance Parameters: token bucket parameters (b,r) MUST be identified

• Treatment of excess traffic: dropping. Thus: only green packets are allowed into the network.

• Performance Parameter: guaranteed throughput R, delay and packet loss MUST be indicated.Typically R = r. Jitter MAY be indicated.

• Service Schedule: may be indicated

• Reliability: may be indicated

Typical applications

This VLL could be used by the customer for supporting interactive real-time services. For exampleVoIP or Videoconference micro-flows could be multiplexed into the VLL. However, the Operator onlyoffers a VLL and it is the responsibility of the customer to control the traffic (and number of micro-flows) which are multiplexed into the VLL pipe. Thus, in this model, it is up to the customer toperform admission control of micro-flows.

4.3.1.2 Virtual Leased Line for data-applicationsThis second type of VLLs (only) offers a quantified bandwidth guarantee and loose requirements ondelay and packet loss. Delay and loss are not quantified and are only expected to be “low” for the in-profile packets. Excess traffic is allowed but should be marked/tagged appropriately.

SLS specification

• Scope: Pipe model (hose model is NOT allowed).

• Flow Id: set of (source information, destination information, application information) OR DSCP-value (e.g. standardised DSCP indicating the EF-PHB).

• Traffic Conformance Parameters: token bucket parameters (b,r) MUST be identified

• Treatment of excess traffic: marking.

• Performance Parameter: guaranteed throughput R = r. Delay, loss and jitter are not specified

• Service Schedule: may be indicated

• Reliability: may be indicated




Basically VLL type 2 gives a throughput guarantee R - without specifying delay or packet loss. Ofcourse, if the customer injects traffic at a rate r <= R, then delay and loss will be low (implicitguarantee of low loss and low delay).

4.3.1.3 Real-time Micro-flows with strict delay guaranteesSLS specification

• Scope: one-to-one communication (Pipe model), (Ingress, Egress) specified

• Flow specification: (source IP-address, destination IP-address, source port number, destinationport number, protocol)

• Traffic Conditioning: leaky bucket (b,r), peak rate p= r = 64 Kbps

• Excess Treatment = dropping.

• Performance Parameters: delay = 10 msec, packet loss = 10E-3, guaranteed throughput R = r.

Typical Applications

• IntServ Guaranteed Service flows

• VoIP requiring strict delay guarantees

4.3.1.4 Minimum guaranteed rate with allowed excessSLS specification

• Scope: Pipe or hose model (!)

• Flow specification: set of (source information, destination information, application information).OR a DSCP-value indicating a possible AF-PBH.

• Traffic Conformance Parameters: (b, r) MUST be indicated

• Excess traffic: Remarking MUST be indicated

• Performance Parameter: the guaranteed throughput R = r. Other parameters MUST NOT beindicated.


• IntServ Controlled Load flows

• Adaptive applications requiring a minimum throughput for the service, e.g. MPEG video streams,

• Applications that could rely on RTCP to come back with flow characteristics to adjust codecs,…

• Bulk FTP traffic that requires minimum, but would take everything it can get (TCP).

4.3.2 Qualitative (CoS – Olympic) servicesService Level Specification

• Scope: pipe, hose (1|1,N,all), funnel

• Flow specification: MAY be indicated

• Traffic Conformance Parameters: MUST be indicated. The token bucket rate r indicates an(average) maximum Committed Access Rate (CAR) for which “better-than-best-effort” treatmentwill be applied.



• Excess traffic MUST be (re-) marked. For example green packets to yellow or unmarked packetsto yellow or red (excess packets allowed into the network MUST NOT be green). Excess packetsremain however into the same delay class (gold, silver, bronze) because packet-re-ordering is NOTallowed. However, if this type of service is targeting real-time flows (without strict guarantees)then supplementary mechanisms should be foreseen to keep the delay low, e.g. dropping of excesstraffic or intelligent buffer acceptance algorithms for isolating in-and out-of-profile packets.

• Performance Parameter: Delay OR loss MUST be indicated qualitatively. Throughput and jitterMUST NOT be indicated


• the gold/green delay class can be used for real-time services without strict guarantees (givingpriority to these packets over silver/bronze and BE + dimensioning small queues s.t. queuing delaywithin the class is small). Th

• Better-than-best effort data traffic applications

• Differentiating different applications, e.g. web traffic gets better condition than mail traffic overthe WAN without any hard guarantees.

4.3.3 The Funnel ServiceThe service offered by the funnel model is primarily a protection service: the customer wants to set amaximum on the amount of traffic (characterised by a DSCP) entering his network.

Figure 11: the funnel model

In Figure 11, the customer A requires that the traffic entering his network from A,B and C does notexceed the rate aout.

Optionally, the Funnel my also offer throughput guarantees for the aggregate traffic coming from a(finite) number of ingress points.

SLS specification

• Scope: Funnel (N|all,1).

• Flow specification: DSCP MUST be indicated. The filter (see below) is applied to all trafficcharacterized by the DSCP -value.

• Traffic Conformance Parameters: (b, r) MUST be indicated. The token bucket parameters indicatethe maximum allowed throughput (r = a_out) towards the customer network on the specifiedegress interface. This maximum or filter is applied to all packets marked with the DSCP-valueindicated above.

• Excess treatment: dropping (this is actually the service offered by the network).

$

%

&

'

1HWZRUN1HWZRUN

DRXW

+RVH��+RVH��



• Performance Parameter: not specified.


• Business customers restricting e.g. the amount of web browsing traffic entering their network.

• Concerning guarantees. Typically a residential user could watch simultaneously two videos. If therates must be specified for the individual pipes (each video separately), then this customer servicemust be constructed as a container of 2 (or more) SLSs, see next section.

4.3.4 Best Effort trafficSLS specification:

• Scope : all models

• Flow specification : none

• Excess Treatment: not specified

• Performance Parameters: none

• Service Schedule: may be indicated.

• Reliability: may be indicated.

4.3.5 Bi-directional Virtual Leased LineCustomer Services

This section and the following describes how customer services, such as bi-directional Virtual LeasedLines and VPNs can be constructed with the SLS types as defined above. The basic idea is indeed thatthe SLSs are basic building blocks for constructing services.

Formally a Customer Service is a container or a (finite) set of and a number of conditionsinvolving attributes (parameters) of more then one SLS (conditions on a “supra” level). A customerservice will probably be modelled itself as an object class containing a number (array) of SLS-id’s andformal conditions.

Concerning customer-service negotiation, member-SLSs of the same customer service are all allowedor all rejected, i.e. atomicity is required in providing these SLSs.

The basic problem of bi-directional SLSs is handled by simply making a set of 2 SLSs where (ingress,egress) are inter-changed. Thus:

• A single SLS always describes UNI-directional traffic from ingress to egress.

• a bi-directional VLL is the set of 2 SLSs SLS1 and SLS2 where the “supra” level condition is thefollowing: Ingress1 = Egress2 and Egress1 = Ingress2

• All other SLS1/2 attributes are independent from each other. This allows for completely a-symmetric traffic characteristics and service guarantees.

4.3.6 “Hose” Virtual Private Networks• Model 1 First consider the hose SLS given by Figure 12, hose 1. The basic parameters of this SLS

are:

- (ingress = A, egress = B,C,D)

- The aggregate injected traffic from A has a throughput guarantee of ain. There are noguarantees concerning individual traffic streams from A to e.g. B. The guarantee concerns theaggregate traffic from A to any egress point B,C, D.



• Model 2 : consider a VPN made out of 4 SLSs as described in Figure 12.- The aggregate traffic from the all other nodes to a particular node in the hose.

Figure 12: Four Uni-directional Hoses.

• Hose 1:Scope: Ingress A, Egress B, C, and DTraffic Conformance Parameter: ain as the maximum allowed throughput from A

• Hose 2:Scope: Ingress C, Egress B, A, and DTraffic Conformance Parameter: cin as the maximum allowed throughput from C

• Hose 3:Scope: Ingress B, Egress A, C, and DTraffic Conformance Parameter: bin as the maximum allowed throughput from B

• Hose 4:Scope: Ingress D, Egress A, B, and CTraffic Conformance Parameter: din as the maximum allowed throughput from D

Conclusion (cf. also discussion on the Tequila mailing list)

A hose SLS only specifies the input rate at the (single) Ingress point. There are no specificationsabout output rates at Egress points.

Analogously, Funnel SLSs (only) specify output rates at the (single) Egress point.

The VPN described above is a made of a set of four SLSs. The “supra” condition is again on thecouples of (ingress, egress) points.

$

%

&

'

1HWZRUN

1HWZRUN

DLQ

+RVH��

+RVH��

&

%

$

'

1HWZRUN

1HWZRUN

FLQ

+RVH��

+RVH��

%

$

&

'

1HWZRUN

1HWZRUN

ELQ

+RVH��

+RVH��

'

$

%

&

1HWZRUN

1HWZRUN

GLQ

+RVH��

+RVH��



• Model 3: Additional constraints are put on the throughput from the network towards the customerat each egress, i.e. the funnel (filter) model (SLS type 1.c) is applied at each egress point to limitthe traffic coming from the network towards the customer.

We have 4 extra SLS scope (N,1) with a Performance guarantee setting a filter at the egress points:aout as the maximum allowed (aggregate) throughput to A (coming from B,C,D),bout as the maximum allowed throughput to B,cout as the maximum allowed throughput to C,dout as the maximum allowed throughput to D.

Extra “supra”-level conditions can be put in the 8 throughput parameters.

Figure 13: VPN with 8 SLSs

This model is the preferred (hose) model VPN providing performance guarantees based on aggregatetraffic specifications. The customer needs to only specify the aggregate traffic in and out of each hoseendpoints. Unlike the pipe model VPN, the customer does not have to specify the full traffic matrix orthe spread of this traffic to other hose endpoints in the VPN. This gives the customer freedom to sendtraffic between each pair of endpoints, provided the aggregate traffic in and out of each of theendpoints does not exceed the respective hose capacities.

$

%

&

'

1HWZRU1HWZRU

DRXW

DLQ

ERXW

ELQ

FRXW

FLQ

GLQ

GRXW



4.4 SLS Handling – Functional Scenarios

4.4.1 Introduction on Traffic Forecast & Prediction“One thing that is sure about predictions, is that they are always wrong…”

Traffic prediction is one of the more critical functions of the TEQUILA system. This section willelaborate on its exact functionality and provide some input on how it might be implemented andproven useful in the TEQUILA functional architecture.

The main function of traffic prediction is to generate a traffic estimation matrix to be used by theNetwork Dimensioning functional block.

What needs to be predicted is the amount of traffic of each customer service type, that will enter theAS at a certain ingress router and that has as destination address a prefix in the AS or advertised route(by BGP) in the global Internet. This might at first seem a whole bunch of information to start with,however, aggregation of that information will be fed customised to be used by network dimensioning.

A first level of aggregation is to bundle all the traffic that is intra-domain solely and as such a source-destination matrix will be made for each customer service type. This may already yield a considerableamount of information, especially when considering IP VPNs…and possible private addressingschemes.

A second level of aggregation takes into account inter-domain traffic and it combines all traffic thatneeds to end at a certain destination AS (that means the traffic prediction function needs to haveinsight into the BGP route information).

From this, a second matrix can be constructed, a source-destination AS matrix will be made for eachcustomer service type. This inter-domain traffic in turn, adds to the ingress/egress traffic matrix.

Once the egress point for inter-domain traffic is selected (which may however be not unique, yieldingthe use of the MED attribute, for example), both matrices can be combined to find the full amount ofdata between any ingress and egress router in a certain AS. This yields the following Traffic PredictionMatrix:

Per class of service, the predicted traffic load per ingress/egress pair

per Class of Service Egress_x Egress_y

Ingress_I A(I,x)

Ingress_J

Per CoS: A(I,J) is the predicted load between ingress I and Egress J. It counts as well the solely intra-domain as inter-domain (transit) traffic.

This information is fed to Network Dimensioning.

It is assumed that the network dimensioning will take this decision based upon resources availablewithin the AS itself, and its negotiation of capability (and cost associated with) aggregate SLS with theselected next hop (see also the section on inter-domain SLS negotiation). Subsequently, Networkdimensioning will dimension the internal links of the AS to be able to transport the traffic and interactwith the inter-domain routing to indicate what path vector to advertise to the upstream peer.

How does traffic prediction comes to its base matrix?

The following information can be taken into account for traffic prediction

• SLS subscription history: the present Subscribed SLSses and the changes in these.



• Network physical topology: According to the type of customers at the border (residential users,VPN sites) and the physical nature of the access links (ADSL, VDSL, PON, WLL, SDH, PoS, …)predictions can be made on the SLS subscription behaviours.

• Business policy: e.g., basic QoS packages for residential users / SOHO, enterprises, etc…

• Etc…

The internal algorithms will be detailed in D1.2

Remark about over-subscription

The TF module calculates the predicted load taking into account certain over-subscription policyrules. Indeed, long–term SLSs allow for over-subscription because not all SLSs will actually beinvoked at the same time. Take for example an Access Router, which terminates (incoming) xDSLlines with a 1 Mega bps capacity. Given that the Access Router has an (outgoing) link capacity of 100Mega bps, then it is clear that more than 100 access lines can be subscripted.

Based on certain algorithms and business policies, there could e.g. be an over-provisioning index (OPI)of 1:5, allowing in this case SLS subscriptions up to 500 Mbps i.s.o. 100 Mbps.

Still in this example, if there are 400 SLS xDSL line subscriptions, then the TF Module will predict atraffic load of 400/5 = 80 Mbps.

Further details about over-subscription, and how this might affect the SLS format and semantics, canbe found in section 4.4.5. This discussion may introduce a new SLS attribute, i.e. Grade of Service orBlocking probability. This attribute is typically for enabling the network operator to have over-subscription policies. The attribute is also specific for SLS subscription objects (and not SLSinvocation objects).

4.4.2 SLS-Management, Traffic Forecast & DimensioningBefore going into the details of the Functional Scenarios about SLS Handling, we first give the maininformation streams and interactions between SLS management, Traffic Forecast (TF) and NetworkDimensioning (NW-Dim). This should give a high-level understanding of how things are actuallyworking, i.e. how is the Tequila network dealing with new/modified SLSs.

NW-Dimensioning

Traffic Forecast

SLS subscription

A.C. / SLSInvocation

[Traffic Matrix]

[SLS repository]

[NW config]

[Traffic Matrix]

[NW config]

NetworkMonitoring

[current network load]

[SLS policies]

NetworkMonitoring

Over-subscriptionpolicies

planning

[aggregate NW load] [over-subscription Indexes]

[physical resources][topology]

Figure 14: SLS-Management, Traffic Forecast and NW-Dimensioning (1)



Network Configuration – Actual allocated Resources

The Network Dimensioning FB receives as the main input the Traffic Forecast Matrices, the physicalresources (planning) and eventually policy rules. It calculates the Network configuration. The NetworkConfiguration gives the actual resources that are allocated to the network (links, buffers,…).Important for SLS management is the following subset of the NW configuration:

Network Configuration parameters

• per QoS class and Per Ingress/Egress pair

• Source/destination (Ingress/Egress) route set (if e.g. Multi-path routing)

• route capacity

• (eventually) QoS parameters such as the maximum transfer delay from ingress to egress (Editor’snote: should this be calculated here? Maybe transfer delays will be based on measurements,provided by Network Monitoring and stored somewhere in a MIB)

• Per QoS class and per peering Autonomous system

• Border routers to this AS

• capacity of the pipe between the border router and the peering AS

In fact, the Network Configuration parameters have a similar structure as to the Traffic ForecastMatrix. However, the NW Configuration gives the resources that are actually allocated while the TFMatrix is a prediction of the load.

Of course, network configuration has also more “detailed” parameters important for the configurationof schedulers, buffer algorithms… These are however not needed for SLS management.

Accepting new/modified SLS subscriptions

SLS subscription is responsible for the permission/rejection of new/modified long-term SLSsubscriptions. This is based on administrative policies and available spare resources.

SLS subscription (and not NW-Dim) calculates the available spare resources for new SLS subscriptionrequests. Roughly speaking, one has:

“Long-term Spare resources = NW-Config – Long term traffic load”

NW-Config is provided by NW-dim. The question is however what is “long-term traffic load”. Thiscan not be based on instantaneous measurements of traffic load. It should be based

• on the current SLS-subscriptions

• long-term Network-wide (aggregate) monitoring reports

• over-subscription policies

The Traffic Forecast Module provides this. Thus one has

“ Long-term Spare resources = NW-Config – Traffic Forecast Matrix”.

Therefore, the TF Matrix must be downloaded from TF Module to the SLS subscription.

Of course, the equality above is not exact and a rigorous calculation of the long-term spare resources,i.e. the exact algorithm, is handled in Deliverable D1.2.

Alternative Solution

There is a possible alternative for the information flows depicted in Figure 14. This alternative is givenin the next Figure.



NW-Dimensioning

Traffic Forecast

SLS subscription

A.C. / SLSInvocation

[Traffic Matrix]

[SLS repository]

[NW config]

[NW Config]

NetworkMonitoring

[current network load]

[SLS policies]

NetworkMonitoring

Over-subscriptionpolicies

planning

[aggregate NW load] [over-subscription Indexes]

[physical resources][topology]

[Spare Resources]

Figure 15: SLS Management, Traffic Forecast & NW Dimensioning (2)

The main difference with the first solution is that Traffic Forecast is calculating the long-term Spareresources, based on its input (as before) and the Network Configuration. An advantage is e.g. that onlyTraffic Forecast must be aware of the over-subscription policies. A choice between the twoalternatives depends on the concrete algorithms and protocols [D1.2].

SLS Invocation/ Admission Control

SLS invocation/ Admission Control is responsible for dynamic SLS-admission/rejection. If the SLS isonly long-term, e.g. a VLL for data-traffic, then the SLS invocation process is superfluous because theSLS is invoked automatically after a successful SLS subscription (see section 6.2 for more details).Therefore, SLS admission control is only required in case of:

- Dynamic short-lived micro-flow SLSs

- Short-lived micro-flow SLSs “multiplexed” in a long-term SLS subscription. This might either bethe responsibility of the (Tequila) Network operator or the Customer, depending on the businessmodel. This is explained into more details in chapter 4.5, discussing the support of IntegratedServices over the Tequila DiffServ network.

The input for the Admission Control Algorithm is

- SLS subscription information enabling e.g. authorisation for micro-flows which are a (partial)invocation of a previously SLS subscription.

- Administrative & SLS policy rules, e.g. enabling different accounting for micro-flows which don’thave a previous SLS subscription (“unknown” micro-flow SLSs)

- NW-configuration, which is downloaded from SLS subscription/NW-dimensioning.

- Effective Bandwidth, is the bandwidth that is actually allocated to a path (e.g. ingress/egress LSP)by the dynamic Route/Resource Manager. Indeed, Network Configuration sets the overall networkconfiguration and thus also the bandwidth of pipes on a relative long time scale. Dynamic resourcemanagement MAY vary this bandwidth pipes between certain thresholds, according to Policy rulesand the instantaneous (measured) load.



- Network monitoring (edge-to-edge information)

Example of bandwidth definitions between ingress A and egress B

- Predicted Traffic Load = 10 (units)

- Configured Load by NW Dim = 12 (NW Config finds out that there is enough resources anyway)

- Effective Bandwidth = 11 (may e.g. vary between 10 and 14), set - locally on the pipe- by theDynamic Resource Manager

- Measured load = 9 (value obtained by Monitoring)

The exact Calculation of “short-time” spare resources, i.e. the Admission Control Algorithm, is subjectof Deliverable D1.2 and it will probably depend on the previous Bandwidth definitions, on the Class ofService, QoS parameters and on instantaneous measurements. For example, one could have

“ Short-term spare resources = Effective bandwidth –network load trend”

The SLS admission control is “distributed”, i.e. the algorithm is executed at the ingress edge router ofthe network. Roughly speaking, consider a micro-flow with scope [Ingress, Egress] = [A, B]. Then, atthe edge A, the admission is based on:

- Effective bandwidth in the pipe [A,B] (this is a subset of NW-Config)

- Current load (of the appropriate QoS class) measured at A with destination B.

- Other QoS parameters such as the ingress/egress delay from A to B.

- The QoS requests of the new micro-flow SLS (capacity, etc…)

4.4.3 Inter-Domain SLS negotiationThis section briefly introduces possible schemes for Inter-domain SLS negotiation. The section onlygives a high level overview of SLS-negotiation approaches. More details with other functions relatedwith Inter-domain issues, e.g. BGP4 routing, are handled in Deliverable D1.2

Three possible schemes are identified for inter-domain SLS negotiation (and set-up):

• Hop-by-Hop SLS negotiation (where a “Hop” is an Autonomous System – AS)

• End-To-End SLS negotiation with eventually pre-establishment of Inter-AS pipes

• Local SLS negotiation

4.4.3.1 Hop-by-Hop SLS negotiation

SLS

SiteA

SiteB

AS1 AS2 AS3

SLS-hit

2 31

4- ACK5-ACK6-ACK

Figure 16: Hop-by-Hop SLS negotiation



Consider the example of a Virtual Leased Line between Customer site A and B, crossing threeAutonomous Systems (AS). The general question is what should happen if an SLS hits an AS, e.g.AS1.

In the Hop-by-Hop scenario, the SLS (subscription) negotiation and admission is done betweenCustomer-AS or between peering AS.

In this scenario ASi is responsible for:

• Reserving resources at its ingress/access link, i.e. reserving capacity at the ingress router forhandling the incoming traffic.

• Reserving its own (intra-domain) resources between ingress and egress.

• Launching SLS negotiation between ASi and AS(i+1)

For (off-line) SLS subscription negotiation, this means that ASi can only acknowledge AS (I-1) ifitself gets an ACK of AS (I+1). In the example above, AS3 first has to acknowledge, followed by AS2and finally AS1 acknowledge the customer.

A further issue is whether or not AS3 has to launch “SLS negotiation” with the customer site B(supposed to be an access link). Indeed, customer site B should acknowledge because the (newly)incoming traffic could possible disturb already established SLSs.

4.4.3.2 End-to-End SLS negotiationIn this case AS1, which is (first) hit by the SLS, is responsible for the establishment of resources fromcustomer site A to customer site B.

ClientAccess

SLS

SiteA

SiteB

AS1 AS2 AS3

1: pre-establishment of “Internet” pipe SLSs2: SLS-hit

3: ACK

Figure 17: End-to-End SLS negotiation based on “Internet pipes”

In this scenario, the AS which is hit by the SLS (AS1), is responsible for:

• Reserving resources at its ingress/access link

• Reserving its own (intra-domain) resources between ingress and egress

• Having (!) established an “Internet pipe” between its egress and the egress of the lastAS/destination (depending on the nature of the destination). This is actually done before the SLSarrives at AS1.

How these pipes are effectively put in place is rather a business issue than a technical issue. Forexample, AS1 could have negotiated a bandwidth pipe SLS with AS2 where the destination is part ofthe contract (e.g. site B with a particular network prefix). It is then the responsibility of AS2 to pre-establish pipes with (eventually) other ASs to reach destination B.



Remark that the destination can be “discovered” by the Flow Id attribute in the SLS template.

The acknowledgement (Admission Control) of the SLS now depends on:

• The available intra-domain resources in AS1

• The available “Internet pipe” resources, i.e. can the SLS still be multiplexed in the pipe or not.

The advantage is that there is no “cascade” of SLS negotiations, ACKs… The major disadvantage ishowever that each AS must maintain an Inter-domain Matrix of available pipes for traffic originationfrom AS (I) and terminating in AS (J).

Remark also that this mechanism only works for SLSs where source and destination are both know!

4.4.3.3 Local SLS negotiation (only)This is a simple scheme fitted for (short-lived) micro-flows without any hard quantitativeguarantees, e.g. Olympic or Best-effort services.

There are no restrictions on the SLS-scope or the SLS-Flow Identification. There will be no signallingin the control plane.

SLS

SiteA

SiteB

AS1

AS2

AS4

AS3

1: SLS-hit

2: ACK

Figure 18: Local SLS negotiation without guarantees

The scenario is very simple. There is an off-line SLS subscription negotiation, e.g. for theestablishment of an ADSL access line (with e.g. 1 Mbps capacity). After the ACK (customer paid forhis access line), the customer may send “better-than-best-effort” traffic, e.g. gold/green traffic. He hasno guarantees, but is “hoping for the best”.

This approach can be used for micro-flows with as well data-traffic as real-time interactive traffic suchas VoIP. Of course there are no hard guarantees.



4.4.4 SLS-subscription & -Invocation inter-working

4.4.4.1 TerminologyThe following sections give an overview of the Customer service (SLS)-handling for the TEQUILAsystem. The SLS management functional component is responsible for all the Customer-service (SLS)-related activities. Considering the Customer-service handling functional process we may considerthree consecutive (sub) processes:

- Customer service (SLS) subscription process resulting in SLS permission or SLS refusal

- Customer service (SLS) invocation process resulting in SLS admission or SLS blocking

- Data transmission

The Customer-service (SLS) subscription and Customer-service invocation process are described intomore detail in respectively section 4.4.5 and 4.4.6. Examples illustrating the ideas can be found insection 4.4.7. In the following we will mainly use the terminology “SLS subscription, SLSinvocation”, etc…

4.4.4.2 Partial and dynamic SLS invocationBefore going into details and the Message Sequence Chart of the sub-process, it is important toemphasise the following concepts about the inter-working of the subscription and invocationprocesses.

• Clearly SLS-subscription and SLS invocation are NOT independent processes.

- IF both processes occur (and result in data-transmission), then the time-order in which theseprocess may occur MUST be respected; that is:

- SLS invocation is only possible after a successful SLS subscription (permission)

- Data transmission is only possible after a successful SLS invocation (admission)

- IF the customer-service (SLS) requires some network guarantees or – more precisely – if thecustomer requires contractual guarantees from the network, which may be controlled – THENthe customer service subscription process is MANDATORY. For example all long-term SLA-contracts with peer Autonomous Systems MUST contain a Customer-Service (SLS)subscription object.

- SLSs MAY also be invoked without previous SLS-subscription. In this case the network“does what it can” for serving this SLS (invocation), meaning that such an SLS MAY alwaysbe blocked (even if the SLS-instantiation contains some quantitative guarantees). Typicallythis will not be the case for any long-term (contractual) SLS but it can occur for (short-term)micro-flows. This could for example be the case with transit IntServ flows. The DiffServ SLSis then invoked by RSVP signalling (for more details refer to the IntServ over DiffServsection). Its content is derived from the IntServ FlowSpec and Rspec objects. The DiffServSLS lives for the duration of the IntServ flow. Remark however that certainly not all micro-flows, like IntServ flows, are by definition invoked without previous subscription. On thecontrary the” usual” way is that there is a previous subscription phase, followed by(eventually ” partial” invocation – see next).



- SLS-invocation is (always) a MANDATORY process; i.e. no data-flow is possible without anSLS-invocation (and admission). However, the SLS-invocation process may beSUPERFLUOUS, in the sense that invocation is done automatically after SLS-subscription(and permission). For example, long term SLSs with peer ASs or customer VPN services maybe invoked immediately at the time of making the contract. Thus: Invoke once, run till nextnegotiation. Remark that a superfluous SLS-invocation process does not give anysupplementary information (to the network) than was already available after the SLS-subscription process, I.e. in the SLS-object resulting from subscription. This type ofinvocation could also be called static SLS-invocation.

• Partial SLS-invocation is possible in case of “real different” SLS-subscription and SLS-invocation processes. Take for example a business customer who has one contractual SLA (SLS)for Voice over IP (VoIP) traffic between two Business sites (a VLL). There is one customerservice (VLL) for the aggregate VoIP traffic while each individual VoIP call “invokes” 2 micro-flow SLSs (dedicated for this particular call).

In this example, the SLS subscription captures the (long-term) characteristics of the VLL, whilefor each (short-lived) VoIP call there is a dedicated SLS-invocation. This example is explainedinto more detail in section 4.4.7.

“Partial” invocation of the (already defined) SLS-subscription object means the following:

- “Part in scope”, meaning that the invoked SLS MUST NOT be out of the scope defined in theSLS-subscription object. For example, the SLS subscription may have as scope a hose (1|N),while the invoked SLS has as scope a Pipe SLS (1|1). The condition is then that the egresspoint of the (invoked) Pipe is one of the N egress points of the (subscribed) Hose.

- “Part in traffic”, meaning that the conformance parameters of the invoked (micro-flow) SLSobject must be “smaller” than the conformance parameters of the (aggregate) subscription SLSobject.

In the example of above, the VLL between the two access routers for VoIP traffic is quite static.The dynamic admission control for each individual VoIP flow can either be the responsibility ofthe customer or of the network operator. In any case, the network operator will certainly performpolicing on the aggregate traffic (at its ingress router) for protecting his network resources.

• Dynamic SLS invocation is by definition SLS-invocation that can NOT automatically be deducedfrom the SLS subscription process/object. One can consider three types of dynamic SLSinvocation (objects).

- Customer services/SLS without previous SLS subscription.

- Invocation of the (full) SLS object previously subscribed for a finite period of time. Forexample, watching a Video (on Demand) on Monday 3 July 2000 in the evening from 8 to 10p.m. This is invocation of a previously subscribed SLS which states that a video MAY bewatched etc… (see example 4.4.7.2 for more details).

- Partial invocation of the SLS subscription object previously subscribed. Remark that partialinvocation is by definition dynamic.

Normally dynamic invocation will result in an (invoked) SLS object that only exists for a finiteperiod (for the “micro-flow call duration”). More details are given in the sections below andexamples clarifying these concepts can be found in section 4.4.7.



4.4.5 SLS Subscription handlingCustomer service subscription is basically the process of customer registration & policy-basedadmission. Its basic functions are part of the Management Plane. The customer might either be a peerAutonomous System (AS) or a business or residential user. The subscription (or registration) concernsin the first place the Service Level Agreement, containing amongst others prices, terms & conditionsand the SLS (or set of SLSs making up the customer service). Only the latter (SLS) is in scope of theTEQUILA project.

• customer service subscription has two major objectives:

- It MUST provide the required Authentication information for Authentication, Authorisation& Accounting purposes when the SLS will be (partially) invoked.

- It MAY provide useful information for the Traffic Forecast Module based on trafficconformance parameters and guaranteed rates.

Customer service (SLS) subscription results in a Customer Service (SLS) object.

4.4.5.1 SLS subscription objectThe SLS subscription class is the same as the SLS invocation class (defined in the SLS specificationsection) plus one additional attribute Grade of Service (GoS). The SLS subscription template is thusthe following:

• Scope = (ingress, egress)• Flow Id = (source, destination, application protocol Id, DSCP value• Traffic conformance Testing: (b, r), p, m, M + algorithm• Traffic conditioning / prior to traffic conditioning: (marking/shaping)• excess traffic (drop/shape/remark)• Performance parameters: (throughput R, delay d, packet loss p, jitter)• Blocking Probability GoS

The following “rules” hold specifically for the SLS subscription object.

• Authentication information. It MUST be possible to derive the authentication information fromthe combination Scope/FlowSpec in the SLS subscription object. For example:- Source = (IP address, port, protocol ID)

- Source = Network prefix

- Source = peering interface: All traffic coming from a certain interface (AS egress orcustomer interface).

• Traffic Forecast information. In case the required guarantees are “better-than-best-effort”, thenthe token bucket parameters (b,r) MUST be specified in the SLS subscription object. The tokenrate r is (of course) the conformance parameter of the (aggregate) packet stream specified in theflowspec of the SLS subscription object. The token-rate r can be used for the Traffic Forecastmodule. Indeed, the long-term "average” rate or mean m is smaller than r (m�U�� ,I� QR� VLOHQWperiods are present in the traffic stream, i.e. traffic is continuously injected by the customer (thebucket is never empty), then m = r.

• The Grade of Service (GoS) attribute.- If GoS is NOT specified, then there will be no dynamical invocation of (micro) SLSs. SLS

invocation is static/superfluous. In this case the service guarantees, i.e. the performanceparameters of the SLS subscription are specified for the (aggregate) flow given by theFlowSpec in the SLS subscription object. The performance guarantees are of a “static”nature, they last until the next negotiation of the SLS subscription object.



- If GoS is specified, then there will be dynamic invocation of the SLS; this may eventuallybe a partial invocation. In this case the Service Schedule SLS attribute MUST be specifiedin the SLS object resulting from SLS subscription phase:

- Service Schedule describes WHEN the (micro-flow )SLSs may be invoked

- GoS is the Blocking probability of an (micro-flow) SLS-invocation DURING ServiceSchedule period.

Concerning the meaning of the performance parameters in the SLS subscription object, there arefollowing possibilities:

- The performance parameters MUST NOT be specified in the SLS subscription object, butin the SLS invocation object at moment of SLS invocation.

- The performance parameters MAY be specified, but they only have an indicative meaningfor the SLS that will be invoked in the future. The SLS invocation may copy or evenoverwrite these performance parameters of SLS subscription.

Thus, the “hard” guarantees are always given in the SLS invocation object!

4.4.5.2 Message Sequence ChartFigure 19 gives the Message Sequence chart of the SLS subscription process.

The figure describes actually three separate phases.

• “Downloading” the necessary information to the SLS-subscription block enabling the permissionor refusal of (new or change) SLS-subscription requests. Essential information comes from thePolicy component (added on the MSC!) and the Network Dimensioning component.

• The actual SLS-subscription handling process.

The actions triggered by the permission of a new (or changed) SLS subscription. Information is“downloaded” to admission control for handling SLS invocations. Information is also “uploaded” tothe traffic-forecast module.



Figure 19: MSC of the SLS subscription process

Also the following points should be emphasised:

• This is basically an administrative process registering long-term contracts (SLA/SLS) with thecustomers. It includes an SLS subscription repository, which stores all SLSs permitted and SLSsrefused.

• SLS/SLA-Permission or refusal is based on the following

• Policy-based (AAA rules & others e.g. US traffic is not transiting Iraq…)

These rules are provided by/download from the Policy database

• Traffic-based

- Availability of Customer service/SLS-TYPE.

- Availability of (long-term) Network resources (e.g. for VPNs or VLL of high capacity).

These rules are provided by/download from Network dimensioning.

Network configuration

Request new SLS or change existing SLS

Refer interdomain requestif peer AS terminates egress

TrafficConditioning

AdmissionControl

SLSSubscription

NetworkDimensioning

Inter-domainSLS requestor

User/Upstream AS(management)

DownstreamAS

Request

OK/NOKOK/NOK

Price, terms+conditions, etc. or NOK

Negotiation phase (repeat as needed)

Buy SLS

* This does not necessarily happen for every new SLS, it could take place when a certain threshold has been crossed or it could be “polled” fromTraffic Forecasts** when set of accepted or rejected SLSs is significantly different from current configuration - may be initiated by Traffic Forecasts when certainconditions have been fulfilled (policy?) or may be invoked periodically by Traffic Forecasts or Network dimensioning

Referral as before, if necessary

If interdomain SLS...

Store new SLSin repository

conditioningrules/policies

(in suspend mode)

“Trigger”**

Request new/modified interdomainSLS, if required. Request

OK/NOK

To/from dynamic management

SLS subscription

SLS selectionrules/policies

TrafficForecasts

Traffic matrix

SLSs passedto TrafficForecasts*

Acknowledgement

Network configuration

Available resources

the algorithm for mapping of network configuration to available resources (for new SLSs), i.e. “available resources = current network configuration - those resources allocated for existing SLSs”could be placed in SLS Subscription, as here, or it could be located in Network Dimensioning (for furtherstudy, also see note *** on next MSC)

Policy

Business policy rules



• Remark: The (long-term) SLS permission is by no way a per flow Admission Control (we use theterminology Permission to make the distinction). SLS subscription permission is not based on aninstantaneous snapshot of load/spare capacity, but a longer-term view provided by NetworkDimensioning functions.

• The Permission/rejection process is performed within the SLS-subscription functional block andNOT in the Admission Control/ SLS invocation functional block.

• SLS-subscription can be “on-line” (automated with e.g. Web-based tool) or off-line by e.g.manually registering at the ISP’s local office.

4.4.6 Admission Control - SLS Invocation handlingSLS invocation is basically the process of “establishing” the flow and it is mainly done in the Controlplane. The process is in all cases mandatory. The “nature” of the invocation process is determined bythe following characteristics:

• The invocation can either be static (superfluous) or dynamic.

• In case of dynamic invocation, the existing SLS subscription object can be “partially” or “ fully”invoked; or there might be no existing SLS subscription (invocation without subscription).

4.4.6.1 Static SLS invocation• Is automatically triggered after the SLS subscription process (in case of SLS-permission).

• No “admission control”.

• The SLS invoked object is (simply) a copy of the SLS subscription object (only “full” invocation)

• Delegates rules/policies concerning the SLS invocation object to the Traffic Conditioner.

4.4.6.2 Dynamic SLS invocation• SLS Request is triggered by a signalling protocol (e.g. RSVP or PPP).

• Performs admission control (in case of static SLS this is superfluous)

If a previous subscription exists, then admission control is based on

- Existing SLS subscription object

- Check of policy, e.g. authentication & authorisation

- Check of traffic contract in case of “partial” invocation: e.g. if the SLS subscription is for100 Mega bps, then the “sum” of already partially invoked flows must be less than 100Mega bps.

- Available network resources w.r.t. the demand of the invocation SLS object.

If no previous subscription exists, then admission control is based on

- general rules/policy for invocations without admission

- available network resources.

• In case of SLS admission (no blocking), then an SLS invocation object is created.

- based on the signalling information

- (eventually) partially based on the existing SLS-subscription.

• Delegates rules/policies concerning the SLS invocation object to the Traffic Conditioner.



4.4.6.3 Message Sequence Chart

Figure 20: Dynamic SLS Invocation MSC

Remarks

• Admission control is in fact performed for Customer services, which might be a set of SLSs. Incase of bi-directional customer services, e.g. VoIP, this requires a signalling protocol between thetwo edges (ingress/egress and vice-versa). At least, if the admission control of (micro) flows isdone locally ad the ingress edges. This is for further study (in specification of the protocols).

• As already noticed in the functional model, the need for signalling between ingress/egress couldalso be needed for Uni-directional flows, e.g. if there is a bandwidth bottleneck at egress (in caseof for example a “slow access link downstream”).

SLS subscription object

User/Upstream

AS(control)

User/Upstream

AS(data)

Admission ControlSLS Invocation

TrafficConditioning

Monitoring

SLS Node Network

Monitoring Request at network or node level ((re-)set thresholds) Monitoring Request

threshold crossingsMonitoring Report

(threshold crossings)

Admission rules/policies

Est

ablis

hmen

t of f

acto

rs

for

Adm

issi

on D

ecis

ions

Adm

issi

on R

eque

st

With

pre

viou

s su

bscr

iptio

n

Dynamic SLS request

Dat

a T

rans

mis

sion

Request load info (if certain rule applies)

OK/NOK

Activate conditioningrules if OK/deny if NOK

start

data

Policy

Dynamic SLS Invocation

May trigger Dynamic Control/Dimensioning/Traffic Forecasts

Report NOK

Signal egress AC or refer to network level AC**

OK/NOK

* may be directed to/be originated from either the node or network layer monitoring** the need for signalling the egress node(s) is for further study. If it is needed, the nature of the “signal” is also for further study - RSVP, RSVP-like,new protocol, implicit protocol, etc. The current view is that this signalling is certainly necessary for dynamic requests which have not previously beensubscribed, and it may be necessary for those which have already been subscribed.*** this could be Network Dimensioning (see note on previous MSC)

*

*

(if NOK further negotiations may take place)

May trigger Dynamic Control/Dimensioning/Traffic Forecasts

SLSSubscription***



• The above MSC describes the invocation of the SLS/Customer service. In case of dynamicinvocation, the SLS invoked object only lives for a finite period of time (“call duration”). Hence,there is the need of a “symmetric” “shut-down” process. This shut down may either be hard orsoft state based. In any case, the shut down must delete the SLS invoked object and trigger someactions (such as informing the Traffic Conditioning component, dynamic control component,…).

4.4.7 Examples

4.4.7.1 Virtual Leased Line for a Business CustomerTwo company sites of a Business customer are directly interfacing with the TEQUILA Autonomoussystem (i.e. a single AS example). The customer asks an E1 VLL (2 Mbps) between the two sites. TheVLL is meant for data-applications, thus there are no delay/jitter requirements.

• SLS subscription: the process is completely “of-line“ (e.g. by telephone & fax). The SLS objectresulting from the subscription process might look like this:

- Scope: pipe model- Flow Id: (source IP address, destination IP address, application info NOT specified)- Traffic Conformance Parameters: MUST be indicated : token rate = 2 Mbps- Excess treatment : dropping (only green packets inside the network)- Performance parameters: throughput guarantee R = r- Service Schedule = (tstart, infinity).

- GoS blocking probability: MUST NOT be specified

SLS permission is based on business policy rules (AAA procedures) and Resource availability,i.e. 2Mbps must be available between specified ingress/egress.

• SLS invocation: The service is automatically invoked at time t = tstart. No particular action such assignalling is required. The SLS invoked object is a copy of the SLS subscription object.

• Data transmission is allowed for t ��Wstart.

4.4.7.2 Residential Customer with an xDSL line for VoD servicesA residential user bought an ADSL modem and – after some physical installation & configurationissues – the user wants to have access to a Video on Demand (VoD) Service Provider (all across theInternet).

Thus, we don’t consider here the physical connectivity offered by the Internet Access Provider (IAP -the latter is peering with the TEQUILA network); we assume that this is already established. However,the IAP only provides L2 connectivity; the TEQUILA network offers the IP services (Point ofPresence PoP). For simplicity we also assume that the VoD service provider is directly attached withthe TEQUILA network.

• SLS subscription: Via a Web-based tool the user establishes a (long-term) contract with theTEQUILA network provider. Roughly speaking, the SLS states that the user MAY watcheveryday between 8 and 11 p.m. a Video (on Demand) which can be downloaded from a well-known service provider. The user expects a good quality real-time service. The SLS could looklike this.

- Scope: pipe model : (ingress: IP_itf of VoD server, egress = IP_itf of user)- Flow Id: (source IP address, destination IP address, application info ~> MPEG video)- Traffic Conformance Parameters: MUST be indicated : token rate r = determined by MPEG

application- Traffic Conditioning prior to conformance testing: e.g. shaping may be requested



- Excess treatment : shaping or dropping- Performance parameters: throughput guarantee R >= r, delay = 10 ms….- Service Schedule = every day from 8 to 11 p.m.

- Blocking Probability GoS : 10-3

The blocking probability gives the probability that the SLS-invocation (call attempt) of theuser (i.e. watching a video) is blocked during the Service Schedule period. The Performanceparameters give the QoS of the packet stream if the SLS-invocation has not been blocked.

SLS permission is based on business policy rules (AAA procedures) and Resource availability,i.e. 2Mbps must be available between specified ingress/egress.

• SLS invocation: Via the PPP-protocol the user dials-in at the PoP of the TEQUILA ISP. Based onthe SLS subscription contract, the user has (only) access to the VoD server. SLS admission (orblocking) is based on PPP-Authentication information (checked with the SLS subscriptioninformation) and available bandwidth resources (the user MAY be blocked with p=10-3).

An SLS invocation object is created. The performance parameters (e.g. R) MAY be overwrittenaccording to the negotiation between customer and network provider.

The SLS invocation object could look like this (* means copy from subscription object)

- Scope: pipe model : *- Flow Id: *- Traffic Conformance Parameters: *- Traffic Conditioning prior to conformance testing: *- Excess treatment : *

- Performance parameters: R, d MAY be specified at invocation time- Service Schedule : N/A (time of call/video duration is not know at invocation time)- Blocking Probability GoS : N/A

This invocation is considered as a “full” (i.e. not partial) invocation of the subscription SLS

• Data transmission: downstream transmission from VoD server to user.

4.4.7.3 Business Customer injecting aggregate VoIP trafficA business customer wants to establish a contract saying: I want to inject x=10 Mega bps of real timeIntServ or VoIP flows (100 Mbps is the maximum allowed rate of the aggregate traffic stream). Flowscan be recognised by network prefix address (e.g. a C network). However, the destination of the(individual) VoIP flows is not determined in advance and is different for the flows. The flowsthemselves are short-lived but the contract of the customer is long-lived because he wants the 10 Mbpsguarantee for aggregate VoIP flows. The customer does not want to negotiate SLA/SLS for eachindividual micro VoIP flow. The customer wants "good quality" in "most of the call attempts".

One could consider two approaches for dealing with the aggregate VoIP traffic, depending on thedemand of the customer.

In the first approach, micro-flow SLSs will be created/invoked for each individual VoIP flow. Thisshould guarantee:

• If the VoIP call is admitted, then the quality must be (almost) perfect

• However the VoIP call may be blocked.

This is the “classical” telephony approach.



In the second approach, there will be no SLS invocation for each micro-flow. Instead, the customerasks for an (aggregate) Olympic gold/green. There are no guarantees for individual VoIP flows.However, in most of the cases, the quality should be “acceptable”. Major advantage of this secondapproach is that there is no need for a dedicated IP-signalling protocol (such as RSVP) establishing theindividual VoIP flows.

This could maybe be seen as an introductory scenario for VoIP over the Internet.

Approach 1: Micro-VoIP flow SLS invocation

• SLS subscription- Scope = Hose (1 | all)- Flow Id = (source = unique network prefix, destination = all, protocol ID specified -> VoIP)- Traffic Conformance: token rate = 100 Mbps…- Traffic conditioning : not specified – indicator that it will be micro-flow based- Performance parameters = not specified – indicator that it will be micro-flow based- Service Availability = (tstart, infinity) (the user is always allowed to inject traffic of 100 Mbps

maximum.- Blocking Probability GoS: MUST be indicated; indicates the blocking probability of

individual micro-flows

• SLS invocation: The invoked SLS of the micro-flow is completely different than the "long-term"SLS of the subscription. The micro-flow SLS could look like this.

- Scope = pipe (1 | 1)- Flow Id = (source = IP address, port nr, destination=IP address, port nr; protocol ID specified)

Remarks:* Requirement: Source IP address MUST match with network prefix of long-term SLSsubscription object. Authentication & authorisation is based on this match.* The parameters (and these below) MUST e.g. be determined from signalling protocol forsetting up individual micro-flows (like RSVP)

- Traffic Conformance: peak = token rate = 64 Kbps- Traffic conditioning based on (micro) token bucket. Excess traffic is dropped (green packets).- Performance parameters = guaranteed throughput = 64 Kbps (= token rate); delay = x milli sec- Service Availability = N/A- Blocking GoS : N/A.

This micro-flow SLS exists for the duration of the call (which is not known in advance). After theauthorisation check (matching IP address of call with network prefix of SLS subscription), theadmission of blocking of the SLS is a traffic issue and based on:- overall aggregate traffic from the customer must be less than 10 Mbps- there must be enough resources for the individual (real time) micro-flow (“usual” admission

control algorithm).

Approach 2: Aggregate Olympic real-time traffic

In this case, there is no "real" SLS invocation process. The "aggregate" SLS is invoked at the momentof subscription (similar to the VLL example above). The network can not give any hard, quantifiedguarantees concerning individual VoIP flows; the network can not make distinction on in-profile/excess traffic for individual flows, there is no admission control possible on individual flows.

However, the network can do something by giving this traffic priority w.r.t. best-effort traffic (andother data-traffic). In this approach, the SLS instantiation at the moment of subscription could looklike this:



• SLS subscription object- Scope = Hose (1 | all)- Flow Id = Gold/Green (Olympic service) Authentication is based on the ingress interface

(customer has well known ingress Itf).- Traffic Conformance: peak = line rate; token rate = 10 Mbps…- Traffic conditioning based on (aggregate) token bucket (b=... r = 10 Mbps). Excess traffic

is coloured yellow- Performance parameters = (delay/loss) = (gold/green)- Service Availability = (tstart, infinity) (the user is always allowed to inject gold/green traffic of

10 Mbps maximum.- GoS: MUST NOT be specified

In general, TEQUILA could reserve the (gold/green) class for this type of traffic: "real time servicewithout hard quantitative guarantees”

• SLS invocation: Invocation of the SLS is automatically at time t= tstart. There is no separateinvocation per micro-flow! Thus, there is no “admission control” per micro-flow, nor blockingprobability.

The basic assumption for this approach is that the vast majority of traffic will anyhow be best-effortdata-traffic. Therefore, by giving priority to real-time Olympic gold packets, the service quality ofindividual flows will be good in most of the cases (even without any hard per-micro-flow guarantees).This could maybe be seen as an introductory scenario for VoIP and other real-time services over theInternet.



4.5 Integrated Services Support

4.5.1 IntServ over DiffServ : General architecture

4.5.1.1 The ISSLL model of the IETFThis section discusses the support of Integrated Services (IntServ) over the TEQUILA DifferentiatedServices (DiffServ) network. A starting point is a model as it is proposed today by the ISSLL WorkGroup of the IETF (IntServ over Specific Link Layers working group). The model is given in the IETFdraft [IS-DS-1] A framework for IntServ operation over DiffServ networks, version 05. Main issue inthis IETF draft is the general architecture and the resource reservation issues.

4.5.1.1.1 IP IntServ Essentials

IP IntServ supports three service classes: Guaranteed Service (GS), Control Load (CL) and Best Effort(BE). The architecture is based on the RSVP protocol for Resource Reservation and signalling of thetraffic characteristics of an IP (RSVP) flow. Signalling is done by a number of RSVP-messages, suchas PATH and RESERVATION, which contain RSVP-objects, such as Tspec with the token-bucketparameters of an IP flow (Figure 21: IntServ support over a DiffServ network).

�7VSHF��U�E�S�P�0�

�5VSHF��5��VHUYLFH�UDWH

�$GVSHF��&,��',�7[ 5[

,QW6HUY�'LII6HUY�(GJH�GHYLFHV

3$7+�0(6�

5(6��0(6�

�&'6��'

'6�

4(�(¡0�5��E�0��5�[��S�5��S�U��&(�(�5��'(�(

Figure 21: IntServ support over a DiffServ network

• GS is meant for real-time multimedia applications. It guarantees loss-less transmission for in-profile traffic together with a deterministic upper bound for the E2E queuing delay (QE2E). Thisbound depends on the traffic characteristics of the sending source (described by the token-bucketparameters, given in Tspec) and on the (reserved) service rate R (given in Rspec). Moreover eachrouter adds a particular contribution to QE2E because its implementation deviates naturally from theGPRS fluid-flow model. This is expressed by the so-called C/D error terms.

• The CL class has less stringent requirements and supports amongst others adaptive Multi-mediaapplications and VPNs without the deterministic delay-bound requirement. It guarantees a servicerate R over an “appropriate” time scale. CL traffic could e.g. be implemented in an isolated FIFOqueue with Head of Line (HOL) priority over best effort.

The token-bucket parameters TSpec are signalled from transmitter (Tx) to receiver (Rx), while thereceiver determines the quality of the connection by asking a certain service rate guarantee R,signalled by the RES. Message in RSpec. The reservation is soft-state based, meaning that theReservation Message must be repeated e.g. every 4 seconds for keeping up the connection. Thereceiver may change the QoS “on the fly” by this soft state mechanism by e.g. increasing the servicerate R or he may even change the QoS class of the connection.

About the delay error terms in the IntServ architecture – Guaranteed Service

Given a GS service with parameters (b, r), p, m, M and (requested) guaranteed rate R. R is typicallybetween r (“i.e. the “sustainable rate”) and p (peak rate).



The rate R is asked by the receiver in order to get its desired E2E delay bound QE2E. The formula isgiven in Figure 21. The (C, D) error terms measure the deviation from the fluid-flow model. EachIntServ hop MUST add its (Ci,Di) delay contribution. CE2E and DE2E are the sum of Ci and Direspectively. This means that the delay error terms are additive; in other words: The E2E delay is aworst case delay and is deterministic (not probabilistic e.g. estimated by quantiles).

The sequence of events goes as follows:

• The transmitter sends the RSVP PATH message with the flowspec TSpec and AdSpec forcapturing the error terms (C, D).

• Each IntServ hop adds his delay contribution (Ci, Di) into the AdSpec.

• The receiver will finally have the error terms (C, D) as the sum of all (Ci, Di).

• The receiver determines its maximum E2E delay he is willing to accept (application & qualitybased).

• based on the formula for QE2E and the error terms (CE2E, DE2E ), the receiver calculates therate R he is willing to have

• The requested rate R is sent backward with an RSVP RESERVE message and each hopreserves the appropriate resources (or rejects).

In a sub-network which is not IntServ capable, like the DiffServ Tequila cloud, the ingress routerMUST indicate the (CDS, DDS) error terms taking into account the entire path of the IntServ flow in thesub-network. These error terms (CDS, DDS) should also indicate the worst case delay (deterministicdelay bound) an IntServ IP packet can encounter inside the DS network, i.e. from ingress to egress.

4.5.1.1.2 The basic IS-DS architecture

The following summarises the basics of the ISSLL model [IS-DS-1]

• Integrated Services is the E2E architecture, i.e. the QoS classes from transmitter to receiver areeither IntServ Guaranteed Service or Controlled load.

• The DiffServ network, e.g. the Tequila network, is a “finite” cloud (island) in a “broader” IntServenvironment.

• From an IntServ perspective, the DiffServ network is seen as a single IntServ (RSVP) hop.

• The downstream IntServ/DiffServ edge device (or InterWorking Function – IWF) is responsiblefor

- Doing the appropriate (IntServ-RSVP) admission control,

- Performing the required (DiffServ) traffic conditioning,

- Mapping IntServ classes on DiffServ PHBs, or more exactly, marking incoming IntServpackets with the appropriate DiffServ Code Point (DSCP).

• In case of an IntServ Guaranteed Service IP flow, the downstream IWF is responsible for settingthe delay parameters (CDS, DDS) for the entire downstream path in the DiffServ network. (See lateron in this document).

• The RSVP signalling messages MUST pass transparently through the DiffServ network routers.Dedicated signalling paths must be available between each pair of edge devices.

• The IntServ break bit SHOULD NOT be set because of the (eventual) presence of non-IntServcapable routers in the DiffServ domain.

• There are basically two conceptual issues in the IntServ over DiffServ architecture:

- Capturing the RSVP signalling dynamics and appropriate resource reservation in theDiffServ network (control plane).



- The QoS class mapping itself, i.e. mapping the IntServ classes Guaranteed Service andControlled load on DiffServ PHBs (data plane). This is subject of the very recent draft [IS-DS-2]: Integrated Services Mappings for DiffServ networks, version 01.

It must be clearly said that in these drafts – and especially [IS-DS-2] – numerous questions remain.How the QoS requirements of IntServ applications can be met in a DiffServ network is still veryunclear and an unsolved problem!

4.5.1.1.3 The IntServ – DiffServ Edge Device

The place of the IntServ/DiffServ edge devices (IWFs) and the functions of these IWFs are largelydetermining the overall architecture and QoS functionality of the network. The following gives apossible functional decomposition of such a device. The figure is only informational, otherimplementations are of course possible.

The basic IS-DS inter-working functions are:

• processing of the RSVP signalling messages

• Admission Control agent for the DiffServ cloud (flow-based)

• QoS mapping : IntServ Flow -> DSCP “Service class”

• appropriate policing of IntServ Flows

• selecting the appropriate DSCP (QoS-aware mapping)

• aggregation of IntServ Flows (GS/CL) on DiffServ DSCP

• “exporting” IntServ parameters from the DiffServ cloud, e.g. calculation of the error terms(CDS,DDS)

=> Control plane dominated by RSVP

=> Data plane dominated by DiffServ PHBs

Figure 22: IS-DS functional block diagram

E -B G P

R SV P - C on trol

O SPF

M arker

SL S agent

Shaper

M F -C lassifier Policer Shaper

FIB

M F-C lassifierPo licer

PE P/ A C

C O PS



4.5.1.2 Two Business ModelsThere are two possible business cases for a DiffServ network operator (“the Tequila ISP”) forinteracting with its IntServ capable neighbours (either access networks or peer ISP). Both models arementioned in the IETF draft [IS-DS-1].

4.5.1.2.1 The RSVP gateway model

First the Tequila ISP can position itself as a pure DiffServ operator, in which case he offers DiffServSLA contracts with its peers. The IntServ neighbours are themselves responsible for doing themapping. The IntServ/DiffServ Inter-Working Device is situated outside the DiffServ (Tequila)network. This scenario is called the (exterior) RSVP gateway model: the DiffServ edge routerinterfaces with a “RSVP gateway” router which acts as the IntServ/DiffServ inter-working device.

Figure 23: two business scenarios

In this model the DiffServ network is completely IntServ transparent. Therefore the model has noparticular consequences for the TEQUILA functional model, the system design or the DiffServ SLSdefinition.

4.5.1.2.2 Native IntServ support

In the second case the Tequila ISP sells native IntServ SLA contracts to its customers, i.e. the Tequilaedge routers are IntServ capable. The IS-DS IWF device is situated inside (at the edges) of the Tequilanetwork.

Figure 24: Native IntServ support

4.5.2 IntServ & the Tequila Functional ModelHigh level Requirements

The TEQUILA requirement section specifies the following:

The TEQUILA system supports both the integrated services and differentiated services end-to-endmodels. The TEQUILA system assumes only the RSVP resource reservations protocol in the contextof the IntServ model…

IER EERIAR EAR

IntServ/DiffServ Access router

DiffServ edge router

RSVP RSVP

DiffServ AS core router

IER EERIAR EAR

IntServ/DiffServ edge router

IntServ Access Router

RSVPRSVP

DiffServ AS core router



The TEQUILA system must provide for Best Effort, Controlled Load and Guaranteed Service end-to-end networking in the IntServ model… The TEQUILA project (however) assumes the DiffServ modelin the core of the autonomous systems… Given the assumption of core DiffServ network operation,the TEQUILA system should manage:

• the IntServ to DiffServ and DiffServ to IntServ Interworking at the edge of the network(Requirement 1)

• the resource management in the DiffServ core network to match the IntServ requirements(Requirement 2)

• the DiffServ to DiffServ Interworking at the border between autonomous systems and between ASand Customers (Requirement 3)

Capturing the requirements by the Functional Model

We start from what we have, that is: the Functional Model and the SLS template definition. Both thefunctional model and the SLS Object definitions MUST be capable to capture the IntServ requirementsas stated above. This means two things

- The service requirements imposed by the IntServ model MUST be mapped on TEQUILA SLSobjects. That is: the IntServ Guaranteed Service (GS) and Controlled Load (CL) MUST bemapped on a SLS object. Thus, the TEQUILA SLS class definition is more generic than theIntServ traffic objects (TSpec, RSpec, AdSpec). This mapping is done at the edges of theDiffServ network, the core MUST be IntServ transparent. More details and the relations withSLS subscription & invocation are given below.

- Once the mapping of IntServ services on Tequila SLS objects has been executed, theTEQUILA functional model treats these (IntServ) SLSs “as usual”. For example a VoIP callcan be mapped by the application on the IntServ GS class or the application may directlynegotiate a TEQUILA SLS with the TEQUILA network. In both cases, once the SLS object isdefined and instantiated, the TEQUILA functional components (and network elements doingthe work) do not see any difference between the two approaches.

• Regarding the Tequila functional model, it is concluded that only the SLS managementcomponent MUST be “IntServ” aware. This component performs the mapping of IntServ flowsonto TEQUILA DiffServ SLSs. Eventually also the policy management component MAY beIntServ aware in defining certain “IntServ business policies”.

• Regarding the Tequila Top Level Design, it is concluded that only the edge routers MUST beIntServ (RSVP) aware. However the mapping of IntServ flows on DiffServ SLSs MAY be done inthe edge routers themselves OR dedicated network servers MAY do the mapping more centrally.This depends on the more general Top Level Design of the overall Tequila system.

What this section (contribution) should solve:

• The mapping of IntServ flows, i.e. their traffic characteristics and QoS requirements, on TequilaDiffServ SLSs as defined in the SLS template specification.

• The capturing of the IntServ RSVP signalling by the functional model, i.e. the Message SequenceChart.

This should capture the first requirement formulated above. However, the second requirement (intra-domain resource management) and third requirement (DiffServ-DiffServ Inter-domain-working) is notspecifically treated here. As stated above, once the mapping on SLSs is done, the other functionalcomponents should treat these SLSs as any other.

For example, the basic question how the IntServ QoS requirements can be met by the Tequila networkis similar to the more general problem of supporting real-time flows, such as Voice or Multi-media,over a DiffServ network. Only for informational purposes we give some ideas (such as mapping onPHBs) at the end of this section.



4.5.3 The Exterior RSVP Gateway Model

Figure 25 : The RSVP gateway business scenario

In this business scenario, the RSVP gateway node, outside the Tequila network, does all the work. Thebasic IS/DS functions are configured as follows:

• Static DiffServ SLS contracts with the Customers (Tequila Network sells DiffServ services)

• DiffServ network is statically provisioned

• P2P pipes between edges (N2), pipes per supported QoS (DSCP)

• IS/DS mapping functions at the RSVP gateway

• Admission Control (of IntServ flows)

• outside the DiffServ cloud, at ingress access router

• based on DiffServ SLS contract (& QoS mapping of course)

• triggered upon reception of the RSVP RESERVATION Message

• Mapping of IntServ classes on DiffServ code points (see section 4)

• Basically the RSVP gateway multiplexes IntServ QoS flows into (static) DiffServ pipes.

Note 1: in this context, “static” means that the bandwidth of the DiffServ SLS contract with thecustomer does NOT dynamically change with each (new arriving or expiring) IntServ flow. Also thepipes inside the DiffServ cloud are statically in this sense (which does not exclude appropriate TrafficEngineering of the pipes on a “longer” time-scale, e.g. every hour or every day recalculation of thepipes).

Note 2: The IETF draft [IS-DS-2] only mentions static DiffServ SLAs (as explained in note1). Adiscussion point is whether more dynamic SLSs are possible. Could e.g. the available bandwidth for acertain DSCP mentioned in the SLS, be modified on arrival of a new IntServ Flow? This wouldrequire dynamic DiffServ SLS negotiation between the exterior RSVP gateway and the (interior)Bandwidth Broker of the Tequila network. Personally I think that in case of an exterior RSVPgateway, one should only work with Static SLSs, otherwise it will be too complicated.

Conclusion

• The support of the Exterior RSVP Gateway model has no particular implications for the TequilaFunctional Model neither for the SLS template definition. The Tequila network provider has a(DiffServ) SLS contract with its customers and it is entirely the responsibility of the customer tomultiplex the IntServ flows into the DiffServ pipes.

7[ 5[

3$7+�0(6�

6/6�FRQWUDFW6WDWLF�'LII6HUY

3LSHV$GPLVVLRQ

&RQWURO�$JHQW

'6�,6,6�'6

5(6��0(6�



4.5.4 Native IntServ support

4.5.4.1 OverviewThe Tequila operator positions itself as a supplier of native Integrated Services, i.e. support of nativeGuaranteed Service and Controlled load IP IntServ flows.

Figure 26: Native IntServ flow support

• There is no DiffServ SLS contract with the peers (at least not for the support of IntServ flows).

• The IntServ flows must be treated “at arrival” by the IS/DS edge device inside (at the border of)the Tequila network.

• Each new arriving IntServ flow is mapped on a (dynamic) DiffServ SLS: this is the process of SLSinvocation. If a new IntServ flow is established, the IntServ QoS characteristics must be mappedonto a (newly created) DiffServ SLS contract.

• In fact the creation of the DiffServ SLS contract is triggered by the arrival of the (backward)RSVP Reserve message at the ingress hop. The processes are as explained in the SLS-invocation MSC. The trigger for the invocation is the arrival of the RSVP message.

• This SLS exists for the duration of the IntServ flow.

• In case the characteristics of the IntServ flow are changed (this is possible by the soft-staterefresh mechanism of RSVP), then also the DiffServ SLS should be changed.

• Once the DiffServ SLS is created, it is treated like all other SLSs. That is: the “normal”procedures concerning admission control, dynamic resource management, scheduling… areapplied in order to serve this (“IntServ”) SLS. This is explained in the sections describingthese functional blocks.

• NOTE: The SLS invocation/creation happens at the time of the arrival of the RSVP RESVmessage, and only exists for duration of the IntServ flow. However possibly the customer hasalso a long-term SLS subscription (object) with the Tequila Network provider which e.g. givesnecessary information about authentication & billing. See the SLS-handling section for moredetails.

4.5.4.2 Mapping IntServ flows on DiffServ SLSsThe mapping is done at Ingress Edge.

As stated above, the mapping takes place at arrival (at the ingress node) of the RSVP RESV message.Note that at this moment the Ingress Edge has already the state information that was contained in theRSVP PATH message.

The necessary information, i.e. scope, Flow Id, performance parameters, etc is obtained from severalIntServ objects in the PATH and RESV messages. Description of these objects can be found in[RSVP-1], chapter 5.

7[ 5[

3$7+�0(6�

�/RFDO��$GPLVVLRQ&RQWURO�$JHQW

'6�,6,6�'6

5(6��0(6�

5693



Controlled load IntServ flows

• Scope: Pipe model: (Ingress, Egress);

- Ingress IP address = interface over which the RSVP path message arrived at the Ingress router

- Egress IP address = determined by the routing policy/paths inside the TEQUILA network.This egress router is considered to be the RSVP Next Hop of the Ingress router. Therefore theaddress must correspond with address in the Hop Class object in the RESV message (Hop classidentifies neighbouring RSVP aware routers). Note that we supposed here that the core(interior) IP routers ARE NOT RSVP-aware, i.e. they don’t read/write RSVP objects.

• Flow Id: (source information, destination information, and application information). Thisinformation Is obtained from several IntServ objects: Sender Template object and Session Objectin the PATH message.

- source IP address = <Ipv4 address> in the Sender Template object inside PATH message

- source port number = <Source Port> in the Sender Template object inside PATH message

- destination IP address = <Ipv4 address> in the Session Class object inside PATH message

- destination port number = <Dest. Port> in the Session Class object inside PATH message

- protocol Id = <Protocol Id> in the Session Class object inside PATH message

• Traffic Conformance Testing: (b, r), p, m, M all are provided by the IntServ Sender Tspec objectin the PATH message. The Conformance algorithm is the combined token & leaky bucketalgorithm: i.e. token bucket algorithm + a check on the peak rate (two combined buckets in fact).This algorithm is described in [RSVP-1], page 200.

- b = <Token Bucket Size> in the Sender TSpec object inside PATH message

- r = <Token Rate> in the Sender TSpec object inside PATH message

- p = <Peak Data Rate> in the Sender TSpec object inside PATH message

- m = <Minimum Policed Unit> in the Sender TSpec object inside PATH message

- M = <Maximum Packet Size> in the Sender TSpec object inside PATH message

• Treatment of excess traffic:

- Excess Treatment = Marking

The IntServ RFCs explicitly mention that excess traffic of the CL IntServ service MUST bemarked or tagged – if the network has this capability (which is the case with the DSCP byte).

• Performance Parameters:

- Guaranteed throughput R = r

- Delay & jitter are not indicated.

- Packet loss is not indicated. IntServ requires “low loss” for in-profile packets, but this in factshould be automatically provided if the guaranteed rate is put to the token rate

Guaranteed service IntServ flows

• Scope: same as above

• Flow Id: same as above

• Traffic Conformance Testing: same as above

• Treatment of excess traffic: Excess traffic is dropped.

• Performance Parameters:



- Guaranteed throughput R = the Requested guaranteed rate by the receiver.

R = <Rate> in the GS Flow Spec object inside RESV message

- Delay bound = DDS Delay Error Term, which is also “exported” into the AdSpec Object (in theRESV message). The Tequila network provider itself determines this delay bound: see belowon “exporting the delay error terms”.

- Quantile for the delay bound: the delay bound is a probabilistic bound, allowing that somepackets exceed the bound (probability = 1-quantile)

- Packet loss: according to IntServ requirements, the packet loss of in-profile traffic must be 0.PROPOSAL is to put packet loss = e.g. 10E-9.

4.5.4.3 Exporting the delay error terms - a “pragmatic” proposal• The Tequila cloud is seen as a “pure” delay element in the IntServ architecture.

Therefore CDS = 0. C in fact indicates rate R dependent delays. Here we follow the same approachas in the IntServ on ATM mapping.

• The delay error term DDS

- Is part of the SLS object, instantiated by the ingress edge device at time of RSVP RESVmessage arrival (see above).

- Is given per ingress/egress pair

- Is based on measurements !

- Is stored in e.g. MIB database

- Is updated on regular time-intervals

- DDS MUST be written by the Edge device into the ADSPEC object of the RSVP RESVmessage

- It indicates a probabilistic bound. The quantile p is part of the SLS object (quantile p).

A GS IP packet traverse the DS cloud in a time less then DDS with a probability of 1-p

This probabilistic approach enables statistical multiplexing gain along the path and therefore amuch higher utilisation of network resources (in fact we follow here the same approach as inATM delay calculations for CBR and rt-VBR).

Bandwidth reservation & Admission Control - Two-level dynamics

This must be solved by general TEQUILA system architecture. Here are some ideas.

• Pipe model & local admission control at Ingress

• requires stable routing of IntServ flows inside the tequila cloud from ingress to egress

• Reconfiguring of pipes (and/or re-routing) by Bandwidth Broker

• at longer time-scales, a Traffic Engineering approach (the indication “longer” is to beinvestigated by the Tequila project and this time-scale should be a parameters of our Tequilasystem)

• on aggregate flows avoiding scaling issues!

• only triggered “when needed” by a congestion indication mechanism



4.5.5 QoS Mapping On DiffServ PHBsThis section is purely informational.

It handles the support of (micro) IntServ flows by (aggregated) DiffServ PHBs. In fact this should besolved by the several functional components as Dynamic Resource reservation, scheduling, etc.

Some of the information can be found in the second draft mentioned in the introduction [IS-DS-2].

4.5.5.1 Controlled Load (IETF draft recommendation)Definition: intrinsic burstiness

Given a controlled load flow with parameters (b,r), p, m, M. The intrinsic burstiness of the flow is (bydefinition) b/r. It corresponds with an delay encountered by the flow in a fluid-flow model (no extraqueuing delay nor delay due to packetisation). The Controlled load class requires that the per-hopdelay encountered by the flow is no more than b/r (for almost all in-profile packets, i.e. no quantifiedguarantee).

Mapping: Assured Forwarding (AF) is the recommended PHB-group

• A different delay AF-class according to the burstiness parameter b/r

• Thus: discretise! => average (b/r)avg

per available AF-class

• thus : IntServ flows with more or less the same b/r are aggregated around a burstiness

“average” (b/r)avg

, which is a parameter of the AF-class!

• per AF class => an aggregate Tspec : (bag

, rag

) = (�Ei, �U

i)

• Thus: remark that according to the IETF draft, the aggregation is done in the IntServ domain.Of course something similar if a 1to1 mapping of IntServ flows on DiffServ SLS and thenaggregating the DiffServ SLSs.

• The more AF-classes supported the finer the granularity of the mapping.

• If only one AF-class is supported, then all CL flows are mapped into the same class. In this

case, the only parameter is the AF output rate = �Ui

• traffic conditioning (marking drop precedence) against aggregate Tspec

• Traffic conditioning of each individual IntServ CL flow at ingress, based on token bucketparameters

• in-profile traffic is marked: green

• out-of-profile traffic is allowed and marked as “not-green”

• both in- and out of profile are put into the same AF class

CL node configuration issues

• Per AF class:

• limit the queue size (in practice max_threshold for Green) to limit the queuing delay target

• isolation of high and low priority traffic (n-RED)

• service rate s.t. loss & delay requirements are met

• Relationship between AF classes

• relative delay requirements according to (b/r)avg



• bandwidth must be available for time-scales shorter than delay bound

• E.g. WFQ scheduler with weights appropriately set

Personal Remarks

- The exact calculation of the corresponding parameters (e.g. AF output rate,…) is forfurther study (the RFC draft does not specify anything).

- This architecture requires a dedicated DSCP for each AF-class intended for supportingIntServ traffic. It means that “other” AF-traffic SHOULD NOT by mixed with IntServ CLflows inside the Tequila cloud.

• My personal advice is: ALL Controlled Load flows are aggregated and mapping into ONESINGLE AF class. Thus: no distinction should be made according to burstiness. About the codepoint : one could eventually take a dedicated code DSCP which is not necessarily the standardisedcode points of the AF PHB group)

4.5.5.2 Guaranteed Service (IETF draft recommendation)

GS mapping: Expedited Forwarding (EF) is the recommended PHB

If all of the above is OK, then the IS on DS mapping goes as follows:

• Between each pair of Ingress/egress edge devices, configure a DiffServ EF bandwidth pipe withgiven rate REF

and error terms (CDS = 0, DDS).

• The EF rate is calculated based on the requested rates Ri of all individual IntServ GS flows in thepipe : REF = ��5L; Ri is captured at the ingress IS/DS router in the RSVP Res. messages (of theindividual flows)

• Traffic conditioning of each individual IntServ flow at the Ingress router. The requirement is thatthe aggregated EF-input traffic MUST be smaller than the guaranteed EF-output rate REF.Therefore:

• shape each flow to a CBR-alike profile with rate ri (extra delay!)

• OR: drop all excess traffic based on (bi, ri) (looks better for me!) recommendation of author!

• Requirement: There must be a dedicated DSCP for the EF PHB carrying IntServ GS flows (likewith the CS/AF mapping).



4.6 SLS Management – Functional Block DecompositionThis functional component is responsible for all the SLS-related activities. Due to its complexity it isfurther decomposed as shown in the figure bellow. Note that both SLS subscription and SLSinvocation (Admission Control) have a view on the repository (which itself is not a FB).

Figure 27: SLS Management - Functional Block Decomposition

The semantics of the SLS objects, stored into the SLS repository, has been defined in chapter 4,section 4.2 “SLS semantics”. The repository could be further decomposed into an SLS subscriptionrepository, which contains all long-term SLS subscription objects, and an SLS invocation repository.The latter only contains “dynamic”, short-term SLSs (see section 6 on SLS-handling). Concerning thedata-model of the Repository, the following should be remarked:

• As discussed in section 4.4.5, SLS subscription objects may contain an extra attribute (w.r.t. SLSinvocation objects), i.e. the Blocking probability or Grade of Service (GoS). This attribute shouldallow for over-subscription of services and – therefore – optimal resource utilisation. We comeback to this in the sequel.

• The SLS repository is in fact a Customer Service Repository, as discussed in section 4.4. It meansthat it should be possible to “group” (uni-directional) SLSs into bi-directional services.

The repository has all usual Database functionality such as store, retrieve update, delete, search, SQLview, etc. We don’t go into further details on this.

4.6.1 Description of FunctionsThis section describes the main functions of SLS Management.

SLS SUBSCRIPTION FB

The following two processes are involved in SLS Subscription.

• Process SLS Subscription Requests

This function receives all requests and notifications to the SLS subscription FB about new/modifiedSLS subscription objects. It is the “External Interface – API” of the FB.

Input:

- New or modified SLS subscription object. The request for a new SLS subscription may come froma customer or a peering AS.

Action:

SLS repository

SLSsubscription

A.C./SLSInvocation

Inter-DomainSLS Requester

SLS Management



- Trigger the (internal) function SLS Subscription Permission Control

Output: depending on the output of the SLS Subscription Permission Control

- Notification to the user & eventually proposal of a modified SLS object (see below)

- Storage of accepted/rejected SLS subscription object into the SLS Repository.

- Triggering of SLS Invocation FB (in order to effectively “activate” the SLS – see below)

- Trigger the SLS Inter-domain requester if required, e.g. for transit traffic.

• SLS subscription Permission Control

This function accepts/rejects long-term SLS subscriptions. The function is triggered by “Process SLSSubscription Request”

Input:

- new or modified SLS subscription object

- Network Configuration

- Traffic Matrix

- SLS & Over-subscription Policy rules

Output: Depending on the available long-term spare resources and SLS (administrative) policies:

- Permission = YES :

- Notification of acceptation to the user or the SLS Inter-Domain requester.

- New/Modified SLS object stored in the SLS repository

- Permission = NO

- Notification of rejection to the user or the SLS Inter-Domain requester.

- Storage of refused SLS in R-SLS repository + reason why it was refused (e.g. lack of spareresources). This Refusal-SLS repository can then be used as input for the traffic matrix and/orNetwork Dimensioning

- Permission = RE-NEGOTIATE / “hints”

- Proposal of modified SLS object to the user/SLS inter-domain requester. This is only atemporary state: the negotiation between user/peering AS and our AS is still ongoing.

- Temporary storage of proposed SLS object

SLS INVOCATION / Admission Control FB

The Invocation (or “activation” if you want…) depends on the nature of the SLS. Invocation

• Process SLS Invocation Requests

This function receives all requests and notifications to the SLS Invocation FB about new/modifiedSLS invocation objects. The SLS processing depends on the nature of the SLS.

- If invocation is superfluous, e.g. a long-term VLL, then the SLS is invoked automatically aftersubscription. This means:

- The SLS subscription object = SLS invocation object and the SLS is stored in the SLSInvocation Repository (just a mark that the SLS is activated)



- Delegation of rules/policies to the Traffic Conditioner. These rules should ensure that thepackets are marked with the correct DSCP, that the traffic excess treatment is accordingly tothe SLS contract

- If the invocation is not superfluous, i.e. for (dynamic) micro-flows, then the process is as follows:

Input:

- New or modified SLS (micro-flow) Invocation objects.

Action:

- Trigger the (internal) function SLS Invocation Admission Control

Output: depending on the output of the SLS Invocation Admission Control

- Notification to the user

- Storage of accepted SLS Invocation objects into the SLS Invocation Repository.

- (Eventually) notification to Monitoring in case of threshold crossing (?)

- Delegation of rules/policies to the Traffic Conditioner.

- Trigger the SLS Inter-domain requester if required, e.g. for transit traffic.

- Trigger the SLS monitoring in both cases of automatic invocation and invocation aftersubscription.

• SLS Invocation Admission Control

This function accepts/rejects short-term SLS invocations (dynamic admission control). This function isexecuted at the edge routers of the network. The Admission Control algorithm will be measurement-based.

Still under discussion is however whether or not there is the need for signalling betweeningress/egress: must the egress node be involved in this process or not?

Input:

- new or modified SLS invocation object

- (subset of) Network Configuration (e.g. capacity of bandwidth pipe for certain CoS betweenIngress/Egress)

- Current Ingress/Egress Node load

- SLS Subscription Repository

- SLS Policy rules (e.g. rules for Micro-flows without reference to a long-term SLS subscription).

Output: Depending on the available short-term spare resources and SLS (administrative) policies:

- GREENE ZONE: Acceptation = YES and NO alarm-triggering/threshold crossing:

The current load is reasonably low and the SLS can be accepted


- New/Modified SLS object stored in the SLS Invocation repository (this will only be temporarystorage, for the (short) life-time of the flow.

- Trigger the SLS monitoring

- YELLOW ZONE : Acceptation = YES and alarm-triggering/threshold crossing:

The SLS can still be accepted, but a (local, first) threshold is crossed.


- New/Modified SLS object stored in the SLS Invocation repository



- Notification to Node monitoring, which in turn must do the alarm triggering to NetworkDimensioning (Editor’s note: is this OK?)


- RED ZONE : Acceptation = NO

- The SLS can not be accepted because a second threshold is crossed

- Notification of refusal to the user.


Note: The SLS information related to customers/users are kept in the SLS repository. The SLSrepository serves as input for the Traffic Forecast Module. TF calculates the predicted load, which willbe used by NM-Dim… There is need for a process that deactivates the use of SLS information(currently available in the SLS repository) for the customers that are no longer subscribed and use theservice i.e., un-subscribed customers. This process must operate on both the customers who are notusing the service any more and the users who already used the service without prior subscription.

-

SLS INTER-DOMAIN REQUESTER FB

This FB handles all requests for new/modified Inter-Domain SLSs. Function:

• Process Inter-Domain SLS requests

The request may come from SLS subscription, SLS invocation, Network Dimensioning or auser/upstream AS.

Still under discussion here is whether we will consider hop-by-hop Inter-Domain SLS negotiation (hopAS, thus only SLSs with peers) or we will consider End-to-End SLS negotiation. In the latter case onecould have SLS contracts with non-peering ASs.

This is for further study/to be completed.



4.6.2 Interface semantics and parametersThis section describes the interaction of the SLS Management Functional Block with other FunctionalBlocks through events, messages or signals. Basic interactions were already given in Figure 14: SLS-Management, Traffic Forecast and NW-Dimensioning. The figure and the table below give moredetails.

Figure 28: Interaction of the SLS Management Functional Block with others

The description of the relevant events is included in the table that follows:

1:�'LPHQVLRQLQJ

7UDIILF�)RUHFDVW6/6�VXEVFULSWLRQ

6/6�,QYRFDWLRQ

�

1HWZRUN�6/60RQLWRULQJ

,QWHU�'RPDLQ�5HTXHVWHU'RZQVWUHDP$6

8VHU�8SVWUHDP�$6

7UDIILF&RQGLWLRQLQJ

3ROLF\�&RQVXPHU 6/6�0RQLWRULQJ

6/6�0DQDJHU

�

�

��

�

�

� �

��

��

��

��

��

�·

��·

��·

��·��··

��·

From FB To FB Event name Parameters Comment

1 PolicyConsumer SLS_Manager SLS_Manager_SetPolicy Setup of Policy Rules & (administrative) constraints

2 SLS_Manager SLS_Monitoring SLS_Monitoring_SetSLSRepository SLS Repository The SLS Monitoring report is generated by the Monitoring FB based on theirmeasurements & the SLS Repository information

3 Dimensioning SLS_InterDomain_Req SLS_InterDomain_Req_Request_Interdomain_SLS ResourcesRequested

Dimensioning request modification or new Inter-domain SLS with peers

4 SLS_InterDomain_Req Dimensioning Dimensioning_Notify_Interdomain_Request Resources granted SLS Management notifies Dimensioning about the new/modified SLS

5 Dimensioning SLS_Subscription SLS_Subscription_Set_Dimensioning_Configuration NW_Confog Dimensioning passes the network configuration to SLS Subscription, who willdo the calculation of spare resources

6 SLS_Subscription Traffic_Forecast Traffic_Forecast_Set SLS_Repository SLS Repository Traffic Forecast needs the SLS Repository for calculating the Traffic PredictionMatrix

7 Traffic_Forecast SLS_Subscription SLS_Subscription_Set Traffic Matrix Traffic Matrix SLS Subscription needs the predicted traffic load for calculating long-term spareresources

8 SLS_Subscription SLS_InterDomain_Req SLS_InterDomain_Req_ Request_Interdomain_SLS Resources requested request modification or new Inter-domain SLS with peers, trigered by an SLSrequest of user/upstream ISP

8’ SLS_Invocation SLS_InterDomain_Req SLS_InterDomain_Req_ Request_Interdomain_SLS Resources requested as above, but for dynamic short-lived micro-flows (WILL WE ACTUALLY DOTHIS?)

9 (9’) SLS_InterDomain_Req SLS_Subscription SLS_Subscription_Notify_Interdomain SLS Resources granted notification about the newly granted Inter-Domain resources/SLSs

10 SLS_Subscription SLS_Invocation SLS_Invocation_Activate_SLS SLS object Activation of a modified/newly SLS object (remark that SLS invocation hasalways a view on the SLS repository, it need only be notified about changes to tonew/modified SLS subscriptions)

12 Network_Monitoring SLS_Invocation SLS_Invocation_Set_Currrent load Edge-to-Edge loadSLS Invocation needs the current node load for calculating the short-term spareresources

12’ SLS_Invocation Network _Monitoring Node_Monitoring_Alarm_Trigger Admission Control Algorithms discovers threshold crossings. Monitoring mustnow inform Network Dimensioning (To DISCUSS)

12’’ SLS-Invocation SLS_Monitoring SLS_Monitoring_Trigger SLS Repository SLS Monitor takes its input form SLS repository and activate the monitoringaction for new/modified SLSs (based on service and scope of the service).

13 SLS_Invocation Traffic_Conditioning Traffic_Conditioning_Set_Conditioning rules SLS_Object infoAfter the successful invocation of an SLS, the edge node must be informed aboutConditioning rules e.g. marking, excess treatment,…

14 User SLS_Invocation SLS_Invocation_Signal_New_SLS SLS_Object(Invok.)

Signalling of new micro-flow SLS. SLS Invocation will now trigger the ProcessSLS Invocation Function

14’ SLS_Invocation User User_Notify_New_SLS Notification SLS signals to the user whether or not the SLS has been accepted.

15 User SLS_Subscription SLS_Subscription_ Signal_New_SLS SLS Object

(subscr.)

Signalling of new subscription SLS. SLS Subscription will now trigger theProcess SLS Subscription Function

15’ SLS_Subscription User User_ Notify_New_SLS Notification/proposal of modified SLSObject

SLS subscription informs the user/AS whether the SLS subscription wassuccessful or not. Also re-negotiation make take place, based on a proposal ofSLS subscription.

16 SLS_InterDomain_Req Inter_Domain_AS Inter_Domain_AS SLS object Request for new/modified Interdomain SLS (resources)

16’ Inter_Domain_AS SLS_InterDomain_Req SLS_InterDomain_Req Notification Notification about granted SLS/resources



5 TRAFFIC ENGINEERING

5.1 Intra-domain Traffic Engineering

5.1.1 Objectives and ApproachesNetwork Traffic Engineering (TE) is in general the process of specifying the manner in which traffic istreated within a given network so that to meet its transfer requirements. The objectives of trafficengineering are twofold, user-oriented and system-oriented.

• User-oriented objectives: The users expect certain performance from the network; and thenetwork in turn should attempt to satisfy user expectations. The expected performance depends onthe type of traffic that the network carries. In the traditional Internet, traffic is best effort and mainrequirements are good throughput and low average delay. In the emerging multi-service Internet,however, traffic requirements vary considerably and may be much more stringent than those ofbest effort traffic. Hence the issue of satisfying traffic performance requirements becomes morecomplicated and more important. This is of primary concern to Tequila; its main objective is theprovisioning of Quality of Service in a multi-service Internet.

• System-oriented objectives: ISPs aim at satisfying the user traffic requirements in a cost-effectivemanner. In addition, they attempt to accommodate as many as possible of the traffic requests, byusing optimally the available network resources. It is desirable to utilise highly the availableresources, however over-utilisation may result in missing transfer requirements. Hence, carefulsystem design is called for. In case the available system resources are not adequate, increase ofresources at minimal cost should be sought for.

The main routing method used today in the Internet is shortest-path routing with respect to certain linkcost. In the context of multi-service QoS provisioning, however, such an approach may not bedesirable always. It may lead to bottlenecks and oscillations. Furthermore, the chosen path may notrepresent the best path necessarily with respect to QoS requirements; and, there is no guaranteewhatsoever, that what deemed as a best path at a time, will result in optimum network operation in aperiod of time. There (has been and there) is today an increasing volume of studies on TE approachesfor dealing with such problems in a cost-effective and scalable manner.

Two different TE approaches are explored within the context of TEQUILA:

• An MPLS-based TE approach: This approach relies on an explicitly-routed paradigm, whereby aset of routes (paths) is computed (in a centralised and/or distributed manner) for specific types oftraffic. In addition, appropriate network resources (e.g. bandwidth) may be provisioned for routingpurposes, according to traffic requirements. Traffic is then routed within the established sets ofroutes, dynamically according to network state within the constraints of the allocated resources,through which routes have been defined.

• A layer 3 (L3)-based TE approach: This approach relies on a ‘liberal’ routing strategy, wherebyroutes are computed in a completely distributed manner, as discovered by network topology set-up. Although route selection is performed in a distributed fashion, the QoS-based routing decisionswill be constrained according to network-wide TE considerations made by the NetworkDimensioning algorithms. The most appropriate route, according to certain criteria, out of thoseroutes meeting the requirements of the traffic is selected. To the end of route computation andselection, static and/or state dependent costs are associated with each link. Route computation isusually based on shortest or widest paths with respect to the assigned link costs.



For each the above approaches, the required intelligence for resource reservation and provisioning may-in theory- either be centralised or distributed. However, the IP-based TE approach is rather based on adistributed approach, while the MPLS approach could very well combine a mix of centralised anddistributed intelligence. The considered approaches are described in sections 5.1.3 and 5.1.4respectively.

The considered approaches are amongst the most discussed approaches in literature and IETF, andactively pursued by ISPs. Note that this does not exclude other viable approaches to emerge in thecourse of the project.

It should be stressed that no correlation between intra-domain traffic engineering approaches indifferent ASs, parts of the TEQUILA system, is assumed.

5.1.2 Elementary TE Functions and the TEQUILA TE Functional ModelAs outlined previously, the term traffic engineering is a general expression for depicting techniqueswhich aim at processing traffic in the network, according to specific requirements and constraints (asspecified in contracted SLSs). It does not itself suggest a specific approach for handling trafficflows/streams in the network. As such, the project has come up with two approaches, outlinedpreviously (more details can be found in the following sections). Anyhow, the choice of a specificintra-domain traffic engineering approach should be a decision by the Autonomous Systemadministrator.

The results of the adopted traffic engineering policy should be enforced in the network by means ofappropriate network components. From this perspective, it is assumed that the following elementaryTE functions support the enforcement of the adopted TE policy:

• Traffic Identification, (namely a flow identification, whereas a flow is defined as a collection of IPdatagrams which share at least one common characteristic – same source address, same protocolidentifier, etc.);

• Traffic Classification, (namely flow classification, so that the switching resources of the networkenforce the appropriate policy, in terms of scheduling, dropping, forwarding and routing);

• Traffic Metering, (so that the switching resources of the network appropriately adapt theirbehaviour, according to the corresponding policy -(see above)).

• Routing of traffic through the network. This involves route path selection and association ofbandwidth with the path.

• Scheduling & buffering mechanisms for packets at each router on the path of the traffic route.

The above elementary TE functions are assumed to be part of the capabilities of the routers in thenetwork. In addition to these elemental TE functions, the TEQUILA system caters in its FunctionalModel (presented in chapter 3) for a number of other functions complementing the elemental TEfunctions, to the end of specifying a complete solution for intra-domain TE. Figure 29 depicts the mainfunctional building blocks to the purpose of traffic engineering during the TEQUILA systemoperation.



1HWZRUN�'LPHQVLRQLQJ

'\QDPLF�5RXWH

0DQDJHPHQW

'\QDPLF�5HVRXUFH

0DQDJHPHQW

5RXWLQJ 3+%�(QIRUFHPHQW

Figure 29: Functional blocks involved in intra-domain traffic engineering

It should be noted that the specified Functional Model for TE covers both approaches contemplated bythe project (MPLS and IP-based, see section 5.2 describing the identified components). Further, itshould be noted that both approaches could co-exist in the network, as appropriate for specific types oftraffic, or simply because MPLS switching may not be deployed everywhere in the network consideredas a collection of autonomous systems. This is achieved thanks to the functional decompositionimplied by the Functional Model, by appropriately restricting the responsibility of the identifiedfunctional components. The role of the intra-domain TE functional blocks (Figure 29) in the twoapproaches (MPLS and IP based) considered, is outlined in section 5.2.

It is believed that the proposed Functional Model can cover (any) other known TE approaches.

It should be stressed that the operation of the intra-domain traffic engineering approach should be (andit is in the proposed Functional Model) transparent to the SLS management and inter-domain trafficengineering approach. Appropriate interactions on suitable components ensure their inter-working inthe context of a single system. This should allow different operators to select different intra-domaintraffic engineering approaches, e.g., dependent on the availability of MPLS network capableequipment.

Last, it should be noted that the specified Functional Model, especially the interfaces between theidentified functional blocks, will be continuously reviewed according to the maturity of the underlyingideas and in the light of the algorithms/protocol specifications and experimental results, to beundertaken by the project.

5.1.3 MPLS-based Traffic EngineeringThis section provides the MPLS traffic-engineering framework of the TEQUILA system. MPLS TE isexercised at two time scales, long-term and short-term.

• Long-term MPLS TE (days - weeks) selects the traffic that will be routed by MPLS based onpredicted traffic loads and existing long-term SLS contracts. Following, the routes (path,bandwidth) as well as associated router scheduling and buffer mechanisms are defined. Thisprocess is done off-line taking into account global network conditions and traffic loads. It involvesthe global trade-offs of user and system oriented objectives; it is part of the NetworkDimensioning component of the Functional Model (see Figure 29).

• Short-tem MPLS TE (minutes - hours) is based on the observed state of the operational network.Dynamic resource and route management procedures (Dynamic Resource and Route Managementcomponents of the Functional Model, see Figure 29) are employed in order to ensure high resourceutilisation and to balance the network traffic across the LSPs specified by long term MPLS. Thesedynamic management procedures perform adaptation to current network state within the boundsdetermined by long-term traffic engineering. Triggered by inability of dynamic managementfunctions to adapt appropriately, or by significant changes in expected traffic loads, or localchanges in network topology, LSPs may be created or torn down by long-term TE functions.



The long-term TE corresponds to the time-based capacity management functions of TE [TE-FRAM],whereas short-term TE corresponds to state-dependent capacity management functions of TE. Byvirtue of the specified Functional Model, all these functions inter-operate to the objective of offering acomplete TE solution.

Long and short term TE is discussed in more detail in the following.

In the sequel, traffic with certain performance requirements is associated with origin-destination set-pairs. The term set-pair refers to the fact that in certain cases such as VPN traffic from a certain sourcemay be directed to multiple outputs or vice versa.

5.1.3.1 Long-term MPLS TE

n e two rkp la n n ing

T ra ff icFo re ca s t

A d m in istra tiv eP o lic ie s

T raffic T runks ,T raffic T run k

A ttr ibu tes

L S P D ete rm ina tio n

P H B T reatm en t o f L SP s

L in k B an d w id th R ese rvation

L SP A ggrega tio n

Schedu lin g andB uffe r ing m echan ismparam ete rs

Lo ad B alanc in g M echan is m sA nd P aram ete rs

Figure 30: Long-term MPLS Traffic Engineering

The long term TE process is illustrated in Figure 30. It is realised by the Network Dimensioningcomponent. Its inputs are:

• Network topology and the link capacities (capacity, delay, PHB capability) as determined by theNetwork Planning component.

• Predicted traffic between various source-destination pairs. Traffic predictions are calculated by theTraffic Forecast Model and are based on

- extrapolations from measurements performed during the operation of the network,representing an average of the expected traffic load, and

- SLS contracts between the users and the network; the network has the obligation to fulfil thesecontracts and thus has to reserve the appropriate network resources.

• Administrative policies regarding physical restrictions on the allowable paths of certain types oftraffic. E.g. traffic coming from a given AS is not allowed to pass through certain parts of thenetwork, or a given percent of network capacity to be always available for best effort traffic.

Based on the above input, part of the predicted or contracted network traffic is routed using MPLS.Candidates of traffic for MPLS-based handling are:



• Traffic contracted through SLSs with quantitative performance requirements (quantitative SLS).

• Traffic contracted through SLS with qualitative, relatively strict performance requirements(qualitative gold service SLS).

• Predicted traffic that has been determined from measurements as being of statistically consistenthigh volume to warrant the specification of explicit path set-up.

For each of the above categories of traffic, sets of traffic trunks, i.e., aggregates of traffic flows withthe same origin-destination pair and the same performance requirements, are determined. For example,all SLSs with the same quantitative performance requirements from ingress router A to egress router Bform a traffic trunk. Aggregating flows to traffic trunks results in fewer LSPs. This has obviousbenefits to scalability and LSP management. However, care should be taken in order to ensure thatSLS contracts are observed (see the discussion below). Next, TE attributes are associated with each ofthe traffic trunks. The TE attributes are used for LSP design, and network resource allocation. Alongthe lines of [RFC2702], they consist of

• Trunk traffic load attributes. These attributes determine the bandwidth of the traffic trunk.Associated with these attributes are

• Traffic policing attributes. These attributes specify the manner in which excess trunk traffic ispoliced and treated. Care should be exercised in the manner these attributes are defined since atrunk may consist of an aggregate of flows specified by different SLSs. Aggregating trafficpolicing parameters of a number of SLSs may result in unfair and out-of-contract treatment ofcertain flows.

• Path selection attributes. These attributes specify the administrative constraints on the traffic trunkpaths, as well as constraints imposed by QoS requirements. For example, if the traffic trunk hasstrict delay requirements, then long delay links (e.g., satellite links) are avoided and a maximumhop-number on the LSPs may be imposed. On the other hand, for best effort traffic trunks, ashortest path selection methodology may be applied.

• PHB attributes. These attributes specify the possible PHB treatment of the trunk traffic throughoutthe network. That is, they may specify a list of PHBs to which the trunk traffic may be assigned asit traverses the network routers. For example, for type 2 SLSs the possible PHB attribute may beAF1, AF2, or AF3.

• Path adaptation attribute (0 or 1). This attribute specifies whether the selected LSPs are subject tore-optimisation. This information will be used in conjunction with short-term TE to determinewhether LSPs can be modified (either by rerouting or by modifying the reserved resources) toadapt to changing network conditions during the operation of the network

• Resilience (reliability) attributes. These attributes specify the treatment of the trunk traffic whennetwork component failures or faults occur. They specify choices such as, whether recoveryshould be attempted by re-routing, whether only failure notification should be provided withoutany further actions etc. There are a variety of policies that can be employed regarding reliability,each implying a number of mechanisms and implementation issues that need to be resolved.

Traffic trunks are unidirectional. In the operation network, the notion of bi-directional trunk is alsomeaningful when flows in one direction may exist only if flows in the other direction also exist e.g.conversational flows. If no restrictions on the forward and backward paths are imposed, then bi-directional paths may be implemented as two unidirectional paths with the restriction that they arecreated activated, deactivated and destroyed together. Hence, from a TE point of view, onlyunidirectional trunks need to be considered. If however, the restriction is imposed that bi-directionalpaths are established on the same links, then TE must take into account the existence of bi-directionaltrunks in the design of LSPs. In TEQUILA, the former approach is followed that is, bi-directionaltrunks are treated as two uni-directional trunks.



Having determined the traffic trunks and their attributes, the next step is to associate LSPs with thetraffic trunks in accordance with their attributes. This process involves the following

• Determining a number of LSPs that are appropriate for carrying the trunk traffic.

• Determining the PHB treatment at each network router, of the traffic carried by the LSPs.

• Reserving bandwidth on the network links.

At the end of the previous process it may happen that multiple LSPs, belonging to different traffictrunks follow the same physical links. Using the same label for these LSPs (aggregating in effect in asingle LSP) will simplify MPLS management. However, a mechanism is needed in this situation bywhich the different PHB treatment of the original LSPs is maintained. Such a mechanism is proposedin [FAUCH2000].

Usually, as a result of the TE process, appropriate bandwidth is allocated to each LSP. However, thehose and funnel scope models that are adopted by TEQUILA require careful handling andimplementation. In the hose scope model, traffic from a single ingress node may be directed to anumber of egress nodes. If the hose model carries best effort traffic, then no special problems arecreated. New issues arise, however, when performance parameters are specified.

$ %

&

'

� � �0 E S V

� � �0 E S V

� � �0 E S V

Figure 31: Bandwidth Allocation Under the Hose Scope Model

Consider the situation in Figure 31. In this figure an SLS is introduced using the hose model. The SLSspecifies that traffic from ingress node A is to be routed to egress nodes C or D. In addition it specifiesthat the maximum traffic injected into the network by node A is 10Mbps. This traffic may be directedto either C or D. Hence both C and D may accept up to 10 Mbps of traffic from A, however, the sumtotal of the injected traffic may not exceed 10Mbps. In this situation, from a traffic engineeringperspective an efficient way to reserve bandwidth while fulfilling the SLS contract is to reserve10Mbps on links BC and BD, and 10Mbps (instead of 20Mbps) on link AB. In order to carry thecontracted SLS traffic using MPLS, two LSPs can be created, LSP1 using links {AB, BC}, and LSP2using links {AB, BD}. However, is this case, it is not appropriate to associate Bandwidth with eachLSP, since such an association will result in reserving 20Mbps on link AB. Hence, the bandwidthreservation process must not be directly linked to LSPs. Another approach would be to terminate anLSP at B and then split the traffic of that LSP to two new LSPs, one on link BC and one on link BD.Asimilar situation can arise with the funnel scope model.

Irrespective of the manner bandwidth is associated to LSPs, there is the question on how thebandwidth reservation is to take place on the network links. An approach to this issue is the following.

• The bandwidth reserved for the LSPs, is directly related to the bandwidth of the available PHBs.Hence the bandwidth available to a PHB must be larger than or equal to the sum of the bandwidthsof the LSPs whose traffic belongs to the given PHB. The bandwidth available to the PHBs can becontrolled by the scheduling mechanism. In particular, for WFQ scheduling mechanisms, theminimum guaranteed bandwidth to each PHB could be determined by the appropriate weights.



• The above-mentioned approach may provide the proper total bandwidth needed by the LSPs,however, it cannot guarantee that each of the LSPs will receive its proper share of the totalbandwidth. For this, some type of policing is required in order to ensure that the LSPs are notinjecting into the network more traffic load than that warranted by the bandwidth allocated tothem. The appropriate place of such policing is the source LER for the given LSP; and, this isachieved by setting appropriate traffic meters. These traffic meters functions should not beconfused with the traffic meters set for SLS conformance (by the SLS management components).

Once the LSPs along with their PHB treatment and their bandwidth are determined, there remains tospecify:

• The parameters that are needed by the PHB implementations in order to ensure that there areavailable resources in the network to accommodate the LSP traffic. These parameters depend onthe manner PHBs are implemented by the network routers. For example, if WFQ is used toimplement AF1, the WFQ weight of this PHB must be determined. Similarly, the buffermanagement parameters will be determined from the loss probability associated with the PHB andthe traffic rate it is expected to carry.

• The load balancing parameters that will be used by the dynamic routing functions (cf. DynamicRoute Management component, see Figure 29). This is due to the fact that normally for eachsource-destination pair, the TE process will determine more than one possible route. This is adesirable scenario since in this manner the load is distributed evenly in the network, resulting inefficient resource utilisation and improved traffic performance. In addition, the probability ofhaving available routes to the destination when network components fail increases. In order to takeadvantage of the existence of multiple paths to the destination, however, algorithms must be inplace to ensure the proper distribution of the load, taking into account constraints such as avoidingout of order packet arrival etc.

It is clear from the above, that the proposed MPLS-based TE views LSPs as ‘route-maps’; not as pipeswith explicitly allocated bandwidth. LSPs are further aggregated in terms of their bandwidth intoPHBs, setting accordingly the bandwidth of the resources implemented the PHBs. The bandwidthallocated to the established LSPs and subsequently to PHBs should not take only into account theexpected traffic to be routed over the LSPs. They should also take into account the QoS guarantees ofthe traffic (as in the SLSs) e.g. the throughput or delay that the individual traffic aggregated in theLSPs and in the PHBs should enjoy.

5.1.3.2 Short-term MPLS Traffic EngineeringAs discussed in the previous section, as a result of the long-term TE, the following parameters aredetermined:

• A set of LSPs for connecting origin-destination pairs.

• Bandwidth reserved on network links in order to accommodate the traffic carried by the definedLSPs.

• PHB link scheduling parameters for the routers in the network, reflecting the above bandwidthreservations.

• PHB buffer management parameters for the routers in the network.

• Load balancing parameters for the set of LSPs connecting given origin-destination pairs.

This information is downloaded to the LSRs and is used to configure the router forwarding tables, aswell as the scheduling and buffer management parameters. Hence, the LSRs are now ready to acceptMPLS traffic on the established LSPs. The mechanisms that are now put in operation in order toensure the proper -in terms of user-oriented objectives- and efficient - in terms of system orientedobjectives- operation of the network.



Short-term MPLS TE is based on the observed state of the operational network. Its objective is toadapt the mechanisms and parameters of the elemental TE functions (section 5.1.2), in a timely fashionwithout major disruption of network operation in order to effect the network adaptation to a new good(not necessarily optimal) state. This adaptation usually involves only local changes.

Specifically, during the operation of the network, dynamic routing management procedures areemployed (by the Dynamic Route Management component) in order to balance the network trafficacross the sets of traffic routes defined by long-term TE. In addition, dynamic management of linkbandwidth and buffer space is performed (by the Dynamic Resource Management component) in orderto adapt to current network state within the bounds determined by long-term TE. Inability of thedynamic route and/or resource management to adapt to current network state, significant changes intraffic loads, or local changes in network topology, trigger long-term TE effect global networkchanges.

More details on the activities of the Dynamic Resource and Dynamic Route Management componentsin the MPLS-based approach are given in sections 5.2.2.1 and 5.2.3.1 for.

5.1.4 Pure IP-based Traffic Engineering

5.1.4.1 IntroductionThis section describes the IP-based TE approach relying mainly on the capabilities of the IP dynamicrouting protocols employed in the TEQUILA system. From this standpoint, we adopt the classicalintra-AS (Autonomous System)/inter-AS taxonomy. The section is organised as follows:

• A “basic assumptions” section, which introduces the concept of traffic engineering adapted to IPdynamic routing protocols;

• A section which describes the basic components of the overall “layer 3” functional architecture,including IP routers and their interaction with the dynamic resource/route management modules ofthe TEQUILA system;

• An intra-AS section, which focuses on the use of the OSPF (Open Shortest Path First, [RFC-2328]) protocol for conveying traffic engineering-related information;

• autonomous systems;

5.1.4.2 Basic AssumptionsAs already mentioned in section 5.1.2 the elementary TE functions are: Traffic Identification, TrafficClassification, Traffic Volume Metering and Route Selection. The result of Route Selection consists inpopulating the FIB (Forwarding Information Base) of each IP router of the network accordingly. Theactual selection of a route will however not only depend on the metrics that will be taken into accountwhen running the routing algorithm, but also on SLS-related information. The former could e.g. be thehop count metric that will be used by the RIP (Routing Information Protocol, [RFC-2453]) protocol,whereas a cost metric will be used by the Dijkstra’s SPF (Shortest Path First) algorithm performed bythe OSPF protocol.

We distinguish between:

• QoS-related information, conveyed in SLS templates (being processed by the SLS managementmodules of the TEQUILA system); this information should be taken into account by the dynamicIP routing protocols for selecting paths to reach specific destinations;

• TE (Traffic Engineering)-related information, exchanged by routers for enabling the enforcementof the traffic engineering policy (within an AS, typically).



As such, QoS-related information provides information on the traffic to be forwarded in the network,including the QOS specific requirements associated to a given traffic, whereas TE-related informationprovides information to the routing processes (being activated by each router of the network) forrouting the traffic so as to meet its requirements. From this standpoint, the TE-related information canbe viewed as the "IP routing"-oriented translation of the QOS-related information, e.g. the QOS-related information conveyed in an RSVP PATH message can be used as an input for the "bw"(bandwidth) metric to be taken into account by an OSPF calculation for the selection of the best"QOS" route that will meet the requirements of the RSVP reservation process. There is therefore aclose relationship between these two types of information, so that end-to-end quality of serviceprovisioning be appropriately enforced.

Finally, it is assumed that:

• IPv4 is the only formalism considered, despite the intrinsic traffic engineering capabilities of theIPv6 formalism (including the routing header);

• OSPF is the IGP (Interior Gateway Protocol) being run within an AS. From this standpoint, staticrouting is not considered as an option, mainly because of scalability concerns (whatever this staticrouting may consist in, i.e. either using the LSR (Loose Source Routing) or SSR (Strict SourceRouting) options of the IPv4 header ([RFC-791]), or by manually populating the FIB of therouters);

• BGP-4 is the EGP (Exterior Gateway Protocol) being run for conveying reachability informationbetween autonomous systems;

• Aggregation is a MUST whenever possible (at least between domains, according to the CIDR(Classless Inter-Domain Routing, [RFC-1519]) specification, but also within domains wheremultiple OSPF areas may have been deployed, thus yielding the use of type 3 LSAs (Link StateAdvertisement) between areas);

• Whenever possible, the information contained in this document is as independent as possible fromthe various routing design flavours made possible by the activation of such routing protocols, likea multiple area environment within a given domain, or a BGP confederation topology. These areconcerns, which mainly address scalability issues, but it’s obviously worth considering themwhenever routing efficiency (which can be defined in terms of convergence times or path selectionaccording to specific constraints) is viewed as a key component of the traffic engineeringcapabilities of the TEQUILA system.



5.1.4.3 Functional Architecture

Figure 32: Functional architecture of the IP-based traffic engineering approach

The network elements are the IP switching resources of the network, namely the IP routers. For IPtraffic engineering purposes, a basic classification of such elements consists in distinguishing networkelements which belong to autonomous system AS # n, from network elements which do not belong tothis autonomous system, so as to consider intra-AS traffic engineering from inter-AS trafficengineering. By definition, all of the routers embed forwarding and routing features (i.e. all of therouters support both the OSPF and the BGP-4 protocols1), whereas:

• Some of them are diffserv-capable, i.e. they have the ability to process the incoming trafficaccording to PHBs, which have a one-to-one relationship with the DSCP (DiffServ Code Point)values assigned in the DS (DiffServ) byte of the header of each IP datagram.

• Some of them are intserv-capable, i.e. they have the ability to process the information conveyed inthe RSVP (Resource reSerVation Protocol, [RFC-2205]) traffic which may pass through them, sothat they might be able to enforce bandwidth reservation requests along a given path;

• Some of them are both diffserv- and intserv-capable, so that they might gracefully process thecorresponding QOS-related information.

• There may well be routers that do not support any of the above-mentioned capabilities.

• All of the routers are interconnected by links of different nature (i.e. there is no specificassumption about the underlying transport technology), and according to a (possibly) meshtopology.

• As far as traffic engineering is concerned, the routing capacities of these network elements aim atselecting the best path to reach a specific destination (where destination is expressed as an IPprefix), according to the hop-by-hop paradigm.

1 This figure does not make any assumption about the number of RIBs and FIBs a given IP router can maintain(e.g. within the context of “virtually routed VPNs” (based upon the use of “virtual routers”), one could assume aFIB (and a collection of RIBs) PER VPN.

RI

FI

“Routing”

RI

FI

“Routing”

RI

FI

“Routing”

AS #

Dynamic route

Dynamic resource

“Routing”BGP-4 peering relationships



The dynamic route management block of the TEQUILA system is expected to embed a route database([IRR]) for consistency purposes, and the generic architecture being specified by the TEQUILAproject and depicted by figure 4 assumes:

• The selection of a route is based upon the knowledge of QOS-related information, made of DSCP-related information as well as resource-specific information (expressed in terms of bandwidth,delay, jitter according to the customer’s requirements),

• The dynamic route management block embeds a PDP (Policy Decision Point, [RFC-2748], onePDP per AS typically) capability that will aim at transmitting the above-mentioned QOS-relatedinformation to the PEP (Policy Enforcement Point, [RFC-2748]) capability embedded in therouters. Upon receipt of this information, the routing processes will have the ability to use it forselecting the best paths accordingly.

The COPS (Common Open Policy Service protocol, [RFC-2748] appears to be one of the privilegedcommunication means between a given PDP and a collection of PEP, while information repositories(bandwidth brokers, route databases) can be accessed by the LDAP (Lightweight Directory AccessProtocol, [RFC-1777]) protocol.

The PEP facility is assumed to have the ability to exchange information with a “routing” PDP (PolicyDecision Point), which is embedded in the Dynamic Route Management module of the TEQUILAsystem. I.e., from a traffic engineering policy standpoint, running either OSPF, BGP-4 or bothprotocols on a given router should gracefully benefit from the information provided by the PDPthrough the PEP for route calculation and selection purposes.

The PDP (one per AS, typically, though a distributed implementation might be envisaged) isresponsible for:

• Formatting the QoS-related routing information according to COPS (Common Open PolicyService) semantics, so that it might be conveyed in DEC messages accordingly, whether thesemessages be solicited or not (i.e. the PDP would have, by definition, the ability to send unsolicitedmessages to the PEPs it is responsible of – within the context of a time-based traffic engineeringpolicy for example);

• Processing REQ messages coming from the PEPs, whenever a change (topology, environment,etc.) has been detected by the routers supporting these PEPs. This processing would probablyimpact the network planning and dimensioning modules of the TEQUILA system.

For those routers that do not support a PEP capability (or any equivalent mechanism), the enforcementof a traffic engineering policy will be based upon their local decision points, i.e. the routing processesthey activate. The route calculation and selection will therefore be basically composed of:

• Standard OSPF and BGP4 procedures (as described in the corresponding specifications);

• TE-related information whenever possible (see below), to be exchanged between OSPFneighbours within an area, between areas, and between BGP peers of different administrativedomains;

• QoS-related information, to be taken into account by the SPF algorithm and/or by the path-vectorrouting algorithm (e.g. when the router is RSVP-capable).

For such “non-COPS” capable routers, consistency of the topology as well as the routing informationwill be mainly enforced by the router themselves2.

2 If we except the management capabilities of the TEQUILA system, like the use of the SNMP (Simple NetworkManagement Protocol) protocol together with the appropriate MIBs (Management Information Base, such as theOSPF MIB, [RFC-1850]) which will help in storing and maintaining the routing information used by the routersto make their path selection decisions.



5.1.4.4 Using OSPF

5.1.4.4.1 Processing QOS-related information

Some (if not all) of the OSPF implementations to be used by the TEQUILA system are expected to setthe T3 bit (the least significant bit of this one-byte long field, [RFC-1583]) in the Options field ofOSPF Hello packets, database description packets and all LSAs, so as to indicate (to their OSPFneighbours) they have QoS routing capabilities, i.e. they have the ability to calculate a path accordingto the QoS-related information they have been provided by different means:

• activation of the RSVP protocol (and processing of the corresponding TSpec parameter conveyedby RSVP PATH messages),

• manual configuration according to administrative policies, and/or

• dynamic processing of QoS-related information (such as DSCP-based routing) provided by theDynamic Route Management modules of the TEQUILA system, thanks to the possible use of aPEP capability.

This QoS capability should allow the corresponding OSPF implementations to compute QoS-basedpaths, which will aim at populating a QoS routing information base (which can be considered as partof the classical LSDB for the QoS-based entries of the OSPF RIB). This populating activity shouldalso yield the generation of a RPT message, sent by the PEP back to the PDP, so that the dynamicresource/route management be updated accordingly.

QoS-unaware implementations should gracefully ignore the above-mentioned QoS capability, and runthe SPF algorithm according to [RFC-2328]. QOS-unaware implementations should be known by theNetwork Dimensioning module for preparing accordingly the QoS-related routing information to bepassed to the Dynamic Route Management module and subsequently to the routing processes of therouters.

5.1.4.4.2 Conveying TE-related information by using opaque LSAs

Routers within a domain may be organised into several OSPF areas, thus yielding the use of type 10(area flooding scope) as well as type 11 (domain-wide flooding scope) Opaque LSAs, as per [RFC-2370]. Indeed, the OSPF Opaque LSA is the privileged support for conveying TE-related informationwithin a domain, by using specific TLV (Type Length Value) and sub-TLV encoding, as defined in[KATZ99] (for TLV type 2 (“Link TLV”) and its associated sub-TLVs) and in [FUJITA00] (for usingan opaque-based TE LSA across areas4).

Opaque LSA implementations may include an application programming interface for encapsulatingapplication-specific information in a specific opaque type, for sending (and receiving) application-specific information and for informing an application of the change in validity of previously receivedinformation, whenever appropriate. Within the context of this document, it is expected that such anAPI might be available for communication between the above-mentioned routing PEP capability andthe OSPF implementation itself.

Most of the existing OSPF implementations support the Type 10 Opaque LSA (area flooding scope),while implementations which do not recognise the above-mentioned TLV and sub-TLV encodingshould gracefully ignore the corresponding LSA messages.

3 [RFC-2676] proposes to re-name this bit as the “Q” (for QoS) bit, which basically consists in indicating to itsOSPF neighbours that the advertising router has QoS-routing capabilities.

4 The work described in this draft needs further elaboration, though (especially from a type5/type11 LSAmanagement and consistency standpoint).



5.1.4.4.3 Load sharing capability

While document [RFC-2328] clearly defines the ECMP (Equal Cost Multi-Path) capability, whichallows a router to divide traffic somewhat evenly among the available paths, it’s generally admittedthat an unequal division of traffic among available paths is preferable ([OMP99]).

ECMP does not make any attempt to dynamically adjust to OSPF cost metrics, it will divide trafficequally among the available paths. Such a load sharing capability is performed either by:

• Forwarding datagrams on a round-robin basis (which is applicable when the observed transitdelays over the available paths are almost equal);

• Dividing destination prefixes among available next hops, according to the entries of the router’sFIB (which may yield unpredictable load split (especially when considering aggregationcapabilities of some OSPF routers, like ASBR routers, typically));

• Dividing traffic according to a hash function applied to [source; destination] pairs (based upon a16-bit encoded CRC (Cyclic Redundancy Check) algorithm, for example).

We assume that some of the OSPF implementations to be used within the context of the TEQUILAsystem will support a hash-based ECMP capability, so that traffic might benefit from a load sharingcapability which has proven its stability (i.e. the risk of oscillating routes is negligible)5.

5 OMP-based commercial implementations do not exist, apart from simulation works. The experimental networkelements to be used by the TEQUILA system may possibly support this capability, at the risk of managingoscillating routes.



5.2 Traffic Engineering: Functional Block DecompositionThis section describes in more detail the main functional blocks responsible for TE within theTEQUILA Functional Model (see Figure 29): Network Dimensioning, Dynamic ResourceManagement and Dynamic Route Management.

It should be noted that the functionality and interactions of the identified functional blocks are subjectto revisions according to algorithm/protocol specifications to be subsequently undertaking.

5.2.1 Network Dimensioning

5.2.1.1 DescriptionThe network-dimensioning block is responsible for determining cost-effective allocation of physicalnetwork resources subject to resource restrictions, load trends, requirements of quality of service andpolicy directives and constraints. The resources that need to be allocated are mainly QoS routingconstraints, are mainly link capacities and router buffer space, while the means for allocating theseresources are capacity allocation, routing mechanisms, scheduling and buffer management schemes.

The main task of Network Dimensioning in both TE approaches considered (see sections 5.1.3, 5.1.4)is to accept input from the Traffic Forecast Model (cf. chapter 3), and dependent on the particular logicof the adopted approach, to calculate and install parameters required by the elementary TE functions inthe network (section 5.1.2). This way, the input from Traffic Forecast Model and the output to SLSmanagement components is assumed to be independent of particular logic of the intra-domain TEapproach employed.

The Network Dimensioning component is, in general, centralised; distributed implementations are alsopossible. In any case, it utilises network-wide information, received from the network routers and/orother functional components through polling and/or asynchronous events.

In the MPLS approach (section 5.1.3.1), Network Dimensioning calculates a set of routes (paths)through the network, according to the specific transfer requirements and the predicted volume of thecontracted traffic (SLSs). The computed explicit routes are then provided to the appropriate ingressnode(s) of the network (might also be provided in the core of the network, if the MPLS capabilities ofthe routers allow so –label stacking), triggering the appropriate path establishment mechanisms.Network Dimensioning also calculates the required bandwidth to be associated with the explicit routes(according to predicted traffic volumes). The required resource reservations along the explicit pathscan either be signalled along the establishment procedure, or can be implicitly reserved by settingbuffer and scheduling parameters in the individual nodes along the paths (using E-LSPs) – see section5.1.3.1).

As already outlined in section 5.1.4, the basic paradigm in the pure IP approach is that all trafficengineering and resource reservations should be made in a distributed fashion, thereby inherentlyproviding high levels of scalability and fault tolerance. Hence, in this approach, NetworkDimensioning exercises less influence on the routing decisions compared to MPLS approach, in thesense that does not calculate explicit routes (paths) for routing specific types of traffic; this might haveimplications in the ability of the network to provide efficient traffic performance differentiation.

In the IP-based TE approach, Network Dimensioning sets ‘administrative’ parameters (no dynamicload dependent parameters) per link to be distributed by the IGP employed in the network, OSPFwithin the context of the TEQUILA project. This enables to deterministically influence the routingdecisions in the network, in the sense of indicating the network interfaces to be used for routingpurposes by the IGP employed in the network. Through these settings, it could be possible to reservespecific network interfaces for the MPLS-based traffic engineering (for treating specific types oftraffic e.g. requiring very stringent performance).



By relying routing solely on administrative link parameters, adaptability to changing networkconditions is very limited, although such parameters may be dynamically modified, thanks to theCOPS-based enforcement of a time-based routing policy where, for example, OSPF cost metricsshould be modified every given period of time for the purpose of routing and forwarding specifictraffic. To overcome this inability, routing should be based on the distribution of load related linkparameters by the IGP. As such, the paths the traffic follows would be load dependent, hence non-deterministic. Key issue here is whether such an approach, i.e. making routing decisions based on loadparameters, would make route flapping as the rule than being the exception. This depends on howdynamic such routing decisions would be; the issue will be further investigated, duringalgorithm/protocol specifications.

For making the state-dependent IGP, QoS-aware (according to the requirements of the contractedSLSs), Network Dimensioning computes QoS-related routing information (section 5.1.4.1) which issent down (through the Dynamic Route Management component, see below) the routers forinfluencing accordingly the routing processes in the routers (see discussion in section 5.1.4.3).

5.2.1.2 Interface Semantics and ParametersThis section describes the interaction of the Dimensioning functional block with other functionalblocks through events, messages or signals.

In te rd o m a in S L S R eq

D im e n sio n in g

D yn a m ic R o u te M g m t

M o n ito rin g

P la n n in g

D yn am ic R e s o u rce M g m t

P o lic yC o n s u m e r

2

1

3

45678 , 9

1 0

11

T ra ffic F o re c a s t

1 2

1 3

S L S S u b s c rip tio n

A d m is s io n C o n tro l

1 4

Figure 33: Interaction of the Network Dimensioning Functional Block


1 PolicyConsumer Dimensioning Dimensioning_SetPolicy (1) -This message will set up constraints/policy directives.

2 Dimensioning Planning Planning_NotifyPhyResourceLimitFound (2) -This message will be sent when physical resources no longer satisfy demand.

3 Planning Dimensioning Dimensioning_NotifyTopolResChange (3) Physical topology,Resources

-This message will notify the Network Dimensioning that planning has madenew resources/topology available.

4 Dimensioning DynamicResourceMgmt DynamicResourceMgmt_SetResourcesConfig (4) (see comment) -This message will determine scheduling and buffer management policies andset up scheduling/buffer management parameters.

-This message will set up constraints/policies for distributed bandwidthmanagement algorithms.

5 DynamicResourceMgmt Dimensioning Dimensioning_NotifyResMgmtUn (5) -This message will notify the Network Dimensioning that the dynamic resourcemanagement was not able to deal with the actual demand with its currentconfiguration. Re-dimensioning will be done as a result of this.

6 Dimensioning DynamicRouteMgmt DynamicRouteMgmt_SetRouteConfig (6) (see comment) -This message will set up the Dynamic Route Management parameters e.g.MPLS LSPs, link costs, route per traffic class.

-This message will set up constraints/policies for distributed route managementalgorithms.

7 DynamicRouteMgmt Dimensioning Dimensioning_NotifyDynRouteMgmtUn (7) -This message will notify the Network Dimensioning that the dynamic routemanagement was not able to deal with the actual demand with its currentconfiguration. Re-dimensioning will be done as a result of this.

8 Dimensioning Monitoring Monitoring_SetMonitoring (8) (see comment) -This message will set up Monitoring parameters related to Dimensioning.These include threshold values and parameters that dimensioning wants to bemeasured. See Dimensioning_NotifyThresholdEvent below.

9 Dimensioning Monitoring Monitoring_NotifyNewConfig (9) -This message will be sent in each re-dimensioning of the network and it willinclude the new network configuration.

10 Monitoring Dimensioning Dimensioning_NotifyThresholdEvent (10) Monitoring eventthreshold

This message is sent when a threshold crossing/link failure, etc, has happened,according to the parameters configured by Monitoring_SetMonitoring. It willtrigger re-dimensioning.

11 Dimensioning SLSSubscription SLSSubscription_SendNetConfig (11) NetworkConfiguration

-This message will be sent to the SLS Subscription in order for Subscription tocalculate the spare resources.

12 Dimensioning InterdomainSLSReq InterdomainSLSReq_RequestInterDomainRes (12) Resources -This message will be sent to request the initiation of interdomain SLSnegotiation/re-negotiation.

13 InterdomainSLSReq Dimensioning Dimensioning_NotifyInterDomainResAvail (13) Resources -This message will notify Dimensioning that interdomain request was successfuland what resources have been granted.

14 Dimensioning TrafficForecast TrafficForecast_GetForecast (14) Forecast parameters -This message requests and gets Traffic Forecast related to Dimensioning.



5.2.1.3 Description of FunctionsConsidering the functions of the Network Dimensioning component described previously, all requestsfor network re-dimensioning will be processed by the function Process Request. Based on policydirectives and constraints, the Process Request can call the other functions or wait for the next request.

1. Calculate New Configuration: This function maps service demand sets to network resources.This is done taking into account current load, expected traffic and policy directives andconstraints.

This function requires the following information as input:

- The traffic forecasts related to dimensioning (from Traffic Forecast). All information about thecurrent SLS subscriptions is included here.

- Policy directives and constraints (from Policy Consumer).

The output information is as follows:

- The configuration of resources that accommodates the traffic load and satisfies the traffic QoSrequirements. The configuration includes:

- Source-destination route set

- Capacity allocated to each route

- Load balancing mechanism and parameters for the routes in each route set

- Traffic conditioning parameters for each source-destination traffic

- PHB assignment for each route

- Link scheduling mechanisms and parameters for the network routers

- Buffer management mechanisms and parameters for the network routers.

- If there is no such configuration, the parameters can be negotiated.

2. Enforce New Configuration: This function will carry out the new configuration of the networkthat was previously dimensioned by the function Calculate New Configuration. Allconfigurations necessary to be set up are done by this function.


- The new network configuration provided by the function Calculate New Dimensioning.


- Messages to Monitoring, Dynamic Route, Resource Management and SLS Management to setup their parameters according to the new configuration.

3. Store / Retrieve Configuration Network: This function will store / retrieve all configurationsthat have been effectively used by the network.


- The new network configuration provided by the functions Calculate New Configuration andEnforce New Configuration.

- A request for current or past configuration to be retrieved.


- Message informing about the success or failure of the retrieval

- The requested configuration.



4. Process Requests: This function receives all requests and notifications to network dimensioningblock and calls other functions or rejects them. This decision will be based on constraints andpolicy directives.


- Policy directives and Constraints (from Policy Consumer).

- Request for new (or update of) network configuration


- Command to calculate a new configuration.

- Command to carry out or deny this new configuration.

5.2.1.4 Finite State MachineThis section describes the internal working of the Functional Sub-Blocks, which constitute theDimensioning Functional Block by means of a Finite State Machine (FSM).

Propagating Configuration Storing

ConfigStoring Config

Calculating

Getting Forecast

Processing

UpdatingTopology

IdleIdle

InitInit

ErrorError

**

Forecast Got E.10

Calculation Done E.11

Configuration Stored E.13

Calculation Infeasible E.12

Propagation Failed E.15

Alarm Sent E.16

Propagation Done E.14

Initialization Done E.0

No Event E.1

*

SetPolicyDim Funct E.3

NotifyDynResM gm tUn E.5

NotifyDynRouteM gmtUn E.6

NotifyThresholdEvent E.7

NotifyResAvail E.8

Topology Updated E.9

New Request /Notification

E.2SetPolicyDim Funct

E.3

Propagation Request E.4

Figure 34: The Finite State Machine of the Dimensioning Functional Block.

Description of states

• Init: all functions to initialise the Network Dimensioning block are performed during this state.

• Idle: state at which we wait for external requests and notifications.

• Processing: during this state every new request or notification is processed in order to determinethe correct action. When the notification or request has been processed the next state will dependon the type of arriving message and current constraints and policy directives.

• Updating Topology: during this state the internal topological database is updated as a result of achange of the physical topology.

• Getting Forecast: at this state we are requesting and getting the predicted traffic from the TrafficForecast.



• Calculating: at this state is where the new configuration of the network is being calculated. Thisis the state where the core dimensioning algorithms will operate. If the calculation finishessuccessfully the next state will be the Storing Configuration state and followed by thePropagating Configuration state. Otherwise the next state will be the Error.

• Storing Configuration: the state during which the new configuration is being stored.

• Propagating Configuration: at this state the current configuration is enforced and disseminatedappropriately. The network has a valid new configuration when the system exits this state and theother functional components (SLS Management and Monitoring) have been informed about thisnew configuration.

• Error: this is an error state which we reach when either there has been a problem whencalculating the new configuration in the Calculating state or some error has occurred during thePropagation Configuration state. After the appropriate alarm has been sent we are transferred tothe Idle state.

Event-name Parameters Description

E.0 All initialisation tasks have been completed.

E.1 No messages arrive; the system has to stay in this state.

E.2 Request/notification

A new request / notification has arrived.

E.3 Constraints andpolicy directives

This event sets up constraints and policy directives and at thesame time transits the system to the appropriate state.

E.4 This event indicates that propagation of the configuration hasbeen requested.

E.5 This event indicates that the Dynamic Resource Managementwas unable to manage the current demand (trigger re-dimensioning).

E.6 This event indicates that the Dynamic Route Management wasunable to manage the current demand (trigger re-dimensioning).

E.7 This event indicates that a threshold crossing has happened(mostly received by Monitoring).

E.8 Resources This event indicates a change in the physical resources.

E.9 Topology This event indicates that the topology database was updated.

E.10 Forecast data This event indicates that the forecasted data has been received.

E.11 This event indicates that functions in calculation state werecompleted correctly.

E.12 This event indicates that functions in calculation state were notable to find a new configuration that satisfies the demand.

E.13 This event indicates that the new configuration has been storedsuccessfully.

E.14 This event indicates that the network was updated successfully.

E.15 This event indicates that the network was not updatedsuccessfully.

E.16 This event indicates that the network has sent alarms because anerror has happened.





State Transition Table

S0Init

S1Idle

S2Processing

S3Updating Topology

S4Getting Forecast

S5Calculating

S6Storing Config

S7Propagating Config

S8Error

E.0 [Initialisation done,S1]

E.1 [No event, S1]

E.2 [Newrequest/Notification,S2]

E.3 [SetPolicyDimFunct,S4/S1]

E.4 [PropagationRequest, S7]

E.5 [NotifyDynResMgmtUn,S4/S1]

E.6 [NotifyDynRouteMgmtUn,S4/S1]

E.7 [NotifyThresholdEvent,S4/S1]

E.8 [NotifyResAvail, S3]

E.9 [Topology Updated,S4]

E.10 [Forecast Got, S5]

E.11 [Calculation Done, S6]

E.12 [Calculation Infeasible,S8]

E.13 [ConfigurationStored, S7]

E.14 [Propagation Done, S1]

E.15 [Propagation Failed, S8]

E.16 [AlarmSent, S1]



5.2.2 Dynamic Resource Management

5.2.2.1 DescriptionDynamic Resource Management (DRsM) has distributed functionality, with an instance attached toeach router. In both MPLS and L3 approaches, it aims at ensuring that link capacity is appropriatelydistributed between the PHBs defined on a link by setting buffer and scheduling parameters associatedwith the interface the link is attached to, according to Network Dimensioning directives, constraintsand rules. Specifically, it gets estimates of the required resources for each PHB at each networkinterface, from Network Dimensioning. Further, it receives a certain margin on the requiredbandwidth. Within the limits of this margin, DRsM is allowed to dynamically manage the resourcereservations (i.e., the effective resources required to cope with e.g., unexpected SLS invocations).DRsM manages the resources according to its algorithm, which considers actual, experienced load ascompared to required (predicted) resources. Compared to Network Dimensioning, DRsM operates ona relatively short time-scale (order of minutes).

Through the activities of DRsM, the load-dependent metrics associated with links for routing purposes(in the IP-based TE approach) may change accordingly. This is in the case where the metrics on a link,do not reflect load (used capacity), but potential (free capacity) for specific PHB. Similarly, in theMPLS TE approach, DRsM issues appropriate updates on the state of the allocated resources for PHBto be utilised for routing purposes (cf. Dynamic Route Management component).

DRsM triggers Network Dimensioning when network/traffic conditions are such that its algorithms areno longer able to operate effectively, e.g. due to excessive high priority traffic, link partitioning iscausing lower priority/best effort traffic to be throttled. Specifically, DRsM issues over- or under-loadalarms to Network Dimensioning respectively if the higher margin is closely approached, or if theunder margin has been kept for a predetermined time. The issue of over-utilised alarms is for furtherthought.

5.2.2.1.1 Resources to be managed

This section elaborates on the resources to be managed by Dynamic Resource Management (Figure35).

There are two main resources that need to be allocated and therefore managed, for the router to handletraffic at the packet level: link bandwidth and buffer space. While controls are exercised in order toensure the proper allocation of these two resources, one should keep in mind a third resource thatenables the control process, namely processing power. The limited amount of the latter resource,dictates to avoid overly complicated control processes whose on-line operation would requireinordinate amount of time, hence defeating the purpose of timely resource allocation.

Link Bandwidth

Proper packet scheduling effects allocation of link bandwidth. As a result of Network Dimensioning,certain bandwidth is allocated to each PHB at the router. This bandwidth allocation is translated toproper scheduling parameters, which are then used to configure link schedulers.



It can be assumed that the scheduling parameters are in the form of minimum and maximum ratesassociated with the PHBs. These parameters are managed by DRsM dynamically, according to actualload conditions, so that to resolve conflicts for physical link bandwidth and avoid starving of somePHBs (where the starving levels are determined by the Network Dimensioning, based on predictedtraffic estimates and service provisioning policies). Another aspect of dynamic management relates tothe discussion of section 5.2.3.1.1. During the operation of the network, the Dynamic RouteManagement process may need to change the bandwidth of certain LSPs6 and/or NetworkDimensioning may create new LSPs. These changes imply a) the update of the bandwidth allocated tothe router PHBs and b) update to the policing parameters at the edge routers. Hence, if the LSP updaterequests are granted by Network Dimensioning, the necessary bandwidth modifications arecommunicated to DRsM, which translates bandwidth modifications to link scheduling parameters,which are then downloaded to the scheduler.

1HWZRUN�

0RQLWRULQJ

'\QDPLF�

%DQGZLGWK�

0DQDJHPHQW

'\QDPLF�5RXWLQJ

0DQDJHPHQW

/LQN�

6FKHGXOLQJ

'\QDPLF�5HVRXUFH�$OORFDWLRQ

'\QDPLF�

'\QDPLF�

%XIIHU�

%XIIHU�

0DQDJHPHQW0DQDJHPHQW

Figure 35: Dynamic Resource Management

Buffer Space

Buffers are used at the routers for the temporary storage of packets that contend for transmission onthe output links of a router. It is assumed, in the following, that the main packet buffering occurs at theoutput links of the routers. This assumption is valid for the routers that will be used by TEQUILA.Output buffering simplifies the scheduling process since only the packets that need to be transmittedon a given link need to be taken into account by the buffer management mechanism. In contrast, inputbuffering routers need to consider all the packets that must be transmitted from all the input to all theoutput links.

6 Although the term LSP is used here which implies an MPLS-based TE scheme this is equally applicable to thepure IP TE approach. In the IP approach adopted by TEQUILA the set of feasible routes between ingress/egresspairs for a particular traffic class is determined by Network Dimensioning and is known by Dynamic RouteManagement. Although the routes are not explicitly nailed-up in the routers, as in the MPLS case for LSPs, theystill exist as a logical overlay network known by the TE system. Therefore they can be used to determine theresources required by the potential routes which will map, finally, to a set of PHBs along a set of links.



Appropriate management of the buffer space may differentiate packet loss probabilities for the variousPHBs in the router. Also, they provide a bound on the largest delay that successfully transmittedpackets may incur. There is a large number of buffering schemes that are proposed in the literature.These schemes dictate how the buffer space is split between contending flows, when packets aredropped and whether new packets may replace already stored packets in the buffer. The bufferingschemes that will be used by the TEQUILA project will be restricted by the capabilities of the routers.It is assumed that a set of drop levels is associated with the buffer management mechanisms of therouters.

As a result of Network Dimensioning, the buffer management module of the DRsM component isupdated accordingly with buffer management parameters used to configure the buffer space anddetermine the rules for packet dropping in the routers (drop levels). The drop levels have beendetermined according to the QoS requirements (SLSs) of the traffic multiplexed in the buffer andestimates of the anticipated input rate (determined also by the network routing functions).

Therefore, the buffer management parameters (drop levels) need to be managed according to changesof the traffic mix of (determined by Network Dimensioning) and changes in the input rate. These areundertaken by the activities of the DRsM. For example, altering the bandwidth allocated to an LSPmay alter the bandwidth allocated to a corresponding PHB. If the loss probability for the PHB is toremain constant, then the buffer space allocated to the PHB may need to change. The dynamic buffermanager translates the required bandwidth modifications to appropriate buffer managementparameters that are used to configure the router buffer space.

5.2.2.2 Interface semanticsFigure 36 shows the interfaces between DRsM and the other functional blocks. The operationsinvoked over the interfaces are summarised in Table 1.

Node Monitor

NetworkDimensioning

Dynamic RouteManagement

PHBEnforcement

Dynamic ResourceManagement

1 2

3

4

7

5 6

Figure 36 Interfaces between Dynamic Resource Management and other functional blocks



From FB To FB Operation Parameters Comment

1 NetworkDimensioning

DynamicResourceManagement

SetResourcesConfig

(modify and deleteoperations alsosupported)

LinkId, PHBId,Buffering_Constraints,Scheduling_Constraints,Importance

This is the main mechanism bywhich Network Dimensioningconfigures DRM

2 DynamicResourceManagement

NetworkDimensioning

NotifyResMgtUn LinkId, PHBId,ProblemType

Sent when DRM is unable tosatisfy demands on all resources.This triggers a reconfiguration byNetwork Dimensioning.


Node Monitor SetMonitorConfig

(suspend, resume,modify and deleteoperations alsosupported)

ResourceId,MonitoringAlgorithm,ThresholdSpecification

DRM initiates, modifies andterminates monitoring activitiesthrough this operation. Dependingon the monitoring algorithm to bedeployed (e.g. ExponentiallyWeighted Moving Average or aforecast/trend analysis) someparameters which specific to thatalgorithm may be required.

4 Node Monitor DynamicResourceManagement

NotifyThreshold ResourceId,ThresholdId,MonitoredValue

Monitoring informs DRM whenmonitored values has crossedpredefined thresholds.

SetBufferParams


LinkId, PHBId,BufferId, Size,DropLevel


PHBEnforcement

SetSchedulerParams


LinkId, PHBId, Priority

These operations configure thebuffering and schedulingfunctions of the router. Theparameters are for further studyand are dependent on themechanisms in the routers as wellas the algorithms defined inDRM.

6 PHBEnforcement

DynamicResourceManagement

NotifyPHBState LinkId, PHBId,Statistics….

Network monitoring is only ableto report on load, and otherexternally measurable statistics.These notifications, directly fromPHB Enforcement, are on bufferand scheduler statistics from theinternal viewpoint of the router.E.g. on the occupancy of thebuffers for AFn.


DynamicRouteManagement

AdviseResourceAllocation

LinkId, PHBId,AllocatedResources,SharingMethod

These messages are required toinform Dynamic RouteManagement how much capacityis reserved per PHBs and howPHBs are shared on a link. Thisinformation is not available fromMonitoring and is necessary forDynamic Route Management tobe aware of the capacity availableper potential route.

Table 1 Interactions between Dynamic Resource Management and other functional blocks



5.2.3 Dynamic Route Management

5.2.3.1 DescriptionDynamic Route Management (DRtM) is responsible for managing the routing processes in thenetwork according to the guidelines produced by Network Dimensioning on routing traffics accordingto QoS requirements associated to such traffics (contracted SLSs).

In the MPLS approach (section 5.1.3.2) the component is mainly responsible for managing theparameters based on which the selection of one of the established LSPs is done in the network, to thepurpose of load balancing. To this end, it receives as input the set of explicit paths defined by NetworkDimensioning and relies on appropriate network state updates distributed by the Network ResourceManagement component. Further, the Dynamic Route Management component informs the NetworkDimensioning component on over-utilisation of the defined paths so that appropriate actions be taken(e.g. creation of new paths). In this approach, the functionality of the DRtM is distributed at thenetwork edges, or in the ingress points of the established LSPs.

In addition to LSP selection management, in the MPLS-based approach, the DRtM sets appropriatetraffic meters in order to ensure the proper flow of traffic in the established LSPs, according to thedefined LSP bandwidth and available capacity in the network as it is known from the updates from theNetwork Resource Management component. Note that as it has been discussed in section 5.1.3.1, thebandwidth to each LSP is not explicitly allocated. It is implicitly allocated through link schedulingparameters through which the LSPs are defined, while the means to ensure that the input traffic to theLSPs is according to its defined capacity is enforced through traffic meters.

In the IP-based approach, Dynamic Routing Management acts as a PDP towards resolving QoS-basedrouting (5.1.4.1) i.e. routing of traffic according to contracted SLS requirements. To this end, as SLSsare contracted it receives the appropriate QoS-information required for routing (in the form of routingconstraints) from Network Dimensioning and appropriately informs the routing processes in thenetwork (employing a PEP capability) e.g. to restrict the routing of specific traffic out of certaininterfaces. Note, that the QoS information maintained may change dynamically from the activities ofthe Network Resource Management component (see previous sections), as the configured service ratesassociated to each PHB may change.

5.2.3.1.1 Dynamic Route Management in MPLS-based TE

As traffic for a given source-destination pair enters the network, the source Label Edge Router (LER)routes the traffic through one of the available LSPs. The objective of routing at this level is todistribute the load on the available paths, in order to avoid overloading and congestion in parts of thenetwork. The appropriate parameters for load balancing have been downloaded and configured byNetwork Dimensioning (long-term TE, section 5.1.3.1). However, with the exception of static loadbalancing, e.g. in a fixed-weight round-robin fashion, this information alone does not suffice. In fact,even if the long-term predicted values remain unchanged, there will always be statistical variations ofnetwork traffic. Hence it may be preferable to implement load-balancing schemes that adapt to varyingnetwork conditions. However, highly dynamical schemes that try to continuously adapt to currentnetwork state may not be feasible or desirable due to the following reasons:

• Adaptation implies the existence of monitoring mechanisms that collect the network stateinformation. Collecting this information is expensive in terms of network resources and hence itcannot be done very frequently. Hence it cannot be assumed that network state information iscompletely up to date when decisions are made.

• Reacting to temporary changes to network conditions too fast and too often may lead toinstabilities and rapid fluctuation of link loads, resulting in unpredictable delays, excessive packetlosses and reduced system throughput.



Hence a semi-dynamic scheme is called for. In Figure 37 the basic operation of such a scheme isshown. Central to this scheme is the Dynamic Route Management module that adapts the routingselection parameters based on the information obtained from Network Monitoring7. Issues that need tobe resolved in the design of the module are the following.

• Type and location of the information and information request mechanisms

• The identification of the network parameters that are amenable to updating

Next we address these issues.

D y n a m ic R o u teM a n a g e m e n t

R o u t in g B a s e d o n P re d e te rm in e d P a r a m e te rs

I n fo R e q u e s t o r I n fo T r i g g e rI n fo T ra n s m is s io n

N e tw o rk M o n i to r in g

N e tw o rk D im e n s io n in g

A la rm T r i g g e r

N e w R o u t in gI n fo rm a tio n

S L S A d m is s io n C o n t ro l

T ra f f ic C o n d it io n in g /P o l ic in g

Figure 37: Dynamic Route Management.

Information Update Mechanisms

There are two basic mechanisms for information update, a) timer driven and b) event driven. In thetimer driven approach, the information is updated at regular intervals while in the event drivenapproach updates are triggered by specific events. With the timer driven approach the overhead due toinformation updates can be controlled by the choice of the update intervals. This is harder to achievewith the event driven approach, since the frequency of event occurrence is not known a priori, but onecould decide that updates will not be triggered before the reception of a given number of events,ideally correlated. This is the kind of suggestion which is made in [RFC-2676], as far as the pre-computation of the "QOS routes" I concerned. By doing so, the event driven approach remains aninteresting option (this is a somewhat mandatory option in the case of IP TE). However, the timerdriven approach may have late reaction to sudden large changes in network state. Hence a compromisebetween the two approaches seems appropriate: The timer driven approach is used as a basicmechanism for information update. At the same time, the system is designed to provide immediateupdates to a small number of critical events, which are expected to occur infrequently.

Regarding the location of information update mechanisms, the timer driven approach can beimplemented either at the Dynamic Route Management module or the Network Monitoring module.However, in order to reduce the load on the Network Monitoring module, the Dynamic Routemanagement seems more appropriate. The event driven mechanism, by its nature should beimplemented at the Network Monitoring Module.

7In this section, the Network Monitoring is used as a general means to obtain information from the network. Inother sections, where component functionality/interactions are described, the routing updates that are consideredare those received by the Network Resource Management component. They may be as well thought as deliveredthrough the capabilities of the Network Monitor component, as herein; but this is a system architecture issue.



Routing Parameters Amenable to Updating

The process of routing parameter update is shown in Figure 38. The routing parameters that need to beupdated depend on whether the network, from the point of view of the LER under consideration isunder

• Normal load operating conditions

• Medium load operating conditions

• Highly load operating conditions

Normal, medium and highly load conditions from the point of view of the LSR are defined accordingto the ability of the LSR to react to system load changes based respectively on

• The guidelines provided by long-term TE

• Adjustments and deviations from the guidelines provided by long-term TE

• Requests to long-term TE for new guidelines

%DQGZLGWK�$YDLODEOH

2Q�3UHGHWHUPLQHG� /63V

3RVVLEOH�8SGDWH

2I��)RUZDUGLQJ�

7DEOHV

<HV

%DQGZLGWK�$YDLODEOH

$IWHU�QHJRWLDWLRQ�ZLWK�

1HWZRUN�'LPHQVLRQLQJ

<HV

1R 1R

8SGDWH�RI

/63�%DQGZLGWK�

3RVVLEOH�QHZ�/63

&UHDWLRQ

7ULJJHU�:LGH � 6FDOH�/63

8SGDWH�3URFHVV�E\�

1HWZRUN�

'LPHQVLRQLQJ

1RUPDO�/RDG 0HGLXP�/RDG +LJK�/RDG

6HW�XS�RI�WUDIILF�PHWHUV

Figure 38: Dynamic Routing Process

Under normal load operating conditions the LSPs along with the bandwidth reserved for them aresufficient to route the traffic entering the LER. In this case, only the forwarding tables may be updatedwhenever it is deemed appropriate to modify the rules by which new traffic is entering the system, inorder to balance the network load. This depends on the LSP selection mechanisms in the routers.Furthermore, during normal load operation, traffic meters may need to be set to ensure that the trafficinjected to specific LSPs is according to their allocated bandwidth (by Network Dimensioning).

Under medium load operating conditions the LER cannot find enough bandwidth on the availableLSPs to accommodate new traffic requests. However, it can accommodate these requests by

• Requesting form Network Dimensioning to update the bandwidth of the available LSPs

• Requesting the formation of new LSPs from Network Dimensioning, and in case of positiveanswer, proceeding with the formation of such LSPs



This process implies that there are algorithms in place in the Network Dimensioning module to adjustthe bandwidth allocated to already existing, or provide the bandwidth needed by newly created LSPs.This bandwidth is of course taken from the pool of unreserved bandwidth and is available for theneeds of all the LERs. Hence, an important issue in this respect, besides the load balancing objective,is the fair allocation of the available network bandwidth.

Under high load conditions, no new routes can be found by adjustments of the current allocation. Inthis case, the Network Dimensioning component initiates the process of wide-scale LSP update. As aresult, LSPs belonging to source-destination pairs other than that which invokes the update may beaffected.

5.2.3.2 Interface semanticsFigure 39 shows the interfaces between DRtM and the other functional blocks. The operations invokedover the interfaces are summarised in Table 2.

7UDIILF�0HWHULQJ

1HWZRUN

'LPHQVLRQLQJ

'\QDPLF�5HVRXUFH

0DQDJHPHQW

5RXWLQJ

'\QDPLF�5RXWH

0DQDJHPHQW

�

�

�

�

�

Figure 39 - Interfaces between Dynamic Route Management and other functional blocks



From FB To FB Operation Parameters Comment

1 NetworkDimensioning


LSPs and QoS routinginfo


LSP topology, traffictrunks, bandwidth

RouteIds, traffic trunks,LSPs, selectionparameters

This is the main mechanism bywhich Network Dimensioningconfigures DRtM

2 DynamicRouteManagement

NetworkDimensioning

NotifyResMgtOn RouteId, ProblemType Sent when DRtM sees all LSPstend heavily utilised. This triggersa reconfiguration by NetworkDimensioning.



AdviseResourceAllocation

LinkId, PHBId,AllocatedResources,SharingMethod

These messages are required toinform Dynamic RouteManagement how much capacityis reserved per PHBs and howPHBs are shared on a link. Thisinformation is not available fromMonitoring and is necessary forDynamic Route Management tobe aware of the capacity availableper potential route.


Routing Update Parameters

QoS routing info

LSPId, selectionparameters

Admissible interfacesfor traffic types perDCSP

To manage appropriately therouting processes in the routers.


TrafficMetering

SetTrafficMeters Interface,FlowIdentification, rate-limit, ExcessActions

These operations are for enforcingLSP bandwidth, in the sense ofensuring that the input traffic willnot exceed allocated LSPbandwidth.

Table 2: Interactions between Dynamic Route Management and other functional blocks



5.3 Message Sequence Charts

5.3.1 MPLS-based TEIn this section the MSCs are presented of the MPLS-based TE approach. To reduce clutter and for easeof presentation, two MSC charts are presented. The first MSC shows the message sequences foroperations implementing the updates indicated by the Network Dimensioning Component. The secondMSC describes the message sequences that trigger the Network Dimensioning component to proceed(if needed) with updates from the Dynamic Route and Resource Management components.

7UDIILF

&RQGLWLRQLQJ

6/6�0DQDJHPHQW

�VXEVFULSWLRQ��

DGPLVVLRQ�FRQWURO�

'\QDPLF�5RXWH�

0DQDJHPHQW

1HWZRUN

'LPHQVLRQLQJ

6FKHGXOLQJ

)RUZDUGLQJ

03/6�7(� ± 3DUDPHWHU�8SGDWHV

7UDIILF�PDWUL[

7UDIILF

)RUHFDVW�

5RXWLQJ

'\QDPLF�5HVRXUFH�

0DQDJHPHQW

0RQLWRULQJ

/63�EDQGZLGWK��

OLQN�EDQGZLGWK��EXIIHU�

VKDULQJ�FRQVWUDLQWV

(5 �/63V ��WUDIILF�WUXQNV�

6SOLWWLQJ�UDWLRV�

5RXWH�FRQVWUDLQWV

6/6�DGPLVVLRQ�

SDUDPHWHUV

(5

�

/63V

�

6SOLWWLQJ�UDWLRV

6FKHGXOLQJ��GURS�OHYHO�

SDUDPHWHUV

3ROLFLQJ�SDUDPHWHUV

SHU�WUDIILF�WUXQN

6/6V

5HTXHVW�XSGDWH�RI� /63V



5RXWH�FRQVWUDLQWV

(5

�

/63V

�

6SOLWWLQJ�UDWLRV

6/6�DGPLVVLRQ�

SDUDPHWHUV





SDUDPHWHUV



1HWZRUN�RYHU �ORDG





SDUDPHWHUV



5RXWH�FRQVWUDLQWV

(5

�

/63V

�

6SOLWWLQJ�UDWLRV

6/6�DGPLVVLRQ�

SDUDPHWHUV



Figure 40: MPLS Traffic Engineering Parameter Updates

Referring to Figure 40, the top chart describes the message sequences occurring when the systeminitialised. In this case,

• Traffic Forecast prepares the Traffic matrix based on collected statistics and the contracted SLSs

• Network Dimensioning computes LSPs, LSP bandwidths, LSP load balancing parameters, andScheduling parameters. The results are downloaded to Dynamic Route Management and DynamicResource Management components.

• Network Dimensioning downloads the SLS admission parameters to SLS Management component

• Dynamic Route Management configures the routing tables appropriately

• Dynamic Resource Management configures link and buffer scheduling mechanisms appropriately.

The middle and bottom parts of Figure 40 refer respectively to the cases where Dynamic RouteManagement or Dynamic Resource Management components require updates to the downloadedparameters. The message sequences are the same as the top part, with the exception that the NetworkDimensioning component performs its calculations based on the current network state and currentnetwork traffic statistics/requirements.



7UDIILF

&RQGLWLRQLQJ6/6�$GPLVVLRQ�&RQWURO

'\QDPLF�5RXWH�

0DQDJHPHQW

1HWZRUN

'LPHQVLRQLQJ

6FKHGXOLQJ

)RUZDUGLQJ

03/6�7(� ± 7ULJJHULQJ�RI�8SGDWHV

5RXWLQJ

'\QDPLF�5HVRXUFH�

0DQDJHPHQW0RQLWRULQJ

0HDVXUHPHQWV�DODUPV

6SOLWWLQJ�UDWLRV


5HTXHVW�XSGDWH�RI�6/6�

DGPLVVLRQ�SDUDPHWHUV

�

6SOLWWLQJ�UDWLRV


0HDVXUHPHQWV�DODUPV


SDUDPHWHUV



1HWZRUN�RYHU �ORDG



Figure 41: MPLS Traffic Engineering Triggering of Updates

In Figure 41, the top and middle charts indicate that the request to update LSPs issued by DynamicRoute Management may be triggered by alarms/measurements from the Dynamic ResourceManagement component or by request to update SLS admission parameters. The bottom chart inFigure 41 indicates that request for updates issued by Dynamic Resource Management are triggered byalarms from the Monitoring component.

5.3.2 Link Failure HandlingIn this section we need to make some assumptions on how the link failures will be detected andhandled. The text below assumes that the TEQUILA network has MPLS TE capabilities.

There are several techniques for coping with link failures in MPLS networks. Each one of them has itsown benefits. It might be necessary to support a mixture of these techniques to be able to support theresilience needs of the different services supported by the TEQUILA system.

5.3.2.1 Link failure detection and handlingIn the structure of the TEQUILA system, there are three sources that can possibly offer information onthe operative state of network element links. The first element that can be able to detect a link failureis of course the network element itself. The support of direct (or physical) detection is link layerdependent e.g. it is supported on ATM but not necessarily on Ethernet. If link failure is directlysupported then it will without doubt be the fastest way. Another solution to detect the error, is todepend on the routing protocol (in the case of TEQUILA, this will come down to the hello-messagesof the OSPF protocol or its equivalent in IS-IS).

The methods above are directly linked to the network element. Both the direct and indirect detectioncan be given an abstract, generic interface towards the upper layers by setting the operational interfacestatus in MIB-II or by specifying a proprietary trap/event. A third source of information about linkfailures in the TEQUILA system is the monitoring subsystem. In contrast to the previous methods, thiscould be implemented independent of the network elements. If the monitoring is performed on aregular basis, the active measurement (which inserts a test-stream into the TEQUILA system) will beable to detect the failure. A further functional description on this will be given in a separate section.



Once the failure is detected, it can be handled in a number of ways: protection switching, restorationor hybrid techniques. In this document we will not elaborate on hybrid solutions. Each of thesemethods has its own recovery time and has its own impact on the required system resources(bandwidth, processor power, routing entries, NHLFE/LIB space, etc.). The selection of the methodshould preferably not be made a part of the SLS because the user is not interested in the method, butrather the result. The following section will give possible extensions to the SLS specification and theimpact on the TEQUILA system.

5.3.2.2 Suggested SLS Extensions and Impact on TEQUILA SystemA differentiation between the services in terms of link failure handling can be inserted in the SLSspecification by adding extra parameters. These parameters do not need to be an explicit part of anSLS-negotiation, but could also be implicitly defined by the service definition. For example premiumservices are always recovered by protection switching.

Below are possible extensions for the SLS specification can be used to have better control over theway failure handling is done in the Tequila system.

Link failure handling:

• SLS in case of failure = [SLS-entry]

• Recovery probability

• Max. recovery time

It is possible that the customer does not want (to pay for) a full service in case of a failure situation. Inorder to make this possible a second SLS is necessary. This SLS specifies the service the customerwants in case of a failure. If we cannot cope with every SLS in every possible failure scenario (verylikely) we need to determine which SLS gets restored and which not. What the customer wants toknow is with which probability his SLS gets restored. The maximum recovery time can be a veryimportant parameter, and will be defined in a contractual fashion between the customer and the serviceprovider, as far as the corresponding commitment is concerned. Real-time services need a quickrecovery. Other services might have less stringent requirements on the recovery time.

Remark that there is a complex interaction between recovery probability and recovery type (protectionswitching or restoration). Protection switching with resource reservation typically gives a better chance of recovery because the resources are allocated in advance. Most of the time restoration will find anew path but the necessary resources might not be available on this path. If we do not considersituations with more than one link failure then this means that protection switching always succeeds ifthe failing link is protected.

Note that none of the above extensions are mandatory. The system can be configured with a defaultfailure handling technique. There can be one default or “best-effort” technique for the whole system orthere can be one default technique per service class.

A remark that should be made here is that a resource usage policy should take into account both theavailability of backup paths and non-starvation of BE-traffic. A possible schematic link-usage schemeis given in Figure 42.

Figure 42: Link usage policy

Reserved for BE(non-starvation principle)

Reservedfor

Sharedbetween BE andbackup



5.3.2.3 Message Sequence Chart: Protection switchingThere are two scenarios given below: protection switching and restoration. We assume that thedetection of link failures is being done by the monitoring subsystem, but extensions to the othermethods should be obvious.

After the monitoring subsystem has detected the failure, the protecting backup path is activated. In anMPLS-driven traffic-engineering scheme, this will be a decision made by the dynamic routemanagement, which will inform the PSL (protection switch LSR, the LSR that does the switch over tothe backup LSP). Then network dimensioning should be notified of the change of the network status(due to a change in the paths and resource allocations). If it is necessary (e.g. certain thresholds gotcrossed), the management should also be notified.

In addition to that, certain actions might be necessary to handle the behaviour after the link connectionhas been restored. Again, there are several options:

• Revertive mode: the connection can be re-routed along its original path (maybe not the best optionif you have a VLL-service, because of the additional disruption).

• Non-revertive mode: the traffic is not re-routed, the restored path can be used as a backup path.

Failure Detected

Configuration Changed

NetworkDimensioning

DynamicManagement

Monitoring

Activate Backup Path

Figure 43: Protection Switching MSC

5.3.2.4 Message Sequence Chart: Restoration(SLS)Management

Failure Detected

ConfigurationChanged

Network StatusChanged

NetworkDimensioning

DynamicManagement

Monitoring

No Path Found

Calculate new path

Renew Network Status

No Path Found

Network StatusChanged

Renew NetworkStatus

OR

SLSFailed



Figure 44: Restoration MSC

The basic contrast with a protecting scheme, lies in the fact that we need to tear-down the broken path,recalculate the new path and set it up. Depending on the underlying technology this can be a localoperation (only a few LSRs are affected) or a global (every LSR on the LSP is affected).

This MSC is analogous to the previous case. If the “backup path” SLS has been negotiated like anyother SLS then the restoration probability can be as high as in the case protection switching case. Toelaborate on this, the restoration will, generally speaking, be able to find a new route more easily(because it takes into account all the available paths during its calculations), but will have moretrouble finding the necessary resources on these paths (because nothing has been reserved). Theselection of which traffic is allowed on the new path and which is denied should depend on the agreedSLS (e.g. the recovery probability above). If the restoration fails, the management should be notified.This notification can than be used by the management system operator to contact the customer.



5.4 Inter-domain Traffic Engineering

5.4.1 Problem DescriptionThis section describes the process of providing end-to-end quality in the TEQUILA system. TheTEQUILA system (Figure 45) consists of a set of interconnected autonomous systems (ASs). Thegrey squares on Figure 45 are BGP nodes.

G H V W

6 / 6

% %

$ 6 �

$ 6 �

$ 6 �

$ 6 �

$ 6 �

% %

% %

% %

% %

6 WH S �� 6 WH S ��

6 WH S ��

6 WH S �� 6 WH S ��

6 WH S ��

6 WH S ��

6 WH S ��

6 WH S ��

Figure 45: The TEQUILA system

In the following, the term Bandwidth Broker (BB) is used to denote the required functionality in anAS to undertake the required actions and interactions with neighbouring ASs for handling SLSrequests and configuring the network to support them. The functionality of the BB is realised througha number of components in the TEQUILA Functional Model belonging to the SLS Management andTE groups of functional blocks. In particular, BB functionality overlaps with SLS Subscription, SLSAdmission Control, Inter-domain SLS Requestor, Network Dimensioning, Dynamic ResourceManagement and Dynamic Route Management (cf. chapter 3). However, for the sake of simplicity, inthis section we use the term BB for better outlining inter-domain issues and solutions, rather thandetailing the interactions at the level of individual components.

Assume that the BB in AS1 receives a SLS: the transfer of traffic to a certain destination dest should begiven a certain “quality” (in term of delay, bandwidth etc.).

The first action to be taken is to determine the correct path to the destination, capable of satisfying therequirements in the SLS. Identifying the correct path to the destination automatically identifies theneighbour BB. Once this neighbour BB is determined, BB to BB negotiation aims at reservingcapacity between ASs.

Imagine that, based on considerations that will be explained later on in this document, inter-domainpath AS1-AS2-AS4-AS5 to destination dest is identified (step 1 on Figure 45).

Each AS may have different capability in term of QoS. Assume that, thanks to measurements, eachBB in each AS has a correct idea of the current QoS capability of the AS to which it attaches. It is thuscapable to run a decision process in order to accept or reject the SLS.



BB to BB negotiation (step 2 on Figure 45) will thus try to reserve capacity between the ASs. If thisnegotiation fails, no capacity will be reserved and the SLS will be rejected. On the contrary, if itsucceeds, a certain capacity will be reserved between AS1 and its neighbour AS2 (step 2 on Figure 45).Then, the whole process of identifying the correct QoS path between the neighbour AS and thedestination, negotiating and reserving capacity between the neighbour AS and one of its neighbourshas to be done. In step 4, BB to BB negotiation between AS2 and AS4 results in capacity reservationbetween the two ASs.

Remark: At the intra-domain level, once step 2 is finished, the intra-domain path should be determinedand capacity should be reserved between the ingress pointy and the egress point in AS1: this isrepresented by the orange pipe of step 3 in Figure 45.

The whole process, from the arrival of the SLS, to the establishment of an end-to-end QoS path (withthe reservation of capacity at the intra- and inter-domain level), can be summarised as follows:

• Step 0: Arrival of a SLS with QoS requirements.

• Step 1: BGP determines an end-to-end path, that will a-priori be able to fit the QoS requirementslisted in the SLS. The determination of this path automatically identifies the neighbour BB.

• Step 2: BB to BB negotiation may potentially result in the reservation of some capacity betweenthe two neighbouring ASs.

• If this negotiation fails, another path has to be determined (if such a path exists) – back to step 1.Remark: This implicitly assumes that BGP is capable of determining several paths to the samedestination, which is far from obvious and not supported by current implementations of BGP.

• Step 3: This is purely intra-domain. The IGP determines the intra-domain path between the ingressand the egress nodes in the AS. Capacity may be reserved, at the intra-domain level, to ensure theQoS transfer of traffic through the domain. Intra-domain TE solutions, such as OMP, may alsooptimise the usage of the capacity. Refer to the paragraph “intra-domain routing” for moreinformation.

• Back to step 1: the BB in the neighbour AS handles the whole process: BGP determines the pathto the destination that is capable, a priori, to fulfil the QoS requirements in the SLS. This path isonly the subsection of the path determined in step 1 above. Capacity is reserved between theneighbour AS and the next AS in the path.

If one of these steps fails, no end-to-end capacity is reserved.

We then come to the situation where a certain end-to-end capacity is reserved. The availablebandwidth in each of these QoS pipes will vary. At a certain moment, the available bandwidth couldbe so small that no new SLS could be accepted anymore. Several actions are then possible:

• Negotiate an increase of bandwidth for this QoS pipe. Since it doesn’t require the establishment ofa new or alternative pipe, the traffic is not stopped. But this increase of allocated bandwidth willnot always be possible.

• Establish a second pipe, between the same ingress-egress nodes, but via an alternative path, withthe required additive bandwidth, and keep the “old” pipe up. The new pipe could be used to handlethe new SLS. The old flows are not stopped.

• Establish a totally new QoS pipe for the same class of service, between the same ingress-egresspair, but via a different path (different inter-domain nodes and/or different ASs). This pipe mustaccept the total traffic (the “old” traffic that was already transported within the QoS pipe, and thenew required one). This is the worst solution, since the flows are broken. For some applications, itis totally unacceptable.



The implementation of the two last solutions requires that several paths between the same ingress-egress pair exist and be discovered/calculated. The first solution is the simplest one and requires onlyone path to be established, but since the bandwidth is limited anyway, we may be forced at a certainmoment, to opt for the second or third solution. The second solution should be preferred to the thirdone, because no flows are interrupted.

The rest of the document is organised as follows: paragraphs 5.4.2 and 5.4.3 briefly explain why, inthe context of end-to-end QoS, BGP should be extended. Paragraphs 5.4.4 and 5.4.5 present twodifferent models: the first one uses additional TE parameters (load, bandwidth), while in the secondone QoS paths are determined based solely on the “raw” capability of the Tequila system. Paragraph5.4.6 compares current BGP (single-path BGP) and Multi-path BGP.

5.4.2 Current BGP and inter-domain TE

5.4.2.1 IntroductionThe Internet consists of a collection of “independent” ASs managed autonomously by ISPs. BGPallows selecting the “best” path to each destination across these systems. The IP traffic traversesseveral ASs toward the destination. The choice of which AS to select is based purely on a localdecision: the number of ASs to reach a destination, or local weights and preferences.

The ISPs filter traffic from each other. This in itself creates a non-optimal routing. Constraint basedrouting ads another lever of traffic influence by defining the path that a packet should take. It does thisvery well within an AS, until the packet leaves the AS to the next AS.

The BGP Multi-Exit Discriminator (MED) provides a kind of inter-domain routing metric, but it islimited to the adjacent domain (see remark hereafter).

Remark: The Multi-Exit Discriminator (MED) attribute may be used by a BGP speaker’s decisionprocess to discriminate among multiple exit points to a neighbouring AS. A lower MED value ispreferred over a higher value. The MED attribute is exchanged between ASs, but a MED attribute thatcomes into an AS does not leave the AS. When an update enters the AS with a certain MED value, thatvalue is used for decision within the AS. When BGP sends an update to another AS, the MED is resetto 0.

5.4.2.2 Basic traffic engineering capabilities of BGP-4The BGP-4 protocol has been designed for conveying network reachability information betweendomains. The protocol is based upon the use of a path-vector algorithm, whereas the reachabilityinformation is described by using attributes which aim at qualifying the route, in terms of number ofautonomous systems the route advertisement has crossed, the local preference which can be expressedby a BGP peer (to its internal peers) to reach a given destination located outside of the domain, etc.

From this standpoint, most of the existing BGP implementations allow to enforce a BGP routingpolicy based upon a possible alteration of these attributes. For example:

• A network operator can modify the value of the AS_PATH attribute, so as to make the BGPdecision process select a route rather than another (thus allowing service providers within analliance to systematically avoid domains of their competitors);

• A network operator can also influence the choice of an exit point to reach a neighbouringautonomous system, by using the MULTI_EXIT_DISC attribute;

• The use of the COMMUNITIES attribute ([RFC-1998], [NUSSBACHER99]) allows a networkoperator to enforce a specific routing policy for a set of destination prefixes (e.g. EF-marked IPdatagrams destined to a set of IP VPN customers MUST use a given sequence of autonomoussystems);

• Etc.



As far as the TEQUILA system is concerned, the enforcement of such basic routing rules is generallyperformed by means of manual configuration, which could be automated thanks to the use of theabove-mentioned “routing” client-type, according to the following Figure 46:

Figure 46: Automated enforcement of a BGP4 routing policy -

Comments related to Figure 46:

• The IRR (Internet Route Registry, [IRR]) is a route database which can be accessed directly byeach router of a given domain, thanks to the establishment of the appropriate BGP peeringrelationship. Storage of the routing information within the database is based upon the use of theRPSL (Routing Policy Specification Language, [RFC-2622]) language semantics, which allows todepict a complete routing policy (thanks to the value assignment of the above-mentionedattributes). This figure assumes the use of a PEP/PDP relationship to retrieve the appropriaterouting policy information from the IRR, thus allowing a complete consistency between theinformation which is stored in the IRR and the routing information which is exchanged betweenBGP peers of a routing domain;

• Upon receipt of an UPDATE message, a BGP peer will notify the IRR (by means of theappropriate REQ/RPT messages between the PEP and the PDP), so that it might make the routeselection decision accordingly.

From this perspective, a certain degree of automation can be reached when considering the dynamicenforcement of some basic BGP-4 rules, which aim at reflecting a service provider’s policy.

5.4.2.3 Processing QOS-related informationThe architecture which has been described in the above figure can be extended for conveying QOS-related information to BGP peers, thus allowing a potential enhancement of the BGP4 selectionprocess. Indeed, by making a bandwidth broker facility exchange information with an IRR facility, theresulting information could influence the value of some specific BGP-4 attributes. For example:

• Bandwidth considerations about the links which interconnect a pair of eBGP peers will influencethe value of the MULTI_EXIT_DISC attribute (which, by the way, appears to be a fully qualifiedmetric), thus yielding the choice of STM-1 links over 64 kbit/s leased lines;

IRR

Dynamic route management blockPDP

PEP

IP router



• DSCP marking can also be conveyed within the use of the COMMUNITIES attribute, asmentioned in the previous section8.

5.4.2.4 Conveying TE-related informationIf the above sections have attempted to describe how a BGP-4 routing policy could be enforced byrouters of a given domain, thanks to the use of QOS-related information to be provided by thedynamic resource/route management modules of the TEQUILA system, the enforcement of a globalinter-AS traffic engineering policy is a matter of:

• Bilateral (or multi-lateral) agreements between service providers (possibly leading to anautomated exchange of information between IRR building blocks, according to figure 2 of thisdocument);

• Conveying TE-related information between domains.

From the latter perspective, it has been proposed to use an additional attribute, the QOS_NLRIattribute ([JACQUENET00]), which will help the BGP peers in taking into consideration (i.e. possiblyinfluence the BGP decision process) the specific QOS requests which have been expressed by meansof SLS.

The QOS-related information conveyed in the SLS has been processed by the dynamic resource/routemanagement modules, so that the TE-related information to be conveyed between autonomoussystems might reflect these requirements, in terms of DSCP marking or bandwidth reservation, forexample.

(to be completed).

5.4.2.5 Load sharing capabilityThere is no intrinsic load sharing capability which is provided by the BGP-4 protocol, but the use ofspecific attributes (such as the COMMUNITIES or the MULTI_EXIT_DISCR) could possibly help individing the processing of traffic (on a per-destination basis) among different paths.

There is also one vendor whose routers support a load sharing capability between parallel links whichare established between two eBGP peers.

5.4.3 TE Extensions of BGP

As explained in paragraph 5.4.1, BGP has to determine end-to-end paths able to fulfil, a priori, someQoS requirements.

Current TE models are generally based on IGP protocols and not on BGP: the view of the Internet islimited to one AS and QoS is not provided at the global level. This is not sufficient in the context ofTequila where the aim is to provide end-to-end quality of service. In that sense, BGP must be stronglyextended: the complete view of the Tequila Domain must be taken as input for the QoS routecalculation.

To achieve this aim, several models, requiring very small or very important modifications (extensions)of BGP are currently under development. We can distinguish basically between two ideas:

8 This is what some vendor calls “Quality of service Policy Propagation by BGP-4”…



• “QoS parameters” model: BGP nodes exchange not only topology information, as in standardBGP, but also QoS parameters (delay, load, available bandwidth, etc). All these parameters referto the complete Tequila System. Taking this QoS information as input, and using a modified routedecision process, BGP peers calculate end-to-end QoS paths, optimised for some (set of)parameters (paths minimising the end-to-end delay, paths optimising the bandwidth, pathsoptimising the bandwidth, and still providing the smallest possible delay, etc).

This is basically the idea in [JACQ] and [ABAR]. This model is further detailed in paragraph5.4.4.

• The “CoS capability” model is much simpler. BGP nodes only transport the QoS capabilitiessupported by the ASs in a path vector (associated with a certain route). Path establishment(selecting the route and as such the next hop AS) would then be subject to QoS capability,topology and again policy decisions. Resource establishment along the route would be solely thetask of the BB.

This model puts a clear separation between the BB functionality and BGP: BGP calculates paths,given a very limited set of information, and BB brokers decide if the QoS requirements may besatisfied. This model is further detailed in paragraph 5.4.5.

5.4.4 Model 1: “QOS parameters” model

%%

GHV W

%% %%

%%

$ 6 �

$6 �

$6 �

$6 �

$ 6 �

%%

' HOD \ ��/RDG �

$ Y��% DQGZ LG WK �

%%

' H OD \��/R DG �

$ Y��%DQGZ LG WK �

' H OD \ ��/RDG �


' H OD \ ��/RDG �


' H OD \ ��/RDG �

$ Y��%DQGZ LG WK �

/RZ HV W�GH OD \

+ LJ KHV W�D YD LOD E OH �E DQGZ LG WK

Figure 47: “QoS parameters” model

BGP is extended for conveying QoS-related information (load, delay, available bandwidth, etc) thusallowing a potential enhancement of the BGP route selection process. In Figure 47, BGP nodes run amodified route decision process that takes these additional parameters into account. This may result indifferent paths toward “dest”, depending on the parameter: a route may be optimised for the delay,while another route may optimise the available bandwidth.

If a SLS comes in AS1, the acceptance or rejection of the SLS comes from a simple comparisonbetween the characteristics of the paths and the requirements in the SLS.

This is the idea presented both in [JACQ] and [ABAR]. [JACQ] aims at specifying a new BGP-4attribute, the QoS-NLRI attribute, which will convey QoS information associated to the routesdescribed in the NLRI field of a BGP UPDATE message. [ABAR] proposes to use the BGP protocolto choose the best BGP routes based on TE constraint weights.

These two documents identify the additional parameters and propose new formats of the BGPUPDATE message. A modified route decision process, using these additional TE parameters,calculates TE routes (routes able to fulfil some TE requirements). These additional TE parameterscould even take precedence over the standard BGP weights.



5.4.4.1 draft-abarbanel-idr-bgp4-te-01 [ABAR]The idea here is to consider the global Internet as a collection of interconnected ASs, where each AS isrepresented by a set of summary weights based on a given traffic engineering criterion. The weightscould be:

• Maximum bandwidth available for a certain class of service

• Maximum number of hops

• Maximum transit delay to cross the domain

• Colour

• Other

The method used to propagate constraint summarisation weights for each AS is to define a new BGPattribute that contains QoS sub-fields.

The BGP route selection process is extended to support a TE way of prioritising the best routes for anydestination. The order of preference of the routes can be changed to give the TE weight attribute ahigher priority than other attributes.

These criteria levels are summarised by the IGP (OSPF or ISIS) and exported to BGP.

5.4.4.2 draft-jacquenet-QoS-nlri-00 [JACQ]The purpose of this draft consists in proposing an additional BGP attribute, named the QoS-NLRI,which aims at providing QoS-related information related to the NLRI information conveyed in a BGPupdate message.

The QoS-NLRI attribute is an optional transitive attribute, which can be use:

• To advertise a QoS route to a peer

• To provide some QoS information along with the NLRI in a single BGP UPDATE message.

The QoS-NLRI attribute contains a code field, a sub-code field and a value field (Figure 48):

4R6�LQIRUPDWLRQ�FRGH

4R6�LQIRUPDWLRQ�VXEFRGH

4R6�LQIRUPDWLRQ�YDOXH

4R6�LQIRUPDWLRQ�YDOXH

1HWZRUN�DGGUHVV�RI�QH[W�KRS

1HWZRUN�OD\HU�UHDFKDELOLW\�LQIRUPDWLRQ

Figure 48: QoS-NLRI attribute

The QoS code could be:

• 0: reserved

• 1: bandwidth

• 2: delay

• 3: jitter

• 4: DSCP



The QoS sub-code could be:

• 0: none

• 1: reserved bandwidth

• 2: available bandwidth

• 3: minimum transit delay

• 4: maximum transit delay

• 5: average transit delay

• 6: AF type

Only some combinations of code and subcode values are possible (the grey combinations in Figure49).

0 1 2 3 4 5 6

0

1

2

3

4

code

Subc

ode

Figure 49: code and sub-code combinations

5.4.4.3 Additional TE Weights

5.4.4.3.1 Which TE weights?

TE weights may be measured per CoS or for all the classes of services.

It is also very important to decide what to measure:

• Bandwidth: Maximal, minimal, average, current available bandwidth for all the Classes of service,Maximal, minimal, average, current available bandwidth per class of service…

• Delay: maximal, minimal, average, smooth delay to cross the domain, or per ingress/egress pair(per pair of BGP peers)…

• …

As explained in paragraph 5.4.4.2, draft-jacquenet-QoS-nlri-00 provides a very complete and efficientanswer to this problem, which makes use of QoS code and subcode combination.

5.4.4.3.2 The role of the IGP

At the IGP level, each ASBR can determine the TE weight to reach a destination network in its owndomain by looking in a “TE database” and performing a calculation. This calculation can be a realDijkstra if the weight is additive (e.g. the delay) or a Dijkstra-like calculation if the weight is exclusive(e.g. the bandwidth).



For each TE weight type: each ABR summarises the cost to each destination network in its area, andflood it for advertisement to the other attached areas. The ASBRs can then in turn calculate the TEweights for each destination network. These calculations result in a value for each TE Weight for eachdestination network in the AS and for each ASBR across the AS. The weights from the IGP are thenexported into BGP for propagation to its EBGP peers.

BGP should take special care of the homogeneity of the metrics otherwise the route calculation won’tbe consistent: different IGPs may calculate different values for the same parameter.

Another approach would be to define new IGP TE metrics per link. Each type of TE metric would berepresentative of a requirement: a metric would represent the delay on a link, another metric wouldrepresent the available bandwidth on the link (the lower the metric, the more bandwidth it has). TheseTE metrics would only be used for the calculation of the TE weights exported by the IGP to BGP, andnot during the IGP route calculation itself. In that way, we avoid the risk of oscillations.

The TE metric should be exchanged within the domain. If OSPF is the IGP, a new type of OpaqueLSA must be created.

5.4.4.3.3 Level of aggregation

The network of Figure 50 consists of three interconnected ASs. Intra-domain connectivity is onlyshown in AS1.

$6�

$6�

$6�

Figure 50: level of aggregation (1)

Depending on the level of aggregation we want to support, the network TE capability can besummarised in two ways (Figure 51).

On the left side of Figure 51, each domain is represented as a set of interconnected BGP nodes.Dashed lines between BGP peers represent this connectivity: it is the aggregation of a set of intra-domain links. It just means that there is some connectivity between the two BGP peers, but it does notrepresent as such an existing link. This “connectivity” is found by the intra-domain routing protocol.In the case of OSPF, the “connectivity” may be the best path between two ASBRs, or the aggregationof the Equal-cost paths between two ASBRs, or the aggregation of the set of possible paths ascalculated by OMP (Figure 52).

In this model, a set of TE weights is associated with each interconnection. This is an intermediate levelof aggregation, since a dashed line may represent the aggregation of several inter-domain links. Delayfor example represents the delay between two BGP peers, and may be different if we consider anotherpair of BGP nodes.

On the right side of Figure 51, each domain is represented as a node. A set of metrics are attached tothis node. This a very strong level of aggregation: delay for example is a “default” value, and remainsthe same, even if we consider different pairs of BGP nodes. It can be for example the maximum delayto cross the domain, or an average value to cross the domain.



The latest level of aggregation is the simplest. We have a limited set of “nodes” to consider (thenumber of ASs in the Tequila network). With each “node” is attached a number of TE weights. Butthis is a worst case solution since we can only consider “default” TE weights for an AS.

$6�

$6�

$6�$6�

$6�

$6�

'HOD\$Y�%DQGZLGWK&RORU«

'HOD\$Y�%DQGZLGWK&RORU«

/RZ�OHYHO�RI�DJJUHJDWLRQ +LJK�OHYHO�RI�DJJUHJDWLRQ


$6� $6�

&RQQHFWLYLW\� EHWZHHQ� WZR� %*3� SHHUV� UHVXOW� IURP� WKHDJJUHJDWLRQ�RI�D�VHW�RI�LQWUD�GRPDLQ�SDWKV�

DJJUHJDWLRQ


The first level of aggregation is more complex: we have more parameters:

• Number of parameters = number of ASs in the Tequila network * the number of “connections”within an AS * number of types of TE weights

• The number of connections within an AS may vary (full-mesh between BGP peers or use of routereflector for example).



But the first level of aggregation gives a more accurate view of the network capability in terms ofdelay, bandwidth, since we have a finer level of granularity.

5.4.4.3.4 Interpretation of the TE weights

A TE weight may have different meanings and interpretations, depending on the way it is measuredand on the model (low level of aggregation vs. high level of aggregation).

5.4.4.3.4.1 Dependency on the calculation

Even if the model is specified, a TE weight may have different interpretations, depending on the wayit is measured / calculated.

The value of a certain parameter between a pair of BGP peers may be:

• The worst-case value, between the pair of BGP pairs, through the domain.

• The best-case value, between the pair of BGP pairs, through the domain.

• A smooth value, depending on the current measurement and old value(s). Here again, it could be asmooth worst case or a smooth best case.

• Other…

Worst-case and best case should be excluded, because they do not really represent the transfercapability between the pair of BGP nodes. A smooth value, resulting from regression between thecurrent measurement and some previous values, may give better results and eliminates fastoscillations.

5.4.4.3.4.2 Dependency on the model

Delay is measured over the whole AS in the case of the most aggregated model while it is a per-pair ofBGP peers value in the case of the low-level aggregation model. Let us consider, for simplicity, thecase of delay.

Low-level of aggregation model

It is important to remember that, with the low-level of aggregation model, connectivity between twoBGP peers (a dashed line in Figure 51) may result from the aggregation of a set of intra-domain pathsbetween these two BGP nodes (Figure 52).

Delay also results from the aggregation of delay values on each path. If, on each path, delay ismeasured using a smooth algorithm (as explained in section 5.4.4.3.4.1), the last step is to aggregatethe set of delay measurement for each path, to a single value, representative of the transfer capabilityof this pair of BGP nodes. A possible solution here would be to take the average value.

G ��

G �� G ��

G ��

G �� G ��

G ��

3D WK ��

3D WK ��

$

%



�

∑

∑=

=

=

=

=

=

3

12,2

4

11,1

)(

)(

j

jjt

j

jjt

tdD

tdD

),(

),(

,2,21,2

,1,11,1

ttt

ttt

DSDfSD

DSDfSD

δ

δ

−

−

==

),()( ,2,12, ttBA SDSDftD =

G

M L

� �G H OD \ �R Q �OLQ N � M L�R I�S D WK � L

'

L

� W� � � 6 XP � R I � D OO� WK H � G H OD \ V � R Q

D OO� WK H � OLQ N V �R Q �S D WK � L� �D W � W LP H � � W

� UD Z �G H OD \ �R Q �S D WK � L� �D W� W LP H �W�

6 '

L

� W� � � 6P R R WK �' H OD \ � R Q � S D WK � L�

D W � W LP H �W �

'

$ �%

� W� � � $ J J UH J D WH G � G H OD \

E H WZ H HQ �$ �D Q G �% � �D W�W LP H �W

Figure 53: Calculations for delay aggregation

Delay calculation may be summarised (Figure 53).

At an ASBR, the IGP identifies the set of possible paths between each other ASBR. (There are twopaths between A and B).

Thanks to extensions of the IGP (Q-OSPF, exchange of Opaque LSAs), each ASBR can measure thecurrent value of the delay on each path to another ASBR (on path 1, delay is the sum of the delaysmeasured on each link and exchanged between routers via to Opaque LSAs).

It is better to take previous values into account: in this case f1 is a regression function. Smooth DelaySD on each path, at time t, is a function of the current raw measurement of the delay on the path, andof the previous value of the SD (at time t-δ).

We need a value of the delay per pair of BGP peers. A solution is to take the average values of all thesmooth values calculated in the previous step. At this point, for each pair of BGP peers, we have asingle value of the delay that reflects the delay between this pair of BGP peers, i.e. on the“connectivity” between these BGP peers (f2 is here an averaging function). The final situation is theone depicted on Figure 54, where each link between A and one of its BGP peer is characterised by anaggregated value of the Delay D.

$

%

&'

('

$�' '$�&

'$�(

'$�%

Figure 54: Aggregating delays

Important remark: Delay on a link may depend on the direction: DA,B may differ from delay DB,A.

High-level of aggregation model

With the high-level of aggregation model, delay represents the transfer capability of the whole domain(and not only the transfer capability between a pair of BGP nodes): only one value of the delay willrepresent the complete AS.

Here again, best-case and worst-case measurements should be excluded: we need a measurement thatbetter represents delay in the domain.

The final delay value for the whole domain results from a calculation made in several steps:

• Do the same calculation as in the “low-level of aggregation” model and extend it:

• At this point, we have a delay value for each pair of BGP peers. Then summarise all these valuesinto a single one, representative of the whole domain. Here again, we have several choices: takethe lowest one, the highest one, do an average on all the values, …



5.4.4.3.5 When to measure and to advertise TE weights?

Some parameters are subject to changes. This is the case for bandwidth for example. Frequentexchanges of TE weights give a correct view of the network, but consume more bandwidth andincrease the number of operations at a router. On the other hand, it is very important to give everynode a correct knowledge of the TE capability of the network. A compromise must be made betweenfrequent exchange of TE weights and bandwidth consumption.

5.4.4.4 Discussion

• Conceptually, the “QoS parameters” model presents a very simple idea to provide QoS at theInternet level, but requires a lot of changes and presents an important implementation complexity.

• It requires very important modifications of BGP. The BGP route selection process itself must bemodified: the additional TE parameters should be used as input, and could even take precedenceover the standard BGP weights. No real clue is given concerning the modifications of the BGProute decision process. No algorithm (pseudo-code for the implementation) is given. We onlyknow that the additional TE parameters can take precedence over the standard BGP weights.

• BGP must now convey QoS information. Here we can point some problems related to this model:

• Due to the size of the Internet, the distributed numbers may be totally outdated by the timethey are actually used for a routing decision. This would also very much increase theinformation to be transported by BGP.

• There is no incentive for anyone to try to load balance the entire internet, since the choice ofnext hop AS for certain traffic that is subject to service level guarantees will merely depend oncapability of support along the route, and cost, as negotiated with your peer.

• An ISP will not be very willing to actually distribute to all its neighbours how much sparecapacity it still has on its network, since this is pretty much highly valued competitiveinformation. So first ask if capacity is available for premium traffic, and yes or no will be theanswer, along with the price.

• Homogeneity. The TE weights are exported from the IGP to BGP (paragraph 5.4.4.3.2). DifferentASs may run different IGPs. Moreover, it has become common for a single AS to use severalIGPs. Metrics calculated by OSPF can be different from metrics calculated by ISIS, then resultingin incoherent route calculation. Special care should then be taken at the BGP level to ensure thehomogeneity of the TE metrics: BGP can provide the homogeneity that we need to make the routecalculation coherent. BGP must be aware of the IGP protocol that originates the metric.

• For the parameter calculation, there must be a choice between a low-level or high level ofaggregation model (paragraph 5.4.4.3.3 and 5.4.4.3.4).

5.4.4.5 ConclusionThere is no clear separation, in the “QoS parameters model”, between the BB functionality and BGP.BGP does some operations that are normally handled by the BB: BGP decides, based on the availableresources, whether the Tequila System is able to fulfil the QoS requirements listed in the SLS.

This model is very complex, because a lot of additional information must be exchanged between BGPnodes. But this is maybe not necessary, since resources are normally measured and managed by theBB.

Moreover, for the reasons explained in paragraph 5.4.4.4, we do not fully believe in exchange of QoSinformation. The problems are mainly related to the amount of information, to the problem ofmaintaining up-to-date information (given the size of the Internet), and to commercial andadministrative constraints.



Finally, there are a lot of open issues in [JACQ] and [ABAR]:

• What is the modified BGP route decision process. How is it implemented?

• How do we manage the complete process of calculating, maintaining, updating TE routes?

• When to measure and exchange the additional parameters?

• How do we achieve a scalable solution?

Due to all these remarks, and given the complexity and the importance of the modifications thatshould be made on BGP, we imagined another model, far simpler, but still providing a way tocalculate end-to-end QoS paths.

5.4.5 Model 2: “CoS capability” model

%%

G HVW

%% %%

%%

$ 6 �

$ 6 �

$6 �

$ 6 �

$ 6 �

%%

% ( ��()

% (

%( ��( )

% ( ��()

% ( ��( )

()

S D WK

%%

Figure 55: “CoS capability” model

This model requires very limited extensions: each domain advertises to its peer ASs what “types” oftraffic are supported (advertisement of a set of ToS bytes for example). BGP messages include an ASpath per value of the ToS byte (per type of traffic).

In Figure 55, BGP update messages from AS2 to AS1 contain no EF route toward “dest”, becauseAS2 does not support EF traffic. On the contrary, AS3 supports this type of traffic, and advertise thiscapability to AS1. BGP nodes in AS1 can thus find an EF path toward “dest” via AS1-AS3-AS4-AS5.

This is only one step in the process. This only determines the “raw” capability of the Tequila System.

If a SLS comes in AS1, BB to BB negotiation between the ASs in the paths determines whether therequired capacity is available along this EF path.

In this model, resources are completely managed by BB. There is a clear separation between BGP(calculation of end-to-end inter-domain paths) and the BBs (management, measurement and allocationof resources).

5.4.6 Single-path BGP versus Multi-path BGPBGP4, as detailed in [BGP4], is intrinsically single-path. This means that there is only one path towarda set of destination, for a certain CoS. But for end-to-end TE, it may be interesting to use severaldifferent paths: this would give the opportunity, for example, to load-balance between several ASs.Another advantage of multipath is that in case of a path failure, the alternative paths can still be used.



This chapter compares single-path and possible extensions of BGP toward multipath, and details theadvantages and limitations of each solution, in term of TE.

Remark: Current Internet is only Best Effort. In that sense, there is only CoS and one route per (set of)destination(s) within this CoS. The discussion on single-path or multipath BGP is independent of thischaracteristic: even if BGP only supports one CoS, there may be one or several path toward a certainset of destination, within this CoS.

5.4.6.1 A BGP single-path solutionThere is no load-sharing capability in standard BGP. Each BGP node calculates only one path perdestination and per TOS value is stored in the routing table.

The problem is then to determine what is the best path toward the set of destinations that meets theQoS requirements contained in the SLS.

• In the “QoS capability” model, BGP calculates one path, taking the advertised QoS capability asinput. The BBs are responsible for deciding whether the QoS requirements in the SLS may bewarranted.

• In the “QoS parameters” model, BGP calculates one path, taking load, delay, available bandwidthor other, into account. The QoS capability of each path is known from the calculation, and the SLSacceptance process may be done without BBs.

The available bandwidth in each of these QoS pipes will vary, as a function of the traffic transportedin each traffic category. At a certain moment, the available bandwidth in a QoS pipe could be so smallthat the QoS pipe could not accept any new SLS. Since we are in a single-path BGP scheme, the onlysolution is to negotiate an increase of bandwidth for this QoS pipe. Since it doesn’t require a new oralternative pipe to be established, the traffic is not stopped. But we can not be sure that this increase ofallocated bandwidth will always be possible.

5.4.6.2 A BGP Multi-path solution – load sharing capability

5.4.6.2.1 Principle

Multi-path provides some additional values, such as, for example, the possibility to load-balancebetween several ASs and an additional degree of security in case of a path failure: the alternative pathscan still be used.

There is no intrinsic load-sharing capability in BGP4. Instead of calculating only the best path towarda certain (set of) destination(s), Multipath-BGP would calculate several paths toward the (set of)destination(s), for a certain CoS. The result would be several paths per destination (or set ofdestination) and per CoS.

One problem here is to avoid the introduction of loops: BGP is a path-vector protocol, and loops maybe easily introduced, especially with the multipath.

5.4.6.2.2 Loop detection algorithm

Very generally, a BGP route consists of the list of ASs through which the advertisement has passed. Ifwe want to keep several BGP routes, each route is represented by a list of ASs numbers:

If there are two paths toward a certain destination “dest”, each path will be encoded as:

� Path1: AS11 → AS21 → AS31 → AS41 → dest

� Path2: AS12 → AS22 → AS32 → AS42 → AS52→ dest

� Where each ASij is the next AS toward which to send the traffic

Consider the following basic example, consisting of 4 ASs.



$6�

$6�

$6�

$6� GHVW

AS1 receives two advertisements:

� from AS2: [dest: AS2 - AS3]

� from AS4: [dest: AS4 – AS3]

These two routes are valid, from the point of view of AS1. But we may introduce a loop if AS4 forexample thinks that there are two paths toward destination dest:

� [dest: AS1 -AS2 - AS3] here is the loop: AS1 will send traffic back to AS4

� [dest: AS3]

We avoid the loop if AS1:

� doesn’t advertise to AS4 the route toward “dest” via AS2

� doesn’t advertise to AS2 the route toward “dest” via AS4

The loop avoidance rule is thus: “you can not advertise a route toward a destination if the AS to whichyou advertise the route is already included in your list of path vectors”. AS4 and AS2 are indeedincluded in the list of valid paths toward “dest”, in AS1.

But this principle -although conceptually very simple- is strongly limited, because of scalabilityproblems. It requires indeed that a tree or list of the possible AS-Paths be added to the BGP UPDATEmessage. As the size of the network and the number of branching points in it are unpredictable, thereis no upper limit on the size of the list in the BGP message. If, for the purpose of TE, it appears thatmultipath extension for BGP are required, this scalability problem must be solved.

5.4.6.3 ConclusionFor the time being, the scalability problem related to the multipath BGP loop detection algorithm cannot be solved. We suggest thus to use a single path solution at the BGP level, at least in a first step. Iflater on, a scalable loop detection algorithm for BGP can be found, multipath BGP can be foreseen tofurther improve the use of the network (giving the opportunity, for example, to load balance betweenASs).

5.4.7 ConclusionThe “QoS parameters” model is very complex and requires a lot of extensions to BGP. Exchange ofTE parameters is not that simple:

• Information may be outdated by the time a BGP peer receives it

• ISPs may not be willing to exchange this confidential information

• It is not simple to determine the frequency of measurement and flooding

• On the other hand, the “CoS capability” model is much simpler, since resources are completelyhandled by the BBs.

As, for the time being, the scalability problem of multi-path BGP can not be solved, we will work onTE extension for BGP, using a single-path solution. Single-path BGP is conceptually very simple:only path per destination and per TOS value is stored in the routing table.



6 DATA-PLANE FUNCTIONSThis chapter briefly describes the main data-plane functions, i.e. Traffic Conditioning (mainly at theedge routers) and Per Hop Behaviour (PHB) – Enforcement. Considering these functions, theTEQUILA project follows the guidelines given by the IETF DiffServ working group.

6.1 Traffic Conditioning

6.1.1 OverviewThe traffic conditioning block (TCB) is responsible of:

• the recognition of traffic circulating through the (Tequila) data network

• the enforcement of users’ profiles, negotiated through the SLS management, on this traffic beforeit actually enters the Tequila network

• the dissemination of resulting relevant information to SLS management block and monitoringblock.

Once the traffic has been conditioned it can be properly queued into the (Tequila) network through thequeuing (ex. scheduling/forwarding9) block.

So the TCB is mainly acting in the data plane (as part of the PEP feature, cf. COPS architecture) andreceiving and disseminating information from/to the control plane.

The DiffServ traffic conditioning block has been defined in the DiffServ Architecture document[RFC2475] and is currently refined in the following draft: An Informal Management Model forDiffServ Routers [DS-Model], called DSR model here.

The following sections extract the “Tequila-relevant” concepts developed in this model. Note: thesame draft should/could be closely followed for the queuing block.

The traffic-conditioning block is composed of the following functional elements:

• classifier

• meter

• action elements

• queuing elements (a clarification needed here : shaping and policing actions are partlyperformed through queuing. cf. following sections)

To be more precise the DSR model consider (through hierarchical approach) each of the aboveelements as individual functional datapath elements out of which relevant TCBs can be implemented,according to the desired network policies. These TCB are then applied to router interfaces.

6.1.2 Functional Elements

6.1.2.1 Classifier FunctionClassifiers are 1:N devices: they take a single stream as input and generate N logically separate trafficstreams as output. Filters and output streams parameterise classifiers.

A filter consists of a set of conditions on the component values of packet's classification key (theheader values, contents, and attributes relevant for classification).

9 cf. the renaming proposed for the forwarding/scheduling block.



Among the examples given in the model, the two main classifiers (and corresponding filters) ofinterest for Tequila are:

• The BA classifier using only the DiffServ code-point (DSCP) in a packet’s IP header to determinethe logical output stream to which the packet should be directed, with exact-match condition onthis field because the assigned DSCP values have no structure, and therefore no subset of DSCPbits are significant.

• The MF classifier using one or more fields in the packet. A common type of MF classifier is a 6-tuple classifier that classifies based on six fields from the IP and TCP or UDP headers (destinationaddress, source address, IP protocol, source port, destination port, and DSCP). MF classifiers mayclassify on other fields such as MAC addresses, VLAN tags, link-layer traffic class fields or otherhigher-layer protocol fields (e.g. for the “famous” state-full applications).

Notes:

• To prevent ambiguity between overlapping filters in a classifier, a precedence mechanism betweenestablished filters is needed. To be complete, a classifier need also a “everything else” filter as thelowest precedence element.

• MF classification of fragmented packets is impossible if the filter uses transport-layer portnumbers e.g. TCP port numbers. MTU-discovery is therefore a prerequisite for proper operation ofa DiffServ network that uses such classifiers.

6.1.2.2 Meter FunctionA meter is needed to offer services based on temporal (i.e. rate) profile within which the customersubmits traffic.

A meter measures the rate at which packets making up a stream of traffic pass it, compares the rate tosome set of thresholds and produces some number (two or more) potential results: a given packet issaid to "conform" to the meter if, at the time that the packet is being looked at, the stream appears tobe within the meter's limit rate.

Actions are then applied to conforming and non-conforming packets (e.g real-time marking, countingfor out-of-band management, etc.).

Among the examples given in the model, the two main meters of interest for Tequila are:

• the leaky bucket, primarily used for traffics shaping (see the corresponding section)

• the token bucket

Both buckets are, by definition, theoretical relationships between some defined burst size, rate andinterval: rate = burst_size/interval

E.g. a token bucket of rate 1,2Mbit/s and burst size 1500 bytes has a token interval of 10 ms andallows at most 100 bursts per second of 1500 bytes and at a rate not to exceed 1.2 Mbps as conformingtraffic. See the model for detailed discussion on the approximations of such theoretical relationships.

The token bucket implemented by Cisco (CAR) permits two-parameter and Multi-stage token bucketmeters 10 (and associated policing for EF and AF based TCB).

6.1.2.3 Action Elements/FunctionsThe classifiers and meters described up to this point are generally used to determine the appropriateaction to apply to a packet. The set of possible actions that can then be applied include: 10 with some random affectation between conforming and no-conforming packets, to allow some borrowing fromfuture token allocations. To be confirmed : CAR is close to “loose token bucket” detailled in the appendix of themodel.



• marking,

• absolute dropping,

• multiplexing

• counting,

Marking (remarking) sets (remarks) a DSCP code-point in the packet header.

Absolute dropping simply discard (non conformant) packets.

Counting is a passive action permitting to account any action processed on a packet. The statistics thatresult might be used later for customer billing, service verification network engineering, monitoringpurposes, etc.

Multiplexing is occasionally necessary to multiplex traffic streams into a functional datapath elementwith a single input.

6.1.2.4 Queuing elements/FunctionsTo be complete on TCB, queuing elements described in the DSR model have to be mentioned. Thequeuing block is decomposed in the following elements:

• queues (i.e. non-reordering FIFO)

• Schedulers (e.g. PQ, WFQ, WRR, etc.)

• Algorithmic droppers (e.g. RED, RIO, etc).

See the model for more details.

Policing (TCB action) is modelled as either a concatenation of a meter with an absolute dropper or asa concatenation of an algorithmic dropper with a scheduler.

Shaping (TCB action) is modelled by a non-work-conserving scheduler, delaying the departure ofpackets that would be deemed non-conforming by a meter configured to the shaper’s maximumservice rate profile.

Notes:

It has to be noticed that the DSR model defines that a TCB contains, by definition, zero or moreclassifier, meter, action, algorithmic dropper, queue and scheduler elements, arranged arbitrarilyaccording to the policy being expressed, but always in the order here.

6.1.3 Examples for the Tequila SLSsThe DSR model gives some examples of TCBs which implement the cascading/concatenation ofelementary functional elements described previously to provide SLS for mono-customer permanentaccess, Multi-customers permanent access and micro-flow based services.

The same exercise can be done onto the SLS defined in the Tequila project. Many flavours of TCBimplementations can be thought of. The following section proposes examples of TCBs to berefined/improved/extended.

• VLL TCB

2 variations are given here. 1st variation: the ISP “starts” managing the VLL service at the CPE(recommended). 2nd variation: the ISP “starts” managing the VLL service at the PE (in which case thecustomer manages the congestion control and VLL on the access link + the BA marking)

Queue and scheduler are mentioned here but concern the queuing block.

No shaping nor algorithmic dropper are considered for the VLL.



CPE lan side CPE wan side PE customer side PE backbone side

e2e VLL

(CPE to CPE)

MF classifier (recognitionof traffic belonging to theVLL)

Meter (X bucket)

Marker (VLL codepoint)

Policer (absolute dropper)

Counter(transmitted/dropped VLLtraffic)

Options:

Per application meter/policer “inside” the VLL

Queue and Scheduler(VLL vs other traffic)

BA classifier

Meter

Marker

Policer

Counter

(these elements areredundant with the CPEbut needed for security)

Queue and Scheduler(VLL vs other traffic) :PEÅCPE

Queue and scheduler

Edge to edge VLL

(PE to PE)

BA classifier

Meter

Marker

Policer

Counter

Queue and Scheduler(VLL vs other traffic) :PEÅCPE

Options :

MF classifier instead ofBA classifier (ISPmarking)

Shaper or policerPEÅCPE

Queue and scheduler

• The real time micro-flows TCB

Should require the same kind of TCB (e2e) + per-microflow meter/policer.

• The minimum rate guarantee with allowed excess TCB and qualitative olympic services

Should require the same kind of TCB (e2e) + per AF class meter/marker + algorithmic dropper +shapers on non real-time micro-flows/applications.

It has to be noticed that performance parameter management does not concern TCBs.

6.1.4 Interface semantics and parametersThe traffic-conditioning block interacts with the SLS management block and the monitoring block.

Communications with SLS mgmt block are two-ways. Essentially:

• the SLS mgmt block send configuration rules (init./modification/deletion) to the TCB block

• the TCB block inform the SLS mgmt block by :

• acquitting the configuration rules

• sending the counters (feed-back from the TCB actions on the customers traffic to the SLS mgmtblock)

Communications with the monitoring block are essentially one-way:



• sending the counters (feed-back from the TCB actions on the customers traffic to the monitoringblock)

Notes:

I can’t see now if sending the counters to both SLS mgmt and monitoring block are/are not redundant.

I can’t see no reasons why monitoring block should send configurations rules (at least on counters) tothe TCB. Indeed it should be forbidden (these orders should only come from the SLS mgmt block)

6.2 PHB EnforcementThe PHB Enforcement functional block is responsible for implementing the mechanisms needed toprovide differential forwarding treatment to traffic passing through the router according to theDiffServ WG specifications. From the definition of the PHB as "the externally observable forwardingbehaviour applied at a DS-compliant node to a DS behaviour aggregate", it is deduced that the PHBEnforcement block should implement the standardised PHBs in an abstract level, hiding the vendorand algorithm specific implementation details.

In order to achieve this, the PHB Enforcement block manipulates the NE's native scheduling andqueue management mechanisms so as to enforce the bandwidth and buffer sharing rules andparameters, defined by the Dynamic Resource Management functional block, and hence satisfy thePHBs requirements in terms of throughput, delay, jitter and loss.

6.2.1 Description of Functions

6.2.1.1 SchedulingScheduling is a mechanism that regulates the order of departure of packets from separate packetqueues, forming a single output queue destined for transmission. The way scheduling treats each inputpacket queue determines how the traffic classified into that specific queue is transmitted by the router.Thus, the scheduling mechanism provides the means for implementing differentiated trafficforwarding treatment.

Scheduling takes as input a set of packet queues, each serving a pre-classified type of traffic anddelivers as output a single packet queue. It uses a scheduling algorithm which may vary depending onthe underlying Network Element's implementation. It is important though for a scheduling algorithmto support a minimum functionality in order to comply with the Tequila functional requirements and toenable the configuration of PHB related parameters.

The functional requirements resulting from the project's needs for scheduling include:

• support for traffic prioritisation,

• support for bandwidth and buffer allocation for a specific traffic type,

• support for rules definition for handling traffic exceeding the bandwidth allocation of a specifictraffic type.

Optionally, the scheduling algorithm may provide support for applying a maximum traffic profile inorder to enforce constraints to a specific traffic type.

6.2.1.2 Queue ManagementQueue management is a mechanism that controls the average queue size of a packet queue in order toprovide congestion avoidance and maintain high throughput and low delay. In order to achieve this, itexercises a dropping algorithm which selectively discards packets from the queue. This algorithm canbe regulated to be more or less aggressive and provides therefore the means for enforcing dropprecedence to traffic classified into different queues.



As in the case of the scheduling mechanism, the queue management mechanism supported by aNetwork Element may vary. Though, the state of the art review shows that most of the consideredalgorithms function using thresholds and dropping probabilities.

6.2.2 Interface semantics and parametersThe PHB Enforcement functional block interacts only with the Dynamic Resource Managementfunctional block from which it gets the necessary PHB configuration information. The DynamicResource Management block is entitled to configure the PHB Enforcement block during the latter’sinitialisation and operational phase.

The PHB Enforcement block should support configuration parameters for each supported PHB dealingwith bandwidth and buffer resources allocation and excess traffic treatment. The specific parameters tobe supported are yet to be defined. It is envisaged that the [PHBSPEC], which describes a set of PHBspecification parameters, will be used as input. More specifically, [PHBSPEC] proposes that anabstract representation of the PHBs and a minimal set of parameters for their tuning, both independentof particular implementations, shall be used to achieve interoperability between different devices andvendors. The proposed set of the PHB configuration parameters comprises parameters providing forbandwidth and buffer allocation for each specified PHB, thus satisfying one of the functionalrequirements of the PHB Enforcement block. The proposed set of parameters though, needs to bestudied, refined and enhanced according to the project’s needs.

The PHB Enforcement block is responsible for mapping these PHB configuration parameters to theappropriate scheduling and queue management configuration parameters and to ensure the underlyingmechanisms enforce the appropriate forwarding treatment in order to support the defined PHBs.



7 POLICY FRAMEWORKPolicy Management can be considered as a set of functional blocks as seen in Figure 56. Thedescription of the functions of each block is presented in the following subsections.

Human

PolicyMgmt Tool

PolicyConsumer

PolicyStoringService

Policy Management

Human

PolicyMgmt Tool

PolicyConsumer


Policy Management

Figure 56 Policy Management Functional Block Decomposition.

7.1 Description of Functions

7.1.1 Policy Management Tool

• Policy Editing and Presentation: is a mechanism for entering, viewing and editing Policy Rulesin the Policy Repository through a GUI, a simple Web-based form, and/or a command lineinterface or scripting interface.

This function has as input the definition or activation of Policies in a high level language by thehuman operator. It also provides feedback on the validation or translation results to theadministrator, indicating the erroneous rule conditions or actions or displaying the existing PolicyRule with which the new one conflicts.

• Translation: this function maps a high level (e.g. Business-oriented) specification of a PolicyRule to an object-oriented policy representation (information objects), which can be stored in therepository.

This function requires as input the policy specification as entered by the operator and delivers asoutput an object-oriented policy representation (information objects) for storing them in the PolicyRepository.



• Validation: this function performs two kinds of check of policy prescription and/or rule andreturns the result of this check. The first kind of check is to validate the data types of the terms ofthe specified Policy Rule and the second one is to validate semantics of the Policy Rule, ensuringthat the construction of the Policy Rule and its conditions and actions, from a set of predefinedblocks, actually make sense.

This function has as input the translated Policy Rules entered in the tool and provides as outputmessages, which indicate the result of the validation function (i.e. ok or error).

• Conflict Detection: performs checks to see if a newly entered policy conflicts with other existingpolicies but this check is not bound to any specific device, subnet or network.

The input to this function are the Policy Rules as they are delivered from the Translation functionand the output are error or ok messages indicating the result of the conflict detection process.

• Policy Activation: after the definition/change or deletion of a policy by the human operator andthe appropriate verifications are made, this particular policy must be activated in order to be storedin the Policy Repository. When the human operator has specified a policy hierarchy, definitionand verification of all the policies in the hierarchy have to be done before storing the whole policyhierarchy in the Repository.

This function requires as input the activating Policy message from the human operator and thedelivered output is a single Policy or a whole Policy Hierarchy in the Policy repository.

Policy Refinement: stores the policy refinement rules and generates policies for each level ofhierarchy defined.

The input to this function is the policy refinement rules that will be stored and the policy rules thatwill be refined. The output will be the generated policies for each level of hierarchy defined.

7.1.2 Policy Storing Service• Policy Storage, Search and Retrieval: policy Rules need to be stored in the Policy Repository

after they have been translated and verified. Also the retrieval of Policy Rules from the repositoryis required, in order to perform the Rule Validation and Conflict Detection function as well asfrom the Policy Consumer in order to have the appropriate information of the associated policies.

This function requires as input the policies that need to be stored in the repository or requests forretrieval of already stored policies either from the Policy Management Tool or the PolicyConsumer. The delivered output is sending back the requested information to the functionalcomponent that asked for it and also notifying the appropriate Policy Consumer aboutchanges/new policies that they are responsible for enforcing.

7.1.3 Policy Consumer• Getting Policy: after receiving the notification of a change/addition/deletion of a Policy in the

Policy Repository, the associated Policy Consumer must be updated accordingly, by getting therequired information from the Policy Storing Service.

The input for this function is the notification sent by the Policy Storing Service to the PolicyConsumer, which results in the retrieval of the necessary Policy information.

• Mapping: the purpose of this function is to take the representation of the Policies as stored in theRepository and interpret them to parameterised functions of the management capabilities of therelated functional block.



The required input is the retrieved new policy that this Policy Consumer is responsible for and theoutput is the triggering of the appropriate management function when the associated event hasbeen sent from the monitoring service.

• Register Policy Monitoring: this function registers the appropriate events at the MonitoringFunctional Block in order to get notified about the triggering of the enforcement of specificpolicies or the inability of continuing the enforcement of an already enforced Policy.

As input, this function requires the retrieval of an additional/changed or deleted Policy in thePolicy repository and delivers as output the registering or un-registering messages sent to theMonitoring FB.

• Enforcing Policy: this function triggers the mapped management action of the FB associated withthat Policy Consumer after a notification from the Monitoring FB has arrived.

The notifications sent from Monitoring are the input to this function and the delivered output is thetriggering of the mapped management function.

7.2 Interface semantics and parametersThis section describes the interaction of the PolicyManagement Functional Block with otherFunctional Blocks through events, messages or signals.

Figure 57: Interaction of the PolicyManagement Functional Block with others

The description of the relevant events is included in the table that follows:

SLSManagement

DynamicRt&RsrcMgmt

Monitoring


PolicyMgmtTool

3, 4, 5

1, 2

8

6

7

91011, 12

Human

PolicyConsumer

Dimensioning

13

14

PolicyManagement


1 Human PolicyMgmtTool PolicyMgmtTool_SetPolicy (1) Policy fields -This message represents the definition of Policies in a high levellanguage by the Human Operator

2 Human PolicyMgmtTool PolicyMgmtTool_ActivatePolicy (2) PID -This message will activate the policy that was previously entered bythe operator so that the policy will be in a state of waiting to beenforced when the conditions are satisfied.

3 PolicyMgmtTool PolicyStoringService PolicyStoringService _StorePolicy (3) Policy Objects -This message will store the new Policy Rule in the Repository

4 PolicyMgmtTool PolicyStoringService PolicyStoringService _RemovePolicy (4) PID -This message will remove a Policy Rule from the Repository

5 PolicyMgmtTool PolicyStoringService PolicyStoringService _RetrievePolicy (5) PID, Policy fields -This message will retrieve the Policy Rule from the repository forediting purposes e.g. change, delete. This message can also be usedto search for a particular Policy Rule.

6 PolicyStoringService PolicyConsumer PolicyConsumer_NotifyNew/ChangePolicy (6) PID -This message will notify the appropriate Policy Consumer for achange in an existing Policy that this Policy Consumer is responsiblefor enforcing.

7 PolicyConsumer PolicyStoringService PolicyStoringService _GetPolicy (7) PID -This message will retrieve the appropriate information needed fromthe Policy that was newly entered or changed in the Repository.

8 PolicyConsumer PolicyMgmtTool PolicyMgmtTool_NotifyEnforceUn (8) PID -This message will notify the Policy Management Tool if a policycan no longer be enforced.

9 PolicyConsumer Dimensioning Dimensioning_SetPolicyDimFunct (9) (see comment) -This message will map the policies to the parameterized functionsof management capabilities of the Dimensioning FB.

10 PolicyConsumer DynamicRt&RsrcMgmt DynamicRt&RsrcMgmt_MapPolicyDynRRMFunct (10) (see comment) -This message will map the policies to the parameterised functionsof management capabilities of the Dynamic Resource and RouteManagement FB.

11 PolicyConsumer Monitoring Monitoring_RegisterPolicyMonitoring (11) Triggering Event,Monitoring Objects,Thresholds

-This message will register the triggering events to the MonitoringFB that the Policy Consumer wants to be notified for enforcing thepolicies.

- It may also register events that indicate the correct enforcement ofpolicies.

12 PolicyConsumer Monitoring Monitoring_UnRegisterPolicyMonitoring (12) Triggering Event,Monitoring Objects,Thresholds

-This message will unregister the triggering events to the MonitoringFB that the Policy Consumer wants to be notified for enforcing thepolicies.

- It may also unregister events that indicate the correct enforcementof policies.

13 Monitoring PolicyConsumer PolicyConsumer_NotifyMonitoringEvent (13) Monitoring Objects,Thresholds

-This message will notify the Policy Consumer about the specifiedevent to trigger the policy enforcement.

- It may also notify the Policy Consumer about a registered event,which indicates the inability to enforce a certain policy.

14 PolicyConsumer SLSManagement SLSManagement_MapPolicySLSMgmtFunct (14) (see comment) -This message will map the policies to the parameterized functionsof management capabilities of the SLS Management FB.


TEQUILA Consortium - September 2000

7.3 Finite State MachinesThe following sections describe the internal working of the Functional Sub-Blocks, which constitutethe Policy Management Functional Block by means of a Finite State Machine (FSM).

7.3.1 The Policy Management Tool FSM

Wait/ Editing

Validating

Translating

Error

Storing Policy in

Repository

Refinement

Set/ Change Policy

E.2

Policy Stored E.11

Policy Conflict Found E.7

Cannot Validate Policy E.5

Translation Done E.4

Policy Validated

E.6

No Conflict E.8

Alarm Sent E.9

Generate Hierarchy E.12

Refinement Stored E.13

Translation Failed E.3

Activate Policy E.10

ConflictDetection

Delete Policy E.14

InitInitInitialization

Done E.0 No event E.1

Store Refinement Rules E.15

Hierarchy Generated E.16

Figure 58: The Policy Management Tool FSM.


• Init: all functions to initialise the Policy Management Tool are performed during this state.

• Wait/Editing: at this state we wait for the human operator to enter, view and edit the policy rules.

• Storing Policy in Repository: state during which the policy rules are stored.

• Translating: state at which a high-level (e.g. Business-oriented) specification of a Policy Rule ismapped to an object-oriented policy representation (information objects).

• Validating: state at which data types and semantics of policy prescription and/or rules arechecked.

• Conflict Detection: state at which consistent checks to identify conflicts between the new andexisting policies are carried out.



• Refinement: at this state policy refinement rules are stored and policies for each level of hierarchydefined are generated.

• Error: this is an error state, which is reached when either there has been a problem whenvalidating a new policy rule or checking out conflicts between the new and existing policies. Afterthe appropriate alarm has been sent the next active state is the Wait /Editing.



E.1 After the Policy Management Tool has initialised, even withoutany policy being edited; the system has to stay in this state.

E.2 Policy Fields This event indicates that the new policy rules have been editedand have to be validated and executed.

E.3 PID This event indicates that the new policy rules were nottranslated successfully.

E.4 Policy Object This event indicates that the new policy rules were translatedsuccessfully.

E.5 PID This event indicates that the new policy rules could not bevalidated.

E.6 Policy Object This event indicates that the new policy rules have beenvalidated.

E.7 PIDs This event indicates that conflicts have been found between thenew and existing policies.

E.8 Policy Object This event indicates that conflicts have not been found betweenthe new and existing policies.

E.9 PID This event indicates that the new policy rules were declaredinvalid.

E.10 Policy Objects This event indicates that new policy rules will be stored andactivated.

E.11 PID This event indicates that new policy rules have been stored andactivated.

E.12 Policy HierarchyRules

This event indicates that new refinement/hierarchy directiveswill be stored and activated.

E.13 Policy HierarchyRules

This event indicates that new refinement/hierarchy directiveshave stored and activate successfully

E.14 PID This event indicates that existing policy rules have to bechecked for deletion.

E.15 Policy Fields This event indicates that policies will be refined according torefinement rules stored.

E.16 Policy Fields This event indicates that policies were generated for every levelof hierarchy defined. Each policy generated has its own policyfields.




S0

Init

S1

Wait/Editing

S2

Translating

S3

Validating

S4

Conflict Detection

S5

Storing Policy inRepository

S6

Error

S7

Refinement

E.0 [Initialisation Done, S1]

E.1 [No Event, S1]

E.2 [Set/Change Policy, S2]

E.3 [Translation Failed, S6]

E.4 [Translation Done, S3]

E.5 [Cannot ValidatePolicy, S6]

E.6 [Policy Validated, S4]

E.7 [Policy Conflict, S6]

E.8 [No Conflict, S1]

E.9 [Alarm Sent, S1]

E.10 [Activate Policy, S5]

E.11 [Policy Stored, S1]

E.12 [Generate Hierarchy,S7]

E.13 [RefinementStored, S1]

E.14 [Delete Policy, S4]

E.15 [Store RefinementRules, S7]

E.16 [HierarchyGenerated, S1]



7.3.2 The Policy Storing Service FSM

Figure 59: The Policy Storing Service FSM


• Init: all functions to initialise the Policy Consumer block are performed during this state.


• Updating Repository: at this state, the storage or removal of translated policies is done,depending on the request from the Policy Management Tool.

• Notify Consumer: during this state, the Policy Storing Service is sending a notification to theappropriate Policy Consumer about a new, changed or deleted Policy.

• Searching: at this state, the Policy Storing Service is searching the stored Policies to find thepolicy requested either by the Policy Management or the Policy Consumer.

• Sending Results: during this state, the Policy Storing Service is sending back the results from therequests of specific Policies either to the Policy Management Tool or the Policy Consumer.

Idle

Updating Repository

Notify Consumer

Searching

Update Done E.4

Store Policy E.2

Remove Policy E.3

Sending results

Search Done E.8

Results Sent E.9

Get Policy E.6Retrieve Policy E.7

Consumer Notified

E.5

Init Initialization Done E.0 No Event E.1

IdleIdle

Updating RepositoryUpdating

Repository

Notify Consumer

Searching

Update Done E.4

Store Policy E.2

Remove Policy E.3

Sending results

Search Done E.8

Results Sent E.9

Get Policy E.6Retrieve Policy E.7

Consumer Notified

E.5

InitInit Initialization Done E.0 No Event E.1






E.2 Policy Objects A new request for storing a Policy in the Repository hasarrived.

E.3 PID A new request for removing a Policy from the Repositoryhas arrived.

E.4 Policy Objects This event indicated that the repository has been updatedabout the new/changed or deleted Policy Objects.

E.5 PID This event indicates that a notification to the appropriateconsumer has been sent about an addition, change or removalof a Policy.

E.6 PID This event indicates that a Get request for a Policy by thePolicy Consumer has arrived.

E.7 PID This event indicates that a request for a retrieval of a Policyby the Policy Management Tool has arrived.

E.8 Policy Object This event indicates that the searching function has found therequested Policy Object.

E.9 Policy fields The requested information about a Policy has been senteither to the Policy Management Tool or the PolicyConsumer.


S0

Init

S1

Idle

S2

Updatingrepository

S3

Notify Consumer

S4

Searching

S5

Sending Results

E.0 [Initialisation Done,S1]

E.1 [No Event, S1]

E.2 [Store Policy, S2]

E.3 [Remove Policy,S2]

E.4 [Update Done, S3]

E.5 [ConsumerNotified, S1]

E.6 [Get Policy, S4]

E.7 [Retrieve Policy,S4]

E.8 [Search Done, S5]

E.9 [Results Sent, S1]



7.3.3 The Policy Consumer FSM

Idle

Mapping

Policy Deactivation Error

Wait trigger event

Policy Enforcement

Wait

No Triggering Event E.5

Policy Deleted E.13

Get Policy

Notify New/ Change Policy

E.2

Policy Got E.3

NotifyEnforceUnE.11

Delete Policy E.12

Register Policy Montoring

(Trigger Event) E.6

Notify Monitoring Event(trigger) E.7

Notify Monitoring Event (UnEnforcePolicy) E.10

Cannot Enforce Policy E.9

InitInitialization

Done E.0

Cannot Map Policy E.4

No Event E.1

Idle

Mapping

Policy Deactivation

Policy Deactivation Error

Wait trigger event

Policy Enforcement

Wait

No Triggering Event E.5

Policy Deleted E.13

Get Policy

Notify New/ Change Policy

E.2

Policy Got E.3

NotifyEnforceUnE.11

Delete Policy E.12

Register Policy Montoring

(Trigger Event) E.6

Notify Monitoring Event(trigger) E.7

Notify Monitoring Event (UnEnforcePolicy) E.10

Cannot Enforce Policy E.9

InitInitInitialization

Done E.0

Cannot Map Policy E.4

No Event E.1

Figure 60: The Policy Consumer FSM


• Init: all functions to initialise the Policy Consumer block are performed during this state.


• Get Policy: at this state the Policy Consumer is requesting and retrieving the needed informationabout the policy from the Policy Storing Service.

• Mapping: during this state the mapping of the Policy fields is performed to the specificmanagement functions of the functional block to which the Policy Consumer is associated with andthe monitoring events needed to register with the Monitoring Block. If the mapping cannot be donesuccessfully, the next state will be the Error State.

• Wait trigger event: during this state the Policy Consumer waits to be notified about the registeredtrigger event from the Monitoring Block to start enforcing the Policy action.

• Policy Enforcement: at this state, the Policy Consumer triggers the mapped Policy action afterreceiving the notification about the triggering event. If this is done successfully the next state is theWait state, otherwise it goes to the Error state.

• Wait: during this state the Policy Consumer waits for a notification from the monitoring servicespecifying that the policy can no longer be enforced. If it receives this notification it goes to theError state.

• Error: this is the state reached when there is a problem with mapping, policy enforcement orwhen Monitoring notifies about the inability to further enforce the policy.

• Policy Deactivation: during this state all the necessary actions needed for removing a policy fromthe Policy Consumer are performed (i.e. un-registering the monitoring events and deleting theinformation that the policy consumer had for realising this policy).






E.2 PID A notification about a new or a change in an existing Policyhas arrived.

E.3 Policy Info This event indicates that the needed information about thechanged or new policy is retrieved.

E.4 PID This event indicates that the Policy Consumer was unable toperform the mapping function.

E.5 This event indicates that there was no triggering event for thespecified Policy so the Policy Consumer goes directly to theEnforcement state.

E.6 Triggering Event,Monitoring Objects,Thresholds

This event indicates that the appropriate triggering events areregistered to the Monitoring Block.

E.7 Monitoring Objects,Thresholds

A notification of the previous registered triggering events hasarrived.

E.8 Monitoring Objects,Thresholds

This event indicates that the enforcement of the policy isnow registered for being monitored.

E.9 PID A notification about an erroneous attempt to enforce thePolicy.

E.10 PID A notification from monitoring that the Policy can no longerbe enforced has arrived.

E.11 PID A notification to the Policy Management Tool that there is aproblem handling this policy by the Consumer has been sent.

E.12 PID This event indicates that a request for deleting a Policy hasarrived.

E.13 PID A confirmation about the deletion of the requested Policy hasbeen sent.

D2.1: Simulators, Network Elements and Development Environment Page 156 of 172



S0Init

S1Idle

S2Get Policy

S3Mapping

S4Wait trigger event

S5Policy Enforcement

S6Wait

S7Error

S8PolicyDeactivation

E.0 [Initialisation done,S1]

E.1 [No event, S1]

E.2 [Newrequest/Notification,S2]

E.3 [Policy Got, S3]

E.4 [Cannot Map Policy,S7]

E.5 [No TriggeringEvent, S5]

E.6 [Register PolicyMonitoring (TriggerEvent), S4]

E.7 [Notify MonitoringEvent, S5]

E.8 [Register PolicyMonitoring(Enforcement), S6]

E.9 [Cannot EnforcePolicy, S7]

E.10 [NotifyingMonitoring Event(UnEnforcePolicy),S7]

E.11 [NotifyEnforceUn, S1]

E.12 [Delete Policy, S8]

E.13 [Policy Deleted,S1]



8 MONITORING FRAMEWORK

8.1 IntroductionMonitoring is a crucial network function for both the correct functioning of the Tequila system and forthe ability to impose a check on the SLSs, which were agreed with a customer. It is necessary to havea local and an aggregated overall view on the network in terms of the definitions of the IETF IPPMworking group. This is reflected in the monitoring framework and its correlation with the rest of theTequila system. In this document we do not emphasise on the way the monitoring is accomplished.

It is necessary to mention that the Tequila system needs to support two sources of information as thebasis for the monitoring framework. First information gained by inserting (low-impact) test streams(referred to as active measurements) and the results of the analysis of the traffic passing in the networkelement (referred to as passive measurements). To have a scaleable system, the information of thesebasic building blocks needs to be aggregated into summarising statistics by some higher level blocks.

8.2 Message Sequence ChartThe next figure gives an overview of the typical behaviour of the monitoring framework within theTequila system. Three external sources are interested in the information gained by monitoring.

• The network dimensioning, to be able to construct a network model.

• The SLS-monitor for accounting and as an extra check that the agreed service is indeed beingdelivered.

• The dynamic resource and route management (to be able to perform local optimisations).

This is reflected in the message sequence diagram.

For the network-wide view we need an organising and processing block, named Network Monitor inthe figure. The local activities of the monitoring framework are organised by the Node Monitor. Thelatter one uses its knowledge on the configuration of a network element, and the requested informationfrom the other blocks, to configure the implementation of the measurements.

The typical monitoring behaviour can be split into 4 phases. At first, every functional elementinterested in the aggregated, network-wide monitoring information needs to subscribe to the networkmonitor. He will then decide which local (node) measurements are needed to be at the basis of thisnetwork-wide information. This will be incorporated in the second phase: the configuration of thelocal node. It could be that some other blocks need direct local information (e.g. dynamic managementfor local optimisations), so they will have to configure and poll the node monitor directly. They willalso act in this phase. The node monitor will perform the measurements on basis of theseconfigurations, and will also use information from the traffic conditioning for this action (e.g.metering information). To conclude the execution of the monitoring, the network monitor willaggregate the local information. A last phase consists of the monitoring feedback to the subscribedcomponents.



Figure 61: Monitoring feedback MSC

NodeMonitor

SLSMonitor

TrafficForecast

DynamicResource

Management

NetworkMonitor

Summarise andprocess results

SLSManagement

Subscribe to network-wideMonitoring Information

DynamicRoute

Management

Retrievemetering

informationas input

Set-upmonitoring

requestsand poll at

regularintervals

Thresholds crossed

Network Status reports

Exceptional Events

Req

ues

tC

onfi

gura

tion

Exc

ecut

ion

Rep

rotin

g &

exc

eptio

ns



8.3 Functional Block DecompositionIn this section, a decomposition of the monitoring framework will be given. After a general overviewthere will be a more thorough description on the semantics of SLS-monitoring.

8.3.1 Architecture

Figure 62: Monitoring Architecture

8.3.2 Functions• SLS Monitor

The SLS monitor is used to add an explicit check on certain SLSs. This functional block willrequest some summary statistics to be able to report to other management layers. Depending tothe nature of the SLS and the kind of results requested, the information needed can benetwork-wide or can be retrieved from the monitoring sub-system at the edges of the SLS.

• Network Monitor

This functional element has a network-wide view on the monitoring architecture. This willalso be the block that aggregates and correlates the different local monitoring results.

• Node Monitoring

The node monitor retrieves local information at a low time scale. Next to the control overeffective measurement drivers, he has the configuration of the network element as an(implicit) input. This enables the monitoring configuration agent to translate requests andresults between low-level drivers and upper layer requestors.

• Traffic Conditioning

Next to its obvious conditioning role, the traffic conditioning is also a part monitoringframework. Information from its metering, classification and scheduling/queuing will be aninput to the node monitor. At the edges, this information could also be used directly by theSLS-monitor.

NetworkMonitor

SLSMonitor

TrafficForecast

TrafficConditioning

NodeMonitor

SLSManagement

NetworkDimensioning

Dynamic RouteManagement

Dynamic ResourceManagement



8.3.3 Interfaces

8.3.3.1 TypeAll of the interfaces in the monitoring framework fit into a client-server relationship. Section 2.1.33will give an overview of these relationships. The communication on the interfaces can be handled indifferent ways: continuos reporting, either by polling or trap-based, reporting based on configuredthresholds, exception reporting (e.g. service interruption detection), or even a combination of these.

8.3.3.2 ParametersTwo types of parameters are being used for the communication. The basic measurements results willbe expressed in terms of the metrics defined by the IPPM working group. These might be extendedwith own defined metrics (e.g. the CPU-load of a node). Next to this, the aggregated information willneed to be expressed in terms of the available metrics or new ones defined by Tequila.

In the other direction, a formal specification of what needs to be monitored needs to be given. The waythis is filled in needs to be studied.

8.3.3.3 Interface overview & semanticsParameter type

Client role Server rolebasic aggregated

Semantics

SLS-management

SLS-monitor X Follow-up on established SLSs

SLS-management

NetworkMonitor

X Network status information exchange

SLS-monitorTraffic

ConditioningX Local information (e.g. at the edge) retrieval

SLS-monitorNetworkMonitor

X Network status retrieval for the observed SLS

SLS-monitor Node Monitor X Local information (e.g. at the edge) retrieval

NetworkMonitor

Node Monitor X Local information retrieval

TrafficForecast

NetworkMonitor

XNetwork status retrieval (possibly including

trends)

DynamicManagement

NetworkMonitor

XCurrent network status and/or exceptional

events (e.g. service interruption)

DynamicManagement

Node Monitor XCurrent node status and/or exceptional events

(e.g. service interruption)

Node MonitorTraffic

ConditioningX Current node status



8.3.4 Finite State MachineThe SLS-monitor, Network Monitor and Node Monitor have functional state machines which comedown to the classic client-server paradigm, and which should be obvious when looking at the scenariodescribed in.

8.3.5 Algorithm and Protocol Problem DescriptionTo complete this section an overview is given of the protocols and algorithms that need to be filled in:

• Node monitor: an algorithm for correlating requests with the configuration of the network elementneeds to be available.

• Network Monitor: needs to process the large amount of local information to give an aggregatedview to its clients.

• Interfaces: these are all client-server kind of relationships, needing the folowing genericenhancements:

½ Configuration / initialisation protocols.

½ Result transportation protocols.

½ Exception handling events.

8.4 SLS Monitoring

8.4.1 IntroductionThis contribution basically explains the SLS Monitoring in TEQUILA context. This separate view isincluded to shed a light on the specific semantics of this component.

8.4.2 Service SubscriptionA Customer Service is a set of more then one uni-directional SLS. These uni-directional SLSs mayhave end-points outside of the AS domain. The resource availability check must be done for all ofthese uni-directional SLSs prior to the OK/NOK of the service to user. That is a necessity for SLSsubscription to perform the check to ensure that adequate resources are available in order to meet thequantitative/qualitative QoS/CoS bounds along the path between any two endpoints within the scope.Upon the acceptance of Customer request (all uni-directional SLSs), the SLS subscription entity needsto perform any necessary action in order to provide the term and conditions of service to the customerand then inform the customer about the conditions. The customer may accept the conditions and buythe service. Before the user use the service, any necessary classification, marking, shaping andpolicing must be set at the ingress nodes.

8.4.3 SLS Monitoring Framework



We decided to have two separate entities called Node Monitoring (NM) and Ingress/Egress Monitoring(I/EM). These two may be combined later. A Node Monitoring task is assigned to every NE in thenetwork while the Ingress/Egress Monitoring task is only assigned to the access edges of theIngress/Egress NEs (see Figure 1). The Node Monitoring performs the aggregate performancemeasurement. Ingress/Egress Monitor performs per-SLS monitoring at the access edges of theIngress/Egress NEs. Hence, both types of monitoring are performed on different edges of theIngress/Egress NEs i.e., per-SLS measurement on the access edge and aggregate measurement on thecore edge.

Figure 63: Node Monitoring and Ingress/Egress Monitoring.

Node Monitoring entity passively/actively monitors the traffic on the links. Ingress/Egress Monitorperforms per-SLS measurement such as throughput and user usage time at the access edges of thenetwork. Network Monitoring, gets the view of entire network based on the physical and logicaltopologies. Network Monitoring provides the SLS Monitoring with the end-to-end performance viewof the network. The SLS Monitoring analyses the performance information received from the Networkand Ingress/Egress Monitoring and then provides the related entities with feedback regarding serviceconditions and SLA conformity. SLS monitoring is not interested in Node Monitoring and it willdepend on Network Monitoring for core performance and Ingress/Egress Monitoring for customerrelated accounting information.

8.4.4 Functional Block Decomposition of SLS Monitoring

8.4.4.1 SLS Monitoring DescriptionSLS Monitoring takes its input from SLS repository and acts as a client to Ingress/Egress Monitoringand Network Monitoring. SLS Monitoring must keep track of compliance with customer SLSs byanalysing performance values provided by Network and Ingress/Egress Monitoring entities. SLSmonitoring gathers the combination of information for several uni-directional SLSs to derive theoverall service report to the customer. SLS monitoring focuses on the network layer metricinformation such as one-way delay, IPDV, packet loss ratio, and throughput. Apart from havingoverall view on the above parameters, the monitoring framework includes link and device availabilityand accounting information.

Network

NMI/EM NM

NM

NM

NM: Node Monitor

I/EM: Ingress/Egress Monitor

Ingress/Egress Network Element

Core Network Element

I/EMNM

I/EMNM

Access Edge Core Edge

A

B

C



The Network Monitoring provides the end-to-end performance view for SLS Monitoring. It is alsoessential for SLS Monitoring to use the edge node statistics via Ingress/Egress Monitoring. Thecustomer traffic is regulated at the Ingress point where the user offered load and service usage time canbe measured. At the egress point, one can observe if the performance (e.g., throughput) is beingprovided in the manner expected and agreed upon.

Monitoring every customer SLS is scalable and feasible provided aggregate network performancemetrics are used combined with per SLS Ingress/Egress metrics. The monitoring process can becategorised based on the QoS/CoS profile of the offered services (mainly PHBs) and scope of theservices (Ingress and Egress points). The Network Monitoring instructs the Node Monitoring tomeasure the performance parameters and then it build a network view based on each specifiedcategory. Network Monitoring collects information about network-wide view of paths for every PHBsalong the paths and deduces an end-to-end performance view. SLS monitoring uses this information tobuild a view of the offered services to the customers. This is explained in more detail in the followingsections.

8.4.4.2 Functional ArchitectureThe SLS Monitoring functional architecture and its components are given in Figure 1. The functions ofeach block in explained in the next section. Arrows show the flow direction of messages or signalsamong SLS monitoring components as well as SLS monitoring components with external FunctionalBlocks. The circled numbers shows the sequence order of information flow.

Figure 64: SLS Monitoring Components and Sequence of Actions.

Performance DataAggregator

Performance Data Initiator/Collector

Ingress/EgressMonitoring

Report Generator

Customer Report

ManagementReport

AdmissionControl

4

1

Customer SLS & uni-directional SLSs are used for keeping track of Customer SLS and creating Service-Scope Tables.2

SLS Monitoring is always be active and this trigger is used for initiation of the monitoring action for new Services & Scopes.3

3

SLSMonitoringRepository

SL values percustomer

Initiation Collection

SLS MonitoringSLS Monitoring

SLS Manager(Check SL values against

SLS)

2

5 6

Customer SLS & other relevant data are passed.1

7

8

9

Action to be taken TrafficForecast

10

11

Action to be taken

SLSSubscription

&

SLSRepository

5 6

NetworkMonitoring



8.4.4.3 Functions of ComponentsSLS Monitoring takes its input from SLS repository (both customer SLS and resulting uni-directionalSLSs). Monitoring action is triggered when a new SLS is activated by Admission Control or SLSSubscription activates an SLS on behalf of the customer. The Monitoring action is stopped for theservices and scopes that no longer are used. The SLS monitoring components, shown in Figure 2, andtheir actions are specified as below.

• Performance and traffic data related to PHBs and scopes are collected from Network Monitoringor from Ingress/Egress Monitoring. The data collection is performed by "Performance DataInitiator/Collector".

• "Performance Data Initiator/Collector" also receives some sort of accounting information such asuser offered load and usage time and received throughput from Ingress/Egress Monitoring entitieson the ingress and egress nodes.

• Performance data and other related data, such as faults, link and device availability are used tocompute Service Level values based on service types and scopes and subsequently to deducecustomer SL values as the customer SLS indicators. These actions are performed by "PerformanceData Aggregator". The PDA constructs Service Level Tables (see section 2.3.1) and also initiatethe monitoring action for new services and scopes if required.

• "SLS Manager" keeps track of measured SL values. Customer SLS indicators are checked againstcontractual SLS values for each specific customer, in order to see the SLS conformance or todetect any violations.

• "Report Generator" provides necessary reports both to the customer and management by:

• Providing reports having enough information for the customer that the services were beingprovided in the manner expected and agreed upon. That is, customer SLS indicators and the resultsof SLS checks are reported to the customers.

• Producing regular and detailed reports to inform Management about SLSs status and also statingproblem areas that are causing the SLS not to be met. This information may include networkperformance, service level, and customer SLS indicators that Management requires for follow-upon service activity and possible corrective actions.

• SLS Manager provides the Traffic Forecast entity with the current network behaviour in terms ofSLS commitments and with appropriate traffic matrices in order to adjust any irregularities if somecustomers does not get the expected service.

• "SLS Monitoring Repository" is used to keep the observed customer SLS indicators.

8.4.4.4 Example - SLS Monitoring Based on Service Types and ScopesAs an example, two service types are requested and offered along A - B path (i.e., service type 1.a andservice type 2). All customers who use these services and path are affected by traffic conditions alongthis path. A customer requests a service type 1.a (VLL Pipe service between A and B). Two uni-directional SLSs are constructed for this VPN by SLS Subscription entity. PDA constructs Table 1 andTable 2 which specify the observed Service Level values along the paths A to B and B to A.Information in these tables can be used for any other customer who uses these services and scopes.These SL values (Table 1& 2) are used by PDA to construct Table 3 and deduce the customer SLSindicator.



Scope 1: Ingress A to Egress B Scope 2: Ingress B to Egress AService 1.aPHB-EF

Service 2PHB-AF

Service 1.aPHB-EF

Service 2PHB-AF

Delay value Delay valueIPDV value IPDV valuePacket loss ratio Packet loss ratioAvailability AvailabilityOther other

Table 1: Service Level values for Scope 1. Table 2: Service Level values for Scope 2.

Scope: Pipe VPN between A and BService 1.a

Delay valueIPDV value

Packet loss ratioAvailability

otherUsage Time xx:xx

Table 3: Service Level values for a Pipe VPN customer using service type 1.a.

It should be noted that more intelligent decisions should be made by PDA for the services (e.g., VPNHose and Pipe) in which much ingress and egress points are involved).



9 REFERENCES[ABAR] draft-abarbanel-idr-bgp4-te-01.txt, Abarbanel and Venkatachalam, IETF draft

[DS-MODEL] “An Informal Model for DiffServ Routers", Y. Bernet et al., draft-ietf-diffserv-model-04.txt, Work in Progress, May 2000

[D1.2] TEQUILA Consortium, Deliverable D1.2, Protocol and Algorithm Specification,November 2000

[DS-TERMS] "New terminology for diffserv", D. Grossman, draft-ietf-diffserv-new-terms-02.txt,work in progress

[FAUCH2000] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan. P. Cheval, J.Heinannen, "MPLS Support of Differentiated Services," IETF Internet Draft, June2000

[FUJITA00] N. Fujita, “Traffic Engineering Extensions to OSPF Summary LSA”, draft-fujita-ospf-te-summary-00.txt, work in progress, March 2000.

[JACQ] C. Jacquenet, “Providing Quality of Service Indication by the BGP-4 Protocol: theQOS_NLRI Attribute”, draft-jacquenet-qos-nlri-00.txt, July 2000.

[IRR] http://www.irrd.net/

[IS-DS-1] A Framework for Integrated Services Operation over DiffServ Networks - IETF IETFdraft http://www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-05.txt

[IS-DS-2] Integrated Service Mappings for Differentiated Services Networks. Networks - IETFIETF draft. http://www.ietf.org/internet-drafts/draft-ietf-issll-ds-map-00.txt

[KATZ99] D. Katz et al., “Traffic Engineering Extensions to OSPF”, draft-katz-yeung-ospf-traffic-01.txt, work in progress, October 1999.

[NUSSBACHER99] H. Nussbacher et al., “Global BGP Community Values”, draft-nussbacher-global-community-values-v1-00.txt, work in progress, November 1999.

[OMP99] C. Villamizar, “OSPF Optimized Multipath (OSPF-OMP)”, draft-ietf-ospf-omp-03-preview.ps, work in progress, April 1999.

[PHBSPEC] "Domain Per Hop Behavior Specification", draft-ronc-domain-phb-set-specification-00.txt, March 2000.

[QBONE] "Qbone Architecture (v1.0), Ben Teitelbaum (1999),http://www.internet2.edu/qos/wg/papers/qbArch/

[RFC-791] Internet Protocol. J. Postel. Sep-01-1981.

[RFC-1519] Classless Inter-Domain Routing (CIDR): an Address Assignment and AggregationStrategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September 1993.

[RFC-1583] J. Moy, “OSPF Version 2”, RFC 1583, March 1994.

[RFC-1657] Definitions of Managed Objects for the Fourth Version of the Border GatewayProtocol (BGP-4) using SMIv2. S. Willis, J. Burruss, J. Chu, Editor. July 1994.

[RFC 1661] "The Point-to-Point Protocol (PPP)",W.Simpson,tp://www.ietf.org/rfc/rfc1661.txt?number=1661

[RFC-1771] A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995.

[RFC-1997] BGP Communities Attribute. R. Chandra, P. Traina & T. Li. August 1996.

[RFC-1998] An Application of the BGP Community Attribute in Multi-home Routing. E. Chen, T.Bates. August 1996.



[RFC 2205] "Resource ReSerVation Protocol (RSVP)- Version 1 Functional Specification", R.Braden et al. http://www.ietf.org/rfc/rfc2205.txt?number=2205

[RFC-2328] OSPF Version 2. J. Moy. April 1998.

[RFC-2370] R. Coltun, “The OSPF Opaque LSA Option”, RFC 2370, July 1998.

[RFC-2386] A Framework for QoS-based Routing in the Internet, E. Crawley, R. Nair, B.Rajagopalan, H. Sandick, August 1998.

[RFC-2453] RIP Version 2. G. Malkin. November 1998.

[RFC-2461] Neighbor Discovery for IP Version 6 (IPv6), T. Narten, E. Nordmark, W. Simpson,December 1998.

[RFC 2474] "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6Headers", K.Nichols, S. Blake, F. Baker, D. Black, www.ietf.org/rfc/rfc2474.txt

[RFC-2475] "An Architecture for Differentiated Services", S. Blake, D. Black,M.Carlson,E.Davies,Z.Wang,W.Weiss, www.ietf.org/rfc/rfc2475.txt

[RFC-2519] A Framework for Inter-Domain Route Aggregation. E. Chen, J. Stewart. February1999.

[RFC 2597] "Assured Forwarding PHB Group", F. Baker, J. Heinanen, W. Weiss, J. Wroclawski,www.ietf.org/rfc/rfc2597.txt

[RFC 2598] "An Expedited Forwarding PHB", V.Jacobson, K.Nichols, K.Poduri,www.ietf.org/rfc/rfc2598.txt

[RFC-2622] Routing Policy Specification Language, C. Alaettinoglu, C. Villamizar, E. Gerich, D.Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra, June 1999.

[RFC-2676] QoS Routing Mechanisms and OSPF Extensions, G. Apostolopoulos,D. Williams, S. Kamat, R. Guerin, A. Orda, T. Przygienda, August 1999.

[RFC 2676] RFC 2676: QoS routing mechanisms and OSPF extensions

[RFC-2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell and J. McManus “Requirements forTraffic Engineering Over MPLS”, RFC 2702, September 1999.

[RFC-2748] D. Durham et al., “The COPS (Common Open Policy Service) Protocol”, RFC 2748,January 2000.

[RSVP-1] Inside the Internet’s Resource reSerVation Protocol David Durham, Ray Yavatkar(1999). ISBN 0-471-32214-8 Press. J. Wiley & Sons.

[TEQUILA-1] Service Level Specification Semantics, Parameters and negotiation requirements.Internet Draft < http://search.ietf.org/internet-drafts/draft-tequila-diffserv-sls-00.txt>,July 2000, Danny Goderis, Yves T’joens, Christian Jacquenet, George Memenios,George Pavlou, Richard Egan, David Griffin, Panos Georgatsos, Leonidas Georgiadis

[TWOBIT] "A Two-bit Differentiated Services Architecture for the Internet",ftp://ftp.ee.lbl.gov/parpers/dsarch.pdf, 1997



10 ACRONYMS AND ABBREVIATIONS

AAA Authentication, Authorisation and Accounting (IETF WG)AC Admission Control

ADSL Asymmetric Digital Subscriber LineAF Assured Forwarding

AFG Assured Forwarding GroupAPI Application Programming Interface

ARP Address Resolution ProtocolARPANET Advanced Research Projects Agency Network

AS Autonomous SystemATM Asynchronous Transfer Mode

ATMARP ATM ARPAVP Active Virtual Pipe

BA Behaviour-AggregateBAN Boundary Access Node

BB Bandwidth BrokerBCIT British Columbia Institute of Technology

BD Bandwidth DistributionBE Best Effort

BGP Border Gateway ProtocolBRI Basic Rate Interface

CAC Connection Admission ControlCAR Committed Access RateCBQ Class Based QueuingCBR Constant Bit Rate

CBWFQ Class-Based Weighted Fair QueuingCIM Common Information Model

CL ConnectionlessCLI Command Line Interface

CLIP Classical IP over ATMCMIP Common Management Information ProtocolCMIS Common Management Information Service

CO Connection OrientedCOPS Common Open Policy Service

CORBA Common Object Request Broker ArchitectureCoS Class of ServiceCPE Customer Premises EquipmentCPN Customer Premises NetworkCPU Central Processing Unit

CR Constraint-Based RoutingCRC Cyclic Redundancy Check

CR-LDP Constraint-Based Routing using LDPDBMS Database Management SystemDHCP Dynamic Host Configuration Protocol



DNS Domain Name SystemDrSM Dynamic Resource ManagementDRtM Dynamic Route Management

DS Differentiated ServicesDSC Differentiated Services Classifier

DSCP Differentiated Services Code PointDSR Differentiated Services Router (model)DTD Document Type DefinitionE2E End to End

eBGP Exterior Border Gateway ProtocolECMP Equal Cost Multi-Path

ECN Explicit Congestion NotificationEF Expedited Forwarding

EGP Exterior Gateway ProtocolEIGRP Enhanced Interior Gateway Routing Protocol

FB Functional BlockFIB Forwarding Information Base

FIFO First In First OutFM Functional ModelFQ Fair Queuing

FSM Finite State MachineFTP File Transfer ProtocolGoS Grade of ServiceGTS Generic Traffic ShapingGUI Graphical User Interface

HDLC High-Level Data Link ControlHTML Hypertext Markup LanguageHTTP Hypertext Transfer ProtocoliBGP Interior Border Gateway Protocol

I-D Internet DraftIETF Internet Engineering Task Force

IGMP Internet Group Management ProtocolIGP Interior gateway protocol

IGRP Interior Gateway Routing ProtocolISSLL Integrated Services Support over different Link Layers (IETF WG)

IP Internet ProtocolIPPM IP Performance MetricsIPSec IP Security Protocol

IS Integrated ServicesISDN Integrated Services Digital Network

ISP Internet Service ProviderL3 Layer 3 (IP)

LAN Local Area NetworkLANE LAN EmulationLDAP Lightweight Data Access Protocol

LDP Label Distribution Protocol



LER Label Edge RouterLSA Link State Advertisement

LSDB Link State Data BaseLSP Label Switched PathLSR Label Switched Router

MAC Media Access ControlMAN Metropolitan Area NetworkMDT Mean Down Time (per year)

MF Multi-FieldMIB Management Information Base

MPLS Multi-Protocol Label SwitchingMSC Message Sequence ChartMTU Maximum Transfer UnitNAT Network Address Translator

NE Network ElementNFS Network File SystemNIC Network interface cardNM Network managementNN Network NodeNP Network Planning

NRM Network Resource MonitoringNW Network

OAM Operations, Administration and MaintenanceOMP Optimised Multi-Path

OO Object OrientedORB Object Request Broker

OSPF Open Shortest Path FirstPCI Protocol Control Information

PDP Policy Decision PointPDU Protocol Data Unit

PE Provider EdgePEP Policy Enforcement PointPFQ Packet Fair QueuingPHB Per Hop BehaviourPIB Policy Information BasePPP Point-to-Point ProtocolPQ Priority QueuingPS Premium Service

PVC Permanent Virtual ChannelQoS Quality of Service

RADIUS Remote Authentication Dial-In User ServiceRAR Resource allocation request

RDBMS Relational database management systemRED Random Early DetectionREQ RequestRFC Request for Comments



RIB Routing Information BaseRIO Random Early Drop with In/Out bitRIP Routing Information Protocol

RPC Remote Procedure CallRSVP Resource Reservation Protocol

RT Real TimeSBM Subnet Bandwidth Manager/Solaris Bandwidth ManagerSDH Synchronous Digital HierarchySDL Specification and Description LanguageSFQ Stochastic Fair QueuingSLA Service Level AgreementSLIP Serial Line Internet ProtocolSLS Service Level Specification

SNA System Network ArchitectureSNMP Simple Network Management Protocol

SoA State of the ArtSONET Synchronous Optical Network

SPF Shortest Path FirstSQL Structured Query LanguageSSL Secure Sockets Layer

STM Synchronous Transfer ModeSVC Switched Virtual Channel

TC Traffic ConditioningTCP Transmission Control Protocol

TE Traffic EngineeringTLV Type Length Value

TMN Telecommunications Management NetworkToS Type of ServiceTQ TEQUILA

TTL Time to LiveTTR Time to RepearUDP User Datagram ProtocolUML Unified Modelling LanguageUNI User Network Interface

VBR Variable Bit RateVC Virtual Channel

VLAN Virtual LANVLL Virtual Leased LineVoD Video on DemandVoIP Voice over IP

VP Virtual PathVPC Virtual Path ConnectionVPN Virtual Private Network

WAN Wide Area NetworkWFQ Weighted Fair Queuing

WG Work Group



WRED Weighted Random Early DetectionWP Work Package

XML eXtensible Mark-up Language

Documents

D1.1: Functional Architecture Definition and Top Level · PDF fileD1.1: Functional Architecture Definition and Top Level Design Page 1 of 172 CEC Deliverable Number: 101/Alcatel/b1