tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2814

 
 
 

SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks

Part 3 of 3, p. 36 to 60
Prev RFC Part

 


prevText      Top       Page 36 
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.

Top       Page 37 
   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).

Top       Page 38 
   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.

Top       Page 39 
   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.

Top       Page 40 
   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.

Top       Page 41 
       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.

Top       Page 42 
   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();

Top       Page 43 
 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

Top       Page 44 
 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

Top       Page 45 
                 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

Top       Page 46 
   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
   indicates that the SBM protocol entity on the device is not eligible
   to be a DSBM for the segment attached to the interface.

   A separate range of values is reserved for each type of SBM-capable
   device to reflect the relative priority among different classes of
   L2/L3 devices. L2 devices get higher priority followed by routers
   followed by hosts. The priority values in the range of 128..255 are
   reserved for L2 devices, the values in the range of 64..127 are
   reserved for routers, and values in the range of 1..63 are reserved
   for hosts.

A.11. DSBM Election over switched links

   The election algorithm works as described before in this case except
   each SBM-capable L2 device restricts the scope of the election to its
   local segment. As described in Section B.1 below, all messages
   related to the DSBM election are sent to a special multicast address
   (AllSBMAddress). AllSBMAddress (its corresponding MAC multicast
   address) is configured in the permanent database of SBM-capable,
   layer 2 devices so that all frames with AllSBMAddress as the
   destination address are not forwarded and instead directed to the SBM
   management entity in those devices. Thus, a DSBM can be elected
   separately on each point-to-point segment in a switched topology. For
   example, in Figure 2, DSBM for "segment A" will be elected using the
   election algorithm between R1 and S1 and none of the election-related
   messages on this segment will be forwarded by S1 beyond "segment A".
   Similarly, a separate election will take place on each segment in
   this topology.

   When a switched segment is a half-duplex segment, two senders (one
   sender at each end of the link) share the link. In this case, one of
   the two senders will win the DSBM election and will be responsible
   for managing the segment.

Top       Page 47 
   If a switched segment is full-duplex, exactly one sender sends on the
   link in each direction. In this case, either one or two DSBMs can
   exist on such a managed segment. If a sender at each end wishes to
   serve as a DSBM for that end, it can declare itself to be the DSBM by
   sending out an I_AM_DSBM advertisement and start managing the
   resources for the outgoing traffic over the segment.  If one of the
   two senders does not wish itself to be the DSBM, then the other DSBM
   will not receive any DSBM advertisement from its peer and assume
   itself to be the DSBM for traffic traversing in both directions over
   the managed segment.

Top       Page 48 
Appendix B  Message Encapsulation and Formats

   To minimize changes to the existing RSVP implementations and to
   ensure quick deployment of a SBM in conjunction with RSVP, all
   communication to and from a DSBM will be performed using messages
   constructed using the current rules for RSVP message formats and raw
   IP encapsulation. For more details on the RSVP message formats, refer
   to the RSVP specification (RFC 2205).  No changes to the RSVP message
   formats are proposed, but new message types and new L2-specific
   objects are added to the RSVP message formats to accommodate DSBM-
   related messages. These additions are described below.

B.1 Message Addressing

   For the purpose of DSBM election and detection, AllSBMAddress is used
   as the destination address while sending out both DSBM_WILLING and
   I_AM_DSBM messages. A DSBM client first detects a managed segment by
   listening to I_AM_DSBM advertisements and records the DSBMAddress
   (unicast IP address of the DSBM).

B.2. Message Sizes

   Each message must occupy exactly one IP datagram. If it exceeds the
   MTU, such a datagram will be fragmented by IP and reassembled at the
   recipient node. This has a consequence that a single message may not
   exceed the maximum IP datagram size, approximately 64K bytes.

B.3. RSVP-related Message Formats

   All RSVP messages directed to and from a DSBM may contain various
   RSVP objects defined in the RSVP specification and messages continue
   to follow the formatting rules specified in the RSVP specification.
   In addition, an RSVP implementation must also recognize new object
   classes that are described below.

B.3.1. Object Formats

   All objects are defined using the format specified in the RSVP
   specification. Each object has a 32-bit header that contains length
   (of the object in bytes including the object header), the object
   class number, and a C-Type. All unused fields should be set to zero
   and ignored on receipt.

