draft-ietf-issll-is802-sbm-06.txt   draft-ietf-issll-is802-sbm-07.txt 
Internet Engineering Task Force Raj Yavatkar, Intel Internet Engineering Task Force Raj Yavatkar, Intel
INTERNET-DRAFT Don Hoffman, Teledesic INTERNET-DRAFT Don Hoffman, Teledesic
<draft-ietf-issll-is802-sbm-06.txt> Yoram Bernet, Microsoft Yoram Bernet, Microsoft
Fred Baker, Cisco Fred Baker, Cisco
Michael Speer, Sun Microsystems Michael Speer, Sun Microsystems
November 1998
SBM (Subnet Bandwidth Manager): SBM (Subnet Bandwidth Manager):
A Protocol for RSVP-based Admission Control over IEEE 802-style networks A Protocol for RSVP-based Admission Control over IEEE 802-style networks
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
(Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West
Coast). Coast).
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
Abstract Abstract
This document describes a signaling method and protocol for RSVP-based This document describes a signaling method and protocol for RSVP-based
admission control over IEEE 802-style LANs. The protocol is designed 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 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. recent work completed by the IEEE 802.1 committee.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
1. Introduction 1. Introduction
New extensions to the Internet architecture and service models have New extensions to the Internet architecture and service models have
been defined for an integrated services Inernet [RFC-1633, RFC-2205, been defined for an integrated services Inernet [RFC-1633, RFC-2205,
RFC-2210] so that applications can request specific qualities or lev- RFC-2210] so that applications can request specific qualities or lev-
els of service from an internetwork in addition to the current IP els of service from an internetwork in addition to the current IP
best-effort service. These extensions include RSVP, a resource reser- best-effort service. These extensions include RSVP, a resource reser-
vation setup protocol, and definition of new service classes to be vation setup protocol, and definition of new service classes to be
supported by Integrated Services routers. RSVP and service class supported by Integrated Services routers. RSVP and service class
skipping to change at page 3, line 31 skipping to change at page 3, line 31
shared and switched IEEE-802-style LAN technologies. shared and switched IEEE-802-style LAN technologies.
This document defines SBM, a signaling protocol for RSVP-based admis- This document defines SBM, a signaling protocol for RSVP-based admis-
sion control over IEEE 802-style networks. SBM provides a method for sion control over IEEE 802-style networks. SBM provides a method for
mapping an internet-level setup protocol such as RSVP onto IEEE 802- mapping an internet-level setup protocol such as RSVP onto IEEE 802-
style networks. In particular, it describes the operation of RSVP- style networks. In particular, it describes the operation of RSVP-
enabled hosts/routers and link layer devices (switches, bridges) to enabled hosts/routers and link layer devices (switches, bridges) to
support reservation of LAN resources for RSVP-enabled data flows. A support reservation of LAN resources for RSVP-enabled data flows. A
framework for providing Integrated Services over shared and switched framework for providing Integrated Services over shared and switched
IEEE-802-style LAN technologies and a definition of service mappings IEEE-802-style LAN technologies and a definition of service mappings
have been described in separate documents [Ghanwani98, Seaman97]. have been described in separate documents [Ghanwani98, Seaman98].
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 based
on the following architectural goals and assumptions: on the following architectural goals and assumptions:
I. Even though the current trend is towards increased use of I. Even though the current trend is towards increased use of
switched LAN topologies consisting of newer switches that support switched LAN topologies consisting of newer switches that support
the priority queuing mechanisms specified by IEEE 802.1p, we the priority queuing mechanisms specified by IEEE 802.1p, we
assume that the LAN technologies will continue to be a mix of assume that the LAN technologies will continue to be a mix of
legacy shared/ switched LAN segments and newer switched segments legacy shared/ switched LAN segments and newer switched segments
based on IEEE 802.1p specification. Therefore, we specify a sig- based on IEEE 802.1p specification. Therefore, we specify a sig-
naling protocol for managing bandwidth over both legacy and newer naling protocol for managing bandwidth over both legacy and newer
LAN topologies and that takes advantage of the additional func- LAN topologies and that takes advantage of the additional func-
tionality (such as an explicit support for different traffic tionality (such as an explicit support for different traffic
classes or integrated service classes) as it becomes available in classes or integrated service classes) as it becomes available in
the new generation of switches, hubs, or bridges. As a result, the new generation of switches, hubs, or bridges. As a result,
the SBM protocol would allow for a range of LAN bandwidth the SBM protocol would allow for a range of LAN bandwidth
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
management solutions that vary from one that exercises purely management solutions that vary from one that exercises purely
administrative control (over the amount of bandwidth consumed by administrative control (over the amount of bandwidth consumed by
RSVP-enabled traffic flows) to one that requires cooperation (and RSVP-enabled traffic flows) to one that requires cooperation (and
enforcement) from all the end-systems or switches in a IEEE 802 enforcement) from all the end-systems or switches in a IEEE 802
LAN. LAN.
II. This document specifies only a signaling method and protocol for II. This document specifies only a signaling method and protocol for
LAN-based admission control over RSVP flows. We do not define LAN-based admission control over RSVP flows. We do not define
here any traffic control mechanisms for the link layer; the pro- here any traffic control mechanisms for the link layer; the pro-
skipping to change at page 5, line 5 skipping to change at page 5, line 5
by the TCP/IP-based traffic sources is generally rate-adaptive by the TCP/IP-based traffic sources is generally rate-adaptive
(using a TCP-style "slow start" congestion avoidance mechanism or (using a TCP-style "slow start" congestion avoidance mechanism or
a feedback-based rate adaptation mechanism used by audio/video a feedback-based rate adaptation mechanism used by audio/video
streams based on RTP/RTCP protocols) and adapts to stay within streams based on RTP/RTCP protocols) and adapts to stay within
the available network bandwidth. Thus, the combination of admis- the available network bandwidth. Thus, the combination of admis-
sion control and rate adaptation should avoid persistent traffic sion control and rate adaptation should avoid persistent traffic
congestion. This does not, however, guarantee that non- congestion. This does not, however, guarantee that non-
Integrated-Services traffic will not interfere with the Integrated-Services traffic will not interfere with the
Integrated Services traffic in the absence of traffic control Integrated Services traffic in the absence of traffic control
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
support in the underlying LAN infrastructure. 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 SBM- The rest of this document provides a detailed description of the SBM-
based admission control procedure(s) for IEEE 802 LAN technologies. based admission control procedure(s) for IEEE 802 LAN technologies.
The document is organized as follows: The document is organized as follows:
* Section 4 first defines the various terms used in the document * Section 4 first defines the various terms used in the document
skipping to change at page 6, line 5 skipping to change at page 6, line 5
4. Overview 4. Overview
4.1. Definitions 4.1. Definitions
- Link Layer or Layer 2 or L2: We refer to data-link layer techno- - Link Layer or Layer 2 or L2: We refer to data-link layer techno-
logies such as IEEE 802.3/Ethernet as L2 or layer 2. logies such as IEEE 802.3/Ethernet as L2 or layer 2.
- Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes - Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
and links interconnected without passing through a L3 forwarding and links interconnected without passing through a L3 forwarding
function. One or more IP subnets can be overlaid on a L2 domain. function. One or more IP subnets can be overlaid on a L2 domain.
- Layer 2 or L2 devices: We refer to devices that only implement - Layer 2 or L2 devices: We refer to devices that only implement
Layer 2 functionality as Layer 2 or L2 devices. These include Layer 2 functionality as Layer 2 or L2 devices. These include
802.1D bridges or switches. 802.1D bridges or switches.
- Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO 7 layer - Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO 7 layer
model. This document is primarily concerned with networks that model. This document is primarily concerned with networks that
skipping to change at page 7, line 5 skipping to change at page 7, line 5
transmission and reception of all frames in the IEEE 802 service transmission and reception of all frames in the IEEE 802 service
model: it is supplied by the sender that is using the MAC ser- model: it is supplied by the sender that is using the MAC ser-
vice. It is provided along with the data to a receiver using the vice. It is provided along with the data to a receiver using the
MAC service. It may or may not be actually carried over the net- MAC service. It may or may not be actually carried over the net-
work: Token-Ring/802.5 carries this value (encoded in its FC work: Token-Ring/802.5 carries this value (encoded in its FC
octet), basic Ethernet/802.3 does not, 802.12 may or may not 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 depending on the frame format in use. 802.1p defines a consistent
way to carry this value over the bridged network on Ethernet, way to carry this value over the bridged network on Ethernet,
Token Ring, Demand-Priority, FDDI or other MAC-layer media using Token Ring, Demand-Priority, FDDI or other MAC-layer media using
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
an extended frame format. The usage of user_priority is fully an extended frame format. The usage of user_priority is fully
described in section 2.5 of 802.1D [IEEE8021D] and 802.1p described in section 2.5 of 802.1D [IEEE8021D] and 802.1p
[IEEE8021P] "Support of the Internal Layer Service by Specific [IEEE8021P] "Support of the Internal Layer Service by Specific
MAC Procedures". MAC Procedures".
- Subnet: used in this memo to indicate a group of L3 devices shar- - Subnet: used in this memo to indicate a group of L3 devices shar-
ing a common L3 network address prefix along with the set of seg- ing a common L3 network address prefix along with the set of seg-
ments making up the L2 domain in which they are located. ments making up the L2 domain in which they are located.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
domain with no DSBMs present for exercising admission control domain with no DSBMs present for exercising admission control
over resources at segments in the L2 domain. over resources at segments in the L2 domain.
- DSBM clients: These are entities that transmit traffic onto a - DSBM clients: These are entities that transmit traffic onto a
managed segment and use the services of a DSBM for the managed managed segment and use the services of a DSBM for the managed
segment for admission control over a LAN segment. Only the layer segment for admission control over a LAN segment. Only the layer
3 or higher layer entities on L3 devices such as hosts and 3 or higher layer entities on L3 devices such as hosts and
routers are expected to send traffic that requires resource routers are expected to send traffic that requires resource
reservations, and, therefore, DSBM clients are L3 entities. reservations, and, therefore, DSBM clients are L3 entities.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
- 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 con- therefore, does not participate in the SBM-based admission con-
trol procedure over a managed segment. Such a device uses stan- trol procedure over a managed segment. Such a device uses stan-
dard forwarding rules appropriate for the device and is tran- dard forwarding rules appropriate for the device and is tran-
sparent with respect to SBM. An example of such a L2 device is a sparent with respect to SBM. An example of such a L2 device is a
legacy switch that does not participate in resource reservation. legacy 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
skipping to change at page 9, line 5 skipping to change at page 9, line 5
described in Appendix A. The only other approved method for specifying described in Appendix A. The only other approved method for specifying
a DSBM for a managed segment is static configuration at SBM-capable a DSBM for a managed segment is static configuration at SBM-capable
devices. devices.
The presence of a DSBM makes the segment a "managed segment". Some- The presence of a DSBM makes the segment a "managed segment". Some-
times, two or more L2 segments may be interconnected by SBM tran- times, two or more L2 segments may be interconnected by SBM tran-
sparent devices. In that case, a single DSBM will manage the resources sparent devices. In that case, a single DSBM will manage the resources
for those segments treating the collection of such segments as a sin- for those segments treating the collection of such segments as a sin-
gle managed segment for the purpose of admission control. gle managed segment for the purpose of admission control.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
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 |
+-------+ +-----+ / +-----+ +--------+ +-------+ +-----+ / +-----+ +--------+
| | / | | | | / | |
skipping to change at page 10, line 5 skipping to change at page 10, line 5
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 2. DSBM Client Initialization: For each interface attached, a DSBM
client determines whether a DSBM exists on the interface. The client determines whether a DSBM exists on the interface. The
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
procedure for discovering and verifying the existence of the DSBM procedure for discovering and verifying the existence of the DSBM
for an attached segment is described in Appendix A. If the client 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 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 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 start, a DSBM client first verifies that a DSBM exists in its L2
domain so that it can communicate with the DSBM for admission domain so that it can communicate with the DSBM for admission
control purposes. control purposes.
In the case of a full-duplex segment, an election may not be In the case of a full-duplex segment, an election may not be
skipping to change at page 11, line 5 skipping to change at page 11, line 5
tion 5). In the process, the DSBM builds the PATH state, tion 5). In the process, the DSBM builds the PATH state,
remembers the router R1 (its L2 and l3 addresses) as the previ- remembers the router R1 (its L2 and l3 addresses) as the previ-
ous hop for the session, puts its own L2 and L3 addresses in ous hop for the session, puts its own L2 and L3 addresses in
the PHOP objects (see explanation later), and effectively the PHOP objects (see explanation later), and effectively
inserts itself as an intermediate node between the sender (or inserts itself as an intermediate node between the sender (or
R1 in Figure 1) and the receiver (host A) on the managed seg- R1 in Figure 1) and the receiver (host A) on the managed seg-
ment. ment.
b) When an application on host A wishes to make a reservation for b) When an application on host A wishes to make a reservation for
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
the RSVP session, host A follows the standard RSVP message pro- the RSVP session, host A follows the standard RSVP message pro-
cessing rules and sends a RSVP RESV message to the previous hop cessing rules and sends a RSVP RESV message to the previous hop
L2/L3 address (the DSBMs address) obtained from the PHOP L2/L3 address (the DSBMs address) obtained from the PHOP
object(s) in the previously received PATH message. 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 RESVERR message to the requester (host available and returns an RESVERR message to the requester (host
A) if the request cannot be granted. If sufficient resources A) if the request cannot be granted. If sufficient resources
are available and the reservation request is granted, the DSBM are available and the reservation request is granted, the DSBM
forwards the RESV message towards the PHOP(s) based on its forwards the RESV message towards the PHOP(s) based on its
local PATH state for the session. The DSBM merges reservation local PATH state for the session. The DSBM merges reservation
requests for the same session as and when possible using the requests for the same session as and when possible using the
rules similar to those used in the conventional RSVP process- rules similar to those used in the conventional RSVP processing
ing. (except for an additional criterion described in Section 5.9).
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 pro- PATH state at each DSBM. Therefore, the RESV message would pro-
pagate hop-by-hop in reverse through the intermediate DSBMs and pagate hop-by-hop in reverse through the intermediate DSBMs and
eventually reach the original forwarder (router R1) on the L2 eventually reach the original forwarder (router R1) on the L2
domain if admission control at all DSBMs succeeds. domain if admission control at all DSBMs succeeds.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
- Normal RSVP forwarding rules apply at a DSBM client when it is - Normal RSVP forwarding rules apply at a DSBM client when it is
not forwarding an outgoing PATH message over a managed segment. not forwarding an outgoing PATH message over a managed segment.
However, outgoing PATH messages on a managed segment are sent to However, outgoing PATH messages on a managed segment are sent to
the DSBM for the corresponding managed segment (Section 5.2 the DSBM for the corresponding managed segment (Section 5.2
describes how the PATH messages are sent to the DSBM on a managed describes how the PATH messages are sent to the DSBM on a managed
segment). segment).
- In conventional RSVP processing over point-to-point links, RSVP - In conventional RSVP processing over point-to-point links, RSVP
nodes (hosts/routers) use RSVP_HOP object (NHOP and PHOP info) to nodes (hosts/routers) use RSVP_HOP object (NHOP and PHOP info) to
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
keep track of the next hop (downstream node in the path of data keep track of the next hop (downstream node in the path of data
packets in a traffic flow) and the previous hop (upstream nodes packets in a traffic flow) and the previous hop (upstream nodes
with respect to the data flow) nodes on the path between a sender with respect to the data flow) nodes on the path between a sender
and a receiver. Routers along the path of a PATH message forward and a receiver. Routers along the path of a PATH message forward
the message towards the destination address based on the L3 rout- the message towards the destination address based on the L3 rout-
ing (packet forwarding) tables. ing (packet forwarding) tables.
For example, consider the L2 domain in Figure 1. Assume that both 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 the sender (some host X) and the receiver (some host Y) in a RSVP
skipping to change at page 13, line 5 skipping to change at page 13, line 5
our example of an RSVP session involving the sender X and our example of an RSVP session involving the sender X and
receiver Y with L2 domain in Figure 1 acting as the transit sub- receiver Y with L2 domain in Figure 1 acting as the transit sub-
net, R1 is the ingress node that receives the PATH message. R1 net, R1 is the ingress node that receives the PATH message. R1
first determines that R2 is the next hop router (or the egress first determines that R2 is the next hop router (or the egress
node in the L2 domain for the session address) and then inserts a node in the L2 domain for the session address) and then inserts a
LAN_NHOP object that specifies R2's IP address. When a DSBM LAN_NHOP object that specifies R2's IP address. When a DSBM
receives a PATH message, it can now look at the address in the receives a PATH message, it can now look at the address in the
LAN_NHOP object and forward the PATH message towards the egress LAN_NHOP object and forward the PATH message towards the egress
node after processing the PATH message. However, we expect the node after processing the PATH message. However, we expect the
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
L2 devices (such as switches) to act as DSBMs on the path within L2 devices (such as switches) to act as DSBMs on the path within
the L2 domain and it may not be reasonable to expect these dev- the L2 domain and it may not be reasonable to expect these dev-
ices to have an ARP capability to determine the MAC address (we ices to have an ARP capability to determine the MAC address (we
call it L2ADDR for Layer 2 address) corresponding to the IP call it L2ADDR for Layer 2 address) corresponding to the IP
address in the LAN_NHOP object. address in the LAN_NHOP object.
Therefore, we require that the LAN_NHOP information (generated by Therefore, we require that the LAN_NHOP information (generated by
the L3 device) include both the IP address (LAN_NHOP_L3 address) the L3 device) include both the IP address (LAN_NHOP_L3 address)
and the corresponding MAC address (LAN_NHOP_L2 address ) for the and the corresponding MAC address (LAN_NHOP_L2 address ) for the
skipping to change at page 14, line 5 skipping to change at page 14, line 5
through the DSBM. In particular, a PATH_TEAR message is routed through the DSBM. In particular, a PATH_TEAR message is routed
exactly through the intermediate DSBM(s) as its corresponding exactly through the intermediate DSBM(s) as its corresponding
PATH message and the local PATH state is first cleaned up at each PATH message and the local PATH state is first cleaned up at each
intermediate hop before the PATH_TEAR message gets forwarded. intermediate hop before the PATH_TEAR message gets forwarded.
- So far, we have described how the PATH message propagates through - So far, we have described how the PATH message propagates through
the L2 domain establishing PATH state at each DSBM along the the L2 domain establishing PATH state at each DSBM along the
managed segments in the path. The layer 2 address (LAN_NHOP_L2 managed segments in the path. The layer 2 address (LAN_NHOP_L2
address) in the LAN_NHOP object should be used by the L2 devices address) in the LAN_NHOP object should be used by the L2 devices
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
along the path to decide how to forward the PATH message toward along the path to decide how to forward the PATH message toward
the next L3 hop. Such devices will apply the standard IEEE 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 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 its filtering database, or flood it on all ports active in the
spanning tree if the L2 address does not appear in the filtering spanning tree if the L2 address does not appear in the filtering
database) to the LAN_NHOP_L2 address as are applied normally to database) to the LAN_NHOP_L2 address as are applied normally to
data packets destined to the address. data packets destined to the address.
In the conventional RSVP message processing, the PATH state esta- In the conventional RSVP message processing, the PATH state esta-
skipping to change at page 15, line 5 skipping to change at page 15, line 5
a RSVP_HOP_L2 object that includes the corresponding L2 address a RSVP_HOP_L2 object that includes the corresponding L2 address
for the interface. When a device in the L2 domain receives such a for the interface. When a device in the L2 domain receives such a
PATH message, it remembers the addresses in the RSVP_HOP and PATH message, it remembers the addresses in the RSVP_HOP and
RSVP_HOP_L2 objects in its PATH state and then overwrites the RSVP_HOP_L2 objects in its PATH state and then overwrites the
RSVP_HOP and RSVP_HOP_L2 objects with its own addresses before RSVP_HOP and RSVP_HOP_L2 objects with its own addresses before
forwarding the PATH message over a managed segment. forwarding the PATH message over a managed segment.
The exact format of RSVP_HOP_L2 object is specified in APPENDIX The exact format of RSVP_HOP_L2 object is specified in APPENDIX
B. B.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
- When an RSVP session address is a multicast address and a SBM, - When an RSVP session address is a multicast address and a SBM,
DSBM, and DSBM clients share the same L2 segment (a shared seg- DSBM, and DSBM clients share the same L2 segment (a shared seg-
ment), it is possible for a SBM or a DSBM client to receive one ment), it is possible for a SBM or a DSBM client to receive one
or more copies of a PATH message that it forwarded earlier when a or more copies of a PATH message that it forwarded earlier when a
DSBM on the same wire forwards it (See Section 5.8 for an example DSBM on the same wire forwards it (See Section 5.8 for an example
of such a case). To facilitate detection of such loops, we use a of such a case). To facilitate detection of such loops, we use a
new RSVP object called the LAN_LOOPBACK object. DSBM clients or new RSVP object called the LAN_LOOPBACK object. DSBM clients or
SBMs (but not the DSBMs reflecting a PATH message onto the inter- SBMs (but not the DSBMs reflecting a PATH message onto the inter-
face over which it arrived earlier) must overwrite (or add if the face over which it arrived earlier) must overwrite (or add if the
skipping to change at page 15, line 45 skipping to change at page 15, line 45
values encoded in packets representing different traffic classes values encoded in packets representing different traffic classes
(see [IEEE802Q, IEEE8021p] for further details). The (see [IEEE802Q, IEEE8021p] for further details). The
user_priority values can be encoded either in native LAN packets user_priority values can be encoded either in native LAN packets
(e.g., in IEEE 802.5's FC octet) or by using an encapsulation (e.g., in IEEE 802.5's FC octet) or by using an encapsulation
above the MAC layer (e.g., in the case of Ethernet, the above the MAC layer (e.g., in the case of Ethernet, the
user_priority value assigned to each packet will be carried in user_priority value assigned to each packet will be carried in
the frame header using the new, extended frame format defined by the frame header using the new, extended frame format defined by
IEEE 802.1Q [IEEE8021Q]. IEEE, however, makes no recommendations IEEE 802.1Q [IEEE8021Q]. IEEE, however, makes no recommendations
about how a sender or network should use the user_priority about how a sender or network should use the user_priority
values. An accompanying document makes recommendations on the values. An accompanying document makes recommendations on the
usage of the user_priority values (see [Seaman97] for details). usage of the user_priority values (see [Seaman98] 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 transmit traffic flows onto a L2 segment should perform per-flow
policing to ensure that the flows do not exceed their traffic policing to ensure that the flows do not exceed their traffic
specification as specified during admission control. In addition, specification as specified during admission control. In addition,
L3 devices may label the frames in such flows with a L3 devices may label the frames in such flows with a
user_priority value to identify their service class. user_priority value to identify their service class.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
For the purpose of this discussion, we will refer to the For the purpose of this discussion, we will refer to the
user_priority value carried in the extended frame header as a user_priority value carried in the extended frame header as a
"traffic class" of a packet. Under the ISSLL model, the L3 enti- "traffic class" of a packet. Under the ISSLL model, the L3 enti-
ties, that send traffic and that use the SBM protocol, may not ties, that send traffic and that use the SBM protocol, may not
select the traffic class of outgoing packets. Instead, once a select the traffic class of outgoing packets. Instead, once a
sender sends a PATH message, downstream DSBMs will insert a new sender sends a PATH message, downstream DSBMs will insert a new
traffic class object (TCLASS object) in the PATH message that traffic class object (TCLASS object) in the PATH message that
travels to the next L3 device (L3 NHOP for the PATH message). To travels to the next L3 device (L3 NHOP for the PATH message). To
some extent, the TCLASS object contents are treated like the some extent, the TCLASS object contents are treated like the
skipping to change at page 16, line 42 skipping to change at page 16, line 42
In summary, use of TCLASS objects requires following additions to In summary, use of TCLASS objects requires following additions to
the conventional RSVP message processing at DSBMs, SBMs, and DSBM the conventional RSVP message processing at DSBMs, SBMs, and DSBM
clients: clients:
* When a DSBM receives a PATH message over a managed segment and * When a DSBM receives a PATH message over a managed segment and
the PATH message does not include a TCLASS object, the DSBM the PATH message does not include a TCLASS object, the DSBM
adds a TCLASS object to the PATH message before forwarding it. adds a TCLASS object to the PATH message before forwarding it.
The DSBM comes up with the appropriate user_priority value for The DSBM comes up with the appropriate user_priority value for
the TCLASS object according to some internal mapping of the the TCLASS object according to some internal mapping of the
service classes. One possible set of internal mappings is pro- service classes. One possible set of internal mappings is pro-
posed as an example in an accompanying document [Seaman97]. posed as an example in an accompanying document [Seaman98].
* When SBM or DSBM receives a PATH or RESV message with a TCLASS * When SBM or DSBM receives a PATH message with a TCLASS object
object over a managed segment in a L2 domain and needs to for- over a managed segment in a L2 domain and needs to forward it
ward it over a managed segment in the same L2 domain, it will over a managed segment in the same L2 domain, it will typically
typically forward the message without changing the contents of forward the message without changing the contents of the TCLASS
the TCLASS object. However, if the DSBM/SBM cannot support the object. However, if the DSBM/SBM cannot support the service
service class represented by the user_priority value specified class represented by the user_priority value specified by the
by the TCLASS object in the PATH message, it may change the TCLASS object in the PATH message, it may change the priority
priority value in the TCLASS to a semantically "lower" service value in the TCLASS to a semantically "lower" service value to
value to reflect its capability. reflect its capability.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
[NOTE: An accompanying document defines the int-serv mappings [NOTE: An accompanying document defines the int-serv mappings
over IEEE 802 networks [Seaman97] provides a precise definition over IEEE 802 networks [Seaman98] provides a precise definition
of user_priority values and describes how the user_priority of user_priority values and describes how the user_priority
values are compared to determine "lower" of the two values or values are compared to determine "lower" of the two values or
the "lowest" among all the user_priority values.] the "lowest" among all the user_priority values.]
* When a DSBM receives a RESV message with a TCLASS object, it * When a DSBM receives a RESV message with a TCLASS object, it
may use the traffic class information (in addition to the usual may use the traffic class information (in addition to the usual
flowspec information in the RSVP message) for its own admission flowspec information in the RSVP message) for its own admission
control for the managed segment. control for the managed segment.
Note that this document does not specify the actual algorithm Note that this document does not specify the actual algorithm
skipping to change at page 18, line 5 skipping to change at page 18, line 5
ensure that the data packets in the admitted RSVP flow that are ensure that the data packets in the admitted RSVP flow that are
subsequently forwarded over the outgoing interface will contain subsequently forwarded over the outgoing interface will contain
the appropriate value encoded in their frame header. 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 segment in one L2 domain and it needs to forward the managed segment in one L2 domain and it needs to forward the
PATH/RESV message over an interface outside that domain, the L3 PATH/RESV message over an interface outside that domain, the L3
device must remove the TCLASS object (along with LAN_NHOP, device must remove the TCLASS object (along with LAN_NHOP,
RSVP_HOP_L2, and LAN_LOOPBACK objects in the case of the PATH RSVP_HOP_L2, and LAN_LOOPBACK objects in the case of the PATH
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
message) before forwarding the PATH/RESV message. If the outgo- message) before forwarding the PATH/RESV message. If the outgo-
ing interface is on a separate L2 domain, these objects may be ing interface is on a separate L2 domain, these objects may be
regenerated according to the processing rules applicable to regenerated according 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
skipping to change at page 19, line 5 skipping to change at page 19, line 5
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 to L3 hop in the path. RSVP PATH messages are addressed, according to
RFC-2205, to their destination address (which can be either an IP uni- RFC-2205, to their destination address (which can be either an IP uni-
cast or multicast address). When a L2 device hosts a DSBM, a simple- cast or multicast address). When a L2 device hosts a DSBM, a simple-
to-implement mechanism must be provided for the device to capture an to-implement mechanism must be provided for the device to capture an
incoming PATH message and hand it over to the local DSBM agent without incoming PATH message and hand it over to the local DSBM agent without
requiring the L2 device to snoop for L3 RSVP messages. 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
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
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 exist- binding, it should be possible to easily detect and address the exist-
ing DSBM on a managed segment. ing 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 pur- address. We make use of reserved IP multicast address(es) for the pur-
pose of communication with a DSBM. In particular, we require that pose of communication with a DSBM. In particular, we require that
skipping to change at page 20, line 5 skipping to change at page 20, line 5
SBM transparent. 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 pack- these devices to explicitly snoop for SBM related control pack-
ets. ets.
* The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress) * The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress)
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
and 224.0.0.17 (AllSBMAddress). and 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
skipping to change at page 21, line 5 skipping to change at page 21, line 5
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 that
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
need not be interpreted by an L3 device and can be treated as an 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 Appen- opaque object. The format of the L2ADDR object is specified in Appen-
dix B. dix 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 mes- Thus, when a SBM protocol entity on a L3 device forwards a RSVP mes-
sage onto a L2 segment, it will only use RAW IP encapsulation. sage 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) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
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 |
| | . | | | | | | | | | | . | | | | | | | |
+------+ . +------+ +------+ +------+ +------+ +------+ . +------+ +------+ +------+ +------+
skipping to change at page 23, line 5 skipping to change at page 23, line 5
and a shared L2 segment. The sample network contains the following and a shared L2 segment. The sample network contains the following
devices: 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) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
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 dev- The following paragraphs describe the rules, which each of these dev-
ices should use to forward PATH messages (rules apply to PATH_TEAR ices 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. Excep- scenario, they do address most of the interesting scenarios. Excep-
skipping to change at page 24, line 5 skipping to change at page 24, line 5
* If the device is a layer 3 device, determine whether the inter- * If the device is a layer 3 device, determine whether the inter-
face is on a managed segment managed by a DSBM, based on the face is on a managed segment managed by a DSBM, based on the
presence or absence of I_AM_DSBM messages. If the interface is presence or absence of I_AM_DSBM messages. If the interface is
not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP, not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP,
LAN_LOOPBACK, and TCLASS objects (if present), and forward to LAN_LOOPBACK, and TCLASS objects (if present), and forward to
the unicast or multicast destination. the unicast or multicast destination.
(Note that the RSVP Class Numbers for these new objects are (Note that the RSVP Class Numbers for these new objects are
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
chosen so that if an RSVP message includes these objects, the chosen so that if an RSVP message includes these objects, the
nodes that are RSVP-aware, but do not participate in the SBM nodes that are RSVP-aware, but do not participate in the SBM
protocol, will ignore and silently discard such objects.) protocol, will ignore and silently discard such objects.)
* If the device is a layer 2 device or it is a layer 3 device * 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 *and* the interface is on a managed segment, proceed to rule
#3. #3.
3. Forward the PATH message onto the managed segment: 3. Forward the PATH message onto the managed segment:
skipping to change at page 24, line 47 skipping to change at page 24, line 47
- Copy the IP address of the forwarding interface (layer 2 dev- - Copy the IP address of the forwarding interface (layer 2 dev-
ices must also have IP addresses) into the standard RSVP HOP ices must also have IP addresses) into the standard RSVP HOP
object and the L2 address of the forwarding interface into object and the L2 address of the forwarding interface into
the RSVP_HOP_L2 object. the RSVP_HOP_L2 object.
- If the PATH message received does not contain the TCLASS - If the PATH message received does not contain the TCLASS
object, insert a TCLASS object. The user_priority value object, insert a TCLASS object. The user_priority value
inserted in the TCLASS object is based on service mappings inserted in the TCLASS object is based on service mappings
internal to the device that are configured according to the internal to the device that are configured according to the
guidelines listed in [Seaman97]. If the message already guidelines listed in [Seaman98]. If the message already
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
contains the TCLASS object, the user_priority value may be contains the TCLASS object, the user_priority value may be
changed based again on the service mappings internal to the changed based again on the service mappings internal to the
device. device.
* If the device is a layer 3 device and hosts a SBM for the seg- * If the device is a layer 3 device and hosts a SBM for the seg-
ment to which the forwarding interface is attached, it *is ment to which the forwarding interface is attached, it *is
required* to retrieve and store the PHOP info. required* to retrieve and store the PHOP info.
If the device is a layer 2 device and hosts a SBM for the seg- If the device is a layer 2 device and hosts a SBM for the seg-
skipping to change at page 26, line 5 skipping to change at page 26, line 5
* If the SBM protocol entity is the DSBM for the segment to which * If the SBM protocol entity is the DSBM for the segment to which
the forwarding interface is attached, it must send the PATH the forwarding interface is attached, it must send the PATH
message to the AllSBMAddress. message to the AllSBMAddress.
* If the SBM protocol entity is a SBM or a DSBM Client on the * If the SBM protocol entity is a SBM or a DSBM Client on the
segment to which the forwarding interface is attached, it must segment to which the forwarding interface is attached, it must
send the PATH message to the DSBMLogicalAddress. send the PATH message to the DSBMLogicalAddress.
5.6.1. Additional notes on forwarding a PATH message onto a 5.6.1. Additional notes on forwarding a PATH message onto a
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
managed segment managed segment
Rule #1 states that normal IEEE 802.1D forwarding rules should be Rule #1 states that normal IEEE 802.1D forwarding rules should be
used to determine the interfaces on which the PATH message should used to determine the interfaces on which the PATH message should
be forwarded. In the case of data packets, standard forwarding be forwarded. In the case of data packets, standard forwarding
rules at a L2 device dictate that the packet should not be for- rules at a L2 device dictate that the packet should not be for-
warded on the interface from which it was received. However, in warded on the interface from which it was received. However, in
the case of a DSBM that receives a PATH message over a managed the case of a DSBM that receives a PATH message over a managed
segment, the following exception applies: segment, the following exception applies:
skipping to change at page 27, line 5 skipping to change at page 27, line 5
LAN_LOOPBACK object addresses this issue. All SBM protocol enti- LAN_LOOPBACK object addresses this issue. All SBM protocol enti-
ties (except DSBMs reflecting a PATH message) overwrite the ties (except DSBMs reflecting a PATH message) overwrite the
LAN_LOOPBACK object in the PATH message with the IP address of LAN_LOOPBACK object in the PATH message with the IP address of
the outgoing interface. DSBMs which are reflecting a PATH mes- the outgoing interface. DSBMs which are reflecting a PATH mes-
sage, leave the LAN_LOOPBACK object unchanged. Thus, SBM proto- sage, leave the LAN_LOOPBACK object unchanged. Thus, SBM proto-
col entities will always be able to recognize a reflected multi- col entities will always be able to recognize a reflected multi-
cast message by the presence of their own address in the cast message by the presence of their own address in the
LAN_LOOPBACK object. These messages should be silently dis- LAN_LOOPBACK object. These messages should be silently dis-
carded. carded.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
5.7. Applying the Rules -- Unicast Session 5.7. Applying the Rules -- Unicast Session
Let's see how the rules are applied in the general network illus- Let's see how the rules are applied in the general network illus-
trated previously (see Figure 2). trated previously (see Figure 2).
Assume that H1 is sending a PATH for a unicast session for which 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: H5 is the receiver. The following PATH message is composed by H1:
RSVP Contents RSVP Contents
skipping to change at page 28, line 5 skipping to change at page 28, line 5
PHOP IP address of R1 (2.0.0.1) PHOP IP address of R1 (2.0.0.1)
(seed the return path for RESV messages) (seed the return path for RESV messages)
RSVP_HOP_L2 L2 address of R1 RSVP_HOP_L2 L2 address of R1
LAN_NHOP LAN_NHOP_L3 (2.0.0.2) and LAN_NHOP LAN_NHOP_L3 (2.0.0.2) and
LAN_NHOP_L2 address of R2 (L2ADDR) LAN_NHOP_L2 address of R2 (L2ADDR)
(this is the next layer 3 hop) (this is the next layer 3 hop)
LAN_LOOPBACK IP address of R1 (2.0.0.1) LAN_LOOPBACK IP address of R1 (2.0.0.1)
IP Header IP Header
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
Source address IP address of H1 Source address IP address of H1
Destn address DSBMLogical IP address (224.0.0.16) Destn address DSBMLogical IP address (224.0.0.16)
MAC Header MAC Header
Destn address DSBMLogical MAC address Destn address DSBMLogical MAC address
* R1 does a routing lookup on the RSVP session address, to * R1 does a routing lookup on the RSVP session address, to
determine the IP address of the next layer 3 hop, R2. determine the IP address of the next layer 3 hop, R2.
skipping to change at page 29, line 5 skipping to change at page 29, line 5
RSVP_HOP_L2 L2 address of S1 RSVP_HOP_L2 L2 address of S1
LAN_NHOP LAN_NHOP_L3 (IP) and LAN_NHOP_L2 LAN_NHOP LAN_NHOP_L3 (IP) and LAN_NHOP_L2
address of R2 address of R2
(layer 2 devices do not modify the LAN_NHOP) (layer 2 devices do not modify the LAN_NHOP)
LAN_LOOPBACK IP addr of S1 LAN_LOOPBACK IP addr of S1
IP Header IP Header
Source address IP address of H1 Source address IP address of H1
Destn address AllSBMIPaddr (224.0.0.17, since S1 is the Destn address AllSBMIPaddr (224.0.0.17, since S1 is the
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
DSBM for seg B). DSBM for seg B).
MAC Header MAC Header
Destn address All SBM MAC address (since S1 is the DSBM for Destn address All SBM MAC address (since S1 is the DSBM for
seg B). seg B).
* S1 looks at the LAN_NHOP address information to determine the * S1 looks at the LAN_NHOP address information to determine the
L2 address towards which it should forward the PATH message. L2 address towards which it should forward the PATH message.
skipping to change at page 30, line 5 skipping to change at page 30, line 5
LAN_LOOPBACK IP address of S3 LAN_LOOPBACK IP address of S3
IP Header IP Header
Source address IP address of H1 Source address IP address of H1
Destn address DSBMLogical IP addr (since S3 is Destn address DSBMLogical IP addr (since S3 is
not the DSBM for seg F) not the DSBM for seg F)
MAC Header MAC Header
Destn address DSBMLogical MAC address Destn address DSBMLogical MAC address
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
* S3 looks at the LAN_NHOP address information to determine the * S3 looks at the LAN_NHOP address information to determine the
L2 address towards which it should forward the PATH message. L2 address towards which it should forward the PATH message.
* From the bridge forwarding tables, it determines that the L2 * From the bridge forwarding tables, it determines that the L2
address is reachable via segment F. address is reachable via segment F.
* It has discovered that R2 is the DSBM for segment F. It * It has discovered that R2 is the DSBM for segment F. It
therefore sends the PATH message to the DSBMLogicalAddress. therefore sends the PATH message to the DSBMLogicalAddress.
skipping to change at page 31, line 5 skipping to change at page 31, line 5
MAC Header MAC Header
Destn address L2 addr corresponding to H5, the next Destn address L2 addr corresponding to H5, the next
layer 3 hop layer 3 hop
* R2 does a routing lookup on the RSVP session address, to * R2 does a routing lookup on the RSVP session address, to
determine the IP address of the next layer 3 hop, H5. determine the IP address of the next layer 3 hop, H5.
* It determines that H5 is accessible via a segment for which * It determines that H5 is accessible via a segment for which
there is no DSBM (not a managed segment). there is no DSBM (not a managed segment).
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
* Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects * Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects
and places the RSVP session address in the destination and places the RSVP session address in the destination
address of the IP header. It places the L2 address of the address of the IP header. It places the L2 address of the
next layer 3 hop, into the destination address of the MAC next layer 3 hop, into the destination address of the MAC
header and forwards the PATH message to H5. header and forwards the PATH message to H5.
5.8. Applying the Rules - Multicast Session 5.8. Applying the Rules - Multicast Session
The rules described above also apply to multicast (m/c) sessions. The rules described above also apply to multicast (m/c) sessions.
skipping to change at page 32, line 5 skipping to change at page 32, line 5
PHOP IP addr of R2 (seed the return path for PHOP IP addr of R2 (seed the return path for
RESV messages) RESV messages)
RSVP_HOP_L2 L2 addr of R2 RSVP_HOP_L2 L2 addr of R2
LAN_NHOP m/c session address and corresponding L2 address LAN_NHOP m/c session address and corresponding L2 address
LAN_LOOPBACK IP addr of S3 (DSBMs reflecting a PATH LAN_LOOPBACK IP addr of S3 (DSBMs reflecting a PATH
message don't modify this object) message don't modify this object)
IP Header IP Header
Source address IP address of H1 Source address IP address of H1
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
Destn address AllSBMIP address (since R2 is the DSBM for seg F) Destn address AllSBMIP address (since R2 is the DSBM for seg F)
MAC Header MAC Header
Destn address AllSBMMAC address (since R2 is the Destn address AllSBMMAC address (since R2 is the
DSBM for seg F) DSBM for seg F)
Since H3 is monitoring the All SBM Address, it will receive the Since H3 is monitoring the All SBM Address, it will receive the
PATH message reflected by R2. Note that R2 violated the standard PATH message reflected by R2. Note that R2 violated the standard
forwarding rules here by sending an incoming message back onto the forwarding rules here by sending an incoming message back onto the
skipping to change at page 33, line 5 skipping to change at page 33, line 5
* R2 determines that there is an m/c receiver accessible via a * R2 determines that there is an m/c receiver accessible via a
segment for which there is no DSBM. Therefore, it removes the segment for which there is no DSBM. Therefore, it removes the
LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session
address in the destination address of the IP header. It address in the destination address of the IP header. It
places the corresponding L2 address into the destination places the corresponding L2 address into the destination
address of the MAC header and multicasts the message towards address of the MAC header and multicasts the message towards
H5. H5.
5.9. Merging Traffic Class objects 5.9. Merging Traffic Class objects
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
When a DSBM client receives TCLASS objects from different senders When a DSBM client receives TCLASS objects from different senders
(different PATH messages) in the same RSVP session and needs to (different PATH messages) in the same RSVP session and needs to
combine them for sending back a single RESV message (as in a combine them for sending back a single RESV message (as in a
wild-card style reservation), the DSBM client should use the wild-card style reservation), the DSBM client must choose an
semantically "lowest" user_priority value among the values appropriate value that corresponds to the desired-delay traffic
received in TCLASS objects of the PATH messages. class. An accompanying document discusses the guidelines for
traffic class selection based on desired service and the TSpec
Similarly, when a SBM or DSBM needs to merge RESVs from different information [Seaman98].
next hops at a merge point, it should merge the TCLASS values in
the incoming RESVs to the semantically "lowest" user_priority
value among those received.
[NOTE: As stated earlier, an accompanying document defines the In addition, when a SBM or DSBM needs to merge RESVs from dif-
int-serv mappings over IEEE 802 networks [Seaman97] provides a ferent next hops at a merge point, it must decide how to handle
precise definition of user_priority values and describes how the the TCLASS values in the incoming RESVs if they do not match. Con-
priority values are compared to determine semantically "lower" of sider the case when a reservation is in place for a flow at a DSBM
the two values or the semantically "lowest" among all the (or SBM) with a successful admission control done for the TCLASS
user_priority values.] 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 mes-
sage 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 corrsponding to the RSVP "traffic control error"
(RESV_ERR code 21) that indicates failure to merge two incompati-
ble service requests (sub-code 01 for the RSVP traffic control
error) [RFC-2205].
5.10. Operation of SBM Transparent Devices 5.10. Operation of SBM Transparent Devices
We previously defined SBM Transparent devices. Since no SBM tran- We previously defined SBM Transparent devices. Since no SBM tran-
sparent devices were illustrated in the example provided, we will sparent devices were illustrated in the example provided, we will
describe the operation of these in the following paragraph. describe the operation of these in the following paragraph.
SBM transparent devices are unaware of the entire SBM/DSBM proto- SBM transparent devices are unaware of the entire SBM/DSBM proto-
col. They do not intercept messages addressed to either of the SBM col. They do not intercept messages addressed to either of the SBM
related local group addresses (the DSBMLogicalAddrss and the related local group addresses (the DSBMLogicalAddrss and the
ALLSBMAddress), but instead, pass them through. As a result, they ALLSBMAddress), but instead, pass them through. As a result, they
do not divide the DSBM election scope, they do not explicitly par- do not divide the DSBM election scope, they do not explicitly par-
ticipate in routing of PATH or RESV messages, and they do not par- ticipate in routing of PATH or RESV messages, and they do not par-
ticipate in admission control. They are entirely transparent with ticipate in admission control. They are entirely transparent with
respect to SBM operation. respect to SBM operation.
According to the definitions provided, physical segments intercon- According to the definitions provided, physical segments intercon-
nected by SBM transparent devices are considered a single managed nected by SBM transparent devices are considered a single managed
segment. Therefore, DSBMs must perform admission control on such segment. Therefore, DSBMs must perform admission control on such
managed segments, with limited knowledge of the segment's topol- managed segments, with limited knowledge of the segment's
ogy. In this case, the network administrator should configure the
DSBM for each managed segment, with some reasonable approximation SBM (Subnet Bandwidth Manager) November, 1998
of the segment's capacity. A conservative policy would configure
the DSBM for the lowest capacity route through the managed seg- topology. In this case, the network administrator should configure
ment. A liberal policy would configure the DSBM for the highest the DSBM for each managed segment, with some reasonable approxima-
tion of the segment's capacity. A conservative policy would con-
figure 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 administra- capacity route through the managed segment. A network administra-
tor will likely choose some value between the two, based on the tor will likely choose some value between the two, based on the
level of guarantee required and some knowledge of likely traffic level of guarantee required and some knowledge of likely traffic
patterns. patterns.
SBM (Subnet Bandwidth Manager) March, 1998
This document does not specify the configuration mechanism or the This document does not specify the configuration mechanism or the
choice of a policy. choice of a policy.
5.11. Operation of SBMs Which are NOT DSBMs 5.11. Operation of SBMs Which are NOT DSBMs
In the example illustrated, S3 hosts a SBM, but the SBM on S3 did In the example illustrated, S3 hosts a SBM, but the SBM on S3 did
not win the election to act as DSBM on any segment. One might ask not win the election to act as DSBM on any segment. One might ask
what purpose such a SBM protocol entity serves. Such SBMs actually what purpose such a SBM protocol entity serves. Such SBMs actually
provide two useful functions. First, the additional SBMs remain provide two useful functions. First, the additional SBMs remain
passive in the background for fault tolerance. They listen to the passive in the background for fault tolerance. They listen to the
skipping to change at page 34, line 44 skipping to change at page 35, line 5
Note that, SBM protocol entities which are not DSBMs, are not Note that, SBM protocol entities which are not DSBMs, are not
required to overwrite the PHOP in incident PATH messages with required to overwrite the PHOP in incident PATH messages with
their own address. This is because it is not necessary for RESV their own address. This is because it is not necessary for RESV
messages to be routed through these devices. RESV messages are messages to be routed through these devices. RESV messages are
only required to be routed through the correct sequence of DSBMs. only required to be routed through the correct sequence of DSBMs.
SBMs may not process RESV messages that do pass through them, SBMs may not process RESV messages that do pass through them,
other than to forward them towards their destination address, other than to forward them towards their destination address,
using standard forwarding rules. using standard forwarding rules.
SBM (Subnet Bandwidth Manager) November, 1998
SBM protocol entities which are not DSBMs are required to SBM protocol entities which are not DSBMs are required to
overwrite the address in the LAN_LOOPBACK object with their own overwrite the address in the LAN_LOOPBACK object with their own
address, in order to avoid looping multicast messages. However, no address, in order to avoid looping multicast messages. However, no
state need be stored. state need be stored.
6. Inter-Operability Considerations 6. Inter-Operability Considerations
SBM (Subnet Bandwidth Manager) March, 1998
There are a few interesting inter-operability issues related to There are a few interesting inter-operability issues related to
the deployment of a DSBM-based admission control method in an the deployment of a DSBM-based admission control method in an
environment consisting of network nodes with and without RSVP environment consisting of network nodes with and without RSVP
capability. In the following, we list some of these scenarios and capability. In the following, we list some of these scenarios and
explain how SBM-aware clients and nodes can operate in those explain how SBM-aware clients and nodes can operate in those
scenarios: scenarios:
6.1. An L2 domain with no RSVP capability. 6.1. An L2 domain with no RSVP capability.
It is possible to envisage L2 domains that do not use RSVP signal- It is possible to envisage L2 domains that do not use RSVP signal-
skipping to change at page 35, line 45 skipping to change at page 36, line 5
6.2. An L2 domain with SBM-transparent L2 Devices. 6.2. An L2 domain with SBM-transparent L2 Devices.
This scenario has been addressed earlier in the document. The This scenario has been addressed earlier in the document. The
SBM-based method is designed to operate in such an environment. SBM-based method is designed to operate in such an environment.
When SBM-transparent L2 devices interconnect SBM-aware devices, When SBM-transparent L2 devices interconnect SBM-aware devices,
the resulting managed segment is a combination of one or more phy- the resulting managed segment is a combination of one or more phy-
sical segments and the DSBM for the managed segment may not be as sical segments and the DSBM for the managed segment may not be as
efficient in allocating resources as it would if all L2 devices efficient in allocating resources as it would if all L2 devices
were SBM-aware. were SBM-aware.
SBM (Subnet Bandwidth Manager) November, 1998
6.3. An L2 domain on which some RSVP-based senders are not DSBM 6.3. An L2 domain on which some RSVP-based senders are not DSBM
clients. clients.
All senders that are sourcing RSVP-based traffic flows onto a All senders that are sourcing RSVP-based traffic flows onto a
managed segment MUST be SBM-aware and participate in the SBM managed segment MUST be SBM-aware and participate in the SBM pro-
tocol. Use of the standard, non-SBM version of RSVP may result in
SBM (Subnet Bandwidth Manager) March, 1998 over-allocation of resources, as such use bypasses the resource
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 management function of the DSBM. All other senders (i.e., senders
that are not sending streams subject to RSVP admission control) that are not sending streams subject to RSVP admission control)
should be elastic applications that send traffic of lower priority should be elastic applications that send traffic of lower priority
than the RSVP traffic, and use TCP-like congestion avoidance than the RSVP traffic, and use TCP-like congestion avoidance
mechanisms. mechanisms.
All DSBMs, SBMs, or DSBM clients on a managed segment (a segment All DSBMs, SBMs, or DSBM clients on a managed segment (a segment
with a currently active DSBM) must not accept PATH messages from with a currently active DSBM) must not accept PATH messages from
senders that are not SBM-aware. PATH messages from such devices senders that are not SBM-aware. PATH messages from such devices
can be easily detected by SBMs and DSBM clients as they would not can be easily detected by SBMs and DSBM clients as they would not
skipping to change at page 36, line 46 skipping to change at page 37, line 5
This document stipulates that DSBMs, DSBM clients, and SBMs use This document stipulates that DSBMs, DSBM clients, and SBMs use
only raw IP for encapsulating RSVP messages that are forwarded only raw IP for encapsulating RSVP messages that are forwarded
onto a L2 domain. RFC-2205 (the RSVP Proposed Standard) includes onto a L2 domain. RFC-2205 (the RSVP Proposed Standard) includes
support for both raw IP and UDP encapsulation. Thus, a RSVP node support for both raw IP and UDP encapsulation. Thus, a RSVP node
using only the UDP encapsulation will not be able to interoperate using only the UDP encapsulation will not be able to interoperate
with the DSBM unless DSBM accepts and supports UDP encapsulated with the DSBM unless DSBM accepts and supports UDP encapsulated
RSVP messages. RSVP messages.
7. Guidelines for Implementors 7. Guidelines for Implementors
SBM (Subnet Bandwidth Manager) November, 1998
In the following, we provide guidelines for implementors on dif- In the following, we provide guidelines for implementors on dif-
ferent aspects of the implementation of the SBM-based admission ferent aspects of the implementation of the SBM-based admission
control procedure including suggestions for DSBM initialization, control procedure including suggestions for DSBM initialization,
SBM (Subnet Bandwidth Manager) March, 1998
etc. etc.
7.1. DSBM Initialization 7.1. DSBM Initialization
As stated earlier, DSBM initialization includes configuration of As stated earlier, DSBM initialization includes configuration of
maximum bandwidth that can be reserved on a managed segment under maximum bandwidth that can be reserved on a managed segment under
its control. We suggest the following guideline. its control. We suggest the following guideline.
In the case of a managed segment consisting of L2 devices inter- In the case of a managed segment consisting of L2 devices inter-
connected by a single shared segment, DSBM entities on such dev- connected by a single shared segment, DSBM entities on such dev-
skipping to change at page 37, line 50 skipping to change at page 38, line 4
This configuration compromises the efficiency with which the DSBM This configuration compromises the efficiency with which the DSBM
can allocate resources. This is because the single DSBM is can allocate resources. This is because the single DSBM is
required to make admission control decisions for all reservation required to make admission control decisions for all reservation
requests within the L2 topology, with no knowledge of the actual requests within the L2 topology, with no knowledge of the actual
physical segments affected by the reservation. physical segments affected by the reservation.
We can realize improvements in the efficiency of resource alloca- We can realize improvements in the efficiency of resource alloca-
tion by subdividing the complex segment into a number of managed tion by subdividing the complex segment into a number of managed
segments, each managed by their own DSBM. In this case, each DSBM segments, each managed by their own DSBM. In this case, each DSBM
SBM (Subnet Bandwidth Manager) November, 1998
manages a managed segment having a relatively simple topology. manages a managed segment having a relatively simple topology.
Since managed segments are simpler, the DSBM can be configured Since managed segments are simpler, the DSBM can be configured
with a more accurate estimate of the resources available for all with a more accurate estimate of the resources available for all
SBM (Subnet Bandwidth Manager) March, 1998
reservations in the managed segment. In the ultimate configura- reservations in the managed segment. In the ultimate configura-
tion, each physical segment is a managed segment and is managed by tion, each physical segment is a managed segment and is managed by
its own DSBM. We make no assumption about the number of managed its own DSBM. We make no assumption about the number of managed
segments but state, simply, that in complex L2 topologies, the segments but state, simply, that in complex L2 topologies, the
efficiency of resource allocation improves as the granularity of efficiency of resource allocation improves as the granularity of
managed segments increases. managed segments increases.
8. Security Considerations 8. Security Considerations
The message formatting and usage rules described in this note The message formatting and usage rules described in this note
skipping to change at page 39, line 5 skipping to change at page 39, line 5
described here. A SBM implementation should satisfy these require- described here. A SBM implementation should satisfy these require-
ments and provide the suggested mechanisms just as though it were ments and provide the suggested mechanisms just as though it were
a conventional RSVP implementation and also protect the addi- a conventional RSVP implementation and also protect the addi-
tional, SBM-specific objects in a message. tional, SBM-specific objects in a message.
In addition, it is also necessary to authenticate DSBM candidates In addition, it is also necessary to authenticate DSBM candidates
during the election process, and a mechanism based on a shared during the election process, and a mechanism based on a shared
secret among the DSBM candidates may be used. The mechanism secret among the DSBM candidates may be used. The mechanism
defined in [Baker97] should be used. defined in [Baker97] should be used.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
9. References 9. References
[RFC-2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, [RFC-2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification ", RFC-2205, September 1997. Specification ", RFC-2205, September 1997.
[Baker97] F. Baker., "RSVP Cryptographic Authentication", draft- [Baker97] F. Baker., "RSVP Cryptographic Authentication", draft-
ietf-rsvp-md5-05.txt, August 1997. ietf-rsvp-md5-05.txt, August 1997.
skipping to change at page 39, line 38 skipping to change at page 39, line 38
[RFC-2210] J. Wroclawski, "The Use of RSVP with IETF Integrated [RFC-2210] J. Wroclawski, "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[RFC-2213] F. Baker, J. Krawczyk, "Integrated Services Management [RFC-2213] F. Baker, J. Krawczyk, "Integrated Services Management
Information Base", RFC 2213, September 1997. Information Base", RFC 2213, September 1997.
[Ghanwani98] A. Ghanwani, W. Pace, V. Srinivasan, A.Smith, [Ghanwani98] A. Ghanwani, W. Pace, V. Srinivasan, A.Smith,
M.Seaman "A Framework for Providing Integrated Services Over M.Seaman "A Framework for Providing Integrated Services Over
Shared and Switched LAN Technologies", Internet Draft <draft- Shared and Switched LAN Technologies", Internet Draft <draft-
ietf-issll-is802-framework-04.txt>, March 1998. ietf-issll-is802-framework-05.txt>, November 1998.
[Seaman97] M. Seaman, A. Smith, E. Crawley, "Integrated Service [Seaman98] M. Seaman, A. Smith, E. Crawley, "Integrated Service
Mappings on IEEE 802 Networks", Internet Draft <draft-ietf-issll- Mappings on IEEE 802 Networks", Internet Draft <draft-ietf-issll-
is802-svc-mapping-03.txt>, November 1997. is802-svc-mapping-04.txt>, November 1998.
[IEEE802Q] "IEEE Standards for Local and Metropolitan Area Net- [IEEE802Q] "IEEE Standards for Local and Metropolitan Area Net-
works: Virtual Bridged Local Area Networks", Draft Standard works: Virtual Bridged Local Area Networks", Draft Standard
P802.1Q/D9, February 20, 1998. P802.1Q/D9, February 20, 1998.
[IEEEP8021p] "Information technology - Telecommunications and [IEEEP8021p] "Information technology - Telecommunications and
information exchange between systems - Local and metropolitan area information exchange between systems - Local and metropolitan area
networks - Common specifications - Part 3: Media Access Control networks - Common specifications - Part 3: Media Access Control
(MAC) Bridges: Revision (Incorporating IEEE P802.1p: Traffic Class (MAC) Bridges: Revision (Incorporating IEEE P802.1p: Traffic
Expediting and Dynamic Multicast Filtering)", ISO/IEC Final CD Class Expediting and Dynamic Multicast Filtering)", ISO/IEC Final
15802-3 IEEE P802.1D/D15, November 24, 1997. CD 15802-3 IEEE P802.1D/D15, November 24, 1997.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
[IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D- [IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-
1993. 1993.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
APPENDIX A APPENDIX A
DSBM Election Algorithm DSBM Election Algorithm
A.1. Introduction A.1. Introduction
To simplify the rest of this discussion, we will assume that there 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 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 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. DSBM is elected for a half-duplex or full-duplex switched segment.
skipping to change at page 42, line 5 skipping to change at page 42, line 5
failure of a DSBM, it waits for a subsequent I_AM_DSBM advertise- failure of a DSBM, it waits for a subsequent I_AM_DSBM advertise-
ment before resuming any communication with the DSBM. During the ment before resuming any communication with the DSBM. During the
period when a DSBM is not present, a DSBM client may forward out- period when a DSBM is not present, a DSBM client may forward out-
going PATH messages using the standard RSVP forwarding rules. going PATH messages using the standard RSVP forwarding rules.
The exact message formats and addresses used for communication The exact message formats and addresses used for communication
with (and among) SBM(s) are described in Appendix B. with (and among) SBM(s) are described in Appendix B.
A.2. Overview of the DSBM Election Procedure A.2. Overview of the DSBM Election Procedure
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
When a SBM first starts up, it listens for incoming DSBM adver- When a SBM first starts up, it listens for incoming DSBM adver-
tisements for some period to check whether a DSBM already exists tisements for some period to check whether a DSBM already exists
in its L2 domain. If one already exists (and no new election is in 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 progress), the new SBM stays quiet in the background until an
election of DSBM is necessary. All messages related to the DSBM election of DSBM is necessary. All messages related to the DSBM
election and DSBM advertisements are always sent to the AllSBMAd- election and DSBM advertisements are always sent to the AllSBMAd-
dress. dress.
If no DSBM exists, the SBM initiates the election of a DSBM by If no DSBM exists, the SBM initiates the election of a DSBM by
skipping to change at page 43, line 5 skipping to change at page 43, line 5
(called ElectionIntervalTimer that is typically set to a value at (called ElectionIntervalTimer that is typically set to a value at
least equal to the DeadIntervalTimer value) to wait for the elec- least equal to the DeadIntervalTimer value) to wait for the elec-
tion to finish and to discover who is the best candidate. In this tion 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 state, X keeps track of the best (or better) candidate seen so far
(including itself). Whenever it receives another DSBM_WILLING mes- (including itself). Whenever it receives another DSBM_WILLING mes-
sage, it updates its notion of the best (or better) candidate sage, it updates its notion of the best (or better) candidate
based on the priority (and tie-breaking) criterion. During the based on the priority (and tie-breaking) criterion. During the
ElectionInterval, X sends out a DSBM_WILLING message every ElectionInterval, X sends out a DSBM_WILLING message every
RefreshInterval to (re)assert its candidacy. RefreshInterval to (re)assert its candidacy.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
At the end of the ElectionInterval, X checks whether it is the At the end of the ElectionInterval, X checks whether it is the
best candidate so far. If so, it declares itself to be the DSBM best candidate so far. If so, it declares itself to be the DSBM
(by sending out the I_AM_DSBM advertisement) and enters the (by sending out the I_AM_DSBM advertisement) and enters the
I_AM_DSBM state; otherwise, it decides to wait for the best candi- I_AM_DSBM state; otherwise, it decides to wait for the best candi-
date to declare itself the winner. To wait, X re-initializes its date to declare itself the winner. To wait, X re-initializes its
ElectDSBM state and continues to wait for another round of elec- ElectDSBM state and continues to wait for another round of elec-
tion (each round lasts for an ElectionTimerInterval duration). tion (each round lasts for an ElectionTimerInterval duration).
A SBM is in Idle state when no election is in progress and the A SBM is in Idle state when no election is in progress and the
skipping to change at page 44, line 5 skipping to change at page 44, line 5
At the end of the ElectionInterval, the elected DSBM sends out an At the end of the ElectionInterval, the elected DSBM sends out an
I_AM_DSBM advertisement and the DSBM is then operational. I_AM_DSBM advertisement and the DSBM is then operational.
A.4. DSBM Advertisements A.4. DSBM Advertisements
The I_AM_DSBM advertisement contains the following information: The I_AM_DSBM advertisement contains the following information:
1. DSBM address information -- contains the IP and L2 addresses 1. DSBM address information -- contains the IP and L2 addresses
of the DSBM and its SBM priority (a configuration parameter of the DSBM and its SBM priority (a configuration parameter
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
-- priority specified by a network administrator). The prior- -- priority specified by a network administrator). The prior-
ity value is used to choose among candidate SBMs during the ity value is used to choose among candidate SBMs during the
election algorithm. Higher integer values indicate higher election algorithm. Higher integer values indicate higher
priority and the value is in the range 0..255. The value zero 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 indicates that the SBM is not eligible to be the DSBM. The
IP address is required and used for breaking ties. The L2 IP address is required and used for breaking ties. The L2
address is for the interface of the managed segment. address is for the interface of the managed segment.
2. refresh interval -- contains the value of the refresh inter- 2. refresh interval -- contains the value of the refresh inter-
skipping to change at page 45, line 5 skipping to change at page 45, line 5
1. DSBM address information -- Contains the SBM's own addresses 1. DSBM address information -- Contains the SBM's own addresses
(IP and L2 address), if it wishes to be the DSBM. The IP (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 required and used for breaking ties. The L2
address is the address of the interface for the managed seg- address is the address of the interface for the managed seg-
ment in question. Also, the DSBM address information ment in question. Also, the DSBM address information
includes the corresponding priority of the SBM whose address includes the corresponding priority of the SBM whose address
is given above. is given above.
A.6. SBM State Variables A.6. SBM State Variables
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
For each network interface, a SBM maintains the following state For each network interface, a SBM maintains the following state
variables related to the election of the DSBM for the L2 domain on variables related to the election of the DSBM for the L2 domain on
that interface: that interface:
a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, a) LocalDSBMAddrInfo -- current DSBM's IP address (initially,
0.0.0.0) and priority. All IP addresses are assumed to be in 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 network byte order. In addition, current DSBM's L2 address is
also stored as part of this state information. also stored as part of this state information.
skipping to change at page 46, line 5 skipping to change at page 46, line 5
Figure 3 shows the state transition diagram for the election pro- Figure 3 shows the state transition diagram for the election pro-
tocol and the various states are described below. A complete tocol and the various states are described below. A complete
description of the state machine is provided in Section A.10. description of the state machine is provided in Section A.10.
A.7. DSBM Election States A.7. DSBM Election States
DOWN -- SBM is not operational. DOWN -- SBM is not operational.
DetectDSBM -- typically, the initial state of a SBM when it DetectDSBM -- typically, the initial state of a SBM when it
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
starts up. In this state, it checks to see whether a DSBM starts up. In this state, it checks to see whether a DSBM
already exists in its domain. already exists in its domain.
Idle -- SBM is in this state when no election is in progress Idle -- SBM is in this state when no election is in progress
and it is not the DSBM. In this state, SBM passively monitors and it is not the DSBM. In this state, SBM passively monitors
the state of the DSBM. the state of the DSBM.
ElectDSBM -- SBM is in this state when a DSBM election is in ElectDSBM -- SBM is in this state when a DSBM election is in
progress. progress.
skipping to change at page 47, line 5 skipping to change at page 47, line 5
I_AM_DSBM message received -- SBM received a DSBM advertise- I_AM_DSBM message received -- SBM received a DSBM advertise-
ment from the DSBM in its L2 domain. ment from the DSBM in its L2 domain.
SBMDeadInterval Timeout -- The SBMDeadInterval timer has SBMDeadInterval Timeout -- The SBMDeadInterval timer has
fired. This means that the SBM did not receive even one DSBM fired. This means that the SBM did not receive even one DSBM
advertisement during this period and indicates possible advertisement during this period and indicates possible
failure of the DSBM. failure of the DSBM.
RefreshInterval Timeout -- The RefreshInterval timer has RefreshInterval Timeout -- The RefreshInterval timer has
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
fired. In the I_AM_DSBM state, this means it is the time for fired. In the I_AM_DSBM state, this means it is the time for
sending out the next DSBM advertisement. In the ElectDSBM sending out the next DSBM advertisement. In the ElectDSBM
state, the event means that it is the time to send out state, the event means that it is the time to send out
another DSBM_WILLING message. another DSBM_WILLING message.
ElectionInterval Timeout -- The ElectionInterval timer has ElectionInterval Timeout -- The ElectionInterval timer has
fired. This means that the SBM has waited long enough after fired. This means that the SBM has waited long enough after
declaring its candidacy to determine whether or not it suc- declaring its candidacy to determine whether or not it suc-
ceeded. ceeded.
CONTINUED ON NEXT PAGE CONTINUED ON NEXT PAGE
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
A.9. State Transition Diagram (Figure 3) A.9. State Transition Diagram (Figure 3)
+-----------+ +-----------+
+--<--------------<-|DetectDSBM |---->------+ +--<--------------<-|DetectDSBM |---->------+
| +-----------+ | | +-----------+ |
| | | |
| | | |
| | | |
| +-------------+ +---------+ | | +-------------+ +---------+ |
skipping to change at page 49, line 5 skipping to change at page 49, line 5
-- determines whether the entity represented by the first parameter -- determines whether the entity represented by the first parameter
is better than the second entity using the priority information is better than the second entity using the priority information
and the IP address information in the two parameters. and the IP address information in the two parameters.
If any address is zero, that entity If any address is zero, that entity
automatically loses; then first priorities are compared; higher automatically loses; then first priorities are compared; higher
priority candidate wins. If there is a tie based on priority candidate wins. If there is a tie based on
the priority value, the tie is broken using the IP the priority value, the tie is broken using the IP
addresses of tied candidates (one with the higher IP address in the addresses of tied candidates (one with the higher IP address in the
lexicographic order wins). Returns TRUE if first entity is a better lexicographic order wins). Returns TRUE if first entity is a better
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
choice. FALSE otherwise. choice. FALSE otherwise.
SendDSBMWilling Message() SendDSBMWilling Message()
Begin Begin
Send out DSBM_WILLING message listing myself as a candidate for Send out DSBM_WILLING message listing myself as a candidate for
DSBM (copy OwnAddr and priority into appropriate fields) DSBM (copy OwnAddr and priority into appropriate fields)
start RefreshIntervalTimer start RefreshIntervalTimer
goto ElectDSBM state goto ElectDSBM state
End End
skipping to change at page 50, line 5 skipping to change at page 50, line 5
Action: Initialize the local state variables (LocalDSBMADDR and Action: Initialize the local state variables (LocalDSBMADDR and
LocalDSBMAddrInfo set to 0). Start the ListenIntervalTimer. LocalDSBMAddrInfo set to 0). Start the ListenIntervalTimer.
State: DetectDSBM State: DetectDSBM
New State: Idle New State: Idle
Event: I_AM_DSBM message received Event: I_AM_DSBM message received
Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo
start DeadDSBMInterval timer start DeadDSBMInterval timer
goto Idle State goto Idle State
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
State: DetectDSBM State: DetectDSBM
Event: ListenIntervalTimer fired Event: ListenIntervalTimer fired
New State: ElectDSBM New State: ElectDSBM
Action: Start ElectionIntervalTimer Action: Start ElectionIntervalTimer
SendDSBMWillingMessage(); SendDSBMWillingMessage();
State: DetectDSBM State: DetectDSBM
Event: DSBM_WILLING message received Event: DSBM_WILLING message received
New State: ElectDSBM New State: ElectDSBM
skipping to change at page 51, line 5 skipping to change at page 51, line 5
Event: DSBM_WILLING Message is received Event: DSBM_WILLING Message is received
New State: Depends on action (ElectDSBM or Idle) New State: Depends on action (ElectDSBM or Idle)
Action: /* check whether it is from the DSBM itself (shutdown) */ Action: /* check whether it is from the DSBM itself (shutdown) */
if (IncomingDSBMAddr == LocalDSBMAddr) { if (IncomingDSBMAddr == LocalDSBMAddr) {
cancel active timers cancel active timers
Set LocalDSBMAddrInfo = OwnAddrInfo Set LocalDSBMAddrInfo = OwnAddrInfo
Start ElectionIntervalTimer Start ElectionIntervalTimer
SendDSBMWillingMessage() /* goto ElectDSBM state */ SendDSBMWillingMessage() /* goto ElectDSBM state */
} }
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
/* else, ignore it */ /* else, ignore it */
continue in current state continue in current state
State: ElectDSBM State: ElectDSBM
Event: ElectionIntervalTimer Fired Event: ElectionIntervalTimer Fired
New State: depends on action (I_AM_DSBM or Current State) New State: depends on action (I_AM_DSBM or Current State)
Action: If (LocalDSBMAddrInfo == OwnAddrInfo) { Action: If (LocalDSBMAddrInfo == OwnAddrInfo) {
/* I won */ /* I won */
send I_AM_DSBM message send I_AM_DSBM message
skipping to change at page 52, line 5 skipping to change at page 52, line 5
State: ElectDSBM State: ElectDSBM
Event: RefreshIntervalTimer fired Event: RefreshIntervalTimer fired
New State: ElectDSBM New State: ElectDSBM
Action: /* continue to send DSBMWilling messages until Action: /* continue to send DSBMWilling messages until
election interval ends */ election interval ends */
SendDSBMWillingMessage() SendDSBMWillingMessage()
State: I_AM_DSBM State: I_AM_DSBM
Event: DSBM_WILLING message received Event: DSBM_WILLING message received
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
New State: I_AM_DSBM New State: I_AM_DSBM
Action: send I_AM_DSBM message /* reassert myself */ Action: send I_AM_DSBM message /* reassert myself */
restart RefreshIntervalTimer restart RefreshIntervalTimer
State: I_AM_DSBM State: I_AM_DSBM
Event: RefreshIntervalTimer fired Event: RefreshIntervalTimer fired
New State: I_AM_DSBM New State: I_AM_DSBM
Action: send I_AM_DSBM message Action: send I_AM_DSBM message
restart RefreshIntervalTimer restart RefreshIntervalTimer
skipping to change at page 53, line 5 skipping to change at page 53, line 5
the edge devices, we suggest the following values for various the edge devices, we suggest the following values for various
timers. timers.
Assuming that the RSVP implementations use a 30 second timeout for Assuming that the RSVP implementations use a 30 second timeout for
PATH and RESV refreshes, we suggest that the RefreshIntervalTimer PATH and RESV refreshes, we suggest that the RefreshIntervalTimer
should be set to about 5 seconds with DSBMDeadIntervalTimer set to should be set to about 5 seconds with DSBMDeadIntervalTimer set to
15 seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be 15 seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be
set to a random value between (DeadIntervalTimer, 2*DeadInterval- set to a random value between (DeadIntervalTimer, 2*DeadInterval-
Timer). The ElectionIntervalTimer should be set at least to the Timer). The ElectionIntervalTimer should be set at least to the
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
value of DeadIntervalTimer to ensure that each SBM has a chance to value of DeadIntervalTimer to ensure that each SBM has a chance to
have its DSBM_WILLING message (sent every RefreshInterval in have its DSBM_WILLING message (sent every RefreshInterval in
ElectDSBM state) delivered to others. ElectDSBM state) delivered to others.
A.10.3. Guidelines for Choice of Values for SBM_PRIORITY A.10.3. Guidelines for Choice of Values for SBM_PRIORITY
Network administrators should configure SBM protocol entity at Network administrators should configure SBM protocol entity at
each SBM-capable device with the device's "SBM priority" for each each SBM-capable device with the device's "SBM priority" for each
of the interfaces attached to a managed segment. SBM_PRIORITY is of the interfaces attached to a managed segment. SBM_PRIORITY is
skipping to change at page 54, line 5 skipping to change at page 54, line 5
elected separately on each point-to-point segment in a switched elected separately on each point-to-point segment in a switched
topology. For example, in Figure 2, DSBM for "segment A" will be topology. For example, in Figure 2, DSBM for "segment A" will be
elected using the election algorithm between R1 and S1 and none of elected using the election algorithm between R1 and S1 and none of
the election-related messages on this segment will be forwarded by the election-related messages on this segment will be forwarded by
S1 beyond "segment A". Similarly, a separate election will take S1 beyond "segment A". Similarly, a separate election will take
place on each segment in this topology. place on each segment in this topology.
When a switched segment is a half-duplex segment, two senders (one When a switched segment is a half-duplex segment, two senders (one
sender at each end of the link) share the link. In this case, one sender at each end of the link) share the link. In this case, one
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
of the two senders will win the DSBM election and will be respon- of the two senders will win the DSBM election and will be respon-
sible for managing the segment. sible for managing the segment.
If a switched segment is full-duplex, exactly one sender sends on 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 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 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 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 be the DSBM by sending out an I_AM_DSBM advertisement and start
managing the resources for the outgoing traffic over the segment. managing the resources for the outgoing traffic over the segment.
If one of the two senders does not wish itself to be the DSBM, 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 then the other DSBM will not receive any DSBM advertisement from
its peer and assume itself to be the DSBM for traffic traversing its peer and assume itself to be the DSBM for traffic traversing
in both directions over the managed segment. in both directions over the managed segment.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
APPENDIX B APPENDIX B
Message Encapsulation and Formats Message Encapsulation and Formats
To minimize changes to the existing RSVP implementations and to To minimize changes to the existing RSVP implementations and to
ensure quick deployment of a SBM in conjunction with RSVP, all ensure quick deployment of a SBM in conjunction with RSVP, all
communication to and from a DSBM will be performed using messages communication to and from a DSBM will be performed using messages
constructed using the current rules for RSVP message formats and constructed using the current rules for RSVP message formats and
raw IP encapsulation. For more details on the RSVP message for- raw IP encapsulation. For more details on the RSVP message for-
mats, refer to the RSVP specification (RFC 2205). No changes to mats, refer to the RSVP specification (RFC 2205). No changes to
skipping to change at page 56, line 5 skipping to change at page 56, line 5
B.3. RSVP-related Message Formats B.3. RSVP-related Message Formats
All RSVP messages directed to and from a DSBM may contain various All RSVP messages directed to and from a DSBM may contain various
RSVP objects defined in the RSVP specification and messages con- RSVP objects defined in the RSVP specification and messages con-
tinue to follow the formatting rules specified in the RSVP specif- tinue to follow the formatting rules specified in the RSVP specif-
ication. In addition, an RSVP implementation must also recognize ication. In addition, an RSVP implementation must also recognize
new object classes that are described below. new object classes that are described below.
B.3.1. Object Formats B.3.1. Object Formats
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
All objects are defined using the format specified in the RSVP All objects are defined using the format specified in the RSVP
specification. Each object has a 32-bit header that contains specification. Each object has a 32-bit header that contains
length (of the object in bytes including the object header), the length (of the object in bytes including the object header), the
object class number, and a C-Type. All unused fields should be set object class number, and a C-Type. All unused fields should be set
to zero and ignored on receipt. to zero and ignored on receipt.
B.3.2. LAN_NHOP, RSVP_HOP_L2, and LAN_LOOPBACK Objects B.3.2. LAN_NHOP, RSVP_HOP_L2, and LAN_LOOPBACK Objects
LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2 objects are identified as LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2 objects are identified as
skipping to change at page 57, line 5 skipping to change at page 57, line 5
This canonical format corresponds to the natural value of the This canonical format corresponds to the natural value of the
address octets for Ethernet. The actual transmission order or for- address octets for Ethernet. The actual transmission order or for-
mal encoding rules for addresses on media which do not transmit mal encoding rules for addresses on media which do not transmit
bit serially are derived from the canonical format octet values. bit serially are 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 the SBM protocol be encoded in the canonical format as a with the SBM protocol be encoded in the canonical format as a
sequence of 6 octets. In the following, we define the object sequence of 6 octets. In the following, we define the object
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
formats for objects that contain L2 addresses that are based on formats for objects that contain L2 addresses that are based on
the canonical representation. the canonical 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 of the previous hop L3 device in the IEEE Canonical
address format discussed above. address format discussed above.
skipping to change at page 58, line 5 skipping to change at page 58, line 5
B.3.5. LAN_NHOP object B.3.5. LAN_NHOP object
LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 LAN_NHOP object represents two objects, namely, LAN_NHOP_L3
address object and LAN_NHOP_L2 address object. address object and LAN_NHOP_L2 address object.
<LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object> <LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object>
LAN_NHOP_L2 address object uses object class = 162 and uses the LAN_NHOP_L2 address object uses object class = 162 and uses the
same format (but different class number) as the RSVP_HOP_L2 same format (but different class number) as the RSVP_HOP_L2
object. It provides the L2 or MAC address of the next hop L3 object. It provides the L2 or MAC address of the next hop L3
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
device. device.
0 1 2 3 0 1 2 3
+---------------+---------------+---------------+----------------+ +---------------+---------------+---------------+----------------+
| Length | 162 |C-Type(addrtype)| | Length | 162 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+ +---------------+---------------+---------------+----------------+
| Variable length Opaque data | | Variable length Opaque data |
+---------------+---------------+---------------+----------------+ +---------------+---------------+---------------+----------------+
skipping to change at page 59, line 5 skipping to change at page 59, line 5
and IPv6 formats are specified. and IPv6 formats are specified.
IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1 IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1
0 1 2 3 0 1 2 3
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Length | 164 | 1 | | Length | 164 | 1 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| IPV4 address of an interface | | IPV4 address of an interface |
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2 IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Length | 164 | 2 | | Length | 164 | 2 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
+ + + +
skipping to change at page 60, line 5 skipping to change at page 60, line 5
tion (RFC 2205). Enhancements to an RSVP_PATH message include tion (RFC 2205). Enhancements to an RSVP_PATH message include
additional objects as specified below. additional objects as specified below.
<PATH Message> ::= <RSVP Common Header> [<INTEGRITY>] <PATH Message> ::= <RSVP Common Header> [<INTEGRITY>]
<RSVP_HOP_L2> <LAN_NHOP> <RSVP_HOP_L2> <LAN_NHOP>
<LAN_LOOPBACK> [<TCLASS>] <SESSION><RSVP_HOP> <LAN_LOOPBACK> [<TCLASS>] <SESSION><RSVP_HOP>
<TIME_VALUES> [<POLICY DATA>] <sender descriptor> <TIME_VALUES> [<POLICY DATA>] <sender descriptor>
<PATH_TEAR Message> ::= <RSVP Common Header> [<INTEGRITY>] <PATH_TEAR Message> ::= <RSVP Common Header> [<INTEGRITY>]
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
<LAN_LOOPBACK> <LAN_NHOP> <SESSION> <RSVP_HOP> <LAN_LOOPBACK> <LAN_NHOP> <SESSION> <RSVP_HOP>
[<sender descriptor>] [<sender descriptor>]
If the INTEGRITY object is present, it must immediately follow the If the INTEGRITY object is present, it must immediately follow the
RSVP common header. L2-specific objects must always precede the RSVP common header. L2-specific objects must always precede the
SESSION object. SESSION object.
B.5. RSVP RESV Message Format B.5. RSVP RESV Message Format
skipping to change at page 61, line 5 skipping to change at page 61, line 5
For each SBM message type, there is a set of rules for the permis- For each SBM message type, there is a set of rules for the permis-
sible choice of object types. These rules are specified using sible choice of object types. These rules are specified using
Backus-Naur Form (BNF) augmented with square brackets surrounding Backus-Naur Form (BNF) augmented with square brackets surrounding
optional sub-sequences. The BNF implies an order for the objects optional sub-sequences. The BNF implies an order for the objects
in a message. However, in many (but not all) cases, object order in a message. However, in many (but not all) cases, object order
makes no logical difference. An implementation should create mes- makes no logical difference. An implementation should create mes-
sages with the objects in the order shown here, but accept the sages with the objects in the order shown here, but accept the
objects in any permissible order. Any exceptions to this rule will objects in any permissible order. Any exceptions to this rule will
be pointed out in the specific message formats. be pointed out in the specific message formats.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
DSBM_WILLING Message DSBM_WILLING Message
<DSBM_WILLING message> ::= <SBM Common Header> <DSBM IP ADDRESS> <DSBM_WILLING message> ::= <SBM Common Header> <DSBM IP ADDRESS>
<DSBM L2 address> <SBM PRIORITY> <DSBM L2 address> <SBM PRIORITY>
I_AM_DSBM Message I_AM_DSBM Message
<I_AM_DSBM> ::= <SBM Common Header> <DSBM IP ADDRESS> <DSBM L2 address> <I_AM_DSBM> ::= <SBM Common Header> <DSBM IP ADDRESS> <DSBM L2 address>
<SBM PRIORITY> <DSBM Timer Intervals> <SBM PRIORITY> <DSBM Timer Intervals>
skipping to change at page 62, line 5 skipping to change at page 62, line 5
| | | |
+ IPv6 DSBM IP Address + + IPv6 DSBM IP Address +
| | | |
+ + + +
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
<DSBM L2 address> Object is the same as <RSVP_HOP_L2> object with C-Type <DSBM L2 address> Object is the same as <RSVP_HOP_L2> object with C-Type
=1 for IEEE Canonical Address format. =1 for IEEE Canonical Address format.
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
<DSBM L2 address> ::= <RSVP_HOP_L2> <DSBM L2 address> ::= <RSVP_HOP_L2>
a SBM may omit this object by including a NULL L2 address object. For 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 C-Type=1 (IEEE Canonical address format), such a version of the L2
address object contains value zero in the six octet s corresponding to the address object contains value zero in the six octet s corresponding to the
MAC address (see section B.3.4 for the exact format). MAC address (see section B.3.4 for the exact format).
SBM_PRIORITY Object: class = 43, C-Type =1 SBM_PRIORITY Object: class = 43, C-Type =1
skipping to change at page 63, line 5 skipping to change at page 63, line 5
+---------------+---------------+---------------+----------------+ +---------------+---------------+---------------+----------------+
| //// | //// | //// | Media Type | | //// | //// | //// | Media Type |
+---------------+---------------+---------------+----------------+ +---------------+---------------+---------------+----------------+
| OptFlowSpec (limit on traffic allowed to send without RESV) | | OptFlowSpec (limit on traffic allowed to send without RESV) |
| | | |
+---------------+---------------+---------------+----------------+ +---------------+---------------+---------------+----------------+
Media Type values: 0 (Shared segment); a default Media Type values: 0 (Shared segment); a default
1 (switched, half duplex) 1 (switched, half duplex)
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
2 (switched, full duplex) 2 (switched, full duplex)
OptFlowSpec: OptFlowSpec:
This parameter specifies whether or not a sender can send traffic This parameter specifies whether or not a sender can send traffic
when its RESV request fails. The parameter is an Intserv SENDER_TSPEC when its RESV request fails. The parameter is an Intserv SENDER_TSPEC
object (see RFC 2210 for contents and encoding rules). object (see RFC 2210 for contents and encoding rules).
If the token bucket rate (r) specified in If the token bucket rate (r) specified in
this parameter is zero, it indicates that the sender(s) must not send this parameter is zero, it indicates that the sender(s) must not send
traffic if their RESV request fails; otherwise, the parameter specifies traffic if their RESV request fails; otherwise, the parameter specifies
per-session limit on the amount of traffic that can be sent when RESV per-session limit on the amount of traffic that can be sent when RESV
attempt for the session fails. attempt for the session fails.
<OptFlowSpec> ::= <Intserv Sender_TSPEC object> (class=12, C-Type =2) <OptFlowSpec> ::= <Intserv Sender_TSPEC object> (class=12, C-Type =2)
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
ACKNOWLEDGEMENTS ACKNOWLEDGEMENTS
Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel), Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel),
David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman
(3COM), Andrew Smith (Extreme Networks) for their constructive (3COM), Andrew Smith (Extreme Networks) for their constructive
comments on the SBM design and the earlier versions of this docu- comments on the SBM design and the earlier versions of this docu-
ment. ment.
6. Authors` Addresses 6. Authors` Addresses
skipping to change at page 65, line 5 skipping to change at page 65, line 5
phone: +1 408 526 4257 phone: +1 408 526 4257
email: fred@cisco.com email: fred@cisco.com
Michael Speer Michael Speer
Sun Microsystems, Inc Sun Microsystems, Inc
901 San Antonio Road UMPK15-215 901 San Antonio Road UMPK15-215
Palo Alto, CA 94303 Palo Alto, CA 94303
phone: +1 650-786-6368 phone: +1 650-786-6368
email: speer@Eng.Sun.COM email: speer@Eng.Sun.COM
SBM (Subnet Bandwidth Manager) March, 1998 SBM (Subnet Bandwidth Manager) November, 1998
 End of changes. 85 change blocks. 
118 lines changed or deleted 129 lines changed or added

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