tech-invite   World Map     

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

RFC 2814

 
 
 

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

Part 2 of 3, p. 16 to 35
Prev RFC Part       Next RFC Part

 


prevText      Top       Page 16 
5. Detailed Message Processing Rules

5.1. Additional Notes on Terminology

   *  An L2 device may have several interfaces with attached segments
      that are part of the same L2 domain. A switch in a L2 domain is an
      example of such a device. A device which has several interfaces
      may contain a SBM protocol entity that acts in different
      capacities on each interface. For example, a SBM protocol entity
      could act as a SBM on interface A, and act as a DSBM on interface
      B.

   *  A SBM protocol entity on a layer 3 device can be a DSBM client,
      and SBM, a DSBM, or none of the above (SBM transparent).  Non-
      transparent L3 devices can implement any combination of these
      roles simultaneously. DSBM clients always reside at L3 devices.

   *  A SBM protocol entity residing at a layer 2 device can be a SBM, a
      DSBM or none of the above (SBM transparent). A layer 2 device will
      never host a DSBM client.

5.2. Use Of Reserved IP Multicast Addresses

   As stated earlier, we require that the DSBM clients forward the RSVP
   PATH messages to their DSBMs in a L2 domain before they reach the
   next L3 hop in the path. RSVP PATH messages are addressed, according
   to RFC-2205, to their destination address (which can be either an IP
   unicast or multicast address).  When a L2 device hosts a DSBM, a
   simple-to-implement mechanism must be provided for the device to
   capture an incoming PATH message and hand it over to the local DSBM
   agent without requiring the L2 device to snoop for L3 RSVP messages.

   In addition, DSBM clients need to know how to address SBM messages to
   the DSBM. For the ease of operation and to allow dynamic DSBM-client
   binding, it should be possible to easily detect and address the
   existing DSBM on a managed segment.

Top       Page 17 
   To facilitate dynamic DSBM-client binding as well as to enable easy
   detection and capture of PATH messages at L2 devices, we require that
   a DSBM be addressed using a logical address rather than a physical
   address. We make use of reserved IP multicast address(es) for the
   purpose of communication with a DSBM.  In particular, we require that
   when a DSBM client or a SBM forwards a PATH message over a managed
   segment, it is addressed to a reserved IP multicast address. Thus, a
   DSBM on a L2 device needs to be configured in a way to make it easy
   to intercept the PATH message and forward it to the local SBM
   protocol entity. For example, this may involve simply adding a static
   entry in the device's filtering database (FDB) for the corresponding
   MAC multicast address to ensure the PATH messages get intercepted and
   are not forwarded further without the DSBM intervention.

   Similarly, a DSBM always sends the PATH messages over a managed
   segment using a reserved IP multicast address and, thus, the SBMs or
   DSBM clients on the managed segments must simply be configured to
   intercept messages addressed to the reserved multicast address on the
   appropriate interfaces to easily receive PATH messages.

   RSVP RESV messages continue to be unicast to the previous hop address
   stored as part of the PATH state at each intermediate hop.

   We define use of two reserved IP multicast addresses. We call these
   the "AllSBM Address" and the "DSBMLogicalAddress". These are chosen
   from the range of local multicast addresses, such that:

   *  They are not passed through layer 3 devices.

   *  They are passed transparently through layer 2 devices which are
      SBM transparent.

   *  They are configured in the permanent database of layer 2 devices
      which host SBMs or DSBMs, such that they are directed to the SBM
      management entity in these devices. This obviates the need for
      these devices to explicitly snoop for SBM related control packets.

   *  The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress) and
      224.0.0.17 (AllSBMAddress).

   These addresses are used as described in the following table:

   Type     DSBMLogicaladdress         AllSBMAddress

   DSBM     * Sends PATH messages      * Monitors this address to detect
   Client     to this address            the presence of a DSBM

Top       Page 18 
                                       * Monitors this address to
                                         receive PATH messages
                                         forwarded by the DSBM

   SBM      * Sends PATH messages      * Monitors and sends on this
              to this address            address to participate in
                                         election of the DSBM
                                       * Monitors this address to
                                         receive PATH messages
                                         forwarded by the DSBM

   DSBM     * Monitors this address    * Monitors and sends on this
              for PATH messages          to participate in election
              directed to it             of the DSBM
                                       * Sends PATH messages to this
                                         address

   The L2 or MAC addresses corresponding to IP multicast addresses are
   computed algorithmically using a reserved L2 address block (the high
   order 24-bits are 00:00:5e). The Assigned Numbers RFC [RFC-1700]
   gives additional details.

