Protocols for QoS Supportomikron.eit.lth.se/ETSN01/ETSN012015/lectures/QoS_protocols.pdf · Lund University / Presentation 2012 Flow Descriptor •Reservation Request includes a flow

Lund University / Presentation 2012

Protocols for QoS Support


Review/Preview

Approaches to QoS support:• Fine-grained approach

– provide QoS to individual applications or flows– IntServ, RSVP (ATM too)

• Coarse-grained approach– provide QoS to large classes of data or aggregated traffic– DiffServ


Review/Preview: IntServ

• 2 service classes, besides best-effort– guaranteed service:

• for delay intolerant application, packets never arrive late maximum delay guaranteed

– controlled load service:• for adaptive applications that run well if network is not heavily loaded

• Mechanisms– Declaring service requirements and characterising the data

(flowspec)

– admission control (can we provide requested service to given data)

– resource reservation (networks exchange of information)

– packet scheduling (actions of routers to meet the requirements) i.e. queuing discipline!


Resource Reservation Problems on an Internet

• Must interact with dynamic routing– Reservations must follow changes in route

• Thus, keep soft state – a set of state information at a router that expires unless refreshed– End users periodically renew resource requests


Resource ReSerVation Protocol (RSVP) Design Goals

• Enable receivers to make reservations– Different reservations among members of same multicast

group allowed

• Deal gracefully with changes in group membership– Dynamic reservations, separate for each member of group

• Receivers can select one of multiple sources (like channel selection)

• Deal gracefully with changes in routes– Re-establish reservations

• Need to control protocol overhead

• Independent of routing protocol used

• Specified in RFC2205


RSVP Characteristics

• Can be used for Unicast and Multicast• Simplex

– I.e. unidirectional data flow– Separate reservations in two directions if two-way exchange

•Receiver initiated– Receiver knows which subset of source transmissions it wants

• Maintain soft state on internet– It’s the responsibility of receivers!

• Transparent operation through non-RSVP routers


Data Flows - Session• Data flow identified by destination• Resources allocated by router for duration of session• Defined by (used for packet filtering)

– Destination IP address• Unicast or multicast

– IP protocol field (rep. next higher level)• TCP, UDP etc.

– Destination port• May not be used in multicast


Flow Descriptor

• Reservation Request includes a flow descriptor containing a flowspec and a filter spec

• Flowspec:– Specifies the service class– TSpec: a flow’s traffic characteristics, such as

data rate– RSpec: service requested from network (its

desired QoS)

• Filter spec– Set of packets for this reservation– Uses source address & source port


Treatment of Packets of One Session at One Router


RSVP Protocol Mechanisms

Two message types:•Path

– Provide upstream routing information– Used by receivers to make reservation– Issued by sending hosts– Transmitted through distribution tree to all

destinations

•Resv (i.e. reserve)– Originate at multicast group receivers– Propagate upstream– Merged and packed as appropriate– Create & store soft states


Path reservation

• Receiver-oriented approach - receiver needs to know sender’s TSpec and the path

• sender sends a message with TSpec to receiver, get reverse path as a bonus

– source transmits PATH, receiver responds with RESV


MPLS: Background

• Efforts to marry IP and ATM as ATM switching (was) much faster than IP routers

• IETF working group formed in 1997, proposed standard 2001• However, routers developed to be as fast as ATM switches

now!– Remove the need to provide both technologies in same network

• MPLS does provide new capabilities:– QoS support– Traffic engineering– Virtual private networks (VPNs)– Multiprotocol support


Connection Oriented QoS Support (1)

• Guarantee fixed capacity for specific applications• Control latency/jitter

– E.g., ensures capacity for voice• MPLS imposes connection oriented framework on IP based internets

– Contrary to RSVP’s approach


Traffic Engineering (2)

• Ability to dynamically define routes, plan resource commitments based on known demands and optimise network utilisation

• Basic IP allows primitive traffic engineering– E.g. dynamic routing

• MPLS makes network resource commitment easy– Able to balance load in face of demand

– Able to commit to different levels of support to meet user traffic requirements

– Aware of traffic flows with QoS requirements and predicted demand

– Intelligent re-routing when congested


Virtual Private Network (VPN) Support (3)

• Traffic from a given enterprise or group passes transparently through an internet

• Dedicated resources for VPNs• Segregated from other traffic on internet• VPN feature allows:

– Performance guarantees– Security


Multiprotocol support (4)


MPLS Operation

• Label switched routers (LSRs) capable of switching and routing packets based on label appended to a packet

• Labels define a flow of packets between end points or multicast destinations

• Each flow has specific path through LSRs– Connection oriented– Assigned to a FEC (forwarding equivalence class)

• Each FEC declares QoS requirements• IP header not examined in LSRs

– Forward only based on label value


MPLS Operation II

• MPLS domain is contiguous set of MPLS enabled routers (i.e LSRs)• A FEC (i.e. a flow) determined by:

– Source/destination IP address or network IP address– Port numbers– IP protocol value– DiffServ codepoint or IPv6 flow label

• Forwarding is simple lookup in predefined table– Map label to next hop

• Packets between same end points may belong to different FECs


FECs, LSPs, and Labels

• A FEC’s path is known as Labelled Switched Path (LSP)

• Packets identified by locally significant label– At each LSR, labelled packets forwarded on basis of label

– LSR replaces incoming label with outgoing label

• Routing protocol ma determine topology and current conditions so LSP can be assigned to FEC

– Must be able to gather and use information to support QoS

• LSRs must be aware of LSP for given FEC, assign label to FEC and communicate label to other LSRs


MPLS Operation Diagram


Explanation – Connection Setup

• LSP established prior to routing and delivery of packets• QoS parameters established along LSP

– Resource commitment– Queuing and AQM policies at LSR

• Labels assigned– Has local significance only– Manually or using a distribution protocol


Explanation – Packet Handling

• Packet enters domain through edge LSR– Processed to determine QoS (thru DS codepoint)

• Ingress LSR assigns packet to FEC and hence LSP– May need co-operation to set up new LSP

• LSR appends label and forwards packet• Other LSR in LSP receives packet

– Remove incoming label, attach outgoing label and forward

•Egress LSR strips label, reads IP header and forwards


MPLS Packet Forwarding


Label Format Diagram

• Label value: Locally significant 20 bit• Exp: 3 bit reserved for experimental use• S: 1 for oldest entry in stack, zero otherwise• Time to live (TTL): hop count or TTL value


Time to Live Processing

• Needed to support TTL since IP header not read– Otherwise faulty LSR may result in endless looping

• First label TTL set to IP header TTL on entry to MPLS domain

• TTL decremented at internal LSR– If zero, packet dropped or passed to ordinary error processing (e.g. ICMP)

– If positive, value placed in TTL of label and packet forwarded

• At exit from domain, TTL decremented– If zero, as above

– If positive, placed in TTL field of IP header and forwarded


Summary

• RSVP and MPLS protocols used to provide QoS support• There are other protocols used for specific type of applications

– RTP and SCTP for streaming applications requiring soft real-time communication

• Choice of a suitable protocol and architecture depends upon user requirements

• To substantiate a choice, performance studies are required through tools like queuing theory and simulators!

Documents

Protocols for QoS Supportomikron.eit.lth.se/ETSN01/ETSN012015/lectures/QoS_protocols.pdf · Lund University / Presentation 2012 Flow Descriptor •Reservation Request includes a flow