RFC 2814
SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks
Part 1 of 14 🎀
RFC 2814 💖
Okay bestie, this one is RFC 2814, titled "SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks" ✨. It's from the Network Working Group, dated May 2000, and it's on the Standards Track 🌸. The authors are R. Yavatkar (Intel), D. Hoffman (Teledesic), Y. Bernet (Microsoft), F. Baker (Cisco), and M. Speer (Sun Microsystems) 👑. The title block doesn't list anything it obsoletes or updates, so there's no drama there 💅.
Status of this Memo ✨
This doc specifies an Internet standards track protocol for the Internet community, and it's basically asking for your thoughts and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. 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 🔥. It's designed to work with the current generation of IEEE 802 LANs and also with the recent work finished by the IEEE 802.1 committee 💅✨.
1. Introduction 🦋
Okay so, new extensions to the Internet architecture and service models have been defined for an integrated services Internet [RFC-1633, RFC-2205, RFC-2210] 😭. This lets applications ask for specific qualities or levels of service from an internetwork, not just the usual IP best-effort service 🍓. These extensions include RSVP, a resource reservation setup protocol, plus new service classes that Integrated Services routers are supposed to support 🌸. RSVP and the service class definitions are mostly independent of the underlying networking tech, so we need to define how RSVP and Integrated Services specifications map onto specific subnetwork technologies 🧠. For example, we need service mappings and reservation setup protocols for specific link-layer techs like shared and switched IEEE-802-style LANs 💜.
This document defines SBM, a signaling protocol for RSVP-based admission control over IEEE 802-style networks 🎀. SBM gives a way to map an internet-level setup protocol like RSVP onto IEEE 802 style networks 🔥. Specifically, it explains how RSVP-enabled hosts and routers, along with link layer devices (switches, bridges), work together to reserve LAN resources for RSVP-enabled data flows 💅. A framework for providing Integrated Services over shared and switched IEEE-802-style LAN techs, plus a definition of service mappings, lives in separate documents [RFC-FRAME, RFC-MAP] 📚✨.
2. Goals and Assumptions 👑
The SBM (Subnet Bandwidth Manager) protocol, and how it's used for admission control and bandwidth management in IEEE 802 level-2 networks, is built on the following architectural goals and assumptions 🌈:
I. Even though the trend is moving toward switched LAN topologies made of newer switches that support the priority queuing mechanisms in IEEE 802.1p, we assume LAN technologies will keep being a mix of legacy shared/switched LAN segments and newer switched segments based on the IEEE 802.1p spec 🧚. So we specify a signaling protocol for managing bandwidth over both legacy and newer LAN topologies, and it takes advantage of extra functionality (like explicit support for different traffic classes or integrated service classes) as it shows up in the next generation of switches, hubs, or bridges 💖. As a result, SBM can cover a whole range of LAN bandwidth management solutions 🦋. On one end, it's purely administrative control (over how much bandwidth RSVP-enabled traffic flows can consume). On the other end, it needs cooperation (and enforcement) from all the end-systems or switches in an IEEE 802 LAN 🔥.
II. This document only specifies a signaling method and protocol for LAN-based admission control over RSVP flows 💅. We don't define any traffic control mechanisms for the link layer here; the protocol is designed to use any such mechanisms that IEEE 802 defines 📚. We also assume Layer 3 end-systems (like a host or a router) will do traffic control by policing Integrated Services traffic flows, so each flow stays within the traffic specifications set in an earlier reservation request submitted for admission control 🫶. This lets a system combine SBM admission control, per-flow shaping at end systems, and IEEE-defined traffic control at the link layer to get some approximation of Controlled Load (and even Guaranteed) services over IEEE 802-style LANs 🌸✨.
III. Without any link-layer traffic control or priority queuing in the underlying LAN (like a shared LAN segment), the SBM-based admission control mechanism only limits the total amount of traffic load that RSVP-enabled flows put on a shared LAN 🙈. In that setup, there's no traffic flow separation to protect RSVP-enabled flows from best-effort traffic on the same shared media, which raises the question of whether this mechanism is useful outside a topology made only of 802.1p-compliant switches 😭. Still, we assume SBM-based admission control serves a useful purpose on a legacy, shared LAN topology, for two reasons 💜. First, if all the nodes generating Integrated Services traffic flows use the SBM-based admission control procedure to request resources before sending any traffic, the mechanism restricts the total traffic generated by Integrated Services flows to the bounds a LAN administrator wants (see the discussion of the NonResvSendLimit parameter in Appendix C) 👑. Second, best-effort traffic from TCP/IP-based sources is usually rate adaptive (using TCP-style "slow start" congestion avoidance 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 🦋. So the combo of admission control and rate adaptation should avoid persistent traffic congestion 🌈. That said, it does not guarantee that non-Integrated-Services traffic won't interfere with Integrated Services traffic when the underlying LAN infrastructure has no traffic control support 💀✨.
3. Organization of the rest of this document 🧚
The rest of this document digs into the SBM-based admission control procedure(s) for IEEE 802 LAN technologies 🎀. Here's how it's laid out 💅:
- Section 4 first defines the various terms used in the document, then gives an overview of the admission control procedure, with an example of applying it 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 🔥.
- Section 6 covers interoperability issues when a DSBM may operate without 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 DSBM election algorithm used to elect a designated SBM on a LAN segment when more than one SBM is present. It also explains how DSBM clients discover the presence of a DSBM on a managed segment 🦋.
- Appendix B specifies the formats of SBM-specific messages and the formats of new RSVP objects needed for SBM operation 💖.
- Appendix C describes how the DSBM is used to distribute configuration information to senders on a managed segment 💜.
4. Overview 🌸
Part 2 picks up right here, so stay tuned bestie 💅✨
4.1. Definitions 🎀
okay bestie, let's lock in the vocab first 📚 these terms are the whole foundation for the rest of the doc, so pls read carefully 💅
- Link Layer or Layer 2 or L2: this is the data-link layer stuff, like IEEE 802.3/Ethernet. we call it L2 or layer 2 🌸
- Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes and links connected together without going through an L3 forwarding function. one or more IP subnets can be overlaid on a L2 domain ✨
- Layer 2 or L2 devices: devices that only do Layer 2 stuff are called Layer 2 or L2 devices. 802.1D bridges or switches are examples 🦋
- Internetwork Layer or Layer 3 or L3: this is Layer 3 of the ISO 7 layer model 🧚 this doc is mainly about 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: an L2 physical segment that's shared by one or more senders. examples are (a) a shared Ethernet or Token-Ring wire that sorts out media access with CSMA or token passing ("shared L2 segment"), (b) a half duplex link between two stations or switches, and (c) one direction of a switched full-duplex link 🔥
- Managed segment: a segment with a DSBM present that's responsible for admission control over resource reservation requests. a managed segment includes those interconnected parts of a shared LAN that aren't separated by DSBMs 🫶
- Traffic Class: an aggregation of data flows that get similar service within a switched network 🌈
- User_priority: this is a value tied to sending and receiving all frames in the IEEE 802 service model. the sender using the MAC service supplies it, and it's handed to a receiver along with the data. it may or may not actually go over the network: Token-Ring/802.5 carries it (encoded in its FC octet), basic Ethernet/802.3 doesn't, and 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 full usage of user_priority is described in section 2.5 of 802.1D [IEEE8021D] and in 802.1p [IEEE8021P] "Support of the Internal Layer Service by Specific MAC Procedures" 📖💖
- Subnet: in this memo, this means a group of L3 devices sharing a common L3 network address prefix, along with the set of segments making up the L2 domain they're located in 🍓
- Bridge/Switch: a layer 2 forwarding device as defined by IEEE 802.1D. bridge and switch mean the same thing in this doc 🎀
- DSBM: a Designated SBM (DSBM) is a protocol entity that lives in an L2 or L3 device and manages resources on an L2 segment. at most one DSBM exists for each L2 segment 💅
- SBM: the SBM is a protocol entity that lives in an L2 or L3 device and can manage 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 them gets elected to be the DSBM 🦋
- Extended segment: this includes those parts of a network that are members of the same IP subnet, so they're not separated by any layer 3 devices. several managed segments interconnected by layer 2 devices make up an extended segment ✨
- Managed L2 domain: an L2 domain made of managed segments is called a managed L2 domain. this is to tell it apart from an L2 domain with no DSBMs around to do admission control over resources at its segments 🌸
- DSBM clients: entities that send traffic onto a managed segment and use the services of that segment's DSBM for admission control over a LAN segment. only the layer 3 or higher layer entities on L3 devices, like hosts and routers, are expected to send traffic that needs resource reservations, so DSBM clients are L3 entities 🧚
- SBM transparent devices: an "SBM transparent" device is unaware of SBMs or DSBMs (though it may or may not be RSVP aware). so it doesn't take part in the SBM-based admission control procedure over a managed segment. it uses the standard forwarding rules that suit the device and is transparent with respect to SBM. a legacy switch that doesn't take part in resource reservation is an example 💜
- Layer 3 and layer 2 addresses: we call the layer 3 addresses of L3/L2 devices "L3 addresses" and layer 2 addresses "L2 addresses". this convention is used for the rest of the document to tell apart the L3 and L2 addresses used to refer to RSVP next hop (NHOP) and previous hop (PHOP) devices. for example, in conventional RSVP message processing, the RSVP_HOP object in a PATH message carries the L3 address of the previous hop device. we'll call the address in the RSVP_HOP object the
RSVP_HOP_L3address, and the matching MAC address of the previous hop device theRSVP_HOP_L2address 👑🌈
4.2. Overview of the SBM-based Admission Control Procedure ✨
okay so this is the big picture 🔥 a protocol entity called "Designated SBM" (DSBM) exists for each managed segment, and it's in charge of admission control over the resource reservation requests coming from the DSBM clients on that segment 💖 given a segment, one or more SBMs may exist on it. for example, lots of SBM-capable devices might be attached to a shared L2 segment, while two SBM-capable switches might share a half-duplex switched segment. in that case, a single DSBM gets elected for the segment 🦋 the procedure for electing the DSBM dynamically is described in Appendix A. the only other approved way to specify a DSBM for a managed segment is static configuration at SBM-capable devices 🫶
the presence of a DSBM is what makes a segment a "managed segment" 🌸 sometimes two or more L2 segments are interconnected by SBM transparent devices. when that happens, a single DSBM manages the resources for all of those segments, treating the whole collection as one managed segment for admission control purposes 🧚💅
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 |
+------+ +-------+Okay so Figure 1 shows a managed segment in an L2 domain that connects a bunch of hosts and routers 🧚✨ For this chat, we're pretending the physical topology doesn't exist. Just imagine it's one shared L2 segment, and one managed segment covers the whole L2 domain 🫶 One SBM device gets picked to be the DSBM for that managed segment. We'll look at how the DSBM works over switched and shared segments later in the document, bestie 💅
The basic DSBM-based admission control procedure goes like this:
- DSBM Initialization: Okay, first things first 🌸 The DSBM gets info during its initial configuration, like the limits on what fraction of available resources can be reserved on each managed segment it controls. Bandwidth is one of those resources 💖 Methods like auto-negotiation of link speeds and knowing the link topology can help discover link capacity, but you may still need configuration to limit how much of a link's capacity can be reserved on it. Configuration will probably stay static with today's L2/L3 devices. Future work might allow dynamic discovery of this info. This document doesn't specify the configuration mechanism, so that's a whole other story 🙈
- DSBM Client Initialization: For each interface that's attached, a DSBM client figures out whether a DSBM exists on that interface. The procedure for discovering and verifying a DSBM on an attached segment is in Appendix A ✨ If the client is itself capable of serving as the DSBM on the segment, it may choose to join the election to become the DSBM 👑 At the start, a DSBM client first checks that a DSBM exists in its L2 domain, so it can talk to the DSBM for admission control purposes. Main character energy for sure 💅
On a full-duplex segment, an election might not be necessary, because the SBM at each end will typically act as the DSBM for outgoing traffic in each direction. Iconic, no notes 🦋
- DSBM-based Admission Control: To request a reservation of resources (for example, LAN bandwidth in an L2 domain), DSBM clients (RSVP-capable L3 devices like hosts and routers) follow these steps:
- a) When a DSBM client sends or forwards an RSVP PATH message over an interface attached to a managed segment, it sends the PATH message to the segment's DSBM instead of the RSVP session destination address (which is what happens in conventional RSVP processing). After processing the message (and possibly updating an ADSPEC), the DSBM forwards the PATH message toward its destination address. As part of this, the DSBM builds and maintains PATH state for the session and notes the previous L2/L3 hop that sent it the PATH message 📝
Let's look at the managed segment in Figure 1. Say a sender to an RSVP session (the session address is the IP address of host A on the managed segment in Figure 1) is outside the L2 domain of the managed segment, and it sends a PATH message that arrives at router R1, which is on the path toward host A 🌍 The DSBM client on router R1 forwards the PATH message from the sender to the DSBM. The DSBM processes it and forwards it toward the RSVP receiver. (The detailed message processing and forwarding rules are in Section 5.) Along the way, the DSBM builds the PATH state, remembers 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 (more on that 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 🧚
- b) When an application on host A wants to make a reservation for the RSVP session, host A follows the standard RSVP message processing rules and sends an RSVP RESV message to the previous hop L2/L3 address (the DSBM's address) taken from the PHOP object(s) in the PATH message it received earlier 💌
- c) The DSBM processes the RSVP RESV message based on the bandwidth available. If the request can't be granted, it sends a RESV_ERR message back to the requester (host A) 🙅♀️ If there are enough resources and the request is granted, the DSBM forwards the RESV message toward the PHOP(s) based on its local PATH state for the session. It merges reservation requests for the same session whenever it can, using rules similar to conventional RSVP processing (with one extra criterion, described in Section 5.8) 🫶
- d) If the L2 domain has more than one managed segment, the requester (host A) and the forwarder (router R1) might be separated by more than one managed segment. In that case, the original PATH message propagates through many DSBMs (one for each managed segment on the path from R1 to A), setting up PATH state at each DSBM. So the RESV message travels hop-by-hop in reverse through the intermediate DSBMs and eventually reaches the original forwarder (router R1) on the L2 domain, but only if admission control succeeds at all the DSBMs 🌈
4.2.2. Enhancements to the conventional RSVP operation
(D)SBMs and DSBM clients add a few minor extras to the standard RSVP protocol 🎀 They're summarized in this section, and the detailed message processing and forwarding rules come after, in section 5 💖
4.2.2.1 Sending PATH Messages to the DSBM on a Managed Segment
Normal RSVP forwarding rules still apply at a DSBM client when it's not forwarding an outgoing PATH message over a managed segment. But outgoing PATH messages on a managed segment get sent to the DSBM for that managed segment (Section 5.2 explains how PATH messages get sent to the DSBM on a managed segment) 🦋
4.2.2.2 The LAN_NHOP Objects
In conventional RSVP over point-to-point links, RSVP nodes (hosts and routers) use the RSVP_HOP object (NHOP and PHOP info) to keep track of the next hop (the downstream node on the path of data packets in a traffic flow) and the previous hop (the upstream nodes with respect to the data flow) between a sender and a receiver. Routers along the path of a PATH message forward it toward the destination address based on their L3 routing (packet forwarding) tables 🗺️
Let's use the L2 domain in Figure 1 as an example. Say both the sender (some host X) and the receiver (some host Y) in an RSVP session are outside the L2 domain shown in the figure, but PATH messages from the sender to the receiver pass through the routers in the L2 domain, using it as a transit subnet 🌸 The PATH message from sender X arrives at router R1. R1 uses its local routing info to decide which next hop router (either R2 or R3) to use to forward the PATH message toward host Y. But when the path goes through a managed L2 domain, we require the PATH and RESV messages to go through a DSBM for each managed segment. That L2 domain might span many managed segments (and DSBMs), and typically the SBM protocol entities on L2 devices (like switches) 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 info it needs to pick the egress router (between R2 and R3) before forwarding the PATH message. So, to make sure RSVP messages are routed correctly, we have to give the DSBMs some extra forwarding info 🙈
For this purpose, we introduce new RSVP objects called LAN_NHOP address objects. They keep track of the next L3 hop as the PATH message travels across an L2 domain between two L3 entities (the 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 a PATH message to the DSBM, it must include LAN_NHOP information in the message 🫶 For a unicast destination, the LAN_NHOP address is either the destination address (if the destination is local to its L2 domain) or the address of the next hop router toward the destination. Back to our example with sender X and receiver Y, where the L2 domain in Figure 1 is the transit subnet: R1 is the ingress node that receives the PATH message. R1 first works out that R2 is the next hop router (or the egress node in the L2 domain for the session address), then inserts a LAN_NHOP object that specifies R2's IP address 🧚 When a DSBM receives a PATH message, it can look at the address in the LAN_NHOP object and forward the PATH message toward the egress node after processing it. However, we expect the L2 devices (like switches) to act as DSBMs on the path within the L2 domain, and it may not be reasonable to expect them to have ARP capability to determine the MAC address (we call this the L2ADDR, for Layer 2 address) that corresponds to the IP address in the LAN_NHOP object 🙃
So we require that the LAN_NHOP information (generated by the L3 device) include both the IP address (the LAN_NHOP_L3 address) and the corresponding MAC address (the 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 toward its destination. The L2 address is used by SBM protocol entities on L2 devices to work out how to forward the PATH message toward the L3 NHOP (the egress point from the L2 domain). The exact format of the LAN_NHOP information and related objects is described later, in Appendix B 🌈
4.2.2.4 Similarities to Standard RSVP Message Processing ✨
- Okay bestie, when a DSBM gets an RSVP PATH message, it handles that message using the PATH processing rules from the RSVP spec 💅 It grabs the IP address of the previous hop from the RSVP_HOP object and stores that PHOP address in its PATH state. Then it forwards the PATH message with the PHOP (RSVP_HOP) object updated to show its own IP address (RSVP_HOP_L3 address). So the DSBM literally slides itself in as an intermediate hop between two L3 nodes across the L2 domain 🦋
- The PATH state in a DSBM is what it uses to forward RESV messages later, following the usual RSVP message processing rules 🫶 When a DSBM gets a RESV message, it processes it and forwards it to the right PHOP(s) based on that PATH state.
- Because a DSBM sits between two RSVP nodes on an RSVP flow's path, every RSVP message (PATH, PATH_TEAR, RESV, RESV_CONF, RESV_TEAR, and RESV_ERR) now flows through the DSBM 🌸 A PATH_TEAR message goes through the same intermediate DSBM(s) as its matching PATH message did, and the local PATH state gets cleaned up at each intermediate hop before the PATH_TEAR is forwarded. Main character energy for the DSBM, fr 👑
- So far we've covered how a PATH message moves through the L2 domain, setting up PATH state at each DSBM along the managed segments. Now the layer 2 address (LAN_NHOP_L2 address) in the LAN_NHOP object should be used by the L2 devices on the path to decide where to forward the PATH message next toward the next L3 hop 🧚 Those devices apply the standard IEEE 802.1D forwarding rules to that address, the same way they would for any data packet headed there. That means sending it out a single port based on the filtering database, or flooding it out all ports active in the spanning tree if the L2 address isn't in the filtering database 💖
4.2.2.5 Including Both Layer-2 and Layer-3 Addresses in the RSVP_HOP Objects ✨
In regular RSVP message processing, the PATH state set up along the nodes of a path is what routes a RESV message from a receiver back to a sender in an RSVP session 🎀 Each intermediate node remembers the previous hop (the PHOP IP address from the RSVP_HOP object of an incoming message) that sent it the PATH message. When the RESV message shows up, the node just uses that stored PHOP address to forward the RESV, as long as it processed the RESV successfully.
Here's the twist. We expect the SBM entities on L2 devices to act as DSBMs (and so as intermediate RSVP hops inside an L2 domain) along the path between a sender (PHOP) and a receiver (NHOP) 🔥 So when a RESV message reaches a DSBM, it must use the stored PHOP IP address to forward the RESV to its previous hop. But it may not be reasonable to expect L2 devices to have an ARP cache, or the ARP capability, to map the PHOP IP address to its matching L2 address before forwarding the RESV. Not every switch is doing that, bestie 🙈
To skip that address mapping at L2 devices, we add an RSVP_HOP_L2 object to the PATH message. The RSVP_HOP_L2 object carries the Layer 2 address (L2ADDR) of the previous hop, and it works alongside the L3 address info in the RSVP_HOP object (RSVP_HOP_L3 address) 🦋
When an L3 device builds and forwards a PATH message over a managed segment, it puts its IP address (the IP address of the interface the PATH goes out on) in the RSVP_HOP object. It also adds an RSVP_HOP_L2 object with the matching L2 address for that interface. When a device in the L2 domain gets a PATH message like this, it remembers the addresses in the RSVP_HOP and RSVP_HOP_L2 objects in its PATH state. Then it overwrites both 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 the RSVP_HOP_L2 object is specified in Appendix B. Go check it out 💅
4.2.2.6 Loop Detection ✨
Okay so this one is kind of a drama 😭 When an RSVP session address is a multicast address, and an SBM, DSBM, and DSBM clients all share the same L2 segment (a shared segment), it's possible for an SBM or DSBM client to get one or more copies of a PATH message it forwarded earlier, when a DSBM on the same wire forwards it back (see Section 5.7 for an example of this). To catch these loops, we use a new RSVP object called the LAN_LOOPBACK object 🔁
DSBM clients or SBMs (but not the DSBMs reflecting a PATH message back onto the interface it arrived on earlier) must overwrite the LAN_LOOPBACK object in the PATH message with their own unicast IP address. If the PATH message does NOT already include a LAN_LOOPBACK object, they add one instead. ✨
Now an SBM or a DSBM client can easily spot and toss out duplicates by checking the LAN_LOOPBACK object's contents. A duplicate PATH message will list the device's own interface address in there, so it's giving "I've seen this before" energy 💀 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 that traffic flows be isolated from each other while they transit a network 💜 The point of flow separation is to protect Integrated Services flows from misbehaving flows and from best-effort traffic sharing the same path. Basic IEEE 802.3/Ethernet networks don't have any notion of traffic classes for telling apart flows that request different services. IEEE 802.1p does give switches a way to tell apart 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 (for example, in IEEE 802.5's FC octet), or by using an encapsulation above the MAC layer. For Ethernet, the user_priority value for each packet is 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 the network should use the user_priority values. An accompanying document does make recommendations on how to use them (see [RFC-MAP] for details) 🌸
Under the Integrated Services model, L3 (or higher) entities that send traffic flows onto an L2 segment should perform per-flow policing, so the flows don't exceed the traffic specification agreed during admission control 🎀 On top of that, L3 devices may label the frames in those flows with a user_priority value to mark their service class ✨
For this discussion, we'll call the user_priority value carried in the extended frame header the "traffic class" of a packet. Under the ISSLL model, the L3 entities that send traffic and use the SBM protocol may select the appropriate traffic class for outgoing packets [RFC-MAP]. That selection can be overridden by DSBM devices, like this 🧚 Once a sender sends a PATH message, downstream DSBMs insert a new traffic class object (TCLASS object) into the PATH message that travels on to the next L3 device (the L3 NHOP for the PATH message). In some ways, the TCLASS object contents get treated like the ADSPEC object in RSVP PATH messages 💖 The L3 device that receives the PATH message must remove the TCLASS object and store it as part of its PATH state for the session. Later, when that same L3 device needs to forward an RSVP RESV message toward 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 own selection for the traffic class marked in outgoing packets. Iconic override moment 👑
The format of the TCLASS object is specified in Appendix B. Note that TCLASS and other SBM-specific objects are carried in an RSVP message alongside all the other normal RSVP objects per RFC 2205 🫶
4.2.2.8 Processing the TCLASS Object ✨
Okay so, quick recap bestie 💅: using TCLASS objects means a few extra moves in the normal RSVP message processing at DSBMs, SBMs, and DSBM clients 🫶
- When a DSBM gets a PATH message over a managed segment and that PATH message has no TCLASS object, the DSBM MAY add one before forwarding it 🦋 The DSBM works out the right user_priority value for the TCLASS object, and a way to pick that value is described in an accompanying document [RFC-MAP] 📚
- When an SBM or DSBM gets a PATH message with a TCLASS object over a managed segment in an L2 domain, and needs to forward it over a managed segment in that same L2 domain, it stores the TCLASS in its path state and usually forwards the message without changing the TCLASS contents 🌸 BUT, if the DSBM/SBM can't support the service class that the user_priority value in the TCLASS object stands for, it may change the priority value to a semantically "lower" service value that matches what it can actually do 💀 It then stores the changed TCLASS value in its path state 🧚
[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 gets a RESV message with a TCLASS object, it may use the traffic class information (on top of the usual flowspec information in the RSVP message) for its own admission control on the managed segment 👑
Also, this document doesn't spell out the actual algorithm or policy for admission control 🙈 At one extreme, a DSBM may use per-flow reservation requests as specified by the flowspec, for super fine-grained admission control ✨ At the other extreme, a DSBM may only look at the traffic class information for a very coarse-grained 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) gets a RESV message without a TCLASS object, and needs to forward the RESV message over a managed segment in the same L2 domain, it should first check its path state to see whether it has stored a TCLASS value 🔍 If so, it should include the TCLASS object in the outgoing RESV message after doing 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 (living at an L3 device such as a host or an edge router) gets 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 that interface 🧸 Later, when the client forwards a RESV message for the same session on that interface, the client must include the TCLASS object (unchanged from what it 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 on the outgoing interface over that managed segment, the client must pass the user_priority value in the TCLASS object to its local packet classifier 🔥 This makes sure the data packets in the admitted RSVP flow that get forwarded over the outgoing interface carry the right value encoded in their frame header 🫧
- When an L3 device gets a PATH or RESV message over a managed segment in one L2 domain, and needs to forward the PATH/RESV message over an interface outside that domain, the L3 device must remove the TCLASS object before forwarding (and, in the case of a PATH message, also remove the LAN_NHOP, RSVP_HOP_L2, and LAN_LOOPBACK objects) 🚫 If the outgoing interface is on a separate L2 domain, these objects may be regenerated according to the processing rules that apply 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 an L2 domain is an example of such a device. A device that has several interfaces may contain an SBM protocol entity that acts in different capacities on each interface 🎭 For example, an SBM protocol entity could act as an SBM on interface A, and act as a DSBM on interface B 🦋
- An 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 💜
- An SBM protocol entity residing at a layer 2 device can be an 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 an 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 an 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 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 💫
To make dynamic DSBM-client binding happen, and 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 communicating with a DSBM 🫶 In particular, we require that when a DSBM client or an SBM forwards a PATH message over a managed segment, it is addressed to a reserved IP multicast address 🎯 So a DSBM on an L2 device needs to be configured in a way that makes 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, so the PATH messages get intercepted and aren't forwarded further without the DSBM stepping in 🔒
Similarly, a DSBM always sends the PATH messages over a managed segment using a reserved IP multicast address 📣 So 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, so they can 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 the 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 that are SBM transparent.
- They are configured in the permanent database of layer 2 devices that host SBMs or DSBMs, so they are directed to the SBM management entity in these devices. This means these devices don't need to explicitly snoop for SBM-related control packets 🙌
- The two reserved addresses are
224.0.0.16(DSBMLogicalAddress) and224.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
* 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
addressThe 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 an L3 device must include an LAN_NHOP_L2 address in the LAN_NHOP information, so that L2 devices along the path of a PATH message don't need to separately work out 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 this mapping at L3 devices, we assume a mapping function called "map_address" that does the necessary mapping 🧩
L2ADDR object = map_addr(L3Addr)We don't specify how the function is implemented 🤷♀️ The implementation may simply involve accessing the local ARP cache entry, or it may require performing an ARP function. The function returns an L2ADDR object that doesn't need to 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 an L2 domain 🙌 So when an SBM protocol entity on an L3 device forwards an RSVP message onto an L2 segment, it will only use RAW IP encapsulation 💅
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 +------+ +------+Wait, I can't fake that. Here is the actual figure:
| 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
.................Okay so Figure 2 is giving network map energy 🗺️✨. It shows three IP subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) linked together by two routers. The subnet 2.0.0.0 is an L2 domain made of switches, hosts, and routers connected over switched segments and a shared L2 segment 🫶. Here's the cast of devices:
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) SBMBestie, these are the rules every device should use to forward PATH messages 💖, and yes, PATH_TEAR messages follow them too 💅. The examples are described in the context of that general network up there. They don't cover every single scenario, but they cover most of the spicy ones 🔥. Any exceptions can be talked about separately 🌸.
The forwarding rules get applied to received PATH messages (routers and switches) or to originating PATH messages (hosts), like this:
- Determine the interface(s) on which to forward the PATH message using standard forwarding rules:
- If there is a
LAN_LOOPBACKobject 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_L2address in theLAN_NHOPinformation 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").
- If there is a
- 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_DSBMmessages. If the interface is not on a managed segment, strip outRSVP_HOP_L2,LAN_NHOP,LAN_LOOPBACK, andTCLASSobjects (if present), and forward to the unicast or multicast destination. - 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.
- 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
- Forward the PATH message onto the managed segment:
- If the device is a layer 3 device, insert
LAN_NHOPaddress objects, aLAN_LOOPBACK, and aRSVP_HOP_L2object into the PATH message. TheLAN_NHOPobjects carry theLAN_NHOP_L3andLAN_NHOP_L2addresses of the next layer 3 hop. TheRSVP_HOP_L2object carries the device's own L2 address, and theLAN_LOOPBACKobject contains the IP address of the outgoing interface. An L3 device should use themap_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
HOPobject 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 theRSVP_HOP_L2object; 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
HOPobject and the L2 address of the forwarding interface into theRSVP_HOP_L2object. - If the PATH message received does not contain the
TCLASSobject, insert aTCLASSobject. Theuser_priorityvalue inserted in theTCLASSobject 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 theTCLASSobject, theuser_priorityvalue may be changed based again on the service mappings internal to the device.
- Retrieve the PHOP information from the standard RSVP
- 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
HOPobject and theRSVP_HOP_L2objects in the PATH message intact and it will not receive RESV messages. If the SBM on a L2 device chooses to overwrite the RSVPHOPandRSVP_HOP_L2objects 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 standardRSVP_HOPfield andRSVP_HOP_L2objects of the incident PATH message. In both the cases mentioned above (L2 or L3 devices), the SBM must forward theTCLASSobject in the received PATH message unchanged. - Copy the IP address of the forwarding interface into the
LAN_LOOPBACKobject, 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.
- If the device is a layer 3 device, insert
5.5.1. Additional notes on forwarding a PATH message onto a managed segment
Rule #1 says normal IEEE 802.1D forwarding rules should be used to figure out which interfaces the PATH message goes out on 🧭. For regular data packets, the standard rules at a L2 device say the packet shouldn't go back out the interface it came in on. But when a DSBM gets a PATH message over a managed segment, there's a special exception 👑:
- E1. If the address in the
LAN_NHOPobject 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_NHOPobject), 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's possible for a DSBM to reflect a PATH message back onto the interface it came in on, we have to be careful so these messages don't loop forever 🌀. The LAN_LOOPBACK object handles this. 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 that are reflecting a PATH message leave the LAN_LOOPBACK object unchanged. So SBM protocol entities can always spot a reflected multicast message by finding their own address in the LAN_LOOPBACK object. These messages should be silently discarded. 💀
5.6. Applying the Rules -- Unicast Session ✨
okay so let's see how these rules actually play out on the network from earlier (see Figure 2) 🦋 we're following a unicast session where H1 is sending, and H5 is the receiver 💌
H1 starts by composing a PATH message like this:
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
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 isn't sending onto a managed segment, it just composes and forwards the PATH message using the standard RSVP processing rules 💅
When R1 gets that PATH message, it composes and forwards a new one like this 👑
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 addressHere's what R1 does to get there:
- R1 does a routing lookup on the RSVP session address to figure out the IP address of the next layer 3 hop, which is R2 🧚
- It finds out that R2 is reachable via seg A, and that seg A is managed by a DSBM, S1 👀
- So R1 knows it's sending onto a managed segment, and it builds LAN_NHOP objects to carry both the layer 3 and layer 2 next hop addresses. To fill in the LAN_NHOP L2ADDR object, it calls the L3 to L2 address mapping function ("map_address") to get the MAC address of the next hop L3 device, then drops a LAN_NHOP_L2ADDR object (carrying that MAC address) into the message 🌸
- Since R1 is not the DSBM for seg A, it sends the PATH message to the DSBMLogicalAddress 🫶
When S1 gets the PATH message, it composes and forwards this one 🎀
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's moves here are:
- S1 checks the LAN_NHOP address info to figure out which L2 address the PATH message should head toward 🔍
- From the bridge forwarding tables, it sees that this L2 address is reachable via seg B 🌈
- S1 adds 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 💖
When S3 gets the PATH message, it composes and forwards this one 🦋
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 addressS3 does this:
- S3 checks the LAN_NHOP address info to figure out which L2 address the PATH message should go toward 🔎
- From the bridge forwarding tables, it finds that this L2 address is reachable via segment F ✨
- It has discovered that R2 is the DSBM for segment F, so it sends the PATH message to the DSBMLogicalAddress 💅
- Here's a fun bit: S3 may or may not choose to overwrite the PHOP objects with its own IP and L2 addresses. If it does, 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 🧠
When R2 gets the PATH message, it composes and forwards this one 🌟
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)
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 hopAnd R2 wraps it up like this:
- R2 does a routing lookup on the RSVP session address to find the IP address of the next layer 3 hop, which is H5 🏁
- It sees that H5 is reachable via a segment with no DSBM (so it's not a managed segment) 🌷
- So R2 removes the LAN_NHOP and RSVP_HOP_L2 objects, puts the RSVP session address in the destination address of the IP header, puts the L2 address of the next layer 3 hop in the destination address of the MAC header, and forwards the PATH message to H5 🎉
5.7. Applying the Rules - Multicast Session 🌈
the rules we just covered also apply to multicast (m/c) sessions 🫧 for this part, we're assuming that layer 2 devices track multicast group membership on each port individually. L2 devices that don't do that will just generate extra multicast traffic. That's the case for L2 devices that don't implement multicast filtering or GARP/GMRP capability 🙈
Now let's say H1 is sending a PATH for an m/c session where H3 and H5 are the receivers 💜 the rules work just like the unicast case until the PATH message reaches R2, with one exception: the RSVP session address and the LAN_NHOP carry the destination m/c addresses instead of the unicast addresses from the unicast example 🦋
Next up is how R2 processes the PATH message once it arrives. Remember that R2 is the DSBM for segment F. So S3 forwarded its PATH message to the DSBMLogicalAddress, so that R2 would pick it up 🎀 H3 (one of the m/c receivers) never sees that PATH message, because it only monitors the AllSBMAddress, not the DSBMLogicalAddress, for incoming PATH messages 🙃 so we rely on R2 to reflect the PATH message back onto seg f, and to forward it to H5. R2 sends this PATH message onto seg f:
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 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 gets the PATH message that R2 reflected 🥳 Heads up, though: R2 broke the standard forwarding rules here by sending an incoming message back out the interface it came in on. To avoid loops, it left S3's address in the LAN_LOOPBACK object unchanged 🔁
R2 then forwards this 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 sees that there's an m/c receiver reachable via a segment with no DSBM. So it removes the LAN_NHOP and RSVP_HOP_L2 objects, puts the RSVP session address in the destination address of the IP header, puts the corresponding L2 address in the destination address of the MAC header, and multicasts the message toward H5 🌸
5.8. Merging Traffic Class objects 🎀
Okay bestie, so picture this. A DSBM client gets TCLASS objects from different senders, meaning different PATH messages, all in the same RSVP session. Now it needs to squish them together into one RESV message, like in a wild-card style reservation. That client must choose a value that matches the desired-delay traffic class. There's an accompanying document with guidelines for picking a traffic class based on the desired service and the TSpec information [RFC-MAP]. Go read that one, it's giving useful 📚✨
Next up, when an SBM or DSBM merges RESVs coming from different next hops at a merge point, it has to decide what to do with the TCLASS values in those incoming RESVs if they don't match 😭. Let's say a reservation is already set up for a flow at a DSBM (or an SBM), and admission control already passed for the TCLASS requested in the first RESV for that flow. Now another RESV shows up for the same flow. It's not just a refresh of the one that was already admitted, so it's a new one 👀. The DSBM must first check the TCLASS value in the new RESV against the TCLASS value in the RESV that's already installed. If the two values are the same, the RESV requests get merged, and the new merged RESV gets installed and forwarded using the normal message processing rules, no drama 💖. But if the two values are not identical, the DSBM must generate and send a RESV_ERR message back toward the sender (NHOP) of the newer RESV message. That RESV_ERR has to carry the error code for the RSVP "traffic control error" (RESV_ERR code 21), which means it failed to merge two incompatible service requests (sub-code 01 for the RSVP traffic control error) [RFC-2205]. The RESV_ERR message may also include extra objects to help downstream nodes recover from this situation. Defining and using those objects is beyond the scope of this memo, so it's not our problem today 🙈
5.9. Operation of SBM Transparent Devices 🦋
SBM transparent devices don't know anything about the whole SBM/DSBM protocol, they're totally unaware bestie 🫠. They don't intercept messages sent to either of the SBM-related local group addresses (the DSBMLogicalAddrss and the ALLSBMAddress). They just pass those messages through. Because of that, they don't split up the DSBM election scope, they don't explicitly take part in routing PATH or RESV messages, and they don't join admission control. They're completely transparent when it comes to SBM operation 🫶
Now, according to the definitions in this doc, physical segments connected by SBM transparent devices count as one single managed segment. So DSBMs must do admission control on those managed segments, even though they only know a little bit about the segment's topology 🥺. In this situation, the network administrator should configure the DSBM for each managed segment, using a reasonable estimate 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 it for the highest capacity route through the managed segment. Realistically, a network administrator will probably pick something in between, depending on how much guarantee they need and what traffic patterns they expect 💅
This document doesn't specify the configuration mechanism or which policy you should choose. That's on you, not us 💜
5.10. Operation of SBMs Which are NOT DSBMs 🌸
Okay, so in the example, S3 hosts an SBM, but that SBM didn't win the election to be DSBM on any segment. You might be wondering what the point of an SBM protocol entity like that is, and honestly, it's a fair question 🤔. But these SBMs actually do two really useful things. First, they stay 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 if the current DSBM fails or stops being operational for some reason, they step in and elect a new DSBM 🦸♀️. Second, they divide the election scope, which shrinks the size and complexity of managed segments. Take the sample topology in Figure 3 again. The device S3 has an SBM that isn't the DSBM for any of the segments attached to it, which are B, E, or F. But if the SBM protocol entity on S3 weren't there, segments B and F wouldn't be separate segments from the SBM protocol's point of view. They'd form one single managed segment, run by a single DSBM 😱. Because the SBM entity on S3 splits the election scope, seg B and seg F each get their own separate DSBM. Each of those segments has a trivial topology and a well-defined capacity, so their DSBMs don't have to do admission control based on approximations (which is what would happen if S3 were SBM transparent) ✨
Also, SBM protocol entities that aren't DSBMs are not required to overwrite the PHOP in incident PATH messages with their own address. The reason is that RESV messages don't need to be routed through these devices in the first place. RESV messages only need to go through the correct sequence of DSBMs, so the rest is just extra work we don't need 🙅♀️. SBMs also may not process RESV messages that pass through them. They can only forward those messages toward their destination address, using the standard forwarding rules, and that's it 💅
On the other hand, SBM protocol entities that aren't DSBMs are required to overwrite the address in the LAN_LOOPBACK object with their own address, so multicast messages don't end up looping forever 🌀. The good news is that no state needs to be stored for this, so it's lowkey pretty chill 🧚
6. Inter-Operability Considerations 🍓
Let's talk about the interoperability drama 🎭. There are a few interesting issues that pop up when you deploy a DSBM-based admission control method in a network that has nodes with and without RSVP capability. Below, we list some of these scenarios and explain how SBM-aware clients and nodes can handle each one. Let's get into it!
6.1. An L2 domain with no RSVP capability. 🌈
It's totally possible to imagine L2 domains that don't use RSVP signaling to request resource reservations. Instead, they might use some other mechanism, like SNMP or static configuration, to reserve bandwidth at a particular network device, such as a router. So the question is: how does a DSBM-based admission control method work, and how does it play with that non-RSVP mechanism? The SBM-based method doesn't even try to offer an admission control solution for that kind of environment. The SBM-based approach is just one piece of an end-to-end signaling approach for setting up resource reservations, and it doesn't try to solve the SNMP-based configuration scenario 🙈
That said, as we mentioned earlier, the SBM-based approach can co-exist with any other non-RSVP bandwidth allocation mechanism, as long as the resources being reserved are either split up statically between the different mechanisms or are resolved dynamically through a common bandwidth allocator. That way, there's no over-commitment of the same resource 💖
6.2. An L2 domain with SBM-transparent L2 Devices. 🦋
We already covered this scenario earlier in the document, so it's not new tea 🍵. The SBM-based method is designed to work in this kind of environment. When SBM-transparent L2 devices connect SBM-aware devices, the resulting managed segment is a combination of one or more physical segments. Just a heads up, the DSBM for that managed segment might not be as efficient at allocating resources as it would be if all the L2 devices were SBM-aware 📉
6.3. An L2 domain on which some RSVP-based senders are not DSBM clients. 🚨
Here's the big rule, babe: all senders that send RSVP-based traffic flows onto a managed segment MUST be SBM-aware and take part in the SBM protocol 🔥. Using the standard, non-SBM version of RSVP can lead to over-allocation of resources, because that bypasses the DSBM's resource management function, and that's a whole mess 💀. All other senders (that is, senders not sending streams subject to RSVP admission control) should be elastic applications that send traffic at a lower priority than the RSVP traffic, and they should use TCP-like congestion avoidance mechanisms 🫶.
Also, all DSBMs, SBMs, or DSBM clients on a managed segment (meaning a segment with a currently active DSBM) must not accept PATH messages from senders that aren't SBM-aware. The good news is that these PATH messages are easy to spot. SBMs and DSBM clients can detect them because they wouldn't be multicast to the ALLSBMAddress (for SBMs and DSBM clients), or to the DSBMLogicalAddress (for DSBMs) 🕵️♀️✨
6.4. A non-SBM router that interconnects two DSBM-managed L2 domains. 🧚
Multicast SBM messages, like election and PATH messages, have local scope and aren't meant to pass between the two domains. A correctly configured non-SBM router won't pass those messages between the domains, so you're good 👑. But a broken router implementation that does pass them along can cause the SBM protocol to operate incorrectly, which then leads to over- or under-allocation of resources. Not it 😤
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 get forwarded onto an L2 domain. RFC-2205 (the RSVP Proposed Standard) supports both raw IP and UDP encapsulation. So an RSVP node that only uses UDP encapsulation won't be able to interoperate with the DSBM, unless the DSBM accepts and supports UDP-encapsulated RSVP messages 🥲
7. Guidelines for Implementers 💅
Here's where we get to the implementer tips! In this section, we give implementers guidelines on different parts of the SBM-based admission control procedure, including some suggestions for DSBM initialization, and more 🎀.
7.1. DSBM Initialization 🌸
As we said earlier, DSBM initialization includes configuring the maximum bandwidth that can be reserved on the managed segment under its control. Here's the guideline we suggest 💖.
In a managed segment made up of L2 devices that are interconnected by a single shared segment, DSBM entities on those devices should assume the bandwidth of the interface as the total link bandwidth. If a DSBM is located in an L2 switch, it might also need to be configured with an estimate of the device's switching capacity, but only if that's less than the link bandwidth. It might also need some estimate of the switch's buffering resources (see [RFC-FRAME] for the architectural model assumed for L2 switches) 🧠. Once you know the total link bandwidth, the DSBM may be further configured to limit the maximum amount of bandwidth for RSVP-enabled flows. That way, there's always spare capacity left over for best-effort traffic, and everyone's happy 🫶✨
7.2. Operation of DSBMs in Different L2 Topologies 🫧
Okay so, depending on the L2 topology, a DSBM might be asked to manage resources for one or more segments, and implementers need to keep the efficiency implications of using a DSBM in different L2 topologies in mind 👀. Trivial L2 topologies are just a single "physical segment" 🧸. In that case the 'managed segment' is basically the same thing as a single segment. Complex L2 topologies can be a bunch of segments, but admission control on such an L2 extended segment can be done from a single pool of resources, like a single shared segment, from the point of view of one DSBM 💅.
This setup kinda compromises how efficiently the DSBM can allocate resources, and it's giving bottleneck vibes 😭. The single DSBM has to make admission control decisions for every reservation request within the L2 topology, and it has no idea which physical segments a reservation actually touches 🙈.
We can level up the efficiency of resource allocation by splitting the complex segment into a bunch of managed segments, each run by its own DSBM 🦋. Now each DSBM is managing a managed segment with a relatively simple topology ✨. Since managed segments are simpler, the DSBM can be given a more accurate estimate of the resources available for all reservations in its managed segment. In the ultimate configuration, every physical segment is a managed segment with its own DSBM 👑. The spec doesn't assume any particular number of managed segments. It just says, plainly, that in complex L2 topologies, resource allocation efficiency improves as the granularity of managed segments increases 🌈.
8. Security Considerations 🔐
The message formatting and usage rules described in this note raise security issues, the exact same ones that come up with RSVP and Integrated Services 😳. It is necessary to control and authenticate access to the 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. An 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. This part is lowkey the most important bit, so don't skip it, bestie 🚨.
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.
[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.A.1. Introduction 🧁
Okay, so to keep the rest of this discussion simple, we're going to assume there's a single DSBM for the entire L2 domain. In other words, we assume a shared L2 segment for the whole L2 domain 🫶. We'll get to how a DSBM is elected for a half-duplex or full-duplex switched segment later, promise 💖.
To allow for quick recovery when a DSBM fails, we assume that additional SBMs may be active in an L2 domain for fault tolerance 🛟. When more than one SBM is active in an L2 domain, the SBMs use an election algorithm to pick a DSBM for the L2 domain 🗳️. Once the DSBM is elected and operational, the other SBMs just chill in the background, ready to step in and elect a new DSBM when necessary 😌. The protocol for electing and discovering the DSBM is called the "DSBM election protocol", and it's 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 say "hey, I'm here" 📣. The message is sent every period (e.g., every 5 seconds) according to the RefreshInterval timer value, which is a configuration parameter 🕰️. If a DSBM client doesn't see that message for a certain time interval (called DSBMDeadInterval, another configuration parameter, typically set to a multiple of RefreshInterval), it means the DSBM has failed or terminated 💀. That triggers another round of the DSBM election. DSBM clients always listen for the 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 that a DSBM has failed, it waits for a subsequent I_AM_DSBM advertisement before resuming any communication with the DSBM 🙌. While there's no DSBM around, 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 an SBM first starts up, it listens for incoming DSBM advertisements for some period, just 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 is actually necessary 🤫. All messages related to the DSBM election and the DSBM advertisements are always sent to the AllSBMAddress 📮.
If there's no DSBM, the SBM starts the election by sending out a DSBM_WILLING message. That message lists its IP address as a candidate DSBM and its "SBM priority" 🙋♀️. Each SBM gets a priority to determine its relative precedence. When more than one SBM candidate exists, the SBM priority decides who gets to be the DSBM, based on the relative priority of the candidates 👑. If there's a tie on the priority value, the tie is broken using the IP addresses of the tied candidates (the one with the higher IP address in 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, an SBM is in one of four states: Idle, DetectDSBM, ElectDSBM, or IAMDSBM 🎀.
An 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 shows up during this state, the SBM notes the current DSBM (its IP address and priority) and enters the Idle state ✅. If a DSBM_WILLING message comes in from another SBM (call it Y) during this state, then X enters the ElectDSBM state. Before it does, X checks whether it's itself a better candidate than Y. If so, X sends out a DSBM_WILLING message and then enters the ElectDSBM state 💪.
When an SBM (call it X) enters the ElectDSBM state, it sets a timer (called ElectionIntervalTimer, typically set to a value at least equal to the DSBMDeadInterval value) to wait for the election to finish and to discover who the best candidate is ⏳. 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) criteria 🔄. 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 it is, X declares itself 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 keeps waiting for another round of the election (each round lasts for an ElectionTimerInterval duration) 🔁.
An SBM is in the Idle state when no election is in progress and the DSBM has already been elected (and it 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 the DSBM ⏱️. Every time an advertisement is received, the timer restarts. If the timer fires, the SBM goes into the DetectDSBM state to prepare to elect a new DSBM 🚨. If an SBM receives a DSBM_WILLING message from the current DSBM while in this state, it 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 wants to shut down (gracefully terminate), it sends out a DSBM_WILLING message with the SBM priority value set to zero to kick off the election procedure 👋. A priority value of 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 (the 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 then the DSBM is operational 🥳.
A.4. DSBM Advertisements ✨
Okay so the I_AM_DSBM advertisement is packed with four things 🎀
- DSBM address information 💅 This has the IP and L2 addresses of the DSBM, plus its SBM priority. The priority is a configuration parameter that a network administrator sets. The election algorithm uses it to pick among candidate SBMs. Higher integer values mean higher priority, and the value lives in the range 0..255. A value of zero means the SBM is not eligible to be the DSBM. The IP address is required and gets used for breaking ties. The L2 address belongs to the interface on the managed segment.
RegreshInterval🦋 This carries the value of RefreshInterval, in seconds. A value of zero means the parameter was left out of the message. In that case, receivers may swap in their own default value.DSBMDeadInterval🧚 This carries the value of DSBMDeadInterval, in seconds. If it's omitted (or set to zero), a default value from the initial configuration should be used.- Miscellaneous configuration info that gets advertised to senders on the managed segment. Check Appendix C for the full details ✨
A.5. DSBM_WILLING Messages 🌸
When an SBM wants to declare its candidacy to be the DSBM during an election phase, it sends out a DSBM_WILLING message. Here's what's inside it:
- DSBM address information 💖 This has the SBM's own addresses (IP and L2) if it wants 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. The DSBM address information also includes the matching priority of the SBM whose address is listed above.
A.6. SBM State Variables 🍓
For each network interface, an SBM keeps track of some state variables for electing the DSBM on that L2 domain. These are the big ones 👑
a) LocalDSBMAddrInfo is the current DSBM's IP address (starts out as 0.0.0.0) and priority. All IP addresses are assumed to be in network byte order. The current DSBM's L2 address is stored here too, as part of this state info.
b) OwnAddrInfo is the SBM's own IP address and L2 address for the interface, plus its own priority (a configuration parameter).
c) RefreshInterval, in seconds. While the DSBM isn't elected yet, it's set to a default value from a configuration parameter.
d) DSBMDeadInterval, in seconds. While the DSBM isn't elected yet, it starts out at a default value from a configuration parameter.
f) ListenInterval, in seconds. This is a configuration parameter that decides how long an SBM spends in the DetectDSBM state (more on that below) 🦋
g) ElectionInterval, in seconds. This is a configuration parameter that decides how long an SBM spends in the ElectDSBM state after it has declared its candidacy 💜
Figure 3 shows the state transition diagram for the election protocol. The states are described below, and the full state machine is in Section A.10. It's giving organized ✨
A.7. DSBM Election States 💜
DOWN 💀 The SBM is not operational.
DetectDSBM 🔥 This is usually the initial state when an SBM starts up. Here it checks whether a DSBM already exists in its domain.
Idle 🫶 The SBM lands here when no election is happening and it isn't the DSBM. In this state, it quietly monitors the state of the DSBM.
ElectDSBM 🌈 The SBM is in this state while a DSBM election is in progress.
IAMDSBM 👑 The SBM is in this state when it is the DSBM for the L2 domain. Slay.
A.8. Events that cause state changes 🦋
StartUp ✨ The SBM starts operating.
ListenInterval Timeout ⭐ The ListenInterval timer has fired. This means the SBM has checked its domain for an existing DSBM, or checked whether any other candidates are willing to be the DSBM.
DSBM_WILLING message received 🎀 The SBM got a DSBM_WILLING message from some other SBM. Those get sent when an SBM wants to declare its candidacy to be the DSBM.
I_AM_DSBM message received 🧚 The SBM got a DSBM advertisement from the DSBM in its L2 domain.
DSBMDeadInterval Timeout 😭 The DSBMDeadIntervalTimer has fired. This means the SBM did not receive even one DSBM advertisement during that period, which points to a possible failure of the DSBM.
RefreshInterval Timeout 🌸 The RefreshIntervalTimer has fired. In the IAMDSBM state, it's time to send out the next DSBM advertisement. In the ElectDSBM state, it's time to send out another DSBM_WILLING message.
ElectionInterval Timeout 💅 The ElectionIntervalTimer has fired. The SBM has waited long enough after declaring its candidacy to find out whether 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 above, here's how the state changes at an SBM. Each state change is triggered by an event and usually comes with a sequence of actions. The state machine assumes a single-threaded implementation (to avoid race conditions between state changes and timer events), with no timer events firing while the state machine is running 🧚
These routines come up a lot in the state machine, so here they are first 💖
ComparePrio(FirstAddrInfo, SecondAddrInfo) 👑 This decides whether the entity in the first parameter is better than the entity in the second, using the priority and IP address info in the two parameters. If any address is zero, that entity automatically loses. After that, priorities get compared, and the higher-priority candidate wins. If the priorities tie, the IP addresses break it (the one with the higher IP address in lexicographic order wins). It returns TRUE if the first entity is the better choice, and FALSE otherwise.
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
EndAmIBetterDSBM(OtherAddrInfo)
Begin
if (ComparePrio(OwnAddrInfo, OtherAddrInfo))
return TRUE
change LocalDSBMInfo = OtherDSBMAddrInfo
return FALSE
EndUpdateDSBMInfo()
/* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */
Begin
update LocalDSBMInfo such as IP addr, DSBM L2 address,
DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer
EndA.10.1 State Changes ✨
okay so bestie, this is the state machine, and it's giving pure chaos in the best way 💅 quick heads up: "continue" or "continue in current state" just means you exit the current action sequence and stay where you are, no 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();
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
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
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 StateA.10.2 Suggested Values of Interval Timers 🎀
so the goal here is to avoid DSBM outages for a long period 🥺, bounce back fast when a DSBM fails, and keep PATH and RESV state from timing out at the edge devices. so we suggest some timer values 🍓
assuming the RSVP implementations use a 30 second timeout for PATH and RESV refreshes, we suggest that the RefreshIntervalTimer be set to about 5 seconds, with DSBMDeadIntervalTimer set to 15 seconds (K=3, K*RefreshInterval). the DetectDSBMTimer should be set to a random value between (DSBMDeadIntervalTimer, 2*DSBMDeadIntervalTimer). and the ElectionIntervalTimer should be set at least to the value of DSBMDeadIntervalTimer, so that each SBM has a chance to get its DSBM_WILLING message (sent every RefreshInterval in ElectDSBM state) delivered to everyone else 🫶
A.10.3. Guidelines for Choice of Values for SBM_PRIORITY 💜
network administrators should configure the 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 that 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 are instead directed to the SBM management entity in those devices. so a DSBM can be elected separately on each point-to-point segment in a switched topology ✨ for example, in Figure 2, the 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 💅
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 it will assume itself to be the DSBM for traffic traversing in both directions over the managed segment 👑
Appendix B Message Encapsulation and Formats 🌸
to minimize changes to the existing RSVP implementations and to ensure quick deployment of an SBM in conjunction with RSVP, all communication to and from a DSBM will be performed using messages constructed with 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: 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. on top of that, 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 the 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 🎀
B.3.2. SBM Specific Objects ✨
Okay so bestie, the Class-Num values for the SBM specific objects (LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2) are all picked from the 10XXXXXX codespace 🎀. This is lowkey genius because it means non-SBM aware RSVP nodes will just ignore these objects, without forwarding them or generating an error message 🙈.
Within that SBM specific codespace, look at the third most significant bit of the Class-Num, because it's giving two different rules 💅:
a) Objects of the form 100XXXXX MUST be silently discarded by SBM nodes that do not recognize them 💀.
b) Objects of the form 101XXXXX MUST be silently forwarded by SBM nodes that do not recognize them 🦋.
Wait, I need to fix that. The original says "are to be silently discarded" and "are to be silently forwarded", with no BCP 14 key word, so I should not add one. Corrected:
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 🧚
Okay this one is a whole vibe, so bear with me 🫶. 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. But here's the tea: Ethernet octets are sent least significant bit first, while Token Ring sends most significant first 😭. So the numeric values naturally tied to the same address on different 802 media come out different 🙃.
To keep things consistent when higher layer protocols span both Token Ring and Ethernet systems connected by bridges, they needed one reference format, called the canonical format for these addresses 👑. The canonical format defines the value of the address separately from the encoding rules used for transmission. It's a sequence of octets derived from the original wire order bit order, like this: the least significant bit of the first octet is the first bit transmitted, the next least significant bit is the second, and so on up to the most significant bit of the first octet, which is the 8th bit transmitted. Then the least significant bit of the second octet is the 9th bit transmitted, and it keeps going until the most significant bit of the sixth octet of the canonical format, which is the last bit of the address transmitted 🌈.
This canonical format matches the natural value of the address octets for Ethernet 💖. The actual transmission order or formal encoding rules for addresses on media that don't transmit bit serially are derived from the canonical format octet values ✨.
This document REQUIRES that all L2 addresses used with the SBM protocol be encoded in the canonical format as a sequence of 6 octets 🎀. Below, we define the object formats for objects that contain L2 addresses 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 we just talked about 💅.
RSVP_HOP_L2 object: class = 161. The C-Type tells you which addressing format is used. In this case, C-Type=1 means 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 looks like this 👑:
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 the LAN_NHOP_L3 address object and the 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 the same format (but a different class number) as the RSVP_HOP_L2 object 🎀. It provides the L2 or MAC address of the next hop L3 device 🌸.
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 whether the IPv4 or IPv6 address family is used 🌈.
IPv4 LAN_NHOP_L3 object: class = 163, C-Type = 1
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length = 8 | 163 | 1 |
+---------------+---------------+---------------+---------------+
| IPv4 NHOP address |
+---------------------------------------------------------------+IPv6 LAN_NHOP_L3 object: class = 163, C-Type = 2
0 1 2 3
+---------------+---------------+---------------+---------------+
| 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 |
+---------------+---------------+---------------+---------------+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, 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>]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 🦋
okay so this is where we add brand-new RSVP message types so a DSBM and an RSVP node (host or router) can find each other and bind up 💖 the new ones are:
RSVP Msg Type (8 bits) Value
DSBM_WILLING 66
I_AM_DSBM 67All SBM-specific messages are formatted as RSVP messages with an RSVP common header followed by SBM-specific objects, so the shape is always the same 💅
<SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects>
where <SBMP common header> ::= <RSVP common Header> [<INTEGRITY>]For each SBM message type there's a set of rules for which object types are allowed. These rules are written in Backus-Naur Form (BNF), augmented with square brackets around the optional sub-sequences ✨
The BNF implies an order for the objects in a message. But in lots of cases (not all!) the 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>]For compatibility reasons, receivers of the I_AM_DSBM message must be prepared to receive additional objects of the Unknown Class type [RFC-2205]. Unknown objects showing up is fine, babe, that's the whole point of compatibility 🫶
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. so zero is basically the "not me, not today" 🙈
Relevant Objects
DSBM IP ADDRESS objects use object class = 42. The IPv4 DSBM IP ADDRESS object uses <Class=42, C-Type=1> and the 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 +
| |
+ +
| |
+---------------+---------------+---------------+---------------+The <DSBM L2 address> object is the same as the <RSVP_HOP_L2> object with C-Type = 1 for the IEEE Canonical Address format. So basically it's a reuse moment, we love efficiency 🍓
<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), that NULL 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) 🦋
SBM_PRIORITY Object: class = 43, C-Type =1
0 1 2 3
+---------------+---------------+---------------+---------------+
| /// | /// | /// | SBM priority |
+---------------+---------------+---------------+---------------+TIMER INTERVAL VALUES.
The two timer intervals, namely the DSBM Dead Interval and the DSBM Refresh Interval, are each specified as an integer value in the range of 0..255 seconds. Both values get packed into 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 that a sending host is allowed to send onto a managed segment without a valid RSVP reservation (see Appendix C for further details on how this object gets used) 🔥 It holds the NonResvSendLimit parameter, which is equivalent to the Intserv SENDER_TSPEC (see RFC 2210 for contents and encoding rules). The SENDER_TSPEC has five parameters that describe a traffic profile: (r, b, p, m and M).
Here's the vibe check: sending hosts compare the SENDER_TSPEC describing their sender traffic flow to the SENDER_TSPEC advertised by the DSBM. If the flow's SENDER_TSPEC is less than or equal to the one the DSBM advertised, it's allowed to send on that flow without a valid RSVP reservation in place. If not, it isn't. Rules are rules, bestie 💅
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 = 0. Major "nobody sends without a reservation" energy 🙅♀️ 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. That's the open-door policy 🌸 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). so no object means no limit, lowkey iconic 👑
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 can serve as a centralized management point from which those parameters get easily distributed 🧚 In particular, the network administrator configuring a DSBM can 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, and 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 made of traditional shared segments (with no means of traffic separation and no DSBM) to subnets made of dedicated segments switched by sophisticated switches (with both DSBM and 802.1p traffic separation capability). It's giving glow-up era 🌈
A set of intermediate configurations is 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 that setup, the DSBM can be configured to limit the number of reservations approved for senders on the segment, but it can't stop 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 that 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've obtained a reservation. This is problematic, because most applications are used to sending as soon as they wish to, and they expect to get whatever service quality the network can 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 made 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 let the network administrator set a per-flow limit on the amount of non-adaptive traffic 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 requested 🎀
The NON_RESV_SEND_LIMIT object can be used to advertise a Flowspec describing 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. the object literally carries the rules for the in-between moments 🦋
ACKNOWLEDGEMENTS 🌸
Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel), David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman (3COM), and Andrew Smith (Extreme Networks) for their constructive comments on the SBM design and the earlier versions of this document 🫶 the squad that made it happen!
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
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
Full Copyright Statement 💖
Copyright (C) The Internet Society (2000). All Rights Reserved. 🎀
Okay bestie, the legal bit, but make it cute 💅. Anyone can copy this document and share translations of it. People can also write derivative works that comment on it, explain it, or help people implement it, and publish and distribute those works in whole or in part, with no restriction of any kind. The one catch is that the copyright notice and this paragraph have to be included on every copy and every derivative work 📜. The document itself, though, may not be modified in any way. That means you can't remove the copyright notice or the references to the Internet Society or other Internet organizations 🙅♀️. There are two exceptions. You can change it as needed to develop Internet standards, but then the copyright procedures in the Internet Standards process must be followed. You can also change it to translate it into languages other than English 🌍.
These permissions are perpetual, so the Internet Society, its successors, and its assigns will never take them back 🦋.
This document and the information in it are provided on an "AS IS" basis. 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 😭. Translation: no promises, no guarantees, just vibes.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society 🌸. Thank you to the people keeping the whole RFC library running, because without them none of this specs stuff would be findable 💜.
📦 where this page comes from
- ietf: rfc2814 2000-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms