📄 rfc2205.txt
字号:
Network Working Group R. Braden, Ed.Request for Comments: 2205 ISICategory: Standards Track L. Zhang UCLA S. Berson ISI S. Herzog IBM Research S. Jamin Univ. of Michigan September 1997 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional SpecificationStatus of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Abstract This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties.Braden, Ed., et. al. Standards Track [Page 1] RFC 2205 RSVP September 1997Table of Contents 1. Introduction ................................................... 4 1.1 Data Flows ................................................. 7 1.2 Reservation Model .......................................... 8 1.3 Reservation Styles .........................................11 1.4 Examples of Styles .........................................14 2. RSVP Protocol Mechanisms .......................................19 2.1 RSVP Messages ..............................................19 2.2 Merging Flowspecs ..........................................21 2.3 Soft State .................................................22 2.4 Teardown ...................................................24 2.5 Errors .....................................................25 2.6 Confirmation ...............................................27 2.7 Policy Control .............................................27 2.8 Security ...................................................28 2.9 Non-RSVP Clouds ............................................29 2.10 Host Model ................................................30 3. RSVP Functional Specification ..................................32 3.1 RSVP Message Formats .......................................32 3.2 Port Usage .................................................47 3.3 Sending RSVP Messages ......................................48 3.4 Avoiding RSVP Message Loops ................................50 3.5 Blockade State .............................................54 3.6 Local Repair ...............................................56 3.7 Time Parameters ............................................57 3.8 Traffic Policing and Non-Integrated Service Hops ...........58 3.9 Multihomed Hosts ...........................................59 3.10 Future Compatibility ......................................61 3.11 RSVP Interfaces ...........................................63 4. Acknowledgments ................................................76 APPENDIX A. Object Definitions ....................................77 APPENDIX B. Error Codes and Values ................................92 APPENDIX C. UDP Encapsulation .....................................98 APPENDIX D. Glossary .............................................102 REFERENCES .......................................................111 SECURITY CONSIDERATIONS ..........................................111 AUTHORS' ADDRESSES ...............................................112Braden, Ed., et. al. Standards Track [Page 2] RFC 2205 RSVP September 1997 What's Changed This revision contains the following very minor changes from the ID14 version. o For clarity, each message type is now defined separately in Section 3.1. o We added more precise and complete rules for accepting Path messages for unicast and multicast destinations (Section 3.1.3). o We added more precise and complete rules for processing and forwarding PathTear messages (Section 3.1.5). o A note was added that a SCOPE object will be ignored if it appears in a ResvTear message (Section 3.1.6). o A note was added that a SENDER_TSPEC or ADSPEC object will be ignored if it appears in a PathTear message (Section 3.1.5). o The obsolete error code Ambiguous Filter Spec (09) was removed, and a new (and more consistent) name was given to error code 08 (Appendix B). o In the generic interface to traffic control, the Adspec was added as a parameter to the AddFlow and ModFlow calls (3.11.2). This is needed to accommodate a node that updates the slack term (S) of Guaranteed service. o An error subtype was added for an Adspec error (Appendix B). o Additional explanation was added for handling a CONFIRM object (Section 3.1.4). o The rules for forwarding objects with unknown class type were clarified. o Additional discussion was added to the Introduction and to Section 3.11.2 about the relationship of RSVP to the link layer. (Section 3.10). o Section 2.7 on Policy and Security was split into two sections, and some additional discussion of security was included. o There were some minor editorial improvements.Braden, Ed., et. al. Standards Track [Page 3] RFC 2205 RSVP September 19971. Introduction This document defines RSVP, a resource reservation setup protocol designed for an integrated services Internet [RSVP93, RFC 1633]. The RSVP protocol is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality-of-service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows, i.e., it requests resources in only one direction. Therefore, RSVP treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. However, RSVP does not transport application data but is rather an Internet control protocol, like ICMP, IGMP, or routing protocols. Like the implementations of routing and management protocols, an implementation of RSVP will typically execute in the background, not in the data forwarding path, as shown in Figure 1. RSVP is not itself a routing protocol; RSVP is designed to operate with current and future unicast and multicast routing protocols. An RSVP process consults the local routing database(s) to obtain routes. In the multicast case, for example, a host sends IGMP messages to join a multicast group and then sends RSVP messages to reserve resources along the delivery path(s) of that group. Routing protocols determine where packets get forwarded; RSVP is only concerned with the QoS of those packets that are forwarded in accordance with routing. In order to efficiently accommodate large groups, dynamic group membership, and heterogeneous receiver requirements, RSVP makes receivers responsible for requesting a specific QoS [RSVP93]. A QoS request from a receiver host application is passed to the local RSVP process. The RSVP protocol then carries the request to all the nodes (routers and hosts) along the reverse data path(s) to the data source(s), but only as far as the router where the receiver's data path joins the multicast distribution tree. As a result, RSVP's reservation overhead is in general logarithmic rather than linear in the number of receivers.Braden, Ed., et. al. Standards Track [Page 4] RFC 2205 RSVP September 1997 HOST ROUTER _____________________________ ____________________________| _______ | | || | | _______ | | _______ || |Appli- | | | |RSVP | | | || | cation| | RSVP <---------------------------> RSVP <---------->| | <--> | | | _______ | | || | | |process| _____ | ||Routing| |process| _____ || |_._____| | -->Polcy|| || <--> -->Polcy||| | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl||| |data | | |_____|| ||__.____| | | |_____|||===|===========|==|==========| |===|==========|==|==========|| | --------| | _____ | | | --------| | _____ || | | | ---->Admis|| | | | | ---->Admis||| _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||| | | | | |_____|| | | | | ||_____||| |Class-| | Packet | | | |Class-| | Packet | || | ifier|==>Schedulr|================> ifier|==>Schedulr|===========>| |______| |________| |data | |______| |________| |data| | | ||_____________________________| |____________________________| Figure 1: RSVP in Hosts and Routers Quality of service is implemented for a particular data flow by mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. During reservation setup, an RSVP QoS request is passed to two local decision modules, "admission control" and "policy control". Admission control determines whether the node has sufficient available resources to supply the requested QoS. Policy controlBraden, Ed., et. al. Standards Track [Page 5] RFC 2205 RSVP September 1997 determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to obtain the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request. RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths. RSVP itself transfers and manipulates QoS and policy control parameters as opaque data, passing them to the appropriate traffic control and policy control modules for interpretation. The structure and contents of the QoS parameters are documented in specifications developed by the Integrated Services Working Group; see [RFC 2210]. The structure and contents of the policy parameters are under development. Since the membership of a large multicast group and the resulting multicast tree topology are likely to change with time, the RSVP design assumes that state for RSVP and traffic control state is to be built and destroyed incrementally in routers and hosts. For this⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -