Network Working Group F. Tommasi Internet Draft S. Molendini Document: draft-tommasi-rsvp-enhan-scalab-01.txt University of Lecce Expiration date: April 2000 October 1999 Some extensions to enhance the scalability of the RSVP protocol 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 describes a set of proposals to reduce the load introduced by RSVP protocol in routers that must handle a large number of sessions. Specifically, it proposes mechanisms to reduce the number of RSVP signaling IP packets, the total number of RSVP messages and the related processings. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. F.Tommasi / S.Molendini Expires April 2000 [Page 1] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 Contents 1. INTRODUCTION AND BACKGROUND.....................................3 2. MESSAGE_ID OBJECTS..............................................4 3. BUNDLE MESSAGES.................................................5 3.1. BUNDLE MESSAGE FORMAT...........................................5 4. HOW TO DELAY MESSAGES...........................................5 4.1. URGENT BIT......................................................7 5. LIST_DESCRIPTOR OBJECTS.........................................7 5.1. COMPRESSED_LIST_DESCRIPTOR OBJECTS..............................9 6. ACK MESSAGES...................................................12 7. WEAK REFRESH...................................................12 7.1. WEAKREFRESH MESSAGES...........................................13 7.2. MESSAGEREQUEST MESSAGES........................................13 7.3. INVALIDATE_ID MESSAGES.........................................14 8. STRONG REFRESH.................................................14 8.1. STRONGREFRESH MESSAGES.........................................15 8.2. LIST_ID OBJECT.................................................16 8.3. SEQUENCE_# OBJECT..............................................16 9. MESSAGES EXCHANGE WHEN A ROUTE CHANGE HAPPENS..................17 10. HOW TO USE RSVP EXTENSIONS.....................................18 F.Tommasi / S.Molendini Expires April 2000 [Page 2] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 1. Introduction and Background Functional specifications of RSVP are defined in [RFC2205]. Recently a certain amount of work has been devoted to reduce the excessive load the protocol introduces in terms of messages exchange and their processing, especially in routers that handle a large number of sessions. We refer in this document to a previous Internet Draft: [Berger1999]. RSVP keeps a soft state in nodes. This implies that the network is traversed not only by messages to signal creation/change/deletion of states (trigger messages), but also by messages periodically confirming a soft state, (refresh messages). Each message is associated to a single session. Failure to receive refresh messages for a certain number of refresh periods, causes state deletion. In trigger messages a MESSAGE_ID object is inserted. This MESSAGE_ID is unique on a per sender/hop-by-hop basis. It is used to do acknowledgement and refresh. If more messages must be sent to the same node, it is possible to pack them in a single container message. The use of these messages (Bundle messages), is clarified in [Berger1999]. This document discusses how to bundle messages: messages are collected in a buffer with a certain latency for each destination. Messages defined as urgent are immediately sent without any delay. A new LIST_DESCRIPTOR object is defined to transport large lists of MESSAGE_ID objects. Such objects are useful to exchange acknowledgement and refresh messages. A COMPRESSED_LIST_DESCRIPTOR object is proposed too. To validate the exchange of trigger messages an acknowledgement mechanism must be added to the [RFC2205] specifications. This reduces the time needed to set up the correct state, if a RSVP packet is lost. Acknowledgement can be accomplished transmitting back the whole message to be acknowledged. To reduce retransmission time and processing time, the Message_ID can be used in alternative. Instead of refreshing by retransmitting trigger messages, simply the Message_ID can be sent. A mechanism will be described to refresh the state of a large number of sessions with a single message: each node identifies the neighbor nodes, and sends them the Message_IDs of the sessions it wants to refresh. A new, reliable, 'strong refresh' mechanism is proposed: it must be used between neighbors both to refresh sessions and to identify a wrong Message_ID. F.Tommasi / S.Molendini Expires April 2000 [Page 3] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 It is important, before transmitting refresh messages carrying Message_IDs, that the state related to the Message_ID itself has been already acknowledged. If not, the receiver may not be able to recognize the Message_ID. During a route change, a node must process a large number of new RSVP messages in a short time. To make this operation easier, messages can be ordered. This means that in each packet a node receives messages apt to be partially processed in the same way. Issues related to the use of these extensions are finally discussed. In particular, the problem of backward compatibility with an [RFC2205] node is considered. 2. MESSAGE_ID objects Together with the sender IP address a MESSAGE_ID object univocally identifies a message. It must be put into trigger messages for later use as a shorthand to identify a message for acknowledging and refreshing purposes. In Ack Messages, the MESSAGE_ID object specifies the message being acknowledged. In the case of StrongRefresh messages, the MESSAGE_ID object is not associated with a single message but with a group of related StrongRefresh messages. The format of the object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Message_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MESSAGE_ID Class = Value to be assigned by IANA of form 0bbbbbbb MESSAGE_ID object Class = MESSAGE_ID Class, C-Type = 1 Epoch: This value changes as a node resets. It must not change during standard operations Message_ID: ID of the message. It must be unique in a node at a given time. Flags: Signals used extensions. Flag 0x10: Urgent flag, see par. 4.1. Flag 0x08: Base_Extensions flag, see par. 10. Flag 0x04: Compressed_Lists_flag: if set, Base Extensions flag MUST be set, see par. 10. F.Tommasi / S.Molendini Expires April 2000 [Page 4] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 Flag 0x02: Strong_Refresh flag: if set, Base Extensions flag MUST be set, see par. 10. See [Berger1999] about usage rules of MESSAGE_ID objects. 3. Bundle messages Bundle Messages are messages that contain lists of other messages. See [Berger1999] about their usage. 3.1. Bundle message format A Bundle Message is made up of a common header and a body. The body is the list of sub-messages. Body of Bundle messages: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // First sub-message // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // More sub-messages ... // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Bundle message has a common RSVP header with the Msg Type set to 12. (Value to be assigned by IANA) Each sub-message has its own common header and body. 4. How to delay messages If one has to follow the current RSVP specifications, it is hard to create bundle messages. According to RFC 2205, messages are sent as soon as an event has led to their creation. The received message is then processed with a minimum delay. By introducing a small delay it is possible to achieve a noticeable improvement of the protocol performances. A router can assign a maximum latency Td to each destination and then proceed to buffering messages to that destination until Td expires. It will then pack all the queued messages into a bundle message to be sent to that destination. A small delay is rarely critical for messages such as Ack, PathErr, ResvErr, ResvConf. Obviously the sender node has to take into account F.Tommasi / S.Molendini Expires April 2000 [Page 5] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 the introduction of this new latency for Ack messages in its estimates of the retransmission time-out. And even if for Path, Resv, PathTear and ResvTear messages an immediate transmission is sometime required, nonetheless refresh Path and Resv messages can be delayed for a certain amount of time without consequencies. The same cannot be said for messages implying an immediate modification of the RSVP state. If a delay is introduced in these cases, it adds up to the total delay in RSVP response. This can be acceptable for some applications but not for all (e.g. distributed scientific computing). An application must therefore be allowed to require an immediate deliver of some messages it labels as urgent using a flag for this purpose. For the same reasons, it is sometime very important to transmit PathTear and ResvTear messages without delays. Failure in doing so could result in wasting critical resources. A new ±urgent bitˇ in the MESSAGE_ID object of the message is therefore defined: when set, a node must transmit the message without any delay. A related issue is how to determine Td, which is the worst case delay allowed for a message. The Td value is determined by each node, and it depends on the Round Trip Time (RTT) between the node and its neighbour: Td is set to 50% of RTT/2. In this way the total delay a non Urgent message can suffer travelling between two hosts is, in the worst case, 1.5 times the time it would have been without any delay. Sometime the RTT value cannot be determined, or it is too long: in all cases a 100 msec maximum value for Td is introduced. When a new message is created, the RSVP process computes (when possible) the address of the next RSVP node. If this is a new one, a new neighbor is identified and the related Td value is determined. The Td value MUST NOT be greater than the 50% of RTT/2 (if it can be determined) and it MUST NOT be greater than 100 msec. The first message sets the Td timer and the following messages are buffered until one of these events occurs: 1) A message marked as Urgent is created; 2) The Td timer expires; 3) Pending messages are enough to build a large packet. At this point the messages are sent and Td timer is reset. Point 1) states that pending messages are sent immediately when an Urgent message must be transmitted. Point 2) limits the maximum delay a message can tolerate. F.Tommasi / S.Molendini Expires April 2000 [Page 6] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 Point 3) simply states that messages can be sent when the Bundle Message has reached the limit posed by the MTU and further messages cannot fit in it. 4.1. Urgent Bit A new Urgent bit is defined in the Flags field of the MESSAGE_ID object: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Message_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flag 0x10: Urgent. It MUST NOT be set in messages different from Resv, Path, ResvTear, PathTear messages. If set, a message MUST be forwarded through the output interface without being buffered for bundling. This flag should be set by applications. A router MUST set Urgent bit in all Resv, Path, ResvTear, PathTear messages created because of processing a received Urgent message. If a regular [RFC2205] RSVP message (without a MESSAGE_ID object) is received, it will be processed as an Urgent message. 5. LIST_DESCRIPTOR objects A new LIST_DESCRIPTOR_object is defined. It contains a list of Message_IDs and it is defined to minimize the transmission time and the processing time of large lists of MESSAGE_ID objects. It is useful when state refresh or acknowledgement of a large number of messages is needed. MESSAGE_ID objects are made up of 3 words (Header, Flags, Epoch, Message_ID). N MESSAGE_ID objects are 3*N words. A LIST_DESCRIPTOR object carrying N Message_IDs is made up of a single Header, Flags and Epoch fields and a list of Message_IDs, for a total of (2+N) words. Using these objects saves about 2/3 of space and allows a global processing of Flags and Epoch fields. The format of the LIST_DESCRIPTOR object is: F.Tommasi / S.Molendini Expires April 2000 [Page 7] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | First Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LIST_DESCRIPTOR Class = Value to be assigned by IANA of form 0bbbbbbb LIST_DESCRIPTOR object Class = LIST_DESCRIPTOR Class, C-Type = 1 Flags: the same meaning as in MESSAGE_ID objects, par. 2. Epoch: the same meaning as in MESSAGE_ID objects, par. 2. When creating a LIST_DESCRIPTOR_object from a set of MESSAGE_ID objects, they all MUST have the same Epoch value. The value of Flags field SHOULD be equal to the Flags field in the MESSAGE_ID object with highest Message_ID field. The number N of descriptors is variable, and can be derived from the object header. Each descriptor is made up of a 'Code' (or 'C') field and a 'Message_Descr' field. The meaning and the size of the Message_Descr field depends on the Code value. For now only 'EXPLICIT' (or 'X') code is defined. In the next paragraph we will see other codes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Message_Descr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code = 0, 'EXPLICIT' or 'X' : The Message_Descr field is equal to the Message_ID value of the object being specified. A LIST_DESCRIPTOR_object containing a single descriptor is equivalent to a MESSAGE_ID object. When receiving a LIST_DESCRIPTOR_object, each original MESSAGE_ID object is simply recreated by copying common Epoch and Flags values and the value of Message_Descr field in Message_ID. The following LIST_DESCRIPTOR: F.Tommasi / S.Molendini Expires April 2000 [Page 8] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| 50 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| 977 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| 2080 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ substitutes the MESSAGE_IDs objects with Message_IDs: 50, 977, 2080 5.1. COMPRESSED_LIST_DESCRIPTOR objects In this paragraph a simple technique to compress the list of descriptors is described. New ways to specify Message_IDs are introduced by introducing new codes in LIST_DESCRIPTOR objects. This leads to the generation of COMPRESSED_LIST_DESCRIPTOR objects, a different C-Type of the LIST_DESCRIPTOR objects Class. Codes of descriptors are now defined: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Message_Descr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Descriptor. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Message_Descr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Descriptor. We have two types of descriptors. Type 1 descriptor was already discussed in the previous paragraph. It has a Code field of one bit who's unique value 'EXPLICIT' is 0. The Message_Descr represents a Message_ID value. Type 2 descriptor is now introduced. Code field is 8-bit-length, and the first bit MUST be 1. In such a way, Type 2 codes must all have values starting from 128 (included). F.Tommasi / S.Molendini Expires April 2000 [Page 9] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 Codes of descriptors are sequentially processed and a Current_Message_ID variable is to be maintained. As the proposed compression is a differential one, the first decriptor's Code in a COMPRESSED_LIST_DESCRIPTOR object MUST be EXPLICIT and the Current_Message_ID variable is assigned the value Message_Descr (31 bits). Each time an EXPLICIT code is encountered, the Current_Message_ID variable is assigned the value Message_Descr (31 bits). As non-EXPLICIT codes are sequentially encountered, the Current_Message_ID variable is incremented according to the rules given below. Code=128, 3xWORD: Three Message_IDs are present in a single word. The descriptor's Message_Descr field is split in three sub-fields of 8 bits each. Adding to the Current_Message_ID the value of a sub-field, a new Message_ID is obtained. This becomes the new Current_Message_ID and so on. Subfields are processed from left to right. Code=129, 6xWORD: Six Message_IDs are described. The descriptor's Message_Descr field is split in six sub-fields of 4 bits each. Adding to the Current_Message_ID the value of a sub-field, a new Message_ID is defined. This becomes the new Current_Message_ID. Subfields are processed from left to right. Code=130, 12xWORD: Twelve Message_IDs are described. The descriptor's Message_Descr field is split in twelve sub-fields of 2 bits each. Adding to the Current_Message_ID the value of a sub-field, a new Message_ID is defined. This becomes the new Current_Message_ID. Subfields are processed from left to right. Code=131, RANGE: a range of Message_IDs is represented. The Message_Descr gives the number of all the objects following Current_Message_ID. Current_Message_ID + Message_Descr becomes the new Current_Message_ID. Code=132, BITMAP: The list of Message_IDs is represented through a string of bits. This list may be long more than a word. The Message_Descr field specifies the number of descriptors used to represent the list. This field MUST NOT be 0. Bitmap's words are processed in order. Bits are processed from left to right. If a bit is equal to 1, the Message_ID equal to Current_Message_ID + 1 belongs to the list. Current_Message_ID + 1 becomes the new Current_Message_ID. F.Tommasi / S.Molendini Expires April 2000 [Page 10] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 Example N—1: The following COMPRESSED_LIST_DESCRIPTOR object: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| 49 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BITMAP | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 0 0 0 0 1 1 1 0 0 1 0 1 0 1 0 1 0 1 1 0 0 0 0 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 0 1 0 1 0 1 0 1 0 1 1 0 0 0 0 1 1 1 1 0 0 1 0 1 0 1 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Describes the Message_IDs list: 49, 51, 52, 57, 58, 59, 62, 64, 66, 68, 70, 71, 76, 77, 78, 79, 80, 81, 82, 83, 84, 87, 89, 91, 93, 95, 96, 101, 102, 103, 104, 107, 109, 111, 112 Example N—2: The following one: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| 49 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3XWORD | 3 | 1 | 105 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Describes the Message_IDs list: 49, 52, 53, 158 Example N—3: The following one: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| 49 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RANGE | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 12XWORD | 2 | 3 | 2 | 1 | 1 | 1 | 1 | 2 | 1 | 1 | 3 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| 30101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3XWORD | 12 | 121 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Describes the Message_IDs list: 49, 50, 51, 52, 53, 54, 56, 59, 61, 62, 63, 64, 65, 67, 68, 69, 72, 73,30101,30113,30234 F.Tommasi / S.Molendini Expires April 2000 [Page 11] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 COMPRESSED_LIST_DESCRIPTOR objects are significantly smaller in size than the equivalent LIST_DESCRIPTOR ones when Message_IDs are numerically close to each other. A judicious implementation technique would assign Message_IDs as consecutively as possible to messages, in a way that would allow to create compact COMPRESSED_LIST_DESCRIPTOR objects. COMPRESSED_LIST_DESCRIPTOR object: Class = LIST_DESCRIPTOR Class, C-Type = 2. Compression is used only if the neighbor node has set the Compression_Lists flag in received messages: see par. 10. 6. Ack Messages The syntax of Ack messages is: < Ack Message > ::= < Common Header > [ < INTEGRITY > ] < LIST_DESCRIPTOR > An Ack message has a common RSVP header with the Msg Type set to 13. (Value to be assigned by IANA) An Ack message acknowledges one or more messages. The LIST_DESCRIPTOR object contains the Message_IDs of the messages to be acknowledged. As previously discussed, to ack a single message with the LIST_DESCRIPTOR object is equivalent to acking it with a MESSAGE_ID object. A set of messages received in a Bundle Message can be acknowledged with a single Ack message and a LIST_DESCRIPTOR containing the list of Message_IDs. 7. Weak Refresh According to [RFC2205], the state must be periodically refreshed retransmitting periodically all the messages. Retransmissions are triggered by the expiration of a 'refresh timeout' timer. When messages must be sent to the same node, timers can be syncronized to refresh more than one message with a single message. Instead of retrasmitting the whole original message, its Message_ID can be used. A new WeakRefresh message is defined to refresh states specifing their Message_ID in a LIST_DESCRIPTOR object. WeakRefresh messages are sent with a 'refresh timeout' period that can be equal or less than the value (30 sec.) typically used in regular RSVP refresh messages. WeakRefresh messages may indifferently refresh both Resv state and Path state. A WeakRefresh message contains IDs related to Resv messages having the same destination address (that is the next RSVP node's address). It is more complex to identify which Path state may be refreshed with a single WeakRefresh message, as Path messages are F.Tommasi / S.Molendini Expires April 2000 [Page 12] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 used to identify route changes and their destination address is the session's destination address. However it is possible to refresh Path State through their IDs in certain situations: see [Berger1999], par 4. The refresh procedure can be executed in two different ways. In this paragraph the 'weak refresh' procedure is described: refresh messages are processed independently. Local state is refreshed when a matching Message_ID is found. Otherwise, if an unknown Message_ID is found, the receiving node asks the sender for original Path/Resv messages with a new MessageRequest message. In paragraph 8 the 'strong refresh' procedure is described. 7.1. WeakRefresh messages The syntax of WeakRefresh messages is: < WeakRefresh Message > ::= < Common Header > [ < INTEGRITY > ] < LIST_DESCRIPTOR > A WeakRefresh message has a common RSVP header with the Msg Type set to 14 (Value to be assigned by IANA). The sender node puts into the LIST_DESCRIPTOR object only the IDs of acknowledged messages: if not acknowledged, messages are still being retransmitted in their regular form. The receiver node analyses each Message_ID in the list contained in the LIST_DESCRIPTOR object. A matching local state is refreshed if found in the received object. If a local state is not found, the receiver asks the sender node for original Path/Resv messages by sending the Message_IDs in a MessageRequest message 7.2. MessageRequest messages The syntax of MessageRequest messages is: < MessageRequest Message > ::= < Common Header > [ < INTEGRITY > ] < LIST_DESCRIPTOR > A MessageRequest message has a common RSVP header with the Msg Type set to 15 (Value to be assigned by IANA). The sender of a MessageRequest message asks another node for Path/Resv messages, by specifing them with their Message_IDs put into the LIST_DESCRIPTOR object. The receiver node scans the Message_ID list. If a Message_ID matching local state is found, the receiver node MUST send he related Resv / Path message. If a matching state is not found, the node SHOULD send an Invalidate_ID message containing the invalid Message_ID. F.Tommasi / S.Molendini Expires April 2000 [Page 13] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 7.3. Invalidate_ID messages A node sends with an InvalidateID message a list of Message_IDs to be invalidated. The syntax of InvalidateID messages is: < InvalidateID Message > ::= < Common Header > [ < INTEGRITY > ] < LIST_DESCRIPTOR > An InvalidateID message has a common RSVP header with the Msg Type set to 16 (Value to be assigned by IANA). A node receiving an InvalidateID message scans the list of Message_ID into the LIST_DESCRIPTOR object. If a local state is found, then state is invalidated and related resources are released. 8. Strong Refresh In a Strong Refresh procedure, a node sends to its neighbor the whole list of Message_IDs in a reliable way, that is waiting for acknowledgements and retransmitting unreceived IDs. To this purpose, new StrongRefresh messages are defined. More than one StrongRefresh message could be needed to send the list of IDs: messages are then sent as a sequence of messages. Each message contains a SEQUENCE_# object which identifies a specific message in the sequence and a LIST_ID object which identifies the whole sequence. The receiving node matches the list of received Message_IDs with the local state. The possible results of the matching process are: 1) A received Message_ID exists in the local state 2) A received Message_ID does not exist in the local state 3) A Message_ID corresponding to an existing local state has not been received Results 1) and 2) are detected in the same way as in the Weak Refresh procedure. Result 3) is detected because of a missing Message_ID in the received list. In case 1) the state is refreshed as usual. In cases 2) and 3) the receiver node asks the sender for the original Path/Resv messages by sending it a MessageRequest message. Then the sender node sends regular Path/Resv messages (when the local state is found) or InvalidateID messages (when the local state is not found). F.Tommasi / S.Molendini Expires April 2000 [Page 14] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 Strong Refresh is used only if the neighbor node has set the Strong_Refresh flag in received messages: see par. 10. 8.1. StrongRefresh messages The syntax of StrongRefresh messages is: < StrongRefresh Message > ::= < Common Header > [ < INTEGRITY > ] < LIST_ID > < SEQUENCE_# > < LIST_DESCRIPTOR > A StrongRefresh message has a common RSVP header with the Msg Type set to 17 (Value to be assigned by IANA). All StrongRefresh messages of the same sequence MUST have the same LIST_ID object. This object identifies all the messages of the same sequence. The Flags and Epoch fields must be used as specified in par.2. As the refresh timer expires, the sender node sends the set of MESSAGE_IDs in a list of StrongRefresh messages. Each message has the same LIST_ID object and an increasing Sequence_# field in the SEQUENCE_# object. The sender node keeps in memory the list, until it is acknowledged or until a local timer expires. If the list is correctly received, the receiver MUST send to the sender a ListAck message with the LIST_ID of the list and the SEQUENCE_# object with the Last flag set. The Sequence_# of this object should be the number of the last message of the list. Otherwise, if the list is not entirely received, the receiver MUST send to the sender a ListAck message with the LIST_ID of the list, the SEQUENCE_# object with the Last flag clear and the Sequence_# field containing the number of consecutive correctly received messages starting from message 0. That is, a ListAck message with a Sequence_# equal to 5 means that all messages from 0 to 5 were correctly received. The receiver node sets a timer when it receives the first StrongRefresh message of a new sequence. If the timer expires before the correct reception of the whole list, messages already received are partially acknowledged as explained above. If a node receives a StrongRefresh message with a Sequence_# already received, it ignores that message. When the sender node sends the list, it sets an ACK timer. As this timer expires, and the proper ListAck message acknowledging the whole list is not received, the sender node retransmits the missing messages (taking them from memory) in chunks identical to the previous ones. The strategy adopted when sending packets containing the StrongRefresh messages is characteristical of the particular RSVP implementation, and it may depend on the number of packets and the type of interface. F.Tommasi / S.Molendini Expires April 2000 [Page 15] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 However the sender node may transmit all the packets consecutively, terminating the transmission as soon as possible. When a list is correctly received, the receiver node scans the list of Message_IDs. If a Message_ID exists in the local state, the node refreshes the related state and sets a 'Verifed' flag (case 1 in par.8). If a Message_ID does not exist in the local state, the node add it to a Request list (case 2). When all Message_IDs are processed, all messages whose 'Verified' flag has not been set are added to the Request list (case 3). Then all 'Verified' flags are cleared and the receiver node sends to the sender node MessageRequest messages containing Message_IDs in the Request list. 8.2. LIST_ID object The LIST_ID object identifies all the objects of the same sequence. The Flags and Epoch fields must be used as specified in par.2 for MESSAGE_ID objects. The value of Epoch field is the same of the value used in the Epoch field of MESSAGE_ID objects. The values of List_ID field belong to a different space than values of Message_ID field in MESSAGE_ID objects. The value of List_ID MUST be changed in each new refresh phase. The format of the LIST_ID object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| List_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LIST_ID object Class = MESSAGE_ID Class, C-Type = 2 8.3. SEQUENCE_# object The SEQUENCE_# object identifies a StrongRefresh message in a sequence of messages. The format of the SEQUENCE_# object is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Sequence_# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F.Tommasi / S.Molendini Expires April 2000 [Page 16] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 SEQUENCE_# Class = Value to be assigned by IANA of form 0bbbbbbb SEQUENCE_# object Class = SEQUENCE_# Class, C_Type = 1 Flags: Flag 0x80: Last flag. Marks the message as the last one in the list. Sequence_#: Identifies the message in the sequence. The first message MUST have value 0. Other messages MUST have incremental values. 8.4. ListAck Messages The syntax of ListAck messages is: < ListAck Message > ::= < Common Header > [ < INTEGRITY > ] < LIST_ID > < SEQUENCE_# > An Ack message has a common RSVP header with the Msg Type set to 18. (Value to be assigned by IANA) An Ack message acknowledges one or more messages of a list identified by LIST_ID. The SEQUENCE_# object contains the number of the messages to be acknowledged. As previously discussed, the Last flag set in this object means that the whole list is correctly received. The Last flag not set in this object means the acknowledgement is a partial one. 9. Messages exchange when a route change happens Let us examine in this paragraph what happens at nodes that manage a large number of sessions when a route change occurs. We will point out the processing and message exchanges involved, and we will discuss how the extensions proposed in this document support and simplify message exchange. Two routers R1 and R4 are connected through a router R2. A number of RSVP sessions follows the path R1-R2-R4. Let us now suppose that the router R2 fails (or perhaps either R1/R2 or R2/R4 links fail), and the new path is R1-R3-R4. Routers must now exchange RSVP messages to modify existing states (in R1 and R4), to create new states (in R3) and - if possible - to delete old states (in R2). Supposing that the route change information is available to the RSVP processes in routers, we observe that: o) Routers will need to exchange a large number of Path/Resv messages. These messages set up new states, or modify existing ones. Therefore they must be sent as regular messages (that is with all the objects specified in [RFC2205]). o) Path/Resv messages are sent by routers at the same time. They can be put in a smaller number of Bundle messages. F.Tommasi / S.Molendini Expires April 2000 [Page 17] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 o) The router which receives the new Path/Resv messages must send to the sender router the related Ack messages. In an easy way, Message_IDs of all the sub-messages of a single Bundle message can be put into a single Ack Message (par. 3). o) Different Ack messages related to messages in different Bundle messages can be sent in a single Bundle Message (par 4.). o) If Message_IDs are incrementally assigned to new Path/Resv messages, the Ack of M messages can be done in an compact way through the following COMPRESSED_LIST_DESCRIPTOR object: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| First_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RANGE | M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o) In a similar way, successive refresh messages can be very compact (if sessions are stable). o) Of course, sessions which follow the inverse path R4-R2-R1 will receive a similar processing. o) If the route has changed because of a temporary failure of router R2 (or because a link of this router has fault), a similar processing will happen as the old path will be recovered. 10. How to use RSVP extensions This document discusses extensions that MUST be optional in the RSVP v.1 protocol. This paragraph explains how the described extensions are used by extended-RSVP routers. The problem of backward compatibility with plain-RSVP routers is pointed out too. A router SHOULD implement all the proposed mechanisms. The use of some of these mechanisms depends on the load of RSVP traffic a router must process, and on the type of router itself. Adopting an extension should be triggered by manual configuration or by automatic analysis: simply counting, for example, the number of RSVP sessions or the number of RSVP messages processed. First of all, an extended-RSVP node decides if it wants to delay messages as exposed in par. 4. If not, it MUST copy the value of the F.Tommasi / S.Molendini Expires April 2000 [Page 18] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 Urgent bit in generated messages, according to the rules exposed in par.4. Remaining proposed extensions are split into 3 sets, that is a basic set of extensions, and two sets of advanced and indipendent extensions: 1) Base extensions: Processing of regular messages containing a MESSAGE_ID object, processing of Bundle, Ack, WeakRefresh, MessageRequest, InvalidateID messages, processing of non compressed LIST_DESCRIPTOR objects (C-type=1), as discussed in par. 2,3,5,6,7. 2) Compressed Lists: Processing of COMPRESSED_LIST_DESCRIPTOR objects (C-type = 2), as discussed in par. 5.1. 3) Strong Refresh: Processing of StrongRefresh messages, as discussed in par. 8. A node communicates adopted extensions through MESSAGE_ID objects put into RSVP messages. If the neighbor is a plain-RSVP router, this objects will be rejected as they will be unknown. After that, the sending router will send regular [RFC2205] messages to its neighbor until extended messages will be received from it. However, from time to time a node should 'try' sending extended messages. In the Flags field of the Message_ID object, the following flags are defined: Flag 0x08: Base_Extensions flag, the sender node is using extensions explained in point 1). Flag 0x04: Compressed_Lists_flag, the sender node is using extensions explained in point 2). Flag 0x02: Strong_Refresh flag, the sender node is using extensions explained in point 3). If one of Compressed_Lists, Strong_Refresh, Base_Extensions flag MUST be set. Each node should update the value of three local variables after processing flags in MESSAGE_ID objects. An extensions is used only if both nodes agree on its usage through flags. A node should not send to a neighbor non authorized messages. Messages of non authorized types may be ignored. Security Considerations No new security issues are raised in this document. References [Berger1999] Berger, L., Gan, D., Swallow, G., _RSVP Refresh Reduction Extensions_, Internet Draft, draft-berger-rsvp-refresh-reduct-02.txt, May 1999 F.Tommasi / S.Molendini Expires April 2000 [Page 19] draft-tommasi-rsvp-enhan-scalab-01.txt October 1999 [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. Authors' Addresses Franco Tommasi University of Lecce, Fac. Ingegneria Via Monteroni 73100 Lecce, ITALY tommasi@ilenic.unile.it Simone Molendini University of Lecce, Fac. Ingegneria Via Monteroni 73100 Lecce, ITALY molendini@ultra5.unile.it F.Tommasi / S.Molendini Expires April 2000 [Page 20]