affected by the use of Srefresh message based refreshes.
When generating an Srefresh message, a node SHOULD refresh as much
Path and Resv state as is possible by including the information from
as many MESSAGE_ID objects in the same Srefresh message. Only the
information from MESSAGE_ID objects that meet the source and
destination IP address restrictions, as described in Sections 5.2,
may be included in the same Srefresh message. Identifying Resv state
that can be refreshed using the same Srefresh message is fairly
straightforward. Identifying which Path state may be included is a
little more complex.
Only state that was previously advertised in Path and Resv messages
containing MESSAGE_ID objects can be refreshed via an Srefresh
message. Srefresh message based refreshes must preserve the state
synchronization properties of Path or Resv message based refreshes.
Specifically, the use of Srefresh messages MUST NOT result in state
being timed-out at the RSVP next hop. The period at which state is
refreshed when using Srefresh messages MAY be shorter than the period
that would be used when using Path or Resv message based refreshes,
but it MUST NOT be longer.
The particular approach used to trigger Srefresh message based
refreshes is implementation specific. Some possibilities are
triggering Srefresh message generation based on each state's refresh
period or, on a per interface basis, periodically generating Srefresh
messages to refresh all state that has not been refreshed within the
state's refresh interval. Other approaches are also possible. A
default Srefresh message generation interval of 30 seconds is
suggested for nodes that do not dynamically calculate a generation
interval.
When generating an Srefresh message, there are two methods for
identifying which Path state may be refreshed in a specific message.
In both cases, the previously mentioned refresh interval and source
IP address restrictions must be followed. The primary method is to
include only those sessions that share the same destination IP
address in the same Srefresh message.
The secondary method for identifying which Path state may be
refreshed within a single Srefresh message is an optimization. This
method MAY be used when the next hop is known to support RSVP and
when either (a) the session is unicast or (b) the outgoing interface
is a point-to-point link. This method MUST NOT be used when the next
hop is not known to support RSVP or when the outgoing interface is to
a multi-access network and the session is to a multicast address.
The use of this method MAY be administratively configured. When
using this method, the destination address in the IP header of the
Srefresh message is usually the next hop's address. When the use of
this method is administratively configured, the destination address
should be the well known group address 224.0.0.14. When the outgoing
interface is a point-to-point link, all Path state associated with
sessions advertised out the interface SHOULD be included in the same
Srefresh message. When the outgoing interface is not a point-to-
point link, all unicast session Path state SHOULD be included in the
same Srefresh message.
Identifying which Resv state may be refreshed within a single
Srefresh message is based simply on the source and destination IP
addresses. Any state that was previously advertised in Resv messages
with the same IP addresses as an Srefresh message MAY be included.
After identifying the Path and Resv state that can be included in a
particular Srefresh message, the message generator adds to the
message MESSAGE_ID information matching each identified state's
previously used object. For all Resv state and for Path state of
unicast sessions, the information is added to the message in a
MESSAGE_ID LIST object that has a matching Epoch value. (Note only
one Epoch value will be in use during normal operation.) If no
matching object exists, then a new MESSAGE_ID LIST object is created.
Path state of multicast sessions may be added to the same message
when the destination address of the Srefresh message is the RSVP next
hop and the outgoing interface is a point-to-point link. In this
case the information is added to the message in a MESSAGE_ID
MCAST_LIST object that has a matching Epoch value. If no matching
object exists, then a new MESSAGE_ID MCAST_LIST object is created.
When the destination address of the message is a multicast address,
then identified information is added to the message in a MESSAGE_ID
SRC_LIST object that has a matching Epoch value. If no matching
object exists, then a new MESSAGE_ID SRC_LIST object is created.
Once the Srefresh message is composed, the message generator
transmits the message out the proper interface.
Upon receiving an Srefresh message, the node MUST attempt to identify
matching installed Path or Resv state. Matching is done based on the
source address in the IP header of the Srefresh message, the object
type and each Message_Identifier field. If matching state can be
found, then the receiving node MUST update the matching state
information as if a standard refresh message had been received. If
matching state cannot be identified, then an Srefresh NACK MUST be
generated corresponding to the unmatched Message_Identifier field.
Message_Identifier fields received in MESSAGE_ID LIST objects may
correspond to any Resv state or to Path state of unicast sessions.
Message_Identifier fields received in MESSAGE_ID SRC_LIST or
MCAST_LIST objects correspond to Path state of multicast sessions.
An additional check must be performed to determine if a NACK should
be generated for unmatched Message_Identifier fields associated with
Path state of multicast sessions, i.e., fields that were carried in
MESSAGE_ID SRC_LIST or MCAST_LIST objects. The receiving node must
check to see if the node would forward data packets originated from
the source corresponding to the unmatched field. This check,
commonly known as an RPF check, is performed based on the source and
group information carried in the MESSAGE_ID SRC_LIST and MCAST_LIST
objects. In both objects the IP address of the source is listed
immediately after the corresponding Message_Identifier field. The
group address is listed immediately after the source IP address in
MESSAGE_ID MCAST_LIST objects. The group address is the message's
destination IP address when MESSAGE_ID SRC_LIST objects are used.
The receiving node only generates an Srefresh NACK when the node
would forward packets to the identified group from the listed sender.
If the node would forward multicast data packets from a listed sender
and there is a corresponding unmatched Message_Identifier field, then
an appropriate Srefresh NACK MUST be generated. If the node would
not forward packets to the identified group from a listed sender, a
corresponding unmatched Message_Identifier field is silently ignored.
5.4. Srefresh NACK
Srefresh NACKs are used to indicate that a received
Message_Identifier field carried in MESSAGE_ID LIST, SRC_LIST, or
MCAST_LIST object does not match any installed state. This may occur
for a number of reasons including, for example, a route change. An
Srefresh NACK is encoded in a MESSAGE_ID_NACK object. When
generating an Srefresh NACK, the epoch and Message_Identifier fields
of the MESSAGE_ID_NACK object MUST have the same value as was
received. MESSAGE_ID_NACK objects are transmitted as described in
Section 4.6.
Received MESSAGE_ID_NACK objects indicate that the object generator
does not have any installed state matching the object. Upon
receiving a MESSAGE_ID_NACK object, the receiver performs an
installed Path or Resv state lookup based on the Epoch and
Message_Identifier values contained in the object. If matching state
is found, then the receiver MUST transmit the matching state via a
standard Path or Resv message. If the receiver cannot identify any
installed state, then no action is required.
5.5. Preserving RSVP Soft State
As discussed in [RFC2205], RSVP uses soft state to address a large
class of potential errors. RSVP does this by periodically sending a
full representation of installed state in Resv and Path messages.
Srefresh messages are used in place of the periodic sending of
standard Path and Resv refresh messages. While this provides scaling
benefits and protects against common network events such as packet
loss or routing change, it does not provide exactly the same error
recovery properties. An example error that could potentially be
recovered from via standard messages but not with Srefresh messages
is internal corruption of state. This section recommends two methods
that can be used to better preserve RSVP's soft state error recovery
mechanism. Both mechanisms are supported using existing protocol
messages.
The first mechanism uses a checksum or other algorithm to detect a
previously unnoticed change in internal state. This mechanism does
not protect against internal state corruption. It just covers the
case where a trigger message should have been sent, but was not.
When sending a Path or Resv trigger message, a node should run a
checksum or other algorithm, such as [MD5], over the internal state
and store the result. The choice of algorithm is an administrative
decision. Periodically the node should rerun the algorithm and
compare the new result with the stored result. If the values differ,
then a corresponding standard Path or Resv refresh message should be
sent and the new value should be stored. The recomputation period
should be set based on the computation resources of the node and the
reliability requirements of the network.
The second mechanism is simply to periodically send standard Path and
Resv refresh messages. Since this mechanism uses standard refresh
messages, it can recover from the same set of errors as standard
RSVP. When using this mechanism, the period that standard refresh
messages are sent must be longer than the interval that Srefresh
messages are generated in order to gain the benefits of using the
summary refresh extension. When a standard refresh message is sent,
a corresponding summary refresh SHOULD NOT be sent during the same
refresh period. When a node supports the periodic generation of
standard refresh messages while Srefreshes are being used, the
frequency of generation of standard refresh messages relative to the
generation of summary refreshes SHOULD be configurable by the network
administrator.
5.6. Compatibility
Nodes supporting the summary refresh extension advertise their
support via the Refresh-Reduction-Capable bit in the RSVP message
header. This enables nodes supporting the extension to detect each
other. When it is not known if a next hop supports the extension,
standard Path and Resv message based refreshes MUST be used. Note
that when the routing next hop does not support RSVP, it will not
always be possible to detect if the RSVP next hop supports the
summary refresh extension. Therefore, when the routing next hop is
not RSVP capable the Srefresh message based refresh SHOULD NOT be
used. A node MAY be administratively configured to use Srefresh
messages in all cases when all RSVP nodes in a network are known to
support the summary refresh extension. This is useful since when
operating in this mode, the extension properly adjusts to the case of
non-RSVP next hops and changes in routing.
Per section 2, nodes supporting the summary refresh extension must
also take care to recognize when a next hop stops sending RSVP
messages with the Refresh-Reduction-Capable bit set.
6. Exponential Back-Off Procedures
This section is based on [Pan] and provides procedures to implement
exponential back-off for retransmission of messages awaiting
acknowledgment, see Section 4.5. Implementations MUST use the
described procedures or their equivalent.
6.1. Outline of Operation
The following is one possible mechanism for exponential back-off
retransmission of an unacknowledged RSVP message: When sending such a
message, a node inserts a MESSAGE_ID object with the ACK_Desired flag
set. The sending node will retransmit the message until a message
acknowledgment is received or the message has been transmitted a
maximum number of times. Upon reception, a receiving node
acknowledges the arrival of the message by sending back a message
acknowledgment (that is, a corresponding MESSAGE_ID_ACK object.)
When the sending node receives the acknowledgment retransmission of
the message is stopped. The interval between retransmissions is
governed by a rapid retransmission timer. The rapid retransmission
timer starts at a small interval and increases exponentially until it
reaches a threshold.
6.2. Time Parameters
The described procedures make use of the following time parameters.
All parameters are per interface.
Rapid retransmission interval Rf:
Rf is the initial retransmission interval for unacknowledged
messages. After sending the message for the first time, the
sending node will schedule a retransmission after Rf seconds.
The value of Rf could be as small as the round trip time
(RTT) between a sending and a receiving node, if known.
Rapid retry limit Rl:
Rl is the maximum number of times a message will be
transmitted without being acknowledged.
Increment value Delta:
Delta governs the speed with which the sender increases the
retransmission interval. The ratio of two successive
retransmission intervals is (1 + Delta).
Suggested default values are an initial retransmission timeout (Rf)
of 500ms, a power of 2 exponential back-off (Delta = 1) and a retry
limit (Rl) of 3.
6.3. Retransmission Algorithm
After a sending node transmits a message containing a MESSAGE_ID
object with the ACK_Desired flag set, it should immediately schedule
a retransmission after Rf seconds. If a corresponding MESSAGE_ID_ACK
object is received earlier than Rf seconds, then retransmission
SHOULD be canceled. Otherwise, it will retransmit the message after
(1 + Delta)*Rf seconds. The staged retransmission will continue
until either an appropriate MESSAGE_ID_ACK object is received, or the
rapid retry limit, Rl, has been reached.
A sending node can use the following algorithm when transmitting a
message containing a MESSAGE_ID object with the ACK_Desired flag set:
Prior to initial transmission initialize: Rk = Rf and Rn = 0
while (Rn++ < Rl) {
transmit the message;
wake up after Rk seconds;
Rk = Rk * (1 + Delta);
}
/* acknowledged or no reply from receiver for too long: */ do any
needed clean up; exit;
Asynchronously, when a sending node receives a corresponding
MESSAGE_ID_ACK object, it will change the retry count, Rn, to Rl.
Note that the transmitting node does not advertise the use of the
described exponential back-off procedures via the TIME_VALUE object.
6.4. Performance Considerations
The use of exponential back-off retransmission is a new and
significant addition to RSVP. It will be important to review related
operations and performance experience before this document advances
to Draft Standard. It will be particularly important to review
experience with multicast, and any ACK implosion problems actually
encountered.
7. Acknowledgments
This document represents ideas and comments from the MPLS-TE design
team and participants in the RSVP Working Group's interim meeting.
Thanks to Bob Braden, Lixia Zhang, Fred Baker, Adrian Farrel, Roch
Guerin, Kireeti Kompella, David Mankins, Henning Schulzrinne, Andreas
Terzis, Lan Wang and Masanobu Yuhara for specific feedback on the
various versions of the document.
Portions of this work are based on work done by Masanobu Yuhara and
Mayumi Tomikawa [Yuhara].
8. Security Considerations
No new security issues are raised in this document. See [RFC2205]
for a general discussion on RSVP security issues.
9. References
[Pan] Pan, P., Schulzrinne, H., "Staged Refresh Timers for RSVP,"
Global Internet'97, Phoenix, AZ, November 1997.
http://www.cs.columbia.edu/~pingpan/papers/timergi.pdf
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321,
April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
Jamin , "Resource ReserVation Protocol -- Version 1
Functional Specification", RFC2205, September 1997.
[Yuhara] Yuhara, M., and M Tomikawa, "RSVP Extensions for ID-based
Refreshes", Work in Progress.
10. Authors' Addresses
Lou Berger
LabN Consulting, LLC
Phone: +1 301 468 9228
EMail: lberger@labn.net
Der-Hwa Gan
Juniper Networks, Inc.
1194 N. Mathilda Avenue,
Sunnyvale, CA 94089
Voice: +1 408 745 2074
Email: dhg@juniper.net
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Ping Pan
Juniper Networks, Inc.
1194 N. Mathilda Avenue,
Sunnyvale, CA 94089
Voice: +1 408 745 3704
Email: pingpan@juniper.net
Franco Tommasi
University of Lecce, Fac. Ingegneria
Via Monteroni 73100 Lecce, ITALY
EMail: franco.tommasi@unile.it
Simone Molendini
University of Lecce, Fac. Ingegneria
Via Monteroni 73100 Lecce, ITALY
EMail: molendini@ultra5.unile.it
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.