[ Pobierz całość w formacie PDF ]
.This can be realized with active admissioncontrol.Before a router accepts a new QoS reservation, represented by the Tspec,it must consider all important resources, such as link bandwidth, router or switchport buffer space and computational capacity of the packet forwarding.The Controlled Load Service class does not accept or make use of specific targetvalues for control parameters such as bandwidth, delay or loss.Applications thatuse Controlled Load Services must be proof against small amounts of packet lossand packet delays.QoS reservations using Controlled Load Services need to provide a Tspec thatconsists of the token bucket parameters r and b as well as the minimum policedunit m and the maximum packet size M.An Rspec is not necessary becauseControlled Load Services doesn't provide functions to reserve a fixed bandwidth orguarantee minimum packet delays.Controlled Load Service provides QoS controlonly for traffic that conforms to the Tspec that was provided at setup time.Thismeans that the service guarantees only apply for packets that respect the tokenbucket rule that over all time periods T, the amount of data sent can not exceedrT+b.Controlled Load Service is designed for applications that can tolerate reasonableamount of packet loss and delay, such as audio and videoconferencing software.10.2.1.2 Guaranteed ServiceThe Guaranteed Service model provides functions that assure that datagrams willarrive within a guaranteed delivery time.This means that every packet of a flowthat conforms to the traffic specifications will arrive at least at the maximum delaytime that is specified in the flow descriptor.Guaranteed Service is used forapplications that need a guarantee that a datagram will arrive at the receiver notlater than a certain time after it was transmitted by its source.For example, real-time multimedia applications, such as video and audiobroadcasting systems that use streaming technologies, cannot use datagrams that510 TCP/IP Tutorial and Technical Overview arrive after their proper play-back time.Applications that have hard real-timerequirements, such as real-time distribution of financial data (share prices), will alsorequire guaranteed service.Guaranteed Service does not minimize the jitter (thedifference between the minimal and maximal datagram delays), but it controls themaximum queueing delay.The Guaranteed Service model represents the extreme end of delay control fornetworks.Other service models providing delay control have much weaker delayrestrictions.Therefore, Guaranteed Service is only useful if it is provided by everyrouter along the reservation path.Guaranteed Service gives applications considerable control over their delay.It isimportant to understand that the delay in an IP network has two parts: a fixedtransmission delay and a variable queueing delay.The fixed delay depends on thechosen path, which is determined not by guaranteed service but by the setupmechanism.All data packets in an IP network have a minimum delay that is limitedby the speed of light and the turnaround time of the data packets in all routers onthe routing path.The queueing delay is determined by Guaranteed Service and itis controlled by two parameters: the token bucket (in particular, the bucket size b)and the bandwidth R that is requested for the reservation.These parameters areused to construct the fluid model for the end-to-end behavior of a flow that usesGuaranteed Services.The fluid model specifies the service that would be provided by a dedicated linkbetween sender and receiver that provides the bandwidth R.In the fluid model, theflow's service is completely independent from the service for other flows.Thedefinition of guaranteed service relies on the result that the fluid delay of a flowobeying a token bucket (r,b) and being served by a line with bandwidth R isbounded by b/R as long as R is not less than r.Guaranteed Service approximatesthis behavior with the service rate R, where now R is a share of bandwidth throughthe routing path and not the bandwidth of a dedicated line.In the Guaranteed Service model, Tspec and Rspec are used to set up a flowreservation.The Tspec is represented by the token bucket parameters.TheRspec contains the parameter R that specifies the bandwidth for the flowreservation.The Guaranteed Service model is defined in RFC 2212.10.2.2 The Reservation Protocol (RSVP)The Integrated Services model uses the Reservation Protocol (RSVP) to set up andcontrol QoS reservations.RSVP is defined in RFC 2205 and has the status of aproposed standard.Because RSVP is an Internet control protocol and not arouting protocol, it requires an existing routing protocol to operate.The RSVPprotocol runs on top of IP and UDP and must be implemented in all routers on thereservation path.The key concepts of RSVP are flows and reservations.An RSVP reservation applies for a specific flow of data packets on a specific paththrough the routers.As described in 10.1, Why QoS? on page 505, a flow isdefined as a distinguishable stream of related datagrams from a unique sender to aunique receiver.If the receiver is a multicast address, a flow can reach multiplereceivers.RSVP provides the same service for unicast and multicast flows.Eachflow is identified from RSVP by its destination IP address and destination port.Allflows have dedicated a flow descriptor which contains the QoS that a specific flowrequires.The RSVP protocol does not understand the contents of the flowChapter 10.Quality of Service 511 descriptor.It is carried as an opaque object by RSVP and is delivered to therouter's traffic control functions (packet classifier and scheduler) for processing.Because RSVP is a simplex protocol, reservations are only done in one direction.For duplex connections, such as video and audio conferences where each senderis also a receiver, it is necessary to set up two RSVP sessions for each station.The RSVP protocol is receiver-initiated.Using RSVP signalling messages, thesender provides a specific QoS to the receiver which sends an RSVP reservationmessage back with the QoS that should be reserved for the flow from the sender tothe receiver.This behavior considers the different QoS requirements forheterogeneous receivers in large multicast groups.The sender doesn't need toknow the characteristics of all possible receivers to structure the reservations.To establish a reservation with RSVP the receivers send reservation requests tothe senders depending on their system capabilities.For example, a fastworkstation and a slow PC want to receive a high-quality MPEG video stream with30 frames per second which has a data rate of 1.5 Mbps.The workstation hasenough CPU performance to decode the video stream, but the PC can only decode10 frames per second.If the video server sends the messages to the two receiversthat it can provide the 1.5 Mbps video stream, the workstation can return areservation request for the full 1.5 Mbps.But the PC doesn't need the fullbandwidth for its flow because it cannot decode all frames.So the PC may send areservation request for a flow with 10 frames per second and 500 kbps.10.2.2.1 RSVP OperationA basic part of a resource reservation is the path.The path is the way of a packetflow through the different routers from the sender to the receiver.All packets thatbelong to a specific flow will use the same path.The path gets determined if asender generates RSVP path messages that travel in the same direction as theflow.Each sender host periodically sends a path message for each data flow itoriginates [ Pobierz całość w formacie PDF ]