Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2814

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

Pages: 60
Proposed Standard
Part 2 of 3 – Pages 16 to 35
First   Prev   Next

ToP   noToC   RFC2814 - Page 16   prevText

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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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   noToC   RFC2814 - 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 page on part 3)

Next Section