Understanding of RSVP protocol

Today we will introduce the RSVP protocol. This agreement is still very important in some work areas, so learning this agreement is also helpful to some of our work. In order to control the Internet, we have defined many types of protocols to regulate so that the transmission between the host and the host can be completed. Here, we will introduce the RSVP protocol. Many of my friends are not very clear about this agreement.

Resource Reservation Protocol (RSVP) is a protocol used for quality integration services on the Internet. The RSVP protocol allows hosts to request special service quality over the network for transmission of special application data streams. The router also uses RSVP to send QOS requests to all nodes along the stream path) and establishes and maintains this status to provide the request service. Generally, RSVP requests will cause resource reservation on the data path of each node.

RSVP only requests resources in a single direction. Therefore, even though the same application may act as both the sender and receiver, however, the RSVP protocol logically distinguishes the sender and receiver. The RSVP runs on the IPV4 or IPV6 layer, occupying the transfer protocol space in the protocol stack.

RSVP does not transmit application data, but supports Internet control protocols, such as ICMP, IGMP, or route selection protocols. Just like the implementation of route selection and management protocols, RSVP is also executed in the background, not in the data forwarding path.

In essence, RSVP is not a route selection protocol. the RSVP is designed to run simultaneously with the current and future unicast and multicast. The RSVP process selects a database based on the local route to obtain the transfer path.

Taking multicast as an example, the host sends IGMP information to add multicast groups, and then sends RSVP information along the Multicast Group Transfer Path to reserve resources. The routing protocol determines where the data packet is forwarded.

RSVP only considers the QOS of the packets forwarded based on the route. To effectively meet the requirements of large groups, dynamic group members, and receivers of different types, the receiver can request a specific QOS [RSVP93] Through RSVP.

QOS requests are sent from the host application at the receiving end to the local RSVP process, and then the RSVP protocol transmits the request to all the node routers and hosts along the opposite data path ), but only the router that arrives at the receiving end and adds the data path to the multicast allocation tree. Therefore, the reserved RSVP overhead is a non-linear relationship between the number of receivers and the number of receivers.