Top       Page 49 
B.3.2. SBM Specific Objects

   Note that the Class-Num values for the SBM specific objects
   (LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2) are chosen from the
   codespace 10XXXXXX. This coding assures that non-SBM aware RSVP nodes
   will ignore the objects without forwarding them or generating an
   error message.

   Within the SBM specific codespace, note the following interpretation
   of the third most significant bit of the Class-Num:

          a) Objects of the form 100XXXXX are to be silently
             discarded by SBM nodes that do not recognize them.

          b) Objects of the form 101XXXXX are to be silently
             forwarded by SBM nodes that do not recognize them.

B.3.3. IEEE 802 Canonical Address Format

   The 48-bit MAC Addresses used by IEEE 802 were originally defined in
   terms of wire order transmission of bits in the source and
   destination MAC address fields. The same wire order applied to both
   Ethernet and Token Ring. Since the bit transmission order of Ethernet
   and Token Ring data differ - Ethernet octets are transmitted least
   significant bit first, Token Ring most significant first - the
   numeric values naturally associated with the same address on
   different 802 media differ. To facilitate the communication of
   address values in higher layer protocols which might span both token
   ring and Ethernet attached systems connected by bridges, it was
   necessary to define one reference format - the so called canonical
   format for these addresses. Formally the canonical format defines the
   value of the address, separate from the encoding rules used for
   transmission. It comprises a sequence of octets derived from the
   original wire order transmission bit order as follows. The least
   significant bit of the first octet is the first bit transmitted, the
   next least significant bit the second bit, and so on to the most
   significant bit of the first octet being the 8th bit transmitted; the
   least significant bit of the second octet is the 9th bit transmitted,
   and so on to the most significant bit of the sixth octet of the
   canonical format being the last bit of the address transmitted.

   This canonical format corresponds to the natural value of the address
   octets for Ethernet. The actual transmission order or formal encoding
   rules for addresses on media which do not transmit bit serially are
   derived from the canonical format octet values.

Top       Page 50 
   This document requires that all L2 addresses used in conjunction with
   the SBM protocol be encoded in the canonical format as a sequence of
   6 octets. In the following, we define the object formats for objects
   that contain L2 addresses that are based on the canonical
   representation.

B.3.4. RSVP_HOP_L2 object

   RSVP_HOP_L2 object uses object class = 161; it contains the L2
   address of the previous hop L3 device in the IEEE Canonical address
   format discussed above.

   RSVP_HOP_L2 object: class = 161, C-Type represents the addressing
   format used. In our case, C-Type=1 represents the IEEE Canonical
   Address format.

            0              1             2                 3
   +---------------+---------------+---------------+----------------+
   |       Length                  |   161         |C-Type(addrtype)|
   +---------------+---------------+---------------+----------------+
   |                  Variable length Opaque data                   |
   +---------------+---------------+---------------+----------------+

   C-Type = 1 (IEEE Canonical Address format)

   When C-Type=1, the object format is:

           0               1               2               3
   +---------------+---------------+---------------+---------------+
   |              12               |   161         |      1        |
   +---------------+---------------+---------------+---------------+
   |             Octets 0-3 of the MAC address                     |
   +---------------+---------------+---------------+---------------+
   |  Octets 4-5 of the MAC addr.  |   ///         |     ///       |
   +---------------+---------------+---------------+---------------+

   /// -- unused (set to zero)

B.3.5. LAN_NHOP object

   LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address
   object and LAN_NHOP_L2 address object.
        <LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object>

   LAN_NHOP_L2 address object uses object class = 162 and uses the same
   format (but different class number) as the RSVP_HOP_L2 object.  It
   provides the L2 or MAC address of the next hop L3 device.

