Protocols for QoS

CIS 20310 : Protocols for QoS Support

Chapter 18 Protocols for QoS Support

Increased DemandsNeed to incorporate bursty and stream traffic in TCP/IP architectureIncrease capacityFaster links, switches, routersIntelligent routing policiesEnd-to-end flow controlMulticastingQuality of Service (QoS) capabilityTransport protocol for streaming


Resource Reservation - UnicastPrevention as well as reaction to congestion requiredCan do this by resource reservationUnicastEnd users agree on QoS for task and request from networkMay reserve resourcesRouters pre-allocate resourcesIf QoS not available, may wait or try at reduced QoS


Resource Reservation MulticastGenerate vast trafficHigh volume application like videoLots of destinationsCan reduce loadSome members of group may not want current transmissionChannels of videoSome members may only be able to handle part of transmissionBasic and enhanced video components of video streamRouters can decide if they can meet demand


Resource Reservation Problems on an InternetMust interact with dynamic routingReservations must follow changes in routeSoft state a set of state information at a router that expires unless refreshedEnd users periodically renew resource requests


Resource ReSerVation Protocol (RSVP) Design GoalsEnable receivers to make reservationsDifferent reservations among members of same multicast group allowedDeal gracefully with changes in group membershipDynamic reservations, separate for each member of groupAggregate for group should reflect resources neededTake into account common path to different members of groupReceivers can select one of multiple sources (channel selection)Deal gracefully with changes in routesRe-establish reservationsControl protocol overheadIndependent of routing protocol


RSVP CharacteristicsUnicast and MulticastSimplexUnidirectional data flowSeparate reservations in two directionsReceiver initiatedReceiver knows which subset of source transmissions it wantsMaintain soft state in internetResponsibility of end usersProviding different reservation stylesUsers specify how reservations for groups are aggregatedTransparent operation through non-RSVP routersSupport IPv4 (ToS field) and IPv6 (Flow label field)


Data Flows - SessionData flow identified by destinationResources allocated by router for duration of sessionDefined byDestination IP addressUnicast or multicastIP protocol identifierTCP, UDP etc.Destination portMay not be used in multicast


Flow DescriptorReservation RequestFlow specDesired QoSUsed to set parameters in nodes packet schedulerService class, Rspec (reserve), Tspec (traffic)Filter specSet of packets for this reservationSource address, source prot


Figure 10.1 Treatment of Packets of One Session at One Router


Figure 10.2 RSVP Operation


RSVP OperationG1, G2, G3 members of multicast groupS1, S2 sources transmitting to that groupHeavy black line is routing tree for S1, heavy grey line for S2Arrowed lines are packet transmission from S1 (black) and S2 (grey)All four routers need to know reservation s for each multicast addressResource requests must propagate back through routing tree


FilteringG3 has reservation filter spec including S1 and S2G1, G2 from S1 onlyR3 delivers from S2 to G3 but does not forward to R4G1, G2 send RSVP request with filter excluding S2G1, G2 only members of group reached through R4R4 doesnt need to forward packets from this sessionR4 merges filter spec requests and sends to R3R3 no longer forwards this sessions packets to R4Handling of filtered packets not specifiedHere they are dropped but could be best efforts deliveryR3 needs to forward to G3Stores filter spec but doesnt propagate it


Reservation StylesDetermines manner in which resource requirements from members of group are aggregatedReservation attributeReservation shared among senders (shared)Characterizing entire flow received on multicast addressAllocated to each sender (distinct)Simultaneously capable of receiving data flow from each senderSender selectionList of sources (explicit)All sources, no filter spec (wild card)


Reservation Attributes and StylesReservation AttributeDistinctSender selection explicit = Fixed filter (FF)Sender selection wild card = none SharedSender selection explicit= Shared-explicit (SE)Sender selection wild card = Wild card filter (WF)


Wild Card Filter StyleSingle resource reservation shared by all senders to this addressIf used by all receivers: shared pipe whose capacity is largest of resource requests from receivers downstream from any point on treeIndependent of number of senders using itPropagated upstream to all sendersWF(*{Q})* = wild card senderQ = flowspecAudio teleconferencing with multiple sites


Fixed Filter StyleDistinct reservation for each senderExplicit list of sendersFF(S1{Q!}, S2{Q2},)Video distribution


Shared Explicit StyleSingle reservation shared among specific list of sendersSE(S1, S2, S3, {Q})Multicast applications with multiple data sources but unlikely to transmit simultaneously


Figure 10.3Examples of Reservation Style


RSVP Protocol MechanismsTwo message typesResvOriginate at multicast group receiversPropagate upstreamMerged and packet when appropriateCreate soft statesReach senderAllow host to set up traffic control for first hopPathProvide upstream routing informationIssued by sending hostsTransmitted through distribution tree to all destinations


Figure 10.4RSVP Host Model


