Internet Draft David Durham Expiration: December 1999 Intel File: draft-durham-pe-rstatus-00.txt Shai Herzog IPHighway RSVP Reservation Status Policy Element for End-to-End Accounting June 25, 1999 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document details an RSVP Policy Element that provides a mechanism by which RSVP reservation establishment can be reliably confirmed, end-to-end. This Policy Element provides a status update with each PATH message refresh, useful for determining the lifetime of a reservation end-to-end. Such a policy element will be useful for accounting and billing applications that are interested in reliably knowing when a reservation has been successfully established end-to-end and when a reservation is finally removed. Internet Draft Expires December 1999 [Page 1] Internet Draft Reservation Status Policy Element 25-Jun-99 Table of Contents Abstract..............................................................1 Table of Contents.....................................................2 1 Introduction.......................................................3 2 Format of the Reservation Status Policy Element (RSPE).............4 2.1 Format of the RESV message's Request RSPE........................4 2.2 Format of the PATH message's RSPE................................4 3 A Simple Scenario..................................................7 4 PDP Usage Model....................................................8 5 Authoritative CPs..................................................9 6 Security Considerations............................................9 7 References........................................................10 8 Author Information................................................10 David Durham Expires December 1999 [Page 2] Internet Draft Reservation Status Policy Element 25-Jun-99 1 Introduction In RSVP, the Reservation Confirmation (RESV Confirm) message is used to provide a one-time indication that a reservation has been successfully established between a destination and the source or merge point. The problem with the RESV Confirm is that this message is not reliable. It is sent once in reply to the original Reservation (RESV) message sent by the destination. The network may loose the RESV Confirm, and due to the fact it is not sent with every refresh, the destination may never receive the indication. Furthermore, the RESV Confirm only provides an indication that a reservation was successfully received by the source or first merge point. It does not provide an indication of reservation state timeout or state preemption along the end-to-end reserved data path (the equivalent of a Unconfirm Message). Finally, the RESV Confirm message is sent by unicast directly from the source or merge point to the destination that issued the CONF message. Thus, intermediate hops, including their Policy Decision Points (PDP) or Bandwidth Brokers (BB), will never receive the RESV Confirm indication. For purposes of accounting and billing for end-to-end reservation establishment, there needs to be a reliable mechanism to determine when a reservation has been successfully installed along the data path, and when such a reservation is lost to determine its duration. To facilitate such a capability, this specification introduces new Policy Data Element carried by PATH and RESV messages that can provide end-to-end status information on the state of upstream reservations. This policy element is the Reservation Status Policy Element (RSPE). For better scalability, the RSPE exchange is triggered on-demand by downstream entities, by placing an RSPE in RESV messages. The reservation status is sent back with PATH messages. The RSPE assumes a network infrastructure whereby neighboring hops or bordering networks have bilateral relationships (and can authenticate each other). This creates a hop-by-hop or network-by- network chain of security whereby a bordering network can present its status information as well as the culmination of all status information from all upstream networks along the data path. The RSPE is generated by Confirmation Points (CP) for a network along the data path. Every hop along the data path can be a CP, but a CP will typically be a PDP that knows the status of its network as well as any relevant upstream networks with which it has a bilateral relationship. An authoritative CP sends the first PATH with RSPE in it. This status is then passed onto downstream networks for which the CP also has a bilateral relationship. Each CP updates the RSPE according to its own status, and eventually the status of a reservation end-to-end may be ascertained by the receiver of the RSPE. David Durham Expires December 1999 [Page 3] Internet Draft Reservation Status Policy Element 25-Jun-99 2 Format of the Reservation Status Policy Element (RSPE) The Reservation Status Policy Element is carried in either PATH or RESV messages depending on its subtype. It is used in RESV messages to request reservation status information from upstream hops. It is then used in PATH messages to provide the upstream status information back to the downstream hops. Policy Element Type Number = 10 2.1 Format of the RESV message's Request RSPE The this PE is used to request the generation of Reservation Status from upstream CPs. It is carried in RESV messages in the Policy Data Object. As long as a destination (or intermediate hop) is interested in a reservation's status, it should continue to provide the RSPE in its RESV refreshes. 0 1 2 3 +--------------+--------------+--------------+--------------+ | PE Length | PE-Type = RSPE | +--------------+--------------+-----------------------------+ | Sub-Type = 1 | Request Flags| //////////////////////// | +--------------+--------------+-----------------------------+ Note: //// implies field is all zeros. Request Flags: 0x01 = Non-immediate Response When the Non-Immediate Response is set, the Authoritative CP may delay the response until a refresh PATH message is sent. This may reduce the overhead of sending an immediate PATH update. 2.2 Format of the PATH message's RSPE The RSPE is carried in the Policy Data object of a PATH message. It is created by the source itself, or a PDP close to the data source acting as a confirmation point. The RSPE is updated by each downstream CP with which it comes into contact. David Durham Expires December 1999 [Page 4] Internet Draft Reservation Status Policy Element 25-Jun-99 0 1 2 3 +--------------+--------------+--------------+--------------+ | PE Length | PE-Type = RSPE | +--------------+--------------+-----------------------------+ | Sub-Type = 2 | Status Flags | //////////////////////// | +--------------+--------------+-----------------------------+ | End-to-End Resv Duration | +--------------+--------------+-----------------------------+ | CP Timestamp | +-----------------------------+-----------------------------+ | CP Addr Type | CP Addr Length | +-----------------------------+-----------------------------+ | CP Address | +-----------------------------+-----------------------------+ Status Flags: The RSPE status flags describe the reservation status. 0x01 = Reservation Installed. 0x02 = Unconfirmed Segments. If no reservation was yet received, the Reservation Installed flag will NOT be set. If a reservation was received and was successfully installed by the current CP and all upstream CPs (if any) since the last refresh period, the Reservation Installed flag will be set. If the reservation state was removed at the CP, the Reservation Installed flag will NOT be set. The Unconfirmed Segments flag indicates that the status of some parts of the data path cannot be ascertained. This may be because an intermediate network does not participate in the RSPE exchange, or that the RSPE was not included in PATH messages from some upstream segments. As RSPE's are passed via PATH messages CP-to-CP down the data path, a downstream CP is also responsible for relaying the cumulative RSPE status of its upstream CPs. The Reservation Installed status flag may be updated by the downstream CP to reflect its local reservation state. It can only be set by the downstream CP, however, if the upstream CP had it set already and the downstream CP has successfully installed a corresponding reservation. If the Unconfirmed Segments status flag was set in an upstream RSPE, all downstream nodes must leave the flag set in their forwarded RSPEs. A CP will set the Unconfirmed Segments flag if no RSPE was provided by any upstream CP (and the current CP is not the source), or if the RSPE was generated by an unknown upstream CP (based on the RSPE's CP Address field). An upstream CP is unknown if it David Durham Expires December 1999 [Page 5] Internet Draft Reservation Status Policy Element 25-Jun-99 does not match any administratively configured upstream CPs in the current CP's database, or the received RSPE's CP Address field doesn't match the PHOP's address. End-to-End Reservation Duration. This value is determined by taking the MINIMUM of the current CP's reservation duration, and the upstream CP's End-to-End Uninterrupted reservation duration (if the upstream hop provided the RSPE in its PATH). The current CP's reservation duration is the duration that the reservation state has been installed at the current CP. This period is specified in seconds, initially set to zero. When a reservation state is in any way removed at the CP, this period counter will stop (and maintain the last known duration). If the reservation state is reinstalled, this field will be reset to zero and begin counting seconds again. CP Timestamp. This field is zero until a reservation is successfully installed end-to-end. This is the current time in seconds that the CP last set its RSPE's status to Reservation Installed. When a reservation is removed, the CP Timestamp remains set to the last time a reservation was successfully installed end-to-end. The time is defined in seconds since midnight GMT 1/1/1970 (system clock time). Confirmation Point (CP) Address Type. Determines the type of the address used to identify the confirmation point. The currently defined values are: 0x00 = No Address 0x01 = IPv4 Address 0x02 = IPv6 Address 0x03 = DNS Address CP Address Length. Length in bytes of the CP's address. For IPv4 addresses the length must be 4 bytes. For IPv6 addresses the length must be 16 bytes. For DNS Addresses, the length must not exceed 255 bytes of ASCII characters including a NULL terminator. A DNS address must be aligned to a 4 byte boundary using NULL characters. CP Address. David Durham Expires December 1999 [Page 6] Internet Draft Reservation Status Policy Element 25-Jun-99 This is the IP address of the upstream confirmation point that last updated the RSPE. 3 A Simple Scenario This simple scenario assumes that all RSVP aware hops are CP's and can interpret the RSPE object. The data source is assumed as an Authoritative CP (since it can confirm that the RESV reached the source and was installed). First, a requester generates a RSPE Type-1, and places it in its Outgoing RESV message. Intermediate CPs are expected to forward the PE Type-1 upstream as-is. When the Authoritative CP (source) receives a RESV message containing an RSPE Type-1, requesting status, it is expected to respond by inserting an RSPE Type-2 with the appropriate status information in an updated PATH message and all its subsequent PATH refreshes. The Installed Reservation flag should be set in the RSPE if the reservation was installed, specifying that the path is reserved. The timestamp provides the time the reservation was installed. Once installed, the duration timer should be used to record the duration that the reservation remains. This is the duration (in seconds) that the reservation has been installed, uninterrupted. Uninterrupted implies that the reservation was never removed in any way, preempted, or timed-out. It is not particularly valuable to simply know that the source has installed a reservation. This is because intermediate nodes may have since lost or preempted their reservation state. Also, there may be no trust relationship between the administrative domain of the source and that of the destination (multilateral relationships are hard to maintain). Furthermore, for a multicast session, a reservation state close to the source could be associated with any number of possible destinations. While some destinations may have successfully issued a reservation that was installed end-to-end, reservations from other destinations for the same session may have failed. Ideally, all the hops for a RESV message should be able to participate in the reservation status exchanges. Each hop's RSPE status will depend on the status contained in the PATH messages from the previous upstream PHOP as well as the current hop's status. Effectively, the RSPE can be manipulated hop-by-hop. Subsequent hops will examine and modify the RSPE in PATH messages from the previous hops before forwarding the RSPE on downstream. Specifically, the upstream reservation status flags field is updated with the status of the reservation state at the current hop. If the CP Address specified in the RSPE of the PHOP is different from the address of the PHOP specified in the PATH message, then the David Durham Expires December 1999 [Page 7] Internet Draft Reservation Status Policy Element 25-Jun-99 Unconfirmed Segments flag should be set in the forwarded RSPE (as one or more intermediate nodes did not participate in the RSPE exchange). For the updated RSPE, the timestamp will describe the time that Reservation Installed status flag was first set by the current hop (and, thus, was set by the upstream hops as well). Additionally, the current hop keeps a local duration counter for the lifetime of the local reservation state. The current hop will compare its local duration counter with the value of the End-to-End Duration specified in the PHOP's RSPE. The minimum of these two values is then passed in the forwarded PATH's RSPE. Finally, the current hop will insert the HOP address corresponding to the interface out which the PATH carrying the RSPE is forwarded. This is then used by the subsequent NHOP to verify there are no unconfirmed segments. If a reservation state is lost anywhere along the data path, the nodes where the reservation state is lost should stop their duration counters and unset the Reservation Installed flag in the forwarded RSPE. This frozen duration will continue to be supplied in future PATH refreshes by the now unreserved node including the timestamp of the last time the reservation was successfully installed end-to-end. If a reservation state is reinstalled the Reservation Installed flag can be set again, the timestamp updated to the current time, and the local duration counter reset to zero and begin counting the duration of this reservation state. Updates to RSPEs can wait for the next scheduled PATH refresh so as not to generate a new PATH message with each local state change. 4 PDP Usage Model It is likely that the above procedure will be too expensive or technically hard to achieve in all RSVP nodes. It would be more realistic to assume that RSPE processing would be limited to PDP's operating at the edges of networks. In this case, PDPs represent a set of RSVP nodes in their controlled network. Although not foolproof, PDP's can be used to verify the previous (upstream) CP's status, and integrate this status with its own. As such, a chain of trust can be setup whereby scalable verification of the end-to-end establishment of reservations is possible on a domain-by-domain basis. In order to allow this model PDPs within a network must be configured to be confirmation points for their domain. They will have to know which nodes are within their domain. Furthermore, the PDP will have to be configured with the addresses of all CPs in other domains with which it has bilateral relationships. If the source of the corresponding PATH message is within the PDP's domain, it is considered an Authoritative CP. An Authoritative CP is the only CP that may respond to an incoming RESV with RSPE Type-1, David Durham Expires December 1999 [Page 8] Internet Draft Reservation Status Policy Element 25-Jun-99 with an outgoing PATH with RSPE Type-2. An authoritative CP provides the status on behalf of the source. The upstream and downstream procedure is the same as in the hop-by- hop approach, but between PDPs rather than hop-by-hop. The only difference is that the RSPE CP Address field is verified against the configured addresses of neighboring PDP CPs (as opposed to just the RSVP PHOP address). If a PATH contains a RSPE from an unknown PDP (based on the CP Address), then the Unsupported Segments flag must be set before the RSPE is forwarded downstream. The forwarded RSPE's CP Address field must contain the IP Address of the PDP that created/modified the RSPE. 5 Authoritative CPs If the source is a CP, it is always an authoritative CP. However, if the Source does not respond to RSPE, the PDP controlling the domain in which the source is located should be configured as the authoritative CP. If both the source and the PDP are authoritative (or in any other case where multiple CPs are authoritative) the most upstream one wins. When an Authoritative CP sees a RSPE Type-2 in the Incoming PATH, it looses its authority and acts as a regular CP. It may regain this authority when the RSPE Type-2 expires and a new one wasn't received. There may be cases, where there is no authoritative CP to respond, for example, if the source doesn't recognize RSPEs, and no PDP was configured as the source's authoritative CP. In this case, the absence of an RSPE in subsequent PATH messages implies there are unconfirmed segments. After one full timeout period has expired someone needs to reply with an RSPE specifying the Unconfirmed Segments status. This someone would be any CP that has seen one timeout period since it first encountered an RSPE Type-1 object, without seeing an RSPE Type-2 response in return. RSPEs, and any other Policy Data object expire at the same time as other RSVP state [RSVP] and, therefore, must be continuously refreshed. 6 Security Considerations The RSPE is protected by RSVP integrity and Policy Data Integrity mechanisms [RSVP, RSVP-EXT]. There is an underlying assumption that none of the intermediate CPs are malicious. CPs are either trusted (intra-net) or bound by a set of bilateral agreements between neighboring CPs such that sanctions may take place by one neighbor is the other is falsifying RSPE contents. David Durham Expires December 1999 [Page 9] Internet Draft Reservation Status Policy Element 25-Jun-99 7 References [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission Control",IETF , Jan., 1999. [RSVP-EXT] Shai Herzog "RSVP Extensions for Policy Control" , April, 1999. [COPS] Boyle, J., et al. "Common Open Policy Service (COPS)" , Feb., 1999. [RSVP]Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) Version 1 - Functional Specification", RFC 2205, September 1997. 8 Author Information David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124 503.264.6232 David_Durham@mail.intel.com Shai Herzog IPHighway Inc. Parker Plaza, 16th Floor 400 Kelby St. Fort-Lee, NJ 07024 201.585.0800 Herzog@iphighway.com David Durham Expires December 1999 [Page 10]