RFC 2814
SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks
Pages: 60
Proposed Standard
Proposed Standard
Part 2 of 3 – Pages 16 to 35
5. Detailed Message Processing Rules
5.1. Additional Notes on Terminology
* An L2 device may have several interfaces with attached segments that are part of the same L2 domain. A switch in a L2 domain is an example of such a device. A device which has several interfaces may contain a SBM protocol entity that acts in different capacities on each interface. For example, a SBM protocol entity could act as a SBM on interface A, and act as a DSBM on interface 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 these roles simultaneously. DSBM clients always reside at L3 devices. * A SBM protocol entity residing at a layer 2 device can be a SBM, a DSBM or none of the above (SBM transparent). A layer 2 device will never host a DSBM client.5.2. Use Of Reserved IP Multicast Addresses
As stated earlier, we require that the DSBM clients forward the RSVP PATH messages to their DSBMs in a L2 domain before they reach the next L3 hop in the path. RSVP PATH messages are addressed, according to RFC-2205, to their destination address (which can be either an IP unicast or multicast address). When a L2 device hosts a DSBM, a simple-to-implement mechanism must be provided for the device to capture an incoming PATH message and hand it over to the local DSBM agent without requiring the L2 device to snoop for L3 RSVP messages. In addition, DSBM clients need to know how to address SBM messages to the DSBM. For the ease of operation and to allow dynamic DSBM-client binding, it should be possible to easily detect and address the existing DSBM on a managed segment.
To facilitate dynamic DSBM-client binding as well as to enable easy
detection and capture of PATH messages at L2 devices, we require that
a DSBM be addressed using a logical address rather than a physical
address. We make use of reserved IP multicast address(es) for the
purpose of communication with a DSBM. In particular, we require that
when a DSBM client or a SBM forwards a PATH message over a managed
segment, it is addressed to a reserved IP multicast address. Thus, a
DSBM on a L2 device needs to be configured in a way to make it easy
to intercept the PATH message and forward it to the local SBM
protocol entity. For example, this may involve simply adding a static
entry in the device's filtering database (FDB) for the corresponding
MAC multicast address to ensure the PATH messages get intercepted and
are not forwarded further without the DSBM intervention.
Similarly, a DSBM always sends the PATH messages over a managed
segment using a reserved IP multicast address and, thus, the SBMs or
DSBM clients on the managed segments must simply be configured to
intercept messages addressed to the reserved multicast address on the
appropriate interfaces to easily receive PATH messages.
RSVP RESV messages continue to be unicast to the previous hop address
stored as part of the PATH state at each intermediate hop.
We define use of two reserved IP multicast addresses. We call these
the "AllSBM Address" and the "DSBMLogicalAddress". These are chosen
from the range of local multicast addresses, such that:
* They are not passed through layer 3 devices.
* They are passed transparently through layer 2 devices which are
SBM transparent.
* They are configured in the permanent database of layer 2 devices
which host SBMs or DSBMs, such that they are directed to the SBM
management entity in these devices. This obviates the need for
these devices to explicitly snoop for SBM related control packets.
* The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress) and
224.0.0.17 (AllSBMAddress).
These addresses are used as described in the following table:
Type DSBMLogicaladdress AllSBMAddress
DSBM * Sends PATH messages * Monitors this address to detect
Client to this address the presence of a DSBM
* Monitors this address to
receive PATH messages
forwarded by the DSBM
SBM * Sends PATH messages * Monitors and sends on this
to this address address to participate in
election of the DSBM
* Monitors this address to
receive PATH messages
forwarded by the DSBM
DSBM * Monitors this address * Monitors and sends on this
for PATH messages to participate in election
directed to it of the DSBM
* Sends PATH messages to this
address
The L2 or MAC addresses corresponding to IP multicast addresses are
computed algorithmically using a reserved L2 address block (the high
order 24-bits are 00:00:5e). The Assigned Numbers RFC [RFC-1700]
gives additional details.
5.3. Layer 3 to Layer 2 Address Mapping
As stated earlier, DSBMs or DSBM clients residing at a L3 device must
include a LAN_NHOP_L2 address in the LAN_NHOP information so that L2
devices along the path of a PATH message do not need to separately
determine the mapping between the LAN_NHOP_L3 address in the LAN_NHOP
object and its corresponding L2 address (for example, using ARP).
For the purpose of such mapping at L3 devices, we assume a mapping
function called "map_address" that performs the necessary mapping:
L2ADDR object = map_addr(L3Addr)
We do not specify how the function is implemented; the implementation
may simply involve access to the local ARP cache entry or may require
performing an ARP function. The function returns a L2ADDR object
that need not be interpreted by an L3 device and can be treated as an
opaque object. The format of the L2ADDR object is specified in
Appendix B.
5.4. Raw vs. UDP Encapsulation
We assume that the DSBMs, DSBM clients, and SBMs use only raw IP for
encapsulating RSVP messages that are forwarded onto a L2 domain.
Thus, when a SBM protocol entity on a L3 device forwards a RSVP
message onto a L2 segment, it will only use RAW IP encapsulation.
5.5. The Forwarding Rules
The message processing and forwarding rules will be described in the context of the sample network illustrated in Figure 2. Figure 2 - A sample network or L2 domain consisting of switched and shared L2 segments .......... . +------+ . +------+ seg A +------+ seg C +------+ seg D +------+ | H1 |_______| R1 |_________| S1 |_________| S2 |_______| H2 | | | . | | | | | | | | +------+ . +------+ +------+ +------+ +------+ . | / 1.0.0.0 . | / . |___ / . seg B | / seg E .......... | / 2.0.0.0 | / +-----------+ | S3 | | | +-----------+ | | | | seg F | ................. ------------------------------ . | | | . +------+ +------+ +------+ . +------+ | H3 | | H4 | | R2 |____________| H5 | | | | | | | . | | +------+ +------+ +------+ . +------+ . . 3.0.0.0 ................. Figure 2 illustrates a sample network topology consisting of three IP subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) interconnected using two routers. The subnet 2.0.0.0 is an example of a L2 domain consisting of switches, hosts, and routers interconnected using switched segments and a shared L2 segment. The sample network contains the following devices:
Device Type SBM Type
H1, H5 Host (layer 3) SBM Transparent
H2-H4 Host (layer 3) DSBM Client
R1 Router (layer 3) SBM
R2 Router (layer 3) DSBM for segment F
S1 Switch (layer 2) DSBM for segments A, B
S2 Switch (layer 2) DSBM for segments C, D, E
S3 Switch (layer 2) SBM
The following paragraphs describe the rules, which each of these
devices should use to forward PATH messages (rules apply to PATH_TEAR
messages as well). They are described in the context of the general
network illustrated above. While the examples do not address every
scenario, they do address most of the interesting scenarios.
Exceptions can be discussed separately.
The forwarding rules are applied to received PATH messages (routers
and switches) or originating PATH messages (hosts), as follows:
1. Determine the interface(s) on which to forward the PATH message
using standard forwarding rules:
* If there is a LAN_LOOPBACK object in the PATH message, and it
carries the address of this device, silently discard the
message. (See the section below on "Additional notes on
forwarding the PATH message onto a managed segment).
* Layer 3 devices use the RSVP session address and perform a
routing lookup to determine the forwarding interface(s).
* Layer 2 devices use the LAN_NHOP_L2 address in the LAN_NHOP
information and MAC forwarding tables to determine the
forwarding interface(s). (See the section below on "Additional
notes on forwarding the PATH message onto a managed segment")
2. For each forwarding interface:
* If the device is a layer 3 device, determine whether the
interface is on a managed segment managed by a DSBM, based on
the presence or absence of I_AM_DSBM messages. If the interface
is not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP,
LAN_LOOPBACK, and TCLASS objects (if present), and forward to
the unicast or multicast destination.
(Note that the RSVP Class Numbers for these new objects are
chosen so that if an RSVP message includes these objects, the
nodes that are RSVP-aware, but do not participate in the SBM
protocol, will ignore and silently discard such objects.)
* If the device is a layer 2 device or it is a layer 3 device
*and* the interface is on a managed segment, proceed to rule
#3.
3. Forward the PATH message onto the managed segment:
* If the device is a layer 3 device, insert LAN_NHOP address
objects, a LAN_LOOPBACK, and a RSVP_HOP_L2 object into the PATH
message. The LAN_NHOP objects carry the LAN_NHOP_L3 and
LAN_NHOP_L2 addresses of the next layer 3 hop. The RSVP_HOP_L2
object carries the device's own L2 address, and the
LAN_LOOPBACK object contains the IP address of the outgoing
interface.
An L3 device should use the map_addr() function described
earlier to obtain an L2 address corresponding to an IP address.
* If the device hosts the DSBM for the segment to which the
forwarding interface is attached, do the following:
- Retrieve the PHOP information from the standard RSVP HOP
object in the PATH message, and store it. This will be used
to route RESV messages back through the L2 network. If the
PATH message arrived over a managed segment, it will also
contain the RSVP_HOP_L2 object; then retrieve and store also
the previous hop's L2 address in the PATH state.
- Copy the IP address of the forwarding interface (layer 2
devices must also have IP addresses) into the standard RSVP
HOP object and the L2 address of the forwarding interface
into the RSVP_HOP_L2 object.
- If the PATH message received does not contain the TCLASS
object, insert a TCLASS object. The user_priority value
inserted in the TCLASS object is based on service mappings
internal to the device that are configured according to the
guidelines listed in [RFC-MAP]. If the message already
contains the TCLASS object, the user_priority value may be
changed based again on the service mappings internal to the
device.
* If the device is a layer 3 device and hosts a SBM for the
segment to which the forwarding interface is attached, it *is
required* to retrieve and store the PHOP info.
If the device is a layer 2 device and hosts a SBM for the
segment to which the forwarding interface is attached, it is
*not* required to retrieve and store the PHOP info. If it does
not do so, the SBM must leave the standard RSVP HOP object and
the RSVP_HOP_L2 objects in the PATH message intact and it will
not receive RESV messages.
If the SBM on a L2 device chooses to overwrite the RSVP HOP and
RSVP_HOP_L2 objects with the IP and L2 addresses of its
forwarding interface, it will receive RESV messages. In this
case, it must store the PHOP address info received in the
standard RSVP_HOP field and RSVP_HOP_L2 objects of the incident
PATH message.
In both the cases mentioned above (L2 or L3 devices), the SBM
must forward the TCLASS object in the received PATH message
unchanged.
* Copy the IP address of the forwarding interface into the
LAN_LOOPBACK object, unless the SBM protocol entity is a DSBM
reflecting a PATH message back onto the incident interface.
(See the section below on "Additional notes on forwarding a
PATH message onto a managed segment").
* If the SBM protocol entity is the DSBM for the segment to which
the forwarding interface is attached, it must send the PATH
message to the AllSBMAddress.
* If the SBM protocol entity is a SBM or a DSBM Client on the
segment to which the forwarding interface is attached, it must
send the PATH message to the DSBMLogicalAddress.
5.5.1. Additional notes on forwarding a PATH message onto a managed
segment
Rule #1 states that normal IEEE 802.1D forwarding rules should be
used to determine the interfaces on which the PATH message should be
forwarded. In the case of data packets, standard forwarding rules at
a L2 device dictate that the packet should not be forwarded on the
interface from which it was received. However, in the case of a DSBM
that receives a PATH message over a managed segment, the following
exception applies:
E1. If the address in the LAN_NHOP object is a unicast address,
consult the filtering database (FDB) to determine whether the
destination address is listed on the same interface over which
the message was received. If yes, follow the rule below on
"reflecting a PATH message back onto an interface" described
below; otherwise, proceed with the rest of the message
processing as usual.
E2. If there are members of the multicast group address (specified
by the addresses in the LAN_NHOP object), on the segment from
which the message was received, the message should be
forwarded back onto the interface from which it was received
and follow the rule on "reflecting a PATH message back onto an
interface" described below.
*** Reflecting a PATH message back onto an interface ***
Under the circumstances described above, when a DSBM reflects the
PATH message back onto an interface over which it was received, it
must address it using the AllSBMAddress.
Since it is possible for a DSBM to reflect a PATH message back
onto the interface from which it was received, precautions must be
taken to avoid looping these messages indefinitely. The
LAN_LOOPBACK object addresses this issue. All SBM protocol
entities (except DSBMs reflecting a PATH message) overwrite the
LAN_LOOPBACK object in the PATH message with the IP address of the
outgoing interface. DSBMs which are reflecting a PATH message,
leave the LAN_LOOPBACK object unchanged. Thus, SBM protocol
entities will always be able to recognize a reflected multicast
message by the presence of their own address in the LAN_LOOPBACK
object. These messages should be silently discarded.
5.6. Applying the Rules -- Unicast Session
Let's see how the rules are applied in the general network
illustrated previously (see Figure 2).
Assume that H1 is sending a PATH for a unicast session for which H5
is the receiver. The following PATH message is composed by H1:
RSVP Contents
RSVP session IP address IP address of H5 (3.0.0.35)
Sender Template IP address of H1 (1.0.0.11)
PHOP IP address of H1 (1.0.0.11)
RSVP_HOP_L2 n/a (H1 is not sending onto a managed
segment)
LAN_NHOP n/a (H1 is not sending onto a managed
segment)
LAN_LOOPBACK n/a (H1 is not sending onto a managed
segment)
IP Header
Source address IP address of H1 (1.0.0.11)
Destn address IP addr of H5 (3.0.0.35, assuming raw mode
& router alert)
MAC Header
Destn address The L2 addr corresponding to R1 (determined
by map_addr() and routing tables at H1)
Since H1 is not sending onto a managed segment, the PATH message is
composed and forwarded according to standard RSVP processing rules.
Upon receipt of the PATH message, R1 composes and forwards a PATH
message as follows:
RSVP Contents
RSVP session IP address IP address of H5
Sender Template IP address of H1
PHOP IP address of R1 (2.0.0.1)
(seed the return path for RESV messages)
RSVP_HOP_L2 L2 address of R1
LAN_NHOP LAN_NHOP_L3 (2.0.0.2) and
LAN_NHOP_L2 address of R2 (L2ADDR)
(this is the next layer 3 hop)
LAN_LOOPBACK IP address of R1 (2.0.0.1)
IP Header
Source address IP address of H1
Destn address DSBMLogical IP address (224.0.0.16)
MAC Header
Destn address DSBMLogical MAC address
* R1 does a routing lookup on the RSVP session address, to
determine the IP address of the next layer 3 hop, R2.
* It determines that R2 is accessible via seg A and that seg A
is managed by a DSBM, S1.
* Therefore, it concludes that it is sending onto a managed
segment, and composes LAN_NHOP objects to carry the layer 3
and layer 2 next hop addresses. To compose the LAN_NHOP
L2ADDR object, it invokes the L3 to L2 address mapping function
("map_address") to find out the MAC address for the next hop
L3 device, and then inserts a LAN_NHOP_L2ADDR object (that
carries the MAC address) in the message.
* Since R1 is not the DSBM for seg A, it sends the PATH message
to the DSBMLogicalAddress.
Upon receipt of the PATH message, S1 composes and forwards a PATH
message as follows:
RSVP Contents
RSVP session IP address IP address of H5
Sender Template IP address of H1
PHOP IP addr of S1 (seed the return path for RESV
messages)
RSVP_HOP_L2 L2 address of S1
LAN_NHOP LAN_NHOP_L3 (IP) and LAN_NHOP_L2
address of R2
(layer 2 devices do not modify the LAN_NHOP)
LAN_LOOPBACK IP addr of S1
IP Header
Source address IP address of H1
Destn address AllSBMIPaddr (224.0.0.17, since S1 is the
DSBM for seg B).
MAC Header
Destn address All SBM MAC address (since S1 is the DSBM
for seg B).
* S1 looks at the LAN_NHOP address information to determine the
L2 address towards which it should forward the PATH message.
* From the bridge forwarding tables, it determines that the L2
address is reachable via seg B.
* S1 inserts the RSVP_HOP_L2 object and overwrites the RSVP HOP
object (PHOP) with its own addresses.
* Since S1 is the DSBM for seg B, it addresses the PATH message
to the AllSBMAddress.
Upon receipt of the PATH message, S3 composes and forwards a PATH
message as follows:
RSVP Contents
RSVP session IP addr IP address of H5
Sender Template IP address of H1
PHOP IP addr of S3 (seed the return
path for RESV messages)
RSVP_HOP_L2 L2 address of S3
LAN_NHOP LAN_NHOP_L3 (IP) and
LAN_NHOP_L2 (MAC) address of R2
(L2 devices don't modify LAN_NHOP)
LAN_LOOPBACK IP address of S3
IP Header
Source address IP address of H1
Destn address DSBMLogical IP addr (since S3 is
not the DSBM for seg F)
MAC Header
Destn address DSBMLogical MAC address
* S3 looks at the LAN_NHOP address information to determine the
L2 address towards which it should forward the PATH message.
* From the bridge forwarding tables, it determines that the L2
address is reachable via segment F.
* It has discovered that R2 is the DSBM for segment F. It
therefore sends the PATH message to the DSBMLogicalAddress.
* Note that S3 may or may not choose to overwrite the PHOP
objects with its own IP and L2 addresses. If it does so, it
will receive RESV messages. In this case, it must also store
the PHOP info received in the incident PATH message so that
it is able to forward the RESV messages on the correct path.
Upon receipt of the PATH message, R2 composes and forwards a PATH
message as follows:
RSVP Contents
RSVP session IP addr IP address of H5
Sender Template IP address of H1
PHOP IP addr of R2 (seed the return path for RESV
messages)
RSVP_HOP_L2 Removed by R2 (R2 is not sending onto a
managed segment)
LAN_NHOP Removed by R2 (R2 is not sending onto a
managed segment)
IP Header
Source address IP address of H1
Destn address IP address of H5, the RSVP session address
MAC Header
Destn address L2 addr corresponding to H5, the next
layer 3 hop
* R2 does a routing lookup on the RSVP session address, to
determine the IP address of the next layer 3 hop, H5.
* It determines that H5 is accessible via a segment for which
there is no DSBM (not a managed segment).
* Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects
and places the RSVP session address in the destination
address of the IP header. It places the L2 address of the
next layer 3 hop, into the destination address of the MAC
header and forwards the PATH message to H5.
5.7. Applying the Rules - Multicast Session
The rules described above also apply to multicast (m/c) sessions.
For the purpose of this discussion, it is assumed that layer 2
devices track multicast group membership on each port individually.
Layer 2 devices which do not do so, will merely generate extra
multicast traffic. This is the case for L2 devices which do not
implement multicast filtering or GARP/GMRP capability.
Assume that H1 is sending a PATH for an m/c session for which H3 and
H5 are the receivers. The rules are applied as they are in the
unicast case described previously, until the PATH message reaches R2,
with the following exception. The RSVP session address and the
LAN_NHOP carry the destination m/c addresses rather than the unicast
addresses carried in the unicast example.
Now let's look at the processing applied by R2 upon receipt of the
PATH message. Recall that R2 is the DSBM for segment F. Therefore, S3
will have forwarded its PATH message to the DSBMLogicalAddress, to be
picked up by R2. The PATH message will not have been seen by H3 (one
of the m/c receivers), since it monitors only the AllSBMAddress, not
the DSBMLogicalAddress for incoming PATH messages. We rely on R2 to
reflect the PATH message back onto seg f, and to forward it to H5. R2
forwards the following PATH message onto seg f:
RSVP Contents
RSVP session addr m/c session address
Sender Template IP address of H1
PHOP IP addr of R2 (seed the return path for
RESV messages)
RSVP_HOP_L2 L2 addr of R2
LAN_NHOP m/c session address and corresponding L2 address
LAN_LOOPBACK IP addr of S3 (DSBMs reflecting a PATH
message don't modify this object)
IP Header
Source address IP address of H1
Destn address AllSBMIP address (since R2 is the DSBM for seg F)
MAC Header
Destn address AllSBMMAC address (since R2 is the
DSBM for seg F)
Since H3 is monitoring the All SBM Address, it will receive the PATH
message reflected by R2. Note that R2 violated the standard
forwarding rules here by sending an incoming message back onto the
interface from which it was received. It protected against loops by
leaving S3's address in the LAN_LOOPBACK object unchanged.
R2 forwards the following PATH message on to H5:
RSVP Contents
RSVP session addr m/c session address
Sender Template IP address of H1
PHOP IP addr of R2 (seed the return path for RESV
messages)
RSVP_HOP_L2 Removed by R2 (R2 is not sending onto a
managed segment)
LAN_NHOP Removed by R2 (R2 is not sending onto a
managed segment)
LAN_LOOPBACK Removed by R2 (R2 is not sending onto a
managed segment)
IP Header
Source address IP address of H1
Destn address m/c session address
MAC Header
Destn address MAC addr corresponding to the m/c
session address
* R2 determines that there is an m/c receiver accessible via a
segment for which there is no DSBM. Therefore, it removes the
LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session
address in the destination address of the IP header. It
places the corresponding L2 address into the destination
address of the MAC header and multicasts the message towards
H5.
5.8. Merging Traffic Class objects
When a DSBM client receives TCLASS objects from different senders
(different PATH messages) in the same RSVP session and needs to
combine them for sending back a single RESV message (as in a wild-
card style reservation), the DSBM client must choose an appropriate
value that corresponds to the desired-delay traffic class. An
accompanying document discusses the guidelines for traffic class
selection based on desired service and the TSpec information [RFC-
MAP].
In addition, when a SBM or DSBM needs to merge RESVs from different
next hops at a merge point, it must decide how to handle the TCLASS
values in the incoming RESVs if they do not match. Consider the case
when a reservation is in place for a flow at a DSBM (or SBM) with a
successful admission control done for the TCLASS requested in the
first RESV for the flow. If another RESV (not the refresh of the
previously admitted RESV) for the same flow arrives at the DSBM, the
DSBM must first check the TCLASS value in the new RESV against the
TCLASS value in the already installed RESV. If the two values are
same, the RESV requests are merged and the new, merged RESV installed
and forwarded using the normal rules of message processing. However,
if the two values are not identical, the DSBM must generate and send
a RESV_ERR message towards the sender (NHOP) of the newer, RESV
message. The RESV_ERR must specify the error code corresponding to
the RSVP "traffic control error" (RESV_ERR code 21) that indicates
failure to merge two incompatible service requests (sub-code 01 for
the RSVP traffic control error) [RFC-2205]. The RESV_ERR message may
include additional objects to assist downstream nodes in recovering
from this condition. The definition and usage of such objects is
beyond the scope of this memo.
5.9. Operation of SBM Transparent Devices
SBM transparent devices are unaware of the entire SBM/DSBM protocol.
They do not intercept messages addressed to either of the SBM related
local group addresses (the DSBMLogicalAddrss and the ALLSBMAddress),
but instead, pass them through. As a result, they do not divide the
DSBM election scope, they do not explicitly participate in routing of
PATH or RESV messages, and they do not participate in admission
control. They are entirely transparent with respect to SBM operation.
According to the definitions provided, physical segments interconnected by SBM transparent devices are considered a single managed segment. Therefore, DSBMs must perform admission control on such managed segments, with limited knowledge of the segment's topology. In this case, the network administrator should configure the DSBM for each managed segment, with some reasonable approximation of the segment's capacity. A conservative policy would configure the DSBM for the lowest capacity route through the managed segment. A liberal policy would configure the DSBM for the highest capacity route through the managed segment. A network administrator will likely choose some value between the two, based on the level of guarantee required and some knowledge of likely traffic patterns. This document does not specify the configuration mechanism or the choice of a policy.5.10. Operation of SBMs Which are NOT DSBMs
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 what purpose such a SBM protocol entity serves. Such SBMs actually provide two useful functions. First, the additional SBMs remain passive in the background for fault tolerance. They listen to the periodic announcements from the current DSBM for the managed segment (Appendix A describes this in more detail) and step in to elect a new DSBM when the current DSBM fails or ceases to be operational for some reason. Second, such SBMs also provide the important service of dividing the election scope and reducing the size and complexity of managed segments. For example, consider the sample topology in Figure 3 again. the device S3 contains an SBM that is not a DSBM for any f the segments, B, E, or F, attached to it. However, if the SBM protocol entity on S3 was not present, segments B and F would not be separate segments from the point of view of the SBM protocol. Instead, they would constitute a single managed segment, managed by a single DSBM. Because the SBM entity on S3 divides the election scope, seg B and seg F are each managed by separate DSBMs. Each of these segments have a trivial topology and a well defined capacity. As a result, the DSBMs for these segments do not need to perform admission control based on approximations (as would be the case if S3 were SBM transparent). Note that, SBM protocol entities which are not DSBMs, are not required to overwrite the PHOP in incident PATH messages with their own address. This is because it is not necessary for RESV messages to be routed through these devices. RESV messages are only required to be routed through the correct sequence of DSBMs. SBMs may not process RESV messages that do pass through them, other than to forward them towards their destination address, using standard
forwarding rules. SBM protocol entities which are not DSBMs are required to overwrite the address in the LAN_LOOPBACK object with their own address, in order to avoid looping multicast messages. However, no state need be stored.6. Inter-Operability Considerations
There are a few interesting inter-operability issues related to the deployment of a DSBM-based admission control method in an environment consisting of network nodes with and without RSVP capability. In the following, we list some of these scenarios and explain how SBM-aware clients and nodes can operate in those scenarios:6.1. An L2 domain with no RSVP capability.
It is possible to envisage L2 domains that do not use RSVP signaling for requesting resource reservations, but, instead, use some other (e.g., SNMP or static configuration) mechanism to reserve bandwidth at a particular network device such as a router. In that case, the question is how does a DSBM-based admission control method work and interoperate with the non-RSVP mechanism. The SBM-based method does not attempt to provide an admission control solution for such an environment. The SBM-based approach is part of an end to end signaling approach to establish resource reservations and does not attempt to provide a solution for SNMP-based configuration scenario. As stated earlier, the SBM-based approach can, however, co-exist with any other, non-RSVP bandwidth allocation mechanism as long as resources being reserved are either partitioned statically between the different mechanisms or are resolved dynamically through a common bandwidth allocator so that there is no over-commitment of the same resource.6.2. An L2 domain with SBM-transparent L2 Devices.
This scenario has been addressed earlier in the document. The SBM- based method is designed to operate in such an environment. When SBM-transparent L2 devices interconnect SBM-aware devices, the resulting managed segment is a combination of one or more physical segments and the DSBM for the managed segment may not be as efficient in allocating resources as it would if all L2 devices were SBM-aware.
6.3. An L2 domain on which some RSVP-based senders are not DSBM clients.
All senders that are sourcing RSVP-based traffic flows onto a managed segment MUST be SBM-aware and participate in the SBM protocol. Use of the standard, non-SBM version of RSVP may result in over- allocation of resources, as such use bypasses the resource management function of the DSBM. All other senders (i.e., senders that are not sending streams subject to RSVP admission control) should be elastic applications that send traffic of lower priority than the RSVP traffic, and use TCP-like congestion avoidance mechanisms. All DSBMs, SBMs, or DSBM clients on a managed segment (a segment with a currently active DSBM) must not accept PATH messages from senders that are not SBM-aware. PATH messages from such devices can be easily detected by SBMs and DSBM clients as they would not be multicast to the ALLSBMAddress (in case of SBMs and DSBM clients) or the DSBMLogicalAddress (in case of DSBMs).6.4. A non-SBM router that interconnects two DSBM-managed L2 domains.
Multicast SBM messages (e.g., election and PATH messages) have local scope and are not intended to pass between the two domains. A correctly configured non-SBM router will not pass such messages between the domains. A broken router implementation that does so may cause incorrect operation of the SBM protocol and consequent over- or under-allocation of resources.6.5. Interoperability with RSVP clients that use UDP encapsulation and are not capable of receiving/sending RSVP messages using RAW_IP
This document stipulates that DSBMs, DSBM clients, and SBMs use only raw IP for encapsulating RSVP messages that are forwarded onto a L2 domain. RFC-2205 (the RSVP Proposed Standard) includes support for both raw IP and UDP encapsulation. Thus, a RSVP node using only the UDP encapsulation will not be able to interoperate with the DSBM unless DSBM accepts and supports UDP encapsulated RSVP messages.7. Guidelines for Implementers
In the following, we provide guidelines for implementers on different aspects of the implementation of the SBM-based admission control procedure including suggestions for DSBM initialization, etc.7.1. DSBM Initialization
As stated earlier, DSBM initialization includes configuration of maximum bandwidth that can be reserved on a managed segment under its control. We suggest the following guideline.
In the case of a managed segment consisting of L2 devices interconnected by a single shared segment, DSBM entities on such devices should assume the bandwidth of the interface as the total link bandwidth. In the case of a DSBM located in a L2 switch, it might additionally need to be configured with an estimate of the device's switching capacity if that is less than the link bandwidth, and possibly with some estimate of the buffering resources of the switch (see [RFC-FRAME] for the architectural model assumed for L2 switches). Given the total link bandwidth, the DSBM may be further configured to limit the maximum amount of bandwidth for RSVP-enabled flows to ensure spare capacity for best-effort traffic.7.2. Operation of DSBMs in Different L2 Topologies
Depending on a L2 topology, a DSBM may be called upon to manage resources for one or more segments and the implementers must bear in mind efficiency implications of the use of DSBM in different L2 topologies. Trivial L2 topologies consist of a single "physical segment". In this case, the 'managed segment' is equivalent to a single segment. Complex L2 topologies may consist of a number of Admission control on such an L2 extended segment can be performed from a single pool of resources, similar to a single shared segment, from the point of view of a single DSBM. This configuration compromises the efficiency with which the DSBM can allocate resources. This is because the single DSBM is required to make admission control decisions for all reservation requests within the L2 topology, with no knowledge of the actual physical segments affected by the reservation. We can realize improvements in the efficiency of resource allocation by subdividing the complex segment into a number of managed segments, each managed by their own DSBM. In this case, each DSBM manages a managed segment having a relatively simple topology. Since managed segments are simpler, the DSBM can be configured with a more accurate estimate of the resources available for all reservations in the managed segment. In the ultimate configuration, each physical segment is a managed segment and is managed by its own DSBM. We make no assumption about the number of managed segments but state, simply, that in complex L2 topologies, the efficiency of resource allocation improves as the granularity of managed segments increases.8. Security Considerations
The message formatting and usage rules described in this note raise security issues, identical to those raised by the use of RSVP and Integrated Services. It is necessary to control and authenticate
access to enhanced qualities of service enabled by the technology described in this RFC. This requirement is discussed further in [RFC-2205], [RFC-2211], and [RFC-2212]. [RFC-RSVPMD5] describes the mechanism used to protect the integrity of RSVP messages carrying the information described here. A SBM implementation should satisfy the requirements of that RFC and provide the suggested mechanisms just as though it were a conventional RSVP implementation. It should further use the same mechanisms to protect the additional, SBM-specific objects in a message. Finally, it is also necessary to authenticate DSBM candidates during the election process, and a mechanism based on a shared secret among the DSBM candidates may be used. The mechanism defined in [RFC- RSVPMD5] should be used.9. References
[RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC-RSVPMD5] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC 2206] Baker, F. and J. Krawczyk, "RSVP Management Information Base", RFC 2206, September 1997. [RFC 2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. [RFC 2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [RFC 2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997. [RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC 2213] Baker, F. and J. Krawczyk, "Integrated Services Management Information Base", RFC 2213, September 1997.
[RFC-FRAME] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A. and M.Seaman, "A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies", RFC 2816, May 2000. [RFC-MAP] Seaman, M., Smith, A. and E. Crawley, "Integrated Service Mappings on IEEE 802 Networks", RFC 2815, May 2000. [IEEE802Q] "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", Draft Standard P802.1Q/D9, February 20, 1998. [IEEEP8021p] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision (Incorporating IEEE P802.1p: Traffic Class Expediting and Dynamic Multicast Filtering)", ISO/IEC Final CD 15802-3 IEEE P802.1D/D15, November 24, 1997. [IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D- 1993.
(next page on part 3)