Multiprotocol Label Switching (MPLS)Routing algorithms provide support for performance goalsDistributed and dynamicReact to congestionLoad balance across networkBased on metricsDevelop information that can be used in handling different service needsEnhancements provide direct supportIS, DS, RSVPNothing directly improves throughput or delayMPLS tries to match ATM QoS support


BackgroundEfforts to marry IP and ATMIP switching (Ipsilon)Tag switching (Cisco)Aggregate route based IP switching (IBM)Cascade (IP navigator)All use standard routing protocols to define paths between end pointsAssign packets to path as they enter networkUse ATM switches to move packets along pathsATM switching (was) much faster than IP routersUse faster technology


DevelopmentsIETF working group 1997Proposed standard 2001Routers developed to be as fast as ATM switchesRemove the need to provide both technologies in same networkMPLS does provide new capabilitiesQoS supportTraffic engineeringVirtual private networksMultiprotocol support


Connection Oriented QoS SupportGuarantee fixed capacity for specific applicationsControl latency/jitterEnsure capacity for voiceProvide specific, guaranteed quantifiable SLAsConfigure varying degrees of QoS for multiple customersMPLS imposes connection oriented framework on IP based internets


Traffic EngineeringAbility to dynamically define routes, plan resource commitments based on known demands and optimize network utilizationBasic IP allows primitive traffic engineeringE.g. dynamic routingMPLS makes network resource commitment easyAble to balance load in face of demandAble to commit to different levels of support to meet user traffic requirementsAware of traffic flows with QoS requirements and predicted demandIntelligent re-routing when congested


VPN SupportTraffic from a given enterprise or group passes transparently through an internetSegregated from other traffic on internetPerformance guaranteesSecurity


Multiprotocol SupportMPLS can be used on different network technologiesIPRequires router upgradesCoexist with ordinary routersATMEnables and ordinary switches co-existFrame relayEnables and ordinary switches co-existMixed network


MPLS Terminology


MPLS OperationLabel switched routers capable of switching and routing packets based on label appended to packetLabels define a flow of packets between end points or multicast destinationsEach distinct flow (forward equivalence class FEC) has specific path through LSRs definedConnection orientedEach FEC has QoS requirementsIP header not examinedForward based on label value


Figure 10.5MPLS Operation Diagram


Explanation - SetupLabelled switched path established prior to routing and delivery of packetsQoS parameters established along pathResource commitmentQueuing and discard policy at LSRInterior routing protocol e.g. OSPF usedLabels assignedLocal significance onlyManually or using Label distribution protocol (LDP) or enhanced version of RSVP


Explanation Packet HandlingPacket enters domain through edge LSRProcessed to determine QoSLSR assigns packet to FEC and hence LSPMay need co-operation to set up new LSPAppend labelForward packetWithin domain LSR receives packetRemove incoming label, attach outgoing label and forwardEgress edge strips label, reads IP header and forwards


NotesMPLS domain is contiguous set of MPLS enabled routersTraffic may enter or exit via direct connection to MPLS router or from non-MPLS routerFEC determined by parameters, e.g.Source/destination IP address or network IP addressPort numbersIP protocol idDifferentiated services codepointIPv6 flow labelForwarding is simple lookup in predefined tableMap label to next hopCan define PHB at an LSR for given FECPackets between same end points may belong to different FEC


Figure 10.6MPLS Packet Forwarding


Label StackingPacket may carry number of labelsLIFO (stack)Processing based on top labelAny LSR may push or pop labelUnlimited levelsAllows aggregation of LSPs into single LSP for part of routeC.f. ATM virtual channels inside virtual pathsE.g. aggregate all enterprise traffic into one LSP for access provider to handleReduces size of tables


Figure 10.7 MPLS Label FormatLabel value: Locally significant 20 bitExp: 3 bit reserved for experimental useE.g. DS information or PHB guidanceS: 1 for oldest entry in stack, zero otherwiseTime to live (TTL): hop count or TTL value


Time to Live ProcessingNeeded to support TTL since IP header not readFirst label TTL set to IP header TTL on entry to MPLS domainTTL of top entry on stack decremented at internal LSRIf zero, packet dropped or passed to ordinary error processing (e.g. ICMP)If positive, value placed in TTL of top label on stack and packet forwardedAt exit from domain, (single stack entry) TTL decrementedIf zero, as aboveIf positive, placed in TTL field of Ip header and forwarded


Label StackAppear after data link layer header, before network layer headerTop of stack is earliest (closest to network layer header)Network layer packet follows label stack entry with S=1Over connection oriented servicesTopmost label value in ATM header VPI/VCI fieldFacilitates ATM switchingTop label inserted between cell header and IP headerIn DLCI field of Frame RelayNote: TTL problem


Figure 10.8Position of MPLS Label


FECs, LSPs, and LabelsTraffic grouped into FECsTraffic in a FEC transits an MLPS domain along an LSPPackets identified by locally significant labelAt each LSR, labelled packets forwarded on basis of label.LSR replaces incoming label with outgoing labelEach flow must be assigned to a FECRouting protocol must determine topology and current conditions so LSP can be assigned to FECMust be able to gather and use information to support QoS LSRs must be aware of LSP for given FEC, assign incoming label to LSP, communicate label to other LSRs