Top       Page 51 
           0               1               2               3
   +---------------+---------------+---------------+----------------+
   |       Length                  |   162         |C-Type(addrtype)|
   +---------------+---------------+---------------+----------------+
   |                  Variable length Opaque data                   |
   +---------------+---------------+---------------+----------------+

   C-Type = 1 (IEEE 802 Canonical Address Format as defined below) See
   the RSVP_HOP_L2 address object for more details.

   LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP
   address of the next hop L3 device.

   LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6
   address family used.

   IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1
   +---------------+---------------+---------------+---------------+
   |       Length = 8              |   163         |       1       |
   +---------------+---------------+---------------+---------------+
   |               IPv4 NHOP address                               |
   +---------------------------------------------------------------+

   IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2
   +---------------+---------------+---------------+---------------+
   |       Length = 20             |   163         |       2       |
   +---------------+---------------+---------------+---------------+
   |               IPv6 NHOP address (16 bytes)                    |
   +---------------------------------------------------------------+

B.3.6. LAN_LOOPBACK Object

   The LAN_LOOPBACK object gives the IP address of the outgoing
   interface for a PATH message and uses object class=164; both IPv4 and
   IPv6 formats are specified.

   IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1

           0               1               2               3
   +---------------+---------------+---------------+---------------+
   |       Length                  |   164         |       1       |
   +---------------+---------------+---------------+---------------+
   |                  IPV4 address of an interface                 |
   +---------------+---------------+---------------+---------------+

Top       Page 52 
   IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2

   +---------------+---------------+---------------+---------------+
   |       Length                  |   164         |       2       |
   +---------------+---------------+---------------+---------------+
   |                                                               |
   +                                                               +
   |                                                               |
   +                  IPV6 address of an interface                 +
   |                                                               |
   +                                                               +
   |                                                               |
   +---------------+---------------+---------------+---------------+

B.3.7. TCLASS Object

   TCLASS object (traffic class based on IEEE 802.1p) uses  object
   class = 165.

            0              1               2               3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Length                |   165         |       1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ///        |    ///        |  ///          | ///     | PV  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Only  3 bits in data contain the user_priority value (PV).

B.4. RSVP PATH and PATH_TEAR Message Formats

   As specified in the RSVP specification, a PATH and PATH_TEAR messages
   contain the RSVP Common Header and the relevant RSVP objects.

   For the RSVP Common Header, refer to the RSVP specification (RFC
   2205). Enhancements to an RSVP_PATH message include additional
   objects as specified below.

   <PATH Message> ::= <RSVP Common Header> [<INTEGRITY>]
                   <RSVP_HOP_L2> <LAN_NHOP>
                   <LAN_LOOPBACK> [<TCLASS>]  <SESSION><RSVP_HOP>
                   <TIME_VALUES> [<POLICY DATA>] <sender descriptor>

   <PATH_TEAR Message> ::= <RSVP Common Header> [<INTEGRITY>]
                   <LAN_LOOPBACK> <LAN_NHOP> <SESSION> <RSVP_HOP>
                   [<sender descriptor>]

Top       Page 53 
   If the INTEGRITY object is present, it must immediately follow the
   RSVP common header. L2-specific objects must always precede the
   SESSION object.

B.5. RSVP RESV Message Format

   As specified in the RSVP specification, an RSVP_RESV message contains
   the RSVP Common Header and relevant RSVP objects. In addition, it may
   contain an optional TCLASS object as described earlier.

B.6. Additional RSVP message types to handle SBM interactions

   New RSVP message types are introduced to allow interactions between a
   DSBM and an RSVP node (host/router) for the purpose of discovering
   and binding to a DSBM. New RSVP message types needed are as follows:

   RSVP Msg Type (8 bits)      Value
   DSBM_WILLING                66
   I_AM_DSBM                   67

   All SBM-specific messages are formatted as RSVP messages with an RSVP
   common header followed by SBM-specific objects.

   <SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects>

   where <SBMP common header> ::= <RSVP common Header> [<INTEGRITY>]

   For each SBM message type, there is a set of rules for the
   permissible choice of object types. These rules are specified using

   Backus-Naur Form (BNF) augmented with square brackets surrounding
   optional sub-sequences. The BNF implies an order for the objects in a
   message. However, in many (but not all) cases, object order makes no
   logical difference. An implementation should create messages with the
   objects in the order shown here, but accept the objects in any
   permissible order. Any exceptions to this rule will be pointed out in
   the specific message formats.

   DSBM_WILLING Message

   <DSBM_WILLING message> ::= <SBM Common Header> <DSBM IP ADDRESS>
                              <DSBM L2 address> <SBM PRIORITY>

   I_AM_DSBM Message

   <I_AM_DSBM> ::= <SBM Common Header> <DSBM IP ADDRESS> <DSBM L2 address>
                              <SBM PRIORITY> <DSBM Timer Intervals>
                              [<NON_RESV_SEND_LIMIT>]

