Download D1.1: Functional Architecture Definition and Top Level

D1.1: Functional Architecture Definition and Top Level Design
Page 1 of 172
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’Joens
Algosystems: Panos Georgatsos, Leonidas Georgiadis
FT-R&D: Christian Duret, Jean-Pierre Garbisu, Christian Jacquenet
IMEC: Steven Van den Berghe, Pim Van Heuven
NTUA: Dimitris Giannakopoulos, Eleni Mykoniati, George Memenios
Global Crossing (RACAL): Hamid Asgari, Richard Egan
UCL: David Griffin, Lionel Sacks
UniS: Carlos Frederico Cavalcanti, Antonio Liotta, George Pavlou, Ilias
Andrikopoulos, Paris Flegkas, Panos Trimintzios
Workpackage(s):
WP1
Abstract:
WP1 is concerned with the functional architecture, the system design and
related protocols and algorithms for providing End-to-End QoS in the
Internet. After summarising the System Requirements, this deliverable details
the TEQUILA functional model, defines the SLS-template and -semantics
and specifies the QoS-aware Intra-and Inter-domain Traffic Engineering
approaches. The theoretical model is completed by outlining the Policy and
Monitoring Framework.
Keyword List:
CoS, DiffServ, IntServ, Internet, IP, MPLS, QoS, Quality of Service, System
Requirements, Network Management, Resource Management, Route
Management, Traffic Engineering, Service Level Specification, SLS, Policy
Framework, Monitoring Framework, Functional Model, Functional Block
Decomposition, Message Sequence Chart.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 2 of 172
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’Joens
Algosystems: Panos Georgatsos, Leonidas Georgiadis
FT-R&D: Christian Duret, Jean-Pierre Garbisu, Christian Jacquenet
IMEC: Steven Van den Berghe, Pim Van Heuven
NTUA: Dimitris Giannakopoulos, Eleni Mykoniati, George Memenios
Global Crossing (RACAL): Hamid Asgari, Richard Egan
UCL: 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
Algosystems S.A.
FT-R&D
IMEC
NTUA
Global Crossing (RACAL)
UCL
TERENA
UniS
Co-ordinator
Principal Contractor
Principal Contractor
Principal Contractor
Principal Contractor
Principal Contractor
Principal Contractor
Assistant Contractor
Principal Contractor
CEC Deliverable Number: 101/Alcatel/b1
Belgium
Greece
France
Belgium
Greece
United Kingdom
United Kingdom
The Netherlands
United Kingdom
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 3 of 172
Executive Summary
TEQUILA’s main objective is to study, specify, implement and validate service definition and Traffic
Engineering (TE) tools for the Internet. The TEQUILA system should provide both quantitative and
qualitative service guarantees through planning, dimensioning and dynamic control of traffic
management 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 and
complexity only at network edges while the transit routers are responsible for applying appropriate
forwarding treatment to incoming IP packets according to their Differentiated Services (DS) field of
the 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 DiffServ
edge routers, i.e. filters, meters, markers, etc.
The network operator has now at his disposal a series of DiffServ (essentially data-plane) building
blocks, 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 top
of this. The DiffServ architecture has some shortcomings at this time. Deploying QoS sensitive
customer applications over the Internet requires a clear and unique concept of services, service classes
and the related technical “IP-parameters” describing these services and their guarantees. Once the
service demands imposed on the network are clearly expressed, advanced “QoS networking” comes
into play for coping with these (ever-changing) demands. In order to provide end-to-end quantitative
service guarantees, both across single and multiple Internet Service Providers (ISPs), the network
architecture should be augmented with intelligent network dimensioning, operational and management
functions. 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 DiffServ
architecture 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: The
TEQUILA Functional Architecture. D1.1 describes the main architectural (sub-)frameworks explored
within the TEQUILA project, including the Service Level Specification definition and handling
framework, the traffic engineering and network dimensioning framework, the monitoring and
measurement framework and the policy based networking framework.
By adopting a system approach, the overall functionality has been described, by isolating specific
functionality in functional blocks. This deliverable provides an overview for each identified functional
block 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 decision
process.
The purpose of providing such an extensive functional description is twofold. First it allows the
problem of scalable end-to-end IP QoS/CoS provisioning to be decomposed into small and feasible
sub-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, to
separate complex and time consuming tasks from highly dynamic and, as such, time critical tasks
while constructing the full TEQUILA system.
Based upon this functional architecture, and partly in parallel, the necessary protocol and algorithmic
work is being undertaken and will be documented in D1.2. This should lead to a first complete system
description by November 2000. The TEQUILA Functional Model extends the DiffServ architecture
mainly in two dimensions.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 4 of 172
•
The (technical) modelling of the interactions between customers (or other network operators) and
the TEQUILA operator, mainly through the functions SLS Management, Traffic Forecast and
Network Dimensioning (from left-to-right in Figure 4Figure 4). This deals with functions in the
Management plane (e.g. Service – SLS subscription) and in the Control plane (e.g. admission
control). 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, Dynamic
Route and Resource Management and – finally - the data-plane functions such as routing and
DiffServ Traffic Conditioning and PHB enforcement (top-down in Figure 4). The framework
ensures that existing SLSs are adequately provisioned and that future SLSs may be negotiated and
delivered through a combination of static, quasi-static and dynamic Traffic Engineering
techniques within network domains and on an inter-domain basis. It proposes solutions for
operating networks in an optimal fashion through planning and dimensioning and subsequently
through dynamic operations and management functions (“first plan, then take care”).
The structure of this document reflects these two main dimensions of the TEQUILA project. Chapter
four discusses in detail Service Level Specifications, while chapter five brings together everything
concerning 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 TEQUILA
consortium towards standardisation, i.e. the IETF Internet Draft (I-D) “Service Level Specification
Semantics, Parameters and negotiation requirements” [TEQUILA-1].
Indeed, the consortium firmly believes that standardisation of the SLS content and format is required
when considering the deployment of value-added IP service offerings over the Internet. Since these IP
services are likely to be provided over the whole Internet, their corresponding QoS will be based upon
a set of technical parameters that both customers and services providers will have to agree upon. Such
agreements, and especially the negotiations preceding them, will be greatly simplified in the presence
of a standardised set of (technical) SLS parameters. An SLS standard is also necessary to be able to
allow for a highly developed level of automation and dynamic negotiation of SLSs between customers
and 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 all
of the above features, especially automation and dynamic SLS-negotiation between customers and
ISPs. The negotiation protocol itself will be specified in D1.2.
The SLS semantics defined in [TEQUILA-1] allows multi-service deployment over the future Internet
by offering a variety of service quality levels. These ranges from those with explicit, hard performance
guarantees for bandwidth, loss and delay characteristics (“Premium services”) down to low-cost
services based on best-effort traffic, with a range of services receiving qualitative traffic assurances
occupying 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/CoS
contracts. Qualitative guarantees may be useful for defining “Olympic services”, which should allow
network operators or business users to e.g. differentiate between traffic of sales people (priority, less
delay) and research engineers. Another application could be the differentiation between (on-line) webbrowsing services and (background) e-mail traffic. Web browsing could be of the “silver class” while
the e-mail is only tagged as “bronze”.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 5 of 172
Besides the SLS format, this document also describes key functions enabling the network to
effectively handle the SLS contracts between customer and (TEQUILA) operator. Such key
components 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 of
Integrated Services (IntServ) over the TEQUILA DiffServ network. IntServ Guaranteed Service and
Controlled Load are “Premium micro-flow services”. It is described how RSVP Messages are captured
by the TEQUILA Functional Model and how the information of the RSVP Objects, e.g. TSpec and
RSpec, is mapped onto the DiffServ SLSs. Once these “IntServ” SLSs are created, they are handled by
the TEQUILA management system as all others.
Traffic Engineering
Network Traffic Engineering (TE) is in general the process of specifying the manner in which traffic is
treated within a given network. TE has user-oriented as system-oriented objectives. The users expect
certain performance from the network, which in turn should attempt to satisfy these expectations. The
expected performance depends on the type of traffic that the network carries, and is specified in the
SLS contract between customer and ISP. The network operator on the other hand attempts to satisfy
the user traffic requirements in a cost-effective manner. Hence he/she attempts to accommodate as
many 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 routing
method used today in the Internet is shortest-path routing with respect to certain link cost, e.g. OSPF
for intra-domain routing. In the framework of multi-service QoS provisioning, however, such an
approach may not be desirable always since it may lead to bottleneck creation and the chosen path may
not 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 and
provisioning may – in theory - either be centralised or distributed. However, a pure IP-TE approach
will rather be based on the distributed approach, while the MPLS approach could very well be a mix of
centralised 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 which
are not constructed solely from MPLS-capable equipment.
The document also discusses possible QoS-aware inter-domain TE methods based on BGP4
extensions. 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 a
definite choice at this stage of the project. The models differ depending on what information is flooded
through the Internet by BGP. The information can be very basic, e.g. just announcing the Service
Capability of an autonomous system, or a set of QoS parameters (delay, bandwidth) could be
distributed. 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 expected
results, the following can be concluded:
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 6 of 172
•
The framework, i.e. the TEQUILA functional model, is put in place. Functions, semantics and
interfaces are described in sufficient detail to allow the development of the algorithms and
protocols to proceed as planned.
•
The SLS format and semantics have been defined and agreed by the project. This work resulted in
a TEQUILA contribution towards the IETF [TEQUILA-1]
•
Specification of protocols, in particular the SLS negotiation protocol, is now underway and these
will 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, and
based on, the functional model. Development of the algorithms, e.g. resource and route
calculations, is now underway and these will be documented in Deliverable D1.2.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 7 of 172
Table of Contents
1
INTRODUCTION ........................................................................................................................................ 12
1.1 THE TEQUILA PROJECT ....................................................................................................................... 12
1.2 ROLE OF WP1 AND THIS DELIVERABLE ................................................................................................. 13
1.3 STRUCTURE OF THIS DOCUMENT ............................................................................................................ 14
2
REQUIREMENTS, ASSUMPTIONS AND DEFINITIONS OVERVIEW................................................. 16
2.1 GENERIC DEFINITIONS AND REQUIREMENTS .......................................................................................... 16
2.2 NETWORK ARCHITECTURAL ASSUMPTIONS............................................................................................ 16
2.2.1 The Customer Premises Network Architecture..............................................................................17
2.2.2 The Access Network Architecture ..................................................................................................17
2.2.3 The Core Network Architecture .....................................................................................................17
2.2.4 The Roaming Architecture .............................................................................................................18
2.3 GENERAL END TO END COS/QOS IN THE INTERNET.............................................................................. 18
2.3.1 Flows vs. MicroFlows .....................................................................................................................18
2.3.2 CoS vs. QoS .....................................................................................................................................18
2.3.3 Applications.....................................................................................................................................19
2.3.4 CoS/QoS architectures....................................................................................................................19
2.3.5 Basic Traffic Management Blocks .................................................................................................21
2.3.6 Policy framework ............................................................................................................................21
2.4 INTRA-DOMAIN COS/QOS ASPECTS ........................................................................................................ 22
2.4.1 General TE Requirements ..............................................................................................................22
2.4.2 Layer 3 TE requirements ................................................................................................................22
2.4.3 MPLS TE requirements..................................................................................................................23
2.4.4 Survivability Requirements.............................................................................................................23
2.4.5 Measurement Requirements ...........................................................................................................23
2.4.6 Capacity Control and Management Requirements........................................................................23
2.5 INTERDOMAIN QOS ASPECTS .................................................................................................................. 24
2.6 NON-TECHNICAL REQUIREMENTS ........................................................................................................... 24
3
THE TEQUILA FUNCTIONAL MODEL................................................................................................... 25
3.1 POLICY MANAGEMENT ........................................................................................................................... 25
3.2 NETWORK PLANNING .............................................................................................................................. 26
3.3 NETWORK DIMENSIONING ...................................................................................................................... 27
3.4 TRAFFIC FORECAST................................................................................................................................. 27
3.5 SLS MANAGEMENT ................................................................................................................................. 28
3.5.1 SLS Subscription.............................................................................................................................28
3.5.2 Admission Control – SLS Invocation.............................................................................................29
3.5.3 Inter-domain SLS requestor ...........................................................................................................29
3.6 USER & UPSTREAM ISP/AS’S INTER-DOMAIN SLS REQUESTOR .......................................................... 29
3.7 TRAFFIC CONDITIONING ......................................................................................................................... 30
3.8 MONITORING ........................................................................................................................................... 30
3.9 DYNAMIC ROUTE MANAGEMENT ........................................................................................................... 32
3.10
DYNAMIC RESOURCE MANAGEMENT................................................................................................. 32
3.11
ROUTING .............................................................................................................................................. 32
3.12
PHB ENFORCEMENT ........................................................................................................................... 33
3.13
OTHER ISP/AS .................................................................................................................................... 33
3.14
EXAMPLE: BOOTSTRAPPING THE TEQUILA NETWORK ..................................................................... 33
3.14.1
Assumptions.................................................................................................................................33
3.14.2
Zero Phase ...................................................................................................................................33
3.14.3
Bootstrapping Message Sequence Chart ....................................................................................34
4
SERVICE LEVEL SPECIFICATIONS........................................................................................................ 37
4.1 MOTIVATION AND FRAMEWORK ............................................................................................................. 38
4.2 SLS CONTENTS & SEMANTICS ................................................................................................................ 39
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 8 of 172
4.2.1 Scope ...............................................................................................................................................39
4.2.2 Flow Identification .........................................................................................................................40
4.2.3 Traffic Conformance Testing .........................................................................................................41
4.2.4 Marking and shaping services prior to Conformance Testing ......................................................41
4.2.5 Excess Treatment............................................................................................................................42
4.2.6 Performance Parameters ................................................................................................................42
4.2.7 Service schedule..............................................................................................................................44
4.2.8 Reliability ........................................................................................................................................45
4.3 EXAMPLES: SERVICE TYPES & CUSTOMER SERVICES .......................................................................... 46
4.3.1 Quantitative (QoS - Premium) services..........................................................................................46
4.3.2 Qualitative (CoS – Olympic) services .............................................................................................47
The Funnel Service......................................................................................................................................48
4.3.4 Best Effort traffic ............................................................................................................................49
4.3.5 Bi-directional Virtual Leased Line.................................................................................................49
4.3.6 “Hose” Virtual Private Networks ...................................................................................................49
4.4 SLS HANDLING – FUNCTIONAL SCENARIOS .......................................................................................... 52
4.4.1 Introduction on Traffic Forecast & Prediction .............................................................................52
4.4.2 SLS-Management, Traffic Forecast & Dimensioning ..................................................................53
4.4.3 Inter-Domain SLS negotiation .......................................................................................................56
4.4.4 SLS-subscription & -Invocation inter-working .............................................................................59
4.4.5 SLS Subscription handling.............................................................................................................61
4.4.6 Admission Control - SLS Invocation handling..............................................................................64
4.4.7 Examples .........................................................................................................................................66
4.5 INTEGRATED SERVICES SUPPORT ........................................................................................................... 70
4.5.1 IntServ over DiffServ : General architecture.................................................................................70
4.5.2 IntServ & the Tequila Functional Model.......................................................................................73
4.5.3 The Exterior RSVP Gateway Model...............................................................................................75
4.5.4 Native IntServ support ....................................................................................................................76
4.5.5 QoS Mapping On DiffServ PHBs...................................................................................................79
SLS MANAGEMENT – FUNCTIONAL BLOCK DECOMPOSITION ...................................................................... 81
4.6.1 Description of Functions ................................................................................................................81
4.6.2 Interface semantics and parameters...............................................................................................85
5
TRAFFIC ENGINEERING .......................................................................................................................... 88
5.1 INTRA-DOMAIN TRAFFIC ENGINEERING ................................................................................................. 88
5.1.1 Objectives and Approaches.............................................................................................................88
5.1.2 Elementary TE Functions and the TEQUILA TE Functional Model ..........................................89
5.1.3 MPLS-based Traffic Engineering ..................................................................................................90
5.1.4 Pure IP-based Traffic Engineering................................................................................................95
5.2 TRAFFIC ENGINEERING: FUNCTIONAL BLOCK DECOMPOSITION ....................................................... 101
5.2.1 Network Dimensioning .................................................................................................................101
5.2.2 Dynamic Resource Management .................................................................................................109
5.2.3 Dynamic Route Management .......................................................................................................113
5.3 MESSAGE SEQUENCE CHARTS .............................................................................................................. 118
5.3.1 MPLS-based TE............................................................................................................................118
5.3.2 Link Failure Handling .................................................................................................................119
5.4 INTER-DOMAIN TRAFFIC ENGINEERING ............................................................................................... 123
5.4.1 Problem Description .....................................................................................................................123
5.4.2 Current BGP and inter-domain TE..............................................................................................125
5.4.3 TE Extensions of BGP..................................................................................................................127
5.4.4 Model 1: “QOS parameters” model .............................................................................................128
5.4.5 Model 2: “CoS capability” model.................................................................................................136
5.4.6 Single-path BGP versus Multi-path BGP ....................................................................................136
5.4.7 Conclusion ....................................................................................................................................138
6
DATA-PLANE FUNCTIONS.................................................................................................................... 139
6.1 TRAFFIC CONDITIONING ....................................................................................................................... 139
6.1.1 Overview ........................................................................................................................................139
6.1.2 Functional Elements.....................................................................................................................139
6.1.3 Examples for the Tequila SLSs ....................................................................................................141
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 9 of 172
6.1.4 Interface semantics and parameters.............................................................................................142
6.2 PHB ENFORCEMENT ............................................................................................................................. 143
6.2.1 Description of Functions ..............................................................................................................143
6.2.2 Interface semantics and parameters.............................................................................................144
7
POLICY FRAMEWORK ........................................................................................................................... 145
7.1 DESCRIPTION OF FUNCTIONS ................................................................................................................ 145
7.1.1 Policy Management Tool..............................................................................................................145
7.1.2 Policy Storing Service ...................................................................................................................146
7.1.3 Policy Consumer ...........................................................................................................................146
INTERFACE SEMANTICS AND PARAMETERS ................................................................................................... 147
7.3 FINITE STATE MACHINES ...................................................................................................................... 149
7.3.1 The Policy Management Tool FSM .............................................................................................149
7.3.2 The Policy Storing Service FSM ..................................................................................................152
7.3.3 The Policy Consumer FSM ..........................................................................................................154
8
MONITORING FRAMEWORK................................................................................................................ 157
8.1 INTRODUCTION ...................................................................................................................................... 157
8.2 MESSAGE SEQUENCE CHART ................................................................................................................ 157
8.3 FUNCTIONAL BLOCK DECOMPOSITION ................................................................................................ 159
Architecture................................................................................................................................................159
8.3.2 Functions ......................................................................................................................................159
8.3.3 Interfaces.......................................................................................................................................160
8.3.4 Finite State Machine.....................................................................................................................161
8.3.5 Algorithm and Protocol Problem Description .............................................................................161
8.4 SLS MONITORING ................................................................................................................................. 161
8.4.1 Introduction ..................................................................................................................................161
8.4.2 Service Subscription......................................................................................................................161
8.4.3 SLS Monitoring Framework ........................................................................................................161
8.4.4 Functional Block Decomposition of SLS Monitoring .................................................................162
9
REFERENCES .................................................................................................................... ....................... 166
10
ACRONYMS AND ABBREVIATIONS ................................................................................................... 168
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 10 of 172
List of Figures
Figure 1: The Internet Architecture ...................................................................................................................... 16
Figure 2: TEQUILA network architecture ............................................................................................................ 17
Figure 3: The generic policy architecture............................................................................................................. 22
Figure 4: The TEQUILA Functional Architecture. ............................................................................................... 25
Figure 5: The Policy Management Functional Block............................................................................................ 26
Figure 6: The SLS Management Functional Block and its interactions with other blocks.................................... 28
Figure 7: Decomposition of the User-Upstream ISP/AS functional block and interactions with others............... 30
Figure 8: Decomposition of the Monitoring functional block and its interactions with others............................. 31
Figure 9: Zero Phase Message Sequence Chart ................................................................................................... 34
Figure 10: Bootstrapping Phase Message Sequence Chart .................................................................................. 36
Figure 11: the funnel model .................................................................................................................................. 48
Figure 12: Four Uni-directional Hoses................................................................................................................. 50
Figure 13: VPN with 8 SLSs.................................................................................................................................. 51
Figure 14: SLS-Management, Traffic Forecast and NW-Dimensioning (1).......................................................... 53
Figure 15: SLS Management, Traffic Forecast & NW Dimensioning (2) ............................................................. 55
Figure 16: Hop-by-Hop SLS negotiation .............................................................................................................. 56
Figure 17: End-to-End SLS negotiation based on “Internet pipes”...................................................................... 57
Figure 18: Local SLS negotiation without guarantees .......................................................................................... 58
Figure 19: MSC of the SLS subscription process .................................................................................................. 63
Figure 20: Dynamic SLS Invocation MSC ............................................................................................................ 65
Figure 21: IntServ support over a DiffServ network ............................................................................................. 70
Figure 22: IS-DS functional block diagram .......................................................................................................... 72
Figure 23: two business scenarios ........................................................................................................................ 73
Figure 24: Native IntServ support......................................................................................................................... 73
Figure 25 : The RSVP gateway business scenario ................................................................................................ 75
Figure 26: Native IntServ flow support ................................................................................................................. 76
Figure 27: SLS Management - Functional Block Decomposition ......................................................................... 81
Figure 28: Interaction of the SLS Management Functional Block with others ..................................................... 85
Figure 29: Functional blocks involved in intra-domain traffic engineering ......................................................... 90
Figure 30: Long-term MPLS Traffic Engineering................................................................................................. 91
Figure 31: Bandwidth Allocation Under the Hose Scope Model .......................................................................... 93
Figure 32: Functional architecture of the IP-based traffic engineering approach ............................................... 97
Figure 33: Interaction of the Network Dimensioning Functional Block ............................................................. 102
Figure 34: The Finite State Machine of the Dimensioning Functional Block. .................................................... 105
Figure 35: Dynamic Resource Management ....................................................................................................... 110
Figure 36 Interfaces between Dynamic Resource Management and other functional blocks ............................. 111
Figure 37: Dynamic Route Management............................................................................................................. 114
Figure 38: Dynamic Routing Process ................................................................................................................. 115
Figure 39 - Interfaces between Dynamic Route Management and other functional blocks ................................ 116
Figure 40: MPLS Traffic Engineering Parameter Updates ................................................................................ 118
Figure 41: MPLS Traffic Engineering Triggering of Updates ............................................................................ 119
Figure 42: Link usage policy............................................................................................................................... 120
Figure 43: Protection Switching MSC ................................................................................................................ 121
Figure 44: Restoration MSC ............................................................................................................................... 122
Figure 45: The TEQUILA system ........................................................................................................................ 123
Figure 46: Automated enforcement of a BGP4 routing policy -.......................................................................... 126
Figure 47: “QoS parameters” model.................................................................................................................. 128
Figure 48: QoS-NLRI attribute ........................................................................................................................... 129
Figure 49: code and sub-code combinations....................................................................................................... 130
Figure 50: level of aggregation (1) ..................................................................................................................... 131
Figure 51: level of aggregation (2) ..................................................................................................................... 132
Figure 52: level of aggregation (3) ..................................................................................................................... 132
Figure 53: Calculations for delay aggregation ................................................................................................... 134
Figure 54: Aggregating delays............................................................................................................................ 134
Figure 55: “CoS capability” model .................................................................................................................... 136
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 11 of 172
Figure 56 Policy Management Functional Block Decomposition....................................................................... 145
Figure 57: Interaction of the PolicyManagement Functional Block with others ................................................ 147
Figure 58: The Policy Management Tool FSM. .................................................................................................. 149
Figure 59: The Policy Storing Service FSM........................................................................................................ 152
Figure 60: The Policy Consumer FSM................................................................................................................ 154
Figure 61: Monitoring feedback MSC................................................................................................................. 158
Figure 62: Monitoring Architecture.................................................................................................................... 159
Figure 63: Node Monitoring and Ingress/Egress Monitoring............................................................................. 162
Figure 64: SLS Monitoring Components and Sequence of Actions..................................................................... 163
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 12 of 172
1 INTRODUCTION
1.1 The TEQUILA Project
The overall objective of TEQUILA is to study, specify, implement and validate service definition and
traffic engineering tools for the Internet. The TEQUILA system should provide qualitative and close to
quantitative service guarantees through planning, dimensioning and dynamic control of qualitative
traffic management techniques based on DiffServ. TEQUILA 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 other main dimension of the
project studies intra- and inter-domain traffic engineering schemes to ensure that the network can cope
with 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 the
TEQUILA functional model and the TEQUILA SLS template and its semantics. The deliverable gives
a detailed functional decomposition of the system, the specific network functions and the necessary
information streams between the functional components.
The overall work in the TEQUILA project is split over 3 WorkPackages (WPs), and follows a phased
approach: a theoretical phase followed by a refinement phase and then an experimentation and
dissemination phase.
WP1 - Functional Architecture and Algorithms - (which is responsible for the production of this
document) specifies the system architecture and related protocols and algorithms. WP2 - System
Design and Implementation - develops the system components and simulators. WP3 - Integration
Validation, Assessment and Experimentation - configures the testbed and conducts experiments on the
TEQUILA system through the testbed prototypes and the simulators.
During the first phase of the project, WP1 specifies the system functional and architectural
requirements, while WP2 analyses the capabilities of existing simulation tools, available routers and
development technologies. These results can be found in respectively in the deliverables D1.1 – which
is this document – and deliverable D2.1 Subsequently, WP1 focuses on the system architecture and
specification of protocols and algorithms while WP2 undertakes the adaptation of the selected
simulation tools, routers and development tools.
In the second phase of the project, WP2 realises appropriate simulation models and prototypes using
the tools, components and infrastructure as selected in this deliverable. The developed simulation
models and system prototypes are delivered to WP3 where tests are executed. The test results and
experience are fed back to WP1 for revising accordingly the specified mechanisms, protocols and
algorithms. 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 TEQUILA
system by undertaking experimentation and demonstration activities.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 13 of 172
1.2 Role of WP1 and this Deliverable
WP1 ’Functional Architecture and Algorithms’ is concerned with the specification of the system
architecture and related protocols and algorithms. During the first, theoretical phase of the project,
WP1 undertakes an analysis of requirements regarding service provisioning, detailing the assumptions
regarding user access means, service provisioning and network capabilities. During the second phase
of the project, WP2 realises appropriate simulation models and prototypes. These are fed to WP3
where a set of comprehensive simulation runs and tests are executed. The test results and experience
are fed back to WP1 for revising accordingly the specified mechanisms, protocols and algorithms. The
revisions are fed to WP2 and the final prototypes are implemented.
In the theoretical phase WP1 first concentrated on specifying the requirements. A summary of this
work and an overview of the system requirements, assumptions and definitions can be found in this
document (chapter 2). A detailed description of the requirements, resulting from an in-dept State-ofthe Art study of IP QoS in the Internet, per functional are, can be found in the technical annex to this
document.
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 Traffic
Engineering 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 this
document, and Deliverable D1.2, Protocol and Algorithm Specification [D1.2]. D1.1 describes the
functional architecture of the TEQUILA system. D1.2 starts where D1.1 ends. Indeed, while D1.1 is
still algorithm- and protocol- transparent, D1.2 aims at a full system design by specifying the
algorithms and protocols. Thus D1.1 specifies the semantics, interactions and interfaces while D1.2
will specify the protocols, algorithms and Top Level Design.
This deliverable provides a detailed functional decomposition of the system, thereby identifying
specific network functions, related problem statements, and the necessary information streams between
the identified functional components. The main results of this deliverable can be summarised as
follows:
•
Definition of the TEQUILA Functional Model. Starting from a high level view, describing main
interactions 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 how
the TEQUILA system actually should work.
•
Definition of the TEQUILA Service Level Specification and description of its semantics. This
work resulted in a first contribution of the TEQUILA consortium towards standardisation, i.e. the
IETF Internet Draft (I-D) “Service Level Specification Semantics, Parameters and negotiation
requirements” [TEQUILA-1]. Besides the SLS format, the document also describes key functions
enabling the network to effectively handle the SLS contracts between customer and (TEQUILA)
operator. Such key components include amongst others, SLS-monitoring and SLS Subscription and
Invocation handling (including Admission Control).
•
Description of the QoS-aware Traffic Engineering Operations, based on the (inter-) working of
the several functional blocks identified by the Functional Model. TE should actually ensure the
customers that their QoS-requirements, I.e. SLSs, are actually met AND – at the same time – TE
should provide an optimal utilisation of resources in a Multi-service IP network. The document
contains a description of the intra-and inter-domain Traffic Engineering approaches, which will be
followed in the TEQUILA project. It includes MPLS-based and pure IP-based intra-domain TE
approaches. TE involves amongst others Network Dimensioning, (dynamic) Resource and Route
Management and the basic packet-routing, -buffering, -scheduling and -forwarding operations.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 14 of 172
1.3 Structure of this document
Chapter 2 - Requirements, Assumptions and Definitions Overview - introduces and discusses the
initial output from the first few months’ activity in WP1. This is an important chapter, not only for this
deliverable, but also for the project as a whole. It sets the direction of the theoretical, practical and
experimental work of the consortium and has had a strong influence on the reviews and selections
made in this report. More details can be found in the Technical Annex: IP QoS State of the Art
Overview, Requirements and Assumptions. It reviews the current and emerging standardisation work
within the domain of the TEQUILA project, together with the current state of the art (SoA) as viewed
by the Internet industry and research community.
Chapter 3 – The Tequila Functional Model – gives the TEQUILA functional model. Starting from the
overall 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 PHB
Enforcement.
The chapter ends with a Message Sequence Chart (MSC) for the Bootstrapping phase of a TEQUILA
network. The MSC describes the interaction between the several function blocks and the bootstrapping
example mainly serves as an illustration for the Functional Model. The next chapters discuss more the
details of each block and the interaction between them.
Chapter 4 – Service Level Specifications first describes the SLS format and semantics as it is defined
and adapted by the TEQUILA consortium. The SLS contains amongst others the essential Traffic
Conformance Parameters and QoS Performance Guarantees. The chapter also gives some examples of
IP Services, which can be formally described based on the TEQUILA SLS. Examples include the IP
Premium 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 DiffServ
network should actually handle new or modified SLSs. The section SLS handling – Functional
scenarios, is about the interaction of the SLS Management Functional Block with others. An
introduction discusses the main information streams and interactions between SLS management,
Traffic Forecast and Network Dimensioning. It gives a high-level understanding of the SLS-treatment
at an intra-domain level. Inter-domain SLS negotiation is an open area of research and a sub-section
lists possible SLS-negotiation scenarios: Hop-by-Hop, End-to-End or Local SLS negotiation. Further
details of SLS Management and the Message Sequence Charts are treated in SLS-Subscription and
SLS-Invocation handling. Thus, a clear distinction is made 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 chapter concludes with a contribution on the support of Integrated Services (IntServ) over the
TEQUILA DiffServ IP network. The section describes how the TEQUILA DiffServ network is able to
support the IntServ Guaranteed Service and Controlled Load. The technical framework depends upon
the adapted Business Model, which can either be the “Exterior RSVP Gateway” model or the “Native
IntServ Support” model. The latter one is the real technical challenge. The document describes how
RSVP Messages are captured by the TEQUILA Functional Model and how the information of the
RSVP 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 the
essential QoS TE-objectives and -approaches, i.e. user-oriented versus resource-oriented objectives,
centralised versus distributed and connection-oriented versus connectionless, the chapter describes
how basic TE-functions are handled by the TEQUILA functional blocks. Two TE approaches are hold
back 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 Intradomain Traffic Engineering: Network Dimensioning, Dynamic Resource Management and Dynamic
Route Management.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 15 of 172
The third section of this chapter discusses possible QoS-aware inter-domain TE methods based on
BGP4 extensions. Several approaches are explained and pros and cons are put forward, without
however making a definite choice at this stage of the project. The models differ depending on what
information is flooded through the Internet by BGP. The information can be very basic, e.g. just
announcing the Service Type Capability (e.g. “Premium” or “Gold Olympic”) of an autonomous
system, or a set of QoS parameters (delay, bandwidth) could be distributed. Two partners introduced
an IETF Internet Draft on this topic [JACQ, ABAR].
The chapter ends with some message sequence charts (MSCs) illustrating the interactions between the
functional blocks. MSCs are given for long- and short-term MPLS-based Traffic engineering and Link
Failure handling. Some additional notes on Link Failure handling are added here in order to explain
how TE should actually cope with such drastic events.
Chapter 6 gives an overview of the functionality of the Data-plane functions, i.e. the Traffic
Conditioning at the Edge Routers and the Per-Hop-Behaviour Enforcement (buffering & scheduling of
IP packets) in the core (and edge) routers. The TEQUILA project follows the recommendations of the
IETF DiffServ WG on these topics.
Chapter 7 outlines the Policy Framework. The Policy framework consists of the Policy Management
Tool, 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 creation
environment”. Policies are defined in a high-level language, translated into a object-oriented policy
representation (information objects) and finally stored in the policy repository (Policy Storing
Service).
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 the
Dimensioning block, dynamic resource/route management policies for the Dynamic Resource
Management block, etc. Policy Consumers need also to have direct communication with the
Monitoring 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 a
crucial network function for both the correct functioning of the Tequila system and for the ability to
impose a check on the SLSs, which were agreed with a customer. It is necessary to have a local and an
aggregated overall view on the network in terms of the definitions of the IETF IP Performance
Monitoring (IPPM) Working Group. The Tequila system needs to support two sources of information
as the basis 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
network element (referred to as passive measurements). To have a scaleable system, the information of
these basic building blocks needs to be aggregated into summarising statistics by some higher level
blocks.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 16 of 172
2 REQUIREMENTS, ASSUMPTIONS AND DEFINITIONS
OVERVIEW
2.1 Generic definitions and requirements
The TEQUILA system is being defined as the concatenation of IP-based networks that adopt the
procedures, 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., the
Internet. Note that this does not exclude the procedures defined within the context of the TEQUILA
project 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 addressing
realm, that is to say, all communicating parties are supplied with public routable addresses, and
network 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 the
TEQUILA project is to seek consensus in the wide research community and at the level of
standardisation (e.g., IETF), for each protocol that would handle information exchange over open
interfaces. This includes semantics and syntax of the interface specification at management, control
and datagram forwarding level.
2.2 Network architectural assumptions
Internet Backbone Provider
Server Farms / Content Providers
+
+
+
+
+
+
Internet Service Provider (ISP)
Internet Service Provider (ISP)
Enterprise
+
+
+
+
+
Residential
SOHO
+
+
+
+
+
+
+
+
+
+
Corporate / Business User / ISP
+
L3 Router
+
+
Subnetwork Layer Connection
+
+
Corporate / Business User / ISP
Host (Client /Server)
Network Access Server/
Customer Aggregation Router
Figure 1: The Internet Architecture
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 17 of 172
2.2.1 The Customer Premises Network Architecture
The TEQUILA assumes the Customer Premises Networks to be client stub networks to the TEQUILA
system. Although the TEQUILA project takes an ISP perspective to service offering, it is expected that
the offering of services at the access links of the network can easily be extrapolated to the service
offering 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 Architecture
The TEQUILA project assumes the access link between customer premises network and Internet
Service 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 enabled
networking.
2.2.3 The Core Network Architecture
As shown in Figure 2, the core of the Internet is built upon multiple tiers of connectivity between
corporate networks, Internet Service Providers and/or backbone providers.
The TEQUILA system must cover both intra-domain and inter-domain operation, where intra domain
operation denotes the operation of network elements under a single administration. Inter-domain
operation 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 autonomous
systems. A given autonomous system corresponds to a set of IP routers which are interconnected
according to a specific mesh topology, and which are managed by a single and globally unique
administrative 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 edge
routers connect the TEQUILA system to the client access, while AS border routers connect the
Autonomous Systems amongst each other. AS border routers typically communicate by means of
eBGP over the AS to AS links, while communicating by iBGP internally amongst each other within
the Autonomous System. Edge Routers collect client accesses, and as such can be configured to
communicate over the access link to the Customer Premises Network by eBGP or OSPF. It may also
be that no routing information is exchanged dynamically (CPN configured with static route to the
provider).
TEQUILA edge Router
AS Core Router
AS Border Router
TEQUILA SYSTEM
Autonomous System
Autonomous System
Autonomous System
Client
Access
Client
Access
Figure 2: TEQUILA network architecture
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 18 of 172
The TEQUILA project will not elaborate on the network topology planning and initial dimensioning of
the network.
The TEQUILA project must provide mechanisms for both MPLS and IP layer dimensioning, given a
fixed 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 consideration
will 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 connectivity
between border routers at (private, public) peering points.
Routing information exchange between autonomous systems is assumed to be performed by means of
the BGP4 protocol.
2.2.4 The Roaming Architecture
The 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) for
roaming access to CoS/QoS enabled networking.
2.3 General End to end CoS/QoS in the Internet
2.3.1 Flows vs. MicroFlows
A 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 of
parameters beyond the five tuple header information. E.g., any information available in the IP
datagram header such as DSCP, labels for Label Switched Paths in an MPLS architecture, ingress or
egress 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 the
application of dealing with flows (e.g., traffic engineering, or marking, or firewall filtering) and the
relative position in the network (e.g., access versus core). Prescribing the aggregation and deaggregation points and procedures is seen as a consistent part of the TEQUILA project.
2.3.2 CoS vs. QoS
In the TEQUILA project, Quality of Service (QoS) refers to a service offering where one or more
traffic parameters (i.e., throughput, loss, delay and/or jitter) are quantified. The way QoS is offered to
the user by the network can either be by opening the whole spectrum of possible values for one or
more traffic parameters, or by packaging them in a set of discrete parameter values. The latter is
denoted as QoS Classes within TEQUILA.
Further, in the TEQUILA project, Class of Service (CoS) refers to the provisioning of relative levels of
service amongst different packet flows. The resulting service perceived by a CoS flow is dependent on
the number of other flows that share network resources and are members of the same (or different)
CoS.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 19 of 172
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 is
however part of the research task within TEQUILA.
2.3.3 Applications
The TEQUILA system should allow for the widest range of possible applications, and should therefore
be application/service independent to the extent possible.
The TEQUILA system functional components should provide the necessary hooks in the system to
allow for specific service architectures to make use of or request reservation capabilities for CoS/QoS
enabled data transport.
2.3.4 CoS/QoS architectures
2.3.4.1 IntServ and DiffServ networking models
The TEQUILA system supports both the integrated services and differentiated services end-to-end
models.
The TEQUILA system assumes only the RSVP resource reservations protocol in the context of the
IntServ model
The TEQUILA system must provide for Best Effort, Controlled Load and Guaranteed Service end-toend networking in the IntServ model. That is to say, no new Intserv-based service elements will be
defined within the course of the TEQUILA project.
The TEQUILA system assumes only the Expedited Forwarding, Assured Forwarding and Default Per
Hop Behaviours in the DiffServ model. No new per hop behaviours will be defined in the course of the
TEQUILA project.
The TEQUILA project assumes the DiffServ model in the core of the autonomous systems as depicted
in Figure 2. This basic assumption stems from the scalability properties of DiffServ enabled
networking. For the same reason of scalability, the DiffServ domain may extend over multiple
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
•
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) and
between AS and customer networks.
2.3.4.2 Service Level Specification and Negotiation
At the access to the TEQUILA system, service requests should allow for:
•
RSVP-based negotiation of Service Level Specifications that adhere to the IntServ model as
described 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 TEQUILA
system 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, the
TEQUILA project must define them for its own use.
The requirements towards the format and negotiation protocol are the following.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 20 of 172
The TEQUILA project should allow for automated, dynamic SLS negotiation. The accepted dynamics
of SLS negotiation will be dependent on the scalability concerns of the system, and will be
investigated within the context of the TEQUILA project.
The TEQUILA system should allow for Service Levels to be attached to the notion of a flow, the
service level being of CoS or QoS nature. The guarantees implied by the CoS/QoS Service Level
Specification will be limited to a prescribed scope, however limited to the TEQUILA system. That is
to 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-conforming
packets.
Other components of the SLS specific to a flow and considered by the TEQUILA system are
Availability (where availability refers to the time indication when the SLS should apply) and
Maximum update frequency. Components such as Reliability, Security (Privacy, Integrity and
Authenticity requirements), Routing Constraints and Cost will be covered in the margin of the project
to the extent needed to cover the former requirements.
The TEQUILA project should specify a formal format for the description of an SLS at the Client
Access 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 related
service offerings.
•
Service modification from both user and provider
The TEQUILA SLS negotiation protocol transport requirements should be lightweight comparable to
the 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 design
work available.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 21 of 172
2.3.5 Basic Traffic Management Blocks
The TEQUILA project is primarily considered with the study, development and validation of
architectures, algorithms and protocols to ensure end-to-end CoS/QoS in the Internet. Adopting the
DiffServ architecture approach leads to the necessity of specifying and developing mechanisms for the
implementation of the traffic management capabilities needed to support the required Per Hop
Behaviours. Thus the focus of the TEQUILA project is to ensure the support of the PHBs rather than
extensively 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 existing
mechanisms capable to support the target PHBs. This allows the project to adopt the optimum
combination of existing traffic classification, conditioning, scheduling, metering and congestion
management techniques in order to meet its objectives, saving the effort from studying and developing
new traffic management mechanisms.
Further, it is considered that the TEQUILA project should not commit itself to explicit requirements
regarding the traffic management techniques to be used. It is foreseen though to further investigate the
existing solutions and, under the context of the project’s functional model specification, decide on the
specific techniques to be adopted by the project.
Concerning the Explicit Congestion Notification (ECN), it has been decided that the project should not
make the assumption that all the routers composing the DS domain are ECN-capable, but rather
consider it as an optional feature which some routers might support while others might not.
2.3.6 Policy framework
It is expected that ‘correct’ policy enforcement at the edges of the TEQUILA system (and its
underlying autonomous systems) will be a prime concern in the provisioning of CoS/QoS guarantees
at a network wide scope. In addition, policy-based management offers potentially a flexible, extensible
vehicle 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 within
the context of CoS/QoS networking. The framework however requires still substantial work, if it is to
be used in an operational network. The TEQUILA project should start from the present status of the
policy 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), which
eventually lead to a final admission decision.
In addition to admission control policies, TEQUILA should investigate the possibility of using the
policy framework for dynamic resource management policies. This area has not yet been addressed by
the IETF and investigated principles and accruing results should be fed back to the IETF.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 22 of 172
Policy Specifications
Repository
Access
Protocol (e.g. LDAP)
Policy Management Tool
Policy Repository (Directory
server, Database, etc.)
Repository
Access
Protocol (e.g. LDAP)
Policy Consumer
Policy Target
Policies
Protocol
Targets
for
affecting
Policy
Figure 3: The generic policy architecture
The TEQUILA system assumes a LDAP-like interface between the Policy management tool, Policy
repository and Policy Consumer (sometimes referred to as Policy Decision Point, PDP). On the other
hand, TEQUILA should concentrate on the essence of the policy framework rather than focusing on
open, standardised repository access.
The TEQUILA system assumes the use of the COPS protocol between the policy consumer (PDP) and
policy target (sometimes referred to as Policy Enforcement Point, PEP), as only presently standardised
protocol for CoS/QoS related PDP/PEP communication. The project will however investigate new
developments 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 aspects
One of the primary activities within TEQUILA is the investigation on the use of various trafficengineering tools towards the provision of end-to-end QoS as specified in SLSs.
2.4.1 General TE Requirements
TEQUILA is required to provide a TE system with traffic-oriented performance objectives to fulfil the
requirements of the contracted SLSs.
As outlined by its objectives, TEQUILA assumes a DiffServ-capable IP network infrastructure. The
specification of a scalable, effective TE system in DiffServ networks is still an open issue and
TEQUILA is expected to contribute to the design of architectures and algorithms, which will be
validated 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 management
schemes. TEQUILA will investigate the optimal coupling of these functions by studying the dynamics
of 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 requirements
The routing algorithms and protocols in TEQUILA should at a minimum:
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 23 of 172
•
Be QoS-aware, as part of the OSPF extensions, and from a L3 TE perspective. Therefore, the
project should investigate the use of multiple metrics in (OSPF) type 10 LSA and the appropriate
TLVs, 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-level
algorithms such as network dimensioning.
•
Calculate and select feasible paths - not necessarily shortest paths - with the aim of improving
overall network efficiency and the availability of the various service classes offered by the
network.
•
Work in conjunction with resource (capacity) reservations and the dynamic management of those
reservations
•
Routing protocols and embedded algorithms in TEQUILA may be programmed (in the medium to
long 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 term
time scale) distributed protocol - it may not be possible when there are different routing plans for
different service classes multiplexed on the same network. TEQUILA should consider the relative
merits 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 iBGP
peering relationships).
2.4.3 MPLS TE requirements
As it has been extensively described in [I1.1], MPLS with its features (especially its support for
explicit routing) constitutes an important tool upon which effective TE solutions can be based.
TEQUILA envisions that MPLS forwarding mechanism integrated with a constrained-based routing
paradigm is a very important candidate towards specifying an effective TE solution for specific classes
of traffic (e.g. of critical delivery).
The TEQUILA system must also provide MPLS traffic-engineering capabilities.
2.4.4 Survivability Requirements
TEQUILA is required to investigate survivability issues in the specified TE solution. At a minimum,
link failures should be covered.
2.4.5 Measurement Requirements
TEQUILA is required to consider how its SLSs will be monitored and how network measurements are
to 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 measurement
architecture.
TEQUILA is required to study the representation (and aggregation) of measurement information to be
used as an input to other functional elements.
2.4.6 Capacity Control and Management Requirements
TEQUILA is required to provide capacity management functions for being able to handle SLS
requests and optimising network performance. Both network level and network element resources are
in the scope of TEQUILA. Multi-class contention resolution schemes will be investigated.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 24 of 172
As already outlined, TEQUILA will pursue optimum coupling of time and state-dependent capacity
management schemes.
The Bandwidth Broker (BB) work in the Internet 2 Qbone Bandwidth Broker Advisory Council is of
interest to TEQUILA, especially as draft protocol specifications for inter-domain BB communications
have already been published. The architecture is interesting in the sense that, in at least one place in
their 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 and
dynamic 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 of
interest. An outstanding issue, at the time of writing, is to identify the maturity of the implementations
from UCLA, Merit, BCIT and Telia.
2.5 Interdomain QoS aspects
The TEQUILA system should allow for SLS agreed at its edge to stretch over Autonomous Systems
under the control of different administrations. To that end, the TEQUILA system should specify the
necessary extensions on the present best effort inter-domain routing architecture to enable CoS/QoS
enabled 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 interdomain networking.
The TEQUILA system should allow for communication with the Internet2 community on the basis of
the already agreed BB-to-BB communication architecture. It is assumed that this will be a subset of the
capabilities of the TEQUILA system.
2.6 Non-technical requirements
The 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 of
CoS/QoS IP networking.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 25 of 172
3 THE TEQUILA FUNCTIONAL MODEL
In this section we present the TEQUILA Functional Architecture and describe in detail the
functionality of each functional block. Figure 4 illustrates the overall Functional Architecture.
2YHUDOO)XQFWLRQDO$UFKLWHFWXUH
,63$6
3ROLF\
0DQDJHPHQW
'RZQVWUHDP
7UDIILF
1HWZRUN
,63$6
)RUHFDVW
3ODQQLQJ
6/6 0DQDJHPHQW
1HWZRUN
$GPLVVLRQ&RQWURO
'LPHQVLRQLQJ
6XEVFULSWLRQ
8VHU
RU
8SVWUHDP
0RQLWRULQJ
,63$6
0DQDJHPHQW
7UDIILF
&RQGLWLRQLQJ
'\QDPLF
'\QDPLF5RXWH
5RXWLQJ
5HVRXUFH
0DQDJHPHQW
3+%
3DFNHW2XWSXW
(QIRUFHPHQW
7UHDWPHQW
Figure 4: The TEQUILA Functional Architecture.
It should be noted that at this level of abstraction we omit the directionality of the interactions between
the components, because the interpretation of the semantics of such directionality might vary. Whether
the interaction is from or to one component will be clearer (independently of the semantics) in the
functional 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, in
fact this is one of the directory’s advantages as a technology for the repository) and the Policy
Consumers which are mixed with their associated functional blocks (see “A Tequila Functional
Block” in the figure), e.g. SLS related (admission) policies with the SLS Management block,
dimensioning policies with the Dimensioning block, dynamic resource/route management policies
with the Dynamic Resource Management block, etc.
•
In this model there exist many functionally different Policy Consumers, associated with particular
functional blocks of the hierarchical management structure. Targets can be the managed objects of
the 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 in
order to get information about the policy-triggering event. Note that Monitoring might not always
emit the policy-triggering event but there might be cases where this event is emitted by the specific
functional block to which the Policy Consumer is associated with.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 26 of 172
•
Policies are defined in the Policy Management Tool, which provides something like a “policy
creation environment”. Policies are defined in a high-level language, are translated to objectoriented policy representation (information objects) and stored in the policy repository (Policy
Storing Service). New policies are checked for conflicts with existing policies, although some
conflicts may be only detected during execution time. After the policies are stored, activation
information 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
$7HTXLOD
)XQFWLRQDO
%ORFN
3ROLF\
&RQVXPHU
0RQLWRULQJ
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 Decision
Point, TEQUILA considers a hierarchical approach to policy decomposition, with high level
policies including lower level policies, until the latter degenerates at configuration commands at
the lowest level. It is for further investigation to what extent such a hierarchical decomposition can
be supported in an automated manner. Also TEQUILA policy management will consider having
back-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 is
not explicitly shown in the current figure, is used by Network Planning.
•
Receives notification from Network Dimensioning when physical resources are insufficient.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 27 of 172
•
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 also
the target of the IRTF’s BuDS group).
•
Receives input from the Traffic Forecast module about the forecasted load. The forecast of traffic
will be based on the subscribed SLSs but may also include foreseen SLS subscriptions (based on
monitoring and historical data) and factors to take into account dynamic SLS invocations, which
do not conform to previously, subscribed SLSs.
•
Provides SLS subscription with a view of spare network resources to allow the SLS Negotiation
component to be knowledgeable about whether the ISP can meet user requests; note these are
long-term SLSs/access control issues – not per flow (the latter will actually be handled by the
Admission Control part of the SLS Management – see the corresponding section). Network
Dimensioning 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 SLS
information does not have to pass through Dimensioning, (only the forecasted demand will need
to) therefore leaving Dimensioning completely SLS unaware.
•
Informs Planning when physical resources can no longer meet demand, and gets input from it
about new physical resources (connectivity – including link capacities).
•
Interacts with the SLS Management (Inter-domain SLS Requestor) when the dimensioning of the
network results in needs for aggregate traffic to cross-domain boundaries. This is likely to be
significantly different from current inter-domain SLSs, therefore it might result in initiating interdomain 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 network
over the physical underlying network in order to cope better with the expected traffic. Path-based
networks support traffic-engineering functions better. Network dimensioning might initiate MPLS
path creation, if used.
•
It is triggered by the Traffic Forecast and Dynamic Route/Resource Management modules, or in a
periodic way.
•
Passes the network configuration to monitoring. This will probably be via the Connectivity and
Configuration 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 being
decomposed into sub-network dimensioning components, for scalability purposes). Compared to
dynamic control/management of routes and resources, Network Dimensioning should be much less
dynamic/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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 28 of 172
•
It receives input from the customer subscriptions (SLS Subscription) and dynamic requests
(including subscription/requests not accepted), the monitoring/measurements (both SLS
Monitoring 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 dimensioning
and 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 association
between the decomposed SLS Management and the other TEQUILA functional blocks.
•
Note that functional blocks such as SLS Advertisement, Customer Complaints, Accounting (not
shown in Figure 6) might also be considered as SLS Management functionalities. The TEQUILA
Project will NOT investigate any of these issues; they are for future study and/or liaison with other
projects/works.
•
All the SLS Management activities can be affected by policies, therefore an appropriate Policy
Consumer must co-exist with each of the decomposed functional blocks.
6/60DQDJHPHQW
7UDIILF
'RZQ )RUHFDVW
,QWHU GRPDLQ
VWUHDP
6/6 5HTXHVWRU
,63$6
6/6
1HWZRUN
6XEVFULSWLRQ
'LPHQVLRQLQJ
$GPLVVLRQ
&RQWURO
'\QDPLF
'\QDPLF
5RXWH
5HVRXUFH
0DQDJHPHQW
0DQDJHPHQW
8VHU
RU
0RQLWRULQJ
8SVWUHDP
,63$6
7UDIILF
&RQGLWLRQLQJ
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 operates
in the management plane.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 29 of 172
•
Delegates policies/downloads rules for each user according to agreed SLSs to Admission Control
which, in turn, downloads rules/policies to traffic conditioners as and when necessary. 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.
•
Includes an SLS Repository, which stores current and rejected (unable to subscribe) SLSs. This
repository is input to Traffic Forecast. Views of this repository might need to visible by the
Admission 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 be
supported or not in the network given the current network configuration – this is not an
instantaneous snapshot of load/spare capacity, but the longer-term configuration provided by the
Network Dimensioning. It provides a view of the current available resources to Admission Control
functional 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 the
SLS Repository). SLS Subscription will provide Admission Control with the current spare
resources, since SLS Subscription will always have the most updated version.
• Also performs dynamic admission control for requests. This functional block uses a signalling
protocol 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 Traffic
Forecast.
• Local and/or network-wide load information, provided by monitoring, might be necessary to
come to an admission decision.
•
Delegates policies/downloads rules for each user according to the admitted request to traffic
conditioner. 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 SLS
Requestor.
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 Network
Planning (long term/static SLS issues - months) through Network Dimensioning.
•
It handles requests for either changing/renegotiating the SLSs (requested by the SLS Subscription
module) or dynamic requests (requested by the Admission Control module), with the peer
ISPs/ASs in the case the pre-negotiated requests by the Dimensioning and Planning are not
appropriate.
•
Also responsible to request new long-term SLS subscriptions with peer ISP/ASs, or to handle
dynamic 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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
8VHU
RU
8SVWUHDP
,63$6
Page 30 of 172
6/66XEVFULSWLRQ
6/6
0DQDJHPHQW3ODQH
6XEVFULSWLRQ
'\QDPLF5HTXHVW
6/62SWLRQ5HTXHVW
$GPLVVLRQ
56935HTXHVW
&RQWURO
&RQWURO3ODQH
'DWD7UDQVPLVVLRQ
7UDIILF
'DWD3ODQH
GDWD
&RQGLWLRQLQJ
Figure 7: Decomposition of the User-Upstream ISP/AS functional block and
interactions with others.
•
Subscribes/negotiates or renegotiates longer-term SLSs (management plane)
•
Dynamically invokes SLSs. This may be a selection from a number of previously subscribed
options 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 or
a similar protocol, the request may be implicit in the data transmission (e.g. use of particular
DSCP), 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 ) may
also 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 the
management plane).
•
Determines what needs to be measured where and directs the monitoring/metering devices
accordingly – identifies which parameters to measure, sets thresholds.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 31 of 172
7UDIILF
0RQLWRULQJ
)RUHFDVW
6/6
6XEVFULSWLRQ
6/60RQLWRULQJ
1HWZRUN
1HWZRUN
0RQLWRULQJ
'LPHQVLRQLQJ
$GPLVVLRQ
&RQWURO
1RGH
0RQLWRULQJ
0HWHULQJ
'\QDPLF
'\QDPLF
5RXWH
5HVRXUFH
0DQDJHPHQW
0DQDJHPHQW
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 dimensioning
and planning, i.e. it provides information to Traffic Forecast.
•
Accepts monitoring/measurement requests by Network Dimensioning, Traffic Forecast and
Dynamic Route/Resource Management. They may also provide specific thresholds for later
notification.
•
It receives the connectivity and configuration information from Network Dimensioning.
•
Determines what needs to be measured where and directs the monitoring/metering modules
accordingly – identifies the type of measurements needed and which nodes need to participate
in the measurements. It is important to note that it might determine that there is need for
passive and/or active measurements (see node monitoring bellow for more details on this).
•
Notifies/triggers Dynamic Route/Resource Management and/or Dimensioning (threshold
crossings, link failures).
•
Includes database of historical load and quality measurements, in order to provide input traffic
forecasting 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 measurements
node-to-node within the ISP/ASs limits (Network-wide Monitoring is responsible then to
compute the end-to-end results). This engine puts necessary test streams into the forwarding
path (active probing). It schedules the measurements to comply with the IETF’s IPPM WG. It
uses caching to avoid loading the network with too much test traffic.
•
Also the classic passive monitoring is included in this module. Passive monitoring relies on
counters (MIB probing) to perform monitoring. Counters are available in various parts of the
network: meters, classifiers and forwarding engines.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
•
Page 32 of 172
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 Node
Monitoring requesting specific performance parameters for each SLS. It may not be necessary
to 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/reroutes
LSPs. 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 no
longer able to operate effectively, e.g. load balancing cannot be achieved due to an insufficient
number 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 along
with the “QoS-routing” capable indication bit might yield the same allocation of capacity in the
case of pure IP routing.
•
Ensures link capacity is not wastefully allocated to hard-reserved classes when other classes with
an 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 no
longer able to operate effectively, e.g. due to excessive high priority traffic, link partitioning is
causing 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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 33 of 172
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 Network
The following section gives an overview of the bootstrapping scenario for the Tequila system based on
the definitions and inter-dependencies of the functional blocks comprising the Tequila functional
model. 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 Assumptions
In order for the Tequila system to reach the operational phase, the physical network, upon which the
Tequila system will operate, should be already in place and the appropriate Tequila-related
initialisation actions already completed. Thus, we assume two asynchronous phases preceding the
operational phase of the system. The first is called the "Zero Phase" and deals with the long-term
network planning from the business perspective and the installation of the physical network
equipment. The second phase deals with the bootstrapping of the Tequila system and uses as input the
results of the Zero phase.
The Zero phase is outside of the scope of the Tequila project. Therefore, no actions investigating the
aspects of this phase will be undertaken by the project. However, the outcomes of the Zero phase
should be described and specified in detail, since these will constitute the input of the bootstrapping
phase.
3.14.2 Zero Phase
It is assumed that the Zero phase is preceded by the business case definition at the business level. The
business 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 at
the 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
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 34 of 172
These aspects of the business case are stored in the system’s repositories, using simple data entry
interfaces or more sophisticated tools, as in the case of the Policy Management component. The
Network Planning component is then activated. Based on the business case, it calculates the network
physical topology and stores it in the Topology Repository. The network topology, as resulted by the
Network Planning, provides information regarding the equipment configuration, connectivity, network
interfaces and routing.
The need for an SLS Repository has been identified here and thus added to the description of this
scenario. Moreover, there is a de-coupling of the SLS repository, Anticipated Traffic Matrix and
Topology Repository. These functions serve requests from multiple clients and might be invoked in
different phases of the system. For example, during the Zero phase the inter-domain SLSs are specified
at the business level and thus have to be stored, while the SLS manager is not activated yet.
=HUR3KDVH
6/67\SHV
$QWLFLSDWHG7UDIILF
6/6
3ROLF\
1HWZRUN
7RSRORJ\
5HSRVLWRU\
0 DWUL[5HSRVLWRU\
5HSRVLWRU\
0DQDJHPHQW
3ODQQLQJ
5HSRVLWRU\
6WRUH6/67\SHV
6WRUH$QWLFLSDWHG
7UDIILF0DWUL[
6WRUH
,QWHU'RP DLQ6/6V
6WRUH3ROLFLHV
5HTXHVW6/67\SHV
5HTXHVW$QWLFLSDWHG7UDIILF0DWUL[
5HTXHVW,QWHU'RP DLQ6/6V
5HTXHVW3ROLFLHV
6WRUH3K\VLFDO
1HWZRUN7RSRORJ\
,QSXWIURP%XVLQHVV/HYHO
&RPSRQHQW,QLWLDOLVDWLRQ
Figure 9: Zero Phase Message Sequence Chart
3.14.3 Bootstrapping Message Sequence Chart
The 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 last
Zero 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 from
the Topology Repository.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 35 of 172
4. Activation of the Traffic Forecasting Management component. It uses as input the Anticipated
Traffic Matrix.
5. Activation of the SLS Management component.
•
The SLS Subscription sub-component is activated and gets the policies it requires to operate
from 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 the
inter-domain SLSs decided during the Zero phase from the Policy Management component and
the SLS Repository respectively.
6. The Network Dimensioning component is activated.
•
It gets information regarding the network topology, the SLS types, the policies, the inter-domain
SLSs and the anticipated traffic matrix.
•
It performs a verification test communicating with the NEs to ensure that all the NEs are up and
running.
•
Based on the policies obtained from the Policy Management, it calculates and downloads:
•
•
Routing constraints and/or Explicit Routes to the Dynamic Route Management
component,
•
Bandwidth sharing constraints and/or scheduling parameters to the Dynamic Resource
Management component and
•
SLS Admission constraints and parameters to the Admission Control sub-component.
Based on these constraints and parameters, the Dynamic Resource and Route Management
components configure the Scheduling/Forwarding and the Routing components of the NEs.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
%RRWVWUDSSLQJ3KDVH
1(V
5HSRVLWRULHV
6FKHGXOLQJ
)RUZDUGLQJ
Page 36 of 172
5RXWLQJ
7UDIILF
'\QDP LF
7UDIILF
&RQGLWLRQLQJ
5HVRXUFH5RXWH
0RQLWRULQJ
)RUHFDVWLQJ
0DQDJHPHQW
0 DQDJHPHQW
6/60DQDJHPHQW
6/6
$GPLVVLRQ
6XEVFULSWLRQ
&RQWURO
,QWHU'RP DLQ
6/6
5HTXHVWRU
1HWZRUN
'LP HQVLRQLQJ
5HTXHVW7RSRORJ\
5HTXHVW$QWLFLSDWHG7UDIILF0DWUL[
5HTXHVW3ROLFLHV
5HTXHVW3ROLFLHV,QWHU'RPDLQ6/6V
&RQILJXUH7UDIILF&RQGLWLRQLQJ
5HTXHVW7RSRORJ\6/67\SHV3ROLFLHV,QWHU'RPDLQ6/6V$QWLFLSDWHG7UDIILF0DWUL[
9HULILFDWLRQ7HVW
&RQILJXUH5RXWLQJ
&RQILJXUH6FKHGXOLQJ)RUZDUGLQJ
'RZQORDG5RXWLQJ&RQVWUDLQWVDQGRU([SOLFLW5RXWHV
'RZQORDG%DQGZLGWK6KDULQJ&RQVWUDLQWVDQGRU6FKHGXOLQJ3DUDP HWHUV
'RZQORDG6/6
$GPLVVLRQ&RQVWUDLQWV
DQG3DUDP HWHUV
&RPSRQHQW$FWLYDWLRQ
&RPSRQHQW,QLWLDOLVDWLRQ
Figure 10: Bootstrapping Phase Message Sequence Chart
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 37 of 172
4 SERVICE LEVEL SPECIFICATIONS
This chapter brings together all issues related to Service Level Specifications (SLS): SLS contents and
semantics, SLS handling and functional scenarios and a further functional decomposition of the SLSManagement functional block. The main contribution of this chapter is the proposal of a template of
the Service Level Specification (SLS) and the description of the SLS semantics, section 4.2. The
information of this section has served as input for the first contribution of the TEQUILA consortium
towards Standardisation, i.e. an IETF Internet draft submitted to the DiffServ Working Group in July
2000 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. If
the SLS is seen as an object class, then this section describes the semantics of its attributes. The
SLS contains amongst others the essential Traffic Conformance Parameters and QoS Performance
Guarantees. The SLS only contains the attributes relevant for traffic purposes and is as such itself
part of the (broader) ISP/customer contract, i.e. the Service Level Agreement (SLA). The latter
contains e.g. the relevant properties of the customer.
•
The third section describes examples of Service Types and introduces the notion of Customer
Service. Three relevant service types (or classes) are accepted by the Tequila system. Quantitative
SLSs 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 or
packet 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 be
constructed 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 and
interactions between SLS management, Traffic Forecast and Network Dimensioning; how are new
or modified actually handled – on a high level – by the Tequila Network. A clear distinction is
made 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 section
also 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 the
TEQUILA functional model and the (DiffServ) SLS format can actually support IntServ. The
IntServ Guaranteed Service and Controlled Load are “Premium micro-flow services”. It is
described how RSVP Messages are captured by the TEQUILA Functional Model and how the
information of the RSVP Objects, e.g. TSpec and RSpec, is mapped onto the DiffServ SLSs. Once
these “IntServ” SLSs are created, they are handled by the TEQAUILA management system as all
others.
•
The sixth section briefly introduces internal functional decomposition of the SLS Management
block itself.
The Internet Draft covers the first two sections and partially the third (SLS examples). The notion of
bi-directional Customer Service, i.e. bundling of SLSs into a Customer container making up e.g. bidirectional 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 is
functionally described here, will require standardised SLS-negotiation protocol(s) between customer
and 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 topics
towards standardisation.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 38 of 172
4.1 Motivation and framework
This section identifies the basic information to be handled by Service Level Specification (SLS, [RFC
2475], [DS-TERMS]) when considering the deployment of value-added IP service offerings over the
Internet. 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 are
likely to be provided over the whole Internet, their corresponding QoS will be based upon a set of
technical parameters that both customers and services providers will have to agree upon. From this
perspective, the Tequila Draft – and the information in this section of the D1.1 deliverable - aims at
listing (and promoting a standard formalism for) a set of basic parameters which will actually compose
the 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 provider
or amongst services providers within the context of processing a SLS;
-
Provide the corresponding semantics of such information, so that it might be appropriately
modelled 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 the
semantics that go behind this representation. The need to have such an agreed set of Service Level
Specification parameters and semantics is manifold.
First, it is necessary to be able to allow for a highly developed level of automation and dynamic
negotiation of Service Level Specifications between customers and providers. Automation and
dynamics are indeed helpful in providing customers (as well as providers) the technical means for the
dynamic 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-vendor
environment requires a standardised set of semantics for Service Level Specifications being negotiated
at 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 be
uniquely 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 project
in 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), including
the 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 QoSbased peering agreements between themselves, and usual customers of ISPs, like those who compose
both the residential and the corporate market.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 39 of 172
4.2 SLS contents & semantics
The following describes the attributes of the SLS object. It can be expected that, as the project evolves
and further insight is obtained through implementation and simulation, more SLS-attributes could
possibly be added to the definition. Especially some inter-domain aspects require further study. For
example, 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. This
attribute is used for inter-domain routing aspects in the QBONE architecture. Its use in the Tequila
project is for further study.
4.2.1 Scope
Scope = (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 uniquely
identifies the geographical/topological region over which the QoS is to be enforced by indicating the
boundaries 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 the
source/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 be
an IP address, but it may also be determined by a layer-two identifier in case of e.g. Ethernet, or for
unnumbered 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 one
interface address. Thus SLSs describe Uni-directional traffic flows. Bi-directional customer services
are constructed as a set (i.e. two) of SLSs: cf. section 4. Also VPN services allowing traffic to flow
between N edge points, an (N, N) model, will also be constructed as a set of SLSs.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 40 of 172
4.2.2 Flow Identification
The flow identification (Flow Id) of an SLS (associated to a given service offering) indicates for which
IP packets the QoS policy for that specific service offering is to be enforced. A Flow Id identifies a
stream 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 destination
prefixes | 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 other
attributes MUST NOT be specified.
In case of MF-classification all attributes MAY be specified. Remark that MF classification may as
well depict micro-flows as aggregate flows [DS-MODEL].
Note that there are restrictions involved in combining scope and flow identification within a certain
SLS instance.
Remark
In the context of SLS services specification, the TEQUILA system offers multiple level of granularity
what 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, a
clarification has to be made. Indeed, in order to differentiate an application from another, two schemes
are possible. The easiest one is when the application is associated to well known port (therefore
enabling to use that port as discrimination factor). However, this situation is not always the case and
application may be dynamically assigned ephemeral ports (e.g. via a signalling protocol as H.323) for
the time of the session. In this situation, the system could not use the used port values to distinguish an
application from another. So, in order to be able to make that distinction, different mechanism are
possible. Some of them are: intercepting the signalling in order to capture the type of application being
negotiated or even defining traffic patterns which have to be applied to new streams in order to
discover the type of the application being transported.
The detailed study of these applications (and supplementary complexity) is outside the scope of the
Tequila project; the possibility should however be recognised in the framework.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 41 of 172
4.2.3 Traffic Conformance Testing
Traffic Conformance Testing is the set of actions which uniquely identities the "in-profile" and "out-of
profile" (or excess) packets of an IP stream (identified by Flow-Id). Traffic Conformance Testing will
usually be done at a DS-boundary node.
The SLS specifies the Traffic Conformance Testing as a combination of the Traffic Conformance
Parameters and the Traffic Conformance Algorithm. The Traffic Conformance Parameters describe the
reference values the traffic (identified by the Flow ID.) will have to comply with, thus yielding the
notions of "In" and "Out" of profile traffics. The Traffic Conformance Algorithm is the mechanism
enabling unambiguously to identify all "in" or "out" of profile packets based on these Conformance
parameters.
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 bucket
algorithm.
- 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 with
size 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 guaranteeing
delay/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 Testing
This subsection indicates what should happen with packets entering the system prior to conformance
testing/traffic conditioning.
The semantics is that the (Tequila) Network may offer a number of services to its customer such as
shaping or marking prior to conforming testing. For example if the host of the customer has not the
ability 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, the
network 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
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
-
Page 42 of 172
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 may
be dropped, shaped and/or remarked. The SLS MUST specify the appropriate action by the following
attribute.
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 Conformance
Algorithm are dropped. No extra parameters are needed.
If value = shaping, then all packets marked as “out-of-profile” by the Traffic Conformance Algorithm
are delayed until they are “in-profile”. The shaping rate is the policing/token bucket rate. The extra
parameter is the buffer size of the shaper.
If value = remarking, then all packets marked as “out-of-profile” by the Traffic Conformance
Algorithm are (re-) marked with a particular DSCP-value (yellow or red). The extra parameter is the
DSCP.
Remark
Treatment of excess traffic is in close relation with the type of service requested and the traffic
performance parameters. The mapping of services on PHBs is not topic of this document, but the
general 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 or
red). Re-ordering of packets is however not allowed, i.e. in-profile and out-of-profile packets belong to
the 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 parameters
The performance parameters describe the service guarantees the network offers to the customer for the
packet stream described by the Flow Id and over the geographical/topological extent given by the
scope. All service guarantees are for the in-profile traffic; no guarantees are given for excess (out-ofprofile) packets.
There are four performance parameters:
•
delay | optional quantile
•
jitter | optional quantile
•
packet loss
•
throughput
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 43 of 172
The following definitions always consider the (measurable) performance parameters related to the
packet stream specified by the Flow Id.
-
The delay and jitter indicate respectively the maximum packet transfer delay and packet transfer
delay 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 rare
events and customers may find measurements of e.g. 99.5th percentile a more relevant empirical
gauge of delay/jitter.
-
The packet loss indicates the packet loss probability for in-profile packets from ingress to egress
Packet loss
-
=
Lost in-profile packets between ingress and egress
-----------------------------------------------------------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 Traffic
Conformance Algorithm. Indeed, as the customer is only interested in a throughput it is not
required to have a distinction between in- and out-of-profile packets. Of course, the operator
will probably protect his network by implementing a Traffic Conditioner at Ingress and
specifying the token policing rate (r) equal to the throughput guarantee R, R=r. He may or
may 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 while
extra available resources may eventually be allocated to the out-of-profile traffic. If excess
traffic is dropped/shaped, then "throughput" indicates a maximum guarantee.
4.2.6.2 Qualitative & Quantitative Service Classes
Quantitative 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 4
performance 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. the
worst case. Note that the quantification of relative difference between <high/medium/low> is a
provider 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)
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 44 of 172
This yields the following combinations of relative/qualitative/CoS service classes.
delay
loss
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 either
delay or loss (non-exclusive) are qualified to "medium" or "low", i.e. excluding bronze/red from the
above.
The service guarantee offered by the SLS is said to be best-effort if it is NOT quantified nor qualified.
4.2.7 Service schedule
The service schedule indicates the start time and end time of the service, i.e. when is the service
available.
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
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
-
Page 45 of 172
Year = [present year, 9999]
4.2.8 Reliability
Reliability indicates the maximum allowed mean downtime per year (MDT) and the maximum
allowed 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)
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 46 of 172
4.3 Examples: Service Types & Customer Services
This section gives some examples of IP Services, which can be formally described based on the
TEQUILA SLS defined above. Examples include the IP Premium Service (similar to the Qbone
Internet2 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 applications
This 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 DSCPvalue (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 example
VoIP or Videoconference micro-flows could be multiplexed into the VLL. However, the Operator only
offers a VLL and it is the responsibility of the customer to control the traffic (and number of microflows) which are multiplexed into the VLL pipe. Thus, in this model, it is up to the customer to
perform admission control of micro-flows.
4.3.1.2 Virtual Leased Line for data-applications
This second type of VLLs (only) offers a quantified bandwidth guarantee and loose requirements on
delay and packet loss. Delay and loss are not quantified and are only expected to be “low” for the inprofile 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 DSCPvalue (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
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 47 of 172
Typical applications
Basically VLL type 2 gives a throughput guarantee R - without specifying delay or packet loss. Of
course, if the customer injects traffic at a rate r <= R, then delay and loss will be low (implicit
guarantee of low loss and low delay).
4.3.1.3 Real-time Micro-flows with strict delay guarantees
SLS specification
•
Scope: one-to-one communication (Pipe model), (Ingress, Egress) specified
•
Flow specification: (source IP-address, destination IP-address, source port number, destination
port 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 excess
SLS 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 be
indicated.
Typical applications
•
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) services
Service 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” treatment
will be applied.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 48 of 172
•
Excess traffic MUST be (re-) marked. For example green packets to yellow or unmarked packets
to yellow or red (excess packets allowed into the network MUST NOT be green). Excess packets
remain however into the same delay class (gold, silver, bronze) because packet-re-ordering is NOT
allowed. 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 excess
traffic or intelligent buffer acceptance algorithms for isolating in-and out-of-profile packets.
•
Performance Parameter: Delay OR loss MUST be indicated qualitatively. Throughput and jitter
MUST NOT be indicated
Typical applications
•
the gold/green delay class can be used for real-time services without strict guarantees (giving
priority to these packets over silver/bronze and BE + dimensioning small queues s.t. queuing delay
within 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 over
the WAN without any hard guarantees.
4.3.3 The Funnel Service
The service offered by the funnel model is primarily a protection service: the customer wants to set a
maximum on the amount of traffic (characterised by a DSCP) entering his network.
%
1HWZRUN
$
&
DRXW
'
+RVH
Figure 11: the funnel model
In Figure 11, the customer A requires that the traffic entering his network from A,B and C does not
exceed 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 traffic
characterized by the DSCP -value.
•
Traffic Conformance Parameters: (b, r) MUST be indicated. The token bucket parameters indicate
the maximum allowed throughput (r = a_out) towards the customer network on the specified
egress interface. This maximum or filter is applied to all packets marked with the DSCP-value
indicated above.
•
Excess treatment: dropping (this is actually the service offered by the network).
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
Page 49 of 172
Performance Parameter: not specified.
Typical applications
•
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 the
rates must be specified for the individual pipes (each video separately), then this customer service
must be constructed as a container of 2 (or more) SLSs, see next section.
4.3.4 Best Effort traffic
SLS 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 Line
Customer Services
This section and the following describes how customer services, such as bi-directional Virtual Leased
Lines and VPNs can be constructed with the SLS types as defined above. The basic idea is indeed that
the SLSs are basic building blocks for constructing services.
Formally a Customer Service is a container or a (finite) set of and a number of conditions
involving attributes (parameters) of more then one SLS (conditions on a “supra” level). A customer
service will probably be modelled itself as an object class containing a number (array) of SLS-id’s and
formal conditions.
Concerning customer-service negotiation, member-SLSs of the same customer service are all allowed
or 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 the
following: Ingress1 = Egress2 and Egress1 = Ingress2
•
All other SLS1/2 attributes are independent from each other. This allows for completely asymmetric 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 no
guarantees concerning individual traffic streams from A to e.g. B. The guarantee concerns the
aggregate traffic from A to any egress point B,C, D.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
Page 50 of 172
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.
%
%
1HWZRUN
$
1HWZRUN
&
D
$
LQ
+RVH
'
'
$
$
1HWZRUN
%
&
F
LQ
1HWZRUN
&
E
+RVH
%
G
LQ
'
LQ
+RVH
'
&
+RVH
Figure 12: Four Uni-directional Hoses.
•
Hose 1:
Scope: Ingress A, Egress B, C, and D
Traffic Conformance Parameter: ain as the maximum allowed throughput from A
•
Hose 2:
Scope: Ingress C, Egress B, A, and D
Traffic Conformance Parameter: cin as the maximum allowed throughput from C
•
Hose 3:
Scope: Ingress B, Egress A, C, and D
Traffic Conformance Parameter: bin as the maximum allowed throughput from B
•
Hose 4:
Scope: Ingress D, Egress A, B, and C
Traffic 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 specifications
about 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 the
couples of (ingress, egress) points.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
Page 51 of 172
Model 3: Additional constraints are put on the throughput from the network towards the customer
at each egress, i.e. the funnel (filter) model (SLS type 1.c) is applied at each egress point to limit
the 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.
ERXW
DLQ
$
ELQ
1HWZRU
DRXW
%
F LQ
F RXW
GRXW
&
GLQ
'
Figure 13: VPN with 8 SLSs
This model is the preferred (hose) model VPN providing performance guarantees based on aggregate
traffic specifications. The customer needs to only specify the aggregate traffic in and out of each hose
endpoints. Unlike the pipe model VPN, the customer does not have to specify the full traffic matrix or
the spread of this traffic to other hose endpoints in the VPN. This gives the customer freedom to send
traffic between each pair of endpoints, provided the aggregate traffic in and out of each of the
endpoints does not exceed the respective hose capacities.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 52 of 172
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 will
elaborate on its exact functionality and provide some input on how it might be implemented and
proven useful in the TEQUILA functional architecture.
The main function of traffic prediction is to generate a traffic estimation matrix to be used by the
Network Dimensioning functional block.
What needs to be predicted is the amount of traffic of each customer service type, that will enter the
AS 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 sourcedestination matrix will be made for each customer service type. This may already yield a considerable
amount of information, especially when considering IP VPNs…and possible private addressing
schemes.
A second level of aggregation takes into account inter-domain traffic and it combines all traffic that
needs to end at a certain destination AS (that means the traffic prediction function needs to have
insight into the BGP route information).
From this, a second matrix can be constructed, a source-destination AS matrix will be made for each
customer 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, yielding
the use of the MED attribute, for example), both matrices can be combined to find the full amount of
data between any ingress and egress router in a certain AS. This yields the following Traffic Prediction
Matrix:
Per class of service, the predicted traffic load per ingress/egress pair
per Class of Service
Egress_x
Ingress_I
A(I,x)
Egress_y
Ingress_J
Per CoS: A(I,J) is the predicted load between ingress I and Egress J. It counts as well the solely intradomain 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 available
within the AS itself, and its negotiation of capability (and cost associated with) aggregate SLS with the
selected next hop (see also the section on inter-domain SLS negotiation). Subsequently, Network
dimensioning will dimension the internal links of the AS to be able to transport the traffic and interact
with 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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 53 of 172
•
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 policy
rules. Indeed, long–term SLSs allow for over-subscription because not all SLSs will actually be
invoked at the same time. Take for example an Access Router, which terminates (incoming) xDSL
lines with a 1 Mega bps capacity. Given that the Access Router has an (outgoing) link capacity of 100
Mega 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 a
traffic load of 400/5 = 80 Mbps.
Further details about over-subscription, and how this might affect the SLS format and semantics, can
be found in section 4.4.5. This discussion may introduce a new SLS attribute, i.e. Grade of Service or
Blocking probability. This attribute is typically for enabling the network operator to have oversubscription policies. The attribute is also specific for SLS subscription objects (and not SLS
invocation objects).
4.4.2 SLS-Management, Traffic Forecast & Dimensioning
Before going into the details of the Functional Scenarios about SLS Handling, we first give the main
information streams and interactions between SLS management, Traffic Forecast (TF) and Network
Dimensioning (NW-Dim). This should give a high-level understanding of how things are actually
working, i.e. how is the Tequila network dealing with new/modified SLSs.
Network
Monitoring
Over-subscription
policies
[aggregate NW load]
[over-subscription Indexes]
Traffic Forecast
[SLS repository]
[Traffic Matrix]
SLS subscription
NW-Dimensioning
[NW config]
[SLS policies]
[Traffic Matrix]
[physical resources]
[topology]
[NW config]
planning
A.C. / SLS
Invocation
[current network load]
Network
Monitoring
Figure 14: SLS-Management, Traffic Forecast and NW-Dimensioning (1)
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 54 of 172
Network Configuration – Actual allocated Resources
The Network Dimensioning FB receives as the main input the Traffic Forecast Matrices, the physical
resources (planning) and eventually policy rules. It calculates the Network configuration. The Network
Configuration 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’s
note: 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 Forecast
Matrix. However, the NW Configuration gives the resources that are actually allocated while the TF
Matrix is a prediction of the load.
Of course, network configuration has also more “detailed” parameters important for the configuration
of 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 SLS
subscriptions. This is based on administrative policies and available spare resources.
SLS subscription (and not NW-Dim) calculates the available spare resources for new SLS subscription
requests. 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”. This
can 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 given
in the next Figure.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Network
Monitoring
Page 55 of 172
Over-subscription
policies
[aggregate NW load]
[over-subscription Indexes]
Traffic Forecast
[SLS repository]
[NW Config]
[Traffic Matrix]
[Spare Resources]
SLS subscription
NW-Dimensioning
[physical resources]
[topology]
[SLS policies]
[NW config]
planning
A.C. / SLS
Invocation
[current network load]
Network
Monitoring
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 Spare
resources, based on its input (as before) and the Network Configuration. An advantage is e.g. that only
Traffic Forecast must be aware of the over-subscription policies. A choice between the two
alternatives 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 is
only long-term, e.g. a VLL for data-traffic, then the SLS invocation process is superfluous because the
SLS 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 be
the responsibility of the (Tequila) Network operator or the Customer, depending on the business
model. This is explained into more details in chapter 4.5, discussing the support of Integrated
Services 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’t
have 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 network
configuration and thus also the bandwidth of pipes on a relative long time scale. Dynamic resource
management MAY vary this bandwidth pipes between certain thresholds, according to Policy rules
and the instantaneous (measured) load.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
-
Page 56 of 172
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 the
Dynamic Resource Manager
-
Measured load = 9 (value obtained by Monitoring)
The exact Calculation of “short-time” spare resources, i.e. the Admission Control Algorithm, is subject
of Deliverable D1.2 and it will probably depend on the previous Bandwidth definitions, on the Class of
Service, 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 of
the network. Roughly speaking, consider a micro-flow with scope [Ingress, Egress] = [A, B]. Then, at
the 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 negotiation
This section briefly introduces possible schemes for Inter-domain SLS negotiation. The section only
gives a high level overview of SLS-negotiation approaches. More details with other functions related
with 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-hit
1
2
AS1
3
AS2
AS3
SLS
Site
B
Site
A
6-ACK
5-ACK
4- ACK
Figure 16: Hop-by-Hop SLS negotiation
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 57 of 172
Consider the example of a Virtual Leased Line between Customer site A and B, crossing three
Autonomous 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 between
Customer-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 for
handling 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) if
itself gets an ACK of AS (I+1). In the example above, AS3 first has to acknowledge, followed by AS2
and 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 negotiation
In this case AS1, which is (first) hit by the SLS, is responsible for the establishment of resources from
customer site A to customer site B.
2: SLS-hit
1: pre-establishment of “Internet” pipe SLSs
AS1
AS2
AS3
SLS
Client
AccessSite
Site
A
B
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 last
AS/destination (depending on the nature of the destination). This is actually done before the SLS
arrives at AS1.
How these pipes are effectively put in place is rather a business issue than a technical issue. For
example, AS1 could have negotiated a bandwidth pipe SLS with AS2 where the destination is part of
the contract (e.g. site B with a particular network prefix). It is then the responsibility of AS2 to preestablish pipes with (eventually) other ASs to reach destination B.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 58 of 172
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 is
however that each AS must maintain an Inter-domain Matrix of available pipes for traffic origination
from 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 quantitative
guarantees, e.g. Olympic or Best-effort services.
There are no restrictions on the SLS-scope or the SLS-Flow Identification. There will be no signalling
in the control plane.
AS3
1: SLS-hit
AS1
AS4
SLS
Site
A
Site
B
AS2
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 the
establishment of an ADSL access line (with e.g. 1 Mbps capacity). After the ACK (customer paid for
his access line), the customer may send “better-than-best-effort” traffic, e.g. gold/green traffic. He has
no 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 such
as VoIP. Of course there are no hard guarantees.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 59 of 172
4.4.4 SLS-subscription & -Invocation inter-working
4.4.4.1 Terminology
The following sections give an overview of the Customer service (SLS)-handling for the TEQUILA
system. The SLS management functional component is responsible for all the Customer-service (SLS)related activities. Considering the Customer-service handling functional process we may consider
three 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 into
more detail in respectively section 4.4.5 and 4.4.6. Examples illustrating the ideas can be found in
section 4.4.7. In the following we will mainly use the terminology “SLS subscription, SLS
invocation”, etc…
4.4.4.2 Partial and dynamic SLS invocation
Before going into details and the Message Sequence Chart of the sub-process, it is important to
emphasise the following concepts about the inter-working of the subscription and invocation
processes.
•
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 these
process 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 the
customer requires contractual guarantees from the network, which may be controlled – THEN
the customer service subscription process is MANDATORY. For example all long-term SLAcontracts 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 always
be blocked (even if the SLS-instantiation contains some quantitative guarantees). Typically
this 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 SLS
is then invoked by RSVP signalling (for more details refer to the IntServ over DiffServ
section). Its content is derived from the IntServ FlowSpec and Rspec objects. The DiffServ
SLS lives for the duration of the IntServ flow. Remark however that certainly not all microflows, like IntServ flows, are by definition invoked without previous subscription. On the
contrary the” usual” way is that there is a previous subscription phase, followed by
(eventually ” partial” invocation – see next).
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
-
•
Page 60 of 172
SLS-invocation is (always) a MANDATORY process; i.e. no data-flow is possible without an
SLS-invocation (and admission). However, the SLS-invocation process may be
SUPERFLUOUS, 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 may
be invoked immediately at the time of making the contract. Thus: Invoke once, run till next
negotiation. Remark that a superfluous SLS-invocation process does not give any
supplementary information (to the network) than was already available after the SLSsubscription process, I.e. in the SLS-object resulting from subscription. This type of
invocation could also be called static SLS-invocation.
Partial SLS-invocation is possible in case of “real different” SLS-subscription and SLSinvocation 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 customer
service (VLL) for the aggregate VoIP traffic while each individual VoIP call “invokes” 2 microflow SLSs (dedicated for this particular call).
In this example, the SLS subscription captures the (long-term) characteristics of the VLL, while
for each (short-lived) VoIP call there is a dedicated SLS-invocation. This example is explained
into 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 the
SLS-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 egress
point 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) SLS
object must be “smaller” than the conformance parameters of the (aggregate) subscription SLS
object.
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 of
the customer or of the network operator. In any case, the network operator will certainly perform
policing 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 deduced
from the SLS subscription process/object. One can consider three types of dynamic SLS
invocation (objects).
-
Customer services/SLS without previous SLS subscription.
-
Invocation of the (full) SLS object previously subscribed for a finite period of time. For
example, watching a Video (on Demand) on Monday 3 July 2000 in the evening from 8 to 10
p.m. This is invocation of a previously subscribed SLS which states that a video MAY be
watched etc… (see example 4.4.7.2 for more details).
-
Partial invocation of the SLS subscription object previously subscribed. Remark that partial
invocation is by definition dynamic.
Normally dynamic invocation will result in an (invoked) SLS object that only exists for a finite
period (for the “micro-flow call duration”). More details are given in the sections below and
examples clarifying these concepts can be found in section 4.4.7.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 61 of 172
4.4.5 SLS Subscription handling
Customer service subscription is basically the process of customer registration & policy-based
admission. Its basic functions are part of the Management Plane. The customer might either be a peer
Autonomous System (AS) or a business or residential user. The subscription (or registration) concerns
in the first place the Service Level Agreement, containing amongst others prices, terms & conditions
and the SLS (or set of SLSs making up the customer service). Only the latter (SLS) is in scope of the
TEQUILA 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 traffic
conformance parameters and guaranteed rates.
Customer service (SLS) subscription results in a Customer Service (SLS) object.
4.4.5.1 SLS subscription object
The SLS subscription class is the same as the SLS invocation class (defined in the SLS specification
section) plus one additional attribute Grade of Service (GoS). The SLS subscription template is thus
the 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 from
the 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 or
customer interface).
•
Traffic Forecast information. In case the required guarantees are “better-than-best-effort”, then
the token bucket parameters (b,r) MUST be specified in the SLS subscription object. The token
rate r is (of course) the conformance parameter of the (aggregate) packet stream specified in the
flowspec of the SLS subscription object. The token-rate r can be used for the Traffic Forecast
module. Indeed, the long-term "average” rate or mean m is smaller than r (m”U ,I QR VLOHQW
periods are present in the traffic stream, i.e. traffic is continuously injected by the customer (the
bucket 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 performance
parameters of the SLS subscription are specified for the (aggregate) flow given by the
FlowSpec in the SLS subscription object. The performance guarantees are of a “static”
nature, they last until the next negotiation of the SLS subscription object.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 62 of 172
-
If GoS is specified, then there will be dynamic invocation of the SLS; this may eventually
be a partial invocation. In this case the Service Schedule SLS attribute MUST be specified
in 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 Service
Schedule period.
Concerning the meaning of the performance parameters in the SLS subscription object, there are
following possibilities:
-
The performance parameters MUST NOT be specified in the SLS subscription object, but
in the SLS invocation object at moment of SLS invocation.
-
The performance parameters MAY be specified, but they only have an indicative meaning
for the SLS that will be invoked in the future. The SLS invocation may copy or even
overwrite these performance parameters of SLS subscription.
Thus, the “hard” guarantees are always given in the SLS invocation object!
4.4.5.2 Message Sequence Chart
Figure 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 permission
or refusal of (new or change) SLS-subscription requests. Essential information comes from the
Policy 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” to
the traffic-forecast module.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 63 of 172
SLSsubscription
User/
UpstreamAS
(management)
Traffic
Conditioning
Admission
Control
SLS
Subscription
Network
Inter-domain Downstream
Traffic
Dimensioning SLSrequestor
AS
Forecasts
Traffic matrix
Policy
Network configuration
the algorithmfor mapping of network configuration to available resources (for newSLSs), i.e.
“available resources = current network configuration - those resources allocated for existing SLSs”
could be placed in SLSSubscription, as here, or it could be located in Network Dimensioning (for further
study, also see note *** on next MSC)
Request newSLSor change existing SLS
Business policy rules
Refer interdomain request
if peer ASterminates egress
OK/NOK
Request
OK/NOK
Price, terms+conditions, etc. or NOK
Referral as before, if necessary
Negotiation phase (repeat as needed)
Buy SLS
If interdomain SLS...
Store newSLS
in repository
Acknowledgement
SLSselection
conditioning
rules/policies
rules/policies
(in suspend mode)
SLSs passed
to Traffic
Forecasts*
“Trigger”**
Request new/modified interdomain
SLS, if required.
Request
OK/NOK
To/fromdynamic management
Network configuration
Available resources
* This does not necessarily happen for every newSLS, it could take place when a certain threshold has been crossed or it could be “polled” from
Traffic Forecasts
** when set of accepted or rejected SLSs is significantly different fromcurrent configuration - may be initiated by Traffic Forecasts when certain
conditions have been fulfilled (policy?) or may be invoked periodically by Traffic Forecasts or Network dimensioning
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 the
customers. It includes an SLS subscription repository, which stores all SLSs permitted and SLSs
refused.
•
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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 64 of 172
•
Remark: The (long-term) SLS permission is by no way a per flow Admission Control (we use the
terminology Permission to make the distinction). SLS subscription permission is not based on an
instantaneous snapshot of load/spare capacity, but a longer-term view provided by Network
Dimensioning functions.
•
The Permission/rejection process is performed within the SLS-subscription functional block and
NOT 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 handling
SLS invocation is basically the process of “establishing” the flow and it is mainly done in the Control
plane. The process is in all cases mandatory. The “nature” of the invocation process is determined by
the 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 for
100 Mega bps, then the “sum” of already partially invoked flows must be less than 100
Mega 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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 65 of 172
4.4.6.3 Message Sequence Chart
Dynamic SLS Invocation
User/
Upstream
AS
(control)
Monitoring
User/
Upstream
AS
(data)
Traffic
Conditioning
Admission Control
SLS Invocation
SLS
Subscription***
Policy
SLS
Node
Establishment of factors
for Admission Decisions
Admission rules/policies
Monitoring Request at network or node level
((re-)set thresholds)
*
Monitoring Request
threshold crossings
Monitoring Report
(threshold crossings)
*
Admission Request
With previous subscription
Dynamic SLS request
Data Transmission
Network
SLS subscription object
Request load info (if certain rule applies)
Signal egress AC or refer to
network level AC**
Activate conditioning
rules if OK/deny if NOK
OK/NOK
Report NOK
OK/NOK
(if NOK further negotiations may take place)
May trigger Dynamic Control/
Dimensioning/Traffic Forecasts
start
data
May trigger Dynamic Control/
Dimensioning/Traffic Forecasts
* 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 been
subscribed, and it may be necessary for those which have already been subscribed.
*** this could be Network Dimensioning (see note on previous MSC)
Figure 20: Dynamic SLS Invocation MSC
Remarks
•
Admission control is in fact performed for Customer services, which might be a set of SLSs. In
case of bi-directional customer services, e.g. VoIP, this requires a signalling protocol between the
two edges (ingress/egress and vice-versa). At least, if the admission control of (micro) flows is
done 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 could
also be needed for Uni-directional flows, e.g. if there is a bandwidth bottleneck at egress (in case
of for example a “slow access link downstream”).
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
Page 66 of 172
The above MSC describes the invocation of the SLS/Customer service. In case of dynamic
invocation, 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 or
soft state based. In any case, the shut down must delete the SLS invoked object and trigger some
actions (such as informing the Traffic Conditioning component, dynamic control component,…).
4.4.7 Examples
4.4.7.1 Virtual Leased Line for a Business Customer
Two company sites of a Business customer are directly interfacing with the TEQUILA Autonomous
system (i.e. a single AS example). The customer asks an E1 VLL (2 Mbps) between the two sites. The
VLL 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 object
resulting 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 as
signalling 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 services
A residential user bought an ADSL modem and – after some physical installation & configuration
issues – the user wants to have access to a Video on Demand (VoD) Service Provider (all across the
Internet).
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 of
Presence PoP). For simplicity we also assume that the VoD service provider is directly attached with
the TEQUILA network.
•
SLS subscription: Via a Web-based tool the user establishes a (long-term) contract with the
TEQUILA network provider. Roughly speaking, the SLS states that the user MAY watch
everyday between 8 and 11 p.m. a Video (on Demand) which can be downloaded from a wellknown service provider. The user expects a good quality real-time service. The SLS could look
like 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
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
-
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
Page 67 of 172
The blocking probability gives the probability that the SLS-invocation (call attempt) of the
user (i.e. watching a video) is blocked during the Service Schedule period. The Performance
parameters 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 on
the SLS subscription contract, the user has (only) access to the VoD server. SLS admission (or
blocking) is based on PPP-Authentication information (checked with the SLS subscription
information) 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 overwritten
according 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 traffic
A business customer wants to establish a contract saying: I want to inject x=10 Mega bps of real time
IntServ or VoIP flows (100 Mbps is the maximum allowed rate of the aggregate traffic stream). Flows
can 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 flows
themselves are short-lived but the contract of the customer is long-lived because he wants the 10 Mbps
guarantee for aggregate VoIP flows. The customer does not want to negotiate SLA/SLS for each
individual 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 the
demand of the customer.
In the first approach, micro-flow SLSs will be created/invoked for each individual VoIP flow. This
should 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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 68 of 172
In the second approach, there will be no SLS invocation for each micro-flow. Instead, the customer
asks 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 second
approach is that there is no need for a dedicated IP-signalling protocol (such as RSVP) establishing the
individual 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 SLS
subscription object. Authentication & authorisation is based on this match.
* The parameters (and these below) MUST e.g. be determined from signalling protocol for
setting 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 the
authorisation check (matching IP address of call with network prefix of SLS subscription), the
admission 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 moment
of subscription (similar to the VLL example above). The network can not give any hard, quantified
guarantees concerning individual VoIP flows; the network can not make distinction on inprofile/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 (and
other data-traffic). In this approach, the SLS instantiation at the moment of subscription could look
like this:
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
Page 69 of 172
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 service
without hard quantitative guarantees”
•
SLS invocation: Invocation of the SLS is automatically at time t= tstart. There is no separate
invocation per micro-flow! Thus, there is no “admission control” per micro-flow, nor blocking
probability.
The basic assumption for this approach is that the vast majority of traffic will anyhow be best-effort
data-traffic. Therefore, by giving priority to real-time Olympic gold packets, the service quality of
individual 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 the
Internet.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 70 of 172
4.5 Integrated Services Support
4.5.1 IntServ over DiffServ : General architecture
4.5.1.1 The ISSLL model of the IETF
This section discusses the support of Integrated Services (IntServ) over the TEQUILA Differentiated
Services (DiffServ) network. A starting point is a model as it is proposed today by the ISSLL Work
Group of the IETF (IntServ over Specific Link Layers working group). The model is given in the IETF
draft [IS-DS-1] A framework for IntServ operation over DiffServ networks, version 05. Main issue in
this 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 the
traffic characteristics of an IP (RSVP) flow. Signalling is done by a number of RSVP-messages, such
as PATH and RESERVATION, which contain RSVP-objects, such as Tspec with the token-bucket
parameters of an IP flow (Figure 21: IntServ support over a DiffServ network).
5(60(6
,QW6HUY'LII6HUY(GJHGHYLFHV
‡7VSHFUESP0
‡5VSHF5VHUYLFHUDWH
7[
3$7+0(6
&'6''6
5[
‡$GVSHF&,',
4((¡05E05[S5SU&
((5'((
Figure 21: IntServ support over a DiffServ network
•
GS is meant for real-time multimedia applications. It guarantees loss-less transmission for inprofile traffic together with a deterministic upper bound for the E2E queuing delay (QE2E). This
bound depends on the traffic characteristics of the sending source (described by the token-bucket
parameters, given in Tspec) and on the (reserved) service rate R (given in Rspec). Moreover each
router adds a particular contribution to QE2E because its implementation deviates naturally from the
GPRS 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-media
applications and VPNs without the deterministic delay-bound requirement. It guarantees a service
rate R over an “appropriate” time scale. CL traffic could e.g. be implemented in an isolated FIFO
queue with Head of Line (HOL) priority over best effort.
The token-bucket parameters TSpec are signalled from transmitter (Tx) to receiver (Rx), while the
receiver 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 the
Reservation Message must be repeated e.g. every 4 seconds for keeping up the connection. The
receiver may change the QoS “on the fly” by this soft state mechanism by e.g. increasing the service
rate 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 typically
between r (“i.e. the “sustainable rate”) and p (peak rate).
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 71 of 172
The rate R is asked by the receiver in order to get its desired E2E delay bound QE2E. The formula is
given in Figure 21. The (C, D) error terms measure the deviation from the fluid-flow model. Each
IntServ hop MUST add its (Ci,Di) delay contribution. CE2E and DE2E are the sum of Ci and Di
respectively. This means that the delay error terms are additive; in other words: The E2E delay is a
worst 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 for
capturing 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 & quality
based).
•
based on the formula for QE2E and the error terms (CE2E, DE2E ), the receiver calculates the
rate R he is willing to have
•
The requested rate R is sent backward with an RSVP RESERVE message and each hop
reserves the appropriate resources (or rejects).
In a sub-network which is not IntServ capable, like the DiffServ Tequila cloud, the ingress router
MUST indicate the (CDS, DDS) error terms taking into account the entire path of the IntServ flow in the
sub-network. These error terms (CDS, DDS) should also indicate the worst case delay (deterministic
delay 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 are
either IntServ Guaranteed Service or Controlled load.
•
The DiffServ network, e.g. the Tequila network, is a “finite” cloud (island) in a “broader” IntServ
environment.
•
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 responsible
for
-
Doing the appropriate (IntServ-RSVP) admission control,
-
Performing the required (DiffServ) traffic conditioning,
-
Mapping IntServ classes on DiffServ PHBs, or more exactly, marking incoming IntServ
packets with the appropriate DiffServ Code Point (DSCP).
•
In case of an IntServ Guaranteed Service IP flow, the downstream IWF is responsible for setting
the delay parameters (CDS, DDS) for the entire downstream path in the DiffServ network. (See later
on 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-IntServ
capable 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 the
DiffServ network (control plane).
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
-
Page 72 of 172
The QoS class mapping itself, i.e. mapping the IntServ classes Guaranteed Service and
Controlled load on DiffServ PHBs (data plane). This is subject of the very recent draft [ISDS-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 very
unclear 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 largely
determining the overall architecture and QoS functionality of the network. The following gives a
possible functional decomposition of such a device. The figure is only informational, other
implementations 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
COPS
E -B G P
O SPF
F IB
SLS agent
PEP/ A C
R S V P - C o n tro l
M F -C la ssifie r
P o lic e r
Shaper
M a rk e r
Shaper
P o lic e r
M F -C la ssifie r
Figure 22: IS-DS functional block diagram
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 73 of 172
4.5.1.2 Two Business Models
There are two possible business cases for a DiffServ network operator (“the Tequila ISP”) for
interacting with its IntServ capable neighbours (either access networks or peer ISP). Both models are
mentioned 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 DiffServ
SLA contracts with its peers. The IntServ neighbours are themselves responsible for doing the
mapping. 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 router
interfaces with a “RSVP gateway” router which acts as the IntServ/DiffServ inter-working device.
RSVP
RSVP
IntServ/DiffServ Access router
DiffServ edge router
IAR
IER
EER
EAR
DiffServ AS core router
Figure 23: two business scenarios
In this model the DiffServ network is completely IntServ transparent. Therefore the model has no
particular consequences for the TEQUILA functional model, the system design or the DiffServ SLS
definition.
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 Tequila
edge routers are IntServ capable. The IS-DS IWF device is situated inside (at the edges) of the Tequila
network.
RSVP
RSVP
IntServ/DiffServ edge router
IAR
IER
EER
IntServ Access Router
EAR
DiffServ AS core router
Figure 24: Native IntServ support
4.5.2 IntServ & the Tequila Functional Model
High level Requirements
The TEQUILA requirement section specifies the following:
The TEQUILA system supports both the integrated services and differentiated services end-to-end
models. The TEQUILA system assumes only the RSVP resource reservations protocol in the context
of the IntServ model…
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 74 of 172
The TEQUILA system must provide for Best Effort, Controlled Load and Guaranteed Service end-toend networking in the IntServ model… The TEQUILA project (however) assumes the DiffServ model
in 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 AS
and 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 the
functional model and the SLS Object definitions MUST be capable to capture the IntServ requirements
as stated above. This means two things
-
The service requirements imposed by the IntServ model MUST be mapped on TEQUILA SLS
objects. That is: the IntServ Guaranteed Service (GS) and Controlled Load (CL) MUST be
mapped on a SLS object. Thus, the TEQUILA SLS class definition is more generic than the
IntServ traffic objects (TSpec, RSpec, AdSpec). This mapping is done at the edges of the
DiffServ network, the core MUST be IntServ transparent. More details and the relations with
SLS subscription & invocation are given below.
-
Once the mapping of IntServ services on Tequila SLS objects has been executed, the
TEQUILA functional model treats these (IntServ) SLSs “as usual”. For example a VoIP call
can be mapped by the application on the IntServ GS class or the application may directly
negotiate a TEQUILA SLS with the TEQUILA network. In both cases, once the SLS object is
defined and instantiated, the TEQUILA functional components (and network elements doing
the work) do not see any difference between the two approaches.
•
Regarding the Tequila functional model, it is concluded that only the SLS management
component MUST be “IntServ” aware. This component performs the mapping of IntServ flows
onto TEQUILA DiffServ SLSs. Eventually also the policy management component MAY be
IntServ aware in defining certain “IntServ business policies”.
•
Regarding the Tequila Top Level Design, it is concluded that only the edge routers MUST be
IntServ (RSVP) aware. However the mapping of IntServ flows on DiffServ SLSs MAY be done in
the 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 Tequila
DiffServ SLSs as defined in the SLS template specification.
•
The capturing of the IntServ RSVP signalling by the functional model, i.e. the Message Sequence
Chart.
This should capture the first requirement formulated above. However, the second requirement (intradomain resource management) and third requirement (DiffServ-DiffServ Inter-domain-working) is not
specifically treated here. As stated above, once the mapping on SLSs is done, the other functional
components should treat these SLSs as any other.
For example, the basic question how the IntServ QoS requirements can be met by the Tequila network
is 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 on
PHBs) at the end of this section.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 75 of 172
4.5.3 The Exterior RSVP Gateway Model
$GPLVVLRQ
&RQWURO$JHQW
6/6FRQWUDFW
6WDWLF'LII6HUY
3LSHV
,6'6
7[
'6,6
3$7+0(6
5[
5(60(6
Figure 25 : The RSVP gateway business scenario
In this business scenario, the RSVP gateway node, outside the Tequila network, does all the work. The
basic 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 the
customer does NOT dynamically change with each (new arriving or expiring) IntServ flow. Also the
pipes inside the DiffServ cloud are statically in this sense (which does not exclude appropriate Traffic
Engineering of the pipes on a “longer” time-scale, e.g. every hour or every day recalculation of the
pipes).
Note 2: The IETF draft [IS-DS-2] only mentions static DiffServ SLAs (as explained in note1). A
discussion point is whether more dynamic SLSs are possible. Could e.g. the available bandwidth for a
certain DSCP mentioned in the SLS, be modified on arrival of a new IntServ Flow? This would
require 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 RSVP
gateway, 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 Tequila
Functional 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 to
multiplex the IntServ flows into the DiffServ pipes.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 76 of 172
4.5.4 Native IntServ support
4.5.4.1 Overview
The Tequila operator positions itself as a supplier of native Integrated Services, i.e. support of native
Guaranteed Service and Controlled load IP IntServ flows.
/RFDO$GPLVVLRQ
&RQWURO$JHQW
5693
,6'6
7[
'6,6
3$7+0(6
5[
5(60(6
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 SLS
invocation. If a new IntServ flow is established, the IntServ QoS characteristics must be mapped
onto 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 SLSinvocation 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-state
refresh 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… are
applied in order to serve this (“IntServ”) SLS. This is explained in the sections describing
these functional blocks.
•
NOTE: The SLS invocation/creation happens at the time of the arrival of the RSVP RESV
message, and only exists for duration of the IntServ flow. However possibly the customer has
also a long-term SLS subscription (object) with the Tequila Network provider which e.g. gives
necessary information about authentication & billing. See the SLS-handling section for more
details.
4.5.4.2 Mapping IntServ flows on DiffServ SLSs
The 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 the
RSVP PATH message.
The necessary information, i.e. scope, Flow Id, performance parameters, etc is obtained from several
IntServ objects in the PATH and RESV messages. Description of these objects can be found in
[RSVP-1], chapter 5.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 77 of 172
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 the
address must correspond with address in the Hop Class object in the RESV message (Hop class
identifies 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). This
information Is obtained from several IntServ objects: Sender Template object and Session Object
in 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 object
in the PATH message. The Conformance algorithm is the combined token & leaky bucket
algorithm: 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 be
marked 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 fact
should 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:
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
-
Page 78 of 172
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 the
RESV message). The Tequila network provider itself determines this delay bound: see below
on “exporting the delay error terms”.
-
Quantile for the delay bound: the delay bound is a probabilistic bound, allowing that some
packets 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 approach
as 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 RESV
message 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 RESV
message
-
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 a
much higher utilisation of network resources (in fact we follow here the same approach as in
ATM 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 be
investigated by the Tequila project and this time-scale should be a parameters of our Tequila
system)
•
on aggregate flows avoiding scaling issues!
•
only triggered “when needed” by a congestion indication mechanism
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 79 of 172
4.5.5 QoS Mapping On DiffServ PHBs
This section is purely informational.
It handles the support of (micro) IntServ flows by (aggregated) DiffServ PHBs. In fact this should be
solved 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 (by
definition) b/r. It corresponds with an delay encountered by the flow in a fluid-flow model (no extra
queuing delay nor delay due to packetisation). The Controlled load class requires that the per-hop
delay encountered by the flow is no more than b/r (for almost all in-profile packets, i.e. no quantified
guarantee).
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)
•
•
thus : IntServ flows with more or less the same b/r are aggregated around a burstiness
avg
“average” (b/r) , which is a parameter of the AF-class!
ag
ag
i
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 then
aggregating the DiffServ SLSs.
The more AF-classes supported the finer the granularity of the mapping.
•
•
per available AF-class
per AF class => an aggregate Tspec : (b , r ) = (™E , ™U )
•
•
avg
If only one AF-class is supported, then all CL flows are mapped into the same class. In this
i
case, the only parameter is the AF output rate = ™U
traffic conditioning (marking drop precedence) against aggregate Tspec
•
Traffic conditioning of each individual IntServ CL flow at ingress, based on token bucket
parameters
•
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
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
bandwidth must be available for time-scales shorter than delay bound
•
E.g. WFQ scheduler with weights appropriately set
Page 80 of 172
Personal Remarks
•
-
The exact calculation of the corresponding parameters (e.g. AF output rate,…) is for
further study (the RFC draft does not specify anything).
-
This architecture requires a dedicated DSCP for each AF-class intended for supporting
IntServ traffic. It means that “other” AF-traffic SHOULD NOT by mixed with IntServ CL
flows inside the Tequila cloud.
My personal advice is: ALL Controlled Load flows are aggregated and mapping into ONE
SINGLE AF class. Thus: no distinction should be made according to burstiness. About the code
point : one could eventually take a dedicated code DSCP which is not necessarily the standardised
code 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 with
given 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 the
pipe : REF = ™5L; Ri is captured at the ingress IS/DS router in the RSVP Res. messages (of the
individual flows)
•
Traffic conditioning of each individual IntServ flow at the Ingress router. The requirement is that
the 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 (like
with the CS/AF mapping).
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 81 of 172
4.6 SLS Management – Functional Block Decomposition
This functional component is responsible for all the SLS-related activities. Due to its complexity it is
further decomposed as shown in the figure bellow. Note that both SLS subscription and SLS
invocation (Admission Control) have a view on the repository (which itself is not a FB).
SLS Management
SLS
subscription
Inter-Domain
SLS Requester
SLS repository
A.C./SLS
Invocation
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 subscription
repository, 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 the
data-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. SLS
invocation objects), i.e. the Blocking probability or Grade of Service (GoS). This attribute should
allow for over-subscription of services and – therefore – optimal resource utilisation. We come
back to this in the sequel.
•
The SLS repository is in fact a Customer Service Repository, as discussed in section 4.4. It means
that 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, SQL
view, etc. We don’t go into further details on this.
4.6.1 Description of Functions
This 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/modified
SLS 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 from
a customer or a peering AS.
Action:
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
-
Page 82 of 172
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 SLS
Subscription 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 spare
resources). This Refusal-SLS repository can then be used as input for the traffic matrix and/or
Network Dimensioning
Permission = RE-NEGOTIATE / “hints”
-
Proposal of modified SLS object to the user/SLS inter-domain requester. This is only a
temporary 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/modified
SLS 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 after
subscription. This means:
-
The SLS subscription object = SLS invocation object and the SLS is stored in the SLS
Invocation Repository (just a mark that the SLS is activated)
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
-
-
Page 83 of 172
Delegation of rules/policies to the Traffic Conditioner. These rules should ensure that the
packets are marked with the correct DSCP, that the traffic excess treatment is accordingly to
the 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 after
subscription.
•
SLS Invocation Admission Control
This function accepts/rejects short-term SLS invocations (dynamic admission control). This function is
executed at the edge routers of the network. The Admission Control algorithm will be measurementbased.
Still under discussion is however whether or not there is the need for signalling between
ingress/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 between
Ingress/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
-
-
Notification of acceptation to the user or the SLS Inter-Domain requester.
-
New/Modified SLS object stored in the SLS Invocation repository (this will only be temporary
storage, 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.
-
Notification of acceptation to the user or the SLS Inter-Domain requester.
-
New/Modified SLS object stored in the SLS Invocation repository
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
-
Page 84 of 172
-
Notification to Node monitoring, which in turn must do the alarm triggering to Network
Dimensioning (Editor’s note: is this OK?)
-
Trigger the SLS monitoring
RED ZONE : Acceptation = NO
-
The SLS can not be accepted because a second threshold is crossed
-
Notification of refusal to the user.
-
Trigger the SLS monitoring
Note: The SLS information related to customers/users are kept in the SLS repository. The SLS
repository serves as input for the Traffic Forecast Module. TF calculates the predicted load, which will
be 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 the
service i.e., un-subscribed customers. This process must operate on both the customers who are not
using 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 a
user/upstream AS.
Still under discussion here is whether we will consider hop-by-hop Inter-Domain SLS negotiation (hop
AS, thus only SLSs with peers) or we will consider End-to-End SLS negotiation. In the latter case one
could have SLS contracts with non-peering ASs.
This is for further study/to be completed.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 85 of 172
4.6.2 Interface semantics and parameters
This section describes the interaction of the SLS Management Functional Block with other Functional
Blocks through events, messages or signals. Basic interactions were already given in Figure 14: SLSManagement, Traffic Forecast and NW-Dimensioning. The figure and the table below give more
details.
3ROLF\&RQVXPHU
6/60RQLWRULQJ
6/60DQDJHU
'RZQVWUHDP
$6
,QWHU'RPDLQ5HTXHVWHU
·
·
·
·
1:'LPHQVLRQLQJ
6/6VXEVFULSWLRQ
8VHU
8SVWUHDP$6
7UDIILF)RUHFDVW
6/6,QYRFDWLRQ
···
1HWZRUN6/6
0RQLWRULQJ
7UDIILF
&RQGLWLRQLQJ
Figure 28: Interaction of the SLS Management Functional Block with others
The description of the relevant events is included in the table that follows:
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
From FB
To FB
Event name
Parameters
Comment
1
PolicyConsumer
SLS_Manager
SLS_Manager_SetPolicy
2
SLS_Manager
SLS_Monitoring
SLS_Monitoring_SetSLSRepository
SLS Repository
The SLS Monitoring report is generated by the Monitoring FB based on their
measurements & the SLS Repository information
3
Dimensioning
SLS_InterDomain_Req
SLS_InterDomain_Req_Request_Interdomain_SLS
Resources
Requested
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 will
do 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 Prediction
Matrix
7
Traffic_Forecast
SLS_Subscription
SLS_Subscription_Set Traffic Matrix
Traffic Matrix
SLS Subscription needs the predicted traffic load for calculating long-term spare
resources
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 SLS
request 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 DO
THIS?)
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 has
always a view on the SLS repository, it need only be notified about changes to to
new/modified SLS subscriptions)
12
Network_Monitoring
SLS_Invocation
SLS_Invocation_Set_Currrent load
Edge-to-Edge load
SLS Invocation needs the current node load for calculating the short-term spare
resources
12’
SLS_Invocation
Network _Monitoring
Node_Monitoring_Alarm_Trigger
12’’
SLS-Invocation
SLS_Monitoring
SLS_Monitoring_Trigger
SLS Repository
SLS Monitor takes its input form SLS repository and activate the monitoring
action for new/modified SLSs (based on service and scope of the service).
13
SLS_Invocation
Traffic_Conditioning
Traffic_Conditioning_Set_Conditioning rules
SLS_Object info
After the successful invocation of an SLS, the edge node must be informed about
Conditioning 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 Process
SLS 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
Signalling of new subscription SLS. SLS Subscription will now trigger the
Process SLS Subscription Function
Setup of Policy Rules & (administrative) constraints
Admission Control Algorithms discovers threshold crossings. Monitoring must
now inform Network Dimensioning (To DISCUSS)
(subscr.)
15’
SLS_Subscription
User
User_ Notify_New_SLS
Notification/propos
al of modified SLS
Object
SLS subscription informs the user/AS whether the SLS subscription was
successful or not. Also re-negotiation make take place, based on a proposal of
SLS 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
D1.1: Functional Architecture Definition and Top Level Design
Page 88 of 172
5 TRAFFIC ENGINEERING
5.1 Intra-domain Traffic Engineering
5.1.1 Objectives and Approaches
Network Traffic Engineering (TE) is in general the process of specifying the manner in which traffic is
treated within a given network so that to meet its transfer requirements. The objectives of traffic
engineering are twofold, user-oriented and system-oriented.
•
User-oriented objectives: The users expect certain performance from the network; and the
network in turn should attempt to satisfy user expectations. The expected performance depends on
the type of traffic that the network carries. In the traditional Internet, traffic is best effort and main
requirements 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 of
best effort traffic. Hence the issue of satisfying traffic performance requirements becomes more
complicated and more important. This is of primary concern to Tequila; its main objective is the
provisioning of Quality of Service in a multi-service Internet.
•
System-oriented objectives: ISPs aim at satisfying the user traffic requirements in a cost-effective
manner. In addition, they attempt to accommodate as many as possible of the traffic requests, by
using optimally the available network resources. It is desirable to utilise highly the available
resources, however over-utilisation may result in missing transfer requirements. Hence, careful
system design is called for. In case the available system resources are not adequate, increase of
resources at minimal cost should be sought for.
The main routing method used today in the Internet is shortest-path routing with respect to certain link
cost. In the context of multi-service QoS provisioning, however, such an approach may not be
desirable always. It may lead to bottlenecks and oscillations. Furthermore, the chosen path may not
represent the best path necessarily with respect to QoS requirements; and, there is no guarantee
whatsoever, that what deemed as a best path at a time, will result in optimum network operation in a
period of time. There (has been and there) is today an increasing volume of studies on TE approaches
for 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 a
set of routes (paths) is computed (in a centralised and/or distributed manner) for specific types of
traffic. In addition, appropriate network resources (e.g. bandwidth) may be provisioned for routing
purposes, according to traffic requirements. Traffic is then routed within the established sets of
routes, 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, whereby
routes are computed in a completely distributed manner, as discovered by network topology setup. Although route selection is performed in a distributed fashion, the QoS-based routing decisions
will be constrained according to network-wide TE considerations made by the Network
Dimensioning algorithms. The most appropriate route, according to certain criteria, out of those
routes meeting the requirements of the traffic is selected. To the end of route computation and
selection, static and/or state dependent costs are associated with each link. Route computation is
usually based on shortest or widest paths with respect to the assigned link costs.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 89 of 172
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 a
distributed approach, while the MPLS approach could very well combine a mix of centralised and
distributed intelligence. The considered approaches are described in sections 5.1.3 and 5.1.4
respectively.
The considered approaches are amongst the most discussed approaches in literature and IETF, and
actively pursued by ISPs. Note that this does not exclude other viable approaches to emerge in the
course of the project.
It should be stressed that no correlation between intra-domain traffic engineering approaches in
different ASs, parts of the TEQUILA system, is assumed.
5.1.2 Elementary TE Functions and the TEQUILA TE Functional Model
As outlined previously, the term traffic engineering is a general expression for depicting techniques
which aim at processing traffic in the network, according to specific requirements and constraints (as
specified in contracted SLSs). It does not itself suggest a specific approach for handling traffic
flows/streams in the network. As such, the project has come up with two approaches, outlined
previously (more details can be found in the following sections). Anyhow, the choice of a specific
intra-domain traffic engineering approach should be a decision by the Autonomous System
administrator.
The results of the adopted traffic engineering policy should be enforced in the network by means of
appropriate network components. From this perspective, it is assumed that the following elementary
TE functions support the enforcement of the adopted TE policy:
•
•
•
•
•
Traffic Identification, (namely a flow identification, whereas a flow is defined as a collection of IP
datagrams which share at least one common characteristic – same source address, same protocol
identifier, etc.);
Traffic Classification, (namely flow classification, so that the switching resources of the network
enforce the appropriate policy, in terms of scheduling, dropping, forwarding and routing);
Traffic Metering, (so that the switching resources of the network appropriately adapt their
behaviour, according to the corresponding policy -(see above)).
Routing of traffic through the network. This involves route path selection and association of
bandwidth 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 the
network. In addition to these elemental TE functions, the TEQUILA system caters in its Functional
Model (presented in chapter 3) for a number of other functions complementing the elemental TE
functions, to the end of specifying a complete solution for intra-domain TE. Figure 29 depicts the main
functional building blocks to the purpose of traffic engineering during the TEQUILA system
operation.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 90 of 172
1 HWZRUN' LP H QVLRQLQJ
' \QDP LF5RXWH
0 DQDJH P HQW
'\QDP LF5HVRXUFH
0 DQDJH P HQW
5RXWLQJ
3+%(QIRUFHP HQW
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 by
the project (MPLS and IP-based, see section 5.2 describing the identified components). Further, it
should be noted that both approaches could co-exist in the network, as appropriate for specific types of
traffic, or simply because MPLS switching may not be deployed everywhere in the network considered
as a collection of autonomous systems. This is achieved thanks to the functional decomposition
implied by the Functional Model, by appropriately restricting the responsibility of the identified
functional components. The role of the intra-domain TE functional blocks (Figure 29) in the two
approaches (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 (and
it is in the proposed Functional Model) transparent to the SLS management and inter-domain traffic
engineering approach. Appropriate interactions on suitable components ensure their inter-working in
the context of a single system. This should allow different operators to select different intra-domain
traffic engineering approaches, e.g., dependent on the availability of MPLS network capable
equipment.
Last, it should be noted that the specified Functional Model, especially the interfaces between the
identified functional blocks, will be continuously reviewed according to the maturity of the underlying
ideas and in the light of the algorithms/protocol specifications and experimental results, to be
undertaken by the project.
5.1.3 MPLS-based Traffic Engineering
This section provides the MPLS traffic-engineering framework of the TEQUILA system. MPLS TE is
exercised 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 on
predicted traffic loads and existing long-term SLS contracts. Following, the routes (path,
bandwidth) as well as associated router scheduling and buffer mechanisms are defined. This
process is done off-line taking into account global network conditions and traffic loads. It involves
the global trade-offs of user and system oriented objectives; it is part of the Network
Dimensioning 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 Management
components of the Functional Model, see Figure 29) are employed in order to ensure high resource
utilisation and to balance the network traffic across the LSPs specified by long term MPLS. These
dynamic management procedures perform adaptation to current network state within the bounds
determined by long-term traffic engineering. Triggered by inability of dynamic management
functions to adapt appropriately, or by significant changes in expected traffic loads, or local
changes in network topology, LSPs may be created or torn down by long-term TE functions.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 91 of 172
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. By
virtue of the specified Functional Model, all these functions inter-operate to the objective of offering a
complete 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 setpairs. The term set-pair refers to the fact that in certain cases such as VPN traffic from a certain source
may be directed to multiple outputs or vice versa.
5.1.3.1 Long-term MPLS TE
n e tw o r k
p la n n in g
L S P D e te r m in a tio n
L S P A g g re g a tio n
T ra ffic
F o re c a s t
T r affic T r u n k s ,
T r af fic T ru n k
A ttr ib u tes
P H B T re atm e n t
of L SP s
S c h e d u lin g a n d
B u f fe r in g m e c h a n ism
p a ra m e te r s
L in k B an d w id th
R es e rv atio n
A d m in is tr a tiv e
P o lic ie s
L o a d B ala n c in g M e c h a n is m s
A n d P a ra m e te r s
Figure 30: Long-term MPLS Traffic Engineering
The long term TE process is illustrated in Figure 30. It is realised by the Network Dimensioning
component. Its inputs are:
•
•
•
Network topology and the link capacities (capacity, delay, PHB capability) as determined by the
Network Planning component.
Predicted traffic between various source-destination pairs. Traffic predictions are calculated by the
Traffic 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 these
contracts and thus has to reserve the appropriate network resources.
Administrative policies regarding physical restrictions on the allowable paths of certain types of
traffic. E.g. traffic coming from a given AS is not allowed to pass through certain parts of the
network, 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:
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
•
•
Page 92 of 172
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 consistent
high 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 with
the 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 B
form a traffic trunk. Aggregating flows to traffic trunks results in fewer LSPs. This has obvious
benefits to scalability and LSP management. However, care should be taken in order to ensure that
SLS contracts are observed (see the discussion below). Next, TE attributes are associated with each of
the traffic trunks. The TE attributes are used for LSP design, and network resource allocation. Along
the 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 is
policed and treated. Care should be exercised in the manner these attributes are defined since a
trunk may consist of an aggregate of flows specified by different SLSs. Aggregating traffic
policing parameters of a number of SLSs may result in unfair and out-of-contract treatment of
certain flows.
Path selection attributes. These attributes specify the administrative constraints on the traffic trunk
paths, as well as constraints imposed by QoS requirements. For example, if the traffic trunk has
strict delay requirements, then long delay links (e.g., satellite links) are avoided and a maximum
hop-number on the LSPs may be imposed. On the other hand, for best effort traffic trunks, a
shortest path selection methodology may be applied.
PHB attributes. These attributes specify the possible PHB treatment of the trunk traffic throughout
the network. That is, they may specify a list of PHBs to which the trunk traffic may be assigned as
it traverses the network routers. For example, for type 2 SLSs the possible PHB attribute may be
AF1, AF2, or AF3.
Path adaptation attribute (0 or 1). This attribute specifies whether the selected LSPs are subject to
re-optimisation. This information will be used in conjunction with short-term TE to determine
whether LSPs can be modified (either by rerouting or by modifying the reserved resources) to
adapt to changing network conditions during the operation of the network
Resilience (reliability) attributes. These attributes specify the treatment of the trunk traffic when
network component failures or faults occur. They specify choices such as, whether recovery
should be attempted by re-routing, whether only failure notification should be provided without
any 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 also
meaningful 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 bidirectional paths may be implemented as two unidirectional paths with the restriction that they are
created activated, deactivated and destroyed together. Hence, from a TE point of view, only
unidirectional trunks need to be considered. If however, the restriction is imposed that bi-directional
paths are established on the same links, then TE must take into account the existence of bi-directional
trunks in the design of LSPs. In TEQUILA, the former approach is followed that is, bi-directional
trunks are treated as two uni-directional trunks.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 93 of 172
Having determined the traffic trunks and their attributes, the next step is to associate LSPs with the
traffic 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 traffic
trunks follow the same physical links. Using the same label for these LSPs (aggregating in effect in a
single LSP) will simplify MPLS management. However, a mechanism is needed in this situation by
which the different PHB treatment of the original LSPs is maintained. Such a mechanism is proposed
in [FAUCH2000].
Usually, as a result of the TE process, appropriate bandwidth is allocated to each LSP. However, the
hose and funnel scope models that are adopted by TEQUILA require careful handling and
implementation. In the hose scope model, traffic from a single ingress node may be directed to a
number of egress nodes. If the hose model carries best effort traffic, then no special problems are
created. 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 SLS
specifies that traffic from ingress node A is to be routed to egress nodes C or D. In addition it specifies
that the maximum traffic injected into the network by node A is 10Mbps. This traffic may be directed
to either C or D. Hence both C and D may accept up to 10 Mbps of traffic from A, however, the sum
total of the injected traffic may not exceed 10Mbps. In this situation, from a traffic engineering
perspective an efficient way to reserve bandwidth while fulfilling the SLS contract is to reserve
10Mbps on links BC and BD, and 10Mbps (instead of 20Mbps) on link AB. In order to carry the
contracted SLS traffic using MPLS, two LSPs can be created, LSP1 using links {AB, BC}, and LSP2
using links {AB, BD}. However, is this case, it is not appropriate to associate Bandwidth with each
LSP, since such an association will result in reserving 20Mbps on link AB. Hence, the bandwidth
reservation process must not be directly linked to LSPs. Another approach would be to terminate an
LSP at B and then split the traffic of that LSP to two new LSPs, one on link BC and one on link BD.A
similar situation can arise with the funnel scope model.
Irrespective of the manner bandwidth is associated to LSPs, there is the question on how the
bandwidth 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 bandwidths
of the LSPs whose traffic belongs to the given PHB. The bandwidth available to the PHBs can be
controlled by the scheduling mechanism. In particular, for WFQ scheduling mechanisms, the
minimum guaranteed bandwidth to each PHB could be determined by the appropriate weights.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
Page 94 of 172
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 total
bandwidth. For this, some type of policing is required in order to ensure that the LSPs are not
injecting into the network more traffic load than that warranted by the bandwidth allocated to
them. The appropriate place of such policing is the source LER for the given LSP; and, this is
achieved by setting appropriate traffic meters. These traffic meters functions should not be
confused 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 to
specify:
•
•
The parameters that are needed by the PHB implementations in order to ensure that there are
available resources in the network to accommodate the LSP traffic. These parameters depend on
the manner PHBs are implemented by the network routers. For example, if WFQ is used to
implement AF1, the WFQ weight of this PHB must be determined. Similarly, the buffer
management parameters will be determined from the loss probability associated with the PHB and
the traffic rate it is expected to carry.
The load balancing parameters that will be used by the dynamic routing functions (cf. Dynamic
Route Management component, see Figure 29). This is due to the fact that normally for each
source-destination pair, the TE process will determine more than one possible route. This is a
desirable scenario since in this manner the load is distributed evenly in the network, resulting in
efficient resource utilisation and improved traffic performance. In addition, the probability of
having available routes to the destination when network components fail increases. In order to take
advantage of the existence of multiple paths to the destination, however, algorithms must be in
place to ensure the proper distribution of the load, taking into account constraints such as avoiding
out of order packet arrival etc.
It is clear from the above, that the proposed MPLS-based TE views LSPs as ‘route-maps’; not as pipes
with explicitly allocated bandwidth. LSPs are further aggregated in terms of their bandwidth into
PHBs, setting accordingly the bandwidth of the resources implemented the PHBs. The bandwidth
allocated to the established LSPs and subsequently to PHBs should not take only into account the
expected traffic to be routed over the LSPs. They should also take into account the QoS guarantees of
the traffic (as in the SLSs) e.g. the throughput or delay that the individual traffic aggregated in the
LSPs and in the PHBs should enjoy.
5.1.3.2 Short-term MPLS Traffic Engineering
As discussed in the previous section, as a result of the long-term TE, the following parameters are
determined:
•
•
•
A set of LSPs for connecting origin-destination pairs.
Bandwidth reserved on network links in order to accommodate the traffic carried by the defined
LSPs.
PHB link scheduling parameters for the routers in the network, reflecting the above bandwidth
reservations.
•
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, as
well as the scheduling and buffer management parameters. Hence, the LSRs are now ready to accept
MPLS traffic on the established LSPs. The mechanisms that are now put in operation in order to
ensure the proper -in terms of user-oriented objectives- and efficient - in terms of system oriented
objectives- operation of the network.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 95 of 172
Short-term MPLS TE is based on the observed state of the operational network. Its objective is to
adapt the mechanisms and parameters of the elemental TE functions (section 5.1.2), in a timely fashion
without 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 are
employed (by the Dynamic Route Management component) in order to balance the network traffic
across the sets of traffic routes defined by long-term TE. In addition, dynamic management of link
bandwidth and buffer space is performed (by the Dynamic Resource Management component) in order
to adapt to current network state within the bounds determined by long-term TE. Inability of the
dynamic route and/or resource management to adapt to current network state, significant changes in
traffic loads, or local changes in network topology, trigger long-term TE effect global network
changes.
More details on the activities of the Dynamic Resource and Dynamic Route Management components
in 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 Introduction
This section describes the IP-based TE approach relying mainly on the capabilities of the IP dynamic
routing protocols employed in the TEQUILA system. From this standpoint, we adopt the classical
intra-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 IP
dynamic 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 of
the TEQUILA system;
•
An intra-AS section, which focuses on the use of the OSPF (Open Shortest Path First, [RFC2328]) protocol for conveying traffic engineering-related information;
•
autonomous systems;
5.1.4.2 Basic Assumptions
As already mentioned in section 5.1.2 the elementary TE functions are: Traffic Identification, Traffic
Classification, Traffic Volume Metering and Route Selection. The result of Route Selection consists in
populating the FIB (Forwarding Information Base) of each IP router of the network accordingly. The
actual selection of a route will however not only depend on the metrics that will be taken into account
when running the routing algorithm, but also on SLS-related information. The former could e.g. be the
hop 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 by
the OSPF protocol.
We distinguish between:
•
•
QoS-related information, conveyed in SLS templates (being processed by the SLS management
modules of the TEQUILA system); this information should be taken into account by the dynamic
IP routing protocols for selecting paths to reach specific destinations;
TE (Traffic Engineering)-related information, exchanged by routers for enabling the enforcement
of the traffic engineering policy (within an AS, typically).
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 96 of 172
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 information
provides information to the routing processes (being activated by each router of the network) for
routing the traffic so as to meet its requirements. From this standpoint, the TE-related information can
be viewed as the "IP routing"-oriented translation of the QOS-related information, e.g. the QOSrelated 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 a
close relationship between these two types of information, so that end-to-end quality of service
provisioning be appropriately enforced.
Finally, it is assumed that:
•
•
•
•
•
IPv4 is the only formalism considered, despite the intrinsic traffic engineering capabilities of the
IPv6 formalism (including the routing header);
OSPF is the IGP (Interior Gateway Protocol) being run within an AS. From this standpoint, static
routing is not considered as an option, mainly because of scalability concerns (whatever this static
routing may consist in, i.e. either using the LSR (Loose Source Routing) or SSR (Strict Source
Routing) options of the IPv4 header ([RFC-791]), or by manually populating the FIB of the
routers);
BGP-4 is the EGP (Exterior Gateway Protocol) being run for conveying reachability information
between 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 where
multiple OSPF areas may have been deployed, thus yielding the use of type 3 LSAs (Link State
Advertisement) between areas);
Whenever possible, the information contained in this document is as independent as possible from
the various routing design flavours made possible by the activation of such routing protocols, like
a multiple area environment within a given domain, or a BGP confederation topology. These are
concerns, which mainly address scalability issues, but it’s obviously worth considering them
whenever routing efficiency (which can be defined in terms of convergence times or path selection
according to specific constraints) is viewed as a key component of the traffic engineering
capabilities of the TEQUILA system.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 97 of 172
5.1.4.3 Functional Architecture
Dynamic resource
“Routing”
AS #
BGP-4 peering relationships
“Routing”
“Routing”
“Routing”
RI RI RI
FI FI FI
Dynamic route
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 IP
traffic engineering purposes, a basic classification of such elements consists in distinguishing network
elements which belong to autonomous system AS # n, from network elements which do not belong to
this autonomous system, so as to consider intra-AS traffic engineering from inter-AS traffic
engineering. By definition, all of the routers embed forwarding and routing features (i.e. all of the
routers 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 traffic
according 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 in
the RSVP (Resource reSerVation Protocol, [RFC-2205]) traffic which may pass through them, so
that 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 the
corresponding 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 specific
assumption about the underlying transport technology), and according to a (possibly) mesh
topology.
As far as traffic engineering is concerned, the routing capacities of these network elements aim at
selecting the best path to reach a specific destination (where destination is expressed as an IP
prefix), 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 a
FIB (and a collection of RIBs) PER VPN.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 98 of 172
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 TEQUILA
project and depicted by figure 4 assumes:
•
The selection of a route is based upon the knowledge of QOS-related information, made of DSCPrelated 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], one
PDP per AS typically) capability that will aim at transmitting the above-mentioned QOS-related
information to the PEP (Policy Enforcement Point, [RFC-2748]) capability embedded in the
routers. Upon receipt of this information, the routing processes will have the ability to use it for
selecting the best paths accordingly.
The COPS (Common Open Policy Service protocol, [RFC-2748] appears to be one of the privileged
communication 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 Access
Protocol, [RFC-1777]) protocol.
The PEP facility is assumed to have the ability to exchange information with a “routing” PDP (Policy
Decision Point), which is embedded in the Dynamic Route Management module of the TEQUILA
system. I.e., from a traffic engineering policy standpoint, running either OSPF, BGP-4 or both
protocols on a given router should gracefully benefit from the information provided by the PDP
through the PEP for route calculation and selection purposes.
The PDP (one per AS, typically, though a distributed implementation might be envisaged) is
responsible for:
•
•
Formatting the QoS-related routing information according to COPS (Common Open Policy
Service) semantics, so that it might be conveyed in DEC messages accordingly, whether these
messages be solicited or not (i.e. the PDP would have, by definition, the ability to send unsolicited
messages to the PEPs it is responsible of – within the context of a time-based traffic engineering
policy 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 probably
impact 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 enforcement
of a traffic engineering policy will be based upon their local decision points, i.e. the routing processes
they 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 OSPF
neighbours within an area, between areas, and between BGP peers of different administrative
domains;
QoS-related information, to be taken into account by the SPF algorithm and/or by the path-vector
routing algorithm (e.g. when the router is RSVP-capable).
For such “non-COPS” capable routers, consistency of the topology as well as the routing information
will 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 Network
Management Protocol) protocol together with the appropriate MIBs (Management Information Base, such as the
OSPF MIB, [RFC-1850]) which will help in storing and maintaining the routing information used by the routers
to make their path selection decisions.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 99 of 172
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 set
the T3 bit (the least significant bit of this one-byte long field, [RFC-1583]) in the Options field of
OSPF Hello packets, database description packets and all LSAs, so as to indicate (to their OSPF
neighbours) they have QoS routing capabilities, i.e. they have the ability to calculate a path according
to the QoS-related information they have been provided by different means:
•
•
•
activation of the RSVP protocol (and processing of the corresponding TSpec parameter conveyed
by RSVP PATH messages),
manual configuration according to administrative policies, and/or
dynamic processing of QoS-related information (such as DSCP-based routing) provided by the
Dynamic Route Management modules of the TEQUILA system, thanks to the possible use of a
PEP capability.
This QoS capability should allow the corresponding OSPF implementations to compute QoS-based
paths, which will aim at populating a QoS routing information base (which can be considered as part
of the classical LSDB for the QoS-based entries of the OSPF RIB). This populating activity should
also yield the generation of a RPT message, sent by the PEP back to the PDP, so that the dynamic
resource/route management be updated accordingly.
QoS-unaware implementations should gracefully ignore the above-mentioned QoS capability, and run
the SPF algorithm according to [RFC-2328]. QOS-unaware implementations should be known by the
Network Dimensioning module for preparing accordingly the QoS-related routing information to be
passed to the Dynamic Route Management module and subsequently to the routing processes of the
routers.
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 [RFC2370]. Indeed, the OSPF Opaque LSA is the privileged support for conveying TE-related information
within 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 using
an opaque-based TE LSA across areas4).
Opaque LSA implementations may include an application programming interface for encapsulating
application-specific information in a specific opaque type, for sending (and receiving) applicationspecific information and for informing an application of the change in validity of previously received
information, whenever appropriate. Within the context of this document, it is expected that such an
API might be available for communication between the above-mentioned routing PEP capability and
the 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 encoding
should 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 its
OSPF 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 LSA
management and consistency standpoint).
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 100 of 172
5.1.4.4.3 Load sharing capability
While document [RFC-2328] clearly defines the ECMP (Equal Cost Multi-Path) capability, which
allows a router to divide traffic somewhat evenly among the available paths, it’s generally admitted
that 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 traffic
equally 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 transit
delays over the available paths are almost equal);
Dividing destination prefixes among available next hops, according to the entries of the router’s
FIB (which may yield unpredictable load split (especially when considering aggregation
capabilities of some OSPF routers, like ASBR routers, typically));
Dividing traffic according to a hash function applied to [source; destination] pairs (based upon a
16-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 TEQUILA
system will support a hash-based ECMP capability, so that traffic might benefit from a load sharing
capability 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 network
elements to be used by the TEQUILA system may possibly support this capability, at the risk of managing
oscillating routes.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 101 of 172
5.2 Traffic Engineering: Functional Block Decomposition
This section describes in more detail the main functional blocks responsible for TE within the
TEQUILA Functional Model (see Figure 29): Network Dimensioning, Dynamic Resource
Management and Dynamic Route Management.
It should be noted that the functionality and interactions of the identified functional blocks are subject
to revisions according to algorithm/protocol specifications to be subsequently undertaking.
5.2.1 Network Dimensioning
5.2.1.1 Description
The network-dimensioning block is responsible for determining cost-effective allocation of physical
network resources subject to resource restrictions, load trends, requirements of quality of service and
policy directives and constraints. The resources that need to be allocated are mainly QoS routing
constraints, are mainly link capacities and router buffer space, while the means for allocating these
resources 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 logic
of the adopted approach, to calculate and install parameters required by the elementary TE functions in
the network (section 5.1.2). This way, the input from Traffic Forecast Model and the output to SLS
management components is assumed to be independent of particular logic of the intra-domain TE
approach employed.
The Network Dimensioning component is, in general, centralised; distributed implementations are also
possible. In any case, it utilises network-wide information, received from the network routers and/or
other 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 the
contracted traffic (SLSs). The computed explicit routes are then provided to the appropriate ingress
node(s) of the network (might also be provided in the core of the network, if the MPLS capabilities of
the 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 paths
can either be signalled along the establishment procedure, or can be implicitly reserved by setting
buffer and scheduling parameters in the individual nodes along the paths (using E-LSPs) – see section
5.1.3.1).
As already outlined in section 5.1.4, the basic paradigm in the pure IP approach is that all traffic
engineering and resource reservations should be made in a distributed fashion, thereby inherently
providing high levels of scalability and fault tolerance. Hence, in this approach, Network
Dimensioning exercises less influence on the routing decisions compared to MPLS approach, in the
sense that does not calculate explicit routes (paths) for routing specific types of traffic; this might have
implications in the ability of the network to provide efficient traffic performance differentiation.
In the IP-based TE approach, Network Dimensioning sets ‘administrative’ parameters (no dynamic
load dependent parameters) per link to be distributed by the IGP employed in the network, OSPF
within the context of the TEQUILA project. This enables to deterministically influence the routing
decisions in the network, in the sense of indicating the network interfaces to be used for routing
purposes by the IGP employed in the network. Through these settings, it could be possible to reserve
specific network interfaces for the MPLS-based traffic engineering (for treating specific types of
traffic e.g. requiring very stringent performance).
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 102 of 172
By relying routing solely on administrative link parameters, adaptability to changing network
conditions is very limited, although such parameters may be dynamically modified, thanks to the
COPS-based enforcement of a time-based routing policy where, for example, OSPF cost metrics
should be modified every given period of time for the purpose of routing and forwarding specific
traffic. To overcome this inability, routing should be based on the distribution of load related link
parameters by the IGP. As such, the paths the traffic follows would be load dependent, hence nondeterministic. Key issue here is whether such an approach, i.e. making routing decisions based on load
parameters, would make route flapping as the rule than being the exception. This depends on how
dynamic such routing decisions would be; the issue will be further investigated, during
algorithm/protocol specifications.
For making the state-dependent IGP, QoS-aware (according to the requirements of the contracted
SLSs), Network Dimensioning computes QoS-related routing information (section 5.1.4.1) which is
sent down (through the Dynamic Route Management component, see below) the routers for
influencing accordingly the routing processes in the routers (see discussion in section 5.1.4.3).
5.2.1.2 Interface Semantics and Parameters
This section describes the interaction of the Dimensioning functional block with other functional
blocks through events, messages or signals.
P o lic y C o n s u m e r
T r a ffic F o r e c a s t
14
In te r d o m a in S L S R e q
1
13
2
12
S L S S u b s c r ip tio n
D im e n s io n in g
P la n n in g
11
A d m is s io n C o n tr o l
3
10
8, 9
7
6
5
4
M o n ito r in g
D yn a m ic R o u te M g m t
D y n a m ic R e s o u r c e M g m t
Figure 33: Interaction of the Network Dimensioning Functional Block
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
From FB
To FB
Event name
Parameters
Comment
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 made
new resources/topology available.
4
Dimensioning
DynamicResourceMgmt
DynamicResourceMgmt_SetResourcesConfig (4)
(see comment)
-This message will determine scheduling and buffer management policies and
set up scheduling/buffer management parameters.
-This message will set up constraints/policies for distributed bandwidth
management algorithms.
5
DynamicResourceMgmt
Dimensioning
Dimensioning_NotifyResMgmtUn (5)
6
Dimensioning
DynamicRouteMgmt
DynamicRouteMgmt_SetRouteConfig (6)
-This message will notify the Network Dimensioning that the dynamic resource
management was not able to deal with the actual demand with its current
configuration. Re-dimensioning will be done as a result of this.
(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 management
algorithms.
7
DynamicRouteMgmt
Dimensioning
Dimensioning_NotifyDynRouteMgmtUn (7)
-This message will notify the Network Dimensioning that the dynamic route
management was not able to deal with the actual demand with its current
configuration. Re-dimensioning will be done as a result of this.
8
Dimensioning
Monitoring
Monitoring_SetMonitoring (8)
9
Dimensioning
Monitoring
Monitoring_NotifyNewConfig (9)
10
Monitoring
Dimensioning
Dimensioning_NotifyThresholdEvent (10)
Monitoring event
threshold
This message is sent when a threshold crossing/link failure, etc, has happened,
according to the parameters configured by Monitoring_SetMonitoring. It will
trigger re-dimensioning.
11
Dimensioning
SLSSubscription
SLSSubscription_SendNetConfig (11)
Network
Configuration
-This message will be sent to the SLS Subscription in order for Subscription to
calculate the spare resources.
12
Dimensioning
InterdomainSLSReq
InterdomainSLSReq_RequestInterDomainRes (12)
Resources
-This message will be sent to request the initiation of interdomain SLS
negotiation/re-negotiation.
13
InterdomainSLSReq
Dimensioning
Dimensioning_NotifyInterDomainResAvail (13)
Resources
-This message will notify Dimensioning that interdomain request was successful
and what resources have been granted.
14
Dimensioning
TrafficForecast
TrafficForecast_GetForecast (14)
Forecast parameters
-This message requests and gets Traffic Forecast related to Dimensioning.
(see comment)
-This message will set up Monitoring parameters related to Dimensioning.
These include threshold values and parameters that dimensioning wants to be
measured. See Dimensioning_NotifyThresholdEvent below.
-This message will be sent in each re-dimensioning of the network and it will
include the new network configuration.
D1.1: Functional Architecture Definition and Top Level Design
Page 104 of 172
5.2.1.3 Description of Functions
Considering the functions of the Network Dimensioning component described previously, all requests
for network re-dimensioning will be processed by the function Process Request. Based on policy
directives 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 and
constraints.
This function requires the following information as input:
- The traffic forecasts related to dimensioning (from Traffic Forecast). All information about the
current 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 QoS
requirements. 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 network
that was previously dimensioned by the function Calculate New Configuration. All
configurations necessary to be set up are done by this function.
This function requires the following information as input:
- The new network configuration provided by the function Calculate New Dimensioning.
The output information is as follows:
- Messages to Monitoring, Dynamic Route, Resource Management and SLS Management to set
up their parameters according to the new configuration.
3.
Store / Retrieve Configuration Network: This function will store / retrieve all configurations
that have been effectively used by the network.
This function requires the following information as input:
- The new network configuration provided by the functions Calculate New Configuration and
Enforce New Configuration.
- A request for current or past configuration to be retrieved.
The output information is as follows:
- Message informing about the success or failure of the retrieval
- The requested configuration.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
4.
Page 105 of 172
Process Requests: This function receives all requests and notifications to network dimensioning
block and calls other functions or rejects them. This decision will be based on constraints and
policy directives.
This function requires the following information as input:
- Policy directives and Constraints (from Policy Consumer).
- Request for new (or update of) network configuration
The output information is as follows:
- Command to calculate a new configuration.
- Command to carry out or deny this new configuration.
5.2.1.4 Finite State Machine
This section describes the internal working of the Functional Sub-Blocks, which constitute the
Dimensioning Functional Block by means of a Finite State Machine (FSM).
N o Event
E .1
Init
Initialization
D one E .0
Idle
*
N otifyR esA vail
E .8
Processing
Propagation
D one E .14
Error
Topology
U pdated E .9
*
N ew R equest
/N otification
E .2
A larm
Sent E .16
U pdating
Topology
SetPolicyD im Funct
E .3
Propagating
C onfiguration
Forecast G ot
E .10
C alculating
Propagation
R equest E .4
Propagation
Failed E .15
G etting
Forecast
C onfiguration
Stored E .13
C alculation
D one E .11
Storing
C onfig
*
SetPolicyD im Funct
E .3
N otifyD ynR esM gm tUn
E.5
N otifyD ynR outeM gm tU n
E.6
N otifyThresholdE vent
E .7
C alculation Infeasible E .12
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 determine
the correct action. When the notification or request has been processed the next state will depend
on 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 a
change of the physical topology.
•
Getting Forecast: at this state we are requesting and getting the predicted traffic from the Traffic
Forecast.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 106 of 172
•
Calculating: at this state is where the new configuration of the network is being calculated. This
is the state where the core dimensioning algorithms will operate. If the calculation finishes
successfully the next state will be the Storing Configuration state and followed by the
Propagating 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 disseminated
appropriately. The network has a valid new configuration when the system exits this state and the
other functional components (SLS Management and Monitoring) have been informed about this
new configuration.
•
Error: this is an error state which we reach when either there has been a problem when
calculating the new configuration in the Calculating state or some error has occurred during the
Propagation Configuration state. After the appropriate alarm has been sent we are transferred to
the 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 and
policy directives
This event sets up constraints and policy directives and at the
same time transits the system to the appropriate state.
E.4
This event indicates that propagation of the configuration has
been requested.
E.5
This event indicates that the Dynamic Resource Management
was unable to manage the current demand (trigger redimensioning).
E.6
This event indicates that the Dynamic Route Management was
unable 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 were
completed correctly.
E.12
This event indicates that functions in calculation state were not
able to find a new configuration that satisfies the demand.
E.13
This event indicates that the new configuration has been stored
successfully.
E.14
This event indicates that the network was updated successfully.
E.15
This event indicates that the network was not updated
successfully.
E.16
This event indicates that the network has sent alarms because an
error has happened.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
CEC Deliverable Number: 101/Alcatel/b1
Page 107 of 172
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 108 of 172
State Transition Table
S0
Init
E.0
S1
Idle
S2
Processing
S3
Updating Topology
S4
Getting Forecast
S5
Calculating
S6
Storing Config
S7
Propagating Config
S8
Error
[Initialisation done,
S1]
E.1
[No event, S1]
E.2
[New
request/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
E.10
[Topology Updated,
S4]
[Forecast Got, S5]
E.11
[Calculation Done, S6]
E.12
[Calculation Infeasible,
S8]
[Configuration
Stored, S7]
E.13
E.14
[Propagation Done, S1]
E.15
[Propagation Failed, S8]
E.16
CEC Deliverable Number: 101/Alcatel/b1
[AlarmSent, S1]
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 109 of 172
5.2.2 Dynamic Resource Management
5.2.2.1 Description
Dynamic Resource Management (DRsM) has distributed functionality, with an instance attached to
each router. In both MPLS and L3 approaches, it aims at ensuring that link capacity is appropriately
distributed between the PHBs defined on a link by setting buffer and scheduling parameters associated
with the interface the link is attached to, according to Network Dimensioning directives, constraints
and rules. Specifically, it gets estimates of the required resources for each PHB at each network
interface, from Network Dimensioning. Further, it receives a certain margin on the required
bandwidth. Within the limits of this margin, DRsM is allowed to dynamically manage the resource
reservations (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 as
compared to required (predicted) resources. Compared to Network Dimensioning, DRsM operates on
a 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 the
MPLS TE approach, DRsM issues appropriate updates on the state of the allocated resources for PHB
to be utilised for routing purposes (cf. Dynamic Route Management component).
DRsM triggers Network Dimensioning when network/traffic conditions are such that its algorithms are
no longer able to operate effectively, e.g. due to excessive high priority traffic, link partitioning is
causing lower priority/best effort traffic to be throttled. Specifically, DRsM issues over- or under-load
alarms to Network Dimensioning respectively if the higher margin is closely approached, or if the
under margin has been kept for a predetermined time. The issue of over-utilised alarms is for further
thought.
5.2.2.1.1 Resources to be managed
This section elaborates on the resources to be managed by Dynamic Resource Management (Figure
35).
There are two main resources that need to be allocated and therefore managed, for the router to handle
traffic at the packet level: link bandwidth and buffer space. While controls are exercised in order to
ensure the proper allocation of these two resources, one should keep in mind a third resource that
enables 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 require
inordinate 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 to
proper scheduling parameters, which are then used to configure link schedulers.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 110 of 172
It can be assumed that the scheduling parameters are in the form of minimum and maximum rates
associated with the PHBs. These parameters are managed by DRsM dynamically, according to actual
load conditions, so that to resolve conflicts for physical link bandwidth and avoid starving of some
PHBs (where the starving levels are determined by the Network Dimensioning, based on predicted
traffic estimates and service provisioning policies). Another aspect of dynamic management relates to
the discussion of section 5.2.3.1.1. During the operation of the network, the Dynamic Route
Management process may need to change the bandwidth of certain LSPs6 and/or Network
Dimensioning may create new LSPs. These changes imply a) the update of the bandwidth allocated to
the router PHBs and b) update to the policing parameters at the edge routers. Hence, if the LSP update
requests are granted by Network Dimensioning, the necessary bandwidth modifications are
communicated to DRsM, which translates bandwidth modifications to link scheduling parameters,
which are then downloaded to the scheduler.
1 H WZ R UN 0 R Q LWRU LQ J
' \ Q DP LF5 HV RX UFH$ OOR FDWLR Q
' \ Q D P LF5 R XWLQ J
0 D Q DJ H P HQ W
' \ Q D P LF
' \ Q D P LF
% DQ G Z LG WK % X IIH UU
0 D Q D J H P H QW
0 DQDJHP HQW
/ LQ N 6 FK H G X O LQ J
Figure 35: Dynamic Resource Management
Buffer Space
Buffers are used at the routers for the temporary storage of packets that contend for transmission on
the output links of a router. It is assumed, in the following, that the main packet buffering occurs at the
output 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 transmitted
on a given link need to be taken into account by the buffer management mechanism. In contrast, input
buffering routers need to consider all the packets that must be transmitted from all the input to all the
output links.
6
Although the term LSP is used here which implies an MPLS-based TE scheme this is equally applicable to the
pure IP TE approach. In the IP approach adopted by TEQUILA the set of feasible routes between ingress/egress
pairs for a particular traffic class is determined by Network Dimensioning and is known by Dynamic Route
Management. Although the routes are not explicitly nailed-up in the routers, as in the MPLS case for LSPs, they
still exist as a logical overlay network known by the TE system. Therefore they can be used to determine the
resources required by the potential routes which will map, finally, to a set of PHBs along a set of links.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 111 of 172
Appropriate management of the buffer space may differentiate packet loss probabilities for the various
PHBs in the router. Also, they provide a bound on the largest delay that successfully transmitted
packets 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 are
dropped and whether new packets may replace already stored packets in the buffer. The buffering
schemes 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 the
routers.
As a result of Network Dimensioning, the buffer management module of the DRsM component is
updated accordingly with buffer management parameters used to configure the buffer space and
determine the rules for packet dropping in the routers (drop levels). The drop levels have been
determined according to the QoS requirements (SLSs) of the traffic multiplexed in the buffer and
estimates 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 changes
of the traffic mix of (determined by Network Dimensioning) and changes in the input rate. These are
undertaken by the activities of the DRsM. For example, altering the bandwidth allocated to an LSP
may alter the bandwidth allocated to a corresponding PHB. If the loss probability for the PHB is to
remain constant, then the buffer space allocated to the PHB may need to change. The dynamic buffer
manager translates the required bandwidth modifications to appropriate buffer management
parameters that are used to configure the router buffer space.
5.2.2.2 Interface semantics
Figure 36 shows the interfaces between DRsM and the other functional blocks. The operations
invoked over the interfaces are summarised in Table 1.
Network
Dimensioning
1
2
3
Dynamic Resource
Management
Node Monitor
7
Dynamic Route
Management
4
5
6
PHB
Enforcement
Figure 36 Interfaces between Dynamic Resource Management and other functional blocks
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
From FB
Page 112 of 172
To FB
Operation
Parameters
Comment
1 Network
Dimensioning
Dynamic
Resource
Management
SetResourcesConfig
LinkId, PHBId,
Buffering_Constraints,
Scheduling_Constraints,
Importance
This is the main mechanism by
which Network Dimensioning
configures DRM
2 Dynamic
Resource
Management
Network
Dimensioning
NotifyResMgtUn
LinkId, PHBId,
ProblemType
Sent when DRM is unable to
satisfy demands on all resources.
This triggers a reconfiguration by
Network Dimensioning.
3 Dynamic
Resource
Management
Node Monitor
SetMonitorConfig
ResourceId,
MonitoringAlgorithm,
ThresholdSpecification
DRM initiates, modifies and
terminates monitoring activities
through this operation. Depending
on the monitoring algorithm to be
deployed (e.g. Exponentially
Weighted Moving Average or a
forecast/trend analysis) some
parameters which specific to that
algorithm may be required.
4 Node Monitor
Dynamic
Resource
Management
NotifyThreshold
ResourceId,
ThresholdId,
MonitoredValue
Monitoring informs DRM when
monitored values has crossed
predefined thresholds.
5 Dynamic
Resource
Management
PHB
Enforcement
SetBufferParams
LinkId, PHBId,
BufferId, Size,
DropLevel
These operations configure the
buffering and scheduling
functions of the router. The
parameters are for further study
and are dependent on the
mechanisms in the routers as well
as the algorithms defined in
DRM.
(modify and delete
operations also
supported)
(suspend, resume,
modify and delete
operations also
supported)
(modify and delete
operations also
supported)
SetSchedulerParams
LinkId, PHBId, Priority
(modify and delete
operations also
supported)
6 PHB
Enforcement
Dynamic
Resource
Management
NotifyPHBState
LinkId, PHBId,
Statistics….
Network monitoring is only able
to report on load, and other
externally measurable statistics.
These notifications, directly from
PHB Enforcement, are on buffer
and scheduler statistics from the
internal viewpoint of the router.
E.g. on the occupancy of the
buffers for AFn.
7 Dynamic
Resource
Management
Dynamic
Route
Management
AdviseResourceAllocati
on
LinkId, PHBId,
AllocatedResources,
SharingMethod
These messages are required to
inform Dynamic Route
Management how much capacity
is reserved per PHBs and how
PHBs are shared on a link. This
information is not available from
Monitoring and is necessary for
Dynamic Route Management to
be aware of the capacity available
per potential route.
Table 1 Interactions between Dynamic Resource Management and other functional blocks
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 113 of 172
5.2.3 Dynamic Route Management
5.2.3.1 Description
Dynamic Route Management (DRtM) is responsible for managing the routing processes in the
network according to the guidelines produced by Network Dimensioning on routing traffics according
to QoS requirements associated to such traffics (contracted SLSs).
In the MPLS approach (section 5.1.3.2) the component is mainly responsible for managing the
parameters based on which the selection of one of the established LSPs is done in the network, to the
purpose of load balancing. To this end, it receives as input the set of explicit paths defined by Network
Dimensioning and relies on appropriate network state updates distributed by the Network Resource
Management component. Further, the Dynamic Route Management component informs the Network
Dimensioning 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 the
network edges, or in the ingress points of the established LSPs.
In addition to LSP selection management, in the MPLS-based approach, the DRtM sets appropriate
traffic meters in order to ensure the proper flow of traffic in the established LSPs, according to the
defined LSP bandwidth and available capacity in the network as it is known from the updates from the
Network Resource Management component. Note that as it has been discussed in section 5.1.3.1, the
bandwidth to each LSP is not explicitly allocated. It is implicitly allocated through link scheduling
parameters through which the LSPs are defined, while the means to ensure that the input traffic to the
LSPs 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-based
routing (5.1.4.1) i.e. routing of traffic according to contracted SLS requirements. To this end, as SLSs
are contracted it receives the appropriate QoS-information required for routing (in the form of routing
constraints) from Network Dimensioning and appropriately informs the routing processes in the
network (employing a PEP capability) e.g. to restrict the routing of specific traffic out of certain
interfaces. Note, that the QoS information maintained may change dynamically from the activities of
the Network Resource Management component (see previous sections), as the configured service rates
associated 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 to
distribute the load on the available paths, in order to avoid overloading and congestion in parts of the
network. The appropriate parameters for load balancing have been downloaded and configured by
Network Dimensioning (long-term TE, section 5.1.3.1). However, with the exception of static load
balancing, 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 of
network traffic. Hence it may be preferable to implement load-balancing schemes that adapt to varying
network conditions. However, highly dynamical schemes that try to continuously adapt to current
network state may not be feasible or desirable due to the following reasons:
•
•
Adaptation implies the existence of monitoring mechanisms that collect the network state
information. Collecting this information is expensive in terms of network resources and hence it
cannot be done very frequently. Hence it cannot be assumed that network state information is
completely up to date when decisions are made.
Reacting to temporary changes to network conditions too fast and too often may lead to
instabilities and rapid fluctuation of link loads, resulting in unpredictable delays, excessive packet
losses and reduced system throughput.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 114 of 172
Hence a semi-dynamic scheme is called for. In Figure 37 the basic operation of such a scheme is
shown. Central to this scheme is the Dynamic Route Management module that adapts the routing
selection parameters based on the information obtained from Network Monitoring7. Issues that need to
be 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.
N e tw o rk M o n ito rin g
I n fo T r a n s m i s s i o n
I n fo R e q u e s t o r
I n fo T ri g ge r
S L S A d m is sio n
C o n t ro l
A l a rm T r i g g e r
D yn a m ic R o u te
M ana ge m e nt
N e tw o r k D i m e n s i o n i n g
N e w R o u tin g
I n f o r m a ti o n
R o u tin g B as e d o n
P re d e te rm in e d
P a r a m e t e rs
T ra ff 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 the
timer driven approach, the information is updated at regular intervals while in the event driven
approach updates are triggered by specific events. With the timer driven approach the overhead due to
information updates can be controlled by the choice of the update intervals. This is harder to achieve
with the event driven approach, since the frequency of event occurrence is not known a priori, but one
could 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 precomputation of the "QOS routes" I concerned. By doing so, the event driven approach remains an
interesting option (this is a somewhat mandatory option in the case of IP TE). However, the timer
driven approach may have late reaction to sudden large changes in network state. Hence a compromise
between the two approaches seems appropriate: The timer driven approach is used as a basic
mechanism for information update. At the same time, the system is designed to provide immediate
updates 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 be
implemented 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 Route
management seems more appropriate. The event driven mechanism, by its nature should be
implemented at the Network Monitoring Module.
7
In this section, the Network Monitoring is used as a general means to obtain information from the network. In
other sections, where component functionality/interactions are described, the routing updates that are considered
are those received by the Network Resource Management component. They may be as well thought as delivered
through the capabilities of the Network Monitor component, as herein; but this is a system architecture issue.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 115 of 172
Routing Parameters Amenable to Updating
The process of routing parameter update is shown in Figure 38. The routing parameters that need to be
updated depend on whether the network, from the point of view of the LER under consideration is
under
•
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 according
to 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
1RUPDO/RDG
0HGLXP/RDG
+LJK/RDG
7ULJJHU:LGH
%DQGZLGWK$YDLODEOH
%DQGZLGWK$YDLODEOH
2Q3UHGHWHUPLQHG
/63V
1R
<HV
1HWZRUN'LPHQVLRQLQJ
6FDOH/63
8SGDWH3URFHVVE\
$IWHUQHJRWLDWLRQZLWK
1HWZRUN
1R
'LPHQVLRQLQJ
<HV
8SGDWHRI
3RVVLEOH8SGDWH
/63%DQGZLGWK
2I)RUZDUGLQJ
3RVVLEOHQHZ/63
7DEOHV
&UHDWLRQ
6HWXSRIWUDIILFPHWHUV
Figure 38: Dynamic Routing Process
Under normal load operating conditions the LSPs along with the bandwidth reserved for them are
sufficient to route the traffic entering the LER. In this case, only the forwarding tables may be updated
whenever it is deemed appropriate to modify the rules by which new traffic is entering the system, in
order 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 traffic
injected 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 available
LSPs 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 positive
answer, proceeding with the formation of such LSPs
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 116 of 172
This process implies that there are algorithms in place in the Network Dimensioning module to adjust
the 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 the
needs 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. In
this case, the Network Dimensioning component initiates the process of wide-scale LSP update. As a
result, LSPs belonging to source-destination pairs other than that which invokes the update may be
affected.
5.2.3.2 Interface semantics
Figure 39 shows the interfaces between DRtM and the other functional blocks. The operations invoked
over the interfaces are summarised in Table 2.
1HWZRUN
'LPHQVLRQLQJ
'\QDPLF5RXWH
7UDIILF0HWHULQJ
0DQDJHPHQW
'\QDPLF5HVRXUFH
0DQDJHPHQW
5RXWLQJ
Figure 39 - Interfaces between Dynamic Route Management and other functional blocks
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
From FB
Page 117 of 172
To FB
Operation
Parameters
Comment
Dynamic
Route
Management
LSPs and QoS routing
info
LSP topology, traffic
trunks, bandwidth
(modify and delete
operations also
supported)
RouteIds, traffic trunks,
LSPs, selection
parameters
This is the main mechanism by
which Network Dimensioning
configures DRtM
2 Dynamic
Route
Management
Network
Dimensioning
NotifyResMgtOn
RouteId, ProblemType
Sent when DRtM sees all LSPs
tend heavily utilised. This triggers
a reconfiguration by Network
Dimensioning.
3 Dynamic
Resource
Management
Dynamic
Route
Management
AdviseResourceAllocati
on
LinkId, PHBId,
AllocatedResources,
SharingMethod
These messages are required to
inform Dynamic Route
Management how much capacity
is reserved per PHBs and how
PHBs are shared on a link. This
information is not available from
Monitoring and is necessary for
Dynamic Route Management to
be aware of the capacity available
per potential route.
4 Dynamic
Route
Management
Routing
Update Parameters
LSPId, selection
parameters
To manage appropriately the
routing processes in the routers.
1 Network
Dimensioning
QoS routing info
5 Dynamic
Route
Management
Traffic
Metering
SetTrafficMeters
Admissible interfaces
for traffic types per
DCSP
Interface,
FlowIdentification, ratelimit, ExcessActions
These operations are for enforcing
LSP bandwidth, in the sense of
ensuring that the input traffic will
not exceed allocated LSP
bandwidth.
Table 2: Interactions between Dynamic Route Management and other functional blocks
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 118 of 172
5.3 Message Sequence Charts
5.3.1 MPLS-based TE
In this section the MSCs are presented of the MPLS-based TE approach. To reduce clutter and for ease
of presentation, two MSC charts are presented. The first MSC shows the message sequences for
operations implementing the updates indicated by the Network Dimensioning Component. The second
MSC describes the message sequences that trigger the Network Dimensioning component to proceed
(if needed) with updates from the Dynamic Route and Resource Management components.
03/67(
± 3DUDPHWHU8SGDWHV
7UDIILF
6FKHGXOLQJ
)RUZDUGLQJ
7UDIILF
&RQGLWLRQLQJ
'\QDPLF5RXWH
5RXWLQJ
0DQDJHPHQW
0RQLWRULQJ
1HWZRUN
'\QDPLF5HVRXUFH
6/60DQDJHPHQW
VXEVFULSWLRQ
)RUHFDVW
'LPHQVLRQLQJ
0DQDJHPHQW
7UDIILFPDWUL[
DGPLVVLRQFRQWURO
6/6V
(5 /63V WUDIILFWUXQNV
/63V
(5
6SOLWWLQJUDWLRV
6SOLWWLQJUDWLRV
5RXWHFRQVWUDLQWV
/63EDQGZLGWK
3ROLFLQJSDUDPHWHUV
OLQNEDQGZLGWKEXIIHU
SHUWUDIILFWUXQN
6FKHGXOLQJGURSOHYHO
VKDULQJFRQVWUDLQWV
5HTXHVWXSGDWHRI
(5
6/6DGPLVVLRQ
SDUDPHWHUV
SDUDPHWHUV
/63V
/63V
(5 /63V WUDIILFWUXQNV
6SOLWWLQJUDWLRV
6SOLWWLQJUDWLRV
5RXWHFRQVWUDLQWV
3ROLFLQJSDUDPHWHUV
6/6DGPLVVLRQ
SDUDPHWHUV
/63EDQGZLGWK
SHUWUDIILFWUXQN
OLQNEDQGZLGWKEXIIHU
6FKHGXOLQJGURSOHYHO
VKDULQJFRQVWUDLQWV
SDUDPHWHUV
1HWZRUNRYHU
ORDG
/63EDQGZLGWK
6FKHGXOLQJGURSOHYHO
SDUDPHWHUV
OLQNEDQGZLGWKEXIIHU
VKDULQJFRQVWUDLQWV
6/6DGPLVVLRQ
(5
(5 /63V WUDIILFWUXQNV
/63V
6SOLWWLQJUDWLRV
SDUDPHWHUV
6SOLWWLQJUDWLRV
5RXWHFRQVWUDLQWV
3ROLFLQJSDUDPHWHUV
SHUWUDIILFWUXQN
Figure 40: MPLS Traffic Engineering Parameter Updates
Referring to Figure 40, the top chart describes the message sequences occurring when the system
initialised. 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, and
Scheduling parameters. The results are downloaded to Dynamic Route Management and Dynamic
Resource 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 Route
Management or Dynamic Resource Management components require updates to the downloaded
parameters. The message sequences are the same as the top part, with the exception that the Network
Dimensioning component performs its calculations based on the current network state and current
network traffic statistics/requirements.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
03/67(
6FKHGXOLQJ
)RUZDUGLQJ
± 7ULJJHULQJRI8SGDWHV
'\QDPLF5RXWH
7UDIILF
&RQGLWLRQLQJ
5RXWLQJ
Page 119 of 172
'\QDPLF5HVRXUFH
0DQDJHPHQW
0RQLWRULQJ
0DQDJHPHQW
1HWZRUN
'LPHQVLRQLQJ
6/6$GPLVVLRQ&RQWURO
0HDVXUHPHQWVDODUPV
6SOLWWLQJUDWLRV
3ROLFLQJSDUDPHWHUV
5HTXHVWXSGDWHRI
SHUWUDIILFWUXQN
/63V
5HTXHVWXSGDWHRI6/6
DGPLVVLRQSDUDPHWHUV
6SOLWWLQJUDWLRV
5HTXHVWXSGDWHRI
3ROLFLQJSDUDPHWHUV
/63V
SHUWUDIILFWUXQN
0HDVXUHPHQWVDODUPV
6FKHGXOLQJGURSOHYHO
SDUDPHWHUV
1HWZRUNRYHU 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 Dynamic
Route Management may be triggered by alarms/measurements from the Dynamic Resource
Management component or by request to update SLS admission parameters. The bottom chart in
Figure 41 indicates that request for updates issued by Dynamic Resource Management are triggered by
alarms from the Monitoring component.
5.3.2 Link Failure Handling
In this section we need to make some assumptions on how the link failures will be detected and
handled. 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 its
own benefits. It might be necessary to support a mixture of these techniques to be able to support the
resilience needs of the different services supported by the TEQUILA system.
5.3.2.1 Link failure detection and handling
In the structure of the TEQUILA system, there are three sources that can possibly offer information on
the operative state of network element links. The first element that can be able to detect a link failure
is of course the network element itself. The support of direct (or physical) detection is link layer
dependent e.g. it is supported on ATM but not necessarily on Ethernet. If link failure is directly
supported then it will without doubt be the fastest way. Another solution to detect the error, is to
depend on the routing protocol (in the case of TEQUILA, this will come down to the hello-messages
of the OSPF protocol or its equivalent in IS-IS).
The methods above are directly linked to the network element. Both the direct and indirect detection
can be given an abstract, generic interface towards the upper layers by setting the operational interface
status in MIB-II or by specifying a proprietary trap/event. A third source of information about link
failures in the TEQUILA system is the monitoring subsystem. In contrast to the previous methods, this
could be implemented independent of the network elements. If the monitoring is performed on a
regular basis, the active measurement (which inserts a test-stream into the TEQUILA system) will be
able to detect the failure. A further functional description on this will be given in a separate section.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 120 of 172
Once the failure is detected, it can be handled in a number of ways: protection switching, restoration
or hybrid techniques. In this document we will not elaborate on hybrid solutions. Each of these
methods 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 method
should preferably not be made a part of the SLS because the user is not interested in the method, but
rather the result. The following section will give possible extensions to the SLS specification and the
impact on the TEQUILA system.
5.3.2.2 Suggested SLS Extensions and Impact on TEQUILA System
A differentiation between the services in terms of link failure handling can be inserted in the SLS
specification by adding extra parameters. These parameters do not need to be an explicit part of an
SLS-negotiation, but could also be implicitly defined by the service definition. For example premium
services are always recovered by protection switching.
Below are possible extensions for the SLS specification can be used to have better control over the
way 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. In
order to make this possible a second SLS is necessary. This SLS specifies the service the customer
wants in case of a failure. If we cannot cope with every SLS in every possible failure scenario (very
likely) we need to determine which SLS gets restored and which not. What the customer wants to
know is with which probability his SLS gets restored. The maximum recovery time can be a very
important parameter, and will be defined in a contractual fashion between the customer and the service
provider, as far as the corresponding commitment is concerned. Real-time services need a quick
recovery. Other services might have less stringent requirements on the recovery time.
Remark that there is a complex interaction between recovery probability and recovery type (protection
switching or restoration). Protection switching with resource reservation typically gives a better chanc
e of recovery because the resources are allocated in advance. Most of the time restoration will find a
new path but the necessary resources might not be available on this path. If we do not consider
situations with more than one link failure then this means that protection switching always succeeds if
the failing link is protected.
Note that none of the above extensions are mandatory. The system can be configured with a default
failure handling technique. There can be one default or “best-effort” technique for the whole system or
there 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 the
availability of backup paths and non-starvation of BE-traffic. A possible schematic link-usage scheme
is given in Figure 42.
Reserved for
Shared between BE and backup
Reserved for BE
(non-starvation principle)
Figure 42: Link usage policy
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 121 of 172
5.3.2.3 Message Sequence Chart: Protection switching
There are two scenarios given below: protection switching and restoration. We assume that the
detection of link failures is being done by the monitoring subsystem, but extensions to the other
methods should be obvious.
After the monitoring subsystem has detected the failure, the protecting backup path is activated. In an
MPLS-driven traffic-engineering scheme, this will be a decision made by the dynamic route
management, which will inform the PSL (protection switch LSR, the LSR that does the switch over to
the 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 got
crossed), the management should also be notified.
In addition to that, certain actions might be necessary to handle the behaviour after the link connection
has been restored. Again, there are several options:
•
Revertive mode: the connection can be re-routed along its original path (maybe not the best option
if 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.
Dynamic
M anagement
Monitoring
Failure Detected
Network
Dimensioning
Activate Backup Path
Configuration Changed
Figure 43: Protection Switching MSC
5.3.2.4 Message Sequence Chart: Restoration
Monitoring
Dynamic
Management
Network
Dimensioning
(SLS)
Management
Failure Detected
Calculate new path
No Path Found
No Path Found
Renew Network
Status
SLS
Failed
Network Status
Changed
OR
Configuration
Changed
Renew Network Status
Network Status
Changed
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 122 of 172
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 local
operation (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 any
other SLS then the restoration probability can be as high as in the case protection switching case. To
elaborate 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 more
trouble finding the necessary resources on these paths (because nothing has been reserved). The
selection of which traffic is allowed on the new path and which is denied should depend on the agreed
SLS (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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 123 of 172
5.4 Inter-domain Traffic Engineering
5.4.1 Problem Description
This section describes the process of providing end-to-end quality in the TEQUILA system. The
TEQUILA system (Figure 45) consists of a set of interconnected autonomous systems (ASs). The
grey squares on Figure 45 are BGP nodes.
6/6
6 WH S %%
%%
6 WH S 6 WH S $ 6
$ 6
6 WH S 6 WH S 6 WH S 6 WH S 6 WH S %%
%%
$ 6
$ 6
6 WH S %%
$ 6
G H VW
Figure 45: The TEQUILA system
In the following, the term Bandwidth Broker (BB) is used to denote the required functionality in an
AS to undertake the required actions and interactions with neighbouring ASs for handling SLS
requests and configuring the network to support them. The functionality of the BB is realised through
a number of components in the TEQUILA Functional Model belonging to the SLS Management and
TE groups of functional blocks. In particular, BB functionality overlaps with SLS Subscription, SLS
Admission Control, Inter-domain SLS Requestor, Network Dimensioning, Dynamic Resource
Management and Dynamic Route Management (cf. chapter 3). However, for the sake of simplicity, in
this section we use the term BB for better outlining inter-domain issues and solutions, rather than
detailing 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 be
given 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 the
requirements in the SLS. Identifying the correct path to the destination automatically identifies the
neighbour BB. Once this neighbour BB is determined, BB to BB negotiation aims at reserving
capacity between ASs.
Imagine that, based on considerations that will be explained later on in this document, inter-domain
path 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, each
BB in each AS has a correct idea of the current QoS capability of the AS to which it attaches. It is thus
capable to run a decision process in order to accept or reject the SLS.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 124 of 172
BB to BB negotiation (step 2 on Figure 45) will thus try to reserve capacity between the ASs. If this
negotiation fails, no capacity will be reserved and the SLS will be rejected. On the contrary, if it
succeeds, 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 the
destination, negotiating and reserving capacity between the neighbour AS and one of its neighbours
has to be done. In step 4, BB to BB negotiation between AS2 and AS4 results in capacity reservation
between the two ASs.
Remark: At the intra-domain level, once step 2 is finished, the intra-domain path should be determined
and capacity should be reserved between the ingress pointy and the egress point in AS1: this is
represented 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 (with
the 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 requirements
listed 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 between
the 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 same
destination, 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 ingress
and the egress nodes in the AS. Capacity may be reserved, at the intra-domain level, to ensure the
QoS transfer of traffic through the domain. Intra-domain TE solutions, such as OMP, may also
optimise the usage of the capacity. Refer to the paragraph “intra-domain routing” for more
information.
Back to step 1: the BB in the neighbour AS handles the whole process: BGP determines the path
to the destination that is capable, a priori, to fulfil the QoS requirements in the SLS. This path is
only the subsection of the path determined in step 1 above. Capacity is reserved between the
neighbour 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 available
bandwidth in each of these QoS pipes will vary. At a certain moment, the available bandwidth could
be 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 of
a new or alternative pipe, the traffic is not stopped. But this increase of allocated bandwidth will
not always be possible.
Establish a second pipe, between the same ingress-egress nodes, but via an alternative path, with
the required additive bandwidth, and keep the “old” pipe up. The new pipe could be used to handle
the new SLS. The old flows are not stopped.
Establish a totally new QoS pipe for the same class of service, between the same ingress-egress
pair, but via a different path (different inter-domain nodes and/or different ASs). This pipe must
accept the total traffic (the “old” traffic that was already transported within the QoS pipe, and the
new required one). This is the worst solution, since the flows are broken. For some applications, it
is totally unacceptable.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 125 of 172
The implementation of the two last solutions requires that several paths between the same ingressegress pair exist and be discovered/calculated. The first solution is the simplest one and requires only
one path to be established, but since the bandwidth is limited anyway, we may be forced at a certain
moment, to opt for the second or third solution. The second solution should be preferred to the third
one, 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, in
the context of end-to-end QoS, BGP should be extended. Paragraphs 5.4.4 and 5.4.5 present two
different models: the first one uses additional TE parameters (load, bandwidth), while in the second
one QoS paths are determined based solely on the “raw” capability of the Tequila system. Paragraph
5.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 Introduction
The Internet consists of a collection of “independent” ASs managed autonomously by ISPs. BGP
allows selecting the “best” path to each destination across these systems. The IP traffic traverses
several ASs toward the destination. The choice of which AS to select is based purely on a local
decision: 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 based
routing ads another lever of traffic influence by defining the path that a packet should take. It does this
very 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 is
limited to the adjacent domain (see remark hereafter).
Remark: The Multi-Exit Discriminator (MED) attribute may be used by a BGP speaker’s decision
process to discriminate among multiple exit points to a neighbouring AS. A lower MED value is
preferred over a higher value. The MED attribute is exchanged between ASs, but a MED attribute that
comes into an AS does not leave the AS. When an update enters the AS with a certain MED value, that
value is used for decision within the AS. When BGP sends an update to another AS, the MED is reset
to 0.
5.4.2.2 Basic traffic engineering capabilities of BGP-4
The BGP-4 protocol has been designed for conveying network reachability information between
domains. The protocol is based upon the use of a path-vector algorithm, whereas the reachability
information is described by using attributes which aim at qualifying the route, in terms of number of
autonomous systems the route advertisement has crossed, the local preference which can be expressed
by 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 routing
policy 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 BGP
decision process select a route rather than another (thus allowing service providers within an
alliance to systematically avoid domains of their competitors);
•
A network operator can also influence the choice of an exit point to reach a neighbouring
autonomous system, by using the MULTI_EXIT_DISC attribute;
•
The use of the COMMUNITIES attribute ([RFC-1998], [NUSSBACHER99]) allows a network
operator to enforce a specific routing policy for a set of destination prefixes (e.g. EF-marked IP
datagrams destined to a set of IP VPN customers MUST use a given sequence of autonomous
systems);
•
Etc.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 126 of 172
As far as the TEQUILA system is concerned, the enforcement of such basic routing rules is generally
performed by means of manual configuration, which could be automated thanks to the use of the
above-mentioned “routing” client-type, according to the following Figure 46:
IRR
PDP
Dynamic route management block
PEP
IP router
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 by
each router of a given domain, thanks to the establishment of the appropriate BGP peering
relationship. Storage of the routing information within the database is based upon the use of the
RPSL (Routing Policy Specification Language, [RFC-2622]) language semantics, which allows to
depict a complete routing policy (thanks to the value assignment of the above-mentioned
attributes). This figure assumes the use of a PEP/PDP relationship to retrieve the appropriate
routing policy information from the IRR, thus allowing a complete consistency between the
information which is stored in the IRR and the routing information which is exchanged between
BGP peers of a routing domain;
•
Upon receipt of an UPDATE message, a BGP peer will notify the IRR (by means of the
appropriate REQ/RPT messages between the PEP and the PDP), so that it might make the route
selection decision accordingly.
From this perspective, a certain degree of automation can be reached when considering the dynamic
enforcement of some basic BGP-4 rules, which aim at reflecting a service provider’s policy.
5.4.2.3 Processing QOS-related information
The architecture which has been described in the above figure can be extended for conveying QOSrelated information to BGP peers, thus allowing a potential enhancement of the BGP4 selection
process. Indeed, by making a bandwidth broker facility exchange information with an IRR facility, the
resulting 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 influence
the value of the MULTI_EXIT_DISC attribute (which, by the way, appears to be a fully qualified
metric), thus yielding the choice of STM-1 links over 64 kbit/s leased lines;
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
Page 127 of 172
DSCP marking can also be conveyed within the use of the COMMUNITIES attribute, as
mentioned in the previous section8.
5.4.2.4 Conveying TE-related information
If the above sections have attempted to describe how a BGP-4 routing policy could be enforced by
routers of a given domain, thanks to the use of QOS-related information to be provided by the
dynamic resource/route management modules of the TEQUILA system, the enforcement of a global
inter-AS traffic engineering policy is a matter of:
•
Bilateral (or multi-lateral) agreements between service providers (possibly leading to an
automated exchange of information between IRR building blocks, according to figure 2 of this
document);
•
Conveying TE-related information between domains.
From the latter perspective, it has been proposed to use an additional attribute, the QOS_NLRI
attribute ([JACQUENET00]), which will help the BGP peers in taking into consideration (i.e. possibly
influence the BGP decision process) the specific QOS requests which have been expressed by means
of SLS.
The QOS-related information conveyed in the SLS has been processed by the dynamic resource/route
management modules, so that the TE-related information to be conveyed between autonomous
systems might reflect these requirements, in terms of DSCP marking or bandwidth reservation, for
example.
(to be completed).
5.4.2.5 Load sharing capability
There is no intrinsic load sharing capability which is provided by the BGP-4 protocol, but the use of
specific attributes (such as the COMMUNITIES or the MULTI_EXIT_DISCR) could possibly help in
dividing 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 which
are 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, some
QoS requirements.
Current TE models are generally based on IGP protocols and not on BGP: the view of the Internet is
limited to one AS and QoS is not provided at the global level. This is not sufficient in the context of
Tequila where the aim is to provide end-to-end quality of service. In that sense, BGP must be strongly
extended: the complete view of the Tequila Domain must be taken as input for the QoS route
calculation.
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”…
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
Page 128 of 172
“QoS parameters” model: BGP nodes exchange not only topology information, as in standard
BGP, but also QoS parameters (delay, load, available bandwidth, etc). All these parameters refer
to the complete Tequila System. Taking this QoS information as input, and using a modified route
decision 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, paths
optimising 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 paragraph
5.4.4.
•
The “CoS capability” model is much simpler. BGP nodes only transport the QoS capabilities
supported 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 the
task 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 be
satisfied. This model is further detailed in paragraph 5.4.5.
5.4.4 Model 1: “QOS parameters” model
' H OD \ / R D G %%
$ Y % D Q G Z LG WK ' H OD \ / R D G %%
$ Y % D Q G Z LG WK $6
$ 6
' H OD \ / R D G $ Y % D Q G Z LG WK %%
%%
$6
%%
$6
%%
' H OD \ / R D G $ Y % D Q G Z LG WK $ 6
' H OD \ / R D G / R Z H V W G H OD \
$ Y % D Q G Z LG WK GHVW
+ L J K H V W D Y D LO D E O H E D Q G Z L G W K
Figure 47: “QoS parameters” model
BGP is extended for conveying QoS-related information (load, delay, available bandwidth, etc) thus
allowing a potential enhancement of the BGP route selection process. In Figure 47, BGP nodes run a
modified route decision process that takes these additional parameters into account. This may result in
different 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 comparison
between 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-4
attribute, the QoS-NLRI attribute, which will convey QoS information associated to the routes
described in the NLRI field of a BGP UPDATE message. [ABAR] proposes to use the BGP protocol
to choose the best BGP routes based on TE constraint weights.
These two documents identify the additional parameters and propose new formats of the BGP
UPDATE message. A modified route decision process, using these additional TE parameters,
calculates TE routes (routes able to fulfil some TE requirements). These additional TE parameters
could even take precedence over the standard BGP weights.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 129 of 172
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 is
represented by a set of summary weights based on a given traffic engineering criterion. The weights
could 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 BGP
attribute that contains QoS sub-fields.
The BGP route selection process is extended to support a TE way of prioritising the best routes for any
destination. The order of preference of the routes can be changed to give the TE weight attribute a
higher 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 BGP
update 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):
4R6LQIRUPDWLRQFRGH
4R6LQIRUPDWLRQVXEFRGH
4R6LQIRUPDWLRQYDOXH
4R6LQIRUPDWLRQYDOXH
1HWZRUNDGGUHVVRIQH[WKRS
1HWZRUNOD\HUUHDFKDELOLW\LQIRUPDWLRQ
Figure 48: QoS-NLRI attribute
The QoS code could be:
•
0: reserved
•
1: bandwidth
•
2: delay
•
3: jitter
•
4: DSCP
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 130 of 172
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 Figure
49).
code
0
1
2
3
4
5
6
Subcode
0
1
2
3
4
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 efficient
answer 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 own
domain by looking in a “TE database” and performing a calculation. This calculation can be a real
Dijkstra if the weight is additive (e.g. the delay) or a Dijkstra-like calculation if the weight is exclusive
(e.g. the bandwidth).
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 131 of 172
For each TE weight type: each ABR summarises the cost to each destination network in its area, and
flood it for advertisement to the other attached areas. The ASBRs can then in turn calculate the TE
weights for each destination network. These calculations result in a value for each TE Weight for each
destination network in the AS and for each ASBR across the AS. The weights from the IGP are then
exported into BGP for propagation to its EBGP peers.
BGP should take special care of the homogeneity of the metrics otherwise the route calculation won’t
be 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 be
representative of a requirement: a metric would represent the delay on a link, another metric would
represent the available bandwidth on the link (the lower the metric, the more bandwidth it has). These
TE metrics would only be used for the calculation of the TE weights exported by the IGP to BGP, and
not 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 Opaque
LSA 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 only
shown 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 be
summarised 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 intradomain links. It just means that there is some connectivity between the two BGP peers, but it does not
represent 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 aggregation
of the Equal-cost paths between two ASBRs, or the aggregation of the set of possible paths as
calculated by OMP (Figure 52).
In this model, a set of TE weights is associated with each interconnection. This is an intermediate level
of aggregation, since a dashed line may represent the aggregation of several inter-domain links. Delay
for example represents the delay between two BGP peers, and may be different if we consider another
pair of BGP nodes.
On the right side of Figure 51, each domain is represented as a node. A set of metrics are attached to
this node. This a very strong level of aggregation: delay for example is a “default” value, and remains
the same, even if we consider different pairs of BGP nodes. It can be for example the maximum delay
to cross the domain, or an average value to cross the domain.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 132 of 172
The latest level of aggregation is the simplest. We have a limited set of “nodes” to consider (the
number of ASs in the Tequila network). With each “node” is attached a number of TE weights. But
this 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
«
/RZOHYHORIDJJUHJDWLRQ
+LJKOHYHORIDJJUHJDWLRQ
Figure 51: level of aggregation (2)
$6
$6
DJJUHJDWLRQ
&RQQHFWLYLW\ EHWZHHQ WZR %*3 SHHUV UHVXOW IURP WKH
DJJUHJDWLRQRIDVHWRILQWUDGRPDLQSDWKV
Figure 52: level of aggregation (3)
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 route
reflector for example).
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 133 of 172
But the first level of aggregation gives a more accurate view of the network capability in terms of
delay, 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 measured
and 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 way
it 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 a
smooth worst case or a smooth best case.
Other…
Worst-case and best case should be excluded, because they do not really represent the transfer
capability between the pair of BGP nodes. A smooth value, resulting from regression between the
current measurement and some previous values, may give better results and eliminates fast
oscillations.
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 of
BGP peers value in the case of the low-level aggregation model. Let us consider, for simplicity, the
case of delay.
Low-level of aggregation model
It is important to remember that, with the low-level of aggregation model, connectivity between two
BGP peers (a dashed line in Figure 51) may result from the aggregation of a set of intra-domain paths
between these two BGP nodes (Figure 52).
Delay also results from the aggregation of delay values on each path. If, on each path, delay is
measured using a smooth algorithm (as explained in section 5.4.4.3.4.1), the last step is to aggregate
the set of delay measurement for each path, to a single value, representative of the transfer capability
of this pair of BGP nodes. A possible solution here would be to take the average value.
3 D WK G $
G G G G G G %
3 D WK CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
j=4
D 1,t =
∑
D 2 ,t =
∑
d
j1
d
j2
j =1
G M L G H O D \ R Q O L Q N M L R I S D W K L
(t )
' L W 6 X P R I D O O W K H G H O D \ V R Q
j=3
j =1
SD
1,t
= f 1 ( SD
SD
2 ,t
= f 1 ( SD
D OO W K H OLQ N V R Q S D W K L D W WLP H W
(t )
UD Z G H OD \ R Q S D WK LD W WLP H W
1,t − δ
6 ' L W 6 P R R W K ' H O D \ R Q S D W K L , D 1,t )
2 ,t − δ
D WWLP H W
, D 2 ,t )
'
D
A,B
Page 134 of 172
( t ) = f 2 ( SD
1,t
, SD
$ %
W
$ J J UH J D WH G G H OD \
E H WZ H H Q $ D Q G % D WWLP H W
)
2 ,t
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 two
paths between A and B).
Thanks to extensions of the IGP (Q-OSPF, exchange of Opaque LSAs), each ASBR can measure the
current value of the delay on each path to another ASBR (on path 1, delay is the sum of the delays
measured 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 Delay
SD on each path, at time t, is a function of the current raw measurement of the delay on the path, and
of 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 the
smooth values calculated in the previous step. At this point, for each pair of BGP peers, we have a
single 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 the
one depicted on Figure 54, where each link between A and one of its BGP peer is characterised by an
aggregated 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 will
represent the complete AS.
Here again, best-case and worst-case measurements should be excluded: we need a measurement that
better 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 values
into a single one, representative of the whole domain. Here again, we have several choices: take
the lowest one, the highest one, do an average on all the values, …
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 135 of 172
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. Frequent
exchanges of TE weights give a correct view of the network, but consume more bandwidth and
increase the number of operations at a router. On the other hand, it is very important to give every
node a correct knowledge of the TE capability of the network. A compromise must be made between
frequent 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 the
Internet 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 be
modified: the additional TE parameters should be used as input, and could even take precedence
over the standard BGP weights. No real clue is given concerning the modifications of the BGP
route decision process. No algorithm (pseudo-code for the implementation) is given. We only
know 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 time
they are actually used for a routing decision. This would also very much increase the
information to be transported by BGP.
There is no incentive for anyone to try to load balance the entire internet, since the choice of
next hop AS for certain traffic that is subject to service level guarantees will merely depend on
capability 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 spare
capacity it still has on its network, since this is pretty much highly valued competitive
information. So first ask if capacity is available for premium traffic, and yes or no will be the
answer, along with the price.
Homogeneity. The TE weights are exported from the IGP to BGP (paragraph 5.4.4.3.2). Different
ASs may run different IGPs. Moreover, it has become common for a single AS to use several
IGPs. Metrics calculated by OSPF can be different from metrics calculated by ISIS, then resulting
in incoherent route calculation. Special care should then be taken at the BGP level to ensure the
homogeneity of the TE metrics: BGP can provide the homogeneity that we need to make the route
calculation 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 of
aggregation model (paragraph 5.4.4.3.3 and 5.4.4.3.4).
5.4.4.5 Conclusion
There 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 available
resources, 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 BGP
nodes. But this is maybe not necessary, since resources are normally measured and managed by the
BB.
Moreover, for the reasons explained in paragraph 5.4.4.4, we do not fully believe in exchange of QoS
information. The problems are mainly related to the amount of information, to the problem of
maintaining up-to-date information (given the size of the Internet), and to commercial and
administrative constraints.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 136 of 172
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 that
should be made on BGP, we imagined another model, far simpler, but still providing a way to
calculate end-to-end QoS paths.
5.4.5 Model 2: “CoS capability” model
% ( ( )
%%
%(
%%
$ 6
$ 6
% ( ( )
% ( ( )
%%
%%
$ 6
%%
$6
% ( ( )
%%
$ 6
()
S D WK
G HVW
Figure 55: “CoS capability” model
This model requires very limited extensions: each domain advertises to its peer ASs what “types” of
traffic are supported (advertisement of a set of ToS bytes for example). BGP messages include an AS
path 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”, because
AS2 does not support EF traffic. On the contrary, AS3 supports this type of traffic, and advertise this
capability 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 the
required 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 allocation
of resources).
5.4.6 Single-path BGP versus Multi-path BGP
BGP4, as detailed in [BGP4], is intrinsically single-path. This means that there is only one path toward
a set of destination, for a certain CoS. But for end-to-end TE, it may be interesting to use several
different 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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 137 of 172
This chapter compares single-path and possible extensions of BGP toward multipath, and details the
advantages 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 this
characteristic: even if BGP only supports one CoS, there may be one or several path toward a certain
set of destination, within this CoS.
5.4.6.1 A BGP single-path solution
There is no load-sharing capability in standard BGP. Each BGP node calculates only one path per
destination 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 the
QoS requirements contained in the SLS.
•
•
In the “QoS capability” model, BGP calculates one path, taking the advertised QoS capability as
input. The BBs are responsible for deciding whether the QoS requirements in the SLS may be
warranted.
In the “QoS parameters” model, BGP calculates one path, taking load, delay, available bandwidth
or other, into account. The QoS capability of each path is known from the calculation, and the SLS
acceptance process may be done without BBs.
The available bandwidth in each of these QoS pipes will vary, as a function of the traffic transported
in each traffic category. At a certain moment, the available bandwidth in a QoS pipe could be so small
that the QoS pipe could not accept any new SLS. Since we are in a single-path BGP scheme, the only
solution is to negotiate an increase of bandwidth for this QoS pipe. Since it doesn’t require a new or
alternative pipe to be established, the traffic is not stopped. But we can not be sure that this increase of
allocated 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-balance
between several ASs and an additional degree of security in case of a path failure: the alternative paths
can still be used.
There is no intrinsic load-sharing capability in BGP4. Instead of calculating only the best path toward
a 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 of
destination) and per CoS.
One problem here is to avoid the introduction of loops: BGP is a path-vector protocol, and loops may
be 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. If
we 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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 138 of 172
$6
$6
$6
GHVW
$6
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 for
example 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 which
you advertise the route is already included in your list of path vectors”. AS4 and AS2 are indeed
included in the list of valid paths toward “dest”, in AS1.
But this principle -although conceptually very simple- is strongly limited, because of scalability
problems. It requires indeed that a tree or list of the possible AS-Paths be added to the BGP UPDATE
message. As the size of the network and the number of branching points in it are unpredictable, there
is no upper limit on the size of the list in the BGP message. If, for the purpose of TE, it appears that
multipath extension for BGP are required, this scalability problem must be solved.
5.4.6.3 Conclusion
For the time being, the scalability problem related to the multipath BGP loop detection algorithm can
not be solved. We suggest thus to use a single path solution at the BGP level, at least in a first step. If
later on, a scalable loop detection algorithm for BGP can be found, multipath BGP can be foreseen to
further improve the use of the network (giving the opportunity, for example, to load balance between
ASs).
5.4.7 Conclusion
The “QoS parameters” model is very complex and requires a lot of extensions to BGP. Exchange of
TE 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 completely
handled by the BBs.
As, for the time being, the scalability problem of multi-path BGP can not be solved, we will work on
TE 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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 139 of 172
6 DATA-PLANE FUNCTIONS
This chapter briefly describes the main data-plane functions, i.e. Traffic Conditioning (mainly at the
edge routers) and Per Hop Behaviour (PHB) – Enforcement. Considering these functions, the
TEQUILA project follows the guidelines given by the IETF DiffServ working group.
6.1 Traffic Conditioning
6.1.1 Overview
The 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 before
it actually enters the Tequila network
•
the dissemination of resulting relevant information to SLS management block and monitoring
block.
Once the traffic has been conditioned it can be properly queued into the (Tequila) network through the
queuing (ex. scheduling/forwarding9) block.
So the TCB is mainly acting in the data plane (as part of the PEP feature, cf. COPS architecture) and
receiving 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 for
DiffServ Routers [DS-Model], called DSR model here.
The following sections extract the “Tequila-relevant” concepts developed in this model. Note: the
same 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 partly
performed through queuing. cf. following sections)
To be more precise the DSR model consider (through hierarchical approach) each of the above
elements 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 Function
Classifiers are 1:N devices: they take a single stream as input and generate N logically separate traffic
streams 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 (the
header values, contents, and attributes relevant for classification).
9
cf. the renaming proposed for the forwarding/scheduling block.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 140 of 172
Among the examples given in the model, the two main classifiers (and corresponding filters) of
interest for Tequila are:
•
The BA classifier using only the DiffServ code-point (DSCP) in a packet’s IP header to determine
the logical output stream to which the packet should be directed, with exact-match condition on
this field because the assigned DSCP values have no structure, and therefore no subset of DSCP
bits are significant.
•
The MF classifier using one or more fields in the packet. A common type of MF classifier is a 6tuple classifier that classifies based on six fields from the IP and TCP or UDP headers (destination
address, source address, IP protocol, source port, destination port, and DSCP). MF classifiers may
classify on other fields such as MAC addresses, VLAN tags, link-layer traffic class fields or other
higher-layer protocol fields (e.g. for the “famous” state-full applications).
Notes:
•
To prevent ambiguity between overlapping filters in a classifier, a precedence mechanism between
established filters is needed. To be complete, a classifier need also a “everything else” filter as the
lowest precedence element.
•
MF classification of fragmented packets is impossible if the filter uses transport-layer port
numbers e.g. TCP port numbers. MTU-discovery is therefore a prerequisite for proper operation of
a DiffServ network that uses such classifiers.
6.1.2.2 Meter Function
A meter is needed to offer services based on temporal (i.e. rate) profile within which the customer
submits traffic.
A meter measures the rate at which packets making up a stream of traffic pass it, compares the rate to
some set of thresholds and produces some number (two or more) potential results: a given packet is
said to "conform" to the meter if, at the time that the packet is being looked at, the stream appears to
be within the meter's limit rate.
Actions are then applied to conforming and non-conforming packets (e.g real-time marking, counting
for 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 and
interval: 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 and
allows at most 100 bursts per second of 1500 bytes and at a rate not to exceed 1.2 Mbps as conforming
traffic. 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 bucket
meters 10 (and associated policing for EF and AF based TCB).
6.1.2.3 Action Elements/Functions
The classifiers and meters described up to this point are generally used to determine the appropriate
action 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 from
future token allocations. To be confirmed : CAR is close to “loose token bucket” detailled in the appendix of the
model.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
marking,
•
absolute dropping,
•
multiplexing
•
counting,
Page 141 of 172
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 that
result might be used later for customer billing, service verification network engineering, monitoring
purposes, etc.
Multiplexing is occasionally necessary to multiplex traffic streams into a functional datapath element
with a single input.
6.1.2.4 Queuing elements/Functions
To be complete on TCB, queuing elements described in the DSR model have to be mentioned. The
queuing 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 as
a concatenation of an algorithmic dropper with a scheduler.
Shaping (TCB action) is modelled by a non-work-conserving scheduler, delaying the departure of
packets that would be deemed non-conforming by a meter configured to the shaper’s maximum
service rate profile.
Notes:
It has to be noticed that the DSR model defines that a TCB contains, by definition, zero or more
classifier, meter, action, algorithmic dropper, queue and scheduler elements, arranged arbitrarily
according to the policy being expressed, but always in the order here.
6.1.3 Examples for the Tequila SLSs
The DSR model gives some examples of TCBs which implement the cascading/concatenation of
elementary functional elements described previously to provide SLS for mono-customer permanent
access, 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 TCB
implementations can be thought of. The following section proposes examples of TCBs to be
refined/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 the
customer 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.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
e2e VLL
(CPE to CPE)
Page 142 of 172
CPE lan side
CPE wan side
PE customer side
PE backbone side
MF classifier (recognition
of traffic belonging to the
VLL)
Queue and Scheduler
(VLL vs other traffic)
BA classifier
Queue and scheduler
Meter
Meter (X bucket)
Marker
Marker (VLL codepoint)
Policer
Policer (absolute dropper)
Counter
Counter
(transmitted/dropped VLL
traffic)
(these elements are
redundant with the CPE
but needed for security)
Options:
Queue and Scheduler
(VLL vs other traffic) :
PE CPE
Per application meter/
policer “inside” the VLL
Edge to edge VLL
(PE to PE)
Å
BA classifier
Queue and scheduler
Meter
Marker
Policer
Counter
Queue and Scheduler
(VLL vs other traffic) :
PE CPE
Å
Options :
MF classifier instead of
BA classifier (ISP
marking)
Å
Shaper or policer
PE CPE
•
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 parameters
The 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 mgmt
block)
Communications with the monitoring block are essentially one-way:
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
Page 143 of 172
sending the counters (feed-back from the TCB actions on the customers traffic to the monitoring
block)
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) to
the TCB. Indeed it should be forbidden (these orders should only come from the SLS mgmt block)
6.2 PHB Enforcement
The PHB Enforcement functional block is responsible for implementing the mechanisms needed to
provide differential forwarding treatment to traffic passing through the router according to the
DiffServ WG specifications. From the definition of the PHB as "the externally observable forwarding
behaviour applied at a DS-compliant node to a DS behaviour aggregate", it is deduced that the PHB
Enforcement block should implement the standardised PHBs in an abstract level, hiding the vendor
and algorithm specific implementation details.
In order to achieve this, the PHB Enforcement block manipulates the NE's native scheduling and
queue management mechanisms so as to enforce the bandwidth and buffer sharing rules and
parameters, defined by the Dynamic Resource Management functional block, and hence satisfy the
PHBs requirements in terms of throughput, delay, jitter and loss.
6.2.1 Description of Functions
6.2.1.1 Scheduling
Scheduling is a mechanism that regulates the order of departure of packets from separate packet
queues, forming a single output queue destined for transmission. The way scheduling treats each input
packet 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 traffic
forwarding treatment.
Scheduling takes as input a set of packet queues, each serving a pre-classified type of traffic and
delivers as output a single packet queue. It uses a scheduling algorithm which may vary depending on
the underlying Network Element's implementation. It is important though for a scheduling algorithm
to support a minimum functionality in order to comply with the Tequila functional requirements and to
enable 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 specific
traffic type.
Optionally, the scheduling algorithm may provide support for applying a maximum traffic profile in
order to enforce constraints to a specific traffic type.
6.2.1.2 Queue Management
Queue management is a mechanism that controls the average queue size of a packet queue in order to
provide congestion avoidance and maintain high throughput and low delay. In order to achieve this, it
exercises a dropping algorithm which selectively discards packets from the queue. This algorithm can
be regulated to be more or less aggressive and provides therefore the means for enforcing drop
precedence to traffic classified into different queues.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 144 of 172
As in the case of the scheduling mechanism, the queue management mechanism supported by a
Network Element may vary. Though, the state of the art review shows that most of the considered
algorithms function using thresholds and dropping probabilities.
6.2.2 Interface semantics and parameters
The PHB Enforcement functional block interacts only with the Dynamic Resource Management
functional block from which it gets the necessary PHB configuration information. The Dynamic
Resource Management block is entitled to configure the PHB Enforcement block during the latter’s
initialisation and operational phase.
The PHB Enforcement block should support configuration parameters for each supported PHB dealing
with bandwidth and buffer resources allocation and excess traffic treatment. The specific parameters to
be supported are yet to be defined. It is envisaged that the [PHBSPEC], which describes a set of PHB
specification parameters, will be used as input. More specifically, [PHBSPEC] proposes that an
abstract representation of the PHBs and a minimal set of parameters for their tuning, both independent
of particular implementations, shall be used to achieve interoperability between different devices and
vendors. The proposed set of the PHB configuration parameters comprises parameters providing for
bandwidth and buffer allocation for each specified PHB, thus satisfying one of the functional
requirements of the PHB Enforcement block. The proposed set of parameters though, needs to be
studied, refined and enhanced according to the project’s needs.
The PHB Enforcement block is responsible for mapping these PHB configuration parameters to the
appropriate scheduling and queue management configuration parameters and to ensure the underlying
mechanisms enforce the appropriate forwarding treatment in order to support the defined PHBs.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 145 of 172
7 POLICY FRAMEWORK
Policy Management can be considered as a set of functional blocks as seen in Figure 56. The
description of the functions of each block is presented in the following subsections.
Human
Policy Management
Policy
Mgmt Tool
Policy
Consumer
Policy
StoringService
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 Rules
in the Policy Repository through a GUI, a simple Web-based form, and/or a command line
interface or scripting interface.
This function has as input the definition or activation of Policies in a high level language by the
human operator. It also provides feedback on the validation or translation results to the
administrator, indicating the erroneous rule conditions or actions or displaying the existing Policy
Rule with which the new one conflicts.
•
Translation: this function maps a high level (e.g. Business-oriented) specification of a Policy
Rule to an object-oriented policy representation (information objects), which can be stored in the
repository.
This function requires as input the policy specification as entered by the operator and delivers as
output an object-oriented policy representation (information objects) for storing them in the Policy
Repository.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
•
Page 146 of 172
Validation: this function performs two kinds of check of policy prescription and/or rule and
returns the result of this check. The first kind of check is to validate the data types of the terms of
the specified Policy Rule and the second one is to validate semantics of the Policy Rule, ensuring
that the construction of the Policy Rule and its conditions and actions, from a set of predefined
blocks, actually make sense.
This function has as input the translated Policy Rules entered in the tool and provides as output
messages, 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 existing
policies 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 function
and 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 and
the appropriate verifications are made, this particular policy must be activated in order to be stored
in the Policy Repository. When the human operator has specified a policy hierarchy, definition
and verification of all the policies in the hierarchy have to be done before storing the whole policy
hierarchy in the Repository.
This function requires as input the activating Policy message from the human operator and the
delivered 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 of
hierarchy defined.
The input to this function is the policy refinement rules that will be stored and the policy rules that
will 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 repository
is required, in order to perform the Rule Validation and Conflict Detection function as well as
from 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 for
retrieval of already stored policies either from the Policy Management Tool or the Policy
Consumer. The delivered output is sending back the requested information to the functional
component that asked for it and also notifying the appropriate Policy Consumer about
changes/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 the
required information from the Policy Storing Service.
The input for this function is the notification sent by the Policy Storing Service to the Policy
Consumer, 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 the
Repository and interpret them to parameterised functions of the management capabilities of the
related functional block.
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 147 of 172
The required input is the retrieved new policy that this Policy Consumer is responsible for and the
output is the triggering of the appropriate management function when the associated event has
been sent from the monitoring service.
•
Register Policy Monitoring: this function registers the appropriate events at the Monitoring
Functional Block in order to get notified about the triggering of the enforcement of specific
policies 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 the
Policy repository and delivers as output the registering or un-registering messages sent to the
Monitoring FB.
•
Enforcing Policy: this function triggers the mapped management action of the FB associated with
that 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 the
triggering of the mapped management function.
7.2 Interface semantics and parameters
This section describes the interaction of the PolicyManagement Functional Block with other
Functional Blocks through events, messages or signals.
PolicyManagement
Human
1, 2
PolicyMgmtTool
8
SLSManagement
3, 4, 5
14
6
PolicyConsumer
PolicyStoringService
7
13
Monitoring
11, 12
10
DynamicRt&RsrcMgmt
9
Dimensioning
Figure 57: Interaction of the PolicyManagement Functional Block with others
The description of the relevant events is included in the table that follows:
CEC Deliverable Number: 101/Alcatel/b1
 TEQUILA Consortium - September 2000
From FB
To FB
Event name
Parameters
Comment
1
Human
PolicyMgmtTool
PolicyMgmtTool_SetPolicy (1)
Policy fields
-This message represents the definition of Policies in a high level
language by the Human Operator
2
Human
PolicyMgmtTool
PolicyMgmtTool_ActivatePolicy (2)
PID
-This message will activate the policy that was previously entered by
the operator so that the policy will be in a state of waiting to be
enforced 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 for
editing purposes e.g. change, delete. This message can also be used
to search for a particular Policy Rule.
6
PolicyStoringService
PolicyConsumer
PolicyConsumer_NotifyNew/ChangePolicy (6)
PID
-This message will notify the appropriate Policy Consumer for a
change in an existing Policy that this Policy Consumer is responsible
for enforcing.
7
PolicyConsumer
PolicyStoringService
PolicyStoringService _GetPolicy (7)
PID
-This message will retrieve the appropriate information needed from
the 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 policy
can no longer be enforced.
9
PolicyConsumer
Dimensioning
Dimensioning_SetPolicyDimFunct (9)
(see comment)
-This message will map the policies to the parameterized functions
of 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 functions
of management capabilities of the Dynamic Resource and Route
Management FB.
11
PolicyConsumer
Monitoring
Monitoring_RegisterPolicyMonitoring (11)
Triggering Event,
Monitoring Objects,
Thresholds
-This message will register the triggering events to the Monitoring
FB that the Policy Consumer wants to be notified for enforcing the
policies.
- It may also register events that indicate the correct enforcement of
policies.
12
PolicyConsumer
Monitoring
Monitoring_UnRegisterPolicyMonitoring (12)
Triggering Event,
Monitoring Objects,
Thresholds
-This message will unregister the triggering events to the Monitoring
FB that the Policy Consumer wants to be notified for enforcing the
policies.
- It may also unregister events that indicate the correct enforcement
of policies.
13
Monitoring
PolicyConsumer
PolicyConsumer_NotifyMonitoringEvent (13)
Monitoring Objects,
Thresholds
-This message will notify the Policy Consumer about the specified
event 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 functions
of management capabilities of the SLS Management FB.
D1.1: Functional Architecture Definition and Top Level Design
Page 149 of 172
7.3 Finite State Machines
The following sections describe the internal working of the Functional Sub-Blocks, which constitute
the Policy Management Functional Block by means of a Finite State Machine (FSM).
7.3.1 The Policy Management Tool FSM
Initialization
Done E.0
Init
Hierarchy
Generated E.16
No event E.1
Policy
Stored E.11
Refinement Stored E.13
Generate
Hierarchy E.12
Store Refinement
Rules E.15
Refinement
Alarm Sent
E.9
Wait/
Editing
Activate
Policy E.10
Set/
Change
Policy
E.2
Translating
Delete
Policy E.14
Storing
Policy in
Repository
No Conflict
E.8
Translation
Failed E.3
Translation
Done E.4
Conflict
Detection
Error
Cannot Validate
Policy E.5
Validating
Policy
Validated
E.6
Policy Conflict Found E.7
Figure 58: The Policy Management Tool FSM.
Description of states
•
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 is
mapped to an object-oriented policy representation (information objects).
•
Validating: state at which data types and semantics of policy prescription and/or rules are
checked.
•
Conflict Detection: state at which consistent checks to identify conflicts between the new and
existing policies are carried out.
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 150 of 172
•
Refinement: at this state policy refinement rules are stored and policies for each level of hierarchy
defined are generated.
•
Error: this is an error state, which is reached when either there has been a problem when
validating a new policy rule or checking out conflicts between the new and existing policies. After
the appropriate alarm has been sent the next active state is the Wait /Editing.
Event-name
Parameters
Description
E.0
All initialisation tasks have been completed.
E.1
After the Policy Management Tool has initialised, even without
any 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 edited
and have to be validated and executed.
E.3
PID
This event indicates that the new policy rules were not
translated successfully.
E.4
Policy Object
This event indicates that the new policy rules were translated
successfully.
E.5
PID
This event indicates that the new policy rules could not be
validated.
E.6
Policy Object
This event indicates that the new policy rules have been
validated.
E.7
PIDs
This event indicates that conflicts have been found between the
new and existing policies.
E.8
Policy Object
This event indicates that conflicts have not been found between
the new and existing policies.
E.9
PID
This event indicates that the new policy rules were declared
invalid.
E.10
Policy Objects
This event indicates that new policy rules will be stored and
activated.
E.11
PID
This event indicates that new policy rules have been stored and
activated.
E.12
Policy Hierarchy
Rules
This event indicates that new refinement/hierarchy directives
will be stored and activated.
E.13
Policy Hierarchy
Rules
This event indicates that new refinement/hierarchy directives
have stored and activate successfully
E.14
PID
This event indicates that existing policy rules have to be
checked for deletion.
E.15
Policy Fields
This event indicates that policies will be refined according to
refinement rules stored.
E.16
Policy Fields
This event indicates that policies were generated for every level
of hierarchy defined. Each policy generated has its own policy
fields.
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 151 of 172
State Transition Table
E.0
S0
S1
S2
S3
S4
S5
S6
S7
Init
Wait/Editing
Translating
Validating
Conflict Detection
Storing Policy in
Repository
Error
Refinement
[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 Validate
Policy, S6]
E.6
[Policy Validated, S4]
[Policy Conflict, S6]
E.7
[No Conflict, S1]
E.8
[Alarm Sent, S1]
E.9
E.10
[Activate Policy, S5]
[Policy Stored, S1]
E.11
E.12
[Generate Hierarchy,
S7]
[Refinement
Stored, S1]
E.13
E.14
[Delete Policy, S4]
E.15
[Store Refinement
Rules, S7]
[Hierarchy
Generated, S1]
E.16
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 152 of 172
7.3.2 The Policy Storing Service FSM
Init
Initialization
Done E.0
No Event E.1
Idle
Store Policy E.2
Results
Sent E.9
Remove Policy E.3
Updating
Repository
Consumer
Notified
E.5
Update
Done E.4
Notify
Consumer
Get Policy E.6
Retrieve Policy E.7
Sending
results
Search Done
E.8
Searching
Figure 59: The Policy Storing Service FSM
Description of states
•
Init: all functions to initialise the Policy Consumer block are performed during this state.
•
Idle: state at which we wait for external requests and notifications.
•
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 the
appropriate Policy Consumer about a new, changed or deleted Policy.
•
Searching: at this state, the Policy Storing Service is searching the stored Policies to find the
policy 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 the
requests of specific Policies either to the Policy Management Tool or the Policy Consumer.
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Event-name
Parameters
Page 153 of 172
Description
E.0
All initialisation tasks have been completed.
E.1
No messages arrive; the system has to stay in this state.
E.2
Policy Objects
A new request for storing a Policy in the Repository has
arrived.
E.3
PID
A new request for removing a Policy from the Repository
has arrived.
E.4
Policy Objects
This event indicated that the repository has been updated
about the new/changed or deleted Policy Objects.
E.5
PID
This event indicates that a notification to the appropriate
consumer has been sent about an addition, change or removal
of a Policy.
E.6
PID
This event indicates that a Get request for a Policy by the
Policy Consumer has arrived.
E.7
PID
This event indicates that a request for a retrieval of a Policy
by the Policy Management Tool has arrived.
E.8
Policy Object
This event indicates that the searching function has found the
requested Policy Object.
E.9
Policy fields
The requested information about a Policy has been sent
either to the Policy Management Tool or the Policy
Consumer.
State Transition Table
E.0
S0
S1
S2
S3
S4
S5
Init
Idle
Updating
repository
Notify Consumer
Searching
Sending Results
[Initialisation Done,
S1]
E.1
[No Event, S1]
E.2
[Store Policy, S2]
E.3
[Remove Policy,
S2]
[Update Done, S3]
E.4
[Consumer
Notified, S1]
E.5
E.6
[Get Policy, S4]
E.7
[Retrieve Policy,
S4]
E.8
E.9
[Search Done, S5]
[Results Sent, S1]
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 154 of 172
7.3.3 The Policy Consumer FSM
Init
Initialization
Done E.0
Delete Policy E.12
Wait
Idle
Policy
Deleted E.13
Notify New/
Change Policy
E.2
Policy
Deactivation
No Event E.1
Get
Policy
NotifyEnforceUn
E.11
Notify Monitoring Event
(UnEnforcePolicy) E.10
Error
Cannot Enforce Policy E.9
Cannot Map
Policy E.4
Policy Got E.3
Mapping
Policy
Enforcement
Notify Monitoring
Event(trigger) E.7
Register Policy
Montoring
(Trigger Event)
E.6
Wait trigger
event
No Triggering Event E.5
Figure 60: The Policy Consumer FSM
Description of states
•
Init: all functions to initialise the Policy Consumer block are performed during this state.
•
Idle: state at which we wait for external requests and notifications.
•
Get Policy: at this state the Policy Consumer is requesting and retrieving the needed information
about the policy from the Policy Storing Service.
•
Mapping: during this state the mapping of the Policy fields is performed to the specific
management functions of the functional block to which the Policy Consumer is associated with and
the monitoring events needed to register with the Monitoring Block. If the mapping cannot be done
successfully, the next state will be the Error State.
•
Wait trigger event: during this state the Policy Consumer waits to be notified about the registered
trigger event from the Monitoring Block to start enforcing the Policy action.
•
Policy Enforcement: at this state, the Policy Consumer triggers the mapped Policy action after
receiving the notification about the triggering event. If this is done successfully the next state is the
Wait state, otherwise it goes to the Error state.
•
Wait: during this state the Policy Consumer waits for a notification from the monitoring service
specifying that the policy can no longer be enforced. If it receives this notification it goes to the
Error state.
•
Error: this is the state reached when there is a problem with mapping, policy enforcement or
when Monitoring notifies about the inability to further enforce the policy.
•
Policy Deactivation: during this state all the necessary actions needed for removing a policy from
the Policy Consumer are performed (i.e. un-registering the monitoring events and deleting the
information that the policy consumer had for realising this policy).
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Event-name
Parameters
Page 155 of 172
Description
E.0
All initialisation tasks have been completed.
E.1
No messages arrive; the system has to stay in this state.
E.2
PID
A notification about a new or a change in an existing Policy
has arrived.
E.3
Policy Info
This event indicates that the needed information about the
changed or new policy is retrieved.
E.4
PID
This event indicates that the Policy Consumer was unable to
perform the mapping function.
E.5
This event indicates that there was no triggering event for the
specified Policy so the Policy Consumer goes directly to the
Enforcement state.
E.6
Triggering Event,
Monitoring Objects,
Thresholds
This event indicates that the appropriate triggering events are
registered to the Monitoring Block.
E.7
Monitoring Objects,
Thresholds
A notification of the previous registered triggering events has
arrived.
E.8
Monitoring Objects,
Thresholds
This event indicates that the enforcement of the policy is
now registered for being monitored.
E.9
PID
A notification about an erroneous attempt to enforce the
Policy.
E.10
PID
A notification from monitoring that the Policy can no longer
be enforced has arrived.
E.11
PID
A notification to the Policy Management Tool that there is a
problem handling this policy by the Consumer has been sent.
E.12
PID
This event indicates that a request for deleting a Policy has
arrived.
E.13
PID
A confirmation about the deletion of the requested Policy has
been sent.
 TEQUILA Consortium - September 2000
D2.1: Simulators, Network Elements and Development Environment
Page 156 of 172
State Transition Table
S0
Init
E.0
S1
Idle
S2
Get Policy
S3
Mapping
S4
Wait trigger event
S5
Policy Enforcement
S6
Wait
S8
Policy
Deactivation
[Initialisation done,
S1]
E.1
[No event, S1]
E.2
[New
request/Notification,
S2]
[Policy Got, S3]
E.3
E.4
[Cannot Map Policy,
S7]
E.5
[No Triggering
Event, S5]
E.6
[Register Policy
Monitoring (Trigger
Event), S4]
[Notify Monitoring
Event, S5]
E.7
E.8
[Register Policy
Monitoring
(Enforcement), S6]
E.9
[Cannot Enforce
Policy, S7]
[Notifying
Monitoring Event
(UnEnforcePolicy),
S7]
E.10
[NotifyEnforceUn, S1]
E.11
E.12
S7
Error
[Delete Policy, S8]
E.13
[Policy Deleted,
S1]
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 157 of 172
8 MONITORING FRAMEWORK
8.1 Introduction
Monitoring is a crucial network function for both the correct functioning of the Tequila system and for
the ability to impose a check on the SLSs, which were agreed with a customer. It is necessary to have
a local and an aggregated overall view on the network in terms of the definitions of the IETF IPPM
working group. This is reflected in the monitoring framework and its correlation with the rest of the
Tequila 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 the
basis 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 network
element (referred to as passive measurements). To have a scaleable system, the information of these
basic building blocks needs to be aggregated into summarising statistics by some higher level blocks.
8.2 Message Sequence Chart
The next figure gives an overview of the typical behaviour of the monitoring framework within the
Tequila 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 being
delivered.
•
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 in
the figure. The local activities of the monitoring framework are organised by the Node Monitor. The
latter one uses its knowledge on the configuration of a network element, and the requested information
from the other blocks, to configure the implementation of the measurements.
The typical monitoring behaviour can be split into 4 phases. At first, every functional element
interested in the aggregated, network-wide monitoring information needs to subscribe to the network
monitor. He will then decide which local (node) measurements are needed to be at the basis of this
network-wide information. This will be incorporated in the second phase: the configuration of the
local node. It could be that some other blocks need direct local information (e.g. dynamic management
for local optimisations), so they will have to configure and poll the node monitor directly. They will
also act in this phase. The node monitor will perform the measurements on basis of these
configurations, 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 will
aggregate the local information. A last phase consists of the monitoring feedback to the subscribed
components.
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
SLS
Management
Dynamic
Route
Management
Dynamic
Resource
Management
SLS
Monitor
Node
Monitor
Set-up
monitoring
requests
and poll at
regular
intervals
Retrieve
metering
information
as input
Excecution
Reproting & exceptions
Network
Monitor
Subscribe to network-wide
Monitoring Information
Configuration
Reques
t
Traffic
Forecast
Page 158 of 172
Summarise and
process results
Thresholds crossed
Network Status reports
Exceptional Events
Figure 61: Monitoring feedback MSC
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 159 of 172
8.3 Functional Block Decomposition
In this section, a decomposition of the monitoring framework will be given. After a general overview
there will be a more thorough description on the semantics of SLS-monitoring.
8.3.1 Architecture
SLS
Management
Traffic
Forecast
SLS
Monitor
Network
Monitor
Network
Dimensioning
Node
Monitor
Traffic
Conditioning
Dynamic Route
Management
Dynamic Resource
Management
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 will
request some summary statistics to be able to report to other management layers. Depending to
the nature of the SLS and the kind of results requested, the information needed can be
network-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 will
also 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 over
effective measurement drivers, he has the configuration of the network element as an
(implicit) input. This enables the monitoring configuration agent to translate requests and
results between low-level drivers and upper layer requestors.
•
Traffic Conditioning
Next to its obvious conditioning role, the traffic conditioning is also a part monitoring
framework. Information from its metering, classification and scheduling/queuing will be an
input to the node monitor. At the edges, this information could also be used directly by the
SLS-monitor.
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 160 of 172
8.3.3 Interfaces
8.3.3.1 Type
All of the interfaces in the monitoring framework fit into a client-server relationship. Section 2.1.33
will give an overview of these relationships. The communication on the interfaces can be handled in
different ways: continuos reporting, either by polling or trap-based, reporting based on configured
thresholds, exception reporting (e.g. service interruption detection), or even a combination of these.
8.3.3.2 Parameters
Two types of parameters are being used for the communication. The basic measurements results will
be expressed in terms of the metrics defined by the IPPM working group. These might be extended
with own defined metrics (e.g. the CPU-load of a node). Next to this, the aggregated information will
need 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 way
this is filled in needs to be studied.
8.3.3.3 Interface overview & semantics
Parameter type
Client role
Server role
SLSmanagement
SLS-monitor
X
Follow-up on established SLSs
SLSmanagement
Network
Monitor
X
Network status information exchange
SLS-monitor
Traffic
Conditioning
SLS-monitor
Network
Monitor
SLS-monitor
Node Monitor
X
Local information (e.g. at the edge) retrieval
Network
Monitor
Node Monitor
X
Local information retrieval
Traffic
Forecast
Network
Monitor
X
Network status retrieval (possibly including
trends)
Dynamic
Management
Network
Monitor
X
Current network status and/or exceptional
events (e.g. service interruption)
Dynamic
Management
Node Monitor
X
Current node status and/or exceptional events
(e.g. service interruption)
Node Monitor
Traffic
Conditioning
X
Current node status
basic
aggregated
X
Semantics
Local information (e.g. at the edge) retrieval
X
Network status retrieval for the observed SLS
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 161 of 172
8.3.4 Finite State Machine
The SLS-monitor, Network Monitor and Node Monitor have functional state machines which come
down to the classic client-server paradigm, and which should be obvious when looking at the scenario
described in.
8.3.5 Algorithm and Protocol Problem Description
To 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 element
needs to be available.
•
Network Monitor: needs to process the large amount of local information to give an aggregated
view to its clients.
•
Interfaces: these are all client-server kind of relationships, needing the folowing generic
enhancements:
½ Configuration / initialisation protocols.
½ Result transportation protocols.
½ Exception handling events.
8.4 SLS Monitoring
8.4.1 Introduction
This contribution basically explains the SLS Monitoring in TEQUILA context. This separate view is
included to shed a light on the specific semantics of this component.
8.4.2 Service Subscription
A Customer Service is a set of more then one uni-directional SLS. These uni-directional SLSs may
have end-points outside of the AS domain. The resource availability check must be done for all of
these uni-directional SLSs prior to the OK/NOK of the service to user. That is a necessity for SLS
subscription to perform the check to ensure that adequate resources are available in order to meet the
quantitative/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 needs
to perform any necessary action in order to provide the term and conditions of service to the customer
and then inform the customer about the conditions. The customer may accept the conditions and buy
the service. Before the user use the service, any necessary classification, marking, shaping and
policing must be set at the ingress nodes.
8.4.3 SLS Monitoring Framework
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 162 of 172
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 the
network while the Ingress/Egress Monitoring task is only assigned to the access edges of the
Ingress/Egress NEs (see Figure 1). The Node Monitoring performs the aggregate performance
measurement. Ingress/Egress Monitor performs per-SLS monitoring at the access edges of the
Ingress/Egress NEs. Hence, both types of monitoring are performed on different edges of the
Ingress/Egress NEs i.e., per-SLS measurement on the access edge and aggregate measurement on the
core edge.
I/EM
NM
Network
I/EM NM
B
NM
NM
A
NM
Access Edge Core Edge
NM
I/EM
C
Ingress/Egress Network Element
Core Network Element
NM:
Node Monitor
I/EM:
Ingress/Egress Monitor
Figure 63: Node Monitoring and Ingress/Egress Monitoring.
Node Monitoring entity passively/actively monitors the traffic on the links. Ingress/Egress Monitor
performs per-SLS measurement such as throughput and user usage time at the access edges of the
network. Network Monitoring, gets the view of entire network based on the physical and logical
topologies. Network Monitoring provides the SLS Monitoring with the end-to-end performance view
of the network. The SLS Monitoring analyses the performance information received from the Network
and Ingress/Egress Monitoring and then provides the related entities with feedback regarding service
conditions and SLA conformity. SLS monitoring is not interested in Node Monitoring and it will
depend on Network Monitoring for core performance and Ingress/Egress Monitoring for customer
related accounting information.
8.4.4 Functional Block Decomposition of SLS Monitoring
8.4.4.1 SLS Monitoring Description
SLS Monitoring takes its input from SLS repository and acts as a client to Ingress/Egress Monitoring
and Network Monitoring. SLS Monitoring must keep track of compliance with customer SLSs by
analysing performance values provided by Network and Ingress/Egress Monitoring entities. SLS
monitoring gathers the combination of information for several uni-directional SLSs to derive the
overall service report to the customer. SLS monitoring focuses on the network layer metric
information such as one-way delay, IPDV, packet loss ratio, and throughput. Apart from having
overall view on the above parameters, the monitoring framework includes link and device availability
and accounting information.
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 163 of 172
The Network Monitoring provides the end-to-end performance view for SLS Monitoring. It is also
essential for SLS Monitoring to use the edge node statistics via Ingress/Egress Monitoring. The
customer traffic is regulated at the Ingress point where the user offered load and service usage time can
be measured. At the egress point, one can observe if the performance (e.g., throughput) is being
provided in the manner expected and agreed upon.
Monitoring every customer SLS is scalable and feasible provided aggregate network performance
metrics are used combined with per SLS Ingress/Egress metrics. The monitoring process can be
categorised based on the QoS/CoS profile of the offered services (mainly PHBs) and scope of the
services (Ingress and Egress points). The Network Monitoring instructs the Node Monitoring to
measure the performance parameters and then it build a network view based on each specified
category. Network Monitoring collects information about network-wide view of paths for every PHBs
along the paths and deduces an end-to-end performance view. SLS monitoring uses this information to
build a view of the offered services to the customers. This is explained in more detail in the following
sections.
8.4.4.2 Functional Architecture
The SLS Monitoring functional architecture and its components are given in Figure 1. The functions of
each block in explained in the next section. Arrows show the flow direction of messages or signals
among SLS monitoring components as well as SLS monitoring components with external Functional
Blocks. The circled numbers shows the sequence order of information flow.
SLS Monitoring
SLS
Monitoring
Repository
Action to be taken
9
11
SLS
Subscription
Report Generator
SLS Manager
1
2
8
Admission
Control
Customer Report
(Check SL values against
SLS)
&
SLS
Repository
Traffic
Forecast
SL values per
customer
10
Management
Report
Action to be taken
Performance Data
Aggregator
3
4
7
Performance Data Initiator/Collector
Initiation
5
Collection
6
Ingress/Egress
Monitoring
1
5
6
Network
Monitoring
Customer SLS & other relevant data are passed.
2
Customer SLS & uni-directional SLSs are used for keeping track of Customer SLS and creating Service-Scope Tables.
3
SLS Monitoring is always be active and this trigger is used for initiation of the monitoring action for new Services & Scopes.
Figure 64: SLS Monitoring Components and Sequence of Actions.
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 164 of 172
8.4.4.3 Functions of Components
SLS Monitoring takes its input from SLS repository (both customer SLS and resulting uni-directional
SLSs). Monitoring action is triggered when a new SLS is activated by Admission Control or SLS
Subscription activates an SLS on behalf of the customer. The Monitoring action is stopped for the
services and scopes that no longer are used. The SLS monitoring components, shown in Figure 2, and
their actions are specified as below.
•
Performance and traffic data related to PHBs and scopes are collected from Network Monitoring
or from Ingress/Egress Monitoring. The data collection is performed by "Performance Data
Initiator/Collector".
•
"Performance Data Initiator/Collector" also receives some sort of accounting information such as
user offered load and usage time and received throughput from Ingress/Egress Monitoring entities
on the ingress and egress nodes.
•
Performance data and other related data, such as faults, link and device availability are used to
compute Service Level values based on service types and scopes and subsequently to deduce
customer SL values as the customer SLS indicators. These actions are performed by "Performance
Data Aggregator". The PDA constructs Service Level Tables (see section 2.3.1) and also initiate
the monitoring action for new services and scopes if required.
•
"SLS Manager" keeps track of measured SL values. Customer SLS indicators are checked against
contractual SLS values for each specific customer, in order to see the SLS conformance or to
detect 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 being
provided in the manner expected and agreed upon. That is, customer SLS indicators and the results
of SLS checks are reported to the customers.
•
Producing regular and detailed reports to inform Management about SLSs status and also stating
problem areas that are causing the SLS not to be met. This information may include network
performance, service level, and customer SLS indicators that Management requires for follow-up
on service activity and possible corrective actions.
•
SLS Manager provides the Traffic Forecast entity with the current network behaviour in terms of
SLS commitments and with appropriate traffic matrices in order to adjust any irregularities if some
customers 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 Scopes
As an example, two service types are requested and offered along A - B path (i.e., service type 1.a and
service type 2). All customers who use these services and path are affected by traffic conditions along
this path. A customer requests a service type 1.a (VLL Pipe service between A and B). Two unidirectional SLSs are constructed for this VPN by SLS Subscription entity. PDA constructs Table 1 and
Table 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 SLS
indicator.
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Scope 1: Ingress A to Egress B
Service 1.a Service 2
PHB-EF
PHB-AF
Delay value
IPDV value
Packet loss ratio
Availability
Other
Table 1: Service Level values for Scope 1.
Page 165 of 172
Scope 2: Ingress B to Egress A
Service 1.a
Service 2
PHB-EF
PHB-AF
Delay value
IPDV value
Packet loss ratio
Availability
other
Table 2: Service Level values for Scope 2.
Scope: Pipe VPN between A and B
Service 1.a
Delay value
IPDV value
Packet loss ratio
Availability
other
Usage 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., VPN
Hose and Pipe) in which much ingress and egress points are involved).
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 166 of 172
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-model04.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, June
2000
[FUJITA00]
N. Fujita, “Traffic Engineering Extensions to OSPF Summary LSA”, draft-fujita-ospfte-summary-00.txt, work in progress, March 2000.
[JACQ]
C. Jacquenet, “Providing Quality of Service Indication by the BGP-4 Protocol: the
QOS_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 IETF
draft http://www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-05.txt
[IS-DS-2]
Integrated Service Mappings for Differentiated Services Networks. Networks - IETF
IETF 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-ospftraffic-01.txt, work in progress, October 1999.
[NUSSBACHER99]
H. Nussbacher et al., “Global BGP Community Values”, draft-nussbacherglobal-community-values-v1-00.txt, work in progress, November 1999.
[OMP99]
C. Villamizar, “OSPF Optimized Multipath (OSPF-OMP)”, draft-ietf-ospf-omp-03preview.ps, work in progress, April 1999.
[PHBSPEC]
"Domain Per Hop Behavior Specification", draft-ronc-domain-phb-set-specification00.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 Aggregation
Strategy. 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 Gateway
Protocol (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.
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 167 of 172
[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 IPv6
Headers", K.Nichols, S. Blake, F. Baker, D. Black, www.ietf.org/rfc/rfc2474.txt
[RFC-2475]
"An Architecture for Differentiated Services",
S. Blake,
M.Carlson,E.Davies,Z.Wang,W.Weiss, www.ietf.org/rfc/rfc2475.txt
D.
Black,
[RFC-2519]
A Framework for Inter-Domain Route Aggregation. E. Chen, J. Stewart. February
1999.
[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
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.
PHB",
V.Jacobson,
K.Nichols,
K.Poduri,
[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 for
Traffic 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
ftp://ftp.ee.lbl.gov/parpers/dsarch.pdf, 1997
Architecture
for
the
Internet",
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 168 of 172
10 ACRONYMS AND ABBREVIATIONS
AAA
AC
ADSL
AF
AFG
API
ARP
ARPANET
AS
ATM
ATMARP
AVP
BA
BAN
BB
BCIT
BD
BE
BGP
BRI
CAC
CAR
CBQ
CBR
CBWFQ
CIM
CL
CLI
CLIP
CMIP
CMIS
CO
COPS
CORBA
CoS
CPE
CPN
CPU
CR
CRC
CR-LDP
DBMS
DHCP
Authentication, Authorisation and Accounting (IETF WG)
Admission Control
Asymmetric Digital Subscriber Line
Assured Forwarding
Assured Forwarding Group
Application Programming Interface
Address Resolution Protocol
Advanced Research Projects Agency Network
Autonomous System
Asynchronous Transfer Mode
ATM ARP
Active Virtual Pipe
Behaviour-Aggregate
Boundary Access Node
Bandwidth Broker
British Columbia Institute of Technology
Bandwidth Distribution
Best Effort
Border Gateway Protocol
Basic Rate Interface
Connection Admission Control
Committed Access Rate
Class Based Queuing
Constant Bit Rate
Class-Based Weighted Fair Queuing
Common Information Model
Connectionless
Command Line Interface
Classical IP over ATM
Common Management Information Protocol
Common Management Information Service
Connection Oriented
Common Open Policy Service
Common Object Request Broker Architecture
Class of Service
Customer Premises Equipment
Customer Premises Network
Central Processing Unit
Constraint-Based Routing
Cyclic Redundancy Check
Constraint-Based Routing using LDP
Database Management System
Dynamic Host Configuration Protocol
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
DNS
DrSM
DRtM
DS
DSC
DSCP
DSR
DTD
E2E
eBGP
ECMP
ECN
EF
EGP
EIGRP
FB
FIB
FIFO
FM
FQ
FSM
FTP
GoS
GTS
GUI
HDLC
HTML
HTTP
iBGP
I-D
IETF
IGMP
IGP
IGRP
ISSLL
IP
IPPM
IPSec
IS
ISDN
ISP
L3
LAN
LANE
LDAP
LDP
Page 169 of 172
Domain Name System
Dynamic Resource Management
Dynamic Route Management
Differentiated Services
Differentiated Services Classifier
Differentiated Services Code Point
Differentiated Services Router (model)
Document Type Definition
End to End
Exterior Border Gateway Protocol
Equal Cost Multi-Path
Explicit Congestion Notification
Expedited Forwarding
Exterior Gateway Protocol
Enhanced Interior Gateway Routing Protocol
Functional Block
Forwarding Information Base
First In First Out
Functional Model
Fair Queuing
Finite State Machine
File Transfer Protocol
Grade of Service
Generic Traffic Shaping
Graphical User Interface
High-Level Data Link Control
Hypertext Markup Language
Hypertext Transfer Protocol
Interior Border Gateway Protocol
Internet Draft
Internet Engineering Task Force
Internet Group Management Protocol
Interior gateway protocol
Interior Gateway Routing Protocol
Integrated Services Support over different Link Layers (IETF WG)
Internet Protocol
IP Performance Metrics
IP Security Protocol
Integrated Services
Integrated Services Digital Network
Internet Service Provider
Layer 3 (IP)
Local Area Network
LAN Emulation
Lightweight Data Access Protocol
Label Distribution Protocol
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
LER
LSA
LSDB
LSP
LSR
MAC
MAN
MDT
MF
MIB
MPLS
MSC
MTU
NAT
NE
NFS
NIC
NM
NN
NP
NRM
NW
OAM
OMP
OO
ORB
OSPF
PCI
PDP
PDU
PE
PEP
PFQ
PHB
PIB
PPP
PQ
PS
PVC
QoS
RADIUS
RAR
RDBMS
RED
REQ
RFC
Page 170 of 172
Label Edge Router
Link State Advertisement
Link State Data Base
Label Switched Path
Label Switched Router
Media Access Control
Metropolitan Area Network
Mean Down Time (per year)
Multi-Field
Management Information Base
Multi-Protocol Label Switching
Message Sequence Chart
Maximum Transfer Unit
Network Address Translator
Network Element
Network File System
Network interface card
Network management
Network Node
Network Planning
Network Resource Monitoring
Network
Operations, Administration and Maintenance
Optimised Multi-Path
Object Oriented
Object Request Broker
Open Shortest Path First
Protocol Control Information
Policy Decision Point
Protocol Data Unit
Provider Edge
Policy Enforcement Point
Packet Fair Queuing
Per Hop Behaviour
Policy Information Base
Point-to-Point Protocol
Priority Queuing
Premium Service
Permanent Virtual Channel
Quality of Service
Remote Authentication Dial-In User Service
Resource allocation request
Relational database management system
Random Early Detection
Request
Request for Comments
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
RIB
RIO
RIP
RPC
RSVP
RT
SBM
SDH
SDL
SFQ
SLA
SLIP
SLS
SNA
SNMP
SoA
SONET
SPF
SQL
SSL
STM
SVC
TC
TCP
TE
TLV
TMN
ToS
TQ
TTL
TTR
UDP
UML
UNI
VBR
VC
VLAN
VLL
VoD
VoIP
VP
VPC
VPN
WAN
WFQ
WG
Page 171 of 172
Routing Information Base
Random Early Drop with In/Out bit
Routing Information Protocol
Remote Procedure Call
Resource Reservation Protocol
Real Time
Subnet Bandwidth Manager/Solaris Bandwidth Manager
Synchronous Digital Hierarchy
Specification and Description Language
Stochastic Fair Queuing
Service Level Agreement
Serial Line Internet Protocol
Service Level Specification
System Network Architecture
Simple Network Management Protocol
State of the Art
Synchronous Optical Network
Shortest Path First
Structured Query Language
Secure Sockets Layer
Synchronous Transfer Mode
Switched Virtual Channel
Traffic Conditioning
Transmission Control Protocol
Traffic Engineering
Type Length Value
Telecommunications Management Network
Type of Service
TEQUILA
Time to Live
Time to Repear
User Datagram Protocol
Unified Modelling Language
User Network Interface
Variable Bit Rate
Virtual Channel
Virtual LAN
Virtual Leased Line
Video on Demand
Voice over IP
Virtual Path
Virtual Path Connection
Virtual Private Network
Wide Area Network
Weighted Fair Queuing
Work Group
 TEQUILA Consortium - September 2000
D1.1: Functional Architecture Definition and Top Level Design
Page 172 of 172
WRED Weighted Random Early Detection
WP Work Package
XML eXtensible Mark-up Language
 TEQUILA Consortium - September 2000