Network Services and Applications. MAP-TELE 2007/08 José Ruela

Transcription

1 Network Services and Applications MAP-TELE 2007/08 José Ruela

2 Service Integration, QoS Applications and Services

3 Service Integration

4 Service separation vs. service integration In the past communication networks were planned and optimized for specific services (e.g., voice, data, radio and TV broadcasting), according to their particular characteristics and requirements These networks were created and evolved independently and used different technologies and transmission media Service separation meant the need to provide separate access to the various networks The adoption of different and usually incompatible interfaces and protocols seriously compromised the possibility of interworking Separation did not prevent, in some cases, sharing of a common transmission infrastructure, by means of multiplexing techniques This situation had economic and operational disadvantages for network operators and service providers and imposed constraints to equipment manufacturers and end-users

5 Service integration The concept of service integration may be described in a rather simplistic way by the possibility of carrying traffic of different services on the same network Sharing of a transmission infrastructure by flows of different services is certainly a necessary but not sufficient condition for full service integration Service integration means that traffic flows of different services must be carried in a coherent and logical unified way (same architecture), instead of segregation per service (physical or logical independent networks) The network must ensure differentiated treatment to traffic flows, according to the characteristics and specific requirements of each service and taking into account the need for global resource optimization Service integration has to be considered in various complementary aspects and its feasibility has to be analysed in technological and economic terms

6 Enabling technologies The exploitation of service integration became possible with the advances in digital and optical technologies Digital technology Allows the integration of multiplexing and switching operation in the same equipment (convergence of transmission and switching technologies) Allows a common way to represent and transport information (digital format) independently of its content (service convergence) Allows the exploitation of new architectures and functionality in network and terminal equipment, which was made possible with the continuous increase in memory and processing capacity Use of digital signal processing techniques (e.g., for compression) Reduction of processing time (e.g., fast switching in hardware) Development of multimedia architectures and applications Optical technology Allows the deployment of highly reliable transmission systems with very high capacity (high bandwidth-distance product)

7 Integrated service networks ISDN and BISDN The exploitation of the concept and principles of service integration in public networks may be exemplified with two solutions standardized by ITU-T ISDN (Integrated Services Digital Network) was an evolution of the digital telephone network (IDN Integrated Digital Network) and only supported the so-called narrowband services (with rates up to 2 Mbit/s) BISDN(Broadband Integrated Services Digital Network) was aimed at extending the ISDN concepts to support all types of user and services (narrowband and broadband) ITU-T specified ATM (Asynchronous Transfer Mode) as the target mode for the deployment of BISDN

8 Service integration broadband networks and QoS In practical terms, service integration cannot be dissociated today from broadband networks, but is not restricted to public networks nor has to be necessarily realized according to the principles of BISDN / ATM Service integration in LANs is now feasible with the widespread availability of high capacity LAN switches (up to 10 Gbit/s interfaces) and new architectural solutions (e.g., multilayer LAN switches, Virtual LANs, etc.) Service integration in IP networks is possible with the availability of high performance routers (Gigabit routers), the adoption of new QoS models and mechanisms and with the exploitation of architectures that integrate routing and switching (e.g., MPLS) Integration of services cannot be dissociated from Quality of Service (QoS), that is, services must be provided with different levels of QoS assurance (e.g., delay, throughput, losses, etc.), which means that their flows must receive a differentiated treatment from the network

9 Brodband networks and services Today it is possible to provide both in LANs and WANs transmission and switching capacity in the order of tens (or hundreds) of Gbit/s The terms Broadband Networks, High Speed Networks or Gigabit Networks are normally used with a similar meaning Technological differences between LANs and WANs tend to become blurred and the same technology may be used across different geographic spans (e.g., ATM, Ethernet) The separation between narrowband and broadband services was traditionally set at 2 Mbit/s (as in ISDN and BISDN) This separation is somewhat artificial and was related with the ISDN limitations and the coding techniques used at that time The evolution of compression techniques has allowed to drastically reduce the bit rate of many services an example is video distribution with TV quality, with bit rates of the order of 150 Mbit/s (or higher), for the uncompressed signal, down to values of the order of 2 Mbit/s (or even less)

10 Feasibility of broadband networks The technological feasibility of broadband networks is related with The increase of the capacity of transmission systems (e.g., long-haul optical systems) The increase of the capacity of switching systems, especially the possibility of dynamic switching at high speed and with low latency (e.g., ATM switching) The increase in memory capacity and processing speed and the exploitation of digital signal processing techniques allow supporting a variety of services in different types of user terminals, in particular Real-time services (audio, video), at low to moderate rates using compression techniques Multimedia services, which may require high bandwidth and tight synchronization between the different media The representation of all types of information in a digital format allows the convergence and thus the integration of services

