Documente Academic
Documente Profesional
Documente Cultură
Introduction
Modern internet applications demand services not provided by a best-effort service model The TCP/IP infrastructure has been enhanced to address the need
increased capacity and data rates efficient multicasting techniques (Chap. 15) QoS capabilities added (Chap. 17)
similar, but fundamentally different from that used in connection-oriented networks such as ATM, frame relay soft state at routers: reserved resources expire unless refreshed
end systems must periodically renew their requests (default: every 30 sec.)
Chapter 18: Protocols for QoS Support
Receiver-Initiated Reservation
different members of same group may have different resource requirements if transmission flow is divided into sub-flows, not all members need all sub-flows if multiple sources are transmitting for same group, receiver may want to select source In general, QoS needs of different receivers may differ due to equipment, link speed, processing speed/power or other differences
Soft State
Values associated with a given flow is temporarily cached at the router Routing for that flow is subject to change End systems must periodically refresh the state information Routers discard states not refreshed within specified time limit If a new route becomes the preferred route for the flow, end systems provide the reservation information to the new routers on the route
6
Flow Descriptor
Service class Tspec: traffic characteristics of the flow (average rate, peak rate, maximum burst size) Rspec: QoS reservations specification of the flow (for Guaranteed Service)
Source IP address (minimal) UDP/TCP source port number (optional) other fields (based on application)
1.
2.
3.
RSVP Operation
R1, R2, R3, R4: forwarding routers G1, G2, G3: multicast receivers S1, S2: multicast senders
Destination(s)/ Receiver(s)
Router
Reservation actions at router: 1. Admission control verify requested resources are available 2. Policy control verify permissions 3. Set up classifier and scheduler to provide requested Q0S 4. Forward request upstream (aggregate as required)
Chapter 18: Protocols for QoS Support
10
Reservation Styles
How resource reservations are aggregated/merged for multiple receivers in the same multicast group Two options, specified in the receivers reservation requests
Reservation attribute: reservation is shared over flows from multiple senders, or distinct for each sender Sender selection: explicit list or wildcard
Fixed-Filter: Specifies a distinct reservation for each sender and an explicit list of senders Symbolic representation: FF(S1{Q1}, S2{Q2}, )
Shared-Explicit: Specifies that a single resource reservation is to be shared by an explicit list of senders Symbolic representation: SE(S1, S2, {Q})
Wildcard-Filter: Specifies that a single resource reservation is to be shared by all senders to this address Symbolic representation: WF(*{Q})
12
S2
S3
13
Resv: propagates upstream from receivers to establish router soft states (resource reservations) for a multicast group, merging as required. Message carries a merged flowspec. Path: issued by senders to establish reverse-hop (upstream) path back to a source from group members
14
15
16
MPLS Goal: provide ATM-like traffic management and QoS within IPbased networks Reality: provides an approach which reduces per-packet processing required at routers, thereby enhancing IP routing performance
1. support for connectionoriented QoS 2. Traffic engineering 3. VPN support 4. multiprotocol support
17
MPLS in Practice
High-speed IP backbones Legacy ATM networks MPLS-capable ATM networks Optical networks Frame relay networks
Most prevalent usage is for transporting IP data over these networks with low overhead/latency, often to implement a VPN for IP traffic
18
MPLS in Practice
MPLS enhances and simplifies packet forwarding through routers using Layer-2 switching paradigms. MPLS is simple, which allows for easy implementation. MPLS increases network performance because it enables routing by switching at wireline speeds.
MPLS in Practice
MPLS provides a bridge between access IP and core ATM. MPLS can reuse existing router/ATM switch hardware, effectively joining the two disparate networks.
MPLS is a standards-based solution that achieves synergy between IP and ATM networks. MPLS facilitates IPover-synchronous optical network (SONET) integration in optical switching. MPLS helps build scalable VPNs with trafficengineering capability.
20
MPLS Operation
using an interior routing protocol (like OSPF), establish a path (LSP) in advance for a given FEC and establish the QoS parameters for the FEC. Labels are assigned for each FEC.
packets entering at ingress LSR are assigned to an appropriate FEC and a label is attached
the egress LSR strips the label and forwards the packet to its final destination
at each LSR along the LSP, the incoming label is removed and an outgoing label is attached
22
MPLS Operation
23
MPLS Operation
Forwarding between LSRs requires only simple mapping between label values and next hop addresses A particular PHB can be assigned for a given FEC at each LSR
24
MPLS forwarding can be done by high-speed switches that may not be capable of IP packet analysis/handling Forwarding behavior (the LSP) can be based on information other than that in the IP header Forwarding behavior can be based on network ingress point FEC determination can be arbitrarily complex since it is done only once at ingress Paths for traffic can be engineered in advance to balance load traffic or provide different levels of serviced for different FECs
25
Label stacking?
Chapter 18: Protocols for QoS Support 26
Traffic Engineering
Class of Service
28
explicit routing
makes use of ordinary routing protocols, like OSPF does not readily support traffic engineering or routing based on policy/priority single designated LSR, usually an ingress or egress LSR, specifies all LSRs in a route for a given FEC with loose explicit routing only some of the LSRs are specified
29
RFC 3031 does not define or depend on a specific label distribution protocol several are defined
MPLS-LDP (RFC 3036) RSVP-TE (RFC 3209) MPLS-BGP MPLS-RSVP-TUNNELS
Recent focus of IETF efforts
Labels are distributed (bound) in a downstream path of LSRs in an LSP Labels must be unique on each hop between pairs of LSRs )local significance)
31
Real-time traffic requires preservation of the time relationship between packets of a session.
From Data Communication and Networks, Forouzan, 4th Edition Chapter 18: Protocols for QoS Support 33
Jitter is introduced due top the variable component of delay in packet switched networks.
From Data Communication and Networks, Forouzan, 4th Edition Chapter 18: Protocols for QoS Support 34
Timestamp
Timestamping packets can allow reconstruction of original time relationship at the receiver.
From Data Communication and Networks, Forouzan, 4th Edition Chapter 18: Protocols for QoS Support 35
Playback Buffer
threshold
threshold
A playback buffer at the receiver is used to sequence/time the release of data to the application.
From Data Communication and Networks, Forouzan, 4th Edition Chapter 18: Protocols for QoS Support 36
TCP
point-to-point, connection-oriented, so not suitable for multicast includes retransmission mechanisms for lost segments, which often conflicts with real-time application requirement no segment timing information available
UDP
no segment timing information available or other general purpose real time tools
37
Defined in RFC 3550 to provide mechanisms needed to support real-time traffic in IP-based networks,
primarily to satisfy the needs of multi- participant multimedia conferences
Best suited for soft real-time communication Lacks mechanisms to support hard real-time traffic (i.e., traffic with no loss tolerance, minimal jitter) Closely coupled with the application layer in the Internet protocol stack (typically, above UDP) Two protocols make up RTP: RTP, a data transfer protocol (carries the data) RTCP, a control protocol (carries session/QoS info)
Chapter 18: Protocols for QoS Support
38
From Data Communication and Networks, Forouzan, 4th Edition Chapter 18: Protocols for QoS Support
39
Application-Level Framing
recovery from lost data and framing can be handled at the application layer
retransmission may not be appropriate may be more useful for destination(s) to inform source about the quality of transmission
flow is broken into ADUs (application data units), e.g. audio samples, video frames
may need to re-compute lost data before sending may be able to send new data that fixes the consequences of any lost data
lower layers must preserve ADU boundaries payload format is specific to the application
40
typical layered protocols call for data units to be sequentially processed by each layer integrated layer processing allows adjacent layers (application, RTP, transport) of the protocol stack to be tightly coupled therefore, RTP is not complete by itself requires application-layer and transport layer capabilities (and appropriate information in its header)
41
defines a set of payload type codes and their mapping to payload formats (e.g., media encodings). May also define extensions or modifications to RTP that are specific to a particular class of applications. Typically, an application will operate under only one profile. E.g. profile for AV application data may be found in RFC 3551.
define how a particular payload, such as an audio or video encoding, is to be carried in RTP.
Chapter 18: Protocols for QoS Support 42
session is defined by: RTP port#, RTCP port#, participant IP address payload type identification timestamping data sequencing/synchronizing data mixing/translating data
43
RTP relays
source identifiers (who generated data) timestamp (when data was generated) sequence number (order of data in a flow) payload format (type of data)
mixer: combines data from multiple sources and creates new single data signal translator: converts input and resends in new format, or replicates for unicast destinations
44
Translator
45
Supplied by a mixer
46
47
Provides control information and feedback between session participants Each participant in an RTP session periodically issues an RTCP packet Uses same underlying transport as RTP (usually UDP) RTCP port # = RTP session port # +1 Provides four key functions for real-time traffic management (per RFC 1889)
QoS and congestion control Source identification Session size estimation and scaling Session control
48
RTCP Operation
Protocol specifies report packets exchanged between sources and destinations in real-time flows (max. one every 5 secs, limit to 5% session traffic) Five report types are defined: Sender (SR), Receiver(RR), Goodbye (BYE), Source Description (SDES) and Application specific SR and RR reports contain statistics such as the number of packets sent, number of packets lost, inter-arrival jitter, etc. Used to modify sender(s) transmissions and for diagnostics purposes
49
Example Suppose one sender, sending video at a rate of 2 Mbps. Then RTCP attempts to limit its traffic to 100 Kbps (5% of 2 Mbps) RTCP gives 75% of this rate to the receivers; remaining 25% to the sender
Chapter 18: Protocols for QoS Support
The 75 kbps is equally shared among receivers: With R receivers, each receiver gets to send RTCP traffic at 75/R kbps. Sender gets to send RTCP traffic at 25 kbps. Participant determines RTCP packet transmission period by calculating avg RTCP packet size (across the entire session) and dividing by allocated rate.
50
RTCP Formats
Source Description
SDES Types
52