Network Working Group F. Tommasi Internet Draft S. Molendini Document: draft-tommasi-rsvp-enhan-scalab-00.txt University of Lecce Expiration date: January 2000 July 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 January 2000 [Page 1] draft-tommasi-rsvp-enhan-scalab-00.txt July 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. CompactRefresh messages.......................................13 7.2. MessageRequest messages.......................................13 7.3. Invalidate_ID messages........................................14 8. Strong Refresh................................................14 8.1. IDExchange messages...........................................15 8.2. LIST_ID object................................................16 8.3. SEQUENCE_# object.............................................16 9. Ordering of messages..........................................16 10. Messages exchange when a route change happens.................18 11. How to use RSVP extensions....................................19 F.Tommasi / S.Molendini Expires January 2000 [Page 2] draft-tommasi-rsvp-enhan-scalab-00.txt July 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 acknowledgment 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 acknowledgment and refresh messages. A COMPRESSED_LIST_DESCRIPTOR object is proposed too. To validate the exchange of trigger messages an acknowledgment 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. Acknowledgment 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 '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 January 2000 [Page 3] draft-tommasi-rsvp-enhan-scalab-00.txt July 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. A new mechanism to exchange messages in an ordered way is proposed. This should improve processing in receiving nodes. 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 IDExchange messages, the MESSAGE_ID object is not associated with a single message but with a group of related IDExchange 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. F.Tommasi / S.Molendini Expires January 2000 [Page 4] draft-tommasi-rsvp-enhan-scalab-00.txt July 1999 Flag 0x10: Urgent flag, see par. 4.1. Flag 0x08: Base_Extensions flag, see par. 11. Flag 0x04: Compressed_Lists_flag: if set, Base Extensions flag MUST be set, see par. 11. Flag 0x02: Strong_Refresh flag: if set, Base Extensions flag MUST be set, see par. 11. Flag 0x01: Order flag: if set, Base Extensions flag MUST be set, see par. 11. 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 F.Tommasi / S.Molendini Expires January 2000 [Page 5] draft-tommasi-rsvp-enhan-scalab-00.txt July 1999 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 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. F.Tommasi / S.Molendini Expires January 2000 [Page 6] draft-tommasi-rsvp-enhan-scalab-00.txt July 1999 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. 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 acknowledgment 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. F.Tommasi / S.Molendini Expires January 2000 [Page 7] draft-tommasi-rsvp-enhan-scalab-00.txt July 1999 The format of the LIST_DESCRIPTOR 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. F.Tommasi / S.Molendini Expires January 2000 [Page 8] draft-tommasi-rsvp-enhan-scalab-00.txt July 1999 The following LIST_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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 January 2000 [Page 9] draft-tommasi-rsvp-enhan-scalab-00.txt July 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 January 2000 [Page 10] draft-tommasi-rsvp-enhan-scalab-00.txt July 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 January 2000 [Page 11] draft-tommasi-rsvp-enhan-scalab-00.txt July 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. 11. 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 CompactRefresh message is defined to refresh states specifing their Message_ID in a LIST_DESCRIPTOR object. CompactRefresh 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. CompactRefresh messages may indifferently refresh both Resv state and Path state. A CompactRefresh 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 CompactRefresh message, as Path messages F.Tommasi / S.Molendini Expires January 2000 [Page 12] draft-tommasi-rsvp-enhan-scalab-00.txt July 1999 are 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. CompactRefresh messages The syntax of CompactRefresh messages is: < CompactRefresh Message > ::= < Common Header > [ < INTEGRITY > ] < LIST_DESCRIPTOR > A CompactRefresh 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 January 2000 [Page 13] draft-tommasi-rsvp-enhan-scalab-00.txt July 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 at the same time and waits for a cumulative acknowledgement. To this purpose, new IDExchange messages are defined. More than one IDExchange message could be needed: 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 existing in the local state has not be 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). Strong Refresh is used only if the neighbor node has set the Strong_Refresh flag in received messages: see par. 11. F.Tommasi / S.Molendini Expires January 2000 [Page 14] draft-tommasi-rsvp-enhan-scalab-00.txt July 1999 8.1. IDExchange messages The syntax of IDExchange messages is: < IDExchange Message > ::= < Common Header > [ < INTEGRITY > ] < LIST_ID > < SEQUENCE_# > < LIST_DESCRIPTOR > An IDExchange message has a common RSVP header with the Msg Type set to 17 (Value to be assigned by IANA). All IDExchange messages of the same sequence MUST have the same LIST_ID object. This object identifies all the objects of the same sequence. The Flags and Epoch fields must be used as specified in par.2. After having correctly received the sequence of messages, the receiver node MUST send an Ack message to the sender. A single Ack message should be sent for all the IDExchange messages of the list. For acking purposes the LIST_ID object of IDExchange messages is used. The sender node sends all the Message_IDs to the receiver node when the refresh timer expires. It then sets an acknowledge timer. As this timer expires without the reception of an Ack message, the sender node retransmits all the messages with a new value of List_ID in LIST_ID objects. The strategy adopted when sending packets containing the IDExchange messages is characteristical of the particular RSVP implementation, and it may depend on the number of packets and the type of interface. However the sender node may transmit all the packets consecutively, terminating the transmission as soon as possible. A node sets a timer when it receives the first IDExchange message of a new sequence. If the timer expires before the reception of the whole list, messages already received are silently ignored. If a node receives an IDExchange message with a Sequence_# already received, it ignores that message. 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. F.Tommasi / S.Molendini Expires January 2000 [Page 15] draft-tommasi-rsvp-enhan-scalab-00.txt July 1999 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 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 an IDExchange 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_# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 9. Ordering of messages Sometimes a node must create/modify/delete lots of new states in a short time (e.g. when a route change happens). Minimizing the total F.Tommasi / S.Molendini Expires January 2000 [Page 16] draft-tommasi-rsvp-enhan-scalab-00.txt July 1999 processing time of RSVP messages, helps to keep short the time data flows are not served with proper QoS. Global processing can be improved if RSVP messages are put into packets in an ordered way. A proper ordering of messages leads to a better management of resources. However, we remember that datagrams can be received with a different order than they were sent. The following rules SHOULD be followed when a node sends to a neighbor a set of regular RSVP messages in more than one packet: 1) Send messages with the following order: ResvTear, Resv, Path, PathTear, other messages. 2) ResvTear messages SHOULD be ordered by : 2.1) for FF and SE styles: increasing (DestAddress, ProtocolId, DstPort, SrcAddress, SrcPort) 2.2) for WF style: increasing (DestAddress, ProtocolId, DstPort) 3) Resv messages SHOULD be ordered by : 3.1) for FF and SE styles: increasing (DestAddress, ProtocolId, DstPort, SrcAddress, SrcPort) 3.2) for WF style: increasing (DestAddress, ProtocolId, DstPort) 4) Path messages SHOULD be ordered by increasing (DestAddress, ProtocolId, DstPort, SrcAddress, SrcPort) 5) PathTear messages SHOULD be ordered by increasing (DestAddress, ProtocolId, DstPort, SrcAddress, SrcPort) 'Ordered by (a, b, c, ...)' means that (a1, b1, c1, ...) < (a2, b2, c2, ...) if a1