Topology of LSPsUnique ingress and egress LSRSingle path through domainUnique egress, multiple ingress LSRsMultiple paths, possibly sharing final few hopsMultiple egress LSRs for unicast trafficMulticast


Route SelectionSelection of LSP for particular FECHop-by-hopLSR independently chooses next hopOrdinary routing protocols e.g. OSPFDoesnt support traffic engineering or policy routingExplicitLSR (usually ingress or egress) specifies some or all LSRs in LSP for given FECSelected by configuration,or dynamically


Constraint Based Routing AlgorithmTake in to account traffic requirements of flows and resources available along hopsCurrent utilization, existing capacity, committed servicesAdditional metrics over and above traditional routing protocols (OSPF)Max link data rateCurrent capacity reservationPacket loss ratioLink propagation delay


Label DistributionSetting up LSPAssign label to LSPInform all potential upstream nodes of label assigned by LSR to FECAllows proper packet labellingLearn next hop for LSP and label that downstream node has assigned to FECAllow LSR to map incoming to outgoing label


Real Time Transport ProtocolTCP not suited to real time distributed applicationPoint to point so not suitable for multicastRetransmitted segments arrive out of orderNo way to associate timing with segmentsUDP does not include timing information nor any support for real time applicationsSolution is real-time transport protocol RTP


RTP ArchitectureClose coupling between protocol and application layer functionalityFramework for application to implement single protocolApplication level framingIntegrated layer processing


Application Level FramingRecovery of lost data done by application rather than transport layerApplication may accept less than perfect deliveryReal time audio and videoInform source about quality of delivery rather than retransmitSource can switch to lower qualityApplication may provide data for retransmissionSending application may recompute lost values rather than storing themSending application can provide revised valuesCan send new data to fix consequences of lossLower layers deal with data in units provided by applicationApplication data units (ADU)


Integrated Layer ProcessingAdjacent layers in protocol stack tightly coupledAllows out of order or parallel functions from different layers


Figure 10.9RTP Protocol Architecture


RTP Data Transfer ProtocolTransport of real time data among number of participants in a session, defined by:RTP Port numberUDP destination port number if using UDPRTP Control Protocol (RTCP) port number Destination port address used by all participants for RTCP transferIP addressesMulticast or set of unicast


Multicast SupportEach RTP data unit includes:Source identifierTimestampPayload format


RelaysIntermediate system acting as receiver and transmitter for given protocol layerMixersReceives streams of RTP packets from one or more sourcesCombines streamsForwards new streamTranslatorsProduce one or more outgoing RTP packets for each incoming packetE.g. convert video to lower quality


Figure 10.10RTP Header


RTP Control Protocol (RTCP)RTP is for user dataRTCP is multicast provision of feedback to sources and session participantsUses same underlying transport protocol (usually UDP) and different port numberRTCP packet issued periodically by each participant to other session members


RTCP FunctionsQoS and congestion controlIdentificationSession size estimation and scalingSession control


RTCP TransmissionNumber of separate RTCP packets bundled in single UDP datagramSender reportReceiver reportSource descriptionGoodbyeApplication specific


Figure 10.11RTCP Packet Formats


Packet Fields (All Packets)Version (2 bit) currently version 2Padding (1 bit) indicates padding bits at end of control information, with number of octets as last octet of paddingCount (5 bit) of reception report blocks in SR or RR, or source items in SDES or BYEPacket type (8 bit)Length (16 bit) in 32 bit words minus 1In addition Sender and receiver reports have:Synchronization Source Identifier


Packet Fields (Sender Report)Sender Information BlockNTP timestamp: absolute wall clock time when report sentRTP Timestamp: Relative time used to create timestamps in RTP packetsSenders packet count (for this session)Senders octet count (for this session)


Packet Fields (Sender Report)Reception Report BlockSSRC_n (32 bit) identifies source refered to by this report blockFraction lost (8 bits) since previous SR or RRCumulative number of packets lost (24 bit) during this sessionExtended highest sequence number received (32 bit) Least significant 16 bits is highest RTP data sequence number received from SSRC_nMost significant 16 bits is number of times sequence number has wrapped to zeroInterarrival jitter (32 bit)Last SR timestamp (32 bit)Delay since last SR (32 bit)


Receiver ReportSame as sender report except:Packet type field has different valueNo sender information block


Source Description PacketUsed by source to give more information32 bit header followed by zero or more additional information chunksE.g.:0ENDEnd of SDES list1CNAMECanonical name2NAMEReal user name of source3EMAILEmail address


Goodbye (BYE)Indicates one or more sources no linger activeConfirms departure rather than failure of network


Application Defined PacketExperimental useFor functions & features that are application specific


Required ReadingStallings chapter 10


Protocols for QoS SupportChapter 18

Documents

Protocols for QoS