11 Feasibility of broadband networks The evolution of digital techniques contributed to parallel advances in broadband networks, terminal equipment and applications and to their convergence Applications with critical requirements as far as bandwidth or delay benefit from the high capacity provided by broadband networks Broadband networks are justified from an economic point of view by the traffic volume they can handle, which fosters new services and applications with very demanding requirements Multimedia applications generate large traffic volumes and thus consume very high bandwidth Real-time applications need critical response time and tight control of delay, which requires timely bandwidth guarantees The ever increasing number of users and bandwidth consuming applications contribute to the exponential increase of the traffic volume to be carried in broadband networks

12 Integration levels Service integration has to be considered at various levels Network access The access interface may be shared by a number of terminals or by different services on the same or different terminals Even when the access interface is shared, services may be supported by different networks or accessed using different procedures (no fully integration) Transport (multiplexing and switching) A transmission infrastructure may be shared by means of multiplexing techniques, while keeping logical separate networks (e.g., no integration at the switching level) Integration at the switching level means that all traffic is handled by the same switching platform (e.g., ATM) Service access Integration at this level requires the adoption of uniform signalling procedures to access different services establishing logical access to the service, negotiation of facilities, resource reservation, integration of different media on an application or service, etc.

13 Evolution from IDN to BISDN IDN (Integrated Digital Network) Integration at the transmission level (synchronous time division multiplexing) Integration of digital transmission and switching (circuit switching only) ISDN (Integrated Services Digital Network) Integration at the access level (e.g., 2B+D, 30B+D interfaces) Uniform signalling procedures (for access to native resources and services) BISDN (Broadband Integrated Services Digital Network) Integration at the switching level (ATM) Extension of ISDN signalling procedures Traffic control mechanisms and QoS support

14 Broadband ISDN and ATM ISDN had serious technological and architectural limitations that did not allow full integration of services As an evolution of the digital telephone network (IDN), it natively supported circuit mode communications (over 64 or n * 64 kbit/s channels) Native support of packet or frame mode communications required specific functional components (Packet and Frame Handlers, respectively) and only a limited degree of integration was possible (overlay model) Fully integration in a single network of narrowband and broadband services, with very different characteristics and requirements, raised the need for a totally new infrastructure Recognizing this fact, ITU-T started by defining the architectural principles and a transfer mode (multiplexing and switching) adequate to fulfil these goals and initiated a standardization process aimed at the deployment of the so-called Broadband Integrated Services Digital Network (BISDN) ITU-T selected as the target transfer mode for BISDN a kind of connection oriented, fast packet switching technique based on small and fixed size packets (cells) and called it ATM (Asynchronous Transfer Mode) The main reasons behind the choice of ATM were service independence (a common platform for all types of services), switching speed (low latency), speed and distance independence (scalability), efficient sharing of resources and flexibility for supporting differentiated levels of QoS

15 ATM and IP evolution The BSIDN concept, as envisaged by ITU-T ( ATM to the desktop ), did not become a reality However, the ATM technology that was developed with BISDN in mind constitutes today the basic infrastructure of many telecom operators In this context, ATM mainly provides layer 2 services The core of many ISP networks evolved from a high capacity and low latency ATM infrastructure aimed at interconnecting IP routers on the edges The solution initially adopted CLIP (Classical IP and ARP over ATM) is based on an overlay model and has serious limitations The limitation of overlay models are overcome by architectures that integrate layer 2 switching techniques (based on labels) with layer 3 routing MPLS (Multiprotocol Label Switching), defined by IETF, is the best known example MPLS is an interesting solution for carrying IP traffic over different layer 2 technologies (ATM, LAN, PPP) On the other hand, architectural enhancements of high speed and low latency IP routers (Gigabit routers) make it possible to think of an evolution of IP networks along a direction different from ATM (label based, fast switching of small fixed size packets) or MPLS

16 ATM

17 ATM main attributes Asynchronous Transfer Mode (ATM), as specified by ITU-T, is a connection oriented, fast packet switching technique The transmission and switching unit is a short, fixed size packet called cell Cells are carried on switched or permanent Virtual Circuits The switching process is simplified, since complex error and flow control mechanisms are not implemented in the network nodes An ATM cell has a length of 53 bytes Header: 5 bytes, Payload: 48 bytes Each cells carries on its header a Virtual Path and a Virtual Channel Identifier (VPI / VCI) Virtual Paths aggregate Virtual Channels and may be used for Traffic Engineering purposes The ATM architecture includes 3 layers Physical, ATM and AAL (ATM Adaptation Layer) The ATM Forum extended the ITU-T specifications, in particular to foster its use in LANs (e.g., LAN Emulation, Multiprotocol over ATM), and also specified a QoS architecture described in the document ATM Forum Traffic Management (AF-TM )

18 ATM architecture

19 ATM cell format

20 ATM multiplexing and switching b c a c 1 Switch 1 2 k n n m k y c z y M N g h g t t Switch Control Input Output Port VCI Port VCI header 1 a b c 2 1 N n n g payload a, b, c,.. Virtual Circuit Identifier (VCI) M y z c 1 N 2 k h m Forwarding table