Top       Page 54 
   For compatibility reasons, receivers of the I_AM_DSBM message must be
   prepared to receive additional objects of the Unknown Class type
   [RFC-2205].

   All I_AM_DSBM messages are multicast to the well known AllSBMAddress.
   The default priority of a SBM is 1 and higher priority values
   represent higher precedence. The priority value zero indicates that
   the SBM is not eligible to be the DSBM.

   Relevant Objects

   DSBM IP ADDRESS objects use object class = 42; IPv4 DSBM IP ADDRESS
   object uses <Class=42, C-Type=1> and IPv6 DSBM IP ADDRESS object uses
   <Class=42, C-Type=2>.

   IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1
           0               1               2               3
   +---------------+---------------+---------------+---------------+
   |                       IPv4 DSBM IP Address                    |
   +---------------+---------------+---------------+---------------+

   IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 2

   +---------------+---------------+---------------+---------------+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       IPv6 DSBM IP Address                    +
   |                                                               |
   +                                                               +
   |                                                               |
   +---------------+---------------+---------------+---------------+

   <DSBM L2 address> Object is the same as <RSVP_HOP_L2> object with C-
   Type = 1 for IEEE Canonical Address format.

   <DSBM L2 address> ::= <RSVP_HOP_L2>

   A SBM  may omit this object by including a NULL L2 address object.
   For C-Type=1 (IEEE Canonical address format), such a version of the
   L2 address object contains value zero in the six octets corresponding
   to the MAC address (see section B.3.4 for the exact format).

Top       Page 55 
   SBM_PRIORITY Object: class = 43, C-Type =1

           0               1               2               3
   +---------------+---------------+---------------+---------------+
   |   ///         |   ///         | ///           | SBM priority  |
   +---------------+---------------+---------------+---------------+

   TIMER INTERVAL VALUES.

   The two timer intervals, namely, DSBM Dead Interval and DSBM Refresh
   Interval, are specified as integer values each in the range of 0..255
   seconds. Both values are included in a single "DSBM Timer Intervals"
   object described below.

   DSBM Timer Intervals Object: class = 44, C-Type =1

   +---------------+---------------+---------------+----------------+
   |   ///        |   ///          | DeadInterval  | RefreshInterval|
   +---------------+---------------+---------------+----------------+

   NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 1

       0       1       2       3
   +---------------+---------------+---------------+----------------+
   | NonResvSendLimit(limit on traffic allowed to send without RESV)|
   |                                                                |
   +---------------+---------------+---------------+----------------+

   <NonResvSendLimit> ::= <Intserv Sender_TSPEC object>
   (class=12, C-Type =2)

   The NON_RESV_SEND_LIMIT object specifies a per-flow limit on the
   profile of traffic which a sending host is allowed to send onto a
   managed segment without a valid RSVP reservation (see Appendix C for
   further details on the usage of this object). The object contains the
   NonResvSendLimit parameter.  This parameter is equivalent to the
   Intserv SENDER_TSPEC (see RFC 2210 for contents and encoding rules).
   The SENDER_TSPEC includes five parameters which describe a traffic
   profile (r, b, p, m and M). Sending hosts compare the SENDER_TSPEC
   describing a sender traffic flow to the SENDER_TSPEC advertised by
   the DSBM. If the SENDER_TSPEC of the traffic flow in question is less
   than or equal to the SENDER_TSPEC advertised by the DSBM, it is
   allowable to send traffic on the corresponding flow without a valid
   RSVP reservation in place. Otherwise it is not.

   The network administrator may configure the DSBM to disallow any sent
   traffic in the absence of an RSVP reservation by configuring a
   NonResvSendLimit in which r = 0, b = 0, p = 0, m = infinity and M =

