Connected: An Internet Encyclopedia
3.4 Avoiding RSVP Message Loops

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2205
Up: 3. RSVP Functional Specification
Prev: 3.3 Sending RSVP Messages
Next: 3.5 Blockade State

3.4 Avoiding RSVP Message Loops

3.4 Avoiding RSVP Message Loops

Forwarding of RSVP messages must avoid looping. In steady state, Path and Resv messages are forwarded on each hop only once per refresh period. This avoids looping packets, but there is still the possibility of an "auto-refresh" loop, clocked by the refresh period. Such auto-refresh loops keep state active "forever", even if the end nodes have ceased refreshing it, until the receivers leave the multicast group and/or the senders stop sending Path messages. On the other hand, error and teardown messages are forwarded immediately and are therefore subject to direct looping.

Consider each message type.

If the topology has no loops, then looping of Resv and ResvErr messages with wildcard sender selection can be avoided by simply enforcing the rule given earlier: state that is received through a particular interface must never be forwarded out the same interface. However, when the topology does have cycles, further effort is needed to prevent auto-refresh loops of wildcard Resv messages and fast loops of wildcard ResvErr messages. The solution to this problem adopted by this protocol specification is for such messages to carry an explicit sender address list in a SCOPE object.

When a Resv message with WF style is to be forwarded to a particular previous hop, a new SCOPE object is computed from the SCOPE objects that were received in matching Resv messages. If the computed SCOPE object is empty, the message is not forwarded to the previous hop; otherwise, the message is sent containing the new SCOPE object. The rules for computing a new SCOPE object for a Resv message are as follows:

  1. The union is formed of the sets of sender IP addresses listed in all SCOPE objects in the reservation state for the given session.

    If reservation state from some NHOP does not contain a SCOPE object, a substitute sender list must be created and included in the union. For a message that arrived on outgoing interface OI, the substitute list is the set of senders that route to OI.

  2. Any local senders (i.e., any sender applications on this node) are removed from this set.

  3. If the SCOPE object is to be sent to PHOP, remove from the set any senders that did not come from PHOP.

Figure 11 shows an example of wildcard-scoped (WF style) Resv messages. The address lists within SCOPE objects are shown in square brackets. Note that there may be additional connections among the nodes, creating looping topology that is not shown.

                         ________________
                      a |                | c
           R4, S4<----->|     Router     |<-----> R2, S2, S3
                        |                |
                      b |                |
           R1, S1<----->|                |
                        |________________|

          Send on (a):           |    Receive on (c):
                                 |
             <-- WF( [S4] )      |       <-- WF( [S4, S1])
                                 |
          Send on (b):           |
                                 |
             <-- WF( [S1] )      |
                                 |
          Receive on (a):        |    Send on (c):
                                 |
             WF( [S1,S2,S3]) --> |       WF( [S2, S3]) -->
                                 |
          Receive on (b):        |
                                 |
             WF( [S2,S3,S4]) --> |
                                 |

           Figure 11: SCOPE Objects in Wildcard-Scope Reservations

SCOPE objects are not necessary if the multicast routing uses shared trees or if the reservation style has explicit sender selection. Furthermore, attaching a SCOPE object to a reservation should be deferred to a node which has more than one previous hop for the reservation state.

The following rules are used for SCOPE objects in ResvErr messages with WF style:

  1. The node that detected the error initiates an ResvErr message containing a copy of the SCOPE object associated with the reservation state or message in error.

  2. Suppose a wildcard-style ResvErr message arrives at a node with a SCOPE object containing the sender host address list L. The node forwards the ResvErr message using the rules of Section 3.1.8. However, the ResvErr message forwarded out OI must contain a SCOPE object derived from L by including only those senders that route to OI. If this SCOPE object is empty, the ResvErr message should not be sent out OI.


Next: 3.5 Blockade State

Connected: An Internet Encyclopedia
3.4 Avoiding RSVP Message Loops