21 ATM VPI switching

22 ATM VPI and VCI switching

23 ATM Virtual Paths VPI=9 VCI=3, 4 VPI=7 VCI=1, 2, 3 VP switch VPI=5 VCI=1, 2, 3 VP switch VP in VPI=8 VCI=1, 2, 3 VP out 5 8 VP out VP in VPI=6 VCI=3, 4 VP in VP out 6 3 VP switch VPI=3 VCI=3, 4

24 ATM sharing of resources Flows of ATM cells carried on different Virtual Circuits have to compete for network resources It is inherent to the operation of ATM networks (packet oriented multiplexing and switching) that cells are allocated to a given VC in an irregular (asynchronous) way, thus not following a fixed, predefined pattern To arbitrate access to shared transmission resources (mainly to solve short term conflicts) ATM switches have to buffer cells and manage queues Multiplexing and switching of ATM cells give rise to variations in throughput and delay, which depend on the traffic patterns (constant or variable rate) submitted to the VCs, as well as on the availability of resources and the strategy for allocating resources to competing flows Since ATM networks were designed to support services with different characteristics and QoS requirements, they must include traffic control mechanisms that should allow different types of resource reservation and allocation strategies to competing flows, with exploitation of statistical multiplexing whenever possible

25 ATM Adaptation Layer The ATM Adaptation Layer (AAL) adds functionality to the services provided by the ATM layer in order to fulfil different requirements of higher layers Examples of functions that may have to be supported by AAL Packetisation (e.g., voice, audio, video samples) Segmentation / Reassembly SAR (e.g., data packets) Multiplexing of AAL flows over an ATM connection End-to-end error recovery Extraction of service clock (e.g., for circuit emulation) Removal of delay jitter (e.g., real-time services that require that the temporal relation between source and destination is preserved) The diversity of applications requires different AAL protocols, which are implemented end-to-end in ATM hosts or network elements (bridges, routers) that use ATM for communication (e.g., IP over ATM or ATM LAN Emulation) AAL is divided in two sub-layers CS Convergence Sublayer SAR Segmentation and Reassembly Sublayer

26 ATM and AAL structuring AAL-SAP AAL-SDU Convergence Sublayer (CS) Segmentation and Reassembly (SAR) sublayer CS-PDU CS-PDU payload header CS-PDU No SAP defined between CS and SAR SAR-PDU SAR-PDU header payload SAR-PDU CS-PDU trailer SAR-PDU trailer SAR CS AAL ATM-SAP ATM-SDU ATM layer Cell Cell information field ATM header (cell payload) ATM-PDU = Cell

27 AAL types The ATM Adaptation Layer (on top of ATM) provides different services to applications, based on a set of AAL types AAL1 constant bit rate services that require timing information (clock) provided by the AAL service (e.g., circuit emulation, voice, etc.) AAL2 services with real-time requirements that generate traffic with low and variable bit rates and which is made up of short packets (e.g., control applications) AAL3/4 data services, with capability to multiplex packet flows at cell level (interleaving of cells that carry information of different packets) AAL5 data services (e.g., Classical IP over ATM, LANE, MPOA) and real-time services that do not require clock extraction by the AAL service (e.g., MPEG2 Transport Streams) simpler and more efficient than AAL3/4, but multiplexing is only possible at packet level (AAL5 frame)

28 AAL3/4 CS-PDU and SAR-PDU Header 4 bytes CS-PDU payload bytes PAD 0-3 bytes Trailer 4 bytes CPI Btag BA size AL Etag Length Header 2 bytes SAR-PDU payload 44 bytes Trailer 2 bytes ST SN MID LI CRC

29 AAL3/4 CS-PDU Header 4 bytes CS-PDU payload bytes PAD 0-3 bytes Trailer 4 bytes CPI Btag BA size AL Etag Length CPI Common Part Indicator allows redefining the meaning of the header per connection (a zero value assigns to the other fields the meaning described next) Btag, Etag BA size AL Length Tags with the same value for each CS-PDU, which allow associating the header and the trailer of each packet (the value is increased for each packet) Buffer Allocation size maximum number of bytes required to buffer a packet Alignment all zeros byte to ensure that the trailer is four bytes long Number of data bytes sent, excluding PAD (less than or equal to BA size)

30 AAL3/4 SAR-PDU Header 2 bytes SAR-PDU payload 44 bytes Trailer 2 bytes ST SN MID LI CRC ST SN MID LI CRC Segment Type BOM 10 Beginning of Message COM 00 Continuation of Message EOM 01 End of Message SSM 11 Single Segment Message (combines BOM and EOM) Sequence Number sequential numbering of the segments (SAR-PDUs) of each packet Multiplexing Identification identifier common to all segments of the same packet; allows interleaving fragments of different packets on the same ATM connection Length Indication number of data bytes in the payload (may be less than 44 in SSM and EOM segments, thus requiring padding) Cyclic Redundancy Check code with single error correction capacity polynomial generator: x 10 + x 9 + x 5 +x 4 + x + 1

