summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2814.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2814.txt')
-rw-r--r--doc/rfc/rfc2814.txt3363
1 files changed, 3363 insertions, 0 deletions
diff --git a/doc/rfc/rfc2814.txt b/doc/rfc/rfc2814.txt
new file mode 100644
index 0000000..2547968
--- /dev/null
+++ b/doc/rfc/rfc2814.txt
@@ -0,0 +1,3363 @@
+
+
+
+
+
+
+Network Working Group R. Yavatkar
+Request for Comments: 2814 Intel
+Category: Standards Track D. Hoffman
+ Teledesic
+ Y. Bernet
+ Microsoft
+ F. Baker
+ Cisco
+ M. Speer
+ Sun Microsystems
+ May 2000
+
+
+ SBM (Subnet Bandwidth Manager):
+A Protocol for RSVP-based Admission Control over IEEE 802-style networks
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document describes a signaling method and protocol for RSVP-
+ based admission control over IEEE 802-style LANs. The protocol is
+ designed to work both with the current generation of IEEE 802 LANs as
+ well as with the recent work completed by the IEEE 802.1 committee.
+
+1. Introduction
+
+ New extensions to the Internet architecture and service models have
+ been defined for an integrated services Internet [RFC-1633, RFC-2205,
+ RFC-2210] so that applications can request specific qualities or
+ levels of service from an internetwork in addition to the current IP
+ best-effort service. These extensions include RSVP, a resource
+ reservation setup protocol, and definition of new service classes to
+ be supported by Integrated Services routers. RSVP and service class
+ definitions are largely independent of the underlying networking
+ technologies and it is necessary to define the mapping of RSVP and
+ Integrated Services specifications onto specific subnetwork
+ technologies. For example, a definition of service mappings and
+
+
+
+Yavatkar, et al. Standards Track [Page 1]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ reservation setup protocols is needed for specific link-layer
+ technologies such as shared and switched IEEE-802-style LAN
+ technologies.
+
+ This document defines SBM, a signaling protocol for RSVP-based
+ admission control over IEEE 802-style networks. SBM provides a
+ method for mapping an internet-level setup protocol such as RSVP onto
+ IEEE 802 style networks. In particular, it describes the operation
+ of RSVP-enabled hosts/routers and link layer devices (switches,
+ bridges) to support reservation of LAN resources for RSVP-enabled
+ data flows. A framework for providing Integrated Services over
+ shared and switched IEEE-802-style LAN technologies and a definition
+ of service mappings have been described in separate documents [RFC-
+ FRAME, RFC-MAP].
+
+2. Goals and Assumptions
+
+ The SBM (Subnet Bandwidth Manager) protocol and its use for admission
+ control and bandwidth management in IEEE 802 level-2 networks is
+ based on the following architectural goals and assumptions:
+
+ I. Even though the current trend is towards increased use of
+ switched LAN topologies consisting of newer switches that support
+ the priority queuing mechanisms specified by IEEE 802.1p, we
+ assume that the LAN technologies will continue to be a mix of
+ legacy shared/ switched LAN segments and newer switched segments
+ based on IEEE 802.1p specification. Therefore, we specify a
+ signaling protocol for managing bandwidth over both legacy and
+ newer LAN topologies and that takes advantage of the additional
+ functionality (such as an explicit support for different traffic
+ classes or integrated service classes) as it becomes available in
+ the new generation of switches, hubs, or bridges. As a result,
+ the SBM protocol would allow for a range of LAN bandwidth
+ management solutions that vary from one that exercises purely
+ administrative control (over the amount of bandwidth consumed by
+ RSVP-enabled traffic flows) to one that requires cooperation (and
+ enforcement) from all the end-systems or switches in a IEEE 802
+ LAN.
+
+ II. This document specifies only a signaling method and protocol
+ for LAN-based admission control over RSVP flows. We do not define
+ here any traffic control mechanisms for the link layer; the
+ protocol is designed to use any such mechanisms defined by IEEE
+ 802. In addition, we assume that the Layer 3 end-systems (e.g., a
+ host or a router) will exercise traffic control by policing
+ Integrated Services traffic flows to ensure that each flow stays
+ within its traffic specifications stipulated in an earlier
+ reservation request submitted for admission control. This then
+
+
+
+Yavatkar, et al. Standards Track [Page 2]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ allows a system using SBM admission control combined with per flow
+ shaping at end systems and IEEE-defined traffic control at link
+ layer to realize some approximation of Controlled Load (and even
+ Guaranteed) services over IEEE 802-style LANs.
+
+ III. In the absence of any link-layer traffic control or priority
+ queuing mechanisms in the underlying LAN (such as a shared LAN
+ segment), the SBM-based admission control mechanism only limits
+ the total amount of traffic load imposed by RSVP-enabled flows on
+ a shared LAN. In such an environment, no traffic flow separation
+ mechanism exists to protect the RSVP-enabled flows from the best-
+ effort traffic on the same shared media and that raises the
+ question of the utility of such a mechanism outside a topology
+ consisting only of 802.1p-compliant switches. However, we assume
+ that the SBM-based admission control mechanism will still serve a
+ useful purpose in a legacy, shared LAN topology for two reasons.
+ First, assuming that all the nodes that generate Integrated
+ Services traffic flows utilize the SBM-based admission control
+ procedure to request reservation of resources before sending any
+ traffic, the mechanism will restrict the total amount of traffic
+ generated by Integrated Services flows within the bounds desired
+ by a LAN administrator (see discussion of the NonResvSendLimit
+ parameter in Appendix C). Second, the best-effort traffic
+ generated by the TCP/IP-based traffic sources is generally rate
+ adaptive (using a TCP-style "slow start" congestion avoidance
+ mechanism or a feedback-based rate adaptation mechanism used by
+ audio/video streams based on RTP/RTCP protocols) and adapts to
+ stay within the available network bandwidth. Thus, the
+ combination of admission control and rate adaptation should avoid
+ persistent traffic congestion. This does not, however, guarantee
+ that non-Integrated-Services traffic will not interfere with the
+ Integrated Services traffic in the absence of traffic control
+ support in the underlying LAN infrastructure.
+
+3. Organization of the rest of this document
+
+ The rest of this document provides a detailed description of the
+ SBM-based admission control procedure(s) for IEEE 802 LAN
+ technologies. The document is organized as follows:
+
+ * Section 4 first defines the various terms used in the document and
+ then provides an overview of the admission control procedure with
+ an example of its application to a sample network.
+
+ * Section 5 describes the rules for processing and forwarding PATH
+ (and PATH_TEAR) messages at DSBMs (Designated Subnet Bandwidth
+ Managers), SBMs, and DSBM clients.
+
+
+
+
+Yavatkar, et al. Standards Track [Page 3]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ * Section 6 addresses the inter-operability issues when a DSBM may
+ operate in the absence of RSVP signaling at Layer 3 or when
+ another signaling protocol (such as SNMP) is used to reserve
+ resources on a LAN segment.
+
+ * Appendix A describes the details of the DSBM election algorithm
+ used for electing a designated SBM on a LAN segment when more than
+ one SBM is present. It also describes how DSBM clients discover
+ the presence of a DSBM on a managed segment.
+
+ * Appendix B specifies the formats of SBM-specific messages used and
+ the formats of new RSVP objects needed for the SBM operation.
+
+ * Appendix C describes usage of the DSBM to distribute configuration
+ information to senders on a managed segment.
+
+4. Overview
+
+4.1. Definitions
+
+ - Link Layer or Layer 2 or L2: We refer to data-link layer
+ technologies such as IEEE 802.3/Ethernet as L2 or layer 2.
+
+ - Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes
+ and links interconnected without passing through a L3 forwarding
+ function. One or more IP subnets can be overlaid on a L2 domain.
+
+ - Layer 2 or L2 devices: We refer to devices that only implement
+ Layer 2 functionality as Layer 2 or L2 devices. These include
+ 802.1D bridges or switches.
+
+ - Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO 7 layer
+ model. This document is primarily concerned with networks that use
+ the Internet Protocol (IP) at this layer.
+
+ - Layer 3 Device or L3 Device or End-Station: these include hosts
+ and routers that use L3 and higher layer protocols or application
+ programs that need to make resource reservations.
+
+ - Segment: A L2 physical segment that is shared by one or more
+ senders. Examples of segments include (a) a shared Ethernet or
+ Token-Ring wire resolving contention for media access using CSMA
+ or token passing ("shared L2 segment"), (b) a half duplex link
+ between two stations or switches, (c) one direction of a switched
+ full-duplex link.
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 4]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ - Managed segment: A managed segment is a segment with a DSBM
+ present and responsible for exercising admission control over
+ requests for resource reservation. A managed segment includes
+ those interconnected parts of a shared LAN that are not separated
+ by DSBMs.
+
+ - Traffic Class: An aggregation of data flows which are given
+ similar service within a switched network.
+
+ - User_priority: User_priority is a value associated with the
+ transmission and reception of all frames in the IEEE 802 service
+ model: it is supplied by the sender that is using the MAC service.
+ It is provided along with the data to a receiver using the MAC
+ service. It may or may not be actually carried over the network:
+ Token-Ring/802.5 carries this value (encoded in its FC octet),
+ basic Ethernet/802.3 does not, 802.12 may or may not depending on
+ the frame format in use. 802.1p defines a consistent way to carry
+ this value over the bridged network on Ethernet, Token Ring,
+ Demand-Priority, FDDI or other MAC-layer media using an extended
+ frame format. The usage of user_priority is fully described in
+ section 2.5 of 802.1D [IEEE8021D] and 802.1p [IEEE8021P] "Support
+ of the Internal Layer Service by Specific MAC Procedures".
+
+ - Subnet: used in this memo to indicate a group of L3 devices
+ sharing a common L3 network address prefix along with the set of
+ segments making up the L2 domain in which they are located.
+
+ - Bridge/Switch: a layer 2 forwarding device as defined by IEEE
+ 802.1D. The terms bridge and switch are used synonymously in this
+ document.
+
+ - DSBM: Designated SBM (DSBM) is a protocol entity that resides in a
+ L2 or L3 device and manages resources on a L2 segment. At most one
+ DSBM exists for each L2 segment.
+
+ - SBM: the SBM is a protocol entity that resides in a L2 or L3
+ device and is capable of managing resources on a segment. However,
+ only a DSBM manages the resources for a managed segment. When more
+ than one SBM exists on a segment, one of the SBMs is elected to be
+ the DSBM.
+
+ - Extended segment: An extended segment includes those parts of a
+ network which are members of the same IP subnet and therefore are
+ not separated by any layer 3 devices. Several managed segments,
+ interconnected by layer 2 devices, constitute an extended segment.
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 5]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ - Managed L2 domain: An L2 domain consisting of managed segments is
+ referred to as a managed L2 domain to distinguish it from a L2
+ domain with no DSBMs present for exercising admission control over
+ resources at segments in the L2 domain.
+
+ - DSBM clients: These are entities that transmit traffic onto a
+ managed segment and use the services of a DSBM for the managed
+ segment for admission control over a LAN segment. Only the layer 3
+ or higher layer entities on L3 devices such as hosts and routers
+ are expected to send traffic that requires resource reservations,
+ and, therefore, DSBM clients are L3 entities.
+
+ - SBM transparent devices: A "SBM transparent" device is unaware of
+ SBMs or DSBMs (though it may or may not be RSVP aware) and,
+ therefore, does not participate in the SBM-based admission control
+ procedure over a managed segment. Such a device uses standard
+ forwarding rules appropriate for the device and is transparent
+ with respect to SBM. An example of such a L2 device is a legacy
+ switch that does not participate in resource reservation.
+
+ - Layer 3 and layer 2 addresses: We refer to layer 3 addresses of
+ L3/L2 devices as "L3 addresses" and layer 2 addresses as "L2
+ addresses". This convention will be used in the rest of the
+ document to distinguish between Layer 3 and layer 2 addresses used
+ to refer to RSVP next hop (NHOP) and previous hop (PHOP) devices.
+ For example, in conventional RSVP message processing, RSVP_HOP
+ object in a PATH message carries the L3 address of the previous
+ hop device. We will refer to the address contained in the RSVP_HOP
+ object as the RSVP_HOP_L3 address and the corresponding MAC
+ address of the previous hop device will be referred to as the
+ RSVP_HOP_L2 address.
+
+4.2. Overview of the SBM-based Admission Control Procedure
+
+ A protocol entity called "Designated SBM" (DSBM) exists for each
+ managed segment and is responsible for admission control over the
+ resource reservation requests originating from the DSBM clients in
+ that segment. Given a segment, one or more SBMs may exist on the
+ segment. For example, many SBM-capable devices may be attached to a
+ shared L2 segment whereas two SBM-capable switches may share a half-
+ duplex switched segment. In that case, a single DSBM is elected for
+ the segment. The procedure for dynamically electing the DSBM is
+ described in Appendix A. The only other approved method for
+ specifying a DSBM for a managed segment is static configuration at
+ SBM-capable devices.
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 6]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ The presence of a DSBM makes the segment a "managed segment".
+ Sometimes, two or more L2 segments may be interconnected by SBM
+ transparent devices. In that case, a single DSBM will manage the
+ resources for those segments treating the collection of such segments
+ as a single managed segment for the purpose of admission control.
+
+4.2.1. Basic Algorithm
+
+ Figure 1 - An Example of a Managed Segment.
+
+ +-------+ +-----+ +------+ +-----+ +--------+
+ |Router | | Host| | DSBM | | Host| | Router |
+ | R2 | | C | +------+ | B | | R3 |
+ +-------+ +-----+ / +-----+ +--------+
+ | | / | |
+ | | / | |
+ ==============================================================LAN
+ | |
+ | |
+ +------+ +-------+
+ | Host | | Router|
+ | A | | R1 |
+ +------+ +-------+
+
+ Figure 1 shows an example of a managed segment in a L2 domain that
+ interconnects a set of hosts and routers. For the purpose of this
+ discussion, we ignore the actual physical topology of the L2 domain
+ (assume it is a shared L2 segment and a single managed segment
+ represents the entire L2 domain). A single SBM device is designated
+ to be the DSBM for the managed segment. We will provide examples of
+ operation of the DSBM over switched and shared segments later in the
+ document.
+
+ The basic DSBM-based admission control procedure works as follows:
+
+ 1. DSBM Initialization: As part of its initial configuration, DSBM
+ obtains information such as the limits on fraction of available
+ resources that can be reserved on each managed segment under its
+ control. For instance, bandwidth is one such resource. Even
+ though methods such as auto-negotiation of link speeds and
+ knowledge of link topology allow discovery of link capacity, the
+ configuration may be necessary to limit the fraction of link
+ capacity that can be reserved on a link. Configuration is likely
+ to be static with the current L2/L3 devices. Future work may
+ allow for dynamic discovery of this information. This document
+ does not specify the configuration mechanism.
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 7]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 2. DSBM Client Initialization: For each interface attached, a DSBM
+ client determines whether a DSBM exists on the interface. The
+ procedure for discovering and verifying the existence of the DSBM
+ for an attached segment is described in Appendix A. If the client
+ itself is capable of serving as the DSBM on the segment, it may
+ choose to participate in the election to become the DSBM. At the
+ start, a DSBM client first verifies that a DSBM exists in its L2
+ domain so that it can communicate with the DSBM for admission
+ control purposes.
+
+ In the case of a full-duplex segment, an election may not be
+ necessary as the SBM at each end will typically act as the DSBM
+ for outgoing traffic in each direction.
+
+ 3. DSBM-based Admission Control: To request reservation of resources
+ (e.g., LAN bandwidth in a L2 domain), DSBM clients (RSVP-capable
+ L3 devices such as hosts and routers) follow the following steps:
+
+ a) When a DSBM client sends or forwards a RSVP PATH message over
+ an interface attached to a managed segment, it sends the PATH
+ message to the segment's DSBM instead of sending it to the RSVP
+ session destination address (as is done in conventional RSVP
+ processing). After processing (and possibly updating an
+ ADSPEC), the DSBM will forward the PATH message toward its
+ destination address. As part of its processing, the DSBM builds
+ and maintains a PATH state for the session and notes the
+ previous L2/L3 hop that sent it the PATH message.
+
+ Let us consider the managed segment in Figure 1. Assume that a
+ sender to a RSVP session (session address specifies the IP
+ address of host A on the managed segment in Figure 1) resides
+ outside the L2 domain of the managed segment and sends a PATH
+ message that arrives at router R1 which is on the path towards
+ host A.
+
+ DSBM client on Router R1 forwards the PATH message from the
+ sender to the DSBM. The DSBM processes the PATH message and
+ forwards the PATH message towards the RSVP receiver (Detailed
+ message processing and forwarding rules are described in
+ Section 5). In the process, the DSBM builds the PATH state,
+ remembers the router R1 (its L2 and l3 addresses) as the
+ previous hop for the session, puts its own L2 and L3 addresses
+ in the PHOP objects (see explanation later), and effectively
+ inserts itself as an intermediate node between the sender (or
+ R1 in Figure 1) and the receiver (host A) on the managed
+ segment.
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 8]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ b) When an application on host A wishes to make a reservation for
+ the RSVP session, host A follows the standard RSVP message
+ processing rules and sends a RSVP RESV message to the previous
+ hop L2/L3 address (the DSBMs address) obtained from the PHOP
+ object(s) in the previously received PATH message.
+
+ c) The DSBM processes the RSVP RESV message based on the bandwidth
+ available and returns an RESV_ERR message to the requester
+ (host A) if the request cannot be granted. If sufficient
+ resources are available and the reservation request is granted,
+ the DSBM forwards the RESV message towards the PHOP(s) based on
+ its local PATH state for the session. The DSBM merges
+ reservation requests for the same session as and when possible
+ using the rules similar to those used in the conventional RSVP
+ processing (except for an additional criterion described in
+ Section 5.8).
+
+ d) If the L2 domain contains more than one managed segment, the
+ requester (host A) and the forwarder (router R1) may be
+ separated by more than one managed segment. In that case, the
+ original PATH message would propagate through many DSBMs (one
+ for each managed segment on the path from R1 to A) setting up
+ PATH state at each DSBM. Therefore, the RESV message would
+ propagate hop-by-hop in reverse through the intermediate DSBMs
+ and eventually reach the original forwarder (router R1) on the
+ L2 domain if admission control at all DSBMs succeeds.
+
+4.2.2. Enhancements to the conventional RSVP operation
+
+ (D)SBMs and DSBM clients implement minor additions to the standard
+ RSVP protocol. These are summarized in this section. A detailed
+ description of the message processing and forwarding rules follows in
+ section 5.
+
+4.2.2.1 Sending PATH Messages to the DSBM on a Managed Segment
+
+ Normal RSVP forwarding rules apply at a DSBM client when it is not
+ forwarding an outgoing PATH message over a managed segment. However,
+ outgoing PATH messages on a managed segment are sent to the DSBM for
+ the corresponding managed segment (Section 5.2 describes how the PATH
+ messages are sent to the DSBM on a managed segment).
+
+4.2.2.2 The LAN_NHOP Objects
+
+ In conventional RSVP processing over point-to-point links, RSVP nodes
+ (hosts/routers) use RSVP_HOP object (NHOP and PHOP info) to keep
+ track of the next hop (downstream node in the path of data packets in
+ a traffic flow) and the previous hop (upstream nodes with respect to
+
+
+
+Yavatkar, et al. Standards Track [Page 9]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ the data flow) nodes on the path between a sender and a receiver.
+ Routers along the path of a PATH message forward the message towards
+ the destination address based on the L3 routing (packet forwarding)
+ tables.
+
+ For example, consider the L2 domain in Figure 1. Assume that both the
+ sender (some host X) and the receiver (some host Y) in a RSVP session
+ reside outside the L2 domain shown in the Figure, but PATH messages
+ from the sender to its receiver pass through the routers in the L2
+ domain using it as a transit subnet. Assume that the PATH message
+ from the sender X arrives at the router R1. R1 uses its local routing
+ information to decide which next hop router (either router R2 or
+ router R3) to use to forward the PATH message towards host Y.
+ However, when the path traverses a managed L2 domain, we require the
+ PATH and RESV messages to go through a DSBM for each managed segment.
+ Such a L2 domain may span many managed segments (and DSBMs) and,
+ typically, SBM protocol entities on L2 devices (such as a switch)
+ will serve as the DSBMs for the managed segments in a switched
+ topology. When R1 forwards the PATH message to the DSBM (an L2
+ device), the DSBM may not have the L3 routing information necessary
+ to select the egress router (between R2 and R3) before forwarding the
+ PATH message. To ensure correct operation and routing of RSVP
+ messages, we must provide additional forwarding information to DSBMs.
+
+ For this purpose, we introduce new RSVP objects called LAN_NHOP
+ address objects that keep track of the next L3 hop as the PATH
+ message traverses an L2 domain between two L3 entities (RSVP PHOP and
+ NHOP nodes).
+
+4.2.2.3 Including Both Layer-2 and Layer-3 Addresses in the LAN_NHOP
+
+ When a DSBM client (a host or a router acting as the originator of a
+ PATH message) sends out a PATH message to the DSBM, it must include
+ LAN_NHOP information in the message. In the case of a unicast
+ destination, the LAN_NHOP address specifies the destination address
+ (if the destination is local to its L2 domain) or the address of the
+ next hop router towards the destination. In our example of an RSVP
+ session involving the sender X and receiver Y with L2 domain in
+ Figure 1 acting as the transit subnet, R1 is the ingress node that
+ receives the PATH message. R1 first determines that R2 is the next
+ hop router (or the egress node in the L2 domain for the session
+ address) and then inserts a LAN_NHOP object that specifies R2's IP
+ address. When a DSBM receives a PATH message, it can now look at the
+ address in the LAN_NHOP object and forward the PATH message towards
+ the egress node after processing the PATH message. However, we
+ expect the L2 devices (such as switches) to act as DSBMs on the path
+ within the L2 domain and it may not be reasonable to expect these
+ devices to have an ARP capability to determine the MAC address (we
+
+
+
+Yavatkar, et al. Standards Track [Page 10]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ call it L2ADDR for Layer 2 address) corresponding to the IP address
+ in the LAN_NHOP object.
+
+ Therefore, we require that the LAN_NHOP information (generated by the
+ L3 device) include both the IP address (LAN_NHOP_L3 address) and the
+ corresponding MAC address (LAN_NHOP_L2 address ) for the next L3 hop
+ over the L2 domain. The LAN_NHOP_L3 address is used by SBM protocol
+ entities on L3 devices to forward the PATH message towards its
+ destination whereas the L2 address is used by the SBM protocol
+ entities on L2 devices to determine how to forward the PATH message
+ towards the L3 NHOP (egress point from the L2 domain). The exact
+ format of the LAN_NHOP information and relevant objects is described
+ later in Appendix B.
+
+4.2.2.4 Similarities to Standard RSVP Message Processing
+
+ - When a DSBM receives a RSVP PATH message, it processes the PATH
+ message according to the PATH processing rules described in the
+ RSVP specification. In particular, the DSBM retrieves the IP
+ address of the previous hop from the RSVP_HOP object in the PATH
+ message and stores the PHOP address in its PATH state. It then
+ forwards the PATH message with the PHOP (RSVP_HOP) object modified
+ to reflect its own IP address (RSVP_HOP_L3 address). Thus, the
+ DSBM inserts itself as an intermediate hop in the chain of nodes
+ in the path between two L3 nodes across the L2 domain.
+
+ - The PATH state in a DSBM is used for forwarding subsequent RESV
+ messages as per the standard RSVP message processing rules. When
+ the DSBM receives a RESV message, it processes the message and
+ forwards it to appropriate PHOP(s) based on its PATH state.
+
+ - Because a DSBM inserts itself as a hop between two RSVP nodes in
+ the path of a RSVP flow, all RSVP related messages (such as PATH,
+ PATH_TEAR, RESV, RESV_CONF, RESV_TEAR, and RESV_ERR) now flow
+ through the DSBM. In particular, a PATH_TEAR message is routed
+ exactly through the intermediate DSBM(s) as its corresponding PATH
+ message and the local PATH state is first cleaned up at each
+ intermediate hop before the PATH_TEAR message gets forwarded.
+
+ - So far, we have described how the PATH message propagates through
+ the L2 domain establishing PATH state at each DSBM along the
+ managed segments in the path. The layer 2 address (LAN_NHOP_L2
+ address) in the LAN_NHOP object should be used by the L2 devices
+ along the path to decide how to forward the PATH message toward
+ the next L3 hop. Such devices will apply the standard IEEE 802.1D
+ forwarding rules (e.g., send it on a single port based on its
+ filtering database, or flood it on all ports active in the
+ spanning tree if the L2 address does not appear in the filtering
+
+
+
+Yavatkar, et al. Standards Track [Page 11]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ database) to the LAN_NHOP_L2 address as are applied normally to
+ data packets destined to the address.
+
+4.2.2.5 Including Both Layer-2 and Layer-3 Addresses in the RSVP_HOP
+ Objects
+
+ In the conventional RSVP message processing, the PATH state
+ established along the nodes on a path is used to route the RESV
+ message from a receiver to a sender in an RSVP session. As each
+ intermediate node builds the path state, it remembers the previous
+ hop (stores the PHOP IP address available in the RSVP_HOP object of
+ an incoming message) that sent it the PATH message and, when the RESV
+ message arrives, the intermediate node simply uses the stored PHOP
+ address to forward the RESV after processing it successfully.
+
+ In our case, we expect the SBM entities residing at L2 devices to act
+ as DSBMs (and, therefore, intermediate RSVP hops in an L2 domain)
+ along the path between a sender (PHOP) and receiver (NHOP). Thus,
+ when a RESV message arrives at a DSBM, it must use the stored PHOP IP
+ address to forward the RESV message to its previous hop. However, it
+ may not be reasonable to expect the L2 devices to have an ARP cache
+ or the ARP capability to map the PHOP IP address to its corresponding
+ L2 address before forwarding the RESV message.
+
+ To obviate the need for such address mapping at L2 devices, we use a
+ RSVP_HOP_L2 object in the PATH message. The RSVP_HOP_L2 object
+ includes the Layer 2 address (L2ADDR) of the previous hop and
+ complements the L3 address information included in the RSVP_HOP
+ object (RSVP_HOP_L3 address).
+
+ When a L3 device constructs and forwards a PATH message over a
+ managed segment, it includes its IP address (IP address of the
+ interface over which PATH is sent) in the RSVP_HOP object and adds a
+ RSVP_HOP_L2 object that includes the corresponding L2 address for the
+ interface. When a device in the L2 domain receives such a PATH
+ message, it remembers the addresses in the RSVP_HOP and RSVP_HOP_L2
+ objects in its PATH state and then overwrites the RSVP_HOP and
+ RSVP_HOP_L2 objects with its own addresses before forwarding the PATH
+ message over a managed segment.
+
+ The exact format of RSVP_HOP_L2 object is specified in Appendix B.
+
+4.2.2.6 Loop Detection
+
+ When an RSVP session address is a multicast address and a SBM, DSBM,
+ and DSBM clients share the same L2 segment (a shared segment), it is
+ possible for a SBM or a DSBM client to receive one or more copies of
+ a PATH message that it forwarded earlier when a DSBM on the same wire
+
+
+
+Yavatkar, et al. Standards Track [Page 12]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ forwards it (See Section 5.7 for an example of such a case). To
+ facilitate detection of such loops, we use a new RSVP object called
+ the LAN_LOOPBACK object. DSBM clients or SBMs (but not the DSBMs
+ reflecting a PATH message onto the interface over which it arrived
+ earlier) must overwrite (or add if the PATH message does NOT already
+ include a LAN_LOOPBACK object) the LAN_LOOPBACK object in the PATH
+ message with their own unicast IP address.
+
+ Now, a SBM or a DSBM client can easily detect and discard the
+ duplicates by checking the contents of the LAN_LOOPBACK object (a
+ duplicate PATH message will list a device's own interface address in
+ the LAN_LOOPBACK object). Appendix B specifies the exact format of
+ the LAN_LOOPBACK object.
+
+4.2.2.7 802.1p, User Priority and TCLASS
+
+ The model proposed by the Integrated Services working group requires
+ isolation of traffic flows from each other during their transit
+ across a network. The motivation for traffic flow separation is to
+ provide Integrated Services flows protection from misbehaving flows
+ and other best-effort traffic that share the same path. The basic
+ IEEE 802.3/Ethernet networks do not provide any notion of traffic
+ classes to discriminate among different flows that request different
+ services. However, IEEE 802.1p defines a way for switches to
+ differentiate among several "user_priority" values encoded in packets
+ representing different traffic classes (see [IEEE802Q, IEEE8021p] for
+ further details). The user_priority values can be encoded either in
+ native LAN packets (e.g., in IEEE 802.5's FC octet) or by using an
+ encapsulation above the MAC layer (e.g., in the case of Ethernet, the
+ user_priority value assigned to each packet will be carried in the
+ frame header using the new, extended frame format defined by IEEE
+ 802.1Q [IEEE8021Q]. IEEE, however, makes no recommendations about how
+ a sender or network should use the user_priority values. An
+ accompanying document makes recommendations on the usage of the
+ user_priority values (see [RFC-MAP] for details).
+
+ Under the Integrated Services model, L3 (or higher) entities that
+ transmit traffic flows onto a L2 segment should perform per-flow
+ policing to ensure that the flows do not exceed their traffic
+ specification as specified during admission control. In addition, L3
+ devices may label the frames in such flows with a user_priority value
+ to identify their service class.
+
+ For the purpose of this discussion, we will refer to the
+ user_priority value carried in the extended frame header as the
+ "traffic class" of a packet. Under the ISSLL model, the L3 entities,
+ that send traffic and that use the SBM protocol, may select the
+ appropriate traffic class of outgoing packets [RFC-MAP]. This
+
+
+
+Yavatkar, et al. Standards Track [Page 13]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ selection may be overridden by DSBM devices, in the following manner.
+ once a sender sends a PATH message, downstream DSBMs will insert a
+ new traffic class object (TCLASS object) in the PATH message that
+ travels to the next L3 device (L3 NHOP for the PATH message). To some
+ extent, the TCLASS object contents are treated like the ADSPEC object
+ in the RSVP PATH messages. The L3 device that receives the PATH
+ message must remove and store the TCLASS object as part of its PATH
+ state for the session. Later, when the same L3 device needs to
+ forward a RSVP RESV message towards the original sender, it must
+ include the TCLASS object in the RESV message. When the RESV message
+ arrives at the original sender, the sender must use the user_priority
+ value from the TCLASS object to override its selection for the
+ traffic class marked in outgoing packets.
+
+ The format of the TCLASS object is specified in Appendix B. Note
+ that TCLASS and other SBM-specific objects are carried in a RSVP
+ message in addition to all the other, normal RSVP objects per RFC
+ 2205.
+
+4.2.2.8 Processing the TCLASS Object
+
+ In summary, use of TCLASS objects requires following additions to the
+ conventional RSVP message processing at DSBMs, SBMs, and DSBM
+ clients:
+
+ * When a DSBM receives a PATH message over a managed segment and the
+ PATH message does not include a TCLASS object, the DSBM MAY add a
+ TCLASS object to the PATH message before forwarding it. The DSBM
+ determines the appropriate user_priority value for the TCLASS
+ object. A mechanism for selecting the appropriate user_priority
+ value is described in an accompanying document [RFC-MAP].
+
+ * When SBM or DSBM receives a PATH message with a TCLASS object over
+ a managed segment in a L2 domain and needs to forward it over a
+ managed segment in the same L2 domain, it will store it in its
+ path state and typically forward the message without changing the
+ contents of the TCLASS object. However, if the DSBM/SBM cannot
+ support the service class represented by the user_priority value
+ specified by the TCLASS object in the PATH message, it may change
+ the priority value in the TCLASS to a semantically "lower" service
+ value to reflect its capability and store the changed TCLASS value
+ in its path state.
+
+
+
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 14]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ [NOTE: An accompanying document defines the int-serv mappings over
+ IEEE 802 networks [RFC-MAP] provides a precise definition of
+ user_priority values and describes how the user_priority values
+ are compared to determine "lower" of the two values or the
+ "lowest" among all the user_priority values.]
+
+ * When a DSBM receives a RESV message with a TCLASS object, it may
+ use the traffic class information (in addition to the usual
+ flowspec information in the RSVP message) for its own admission
+ control for the managed segment.
+
+ Note that this document does not specify the actual algorithm or
+ policy used for admission control. At one extreme, a DSBM may use
+ per-flow reservation request as specified by the flowspec for a
+ fine grain admission control. At the other extreme, a DSBM may
+ only consider the traffic class information for a very coarse-
+ grain admission control based on some static allocation of link
+ capacity for each traffic class. Any combination of the options
+ represented by these two extremes may also be used.
+
+ * When a DSBM (at an L2 or L3) device receives a RESV message
+ without a TCLASS object and it needs to forward the RESV message
+ over a managed segment within the same L2 domain, it should first
+ check its path state and check whether it has stored a TCLASS
+ value. If so, it should include the TCLASS object in the outgoing
+ RESV message after performing its own admission control. If no
+ TCLASS value is stored, it must forward the RESV message without
+ inserting a TCLASS object.
+
+ * When a DSBM client (residing at an L3 device such as a host or an
+ edge router) receives the TCLASS object in a PATH message that it
+ accepts over an interface, it should store the TCLASS object as
+ part of its PATH state for the interface. Later, when the client
+ forwards a RESV message for the same session on the interface, the
+ client must include the TCLASS object (unchanged from what was
+ received in the previous PATH message) in the RESV message it
+ forwards over the interface.
+
+ * When a DSBM client receives a TCLASS object in an incoming RESV
+ message over a managed segment and local admission control
+ succeeds for the session for the outgoing interface over the
+ managed segment, the client must pass the user_priority value in
+ the TCLASS object to its local packet classifier. This will ensure
+ that the data packets in the admitted RSVP flow that are
+ subsequently forwarded over the outgoing interface will contain
+ the appropriate value encoded in their frame header.
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 15]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ * When an L3 device receives a PATH or RESV message over a managed
+ segment in one L2 domain and it needs to forward the PATH/RESV
+ message over an interface outside that domain, the L3 device must
+ remove the TCLASS object (along with LAN_NHOP, RSVP_HOP_L2, and
+ LAN_LOOPBACK objects in the case of the PATH message) before
+ forwarding the PATH/RESV message. If the outgoing interface is on
+ a separate L2 domain, these objects may be regenerated according
+ to the processing rules applicable to that interface.
+
+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.
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 16]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 17]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ * 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.
+
+
+
+Yavatkar, et al. Standards Track [Page 18]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+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:
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 19]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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.
+
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 20]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ (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.
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 21]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ * 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:
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 22]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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
+
+
+
+Yavatkar, et al. Standards Track [Page 23]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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
+
+
+
+
+Yavatkar, et al. Standards Track [Page 24]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ ("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:
+
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 25]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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)
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 26]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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
+
+
+
+Yavatkar, et al. Standards Track [Page 27]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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
+
+
+
+Yavatkar, et al. Standards Track [Page 28]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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.
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 29]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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
+
+
+
+Yavatkar, et al. Standards Track [Page 30]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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.
+
+
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 31]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+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.
+
+
+
+Yavatkar, et al. Standards Track [Page 32]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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
+
+
+
+
+Yavatkar, et al. Standards Track [Page 33]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 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.
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 34]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 35]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+A.1. Introduction
+
+ To simplify the rest of this discussion, we will assume that there is
+ a single DSBM for the entire L2 domain (i.e., assume a shared L2
+ segment for the entire L2 domain). Later, we will discuss how a DSBM
+ is elected for a half-duplex or full-duplex switched segment.
+
+ To allow for quick recovery from the failure of a DSBM, we assume
+ that additional SBMs may be active in a L2 domain for fault
+ tolerance. When more than one SBM is active in a L2 domain, the SBMs
+ use an election algorithm to elect a DSBM for the L2 domain. After
+ the DSBM is elected and is operational, other SBMs remain passive in
+ the background to step in to elect a new DSBM when necessary. The
+ protocol for electing and discovering DSBM is called the "DSBM
+ election protocol" and is described in the rest of this Appendix.
+
+A.1.1. How a DSBM Client Detects a Managed Segment
+
+ Once elected, a DSBM periodically multicasts an I_AM_DSBM message on
+ the AllSBMAddress to indicate its presence. The message is sent every
+ period (e.g., every 5 seconds) according to the RefreshInterval timer
+ value (a configuration parameter). Absence of such a message over a
+ certain time interval (called "DSBMDeadInterval"; another
+ configuration parameter typically set to a multiple of
+ RefreshInterval) indicates that the DSBM has failed or terminated and
+ triggers another round of the DSBM election. The DSBM clients always
+ listen for periodic DSBM advertisements. The advertisement includes
+ the unicast IP address of the DSBM (DSBMAddress) and DSBM clients
+ send their PATH/RESV (or other) messages to the DSBM. When a DSBM
+ client detects the failure of a DSBM, it waits for a subsequent
+ I_AM_DSBM advertisement before resuming any communication with the
+ DSBM. During the period when a DSBM is not present, a DSBM client may
+ forward outgoing PATH messages using the standard RSVP forwarding
+ rules.
+
+ The exact message formats and addresses used for communication with
+ (and among) SBM(s) are described in Appendix B.
+
+A.2. Overview of the DSBM Election Procedure
+
+ When a SBM first starts up, it listens for incoming DSBM
+ advertisements for some period to check whether a DSBM already exists
+ in its L2 domain. If one already exists (and no new election is in
+ progress), the new SBM stays quiet in the background until an
+ election of DSBM is necessary. All messages related to the DSBM
+ election and DSBM advertisements are always sent to the
+ AllSBMAddress.
+
+
+
+
+Yavatkar, et al. Standards Track [Page 36]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ If no DSBM exists, the SBM initiates the election of a DSBM by
+ sending out a DSBM_WILLING message that lists its IP address as a
+ candidate DSBM and its "SBM priority". Each SBM is assigned a
+ priority to determine its relative precedence. When more than one
+ SBM candidate exists, the SBM priority determines who gets to be the
+ DSBM based on the relative priority of candidates. If there is a tie
+ based on the priority value, the tie is broken using the IP
+ addresses of tied candidates (one with the higher IP address in the
+ lexicographic order wins). The details of the election protocol start
+ in Section A.4.
+
+A.2.1 Summary of the Election Algorithm
+
+ For the purpose of the algorithm, a SBM is in one of the four states
+ (Idle, DetectDSBM, ElectDSBM, IAMDSBM).
+
+ A SBM (call it X) starts up in the DetectDSBM state and waits for a
+ ListenInterval for incoming I_AM_DSBM (DSBM advertisement) or
+ DSBM_WILLING messages. If an I_AM_DSBM advertisement is received
+ during this state, the SBM notes the current DSBM (its IP address and
+ priority) and enters the Idle state. If a DSBM_WILLING message is
+ received from another SBM (call it Y) during this state, then X
+ enters the ElectDSBM state. Before entering the new state, X first
+ checks to see whether it itself is a better candidate than Y and, if
+ so, sends out a DSBM_WILLING message and then enters the ElectDSBM
+ state.
+
+ When a SBM (call it X) enters the ElectDSBM state, it sets a timer
+ (called ElectionIntervalTimer, and typically set to a value at least
+ equal to the DSBMDeadInterval value) to wait for the election to
+ finish and to discover who is the best candidate. In this state, X
+ keeps track of the best (or better) candidate seen so far (including
+ itself). Whenever it receives another DSBM_WILLING message it updates
+ its notion of the best (or better) candidate based on the priority
+ (and tie-breaking) criterion. During the ElectionInterval, X sends
+ out a DSBM_WILLING message every RefreshInterval to (re)assert its
+ candidacy.
+
+ At the end of the ElectionInterval, X checks whether it is the best
+ candidate so far. If so, it declares itself to be the DSBM (by
+ sending out the I_AM_DSBM advertisement) and enters the IAMDSBM
+ state; otherwise, it decides to wait for the best candidate to
+ declare itself the winner. To wait, X re-initializes its ElectDSBM
+ state and continues to wait for another round of election (each round
+ lasts for an ElectionTimerInterval duration).
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 37]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ A SBM is in Idle state when no election is in progress and the DSBM
+ is already elected (and happens to be someone else). In this state,
+ it listens for incoming I_AM_DSBM advertisements and uses a
+ DSBMDeadIntervalTimer to detect the failure of DSBM. Every time the
+ advertisement is received, the timer is restarted. If the timer
+ fires, the SBM goes into the DetectDSBM state to prepare to elect the
+ new DSBM. If a SBM receives a DSBM_WILLING message from the current
+ DSBM in this state, the SBM enters the ElectDSBM state after sending
+ out a DSBM_WILLING message (to announce its own candidacy).
+
+ In the IAMDSBM state, the DSBM sends out I_AM_DSBM advertisements
+ every refresh interval. If the DSBM wishes to shut down (gracefully
+ terminate), it sends out a DSBM_WILLING message (with SBM priority
+ value set to zero) to initiate the election procedure. The priority
+ value zero effectively removes the outgoing DSBM from the election
+ procedure and makes way for the election of a different DSBM.
+
+A.3. Recovering from DSBM Failure
+
+ When a DSBM fails (DSBMDeadIntervalTimer fires), all the SBMs enter
+ the ElectDSBM state and start the election process.
+
+ At the end of the ElectionInterval, the elected DSBM sends out an
+ I_AM_DSBM advertisement and the DSBM is then operational.
+
+A.4. DSBM Advertisements
+
+ The I_AM_DSBM advertisement contains the following information:
+
+ 1. DSBM address information -- contains the IP and L2 addresses of
+ the DSBM and its SBM priority (a configuration parameter --
+ priority specified by a network administrator). The priority
+ value is used to choose among candidate SBMs during the election
+ algorithm. Higher integer values indicate higher priority and the
+ value is in the range 0..255. The value zero indicates that the
+ SBM is not eligible to be the DSBM. The IP address is required
+ and used for breaking ties. The L2 address is for the interface
+ of the managed segment.
+
+ 2. RegreshInterval -- contains the value of RefreshInterval in
+ seconds. Value zero indicates the parameter has been omitted in
+ the message. Receivers may substitute their own default value in
+ this case.
+
+ 3. DSBMDeadInterval -- contains the value of DSBMDeadInterval in
+ seconds. If the value is omitted (or value zero is specified), a
+ default value (from initial configuration) should be used.
+
+
+
+
+Yavatkar, et al. Standards Track [Page 38]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 4. Miscellaneous configuration information to be advertised to
+ senders on the managed segment. See Appendix C for further
+ details.
+
+A.5. DSBM_WILLING Messages
+
+ When a SBM wishes to declare its candidacy to be the DSBM during an
+ election phase, it sends out a DSBM_WILLING message. The DSBM_WILLING
+ message contains the following information:
+
+ 1. DSBM address information -- Contains the SBM's own addresses (IP
+ and L2 address), if it wishes to be the DSBM. The IP address is
+ required and used for breaking ties. The L2 address is the
+ address of the interface for the managed segment in question.
+ Also, the DSBM address information includes the corresponding
+ priority of the SBM whose address is given above.
+
+A.6. SBM State Variables
+
+ For each network interface, a SBM maintains the following state
+ variables related to the election of the DSBM for the L2 domain on
+ that interface:
+
+ a) LocalDSBMAddrInfo -- current DSBM's IP address (initially,
+ 0.0.0.0) and priority. All IP addresses are assumed to be in
+ network byte order. In addition, current DSBM's L2 address is
+ also stored as part of this state information.
+
+ b) OwnAddrInfo -- SBM's own IP address and L2 address for the
+ interface and its own priority (a configuration parameter).
+
+ c) RefreshInterval in seconds. When the DSBM is not yet elected,
+ it is set to a default value specified as a configuration
+ parameter.
+
+ d) DSBMDeadInterval in seconds. When the DSBM is not yet elected,
+ it is initially set to a default value specified as a
+ configuration parameter.
+
+ f) ListenInterval in seconds -- a configuration parameter that
+ decides how long a SBM spends in the DetectDSBM state (see
+ below).
+
+ g) ElectionInterval in seconds -- a configuration parameter that
+ decides how long a SBM spends in the ElectDSBM state when it has
+ declared its candidacy.
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 39]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ Figure 3 shows the state transition diagram for the election protocol
+ and the various states are described below. A complete description of
+ the state machine is provided in Section A.10.
+
+A.7. DSBM Election States
+
+ DOWN -- SBM is not operational.
+
+ DetectDSBM -- typically, the initial state of a SBM when it
+ starts up. In this state, it checks to see whether a DSBM already
+ exists in its domain.
+
+ Idle -- SBM is in this state when no election is in progress and
+ it is not the DSBM. In this state, SBM passively monitors the
+ state of the DSBM.
+
+ ElectDSBM -- SBM is in this state when a DSBM election is in
+ progress.
+
+ IAMDSBM -- SBM is in this state when it is the DSBM for the L2
+ domain.
+
+A.8. Events that cause state changes
+
+ StartUp -- SBM starts operation.
+
+ ListenInterval Timeout -- The ListenInterval timer has fired.
+ This means that the SBM has monitored its domain to check for an
+ existing DSBM or to check whether there are candidates (other
+ than itself) willing to be the DSBM.
+
+ DSBM_WILLING message received -- This means that the SBM received
+ a DSBM_WILLING message from some other SBM. Such a message is
+ sent when a SBM wishes to declare its candidacy to be the DSBM.
+
+ I_AM_DSBM message received -- SBM received a DSBM advertisement
+ from the DSBM in its L2 domain.
+
+ DSBMDeadInterval Timeout -- The DSBMDeadIntervalTimer has fired.
+ This means that the SBM did not receive even one DSBM
+ advertisement during this period and indicates possible failure
+ of the DSBM.
+
+ RefreshInterval Timeout -- The RefreshIntervalTimer has fired. In
+ the IAMDSBM state, this means it is the time for sending out the
+ next DSBM advertisement. In the ElectDSBM state, the event means
+ that it is the time to send out another DSBM_WILLING message.
+
+
+
+
+Yavatkar, et al. Standards Track [Page 40]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ ElectionInterval Timeout -- The ElectionIntervalTimer has fired.
+ This means that the SBM has waited long enough after declaring
+ its candidacy to determine whether or not it succeeded.
+
+A.9. State Transition Diagram (Figure 3)
+
+ +-----------+
+ +--<--------------<-|DetectDSBM |---->------+
+ | +-----------+ |
+ | |
+ | |
+ | |
+ | +-------------+ +---------+ |
+ +->---| Idle |--<>---|ElectDSBM|--<--+
+ +-------------+ +---------+
+ | |
+ | |
+ | |
+ | +-----------+ |
+ +<<- +---| IAMDSBM |-<-+
+ | +-----------+
+ |
+ | +-----------+
+ +>>-| SHUTDOWN |
+ +-----------+
+
+A.10. Election State Machine
+
+ Based on the events and states described above, the state changes at
+ a SBM are described below. Each state change is triggered by an event
+ and is typically accompanied by a sequence of actions. The state
+ machine is described assuming a single threaded implementation (to
+ avoid race conditions between state changes and timer events) with no
+ timer events occurring during the execution of the state machine.
+
+ The following routines will be frequently used in the description of
+ the state machine:
+
+ ComparePrio(FirstAddrInfo, SecondAddrInfo)
+ -- determines whether the entity represented by the first parameter
+ is better than the second entity using the priority information
+ and the IP address information in the two parameters. If any
+ address is zero, that entity automatically loses; then first
+ priorities are compared; higher priority candidate wins. If there
+ is a tie based on the priority value, the tie is broken using the
+ IP addresses of tied candidates (one with the higher IP address
+ in the lexicographic order wins). Returns TRUE if first entity
+ is a better choice. FALSE otherwise.
+
+
+
+Yavatkar, et al. Standards Track [Page 41]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ SendDSBMWilling Message()
+ Begin
+ Send out DSBM_WILLING message listing myself as a candidate for
+ DSBM (copy OwnAddr and priority into appropriate fields)
+ start RefreshIntervalTimer
+ goto ElectDSBM state
+ End
+
+ AmIBetterDSBM(OtherAddrInfo)
+ Begin
+ if (ComparePrio(OwnAddrInfo, OtherAddrInfo))
+ return TRUE
+
+ change LocalDSBMInfo = OtherDSBMAddrInfo
+ return FALSE
+ End
+
+ UpdateDSBMInfo()
+ /* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */
+ Begin
+ update LocalDSBMInfo such as IP addr, DSBM L2 address,
+ DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer
+ End
+
+A.10.1 State Changes
+
+ In the following, the action "continue" or "continue in current
+ state" means an "exit" from the current action sequence without a
+ state transition.
+
+ State: DOWN
+ Event: StartUp
+ New State: DetectDSBM
+ Action: Initialize the local state variables (LocalDSBMADDR and
+ LocalDSBMAddrInfo set to 0). Start the ListenIntervalTimer.
+
+ State: DetectDSBM
+ New State: Idle
+ Event: I_AM_DSBM message received
+ Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo
+ start DeadDSBMInterval timer
+ goto Idle State
+
+ State: DetectDSBM
+ Event: ListenIntervalTimer fired
+ New State: ElectDSBM
+ Action: Start ElectionIntervalTimer
+ SendDSBMWillingMessage();
+
+
+
+Yavatkar, et al. Standards Track [Page 42]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ State: DetectDSBM
+ Event: DSBM_WILLING message received
+ New State: ElectDSBM
+ Action: Cancel any active timers
+
+ Start ElectionIntervalTimer
+ /* am I a better choice than this dude? */
+ If (ComparePrio(OwnAddrInfo, IncomingDSBMInfo)) {
+ /* I am better */
+ SendDSBMWillingMessage()
+ } else {
+ Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
+ goto ElectDSBM state
+ }
+
+ State: Idle
+ Event: DSBMDeadIntervalTimer fired.
+ New State: ElectDSBM
+ Action: start ElectionIntervalTimer
+ set LocalDSBMAddrInfo = OwnAddrInfo
+ SendDSBMWiliingMessage()
+
+ State: Idle
+ Event: I_AM_DSBM message received.
+ New State: Idle
+ Action: /* first check whether anything has changed */
+ if (!ComparePrio(LocalDSBMAddrInfo, IncomingDSBMAddrInfo))
+ change LocalDSBMAddrInfo to reflect new info
+ endif
+ restart DSBMDeadIntervalTimer;
+ continue in current state;
+
+ State: Idle
+ Event: DSBM_WILLING Message is received
+ New State: Depends on action (ElectDSBM or Idle)
+ Action: /* check whether it is from the DSBM itself (shutdown) */
+ if (IncomingDSBMAddr == LocalDSBMAddr) {
+ cancel active timers
+ Set LocalDSBMAddrInfo = OwnAddrInfo
+ Start ElectionIntervalTimer
+ SendDSBMWillingMessage() /* goto ElectDSBM state */
+ }
+
+ /* else, ignore it */
+ continue in current state
+
+ State: ElectDSBM
+ Event: ElectionIntervalTimer Fired
+
+
+
+Yavatkar, et al. Standards Track [Page 43]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ New State: depends on action (IAMDSBM or Current State)
+ Action: If (LocalDSBMAddrInfo == OwnAddrInfo) {
+ /* I won */
+ send I_AM_DSBM message
+ start RefreshIntervalTimer
+ goto IAMDSBM state
+ } else { /* someone else won, so wait for it to declare
+ itself to be the DSBM */
+ set LocalDSBMAddressInfo = OwnAddrInfo
+ start ElectionIntervalTimer
+ SendDSBMWillingMessage()
+ continue in current state
+ }
+
+ State: ElectDSBM
+ Event: I_AM_DSBM message received
+ New State: Idle
+ Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo
+ Cancel any active timers
+ start DeadDSBMInterval timer
+ goto Idle State
+
+ State: ElectDSBM
+ Event: DSBM_WILLING message received
+ New State: ElectDSBM
+ Action: Check whether it's a loopback and if so, discard, continue;
+ if (!AmIBetterDSBM(IncomingDSBMAddrInfo)) {
+ Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo
+ Cancel RefreshIntervalTimer
+ } else if (LocalDSBMAddrInfo == OwnAddrInfo) {
+ SendDSBMWillingMessage()
+ }
+ continue in current state
+
+ State: ElectDSBM
+ Event: RefreshIntervalTimer fired
+ New State: ElectDSBM
+ Action: /* continue to send DSBMWilling messages until
+ election interval ends */
+ SendDSBMWillingMessage()
+
+ State: IAMDSBM
+ Event: DSBM_WILLING message received
+ New State: depends on action (IAMDSBM or SteadyState)
+ Action: /* check whether other guy is better */
+ If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
+ /* I am better */
+ send I_AM_DSBM message
+
+
+
+Yavatkar, et al. Standards Track [Page 44]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ restart RefreshIntervalTimer
+ continue in current state
+ } else {
+ Set LocalDSBMAddrInfo = IncomingAddrInfo
+ cancel active timers
+ start DSBMDeadIntervalTimer
+ goto SteadyState
+ }
+
+ State: IAMDSBM
+ Event: RefreshIntervalTimer fired
+ New State: IAMDSBM
+ Action: send I_AM_DSBM message
+ restart RefreshIntervalTimer
+
+ State: IAMDSBM
+ Event: I_AM_DSBM message received
+ New State: depends on action (IAMDSBM or Idle)
+ Action: /* check whether other guy is better */
+ If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
+ /* I am better */
+ send I_AM_DSBM message
+ restart RefreshIntervalTimer
+ continue in current state
+ } else {
+ Set LocalDSBMAddrInfo = IncomingAddrInfo
+ cancel active timers
+ start DSBMDeadIntervalTimer
+ goto Idle State
+ }
+
+ State: IAMDSBM
+ Event: Want to shut myself down
+ New State: DOWN
+ Action: send DSBM_WILLING message with My address filled in, but
+ priority set to zero
+ goto Down State
+
+A.10.2 Suggested Values of Interval Timers
+
+ To avoid DSBM outages for long period, to ensure quick recovery from
+ DSBM failures, and to avoid timeout of PATH and RESV state at the
+ edge devices, we suggest the following values for various timers.
+
+ Assuming that the RSVP implementations use a 30 second timeout for
+ PATH and RESV refreshes, we suggest that the RefreshIntervalTimer
+ should be set to about 5 seconds with DSBMDeadIntervalTimer set to 15
+ seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be set
+
+
+
+Yavatkar, et al. Standards Track [Page 45]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ to a random value between (DSBMDeadIntervalTimer,
+ 2*DSBMDeadIntervalTimer). The ElectionIntervalTimer should be set at
+ least to the value of DSBMDeadIntervalTimer to ensure that each SBM
+ has a chance to have its DSBM_WILLING message (sent every
+ RefreshInterval in ElectDSBM state) delivered to others.
+
+A.10.3. Guidelines for Choice of Values for SBM_PRIORITY
+
+ Network administrators should configure SBM protocol entity at each
+ SBM-capable device with the device's "SBM priority" for each of the
+ interfaces attached to a managed segment. SBM_PRIORITY is an 8-bit,
+ unsigned integer value (in the range 0-255) with higher integer
+ values denoting higher priority. The value zero for an interface
+ indicates that the SBM protocol entity on the device is not eligible
+ to be a DSBM for the segment attached to the interface.
+
+ A separate range of values is reserved for each type of SBM-capable
+ device to reflect the relative priority among different classes of
+ L2/L3 devices. L2 devices get higher priority followed by routers
+ followed by hosts. The priority values in the range of 128..255 are
+ reserved for L2 devices, the values in the range of 64..127 are
+ reserved for routers, and values in the range of 1..63 are reserved
+ for hosts.
+
+A.11. DSBM Election over switched links
+
+ The election algorithm works as described before in this case except
+ each SBM-capable L2 device restricts the scope of the election to its
+ local segment. As described in Section B.1 below, all messages
+ related to the DSBM election are sent to a special multicast address
+ (AllSBMAddress). AllSBMAddress (its corresponding MAC multicast
+ address) is configured in the permanent database of SBM-capable,
+ layer 2 devices so that all frames with AllSBMAddress as the
+ destination address are not forwarded and instead directed to the SBM
+ management entity in those devices. Thus, a DSBM can be elected
+ separately on each point-to-point segment in a switched topology. For
+ example, in Figure 2, DSBM for "segment A" will be elected using the
+ election algorithm between R1 and S1 and none of the election-related
+ messages on this segment will be forwarded by S1 beyond "segment A".
+ Similarly, a separate election will take place on each segment in
+ this topology.
+
+ When a switched segment is a half-duplex segment, two senders (one
+ sender at each end of the link) share the link. In this case, one of
+ the two senders will win the DSBM election and will be responsible
+ for managing the segment.
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 46]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ If a switched segment is full-duplex, exactly one sender sends on the
+ link in each direction. In this case, either one or two DSBMs can
+ exist on such a managed segment. If a sender at each end wishes to
+ serve as a DSBM for that end, it can declare itself to be the DSBM by
+ sending out an I_AM_DSBM advertisement and start managing the
+ resources for the outgoing traffic over the segment. If one of the
+ two senders does not wish itself to be the DSBM, then the other DSBM
+ will not receive any DSBM advertisement from its peer and assume
+ itself to be the DSBM for traffic traversing in both directions over
+ the managed segment.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 47]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+Appendix B Message Encapsulation and Formats
+
+ To minimize changes to the existing RSVP implementations and to
+ ensure quick deployment of a SBM in conjunction with RSVP, all
+ communication to and from a DSBM will be performed using messages
+ constructed using the current rules for RSVP message formats and raw
+ IP encapsulation. For more details on the RSVP message formats, refer
+ to the RSVP specification (RFC 2205). No changes to the RSVP message
+ formats are proposed, but new message types and new L2-specific
+ objects are added to the RSVP message formats to accommodate DSBM-
+ related messages. These additions are described below.
+
+B.1 Message Addressing
+
+ For the purpose of DSBM election and detection, AllSBMAddress is used
+ as the destination address while sending out both DSBM_WILLING and
+ I_AM_DSBM messages. A DSBM client first detects a managed segment by
+ listening to I_AM_DSBM advertisements and records the DSBMAddress
+ (unicast IP address of the DSBM).
+
+B.2. Message Sizes
+
+ Each message must occupy exactly one IP datagram. If it exceeds the
+ MTU, such a datagram will be fragmented by IP and reassembled at the
+ recipient node. This has a consequence that a single message may not
+ exceed the maximum IP datagram size, approximately 64K bytes.
+
+B.3. RSVP-related Message Formats
+
+ All RSVP messages directed to and from a DSBM may contain various
+ RSVP objects defined in the RSVP specification and messages continue
+ to follow the formatting rules specified in the RSVP specification.
+ In addition, an RSVP implementation must also recognize new object
+ classes that are described below.
+
+B.3.1. Object Formats
+
+ All objects are defined using the format specified in the RSVP
+ specification. Each object has a 32-bit header that contains length
+ (of the object in bytes including the object header), the object
+ class number, and a C-Type. All unused fields should be set to zero
+ and ignored on receipt.
+
+
+
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 48]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+B.3.2. SBM Specific Objects
+
+ Note that the Class-Num values for the SBM specific objects
+ (LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2) are chosen from the
+ codespace 10XXXXXX. This coding assures that non-SBM aware RSVP nodes
+ will ignore the objects without forwarding them or generating an
+ error message.
+
+ Within the SBM specific codespace, note the following interpretation
+ of the third most significant bit of the Class-Num:
+
+ a) Objects of the form 100XXXXX are to be silently
+ discarded by SBM nodes that do not recognize them.
+
+ b) Objects of the form 101XXXXX are to be silently
+ forwarded by SBM nodes that do not recognize them.
+
+B.3.3. IEEE 802 Canonical Address Format
+
+ The 48-bit MAC Addresses used by IEEE 802 were originally defined in
+ terms of wire order transmission of bits in the source and
+ destination MAC address fields. The same wire order applied to both
+ Ethernet and Token Ring. Since the bit transmission order of Ethernet
+ and Token Ring data differ - Ethernet octets are transmitted least
+ significant bit first, Token Ring most significant first - the
+ numeric values naturally associated with the same address on
+ different 802 media differ. To facilitate the communication of
+ address values in higher layer protocols which might span both token
+ ring and Ethernet attached systems connected by bridges, it was
+ necessary to define one reference format - the so called canonical
+ format for these addresses. Formally the canonical format defines the
+ value of the address, separate from the encoding rules used for
+ transmission. It comprises a sequence of octets derived from the
+ original wire order transmission bit order as follows. The least
+ significant bit of the first octet is the first bit transmitted, the
+ next least significant bit the second bit, and so on to the most
+ significant bit of the first octet being the 8th bit transmitted; the
+ least significant bit of the second octet is the 9th bit transmitted,
+ and so on to the most significant bit of the sixth octet of the
+ canonical format being the last bit of the address transmitted.
+
+ This canonical format corresponds to the natural value of the address
+ octets for Ethernet. The actual transmission order or formal encoding
+ rules for addresses on media which do not transmit bit serially are
+ derived from the canonical format octet values.
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 49]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ This document requires that all L2 addresses used in conjunction with
+ the SBM protocol be encoded in the canonical format as a sequence of
+ 6 octets. In the following, we define the object formats for objects
+ that contain L2 addresses that are based on the canonical
+ representation.
+
+B.3.4. RSVP_HOP_L2 object
+
+ RSVP_HOP_L2 object uses object class = 161; it contains the L2
+ address of the previous hop L3 device in the IEEE Canonical address
+ format discussed above.
+
+ RSVP_HOP_L2 object: class = 161, C-Type represents the addressing
+ format used. In our case, C-Type=1 represents the IEEE Canonical
+ Address format.
+
+ 0 1 2 3
+ +---------------+---------------+---------------+----------------+
+ | Length | 161 |C-Type(addrtype)|
+ +---------------+---------------+---------------+----------------+
+ | Variable length Opaque data |
+ +---------------+---------------+---------------+----------------+
+
+ C-Type = 1 (IEEE Canonical Address format)
+
+ When C-Type=1, the object format is:
+
+ 0 1 2 3
+ +---------------+---------------+---------------+---------------+
+ | 12 | 161 | 1 |
+ +---------------+---------------+---------------+---------------+
+ | Octets 0-3 of the MAC address |
+ +---------------+---------------+---------------+---------------+
+ | Octets 4-5 of the MAC addr. | /// | /// |
+ +---------------+---------------+---------------+---------------+
+
+ /// -- unused (set to zero)
+
+B.3.5. LAN_NHOP object
+
+ LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address
+ object and LAN_NHOP_L2 address object.
+ <LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object>
+
+ LAN_NHOP_L2 address object uses object class = 162 and uses the same
+ format (but different class number) as the RSVP_HOP_L2 object. It
+ provides the L2 or MAC address of the next hop L3 device.
+
+
+
+
+Yavatkar, et al. Standards Track [Page 50]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ 0 1 2 3
+ +---------------+---------------+---------------+----------------+
+ | Length | 162 |C-Type(addrtype)|
+ +---------------+---------------+---------------+----------------+
+ | Variable length Opaque data |
+ +---------------+---------------+---------------+----------------+
+
+ C-Type = 1 (IEEE 802 Canonical Address Format as defined below) See
+ the RSVP_HOP_L2 address object for more details.
+
+ LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP
+ address of the next hop L3 device.
+
+ LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6
+ address family used.
+
+ IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1
+ +---------------+---------------+---------------+---------------+
+ | Length = 8 | 163 | 1 |
+ +---------------+---------------+---------------+---------------+
+ | IPv4 NHOP address |
+ +---------------------------------------------------------------+
+
+ IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2
+ +---------------+---------------+---------------+---------------+
+ | Length = 20 | 163 | 2 |
+ +---------------+---------------+---------------+---------------+
+ | IPv6 NHOP address (16 bytes) |
+ +---------------------------------------------------------------+
+
+B.3.6. LAN_LOOPBACK Object
+
+ The LAN_LOOPBACK object gives the IP address of the outgoing
+ interface for a PATH message and uses object class=164; both IPv4 and
+ IPv6 formats are specified.
+
+ IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1
+
+ 0 1 2 3
+ +---------------+---------------+---------------+---------------+
+ | Length | 164 | 1 |
+ +---------------+---------------+---------------+---------------+
+ | IPV4 address of an interface |
+ +---------------+---------------+---------------+---------------+
+
+
+
+
+
+
+
+Yavatkar, et al. Standards Track [Page 51]
+
+RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
+
+
+ IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2
+
+ +---------------+---------------+---------------+---------------+
+ | Length | 164 | 2 |
+ +---------------+---------------+---------------+---------------+
+ | |
+ + +
+ | |
+ + IPV6 address of an interface +
+ | |
+ + +
+ | |
+ +---------------+---------------+---------------+---------------+
+
+B.3.7. TCLASS Object
+
+ TCLASS object (traffic class based on IEEE 802.1p) uses object
+ class = 165.
+
+ 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Length | 165 | 1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | /// | /// | /// | /// | PV |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Only 3 bits in data contain the user_priority value (PV).
+
+B.4. RSVP PATH and PATH_TEAR Message Formats
+
+ As specified in the RSVP specification, a PATH and PATH_TEAR messages
+ contain the RSVP Common Header and the relevant RSVP objects.
+
+ For the RSVP Common Header, refer to the RSVP specification (RFC
+ 2205). Enhancements to an RSVP_PATH message include additional
+ objects as specified below.
+
+ <PATH Message> ::= <RSVP Common Header> [<INTEGRITY>]
+ <RSVP_HOP_L2> <LAN_NHOP>
+ <LAN_LOOPBACK> [<TCLASS>] <SESSION><RSVP_HOP>
+ <TIME_VALUES> [<POLICY DATA>] <sender descriptor>
+
+ <PATH_TEAR Message> ::= <RSVP Common Header> [<INTEGRITY>]
+ <LAN_LOOPBACK> <LAN_NHOP> <SESSION> <RSVP_HOP>
+ [<sender descriptor>]
+
+
+
+
+
+
+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]
+