3 minutes catch up the Resource Reservation Protocol
There are a large number of intermediate nodes in the Internet. If the user uses a connectionless protocol to transmit a data stream, each datagram of the data stream may cause two problems when it is forwarded through an intermediate node. One is that the forwarding path of each datagram is different and does not arrive at the destination in order. Some data Packets may arrive late; second, when data packets are queued at intermediate nodes for forwarding, their queuing time is uncertain, and when intermediate nodes are congested due to lack of resources, packet loss strategies will be adopted to divert traffic. For end-to-end communication, it means transmission delay and delay jitter.
These are all disadvantages for multimedia communication, and seriously affect the service quality of end-to-end multimedia communication. The basic method to solve this problem is that the endpoint and the intermediate node should cooperate closely, based on the connectionless protocol, establish a fixed transmission path for a specific data stream, reserve system resources for it, and limit the transmission delay to a specified range to ensure Improve the quality of service of end-to-end multimedia communication. RSVP (Resource Reservation Protocol) proposed by IETF is based on the above method.
Generally, RSVP requests will cause resource reservation on the data path of each node.
RSVP only makes resource requests in one direction. Therefore, although the same application program may act as both a sender and a receiver, RSVP has a logical difference between the sender and the receiver. RSVP runs on the upper layer of IPV4 or IPV6 and occupies the space of the transmission protocol in the protocol stack.
RSVP does not transmit application data, but supports Internet control protocols such as ICMP, IGMP, or routing protocols. Just like the implementation of routing and management protocols, the operation of RSVP is also executed in the background, not on the data forwarding path.
RSVP is not essentially a routing protocol. The design goal of the RSVP protocol is to run simultaneously with current and future unicast and multicast routing protocols. The RSVP process refers to the local routing database to obtain the transmission path. Taking multicast as an example, the host sends IGMP information to join the multicast group, and then sends RSVP information along the multicast group transmission path to reserve resources.
The routing protocol determines where the data packet is forwarded. RSVP only considers the QOS of the data packet forwarded based on routing. In order to effectively meet the needs of the receiving end of large groups, dynamic group members, and different models, through RSVP, the receiving end can request a specific QOS.
The QOS request is transmitted from the receiving end host application to the local RSVP process, and then the RSVP protocol follows the opposite data path to transmit this request to all nodes (routers and hosts), but only reaches the receiving end data path to join the multicast distribution The router when in the tree. Therefore, the RSVP reservation overhead is logarithmic and non-linear with the number of receivers.
Since RSVP packets must be propagated upstream, pass through all intermediate routers, and finally reach all sending hosts. However, the routing protocol lacks reverse routing information, so RSVP introduces the path message. All hosts participating in the multicast group as the sender must send a path message, which is transmitted to all multicast destinations via the distribution tree.
RSVP protocol resource reservation process
1. The source of sending data determines the bandwidth, delay and delay jitter required for sending the data stream, and includes it in the PATH packet and sends it to the receiving end.
2. When a router in the network receives a PATH packet, it stores the path state information in the PATH packet. The path state information describes the upper-level source address on the PATH packet (that is, the upper-level source address sent to the packet). One-hop router address).
3. After the receiving end receives the PATH packet, it follows a RESV packet in the direction opposite to the source path obtained in the PATH packet. The RESV packet contains QoS information such as traffic and performance expectations that need to be described for resource reservation for the data stream.
4. When a router receives a RESV packet, it uses admission control to determine whether there are enough resources to satisfy the QoS request. If so, reserve bandwidth and buffer space, and store some specific information related to the data stream, and then forward the RESV packet to the next router; if the router must reject the request, it returns an error to the receiver information.
The RSVP resource reservation message is initiated by the receiver and transmitted upstream at one time, where upstream is the direction from the receiver to the sender. At each node of the route, the resource reservation request will trigger the following two actions:
1. Resource reservation on the link
The RSVP Process on each node will pass the message requesting resource reservation to Admission Control and Policy Control. As long as any one of these two components fails in the detection of admissibility, the resource reservation request will be rejected; at the same time, the RSVP process generates an error message and sends it to the receiver. If both are successful, the node will also set the packet flow classifier accordingly, so that the reserved data packet can be selected from all the packets entering the router during the actual data flow transmission, and then for It provides QoS guarantee.
2. Forward the resource reservation request to the upstream node
The above is the news sharing from the PASSHOT. I hope it can be inspired you. If you think today' s content is not too bad, you are welcome to share it with other friends. There are more latest Linux dumps, CCNA 200-301 dumps, CCNP Written dumps and CCIE Written dumps waiting for you.
Comments
Post a Comment