indicates that the SBM protocol entity on the device is not eligible
to be a DSBM for the segment attached to the interface.
A separate range of values is reserved for each type of SBM-capable
device to reflect the relative priority among different classes of
L2/L3 devices. L2 devices get higher priority followed by routers
followed by hosts. The priority values in the range of 128..255 are
reserved for L2 devices, the values in the range of 64..127 are
reserved for routers, and values in the range of 1..63 are reserved
for hosts.
A.11. DSBM Election over switched links
The election algorithm works as described before in this case except
each SBM-capable L2 device restricts the scope of the election to its
local segment. As described in Section B.1 below, all messages
related to the DSBM election are sent to a special multicast address
(AllSBMAddress). AllSBMAddress (its corresponding MAC multicast
address) is configured in the permanent database of SBM-capable,
layer 2 devices so that all frames with AllSBMAddress as the
destination address are not forwarded and instead directed to the SBM
management entity in those devices. Thus, a DSBM can be elected
separately on each point-to-point segment in a switched topology. For
example, in Figure 2, DSBM for "segment A" will be elected using the
election algorithm between R1 and S1 and none of the election-related
messages on this segment will be forwarded by S1 beyond "segment A".
Similarly, a separate election will take place on each segment in
this topology.
When a switched segment is a half-duplex segment, two senders (one
sender at each end of the link) share the link. In this case, one of
the two senders will win the DSBM election and will be responsible
for managing the segment.
If a switched segment is full-duplex, exactly one sender sends on the
link in each direction. In this case, either one or two DSBMs can
exist on such a managed segment. If a sender at each end wishes to
serve as a DSBM for that end, it can declare itself to be the DSBM by
sending out an I_AM_DSBM advertisement and start managing the
resources for the outgoing traffic over the segment. If one of the
two senders does not wish itself to be the DSBM, then the other DSBM
will not receive any DSBM advertisement from its peer and assume
itself to be the DSBM for traffic traversing in both directions over
the managed segment.
Appendix B Message Encapsulation and Formats
To minimize changes to the existing RSVP implementations and to
ensure quick deployment of a SBM in conjunction with RSVP, all
communication to and from a DSBM will be performed using messages
constructed using the current rules for RSVP message formats and raw
IP encapsulation. For more details on the RSVP message formats, refer
to the RSVP specification (RFC2205). No changes to the RSVP message
formats are proposed, but new message types and new L2-specific
objects are added to the RSVP message formats to accommodate DSBM-
related messages. These additions are described below.
B.1 Message Addressing
For the purpose of DSBM election and detection, AllSBMAddress is used
as the destination address while sending out both DSBM_WILLING and
I_AM_DSBM messages. A DSBM client first detects a managed segment by
listening to I_AM_DSBM advertisements and records the DSBMAddress
(unicast IP address of the DSBM).
B.2. Message Sizes
Each message must occupy exactly one IP datagram. If it exceeds the
MTU, such a datagram will be fragmented by IP and reassembled at the
recipient node. This has a consequence that a single message may not
exceed the maximum IP datagram size, approximately 64K bytes.
B.3. RSVP-related Message Formats
All RSVP messages directed to and from a DSBM may contain various
RSVP objects defined in the RSVP specification and messages continue
to follow the formatting rules specified in the RSVP specification.
In addition, an RSVP implementation must also recognize new object
classes that are described below.
B.3.1. Object Formats
All objects are defined using the format specified in the RSVP
specification. Each object has a 32-bit header that contains length
(of the object in bytes including the object header), the object
class number, and a C-Type. All unused fields should be set to zero
and ignored on receipt.
B.3.2. SBM Specific Objects
Note that the Class-Num values for the SBM specific objects
(LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2) are chosen from the
codespace 10XXXXXX. This coding assures that non-SBM aware RSVP nodes
will ignore the objects without forwarding them or generating an
error message.
Within the SBM specific codespace, note the following interpretation
of the third most significant bit of the Class-Num:
a) Objects of the form 100XXXXX are to be silently
discarded by SBM nodes that do not recognize them.
b) Objects of the form 101XXXXX are to be silently
forwarded by SBM nodes that do not recognize them.
B.3.3. IEEE 802 Canonical Address Format
The 48-bit MAC Addresses used by IEEE 802 were originally defined in
terms of wire order transmission of bits in the source and
destination MAC address fields. The same wire order applied to both
Ethernet and Token Ring. Since the bit transmission order of Ethernet
and Token Ring data differ - Ethernet octets are transmitted least
significant bit first, Token Ring most significant first - the
numeric values naturally associated with the same address on
different 802 media differ. To facilitate the communication of
address values in higher layer protocols which might span both token
ring and Ethernet attached systems connected by bridges, it was
necessary to define one reference format - the so called canonical
format for these addresses. Formally the canonical format defines the
value of the address, separate from the encoding rules used for
transmission. It comprises a sequence of octets derived from the
original wire order transmission bit order as follows. The least
significant bit of the first octet is the first bit transmitted, the
next least significant bit the second bit, and so on to the most
significant bit of the first octet being the 8th bit transmitted; the
least significant bit of the second octet is the 9th bit transmitted,
and so on to the most significant bit of the sixth octet of the
canonical format being the last bit of the address transmitted.
This canonical format corresponds to the natural value of the address
octets for Ethernet. The actual transmission order or formal encoding
rules for addresses on media which do not transmit bit serially are
derived from the canonical format octet values.
This document requires that all L2 addresses used in conjunction with
the SBM protocol be encoded in the canonical format as a sequence of
6 octets. In the following, we define the object formats for objects
that contain L2 addresses that are based on the canonical
representation.
B.3.4. RSVP_HOP_L2 object
RSVP_HOP_L2 object uses object class = 161; it contains the L2
address of the previous hop L3 device in the IEEE Canonical address
format discussed above.
RSVP_HOP_L2 object: class = 161, C-Type represents the addressing
format used. In our case, C-Type=1 represents the IEEE Canonical
Address format.
0 1 2 3
+---------------+---------------+---------------+----------------+
| Length | 161 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
C-Type = 1 (IEEE Canonical Address format)
When C-Type=1, the object format is:
0 1 2 3
+---------------+---------------+---------------+---------------+
| 12 | 161 | 1 |
+---------------+---------------+---------------+---------------+
| Octets 0-3 of the MAC address |
+---------------+---------------+---------------+---------------+
| Octets 4-5 of the MAC addr. | /// | /// |
+---------------+---------------+---------------+---------------+
/// -- unused (set to zero)
B.3.5. LAN_NHOP object
LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address
object and LAN_NHOP_L2 address object.
<LAN_NHOP object> ::= <LAN_NHOP_L2 object> <LAN_NHOP_L3 object>
LAN_NHOP_L2 address object uses object class = 162 and uses the same
format (but different class number) as the RSVP_HOP_L2 object. It
provides the L2 or MAC address of the next hop L3 device.
0 1 2 3
+---------------+---------------+---------------+----------------+
| Length | 162 |C-Type(addrtype)|
+---------------+---------------+---------------+----------------+
| Variable length Opaque data |
+---------------+---------------+---------------+----------------+
C-Type = 1 (IEEE 802 Canonical Address Format as defined below) See
the RSVP_HOP_L2 address object for more details.
LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP
address of the next hop L3 device.
LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6
address family used.
IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1
+---------------+---------------+---------------+---------------+
| Length = 8 | 163 | 1 |
+---------------+---------------+---------------+---------------+
| IPv4 NHOP address |
+---------------------------------------------------------------+
IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2
+---------------+---------------+---------------+---------------+
| Length = 20 | 163 | 2 |
+---------------+---------------+---------------+---------------+
| IPv6 NHOP address (16 bytes) |
+---------------------------------------------------------------+
B.3.6. LAN_LOOPBACK Object
The LAN_LOOPBACK object gives the IP address of the outgoing
interface for a PATH message and uses object class=164; both IPv4 and
IPv6 formats are specified.
IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1
0 1 2 3
+---------------+---------------+---------------+---------------+
| Length | 164 | 1 |
+---------------+---------------+---------------+---------------+
| IPV4 address of an interface |
+---------------+---------------+---------------+---------------+
IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2
+---------------+---------------+---------------+---------------+
| Length | 164 | 2 |
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPV6 address of an interface +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
B.3.7. TCLASS Object
TCLASS object (traffic class based on IEEE 802.1p) uses object
class = 165.
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | 165 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /// | /// | /// | /// | PV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Only 3 bits in data contain the user_priority value (PV).
B.4. RSVP PATH and PATH_TEAR Message Formats
As specified in the RSVP specification, a PATH and PATH_TEAR messages
contain the RSVP Common Header and the relevant RSVP objects.
For the RSVP Common Header, refer to the RSVP specification (RFC
2205). Enhancements to an RSVP_PATH message include additional
objects as specified below.
<PATH Message> ::= <RSVP Common Header> [<INTEGRITY>]
<RSVP_HOP_L2> <LAN_NHOP>
<LAN_LOOPBACK> [<TCLASS>] <SESSION><RSVP_HOP>
<TIME_VALUES> [<POLICY DATA>] <sender descriptor>
<PATH_TEAR Message> ::= <RSVP Common Header> [<INTEGRITY>]
<LAN_LOOPBACK> <LAN_NHOP> <SESSION> <RSVP_HOP>
[<sender descriptor>]
If the INTEGRITY object is present, it must immediately follow the
RSVP common header. L2-specific objects must always precede the
SESSION object.
B.5. RSVP RESV Message Format
As specified in the RSVP specification, an RSVP_RESV message contains
the RSVP Common Header and relevant RSVP objects. In addition, it may
contain an optional TCLASS object as described earlier.
B.6. Additional RSVP message types to handle SBM interactions
New RSVP message types are introduced to allow interactions between a
DSBM and an RSVP node (host/router) for the purpose of discovering
and binding to a DSBM. New RSVP message types needed are as follows:
RSVP Msg Type (8 bits) Value
DSBM_WILLING 66
I_AM_DSBM 67
All SBM-specific messages are formatted as RSVP messages with an RSVP
common header followed by SBM-specific objects.
<SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects>
where <SBMP common header> ::= <RSVP common Header> [<INTEGRITY>]
For each SBM message type, there is a set of rules for the
permissible choice of object types. These rules are specified using
Backus-Naur Form (BNF) augmented with square brackets surrounding
optional sub-sequences. The BNF implies an order for the objects in a
message. However, in many (but not all) cases, object order makes no
logical difference. An implementation should create messages with the
objects in the order shown here, but accept the objects in any
permissible order. Any exceptions to this rule will be pointed out in
the specific message formats.
DSBM_WILLING Message
<DSBM_WILLING message> ::= <SBM Common Header> <DSBM IP ADDRESS>
<DSBM L2 address> <SBM PRIORITY>
I_AM_DSBM Message
<I_AM_DSBM> ::= <SBM Common Header> <DSBM IP ADDRESS> <DSBM L2 address>
<SBM PRIORITY> <DSBM Timer Intervals>
[<NON_RESV_SEND_LIMIT>]
For compatibility reasons, receivers of the I_AM_DSBM message must be
prepared to receive additional objects of the Unknown Class type
[RFC-2205].
All I_AM_DSBM messages are multicast to the well known AllSBMAddress.
The default priority of a SBM is 1 and higher priority values
represent higher precedence. The priority value zero indicates that
the SBM is not eligible to be the DSBM.
Relevant Objects
DSBM IP ADDRESS objects use object class = 42; IPv4 DSBM IP ADDRESS
object uses <Class=42, C-Type=1> and IPv6 DSBM IP ADDRESS object uses
<Class=42, C-Type=2>.
IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1
0 1 2 3
+---------------+---------------+---------------+---------------+
| IPv4 DSBM IP Address |
+---------------+---------------+---------------+---------------+
IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 2
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPv6 DSBM IP Address +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
<DSBM L2 address> Object is the same as <RSVP_HOP_L2> object with C-
Type = 1 for IEEE Canonical Address format.
<DSBM L2 address> ::= <RSVP_HOP_L2>
A SBM may omit this object by including a NULL L2 address object.
For C-Type=1 (IEEE Canonical address format), such a version of the
L2 address object contains value zero in the six octets corresponding
to the MAC address (see section B.3.4 for the exact format).
SBM_PRIORITY Object: class = 43, C-Type =1
0 1 2 3
+---------------+---------------+---------------+---------------+
| /// | /// | /// | SBM priority |
+---------------+---------------+---------------+---------------+
TIMER INTERVAL VALUES.
The two timer intervals, namely, DSBM Dead Interval and DSBM Refresh
Interval, are specified as integer values each in the range of 0..255
seconds. Both values are included in a single "DSBM Timer Intervals"
object described below.
DSBM Timer Intervals Object: class = 44, C-Type =1
+---------------+---------------+---------------+----------------+
| /// | /// | DeadInterval | RefreshInterval|
+---------------+---------------+---------------+----------------+
NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 1
0 1 2 3
+---------------+---------------+---------------+----------------+
| NonResvSendLimit(limit on traffic allowed to send without RESV)|
| |
+---------------+---------------+---------------+----------------+
<NonResvSendLimit> ::= <Intserv Sender_TSPEC object>
(class=12, C-Type =2)
The NON_RESV_SEND_LIMIT object specifies a per-flow limit on the
profile of traffic which a sending host is allowed to send onto a
managed segment without a valid RSVP reservation (see Appendix C for
further details on the usage of this object). The object contains the
NonResvSendLimit parameter. This parameter is equivalent to the
Intserv SENDER_TSPEC (see RFC2210 for contents and encoding rules).
The SENDER_TSPEC includes five parameters which describe a traffic
profile (r, b, p, m and M). Sending hosts compare the SENDER_TSPEC
describing a sender traffic flow to the SENDER_TSPEC advertised by
the DSBM. If the SENDER_TSPEC of the traffic flow in question is less
than or equal to the SENDER_TSPEC advertised by the DSBM, it is
allowable to send traffic on the corresponding flow without a valid
RSVP reservation in place. Otherwise it is not.
The network administrator may configure the DSBM to disallow any sent
traffic in the absence of an RSVP reservation by configuring a
NonResvSendLimit in which r = 0, b = 0, p = 0, m = infinity and M =
0. Similarly the network administrator may allow any traffic to be
sent in the absence of an RSVP reservation by configuring a
NonResvSendLimit in which r = infinity, b = infinity, p = infinity, m
= 0 and M = infinity. Of course, any of these parameters may be set
to values between zero and infinity to advertise finite per-flow
limits.
The NON_RESV_SEND_LIMIT object is optional. Senders on a managed
segment should interpret the absence of the NON_RESV_SEND_LIMIT
object as equivalent to an infinitely large SENDER_TSPEC (it is
permissible to send any traffic profile in the absence of an RSVP
reservation).
Appendix C The DSBM as a Source of Centralized Configuration Information
There are certain configuration parameters which it may be useful to
distribute to layer-3 senders on a managed segment. The DSBM may
serve as a centralized management point from which such parameters
can easily be distributed. In particular, it is possible for the
network administrator configuring a DSBM to cause certain
configuration parameters to be distributed as objects appended to the
I_AM_DSBM messages. The following configuration object is defined at
this time. Others may be defined in the future. See Appendix B for
further details regarding the NON_RESV_SEND_LIMIT object.
C.1. NON_RESV_SEND_LIMIT
As we QoS enable layer 2 segments, we expect an evolution from
subnets comprised of traditional shared segments (with no means of
traffic separation and no DSBM), to subnets comprised of dedicated
segments switched by sophisticated switches (with both DSBM and
802.1p traffic separation capability).
A set of intermediate configurations consists of a group of QoS
enabled hosts sending onto a traditional shared segment. A layer-3
device (or a layer-2 device) acts as a DSBM for the shared segment,
but cannot enforce traffic separation. In such a configuration, the
DSBM can be configured to limit the number of reservations approved
for senders on the segment, but cannot prevent them from sending. As
a result, senders may congest the segment even though a network
administrator has configured an appropriate limit for admission
control in the DSBM.
One solution to this problem which would give the network
administrator control over the segment, is to require applications
(or operating systems on behalf of applications) not to send until
they have obtained a reservation. This is problematic as most
applications are used to sending as soon as they wish to and expect
to get whatever service quality the network is able to grant at that
time. Furthermore, it may often be acceptable to allow certain
applications to send before a reservation is received. For example,
on a segment comprised of a single 10 Mbps ethernet and 10 hosts, it
may be acceptable to allow a 16 Kbps telephony stream to be
transmitted but not a 3 Mbps video stream.
A more pragmatic solution then, is to allow the network administrator
to set a per-flow limit on the amount of non-adaptive traffic which a
sender is allowed to generate on a managed segment in the absence of
a valid reservation. This limit is advertised by the DSBM and
received by sending hosts. An API on the sending host can then
approve or deny an application's QoS request based on the resources
requested.
The NON_RESV_SEND_LIMIT object can be used to advertise a Flowspec
which describes the shape of traffic that a sender is allowed to
generate on a managed segment when its RSVP reservation requests have
either not yet completed or have been rejected.
ACKNOWLEDGEMENTS
Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel),
David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman
(3COM), Andrew Smith (Extreme Networks) for their constructive
comments on the SBM design and the earlier versions of this document.
6. Authors' Addresses
Raj Yavatkar
Intel Corporation
2111 N.E. 25th Avenue,
Hillsboro, OR 97124
USA
Phone: +1 503-264-9077
EMail: yavatkar@ibeam.intel.com
Don Hoffman
Teledesic Corporation
2300 Carillon Point
Kirkland, WA 98033
USA
Phone: +1 425-602-0000
Yoram Bernet
Microsoft
1 Microsoft Way
Redmond, WA 98052
USA
Phone: +1 206 936 9568
EMail: yoramb@microsoft.com
Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
USA
Phone: +1 408 526 4257
EMail: fred@cisco.com
Michael Speer
Sun Microsystems, Inc
901 San Antonio Road UMPK15-215
Palo Alto, CA 94303
Phone: +1 650-786-6368
EMail: speer@Eng.Sun.COM
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.