diff options
Diffstat (limited to 'doc/rfc/rfc2814.txt')
| -rw-r--r-- | doc/rfc/rfc2814.txt | 3363 |
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] + |