31 AAL3/4 Segmentation and Reassembly CS-PDU (n x 4 bytes) H T BOM H T COM H T COM H T Header 2 bytes COM Trailer 2 bytes H EOM PAD T PAD 0-40 bytes

32 AAL5 CS-PDU CS-PDU (n 48 bytes) payload bytes PAD 0-47 bytes T 8 bytes Ctrl 2 bytes LI 2 bytes CRC 4 bytes T PAD Trailer Padding Ctrl Control control functions LI Length Indicator payload length, excluding PAD CRC Cyclic Redundancy Check error detection Variable lenght, such that the total CS-PDU size is a multiple of 48 bytes Ctrl field includes: UUI User-to-User Information (1 byte) CPI Common Part Indicator (1 byte), for interpretation of the other trailer fields

33 AAL5 Segmentation and Reassembly Higher layers User data AAL 5 CS Convergence Sublayer SAR Segmentation and Reassembly Sublayer 1 to bytes n 48 bytes n 48 bytes CS-SDU CS-PDU SAR-SDU SAR-PDU AAL-SDU AAL-PDU ATM ATM cell 48 bytes 53 bytes Payload Header Trailer

34 ATM and IP The combination of ATM and IP found an application in the backbones of Internet Service Providers, which adopted a structure in two levels edge and core ATM is suitable for the network core, since it provides a high capacity switching infrastructure with low latency ATM allows building any desired logical topology of Virtual Circuits to interconnect IP routers in the periphery IP routers are situated in the network edge, where the most complex functions have to be performed Initially, the Classical IP over ATM (CLIP) architecture was adopted It is based on an overlay model (ATM is treated as any other layer two technology) The model has a number of limitations that justified the study of more advanced solutions (with a higher degree of integration), which ultimately led to MPLS (Multiprotocol Label Switching)

35 MPLS

36 MPLS Relevant RFCs RFC 2702 Requirements for Traffic Engineering Over MPLS RFC 3031 Multiprotocol Label Switching Architecture RFC 3032 MPLS Label Stack Encoding RFC 3036 LDP Specification RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 3212 Constraint-Based LSP Setup using LDP RFC 3270 MPLS Support of Differentiated Services RFC 3564 Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering

37 MPLS principles MPLS is a forwarding mechanism that combines fast and scalable layer two label switching / swapping techniques with conventional layer three routing mechanisms MPLS overcomes the limitations of overlay models (such as CLIP) MPLS nodes share topological information and run the same protocols over a single physical and logical topology MPLS separates the Control and Data Transport functions Control functions are based on routing and signalling protocols Data forwarding is based on label switching techniques MPLS nodes keep an association between layer three and layer two information (routing and forwarding tables), that is, the association between labels and routes (label binding)

38 CLIP vs. MPLS topologies CLIP MPLS Physical Topology Physical and Logical Topology Logical Topology

39 Architecture Routing and Signaling Protocols Control Routing Table Forwarding Table Forwarding Packet in Label Processing and Swapping Packet out

40 Concepts Label Fixed short length identifier (or tag), defined in a space of contiguous values, with local significance, used to identify packet flows Forwarding Equivalence Class (FEC) A group of layer three packets that are forwarded by the network in a similar way, that is, over the same path and receiving the same node forwarding treatment Packets associated with a FEC carry the same label Label Switched Path (LSP) A path created by the concatenation (ordered set) of labels Packets with the same label travel over the same LSP Label Switching Router (LSR) Any node of an MPLS domain Label Edge Router (LER) An LSR at the edge (ingress / egress) of an MPLS domain Ingress LERs are more complex than internal (core) nodes

41 Operation Labels are assigned to packets at the ingress of an MPLS domain, based on the concept of Forwarding Equivalence Class (FEC) Different criteria may be used to define a FEC (e.g., destination address prefix, Class of Service, multicast group, VPN, application flow, etc.) Throughout the MPLS domain forwarding decisions are exclusively based on the labels attached to packets, without processing the original packet header Packets are forced into Label Switched Paths (LSP) The ingress LER classifies an incoming packet, assigns it to a FEC and then appends the corresponding label to the packet Internal (core) LSRs forward the packet based on the incoming label and perform label swapping (outgoing label used in the next hop) The egress LER removes the label

42 Label swapping LER LSR LSR LER IP #L1 IP #L2 IP #L3 IP IP IP Forwarding LABEL SWITCHING IP Forwarding

43 Ingress node Routing Packets/Traffic Engineering Parameters Input Packets Control Plane Next Hop Label Forwarding Entry FEC to NHLFE Map(FTN) FEC Packet Classification IP Header IP payload Next Hop + Port Queuing and Schedule rules Label Push MPLS Label Output Queue IP Header IP payload User Plane Output Packets

