D1.1: Functional Architecture Definition and Top Level Design

Transcription

1 D1.1: Functional Architecture Definition and Top Level Design Page 1 of 172 Project Number: Project Title: IST TEQUILA 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: Contributors: Workpackage(s): Abstract: Keyword List: Danny Goderis 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 WP1 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. 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.

2 D1.1: Functional Architecture Definition and Top Level Design Page 2 of 172 Project Number: Project Title: IST TEQUILA Traffic Engineering for Quality of Service in the Internet, at Large Scale D1.1: Functional Architecture Definition and Top Level Design Editor: Contributors: Version: Danny Goderis 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 Final Version Date: 11 September 2000 Distribution: TEQUILA, CEC Copyright by the TEQUILA Consortium, September 2000 The TEQUILA Consortium consists of: Alcatel Co-ordinator Belgium Algosystems S.A. Principal Contractor Greece FT-R&D Principal Contractor France IMEC Principal Contractor Belgium NTUA Principal Contractor Greece Global Crossing (RACAL) Principal Contractor United Kingdom UCL Principal Contractor United Kingdom TERENA Assistant Contractor The Netherlands UniS Principal Contractor United Kingdom

3 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 The TEQUILA Functional Model extends the DiffServ architecture mainly in two dimensions.

4 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) traffic. Web browsing could be of the silver class while the is only tagged as bronze.

5 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:

6 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.

7 D1.1: Functional Architecture Definition and Top Level Design Page 7 of 172 Table of Contents 1 INTRODUCTION THE TEQUILA PROJECT ROLE OF WP1 AND THIS DELIVERABLE STRUCTURE OF THIS DOCUMENT REQUIREMENTS, ASSUMPTIONS AND DEFINITIONS OVERVIEW GENERIC DEFINITIONS AND REQUIREMENTS NETWORK ARCHITECTURAL ASSUMPTIONS The Customer Premises Network Architecture The Access Network Architecture The Core Network Architecture The Roaming Architecture GENERAL END TO END COS/QOS IN THE INTERNET Flows vs. MicroFlows CoS vs. QoS Applications CoS/QoS architectures Basic Traffic Management Blocks Policy framework INTRA-DOMAIN COS/QOS ASPECTS General TE Requirements Layer 3 TE requirements MPLS TE requirements Survivability Requirements Measurement Requirements Capacity Control and Management Requirements INTERDOMAIN QOS ASPECTS NON-TECHNICAL REQUIREMENTS THE TEQUILA FUNCTIONAL MODEL POLICY MANAGEMENT NETWORK PLANNING NETWORK DIMENSIONING TRAFFIC FORECAST SLS MANAGEMENT SLS Subscription Admission Control SLS Invocation Inter-domain SLS requestor USER & UPSTREAM ISP/AS S INTER-DOMAIN SLS REQUESTOR TRAFFIC CONDITIONING MONITORING DYNAMIC ROUTE MANAGEMENT DYNAMIC RESOURCE MANAGEMENT ROUTING PHB ENFORCEMENT OTHER ISP/AS EXAMPLE: BOOTSTRAPPING THE TEQUILA NETWORK Assumptions Zero Phase Bootstrapping Message Sequence Chart SERVICE LEVEL SPECIFICATIONS MOTIVATION AND FRAMEWORK SLS CONTENTS & SEMANTICS... 39

