As per Relevance of the word messages, we have this rfc below:
Network Working Group R.
Request for Comments: 2814
Category: Standards Track D.
Y.
F.
M.
Sun
May 2000
SBM (Subnet Bandwidth Manager):
A Protocol for RSVP-based Admission Control over IEEE 802-style
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document describes a signaling method and protocol for RSVP
based admission control over IEEE 802-style LANs. The protocol
designed to work both with the current generation of IEEE 802 LANs
well as with the recent work completed by the IEEE 802.1 committee
1.
New extensions to the Internet architecture and service models
been defined for an integrated services Internet [RFC-1633, RFC-2205,
RFC-2210] so that applications can request specific qualities
levels of service from an internetwork in addition to the current
best-effort service. These extensions include RSVP, a
reservation setup protocol, and definition of new service classes
be supported by Integrated Services routers. RSVP and service
definitions are largely independent of the underlying
technologies and it is necessary to define the mapping of RSVP
Integrated Services specifications onto specific
technologies. For example, a definition of service mappings
Yavatkar, et al. Standards Track [Page 1]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
reservation setup protocols is needed for specific link-
technologies such as shared and switched IEEE-802-style
technologies
This document defines SBM, a signaling protocol for RSVP-
admission control over IEEE 802-style networks. SBM provides
method for mapping an internet-level setup protocol such as RSVP
IEEE 802 style networks. In particular, it describes the
of RSVP-enabled hosts/routers and link layer devices (switches
bridges) to support reservation of LAN resources for RSVP-
data flows. A framework for providing Integrated Services
shared and switched IEEE-802-style LAN technologies and a
of service mappings have been described in separate documents [RFC
FRAME, RFC-MAP].
2. Goals and
The SBM (Subnet Bandwidth Manager) protocol and its use for
control and bandwidth management in IEEE 802 level-2 networks
based on the following architectural goals and assumptions
I. Even though the current trend is towards increased use
switched LAN topologies consisting of newer switches that
the priority queuing mechanisms specified by IEEE 802.1p,
assume that the LAN technologies will continue to be a mix
legacy shared/ switched LAN segments and newer switched
based on IEEE 802.1p specification. Therefore, we specify
signaling protocol for managing bandwidth over both legacy
newer LAN topologies and that takes advantage of the
functionality (such as an explicit support for different
classes or integrated service classes) as it becomes available
the new generation of switches, hubs, or bridges. As a result
the SBM protocol would allow for a range of LAN
management solutions that vary from one that exercises
administrative control (over the amount of bandwidth consumed
RSVP-enabled traffic flows) to one that requires cooperation (
enforcement) from all the end-systems or switches in a IEEE 802
LAN
II. This document specifies only a signaling method and
for LAN-based admission control over RSVP flows. We do not
here any traffic control mechanisms for the link layer;
protocol is designed to use any such mechanisms defined by
802. In addition, we assume that the Layer 3 end-systems (e.g.,
host or a router) will exercise traffic control by
Integrated Services traffic flows to ensure that each flow
within its traffic specifications stipulated in an
reservation request submitted for admission control. This
Yavatkar, et al. Standards Track [Page 2]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
allows a system using SBM admission control combined with per
shaping at end systems and IEEE-defined traffic control at
layer to realize some approximation of Controlled Load (and
Guaranteed) services over IEEE 802-style LANs
III. In the absence of any link-layer traffic control or
queuing mechanisms in the underlying LAN (such as a shared
segment), the SBM-based admission control mechanism only
the total amount of traffic load imposed by RSVP-enabled flows
a shared LAN. In such an environment, no traffic flow
mechanism exists to protect the RSVP-enabled flows from the best
effort traffic on the same shared media and that raises
question of the utility of such a mechanism outside a
consisting only of 802.1p-compliant switches. However, we
that the SBM-based admission control mechanism will still serve
useful purpose in a legacy, shared LAN topology for two reasons
First, assuming that all the nodes that generate
Services traffic flows utilize the SBM-based admission
procedure to request reservation of resources before sending
traffic, the mechanism will restrict the total amount of
generated by Integrated Services flows within the bounds
by a LAN administrator (see discussion of the
parameter in Appendix C). Second, the best-effort
generated by the TCP/IP-based traffic sources is generally
adaptive (using a TCP-style "slow start" congestion
mechanism or a feedback-based rate adaptation mechanism used
audio/video streams based on RTP/RTCP protocols) and adapts
stay within the available network bandwidth. Thus,
combination of admission control and rate adaptation should
persistent traffic congestion. This does not, however,
that non-Integrated-Services traffic will not interfere with
Integrated Services traffic in the absence of traffic
support in the underlying LAN infrastructure
3. Organization of the rest of this
The rest of this document provides a detailed description of
SBM-based admission control procedure(s) for IEEE 802
technologies. The document is organized as follows
* Section 4 first defines the various terms used in the document
then provides an overview of the admission control procedure
an example of its application to a sample network
* Section 5 describes the rules for processing and forwarding
(and PATH_TEAR) messages at DSBMs (Designated Subnet
Managers), SBMs, and DSBM clients
Yavatkar, et al. Standards Track [Page 3]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
* Section 6 addresses the inter-operability issues when a DSBM
operate in the absence of RSVP signaling at Layer 3 or
another signaling protocol (such as SNMP) is used to
resources on a LAN segment
* Appendix A describes the details of the DSBM election
used for electing a designated SBM on a LAN segment when more
one SBM is present. It also describes how DSBM clients
the presence of a DSBM on a managed segment
* Appendix B specifies the formats of SBM-specific messages used
the formats of new RSVP objects needed for the SBM operation
* Appendix C describes usage of the DSBM to distribute
information to senders on a managed segment
4.
4.1.
- Link Layer or Layer 2 or L2: We refer to data-link
technologies such as IEEE 802.3/Ethernet as L2 or layer 2.
- Link Layer Domain or Layer 2 domain or L2 domain: a set of
and links interconnected without passing through a L3
function. One or more IP subnets can be overlaid on a L2 domain
- Layer 2 or L2 devices: We refer to devices that only
Layer 2 functionality as Layer 2 or L2 devices. These
802.1D bridges or switches
- Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO 7
model. This document is primarily concerned with networks that
the Internet Protocol (IP) at this layer
- Layer 3 Device or L3 Device or End-Station: these include
and routers that use L3 and higher layer protocols or
programs that need to make resource reservations
- Segment: A L2 physical segment that is shared by one or
senders. Examples of segments include (a) a shared Ethernet
Token-Ring wire resolving contention for media access using
or token passing ("shared L2 segment"), (b) a half duplex
between two stations or switches, (c) one direction of a
full-duplex link
Yavatkar, et al. Standards Track [Page 4]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
- Managed segment: A managed segment is a segment with a
present and responsible for exercising admission control
requests for resource reservation. A managed segment
those interconnected parts of a shared LAN that are not
by DSBMs
- Traffic Class: An aggregation of data flows which are
similar service within a switched network
- User_priority: User_priority is a value associated with
transmission and reception of all frames in the IEEE 802
model: it is supplied by the sender that is using the MAC service
It is provided along with the data to a receiver using the
service. It may or may not be actually carried over the network
Token-Ring/802.5 carries this value (encoded in its FC octet),
basic Ethernet/802.3 does not, 802.12 may or may not depending
the frame format in use. 802.1p defines a consistent way to
this value over the bridged network on Ethernet, Token Ring
Demand-Priority, FDDI or other MAC-layer media using an
frame format. The usage of user_priority is fully described
section 2.5 of 802.1D [IEEE8021D] and 802.1p [IEEE8021P] "
of the Internal Layer Service by Specific MAC Procedures".
- Subnet: used in this memo to indicate a group of L3
sharing a common L3 network address prefix along with the set
segments making up the L2 domain in which they are located
- Bridge/Switch: a layer 2 forwarding device as defined by
802.1D. The terms bridge and switch are used synonymously in
document
- DSBM: Designated SBM (DSBM) is a protocol entity that resides in
L2 or L3 device and manages resources on a L2 segment. At most
DSBM exists for each L2 segment
- SBM: the SBM is a protocol entity that resides in a L2 or L
device and is capable of managing resources on a segment. However
only a DSBM manages the resources for a managed segment. When
than one SBM exists on a segment, one of the SBMs is elected to
the DSBM
- Extended segment: An extended segment includes those parts of
network which are members of the same IP subnet and therefore
not separated by any layer 3 devices. Several managed segments
interconnected by layer 2 devices, constitute an extended segment
Yavatkar, et al. Standards Track [Page 5]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
- Managed L2 domain: An L2 domain consisting of managed segments
referred to as a managed L2 domain to distinguish it from a L
domain with no DSBMs present for exercising admission control
resources at segments in the L2 domain
- DSBM clients: These are entities that transmit traffic onto
managed segment and use the services of a DSBM for the
segment for admission control over a LAN segment. Only the layer 3
or higher layer entities on L3 devices such as hosts and
are expected to send traffic that requires resource reservations
and, therefore, DSBM clients are L3 entities
- SBM transparent devices: A "SBM transparent" device is unaware
SBMs or DSBMs (though it may or may not be RSVP aware) and
therefore, does not participate in the SBM-based admission
procedure over a managed segment. Such a device uses
forwarding rules appropriate for the device and is
with respect to SBM. An example of such a L2 device is a
switch that does not participate in resource reservation
- Layer 3 and layer 2 addresses: We refer to layer 3 addresses
L3/L2 devices as "L3 addresses" and layer 2 addresses as "L
addresses". This convention will be used in the rest of
document to distinguish between Layer 3 and layer 2 addresses
to refer to RSVP next hop (NHOP) and previous hop (PHOP) devices
For example, in conventional RSVP message processing, RSVP_
object in a PATH message carries the L3 address of the
hop device. We will refer to the address contained in the RSVP_
object as the RSVP_HOP_L3 address and the corresponding
address of the previous hop device will be referred to as
RSVP_HOP_L2 address
4.2. Overview of the SBM-based Admission Control
A protocol entity called "Designated SBM" (DSBM) exists for
managed segment and is responsible for admission control over
resource reservation requests originating from the DSBM clients
that segment. Given a segment, one or more SBMs may exist on
segment. For example, many SBM-capable devices may be attached to
shared L2 segment whereas two SBM-capable switches may share a half
duplex switched segment. In that case, a single DSBM is elected
the segment. The procedure for dynamically electing the DSBM
described in Appendix A. The only other approved method
specifying a DSBM for a managed segment is static configuration
SBM-capable devices
Yavatkar, et al. Standards Track [Page 6]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
The presence of a DSBM makes the segment a "managed segment".
Sometimes, two or more L2 segments may be interconnected by
transparent devices. In that case, a single DSBM will manage
resources for those segments treating the collection of such
as a single managed segment for the purpose of admission control
4.2.1. Basic
Figure 1 - An Example of a Managed Segment
+-------+ +-----+ +------+ +-----+ +--------+
|Router | | Host| | DSBM | | Host| | Router |
| R2 | | C | +------+ | B | | R3 |
+-------+ +-----+ / +-----+ +--------+
| | / | |
| | / | |
==============================================================
| |
| |
+------+ +-------+
| Host | | Router
| A | | R1 |
+------+ +-------+
Figure 1 shows an example of a managed segment in a L2 domain
interconnects a set of hosts and routers. For the purpose of
discussion, we ignore the actual physical topology of the L2
(assume it is a shared L2 segment and a single managed
represents the entire L2 domain). A single SBM device is
to be the DSBM for the managed segment. We will provide examples
operation of the DSBM over switched and shared segments later in
document
The basic DSBM-based admission control procedure works as follows
1. DSBM Initialization: As part of its initial configuration,
obtains information such as the limits on fraction of
resources that can be reserved on each managed segment under
control. For instance, bandwidth is one such resource.
though methods such as auto-negotiation of link speeds
knowledge of link topology allow discovery of link capacity,
configuration may be necessary to limit the fraction of
capacity that can be reserved on a link. Configuration is
to be static with the current L2/L3 devices. Future work
allow for dynamic discovery of this information. This
does not specify the configuration mechanism
Yavatkar, et al. Standards Track [Page 7]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
2. DSBM Client Initialization: For each interface attached, a
client determines whether a DSBM exists on the interface.
procedure for discovering and verifying the existence of the
for an attached segment is described in Appendix A. If the
itself is capable of serving as the DSBM on the segment, it
choose to participate in the election to become the DSBM. At
start, a DSBM client first verifies that a DSBM exists in its L
domain so that it can communicate with the DSBM for
control purposes
In the case of a full-duplex segment, an election may not
necessary as the SBM at each end will typically act as the
for outgoing traffic in each direction
3. DSBM-based Admission Control: To request reservation of
(e.g., LAN bandwidth in a L2 domain), DSBM clients (RSVP-
L3 devices such as hosts and routers) follow the following steps
a) When a DSBM client sends or forwards a RSVP PATH message
an interface attached to a managed segment, it sends the
message to the segment's DSBM instead of sending it to the
session destination address (as is done in conventional
processing). After processing (and possibly updating
ADSPEC), the DSBM will forward the PATH message toward
destination address. As part of its processing, the DSBM
and maintains a PATH state for the session and notes
previous L2/L3 hop that sent it the PATH message
Let us consider the managed segment in Figure 1. Assume that
sender to a RSVP session (session address specifies the
address of host A on the managed segment in Figure 1)
outside the L2 domain of the managed segment and sends a
message that arrives at router R1 which is on the path
host A
DSBM client on Router R1 forwards the PATH message from
sender to the DSBM. The DSBM processes the PATH message
forwards the PATH message towards the RSVP receiver (
message processing and forwarding rules are described
Section 5). In the process, the DSBM builds the PATH state
remembers the router R1 (its L2 and l3 addresses) as
previous hop for the session, puts its own L2 and L3
in the PHOP objects (see explanation later), and
inserts itself as an intermediate node between the sender (
R1 in Figure 1) and the receiver (host A) on the
segment
Yavatkar, et al. Standards Track [Page 8]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
b) When an application on host A wishes to make a reservation
the RSVP session, host A follows the standard RSVP
processing rules and sends a RSVP RESV message to the
hop L2/L3 address (the DSBMs address) obtained from the
object(s) in the previously received PATH message
c) The DSBM processes the RSVP RESV message based on the
available and returns an RESV_ERR message to the
(host A) if the request cannot be granted. If
resources are available and the reservation request is granted
the DSBM forwards the RESV message towards the PHOP(s) based
its local PATH state for the session. The DSBM
reservation requests for the same session as and when
using the rules similar to those used in the conventional
processing (except for an additional criterion described
Section 5.8).
d) If the L2 domain contains more than one managed segment,
requester (host A) and the forwarder (router R1) may
separated by more than one managed segment. In that case,
original PATH message would propagate through many DSBMs (
for each managed segment on the path from R1 to A) setting
PATH state at each DSBM. Therefore, the RESV message
propagate hop-by-hop in reverse through the intermediate
and eventually reach the original forwarder (router R1) on
L2 domain if admission control at all DSBMs succeeds
4.2.2. Enhancements to the conventional RSVP
(D)SBMs and DSBM clients implement minor additions to the
RSVP protocol. These are summarized in this section. A
description of the message processing and forwarding rules follows
section 5.
4.2.2.1 Sending PATH Messages to the DSBM on a Managed
Normal RSVP forwarding rules apply at a DSBM client when it is
forwarding an outgoing PATH message over a managed segment. However
outgoing PATH messages on a managed segment are sent to the DSBM
the corresponding managed segment (Section 5.2 describes how the
messages are sent to the DSBM on a managed segment).
4.2.2.2 The LAN_NHOP
In conventional RSVP processing over point-to-point links, RSVP
(hosts/routers) use RSVP_HOP object (NHOP and PHOP info) to
track of the next hop (downstream node in the path of data packets
a traffic flow) and the previous hop (upstream nodes with respect
Yavatkar, et al. Standards Track [Page 9]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
the data flow) nodes on the path between a sender and a receiver
Routers along the path of a PATH message forward the message
the destination address based on the L3 routing (packet forwarding
tables
For example, consider the L2 domain in Figure 1. Assume that both
sender (some host X) and the receiver (some host Y) in a RSVP
reside outside the L2 domain shown in the Figure, but PATH
from the sender to its receiver pass through the routers in the L
domain using it as a transit subnet. Assume that the PATH
from the sender X arrives at the router R1. R1 uses its local
information to decide which next hop router (either router R2
router R3) to use to forward the PATH message towards host Y
However, when the path traverses a managed L2 domain, we require
PATH and RESV messages to go through a DSBM for each managed segment
Such a L2 domain may span many managed segments (and DSBMs) and
typically, SBM protocol entities on L2 devices (such as a switch
will serve as the DSBMs for the managed segments in a
topology. When R1 forwards the PATH message to the DSBM (an L
device), the DSBM may not have the L3 routing information
to select the egress router (between R2 and R3) before forwarding
PATH message. To ensure correct operation and routing of
messages, we must provide additional forwarding information to DSBMs
For this purpose, we introduce new RSVP objects called LAN_
address objects that keep track of the next L3 hop as the
message traverses an L2 domain between two L3 entities (RSVP PHOP
NHOP nodes).
4.2.2.3 Including Both Layer-2 and Layer-3 Addresses in the LAN_
When a DSBM client (a host or a router acting as the originator of
PATH message) sends out a PATH message to the DSBM, it must
LAN_NHOP information in the message. In the case of a
destination, the LAN_NHOP address specifies the destination
(if the destination is local to its L2 domain) or the address of
next hop router towards the destination. In our example of an
session involving the sender X and receiver Y with L2 domain
Figure 1 acting as the transit subnet, R1 is the ingress node
receives the PATH message. R1 first determines that R2 is the
hop router (or the egress node in the L2 domain for the
address) and then inserts a LAN_NHOP object that specifies R2's
address. When a DSBM receives a PATH message, it can now look at
address in the LAN_NHOP object and forward the PATH message
the egress node after processing the PATH message. However,
expect the L2 devices (such as switches) to act as DSBMs on the
within the L2 domain and it may not be reasonable to expect
devices to have an ARP capability to determine the MAC address (
Yavatkar, et al. Standards Track [Page 10]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
call it L2ADDR for Layer 2 address) corresponding to the IP
in the LAN_NHOP object
Therefore, we require that the LAN_NHOP information (generated by
L3 device) include both the IP address (LAN_NHOP_L3 address) and
corresponding MAC address (LAN_NHOP_L2 address ) for the next L3
over the L2 domain. The LAN_NHOP_L3 address is used by SBM
entities on L3 devices to forward the PATH message towards
destination whereas the L2 address is used by the SBM
entities on L2 devices to determine how to forward the PATH
towards the L3 NHOP (egress point from the L2 domain). The
format of the LAN_NHOP information and relevant objects is
later in Appendix B
4.2.2.4 Similarities to Standard RSVP Message
- When a DSBM receives a RSVP PATH message, it processes the
message according to the PATH processing rules described in
RSVP specification. In particular, the DSBM retrieves the
address of the previous hop from the RSVP_HOP object in the
message and stores the PHOP address in its PATH state. It
forwards the PATH message with the PHOP (RSVP_HOP) object
to reflect its own IP address (RSVP_HOP_L3 address). Thus,
DSBM inserts itself as an intermediate hop in the chain of
in the path between two L3 nodes across the L2 domain
- The PATH state in a DSBM is used for forwarding subsequent
messages as per the standard RSVP message processing rules.
the DSBM receives a RESV message, it processes the message
forwards it to appropriate PHOP(s) based on its PATH state
- Because a DSBM inserts itself as a hop between two RSVP nodes
the path of a RSVP flow, all RSVP related messages (such as PATH
PATH_TEAR, RESV, RESV_CONF, RESV_TEAR, and RESV_ERR) now
through the DSBM. In particular, a PATH_TEAR message is
exactly through the intermediate DSBM(s) as its corresponding
message and the local PATH state is first cleaned up at
intermediate hop before the PATH_TEAR message gets forwarded
- So far, we have described how the PATH message propagates
the L2 domain establishing PATH state at each DSBM along
managed segments in the path. The layer 2 address (LAN_NHOP_L
address) in the LAN_NHOP object should be used by the L2
along the path to decide how to forward the PATH message
the next L3 hop. Such devices will apply the standard IEEE 802.1
forwarding rules (e.g., send it on a single port based on
filtering database, or flood it on all ports active in
spanning tree if the L2 address does not appear in the
Yavatkar, et al. Standards Track [Page 11]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
database) to the LAN_NHOP_L2 address as are applied normally
data packets destined to the address
4.2.2.5 Including Both Layer-2 and Layer-3 Addresses in the RSVP_
In the conventional RSVP message processing, the PATH
established along the nodes on a path is used to route the
message from a receiver to a sender in an RSVP session. As
intermediate node builds the path state, it remembers the
hop (stores the PHOP IP address available in the RSVP_HOP object
an incoming message) that sent it the PATH message and, when the
message arrives, the intermediate node simply uses the stored
address to forward the RESV after processing it successfully
In our case, we expect the SBM entities residing at L2 devices to
as DSBMs (and, therefore, intermediate RSVP hops in an L2 domain
along the path between a sender (PHOP) and receiver (NHOP). Thus
when a RESV message arrives at a DSBM, it must use the stored PHOP
address to forward the RESV message to its previous hop. However,
may not be reasonable to expect the L2 devices to have an ARP
or the ARP capability to map the PHOP IP address to its
L2 address before forwarding the RESV message
To obviate the need for such address mapping at L2 devices, we use
RSVP_HOP_L2 object in the PATH message. The RSVP_HOP_L2
includes the Layer 2 address (L2ADDR) of the previous hop
complements the L3 address information included in the RSVP_
object (RSVP_HOP_L3 address).
When a L3 device constructs and forwards a PATH message over
managed segment, it includes its IP address (IP address of
interface over which PATH is sent) in the RSVP_HOP object and adds
RSVP_HOP_L2 object that includes the corresponding L2 address for
interface. When a device in the L2 domain receives such a
message, it remembers the addresses in the RSVP_HOP and RSVP_HOP_L
objects in its PATH state and then overwrites the RSVP_HOP
RSVP_HOP_L2 objects with its own addresses before forwarding the
message over a managed segment
The exact format of RSVP_HOP_L2 object is specified in Appendix B
4.2.2.6 Loop
When an RSVP session address is a multicast address and a SBM, DSBM
and DSBM clients share the same L2 segment (a shared segment), it
possible for a SBM or a DSBM client to receive one or more copies
a PATH message that it forwarded earlier when a DSBM on the same
Yavatkar, et al. Standards Track [Page 12]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
forwards it (See Section 5.7 for an example of such a case).
facilitate detection of such loops, we use a new RSVP object
the LAN_LOOPBACK object. DSBM clients or SBMs (but not the
reflecting a PATH message onto the interface over which it
earlier) must overwrite (or add if the PATH message does NOT
include a LAN_LOOPBACK object) the LAN_LOOPBACK object in the
message with their own unicast IP address
Now, a SBM or a DSBM client can easily detect and discard
duplicates by checking the contents of the LAN_LOOPBACK object (
duplicate PATH message will list a device's own interface address
the LAN_LOOPBACK object). Appendix B specifies the exact format
the LAN_LOOPBACK object
4.2.2.7 802.1p, User Priority and
The model proposed by the Integrated Services working group
isolation of traffic flows from each other during their
across a network. The motivation for traffic flow separation is
provide Integrated Services flows protection from misbehaving
and other best-effort traffic that share the same path. The
IEEE 802.3/Ethernet networks do not provide any notion of
classes to discriminate among different flows that request
services. However, IEEE 802.1p defines a way for switches
differentiate among several "user_priority" values encoded in
representing different traffic classes (see [IEEE802Q, IEEE8021p]
further details). The user_priority values can be encoded either
native LAN packets (e.g., in IEEE 802.5's FC octet) or by using
encapsulation above the MAC layer (e.g., in the case of Ethernet,
user_priority value assigned to each packet will be carried in
frame header using the new, extended frame format defined by
802.1Q [IEEE8021Q]. IEEE, however, makes no recommendations about
a sender or network should use the user_priority values.
accompanying document makes recommendations on the usage of
user_priority values (see [RFC-MAP] for details).
Under the Integrated Services model, L3 (or higher) entities
transmit traffic flows onto a L2 segment should perform per-
policing to ensure that the flows do not exceed their
specification as specified during admission control. In addition, L
devices may label the frames in such flows with a user_priority
to identify their service class
For the purpose of this discussion, we will refer to
user_priority value carried in the extended frame header as
"traffic class" of a packet. Under the ISSLL model, the L3 entities
that send traffic and that use the SBM protocol, may select
appropriate traffic class of outgoing packets [RFC-MAP].
Yavatkar, et al. Standards Track [Page 13]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
selection may be overridden by DSBM devices, in the following manner
once a sender sends a PATH message, downstream DSBMs will insert
new traffic class object (TCLASS object) in the PATH message
travels to the next L3 device (L3 NHOP for the PATH message). To
extent, the TCLASS object contents are treated like the ADSPEC
in the RSVP PATH messages. The L3 device that receives the
message must remove and store the TCLASS object as part of its
state for the session. Later, when the same L3 device needs
forward a RSVP RESV message towards the original sender, it
include the TCLASS object in the RESV message. When the RESV
arrives at the original sender, the sender must use the user_
value from the TCLASS object to override its selection for
traffic class marked in outgoing packets
The format of the TCLASS object is specified in Appendix B.
that TCLASS and other SBM-specific objects are carried in a
message in addition to all the other, normal RSVP objects per
2205.
4.2.2.8 Processing the TCLASS
In summary, use of TCLASS objects requires following additions to
conventional RSVP message processing at DSBMs, SBMs, and
clients
* When a DSBM receives a PATH message over a managed segment and
PATH message does not include a TCLASS object, the DSBM MAY add
TCLASS object to the PATH message before forwarding it. The
determines the appropriate user_priority value for the
object. A mechanism for selecting the appropriate user_
value is described in an accompanying document [RFC-MAP].
* When SBM or DSBM receives a PATH message with a TCLASS object
a managed segment in a L2 domain and needs to forward it over
managed segment in the same L2 domain, it will store it in
path state and typically forward the message without changing
contents of the TCLASS object. However, if the DSBM/SBM
support the service class represented by the user_priority
specified by the TCLASS object in the PATH message, it may
the priority value in the TCLASS to a semantically "lower"
value to reflect its capability and store the changed TCLASS
in its path state
Yavatkar, et al. Standards Track [Page 14]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
[NOTE: An accompanying document defines the int-serv mappings
IEEE 802 networks [RFC-MAP] provides a precise definition
user_priority values and describes how the user_priority
are compared to determine "lower" of the two values or
"lowest" among all the user_priority values.]
* When a DSBM receives a RESV message with a TCLASS object, it
use the traffic class information (in addition to the
flowspec information in the RSVP message) for its own
control for the managed segment
Note that this document does not specify the actual algorithm
policy used for admission control. At one extreme, a DSBM may
per-flow reservation request as specified by the flowspec for
fine grain admission control. At the other extreme, a DSBM
only consider the traffic class information for a very coarse
grain admission control based on some static allocation of
capacity for each traffic class. Any combination of the
represented by these two extremes may also be used
* When a DSBM (at an L2 or L3) device receives a RESV
without a TCLASS object and it needs to forward the RESV
over a managed segment within the same L2 domain, it should
check its path state and check whether it has stored a
value. If so, it should include the TCLASS object in the
RESV message after performing its own admission control. If
TCLASS value is stored, it must forward the RESV message
inserting a TCLASS object
* When a DSBM client (residing at an L3 device such as a host or
edge router) receives the TCLASS object in a PATH message that
accepts over an interface, it should store the TCLASS object
part of its PATH state for the interface. Later, when the
forwards a RESV message for the same session on the interface,
client must include the TCLASS object (unchanged from what
received in the previous PATH message) in the RESV message
forwards over the interface
* When a DSBM client receives a TCLASS object in an incoming
message over a managed segment and local admission
succeeds for the session for the outgoing interface over
managed segment, the client must pass the user_priority value
the TCLASS object to its local packet classifier. This will
that the data packets in the admitted RSVP flow that
subsequently forwarded over the outgoing interface will
the appropriate value encoded in their frame header
Yavatkar, et al. Standards Track [Page 15]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
* When an L3 device receives a PATH or RESV message over a
segment in one L2 domain and it needs to forward the PATH/
message over an interface outside that domain, the L3 device
remove the TCLASS object (along with LAN_NHOP, RSVP_HOP_L2,
LAN_LOOPBACK objects in the case of the PATH message)
forwarding the PATH/RESV message. If the outgoing interface is
a separate L2 domain, these objects may be regenerated
to the processing rules applicable to that interface
5. Detailed Message Processing
5.1. Additional Notes on
* An L2 device may have several interfaces with attached
that are part of the same L2 domain. A switch in a L2 domain is
example of such a device. A device which has several
may contain a SBM protocol entity that acts in
capacities on each interface. For example, a SBM protocol
could act as a SBM on interface A, and act as a DSBM on
B
* A SBM protocol entity on a layer 3 device can be a DSBM client
and SBM, a DSBM, or none of the above (SBM transparent). Non
transparent L3 devices can implement any combination of
roles simultaneously. DSBM clients always reside at L3 devices
* A SBM protocol entity residing at a layer 2 device can be a SBM,
DSBM or none of the above (SBM transparent). A layer 2 device
never host a DSBM client
5.2. Use Of Reserved IP Multicast
As stated earlier, we require that the DSBM clients forward the
PATH messages to their DSBMs in a L2 domain before they reach
next L3 hop in the path. RSVP PATH messages are addressed,
to RFC-2205, to their destination address (which can be either an
unicast or multicast address). When a L2 device hosts a DSBM,
simple-to-implement mechanism must be provided for the device
capture an incoming PATH message and hand it over to the local
agent without requiring the L2 device to snoop for L3 RSVP messages
In addition, DSBM clients need to know how to address SBM messages
the DSBM. For the ease of operation and to allow dynamic DSBM-
binding, it should be possible to easily detect and address
existing DSBM on a managed segment
Yavatkar, et al. Standards Track [Page 16]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
To facilitate dynamic DSBM-client binding as well as to enable
detection and capture of PATH messages at L2 devices, we require
a DSBM be addressed using a logical address rather than a
address. We make use of reserved IP multicast address(es) for
purpose of communication with a DSBM. In particular, we require
when a DSBM client or a SBM forwards a PATH message over a
segment, it is addressed to a reserved IP multicast address. Thus,
DSBM on a L2 device needs to be configured in a way to make it
to intercept the PATH message and forward it to the local
protocol entity. For example, this may involve simply adding a
entry in the device's filtering database (FDB) for the
MAC multicast address to ensure the PATH messages get intercepted
are not forwarded further without the DSBM intervention
Similarly, a DSBM always sends the PATH messages over a
segment using a reserved IP multicast address and, thus, the SBMs
DSBM clients on the managed segments must simply be configured
intercept messages addressed to the reserved multicast address on
appropriate interfaces to easily receive PATH messages
RSVP RESV messages continue to be unicast to the previous hop
stored as part of the PATH state at each intermediate hop
We define use of two reserved IP multicast addresses. We call
the "AllSBM Address" and the "DSBMLogicalAddress". These are
from the range of local multicast addresses, such that
* They are not passed through layer 3 devices
* They are passed transparently through layer 2 devices which
SBM transparent
* They are configured in the permanent database of layer 2
which host SBMs or DSBMs, such that they are directed to the
management entity in these devices. This obviates the need
these devices to explicitly snoop for SBM related control packets
* The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress)
224.0.0.17 (AllSBMAddress).
These addresses are used as described in the following table
Type DSBMLogicaladdress
DSBM * Sends PATH messages * Monitors this address to
Client to this address the presence of a
Yavatkar, et al. Standards Track [Page 17]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
* Monitors this address
receive PATH
forwarded by the
SBM * Sends PATH messages * Monitors and sends on
to this address address to participate
election of the
* Monitors this address
receive PATH
forwarded by the
DSBM * Monitors this address * Monitors and sends on
for PATH messages to participate in
directed to it of the
* Sends PATH messages to
The L2 or MAC addresses corresponding to IP multicast addresses
computed algorithmically using a reserved L2 address block (the
order 24-bits are 00:00:5e). The Assigned Numbers RFC [RFC-1700]
gives additional details
5.3. Layer 3 to Layer 2 Address
As stated earlier, DSBMs or DSBM clients residing at a L3 device
include a LAN_NHOP_L2 address in the LAN_NHOP information so that L
devices along the path of a PATH message do not need to
determine the mapping between the LAN_NHOP_L3 address in the LAN_
object and its corresponding L2 address (for example, using ARP).
For the purpose of such mapping at L3 devices, we assume a
function called "map_address" that performs the necessary mapping
L2ADDR object = map_addr(L3Addr
We do not specify how the function is implemented; the
may simply involve access to the local ARP cache entry or may
performing an ARP function. The function returns a L2ADDR
that need not be interpreted by an L3 device and can be treated as
opaque object. The format of the L2ADDR object is specified
Appendix B
5.4. Raw vs. UDP
We assume that the DSBMs, DSBM clients, and SBMs use only raw IP
encapsulating RSVP messages that are forwarded onto a L2 domain
Thus, when a SBM protocol entity on a L3 device forwards a
message onto a L2 segment, it will only use RAW IP encapsulation
Yavatkar, et al. Standards Track [Page 18]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
5.5. The Forwarding
The message processing and forwarding rules will be described in
context of the sample network illustrated in Figure 2.
Figure 2 - A sample network or L2 domain consisting of switched
shared L2
..........
.
+------+ . +------+ seg A +------+ seg C +------+ seg D +------+
| H1 |_______| R1 |_________| S1 |_________| S2 |_______| H2 |
| | . | | | | | | | |
+------+ . +------+ +------+ +------+ +------+
. | /
1.0.0.0 . | /
. |___ /
. seg B | / seg
.......... | /
2.0.0.0 | /
+-----------+
| S3 |
| |
+-----------+
|
|
|
|
seg F | .................
------------------------------ .
| | | .
+------+ +------+ +------+ . +------+
| H3 | | H4 | | R2 |____________| H5 |
| | | | | | . | |
+------+ +------+ +------+ . +------+
.
. 3.0.0.0
.................
Figure 2 illustrates a sample network topology consisting of three
subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) interconnected using
routers. The subnet 2.0.0.0 is an example of a L2 domain
of switches, hosts, and routers interconnected using
segments and a shared L2 segment. The sample network contains
following devices
Yavatkar, et al. Standards Track [Page 19]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
Device Type SBM
H1, H5 Host (layer 3) SBM
H2-H4 Host (layer 3) DSBM
R1 Router (layer 3)
R2 Router (layer 3) DSBM for segment
S1 Switch (layer 2) DSBM for segments A,
S2 Switch (layer 2) DSBM for segments C, D,
S3 Switch (layer 2)
The following paragraphs describe the rules, which each of
devices should use to forward PATH messages (rules apply to PATH_
messages as well). They are described in the context of the
network illustrated above. While the examples do not address
scenario, they do address most of the interesting scenarios
Exceptions can be discussed separately
The forwarding rules are applied to received PATH messages (
and switches) or originating PATH messages (hosts), as follows
1. Determine the interface(s) on which to forward the PATH
using standard forwarding rules
* If there is a LAN_LOOPBACK object in the PATH message, and
carries the address of this device, silently discard
message. (See the section below on "Additional notes
forwarding the PATH message onto a managed segment).
* Layer 3 devices use the RSVP session address and perform
routing lookup to determine the forwarding interface(s).
* Layer 2 devices use the LAN_NHOP_L2 address in the LAN_
information and MAC forwarding tables to determine
forwarding interface(s). (See the section below on "
notes on forwarding the PATH message onto a managed segment")
2. For each forwarding interface
* If the device is a layer 3 device, determine whether
interface is on a managed segment managed by a DSBM, based
the presence or absence of I_AM_DSBM messages. If the
is not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP
LAN_LOOPBACK, and TCLASS objects (if present), and forward
the unicast or multicast destination
Yavatkar, et al. Standards Track [Page 20]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
(Note that the RSVP Class Numbers for these new objects
chosen so that if an RSVP message includes these objects,
nodes that are RSVP-aware, but do not participate in the
protocol, will ignore and silently discard such objects.)
* If the device is a layer 2 device or it is a layer 3
*and* the interface is on a managed segment, proceed to
#3.
3. Forward the PATH message onto the managed segment
* If the device is a layer 3 device, insert LAN_NHOP
objects, a LAN_LOOPBACK, and a RSVP_HOP_L2 object into the
message. The LAN_NHOP objects carry the LAN_NHOP_L3
LAN_NHOP_L2 addresses of the next layer 3 hop. The RSVP_HOP_L
object carries the device's own L2 address, and
LAN_LOOPBACK object contains the IP address of the
interface
An L3 device should use the map_addr() function
earlier to obtain an L2 address corresponding to an IP address
* If the device hosts the DSBM for the segment to which
forwarding interface is attached, do the following
- Retrieve the PHOP information from the standard RSVP
object in the PATH message, and store it. This will be
to route RESV messages back through the L2 network. If
PATH message arrived over a managed segment, it will
contain the RSVP_HOP_L2 object; then retrieve and store
the previous hop's L2 address in the PATH state
- Copy the IP address of the forwarding interface (layer 2
devices must also have IP addresses) into the standard
HOP object and the L2 address of the forwarding
into the RSVP_HOP_L2 object
- If the PATH message received does not contain the
object, insert a TCLASS object. The user_priority
inserted in the TCLASS object is based on service
internal to the device that are configured according to
guidelines listed in [RFC-MAP]. If the message
contains the TCLASS object, the user_priority value may
changed based again on the service mappings internal to
device
Yavatkar, et al. Standards Track [Page 21]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
* If the device is a layer 3 device and hosts a SBM for
segment to which the forwarding interface is attached, it *
required* to retrieve and store the PHOP info
If the device is a layer 2 device and hosts a SBM for
segment to which the forwarding interface is attached, it
*not* required to retrieve and store the PHOP info. If it
not do so, the SBM must leave the standard RSVP HOP object
the RSVP_HOP_L2 objects in the PATH message intact and it
not receive RESV messages
If the SBM on a L2 device chooses to overwrite the RSVP HOP
RSVP_HOP_L2 objects with the IP and L2 addresses of
forwarding interface, it will receive RESV messages. In
case, it must store the PHOP address info received in
standard RSVP_HOP field and RSVP_HOP_L2 objects of the
PATH message
In both the cases mentioned above (L2 or L3 devices), the
must forward the TCLASS object in the received PATH
unchanged
* Copy the IP address of the forwarding interface into
LAN_LOOPBACK object, unless the SBM protocol entity is a
reflecting a PATH message back onto the incident interface
(See the section below on "Additional notes on forwarding
PATH message onto a managed segment").
* If the SBM protocol entity is the DSBM for the segment to
the forwarding interface is attached, it must send the
message to the AllSBMAddress
* If the SBM protocol entity is a SBM or a DSBM Client on
segment to which the forwarding interface is attached, it
send the PATH message to the DSBMLogicalAddress
5.5.1. Additional notes on forwarding a PATH message onto a
Rule #1 states that normal IEEE 802.1D forwarding rules should
used to determine the interfaces on which the PATH message should
forwarded. In the case of data packets, standard forwarding rules
a L2 device dictate that the packet should not be forwarded on
interface from which it was received. However, in the case of a
that receives a PATH message over a managed segment, the
exception applies
Yavatkar, et al. Standards Track [Page 22]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
E1. If the address in the LAN_NHOP object is a unicast address
consult the filtering database (FDB) to determine whether
destination address is listed on the same interface over
the message was received. If yes, follow the rule below
"reflecting a PATH message back onto an interface"
below; otherwise, proceed with the rest of the
processing as usual
E2. If there are members of the multicast group address (
by the addresses in the LAN_NHOP object), on the segment
which the message was received, the message should
forwarded back onto the interface from which it was
and follow the rule on "reflecting a PATH message back onto
interface" described below
*** Reflecting a PATH message back onto an interface ***
Under the circumstances described above, when a DSBM reflects
PATH message back onto an interface over which it was received,
must address it using the AllSBMAddress
Since it is possible for a DSBM to reflect a PATH message
onto the interface from which it was received, precautions must
taken to avoid looping these messages indefinitely.
LAN_LOOPBACK object addresses this issue. All SBM
entities (except DSBMs reflecting a PATH message) overwrite
LAN_LOOPBACK object in the PATH message with the IP address of
outgoing interface. DSBMs which are reflecting a PATH message
leave the LAN_LOOPBACK object unchanged. Thus, SBM
entities will always be able to recognize a reflected
message by the presence of their own address in the LAN_
object. These messages should be silently discarded
5.6. Applying the Rules -- Unicast
Let's see how the rules are applied in the general
illustrated previously (see Figure 2).
Assume that H1 is sending a PATH for a unicast session for which H
is the receiver. The following PATH message is composed by H1:
RSVP
RSVP session IP address IP address of H5 (3.0.0.35)
Sender Template IP address of H1 (1.0.0.11)
PHOP IP address of H1 (1.0.0.11)
RSVP_HOP_L2 n/a (H1 is not sending onto a
segment
LAN_NHOP n/a (H1 is not sending onto a
Yavatkar, et al. Standards Track [Page 23]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
segment
LAN_LOOPBACK n/a (H1 is not sending onto a
segment
IP
Source address IP address of H1 (1.0.0.11)
Destn address IP addr of H5 (3.0.0.35, assuming raw
& router alert
MAC
Destn address The L2 addr corresponding to R1 (
by map_addr() and routing tables at H1)
Since H1 is not sending onto a managed segment, the PATH message
composed and forwarded according to standard RSVP processing rules
Upon receipt of the PATH message, R1 composes and forwards a
message as follows
RSVP
RSVP session IP address IP address of H
Sender Template IP address of H
PHOP IP address of R1 (2.0.0.1)
(seed the return path for RESV messages
RSVP_HOP_L2 L2 address of R
LAN_NHOP LAN_NHOP_L3 (2.0.0.2)
LAN_NHOP_L2 address of R2 (L2ADDR
(this is the next layer 3 hop
LAN_LOOPBACK IP address of R1 (2.0.0.1)
IP
Source address IP address of H
Destn address DSBMLogical IP address (224.0.0.16)
MAC
Destn address DSBMLogical MAC
* R1 does a routing lookup on the RSVP session address,
determine the IP address of the next layer 3 hop, R2.
* It determines that R2 is accessible via seg A and that seg
is managed by a DSBM, S1.
* Therefore, it concludes that it is sending onto a
segment, and composes LAN_NHOP objects to carry the layer 3
and layer 2 next hop addresses. To compose the LAN_
L2ADDR object, it invokes the L3 to L2 address mapping
Yavatkar, et al. Standards Track [Page 24]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
("map_address") to find out the MAC address for the next
L3 device, and then inserts a LAN_NHOP_L2ADDR object (
carries the MAC address) in the message
* Since R1 is not the DSBM for seg A, it sends the PATH
to the DSBMLogicalAddress
Upon receipt of the PATH message, S1 composes and forwards a
message as follows
RSVP
RSVP session IP address IP address of H
Sender Template IP address of H
PHOP IP addr of S1 (seed the return path for
messages
RSVP_HOP_L2 L2 address of S
LAN_NHOP LAN_NHOP_L3 (IP) and LAN_NHOP_L
address of R
(layer 2 devices do not modify the LAN_NHOP
LAN_LOOPBACK IP addr of S
IP
Source address IP address of H
Destn address AllSBMIPaddr (224.0.0.17, since S1 is
DSBM for seg B).
MAC
Destn address All SBM MAC address (since S1 is the
for seg B).
* S1 looks at the LAN_NHOP address information to determine
L2 address towards which it should forward the PATH message
* From the bridge forwarding tables, it determines that the L
address is reachable via seg B
* S1 inserts the RSVP_HOP_L2 object and overwrites the RSVP
object (PHOP) with its own addresses
* Since S1 is the DSBM for seg B, it addresses the PATH
to the AllSBMAddress
Upon receipt of the PATH message, S3 composes and forwards a
message as follows
Yavatkar, et al. Standards Track [Page 25]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
RSVP
RSVP session IP addr IP address of H
Sender Template IP address of H
PHOP IP addr of S3 (seed the
path for RESV messages
RSVP_HOP_L2 L2 address of S
LAN_NHOP LAN_NHOP_L3 (IP)
LAN_NHOP_L2 (MAC) address of R
(L2 devices don't modify LAN_NHOP
LAN_LOOPBACK IP address of S
IP
Source address IP address of H
Destn address DSBMLogical IP addr (since S3
not the DSBM for seg F
MAC
Destn address DSBMLogical MAC
* S3 looks at the LAN_NHOP address information to determine
L2 address towards which it should forward the PATH message
* From the bridge forwarding tables, it determines that the L
address is reachable via segment F
* It has discovered that R2 is the DSBM for segment F.
therefore sends the PATH message to the DSBMLogicalAddress
* Note that S3 may or may not choose to overwrite the
objects with its own IP and L2 addresses. If it does so,
will receive RESV messages. In this case, it must also
the PHOP info received in the incident PATH message so
it is able to forward the RESV messages on the correct path
Upon receipt of the PATH message, R2 composes and forwards a
message as follows
RSVP
RSVP session IP addr IP address of H
Sender Template IP address of H
PHOP IP addr of R2 (seed the return path for
messages
RSVP_HOP_L2 Removed by R2 (R2 is not sending onto
managed segment
LAN_NHOP Removed by R2 (R2 is not sending onto
managed segment
Yavatkar, et al. Standards Track [Page 26]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
IP
Source address IP address of H
Destn address IP address of H5, the RSVP session
MAC
Destn address L2 addr corresponding to H5, the
layer 3
* R2 does a routing lookup on the RSVP session address,
determine the IP address of the next layer 3 hop, H5.
* It determines that H5 is accessible via a segment for
there is no DSBM (not a managed segment).
* Therefore, it removes the LAN_NHOP and RSVP_HOP_L2
and places the RSVP session address in the
address of the IP header. It places the L2 address of
next layer 3 hop, into the destination address of the
header and forwards the PATH message to H5.
5.7. Applying the Rules - Multicast
The rules described above also apply to multicast (m/c) sessions
For the purpose of this discussion, it is assumed that layer 2
devices track multicast group membership on each port individually
Layer 2 devices which do not do so, will merely generate
multicast traffic. This is the case for L2 devices which do
implement multicast filtering or GARP/GMRP capability
Assume that H1 is sending a PATH for an m/c session for which H3
H5 are the receivers. The rules are applied as they are in
unicast case described previously, until the PATH message reaches R2,
with the following exception. The RSVP session address and
LAN_NHOP carry the destination m/c addresses rather than the
addresses carried in the unicast example
Now let's look at the processing applied by R2 upon receipt of
PATH message. Recall that R2 is the DSBM for segment F. Therefore, S
will have forwarded its PATH message to the DSBMLogicalAddress, to
picked up by R2. The PATH message will not have been seen by H3 (
of the m/c receivers), since it monitors only the AllSBMAddress,
the DSBMLogicalAddress for incoming PATH messages. We rely on R2
reflect the PATH message back onto seg f, and to forward it to H5. R
forwards the following PATH message onto seg f
RSVP
RSVP session addr m/c session
Sender Template IP address of H
Yavatkar, et al. Standards Track [Page 27]
RFC 2814 SBM (Subnet Bandwidth Manager) May 2000
PHOP IP addr of R2 (seed the return path
RESV messages
RSVP_HOP_L2 L2 addr of R
LAN_NHOP m/c session address and corresponding L2
LAN_LOOPBACK IP addr of S3 (DSBMs reflecting a
message don't modify this object
IP
Source address IP address of H
Destn address AllSBMIP address (since R2 is the DSBM for seg F
