1. Protocols with QoS Support 29/9 - 2003 INF5070 – Media Storage and Distribution Systems:

2. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Overview Quality-of-Service Resource reservation Protocols:  IPv4  IPv6  Tenet  ATM  IntServ  RSVP  DiffServ  MPLS  …

3. Quality-of-Service

4. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Quality–of–Service (QoS) – I Many definitions, e.g.: “QoS represents the set of those quantitative and qualitative characteristics of a distributed multimedia system that are necessary to achieve the required functionality of an application” Vogel et. al.: “Distributed Multimedia and QoS: A Survey”, IEEE Multimedia 1995

5. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Quality–of–Service (QoS) – II Different semantics or classes of QoS:  determines reliability of offered service  utilization of resources max reserved A reserved B time resources unused available resources reserved C

6. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Quality–of–Service (QoS) – III Best effort QoS:  system tries its best to give a good performance  no QoS calculation (could be called no effort QoS) simple – do nothing  QoS may be violated  unreliable service Deterministic guaranteed QoS:  hard bounds  QoS calculation based on upper bounds (worst case)  premium better name!!?? QoS is satisfied even in the worst case  high reliability  over-reservation of resources  poor utilization and unnecessary service rejects  QoS values may be less than calculated hard upper bound

7. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Quality–of–Service (QoS) – IV Statistical guaranteed QoS:  QoS values are statistical expressions (served with some probability)  QoS calculation based on average (or some other statistic or stochastic value) resource capabilities can be statistically multiplexed  more granted requests  QoS may be temporarily violated  service not always 100 % reliable Predictive QoS:  weak bounds  QoS calculation based previous behavior of imposed workload resource capabilities can be statistically multiplexed  more granted requests possibly more exact workload description (if past and actual behavior matches)  QoS may be temporarily violated  service not 100 % reliable  QoS values may be less than calculated hard upper bound

8. Resource Reservation

9. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Resource Reservation – I Reservations is fundamental for reliable enforcement of QoS guarantees  per-resource data structure (information about all usage)  QoS calculations and resource scheduling may be done based on the resource usage pattern  reservation protocols negotiate desired QoS by transferring information about resource requirements and resource usage between the end-systems and the intermediate systems participating in the data transfer reservation operation o calculate necessary amount of resources based on the QoS specifications o reserve resources according to the calculation (or reject request)  resource scheduling enforce resource usage with respect to resource administration decisions

10. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Resource Reservation QoS reservation:  specification (parameter set): how to describe QoS e.g., frames-per-second, color depth,…, bandwidth, delay, jitter, error rate, … parameter mapping / translation  negotiation procedure: how to set up QoS peer-to-peer case – all components or resources must agree different types: o triangular: all components (server and network) allowed to change QoS o bilateral: only server allowed to change QoS o unilateral: “take is or leave it” from client  enforcement (reflection) in access mechanisms: how to ensure QoS e.g., scheduling

11. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Resource Management Phases user’s QoS requirements time Phase 1: Phase 2: Phase 3: admission test and calculation of QoS guarantees rejection or renegotiation resource reservationQoS guarantees to user negotiation data transmissionQoS enforcement by proper scheduling monitoring and adaptation “notification” renegotiation enforcement specification confirmation renegotiation stream terminationresource deallocation termination not necessary an own phase, some protocols start sending at once

12. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Reservation Directions Sender oriented:  sender (initiates reservation) must know target addresses (participants) in-scalable good security 1. reserve 2. reserve 3. reserve receiver sender data flow

13. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Reservation Directions Receiver oriented:  receiver (initiates reservation) needs advertisement before reservation must know “flow” addresses  sender need not to know receivers more scalable in-secure 1. reserve 2. reserve 3. reserve receiver sender data flow

14. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Reservation Directions Combination:  start sender oriented reservation  additional receivers join at routers (receiver based) receiver sender data flow reserve from nearest router 1. reserve 2. reserve 3. reserve

15. Routing

16. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Routing physical link network application transport

17. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Routing 216.239.51.101 129.42.16.99 80.91.34.111 129.240.148.31 66.77.74.20 209.73.164.90 192.67.198.54 209.189.226.17 193.99.144.71 81.93.162.20

18. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Routing 216.239.51.101 129.42.16.99 80.91.34.111 129.240.148.31 66.77.74.20 209.73.164.90 192.67.198.54 209.189.226.17 193.99.144.71 81.93.162.20 …-… 216.239.51.101-IF1 209.189.226.17-IF2 80.91.34.111-IF3 209.189.226.*-209.189.226.17 129.240.*-80.91.34.111 81.93.*-80.91.34.111 192.67.*-80.91.34.111 209.73.*-80.91.34.111 129.240.148.*-80.91.34.111 193.99.*-80.91.34.111 66.77.74.20-80.91.34.111 …-…

19. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Routing 216.239.51.101 129.42.16.99 80.91.34.111 129.240.148.31 66.77.74.20 209.73.164.90 192.67.198.54 209.189.226.17 193.99.144.71 81.93.162.20

20. Protocols

21. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Internet Protocol version 4 (IPv4) – I THE IP is THE network layer protocol within the Internet IPv4  defined by RFC 791 (1981) – STD 5  unreliable datagram service (neither flow nor error control)  no fixed routes flexibility for path selection reordering problems not suitable for time critical continuous media data but, source routing is optional o loose – specify some router IP addresses to be passed in order o strict – specify all routers to be passed in order  maximum 64 KB datagrams including headers segmentation for smaller subnets (e.g., 1500 B for standard Ethernet) reassembly in end-system’s IP-layer

22. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Internet Protocol version 4 (IPv4) – II 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ indicates the format of the internet header, i.e., version 4 length of the internet header in 32 bit words, and thus points to the beginning of the data (minimum value of 5) indication of the abstract parameters of the quality of service desired – somehow treat high precedence traffic as more important – tradeoff between low-delay, high-reliability, and high-throughput – NOT used, bits now reused datagram length (octets) including header and data - allows the length of 65,535 octets identifying value to aid assembly of fragments fragments allowed flag allowed and last fragment flag indicate where this fragment belongs in datagram checksum on the header only – TCP, UDP over payload. Since some header fields change(TTL), this is recomputed and verified at each point indicates used transport layer protocol disable a packet to circulate forever,decrease value by at least 1 in each node – discarded if 0 32-bit address fields. May be configured differently from small to large networks options may extend the header. If the options do not end on a 32-bit boundary, the remaining fields are padded in the padding field (0’s)

23. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems 128-bit address fields disable a packet to circulate forever, decrease value by at least 1 in each node – discarded if 0 length of payload in bytes. If zero, indicates that the payload length is carried in a Jumbo Payload option. Identifies the type of header immediately following the header – e.g., TCP, UDP, but also EXTENSION headers version of protocol, i.e., version 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Prio. | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Internet Protocol version 6 (IPv6) – I IPv6  defined by RFC 1883 (1995), but revised by RFC 2460 (1998)  simplified header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the 4-bit priority field has been replaced by an 8-bit traffic class field. To identify and distinguish between different classes or priorities label packets which requests special handling by the IPv6 routers, such as non-default quality of service or real-time

24. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Internet Protocol version 6 (IPv6) – II IPv6  enlarged address space (2 128 = 3.4 x 10 38 addresses)  simplified headers reduce packet processing time  “jumbograms” allows packets larger than 64 KB (using a extension header)  strict routing (source can fix route to destination using a routing extension header)  inclusion of security concepts and mobile end-systems  may specify only a geographical range for a multicast session  some support for QoS concepts – each packet header includes...... a 8-bit traffic class field – defined by DiffServ... a 20-bit flow label

25. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Internet Protocol version 6 (IPv6) – IV Flow labels  “a flow is a sequence of packets sent from the source to the destination for which the source desires special handling by the routers”  each flow must have same flow label, priority and addresses  flow = pseudo-connection before start or during transmission o set up flow between source and destination o route is cached – table entries in a router allows fast packet switching o routers can reserve resources during data transmission o routers can identify flows by a unique “flow label/address” combination o routers can treat packets according to the flow type  still experimental use BUT; IPv6 itself does not define mechanisms for QoS treatment – must use additional protocols BUT; IPv6 itself does not define mechanisms for QoS treatment – must use additional protocols

26. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems IP Multicast Limiting IP multicast geographically  IPv4 – interpretation of TTL header field is used (non-standardized MBONE use)  IPv6 – multicast address contains a 4-bit scope field  possible geographical limits machine LAN organization country (v4 only) continent (v4 only) global – no limit

27. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Tenet – I Late 80’s/early 90’s, Tenet group at Berkeley Aims for network support for real-time continuous media applications Real-time communication model Real-time channels: end-to-end connection with performance guarantees and traffic restrictions  associated with a set of nodes and links (a route) through which real- time packets pass  resource reservation in route nodes  admission control

28. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Tenet – II Traffic specification:  expressing peak and average load on the network  indication of the burstiness of the load  parameters: minimum packet inter-arrival time average packet inter-arrival time averaging interval maximum packet size Supported QoS parameters (by which users describe their requirements):  upper bound on end-to-end message delay  delay violation probability bound  buffer overflow probability bound  delay jitter bound (optional)  a throughput guarantee is obtained from the traffic specification

29. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Tenet – III Protocol suite: Real-time Channel Administration Protocol (RCAP)  performs channel setup  uses the traffic description and performance requirement to find a route and maps the global requirement onto local resources  performs admission control and reservations on the way Real-time Message Transport Protocol (RMTP)  intended for message based real-time transport Continuous Media Transport Protocol (CMTP)  offers a stream based interface and a time-driven mechanism for audio and video – may demand data from application Real-time Internet Protocol (RTIP)  replaces IP  schedules packets according to resource reservations made by RCAP application physical layer data link layer real-time internet protocol real-time message transport protocol continuous media transport protocol continuous media transport protocol real-time channel administration protocol

30. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Defined by ATM Forum and International Telecommunication Union (ITU) Targeted for all kinds of traffic within the same network (i.e., both continuous and discrete data types) A full suite of protocols:  physical layer – deals with voltages, bit timing and framing on the physical medium  ATM layer – defines the ATM cell structure  adaptation layer – analogous to the Internet transport layer supporting different services Today: “IP-over-ATM”  IP rules – TCP/IP is used in every end-system  ATM used as link-layer technology  however, ATM may forward data quickly  ATM may be used in the Internet backbone running under IP  uses AAL5 to transport IP datagrams over the ATM network Asynchronous Transfer Mode (ATM) – I ATM physical layer ATM layer ATM adaptation layer (AAL)

31. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Asynchronous Transfer Mode (ATM) – II Service classes  constant bit rate (CBR) (real-time, guaranteed constant rate)  variable bit rate (VBR) – real-time and non-real-time  available bit rate (ABR) (slightly better than best effort – a minimum guarantee, only class with congestion control)  unspecified bit rate (UBR) (best effort, no guarantees) Virtual channels (VC)  the ATM network sets up a VC between sender and receiver  a path consisting of a sequence of links  each link has a virtual circuit identifier (VCI) used for routing (included in the cell header)  ATM backbones usually use permanent VCs, i.e., saving VC setup and teardown Virtual paths

32. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Asynchronous Transfer Mode (ATM) – III The ATM standard specifies a number of QoS parameters  traffic generation by sender: cell rate (sustainable (SCR) / peak (PCR) / minimum (MCR)) maximum burst size (MBS) cell delay variation tolerance (CDVT)  service provided by network: cell transfer delay (CTD) – cell transit time from source to destination cell delay variation (CDV) – variance in transfer delays cell loss ratio (CLR) – fraction of cells lost or delivered too late cell error rate (CER) – fraction of cells with bit errors severly-errored cell block ratio (SECBR) – fraction of an N-cell block with M or more cells damaged cell misinsertion rate (CMR) – number of cells delivered to wrong destination cannot be negotiated – part of network QoS offer

33. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Asynchronous Transfer Mode (ATM) – VI Traffic contracts  the VC acts like a contract between customer and network for a service  consist of a connection traffic descriptor and a set of QoS parameters which traffic to be offered which service class compliance requirements  the QoS parameters are negotiated during the VC setup (can be specified either explicitly or implicitly)

34. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Asynchronous Transfer Mode (ATM) – V Different service categories require different parameters Traffic description Min loss guarantee (CLR) Delay/variance guarantee (CDV) Bandwidth guarantee Feedback control CBRPCR +++- rt-VBRPCR, SCR, MBS +++- nrt-VBRPCR, SCR, MBS +-+- ABRPCR, MCR +-++ UBRPCR ----

35. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Asynchronous Transfer Mode (ATM) – VI Application areas for ATM service categories (by ATM Forum) CBRrt-VBRnrt-VBRABRUBR critical data 2131n/s ISDN – video conference 3??n/s compressed audio 13221 video distribution 321n/s interactive multimedia 33221 3 – good 2 – fair 1 – not good, not applicable with advantage n/s – not suitable may be more useful now!!??

36. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Integrated Services (IntServ) – I Framework by IETF to provide individualized QoS guarantees to individual application sessions Goals:  efficient Internet support for applications which require service guarantees  fulfill demands of multipoint, real-time applications (like video conferences)  do not introduce new data transfer protocols In the Internet, it is based on IP (v4 or v6) and RSVP (described later) Two key features  reserved resources – the routers need to know what resources are available (both free and reserved)  call setup (admission call) – reserve resources on the whole path from source to destination

37. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Integrated Services (IntServ) – II Admission call:  traffic characterization and specification one must specify the traffic one will transmit on the network (Tspec) one must specify the requested QoS (Rspec – reservation specification)  signaling for setup send the Tspec and Rspec to all routers  per-element admission test each router checks whether the requests specified in the R/Tspecs can be fulfilled if YES, accept; reject otherwise 1. request: specify traffic (Tspec), guarantee (Rspec) 1 2 3 2. consider request against available resources 3. accept or reject receiver sender

38. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Integrated Services (IntServ) – III IntServ introduce two new services enhancing the Internet’s traditional best effort:  guaranteed service guaranteed bounds on delay and bandwidth for applications with real-time requirements  controlled-load service “a QoS closely to the QoS the same flow would receive from an unloaded network element” [RFC 2212], i.e., similar to best-effort in networks with limited load no quantified guarantees, but packets should arrive with “a very high percentage” for applications that can adapt to moderate losses, e.g., real-time multimedia applications

39. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Both service classes uses token bucket to police a packet flow:  packets need a token to be forwarded  each router has a b-sized bucket with tokens: if bucket is empty, one must wait  new tokens are generated at a rate r and added: if bucket is full (little traffic), the token is deleted  the token generation rate r serves to limit the long term average rate  the bucket size b serves to limit the maximum burst size Integrated Services (IntServ) – IV token wait queue bucket token generation

40. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Integrated Services (IntServ) – V Usual protocol structure: application data link IP UDP RSVP RTP

41. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Resource Reservation Protocol (RSVP) - I Defined by RFC 2205 (1997) A protocol to signal reservations of resources in the Internet  contains protocol elements for control  no support for data transfers (reservation signals only)  simplex protocol, i.e., makes reservations for unidirectional flows  receiver-oriented, i.e., the receiver initiates and maintains resource reservations  maintains a “soft” state – graceful changes to dynamic memberships and automatic adaptation to route changes (timeouts)  companion protocol to IP – supports both IPv4 and IPv6  transported as raw IP datagram with protocol number 46  filtering provides support for heterogeneous receivers and different reservation styles

42. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems RSVP will generally require raw network I/O  sends raw IP datagrams using protocol 46  operates on top of IP, i.e., takes the place of the transport protocol  does not perform traditional transport layer services – must add a transport protocol (UDP) Resource Reservation Protocol (RSVP) - II application data link IP UDP RSVP

43. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems same multicast group and port Sessions  a data flow with particular destination and transport protocol  defined by (destination address, protocol ID) IP address IP protocol ID  may carry multiple data flows Data flows are distinguished by  source IP address and source port (IPv4)  source IP address and flow label (IPv6) Transmission model: Resource Reservation Protocol (RSVP) - III

44. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Resource Reservation Protocol (RSVP) - IV Two fundamental messages:  PATH: sender sends a PATH message downstream following the data path sent using same source and destination addresses includes: o hop-addresses o sender template (describes data packet format) o sender Tspec (traffic characteristics generated by sender) o sender Adspec (advertisement information) o...  RESV: receiver sends a RESV message upstream using the path described in the PATH message sent to previous hop only includes: o flowspec: reservation requests, desired QoS (e.g., RFC 1363) o filterspec: reservation style o reverse data paths for the flow o... flow descriptor

45. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Creating and maintaining a reservation state:  the SOURCE multicasts data flows sends PATH messages with traffic characteristics (Tspec) describing flows  the RECEIVER joins multicast group receives the PATH message determines own QoS requirements based the PATH Tspec sends a RESV message with request and filters  the ROUTERS reserve according to incoming flowspecs downstream merge and forward the RESV messages to next node using largest flowspec  the reservations are maintained using “soft” states the reservation has an associated timer – a timeout removes the reservation periodically refreshed by PATH and RESV messages Resource Reservation Protocol (RSVP) - V

46. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Resource Reservation Protocol (RSVP) - VI 3 Mbps 5 Kbps 1 Mbps 10 Mbps 1 Mbps PATH RESV 5 Kbps reserved 5 Kbps RESV 1 Mbps reserved 1 Mbps RESV 1 Mbps reserved 1 Mbps merging RESV 10 Mbps reserved 10 Mbps merging RESV 10 Mbps reserved 10 Mbps RESV 3 Mbps reserved 3 Mbps RESV 3 Mbps reserved 3 Mbps RESV 1 Mbps reserved 1 Mbps merging RESV 3 Mbps reserved 3 Mbps merging RESV 10 Mbps reserved 10 Mbps

47. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Resource Reservation Protocol (RSVP) - VII RSVP in hosts and routers: 1. RESV with flowspec and filterspec to RSVP daemon 2. policy control to check privileges etc. 3. admission control using flowspec 4. forward RESV message 5. control of local modules: classifier and scheduler application process RSVP daemon policy control admission control routing process RSVP daemon policy control admission control packet classifier packet scheduler packet classifier packet scheduler data

48. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Resource Reservation Protocol (RSVP) - VIII Reservation styles  a reservation request includes a set of options called the reservation style  shared vs. distinct reservations concerns treatment of reservations of different senders shared – single reservation for all senders (e.g., video conference audio) distinct – one reservation per sender (e.g., video conference video)  explicit vs. wildcard concerns selection of senders explicit – specify senders (e.g., teleteaching) wildcard – automatically select all senders (e.g., video conference)

49. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Resource Reservation Protocol (RSVP) - IX distinct reservation shared reservation explicit sender selection Fixed: distinct reservation (not shared) for each sender Shared-explicit: single reservation shared by a specified list of senders wildcard sender selection undefined Wildcard: single reservation shared by flows form all senders

50. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Resource Reservation Protocol (RSVP) - X NOT... The RSVP standard [RFC 2205] allows to reserve link bandwidth – it does NOT...: ...define how the network should provide the reserved bandwidth to the data flows – the routers must implement these mechanisms themselves ...specify how to do resource provisioning – which must likely be done using a proper scheduling mechanism ...determine the route – it is not a routing protocol, but relies on others ...determine which data to drop in case of overflow, i.e., the most important data may be lost ...perform an admission test, but it assumes that the routers perform admission control THUS; RSVP can only be used as a small piece in the QoS guarantee puzzle THUS; RSVP can only be used as a small piece in the QoS guarantee puzzle Kurose, J. F., Ross, K. W.: “Computer Networking: A Top-Down Approach Featuring the Internet”, 2nd edition, Addison Wesley, 2002

51. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Differentiated Services (DiffServ) – I IntServ and RSVP provide a framework for per-flow QoS, but they …  … give complex routers much information to handle  … have scalability problems set up and maintain per-flow state information periodically PATH and RESV messages overhead  … specify only a predefined set of services new applications may require other flexible services  DiffServ [RFC 2475] tries to be both scalable and flexible

52. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Differentiated Services (DiffServ) – II ISP favor DiffServ Basic idea  multicast is not necessary  make the core network simple due to many users  implement more complex control operations at the edge  aggregation of flows – reservations for a group of flows, not per flow  thus, avoid scalability problems on routers with many flows  do not specify services or service classes  instead, provide the functional components on which services can be built  thus, support flexible services

53. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Differentiated Services (DiffServ) – III Two set of functional elements:  edge functions: packet classification and traffic conditioning  core function: packet forwarding At the edge routers, the packets are tagged with a DS-mark (differentiated service mark)  uses the type of service field (IPv4) or the traffic class field (IPv6)  different service classes (DS-marks) receive different service  subsequent routers treat the packet according to the DS-mark  classification: incoming packet is classified (and steered to the appropriate marker function) using the header fields the DS-mark is set by marker once marked, forward classifier marker forward

54. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Differentiated Services (DiffServ) – IV Note, however, that there is no “rules” for classification – it is up to the network provider A metric function may be used to limit the packet rate:  the traffic profile may define rate and maximum bursts  if packets arrive too fast, the metric function assigns another marker function telling the router to delay or drop the packet classifier marker forward shaper / dropper

55. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Differentiated Services (DiffServ) – V In the core routers, a DS-marked packet is forwarded according to a per-hop behavior (PHB) associated with the DS-tag  the PHB determines how the router resources are used and shared among the competing service classes  the PHB should be based on the DS-tag only – simple forwarding decisions, no need for QoS-states for each source-destination pair  packets with same DS-tag are treated equally – regardless of source or destination (traffic aggregating)  a PHB can result in different service classes receiving different performance  performance differences must be observable and measurable to be able to monitor the system performance  no specific mechanism for achieving these behaviors are specified - any mechanism can by used as long as the performance specification is met

56. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Differentiated Services (DiffServ) – VI Currently, two PHBs are under active discussion  expedited forwarding [RFC 3246] specifies a minimum departure rate of a class, i.e., a guaranteed bandwidth the guarantee is independent of other classes, i.e., enough resources must be available regardless of competing traffic  assured forwarding [RFC 2597] divide traffic into four classes each class is guaranteed a minimum amount of resources each class are further partitioned into one of three “drop” categories (if congestion occur, the router drops packets based on “drop” value)

57. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems core routers Differentiated Services (DiffServ) – VII Edge router: use header fields to lookup right DS-tag and mark packet Core router: use PHB according to DS-tag to forward packet fast and scalable due to simple core routers

58. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Internet Streaming Protocol, Version 2 (ST-II) – I ST-II is defined by RFC 1190/1819 It is a connection-oriented supplement to IP with two components:  ST: reservations and data management  SCMP (ST control message protocol): reliable control messages Main concepts:  unreliable data transfers, reliable control  a negotiated packet size (no fragmentation and reassembly)  routing tree from sender to multiple receivers  flow specification describing QoS parameters during connection setup application link transport ST-II SCMP

59. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Internet Streaming Protocol, Version 2 (ST-II) – II The resource reservation is sender-oriented  SCMP sends a message with a flow specification  if the routers and the destination accepts the call, the call is returned (possibly modified) to the source  typical parameters include bandwidth delay delay variance size Max delay12 Min delay2 size4096 Max delay12 Min delay5 size2048 Max delay12 Min delay9 size2048 connect accept/reject

60. Fast Routing

61. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Routing Speed-up ATM  Virtual Channels and Virtual Path RSVP  IP and Port Mapping ST-II  Hop ID MPLS  Label

62. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Multiprotocol Label Switching (MPLS) Multiprotocol Label Switching  Separate path determination from hop-by-hop forwarding  Forwarding is based on labels  Path is determined by choosing labels Distribution of labels  On application-demand LDP – label distribution protocol  By traffic engineering decision RSVP-TE – traffic engineering extensions to RSVP

63. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Multiprotocol Label Switching (MPLS) MPLS works above multiple link layer protocols Carrying the label  Over ATM Virtual path identifier or Virtual channel identifier Maybe shim  Frame Relay data link connection identifier (DLCI) Maybe shim  Ethernet, TokenRing, … Shim Shim?

64. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Link Layer HeaderShim Multiprotocol Label Switching (MPLS) Shim: the label itself Network Layer Header… Shim 20 bits label 3 bits experimental 1 bit Bottom of stack 8 bits TTL

65. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Routing using MPLS 216.239.51.101 129.42.16.99 80.91.34.111 129.240.148.31 66.77.74.20 209.73.164.90 192.67.198.54 209.189.226.17 193.99.144.71 81.93.162.20 … Label 12–IF 1 Label 27–IF 2 … Added label Remove label Reserved path for this label

66. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems MPLS Label Stack ISP 1 ISP 2 ISP 3 The ISP 1 Classifies the packet Assigns it to a reservation Performs traffic shaping Adds a label to the packet for routers in his net The ISP 1 Buys resources from ISP 2 The ISP 2 Repeats classifying, assignment, shaping Adds a label for the routers in his net He pushes a label on the label stack

67. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems MPLS Label Stack ISP 1 ISP 2 ISP 3

68. The End: Summary

69. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Summary Timely access to resources is important for multimedia application to guarantee QoS – reservation might be necessary Many protocols have tried to introduce QoS into the Internet, but no protocol has yet won the battle...  often NOT only technological problems, e.g., scalability flexibility...  but also economical and legacy reasons, e.g., IP rules – everything must use IP to be useful several administrative domains (how to make ISPs agree) router manufacturers will not take the high costs (in amount of resources) for per-flow reservations pricing...

70. 2003 Carsten Griwodz & Pål Halvorsen INF5070 – media storage and distribution systems Some References 1. ATM Forum, http://www.atmforum.com 2. ATM Forum: “ATM Service Categories”, http://www.atmforum.com/aboutatm/6.html 3. Danthine, A., Bonaventure, O.: “From Best Effort to Enhanced QoS”, in: Spaniol, O., Danthine, A., Effelsberg, W. (Eds.): “Architecture and Protocols for High-Speed Networks”, Kluwer Achademic Publishers, 1994, pp. 179-201 4. Kurose, J. F., Ross, K. W.: “Computer Networking: A Top-Down Approach Featuring the Internet”, 2nd edition, Addison Wesley, 2002 5. Steinmetz, R., Nahrstedt, C.: “Multimedia: Computing, Communications & Applications”, Prentice Hall, 1995 6. Tenet group: http://tenet.berkeley.edu/tenet.html  The RFC repository maintained by the IETF Secretariat can be found at http://www.ietf.org/rfc.html The following RFCs might be interesting with respect to this lecture:  RFC 791: Internet Protocol  RFC 1883:Internet Protocol, Version 6 (IPv6)  RFC 2460:Internet Protocol, Version 6 (IPv6), Obsoletes: 1883  RFC 2212:Specification of Guaranteed Quality of Service  RFC 2205:Resource ReSerVation Protocol (RSVP)  RFC 1363: A Proposed Flow Specification  RFC 2475:An Architecture for Differentiated Services  RFC 3246:An Expedited Forwarding PHB (Per-Hop Behavior)  RFC 2597:Assured Forwarding PHB Group  RFC 1190:Experimental Internet Stream Protocol, Version 2 (ST-II)  RFC 1819:Internet Stream Protocol Version 2 (ST2): Protocol Specification - Version ST2+