html5-img
1 / 73

RSVP, Resource Reservation Protocol

RSVP, Resource Reservation Protocol. RSVP, Resource Reservation Protocol RSVP is a transport layer protocol that enables a network to provide differentiated levels of service to specific flows of data A network-control protocol to establish unidirectional flows in IP networks

airlia
Télécharger la présentation

RSVP, Resource Reservation Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RSVP, Resource Reservation Protocol

  2. RSVP, Resource Reservation Protocol • RSVP is a transport layer protocol that enables a network to provide differentiated levels of service to specific flows of data • A network-control protocol to establish unidirectional flows in IP networks • •RSVP is used by routers to deliver QoS • •RSVP request : Reserve resources in each node along a path • •RSVP sends periodic refresh message to maintain the state along the reserved paths(s) • Default refresh period = 30 seconds • Support multicast and unicast traffics • •The bandwidth is reserved for a given flow • Merging of reservations • Sender/receiver notified of changes

  3. RSVP, Resource Reservation Protocol • RSVP is not a routing protocol • RSVP works in conjunction with routingprotocols and installs the equivalent of dynamic access lists along the routes that routing protocolscalculate • The Internet Engineering TaskForce (IETF) specified an open version of RSVP in its RFC 2205

  4. RSVP, Resource Reservation Protocol • QoS is provided by reserving resources at network elements

  5. RSVP, Resource Reservation Protocol • Reservation is done by PATH and RESV messages

  6. RSVP, Resource Reservation Protocol • Requires each node to maintain “soft state: information for each flow

  7. RSVP Functional Diagram

  8. How RSVP Works? Senders advertise using PATH message 1. An application on Host A creates a session,128.32.32.69/4078, by communicating with theRSVP daemon on Host A 2. The Host A RSVP daemon generates a PATHmessage that is sent to the next hop RSVProuter, R1, in the direction of the session address, 128.32.32.69 3. The PATH message follows the next hop paththrough R5 and R4 until it gets to Host B. Eachrouter on the path creates soft session state withthe reservation parameters

  9. How RSVP Works? Receivers reserve using RESV messages (Flowspec, filterspec, policy data) 4. An application on Host B communicateswith the local RSVP daemon and asks for areservation in session 128.32.32.69/4078. The daemon checks for and finds existing sessionstate 5. The Host B RSVP daemon generates aRESV message that is sent to the next hopRSVP router, R4, in the direction of thesource address, 24.1.70.210 6. The RESV message continues to follow thenext hop pathuntil it getsto Host A. Each router on the path makes a resource reservation

  10. RSVP Flowspecs

  11. RSVP levels of service • Best-effort service • Used for applications that require reliable delivery rather than a timely delivery • File transfer,disk mounts, interactive logins, and transaction traffic • Rely upon the native TCP mechanisms to resequence datagrams and request retransmissions • Rate-sensitive service (guaranteed bit-rate service) • Used for any traffic that is sensitive to variation in the amount of bandwidth available • H.323 videoconferencing, which was designed to run at a nearly constant rate • Delay-sensitive service • Requires timely but not reliable delivery of data • MPEG-II video, for example, averages about 3 to 7 Mbps, a single frame requires delivery withina specific time frame or the CODEC (code-decode) is incapable of doing its job • Controlled-delay service (non-real-time service) and predictive service (real-time service)

  12. RSVP QoS Services • Guaranteed service • Mathematically provable bounds on end to end datagram queuing delay/bandwidth • Controlled service • Approximate QoS from an unloaded network dor delay/bandwidth

  13. RSVP Data Flows • Data flows consist of discrete sessions between specific source and destination machines • A session is more specifically defined as a simplex flow of datagrams to a particular destination and transport layer protocol • Sessions are identified by destination address, protocol ID, and destination port • RSVP supports both unicast and multicast simplex sessions • It is possible for a unicast session to result in data being forwarded to multiple applications within the same destination host

  14. How RSVP works ? • Receiver first joins the multicast group specified by an IP destination address by using the Internet Group Membership Protocol (IGMP) • Sender starts sending RSVP path messages to the IP destination address, defining his requirements • The receiver application receives a path message and starts sending appropriate reservation-request messages specifying the desired flow descriptors using RSVP • At each node, the RSVP program applies a called admission control to determine whether it can supply the requested QoS • If succeeds, the RSVP program sets the parameters of the packet classifier and scheduler to obtain the desired QoS

  15. How RSVP works ? • RSVP uses the WFQ queuing algorithm to support the QoS • Also provides the policy to LLQ • If fails at any node, the RSVP program returns an error indication to the application that originated the request (in that case a renegotiation may be possible or best effort service can be requested) • When the sender application receives a reservation-request message, starts sending data packets • Currently only way to give resource-based CAC, Call Admission Control • RSVP scalability and performance enhancement • RSVP Aggregation • DiffServ interoperability

  16. Reservation Merging #3

  17. RSVP Tunneling • Tunneling permits: • Sporadically deployment of RSVP • Implement congestion control in situations in which congestion is a known problem

  18. RSVP Tunneling • It is impossible to deploy RSVP or any new protocol at the same moment throughout the entire Internet • RSVP must provide correct protocol operation even when two RSVP-capable routers are interconnected via an arbitrary cloud of non-RSVP routers • An intermediate non RSVP cloud is incapable of provide service guarantees • If, however has sufficient excess capacity, it can provide acceptable and useful real-time service • Tunneling requires RSVP and non-RSVP routers to forward path messages toward the destination address by using a local routing table • When a path message traverses a non-RSVP cloud, the path message copies carry the IP address of the last RSVP-capable router • Reservation-request messages are forwarded to the next upstream RSVP-capable router

  19. RSVP Messages • Four basic message types • Reservation-request messages • Path messages • Error and confirmation messages • Teardown messages • •Messages are encapsulated inside IP packets

  20. Reservation-Request Messages • Sent by each receiver host toward the senders • Follows in reverse the routes that the data packets use, all the way to the sender hosts • Delivered to the sender hosts so that the hosts can set up appropriate traffic-control parameters for the first hop • RSVP does not send any positive acknowledgment messages • Path Messages • Sent by each sender along the unicast or multicast routes provided by the routing protocol(s) • A path message is used to store the path state in each node • The path state is used to route reservation-request messages in the reverse direction

  21. Error and Confirmation Messages • Path-error messages • Result from path messages and travel toward senders • Routed hop by hop using the path state • At each hop, the IP destination address is the unicast address of the previous hop

  22. Error and Confirmation Messages • Reservation-request error messages • Result from reservation-request messages and travel toward thereceiver • Routed hop by hop using the reservation state • At each hop, the IP destination address is the unicast address of the next-hop node • Information carried in error messages can include the following: • • Admission failure • • Bandwidth unavailable • • Service not supported • • Bad flow specification • • Ambiguous path

  23. Error and Confirmation Messages • Reservation-request acknowledgment messages • Sent as the result of the appearance of a reservation-confirmation object in a reservation-request message • This acknowledgment message contains a copy of the reservation confirmation • An acknowledgment message is sent to the unicast address of a receiver host, and the address is obtained from the reservation -confirmation object • Forwarded to the receiver hop by hop

  24. Error and Confirmation Messages • Teardown Messages • Remove the path and reservation state without waiting for the cleanup timeout period • Can be initiated by an application in an end system (sender or receiver) or a router as the result of state timeout • Two types of messages: • Path-teardown messagesdelete the path state (which deletes the • reservation state), travel toward all receivers downstream from the point of initiation, and are routed like path messages • Reservation-request teardown messagesdelete the reservation state, travel toward all matching senders upstream from the point of teardown initiation, and are routed like corresponding reservation-request messages

  25. RSVP Packet Format • An RSVP Packet Format Consists of Message Headers and Object Fields RSVP message header RSVP object fields

  26. RSVP message header fields : Version : A 4-bit field indicating the protocol version number (currently version 1) Flags : A 4-bit field with no flags currently defined. Type : An 8-bit field with six possible (integer) values Checksum : A 16-bit field representing a standard checksum over the RSVP message Length : A 16-bit field representing the length of this RSVP packet in bytes, including the common header and the variable-length objects that follow Send TTL : An 8-bit field indicating the IP time-to-live (TTL) value with which the message was sent Message ID : A 32-bit field providing a label shared by all fragments of one message from a given next/previous RSVP hop More fragments (MF) flag : Low-order bit of a 1-byte word with the other 7 high-order bitsspecified as reserved. MF is set on for all but the last fragment of a message. Fragment offset : A 24-bit field representing the byte offset of the fragment in the message

  27. RSVP Object Fields Length : Is a 16-bit field containing the total object length in bytes (must always be a multiple of 4 and must be at least 4) Class-num : Identifies the object class. Each object class has a name. An RSVP implementation must recognize the classes. The high-order bit of the Class-Num field determines what action a node should take if it does not recognize the Class-Num of an object C-type : Object type, unique within Class-Num. The maximum object content length is 65528 bytes. The Class-Num and C-Type fields (together with the flag bit) can be used together as a 16-bit number to define a unique type for each object

  28. RSVP Object Fields Object contents : The Length, Class-Num, and C-Type fields specify the form of the object Content Classes of objects that can be included in the object contents

  29. IntServ, Integrated Services

  30. IntServ, Integrated Services

  31. IntServ, Integrated Services (RFC-2210, 2211,2212,2215) • Provides for a rich end-to-end QoS solution, by way of end-to-end signaling, state-maintenance (for each RSVP-flow and reservation), and admission control at each network element • Based on traffic control mechanisms • •Signalization protocol: RSVP(typically, but not necessarily) • •Reservation at the router level • Signaled request for network resources along path • Applications: • VoIP • Video over IP or ATM • MPLS Traffic Engineering

  32. IntServ, Integrated Services • By using RSVP signaling, network devices provisioned for the average expected load • In the rare occasion that load exceeds expectations, additional sessions will be rejected, but the integrity of the guarantees offered to existing sessions will be maintained

  33. IntServ Components • TSpec • Specification of WHAT the sender is sending (Rate,MTU,etc.) • RSpec • Specification of WHAT the receiver needs (Bandwidth,Path MTU, etc.) • RSVP, Resource ReSerVation Protocol • Specification of how the signalling is done to the network by the sender and the receiver

  34. Classes of Service for IntServ • Guaranteed Service (Premium service) • Application required fixed delay bound (CBR, RT-VBR) • Controlled-Load Service (Olympic service) • Applications requiring reliable and enhanced best-effort service (NRT-VBR, GFR, ABR) • Null service • No respect of time constraints (UBR), but a better best-effort service

  35. IntServ - Pros • Fairly automatic QoS! Only thing to provision is RSVP bandwidth on interfaces • Integrates well with a policy infrastructure (COPS—Common Open Policy Service) • Microflow granularity for QoS • VoIP and video work great with the DiffServ EF PHB • But … DiffServ has no concept of a call • Admission control may be necessary • Use of RSVP for: Signaling resources for a call and Maintaining and tearing down resources

  36. IntServ - Cons • State and signalling overhead for large networks • Constant refresh messages • Per-flow Classification,Policing,Queuing, and Scheduling is a • significant overhead with very large # of flows

  37. IntServ - Cons • For every microflow router need to: • Identify and categorize it • Maintain one queue • An entry in a database • These cause: • High CPU load • High memory consumption • Scalability problem • Also • All routers must have RSVP • There is no policy for the reservation control • Stations must support signalization => small networks

  38. DIFFERENTIATED SERVICES (DIFFSERV)

  39. Why Differentiated Services ? • Using Resource Reservation we raise the QE, quality/efficiency • product of the network • Higher quality guarantees and more efficient use of network resources • The more sophisticated a QoS mechanism, the more raise of QE • QoS mechanisms come at a cost in increased overhead, associated with supporting the QoS mechanism itself • More processing resources in network devices • Any QoS mechanism should be evaluated in terms of the benefit it brings in terms of increased QE product versus the cost it brings

  40. Why Differentiated Services ? • IntServ is a resource reservation technology • In central network nodes number of simultaneous flows may exceed hundred thousand • If each flow lasts for 10 seconds, then more than 10,000 flows per second are passing • A largetelephone exchange can handle up to a few hundred calls per second • Maintaining per flow state information becomes infeasible in core routers • Time needed to look updatabase entry for 5-tuple in each packet is considerable overhead compared for normal destination address lookup • Solution : Use a per-packet stateless information

  41. DS, Differentiated Service architecture • Traffic is classified at edges of the network • At the edge, each datagram is assigned to one of behavior aggregates which are identified by DSCodepoints • A 6-bit bit-pattern (called the Differentiated Services Code Point, DSCP) in the IPv4 ToS Octet or the IPv6 Traffic Class Octet is used to divide packets to service classes • •Complex mechanisms are implemented only on boundary nodes • •Complexity depends on the number of different services • •SLA between the client and the provider which specifies for each service the amount of traffic that can be sent • •DiffServ scalability comes from the aggregation of the traffic • At the core, packets are forwarded according to the PHB,Per-Hop Behavior) associatedwith the DS codepoint

  42. DS, Differentiated Service architecture • A DiffServ Domain is a logical IP network where PHB definitionsare applied consistently across router hops

  43. DiffServ Model (RFC-2474,2475,2597,2598) • The idea is very simple, offer service levels for packets: Gold, Silver, Bronze, etc… • RFC-2475: Service is : • “Some significant characteristics of packet transmission in one direction across a set of one or more paths within a network (e.g.: Bandwidth,Latency,etc..)” • Packets of a particular service are referred to as packets of a particular “class” • Meaningful services constructed using PHB, Per-Hop Behaviors

  44. DiffServ Model • TCB, Traffic Conditioner Block • Classifier: Identifies packets for assignment to Classes • •Meter: Checks compliance to traffic parameters (Token Bucket) and passes result to Marker and Shaper/Dropper to trigger particular action for in/outof-profile packets • •Marker: Writes/rewrites the DSCP value • •Shaper: Delays some packets for them to be compliant with the profile • •Dropper: Drops packets that exceed the profile (Bc or Be)

  45. DiffServ At the Ingress Network-Edge: TCB, Traffic Conditioning Block 1) Classify the packets into ‘Classes’ 2) Mark (Color) the packets for purposes of classification in the core 3) Optionally meter a class 4) If performing (3), police or shape the class (at network ingress and/or egress) 5) Queue and/or drop packets toward the core In the network core: (implementing the PHB) 6) Queue and/or drop packets

  46. DiffServ Architecture (RFC-2475)

  47. DiffServ Architecture(RFC-2475)

  48. DiffServ Architecture (RFC-2475)

  49. DiffServ Traffic Conditioner Block (TCB) Classifier: selects a packet in a traffic stream based on the content of some portion of the packet header Meter: checks compliance to traffic parameters (e.g., Token Bucket) and passes results to marker and shaper/dropper totrigger action for in/out-of-profile packets Marker: writes/rewrites the DSCP value Shaper: delay some packets for them to be compliant with the profile

  50. How DiffServ Works? • Classifying Packets into Classes • The most popular techniques: • Incoming/outgoing interface • All/any IP traffic • Standard or extended access control list • IP RTP ports (real-time traffic) • Source/destination MAC address • DSCP or IP precedence value (If trusted and marked appropriately) • MPLS EXP (Experimental bits, If trusted and marked appropriately) • NBAR, Network-Based Application Recognition • E.g.: all VoIP (RTP) packets between UDP ports 16384 and 16484 belong to the “Premium Class”

More Related