upper protocol ——RSVP

Resource reservation protocol

The Resource ReSerVation Protocol (RSVP), described in RFC 2205, is a Transport layer protocol designed to reserve resources across a network for an integrated services Internet. "RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols" - RFC 2205. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows with scaling and robustness.

RSVP can be used by either hosts or routers to request or deliver specific levels of quality of service (QoS)for application data streams or flows. RSVP defines how applicationsplace reservations and how they can relinquish the reserved resourcesonce the need for them has ended. RSVP operation will generally resultin resources being reserved in each node along a path.

RSVP is not itself a routing protocol and was designed to interoperate with current and future routing protocols.

RSVP by itself is rarely deployed in telecommunications networks today^{[citation needed]} but the traffic engineering extension of RSVP, or RSVP-TE, is becoming more widely accepted nowadays in many QoS-oriented networks.

 

Contents

• 1 Main attributes
• 2 History and related standards
• 3 Key concepts
  • 3.1 Flowspec
  • 3.2 Filterspec
• 4 Messages
• 5 Operation
• 6 Other features
• 7 References
• 8 External links
  • 8.1 RFCs

    Main attributes

1. RSVP requests resources for simplex flows: a traffic stream in only one direction from sender to one or more receivers.
2. RSVP is not a routing protocol but works with current and future routing protocols.
3. RSVP is receiver oriented: in that the receiver of a data flow initiates and maintains the resource reservation for that flow.
4. RSVP maintains soft state (the reservation at each nodeneeds a periodic refresh) of the host and routers' resourcereservations, hence supporting dynamic automatic adaptation to networkchanges.
5. RSVP provides several reservation styles (a set of reservationoptions) and allows for future styles to be added to protocol revisionsto fit varied applications.
6. RSVP transports and maintains traffic and policy control parameters that are opaque to RSVP.

   History and related standards

    RSVP is described in a series of RFC documents from the IETF:

• RFC 2205: The version 1 functional specification was described in RFC 2205 (Sept. 1997) by IETF. Version 1 describes the interface to admission (traffic) control that is based "only" on resource availability. Later RFC2750 extended the admission control support.
• RFC 2210 defines the use of RSVP with controlled-load RFC 2211 and guaranteed RFC 2212 QoS control services. More details in Integrated Services. Also defines the usage and data format of the data objects (that carry resource reservation information) defined by RSVP in RFC 2205.
• RFC 2211 specifies the network element behavior required to deliver Controlled-Load services.
• RFC 2212 specifies the network element behavior required to deliver guaranteed QoS services.
• RFC 2750 describes a proposed extension for supporting generic policy basedadmission control in RSVP. The extension included a specification ofpolicy objects and a description on handling policy events. (January2000).
• RFC 3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (December 2001).
• RFC 3473,"Generalized Multi-Protocol Label Switching (GMPLS) Signaling ResourceReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (January2003).
• RFC 3936,"Procedures for Modifying the Resource reSerVation Protocol (RSVP)"(October 2004), describes current best practices and specifiesprocedures for modifying RSVP.
• RFC 4495,"A Resource Reservation Protocol (RSVP) Extension for the Reduction ofBandwidth of a Reservation Flow" (May 2006), extends RSVP to enable thebandwidth of an existing reservation to be reduced instead of tearingdown the reservation.
• RFC 4558, "Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement" (June 2006).

    Key concepts

     The two key concepts of RSVP reservation model are flowspec and filterspec:

    Flowspec

RSVP reserves resources for a flow. A flow is identified by thedestination address, the protocol identifier, and, optionally, thedestination port. In MPLS a flow is defined as a LSP.For each flow RSVP also identifies the particular quality of servicerequired by the flow although it does not understand the specificinformation of the flow QoS. This QoS specific information is called a flowspec and RSVP passes the flowspec from the application to the hosts and routers along the path. Those systems then analyse the flowspec to accept and reserve the resources. A flowspec consists of:

1. Service class
2. Reservation spec - defines the QoS
3. Traffic spec - describes the data flow

   Filterspec

The filterspec defines the set of packets that shall be affected by a flowspec (i.e. the data packets to receive the QoS defined by the flowspec). A filterspectypically selects a subset of all the packets processed by a node. Theselection can depend on any attribute of a packet (e.g. the sender IPaddress and port).

The currently defined RSVP reservation styles are:

1. Fixed filter - reserves resources for a specific flow.
2. Shared explicit - reserves resources for several flows and all share the resources
3. Wildcard filter - reserves resources for a general type of flow without specifying the flow; all flows share the resources

An RSVP reservation request consists of a flowspec and a filterspec and the pair is called a flowdescriptor. The effects at the node of each spec are that while the flowspec sets the parameters of the packet scheduler at a node, the filterspec sets the parameters at the packet classifier.

    Messages

There are two primary types of messages:

• Path messages (path)

The path message is sent from the sender host along the data path and stores the path state in each node along the path.

The path state includes the IP address of the previous node, and some data objects:

1. sender template to describe the format of the sender data
2. sender tspec to describe the traffic characteristics of the data flow
3. adspec that carries advertising data (see RFC 2210 for more details).

• Reservation messages (resv)

The resv message is sent from the receiver to the senderhost along the reverse data path. At each node the IP destinationaddress of the resv message will change to the address of thenext node on the reverse path and the IP source address to the addressof the previous node address on the reverse path.

The resv message includes the flowspec data object that identifies the resources that the flow needs.

The data objects on RSVP messages can be transmitted in any order. For the complete list of RSVP messages and date objects see RFC 2205.

    Operation

An RSVP host that needs to send a data flow with specific QoS will transmit an RSVP path message that will travel along the unicast or multicast routes pre-established by the working routing protocol. If the pathmessage arrives at a router that does not understand RSVP, that routerforwards the message without interpreting the contents of the messageand will not reserve resources for the flow.

When the destination router receives the path message it will:

1. Make a reservation based on the request parameters. For this the admission control and policy controlprocess the request parameters and can either instruct the packetclassifier to correctly handle the selected subset of data packets ornegotiate with the upper layer how the packet handling should beperformed.
2. Forward the request upstream (in the direction of the sender). At each node the resv message flowspeccan be modified by a forwarding node (e.g. in the case of a multicastflow reservation the reservations requests can be merged).

The Resv message also has FilterSpec object; it defines the packetsthat will receive the requested QoS defined in the flowspec. A simplefilter spec could be just the sender’s IP address and optionally itsUDP or TCP port.

Each node in the path can either accept or reject the request.

    Other features

• Integrity - RSVP messages are appended with a message digestcreated by combining the message contents and a shared key using amessage digest algorithm (commonly MD5). The key can be distributed and confirmed using 2 message types: integrity challenge request and integrity challenge response.
• Error reporting - when a node detects an error, an error message isgenerated with an error code and is propagated upstream on the reversepath to the sender.
• Information on RSVP flow - two types of diagnostic messages allow anetwork operator to request the RSVP state information on a specificflow.
• Diagnostic facility - An extension to the standard which allows auser to collect information about the RSVP state along a path. RFC2745 - RSVP Diagnostic Messages

    References

• "Deploying IP and MPLS QoS for Multiservice Networks: Theory andPractice" by John Evans, Clarence Filsfils (Morgan Kaufmann, 2007, ISBN 0-12-370549-5)

    External links

• RSVP Project of USC Information Science Institute
• Resource Reservation Protocol Cisco chapter

    RFCs

• RFC 2205
• RFC 2210
• RFC 2211
• RFC 2212