5.3. Layer 3 to Layer 2 Address Mapping

   As stated earlier, DSBMs or DSBM clients residing at a L3 device must
   include a LAN_NHOP_L2 address in the LAN_NHOP information so that L2
   devices along the path of a PATH message do not need to separately
   determine the mapping between the LAN_NHOP_L3 address in the LAN_NHOP
   object and its corresponding L2 address (for example, using ARP).

   For the purpose of such mapping at L3 devices, we assume a mapping
   function called "map_address" that performs the necessary mapping:

                 L2ADDR object = map_addr(L3Addr)

   We do not specify how the function is implemented; the implementation
   may simply involve access to the local ARP cache entry or may require
   performing an ARP function.  The function returns a L2ADDR object
   that need not be interpreted by an L3 device and can be treated as an
   opaque object.  The format of the L2ADDR object is specified in
   Appendix B.

5.4. Raw vs. UDP Encapsulation

   We assume that the DSBMs, DSBM clients, and SBMs use only raw IP for
   encapsulating RSVP messages that are forwarded onto a L2 domain.
   Thus, when a SBM protocol entity on a L3 device forwards a RSVP
   message onto a L2 segment, it will only use RAW IP encapsulation.

Top       Page 19 
5.5. The Forwarding Rules

   The message processing and forwarding rules will be described in the
   context of the sample network illustrated in Figure 2.

   Figure 2 - A sample network or L2 domain consisting of switched and
   shared L2 segments

 ..........
          .
+------+  .    +------+  seg A  +------+  seg C  +------+ seg D +------+
|  H1  |_______|  R1  |_________|  S1  |_________|  S2  |_______|  H2  |
|      |  .    |      |         |      |         |      |       |      |
+------+  .    +------+         +------+         +------+       +------+
          .                        |                /
1.0.0.0   .                        |               /
          .                        |___           /
          .                    seg B  |          / seg E
 ..........                           |         /
                     2.0.0.0          |        /
                                     +-----------+
                                     |    S3     |
                                     |           |
                                     +-----------+
                                          |
                                          |
                                          |
                                          |
                         seg F            |            .................
                 ------------------------------        .
                   |         |             |           .
                +------+  +------+        +------+     .      +------+
                |  H3  |  |  H4  |        |  R2  |____________|  H5  |
                |      |  |      |        |      |     .      |      |
                +------+  +------+        +------+     .      +------+
                                                       .
                                                       .     3.0.0.0
                                                       .................

   Figure 2 illustrates a sample network topology consisting of three IP
   subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) interconnected using two
   routers. The subnet 2.0.0.0 is an example of a L2 domain consisting
   of switches, hosts, and routers interconnected using switched
   segments and a shared L2 segment. The sample network contains the
   following devices:

