* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download D1.1: Functional Architecture Definition and Top Level
Survey
Document related concepts
IEEE 802.1aq wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Computer network wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Airborne Networking wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Deep packet inspection wikipedia , lookup
Distributed firewall wikipedia , lookup
Transcript
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 (mU ,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