Internet Draft M. Yuhara Expiration: October 1999 M. Tomikawa File: draft-yuhara-rsvp-refresh-00.txt Fujitsu Laboratories Ltd. April 1999 RSVP Extensions for ID-based Refreshes 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 The purpose of this document is to provide a discussion on the refresh overhead reduction of RSVP. Specifically, this document proposes some extensions to deal with route change while maintaining the advantage of ID-based refreshes. For environments where PATH refreshes must be used to detect route change, ID-only refreshes are used to decrease the message size. For environments where route change is informed to RSVP process by some other means, a new message is introduced to invalidate ID. 1. Introduction The combination of RSVP [RFC2205, RFC2209] and intserv [RFC2210, RFC2215] was proposed to provide better quality of service than traditional best effort service. When deploying this combination over the internet, however, there are several concerns [RFC 2208], and the scalability problem is regarded as the biggest problem. The Yuhara & Tomikawa Expiration: October 1999 [Page 1] Internet Draft RSVP ID-based Refresh April 1999 differentiated services (diffserv) [RFC2475] has challenged this problem. Diffserv is expected to replace the role of intserv in the internet backbones. However, to provide the end-to-end QoS, we still need an end-to-end signaling protocol, and the only usable signaling protocol now is RSVP. In fact, [Baker] and other drafts propose to use RSVP as a signaling protocol for diffserv. If we assume the aggregation region of [Baker] is a DS domain, RSVP will be used (a) between a DS boundary node of a DS domain and an external node which may be in a different DS domain or in an intserv domain, (b) between DS boundary nodes of the same DS domain (for individual reservation, bypassing interior nodes), (c) between two RSVP neighbor nodes within the same DS domain (for behavior aggregates). Because the number of diffserv codepoints and the number of boundary nodes are limited, (c) should not cause a scalability problem. Scalability problems in the case of (a) and (b), however, still exist. The refresh reduction draft [Berger] alleviates some of the problems using several techniques. The techniques include refresh suppression and packaging multiple RSVP messages into one message (called aggregate messages; should not be confused with the reservation aggregation in [Baker]). The purpose of this document is to provide some discussion on that draft and show some enhancements. Although multicast case will be mentioned, it is not discussed extensively. The extensions introduced in this draft surely complicate the programming of RSVP process, but alleviate the RSVP processing cost and the bandwidth required for refresh messages in the environments where route change must be detected via PATH messages. Whether such environments will exist in the core of the future internet, remains to be seen. 2. Definition of route change Let us defined what "route change at a node" means in the following discussion. Route is said to have changed at an RSVP node when: after sending the first PATH message for a session from this node, the stream of packets for which this PATH message is intended still goes through this node and the next RSVP-capable node (or set of nodes of a multicast group) for this stream has changed, or the outgoing interface (or interfaces) for this stream has changed. Note that this definition only concerns outgoing route from this Yuhara & Tomikawa Expiration: October 1999 [Page 2] Internet Draft RSVP ID-based Refresh April 1999 node. When the packets under consideration are no longer received by this node due to a route change, the route is considered to have changed at some upstream node, not at this node. There are three cases for route change: (case 1) There is no route change for this outgoing interface. An example is an outgoing interface of a diffserv boundary node that connects to another diffserv boundary. Since this kind of link tend to be stable for a long period, we can consider that there is no route change at this node. Maintenance shutdown may be required, but that can be considered as a rare exception and may be manually handled (for example, shutting down rsvp processes on both sides). (case 2) The route change may happen, but the necessary route change information is provided to the rsvp process as soon as possible. The information may be provided by means of routing protocols or management protocols, or by measurements. In this case, if the no-refresh option (Last_Refresh) [Berger] is enabled and the (old) next hop has already registered an ID- based state for PATH of this stream, that state must be explicitly revoked. Otherwise, the state would remain there forever. We will discuss this case in section 4. (case 3) The route change may happen, and the necessary route change information is NOT provided to the rsvp process. In this case, we have to rely on the PATH refreshes. However, by exchanging the ID between RSVP neighbor nodes, we can drastically reduce the amount of PATH message size. We will discuss this case first. 3. ID-only PATH refreshes In (case 3), route change is detected using PATH refreshes, thus we cannot eliminate PATH refreshes. In [Baker], detection of route change within a domain depends on the refreshes of individual PATH messages. An example of route change is shown below. Individual PATH messages are not interpreted by interior nodes (Rx) but by boundary nodes (ingress, egress1, egress2). Yuhara & Tomikawa Expiration: October 1999 [Page 3] Internet Draft RSVP ID-based Refresh April 1999 Before route change [ingress] -----> [R1] -----> [R2] ------> [R3] -----> [egress1] After route change [ingress] -----> [R1] -----> [R2] ---+ | +--> [R4] -----> [egress2] In general, the interior routing protocol does not inform the ingress node of the route change at R2 (although some protocols could do so, such protocols cannot be assumed in general). Since the number of reservations on a DS boundary node may get large, we still want the processing overhead and bandwidth overhead be small to alleviate the scalability problem. The ID-based refresh in [Berger] helps to quickly find a corresponding state in the receiving node and to instantly check the equality of the previous message and the incoming message (Last_Refresh flag off). In this draft, we further reduce the overhead by removing unnecessary information from the PATH refresh. A PATH message with an ID consists of the following elements (size is shown by the number of 4-byte words). Words ------------------------------ Common Header 2 INTEGRITY 0- (9 for HMAC-MD5) MESSAGE_ID 2 [Berger] SESSION 3 (IPv4) RSVP_HOP 3 (IPv4) TIME_VALUES 2 POLICY_DATA 0- SENDER_TEMPLATE 3 (IPv4) SENDER_TSPEC 9 (INTSERV) ADSPEC about 21 (21 for General Param, Guaranteed Service, Controlled-Load Service, no override) Some objets are optional and vary in size. In particular, some people has been worried that a POLICY_DATA object gets large (possibly gets larger than MTU). So a PATH message could be very large. Yuhara & Tomikawa Expiration: October 1999 [Page 4] Internet Draft RSVP ID-based Refresh April 1999 Now, we propose ID-only PATH refreshes. ID-only PATH refresh reduces the PATH message size, once the PATH is confirmed. The ACK mechanism in [Berger] is used for confirmation. ID-only PATH message looks like this: ::= [ ] MESSAGE_ID ACK object is defined in [Berger]. The MESSAGE_REFRESH object is similar to the MESSAGE_ID object in [Berger] but has a different class number: MESSAGE_REFRESH class Class-Num is of 0bbbbbbb form (must report error if this object is unknown) and should be assigned by IANA. REFRESH_ID object Class = MESSAGE_REFRESH class, C-Type = 1 +-------------+-------------+-------------+-------------+ | Reserved | Message ID | +-------------+-------------+-------------+-------------+ Reserved: reserved and must be zero. Message ID: Latest ID for this PATH state. The ID must have been acknowledged by the next hop(s). The IP header is the same as normal PATH messages. The IP destination address is the session address. Unfortunately, since PATH REFRESH messages must detect route change, PATH REFRESH messages cannot be aggregated in a single message [Berger], whose destination address is the address of the common next hop. The recipient hop of this PATH REFRESH message must behave as if the full PATH message previously received with this Message ID was received, if such message was received from the same RSVP_HOP and this node has sent its acknowledgement. However, this node does not have to send another acknowledgment even if the original message requested it. In this way, the total message size is reduced significantly. If we assume the numbers above, the message is reduced from 45 words to 10 words. If the POLICY_DATA object is very large, the reduction is more Yuhara & Tomikawa Expiration: October 1999 [Page 5] Internet Draft RSVP ID-based Refresh April 1999 effective. The smaller gets the message size, the smaller gets the message handling cost. In addition, the bandwidth required for PATH refreshes is reduced. The rest of this section describes how route change is handled when ID-only PATH refresh is used. If a PATH receiving node has never heard of the Message ID from the RSVP_HOP, or if this node has not send an acknowledgment for the Message ID, then this node considers it detects a route change at RSVP_HOP, and explicitly requests the RSVP_HOP node to send a full PATH message. The request message is sent to the sending node (RSVP_HOP) as follows: ::= [ ] [ ... ] REFRESH_REQUEST object Class = MESSAGE_REFRESH class, C-Type = 2 +-------------+-------------+-------------+-------------+ | Reserved | Message ID | +-------------+-------------+-------------+-------------+ Reserved: reserved and must be zero. Message ID: The received Message ID that should be sent again in full format. If a PATH sending node receives Refresh Request message with an ID registered in this node, the node must send a full PATH message with a newly allocated ID. The PATH state in the receiving node will timeout if PATH or PATH Refresh messages are not received for a long time as defined in [RFC2205]. Or, it may be explicitly revoked by Invalidate ID Messages described in the next section. An RSVP node that does not support this extension will report a Path Error when it receives a Path Refresh message, since it does not know the REFRESH_ID object and its class is requesting an error report if the object is unknown to the node. The SESSION and RSVP_HOP objects are included in the Path Refresh Message so that such node can Yuhara & Tomikawa Expiration: October 1999 [Page 6] Internet Draft RSVP ID-based Refresh April 1999 construct a Path Error message. The PATH sending host which receives a Path Error must first check if the previous PATH message was an ID-only PATH, and if so, it should not forward the Path Error message upstream, but should reset the ID-based state and send a full PATH message. If the error reporting node only supports conventional RSVP, it will not send back an acknowledgment, so the sending node continues to send full PATH messages. We could use Path Error in place of Refresh Request. However, we provide a separate message type for easier handling. The above route change handling for ID-only refreshes can also be used for multicast sessions when ID-only refreshes are used. If a new node joins a multicast group down-stream of a PATH sending node, and the rsvp process of the PATH sending node is not informed of the change, then the new node will request a full PATH message or will report an error, since it receives unknown ID-only PATH refreshes. The PATH sending node can try to re-establish ID-based relations with all neighbor members. 4. Route change handling when refresh is suppressed This section discusses the extension to [Berger] for previously described (case 2). In this case, The route change may happen, but the information on route change at this node is provided to the rsvp process. With this information, the node can re-establish the PATH state with a new next hop. However, there is no means to revoke the old state in the old next hop. We cannot use a Path Tear message for this purpose, because Path Tear has the ultimate destination as its IP address and it would now be routed to the new next hop. We need a message that can directly reach the old next hop. To this end, we define INVALIDATE_ID RSVP messages. ::= [ ] [ ... ] INVALIDATE_ID object Class = MESSAGE_REFRESH class, C-Type = 3 Yuhara & Tomikawa Expiration: October 1999 [Page 7] Internet Draft RSVP ID-based Refresh April 1999 +-------------+-------------+-------------+-------------+ | Reserved | Message ID | +-------------+-------------+-------------+-------------+ Reserved: reserved and must be zero. Message ID: The Message ID that should be invalidated. The host must retransmit the Invalidate ID Message until it is acknowledged, or a maximum retry limit is reached (or Hello Message has timed-out and all relating states are cleared). Since this message must be acknowledged, the message ID for this message is included in the message. If a host receives an Invalidate ID Message that has a matching state, the host must invalidate the state and send an acknowledgment. The host must be prepared to repeatedly receive the same INVALIDATE_ID messages, since the acknowledgment may be lost in the network. 6. Possible modification to the RSVP aggregate reservation The RSVP aggregate reservation proposed in [Baker] installs states in DS-ingress and DS-egress boundary nodes to aggregate reservations. Since this state handling is very similar to the one for ID-based refreshes, reservation aggregation mechanism can relay on the ID- based states. In [Baker], Path Error messages with error code of NEW-AGGREGATE- NEEDED are used for two purposes. One is for the ingress node to identify an egress node for the session. This Path Error can be replaced by an acknowledgment for the PATH message. The other is for an egress node to request re-establishment of the states when it receives an unknown PATH (due to route change). This Path Error can be replaced by a Refresh Request message. By combining [Baker] and [Berger] in this way, we can eliminate the duplicate state management. Security Considerations No new security issues are raised in this document. See [RFC2205] for a general discussion on RSVP security issues. References [Baker] Baker, F., Iturralde, C., Le Faucheur, F., Davie, B., "Aggregation of RSVP for IP4 and IP6 Reservations", Work In Progress, draft-baker-rsvp-aggregation-00.txt, February 1999. Yuhara & Tomikawa Expiration: October 1999 [Page 8] Internet Draft RSVP ID-based Refresh April 1999 [Berger] Berger, L., Gan, D., Swallow, G., "RSVP Refresh Reduction Extensions", draft-berger-rsvp-refresh-reduct-00.txt, Work In Progress, March 1999. [Bernet] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Nichols, K., Speer, M., Braden, R., "Interoperation of RSVP/Int-Serv and Diff-Serv Networks", Work In Progress, draft-ietf-diffserv-rsvp- 02.txt, February 1999. [Pan] Pan, P., Schulzrinne, H., Guerin, R., "Staged Refresh Timers for RSVP", draft-pan-rsvp-timer-00.txt, Work In Progress (already expired), November 1997. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC2208] Baker, F., Braden, B., Bradner, S., O`Dell, M., Romanow, A., Weinrib, A., Zhang, L., "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997. [RFC2215] Shenker, S., Wroclawski, J., "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W., "An Architecture for Differentiated Services", RFC 2475, December 1998. Author's Address Masanobu Yuhara Fujitsu Laboratories Ltd. 4-1-1 Kamikodanaka, Nakahara-ku Kawasaki, 211-8588, Japan Phone: +81-44-777-1111 Email: yuhara@flab.fujitsu.co.jp Mayumi Tomikawa Fujitsu Laboratories Ltd. Yuhara & Tomikawa Expiration: October 1999 [Page 9] Internet Draft RSVP ID-based Refresh April 1999 4-1-1 Kamikodanaka, Nakahara-ku Kawasaki, 211-8588, Japan Phone: +81-44-777-1111 Email: ohya@flab.fujitsu.co.jp Yuhara & Tomikawa Expiration: October 1999 [Page 10]