Top       Page 20 
   Device          Type                    SBM Type

   H1, H5      Host (layer 3)          SBM Transparent
   H2-H4       Host (layer 3)          DSBM Client
   R1          Router (layer 3)        SBM
   R2          Router (layer 3)        DSBM for segment F
   S1          Switch (layer 2)        DSBM for segments A, B
   S2          Switch (layer 2)        DSBM for segments C, D, E
   S3          Switch (layer 2)        SBM

   The following paragraphs describe the rules, which each of these
   devices should use to forward PATH messages (rules apply to PATH_TEAR
   messages as well). They are described in the context of the general
   network illustrated above. While the examples do not address every
   scenario, they do address most of the interesting scenarios.
   Exceptions can be discussed separately.

   The forwarding rules are applied to received PATH messages (routers
   and switches) or originating PATH messages (hosts), as follows:

   1. Determine the interface(s) on which to forward the PATH message
      using standard forwarding rules:

      *  If there is a LAN_LOOPBACK object in the PATH message, and it
         carries the address of this device, silently discard the
         message.  (See the section below on "Additional notes on
         forwarding the PATH message onto a managed segment).

      *  Layer 3 devices use the RSVP session address and perform a
         routing lookup to determine the forwarding interface(s).

      *  Layer 2 devices use the LAN_NHOP_L2 address in the LAN_NHOP
         information and MAC forwarding tables to determine the
         forwarding interface(s). (See the section below on "Additional
         notes on forwarding the PATH message onto a managed segment")

   2. For each forwarding interface:

      *  If the device is a layer 3 device, determine whether the
         interface is on a managed segment managed by a DSBM, based on
         the presence or absence of I_AM_DSBM messages. If the interface
         is not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP,
         LAN_LOOPBACK, and TCLASS objects (if present), and forward to
         the unicast or multicast destination.

Top       Page 21 
         (Note that the RSVP Class Numbers for these new objects are
         chosen so that if an RSVP message includes these objects, the
         nodes that are RSVP-aware, but do not participate in the SBM
         protocol, will ignore and silently discard such objects.)

      *  If the device is a layer 2 device or it is a layer 3 device
         *and* the interface is on a managed segment, proceed to rule
         #3.

   3. Forward the PATH message onto the managed segment:

      *  If the device is a layer 3 device, insert LAN_NHOP address
         objects, a LAN_LOOPBACK, and a RSVP_HOP_L2 object into the PATH
         message. The LAN_NHOP objects carry the LAN_NHOP_L3 and
         LAN_NHOP_L2 addresses of the next layer 3 hop. The RSVP_HOP_L2
         object carries the device's own L2 address, and the
         LAN_LOOPBACK object contains the IP address of the outgoing
         interface.

         An L3 device should use the map_addr() function described
         earlier to obtain an L2 address corresponding to an IP address.

      * If the device hosts the DSBM for the segment to which the
         forwarding interface is attached, do the following:

         - Retrieve the PHOP information from the standard RSVP HOP
           object in the PATH message, and store it. This will be used
           to route RESV messages back through the L2 network. If the
           PATH message arrived over a managed segment, it will also
           contain the RSVP_HOP_L2 object; then retrieve and store also
           the previous hop's L2 address in the PATH state.

         - Copy the IP address of the forwarding interface (layer 2
           devices must also have IP addresses) into the standard RSVP
           HOP object and the L2 address of the forwarding interface
           into the RSVP_HOP_L2 object.

         - If the PATH message received does not contain the TCLASS
           object, insert a TCLASS object. The user_priority value
           inserted in the TCLASS object is based on service mappings
           internal to the device that are configured according to the
           guidelines listed in [RFC-MAP]. If the message already
           contains the TCLASS object, the user_priority value may be
           changed based again on the service mappings internal to the
           device.

Top       Page 22 
      *  If the device is a layer 3 device and hosts a SBM for the
         segment to which the forwarding interface is attached, it *is
         required* to retrieve and store the PHOP info.

         If the device is a layer 2 device and hosts a SBM for the
         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:

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

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

Top       Page 25 
      ("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:

Top       Page 26 
                            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)

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

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

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

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

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

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

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

Top       Page 34 
   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 RFC and
   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

   [RFC 2205]    Braden, R., Zhang, L., Berson,  S., Herzog, S. and S.
                 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
                 1 Functional Specification", RFC 2205, September 1997.

   [RFC-RSVPMD5] Baker, F., Lindell, B. and M. Talwar, "RSVP
                 Cryptographic Authentication", RFC 2747, January 2000.

   [RFC 2206]    Baker, F. and J. Krawczyk, "RSVP Management Information
                 Base", RFC 2206, September 1997.

   [RFC 2211]    Wroclawski, J., "Specification of the Controlled-Load
                 Network Element Service", RFC 2211, September 1997.

   [RFC 2212]    Shenker, S., Partridge, C. and  R. Guerin,
                 "Specification of Guaranteed Quality of Service", RFC
                 2212, September 1997.

   [RFC 2215]    Shenker, S. and J. Wroclawski, "General
                 Characterization Parameters for Integrated Service
                 Network Elements", RFC 2215, September 1997.

   [RFC 2210]    Wroclawski, J., "The Use of RSVP with IETF Integrated
                 Services", RFC 2210, September 1997.

   [RFC 2213]    Baker, F. and  J. Krawczyk, "Integrated Services
                 Management Information Base", RFC 2213, September 1997.

Top       Page 35 
   [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",
                 RFC 2816, May 2000.

   [RFC-MAP]     Seaman, M., Smith, A. and E. Crawley, "Integrated
                 Service Mappings on IEEE 802 Networks", RFC 2815, 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.


Next RFC Part