8 D1.1: Functional Architecture Definition and Top Level Design Page 8 of Scope Flow Identification Traffic Conformance Testing Marking and shaping services prior to Conformance Testing Excess Treatment Performance Parameters Service schedule Reliability EXAMPLES: SERVICE TYPES & CUSTOMER SERVICES Quantitative (QoS - Premium) services Qualitative (CoS Olympic) services...47 The Funnel Service Best Effort traffic Bi-directional Virtual Leased Line Hose Virtual Private Networks SLS HANDLING FUNCTIONAL SCENARIOS Introduction on Traffic Forecast & Prediction SLS-Management, Traffic Forecast & Dimensioning Inter-Domain SLS negotiation SLS-subscription & -Invocation inter-working SLS Subscription handling Admission Control - SLS Invocation handling Examples INTEGRATED SERVICES SUPPORT IntServ over DiffServ : General architecture IntServ & the Tequila Functional Model The Exterior RSVP Gateway Model Native IntServ support QoS Mapping On DiffServ PHBs...79 SLS MANAGEMENT FUNCTIONAL BLOCK DECOMPOSITION Description of Functions Interface semantics and parameters TRAFFIC ENGINEERING INTRA-DOMAIN TRAFFIC ENGINEERING Objectives and Approaches Elementary TE Functions and the TEQUILA TE Functional Model MPLS-based Traffic Engineering Pure IP-based Traffic Engineering TRAFFIC ENGINEERING: FUNCTIONAL BLOCK DECOMPOSITION Network Dimensioning Dynamic Resource Management Dynamic Route Management MESSAGE SEQUENCE CHARTS MPLS-based TE Link Failure Handling INTER-DOMAIN TRAFFIC ENGINEERING Problem Description Current BGP and inter-domain TE TE Extensions of BGP Model 1: QOS parameters model Model 2: CoS capability model Single-path BGP versus Multi-path BGP Conclusion DATA-PLANE FUNCTIONS TRAFFIC CONDITIONING Overview Functional Elements Examples for the Tequila SLSs...141

9 D1.1: Functional Architecture Definition and Top Level Design Page 9 of Interface semantics and parameters PHB ENFORCEMENT Description of Functions Interface semantics and parameters POLICY FRAMEWORK DESCRIPTION OF FUNCTIONS Policy Management Tool Policy Storing Service Policy Consumer INTERFACE SEMANTICS AND PARAMETERS FINITE STATE MACHINES The Policy Management Tool FSM The Policy Storing Service FSM The Policy Consumer FSM MONITORING FRAMEWORK INTRODUCTION MESSAGE SEQUENCE CHART FUNCTIONAL BLOCK DECOMPOSITION Architecture Functions Interfaces Finite State Machine Algorithm and Protocol Problem Description SLS MONITORING Introduction Service Subscription SLS Monitoring Framework Functional Block Decomposition of SLS Monitoring REFERENCES ACRONYMS AND ABBREVIATIONS

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

11 D1.1: Functional Architecture Definition and Top Level Design Page 11 of 172 Figure 56 Policy Management Functional Block Decomposition Figure 57: Interaction of the PolicyManagement Functional Block with others Figure 58: The Policy Management Tool FSM Figure 59: The Policy Storing Service FSM Figure 60: The Policy Consumer FSM Figure 61: Monitoring feedback MSC Figure 62: Monitoring Architecture Figure 63: Node Monitoring and Ingress/Egress Monitoring Figure 64: SLS Monitoring Components and Sequence of Actions

12 D1.1: Functional Architecture Definition and Top Level Design Page 12 of 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.

13 D1.1: Functional Architecture Definition and Top Level Design Page 13 of 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.

14 D1.1: Functional Architecture Definition and Top Level Design Page 14 of 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.

15 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.

16 D1.1: Functional Architecture Definition and Top Level Design Page 16 of 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 Enterprise + + Residential Internet Service Provider (ISP) Internet Service Provider (ISP) SOHO Corporate / Business User / ISP Corporate / Business User / ISP + L3 Router Subnetwork Layer Connection Host (Client /Server) Network Access Server/ Customer Aggregation Router Figure 1: The Internet Architecture

17 D1.1: Functional Architecture Definition and Top Level Design Page 17 of 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) 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 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 SYSTEM TEQUILA edge Router AS Core Router AS Border Router Autonomous System Autonomous System Autonomous System Client Access Client Access Figure 2: TEQUILA network architecture

18 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 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 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 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.

19 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 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 CoS/QoS architectures 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 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.

20 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.