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

gt;] <sender descriptor>

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

Yavatkar, et al.            Standards Track                    [Page 52]
RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000

   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>]

Yavatkar, et al.            Standards Track                    [Page 53]
RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000

   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).

Yavatkar, et al.            Standards Track                    [Page 54]
RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000

   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 =

Yavatkar, et al.            Standards Track                    [Page 55]
RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000

   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).

Yavatkar, et al.            Standards Track                    [Page 56]
RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000

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

Yavatkar, et al.            Standards Track                    [Page 57]
RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000

   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

Yavatkar, et al.            Standards Track                    [Page 58]
RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000

   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

Yavatkar, et al.            Standards Track                    [Page 59]
RFC 2814             SBM (Subnet Bandwidth Manager)             May 2000

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.

Yavatkar, et al.            Standards Track                    [Page 60]