draft-ietf-issll-is802-sbm-10.txt   rfc2814.txt 
Internet Engineering Task Force Raj Yavatkar, Intel
INTERNET-DRAFT Don Hoffman, Teledesic
Yoram Bernet, Microsoft
Fred Baker, Cisco
Michael Speer, Sun Microsystems
January 2000 Network Working Group R. Yavatkar
Request for Comments: 2814 Intel
SBM (Subnet Bandwidth Manager): Category: Standards Track D. Hoffman
A Protocol for RSVP-based Admission Control over IEEE 802-style networks Teledesic
draft-ietf-issll-is802-sbm-10.txt Y. Bernet
Status of this Memo Microsoft
F. Baker
This document is an Internet-Draft and is in full conformance with all Cisco
provisions of Section 10 of RFC2026. M. Speer
Sun Microsystems
This document is an Internet Draft. Internet Drafts are working May 2000
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet Drafts are draft documents valid for a maximum of six months SBM (Subnet Bandwidth Manager):
and may be updated, replaced, or obsoleted by other documents at any A Protocol for RSVP-based Admission Control over IEEE 802-style networks
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at Status of this Memo
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
SBM (Subnet Bandwidth Manager) January, 2000 Copyright Notice
Abstract Copyright (C) The Internet Society (2000). All Rights Reserved.
This document describes a signaling method and protocol for RSVP-based Abstract
admission control over IEEE 802-style LANs. The protocol is designed to
work both with the current generation of IEEE 802 LANs as well as with
the recent work completed by the IEEE 802.1 committee.
SBM (Subnet Bandwidth Manager) January, 2000 This document describes a signaling method and protocol for RSVP-
based admission control over IEEE 802-style LANs. The protocol is
designed to work both with the current generation of IEEE 802 LANs as
well as with the recent work completed by the IEEE 802.1 committee.
1. Introduction 1. Introduction
New extensions to the Internet architecture and service models have been New extensions to the Internet architecture and service models have
defined for an integrated services Internet [RFC-1633, RFC-2205, been defined for an integrated services Internet [RFC-1633, RFC-2205,
RFC-2210] so that applications can request specific qualities or levels RFC-2210] so that applications can request specific qualities or
of service from an internetwork in addition to the current IP levels of service from an internetwork in addition to the current IP
best-effort service. These extensions include RSVP, a resource best-effort service. These extensions include RSVP, a resource
reservation setup protocol, and definition of new service classes to be reservation setup protocol, and definition of new service classes to
supported by Integrated Services routers. RSVP and service class be supported by Integrated Services routers. RSVP and service class
definitions are largely independent of the underlying networking definitions are largely independent of the underlying networking
technologies and it is necessary to define the mapping of RSVP and technologies and it is necessary to define the mapping of RSVP and
Integrated Services specifications onto specific subnetwork Integrated Services specifications onto specific subnetwork
technologies. For example, a definition of service mappings and technologies. For example, a definition of service mappings and
reservation setup protocols is needed for specific link-layer reservation setup protocols is needed for specific link-layer
technologies such as shared and switched IEEE-802-style LAN technologies such as shared and switched IEEE-802-style LAN
technologies. technologies.
This document defines SBM, a signaling protocol for RSVP-based admission This document defines SBM, a signaling protocol for RSVP-based
control over IEEE 802-style networks. SBM provides a method for mapping admission control over IEEE 802-style networks. SBM provides a
an internet-level setup protocol such as RSVP onto IEEE 802 style method for mapping an internet-level setup protocol such as RSVP onto
networks. In particular, it describes the operation of RSVP- enabled IEEE 802 style networks. In particular, it describes the operation
hosts/routers and link layer devices (switches, bridges) to support of RSVP-enabled hosts/routers and link layer devices (switches,
reservation of LAN resources for RSVP-enabled data flows. A framework bridges) to support reservation of LAN resources for RSVP-enabled
for providing Integrated Services over shared and switched data flows. A framework for providing Integrated Services over
IEEE-802-style LAN technologies and a definition of service mappings shared and switched IEEE-802-style LAN technologies and a definition
have been described in separate documents [RFC-FRAME, RFC-MAP]. of service mappings have been described in separate documents [RFC-
FRAME, RFC-MAP].
2. Goals and Assumptions 2. Goals and Assumptions
The SBM (Subnet Bandwidth Manager) protocol and its use for admission The SBM (Subnet Bandwidth Manager) protocol and its use for admission
control and bandwidth management in IEEE 802 level-2 networks is based control and bandwidth management in IEEE 802 level-2 networks is
on the following architectural goals and assumptions: based on the following architectural goals and assumptions:
I. Even though the current trend is towards increased use of
switched LAN topologies consisting of newer switches that support
the priority queuing mechanisms specified by IEEE 802.1p, we assume
that the LAN technologies will continue to be a mix of legacy
shared/ switched LAN segments and newer switched segments based on
IEEE 802.1p specification. Therefore, we specify a signaling
protocol for managing bandwidth over both legacy and newer LAN
topologies and that takes advantage of the additional functionality
(such as an explicit support for different traffic classes or
integrated service classes) as it becomes available in the new
generation of switches, hubs, or bridges. As a result, the SBM
protocol would allow for a range of LAN bandwidth
SBM (Subnet Bandwidth Manager) January, 2000
management solutions that vary from one that exercises purely
administrative control (over the amount of bandwidth consumed by
RSVP-enabled traffic flows) to one that requires cooperation (and
enforcement) from all the end-systems or switches in a IEEE 802
LAN.
II. This document specifies only a signaling method and protocol
for LAN-based admission control over RSVP flows. We do not define
here any traffic control mechanisms for the link layer; the
protocol is designed to use any such mechanisms defined by IEEE
802. In addition, we assume that the Layer 3 end-systems (e.g., a
host or a router) will exercise traffic control by policing
Integrated Services traffic flows to ensure that each flow stays
within its traffic specifications stipulated in an earlier
reservation request submitted for admission control. This then
allows a system using SBM admission control combined with per flow
shaping at end systems and IEEE-defined traffic control at link
layer to realize some approximation of Controlled Load (and even
Guaranteed) services over IEEE 802-style LANs.
III. In the absence of any link-layer traffic control or priority I. Even though the current trend is towards increased use of
queuing mechanisms in the underlying LAN (such as a shared LAN switched LAN topologies consisting of newer switches that support
segment), the SBM-based admission control mechanism only limits the the priority queuing mechanisms specified by IEEE 802.1p, we
total amount of traffic load imposed by RSVP-enabled flows on a assume that the LAN technologies will continue to be a mix of
shared LAN. In such an environment, no traffic flow separation legacy shared/ switched LAN segments and newer switched segments
mechanism exists to protect the RSVP-enabled flows from the based on IEEE 802.1p specification. Therefore, we specify a
best-effort traffic on the same shared media and that raises the signaling protocol for managing bandwidth over both legacy and
question of the utility of such a mechanism outside a topology newer LAN topologies and that takes advantage of the additional
consisting only of 802.1p-compliant switches. However, we assume functionality (such as an explicit support for different traffic
that the SBM-based admission control mechanism will still serve a classes or integrated service classes) as it becomes available in
useful purpose in a legacy, shared LAN topology for two reasons. the new generation of switches, hubs, or bridges. As a result,
First, assuming that all the nodes that generate Integrated the SBM protocol would allow for a range of LAN bandwidth
Services traffic flows utilize the SBM-based admission control management solutions that vary from one that exercises purely
procedure to request reservation of resources before sending any administrative control (over the amount of bandwidth consumed by
traffic, the mechanism will restrict the total amount of traffic RSVP-enabled traffic flows) to one that requires cooperation (and
generated by Integrated Services flows within the bounds desired by enforcement) from all the end-systems or switches in a IEEE 802
a LAN administrator (see discussion of the NonResvSendLimit LAN.
parameter in Appendix C). Second, the best-effort traffic
generated by the TCP/IP-based traffic sources is generally rate
adaptive (using a TCP-style "slow start" congestion avoidance
mechanism or a feedback-based rate adaptation mechanism used by
audio/video streams based on RTP/RTCP protocols) and adapts to stay
within the available network bandwidth. Thus, the combination of
admission control and rate adaptation should avoid persistent
traffic congestion. This does not, however, guarantee that
non-Integrated-Services traffic will not interfere with the
SBM (Subnet Bandwidth Manager) January, 2000 II. This document specifies only a signaling method and protocol
for LAN-based admission control over RSVP flows. We do not define
here any traffic control mechanisms for the link layer; the
protocol is designed to use any such mechanisms defined by IEEE
802. In addition, we assume that the Layer 3 end-systems (e.g., a
host or a router) will exercise traffic control by policing
Integrated Services traffic flows to ensure that each flow stays
within its traffic specifications stipulated in an earlier
reservation request submitted for admission control. This then
allows a system using SBM admission control combined with per flow
shaping at end systems and IEEE-defined traffic control at link
layer to realize some approximation of Controlled Load (and even
Guaranteed) services over IEEE 802-style LANs.
Integrated Services traffic in the absence of traffic control III. In the absence of any link-layer traffic control or priority
support in the underlying LAN infrastructure. queuing mechanisms in the underlying LAN (such as a shared LAN
segment), the SBM-based admission control mechanism only limits
the total amount of traffic load imposed by RSVP-enabled flows on
a shared LAN. In such an environment, no traffic flow separation
mechanism exists to protect the RSVP-enabled flows from the best-
effort traffic on the same shared media and that raises the
question of the utility of such a mechanism outside a topology
consisting only of 802.1p-compliant switches. However, we assume
that the SBM-based admission control mechanism will still serve a
useful purpose in a legacy, shared LAN topology for two reasons.
First, assuming that all the nodes that generate Integrated
Services traffic flows utilize the SBM-based admission control
procedure to request reservation of resources before sending any
traffic, the mechanism will restrict the total amount of traffic
generated by Integrated Services flows within the bounds desired
by a LAN administrator (see discussion of the NonResvSendLimit
parameter in Appendix C). Second, the best-effort traffic
generated by the TCP/IP-based traffic sources is generally rate
adaptive (using a TCP-style "slow start" congestion avoidance
mechanism or a feedback-based rate adaptation mechanism used by
audio/video streams based on RTP/RTCP protocols) and adapts to
stay within the available network bandwidth. Thus, the
combination of admission control and rate adaptation should avoid
persistent traffic congestion. This does not, however, guarantee
that non-Integrated-Services traffic will not interfere with the
Integrated Services traffic in the absence of traffic control
support in the underlying LAN infrastructure.
3. Organization of the rest of this document 3. Organization of the rest of this document
The rest of this document provides a detailed description of the The rest of this document provides a detailed description of the
SBM-based admission control procedure(s) for IEEE 802 LAN technologies. SBM-based admission control procedure(s) for IEEE 802 LAN
The document is organized as follows: technologies. The document is organized as follows:
* Section 4 first defines the various terms used in the document
and then provides an overview of the admission control procedure
with an example of its application to a sample network.
* Section 5 describes the rules for processing and forwarding PATH
(and PATH_TEAR) messages at DSBMs (Designated Subnet Bandwidth
Managers), SBMs, and DSBM clients.
* Section 6 addresses the inter-operability issues when a DSBM may
operate in the absence of RSVP signaling at Layer 3 or when
another signaling protocol (such as SNMP) is used to reserve
resources on a LAN segment.
* Appendix A describes the details of the DSBM election algorithm
used for electing a designated SBM on a LAN segment when more than
one SBM is present. It also describes how DSBM clients discover
the presence of a DSBM on a managed segment.
* Appendix B specifies the formats of SBM-specific messages used
and the formats of new RSVP objects needed for the SBM operation.
* Appendix C describes usage of the DSBM to distribute configuration * Section 4 first defines the various terms used in the document and
information to senders on a managed segment. then provides an overview of the admission control procedure with
an example of its application to a sample network.
4. Overview * Section 5 describes the rules for processing and forwarding PATH
(and PATH_TEAR) messages at DSBMs (Designated Subnet Bandwidth
Managers), SBMs, and DSBM clients.
4.1. Definitions * Section 6 addresses the inter-operability issues when a DSBM may
operate in the absence of RSVP signaling at Layer 3 or when
another signaling protocol (such as SNMP) is used to reserve
resources on a LAN segment.
SBM (Subnet Bandwidth Manager) January, 2000 * Appendix A describes the details of the DSBM election algorithm
used for electing a designated SBM on a LAN segment when more than
one SBM is present. It also describes how DSBM clients discover
the presence of a DSBM on a managed segment.
- Link Layer or Layer 2 or L2: We refer to data-link layer * Appendix B specifies the formats of SBM-specific messages used and
technologies such as IEEE 802.3/Ethernet as L2 or layer 2. the formats of new RSVP objects needed for the SBM operation.
- Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes * Appendix C describes usage of the DSBM to distribute configuration
and links interconnected without passing through a L3 forwarding information to senders on a managed segment.
function. One or more IP subnets can be overlaid on a L2 domain.
- Layer 2 or L2 devices: We refer to devices that only implement 4. Overview
Layer 2 functionality as Layer 2 or L2 devices. These include
802.1D bridges or switches.
- Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO 7 layer 4.1. Definitions
model. This document is primarily concerned with networks that
use the Internet Protocol (IP) at this layer.
- Layer 3 Device or L3 Device or End-Station: these include hosts - Link Layer or Layer 2 or L2: We refer to data-link layer
and routers that use L3 and higher layer protocols or application technologies such as IEEE 802.3/Ethernet as L2 or layer 2.
programs that need to make resource reservations.
- Segment: A L2 physical segment that is shared by one or more - Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes
senders. Examples of segments include (a) a shared Ethernet or and links interconnected without passing through a L3 forwarding
Token-Ring wire resolving contention for media access using CSMA function. One or more IP subnets can be overlaid on a L2 domain.
or token passing ("shared L2 segment"), (b) a half duplex link
between two stations or switches, (c) one direction of a switched
full-duplex link.
- Managed segment: A managed segment is a segment with a DSBM - Layer 2 or L2 devices: We refer to devices that only implement
present and responsible for exercising admission control over Layer 2 functionality as Layer 2 or L2 devices. These include
requests for resource reservation. A managed segment includes 802.1D bridges or switches.
those interconnected parts of a shared LAN that are not separated
by DSBMs.
- Traffic Class: An aggregation of data flows which are given - Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO 7 layer
similar service within a switched network. model. This document is primarily concerned with networks that use
the Internet Protocol (IP) at this layer.
- User_priority: User_priority is a value associated with the - Layer 3 Device or L3 Device or End-Station: these include hosts
transmission and reception of all frames in the IEEE 802 service and routers that use L3 and higher layer protocols or application
model: it is supplied by the sender that is using the MAC programs that need to make resource reservations.
service. It is provided along with the data to a receiver using the
MAC service. It may or may not be actually carried over the
SBM (Subnet Bandwidth Manager) January, 2000 - Segment: A L2 physical segment that is shared by one or more
senders. Examples of segments include (a) a shared Ethernet or
Token-Ring wire resolving contention for media access using CSMA
or token passing ("shared L2 segment"), (b) a half duplex link
between two stations or switches, (c) one direction of a switched
full-duplex link.
network: Token-Ring/802.5 carries this value (encoded in its FC - Managed segment: A managed segment is a segment with a DSBM
octet), basic Ethernet/802.3 does not, 802.12 may or may not present and responsible for exercising admission control over
depending on the frame format in use. 802.1p defines a consistent requests for resource reservation. A managed segment includes
way to carry this value over the bridged network on Ethernet, those interconnected parts of a shared LAN that are not separated
Token Ring, Demand-Priority, FDDI or other MAC-layer media using by DSBMs.
an extended frame format. The usage of user_priority is fully
described in section 2.5 of 802.1D [IEEE8021D] and 802.1p
[IEEE8021P] "Support of the Internal Layer Service by Specific
MAC Procedures".
- Subnet: used in this memo to indicate a group of L3 devices - Traffic Class: An aggregation of data flows which are given
sharing a common L3 network address prefix along with the set similar service within a switched network.
of segments making up the L2 domain in which they are located.
- Bridge/Switch: a layer 2 forwarding device as defined by IEEE - User_priority: User_priority is a value associated with the
802.1D. The terms bridge and switch are used synonymously in this transmission and reception of all frames in the IEEE 802 service
document. model: it is supplied by the sender that is using the MAC service.
It is provided along with the data to a receiver using the MAC
service. It may or may not be actually carried over the network:
Token-Ring/802.5 carries this value (encoded in its FC octet),
basic Ethernet/802.3 does not, 802.12 may or may not depending on
the frame format in use. 802.1p defines a consistent way to carry
this value over the bridged network on Ethernet, Token Ring,
Demand-Priority, FDDI or other MAC-layer media using an extended
frame format. The usage of user_priority is fully described in
section 2.5 of 802.1D [IEEE8021D] and 802.1p [IEEE8021P] "Support
of the Internal Layer Service by Specific MAC Procedures".
- DSBM: Designated SBM (DSBM) is a protocol entity that resides in - Subnet: used in this memo to indicate a group of L3 devices
a L2 or L3 device and manages resources on a L2 segment. At most sharing a common L3 network address prefix along with the set of
one DSBM exists for each L2 segment. segments making up the L2 domain in which they are located.
- SBM: the SBM is a protocol entity that resides in a L2 or L3 device - Bridge/Switch: a layer 2 forwarding device as defined by IEEE
and is capable of managing resources on a segment. However, 802.1D. The terms bridge and switch are used synonymously in this
only a DSBM manages the resources for a managed segment. When document.
more than one SBM exists on a segment, one of the SBMs is elected
to be the DSBM.
- Extended segment: An extended segment includes those parts of a - DSBM: Designated SBM (DSBM) is a protocol entity that resides in a
network which are members of the same IP subnet and therefore are L2 or L3 device and manages resources on a L2 segment. At most one
not separated by any layer 3 devices. Several managed segments, DSBM exists for each L2 segment.
interconnected by layer 2 devices, constitute an extended segment.
- Managed L2 domain: An L2 domain consisting of managed segments is - SBM: the SBM is a protocol entity that resides in a L2 or L3
referred to as a managed L2 domain to distinguish it from a L2 device and is capable of managing resources on a segment. However,
domain with no DSBMs present for exercising admission control only a DSBM manages the resources for a managed segment. When more
over resources at segments in the L2 domain. than one SBM exists on a segment, one of the SBMs is elected to be
the DSBM.
- DSBM clients: These are entities that transmit traffic onto a - Extended segment: An extended segment includes those parts of a
network which are members of the same IP subnet and therefore are
not separated by any layer 3 devices. Several managed segments,
interconnected by layer 2 devices, constitute an extended segment.
SBM (Subnet Bandwidth Manager) January, 2000 - Managed L2 domain: An L2 domain consisting of managed segments is
referred to as a managed L2 domain to distinguish it from a L2
domain with no DSBMs present for exercising admission control over
resources at segments in the L2 domain.
managed segment and use the services of a DSBM for the managed - DSBM clients: These are entities that transmit traffic onto a
segment for admission control over a LAN segment. Only the layer managed segment and use the services of a DSBM for the managed
3 or higher layer entities on L3 devices such as hosts and segment for admission control over a LAN segment. Only the layer 3
routers are expected to send traffic that requires resource or higher layer entities on L3 devices such as hosts and routers
reservations, and, therefore, DSBM clients are L3 entities. are expected to send traffic that requires resource reservations,
and, therefore, DSBM clients are L3 entities.
- SBM transparent devices: A "SBM transparent" device is unaware of - SBM transparent devices: A "SBM transparent" device is unaware of
SBMs or DSBMs (though it may or may not be RSVP aware) and, SBMs or DSBMs (though it may or may not be RSVP aware) and,
therefore, does not participate in the SBM-based admission control therefore, does not participate in the SBM-based admission control
procedure over a managed segment. Such a device uses standard procedure over a managed segment. Such a device uses standard
forwarding rules appropriate for the device and is transparent forwarding rules appropriate for the device and is transparent
with respect to SBM. An example of such a L2 device is a with respect to SBM. An example of such a L2 device is a legacy
legacy switch that does not participate in resource reservation. switch that does not participate in resource reservation.
- Layer 3 and layer 2 addresses: We refer to layer 3 addresses of - Layer 3 and layer 2 addresses: We refer to layer 3 addresses of
L3/L2 devices as "L3 addresses" and layer 2 addresses as "L2 L3/L2 devices as "L3 addresses" and layer 2 addresses as "L2
addresses". This convention will be used in the rest of the document addresses". This convention will be used in the rest of the
to distinguish between Layer 3 and layer 2 addresses used to document to distinguish between Layer 3 and layer 2 addresses used
refer to RSVP next hop (NHOP) and previous hop (PHOP) devices. to refer to RSVP next hop (NHOP) and previous hop (PHOP) devices.
For example, in conventional RSVP message processing, RSVP_HOP For example, in conventional RSVP message processing, RSVP_HOP
object in a PATH message carries the L3 address of the previous object in a PATH message carries the L3 address of the previous
hop device. We will refer to the address contained in the hop device. We will refer to the address contained in the RSVP_HOP
RSVP_HOP object as the RSVP_HOP_L3 address and the corresponding object as the RSVP_HOP_L3 address and the corresponding MAC
MAC address of the previous hop device will be referred to as the address of the previous hop device will be referred to as the
RSVP_HOP_L2 address. RSVP_HOP_L2 address.
4.2. Overview of the SBM-based Admission Control Procedure 4.2. Overview of the SBM-based Admission Control Procedure
A protocol entity called "Designated SBM" (DSBM) exists for each A protocol entity called "Designated SBM" (DSBM) exists for each
managed segment and is responsible for admission control over the managed segment and is responsible for admission control over the
resource reservation requests originating from the DSBM clients in resource reservation requests originating from the DSBM clients in
that segment. Given a segment, one or more SBMs may exist on the segment. that segment. Given a segment, one or more SBMs may exist on the
For example, many SBM-capable devices may be attached to a segment. For example, many SBM-capable devices may be attached to a
shared L2 segment whereas two SBM-capable switches may share a shared L2 segment whereas two SBM-capable switches may share a half-
half-duplex switched segment. In that case, a single DSBM is elected for duplex switched segment. In that case, a single DSBM is elected for
the segment. The procedure for dynamically electing the DSBM is the segment. The procedure for dynamically electing the DSBM is
described in Appendix A. The only other approved method for specifying described in Appendix A. The only other approved method for
a DSBM for a managed segment is static configuration at SBM-capable specifying a DSBM for a managed segment is static configuration at
devices. SBM-capable devices.
The presence of a DSBM makes the segment a "managed segment". Sometimes,
two or more L2 segments may be interconnected by SBM transparent
devices. In that case, a single DSBM will manage the resources
for those segments treating the collection of such segments as a
SBM (Subnet Bandwidth Manager) January, 2000
single managed segment for the purpose of admission control.
SBM (Subnet Bandwidth Manager) January, 2000 The presence of a DSBM makes the segment a "managed segment".
Sometimes, two or more L2 segments may be interconnected by SBM
transparent devices. In that case, a single DSBM will manage the
resources for those segments treating the collection of such segments
as a single managed segment for the purpose of admission control.
4.2.1. Basic Algorithm 4.2.1. Basic Algorithm
Figure 1 - An Example of a Managed Segment. Figure 1 - An Example of a Managed Segment.
+-------+ +-----+ +------+ +-----+ +--------+ +-------+ +-----+ +------+ +-----+ +--------+
|Router | | Host| | DSBM | | Host| | Router | |Router | | Host| | DSBM | | Host| | Router |
| R2 | | C | +------+ | B | | R3 | | R2 | | C | +------+ | B | | R3 |
+-------+ +-----+ / +-----+ +--------+ +-------+ +-----+ / +-----+ +--------+
| | / | | | | / | |
| | / | | | | / | |
==============================================================LAN ==============================================================LAN
| | | |
| | | |
+------+ +-------+ +------+ +-------+
| Host | | Router| | Host | | Router|
| A | | R1 | | A | | R1 |
+------+ +-------+ +------+ +-------+
Figure 1 shows an example of a managed segment in a L2 domain that Figure 1 shows an example of a managed segment in a L2 domain that
interconnects a set of hosts and routers. For the purpose of this interconnects a set of hosts and routers. For the purpose of this
discussion, we ignore the actual physical topology of the L2 domain discussion, we ignore the actual physical topology of the L2 domain
(assume it is a shared L2 segment and a single managed segment (assume it is a shared L2 segment and a single managed segment
represents the entire L2 domain). A single SBM device is designated to represents the entire L2 domain). A single SBM device is designated
be the DSBM for the managed segment. We will provide examples of to be the DSBM for the managed segment. We will provide examples of
operation of the DSBM over switched and shared segments later in the operation of the DSBM over switched and shared segments later in the
document. document.
The basic DSBM-based admission control procedure works as follows: The basic DSBM-based admission control procedure works as follows:
1. DSBM Initialization: As part of its initial configuration, DSBM 1. DSBM Initialization: As part of its initial configuration, DSBM
obtains information such as the limits on fraction of available obtains information such as the limits on fraction of available
resources that can be reserved on each managed segment under its resources that can be reserved on each managed segment under its
control. For instance, bandwidth is one such resource. Even control. For instance, bandwidth is one such resource. Even
though methods such as auto-negotiation of link speeds and though methods such as auto-negotiation of link speeds and
knowledge of link topology allow discovery of link capacity, the knowledge of link topology allow discovery of link capacity, the
configuration may be necessary to limit the fraction of link configuration may be necessary to limit the fraction of link
capacity that can be reserved on a link. Configuration is likely capacity that can be reserved on a link. Configuration is likely
to be static with the current L2/L3 devices. Future work may to be static with the current L2/L3 devices. Future work may
allow for dynamic discovery of this information. This document allow for dynamic discovery of this information. This document
does not specify the configuration mechanism. does not specify the configuration mechanism.
2. DSBM Client Initialization: For each interface attached, a DSBM
client determines whether a DSBM exists on the interface. The
SBM (Subnet Bandwidth Manager) January, 2000
procedure for discovering and verifying the existence of the DSBM
for an attached segment is described in Appendix A. If the client
itself is capable of serving as the DSBM on the segment, it may
choose to participate in the election to become the DSBM. At the
start, a DSBM client first verifies that a DSBM exists in its L2
domain so that it can communicate with the DSBM for admission
control purposes.
In the case of a full-duplex segment, an election may not be
necessary as the SBM at each end will typically act as the DSBM
for outgoing traffic in each direction.
3. DSBM-based Admission Control: To request reservation of resources 2. DSBM Client Initialization: For each interface attached, a DSBM
(e.g., LAN bandwidth in a L2 domain), DSBM clients (RSVP-capable client determines whether a DSBM exists on the interface. The
L3 devices such as hosts and routers) follow the following steps: procedure for discovering and verifying the existence of the DSBM
for an attached segment is described in Appendix A. If the client
itself is capable of serving as the DSBM on the segment, it may
choose to participate in the election to become the DSBM. At the
start, a DSBM client first verifies that a DSBM exists in its L2
domain so that it can communicate with the DSBM for admission
control purposes.
a) When a DSBM client sends or forwards a RSVP PATH message over In the case of a full-duplex segment, an election may not be
an interface attached to a managed segment, it sends the PATH necessary as the SBM at each end will typically act as the DSBM
message to the segment's DSBM instead of sending it to the RSVP for outgoing traffic in each direction.
session destination address (as is done in conventional RSVP
processing). After processing (and possibly updating an
ADSPEC), the DSBM will forward the PATH message toward its
destination address. As part of its processing, the DSBM builds
and maintains a PATH state for the session and notes the
previous L2/L3 hop that sent it the PATH message.
Let us consider the managed segment in Figure 1. Assume that a 3. DSBM-based Admission Control: To request reservation of resources
sender to a RSVP session (session address specifies the IP (e.g., LAN bandwidth in a L2 domain), DSBM clients (RSVP-capable
address of host A on the managed segment in Figure 1) resides L3 devices such as hosts and routers) follow the following steps:
outside the L2 domain of the managed segment and sends a PATH
message that arrives at router R1 which is on the path towards
host A.
DSBM client on Router R1 forwards the PATH message from the a) When a DSBM client sends or forwards a RSVP PATH message over
sender to the DSBM. The DSBM processes the PATH message and an interface attached to a managed segment, it sends the PATH
forwards the PATH message towards the RSVP receiver (Detailed message to the segment's DSBM instead of sending it to the RSVP
message processing and forwarding rules are described in session destination address (as is done in conventional RSVP
Section 5). In the process, the DSBM builds the PATH state, processing). After processing (and possibly updating an
remembers the router R1 (its L2 and l3 addresses) as the previous ADSPEC), the DSBM will forward the PATH message toward its
hop for the session, puts its own L2 and L3 addresses in destination address. As part of its processing, the DSBM builds
the PHOP objects (see explanation later), and effectively and maintains a PATH state for the session and notes the
inserts itself as an intermediate node between the sender (or previous L2/L3 hop that sent it the PATH message.
R1 in Figure 1) and the receiver (host A) on the managed
segment.
b) When an application on host A wishes to make a reservation for Let us consider the managed segment in Figure 1. Assume that a
sender to a RSVP session (session address specifies the IP
address of host A on the managed segment in Figure 1) resides
outside the L2 domain of the managed segment and sends a PATH
message that arrives at router R1 which is on the path towards
host A.
SBM (Subnet Bandwidth Manager) January, 2000 DSBM client on Router R1 forwards the PATH message from the
sender to the DSBM. The DSBM processes the PATH message and
forwards the PATH message towards the RSVP receiver (Detailed
message processing and forwarding rules are described in
Section 5). In the process, the DSBM builds the PATH state,
remembers the router R1 (its L2 and l3 addresses) as the
previous hop for the session, puts its own L2 and L3 addresses
in the PHOP objects (see explanation later), and effectively
inserts itself as an intermediate node between the sender (or
R1 in Figure 1) and the receiver (host A) on the managed
segment.
the RSVP session, host A follows the standard RSVP message b) When an application on host A wishes to make a reservation for
processing rules and sends a RSVP RESV message to the previous hop the RSVP session, host A follows the standard RSVP message
L2/L3 address (the DSBMs address) obtained from the PHOP processing rules and sends a RSVP RESV message to the previous
object(s) in the previously received PATH message. hop L2/L3 address (the DSBMs address) obtained from the PHOP
object(s) in the previously received PATH message.
c) The DSBM processes the RSVP RESV message based on the bandwidth c) The DSBM processes the RSVP RESV message based on the bandwidth
available and returns an RESV_ERR message to the requester (host available and returns an RESV_ERR message to the requester
A) if the request cannot be granted. If sufficient resources (host A) if the request cannot be granted. If sufficient
are available and the reservation request is granted, the DSBM resources are available and the reservation request is granted,
forwards the RESV message towards the PHOP(s) based on its the DSBM forwards the RESV message towards the PHOP(s) based on
local PATH state for the session. The DSBM merges reservation its local PATH state for the session. The DSBM merges
requests for the same session as and when possible using the reservation requests for the same session as and when possible
rules similar to those used in the conventional RSVP processing using the rules similar to those used in the conventional RSVP
(except for an additional criterion described in Section 5.9). processing (except for an additional criterion described in
Section 5.8).
d) If the L2 domain contains more than one managed segment, the d) If the L2 domain contains more than one managed segment, the
requester (host A) and the forwarder (router R1) may be requester (host A) and the forwarder (router R1) may be
separated by more than one managed segment. In that case, the separated by more than one managed segment. In that case, the
original PATH message would propagate through many DSBMs (one original PATH message would propagate through many DSBMs (one
for each managed segment on the path from R1 to A) setting up for each managed segment on the path from R1 to A) setting up
PATH state at each DSBM. Therefore, the RESV message would PATH state at each DSBM. Therefore, the RESV message would
propagate hop-by-hop in reverse through the intermediate DSBMs and propagate hop-by-hop in reverse through the intermediate DSBMs
eventually reach the original forwarder (router R1) on the L2 and eventually reach the original forwarder (router R1) on the
domain if admission control at all DSBMs succeeds. L2 domain if admission control at all DSBMs succeeds.
4.2.2. Enhancements to the conventional RSVP operation 4.2.2. Enhancements to the conventional RSVP operation
(D)SBMs and DSBM clients implement minor additions to the standard (D)SBMs and DSBM clients implement minor additions to the standard
RSVP protocol. These are summarized in this section. A detailed RSVP protocol. These are summarized in this section. A detailed
description of the message processing and forwarding rules follows in description of the message processing and forwarding rules follows in
section 5. section 5.
4.2.2.1 Sending PATH Messages to the DSBM on a Managed Segment 4.2.2.1 Sending PATH Messages to the DSBM on a Managed Segment
Normal RSVP forwarding rules apply at a DSBM client when it is not Normal RSVP forwarding rules apply at a DSBM client when it is not
forwarding an outgoing PATH message over a managed segment. However, forwarding an outgoing PATH message over a managed segment. However,
outgoing PATH messages on a managed segment are sent to the DSBM for outgoing PATH messages on a managed segment are sent to the DSBM for
the corresponding managed segment (Section 5.2 describes how the PATH the corresponding managed segment (Section 5.2 describes how the PATH
messages are sent to the DSBM on a managed segment). messages are sent to the DSBM on a managed segment).
4.2.2.2 The LAN_NHOP Objects 4.2.2.2 The LAN_NHOP Objects
In conventional RSVP processing over point-to-point links, RSVP nodes In conventional RSVP processing over point-to-point links, RSVP nodes
(hosts/routers) use RSVP_HOP object (NHOP and PHOP info) to keep track (hosts/routers) use RSVP_HOP object (NHOP and PHOP info) to keep
of the next hop (downstream node in the path of data packets in a track of the next hop (downstream node in the path of data packets in
a traffic flow) and the previous hop (upstream nodes with respect to
SBM (Subnet Bandwidth Manager) January, 2000 the data flow) nodes on the path between a sender and a receiver.
Routers along the path of a PATH message forward the message towards
traffic flow) and the previous hop (upstream nodes with respect to the the destination address based on the L3 routing (packet forwarding)
data flow) nodes on the path between a sender and a receiver. Routers tables.
along the path of a PATH message forward the message towards the
destination address based on the L3 routing (packet forwarding) tables.
For example, consider the L2 domain in Figure 1. Assume that both the For example, consider the L2 domain in Figure 1. Assume that both the
sender (some host X) and the receiver (some host Y) in a RSVP session sender (some host X) and the receiver (some host Y) in a RSVP session
reside outside the L2 domain shown in the Figure, but PATH messages reside outside the L2 domain shown in the Figure, but PATH messages
from the sender to its receiver pass through the routers in the L2 from the sender to its receiver pass through the routers in the L2
domain using it as a transit subnet. Assume that the PATH message from domain using it as a transit subnet. Assume that the PATH message
the sender X arrives at the router R1. R1 uses its local routing from the sender X arrives at the router R1. R1 uses its local routing
information to decide which next hop router (either router R2 or information to decide which next hop router (either router R2 or
router R3) to use to forward the PATH message towards host Y. However, router R3) to use to forward the PATH message towards host Y.
when the path traverses a managed L2 domain, we require the PATH and However, when the path traverses a managed L2 domain, we require the
RESV messages to go through a DSBM for each managed segment. Such a L2 PATH and RESV messages to go through a DSBM for each managed segment.
domain may span many managed segments (and DSBMs) and, typically, SBM Such a L2 domain may span many managed segments (and DSBMs) and,
protocol entities on L2 devices (such as a switch) will serve as the typically, SBM protocol entities on L2 devices (such as a switch)
DSBMs for the managed segments in a switched topology. When R1 forwards will serve as the DSBMs for the managed segments in a switched
the PATH message to the DSBM (an L2 device), the DSBM may not topology. When R1 forwards the PATH message to the DSBM (an L2
have the L3 routing information necessary to select the egress router device), the DSBM may not have the L3 routing information necessary
(between R2 and R3) before forwarding the PATH message. To ensure to select the egress router (between R2 and R3) before forwarding the
correct operation and routing of RSVP messages, we must provide PATH message. To ensure correct operation and routing of RSVP
additional forwarding information to DSBMs. messages, we must provide additional forwarding information to DSBMs.
For this purpose, we introduce new RSVP objects called LAN_NHOP For this purpose, we introduce new RSVP objects called LAN_NHOP
address objects that keep track of the next L3 hop as the PATH message address objects that keep track of the next L3 hop as the PATH
traverses an L2 domain between two L3 entities (RSVP PHOP and NHOP message traverses an L2 domain between two L3 entities (RSVP PHOP and
nodes). NHOP nodes).
4.2.2.3 Including Both Layer-2 and Layer-3 Addresses in the LAN_NHOP 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 When a DSBM client (a host or a router acting as the originator of a
PATH message) sends out a PATH message to the DSBM, it must include PATH message) sends out a PATH message to the DSBM, it must include
LAN_NHOP information in the message. In the case of a unicast destination, LAN_NHOP information in the message. In the case of a unicast
the LAN_NHOP address specifies the destination address (if the destination, the LAN_NHOP address specifies the destination address
destination is local to its L2 domain) or the address of the next hop (if the destination is local to its L2 domain) or the address of the
router towards the destination. In our example of an RSVP session next hop router towards the destination. In our example of an RSVP
involving the sender X and receiver Y with L2 domain in Figure 1 acting session involving the sender X and receiver Y with L2 domain in
as the transit subnet, R1 is the ingress node that receives the Figure 1 acting as the transit subnet, R1 is the ingress node that
PATH message. R1 first determines that R2 is the next hop router (or receives the PATH message. R1 first determines that R2 is the next
the egress node in the L2 domain for the session address) and then hop router (or the egress node in the L2 domain for the session
inserts a LAN_NHOP object that specifies R2's IP address. When a DSBM address) and then inserts a LAN_NHOP object that specifies R2's IP
receives a PATH message, it can now look at the address in the address. When a DSBM receives a PATH message, it can now look at the
LAN_NHOP object and forward the PATH message towards the egress node address in the LAN_NHOP object and forward the PATH message towards
after processing the PATH message. However, we expect the L2 devices the egress node after processing the PATH message. However, we
(such as switches) to act as DSBMs on the path within the L2 domain expect the L2 devices (such as switches) to act as DSBMs on the path
and it may not be reasonable to expect these devices to have an ARP within the L2 domain and it may not be reasonable to expect these
capability to determine the MAC address (we call it L2ADDR for Layer 2 devices to have an ARP capability to determine the MAC address (we
call it L2ADDR for Layer 2 address) corresponding to the IP address
SBM (Subnet Bandwidth Manager) January, 2000 in the LAN_NHOP object.
address) corresponding to the IP address in the LAN_NHOP object.
Therefore, we require that the LAN_NHOP information (generated by the Therefore, we require that the LAN_NHOP information (generated by the
L3 device) include both the IP address (LAN_NHOP_L3 address) and the L3 device) include both the IP address (LAN_NHOP_L3 address) and the
corresponding MAC address (LAN_NHOP_L2 address ) for the next L3 hop corresponding MAC address (LAN_NHOP_L2 address ) for the next L3 hop
over the L2 domain. The LAN_NHOP_L3 address is used by SBM protocol over the L2 domain. The LAN_NHOP_L3 address is used by SBM protocol
entities on L3 devices to forward the PATH message towards its destination entities on L3 devices to forward the PATH message towards its
whereas the L2 address is used by the SBM protocol entities on destination whereas the L2 address is used by the SBM protocol
L2 devices to determine how to forward the PATH message towards the L3 entities on L2 devices to determine how to forward the PATH message
NHOP (egress point from the L2 domain). The exact format of the towards the L3 NHOP (egress point from the L2 domain). The exact
LAN_NHOP information and relevant objects is described later in format of the LAN_NHOP information and relevant objects is described
Appendix B. later in Appendix B.
4.2.2.4 Similarities to Standard RSVP Message Processing
- When a DSBM receives a RSVP PATH message, it processes the PATH
message according to the PATH processing rules described in the
RSVP specification. In particular, the DSBM retrieves the IP
address of the previous hop from the RSVP_HOP object in the PATH
message and stores the PHOP address in its PATH state. It then
forwards the PATH message with the PHOP (RSVP_HOP) object modified
to reflect its own IP address (RSVP_HOP_L3 address). Thus,
the DSBM inserts itself as an intermediate hop in the chain of
nodes in the path between two L3 nodes across the L2 domain.
- The PATH state in a DSBM is used for forwarding subsequent RESV 4.2.2.4 Similarities to Standard RSVP Message Processing
messages as per the standard RSVP message processing rules. When
the DSBM receives a RESV message, it processes the message and
forwards it to appropriate PHOP(s) based on its PATH state.
- Because a DSBM inserts itself as a hop between two RSVP nodes in - When a DSBM receives a RSVP PATH message, it processes the PATH
the path of a RSVP flow, all RSVP related messages (such as PATH, message according to the PATH processing rules described in the
PATH_TEAR, RESV, RESV_CONF, RESV_TEAR, and RESV_ERR) now flow RSVP specification. In particular, the DSBM retrieves the IP
through the DSBM. In particular, a PATH_TEAR message is routed address of the previous hop from the RSVP_HOP object in the PATH
exactly through the intermediate DSBM(s) as its corresponding message and stores the PHOP address in its PATH state. It then
PATH message and the local PATH state is first cleaned up at each forwards the PATH message with the PHOP (RSVP_HOP) object modified
intermediate hop before the PATH_TEAR message gets forwarded. to reflect its own IP address (RSVP_HOP_L3 address). Thus, the
DSBM inserts itself as an intermediate hop in the chain of nodes
in the path between two L3 nodes across the L2 domain.
- So far, we have described how the PATH message propagates through - The PATH state in a DSBM is used for forwarding subsequent RESV
the L2 domain establishing PATH state at each DSBM along the messages as per the standard RSVP message processing rules. When
managed segments in the path. The layer 2 address (LAN_NHOP_L2 the DSBM receives a RESV message, it processes the message and
address) in the LAN_NHOP object should be used by the L2 devices forwards it to appropriate PHOP(s) based on its PATH state.
along the path to decide how to forward the PATH message toward
the next L3 hop. Such devices will apply the standard IEEE
SBM (Subnet Bandwidth Manager) January, 2000 - Because a DSBM inserts itself as a hop between two RSVP nodes in
the path of a RSVP flow, all RSVP related messages (such as PATH,
PATH_TEAR, RESV, RESV_CONF, RESV_TEAR, and RESV_ERR) now flow
through the DSBM. In particular, a PATH_TEAR message is routed
exactly through the intermediate DSBM(s) as its corresponding PATH
message and the local PATH state is first cleaned up at each
intermediate hop before the PATH_TEAR message gets forwarded.
802.1D forwarding rules (e.g., send it on a single port based on - So far, we have described how the PATH message propagates through
its filtering database, or flood it on all ports active in the the L2 domain establishing PATH state at each DSBM along the
spanning tree if the L2 address does not appear in the filtering managed segments in the path. The layer 2 address (LAN_NHOP_L2
database) to the LAN_NHOP_L2 address as are applied normally to address) in the LAN_NHOP object should be used by the L2 devices
data packets destined to the address. along the path to decide how to forward the PATH message toward
the next L3 hop. Such devices will apply the standard IEEE 802.1D
forwarding rules (e.g., send it on a single port based on its
filtering database, or flood it on all ports active in the
spanning tree if the L2 address does not appear in the filtering
database) to the LAN_NHOP_L2 address as are applied normally to
data packets destined to the address.
4.2.2.5 Including Both Layer-2 and Layer-3 Addresses in the 4.2.2.5 Including Both Layer-2 and Layer-3 Addresses in the RSVP_HOP
RSVP_HOP Objects Objects
In the conventional RSVP message processing, the PATH state In the conventional RSVP message processing, the PATH state
established along the nodes on a path is used to route the RESV message established along the nodes on a path is used to route the RESV
from a receiver to a sender in an RSVP session. As each intermediate message from a receiver to a sender in an RSVP session. As each
node builds the path state, it remembers the previous hop (stores the intermediate node builds the path state, it remembers the previous
PHOP IP address available in the RSVP_HOP object of an incoming hop (stores the PHOP IP address available in the RSVP_HOP object of
message) that sent it the PATH message and, when the RESV message an incoming message) that sent it the PATH message and, when the RESV
arrives, the intermediate node simply uses the stored PHOP address to message arrives, the intermediate node simply uses the stored PHOP
forward the RESV after processing it successfully. address to forward the RESV after processing it successfully.
In our case, we expect the SBM entities residing at L2 devices to act In our case, we expect the SBM entities residing at L2 devices to act
as DSBMs (and, therefore, intermediate RSVP hops in an L2 domain) as DSBMs (and, therefore, intermediate RSVP hops in an L2 domain)
along the path between a sender (PHOP) and receiver (NHOP). Thus, when along the path between a sender (PHOP) and receiver (NHOP). Thus,
a RESV message arrives at a DSBM, it must use the stored PHOP IP when a RESV message arrives at a DSBM, it must use the stored PHOP IP
address to forward the RESV message to its previous hop. However, it address to forward the RESV message to its previous hop. However, it
may not be reasonable to expect the L2 devices to have an ARP cache or may not be reasonable to expect the L2 devices to have an ARP cache
the ARP capability to map the PHOP IP address to its corresponding L2 or the ARP capability to map the PHOP IP address to its corresponding
address before forwarding the RESV message. L2 address before forwarding the RESV message.
To obviate the need for such address mapping at L2 devices, we use a To obviate the need for such address mapping at L2 devices, we use a
RSVP_HOP_L2 object in the PATH message. The RSVP_HOP_L2 object RSVP_HOP_L2 object in the PATH message. The RSVP_HOP_L2 object
includes the Layer 2 address (L2ADDR) of the previous hop and complements includes the Layer 2 address (L2ADDR) of the previous hop and
the L3 address information included in the RSVP_HOP object complements the L3 address information included in the RSVP_HOP
(RSVP_HOP_L3 address). object (RSVP_HOP_L3 address).
When a L3 device constructs and forwards a PATH message over a managed When a L3 device constructs and forwards a PATH message over a
segment, it includes its IP address (IP address of the interface over managed segment, it includes its IP address (IP address of the
which PATH is sent) in the RSVP_HOP object and adds a RSVP_HOP_L2 interface over which PATH is sent) in the RSVP_HOP object and adds a
object that includes the corresponding L2 address for the interface. RSVP_HOP_L2 object that includes the corresponding L2 address for the
When a device in the L2 domain receives such a PATH message, it interface. When a device in the L2 domain receives such a PATH
remembers the addresses in the RSVP_HOP and RSVP_HOP_L2 objects in its message, it remembers the addresses in the RSVP_HOP and RSVP_HOP_L2
PATH state and then overwrites the RSVP_HOP and RSVP_HOP_L2 objects objects in its PATH state and then overwrites the RSVP_HOP and
with its own addresses before forwarding the PATH message over a RSVP_HOP_L2 objects with its own addresses before forwarding the PATH
managed segment. message over a managed segment.
The exact format of RSVP_HOP_L2 object is specified in Appendix B. The exact format of RSVP_HOP_L2 object is specified in Appendix B.
4.2.2.6 Loop Detection 4.2.2.6 Loop Detection
When an RSVP session address is a multicast address and a SBM, DSBM, When an RSVP session address is a multicast address and a SBM, DSBM,
SBM (Subnet Bandwidth Manager) January, 2000
and DSBM clients share the same L2 segment (a shared segment), it is and DSBM clients share the same L2 segment (a shared segment), it is
possible for a SBM or a DSBM client to receive one or more copies of a possible for a SBM or a DSBM client to receive one or more copies of
PATH message that it forwarded earlier when a DSBM on the same wire a PATH message that it forwarded earlier when a DSBM on the same wire
forwards it (See Section 5.8 for an example of such a case). To facilitate forwards it (See Section 5.7 for an example of such a case). To
detection of such loops, we use a new RSVP object called the facilitate detection of such loops, we use a new RSVP object called
LAN_LOOPBACK object. DSBM clients or SBMs (but not the DSBMs reflecting the LAN_LOOPBACK object. DSBM clients or SBMs (but not the DSBMs
a PATH message onto the interface over which it arrived earlier) reflecting a PATH message onto the interface over which it arrived
must overwrite (or add if the PATH message does NOT already include a earlier) must overwrite (or add if the PATH message does NOT already
LAN_LOOPBACK object) the LAN_LOOPBACK object in the PATH message with include a LAN_LOOPBACK object) the LAN_LOOPBACK object in the PATH
their own unicast IP address. message with their own unicast IP address.
Now, a SBM or a DSBM client can easily detect and discard the duplicates Now, a SBM or a DSBM client can easily detect and discard the
by checking the contents of the LAN_LOOPBACK object (a duplicate duplicates by checking the contents of the LAN_LOOPBACK object (a
PATH message will list a device's own interface address in the duplicate PATH message will list a device's own interface address in
LAN_LOOPBACK object). Appendix B specifies the exact format of the the LAN_LOOPBACK object). Appendix B specifies the exact format of
LAN_LOOPBACK object. the LAN_LOOPBACK object.
4.2.2.7 802.1p, User Priority and TCLASS 4.2.2.7 802.1p, User Priority and TCLASS
The model proposed by the Integrated Services working group requires The model proposed by the Integrated Services working group requires
isolation of traffic flows from each other during their transit across isolation of traffic flows from each other during their transit
a network. The motivation for traffic flow separation is to provide across a network. The motivation for traffic flow separation is to
Integrated Services flows protection from misbehaving flows and other provide Integrated Services flows protection from misbehaving flows
best-effort traffic that share the same path. The basic IEEE and other best-effort traffic that share the same path. The basic
802.3/Ethernet networks do not provide any notion of traffic classes IEEE 802.3/Ethernet networks do not provide any notion of traffic
to discriminate among different flows that request different services. classes to discriminate among different flows that request different
However, IEEE 802.1p defines a way for switches to differentiate among services. However, IEEE 802.1p defines a way for switches to
several "user_priority" values encoded in packets representing different differentiate among several "user_priority" values encoded in packets
traffic classes (see [IEEE802Q, IEEE8021p] for further representing different traffic classes (see [IEEE802Q, IEEE8021p] for
details). The user_priority values can be encoded either in native LAN further details). The user_priority values can be encoded either in
packets (e.g., in IEEE 802.5's FC octet) or by using an encapsulation native LAN packets (e.g., in IEEE 802.5's FC octet) or by using an
above the MAC layer (e.g., in the case of Ethernet, the user_priority encapsulation above the MAC layer (e.g., in the case of Ethernet, the
value assigned to each packet will be carried in the frame header user_priority value assigned to each packet will be carried in the
using the new, extended frame format defined by IEEE 802.1Q frame header using the new, extended frame format defined by IEEE
[IEEE8021Q]. IEEE, however, makes no recommendations about how a 802.1Q [IEEE8021Q]. IEEE, however, makes no recommendations about how
sender or network should use the user_priority values. An accompanying a sender or network should use the user_priority values. An
document makes recommendations on the usage of the user_priority accompanying document makes recommendations on the usage of the
values (see [RFC-MAP] for details). user_priority values (see [RFC-MAP] for details).
Under the Integrated Services model, L3 (or higher) entities that Under the Integrated Services model, L3 (or higher) entities that
transmit traffic flows onto a L2 segment should perform per-flow policing transmit traffic flows onto a L2 segment should perform per-flow
to ensure that the flows do not exceed their traffic specification policing to ensure that the flows do not exceed their traffic
as specified during admission control. In addition, L3 devices specification as specified during admission control. In addition, L3
may label the frames in such flows with a user_priority value to devices may label the frames in such flows with a user_priority value
identify their service class. to identify their service class.
For the purpose of this discussion, we will refer to the user_priority
value carried in the extended frame header as the "traffic class" of a
SBM (Subnet Bandwidth Manager) January, 2000
packet. Under the ISSLL model, the L3 entities, that send traffic and For the purpose of this discussion, we will refer to the
that use the SBM protocol, may select the appropriate traffic class of user_priority value carried in the extended frame header as the
outgoing packets [RFC-MAP]. This selection may be overridden by DSBM "traffic class" of a packet. Under the ISSLL model, the L3 entities,
devices, in the following manner. once a sender sends a PATH message, that send traffic and that use the SBM protocol, may select the
downstream DSBMs will insert a new traffic class object (TCLASS appropriate traffic class of outgoing packets [RFC-MAP]. This
object) in the PATH message that travels to the next L3 device (L3 selection may be overridden by DSBM devices, in the following manner.
NHOP for the PATH message). To some extent, the TCLASS object contents once a sender sends a PATH message, downstream DSBMs will insert a
are treated like the ADSPEC object in the RSVP PATH messages. The L3 new traffic class object (TCLASS object) in the PATH message that
device that receives the PATH message must remove and store the TCLASS travels to the next L3 device (L3 NHOP for the PATH message). To some
object as part of its PATH state for the session. Later, when the same extent, the TCLASS object contents are treated like the ADSPEC object
L3 device needs to forward a RSVP RESV message towards the original in the RSVP PATH messages. The L3 device that receives the PATH
sender, it must include the TCLASS object in the RESV message. When message must remove and store the TCLASS object as part of its PATH
the RESV message arrives at the original sender, the sender must use state for the session. Later, when the same L3 device needs to
the user_priority value from the TCLASS object to override its forward a RSVP RESV message towards the original sender, it must
selection for the traffic class marked in outgoing packets. include the TCLASS object in the RESV message. When the RESV message
arrives at the original sender, the sender must use the user_priority
value from the TCLASS object to override its selection for the
traffic class marked in outgoing packets.
The format of the TCLASS object is specified in Appendix B. Note that The format of the TCLASS object is specified in Appendix B. Note
TCLASS and other SBM-specific objects are carried in a RSVP message in that TCLASS and other SBM-specific objects are carried in a RSVP
addition to all the other, normal RSVP objects per RFC 2205. message in addition to all the other, normal RSVP objects per RFC
2205.
4.2.2.8 Processing the TCLASS Object 4.2.2.8 Processing the TCLASS Object
In summary, use of TCLASS objects requires following additions to the In summary, use of TCLASS objects requires following additions to the
conventional RSVP message processing at DSBMs, SBMs, and DSBM clients: conventional RSVP message processing at DSBMs, SBMs, and DSBM
clients:
* When a DSBM receives a PATH message over a managed segment and
the PATH message does not include a TCLASS object, the DSBM MAY
add a TCLASS object to the PATH message before forwarding it.
The DSBM determines the appropriate user_priority value for the
TCLASS object. A mechanism for selecting the appropriate
user_priority value is described in an accompanying document
[RFC-MAP].
* When SBM or DSBM receives a PATH message with a TCLASS object
over a managed segment in a L2 domain and needs to forward it
over a managed segment in the same L2 domain, it will store it
in its path state and typically forward the message without
changing the contents of the TCLASS object. However, if the
DSBM/SBM cannot support the service class represented by the
user_priority value specified by the TCLASS object in the PATH
message, it may change the priority value in the TCLASS to a
semantically "lower" service value to reflect its capability
and store the changed TCLASS value in its path state.
[NOTE: An accompanying document defines the int-serv mappings
SBM (Subnet Bandwidth Manager) January, 2000
over IEEE 802 networks [RFC-MAP] provides a precise definition * When a DSBM receives a PATH message over a managed segment and the
of user_priority values and describes how the user_priority PATH message does not include a TCLASS object, the DSBM MAY add a
values are compared to determine "lower" of the two values or TCLASS object to the PATH message before forwarding it. The DSBM
the "lowest" among all the user_priority values.] determines the appropriate user_priority value for the TCLASS
object. A mechanism for selecting the appropriate user_priority
value is described in an accompanying document [RFC-MAP].
* When a DSBM receives a RESV message with a TCLASS object, it * When SBM or DSBM receives a PATH message with a TCLASS object over
may use the traffic class information (in addition to the usual a managed segment in a L2 domain and needs to forward it over a
flowspec information in the RSVP message) for its own admission managed segment in the same L2 domain, it will store it in its
control for the managed segment. path state and typically forward the message without changing the
contents of the TCLASS object. However, if the DSBM/SBM cannot
support the service class represented by the user_priority value
specified by the TCLASS object in the PATH message, it may change
the priority value in the TCLASS to a semantically "lower" service
value to reflect its capability and store the changed TCLASS value
in its path state.
Note that this document does not specify the actual algorithm [NOTE: An accompanying document defines the int-serv mappings over
or policy used for admission control. At one extreme, a DSBM IEEE 802 networks [RFC-MAP] provides a precise definition of
may use per-flow reservation request as specified by the user_priority values and describes how the user_priority values
flowspec for a fine grain admission control. At the other are compared to determine "lower" of the two values or the
extreme, a DSBM may only consider the traffic class information "lowest" among all the user_priority values.]
for a very coarse-grain admission control based on some static
allocation of link capacity for each traffic class. Any
combination of the options represented by these two extremes
may also be used.
* When a DSBM (at an L2 or L3) device receives a RESV message * When a DSBM receives a RESV message with a TCLASS object, it may
without a TCLASS object and it needs to forward the RESV use the traffic class information (in addition to the usual
message over a managed segment within the same L2 domain, it flowspec information in the RSVP message) for its own admission
should first check its path state and check whether it has control for the managed segment.
stored a TCLASS value. If so, it should include the TCLASS
object in the outgoing RESV message after performing its own
admission control. If no TCLASS value is stored, it must
forward the RESV message without inserting a TCLASS object.
* When a DSBM client (residing at an L3 device such as a host or Note that this document does not specify the actual algorithm or
an edge router) receives the TCLASS object in a PATH message policy used for admission control. At one extreme, a DSBM may use
that it accepts over an interface, it should store the TCLASS per-flow reservation request as specified by the flowspec for a
object as part of its PATH state for the interface. Later, when fine grain admission control. At the other extreme, a DSBM may
the client forwards a RESV message for the same session on the only consider the traffic class information for a very coarse-
interface, the client must include the TCLASS object (unchanged grain admission control based on some static allocation of link
from what was received in the previous PATH message) in the capacity for each traffic class. Any combination of the options
RESV message it forwards over the interface. represented by these two extremes may also be used.
* When a DSBM client receives a TCLASS object in an incoming RESV * When a DSBM (at an L2 or L3) device receives a RESV message
message over a managed segment and local admission control without a TCLASS object and it needs to forward the RESV message
succeeds for the session for the outgoing interface over the over a managed segment within the same L2 domain, it should first
managed segment, the client must pass the user_priority value check its path state and check whether it has stored a TCLASS
in the TCLASS object to its local packet classifier. This will value. If so, it should include the TCLASS object in the outgoing
ensure that the data packets in the admitted RSVP flow that are RESV message after performing its own admission control. If no
subsequently forwarded over the outgoing interface will contain TCLASS value is stored, it must forward the RESV message without
inserting a TCLASS object.
SBM (Subnet Bandwidth Manager) January, 2000 * When a DSBM client (residing at an L3 device such as a host or an
edge router) receives the TCLASS object in a PATH message that it
accepts over an interface, it should store the TCLASS object as
part of its PATH state for the interface. Later, when the client
forwards a RESV message for the same session on the interface, the
client must include the TCLASS object (unchanged from what was
received in the previous PATH message) in the RESV message it
forwards over the interface.
the appropriate value encoded in their frame header. * When a DSBM client receives a TCLASS object in an incoming RESV
message over a managed segment and local admission control
succeeds for the session for the outgoing interface over the
managed segment, the client must pass the user_priority value in
the TCLASS object to its local packet classifier. This will ensure
that the data packets in the admitted RSVP flow that are
subsequently forwarded over the outgoing interface will contain
the appropriate value encoded in their frame header.
* When an L3 device receives a PATH or RESV message over a * When an L3 device receives a PATH or RESV message over a managed
managed segment in one L2 domain and it needs to forward the segment in one L2 domain and it needs to forward the PATH/RESV
PATH/RESV message over an interface outside that domain, the L3 message over an interface outside that domain, the L3 device must
device must remove the TCLASS object (along with LAN_NHOP, remove the TCLASS object (along with LAN_NHOP, RSVP_HOP_L2, and
RSVP_HOP_L2, and LAN_LOOPBACK objects in the case of the PATH LAN_LOOPBACK objects in the case of the PATH message) before
message) before forwarding the PATH/RESV message. If the outgoing forwarding the PATH/RESV message. If the outgoing interface is on
interface is on a separate L2 domain, these objects may be a separate L2 domain, these objects may be regenerated according
regenerated according to the processing rules applicable to to the processing rules applicable to that interface.
that interface.
5. Detailed Message Processing Rules 5. Detailed Message Processing Rules
5.1. Additional Notes on Terminology 5.1. Additional Notes on Terminology
* An L2 device may have several interfaces with attached segments * An L2 device may have several interfaces with attached segments
that are part of the same L2 domain. A switch in a L2 domain is that are part of the same L2 domain. A switch in a L2 domain is an
an example of such a device. A device which has several interfaces example of such a device. A device which has several interfaces
may contain a SBM protocol entity that acts in different may contain a SBM protocol entity that acts in different
capacities on each interface. For example, a SBM protocol entity capacities on each interface. For example, a SBM protocol entity
could act as a SBM on interface A, and act as a DSBM on interface could act as a SBM on interface A, and act as a DSBM on interface
B. B.
* A SBM protocol entity on a layer 3 device can be a DSBM client, * A SBM protocol entity on a layer 3 device can be a DSBM client,
and SBM, a DSBM, or none of the above (SBM transparent). and SBM, a DSBM, or none of the above (SBM transparent). Non-
Non-transparent L3 devices can implement any combination of these transparent L3 devices can implement any combination of these
roles simultaneously. DSBM clients always reside at L3 devices. roles simultaneously. DSBM clients always reside at L3 devices.
* A SBM protocol entity residing at a layer 2 device can be a SBM, * A SBM protocol entity residing at a layer 2 device can be a SBM, a
a DSBM or none of the above (SBM transparent). A layer 2 device DSBM or none of the above (SBM transparent). A layer 2 device will
will never host a DSBM client. never host a DSBM client.
5.2. Use Of Reserved IP Multicast Addresses 5.2. Use Of Reserved IP Multicast Addresses
As stated earlier, we require that the DSBM clients forward the RSVP As stated earlier, we require that the DSBM clients forward the RSVP
PATH messages to their DSBMs in a L2 domain before they reach the next PATH messages to their DSBMs in a L2 domain before they reach the
next L3 hop in the path. RSVP PATH messages are addressed, according
SBM (Subnet Bandwidth Manager) January, 2000 to RFC-2205, to their destination address (which can be either an IP
unicast or multicast address). When a L2 device hosts a DSBM, a
L3 hop in the path. RSVP PATH messages are addressed, according to
RFC-2205, to their destination address (which can be either an IP unicast
or multicast address). When a L2 device hosts a DSBM, a
simple-to-implement mechanism must be provided for the device to simple-to-implement mechanism must be provided for the device to
capture an incoming PATH message and hand it over to the local DSBM 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. 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 In addition, DSBM clients need to know how to address SBM messages to
the DSBM. For the ease of operation and to allow dynamic DSBM-client the DSBM. For the ease of operation and to allow dynamic DSBM-client
binding, it should be possible to easily detect and address the existing binding, it should be possible to easily detect and address the
DSBM on a managed segment. existing DSBM on a managed segment.
To facilitate dynamic DSBM-client binding as well as to enable easy To facilitate dynamic DSBM-client binding as well as to enable easy
detection and capture of PATH messages at L2 devices, we require that detection and capture of PATH messages at L2 devices, we require that
a DSBM be addressed using a logical address rather than a physical a DSBM be addressed using a logical address rather than a physical
address. We make use of reserved IP multicast address(es) for the purpose address. We make use of reserved IP multicast address(es) for the
of communication with a DSBM. In particular, we require that purpose of communication with a DSBM. In particular, we require that
when a DSBM client or a SBM forwards a PATH message over a managed when a DSBM client or a SBM forwards a PATH message over a managed
segment, it is addressed to a reserved IP multicast address. Thus, a segment, it is addressed to a reserved IP multicast address. Thus, a
DSBM on a L2 device needs to be configured in a way to make it easy to DSBM on a L2 device needs to be configured in a way to make it easy
intercept the PATH message and forward it to the local SBM protocol to intercept the PATH message and forward it to the local SBM
entity. For example, this may involve simply adding a static entry in protocol entity. For example, this may involve simply adding a static
the device's filtering database (FDB) for the corresponding MAC multicast entry in the device's filtering database (FDB) for the corresponding
address to ensure the PATH messages get intercepted and are not MAC multicast address to ensure the PATH messages get intercepted and
forwarded further without the DSBM intervention. are not forwarded further without the DSBM intervention.
Similarly, a DSBM always sends the PATH messages over a managed segment Similarly, a DSBM always sends the PATH messages over a managed
using a reserved IP multicast address and, thus, the SBMs or DSBM segment using a reserved IP multicast address and, thus, the SBMs or
clients on the managed segments must simply be configured to intercept DSBM clients on the managed segments must simply be configured to
messages addressed to the reserved multicast address on the appropriate intercept messages addressed to the reserved multicast address on the
interfaces to easily receive PATH messages. appropriate interfaces to easily receive PATH messages.
RSVP RESV messages continue to be unicast to the previous hop address RSVP RESV messages continue to be unicast to the previous hop address
stored as part of the PATH state at each intermediate hop. stored as part of the PATH state at each intermediate hop.
We define use of two reserved IP multicast addresses. We call these We define use of two reserved IP multicast addresses. We call these
the "AllSBM Address" and the "DSBMLogicalAddress". These are chosen the "AllSBM Address" and the "DSBMLogicalAddress". These are chosen
from the range of local multicast addresses, such that: from the range of local multicast addresses, such that:
* They are not passed through layer 3 devices. * They are not passed through layer 3 devices.
* They are passed transparently through layer 2 devices which are
SBM transparent.
SBM (Subnet Bandwidth Manager) January, 2000 * They are passed transparently through layer 2 devices which are
SBM transparent.
* They are configured in the permanent database of layer 2 devices * They are configured in the permanent database of layer 2 devices
which host SBMs or DSBMs, such that they are directed to the SBM which host SBMs or DSBMs, such that they are directed to the SBM
management entity in these devices. This obviates the need for management entity in these devices. This obviates the need for
these devices to explicitly snoop for SBM related control these devices to explicitly snoop for SBM related control packets.
packets.
* The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress) * The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress) and
and 224.0.0.17 (AllSBMAddress). 224.0.0.17 (AllSBMAddress).
These addresses are used as described in the following table: These addresses are used as described in the following table:
Type DSBMLogicaladdress AllSBMAddress Type DSBMLogicaladdress AllSBMAddress
DSBM * Sends PATH messages * Monitors this address to detect DSBM * Sends PATH messages * Monitors this address to detect
Client to this address the presence of a DSBM Client to this address the presence of a DSBM
* Monitors this address to * Monitors this address to
receive PATH messages receive PATH messages
forwarded by the DSBM forwarded by the DSBM
SBM * Sends PATH messages * Monitors and sends on this SBM * Sends PATH messages * Monitors and sends on this
to this address address to participate in to this address address to participate in
election of the DSBM election of the DSBM
* Monitors this address to * Monitors this address to
receive PATH messages receive PATH messages
forwarded by the DSBM forwarded by the DSBM
DSBM * Monitors this address * Monitors and sends on this DSBM * Monitors this address * Monitors and sends on this
for PATH messages to participate in election for PATH messages to participate in election
directed to it of the DSBM directed to it of the DSBM
* Sends PATH messages to this * Sends PATH messages to this
address address
The L2 or MAC addresses corresponding to IP multicast addresses are The L2 or MAC addresses corresponding to IP multicast addresses are
computed algorithmically using a reserved L2 address block (the high computed algorithmically using a reserved L2 address block (the high
order 24-bits are 00:00:5e). The Assigned Numbers RFC [RFC-1700] gives order 24-bits are 00:00:5e). The Assigned Numbers RFC [RFC-1700]
additional details. gives additional details.
5.3. Layer 3 to Layer 2 Address Mapping 5.3. Layer 3 to Layer 2 Address Mapping
As stated earlier, DSBMs or DSBM clients residing at a L3 device must As stated earlier, DSBMs or DSBM clients residing at a L3 device must
include a LAN_NHOP_L2 address in the LAN_NHOP information so that L2 include a LAN_NHOP_L2 address in the LAN_NHOP information so that L2
devices along the path of a PATH message do not need to separately devices along the path of a PATH message do not need to separately
determine the mapping between the LAN_NHOP_L3 address in the LAN_NHOP determine the mapping between the LAN_NHOP_L3 address in the LAN_NHOP
object and its corresponding L2 address (for example, using ARP). object and its corresponding L2 address (for example, using ARP).
SBM (Subnet Bandwidth Manager) January, 2000
For the purpose of such mapping at L3 devices, we assume a mapping For the purpose of such mapping at L3 devices, we assume a mapping
function called "map_address" that performs the necessary mapping: function called "map_address" that performs the necessary mapping:
L2ADDR object = map_addr(L3Addr) L2ADDR object = map_addr(L3Addr)
We do not specify how the function is implemented; the implementation We do not specify how the function is implemented; the implementation
may simply involve access to the local ARP cache entry or may require may simply involve access to the local ARP cache entry or may require
performing an ARP function. The function returns a L2ADDR object that performing an ARP function. The function returns a L2ADDR object
need not be interpreted by an L3 device and can be treated as an that need not be interpreted by an L3 device and can be treated as an
opaque object. The format of the L2ADDR object is specified in opaque object. The format of the L2ADDR object is specified in
Appendix B. Appendix B.
5.4. Raw vs. UDP Encapsulation 5.4. Raw vs. UDP Encapsulation
We assume that the DSBMs, DSBM clients, and SBMs use only raw IP for We assume that the DSBMs, DSBM clients, and SBMs use only raw IP for
encapsulating RSVP messages that are forwarded onto a L2 domain. encapsulating RSVP messages that are forwarded onto a L2 domain.
Thus, when a SBM protocol entity on a L3 device forwards a RSVP Thus, when a SBM protocol entity on a L3 device forwards a RSVP
message onto a L2 segment, it will only use RAW IP encapsulation. message onto a L2 segment, it will only use RAW IP encapsulation.
5.5. The Forwarding Rules 5.5. The Forwarding Rules
The message processing and forwarding rules will be described in the The message processing and forwarding rules will be described in the
context of the sample network illustrated in Figure 2. context of the sample network illustrated in Figure 2.
SBM (Subnet Bandwidth Manager) January, 2000
Figure 2 - A sample network or L2 domain consisting of switched and Figure 2 - A sample network or L2 domain consisting of switched and
shared L2 segments shared L2 segments
.......... ..........
. .
+------+ . +------+ seg A +------+ seg C +------+ seg D +------+ +------+ . +------+ seg A +------+ seg C +------+ seg D +------+
| H1 |_______| R1 |_________| S1 |_________| S2 |_________| H2 | | H1 |_______| R1 |_________| S1 |_________| S2 |_______| H2 |
| | . | | | | | | | | | | . | | | | | | | |
+------+ . +------+ +------+ +------+ +------+ +------+ . +------+ +------+ +------+ +------+
. | / . | /
1.0.0.0 . | / 1.0.0.0 . | /
. |___ / . |___ /
. seg B | / seg E . seg B | / seg E
.......... | / .......... | /
2.0.0.0 | / 2.0.0.0 | /
+-----------+ +-----------+
| S3 | | S3 |
| | | |
+-----------+ +-----------+
| |
| |
| |
| |
seg F | ................. seg F | .................
------------------------------ . ------------------------------ .
| | | . | | | .
+------+ +------+ +------+ . +------+ +------+ +------+ +------+ . +------+
| H3 | | H4 | | R2 |____________| H5 | | H3 | | H4 | | R2 |____________| H5 |
| | | | | | . | | | | | | | | . | |
+------+ +------+ +------+ . +------+ +------+ +------+ +------+ . +------+
. .
. 3.0.0.0 . 3.0.0.0
................. .................
Figure 2 illustrates a sample network topology consisting of three IP Figure 2 illustrates a sample network topology consisting of three IP
subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) interconnected using two subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) interconnected using two
routers. The subnet 2.0.0.0 is an example of a L2 domain consisting of routers. The subnet 2.0.0.0 is an example of a L2 domain consisting
switches, hosts, and routers interconnected using switched segments of switches, hosts, and routers interconnected using switched
and a shared L2 segment. The sample network contains the following segments and a shared L2 segment. The sample network contains the
devices: following devices:
Device Type SBM Type Device Type SBM Type
H1, H5 Host (layer 3) SBM Transparent H1, H5 Host (layer 3) SBM Transparent
H2-H4 Host (layer 3) DSBM Client H2-H4 Host (layer 3) DSBM Client
R1 Router (layer 3) SBM R1 Router (layer 3) SBM
R2 Router (layer 3) DSBM for segment F R2 Router (layer 3) DSBM for segment F
SBM (Subnet Bandwidth Manager) January, 2000
S1 Switch (layer 2) DSBM for segments A, B S1 Switch (layer 2) DSBM for segments A, B
S2 Switch (layer 2) DSBM for segments C, D, E S2 Switch (layer 2) DSBM for segments C, D, E
S3 Switch (layer 2) SBM S3 Switch (layer 2) SBM
The following paragraphs describe the rules, which each of these devices The following paragraphs describe the rules, which each of these
should use to forward PATH messages (rules apply to PATH_TEAR devices should use to forward PATH messages (rules apply to PATH_TEAR
messages as well). They are described in the context of the general messages as well). They are described in the context of the general
network illustrated above. While the examples do not address every network illustrated above. While the examples do not address every
scenario, they do address most of the interesting scenarios. scenario, they do address most of the interesting scenarios.
Exceptions can be discussed separately. Exceptions can be discussed separately.
The forwarding rules are applied to received PATH messages (routers The forwarding rules are applied to received PATH messages (routers
and switches) or originating PATH messages (hosts), as follows: and switches) or originating PATH messages (hosts), as follows:
1. Determine the interface(s) on which to forward the PATH message 1. Determine the interface(s) on which to forward the PATH message
using standard forwarding rules: using standard forwarding rules:
* If there is a LAN_LOOPBACK object in the PATH message, and it
carries the address of this device, silently discard the message.
(See the section below on "Additional notes on forwarding the
PATH message onto a managed segment).
* Layer 3 devices use the RSVP session address and perform a routing
lookup to determine the forwarding interface(s).
* Layer 2 devices use the LAN_NHOP_L2 address in the LAN_NHOP
information and MAC forwarding tables to determine the forwarding
interface(s). (See the section below on "Additional notes on
forwarding the PATH message onto a managed segment")
2. For each forwarding interface:
* If the device is a layer 3 device, determine whether the
interface is on a managed segment managed by a DSBM, based on
the presence or absence of I_AM_DSBM messages. If the interface
is not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP,
LAN_LOOPBACK, and TCLASS objects (if present), and forward to
the unicast or multicast destination.
(Note that the RSVP Class Numbers for these new objects are
SBM (Subnet Bandwidth Manager) January, 2000
chosen so that if an RSVP message includes these objects, the
nodes that are RSVP-aware, but do not participate in the SBM
protocol, will ignore and silently discard such objects.)
* If the device is a layer 2 device or it is a layer 3 device
*and* the interface is on a managed segment, proceed to rule
#3.
3. Forward the PATH message onto the managed segment:
* If the device is a layer 3 device, insert LAN_NHOP address
objects, a LAN_LOOPBACK, and a RSVP_HOP_L2 object into the PATH
message. The LAN_NHOP objects carry the LAN_NHOP_L3 and
LAN_NHOP_L2 addresses of the next layer 3 hop. The RSVP_HOP_L2
object carries the device's own L2 address, and the
LAN_LOOPBACK object contains the IP address of the outgoing
interface.
An L3 device should use the map_addr() function described earlier
to obtain an L2 address corresponding to an IP address.
* If the device hosts the DSBM for the segment to which the
forwarding interface is attached, do the following:
- Retrieve the PHOP information from the standard RSVP HOP
object in the PATH message, and store it. This will be used
to route RESV messages back through the L2 network. If the
PATH message arrived over a managed segment, it will also
contain the RSVP_HOP_L2 object; then retrieve and store also
the previous hop's L2 address in the PATH state.
- Copy the IP address of the forwarding interface (layer 2 devices
must also have IP addresses) into the standard RSVP HOP
object and the L2 address of the forwarding interface into
the RSVP_HOP_L2 object.
- If the PATH message received does not contain the TCLASS
object, insert a TCLASS object. The user_priority value
inserted in the TCLASS object is based on service mappings
internal to the device that are configured according to the
guidelines listed in [RFC-MAP]. If the message already
SBM (Subnet Bandwidth Manager) January, 2000
contains the TCLASS object, the user_priority value may be
changed based again on the service mappings internal to the
device.
* If the device is a layer 3 device and hosts a SBM for the segment
to which the forwarding interface is attached, it *is required*
to retrieve and store the PHOP info.
If the device is a layer 2 device and hosts a SBM for the segment
to which the forwarding interface is attached, it is *not*
required to retrieve and store the PHOP info. If it does not do
so, the SBM must leave the standard RSVP HOP object and the
RSVP_HOP_L2 objects in the PATH message intact and it will not
receive RESV messages.
If the SBM on a L2 device chooses to overwrite the RSVP HOP and
RSVP_HOP_L2 objects with the IP and L2 addresses of its forwarding
interface, it will receive RESV messages. In this case,
it must store the PHOP address info received in the standard
RSVP_HOP field and RSVP_HOP_L2 objects of the incident PATH
message.
In both the cases mentioned above (L2 or L3 devices), the SBM
must forward the TCLASS object in the received PATH message
unchanged.
* Copy the IP address of the forwarding interface into the
LAN_LOOPBACK object, unless the SBM protocol entity is a DSBM
reflecting a PATH message back onto the incident interface.
(See the section below on "Additional notes on forwarding a
PATH message onto a managed segment").
* If the SBM protocol entity is the DSBM for the segment to which
the forwarding interface is attached, it must send the PATH
message to the AllSBMAddress.
* If the SBM protocol entity is a SBM or a DSBM Client on the
segment to which the forwarding interface is attached, it must
send the PATH message to the DSBMLogicalAddress.
5.6.1. Additional notes on forwarding a PATH message onto a
SBM (Subnet Bandwidth Manager) January, 2000
managed segment
Rule #1 states that normal IEEE 802.1D forwarding rules should be
used to determine the interfaces on which the PATH message should
be forwarded. In the case of data packets, standard forwarding
rules at a L2 device dictate that the packet should not be
forwarded on the interface from which it was received. However, in
the case of a DSBM that receives a PATH message over a managed
segment, the following exception applies:
E1. If the address in the LAN_NHOP object is a unicast address,
consult the filtering database (FDB) to determine whether
the destination address is listed on the same interface
over which the message was received. If yes, follow the
rule below on "reflecting a PATH message back onto an
interface" described below; otherwise, proceed with the
rest of the message processing as usual.
E2. If there are members of the multicast group address
(specified by the addresses in the LAN_NHOP object), on the
segment from which the message was received, the message
should be forwarded back onto the interface from which it
was received and follow the rule on "reflecting a PATH
message back onto an interface" described below.
*** Reflecting a PATH message back onto an interface ***
Under the circumstances described above, when a DSBM reflects
the PATH message back onto an interface over which it was
received, it must address it using the AllSBMAddress.
Since it is possible for a DSBM to reflect a PATH message back
onto the interface from which it was received, precautions must
be taken to avoid looping these messages indefinitely. The
LAN_LOOPBACK object addresses this issue. All SBM protocol entities
(except DSBMs reflecting a PATH message) overwrite the
LAN_LOOPBACK object in the PATH message with the IP address of
the outgoing interface. DSBMs which are reflecting a PATH
message, leave the LAN_LOOPBACK object unchanged. Thus, SBM
protocol entities will always be able to recognize a reflected
multicast message by the presence of their own address in the
LAN_LOOPBACK object. These messages should be silently
discarded.
SBM (Subnet Bandwidth Manager) January, 2000
5.7. Applying the Rules -- Unicast Session
Let's see how the rules are applied in the general network
illustrated previously (see Figure 2).
Assume that H1 is sending a PATH for a unicast session for which
H5 is the receiver. The following PATH message is composed by H1:
RSVP Contents
RSVP session IP address IP address of H5 (3.0.0.35)
Sender Template IP address of H1 (1.0.0.11)
PHOP IP address of H1 (1.0.0.11)
RSVP_HOP_L2 n/a (H1 is not sending onto a managed
segment)
LAN_NHOP n/a (H1 is not sending onto a managed
segment)
LAN_LOOPBACK n/a (H1 is not sending onto a managed
segment)
IP Header
Source address IP address of H1 (1.0.0.11)
Destn address IP addr of H5 (3.0.0.35, assuming raw mode &
router alert)
MAC Header
Destn address The L2 addr corresponding to R1 (determined
by map_addr() and routing tables at H1)
Since H1 is not sending onto a managed segment, the PATH message
is composed and forwarded according to standard RSVP processing
rules.
Upon receipt of the PATH message, R1 composes and forwards a PATH
message as follows:
RSVP Contents
RSVP session IP address IP address of H5
Sender Template IP address of H1
PHOP IP address of R1 (2.0.0.1)
(seed the return path for RESV messages)
RSVP_HOP_L2 L2 address of R1
LAN_NHOP LAN_NHOP_L3 (2.0.0.2) and
LAN_NHOP_L2 address of R2 (L2ADDR)
(this is the next layer 3 hop)
LAN_LOOPBACK IP address of R1 (2.0.0.1)
IP Header
SBM (Subnet Bandwidth Manager) January, 2000
Source address IP address of H1
Destn address DSBMLogical IP address (224.0.0.16)
MAC Header
Destn address DSBMLogical MAC address
* R1 does a routing lookup on the RSVP session address, to
determine the IP address of the next layer 3 hop, R2.
* It determines that R2 is accessible via seg A and that seg A
is managed by a DSBM, S1.
* Therefore, it concludes that it is sending onto a managed * If there is a LAN_LOOPBACK object in the PATH message, and it
segment, and composes LAN_NHOP objects to carry the layer 3 carries the address of this device, silently discard the
and layer 2 next hop addresses. To compose the LAN_NHOP message. (See the section below on "Additional notes on
L2ADDR object, it invokes the L3 to L2 address mapping function forwarding the PATH message onto a managed segment).
("map_address") to find out the MAC address for the next hop
L3 device, and then inserts a LAN_NHOP_L2ADDR object (that
carries the MAC address) in the message.
* Since R1 is not the DSBM for seg A, it sends the PATH message * Layer 3 devices use the RSVP session address and perform a
to the DSBMLogicalAddress. routing lookup to determine the forwarding interface(s).
Upon receipt of the PATH message, S1 composes and forwards a PATH * Layer 2 devices use the LAN_NHOP_L2 address in the LAN_NHOP
message as follows: information and MAC forwarding tables to determine the
forwarding interface(s). (See the section below on "Additional
notes on forwarding the PATH message onto a managed segment")
RSVP Contents 2. For each forwarding interface:
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 * If the device is a layer 3 device, determine whether the
Source address IP address of H1 interface is on a managed segment managed by a DSBM, based on
Destn address AllSBMIPaddr (224.0.0.17, since S1 is the the presence or absence of I_AM_DSBM messages. If the interface
is not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP,
LAN_LOOPBACK, and TCLASS objects (if present), and forward to
the unicast or multicast destination.
SBM (Subnet Bandwidth Manager) January, 2000 (Note that the RSVP Class Numbers for these new objects are
chosen so that if an RSVP message includes these objects, the
nodes that are RSVP-aware, but do not participate in the SBM
protocol, will ignore and silently discard such objects.)
DSBM for seg B). * 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.
MAC Header 3. Forward the PATH message onto the managed segment:
Destn address All SBM MAC address (since S1 is the DSBM for
seg B).
* S1 looks at the LAN_NHOP address information to determine the * If the device is a layer 3 device, insert LAN_NHOP address
L2 address towards which it should forward the PATH message. objects, a LAN_LOOPBACK, and a RSVP_HOP_L2 object into the PATH
message. The LAN_NHOP objects carry the LAN_NHOP_L3 and
LAN_NHOP_L2 addresses of the next layer 3 hop. The RSVP_HOP_L2
object carries the device's own L2 address, and the
LAN_LOOPBACK object contains the IP address of the outgoing
interface.
* From the bridge forwarding tables, it determines that the L2 An L3 device should use the map_addr() function described
address is reachable via seg B. earlier to obtain an L2 address corresponding to an IP address.
* S1 inserts the RSVP_HOP_L2 object and overwrites the RSVP HOP * If the device hosts the DSBM for the segment to which the
object (PHOP) with its own addresses. forwarding interface is attached, do the following:
* Since S1 is the DSBM for seg B, it addresses the PATH message - Retrieve the PHOP information from the standard RSVP HOP
to the AllSBMAddress. object in the PATH message, and store it. This will be used
to route RESV messages back through the L2 network. If the
PATH message arrived over a managed segment, it will also
contain the RSVP_HOP_L2 object; then retrieve and store also
the previous hop's L2 address in the PATH state.
Upon receipt of the PATH message, S3 composes and forwards a - Copy the IP address of the forwarding interface (layer 2
PATH message as follows: devices must also have IP addresses) into the standard RSVP
HOP object and the L2 address of the forwarding interface
into the RSVP_HOP_L2 object.
RSVP Contents - If the PATH message received does not contain the TCLASS
RSVP session IP addr IP address of H5 object, insert a TCLASS object. The user_priority value
Sender Template IP address of H1 inserted in the TCLASS object is based on service mappings
PHOP IP addr of S3 (seed the return internal to the device that are configured according to the
path for RESV messages) guidelines listed in [RFC-MAP]. If the message already
RSVP_HOP_L2 L2 address of S3 contains the TCLASS object, the user_priority value may be
LAN_NHOP LAN_NHOP_L3 (IP) and changed based again on the service mappings internal to the
LAN_NHOP_L2 (MAC) address of R2 device.
(L2 devices don't modify LAN_NHOP)
LAN_LOOPBACK IP address of S3
IP Header * If the device is a layer 3 device and hosts a SBM for the
Source address IP address of H1 segment to which the forwarding interface is attached, it *is
Destn address DSBMLogical IP addr (since S3 is required* to retrieve and store the PHOP info.
not the DSBM for seg F)
MAC Header If the device is a layer 2 device and hosts a SBM for the
Destn address DSBMLogical MAC address segment to which the forwarding interface is attached, it is
*not* required to retrieve and store the PHOP info. If it does
not do so, the SBM must leave the standard RSVP HOP object and
the RSVP_HOP_L2 objects in the PATH message intact and it will
not receive RESV messages.
SBM (Subnet Bandwidth Manager) January, 2000 If the SBM on a L2 device chooses to overwrite the RSVP HOP and
RSVP_HOP_L2 objects with the IP and L2 addresses of its
forwarding interface, it will receive RESV messages. In this
case, it must store the PHOP address info received in the
standard RSVP_HOP field and RSVP_HOP_L2 objects of the incident
PATH message.
* S3 looks at the LAN_NHOP address information to determine the In both the cases mentioned above (L2 or L3 devices), the SBM
L2 address towards which it should forward the PATH message. must forward the TCLASS object in the received PATH message
unchanged.
* From the bridge forwarding tables, it determines that the L2 * Copy the IP address of the forwarding interface into the
address is reachable via segment F. LAN_LOOPBACK object, unless the SBM protocol entity is a DSBM
reflecting a PATH message back onto the incident interface.
(See the section below on "Additional notes on forwarding a
PATH message onto a managed segment").
* It has discovered that R2 is the DSBM for segment F. It * If the SBM protocol entity is the DSBM for the segment to which
therefore sends the PATH message to the DSBMLogicalAddress. the forwarding interface is attached, it must send the PATH
message to the AllSBMAddress.
* Note that S3 may or may not choose to overwrite the PHOP * If the SBM protocol entity is a SBM or a DSBM Client on the
objects with its own IP and L2 addresses. If it does so, it segment to which the forwarding interface is attached, it must
will receive RESV messages. In this case, it must also store send the PATH message to the DSBMLogicalAddress.
the PHOP info received in the incident PATH message so that
it is able to forward the RESV messages on the correct path.
Upon receipt of the PATH message, R2 composes and forwards a PATH 5.5.1. Additional notes on forwarding a PATH message onto a managed
message as follows: segment
RSVP Contents Rule #1 states that normal IEEE 802.1D forwarding rules should be
RSVP session IP addr IP address of H5 used to determine the interfaces on which the PATH message should be
Sender Template IP address of H1 forwarded. In the case of data packets, standard forwarding rules at
PHOP IP addr of R2 (seed the return path for RESV a L2 device dictate that the packet should not be forwarded on the
messages) interface from which it was received. However, in the case of a DSBM
RSVP_HOP_L2 Removed by R2 (R2 is not sending onto a that receives a PATH message over a managed segment, the following
managed segment) exception applies:
LAN_NHOP Removed by R2 (R2 is not sending onto a
managed segment)
IP Header E1. If the address in the LAN_NHOP object is a unicast address,
Source address IP address of H1 consult the filtering database (FDB) to determine whether the
Destn address IP address of H5, the RSVP session address 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.
MAC Header E2. If there are members of the multicast group address (specified
Destn address L2 addr corresponding to H5, the next by the addresses in the LAN_NHOP object), on the segment from
layer 3 hop 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.
* R2 does a routing lookup on the RSVP session address, to *** Reflecting a PATH message back onto an interface ***
determine the IP address of the next layer 3 hop, H5.
* It determines that H5 is accessible via a segment for which Under the circumstances described above, when a DSBM reflects the
there is no DSBM (not a managed segment). PATH message back onto an interface over which it was received, it
must address it using the AllSBMAddress.
SBM (Subnet Bandwidth Manager) January, 2000 Since it is possible for a DSBM to reflect a PATH message back
onto the interface from which it was received, precautions must be
taken to avoid looping these messages indefinitely. The
LAN_LOOPBACK object addresses this issue. All SBM protocol
entities (except DSBMs reflecting a PATH message) overwrite the
LAN_LOOPBACK object in the PATH message with the IP address of the
outgoing interface. DSBMs which are reflecting a PATH message,
leave the LAN_LOOPBACK object unchanged. Thus, SBM protocol
entities will always be able to recognize a reflected multicast
message by the presence of their own address in the LAN_LOOPBACK
object. These messages should be silently discarded.
* Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects 5.6. Applying the Rules -- Unicast Session
and places the RSVP session address in the destination
address of the IP header. It places the L2 address of the
next layer 3 hop, into the destination address of the MAC
header and forwards the PATH message to H5.
5.8. Applying the Rules - Multicast Session Let's see how the rules are applied in the general network
illustrated previously (see Figure 2).
The rules described above also apply to multicast (m/c) sessions. Assume that H1 is sending a PATH for a unicast session for which H5
For the purpose of this discussion, it is assumed that layer 2 is the receiver. The following PATH message is composed by H1:
devices track multicast group membership on each port individually.
Layer 2 devices which do not do so, will merely generate
extra multicast traffic. This is the case for L2 devices which do
not implement multicast filtering or GARP/GMRP capability.
Assume that H1 is sending a PATH for an m/c session for which H3 RSVP Contents
and H5 are the receivers. The rules are applied as they are in the RSVP session IP address IP address of H5 (3.0.0.35)
unicast case described previously, until the PATH message reaches Sender Template IP address of H1 (1.0.0.11)
R2, with the following exception. The RSVP session address and the PHOP IP address of H1 (1.0.0.11)
LAN_NHOP carry the destination m/c addresses rather than the RSVP_HOP_L2 n/a (H1 is not sending onto a managed
unicast addresses carried in the unicast example. 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)
Now let's look at the processing applied by R2 upon receipt of the IP Header
PATH message. Recall that R2 is the DSBM for segment F. Therefore, Source address IP address of H1 (1.0.0.11)
S3 will have forwarded its PATH message to the DSBMLogicalAddress, Destn address IP addr of H5 (3.0.0.35, assuming raw mode
to be picked up by R2. The PATH message will not have been seen by & router alert)
H3 (one of the m/c receivers), since it monitors only the
AllSBMAddress, not the DSBMLogicalAddress for incoming PATH
messages. We rely on R2 to reflect the PATH message back onto seg f,
and to forward it to H5. R2 forwards the following PATH message
onto seg f:
RSVP Contents MAC Header
RSVP session addr m/c session address Destn address The L2 addr corresponding to R1 (determined
Sender Template IP address of H1 by map_addr() and routing tables at 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 Since H1 is not sending onto a managed segment, the PATH message is
Source address IP address of H1 composed and forwarded according to standard RSVP processing rules.
SBM (Subnet Bandwidth Manager) January, 2000 Upon receipt of the PATH message, R1 composes and forwards a PATH
message as follows:
Destn address AllSBMIP address (since R2 is the DSBM for seg F) 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)
MAC Header IP Header
Destn address AllSBMMAC address (since R2 is the Source address IP address of H1
DSBM for seg F) Destn address DSBMLogical IP address (224.0.0.16)
Since H3 is monitoring the All SBM Address, it will receive the MAC Header
PATH message reflected by R2. Note that R2 violated the standard Destn address DSBMLogical MAC address
forwarding rules here by sending an incoming message back onto the
interface from which it was received. It protected against loops
by leaving S3's address in the LAN_LOOPBACK object unchanged.
R2 forwards the following PATH message on to H5: * R1 does a routing lookup on the RSVP session address, to
determine the IP address of the next layer 3 hop, R2.
RSVP Contents * It determines that R2 is accessible via seg A and that seg A
RSVP session addr m/c session address is managed by a DSBM, S1.
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 * Therefore, it concludes that it is sending onto a managed
Source address IP address of H1 segment, and composes LAN_NHOP objects to carry the layer 3
Destn address m/c session address and layer 2 next hop addresses. To compose the LAN_NHOP
L2ADDR object, it invokes the L3 to L2 address mapping function
("map_address") to find out the MAC address for the next hop
L3 device, and then inserts a LAN_NHOP_L2ADDR object (that
carries the MAC address) in the message.
MAC Header * Since R1 is not the DSBM for seg A, it sends the PATH message
Destn address MAC addr corresponding to the m/c to the DSBMLogicalAddress.
session address
* R2 determines that there is an m/c receiver accessible via a Upon receipt of the PATH message, S1 composes and forwards a PATH
segment for which there is no DSBM. Therefore, it removes the message as follows:
LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session
address in the destination address of the IP header. It
places the corresponding L2 address into the destination
address of the MAC header and multicasts the message towards
H5.
5.9. Merging Traffic Class objects 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
SBM (Subnet Bandwidth Manager) January, 2000 IP Header
Source address IP address of H1
Destn address AllSBMIPaddr (224.0.0.17, since S1 is the
DSBM for seg B).
When a DSBM client receives TCLASS objects from different senders MAC Header
(different PATH messages) in the same RSVP session and needs to Destn address All SBM MAC address (since S1 is the DSBM
combine them for sending back a single RESV message (as in a for seg B).
wild-card style reservation), the DSBM client must choose an
appropriate value that corresponds to the desired-delay traffic
class. An accompanying document discusses the guidelines for
traffic class selection based on desired service and the TSpec
information [RFC-MAP].
In addition, when a SBM or DSBM needs to merge RESVs from different * S1 looks at the LAN_NHOP address information to determine the
next hops at a merge point, it must decide how to handle L2 address towards which it should forward the PATH message.
the TCLASS values in the incoming RESVs if they do not match.
Consider the case when a reservation is in place for a flow at a DSBM
(or SBM) with a successful admission control done for the TCLASS
requested in the first RESV for the flow. If another RESV (not the
refresh of the previously admitted RESV) for the same flow arrives
at the DSBM, the DSBM must first check the TCLASS value in the new
RESV against the TCLASS value in the already installed RESV. If
the two values are same, the RESV requests are merged and the new,
merged RESV installed and forwarded using the normal rules of message
processing. However, if the two values are not identical, the
DSBM must generate and send a RESV_ERR message towards the sender
(NHOP) of the newer, RESV message. The RESV_ERR must specify the
error code corresponding to the RSVP "traffic control error"
(RESV_ERR code 21) that indicates failure to merge two incompatible
service requests (sub-code 01 for the RSVP traffic control
error) [RFC-2205]. The RESV_ERR message may include additional
objects to assist downstream nodes in recovering from this
condition. The definition and usage of such objects is beyond the
scope of this draft.
5.10. Operation of SBM Transparent Devices * From the bridge forwarding tables, it determines that the L2
address is reachable via seg B.
SBM transparent devices are unaware of the entire SBM/DSBM protocol. * S1 inserts the RSVP_HOP_L2 object and overwrites the RSVP HOP
They do not intercept messages addressed to either of the SBM object (PHOP) with its own addresses.
related local group addresses (the DSBMLogicalAddrss and the
ALLSBMAddress), but instead, pass them through. As a result, they
do not divide the DSBM election scope, they do not explicitly
participate in routing of PATH or RESV messages, and they do not
participate in admission control. They are entirely transparent with
respect to SBM operation.
According to the definitions provided, physical segments interconnected * Since S1 is the DSBM for seg B, it addresses the PATH message
by SBM transparent devices are considered a single managed to the AllSBMAddress.
segment. Therefore, DSBMs must perform admission control on such
managed segments, with limited knowledge of the segment's topology.
In this case, the network administrator should configure the
SBM (Subnet Bandwidth Manager) January, 2000 Upon receipt of the PATH message, S3 composes and forwards a PATH
message as follows:
DSBM for each managed segment, with some reasonable approximation RSVP Contents
of the segment's capacity. A conservative policy would configure RSVP session IP addr IP address of H5
the DSBM for the lowest capacity route through the managed seg- Sender Template IP address of H1
ment. A liberal policy would configure the DSBM for the highest PHOP IP addr of S3 (seed the return
capacity route through the managed segment. A network administrator path for RESV messages)
will likely choose some value between the two, based on the RSVP_HOP_L2 L2 address of S3
level of guarantee required and some knowledge of likely traffic LAN_NHOP LAN_NHOP_L3 (IP) and
patterns. LAN_NHOP_L2 (MAC) address of R2
(L2 devices don't modify LAN_NHOP)
LAN_LOOPBACK IP address of S3
This document does not specify the configuration mechanism or the IP Header
choice of a policy. Source address IP address of H1
Destn address DSBMLogical IP addr (since S3 is
not the DSBM for seg F)
5.11. Operation of SBMs Which are NOT DSBMs MAC Header
Destn address DSBMLogical MAC address
In the example illustrated, S3 hosts a SBM, but the SBM on S3 did * S3 looks at the LAN_NHOP address information to determine the
not win the election to act as DSBM on any segment. One might ask L2 address towards which it should forward the PATH message.
what purpose such a SBM protocol entity serves. Such SBMs actually
provide two useful functions. First, the additional SBMs remain
passive in the background for fault tolerance. They listen to the
periodic announcements from the current DSBM for the managed segment
(Appendix A describes this in more detail) and step in to
elect a new DSBM when the current DSBM fails or ceases to be
operational for some reason. Second, such SBMs also provide the
important service of dividing the election scope and reducing the
size and complexity of managed segments. For example, consider the
sample topology in Figure 3 again. the device S3 contains an SBM
that is not a DSBM for any f the segments, B, E, or F, attached to
it. However, if the SBM protocol entity on S3 was not present,
segments B and F would not be separate segments from the point of
view of the SBM protocol. Instead, they would constitute a single
managed segment, managed by a single DSBM. Because the SBM entity
on S3 divides the election scope, seg B and seg F are each
managed by separate DSBMs. Each of these segments have a trivial
topology and a well defined capacity. As a result, the DSBMs for
these segments do not need to perform admission control based on
approximations (as would be the case if S3 were SBM transparent).
Note that, SBM protocol entities which are not DSBMs, are not * From the bridge forwarding tables, it determines that the L2
required to overwrite the PHOP in incident PATH messages with address is reachable via segment F.
their own address. This is because it is not necessary for RESV
messages to be routed through these devices. RESV messages are
only required to be routed through the correct sequence of DSBMs.
SBMs may not process RESV messages that do pass through them,
other than to forward them towards their destination address,
using standard forwarding rules.
SBM (Subnet Bandwidth Manager) January, 2000 * It has discovered that R2 is the DSBM for segment F. It
therefore sends the PATH message to the DSBMLogicalAddress.
SBM protocol entities which are not DSBMs are required to * Note that S3 may or may not choose to overwrite the PHOP
overwrite the address in the LAN_LOOPBACK object with their own objects with its own IP and L2 addresses. If it does so, it
address, in order to avoid looping multicast messages. However, no will receive RESV messages. In this case, it must also store
state need be stored. the PHOP info received in the incident PATH message so that
it is able to forward the RESV messages on the correct path.
6. Inter-Operability Considerations Upon receipt of the PATH message, R2 composes and forwards a PATH
message as follows:
There are a few interesting inter-operability issues related to RSVP Contents
the deployment of a DSBM-based admission control method in an RSVP session IP addr IP address of H5
environment consisting of network nodes with and without RSVP Sender Template IP address of H1
capability. In the following, we list some of these scenarios and PHOP IP addr of R2 (seed the return path for RESV
explain how SBM-aware clients and nodes can operate in those messages)
scenarios: 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
6.1. An L2 domain with no RSVP capability. MAC Header
Destn address L2 addr corresponding to H5, the next
layer 3 hop
It is possible to envisage L2 domains that do not use RSVP signaling * R2 does a routing lookup on the RSVP session address, to
for requesting resource reservations, but, instead, use some determine the IP address of the next layer 3 hop, H5.
other (e.g., SNMP or static configuration) mechanism to reserve
bandwidth at a particular network device such as a router. In that
case, the question is how does a DSBM-based admission control
method work and interoperate with the non-RSVP mechanism. The
SBM-based method does not attempt to provide an admission control
solution for such an environment. The SBM-based approach is part
of an end to end signaling approach to establish resource reservations
and does not attempt to provide a solution for SNMP-based
configuration scenario.
As stated earlier, the SBM-based approach can, however, co-exist * It determines that H5 is accessible via a segment for which
with any other, non-RSVP bandwidth allocation mechanism as long as there is no DSBM (not a managed segment).
resources being reserved are either partitioned statically between
the different mechanisms or are resolved dynamically through a
common bandwidth allocator so that there is no over-commitment of
the same resource.
6.2. An L2 domain with SBM-transparent L2 Devices. * Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects
and places the RSVP session address in the destination
address of the IP header. It places the L2 address of the
next layer 3 hop, into the destination address of the MAC
header and forwards the PATH message to H5.
This scenario has been addressed earlier in the document. The 5.7. Applying the Rules - Multicast Session
SBM-based method is designed to operate in such an environment.
When SBM-transparent L2 devices interconnect SBM-aware devices,
the resulting managed segment is a combination of one or more
physical segments and the DSBM for the managed segment may not be as
efficient in allocating resources as it would if all L2 devices
were SBM-aware.
SBM (Subnet Bandwidth Manager) January, 2000 The rules described above also apply to multicast (m/c) sessions.
For the purpose of this discussion, it is assumed that layer 2
devices track multicast group membership on each port individually.
Layer 2 devices which do not do so, will merely generate extra
multicast traffic. This is the case for L2 devices which do not
implement multicast filtering or GARP/GMRP capability.
6.3. An L2 domain on which some RSVP-based senders are not DSBM Assume that H1 is sending a PATH for an m/c session for which H3 and
clients. H5 are the receivers. The rules are applied as they are in the
unicast case described previously, until the PATH message reaches R2,
with the following exception. The RSVP session address and the
LAN_NHOP carry the destination m/c addresses rather than the unicast
addresses carried in the unicast example.
All senders that are sourcing RSVP-based traffic flows onto a Now let's look at the processing applied by R2 upon receipt of the
managed segment MUST be SBM-aware and participate in the SBM protocol. PATH message. Recall that R2 is the DSBM for segment F. Therefore, S3
Use of the standard, non-SBM version of RSVP may result in will have forwarded its PATH message to the DSBMLogicalAddress, to be
over-allocation of resources, as such use bypasses the resource picked up by R2. The PATH message will not have been seen by H3 (one
management function of the DSBM. All other senders (i.e., senders of the m/c receivers), since it monitors only the AllSBMAddress, not
that are not sending streams subject to RSVP admission control) the DSBMLogicalAddress for incoming PATH messages. We rely on R2 to
should be elastic applications that send traffic of lower priority reflect the PATH message back onto seg f, and to forward it to H5. R2
than the RSVP traffic, and use TCP-like congestion avoidance forwards the following PATH message onto seg f:
mechanisms.
All DSBMs, SBMs, or DSBM clients on a managed segment (a segment RSVP Contents
with a currently active DSBM) must not accept PATH messages from RSVP session addr m/c session address
senders that are not SBM-aware. PATH messages from such devices Sender Template IP address of H1
can be easily detected by SBMs and DSBM clients as they would not PHOP IP addr of R2 (seed the return path for
be multicast to the ALLSBMAddress (in case of SBMs and DSBM RESV messages)
clients) or the DSBMLogicalAddress (in case of DSBMs). 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)
6.4. A non-SBM router that interconnects two DSBM-managed L2 IP Header
domains. Source address IP address of H1
Multicast SBM messages (e.g., election and PATH messages) have Destn address AllSBMIP address (since R2 is the DSBM for seg F)
local scope and are not intended to pass between the two domains.
A correctly configured non-SBM router will not pass such messages
between the domains. A broken router implementation that does so
may cause incorrect operation of the SBM protocol and consequent
over- or under-allocation of resources.
6.5. Interoperability with RSVP clients that use UDP encapsulation MAC Header
and are not capable of receiving/sending RSVP messages using Destn address AllSBMMAC address (since R2 is the
RAW_IP DSBM for seg F)
This document stipulates that DSBMs, DSBM clients, and SBMs use Since H3 is monitoring the All SBM Address, it will receive the PATH
only raw IP for encapsulating RSVP messages that are forwarded message reflected by R2. Note that R2 violated the standard
onto a L2 domain. RFC-2205 (the RSVP Proposed Standard) includes forwarding rules here by sending an incoming message back onto the
support for both raw IP and UDP encapsulation. Thus, a RSVP node interface from which it was received. It protected against loops by
using only the UDP encapsulation will not be able to interoperate leaving S3's address in the LAN_LOOPBACK object unchanged.
with the DSBM unless DSBM accepts and supports UDP encapsulated
RSVP messages.
7. Guidelines for Implementers R2 forwards the following PATH message on to H5:
SBM (Subnet Bandwidth Manager) January, 2000 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)
In the following, we provide guidelines for implementers on different IP Header
aspects of the implementation of the SBM-based admission Source address IP address of H1
control procedure including suggestions for DSBM initialization, Destn address m/c session address
etc.
7.1. DSBM Initialization MAC Header
Destn address MAC addr corresponding to the m/c
session address
As stated earlier, DSBM initialization includes configuration of * R2 determines that there is an m/c receiver accessible via a
maximum bandwidth that can be reserved on a managed segment under segment for which there is no DSBM. Therefore, it removes the
its control. We suggest the following guideline. LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session
address in the destination address of the IP header. It
places the corresponding L2 address into the destination
address of the MAC header and multicasts the message towards
H5.
In the case of a managed segment consisting of L2 devices 5.8. Merging Traffic Class objects
interconnected by a single shared segment, DSBM entities on such
devices should assume the bandwidth of the interface as the total
link bandwidth. In the case of a DSBM located in a L2 switch, it
might additionally need to be configured with an estimate of the
device's switching capacity if that is less than the link
bandwidth, and possibly with some estimate of the buffering
resources of the switch (see [RFC-FRAME] for the architectural
model assumed for L2 switches). Given the total link bandwidth,
the DSBM may be further configured to limit the maximum amount of
bandwidth for RSVP-enabled flows to ensure spare capacity for
best-effort traffic.
7.2. Operation of DSBMs in Different L2 Topologies When a DSBM client receives TCLASS objects from different senders
(different PATH messages) in the same RSVP session and needs to
combine them for sending back a single RESV message (as in a wild-
card style reservation), the DSBM client must choose an appropriate
value that corresponds to the desired-delay traffic class. An
accompanying document discusses the guidelines for traffic class
selection based on desired service and the TSpec information [RFC-
MAP].
Depending on a L2 topology, a DSBM may be called upon to manage In addition, when a SBM or DSBM needs to merge RESVs from different
resources for one or more segments and the implementers must bear next hops at a merge point, it must decide how to handle the TCLASS
in mind efficiency implications of the use of DSBM in different L2 values in the incoming RESVs if they do not match. Consider the case
topologies. Trivial L2 topologies consist of a single "physical when a reservation is in place for a flow at a DSBM (or SBM) with a
segment". In this case, the 'managed segment' is equivalent to a successful admission control done for the TCLASS requested in the
single segment. Complex L2 topologies may consist of a number of first RESV for the flow. If another RESV (not the refresh of the
'physical segments', separated by SBM-transparent L2 switches. previously admitted RESV) for the same flow arrives at the DSBM, the
Admission control on such an L2 extended segment can be performed DSBM must first check the TCLASS value in the new RESV against the
from a single pool of resources, similar to a single shared segment, TCLASS value in the already installed RESV. If the two values are
from the point of view of a single DSBM. same, the RESV requests are merged and the new, merged RESV installed
and forwarded using the normal rules of message processing. However,
if the two values are not identical, the DSBM must generate and send
a RESV_ERR message towards the sender (NHOP) of the newer, RESV
message. The RESV_ERR must specify the error code corresponding to
the RSVP "traffic control error" (RESV_ERR code 21) that indicates
failure to merge two incompatible service requests (sub-code 01 for
the RSVP traffic control error) [RFC-2205]. The RESV_ERR message may
include additional objects to assist downstream nodes in recovering
from this condition. The definition and usage of such objects is
beyond the scope of this memo.
This configuration compromises the efficiency with which the DSBM 5.9. Operation of SBM Transparent Devices
can allocate resources. This is because the single DSBM is
required to make admission control decisions for all reservation
requests within the L2 topology, with no knowledge of the actual
physical segments affected by the reservation.
We can realize improvements in the efficiency of resource allocation SBM transparent devices are unaware of the entire SBM/DSBM protocol.
by subdividing the complex segment into a number of managed They do not intercept messages addressed to either of the SBM related
segments, each managed by their own DSBM. In this case, each DSBM local group addresses (the DSBMLogicalAddrss and the ALLSBMAddress),
but instead, pass them through. As a result, they do not divide the
DSBM election scope, they do not explicitly participate in routing of
PATH or RESV messages, and they do not participate in admission
control. They are entirely transparent with respect to SBM operation.
SBM (Subnet Bandwidth Manager) January, 2000 According to the definitions provided, physical segments
interconnected by SBM transparent devices are considered a single
managed segment. Therefore, DSBMs must perform admission control on
such managed segments, with limited knowledge of the segment's
topology. In this case, the network administrator should configure
the DSBM for each managed segment, with some reasonable approximation
of the segment's capacity. A conservative policy would configure the
DSBM for the lowest capacity route through the managed segment. A
liberal policy would configure the DSBM for the highest capacity
route through the managed segment. A network administrator will
likely choose some value between the two, based on the level of
guarantee required and some knowledge of likely traffic patterns.
manages a managed segment having a relatively simple topology. This document does not specify the configuration mechanism or the
Since managed segments are simpler, the DSBM can be configured choice of a policy.
with a more accurate estimate of the resources available for all
reservations in the managed segment. In the ultimate configuration,
each physical segment is a managed segment and is managed by
its own DSBM. We make no assumption about the number of managed
segments but state, simply, that in complex L2 topologies, the
efficiency of resource allocation improves as the granularity of
managed segments increases.
8. Security Considerations 5.10. Operation of SBMs Which are NOT DSBMs
The message formatting and usage rules described in this note In the example illustrated, S3 hosts a SBM, but the SBM on S3 did not
raise security issues, identical to those raised by the use of win the election to act as DSBM on any segment. One might ask what
RSVP and Integrated Services. It is necessary to control and purpose such a SBM protocol entity serves. Such SBMs actually provide
authenticate access to enhanced qualities of service enabled by two useful functions. First, the additional SBMs remain passive in
the technology described in this RFC. This requirement is discussed the background for fault tolerance. They listen to the periodic
further in [RFC-2205], [RFC-2211], and [RFC-2212]. announcements from the current DSBM for the managed segment (Appendix
A describes this in more detail) and step in to elect a new DSBM when
the current DSBM fails or ceases to be operational for some reason.
Second, such SBMs also provide the important service of dividing the
election scope and reducing the size and complexity of managed
segments. For example, consider the sample topology in Figure 3
again. the device S3 contains an SBM that is not a DSBM for any f the
segments, B, E, or F, attached to it. However, if the SBM protocol
entity on S3 was not present, segments B and F would not be separate
segments from the point of view of the SBM protocol. Instead, they
would constitute a single managed segment, managed by a single DSBM.
Because the SBM entity on S3 divides the election scope, seg B and
seg F are each managed by separate DSBMs. Each of these segments have
a trivial topology and a well defined capacity. As a result, the
DSBMs for these segments do not need to perform admission control
based on approximations (as would be the case if S3 were SBM
transparent).
[RFC-RSVPMD5] describes the mechanism used to protect the integrity of Note that, SBM protocol entities which are not DSBMs, are not
RSVP messages carrying the information described here. A SBM required to overwrite the PHOP in incident PATH messages with their
implementation should satisfy the requirements of that RFC and provide own address. This is because it is not necessary for RESV messages to
the suggested mechanisms just as though it were a conventional RSVP be routed through these devices. RESV messages are only required to
implementation. It should further use the same mechanisms to be routed through the correct sequence of DSBMs. SBMs may not
protect the additional, SBM-specific objects in a message. process RESV messages that do pass through them, other than to
forward them towards their destination address, using standard
forwarding rules.
Finally, it is also necessary to authenticate DSBM candidates SBM protocol entities which are not DSBMs are required to overwrite
during the election process, and a mechanism based on a shared the address in the LAN_LOOPBACK object with their own address, in
secret among the DSBM candidates may be used. The mechanism order to avoid looping multicast messages. However, no state need be
defined in [RFC-RSVPMD5] should be used. stored.
SBM (Subnet Bandwidth Manager) January, 2000 6. Inter-Operability Considerations
9. References There are a few interesting inter-operability issues related to the
deployment of a DSBM-based admission control method in an environment
consisting of network nodes with and without RSVP capability. In the
following, we list some of these scenarios and explain how SBM-aware
clients and nodes can operate in those scenarios:
[RFC-2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 6.1. An L2 domain with no RSVP capability.
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification ", RFC-2205, September 1997.
[RFC-RSVPMD5] F. Baker., "RSVP Cryptographic Authentication", It is possible to envisage L2 domains that do not use RSVP signaling
draft-ietf-rsvp-md5-05.txt, August 1997. [XXX- is this a RFC yet??] for requesting resource reservations, but, instead, use some other
(e.g., SNMP or static configuration) mechanism to reserve bandwidth
at a particular network device such as a router. In that case, the
question is how does a DSBM-based admission control method work and
interoperate with the non-RSVP mechanism. The SBM-based method does
not attempt to provide an admission control solution for such an
environment. The SBM-based approach is part of an end to end
signaling approach to establish resource reservations and does not
attempt to provide a solution for SNMP-based configuration scenario.
[RFC-2206] F. Baker, J. Krawczyk, "RSVP Management Information As stated earlier, the SBM-based approach can, however, co-exist with
Base", RFC 2206, September 1997. any other, non-RSVP bandwidth allocation mechanism as long as
resources being reserved are either partitioned statically between
the different mechanisms or are resolved dynamically through a common
bandwidth allocator so that there is no over-commitment of the same
resource.
[RFC-2211] J. Wroclawski, "Specification of the Controlled-Load 6.2. An L2 domain with SBM-transparent L2 Devices.
Network Element Service", RFC-2211, September 1997.
[RFC-2212] S. Shenker, C. Partridge, R. Guerin, "Specification of This scenario has been addressed earlier in the document. The SBM-
Guaranteed Quality of Service", RFC-2212, September 1997. based method is designed to operate in such an environment. When
SBM-transparent L2 devices interconnect SBM-aware devices, the
resulting managed segment is a combination of one or more physical
segments and the DSBM for the managed segment may not be as efficient
in allocating resources as it would if all L2 devices were SBM-aware.
[RFC-2215] S. Shenker, J. Wroclawski, "General Characterization 6.3. An L2 domain on which some RSVP-based senders are not DSBM clients.
Parameters for Integrated Service Network Elements", RFC-2215,
September 1997.
[RFC-2210] J. Wroclawski, "The Use of RSVP with IETF Integrated All senders that are sourcing RSVP-based traffic flows onto a managed
Services", RFC 2210, September 1997. segment MUST be SBM-aware and participate in the SBM protocol. Use
of the standard, non-SBM version of RSVP may result in over-
allocation of resources, as such use bypasses the resource management
function of the DSBM. All other senders (i.e., senders that are not
sending streams subject to RSVP admission control) should be elastic
applications that send traffic of lower priority than the RSVP
traffic, and use TCP-like congestion avoidance mechanisms.
[RFC-2213] F. Baker, J. Krawczyk, "Integrated Services Management All DSBMs, SBMs, or DSBM clients on a managed segment (a segment with
Information Base", RFC 2213, September 1997. a currently active DSBM) must not accept PATH messages from senders
that are not SBM-aware. PATH messages from such devices can be easily
detected by SBMs and DSBM clients as they would not be multicast to
the ALLSBMAddress (in case of SBMs and DSBM clients) or the
DSBMLogicalAddress (in case of DSBMs).
[RFC-FRAME] A. Ghanwani, W. Pace, V. Srinivasan, A.Smith, 6.4. A non-SBM router that interconnects two DSBM-managed L2 domains.
M.Seaman "A Framework for Providing Integrated Services Over
Shared and Switched LAN Technologies", RFC-XXX, June, 1999.
[RFC-MAP] M. Seaman, A. Smith, E. Crawley, "Integrated Service Multicast SBM messages (e.g., election and PATH messages) have local
Mappings on IEEE 802 Networks", RFC-XXX, June 1999. scope and are not intended to pass between the two domains. A
correctly configured non-SBM router will not pass such messages
between the domains. A broken router implementation that does so may
cause incorrect operation of the SBM protocol and consequent over- or
under-allocation of resources.
[IEEE802Q] "IEEE Standards for Local and Metropolitan Area 6.5. Interoperability with RSVP clients that use UDP encapsulation and
Networks: Virtual Bridged Local Area Networks", Draft Standard are not capable of receiving/sending RSVP messages using RAW_IP
P802.1Q/D9, February 20, 1998.
[IEEEP8021p] "Information technology - Telecommunications and This document stipulates that DSBMs, DSBM clients, and SBMs use only
information exchange between systems - Local and metropolitan area raw IP for encapsulating RSVP messages that are forwarded onto a L2
networks - Common specifications - Part 3: Media Access Control domain. RFC-2205 (the RSVP Proposed Standard) includes support for
(MAC) Bridges: Revision (Incorporating IEEE P802.1p: Traffic both raw IP and UDP encapsulation. Thus, a RSVP node using only the
Class Expediting and Dynamic Multicast Filtering)", ISO/IEC Final UDP encapsulation will not be able to interoperate with the DSBM
CD 15802-3 IEEE P802.1D/D15, November 24, 1997. unless DSBM accepts and supports UDP encapsulated RSVP messages.
SBM (Subnet Bandwidth Manager) January, 2000 7. Guidelines for Implementers
[IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993. In the following, we provide guidelines for implementers on different
aspects of the implementation of the SBM-based admission control
procedure including suggestions for DSBM initialization, etc.
SBM (Subnet Bandwidth Manager) January, 2000 7.1. DSBM Initialization
Appendix A As stated earlier, DSBM initialization includes configuration of
DSBM Election Algorithm maximum bandwidth that can be reserved on a managed segment under its
control. We suggest the following guideline.
A.1. Introduction In the case of a managed segment consisting of L2 devices
interconnected by a single shared segment, DSBM entities on such
devices should assume the bandwidth of the interface as the total
link bandwidth. In the case of a DSBM located in a L2 switch, it
might additionally need to be configured with an estimate of the
device's switching capacity if that is less than the link bandwidth,
and possibly with some estimate of the buffering resources of the
switch (see [RFC-FRAME] for the architectural model assumed for L2
switches). Given the total link bandwidth, the DSBM may be further
configured to limit the maximum amount of bandwidth for RSVP-enabled
flows to ensure spare capacity for best-effort traffic.
To simplify the rest of this discussion, we will assume that there 7.2. Operation of DSBMs in Different L2 Topologies
is a single DSBM for the entire L2 domain (i.e., assume a shared
L2 segment for the entire L2 domain). Later, we will discuss how a
DSBM is elected for a half-duplex or full-duplex switched segment.
To allow for quick recovery from the failure of a DSBM, we assume Depending on a L2 topology, a DSBM may be called upon to manage
that additional SBMs may be active in a L2 domain for fault tolerance. resources for one or more segments and the implementers must bear in
When more than one SBM is active in a L2 domain, the SBMs mind efficiency implications of the use of DSBM in different L2
use an election algorithm to elect a DSBM for the L2 domain. After topologies. Trivial L2 topologies consist of a single "physical
the DSBM is elected and is operational, other SBMs remain passive segment". In this case, the 'managed segment' is equivalent to a
in the background to step in to elect a new DSBM when necessary. single segment. Complex L2 topologies may consist of a number of
The protocol for electing and discovering DSBM is called the "DSBM Admission control on such an L2 extended segment can be performed
election protocol" and is described in the rest of this Appendix. from a single pool of resources, similar to a single shared segment,
from the point of view of a single DSBM.
A.1.1. How a DSBM Client Detects a Managed Segment This configuration compromises the efficiency with which the DSBM can
allocate resources. This is because the single DSBM is required to
make admission control decisions for all reservation requests within
the L2 topology, with no knowledge of the actual physical segments
affected by the reservation.
Once elected, a DSBM periodically multicasts an I_AM_DSBM message We can realize improvements in the efficiency of resource allocation
on the AllSBMAddress to indicate its presence. The message is sent by subdividing the complex segment into a number of managed segments,
every period (e.g., every 5 seconds) according to the each managed by their own DSBM. In this case, each DSBM manages a
RefreshInterval timer value (a configuration parameter). managed segment having a relatively simple topology. Since managed
Absence of such a message over a certain time interval (called segments are simpler, the DSBM can be configured with a more accurate
"DSBMDeadInterval"; another configuration parameter typically set estimate of the resources available for all reservations in the
to a multiple of RefreshInterval) indicates that the DSBM has managed segment. In the ultimate configuration, each physical segment
failed or terminated and triggers another round of the DSBM is a managed segment and is managed by its own DSBM. We make no
election. The DSBM clients always listen for periodic DSBM assumption about the number of managed segments but state, simply,
advertisements. The advertisement includes the unicast IP address of that in complex L2 topologies, the efficiency of resource allocation
the DSBM (DSBMAddress) and DSBM clients send their PATH/RESV (or improves as the granularity of managed segments increases.
other) messages to the DSBM. When a DSBM client detects the
failure of a DSBM, it waits for a subsequent I_AM_DSBM advertisement
before resuming any communication with the DSBM. During the
period when a DSBM is not present, a DSBM client may forward
outgoing PATH messages using the standard RSVP forwarding rules.
The exact message formats and addresses used for communication 8. Security Considerations
with (and among) SBM(s) are described in Appendix B.
A.2. Overview of the DSBM Election Procedure The message formatting and usage rules described in this note raise
security issues, identical to those raised by the use of RSVP and
Integrated Services. It is necessary to control and authenticate
access to enhanced qualities of service enabled by the technology
described in this RFC. This requirement is discussed further in
[RFC-2205], [RFC-2211], and [RFC-2212].
SBM (Subnet Bandwidth Manager) January, 2000 [RFC-RSVPMD5] describes the mechanism used to protect the integrity
of RSVP messages carrying the information described here. A SBM
implementation should satisfy the requirements of that RFC and
provide the suggested mechanisms just as though it were a
conventional RSVP implementation. It should further use the same
mechanisms to protect the additional, SBM-specific objects in a
message.
When a SBM first starts up, it listens for incoming DSBM Finally, it is also necessary to authenticate DSBM candidates during
advertisements for some period to check whether a DSBM already exists the election process, and a mechanism based on a shared secret among
in its L2 domain. If one already exists (and no new election is in the DSBM candidates may be used. The mechanism defined in [RFC-
progress), the new SBM stays quiet in the background until an RSVPMD5] should be used.
election of DSBM is necessary. All messages related to the DSBM
election and DSBM advertisements are always sent to the
AllSBMAddress.
If no DSBM exists, the SBM initiates the election of a DSBM by 9. References
sending out a DSBM_WILLING message that lists its IP address as a
candidate DSBM and its "SBM priority". Each SBM is assigned a
priority to determine its relative precedence. When more than one
SBM candidate exists, the SBM priority determines who gets to be
the DSBM based on the relative priority of candidates. If there is
a tie based on the priority value, the tie is broken using the IP
addresses of tied candidates (one with the higher IP address in
the lexicographic order wins). The details of the election
protocol start in Section A.4.
A.2.1 Summary of the Election Algorithm [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.
For the purpose of the algorithm, a SBM is in one of the four [RFC-RSVPMD5] Baker, F., Lindell, B. and M. Talwar, "RSVP
states (Idle, DetectDSBM, ElectDSBM, IAMDSBM). Cryptographic Authentication", RFC 2747, January 2000.
A SBM (call it X) starts up in the DetectDSBM state and waits for [RFC 2206] Baker, F. and J. Krawczyk, "RSVP Management Information
a ListenInterval for incoming I_AM_DSBM (DSBM advertisement) or Base", RFC 2206, September 1997.
DSBM_WILLING messages. If an I_AM_DSBM advertisement is received
during this state, the SBM notes the current DSBM (its IP address
and priority) and enters the Idle state. If a DSBM_WILLING message
is received from another SBM (call it Y) during this state, then X
enters the ElectDSBM state. Before entering the new state, X first
checks to see whether it itself is a better candidate than Y and,
if so, sends out a DSBM_WILLING message and then enters the
ElectDSBM state.
When a SBM (call it X) enters the ElectDSBM state, it sets a timer [RFC 2211] Wroclawski, J., "Specification of the Controlled-Load
(called ElectionIntervalTimer, and typically set to a value at Network Element Service", RFC 2211, September 1997.
least equal to the DSBMDeadInterval value) to wait for the election
to finish and to discover who is the best candidate. In this
state, X keeps track of the best (or better) candidate seen so far
(including itself). Whenever it receives another DSBM_WILLING
message it updates its notion of the best (or better) candidate
based on the priority (and tie-breaking) criterion. During the
ElectionInterval, X sends out a DSBM_WILLING message every
RefreshInterval to (re)assert its candidacy.
SBM (Subnet Bandwidth Manager) January, 2000 [RFC 2212] Shenker, S., Partridge, C. and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
At the end of the ElectionInterval, X checks whether it is the [RFC 2215] Shenker, S. and J. Wroclawski, "General
best candidate so far. If so, it declares itself to be the DSBM Characterization Parameters for Integrated Service
(by sending out the I_AM_DSBM advertisement) and enters the Network Elements", RFC 2215, September 1997.
IAMDSBM state; otherwise, it decides to wait for the best candidate
to declare itself the winner. To wait, X re-initializes its
ElectDSBM state and continues to wait for another round of election
(each round lasts for an ElectionTimerInterval duration).
A SBM is in Idle state when no election is in progress and the [RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
DSBM is already elected (and happens to be someone else). In this Services", RFC 2210, September 1997.
state, it listens for incoming I_AM_DSBM advertisements and uses
a DSBMDeadIntervalTimer to detect the failure of DSBM. Every time
the advertisement is received, the timer is restarted. If the
timer fires, the SBM goes into the DetectDSBM state to prepare to
elect the new DSBM. If a SBM receives a DSBM_WILLING message from
the current DSBM in this state, the SBM enters the ElectDSBM state
after sending out a DSBM_WILLING message (to announce its own
candidacy).
In the IAMDSBM state, the DSBM sends out I_AM_DSBM advertisements [RFC 2213] Baker, F. and J. Krawczyk, "Integrated Services
every refresh interval. If the DSBM wishes to shut down Management Information Base", RFC 2213, September 1997.
(gracefully terminate), it sends out a DSBM_WILLING message (with
SBM priority value set to zero) to initiate the election
procedure. The priority value zero effectively removes the outgoing
DSBM from the election procedure and makes way for the election of
a different DSBM.
A.3. Recovering from DSBM Failure [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.
When a DSBM fails (DSBMDeadIntervalTimer fires), all the SBMs [RFC-MAP] Seaman, M., Smith, A. and E. Crawley, "Integrated
enter the ElectDSBM state and start the election process. Service Mappings on IEEE 802 Networks", RFC 2815, May
2000.
At the end of the ElectionInterval, the elected DSBM sends out an [IEEE802Q] "IEEE Standards for Local and Metropolitan Area
I_AM_DSBM advertisement and the DSBM is then operational. Networks: Virtual Bridged Local Area Networks", Draft
Standard P802.1Q/D9, February 20, 1998.
A.4. DSBM Advertisements [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.
The I_AM_DSBM advertisement contains the following information: [IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-
1993.
1. DSBM address information -- contains the IP and L2 addresses A.1. Introduction
of the DSBM and its SBM priority (a configuration parameter
SBM (Subnet Bandwidth Manager) January, 2000 To simplify the rest of this discussion, we will assume that there is
a single DSBM for the entire L2 domain (i.e., assume a shared L2
segment for the entire L2 domain). Later, we will discuss how a DSBM
is elected for a half-duplex or full-duplex switched segment.
-- priority specified by a network administrator). The priority To allow for quick recovery from the failure of a DSBM, we assume
value is used to choose among candidate SBMs during the that additional SBMs may be active in a L2 domain for fault
election algorithm. Higher integer values indicate higher tolerance. When more than one SBM is active in a L2 domain, the SBMs
priority and the value is in the range 0..255. The value zero use an election algorithm to elect a DSBM for the L2 domain. After
indicates that the SBM is not eligible to be the DSBM. The the DSBM is elected and is operational, other SBMs remain passive in
IP address is required and used for breaking ties. The L2 the background to step in to elect a new DSBM when necessary. The
address is for the interface of the managed segment. protocol for electing and discovering DSBM is called the "DSBM
election protocol" and is described in the rest of this Appendix.
2. RegreshInterval -- contains the value of RefreshInterval A.1.1. How a DSBM Client Detects a Managed Segment
in seconds. Value zero indicates the parameter has been
omitted in the message. Receivers may substitute their own
default value in this case.
3. DSBMDeadInterval -- contains the value of DSBMDeadInterval Once elected, a DSBM periodically multicasts an I_AM_DSBM message on
in seconds. If the value is omitted (or value zero is specified), the AllSBMAddress to indicate its presence. The message is sent every
a default value (from initial configuration) should be period (e.g., every 5 seconds) according to the RefreshInterval timer
used. value (a configuration parameter). Absence of such a message over a
certain time interval (called "DSBMDeadInterval"; another
configuration parameter typically set to a multiple of
RefreshInterval) indicates that the DSBM has failed or terminated and
triggers another round of the DSBM election. The DSBM clients always
listen for periodic DSBM advertisements. The advertisement includes
the unicast IP address of the DSBM (DSBMAddress) and DSBM clients
send their PATH/RESV (or other) messages to the DSBM. When a DSBM
client detects the failure of a DSBM, it waits for a subsequent
I_AM_DSBM advertisement before resuming any communication with the
DSBM. During the period when a DSBM is not present, a DSBM client may
forward outgoing PATH messages using the standard RSVP forwarding
rules.
4. Miscellaneous configuration information to be advertised to The exact message formats and addresses used for communication with
senders on the managed segment. See Appendix C for further (and among) SBM(s) are described in Appendix B.
details.
A.5. DSBM_WILLING Messages A.2. Overview of the DSBM Election Procedure
When a SBM wishes to declare its candidacy to be the DSBM during When a SBM first starts up, it listens for incoming DSBM
an election phase, it sends out a DSBM_WILLING message. The advertisements for some period to check whether a DSBM already exists
DSBM_WILLING message contains the following information: in its L2 domain. If one already exists (and no new election is in
progress), the new SBM stays quiet in the background until an
election of DSBM is necessary. All messages related to the DSBM
election and DSBM advertisements are always sent to the
AllSBMAddress.
1. DSBM address information -- Contains the SBM's own addresses If no DSBM exists, the SBM initiates the election of a DSBM by
(IP and L2 address), if it wishes to be the DSBM. The IP sending out a DSBM_WILLING message that lists its IP address as a
address is required and used for breaking ties. The L2 candidate DSBM and its "SBM priority". Each SBM is assigned a
address is the address of the interface for the managed priority to determine its relative precedence. When more than one
segment in question. Also, the DSBM address information SBM candidate exists, the SBM priority determines who gets to be the
includes the corresponding priority of the SBM whose address DSBM based on the relative priority of candidates. If there is a tie
is given above. based on the priority value, the tie is broken using the IP
addresses of tied candidates (one with the higher IP address in the
lexicographic order wins). The details of the election protocol start
in Section A.4.
SBM (Subnet Bandwidth Manager) January, 2000 A.2.1 Summary of the Election Algorithm
A.6. SBM State Variables For the purpose of the algorithm, a SBM is in one of the four states
(Idle, DetectDSBM, ElectDSBM, IAMDSBM).
For each network interface, a SBM maintains the following state A SBM (call it X) starts up in the DetectDSBM state and waits for a
variables related to the election of the DSBM for the L2 domain on ListenInterval for incoming I_AM_DSBM (DSBM advertisement) or
that interface: DSBM_WILLING messages. If an I_AM_DSBM advertisement is received
during this state, the SBM notes the current DSBM (its IP address and
priority) and enters the Idle state. If a DSBM_WILLING message is
received from another SBM (call it Y) during this state, then X
enters the ElectDSBM state. Before entering the new state, X first
checks to see whether it itself is a better candidate than Y and, if
so, sends out a DSBM_WILLING message and then enters the ElectDSBM
state.
a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, When a SBM (call it X) enters the ElectDSBM state, it sets a timer
0.0.0.0) and priority. All IP addresses are assumed to be in (called ElectionIntervalTimer, and typically set to a value at least
network byte order. In addition, current DSBM's L2 address is equal to the DSBMDeadInterval value) to wait for the election to
also stored as part of this state information. finish and to discover who is the best candidate. In this state, X
keeps track of the best (or better) candidate seen so far (including
itself). Whenever it receives another DSBM_WILLING message it updates
its notion of the best (or better) candidate based on the priority
(and tie-breaking) criterion. During the ElectionInterval, X sends
out a DSBM_WILLING message every RefreshInterval to (re)assert its
candidacy.
b) OwnAddrInfo -- SBM's own IP address and L2 address for the At the end of the ElectionInterval, X checks whether it is the best
interface and its own priority (a configuration parameter). candidate so far. If so, it declares itself to be the DSBM (by
sending out the I_AM_DSBM advertisement) and enters the IAMDSBM
state; otherwise, it decides to wait for the best candidate to
declare itself the winner. To wait, X re-initializes its ElectDSBM
state and continues to wait for another round of election (each round
lasts for an ElectionTimerInterval duration).
c) RefreshInterval in seconds. When the DSBM is not yet A SBM is in Idle state when no election is in progress and the DSBM
elected, it is set to a default value specified as a is already elected (and happens to be someone else). In this state,
configuration parameter. it listens for incoming I_AM_DSBM advertisements and uses a
DSBMDeadIntervalTimer to detect the failure of DSBM. Every time the
advertisement is received, the timer is restarted. If the timer
fires, the SBM goes into the DetectDSBM state to prepare to elect the
new DSBM. If a SBM receives a DSBM_WILLING message from the current
DSBM in this state, the SBM enters the ElectDSBM state after sending
out a DSBM_WILLING message (to announce its own candidacy).
d) DSBMDeadInterval in seconds. When the DSBM is not yet In the IAMDSBM state, the DSBM sends out I_AM_DSBM advertisements
elected, it is initially set to a default value specified as every refresh interval. If the DSBM wishes to shut down (gracefully
a configuration parameter. terminate), it sends out a DSBM_WILLING message (with SBM priority
value set to zero) to initiate the election procedure. The priority
value zero effectively removes the outgoing DSBM from the election
procedure and makes way for the election of a different DSBM.
f) ListenInterval in seconds -- a configuration parameter A.3. Recovering from DSBM Failure
that decides how long a SBM spends in the DetectDSBM state
(see below).
g) ElectionInterval in seconds -- a configuration parameter When a DSBM fails (DSBMDeadIntervalTimer fires), all the SBMs enter
that decides how long a SBM spends in the ElectDSBM state the ElectDSBM state and start the election process.
when it has declared its candidacy.
Figure 3 shows the state transition diagram for the election At the end of the ElectionInterval, the elected DSBM sends out an
protocol and the various states are described below. A complete I_AM_DSBM advertisement and the DSBM is then operational.
description of the state machine is provided in Section A.10.
A.7. DSBM Election States A.4. DSBM Advertisements
DOWN -- SBM is not operational. The I_AM_DSBM advertisement contains the following information:
SBM (Subnet Bandwidth Manager) January, 2000 1. DSBM address information -- contains the IP and L2 addresses of
the DSBM and its SBM priority (a configuration parameter --
priority specified by a network administrator). The priority
value is used to choose among candidate SBMs during the election
algorithm. Higher integer values indicate higher priority and the
value is in the range 0..255. The value zero indicates that the
SBM is not eligible to be the DSBM. The IP address is required
and used for breaking ties. The L2 address is for the interface
of the managed segment.
DetectDSBM -- typically, the initial state of a SBM when it 2. RegreshInterval -- contains the value of RefreshInterval in
starts up. In this state, it checks to see whether a DSBM seconds. Value zero indicates the parameter has been omitted in
already exists in its domain. the message. Receivers may substitute their own default value in
this case.
Idle -- SBM is in this state when no election is in progress 3. DSBMDeadInterval -- contains the value of DSBMDeadInterval in
and it is not the DSBM. In this state, SBM passively monitors seconds. If the value is omitted (or value zero is specified), a
the state of the DSBM. default value (from initial configuration) should be used.
ElectDSBM -- SBM is in this state when a DSBM election is in 4. Miscellaneous configuration information to be advertised to
progress. senders on the managed segment. See Appendix C for further
details.
IAMDSBM -- SBM is in this state when it is the DSBM for the A.5. DSBM_WILLING Messages
L2 domain.
A.8. Events that cause state changes When a SBM wishes to declare its candidacy to be the DSBM during an
election phase, it sends out a DSBM_WILLING message. The DSBM_WILLING
message contains the following information:
StartUp -- SBM starts operation. 1. DSBM address information -- Contains the SBM's own addresses (IP
and L2 address), if it wishes to be the DSBM. The IP address is
required and used for breaking ties. The L2 address is the
address of the interface for the managed segment in question.
Also, the DSBM address information includes the corresponding
priority of the SBM whose address is given above.
ListenInterval Timeout -- The ListenInterval timer has fired. A.6. SBM State Variables
This means that the SBM has monitored its domain to check for
an existing DSBM or to check whether there are candidates
(other than itself) willing to be the DSBM.
DSBM_WILLING message received -- This means that the SBM For each network interface, a SBM maintains the following state
received a DSBM_WILLING message from some other SBM. Such a variables related to the election of the DSBM for the L2 domain on
message is sent when a SBM wishes to declare its candidacy to that interface:
be the DSBM.
I_AM_DSBM message received -- SBM received a DSBM advertisement a) LocalDSBMAddrInfo -- current DSBM's IP address (initially,
from the DSBM in its L2 domain. 0.0.0.0) and priority. All IP addresses are assumed to be in
network byte order. In addition, current DSBM's L2 address is
also stored as part of this state information.
DSBMDeadInterval Timeout -- The DSBMDeadIntervalTimer has b) OwnAddrInfo -- SBM's own IP address and L2 address for the
fired. This means that the SBM did not receive even one DSBM interface and its own priority (a configuration parameter).
advertisement during this period and indicates possible
failure of the DSBM.
SBM (Subnet Bandwidth Manager) January, 2000 c) RefreshInterval in seconds. When the DSBM is not yet elected,
it is set to a default value specified as a configuration
parameter.
RefreshInterval Timeout -- The RefreshIntervalTimer has d) DSBMDeadInterval in seconds. When the DSBM is not yet elected,
fired. In the IAMDSBM state, this means it is the time for it is initially set to a default value specified as a
sending out the next DSBM advertisement. In the ElectDSBM configuration parameter.
state, the event means that it is the time to send out
another DSBM_WILLING message.
ElectionInterval Timeout -- The ElectionIntervalTimer has f) ListenInterval in seconds -- a configuration parameter that
fired. This means that the SBM has waited long enough after decides how long a SBM spends in the DetectDSBM state (see
declaring its candidacy to determine whether or not it below).
succeeded.
CONTINUED ON NEXT PAGE g) ElectionInterval in seconds -- a configuration parameter that
decides how long a SBM spends in the ElectDSBM state when it has
declared its candidacy.
SBM (Subnet Bandwidth Manager) January, 2000 Figure 3 shows the state transition diagram for the election protocol
and the various states are described below. A complete description of
the state machine is provided in Section A.10.
A.9. State Transition Diagram (Figure 3) A.7. DSBM Election States
+-----------+ DOWN -- SBM is not operational.
+--<--------------<-|DetectDSBM |---->------+
| +-----------+ |
| |
| |
| |
| +-------------+ +---------+ |
+->---| Idle |--<>---|ElectDSBM|--<--+
+-------------+ +---------+
| |
| |
| |
| +-----------+ |
+<<- +---| IAMDSBM |-<-+
| +-----------+
|
| +-----------+
+>>-| SHUTDOWN |
+-----------+
A.10. Election State Machine DetectDSBM -- typically, the initial state of a SBM when it
starts up. In this state, it checks to see whether a DSBM already
exists in its domain.
Based on the events and states described above, the state changes Idle -- SBM is in this state when no election is in progress and
at a SBM are described below. Each state change is triggered by an it is not the DSBM. In this state, SBM passively monitors the
event and is typically accompanied by a sequence of actions. The state of the DSBM.
state machine is described assuming a single threaded implementation
(to avoid race conditions between state changes and timer
events) with no timer events occurring during the execution of the
state machine.
The following routines will be frequently used in the description ElectDSBM -- SBM is in this state when a DSBM election is in
of the state machine: progress.
ComparePrio(FirstAddrInfo, SecondAddrInfo) IAMDSBM -- SBM is in this state when it is the DSBM for the L2
-- determines whether the entity represented by the first parameter domain.
is better than the second entity using the priority information
and the IP address information in the two parameters.
If any address is zero, that entity
automatically loses; then first priorities are compared; higher
priority candidate wins. If there is a tie based on
the priority value, the tie is broken using the IP
addresses of tied candidates (one with the higher IP address in the
lexicographic order wins). Returns TRUE if first entity is a better
SBM (Subnet Bandwidth Manager) January, 2000 A.8. Events that cause state changes
choice. FALSE otherwise. StartUp -- SBM starts operation.
SendDSBMWilling Message() ListenInterval Timeout -- The ListenInterval timer has fired.
Begin This means that the SBM has monitored its domain to check for an
Send out DSBM_WILLING message listing myself as a candidate for existing DSBM or to check whether there are candidates (other
DSBM (copy OwnAddr and priority into appropriate fields) than itself) willing to be the DSBM.
start RefreshIntervalTimer
goto ElectDSBM state
End
AmIBetterDSBM(OtherAddrInfo) DSBM_WILLING message received -- This means that the SBM received
Begin a DSBM_WILLING message from some other SBM. Such a message is
if (ComparePrio(OwnAddrInfo, OtherAddrInfo)) sent when a SBM wishes to declare its candidacy to be the DSBM.
return TRUE
change LocalDSBMInfo = OtherDSBMAddrInfo I_AM_DSBM message received -- SBM received a DSBM advertisement
return FALSE from the DSBM in its L2 domain.
End
UpdateDSBMInfo() DSBMDeadInterval Timeout -- The DSBMDeadIntervalTimer has fired.
/* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */ This means that the SBM did not receive even one DSBM
Begin advertisement during this period and indicates possible failure
update LocalDSBMInfo such as IP addr, DSBM L2 address, of the DSBM.
DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer
End
A.10.1 State Changes RefreshInterval Timeout -- The RefreshIntervalTimer has fired. In
the IAMDSBM state, this means it is the time for sending out the
next DSBM advertisement. In the ElectDSBM state, the event means
that it is the time to send out another DSBM_WILLING message.
In the following, the action "continue" or "continue in current ElectionInterval Timeout -- The ElectionIntervalTimer has fired.
state" means an "exit" from the current action sequence without a This means that the SBM has waited long enough after declaring
state transition. its candidacy to determine whether or not it succeeded.
State: DOWN A.9. State Transition Diagram (Figure 3)
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 +--<--------------<-|DetectDSBM |---->------+
Event: I_AM_DSBM message received | +-----------+ |
Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo | |
start DeadDSBMInterval timer | |
goto Idle State | |
| +-------------+ +---------+ |
+->---| Idle |--<>---|ElectDSBM|--<--+
+-------------+ +---------+
| |
| |
| |
| +-----------+ |
+<<- +---| IAMDSBM |-<-+
| +-----------+
|
| +-----------+
+>>-| SHUTDOWN |
+-----------+
SBM (Subnet Bandwidth Manager) January, 2000 A.10. Election State Machine
State: DetectDSBM Based on the events and states described above, the state changes at
Event: ListenIntervalTimer fired a SBM are described below. Each state change is triggered by an event
New State: ElectDSBM and is typically accompanied by a sequence of actions. The state
Action: Start ElectionIntervalTimer machine is described assuming a single threaded implementation (to
SendDSBMWillingMessage(); avoid race conditions between state changes and timer events) with no
timer events occurring during the execution of the state machine.
State: DetectDSBM The following routines will be frequently used in the description of
Event: DSBM_WILLING message received the state machine:
New State: ElectDSBM
Action: Cancel any active timers
Start ElectionIntervalTimer ComparePrio(FirstAddrInfo, SecondAddrInfo)
/* am I a better choice than this dude? */ -- determines whether the entity represented by the first parameter
If (ComparePrio(OwnAddrInfo, IncomingDSBMInfo)) { is better than the second entity using the priority information
/* I am better */ and the IP address information in the two parameters. If any
SendDSBMWillingMessage() address is zero, that entity automatically loses; then first
} else { priorities are compared; higher priority candidate wins. If there
Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo is a tie based on the priority value, the tie is broken using the
goto ElectDSBM state IP addresses of tied candidates (one with the higher IP address
} in the lexicographic order wins). Returns TRUE if first entity
is a better choice. FALSE otherwise.
State: Idle SendDSBMWilling Message()
Event: DSBMDeadIntervalTimer fired. Begin
New State: ElectDSBM Send out DSBM_WILLING message listing myself as a candidate for
Action: start ElectionIntervalTimer DSBM (copy OwnAddr and priority into appropriate fields)
set LocalDSBMAddrInfo = OwnAddrInfo start RefreshIntervalTimer
SendDSBMWiliingMessage() goto ElectDSBM state
End
State: Idle AmIBetterDSBM(OtherAddrInfo)
Event: I_AM_DSBM message received. Begin
New State: Idle if (ComparePrio(OwnAddrInfo, OtherAddrInfo))
Action: /* first check whether anything has changed */ return TRUE
if (!ComparePrio(LocalDSBMAddrInfo, IncomingDSBMAddrInfo))
change LocalDSBMAddrInfo to reflect new info
endif
restart DSBMDeadIntervalTimer;
continue in current state;
State: Idle change LocalDSBMInfo = OtherDSBMAddrInfo
Event: DSBM_WILLING Message is received return FALSE
New State: Depends on action (ElectDSBM or Idle) End
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 */
}
SBM (Subnet Bandwidth Manager) January, 2000 UpdateDSBMInfo()
/* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */
Begin
update LocalDSBMInfo such as IP addr, DSBM L2 address,
DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer
End
/* else, ignore it */ A.10.1 State Changes
continue in current state
State: ElectDSBM In the following, the action "continue" or "continue in current
Event: ElectionIntervalTimer Fired state" means an "exit" from the current action sequence without a
New State: depends on action (IAMDSBM or Current State) state transition.
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 State: DOWN
Event: I_AM_DSBM message received Event: StartUp
New State: Idle New State: DetectDSBM
Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo Action: Initialize the local state variables (LocalDSBMADDR and
Cancel any active timers LocalDSBMAddrInfo set to 0). Start the ListenIntervalTimer.
start DeadDSBMInterval timer
goto Idle State
State: ElectDSBM State: DetectDSBM
Event: DSBM_WILLING message received New State: Idle
New State: ElectDSBM Event: I_AM_DSBM message received
Action: Check whether it's a loopback and if so, discard, continue; Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo
if (!AmIBetterDSBM(IncomingDSBMAddrInfo)) { start DeadDSBMInterval timer
Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo goto Idle State
Cancel RefreshIntervalTimer
} else if (LocalDSBMAddrInfo == OwnAddrInfo) {
SendDSBMWillingMessage()
}
continue in current state
State: ElectDSBM State: DetectDSBM
Event: RefreshIntervalTimer fired Event: ListenIntervalTimer fired
New State: ElectDSBM New State: ElectDSBM
Action: /* continue to send DSBMWilling messages until Action: Start ElectionIntervalTimer
election interval ends */ SendDSBMWillingMessage();
SendDSBMWillingMessage()
State: IAMDSBM State: DetectDSBM
Event: DSBM_WILLING message received Event: DSBM_WILLING message received
New State: ElectDSBM
Action: Cancel any active timers
SBM (Subnet Bandwidth Manager) January, 2000 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
}
New State: depends on action (IAMDSBM or SteadyState) State: Idle
Action: /* check whether other guy is better */ Event: DSBMDeadIntervalTimer fired.
If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) { New State: ElectDSBM
/* I am better */ Action: start ElectionIntervalTimer
send I_AM_DSBM message set LocalDSBMAddrInfo = OwnAddrInfo
restart RefreshIntervalTimer SendDSBMWiliingMessage()
continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto SteadyState
}
State: IAMDSBM State: Idle
Event: RefreshIntervalTimer fired Event: I_AM_DSBM message received.
New State: IAMDSBM New State: Idle
Action: send I_AM_DSBM message Action: /* first check whether anything has changed */
restart RefreshIntervalTimer if (!ComparePrio(LocalDSBMAddrInfo, IncomingDSBMAddrInfo))
change LocalDSBMAddrInfo to reflect new info
endif
restart DSBMDeadIntervalTimer;
continue in current state;
State: IAMDSBM State: Idle
Event: I_AM_DSBM message received Event: DSBM_WILLING Message is received
New State: depends on action (IAMDSBM or Idle) New State: Depends on action (ElectDSBM or Idle)
Action: /* check whether other guy is better */ Action: /* check whether it is from the DSBM itself (shutdown) */
If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) { if (IncomingDSBMAddr == LocalDSBMAddr) {
/* I am better */ cancel active timers
send I_AM_DSBM message Set LocalDSBMAddrInfo = OwnAddrInfo
restart RefreshIntervalTimer Start ElectionIntervalTimer
continue in current state SendDSBMWillingMessage() /* goto ElectDSBM state */
} else { }
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto Idle State
}
State: IAMDSBM /* else, ignore it */
Event: Want to shut myself down continue in current state
New State: DOWN
Action: send DSBM_WILLING message with My address filled in, but
priority set to zero
goto Down State
A.10.2 Suggested Values of Interval Timers 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
}
To avoid DSBM outages for long period, to ensure quick recovery 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
SBM (Subnet Bandwidth Manager) January, 2000 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
from DSBM failures, and to avoid timeout of PATH and RESV state at State: ElectDSBM
the edge devices, we suggest the following values for various Event: RefreshIntervalTimer fired
timers. New State: ElectDSBM
Action: /* continue to send DSBMWilling messages until
election interval ends */
SendDSBMWillingMessage()
Assuming that the RSVP implementations use a 30 second timeout for State: IAMDSBM
PATH and RESV refreshes, we suggest that the RefreshIntervalTimer Event: DSBM_WILLING message received
should be set to about 5 seconds with DSBMDeadIntervalTimer set to New State: depends on action (IAMDSBM or SteadyState)
15 seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be Action: /* check whether other guy is better */
set to a random value between (DSBMDeadIntervalTimer, If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
2*DSBMDeadIntervalTimer). The ElectionIntervalTimer should be set at /* I am better */
least to the value of DSBMDeadIntervalTimer to ensure that each SBM send I_AM_DSBM message
has a chance to have its DSBM_WILLING message (sent every restart RefreshIntervalTimer
RefreshInterval in ElectDSBM state) delivered to others. continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto SteadyState
}
A.10.3. Guidelines for Choice of Values for SBM_PRIORITY State: IAMDSBM
Event: RefreshIntervalTimer fired
New State: IAMDSBM
Action: send I_AM_DSBM message
restart RefreshIntervalTimer
Network administrators should configure SBM protocol entity at State: IAMDSBM
each SBM-capable device with the device's "SBM priority" for each Event: I_AM_DSBM message received
of the interfaces attached to a managed segment. SBM_PRIORITY is New State: depends on action (IAMDSBM or Idle)
an 8-bit, unsigned integer value (in the range 0-255) with higher Action: /* check whether other guy is better */
integer values denoting higher priority. The value zero for an If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) {
interface indicates that the SBM protocol entity on the device is /* I am better */
not eligible to be a DSBM for the segment attached to the send I_AM_DSBM message
interface. restart RefreshIntervalTimer
continue in current state
} else {
Set LocalDSBMAddrInfo = IncomingAddrInfo
cancel active timers
start DSBMDeadIntervalTimer
goto Idle State
}
A separate range of values is reserved for each type of SBM-capable State: IAMDSBM
device to reflect the relative priority among different Event: Want to shut myself down
classes of L2/L3 devices. L2 devices get higher priority followed New State: DOWN
by routers followed by hosts. The priority values in the range of Action: send DSBM_WILLING message with My address filled in, but
128..255 are reserved for L2 devices, the values in the range of priority set to zero
64..127 are reserved for routers, and values in the range of 1..63 goto Down State
are reserved for hosts.
A.11. DSBM Election over switched links A.10.2 Suggested Values of Interval Timers
The election algorithm works as described before in this case To avoid DSBM outages for long period, to ensure quick recovery from
except each SBM-capable L2 device restricts the scope of the election DSBM failures, and to avoid timeout of PATH and RESV state at the
to its local segment. As described in Section B.1 below, all edge devices, we suggest the following values for various timers.
messages related to the DSBM election are sent to a special multicast
address (AllSBMAddress). AllSBMAddress (its corresponding MAC
multicast address) is configured in the permanent database of
SBM-capable, layer 2 devices so that all frames with AllSBMAddress
as the destination address are not forwarded and instead directed
SBM (Subnet Bandwidth Manager) January, 2000 Assuming that the RSVP implementations use a 30 second timeout for
PATH and RESV refreshes, we suggest that the RefreshIntervalTimer
should be set to about 5 seconds with DSBMDeadIntervalTimer set to 15
seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be set
to a random value between (DSBMDeadIntervalTimer,
2*DSBMDeadIntervalTimer). The ElectionIntervalTimer should be set at
least to the value of DSBMDeadIntervalTimer to ensure that each SBM
has a chance to have its DSBM_WILLING message (sent every
RefreshInterval in ElectDSBM state) delivered to others.
to the SBM management entity in those devices. Thus, a DSBM can be A.10.3. Guidelines for Choice of Values for SBM_PRIORITY
elected separately on each point-to-point segment in a switched
topology. For example, in Figure 2, DSBM for "segment A" will be
elected using the election algorithm between R1 and S1 and none of
the election-related messages on this segment will be forwarded by
S1 beyond "segment A". Similarly, a separate election will take
place on each segment in this topology.
When a switched segment is a half-duplex segment, two senders (one Network administrators should configure SBM protocol entity at each
sender at each end of the link) share the link. In this case, one SBM-capable device with the device's "SBM priority" for each of the
of the two senders will win the DSBM election and will be interfaces attached to a managed segment. SBM_PRIORITY is an 8-bit,
responsible for managing the segment. unsigned integer value (in the range 0-255) with higher integer
values denoting higher priority. The value zero for an interface
indicates that the SBM protocol entity on the device is not eligible
to be a DSBM for the segment attached to the interface.
If a switched segment is full-duplex, exactly one sender sends on A separate range of values is reserved for each type of SBM-capable
the link in each direction. In this case, either one or two DSBMs device to reflect the relative priority among different classes of
can exist on such a managed segment. If a sender at each end L2/L3 devices. L2 devices get higher priority followed by routers
wishes to serve as a DSBM for that end, it can declare itself to followed by hosts. The priority values in the range of 128..255 are
be the DSBM by sending out an I_AM_DSBM advertisement and start reserved for L2 devices, the values in the range of 64..127 are
managing the resources for the outgoing traffic over the segment. reserved for routers, and values in the range of 1..63 are reserved
If one of the two senders does not wish itself to be the DSBM, for hosts.
then the other DSBM will not receive any DSBM advertisement from
its peer and assume itself to be the DSBM for traffic traversing
in both directions over the managed segment.
SBM (Subnet Bandwidth Manager) January, 2000 A.11. DSBM Election over switched links
Appendix B The election algorithm works as described before in this case except
Message Encapsulation and Formats each SBM-capable L2 device restricts the scope of the election to its
local segment. As described in Section B.1 below, all messages
related to the DSBM election are sent to a special multicast address
(AllSBMAddress). AllSBMAddress (its corresponding MAC multicast
address) is configured in the permanent database of SBM-capable,
layer 2 devices so that all frames with AllSBMAddress as the
destination address are not forwarded and instead directed to the SBM
management entity in those devices. Thus, a DSBM can be elected
separately on each point-to-point segment in a switched topology. For
example, in Figure 2, DSBM for "segment A" will be elected using the
election algorithm between R1 and S1 and none of the election-related
messages on this segment will be forwarded by S1 beyond "segment A".
Similarly, a separate election will take place on each segment in
this topology.
To minimize changes to the existing RSVP implementations and to When a switched segment is a half-duplex segment, two senders (one
ensure quick deployment of a SBM in conjunction with RSVP, all sender at each end of the link) share the link. In this case, one of
communication to and from a DSBM will be performed using messages the two senders will win the DSBM election and will be responsible
constructed using the current rules for RSVP message formats and for managing the segment.
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 If a switched segment is full-duplex, exactly one sender sends on the
link in each direction. In this case, either one or two DSBMs can
exist on such a managed segment. If a sender at each end wishes to
serve as a DSBM for that end, it can declare itself to be the DSBM by
sending out an I_AM_DSBM advertisement and start managing the
resources for the outgoing traffic over the segment. If one of the
two senders does not wish itself to be the DSBM, then the other DSBM
will not receive any DSBM advertisement from its peer and assume
itself to be the DSBM for traffic traversing in both directions over
the managed segment.
For the purpose of DSBM election and detection, AllSBMAddress is Appendix B Message Encapsulation and Formats
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 To minimize changes to the existing RSVP implementations and to
ensure quick deployment of a SBM in conjunction with RSVP, all
communication to and from a DSBM will be performed using messages
constructed using the current rules for RSVP message formats and raw
IP encapsulation. For more details on the RSVP message formats, refer
to the RSVP specification (RFC 2205). No changes to the RSVP message
formats are proposed, but new message types and new L2-specific
objects are added to the RSVP message formats to accommodate DSBM-
related messages. These additions are described below.
Each message must occupy exactly one IP datagram. If it exceeds B.1 Message Addressing
the MTU, such a datagram will be fragmented by IP and reassembled
at the recipient node. This has a consequence that a single
message may not exceed the maximum IP datagram size, approximately
64K bytes.
B.3. RSVP-related Message Formats 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).
All RSVP messages directed to and from a DSBM may contain various B.2. Message Sizes
RSVP objects defined in the RSVP specification and messages continue
to follow the formatting rules specified in the RSVP specification.
In addition, an RSVP implementation must also recognize
new object classes that are described below.
B.3.1. Object Formats Each message must occupy exactly one IP datagram. If it exceeds the
MTU, such a datagram will be fragmented by IP and reassembled at the
recipient node. This has a consequence that a single message may not
exceed the maximum IP datagram size, approximately 64K bytes.
SBM (Subnet Bandwidth Manager) January, 2000 B.3. RSVP-related Message Formats
All objects are defined using the format specified in the RSVP All RSVP messages directed to and from a DSBM may contain various
specification. Each object has a 32-bit header that contains RSVP objects defined in the RSVP specification and messages continue
length (of the object in bytes including the object header), the to follow the formatting rules specified in the RSVP specification.
object class number, and a C-Type. All unused fields should be set In addition, an RSVP implementation must also recognize new object
to zero and ignored on receipt. classes that are described below.
B.3.2. SBM Specific Objects B.3.1. Object Formats
Note that the Class-Num values for the SBM specific objects All objects are defined using the format specified in the RSVP
(LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2) are chosen from the specification. Each object has a 32-bit header that contains length
codespace 10XXXXXX. This coding assures that non-SBM aware RSVP (of the object in bytes including the object header), the object
nodes will ignore the objects without forwarding them or class number, and a C-Type. All unused fields should be set to zero
generating an error message. and ignored on receipt.
Within the SBM specific codespace, note the following interpretation B.3.2. SBM Specific Objects
of the third most significant bit of the Class-Num:
a) Objects of the form 100XXXXX are to be silently Note that the Class-Num values for the SBM specific objects
discarded by SBM nodes that do not recognize them. (LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2) are chosen from the
codespace 10XXXXXX. This coding assures that non-SBM aware RSVP nodes
will ignore the objects without forwarding them or generating an
error message.
b) Objects of the form 101XXXXX are to be silently Within the SBM specific codespace, note the following interpretation
forwarded by SBM nodes that do not recognize them. of the third most significant bit of the Class-Num:
B.3.3. IEEE 802 Canonical Address Format a) Objects of the form 100XXXXX are to be silently
discarded by SBM nodes that do not recognize them.
The 48-bit MAC Addresses used by IEEE 802 were originally defined b) Objects of the form 101XXXXX are to be silently
in terms of wire order transmission of bits in the source and forwarded by SBM nodes that do not recognize them.
destination MAC address fields. The same wire order applied to both
Ethernet and Token Ring. Since the bit transmission order of Ethernet
and Token Ring data differ - Ethernet octets are transmitted
least significant bit first, Token Ring most significant first -
the numeric values naturally associated with the same address on
different 802 media differ. To facilitate the communication of
address values in higher layer protocols which might span both
token ring and Ethernet attached systems connected by bridges, it
was necessary to define one reference format - the so called canonical
format for these addresses. Formally the canonical format
defines the value of the address, separate from the encoding rules
used for transmission. It comprises a sequence of octets derived
from the original wire order transmission bit order as follows. The
least significant bit of the first octet is the first bit transmitted,
the next least significant bit the second bit, and so on to
SBM (Subnet Bandwidth Manager) January, 2000 B.3.3. IEEE 802 Canonical Address Format
the most significant bit of the first octet being the 8th bit The 48-bit MAC Addresses used by IEEE 802 were originally defined in
transmitted; the least significant bit of the second octet is the terms of wire order transmission of bits in the source and
9th bit transmitted, and so on to the most significant bit of the destination MAC address fields. The same wire order applied to both
sixth octet of the canonical format being the last bit of the Ethernet and Token Ring. Since the bit transmission order of Ethernet
address transmitted. and Token Ring data differ - Ethernet octets are transmitted least
significant bit first, Token Ring most significant first - the
numeric values naturally associated with the same address on
different 802 media differ. To facilitate the communication of
address values in higher layer protocols which might span both token
ring and Ethernet attached systems connected by bridges, it was
necessary to define one reference format - the so called canonical
format for these addresses. Formally the canonical format defines the
value of the address, separate from the encoding rules used for
transmission. It comprises a sequence of octets derived from the
original wire order transmission bit order as follows. The least
significant bit of the first octet is the first bit transmitted, the
next least significant bit the second bit, and so on to the most
significant bit of the first octet being the 8th bit transmitted; the
least significant bit of the second octet is the 9th bit transmitted,
and so on to the most significant bit of the sixth octet of the
canonical format being the last bit of the address transmitted.
This canonical format corresponds to the natural value of the This canonical format corresponds to the natural value of the address
address octets for Ethernet. The actual transmission order or formal octets for Ethernet. The actual transmission order or formal encoding
encoding rules for addresses on media which do not transmit bit rules for addresses on media which do not transmit bit serially are
serially are derived from the canonical format octet values. derived from the canonical format octet values.
This document requires that all L2 addresses used in conjunction This document requires that all L2 addresses used in conjunction with
with the SBM protocol be encoded in the canonical format as a the SBM protocol be encoded in the canonical format as a sequence of
sequence of 6 octets. In the following, we define the object formats 6 octets. In the following, we define the object formats for objects
for objects that contain L2 addresses that are based on the that contain L2 addresses that are based on the canonical
canonical representation. representation.
B.3.4. RSVP_HOP_L2 object B.3.4. RSVP_HOP_L2 object
RSVP_HOP_L2 object uses object class = 161; it contains the L2 RSVP_HOP_L2 object uses object class = 161; it contains the L2
address of the previous hop L3 device in the IEEE Canonical address address of the previous hop L3 device in the IEEE Canonical address
format discussed above. format discussed above.
RSVP_HOP_L2 object: class = 161, C-Type represents the addressing format RSVP_HOP_L2 object: class = 161, C-Type represents the addressing
used. In our case, C-Type=1 represents the IEEE Canonical Address format used. In our case, C-Type=1 represents the IEEE Canonical
format. Address format.
0 1 2 3 0 1 2 3
+---------------+---------------+---------------+----------------+ +---------------+---------------+---------------+----------------+
| Length | 161 |C-Type(addrtype)| | Length | 161 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+ +---------------+---------------+---------------+----------------+
| Variable length Opaque data | | Variable length Opaque data |
+---------------+---------------+---------------+----------------+ +---------------+---------------+---------------+----------------+
C-Type = 1 (IEEE Canonical Address format) C-Type = 1 (IEEE Canonical Address format)
When C-Type=1, the object format is: When C-Type=1, the object format is:
0 1 2 3 0 1 2 3
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| 12 | 161 | 1 | | 12 | 161 | 1 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Octets 0-3 of the MAC address | | Octets 0-3 of the MAC address |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Octets 4-5 of the MAC addr. | /// | /// | | Octets 4-5 of the MAC addr. | /// | /// |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
SBM (Subnet Bandwidth Manager) January, 2000 /// -- unused (set to zero)
/// -- unused (set to zero) B.3.5. LAN_NHOP object
B.3.5. LAN_NHOP object LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address
object and LAN_NHOP_L2 address object.
<LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object>
LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address LAN_NHOP_L2 address object uses object class = 162 and uses the same
object and LAN_NHOP_L2 address object. format (but different class number) as the RSVP_HOP_L2 object. It
<LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object> provides the L2 or MAC address of the next hop L3 device.
LAN_NHOP_L2 address object uses object class = 162 and uses the 0 1 2 3
same format (but different class number) as the RSVP_HOP_L2 object. +---------------+---------------+---------------+----------------+
It provides the L2 or MAC address of the next hop L3 device. | Length | 162 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
0 1 2 3 C-Type = 1 (IEEE 802 Canonical Address Format as defined below) See
+---------------+---------------+---------------+----------------+ the RSVP_HOP_L2 address object for more details.
| Length | 162 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
C-Type = 1 (IEEE 802 Canonical Address Format as defined below) LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP
See the RSVP_HOP_L2 address object for more details. address of the next hop L3 device.
LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6
address of the next hop L3 device. address family used.
LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6 address IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1
family used. +---------------+---------------+---------------+---------------+
| Length = 8 | 163 | 1 |
+---------------+---------------+---------------+---------------+
| IPv4 NHOP address |
+---------------------------------------------------------------+
IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1 IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Length = 8 | 163 | 1 | | Length = 20 | 163 | 2 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| IPv4 NHOP address | | IPv6 NHOP address (16 bytes) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2 B.3.6. LAN_LOOPBACK Object
+---------------+---------------+---------------+---------------+
| 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.
SBM (Subnet Bandwidth Manager) January, 2000 IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1
The LAN_LOOPBACK object gives the IP address of the outgoing 0 1 2 3
interface for a PATH message and uses object class=164; both IPv4 +---------------+---------------+---------------+---------------+
and IPv6 formats are specified. | Length | 164 | 1 |
+---------------+---------------+---------------+---------------+
| IPV4 address of an interface |
+---------------+---------------+---------------+---------------+
IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2
IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1 +---------------+---------------+---------------+---------------+
| Length | 164 | 2 |
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPV6 address of an interface +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
0 1 2 3 B.3.7. TCLASS Object
+---------------+---------------+---------------+---------------+
| Length | 164 | 1 |
+---------------+---------------+---------------+---------------+
| IPV4 address of an interface |
+---------------+---------------+---------------+---------------+
IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2 TCLASS object (traffic class based on IEEE 802.1p) uses object
class = 165.
+---------------+---------------+---------------+---------------+ 0 1 2 3
| Length | 164 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------+---------------+---------------+---------------+ | Length | 165 | 1 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ + | /// | /// | /// | /// | PV |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ IPV6 address of an interface +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
B.3.7. TCLASS Object Only 3 bits in data contain the user_priority value (PV).
TCLASS object (traffic class based on IEEE 802.1p) uses object B.4. RSVP PATH and PATH_TEAR Message Formats
class = 165.
0 1 2 3 As specified in the RSVP specification, a PATH and PATH_TEAR messages
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ contain the RSVP Common Header and the relevant RSVP objects.
| Length | 165 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /// | /// | /// | /// | PV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Only 3 bits in data contain the user_priority value (PV). For the RSVP Common Header, refer to the RSVP specification (RFC
2205). Enhancements to an RSVP_PATH message include additional
objects as specified below.
B.4. RSVP PATH and PATH_TEAR Message Formats <PATH Message> ::= <RSVP Common Header> [<INTEGRITY>]
<RSVP_HOP_L2> <LAN_NHOP>
<LAN_LOOPBACK> [<TCLASS>] <SESSION><RSVP_HOP>
<TIME_VALUES> [<POLICY DATA>] <sender descriptor>
As specified in the RSVP specification, a PATH and PATH_TEAR messages <PATH_TEAR Message> ::= <RSVP Common Header> [<INTEGRITY>]
contain the RSVP Common Header and the relevant RSVP objects. <LAN_LOOPBACK> <LAN_NHOP> <SESSION> <RSVP_HOP>
[<sender descriptor>]
SBM (Subnet Bandwidth Manager) January, 2000 If the INTEGRITY object is present, it must immediately follow the
RSVP common header. L2-specific objects must always precede the
SESSION object.
For the RSVP Common Header, refer to the RSVP specification (RFC B.5. RSVP RESV Message Format
2205). Enhancements to an RSVP_PATH message include additional
objects as specified below.
<PATH Message> ::= <RSVP Common Header> [<INTEGRITY>] As specified in the RSVP specification, an RSVP_RESV message contains
<RSVP_HOP_L2> <LAN_NHOP> the RSVP Common Header and relevant RSVP objects. In addition, it may
<LAN_LOOPBACK> [<TCLASS>] <SESSION><RSVP_HOP> contain an optional TCLASS object as described earlier.
<TIME_VALUES> [<POLICY DATA>] <sender descriptor>
<PATH_TEAR Message> ::= <RSVP Common Header> [<INTEGRITY>] B.6. Additional RSVP message types to handle SBM interactions
<LAN_LOOPBACK> <LAN_NHOP> <SESSION> <RSVP_HOP>
[<sender descriptor>]
If the INTEGRITY object is present, it must immediately follow the New RSVP message types are introduced to allow interactions between a
RSVP common header. L2-specific objects must always precede the DSBM and an RSVP node (host/router) for the purpose of discovering
SESSION object. and binding to a DSBM. New RSVP message types needed are as follows:
B.5. RSVP RESV Message Format RSVP Msg Type (8 bits) Value
DSBM_WILLING 66
I_AM_DSBM 67
As specified in the RSVP specification, an RSVP_RESV message contains All SBM-specific messages are formatted as RSVP messages with an RSVP
the RSVP Common Header and relevant RSVP objects. In addition, it may common header followed by SBM-specific objects.
contain an optional TCLASS object as described earlier.
B.6. Additional RSVP message types to handle SBM interactions <SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects>
New RSVP message types are introduced to allow interactions between where <SBMP common header> ::= <RSVP common Header> [<INTEGRITY>]
a DSBM and an RSVP node (host/router) for the purpose of discovering
and binding to a DSBM. New RSVP message types needed are as
follows:
RSVP Msg Type (8 bits) Value For each SBM message type, there is a set of rules for the
DSBM_WILLING 66 permissible choice of object types. These rules are specified using
I_AM_DSBM 67
All SBM-specific messages are formatted as RSVP messages with an Backus-Naur Form (BNF) augmented with square brackets surrounding
RSVP common header followed by SBM-specific objects. optional sub-sequences. The BNF implies an order for the objects in a
message. However, in many (but not all) cases, object order makes no
logical difference. An implementation should create messages with the
objects in the order shown here, but accept the objects in any
permissible order. Any exceptions to this rule will be pointed out in
the specific message formats.
<SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects> DSBM_WILLING Message
where <SBMP common header> ::= <RSVP common Header> [<INTEGRITY>] <DSBM_WILLING message> ::= <SBM Common Header> <DSBM IP ADDRESS>
<DSBM L2 address> <SBM PRIORITY>
For each SBM message type, there is a set of rules for the I_AM_DSBM Message
permissible choice of object types. These rules are specified using
SBM (Subnet Bandwidth Manager) January, 2000 <I_AM_DSBM> ::= <SBM Common Header> <DSBM IP ADDRESS> <DSBM L2 address>
<SBM PRIORITY> <DSBM Timer Intervals>
[<NON_RESV_SEND_LIMIT>]
Backus-Naur Form (BNF) augmented with square brackets surrounding For compatibility reasons, receivers of the I_AM_DSBM message must be
optional sub-sequences. The BNF implies an order for the objects in prepared to receive additional objects of the Unknown Class type
a message. However, in many (but not all) cases, object order makes [RFC-2205].
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 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.
<DSBM_WILLING message> ::= <SBM Common Header> <DSBM IP ADDRESS> Relevant Objects
<DSBM L2 address> <SBM PRIORITY>
I_AM_DSBM Message DSBM IP ADDRESS objects use object class = 42; IPv4 DSBM IP ADDRESS
object uses <Class=42, C-Type=1> and IPv6 DSBM IP ADDRESS object uses
<Class=42, C-Type=2>.
<I_AM_DSBM> ::= <SBM Common Header> <DSBM IP ADDRESS> <DSBM L2 address> IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1
<SBM PRIORITY> <DSBM Timer Intervals> 0 1 2 3
[<NON_RESV_SEND_LIMIT>] +---------------+---------------+---------------+---------------+
| IPv4 DSBM IP Address |
+---------------+---------------+---------------+---------------+
For compatibility reasons, receivers of the I_AM_DSBM message must IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 2
be prepared to receive additional objects of the Unknown Class type
[RFC-2205].
All I_AM_DSBM messages are multicast to the well known AllSBMAddress. +---------------+---------------+---------------+---------------+
The default priority of a SBM is 1 and higher priority | |
values represent higher precedence. The priority value zero + +
indicates that the SBM is not eligible to be the DSBM. | |
+ IPv6 DSBM IP Address +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
Relevant Objects <DSBM L2 address> Object is the same as <RSVP_HOP_L2> object with C-
Type = 1 for IEEE Canonical Address format.
DSBM IP ADDRESS objects use object class = 42; IPv4 DSBM IP ADDRESS <DSBM L2 address> ::= <RSVP_HOP_L2>
object uses <Class=42, C-Type=1> and IPv6 DSBM IP ADDRESS object
uses <Class=42, C-Type=2>.
IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1 A SBM may omit this object by including a NULL L2 address object.
0 1 2 3 For C-Type=1 (IEEE Canonical address format), such a version of the
+---------------+---------------+---------------+---------------+ L2 address object contains value zero in the six octets corresponding
| IPv4 DSBM IP Address | to the MAC address (see section B.3.4 for the exact format).
+---------------+---------------+---------------+---------------+
IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 2 SBM_PRIORITY Object: class = 43, C-Type =1
SBM (Subnet Bandwidth Manager) January, 2000 0 1 2 3
+---------------+---------------+---------------+---------------+
| /// | /// | /// | SBM priority |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+ TIMER INTERVAL VALUES.
| |
+ +
| |
+ IPv6 DSBM IP Address +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
<DSBM L2 address> Object is the same as <RSVP_HOP_L2> object with The two timer intervals, namely, DSBM Dead Interval and DSBM Refresh
C-Type = 1 for IEEE Canonical Address format. Interval, are specified as integer values each in the range of 0..255
seconds. Both values are included in a single "DSBM Timer Intervals"
object described below.
<DSBM L2 address> ::= <RSVP_HOP_L2> DSBM Timer Intervals Object: class = 44, C-Type =1
a SBM may omit this object by including a NULL L2 address object. For +---------------+---------------+---------------+----------------+
C-Type=1 (IEEE Canonical address format), such a version of the L2 | /// | /// | DeadInterval | RefreshInterval|
address object contains value zero in the six octet s corresponding to the +---------------+---------------+---------------+----------------+
MAC address (see section B.3.4 for the exact format).
SBM_PRIORITY Object: class = 43, C-Type =1 NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 1
0 1 2 3 0 1 2 3
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+----------------+
| /// | /// | /// | SBM priority | | NonResvSendLimit(limit on traffic allowed to send without RESV)|
+---------------+---------------+---------------+---------------+ | |
+---------------+---------------+---------------+----------------+
TIMER INTERVAL VALUES. <NonResvSendLimit> ::= <Intserv Sender_TSPEC object>
(class=12, C-Type =2)
The two timer intervals, namely, DSBM Dead Interval and DSBM The NON_RESV_SEND_LIMIT object specifies a per-flow limit on the
Refresh Interval, are specified as integer values each in the profile of traffic which a sending host is allowed to send onto a
range of 0..255 seconds. Both values are included in a single managed segment without a valid RSVP reservation (see Appendix C for
"DSBM Timer Intervals" object described below. further details on the usage of this object). The object contains the
NonResvSendLimit parameter. This parameter is equivalent to the
Intserv SENDER_TSPEC (see RFC 2210 for contents and encoding rules).
The SENDER_TSPEC includes five parameters which describe a traffic
profile (r, b, p, m and M). Sending hosts compare the SENDER_TSPEC
describing a sender traffic flow to the SENDER_TSPEC advertised by
the DSBM. If the SENDER_TSPEC of the traffic flow in question is less
than or equal to the SENDER_TSPEC advertised by the DSBM, it is
allowable to send traffic on the corresponding flow without a valid
RSVP reservation in place. Otherwise it is not.
DSBM Timer Intervals Object: class = 44, C-Type =1 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. Similarly the network administrator may allow any traffic to be
sent in the absence of an RSVP reservation by configuring a
NonResvSendLimit in which r = infinity, b = infinity, p = infinity, m
= 0 and M = infinity. Of course, any of these parameters may be set
to values between zero and infinity to advertise finite per-flow
limits.
+---------------+---------------+---------------+----------------+ The NON_RESV_SEND_LIMIT object is optional. Senders on a managed
| /// | /// | DeadInterval | RefreshInterval| 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).
NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 1 Appendix C The DSBM as a Source of Centralized Configuration Information
0 1 2 3 There are certain configuration parameters which it may be useful to
+---------------+---------------+---------------+----------------+ distribute to layer-3 senders on a managed segment. The DSBM may
| NonResvSendLimit(limit on traffic allowed to send without RESV)| serve as a centralized management point from which such parameters
| | can easily be distributed. In particular, it is possible for the
+---------------+---------------+---------------+----------------+ network administrator configuring a DSBM to cause certain
configuration parameters to be distributed as objects appended to the
I_AM_DSBM messages. The following configuration object is defined at
this time. Others may be defined in the future. See Appendix B for
further details regarding the NON_RESV_SEND_LIMIT object.
SBM (Subnet Bandwidth Manager) January, 2000 C.1. NON_RESV_SEND_LIMIT
<NonResvSendLimit> ::= <Intserv Sender_TSPEC object> (class=12, C-Type =2) As we QoS enable layer 2 segments, we expect an evolution from
subnets comprised of traditional shared segments (with no means of
traffic separation and no DSBM), to subnets comprised of dedicated
segments switched by sophisticated switches (with both DSBM and
802.1p traffic separation capability).
The NON_RESV_SEND_LIMIT object specifies a per-flow limit on the A set of intermediate configurations consists of a group of QoS
profile of traffic which a sending host is allowed to send onto a enabled hosts sending onto a traditional shared segment. A layer-3
managed segment without a valid RSVP reservation (see Appendix C device (or a layer-2 device) acts as a DSBM for the shared segment,
for further details on the usage of this object). The object contains but cannot enforce traffic separation. In such a configuration, the
the NonResvSendLimit parameter. This parameter is equivalent DSBM can be configured to limit the number of reservations approved
to the Intserv SENDER_TSPEC (see RFC 2210 for contents and encoding for senders on the segment, but cannot prevent them from sending. As
rules). The SENDER_TSPEC includes five parameters which describe a a result, senders may congest the segment even though a network
traffic profile (r, b, p, m and M). Sending hosts compare the administrator has configured an appropriate limit for admission
SENDER_TSPEC describing a sender traffic flow to the SENDER_TSPEC control in the DSBM.
advertised by the DSBM. If the SENDER_TSPEC of the traffic flow in
question is less than or equal to the SENDER_TSPEC advertised by
the DSBM, it is allowable to send traffic on the corresponding flow
without a valid RSVP reservation in place. Otherwise it is not.
The network administrator may configure the DSBM to disallow any One solution to this problem which would give the network
sent traffic in the absence of an RSVP reservation by configuring a administrator control over the segment, is to require applications
NonResvSendLimit in which r = 0, b = 0, p = 0, m = infinity and M = (or operating systems on behalf of applications) not to send until
0. Similarly the network administrator may allow any traffic to be they have obtained a reservation. This is problematic as most
sent in the absence of an RSVP reservation by configuring a applications are used to sending as soon as they wish to and expect
NonResvSendLimit in which r = infinity, b = infinity, p = infinity, m to get whatever service quality the network is able to grant at that
= 0 and M = infinity. Of course, any of these parameters may be set time. Furthermore, it may often be acceptable to allow certain
to values between zero and infinity to advertise finite per-flow applications to send before a reservation is received. For example,
limits. on a segment comprised of a single 10 Mbps ethernet and 10 hosts, it
may be acceptable to allow a 16 Kbps telephony stream to be
transmitted but not a 3 Mbps video stream.
The NON_RESV_SEND_LIMIT object is optional. Senders on a managed A more pragmatic solution then, is to allow the network administrator
segment should interpret the absence of the NON_RESV_SEND_LIMIT to set a per-flow limit on the amount of non-adaptive traffic which a
object as equivalent to an infinitely large SENDER_TSPEC (it is sender is allowed to generate on a managed segment in the absence of
permissible to send any traffic profile in the absence of an RSVP a valid reservation. This limit is advertised by the DSBM and
reservation). 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.
SBM (Subnet Bandwidth Manager) January, 2000 The NON_RESV_SEND_LIMIT object can be used to advertise a Flowspec
which describes the shape of traffic that a sender is allowed to
generate on a managed segment when its RSVP reservation requests have
either not yet completed or have been rejected.
Appendix C ACKNOWLEDGEMENTS
The DSBM as a Source of Centralized Configuration Information
There are certain configuration parameters which it may be useful Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel),
to distribute to layer-3 senders on a managed segment. The DSBM may David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman
serve as a centralized management point from which such parameters (3COM), Andrew Smith (Extreme Networks) for their constructive
can easily be distributed. In particular, it is possible for the comments on the SBM design and the earlier versions of this document.
network administrator configuring a DSBM to cause certain
configuration parameters to be distributed as objects appended to the
I_AM_DSBM messages. The following configuration object is defined
at this time. Others may be defined in the future. See Appendix B
for further details regarding the NON_RESV_SEND_LIMIT object.
C.1. NON_RESV_SEND_LIMIT 6. Authors' Addresses
As we QoS enable layer 2 segments, we expect an evolution from subnets Raj Yavatkar
comprised of traditional shared segments (with no means of Intel Corporation
traffic separation and no DSBM), to subnets comprised of dedicated 2111 N.E. 25th Avenue,
segments switched by sophisticated switches (with both DSBM and Hillsboro, OR 97124
802.1p traffic separation capability). USA
A set of intermediate configurations consists of a group of QoS Phone: +1 503-264-9077
enabled hosts sending onto a traditional shared segment. A layer-3 EMail: yavatkar@ibeam.intel.com
device (or a layer-2 device) acts as a DSBM for the shared segment,
but cannot enforce traffic separation. In such a configuration, the
DSBM can be configured to limit the number of reservations approved
for senders on the segment, but cannot prevent them from sending.
As a result, senders may congest the segment even though a network
administrator has configured an appropriate limit for admission
control in the DSBM.
One solution to this problem which would give the network administrator Don Hoffman
control over the segment, is to require applications (or Teledesic Corporation
operating systems on behalf of applications) not to send until they 2300 Carillon Point
have obtained a reservation. This is problematic as most applications Kirkland, WA 98033
are used to sending as soon as they wish to and expect to get USA
whatever service quality the network is able to grant at that time.
Furthermore, it may often be acceptable to allow certain applications
to send before a reservation is received. For example, on a
segment comprised of a single 10 Mbps ethernet and 10 hosts, it may
be acceptable to allow a 16 Kbps telephony stream to be transmitted
but not a 3 Mbps video stream.
A more pragmatic solution then, is to allow the network administrator Phone: +1 425-602-0000
to set a per-flow limit on the amount of non-adaptive traffic
which a sender is allowed to generate on a managed segment in the
absence of a valid reservation. This limit is advertised by the
DSBM and received by sending hosts. An API on the sending host can
SBM (Subnet Bandwidth Manager) January, 2000 Yoram Bernet
Microsoft
1 Microsoft Way
Redmond, WA 98052
USA
then approve or deny an application's QoS request based on the Phone: +1 206 936 9568
resources requested. EMail: yoramb@microsoft.com
Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
USA
The NON_RESV_SEND_LIMIT object can be used to advertise a Flowspec Phone: +1 408 526 4257
which describes the shape of traffic that a sender is allowed to EMail: fred@cisco.com
generate on a managed segment when its RSVP reservation requests
have either not yet completed or have been rejected.
SBM (Subnet Bandwidth Manager) January, 2000 Michael Speer
Sun Microsystems, Inc
901 San Antonio Road UMPK15-215
Palo Alto, CA 94303
ACKNOWLEDGEMENTS Phone: +1 650-786-6368
EMail: speer@Eng.Sun.COM
Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel), Full Copyright Statement
David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman
(3COM), Andrew Smith (Extreme Networks) for their constructive
comments on the SBM design and the earlier versions of this document.
6. Authors` Addresses Copyright (C) The Internet Society (2000). All Rights Reserved.
Raj Yavatkar This document and translations of it may be copied and furnished to
Intel Corporation others, and derivative works that comment on or otherwise explain it
2111 N.E. 25th Avenue, or assist in its implementation may be prepared, copied, published
Hillsboro, OR 97124 and distributed, in whole or in part, without restriction of any
USA kind, provided that the above copyright notice and this paragraph are
phone: +1 503-264-9077 included on all such copies and derivative works. However, this
email: yavatkar@ibeam.intel.com document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Don Hoffman The limited permissions granted above are perpetual and will not be
Teledesic Corporation revoked by the Internet Society or its successors or assigns.
2300 Carillon Point
Kirkland, WA 98033
USA
phone: +1 425-602-0000
Yoram Bernet This document and the information contained herein is provided on an
Microsoft "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1 Microsoft Way TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
Redmond, WA 98052 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
USA HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
phone: +1 206 936 9568 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
email: yoramb@microsoft.com
Fred Baker Acknowledgement
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
USA
phone: +1 408 526 4257
email: fred@cisco.com
Michael Speer Funding for the RFC Editor function is currently provided by the
Sun Microsystems, Inc Internet Society.
901 San Antonio Road UMPK15-215
Palo Alto, CA 94303
phone: +1 650-786-6368
email: speer@Eng.Sun.COM
 End of changes. 472 change blocks. 
2242 lines changed or deleted 2084 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/