Top       Page 56 
   0. Similarly the network administrator may allow any traffic to be
   sent in the absence of an RSVP reservation by configuring a
   NonResvSendLimit in which r = infinity, b = infinity, p = infinity, m
   = 0 and M = infinity. Of course, any of these parameters may be set
   to values between zero and infinity to advertise finite per-flow
   limits.

   The NON_RESV_SEND_LIMIT object is optional. Senders on a managed
   segment should interpret the absence of the NON_RESV_SEND_LIMIT
   object as equivalent to an infinitely large SENDER_TSPEC (it is
   permissible to send any traffic profile in the absence of an RSVP
   reservation).

Top       Page 57 
Appendix C The DSBM as a Source of Centralized Configuration Information

   There are certain configuration parameters which it may be useful to
   distribute to layer-3 senders on a managed segment. The DSBM may
   serve as a centralized management point from which such parameters
   can easily be distributed. In particular,  it is possible for the
   network administrator configuring a DSBM to cause certain
   configuration parameters to be distributed as objects appended to the
   I_AM_DSBM messages. The following configuration object is defined at
   this time. Others may be defined in the future. See Appendix B for
   further details regarding the NON_RESV_SEND_LIMIT object.

C.1. NON_RESV_SEND_LIMIT

   As we QoS enable layer 2 segments, we expect an evolution from
   subnets comprised of traditional shared segments (with no means of
   traffic separation and no DSBM), to subnets comprised of dedicated
   segments switched by sophisticated switches (with both DSBM and
   802.1p traffic separation capability).

   A set of intermediate configurations consists of a group of QoS
   enabled hosts sending onto a traditional shared segment. A layer-3
   device (or a layer-2 device) acts as a DSBM for the shared segment,
   but cannot enforce traffic separation. In such a configuration, the
   DSBM can be configured to limit the number of reservations approved
   for senders on the segment, but cannot prevent them from sending.  As
   a result, senders may congest the segment even though a network
   administrator has configured an appropriate limit for admission
   control in the DSBM.

   One solution to this problem which would give the network
   administrator control over the segment, is to require applications
   (or operating systems on behalf of applications) not to send until
   they have obtained a reservation. This is problematic as most
   applications are used to sending as soon as they wish to and expect
   to get whatever service quality the network is able to grant at that
   time.  Furthermore, it may often be acceptable to allow certain
   applications to send before a reservation is received. For example,
   on a segment comprised of a single 10 Mbps ethernet and 10 hosts, it
   may be acceptable to allow a 16 Kbps telephony stream to be
   transmitted but not a 3 Mbps video stream.

   A more pragmatic solution then, is to allow the network administrator
   to set a per-flow limit on the amount of non-adaptive traffic which a
   sender is allowed to generate on a managed segment in the absence of
   a valid reservation. This limit is advertised by the DSBM and
   received by sending hosts. An API on the sending host can then
   approve or deny an application's QoS request based on the resources

Top       Page 58 
   requested.

   The NON_RESV_SEND_LIMIT object can be used to advertise a Flowspec
   which describes the shape of traffic that a sender is allowed to
   generate on a managed segment when its RSVP reservation requests have
   either not yet completed or have been rejected.

ACKNOWLEDGEMENTS

   Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel),
   David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman
   (3COM), Andrew Smith (Extreme Networks) for their constructive
   comments on the SBM design and the earlier versions of this document.

6. Authors' Addresses

   Raj Yavatkar
   Intel Corporation
   2111 N.E. 25th Avenue,
   Hillsboro, OR 97124
   USA

   Phone: +1 503-264-9077
   EMail: yavatkar@ibeam.intel.com


   Don Hoffman
   Teledesic Corporation
   2300 Carillon Point
   Kirkland, WA 98033
   USA

   Phone: +1 425-602-0000


   Yoram Bernet
   Microsoft
   1 Microsoft Way
   Redmond, WA 98052
   USA

   Phone: +1 206 936 9568
   EMail: yoramb@microsoft.com

Top       Page 59 
   Fred Baker
   Cisco Systems
   519 Lado Drive
   Santa Barbara, California 93111
   USA

   Phone: +1 408 526 4257
   EMail: fred@cisco.com


   Michael Speer
   Sun Microsystems, Inc
   901 San Antonio Road UMPK15-215
   Palo Alto, CA 94303

   Phone: +1 650-786-6368
   EMail: speer@Eng.Sun.COM

Top       Page 60 
Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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 RFC Editor function is currently provided by the
   Internet Society.