44 Core node Control Plane Routing Packets/Traffic Engineering Parameters Next Hop Label Forwarding Entry Incoming Label Map Next Hop + Port Queuing and Schedule rules Output Queue Output Packets MPLS Label IP Header IP payload Label Swap MPLS Label IP Header IP payload Input Packets User Plane

45 Egress node Control Plane Routing Packets/Traffic Engineering Parameters Next Hop Label Forwarding Entry Incoming Label Map Next Hop + Port Queuing and Schedule rules Output Queue Output Packets MPLS Label IP Header IP payload Label Pop IP Header IP payload Input Packets User Plane

46 LSP creation Path discovery and selection Hop-by-hop routing (topology based) Explicit routing Constraint-based routing Creation of labels Data driven (flow based) Control driven (topology or policy based) more scalable Label binding association of labels to FECs (along an LSP) Distribution of label binding information between LSRs Label Distribution Protocol

47 Routing and forwarding tables Intf Label Dest Intf Label In In Out Out Intf Label Dest Intf In In Out Intf Dest Intf Label In Out Out Dest Out IP Dest Out IP Label 0.40 Dest Out IP Label IP

48 Label distribution Routing Table: Addr-prefix Next Hop /8 LSR2 Routing Table: Addr-prefix Next Hop /8 LSR3 LSR1 LSR2 LSR3 IP Packet Forwarding Table: Label-In FEC Label-Out XX /8 17 For /8 use label 17 Forwarding Table: Label-In FEC Label-Out /8 XX Label distribution is initiated by the downstream node (relatively to the flow direction) 1 LSR2 discovers a next hop for a given FEC, creates a label and associates it to the FEC 2 LSR2 sends the association label / FEC to LSR1 (upstream node) 3 LSR1 inserts the label value (associated to the FEC) into its forwarding table

49 Label stack A labelled packet can carry a number of labels organised in a last-in, first-out manner (label stack) A label stack is represented by a sequence of label stack entries Label swapping is based on the current top level of the stack Adding or removing a label is done by PUSH and POP operations Stacked labels allow hierarchical routing MPLS defines a way of encoding label stack entries Any layer two technology may be used with MPLS In technologies that do not support labels (e.g., PPP or LANs), a MPLS header is inserted between layer 2 and layer 3 headers (shim header) The MPLS header carries one or more label stack entries In technologies that natively support labels (e.g., ATM or Frame Relay), the top label is carried in the layer two header (e.g., ATM VPI/VCI) In ATM, additional labels are carried in a shim header in an AAL5 frame

50 Label encoding Label Exp S TTL Layer 2 Header MPLS Header Layer 3 Header User Data Label Exp S TTL Label value (20 bits) Experimental use (3 bits) Bottom of Stack (1 bit) Time To Live (8 bits)

51 MPLS-TE and QoS routing It is usually recognised that today the main value of MPLS lies in its Traffic Engineering properties (associated with explicit routing) In MPLS two methods for route selection (and establishment of corresponding Label Switched Paths) have been specified The default is a topology-based method that allows the discovery of shortest-path routes based on conventional hop-by-hop routing Routes that meet TE goals can be explicitly defined and established (by configuration or dynamically) and resources may be provisioned along these routes, according to predicted traffic requirements MPLS does not rule out the possibility of route discovery subject to constraints, such as link characteristics (bandwidth or delay), hop count, policies or QoS parameters This is covered in the global scope of Internet Traffic Engineering and the needed extensions to conventional routing protocols

52 Quality of Service

53 QoS concept From a user point of view Quality of Service (QoS) is related to the level of satisfaction experienced by the user of an application or service delivered through a network and depends on various factors The user s subjective / perceptual evaluation The user s expectations (may be related with cost, type of terminal, etc.) The terminal capabilities in handling media flows The behaviour / performance of intervening networks From a network point of view, QoS characterizes the ability of giving differentiated treatment to traffic flows or classes with different characteristics and requirements and provide them with different levels of delivery assurance (bandwidth, delay, loss) in a consistent and predictable way It must be possible to measure and quantify in an objective way the behaviour of a network by means of a small set of performance (QoS) parameters Overall, QoS is an end-to-end problem

54 QoS principles A network supports Quality of Service (QoS) when it implements a set of mechanisms that allow fulfilling different traffic and service requirements placed by network elements (e.g., a host, a router or an application) The provision of QoS requires the cooperation of various protocol layers and network elements in the end-to-end chain The QoS requirements of users and applications must be mapped into values of network service attributes The attributes of a network service may be described by a set of performance (QoS) parameters, which must be observable, measurable and controllable Networks and users must negotiate contracts, which are described by means of traffic and QoS parameters, and allow setting levels of QoS assurance, differentiated by service type

