segment to which the forwarding interface is attached, it is
*not* required to retrieve and store the PHOP info. If it does
not do so, the SBM must leave the standard RSVP HOP object and
the RSVP_HOP_L2 objects in the PATH message intact and it will
not receive RESV messages.
If the SBM on a L2 device chooses to overwrite the RSVP HOP and
RSVP_HOP_L2 objects with the IP and L2 addresses of its
forwarding interface, it will receive RESV messages. In this
case, it must store the PHOP address info received in the
standard RSVP_HOP field and RSVP_HOP_L2 objects of the incident
PATH message.
In both the cases mentioned above (L2 or L3 devices), the SBM
must forward the TCLASS object in the received PATH message
unchanged.
* Copy the IP address of the forwarding interface into the
LAN_LOOPBACK object, unless the SBM protocol entity is a DSBM
reflecting a PATH message back onto the incident interface.
(See the section below on "Additional notes on forwarding a
PATH message onto a managed segment").
* If the SBM protocol entity is the DSBM for the segment to which
the forwarding interface is attached, it must send the PATH
message to the AllSBMAddress.
* If the SBM protocol entity is a SBM or a DSBM Client on the
segment to which the forwarding interface is attached, it must
send the PATH message to the DSBMLogicalAddress.
5.5.1. Additional notes on forwarding a PATH message onto a managed
segment
Rule #1 states that normal IEEE 802.1D forwarding rules should be
used to determine the interfaces on which the PATH message should be
forwarded. In the case of data packets, standard forwarding rules at
a L2 device dictate that the packet should not be forwarded on the
interface from which it was received. However, in the case of a DSBM
that receives a PATH message over a managed segment, the following
exception applies:
E1. If the address in the LAN_NHOP object is a unicast address,
consult the filtering database (FDB) to determine whether the
destination address is listed on the same interface over which
the message was received. If yes, follow the rule below on
"reflecting a PATH message back onto an interface" described
below; otherwise, proceed with the rest of the message
processing as usual.
E2. If there are members of the multicast group address (specified
by the addresses in the LAN_NHOP object), on the segment from
which the message was received, the message should be
forwarded back onto the interface from which it was received
and follow the rule on "reflecting a PATH message back onto an
interface" described below.
*** Reflecting a PATH message back onto an interface ***
Under the circumstances described above, when a DSBM reflects the
PATH message back onto an interface over which it was received, it
must address it using the AllSBMAddress.
Since it is possible for a DSBM to reflect a PATH message back
onto the interface from which it was received, precautions must be
taken to avoid looping these messages indefinitely. The
LAN_LOOPBACK object addresses this issue. All SBM protocol
entities (except DSBMs reflecting a PATH message) overwrite the
LAN_LOOPBACK object in the PATH message with the IP address of the
outgoing interface. DSBMs which are reflecting a PATH message,
leave the LAN_LOOPBACK object unchanged. Thus, SBM protocol
entities will always be able to recognize a reflected multicast
message by the presence of their own address in the LAN_LOOPBACK
object. These messages should be silently discarded.
5.6. Applying the Rules -- Unicast Session
Let's see how the rules are applied in the general network
illustrated previously (see Figure 2).
Assume that H1 is sending a PATH for a unicast session for which H5
is the receiver. The following PATH message is composed by H1:
RSVP Contents
RSVP session IP address IP address of H5 (3.0.0.35)
Sender Template IP address of H1 (1.0.0.11)
PHOP IP address of H1 (1.0.0.11)
RSVP_HOP_L2 n/a (H1 is not sending onto a managed
segment)
LAN_NHOP n/a (H1 is not sending onto a managed
segment)
LAN_LOOPBACK n/a (H1 is not sending onto a managed
segment)
IP Header
Source address IP address of H1 (1.0.0.11)
Destn address IP addr of H5 (3.0.0.35, assuming raw mode
& router alert)
MAC Header
Destn address The L2 addr corresponding to R1 (determined
by map_addr() and routing tables at H1)
Since H1 is not sending onto a managed segment, the PATH message is
composed and forwarded according to standard RSVP processing rules.
Upon receipt of the PATH message, R1 composes and forwards a PATH
message as follows:
RSVP Contents
RSVP session IP address IP address of H5
Sender Template IP address of H1
PHOP IP address of R1 (2.0.0.1)
(seed the return path for RESV messages)
RSVP_HOP_L2 L2 address of R1
LAN_NHOP LAN_NHOP_L3 (2.0.0.2) and
LAN_NHOP_L2 address of R2 (L2ADDR)
(this is the next layer 3 hop)
LAN_LOOPBACK IP address of R1 (2.0.0.1)
IP Header
Source address IP address of H1
Destn address DSBMLogical IP address (224.0.0.16)
MAC Header
Destn address DSBMLogical MAC address
* R1 does a routing lookup on the RSVP session address, to
determine the IP address of the next layer 3 hop, R2.
* It determines that R2 is accessible via seg A and that seg A
is managed by a DSBM, S1.
* Therefore, it concludes that it is sending onto a managed
segment, and composes LAN_NHOP objects to carry the layer 3
and layer 2 next hop addresses. To compose the LAN_NHOP
L2ADDR object, it invokes the L3 to L2 address mapping function
("map_address") to find out the MAC address for the next hop
L3 device, and then inserts a LAN_NHOP_L2ADDR object (that
carries the MAC address) in the message.
* Since R1 is not the DSBM for seg A, it sends the PATH message
to the DSBMLogicalAddress.
Upon receipt of the PATH message, S1 composes and forwards a PATH
message as follows:
RSVP Contents
RSVP session IP address IP address of H5
Sender Template IP address of H1
PHOP IP addr of S1 (seed the return path for RESV
messages)
RSVP_HOP_L2 L2 address of S1
LAN_NHOP LAN_NHOP_L3 (IP) and LAN_NHOP_L2
address of R2
(layer 2 devices do not modify the LAN_NHOP)
LAN_LOOPBACK IP addr of S1
IP Header
Source address IP address of H1
Destn address AllSBMIPaddr (224.0.0.17, since S1 is the
DSBM for seg B).
MAC Header
Destn address All SBM MAC address (since S1 is the DSBM
for seg B).
* S1 looks at the LAN_NHOP address information to determine the
L2 address towards which it should forward the PATH message.
* From the bridge forwarding tables, it determines that the L2
address is reachable via seg B.
* S1 inserts the RSVP_HOP_L2 object and overwrites the RSVP HOP
object (PHOP) with its own addresses.
* Since S1 is the DSBM for seg B, it addresses the PATH message
to the AllSBMAddress.
Upon receipt of the PATH message, S3 composes and forwards a PATH
message as follows:
RSVP Contents
RSVP session IP addr IP address of H5
Sender Template IP address of H1
PHOP IP addr of S3 (seed the return
path for RESV messages)
RSVP_HOP_L2 L2 address of S3
LAN_NHOP LAN_NHOP_L3 (IP) and
LAN_NHOP_L2 (MAC) address of R2
(L2 devices don't modify LAN_NHOP)
LAN_LOOPBACK IP address of S3
IP Header
Source address IP address of H1
Destn address DSBMLogical IP addr (since S3 is
not the DSBM for seg F)
MAC Header
Destn address DSBMLogical MAC address
* S3 looks at the LAN_NHOP address information to determine the
L2 address towards which it should forward the PATH message.
* From the bridge forwarding tables, it determines that the L2
address is reachable via segment F.
* It has discovered that R2 is the DSBM for segment F. It
therefore sends the PATH message to the DSBMLogicalAddress.
* Note that S3 may or may not choose to overwrite the PHOP
objects with its own IP and L2 addresses. If it does so, it
will receive RESV messages. In this case, it must also store
the PHOP info received in the incident PATH message so that
it is able to forward the RESV messages on the correct path.
Upon receipt of the PATH message, R2 composes and forwards a PATH
message as follows:
RSVP Contents
RSVP session IP addr IP address of H5
Sender Template IP address of H1
PHOP IP addr of R2 (seed the return path for RESV
messages)
RSVP_HOP_L2 Removed by R2 (R2 is not sending onto a
managed segment)
LAN_NHOP Removed by R2 (R2 is not sending onto a
managed segment)
IP Header
Source address IP address of H1
Destn address IP address of H5, the RSVP session address
MAC Header
Destn address L2 addr corresponding to H5, the next
layer 3 hop
* R2 does a routing lookup on the RSVP session address, to
determine the IP address of the next layer 3 hop, H5.
* It determines that H5 is accessible via a segment for which
there is no DSBM (not a managed segment).
* Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects
and places the RSVP session address in the destination
address of the IP header. It places the L2 address of the
next layer 3 hop, into the destination address of the MAC
header and forwards the PATH message to H5.
5.7. Applying the Rules - Multicast Session
The rules described above also apply to multicast (m/c) sessions.
For the purpose of this discussion, it is assumed that layer 2
devices track multicast group membership on each port individually.
Layer 2 devices which do not do so, will merely generate extra
multicast traffic. This is the case for L2 devices which do not
implement multicast filtering or GARP/GMRP capability.
Assume that H1 is sending a PATH for an m/c session for which H3 and
H5 are the receivers. The rules are applied as they are in the
unicast case described previously, until the PATH message reaches R2,
with the following exception. The RSVP session address and the
LAN_NHOP carry the destination m/c addresses rather than the unicast
addresses carried in the unicast example.
Now let's look at the processing applied by R2 upon receipt of the
PATH message. Recall that R2 is the DSBM for segment F. Therefore, S3
will have forwarded its PATH message to the DSBMLogicalAddress, to be
picked up by R2. The PATH message will not have been seen by H3 (one
of the m/c receivers), since it monitors only the AllSBMAddress, not
the DSBMLogicalAddress for incoming PATH messages. We rely on R2 to
reflect the PATH message back onto seg f, and to forward it to H5. R2
forwards the following PATH message onto seg f:
RSVP Contents
RSVP session addr m/c session address
Sender Template IP address of H1
PHOP IP addr of R2 (seed the return path for
RESV messages)
RSVP_HOP_L2 L2 addr of R2
LAN_NHOP m/c session address and corresponding L2 address
LAN_LOOPBACK IP addr of S3 (DSBMs reflecting a PATH
message don't modify this object)
IP Header
Source address IP address of H1
Destn address AllSBMIP address (since R2 is the DSBM for seg F)
MAC Header
Destn address AllSBMMAC address (since R2 is the
DSBM for seg F)
Since H3 is monitoring the All SBM Address, it will receive the PATH
message reflected by R2. Note that R2 violated the standard
forwarding rules here by sending an incoming message back onto the
interface from which it was received. It protected against loops by
leaving S3's address in the LAN_LOOPBACK object unchanged.
R2 forwards the following PATH message on to H5:
RSVP Contents
RSVP session addr m/c session address
Sender Template IP address of H1
PHOP IP addr of R2 (seed the return path for RESV
messages)
RSVP_HOP_L2 Removed by R2 (R2 is not sending onto a
managed segment)
LAN_NHOP Removed by R2 (R2 is not sending onto a
managed segment)
LAN_LOOPBACK Removed by R2 (R2 is not sending onto a
managed segment)
IP Header
Source address IP address of H1
Destn address m/c session address
MAC Header
Destn address MAC addr corresponding to the m/c
session address
* R2 determines that there is an m/c receiver accessible via a
segment for which there is no DSBM. Therefore, it removes the
LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session
address in the destination address of the IP header. It
places the corresponding L2 address into the destination
address of the MAC header and multicasts the message towards
H5.
5.8. Merging Traffic Class objects
When a DSBM client receives TCLASS objects from different senders
(different PATH messages) in the same RSVP session and needs to
combine them for sending back a single RESV message (as in a wild-
card style reservation), the DSBM client must choose an appropriate
value that corresponds to the desired-delay traffic class. An
accompanying document discusses the guidelines for traffic class
selection based on desired service and the TSpec information [RFC-
MAP].
In addition, when a SBM or DSBM needs to merge RESVs from different
next hops at a merge point, it must decide how to handle the TCLASS
values in the incoming RESVs if they do not match. Consider the case
when a reservation is in place for a flow at a DSBM (or SBM) with a
successful admission control done for the TCLASS requested in the
first RESV for the flow. If another RESV (not the refresh of the
previously admitted RESV) for the same flow arrives at the DSBM, the
DSBM must first check the TCLASS value in the new RESV against the
TCLASS value in the already installed RESV. If the two values are
same, the RESV requests are merged and the new, merged RESV installed
and forwarded using the normal rules of message processing. However,
if the two values are not identical, the DSBM must generate and send
a RESV_ERR message towards the sender (NHOP) of the newer, RESV
message. The RESV_ERR must specify the error code corresponding to
the RSVP "traffic control error" (RESV_ERR code 21) that indicates
failure to merge two incompatible service requests (sub-code 01 for
the RSVP traffic control error) [RFC-2205]. The RESV_ERR message may
include additional objects to assist downstream nodes in recovering
from this condition. The definition and usage of such objects is
beyond the scope of this memo.
5.9. Operation of SBM Transparent Devices
SBM transparent devices are unaware of the entire SBM/DSBM protocol.
They do not intercept messages addressed to either of the SBM related
local group addresses (the DSBMLogicalAddrss and the ALLSBMAddress),
but instead, pass them through. As a result, they do not divide the
DSBM election scope, they do not explicitly participate in routing of
PATH or RESV messages, and they do not participate in admission
control. They are entirely transparent with respect to SBM operation.
According to the definitions provided, physical segments
interconnected by SBM transparent devices are considered a single
managed segment. Therefore, DSBMs must perform admission control on
such managed segments, with limited knowledge of the segment's
topology. In this case, the network administrator should configure
the DSBM for each managed segment, with some reasonable approximation
of the segment's capacity. A conservative policy would configure the
DSBM for the lowest capacity route through the managed segment. A
liberal policy would configure the DSBM for the highest capacity
route through the managed segment. A network administrator will
likely choose some value between the two, based on the level of
guarantee required and some knowledge of likely traffic patterns.
This document does not specify the configuration mechanism or the
choice of a policy.
5.10. Operation of SBMs Which are NOT DSBMs
In the example illustrated, S3 hosts a SBM, but the SBM on S3 did not
win the election to act as DSBM on any segment. One might ask what
purpose such a SBM protocol entity serves. Such SBMs actually provide
two useful functions. First, the additional SBMs remain passive in
the background for fault tolerance. They listen to the periodic
announcements from the current DSBM for the managed segment (Appendix
A describes this in more detail) and step in to elect a new DSBM when
the current DSBM fails or ceases to be operational for some reason.
Second, such SBMs also provide the important service of dividing the
election scope and reducing the size and complexity of managed
segments. For example, consider the sample topology in Figure 3
again. the device S3 contains an SBM that is not a DSBM for any f the
segments, B, E, or F, attached to it. However, if the SBM protocol
entity on S3 was not present, segments B and F would not be separate
segments from the point of view of the SBM protocol. Instead, they
would constitute a single managed segment, managed by a single DSBM.
Because the SBM entity on S3 divides the election scope, seg B and
seg F are each managed by separate DSBMs. Each of these segments have
a trivial topology and a well defined capacity. As a result, the
DSBMs for these segments do not need to perform admission control
based on approximations (as would be the case if S3 were SBM
transparent).
Note that, SBM protocol entities which are not DSBMs, are not
required to overwrite the PHOP in incident PATH messages with their
own address. This is because it is not necessary for RESV messages to
be routed through these devices. RESV messages are only required to
be routed through the correct sequence of DSBMs. SBMs may not
process RESV messages that do pass through them, other than to
forward them towards their destination address, using standard
forwarding rules.
SBM protocol entities which are not DSBMs are required to overwrite
the address in the LAN_LOOPBACK object with their own address, in
order to avoid looping multicast messages. However, no state need be
stored.
6. Inter-Operability Considerations
There are a few interesting inter-operability issues related to the
deployment of a DSBM-based admission control method in an environment
consisting of network nodes with and without RSVP capability. In the
following, we list some of these scenarios and explain how SBM-aware
clients and nodes can operate in those scenarios:
6.1. An L2 domain with no RSVP capability.
It is possible to envisage L2 domains that do not use RSVP signaling
for requesting resource reservations, but, instead, use some other
(e.g., SNMP or static configuration) mechanism to reserve bandwidth
at a particular network device such as a router. In that case, the
question is how does a DSBM-based admission control method work and
interoperate with the non-RSVP mechanism. The SBM-based method does
not attempt to provide an admission control solution for such an
environment. The SBM-based approach is part of an end to end
signaling approach to establish resource reservations and does not
attempt to provide a solution for SNMP-based configuration scenario.
As stated earlier, the SBM-based approach can, however, co-exist with
any other, non-RSVP bandwidth allocation mechanism as long as
resources being reserved are either partitioned statically between
the different mechanisms or are resolved dynamically through a common
bandwidth allocator so that there is no over-commitment of the same
resource.
6.2. An L2 domain with SBM-transparent L2 Devices.
This scenario has been addressed earlier in the document. The SBM-
based method is designed to operate in such an environment. When
SBM-transparent L2 devices interconnect SBM-aware devices, the
resulting managed segment is a combination of one or more physical
segments and the DSBM for the managed segment may not be as efficient
in allocating resources as it would if all L2 devices were SBM-aware.
6.3. An L2 domain on which some RSVP-based senders are not DSBM clients.
All senders that are sourcing RSVP-based traffic flows onto a managed
segment MUST be SBM-aware and participate in the SBM protocol. Use
of the standard, non-SBM version of RSVP may result in over-
allocation of resources, as such use bypasses the resource management
function of the DSBM. All other senders (i.e., senders that are not
sending streams subject to RSVP admission control) should be elastic
applications that send traffic of lower priority than the RSVP
traffic, and use TCP-like congestion avoidance mechanisms.
All DSBMs, SBMs, or DSBM clients on a managed segment (a segment with
a currently active DSBM) must not accept PATH messages from senders
that are not SBM-aware. PATH messages from such devices can be easily
detected by SBMs and DSBM clients as they would not be multicast to
the ALLSBMAddress (in case of SBMs and DSBM clients) or the
DSBMLogicalAddress (in case of DSBMs).
6.4. A non-SBM router that interconnects two DSBM-managed L2 domains.
Multicast SBM messages (e.g., election and PATH messages) have local
scope and are not intended to pass between the two domains. A
correctly configured non-SBM router will not pass such messages
between the domains. A broken router implementation that does so may
cause incorrect operation of the SBM protocol and consequent over- or
under-allocation of resources.
6.5. Interoperability with RSVP clients that use UDP encapsulation and
are not capable of receiving/sending RSVP messages using RAW_IP
This document stipulates that DSBMs, DSBM clients, and SBMs use only
raw IP for encapsulating RSVP messages that are forwarded onto a L2
domain. RFC-2205 (the RSVP Proposed Standard) includes support for
both raw IP and UDP encapsulation. Thus, a RSVP node using only the
UDP encapsulation will not be able to interoperate with the DSBM
unless DSBM accepts and supports UDP encapsulated RSVP messages.
7. Guidelines for Implementers
In the following, we provide guidelines for implementers on different
aspects of the implementation of the SBM-based admission control
procedure including suggestions for DSBM initialization, etc.
7.1. DSBM Initialization
As stated earlier, DSBM initialization includes configuration of
maximum bandwidth that can be reserved on a managed segment under its
control. We suggest the following guideline.
In the case of a managed segment consisting of L2 devices
interconnected by a single shared segment, DSBM entities on such
devices should assume the bandwidth of the interface as the total
link bandwidth. In the case of a DSBM located in a L2 switch, it
might additionally need to be configured with an estimate of the
device's switching capacity if that is less than the link bandwidth,
and possibly with some estimate of the buffering resources of the
switch (see [RFC-FRAME] for the architectural model assumed for L2
switches). Given the total link bandwidth, the DSBM may be further
configured to limit the maximum amount of bandwidth for RSVP-enabled
flows to ensure spare capacity for best-effort traffic.
7.2. Operation of DSBMs in Different L2 Topologies
Depending on a L2 topology, a DSBM may be called upon to manage
resources for one or more segments and the implementers must bear in
mind efficiency implications of the use of DSBM in different L2
topologies. Trivial L2 topologies consist of a single "physical
segment". In this case, the 'managed segment' is equivalent to a
single segment. Complex L2 topologies may consist of a number of
Admission control on such an L2 extended segment can be performed
from a single pool of resources, similar to a single shared segment,
from the point of view of a single DSBM.
This configuration compromises the efficiency with which the DSBM can
allocate resources. This is because the single DSBM is required to
make admission control decisions for all reservation requests within
the L2 topology, with no knowledge of the actual physical segments
affected by the reservation.
We can realize improvements in the efficiency of resource allocation
by subdividing the complex segment into a number of managed segments,
each managed by their own DSBM. In this case, each DSBM manages a
managed segment having a relatively simple topology. Since managed
segments are simpler, the DSBM can be configured with a more accurate
estimate of the resources available for all reservations in the
managed segment. In the ultimate configuration, each physical segment
is a managed segment and is managed by its own DSBM. We make no
assumption about the number of managed segments but state, simply,
that in complex L2 topologies, the efficiency of resource allocation
improves as the granularity of managed segments increases.
8. Security Considerations
The message formatting and usage rules described in this note raise
security issues, identical to those raised by the use of RSVP and
Integrated Services. It is necessary to control and authenticate
access to enhanced qualities of service enabled by the technology
described in this RFC. This requirement is discussed further in
[RFC-2205], [RFC-2211], and [RFC-2212].
[RFC-RSVPMD5] describes the mechanism used to protect the integrity
of RSVP messages carrying the information described here. A SBM
implementation should satisfy the requirements of that RFCand
provide the suggested mechanisms just as though it were a
conventional RSVP implementation. It should further use the same
mechanisms to protect the additional, SBM-specific objects in a
message.
Finally, it is also necessary to authenticate DSBM candidates during
the election process, and a mechanism based on a shared secret among
the DSBM candidates may be used. The mechanism defined in [RFC-
RSVPMD5] should be used.
9. References
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC2205, September 1997.
[RFC-RSVPMD5] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC2747, January 2000.
[RFC2206] Baker, F. and J. Krawczyk, "RSVP Management Information
Base", RFC2206, September 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC2211, September 1997.
[RFC2212] Shenker, S., Partridge, C. and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[RFC2215] Shenker, S. and J. Wroclawski, "General
Characterization Parameters for Integrated Service
Network Elements", RFC2215, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC2210, September 1997.
[RFC2213] Baker, F. and J. Krawczyk, "Integrated Services
Management Information Base", RFC2213, September 1997.
[RFC-FRAME] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A. and
M.Seaman, "A Framework for Providing Integrated
Services Over Shared and Switched LAN Technologies",
RFC2816, May 2000.
[RFC-MAP] Seaman, M., Smith, A. and E. Crawley, "Integrated
Service Mappings on IEEE 802 Networks", RFC2815, May
2000.
[IEEE802Q] "IEEE Standards for Local and Metropolitan Area
Networks: Virtual Bridged Local Area Networks", Draft
Standard P802.1Q/D9, February 20, 1998.
[IEEEP8021p] "Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Common specifications -
Part 3: Media Access Control (MAC) Bridges: Revision
(Incorporating IEEE P802.1p: Traffic Class Expediting
and Dynamic Multicast Filtering)", ISO/IEC Final CD
15802-3 IEEE P802.1D/D15, November 24, 1997.
[IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-
1993.
A.1. Introduction
To simplify the rest of this discussion, we will assume that there is
a single DSBM for the entire L2 domain (i.e., assume a shared L2
segment for the entire L2 domain). Later, we will discuss how a DSBM
is elected for a half-duplex or full-duplex switched segment.
To allow for quick recovery from the failure of a DSBM, we assume
that additional SBMs may be active in a L2 domain for fault
tolerance. When more than one SBM is active in a L2 domain, the SBMs
use an election algorithm to elect a DSBM for the L2 domain. After
the DSBM is elected and is operational, other SBMs remain passive in
the background to step in to elect a new DSBM when necessary. The
protocol for electing and discovering DSBM is called the "DSBM
election protocol" and is described in the rest of this Appendix.
A.1.1. How a DSBM Client Detects a Managed Segment
Once elected, a DSBM periodically multicasts an I_AM_DSBM message on
the AllSBMAddress to indicate its presence. The message is sent every
period (e.g., every 5 seconds) according to the RefreshInterval timer
value (a configuration parameter). Absence of such a message over a
certain time interval (called "DSBMDeadInterval"; another
configuration parameter typically set to a multiple of
RefreshInterval) indicates that the DSBM has failed or terminated and
triggers another round of the DSBM election. The DSBM clients always
listen for periodic DSBM advertisements. The advertisement includes
the unicast IP address of the DSBM (DSBMAddress) and DSBM clients
send their PATH/RESV (or other) messages to the DSBM. When a DSBM
client detects the failure of a DSBM, it waits for a subsequent
I_AM_DSBM advertisement before resuming any communication with the
DSBM. During the period when a DSBM is not present, a DSBM client may
forward outgoing PATH messages using the standard RSVP forwarding
rules.
The exact message formats and addresses used for communication with
(and among) SBM(s) are described in Appendix B.
A.2. Overview of the DSBM Election Procedure
When a SBM first starts up, it listens for incoming DSBM
advertisements for some period to check whether a DSBM already exists
in its L2 domain. If one already exists (and no new election is in
progress), the new SBM stays quiet in the background until an
election of DSBM is necessary. All messages related to the DSBM
election and DSBM advertisements are always sent to the
AllSBMAddress.
If no DSBM exists, the SBM initiates the election of a DSBM by
sending out a DSBM_WILLING message that lists its IP address as a
candidate DSBM and its "SBM priority". Each SBM is assigned a
priority to determine its relative precedence. When more than one
SBM candidate exists, the SBM priority determines who gets to be the
DSBM based on the relative priority of candidates. If there is a tie
based on the priority value, the tie is broken using the IP
addresses of tied candidates (one with the higher IP address in the
lexicographic order wins). The details of the election protocol start
in Section A.4.
A.2.1 Summary of the Election Algorithm
For the purpose of the algorithm, a SBM is in one of the four states
(Idle, DetectDSBM, ElectDSBM, IAMDSBM).
A SBM (call it X) starts up in the DetectDSBM state and waits for a
ListenInterval for incoming I_AM_DSBM (DSBM advertisement) or
DSBM_WILLING messages. If an I_AM_DSBM advertisement is received
during this state, the SBM notes the current DSBM (its IP address and
priority) and enters the Idle state. If a DSBM_WILLING message is
received from another SBM (call it Y) during this state, then X
enters the ElectDSBM state. Before entering the new state, X first
checks to see whether it itself is a better candidate than Y and, if
so, sends out a DSBM_WILLING message and then enters the ElectDSBM
state.
When a SBM (call it X) enters the ElectDSBM state, it sets a timer
(called ElectionIntervalTimer, and typically set to a value at least
equal to the DSBMDeadInterval value) to wait for the election to
finish and to discover who is the best candidate. In this state, X
keeps track of the best (or better) candidate seen so far (including
itself). Whenever it receives another DSBM_WILLING message it updates
its notion of the best (or better) candidate based on the priority
(and tie-breaking) criterion. During the ElectionInterval, X sends
out a DSBM_WILLING message every RefreshInterval to (re)assert its
candidacy.
At the end of the ElectionInterval, X checks whether it is the best
candidate so far. If so, it declares itself to be the DSBM (by
sending out the I_AM_DSBM advertisement) and enters the IAMDSBM
state; otherwise, it decides to wait for the best candidate to
declare itself the winner. To wait, X re-initializes its ElectDSBM
state and continues to wait for another round of election (each round
lasts for an ElectionTimerInterval duration).
A SBM is in Idle state when no election is in progress and the DSBM
is already elected (and happens to be someone else). In this state,
it listens for incoming I_AM_DSBM advertisements and uses a
DSBMDeadIntervalTimer to detect the failure of DSBM. Every time the
advertisement is received, the timer is restarted. If the timer
fires, the SBM goes into the DetectDSBM state to prepare to elect the
new DSBM. If a SBM receives a DSBM_WILLING message from the current
DSBM in this state, the SBM enters the ElectDSBM state after sending
out a DSBM_WILLING message (to announce its own candidacy).
In the IAMDSBM state, the DSBM sends out I_AM_DSBM advertisements
every refresh interval. If the DSBM wishes to shut down (gracefully
terminate), it sends out a DSBM_WILLING message (with SBM priority
value set to zero) to initiate the election procedure. The priority
value zero effectively removes the outgoing DSBM from the election
procedure and makes way for the election of a different DSBM.
A.3. Recovering from DSBM Failure
When a DSBM fails (DSBMDeadIntervalTimer fires), all the SBMs enter
the ElectDSBM state and start the election process.
At the end of the ElectionInterval, the elected DSBM sends out an
I_AM_DSBM advertisement and the DSBM is then operational.
A.4. DSBM Advertisements
The I_AM_DSBM advertisement contains the following information:
1. DSBM address information -- contains the IP and L2 addresses of
the DSBM and its SBM priority (a configuration parameter --
priority specified by a network administrator). The priority
value is used to choose among candidate SBMs during the election
algorithm. Higher integer values indicate higher priority and the
value is in the range 0..255. The value zero indicates that the
SBM is not eligible to be the DSBM. The IP address is required
and used for breaking ties. The L2 address is for the interface
of the managed segment.
2. RegreshInterval -- contains the value of RefreshInterval in
seconds. Value zero indicates the parameter has been omitted in
the message. Receivers may substitute their own default value in
this case.
3. DSBMDeadInterval -- contains the value of DSBMDeadInterval in
seconds. If the value is omitted (or value zero is specified), a
default value (from initial configuration) should be used.
4. Miscellaneous configuration information to be advertised to
senders on the managed segment. See Appendix C for further
details.
A.5. DSBM_WILLING Messages
When a SBM wishes to declare its candidacy to be the DSBM during an
election phase, it sends out a DSBM_WILLING message. The DSBM_WILLING
message contains the following information:
1. DSBM address information -- Contains the SBM's own addresses (IP
and L2 address), if it wishes to be the DSBM. The IP address is
required and used for breaking ties. The L2 address is the
address of the interface for the managed segment in question.
Also, the DSBM address information includes the corresponding
priority of the SBM whose address is given above.
A.6. SBM State Variables
For each network interface, a SBM maintains the following state
variables related to the election of the DSBM for the L2 domain on
that interface:
a) LocalDSBMAddrInfo -- current DSBM's IP address (initially,
0.0.0.0) and priority. All IP addresses are assumed to be in
network byte order. In addition, current DSBM's L2 address is
also stored as part of this state information.
b) OwnAddrInfo -- SBM's own IP address and L2 address for the
interface and its own priority (a configuration parameter).
c) RefreshInterval in seconds. When the DSBM is not yet elected,
it is set to a default value specified as a configuration
parameter.
d) DSBMDeadInterval in seconds. When the DSBM is not yet elected,
it is initially set to a default value specified as a
configuration parameter.
f) ListenInterval in seconds -- a configuration parameter that
decides how long a SBM spends in the DetectDSBM state (see
below).
g) ElectionInterval in seconds -- a configuration parameter that
decides how long a SBM spends in the ElectDSBM state when it has
declared its candidacy.
Figure 3 shows the state transition diagram for the election protocol
and the various states are described below. A complete description of
the state machine is provided in Section A.10.
A.7. DSBM Election States
DOWN -- SBM is not operational.
DetectDSBM -- typically, the initial state of a SBM when it
starts up. In this state, it checks to see whether a DSBM already
exists in its domain.
Idle -- SBM is in this state when no election is in progress and
it is not the DSBM. In this state, SBM passively monitors the
state of the DSBM.
ElectDSBM -- SBM is in this state when a DSBM election is in
progress.
IAMDSBM -- SBM is in this state when it is the DSBM for the L2
domain.
A.8. Events that cause state changes
StartUp -- SBM starts operation.
ListenInterval Timeout -- The ListenInterval timer has fired.
This means that the SBM has monitored its domain to check for an
existing DSBM or to check whether there are candidates (other
than itself) willing to be the DSBM.
DSBM_WILLING message received -- This means that the SBM received
a DSBM_WILLING message from some other SBM. Such a message is
sent when a SBM wishes to declare its candidacy to be the DSBM.
I_AM_DSBM message received -- SBM received a DSBM advertisement
from the DSBM in its L2 domain.
DSBMDeadInterval Timeout -- The DSBMDeadIntervalTimer has fired.
This means that the SBM did not receive even one DSBM
advertisement during this period and indicates possible failure
of the DSBM.
RefreshInterval Timeout -- The RefreshIntervalTimer has fired. In
the IAMDSBM state, this means it is the time for sending out the
next DSBM advertisement. In the ElectDSBM state, the event means
that it is the time to send out another DSBM_WILLING message.
ElectionInterval Timeout -- The ElectionIntervalTimer has fired.
This means that the SBM has waited long enough after declaring
its candidacy to determine whether or not it succeeded.
A.9. State Transition Diagram (Figure 3)
+-----------+
+--<--------------<-|DetectDSBM |---->------+
| +-----------+ |
| |
| |
| |
| +-------------+ +---------+ |
+->---| Idle |--<>---|ElectDSBM|--<--+
+-------------+ +---------+
| |
| |
| |
| +-----------+ |
+<<- +---| IAMDSBM |-<-+
| +-----------+
|
| +-----------+
+>>-| SHUTDOWN |
+-----------+
A.10. Election State Machine
Based on the events and states described above, the state changes at
a SBM are described below. Each state change is triggered by an event
and is typically accompanied by a sequence of actions. The state
machine is described assuming a single threaded implementation (to
avoid race conditions between state changes and timer events) with no
timer events occurring during the execution of the state machine.
The following routines will be frequently used in the description of
the state machine:
ComparePrio(FirstAddrInfo, SecondAddrInfo)
-- determines whether the entity represented by the first parameter
is better than the second entity using the priority information
and the IP address information in the two parameters. If any
address is zero, that entity automatically loses; then first
priorities are compared; higher priority candidate wins. If there
is a tie based on the priority value, the tie is broken using the
IP addresses of tied candidates (one with the higher IP address
in the lexicographic order wins). Returns TRUE if first entity
is a better choice. FALSE otherwise.
SendDSBMWilling Message()
Begin
Send out DSBM_WILLING message listing myself as a candidate for
DSBM (copy OwnAddr and priority into appropriate fields)
start RefreshIntervalTimer
goto ElectDSBM state
End
AmIBetterDSBM(OtherAddrInfo)
Begin
if (ComparePrio(OwnAddrInfo, OtherAddrInfo))
return TRUE
change LocalDSBMInfo = OtherDSBMAddrInfo
return FALSE
End
UpdateDSBMInfo()
/* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */
Begin
update LocalDSBMInfo such as IP addr, DSBM L2 address,
DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer
End
A.10.1 State Changes
In the following, the action "continue" or "continue in current
state" means an "exit" from the current action sequence without a
state transition.
State: DOWN
Event: StartUp
New State: DetectDSBM
Action: Initialize the local state variables (LocalDSBMADDR and
LocalDSBMAddrInfo set to 0). Start the ListenIntervalTimer.
State: DetectDSBM
New State: Idle
Event: I_AM_DSBM message received
Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo
start DeadDSBMInterval timer
goto Idle State
State: DetectDSBM
Event: ListenIntervalTimer fired
New State: ElectDSBM
Action: Start ElectionIntervalTimer
SendDSBMWillingMessage();
State: DetectDSBM
Event: DSBM_WILLING message received
New State: ElectDSBM
Action: Cancel any active timers
Start ElectionIntervalTimer
/* am I a better choice than this dude? */
If (ComparePrio(OwnAddrInfo, IncomingDSBMInfo)) {
/* I am better */
SendDSBMWillingMessage()
} else {
Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
goto ElectDSBM state
}
State: Idle
Event: DSBMDeadIntervalTimer fired.
New State: ElectDSBM
Action: start ElectionIntervalTimer
set LocalDSBMAddrInfo = OwnAddrInfo
SendDSBMWiliingMessage()
State: Idle
Event: I_AM_DSBM message received.
New State: Idle
Action: /* first check whether anything has changed */
if (!ComparePrio(LocalDSBMAddrInfo, IncomingDSBMAddrInfo))
change LocalDSBMAddrInfo to reflect new info
endif
restart DSBMDeadIntervalTimer;
continue in current state;
State: Idle
Event: DSBM_WILLING Message is received
New State: Depends on action (ElectDSBM or Idle)
Action: /* check whether it is from the DSBM itself (shutdown) */
if (IncomingDSBMAddr == LocalDSBMAddr) {
cancel active timers
Set LocalDSBMAddrInfo = OwnAddrInfo
Start ElectionIntervalTimer
SendDSBMWillingMessage() /* goto ElectDSBM state */
}
/* else, ignore it */
continue in current state
State: ElectDSBM
Event: ElectionIntervalTimer Fired
New State: depends on action (IAMDSBM or Current State)
Action: If (LocalDSBMAddrInfo == OwnAddrInfo) {
/* I won */
send I_AM_DSBM message
start RefreshIntervalTimer
goto IAMDSBM state
} else { /* someone else won, so wait for it to declare
itself to be the DSBM */
set LocalDSBMAddressInfo = OwnAddrInfo
start ElectionIntervalTimer
SendDSBMWillingMessage()
continue in current state
}
State: ElectDSBM
Event: I_AM_DSBM message received
New State: Idle
Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo
Cancel any active timers
start DeadDSBMInterval timer
goto Idle State
State: ElectDSBM
Event: DSBM_WILLING message received
New State: ElectDSBM
Action: Check whether it's a loopback and if so, discard, continue;
if (!AmIBetterDSBM(IncomingDSBMAddrInfo)) {
Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
Cancel RefreshIntervalTimer
} else if (LocalDSBMAddrInfo == OwnAddrInfo) {
SendDSBMWillingMessage()
}
continue in current state
State: ElectDSBM
Event: RefreshIntervalTimer fired
New State: ElectDSBM
Action: /* continue to send DSBMWilling messages until
election interval ends */
SendDSBMWillingMessage()
State: IAMDSBM
Event: DSBM_WILLING message received
New State: depends on action (IAMDSBM or SteadyState)
Action: /* check whether other guy is better */
If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
/* I am better */
send I_AM_DSBM message
restart RefreshIntervalTimer
continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto SteadyState
}
State: IAMDSBM
Event: RefreshIntervalTimer fired
New State: IAMDSBM
Action: send I_AM_DSBM message
restart RefreshIntervalTimer
State: IAMDSBM
Event: I_AM_DSBM message received
New State: depends on action (IAMDSBM or Idle)
Action: /* check whether other guy is better */
If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
/* I am better */
send I_AM_DSBM message
restart RefreshIntervalTimer
continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto Idle State
}
State: IAMDSBM
Event: Want to shut myself down
New State: DOWN
Action: send DSBM_WILLING message with My address filled in, but
priority set to zero
goto Down State
A.10.2 Suggested Values of Interval Timers
To avoid DSBM outages for long period, to ensure quick recovery from
DSBM failures, and to avoid timeout of PATH and RESV state at the
edge devices, we suggest the following values for various timers.
Assuming that the RSVP implementations use a 30 second timeout for
PATH and RESV refreshes, we suggest that the RefreshIntervalTimer
should be set to about 5 seconds with DSBMDeadIntervalTimer set to 15
seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be set
to a random value between (DSBMDeadIntervalTimer,
2*DSBMDeadIntervalTimer). The ElectionIntervalTimer should be set at
least to the value of DSBMDeadIntervalTimer to ensure that each SBM
has a chance to have its DSBM_WILLING message (sent every
RefreshInterval in ElectDSBM state) delivered to others.
A.10.3. Guidelines for Choice of Values for SBM_PRIORITY
Network administrators should configure SBM protocol entity at each
SBM-capable device with the device's "SBM priority" for each of the
interfaces attached to a managed segment. SBM_PRIORITY is an 8-bit,
unsigned integer value (in the range 0-255) with higher integer
values denoting higher priority. The value zero for an interface