SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks
Extracted elements (28)
Admission control efficiency improves as managed-segment granularity increases. In the ideal limit each physical segment is its own managed segment with a DSBM configured with an accurate capacity estimate; a single DSBM managing a complex multi-segment topology must approximate capacity and consequently may over- or under-admit.
Both L2 and L3 addresses are carried in LAN_NHOP and RSVP_HOP objects because L2 devices acting as DSBMs cannot reasonably be expected to have ARP capability to resolve IP addresses to MAC addresses dynamically. Embedding both at L3 devices eliminates this requirement entirely from L2 DSBMs.
Non-DSBM SBMs serve two purposes: passive standby fault tolerance enabling re-election when the active DSBM fails, and division of the DSBM election scope so that physically distinct segments each have their own DSBM with accurate capacity knowledge, improving admission control efficiency over a single approximating DSBM.
Reserved IP multicast addresses rather than physical addresses are used for DSBM communication to enable dynamic DSBM-client binding and to allow L2 devices to intercept PATH messages without L3 RSVP snooping—a static FDB entry for the MAC multicast address suffices.
SBM-based admission control is still useful on shared LANs without IEEE 802.1p traffic control because it bounds the total IntServ traffic load, and TCP/IP sources use rate-adaptive congestion avoidance (slow-start, RTP/RTCP feedback) that prevents persistent congestion in the remaining best-effort capacity.
A non-SBM router that incorrectly forwards the SBM local-scope multicast messages (DSBMLogicalAddress or AllSBMAddress) between two DSBM-managed L2 domains may corrupt SBM protocol operation and cause over- or under-allocation of resources across domains.
RSVP nodes that support only UDP encapsulation cannot interoperate with a DSBM unless the DSBM is extended to accept UDP-encapsulated RSVP messages, because SBM mandates raw IP encapsulation for all messages forwarded onto a managed L2 domain.
SBM coexists with non-RSVP bandwidth allocation mechanisms (e.g., SNMP-based static configuration) only if reserved resources are either statically partitioned between the mechanisms or resolved through a common bandwidth allocator to prevent over-commitment of the same resource.
When SBM-transparent L2 devices interconnect SBM-aware devices, the resulting managed segment spans multiple physical segments and the single DSBM must approximate aggregate capacity with limited topology knowledge. A conservative policy configures the DSBM for the lowest-capacity path; a liberal policy uses the highest-capacity path.
A DSBM client that receives a TCLASS object in a RESV message after successful local admission control MUST pass the user_priority value to its local packet classifier so that subsequent data packets in the admitted flow are marked with the correct IEEE 802 frame header value.
A SBM implementation SHOULD satisfy all requirements of RFC 2747 (RSVP Cryptographic Authentication) and apply the same MD5-based integrity protection to SBM-specific objects in RSVP messages just as it does to standard RSVP objects.
All senders sourcing RSVP-based traffic flows onto a managed segment MUST be SBM-aware and participate in the SBM protocol. Use of standard non-SBM RSVP bypasses the DSBM's resource management function and may result in over-allocation of segment resources.
DSBMs, DSBM clients, and SBMs MUST use only raw IP encapsulation (not UDP) for RSVP messages forwarded onto an L2 domain.
LAN_NHOP information generated by L3 devices MUST include both the IP address (LAN_NHOP_L3) and the corresponding MAC address (LAN_NHOP_L2) for the next L3 hop across the L2 domain, so that L2 device DSBMs can forward PATH messages without requiring ARP capability.
Non-DSBM SBM entities MUST overwrite the LAN_LOOPBACK object with their own address when forwarding PATH messages to prevent indefinite multicast looping, even though they are not required to store path state or overwrite the PHOP.
When a DSBM client or SBM forwards a PATH message onto a managed segment, it MUST address it to the DSBMLogicalAddress (224.0.0.16). The DSBM MUST forward PATH messages on managed segments using the AllSBMAddress (224.0.0.17).
When a DSBM receives a RESV whose TCLASS value differs from the already-installed RESV for the same flow, it MUST send a RESV_ERR toward the newer RESV's sender using error code 21 (traffic control error), sub-code 01 (failure to merge incompatible service requests) per RFC 2205.
When an L3 device forwards a PATH or RESV message from a managed L2 domain onto an interface outside that domain, it MUST remove the TCLASS, LAN_NHOP, RSVP_HOP_L2, and LAN_LOOPBACK objects before forwarding.
DSBM (Designated Subnet Bandwidth Manager) is the protocol entity responsible for admission control on a managed L2 segment. At most one DSBM exists per segment; when multiple SBMs are present one is elected via a dynamic algorithm or static configuration.
I_AM_DSBM messages are periodic announcements sent by the active DSBM. DSBM clients use these to detect and verify DSBM presence on an attached segment; non-DSBM SBMs monitor them to detect DSBM failure and trigger re-election.
LAN_LOOPBACK object carries the unicast IP address of the most recent non-reflecting forwarder of a PATH message. Devices detect and silently discard duplicate PATH messages by checking whether their own address appears in this object; DSBMs reflecting PATH messages back on an incoming interface leave LAN_LOOPBACK unchanged.
LAN_NHOP object carries both the Layer 3 IP address (LAN_NHOP_L3) and the Layer 2 MAC address (LAN_NHOP_L2) of the next L3 hop across an L2 domain. L3 devices use the L3 address for routing while L2 device DSBMs use the L2 address to forward PATH messages without requiring ARP capability.
RSVP_HOP_L2 object extends the standard RSVP_HOP with the Layer 2 MAC address of the previous hop. It is included in PATH messages by L3 devices forwarding onto managed segments so that L2 device DSBMs can route RESV messages back without needing an ARP cache.
TCLASS object carries a user_priority value derived from IEEE 802.1p traffic class mappings. DSBMs insert or adjust TCLASS in outgoing PATH messages; senders extract the user_priority from the TCLASS in a received RESV and use it to mark the IEEE 802.1Q extended frame header on admitted data flows.
Two reserved local-scope IP multicast addresses are assigned: 224.0.0.16 (DSBMLogicalAddress) for DSBM clients and SBMs to address PATH messages to the DSBM, and 224.0.0.17 (AllSBMAddress) for the DSBM to forward PATH messages and for SBM election traffic. Corresponding MAC addresses use the 00:00:5e high-order prefix per RFC 1700.
Access to enhanced quality-of-service must be controlled and authenticated. SBM security issues are identical to those of RSVP and Integrated Services; RFC 2747 MD5 cryptographic authentication should protect RSVP message integrity including all SBM-specific objects.
DSBM candidates must be mutually authenticated during the election process to prevent unauthorized devices from seizing the DSBM role and controlling admission decisions; a shared-secret mechanism based on RFC 2747 is recommended.
DSBM-based admission control follows a sequential path-state machine: (1) DSBM client discovers DSBM via I_AM_DSBM; (2) client sends PATH to DSBMLogicalAddress; (3) DSBM builds PATH state, inserts itself as intermediate RSVP hop, forwards PATH toward destination; (4) receiver sends RESV to DSBM; (5) DSBM performs admission control and forwards RESV upstream or returns RESV_ERR.