55 Network QoS guarantees Absolute vs. Relative Guarantees for a flow or traffic class may be expressed in an absolute way (independent of other flows / classes) or in relative terms (e.g., a flow / class receives better service than other flows / classes as far as one or more QoS parameters) Quantitative vs. Qualitative The assurance is given in terms of numerical values (in a deterministic or statistical way) or imprecisely (e.g., low delay, low loss, better than best-effort, etc. loose guarantees) Deterministic vs. Statistical The quantitative assurance is given in terms of tight bounds (hard guarantees) or expressed in statistical terms (soft guarantees)

56 Packet Switching and QoS Packet switching networks were originally designed to support data services that did not require bandwidth or delay guarantees Focus was on statistical multiplexing for efficient resource sharing IP networks, which operate in a connectionless mode, did not even assure packet delivery (best-effort service) Packet switching techniques evolved to support service integration in the same network and to provide services with different levels of delivery assurance ATM (Asynchronous Transfer Mode) was developed with this goal in mind (ATM was selected by ITU-T as the target mode for BISDN) ATM networks natively support QoS, which is tightly coupled with their connection-oriented nature

57 Need for QoS in IP networks In spite of the best-effort service paradigm, IP networks started to be used to carry traffic generated by real-time or multimedia services In best-effort networks traffic is carried without any delivery assurance (typically over RTP/UDP/IP) The quality highly depends on the network traffic load and on the adaptation mechanisms (rate, loss, delay) implemented by end-systems The need to support QoS in IP networks thus became inevitable The volume of real-time and multimedia traffic is ever increasing IP is the only accepted universal protocol for internetworking The current trend towards all-ip communications will strengthen with the emergence of next generation networks (NGN)

58 QoS in IP networks challenges QoS provisioning in IP networks requires extensions to the best-effort service model and introduces many challenging problems Ever increasing traffic generated by highly demanding real-time and multimedia applications (VoIP, video-conference, audiovisual streaming), grid computing, etc. Convergence of fixed and mobile terminals Integration of wired and wireless infrastructures Limitations of wireless access networks limited resources (power, bandwidth), highly variable channel conditions, frequent handovers, etc. Need to combine packet level with lower level QoS mechanisms Dynamic and heterogeneous environment mobile users, ad-hoc and moving networks, highly variable traffic Need for scalable solutions Need to upgrade the large basis of installed IP routers Need for dynamic and automated QoS mechanisms (provisioning of network resources, service negotiation, resource reservation and allocation, etc.)

59 QoS in IP networks Multi-dimension problem Different protocol layers and planes (data, control, management) Different time scales short (packets, bursts), medium (flows / sessions), long (resource planning and provisioning cycles) Different scopes of control local vs. network wide actions Different types of systems / organizations and cooperation models, based on different roles and business / trust relationships Different granularity fine-grained (individual applications or single flows) vs. coarse-grained (classes of traffic or aggregated flows) Different mechanisms (building blocks) that need to be integrated Different paradigms centralized vs. distributed, host vs. network centric, sender vs. receiver initiated, open vs. closed loop control, etc. Different technologies that must interwork Different QoS architectures (models) proposed

60 QoS in IP networks A number of architectures, technologies and mechanisms have been devised to enhance the conventional best-effort IP service model Some solutions have already been deployed, but with different flavours and paradigms QoS mechanisms are not yet widely supported over-provisioning is still common in large IP backbones, due to the low cost of high capacity optical light-paths, but this is not acceptable in wireless access networks (scarce and expensive resources) In general QoS mechanisms are still statically configured (neither flexible nor efficient for highly dynamic environments) In this context, it is relevant to discuss QoS supporting mechanisms (building blocks): policing / shaping, scheduling, queue management, admission control, congestion control, traffic engineering, etc. IP QoS models (IntServ, DiffServ)

61 QoS components Different functions need to be performed by network devices and end-systems and may be organised in some general components Network resources must be managed according to some optimisation goals Resource Management Network services must be provided according to some contract negotiated with the users (customers) Service Management The network operation must be governed by some well defined rules that must be enforced Policy Management Traffic generated by users must be controlled Traffic Management To verify and enforce conformance with the contracted services and applicable policies To use resources as efficiently as possible To meet the negotiated QoS goals These functions are implemented by different mechanisms that may be seen as building blocks of a QoS architecture

62 QoS building blocks Data plane (traffic flows / packets) Shaping and Policing Classification and Marking Queuing and Scheduling (service discipline) Congestion control and Queue management Control plane QoS mapping Admission control (QoS) routing Resource reservation and allocation Management plane Resource provisioning Policy management

63 QoS building blocks J. Soldatos et al, On the Building Blocks of Quality of Service in Heterogeneous IP Networks, IEEE Communications Surveys and Tutorials, First Quarter 2005, pp

64 QoS framework Hui-Lan Lu et al, An Architectural Framework for Support of Quality of Service in Packet Networks, IEEE Communications Magazine, June 2003, pp

65 Example of a functional architecture Tequila functional architecture P. Trimintzios et al, A management and control architecture for providing IP differentiated services in MPLS-based networks, IEEE Communications Magazine, May 2001, pp

66 Signalling and provisioning Routers and switches must be configured with information to control their forwarding actions (e.g., classification rules, forwarding / routing tables, scheduling and queue management parameters, etc.) Time scales of (re)configuration actions may be quite different and performed by different means Long-term reconfiguration is usually referred to as Provisioning Short-term reconfiguration may be required as a result of user requests and is achieved by means of Signalling procedures New signalling protocols have been (are being) developed to carry additional QoS information (for resource reservation, QoS routing, etc.) The nature of current and future Internet applications (and of the traffic they generate) introduces the requirement for highly dynamic contract negotiations between customers and providers (and between providers) and for dynamic and automated configuration of network resources

67 Service Level Agreements At present QoS based services are offered in terms of bilateral Service Level Agreements (SLA) An SLA is a contract established between a client (customer) and a service provider that specifies the characteristics of the service received by the client and the responsibilities of the parties In SLAs established between two network providers, one of the parties plays the role of customer and the other of provider (and the roles may be reversed in distinct SLAs) The technical aspects of an SLA are described in a Service Level Specification (SLS) The concept of SLA/SLS was introduced in the DiffServ framework but its scope is rather general

68 SLS information model Automated and dynamic negotiation requires standardization of SLSs and negotiation protocols independent of the network and QoS model The SLS information model must include generic network level parameters independent of application level requirements and network QoS models (IntServ, DiffServ, 3GPP, etc.) Application level parameters should be mapped into network level parameters prior to SLS negotiation Generic SLS QoS parameters (SLS information model) must be mapped into network specific QoS parameters (network QoS model) Traffic and QoS parameters negotiated in the SLS are used to configure network specific QoS mechanisms (policing, admission control, packet scheduling, etc.) that depend on the network QoS model and supporting technologies

69 Example of SLS template Traffic Scope Source / Destination / Service Id Geographic Scope Ingress / Egress Id Temporal Scope Start / end time, periodicity Traffic Descriptor Peak / average source rate, maximum burst size QoS guarantees Throughput, average loss ratio, maximum / average end-to-end delay, maximum / average end-to-end jitter

70 Traffic characterization goals The characterization of traffic generated by a source, by means of a limited set of traffic parameters (traffic descriptor), is essential for the negotiation of a contract with the network and plays an important role in a number of functions that have to be supported by the network and the traffic sources In the first place, traffic description is the basis for the negotiation The network prescribes a set of parameters and a source selects the values that best describe its traffic characteristics The network decides whether the contract can be accepted (admission control), based on an estimate of the resources required to meet the performance goals In case the contract cab be accepted, the network must reserve (commit) the required resources Network nodes must implement scheduling and buffer management disciplines to give a differentiated treatment to traffic flows, according to the contracts A traffic source must shape traffic according to the contract The agreed values are used as input to a traffic regulator (shaper) at the source so that traffic sent to the network conforms with the contract (traffic shaping), thus increasing the probability that the network will handle it as expected The network must monitor traffic to verify its conformity with the contract The same values are used as inputs to a policer at the network, which will accept compliant packets and will drop (or delay) non compliant ones (traffic policing), in order to avoid congestion or that misbehaving sources may degrade the QoS provided to well-behaved ones

71 Traffic descriptors Traffic descriptors must have a set of desirable properties They must be representative, that is, they must describe the flow as accurately as possible, so that the resources reserved by the network match the requirements They must be easily verifiable (e.g., for shaping or policing) They must be usable, that is, the source must be able to describe traffic and the network to perform admission control in an easy and fast way They must be preservable the network must be able to preserve traffic characteristics along the path (to match the reserved resources) or to recalculate the needed resources if it modifies the traffic characteristics Different traffic descriptors have been proposed for use in real networks (such as ATM and IP) Three basic parameters are usually considered peak rate, average rate and maximum burst size and can be combined in different ways to form a traffic descriptor

72 Peak rate Informally, the peak rate is the maximum instantaneous rate of a connection (or flow) In networks with fixed size packets the peak rate is defined as the inverse of the minimum inter-packet spacing T (e.g., peak cell rate in ATM) In networks with variable size packets, the peak rate must be specified for a time window over which it should be measured, that is, the peak rate is the highest rate over all intervals of the specified duration The peak rate is very sensitive to even small deviations in traffic patterns, which is easily exemplified in the case of ATM (to be discussed)

73 Average rate To define the average rate of a source it is necessary to specify the period of time for the averaging process For a given time period, the average rate is the amount of data (bits) generated by the source divided by the duration of the interval An average rate mechanism requires two parameters a time window and the number of bits that can be sent in the window and two common used mechanisms are the jumping window and the moving (sliding) window In a jumping window, the averaging process is performed over consecutive (non overlapping) time intervals (windows) and the process is reinitialized on each interval The average rate is very sensitive to the choice of the starting time (e.g., two back-to-back bursts would be possible, one at the end of a period and the other at the start of the next period) In a moving window, the averaging process is performed over all time intervals with a duration equal to the defined window and thus control is quite tight and independent of the starting time (e.g., Committed Information Rate in Frame Relay is defined in this way)

74 Maximum burst size In order to control the average rate of a flow in a meaningful way (from the point of view of resource allocation), the averaging period should not be too short (this would limit the peak rate) nor too long (e.g., of the order of the flow duration), since then control would be too loose (it would not be possible to control the duration of bursts) The long term average rate will always be bounded by the average rate controlled over shorter intervals (but the reverse is not true) One way of achieving a tighter control over the average rate is to control the duration (or size) of bursts that may be sent at the peak rate A linear bounded arrival process (LBAP) limits the number of transmitted bits in any interval t to r * t + b where r is the long term average to be controlled and b is related with the maximum burst size (MBS) Assuming that p is the peak rate, then MBS = b * p/(p - r) > b b = MBS (1 - r / p) These traffic parameters are usually regulated by a Leaky Bucket (p) and a Token Bucket (r, b)

75 LBAP bounds for a traffic flow (p, r, b) (bits) r * t + b r * t MBS b p * t t

76 Example of moving window Frame Relay In Frame Relay a user can negotiate a Committed Information Rate (CIR) and a Committed Burst Size (CBS) CIR is an average rate that the network guarantees under normal conditions CBS is the maximum amount of information that the network accepts from a user, under normal conditions, during a period T = CBS / CIR Frames are transmitted by the user at the link Access Rate (AR) and bursts are allowed up to CBS CIR (and CBS) cannot be exceeded on any window of duration T (moving window) In fact it is also possible to negotiate an Excess Burst Size (EBS) When the amount of information within any window T exceeds CBS, the corresponding frames are marked as eligible for discard provided that CBS + EBS is not exceeded (otherwise, non compliant frames are simply discarded)

77 Moving window control (CIR, CBS, T) The figure shows three compliant frames transmitted at the link Access Rate CBS and CIR are not exceeded during T = CBS / CIR Other patterns would be possible (e.g., three back-to-back frames) (bits) CBS AR CIR T t

78 Traffic Engineering / Resource Management Traffic Engineering (TE) functions aim at managing network resources so that the offered traffic is optimally mapped into the network topology (resource and performance optimization) Predicted traffic requirements must be supported in a cost-effective way Efficient use of resources is achieved by distributing traffic over selected paths to balance the load on the network links and to avoid congestion TE techniques have been mainly used to compute paths that accommodate highly predictable and slowly varying traffic patterns Route changes are only driven by long-term variations of traffic patterns New emerging scenarios are characterized by highly variable and unpredictable traffic patterns as well as frequent topology changes, in short time scales (e.g., real-time and multimedia traffic, mobile and multi-homed hosts, moving networks, etc.) TE will be necessary to establish and dynamically maintain the network configuration, in order to meet highly varying user demands, according to QoS dynamic information

79 Service Management Service Management (SM) functions handle service requests, trying to maximize incoming traffic, while respecting the commitments (QoS guarantees) on agreed SLAs/SLSs SM tries to avoid overloading beyond loads the network can sustain (to honour the established contracts), by means of admission control Subscription of a new SLA/SLS Dynamic invocation of a previously subscribed SLA/SLS TE and SM are tightly related SM sets traffic related objectives for TE traffic forecast is based on subscriptions established by SM Admission control is based on resource availability determined by TE policies

80 Resource provisioning cycle E. Mykoniati et al, Admission Control for Providing QoS in DiffServ IP Networks: The Tequila Approach, IEEE Communications Surveys and Tutorials, January 2003, pp

81 Service subscription Service subscription requires an SLA negotiation process, during which QoS policies are agreed The customer describes the service requirements by means of a traffic descriptor and target values for QoS parameters The provider may accept or refuse the conditions or propose alternative QoS guarantees for the traffic descriptor It may include a Traffic Conditioning Agreement (TCA) that specifies Packet classification rules and corresponding traffic profiles Conditioning rules to be applied to traffic flows selected by the classifier Explicitly indicated in the SLA Implicitly derived from service requirements or provisioning policies

82 Service invocation Once subscribed, the service may be invoked and conformance is checked against service profiles agreed during subscription The invocation may be implicit, in which case no signalling is required This is the case of a static SLA and the service may be immediately and permanently available after subscription or during pre-defined periods The invocation may be explicit and a QoS signalling / reservation protocol must be used to request the required QoS level This is the case of a dynamic SLA and is subject to Admission Control Admitted traffic in conformity with the stated traffic descriptor must be carried by the provider with the agreed QoS guarantees (delay, jitter, packet loss ratio, etc.) that characterize the QoS level to be provided