Integrated Services/RSVP Anjali Agarwal
Integrated Services IP Model
Defines a flow as a stream of IP packets
» Generated by a sender and destined to a destination » ThatrequirethesameQoS
Provides QoS to individual flows in the Internet » “Better than Best Effort” for some applications
» Supportforreal-timevoiceandvideoapplications
Requires traffic management mechanisms to deliver appropriate QoS to each flow
» Packetclassification,scheduling,admissioncontrol
Explicit reservation of buffers and bandwidth resources for
individual flows at every node
» Resource Reservation Protocol (RSVP) provides means for making reservations
2
Network Service Models
Best effort service
» No guarantees; suitable for elastic traffic
» At low loading, suitable for many traffic classes
Guaranteed service
» bound on maximum delay
» guarantee on available bandwidth
Controlled load service
» delay consistent with lightly loaded network
3
IntServ Router Model
Accept/reject a flow
Routing agent
Reservation agent
Management agent
Routing database
Admission control
Traffic control database
Input driver
Classifier
Packet scheduler Output driver
Internet forwarder
Traffic management mechanisms
Identify a packet’s flow
Buffering to control loss
Transmission scheduling to control delay
End-to-End Performance
End-to-end performance for an individual flow is the result of per-switch performances
» delay,jitter,loss,bandwidth
Per-switch performance depends on:
» per-packetprocessingcommontoallpackets » specificper-connectionorper-classtreatment
Resources must be allocated by RSVP at each node for each flow
Router 1 Router 2 Router 3
5
1.
2.
Admission Control
Individual flow negotiates admission into the network Flow Descriptor has two parts
Filter specification (filterspec) provides information required by classifier to identify the packets in the flow
Flow specification (flowspec) describes traffic properties of flow and QoS requirements
Traffic Specification (Tspec) describes traffic in terms of a token bucket
Request Specification (Rspec) describes QoS in terms of bandwidth, delay, loss
Each node along path must decide whether a flow can be accepted
» »
6
Guaranteed Service
Intended for flows that require real-time packet delivery Provides a firm delay bound
» Each flow is shaped by (b,r) leaky bucket b token bucket size
r token rate
» Police the flow to ensure compliance
» Reserve bit rate R>r at every node (weighted fair queueing) » Account for other network parameters
7
Controlled Load Service
Intended for flows that can tolerate some delay but are sensitive to traffic overload
» Equivalentto“BestEffortunderLightTraffic”
» Low delay and low loss, but no quantitative guarantees
Less complex than guaranteed service
» Each flow is shaped by (b,r) leaky bucket
» Use admission control to limit volume of controlled load service
» Reserve bit rate for the entire class to ensure light traffic mode
» Police each flow to ensure compliance; Non-conforming packets accorded best effort service
8
IntServ involves High Complexity
Numberof(application) flows can become extremely large
Per-flowtreatmentinvolves high complexity
Traffic Management
» Per-flow classifier
» Per-flow queueing
» Per-flow scheduling
» Huge table sizes & high hardware complexity
AdmissionControl
» Set up & maintenance of
individual flows
» High processing load
Routing agent
Reservation agent
Admission control
Management agent
Routing database
Traffic control database
Input driver
Classifier
Packet scheduler
Output driver
Internet forwarder
IntServ is not scalable
Why do we need RSVP
In connectionless protocols, the network nodes (the routers) don’t have any knowledge of a “flow” of information; they see only individual datagrams
There is no mechanism in protocols like TCP/IP to specify just what quality of service (QoS) a given “flow” would require, even if one could figure out what datagrams made it up.
10
What is RSVP
a network-control protocol that enables Internet applications to obtain special QoSs for their data flows
an internetwork end-to-end protocol that reserves the necessary resources for the different classes of service by using the techniques available on each underlying network type
not a routing protocol; works in conjunction with them to determine where it should carry reservation requests
Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing.
It occupies the place of a transport protocol
11
Features of RSVP
Makes resource reservations for both unicast and many-to- many multicast applications
maintains “soft” state in routers and hosts, providing
Adapts dynamically to changing group membership as well as to changing routes – establishes “soft” state that are built and destroyed incrementally in routers and hosts
Because multimedia flows may be (in fact, will probably be) asymmetrical, RSVP treats data flow as one directional (simplex). It logically distinguishes the role of data sender from data receiver.
RSVP is a receiver-based protocol; resource reservations requests are originated by the receivers of the service
12
Key Concepts
Data Flows
» is a sequence of messages that have the same source,
destination (one or more), and QoS
» Flow specification defines the desired QoS
» Session is a set of data flows with the same unicast or multicast destinations (session may have some number of senders talking to some number of receivers)
» multicast traffic – copy of each data packet forwarded from a single sender to multiple destinations
» unicast traffic – session involving a single receiver host distinguished by its generalized destination port
» multiple senders supported for a unicast destination
13
Key Concepts (cont.)
Reservation Model
» basic element is the “flow descriptor” which combines
filter spec (way to identify datagrams in a flow) with the flow spec (QoS the flow is to receive )
» the filter spec is used to set parameters in the packet classifier
» flowspec is used to set parameters in the node’s packet scheduler
Reservation Styles to fit a variety of applications 14
Traffic Control modules
RSVP Deamon – the “main” module,
» manages the reservation algorithm with the help of the
other modules of the service
» responsible to ask the “policy control” and “admission control” for their permission to set up the reservation
» sets parameters in a “packet classifier” and “packet scheduler” to obtain the desired QoS
Policy Control – decision module (for administrative purposes)
» responsible for who is allowed to make reservations, and what kinds of QoS he may reserve
15
Traffic Control modules (cont.)
Admission Control – decision module
» determines whether the node has sufficient resources available to meet
the needs of the reservation request
Packet Classifier –
» If both admission control and policy control returned a positive decision, then RSVP deamon passes incoming data packets to a packet classifier that determines the route and the QoS class for each packet
» may be combined with the routing function Packet Scheduler –
» responsible for achieving the promised QoS by prioritizing queues of flows, as necessary
» key component of the architecture
» must support the distinction between different services on all nodes
16
Traffic Control modules (cont.)
17
Reservation Styles to fit a variety of applications
fixed filter (FF) – distinct reservation
» reservation is made for packets sent by exactly one sender that is
specified in the filterspec
shared explicit (SE) – shared reservation
» packets from several sources listed explicitly in the filterspec can use
the reservation
wildcard filter (WF) – shared reservation
» all sources sending to the multicast group address share the
reservation
Shared and wildcard filters are useful for applications that are self-limiting in their bandwidth needs. These include audio sessions, because usually not more than one or two participants talk at the same time.
FF is more appropriate for video signals
18
S1, S2, S3, R1, R2, R3 belong to the same session
Can S2 & S3 share the bandwidth reserved by S1?
» Yes if application has one sender transmit at a time
» No if multiple senders transmit
How does router know which senders can access a reserved resource?
» ExplicitList
» Wildcard(Anysenderin session)
S1 S2,S3
Fixed Filter
R1
R1, R3
Reservation Styles
Router
Separate reservations Explicit list
Wildcard Filter
Shared reservations Wildcard (all senders) Shared Explicit Filter
Shared reservations Explicit list 19
Example
Router
S1 a S2, S3 b
c
d
R1
R2 R3
20
Send WF( *{4B} )
WF( *{4B} )
Wildcard request for 4B from R1
Wildcard request for 3B & 2B from R2 and R3;
Merged into 3B request
Reserve
Receive
WF( *{4B} )
WF( *{3B} ) WF( *{2B} )
Wildcard Filter
(a) *{4B} (c)
(b)
*{3B}
(d)
Inputs merge requests to 4B before upstream
Example: audioconferencing with
different bitrates
21
Send
FF( S1{4B} )
FF( S2{5B}, S3{B})
Reserve
Fixed Filter
Receive
FF( S1{4B}, S2{5B} )
FF( S1{3B}, S3{B} ) FF( S1{B} )
(a) (c)
(b)
(d)
S1{4B} S2{5B}
S1{3B} S3{B}
FF request from R1 for 4B from S1, 5B from S2
FF request from R2 for 3B from S1, B from S3
FF request from R3 for B from S1
Merge request to S1 for 3B
Merge request to S1 for 4B
Example: all-to-all videoconference
22
Send
SE(S1{3B})
SE((S2, S3){3B})
Reserve
Receive SE((S1,S2){B})
SE((S1,S3){3B}) SE(S2{2B})
Shared Explicit
(a) (S1,S2){B} (c)
(b)
(d)
(S1,S2,S3) {3B}
SE request for B for S1 & S2 from R1
SE request for 3B for S1 & S3 from R2
SE request for 2B for S2 from R2
Merge to union of list (S1, S2, S3) & max request, 3B
Example: layered video 23
RSVP Messages
Reservation-Request Messages
» sent by each receiver host towards the senders
» follows in reverse the routes that data packets use
Path Messages
» sent by each sender forward along the unicast or
multicast routes provided by routing protocols » used to store the path state in each node
» the path state is used to route reservation request messages in reverse direction
24
Path Messages
25
Resv Messages
26
Error Messages
RSVP Messages (cont.)
» path-error messages:
result from path messages and travel toward senders routed hop-by-hop using the path state
» reservation-request error messages:
result from reservation-request messages and travel toward the receiver routed hop-by-hop using the reservation state
» Information in error messages include: admission failure
Bandwidth unavailable service not supported ambiguous path
27
RSVP Messages (cont.)
Confirmation Messages
» reservation-request acknowledge messages sent as a result of the appearance of a reservation-confirmation object in a reservation-request message
Teardown Messages
» removes the path and reservation state without waiting for the cleanup
timeout period
» can be initiated by an application in an end system or a router as the result of state timeout.
» path-teardown messages – deletes the path state which in turn deletes the reservation state, routed like path messages
» reservation-request teardown messages – deleted reservation state, routed like reservation request messages
28
Reservation Process
The net’s routing table defines the routes from senders to receivers
» distribution tree is the directed tree carrying traffic away from a source to all destinations, with the sender being the root node, receivers being the leaves and routers being intermediate nodes
» trees may be unicast or multicast
29
Reservation Process (cont.)
RSVP senders periodically emit PATH message which indicates that the system is a sender and contains information required by network to route later on RESV messages up the distribution tree.
» PATH messages include the following information destination address (IP multicast address)
Reservation ID
Previous-hop IP address (used in forwarding RESV msgs) Templates for identifying traffic from that sender
Flow specification describing the sender’s output
» Routers capture this message and update the previous-hop
IP address before sending it on
» Path messages are used to “mark” the network
30
Reservation Process (cont.)
Receivers can now ask for reservation for a session from the sender by sending RESV messages up the tree
» one source may initiate several sessions (or flows).
RESV must include the session (flow) that the receiver is referring
» Upon a failure, the requester would be notified that his request has been rejected.
» Where multicast flows converge, the reservations are combined, using the highest QoS specified
31
PATH S
RESV
?
PATH RESV
?
PATH
PATH
Rx
RESV
R1
?
R2
Sender multicasts PATH message that describes traffic flow
Uses an existing routing protocol
Each router stores address of previous RSVP router (PHOP) and inserts its address in last hop field and forwards message, establishing the path in the reverse direction
Receiver unicasts RESV message to reserve resources (Can request confirmation from sender)
Each router performs admission & policy control (Send PathErr message if rejected)
Reservations may be modified or merged as RESV proceeds back to sender
RESV
R3
Reservation Process (cont.)
Rspec: specifies the requested service
Tspec: specifies size of the expected data flow
Filterspec: specifies which packets can use the reservation
33
Resource Reservation example
34
Merging
Inordertoincreasetheefficiencyofdistributionandtoavoidredundancy, different RSVP control messages that reach a certain node might be merged or split as necessary before being forwarded to the next hop(s) so that only the larger reservation is passed on towards the sender
The style of reservations combined with the requested flowspecs and with the filterspecs – determine the node’s decision as to merging, splitting or simply forwarding the control messages
35
Reservation Merging
S
Path
Resv
Path Path Resv
Path
Rx1 Resv
Path
Resv Rx2
R1
Resv Path
Resources are shared among receivers up to point where paths to different receivers diverge
RSVP process at nodes will merge requests at node where sufficient resources are already reserved
Request is not forwarded beyond merge point
R2
Resv
Path Resv
Rx3
R3
R4
Soft state
Soft state is state information that needs to be refreshed periodically, otherwise it times out – to allow new nodes to be added and current nodes to be deleted
Path and resv messages are periodically sent at a configurable refresh interval
takes care of any route change occurrence
If end-systems are unable to torn the reservations that are no longer needed, path and reservation state will time out eventually
Short refresh periods increase control traffic overhead; Long refresh and time-out periods lead to unused capacity that is reserved but no longer needed.
37
RSVP Soft State
Reservations are valid for a timeout period
Need to “refresh” reservation state by resending PATH
& RESV messages before expiry time
Reservation removed if not refreshed by timeout
RSVP runs directly over IP with type=46
message delivery is not reliable
Assume 1 in 3 consecutive messages gets through
Nominal refresh rate specified by R (usually 30 sec)
Refresh period for a receiver randomized from (0.5R,
1.5R) to avoid simultaneous refresh attempts
PathTear & ResvTear messages explicitly delete reservations
Transparent non-RSVP clouds
To allow incremental RSVP deployment in the Internet
No explicit tunneling is necessary, the path messages
carry the IP address of the last RSVP-capable router
Non-RSVP routers route path messages towards the receivers like any other unicast or multicast packet
Path state is set up only in RSVP capable routers
Resv messages are sent as unicast packets from one
RSVP-capable node to the next RSVP-hop upstream
However, the end-to-end QoS is unpredictable since there is no traffic control in non-RSVP nodes
39
Transparent non-RSVP clouds
40
41
RSVP Packet Format
Value Message Type
1 Path
2 Reservation-request
3 Path-error
4 Reservation-request error
5 Path-teardown
6 Reservation-teardown
7 Reservation-request ack
42
RSVP Message Header
Length: of this RSVP packet in bytes including
the common header and the variable-length objects that follow.
Send TTL: IP time-to-live (TTL) value with which the message was sent
Message ID: 32-bit field providing a label shared by all fragments of one message from a given next/previous RSVP hop
More Fragments (MF) Flag: MF is set on for all but the last fragment of a message
Fragment Offset—24-bit field representing the byte offset of the fragment in the message
43
RSVP Object Fields
Length: 16-bit field containing the total object length in bytes (must always be a multiple of 4 and be at least 4)
Class-Num: Identifies the object class. Each object class has a name.
C-Type: Object type, unique within Class-Num
» Class-Num and C-Type fields can be used together as a 16-bit
number to define a unique type for each object
Object Contents: The Length, Class-Num, and C-Type fields specify the form of the object content.
44
RSVP Message Objects
SESSION: IP destination address, IP protocol number, and destination port # RSVP_HOP: IP address of RSVP-capable router that sent this message TIME_VALUES: refresh period R.
STYLE: reservation style information not in flowspec or filterspec objects FLOWSPEC: desired QoS in a Resv message.
FILTER-SPEC: set of packets that receive desired QoS in a Resv message. SENDER_TEMPLATE: IP address of the sender in Path message. SENDER_TSPEC: sender’s traffic characteristics in Path message. ADSPEC: carries end-to-end path information in Path message. ERROR_SPEC: specifies errors in PathErr and ResvErr; confirmation in ResvConf.
POLICY_DATA: enables policy modules to determine whether request is allowed
INTEGRITY: cryptographic and authentication information to verify RSVP message
SCOPE: explicit list of senders that are to receive this message. RESV_CONFIRM: receiver IP address that is to receive the confirmation.
RSVP Issues
receiver-initiated –
» need PATH messages since receiver does not know which
path the data packets are taking
» advantage – sender does not need to know the number and specifics of reservations or the location of the receivers
» different receivers might request and receive different QoS Sender-initiated –
» sender had to maintain a reservation for each receiver » the protocol would not scale for large multicast groups
Deployment of RSVP is encouraged in intranets where access control, scalability and security are not critical issues
46
Receiver-initiated reservations
Throughput limit for fast Ethernet on sender side: 100 Mbit/sec Token Ring network limit: 16 Mbit/sec
Bandwidth requirement for standard video stream: 30 Mbit/sec
47
Scaling Issues of RSVP
the control traffic and reservation state within a single large multicast session should be limited – solved by the RSVP design
» path messages also sent as multicast messages, thus minimizing traffic » reservation requests merged
» aggregation of reservations for flows with similar QoS requirements for the same destination
managing the reservation state for a large number of sessions » Information about thousands of reservations needs to be stored,
accessed and changed
» degrades router performance
» the state required for RSVP grows with the bandwidth of the links, since more flows can be served and more state information needs to be managed
48
Scaling Issues of RSVP
enforcement of reservations
» cost of classifying is proportional to the number of packets going through the router where classifier has to look into the network and transport layer headers of each packet
» cost of packet scheduling depends on the number of different services the router supports
49