idnits 2.17.1 draft-ietf-issll-is802-sbm-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 68 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 398 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 10 instances of lines with control characters in the document. == There are 13 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 685: '... include a TCLASS object, the DSBM MAY...' RFC 2119 keyword, line 1562: '... managed segment MUST be SBM-aware and...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 1434 has weird spacing: '...nd send a RES...' == Line 1797 has weird spacing: '...riority to de...' == Line 1800 has weird spacing: '... tie is broke...' == Line 1844 has weird spacing: '...listens for i...' == Line 1850 has weird spacing: '...sending out a...' == (6 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 1999) is 8959 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC-FRAME' on line 1716 looks like a reference -- Missing reference section? 'RFC-MAP' on line 1720 looks like a reference -- Missing reference section? 'IEEE8021D' on line 1736 looks like a reference -- Missing reference section? 'IEEE8021P' on line 229 looks like a reference -- Missing reference section? 'IEEE802Q' on line 1723 looks like a reference -- Missing reference section? 'IEEE8021p' on line 636 looks like a reference -- Missing reference section? 'IEEE8021Q' on line 642 looks like a reference -- Missing reference section? 'RFC-1700' on line 875 looks like a reference -- Missing reference section? 'RFC-2205' on line 2625 looks like a reference -- Missing reference section? 'RFC-2211' on line 1700 looks like a reference -- Missing reference section? 'RFC-2212' on line 1703 looks like a reference -- Missing reference section? 'RFC-RSVPMD5' on line 1694 looks like a reference -- Missing reference section? 'RFC-2206' on line 1697 looks like a reference -- Missing reference section? 'RFC-2215' on line 1706 looks like a reference -- Missing reference section? 'RFC-2210' on line 1710 looks like a reference -- Missing reference section? 'RFC-2213' on line 1713 looks like a reference -- Missing reference section? 'IEEEP8021p' on line 1727 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Raj Yavatkar, Intel 2 INTERNET-DRAFT Don Hoffman, Teledesic 3 Yoram Bernet, Microsoft 4 Fred Baker, Cisco 5 Michael Speer, Sun Microsystems 7 October 1999 9 SBM (Subnet Bandwidth Manager): 10 A Protocol for RSVP-based Admission Control over IEEE 802-style networks 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 SBM (Subnet Bandwidth Manager) October, 1999 35 Abstract 37 This document describes a signaling method and protocol for RSVP-based 38 admission control over IEEE 802-style LANs. The protocol is designed 39 to work both with the current generation of IEEE 802 LANs as well as with the 40 recent work completed by the IEEE 802.1 committee. 42 SBM (Subnet Bandwidth Manager) October, 1999 44 1. Introduction 46 New extensions to the Internet architecture and service models have 47 been defined for an integrated services Internet [RFC-1633, RFC-2205, 48 RFC-2210] so that applications can request specific qualities or lev- 49 els of service from an internetwork in addition to the current IP 50 best-effort service. These extensions include RSVP, a resource reser- 51 vation setup protocol, and definition of new service classes to be 52 supported by Integrated Services routers. RSVP and service class 53 definitions are largely independent of the underlying networking tech- 54 nologies and it is necessary to define the mapping of RSVP and 55 Integrated Services specifications onto specific subnetwork technolo- 56 gies. For example, a definition of service mappings and reservation 57 setup protocols is needed for specific link-layer technologies such as 58 shared and switched IEEE-802-style LAN technologies. 60 This document defines SBM, a signaling protocol for RSVP-based admis- 61 sion control over IEEE 802-style networks. SBM provides a method for 62 mapping an internet-level setup protocol such as RSVP onto IEEE 802- 63 style networks. In particular, it describes the operation of RSVP- 64 enabled hosts/routers and link layer devices (switches, bridges) to 65 support reservation of LAN resources for RSVP-enabled data flows. A 66 framework for providing Integrated Services over shared and switched 67 IEEE-802-style LAN technologies and a definition of service mappings 68 have been described in separate documents [RFC-FRAME, RFC-MAP]. 70 2. Goals and Assumptions 72 The SBM (Subnet Bandwidth Manager) protocol and its use for admission 73 control and bandwidth management in IEEE 802 level-2 networks is based 74 on the following architectural goals and assumptions: 76 I. Even though the current trend is towards increased use of 77 switched LAN topologies consisting of newer switches that support 78 the priority queuing mechanisms specified by IEEE 802.1p, we 79 assume that the LAN technologies will continue to be a mix of 80 legacy shared/ switched LAN segments and newer switched segments 81 based on IEEE 802.1p specification. Therefore, we specify a sig- 82 naling protocol for managing bandwidth over both legacy and newer 83 LAN topologies and that takes advantage of the additional func- 84 tionality (such as an explicit support for different traffic 85 classes or integrated service classes) as it becomes available in 86 the new generation of switches, hubs, or bridges. As a result, 87 the SBM protocol would allow for a range of LAN bandwidth 89 SBM (Subnet Bandwidth Manager) October, 1999 91 management solutions that vary from one that exercises purely 92 administrative control (over the amount of bandwidth consumed by 93 RSVP-enabled traffic flows) to one that requires cooperation (and 94 enforcement) from all the end-systems or switches in a IEEE 802 95 LAN. 97 II. This document specifies only a signaling method and protocol for 98 LAN-based admission control over RSVP flows. We do not define 99 here any traffic control mechanisms for the link layer; the pro- 100 tocol is designed to use any such mechanisms defined by IEEE 802. 101 In addition, we assume that the Layer 3 end-systems (e.g., a host 102 or a router) will exercise traffic control by policing Integrated 103 Services traffic flows to ensure that each flow stays within its 104 traffic specifications stipulated in an earlier reservation 105 request submitted for admission control. This then allows a sys- 106 tem using SBM admission control combined with per-flow shaping at 107 end-systems and IEEE-defined traffic control at link layer to 108 realize some approximation of Controlled Load (and even 109 Guaranteed) services over IEEE 802-style LANs. 111 III. In the absence of any link-layer traffic control or priority 112 queuing mechanisms in the underlying LAN (such as a shared LAN 113 segment), the SBM-based admission control mechanism only limits 114 the total amount of traffic load imposed by RSVP-enabled flows on 115 a shared LAN. In such an environment, no traffic flow separation 116 mechanism exists to protect the RSVP-enabled flows from the 117 best-effort traffic on the same shared media and that raises the 118 question of the utility of such a mechanism outside a topology 119 consisting only of 802.1p-compliant switches. However, we assume 120 that the SBM-based admission control mechanism will still serve a 121 useful purpose in a legacy, shared LAN topology for two reasons. 122 First, assuming that all the nodes that generate Integrated Ser- 123 vices traffic flows utilize the SBM-based admission control pro- 124 cedure to request reservation of resources before sending any 125 traffic, the mechanism will restrict the total amount of traffic 126 generated by Integrated Services flows within the bounds desired 127 by a LAN administrator (see discussion of the NonResvSendLimit 128 parameter in Appendix C). Second, the best-effort traffic gen- 129 erated by the TCP/IP-based traffic sources is generally rate- 130 adaptive (using a TCP-style "slow start" congestion avoidance 131 mechanism or a feedback-based rate adaptation mechanism used by 132 audio/video streams based on RTP/RTCP protocols) and adapts to 133 stay within the available network bandwidth. Thus, the combina- 134 tion of admission control and rate adaptation should avoid per- 135 sistent traffic congestion. This does not, however, guarantee 136 that non-Integrated-Services traffic will not interfere with the 138 SBM (Subnet Bandwidth Manager) October, 1999 140 Integrated Services traffic in the absence of traffic control 141 support in the underlying LAN infrastructure. 143 3. Organization of the rest of this document 145 The rest of this document provides a detailed description of the SBM- 146 based admission control procedure(s) for IEEE 802 LAN technologies. 147 The document is organized as follows: 149 * Section 4 first defines the various terms used in the document 150 and then provides an overview of the admission control procedure 151 with an example of its application to a sample network. 153 * Section 5 describes the rules for processing and forwarding PATH 154 (and PATH_TEAR) messages at DSBMs (Designated Subnet Bandwidth 155 Managers), SBMs, and DSBM clients. 157 * Section 6 addresses the inter-operability issues when a DSBM may 158 operate in the absence of RSVP signaling at Layer 3 or when 159 another signaling protocol (such as SNMP) is used to reserve 160 resources on a LAN segment. 162 * Appendix A describes the details of the DSBM election algorithm 163 used for electing a designated SBM on a LAN segment when more 164 than one SBM is present. It also describes how DSBM clients dis- 165 cover the presence of a DSBM on a managed segment. 167 * Appendix B specifies the formats of SBM-specific messages used 168 and the formats of new RSVP objects needed for the SBM operation. 170 * Appendix C describes usage of the DSBM to distribute configura- 171 tion information to senders on a managed segment. 173 4. Overview 175 4.1. Definitions 177 SBM (Subnet Bandwidth Manager) October, 1999 179 - Link Layer or Layer 2 or L2: We refer to data-link layer techno- 180 logies such as IEEE 802.3/Ethernet as L2 or layer 2. 182 - Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes 183 and links interconnected without passing through a L3 forwarding 184 function. One or more IP subnets can be overlaid on a L2 domain. 186 - Layer 2 or L2 devices: We refer to devices that only implement 187 Layer 2 functionality as Layer 2 or L2 devices. These include 188 802.1D bridges or switches. 190 - Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO 7 layer 191 model. This document is primarily concerned with networks that 192 use the Internet Protocol (IP) at this layer. 194 - Layer 3 Device or L3 Device or End-Station: these include hosts 195 and routers that use L3 and higher layer protocols or application 196 programs that need to make resource reservations. 198 - Segment: A L2 physical segment that is shared by one or more 199 senders. Examples of segments include (a) a shared Ethernet or 200 Token-Ring wire resolving contention for media access using CSMA 201 or token passing ("shared L2 segment"), (b) a half duplex link 202 between two stations or switches, (c) one direction of a switched 203 full-duplex link. 205 - Managed segment: A managed segment is a segment with a DSBM 206 present and responsible for exercising admission control over 207 requests for resource reservation. A managed segment includes 208 those interconnected parts of a shared LAN that are not separated 209 by DSBMs. 211 - Traffic Class: An aggregation of data flows which are given simi- 212 lar service within a switched network. 214 - User_priority: User_priority is a value associated with the 215 transmission and reception of all frames in the IEEE 802 service 216 model: it is supplied by the sender that is using the MAC ser- 217 vice. It is provided along with the data to a receiver using the 218 MAC service. It may or may not be actually carried over the 220 SBM (Subnet Bandwidth Manager) October, 1999 222 network: Token-Ring/802.5 carries this value (encoded in its FC 223 octet), basic Ethernet/802.3 does not, 802.12 may or may not 224 depending on the frame format in use. 802.1p defines a consistent 225 way to carry this value over the bridged network on Ethernet, 226 Token Ring, Demand-Priority, FDDI or other MAC-layer media using 227 an extended frame format. The usage of user_priority is fully 228 described in section 2.5 of 802.1D [IEEE8021D] and 802.1p 229 [IEEE8021P] "Support of the Internal Layer Service by Specific 230 MAC Procedures". 232 - Subnet: used in this memo to indicate a group of L3 devices shar- 233 ing a common L3 network address prefix along with the set of seg- 234 ments making up the L2 domain in which they are located. 236 - Bridge/Switch: a layer 2 forwarding device as defined by IEEE 237 802.1D. The terms bridge and switch are used synonymously in this 238 document. 240 - DSBM: Designated SBM (DSBM) is a protocol entity that resides in 241 a L2 or L3 device and manages resources on a L2 segment. At most 242 one DSBM exists for each L2 segment. 244 - SBM: the SBM is a protocol entity that resides in a L2 or L3 dev- 245 ice and is capable of managing resources on a segment. However, 246 only a DSBM manages the resources for a managed segment. When 247 more than one SBM exists on a segment, one of the SBMs is elected 248 to be the DSBM. 250 - Extended segment: An extended segment includes those parts of a 251 network which are members of the same IP subnet and therefore are 252 not separated by any layer 3 devices. Several managed segments, 253 interconnected by layer 2 devices, constitute an extended seg- 254 ment. 256 - Managed L2 domain: An L2 domain consisting of managed segments is 257 referred to as a managed L2 domain to distinguish it from a L2 258 domain with no DSBMs present for exercising admission control 259 over resources at segments in the L2 domain. 261 - DSBM clients: These are entities that transmit traffic onto a 263 SBM (Subnet Bandwidth Manager) October, 1999 265 managed segment and use the services of a DSBM for the managed 266 segment for admission control over a LAN segment. Only the layer 267 3 or higher layer entities on L3 devices such as hosts and 268 routers are expected to send traffic that requires resource 269 reservations, and, therefore, DSBM clients are L3 entities. 271 - SBM transparent devices: A "SBM transparent" device is unaware of 272 SBMs or DSBMs (though it may or may not be RSVP aware) and, 273 therefore, does not participate in the SBM-based admission con- 274 trol procedure over a managed segment. Such a device uses stan- 275 dard forwarding rules appropriate for the device and is tran- 276 sparent with respect to SBM. An example of such a L2 device is a 277 legacy switch that does not participate in resource reservation. 279 - Layer 3 and layer 2 addresses: We refer to layer 3 addresses of 280 L3/L2 devices as "L3 addresses" and layer 2 addresses as "L2 281 addresses". This convention will be used in the rest of the docu- 282 ment to distinguish between Layer 3 and layer 2 addresses used to 283 refer to RSVP next hop (NHOP) and previous hop (PHOP) devices. 284 For example, in conventional RSVP message processing, RSVP_HOP 285 object in a PATH message carries the L3 address of the previous 286 hop device. We will refer to the address contained in the 287 RSVP_HOP object as the RSVP_HOP_L3 address and the corresponding 288 MAC address of the previous hop device will be referred to as the 289 RSVP_HOP_L2 address. 291 4.2. Overview of the SBM-based Admission Control Procedure 293 A protocol entity called "Designated SBM" (DSBM) exists for each 294 managed segment and is responsible for admission control over the 295 resource reservation requests originating from the DSBM clients in 296 that segment. Given a segment, one or more SBMs may exist on the seg- 297 ment. For example, many SBM-capable devices may be attached to a 298 shared L2 segment whereas two SBM-capable switches may share a half- 299 duplex switched segment. In that case, a single DSBM is elected for 300 the segment. The procedure for dynamically electing the DSBM is 301 described in Appendix A. The only other approved method for specifying 302 a DSBM for a managed segment is static configuration at SBM-capable 303 devices. 305 The presence of a DSBM makes the segment a "managed segment". Some- 306 times, two or more L2 segments may be interconnected by SBM tran- 307 sparent devices. In that case, a single DSBM will manage the resources 308 for those segments treating the collection of such segments as a 310 SBM (Subnet Bandwidth Manager) October, 1999 312 single managed segment for the purpose of admission control. 314 SBM (Subnet Bandwidth Manager) October, 1999 316 4.2.1. Basic Algorithm 318 Figure 1 - An Example of a Managed Segment. 320 +-------+ +-----+ +------+ +-----+ +--------+ 321 |Router | | Host| | DSBM | | Host| | Router | 322 | R2 | | C | +------+ | B | | R3 | 323 +-------+ +-----+ / +-----+ +--------+ 324 | | / | | 325 | | / | | 326 ==============================================================LAN 327 | | 328 | | 329 +------+ +-------+ 330 | Host | | Router| 331 | A | | R1 | 332 +------+ +-------+ 334 Figure 1 shows an example of a managed segment in a L2 domain that 335 interconnects a set of hosts and routers. For the purpose of this dis- 336 cussion, we ignore the actual physical topology of the L2 domain 337 (assume it is a shared L2 segment and a single managed segment 338 represents the entire L2 domain). A single SBM device is designated to 339 be the DSBM for the managed segment. We will provide examples of 340 operation of the DSBM over switched and shared segments later in the 341 document. 343 The basic DSBM-based admission control procedure works as follows: 345 1. DSBM Initialization: As part of its initial configuration, DSBM 346 obtains information such as the limits on fraction of available 347 resources that can be reserved on each managed segment under its 348 control. For instance, bandwidth is one such resource. Even 349 though methods such as auto-negotiation of link speeds and 350 knowledge of link topology allow discovery of link capacity, the 351 configuration may be necessary to limit the fraction of link 352 capacity that can be reserved on a link. Configuration is likely 353 to be static with the current L2/L3 devices. Future work may 354 allow for dynamic discovery of this information. This document 355 does not specify the configuration mechanism. 357 2. DSBM Client Initialization: For each interface attached, a DSBM 358 client determines whether a DSBM exists on the interface. The 360 SBM (Subnet Bandwidth Manager) October, 1999 362 procedure for discovering and verifying the existence of the DSBM 363 for an attached segment is described in Appendix A. If the client 364 itself is capable of serving as the DSBM on the segment, it may 365 choose to participate in the election to become the DSBM. At the 366 start, a DSBM client first verifies that a DSBM exists in its L2 367 domain so that it can communicate with the DSBM for admission 368 control purposes. 370 In the case of a full-duplex segment, an election may not be 371 necessary as the SBM at each end will typically act as the DSBM 372 for outgoing traffic in each direction. 374 3. DSBM-based Admission Control: To request reservation of resources 375 (e.g., LAN bandwidth in a L2 domain), DSBM clients (RSVP-capable 376 L3 devices such as hosts and routers) follow the following steps: 378 a) When a DSBM client sends or forwards a RSVP PATH message over 379 an interface attached to a managed segment, it sends the PATH 380 message to the segment's DSBM instead of sending it to the RSVP 381 session destination address (as is done in conventional RSVP 382 processing). After processing (and possibly updating an 383 ADSPEC), the DSBM will forward the PATH message toward its des- 384 tination address. As part of its processing, the DSBM builds 385 and maintains a PATH state for the session and notes the previ- 386 ous L2/L3 hop that sent it the PATH message. 388 Let us consider the managed segment in Figure 1. Assume that a 389 sender to a RSVP session (session address specifies the IP 390 address of host A on the managed segment in Figure 1) resides 391 outside the L2 domain of the managed segment and sends a PATH 392 message that arrives at router R1 which is on the path towards 393 host A. 395 DSBM client on Router R1 forwards the PATH message from the 396 sender to the DSBM. The DSBM processes the PATH message and 397 forwards the PATH message towards the RSVP receiver (Detailed 398 message processing and forwarding rules are described in Sec- 399 tion 5). In the process, the DSBM builds the PATH state, 400 remembers the router R1 (its L2 and l3 addresses) as the previ- 401 ous hop for the session, puts its own L2 and L3 addresses in 402 the PHOP objects (see explanation later), and effectively 403 inserts itself as an intermediate node between the sender (or 404 R1 in Figure 1) and the receiver (host A) on the managed seg- 405 ment. 407 b) When an application on host A wishes to make a reservation for 409 SBM (Subnet Bandwidth Manager) October, 1999 411 the RSVP session, host A follows the standard RSVP message pro- 412 cessing rules and sends a RSVP RESV message to the previous hop 413 L2/L3 address (the DSBMs address) obtained from the PHOP 414 object(s) in the previously received PATH message. 416 c) The DSBM processes the RSVP RESV message based on the bandwidth 417 available and returns an RESV_ERR message to the requester (host 418 A) if the request cannot be granted. If sufficient resources 419 are available and the reservation request is granted, the DSBM 420 forwards the RESV message towards the PHOP(s) based on its 421 local PATH state for the session. The DSBM merges reservation 422 requests for the same session as and when possible using the 423 rules similar to those used in the conventional RSVP processing 424 (except for an additional criterion described in Section 5.9). 426 d) If the L2 domain contains more than one managed segment, the 427 requester (host A) and the forwarder (router R1) may be 428 separated by more than one managed segment. In that case, the 429 original PATH message would propagate through many DSBMs (one 430 for each managed segment on the path from R1 to A) setting up 431 PATH state at each DSBM. Therefore, the RESV message would pro- 432 pagate hop-by-hop in reverse through the intermediate DSBMs and 433 eventually reach the original forwarder (router R1) on the L2 434 domain if admission control at all DSBMs succeeds. 436 4.2.2. Enhancements to the conventional RSVP operation 438 (D)SBMs and DSBM clients implement minor additions to the standard 439 RSVP protocol. These are summarized in this section. A detailed 440 description of the message processing and forwarding rules follows in 441 section 5. 443 4.2.2.1 Sending PATH Messages to the DSBM on a Managed Segment 445 Normal RSVP forwarding rules apply at a DSBM client when it is not 446 forwarding an outgoing PATH message over a managed segment. However, 447 outgoing PATH messages on a managed segment are sent to the DSBM for 448 the corresponding managed segment (Section 5.2 describes how the PATH 449 messages are sent to the DSBM on a managed segment). 451 4.2.2.2 The LAN_NHOP Objects 453 In conventional RSVP processing over point-to-point links, RSVP nodes 454 (hosts/routers) use RSVP_HOP object (NHOP and PHOP info) to keep track 455 of the next hop (downstream node in the path of data packets in a 457 SBM (Subnet Bandwidth Manager) October, 1999 459 traffic flow) and the previous hop (upstream nodes with respect to the 460 data flow) nodes on the path between a sender and a receiver. Routers 461 along the path of a PATH message forward the message towards the des- 462 tination address based on the L3 routing (packet forwarding) tables. 464 For example, consider the L2 domain in Figure 1. Assume that both the 465 sender (some host X) and the receiver (some host Y) in a RSVP session 466 reside outside the L2 domain shown in the Figure, but PATH messages 467 from the sender to its receiver pass through the routers in the L2 468 domain using it as a transit subnet. Assume that the PATH message from 469 the sender X arrives at the router R1. R1 uses its local routing 470 information to decide which next hop router (either router R2 or 471 router R3) to use to forward the PATH message towards host Y. However, 472 when the path traverses a managed L2 domain, we require the PATH and 473 RESV messages to go through a DSBM for each managed segment. Such a L2 474 domain may span many managed segments (and DSBMs) and, typically, SBM 475 protocol entities on L2 devices (such as a switch) will serve as the 476 DSBMs for the managed segments in a switched topology. When R1 for- 477 wards the PATH message to the DSBM (an L2 device), the DSBM may not 478 have the L3 routing information necessary to select the egress router 479 (between R2 and R3) before forwarding the PATH message. To ensure 480 correct operation and routing of RSVP messages, we must provide addi- 481 tional forwarding information to DSBMs. 483 For this purpose, we introduce new RSVP objects called LAN_NHOP 484 address objects that keep track of the next L3 hop as the PATH message 485 traverses an L2 domain between two L3 entities (RSVP PHOP and NHOP 486 nodes). 488 4.2.2.3 Including Both Layer-2 and Layer-3 Addresses in the LAN_NHOP 490 When a DSBM client (a host or a router acting as the originator of a 491 PATH message) sends out a PATH message to the DSBM, it must include 492 LAN_NHOP information in the message. In the case of a unicast destina- 493 tion, the LAN_NHOP address specifies the destination address (if the 494 destination is local to its L2 domain) or the address of the next hop 495 router towards the destination. In our example of an RSVP session 496 involving the sender X and receiver Y with L2 domain in Figure 1 act- 497 ing as the transit subnet, R1 is the ingress node that receives the 498 PATH message. R1 first determines that R2 is the next hop router (or 499 the egress node in the L2 domain for the session address) and then 500 inserts a LAN_NHOP object that specifies R2's IP address. When a DSBM 501 receives a PATH message, it can now look at the address in the 502 LAN_NHOP object and forward the PATH message towards the egress node 503 after processing the PATH message. However, we expect the L2 devices 504 (such as switches) to act as DSBMs on the path within the L2 domain 505 and it may not be reasonable to expect these devices to have an ARP 506 capability to determine the MAC address (we call it L2ADDR for Layer 2 508 SBM (Subnet Bandwidth Manager) October, 1999 510 address) corresponding to the IP address in the LAN_NHOP object. 512 Therefore, we require that the LAN_NHOP information (generated by the 513 L3 device) include both the IP address (LAN_NHOP_L3 address) and the 514 corresponding MAC address (LAN_NHOP_L2 address ) for the next L3 hop 515 over the L2 domain. The LAN_NHOP_L3 address is used by SBM protocol 516 entities on L3 devices to forward the PATH message towards its desti- 517 nation whereas the L2 address is used by the SBM protocol entities on 518 L2 devices to determine how to forward the PATH message towards the L3 519 NHOP (egress point from the L2 domain). The exact format of the 520 LAN_NHOP information and relevant objects is described later in Appen- 521 dix B. 523 4.2.2.4 Similarities to Standard RSVP Message Processing 525 - When a DSBM receives a RSVP PATH message, it processes the PATH 526 message according to the PATH processing rules described in the 527 RSVP specification. In particular, the DSBM retrieves the IP 528 address of the previous hop from the RSVP_HOP object in the PATH 529 message and stores the PHOP address in its PATH state. It then 530 forwards the PATH message with the PHOP (RSVP_HOP) object modi- 531 fied to reflect its own IP address (RSVP_HOP_L3 address). Thus, 532 the DSBM inserts itself as an intermediate hop in the chain of 533 nodes in the path between two L3 nodes across the L2 domain. 535 - The PATH state in a DSBM is used for forwarding subsequent RESV 536 messages as per the standard RSVP message processing rules. When 537 the DSBM receives a RESV message, it processes the message and 538 forwards it to appropriate PHOP(s) based on its PATH state. 540 - Because a DSBM inserts itself as a hop between two RSVP nodes in 541 the path of a RSVP flow, all RSVP related messages (such as PATH, 542 PATH_TEAR, RESV, RESV_CONF, RESV_TEAR, and RESV_ERR) now flow 543 through the DSBM. In particular, a PATH_TEAR message is routed 544 exactly through the intermediate DSBM(s) as its corresponding 545 PATH message and the local PATH state is first cleaned up at each 546 intermediate hop before the PATH_TEAR message gets forwarded. 548 - So far, we have described how the PATH message propagates through 549 the L2 domain establishing PATH state at each DSBM along the 550 managed segments in the path. The layer 2 address (LAN_NHOP_L2 551 address) in the LAN_NHOP object should be used by the L2 devices 552 along the path to decide how to forward the PATH message toward 553 the next L3 hop. Such devices will apply the standard IEEE 555 SBM (Subnet Bandwidth Manager) October, 1999 557 802.1D forwarding rules (e.g., send it on a single port based on 558 its filtering database, or flood it on all ports active in the 559 spanning tree if the L2 address does not appear in the filtering 560 database) to the LAN_NHOP_L2 address as are applied normally to 561 data packets destined to the address. 563 4.2.2.5 Including Both Layer-2 and Layer-3 Addresses in the 564 RSVP_HOP Objects 566 In the conventional RSVP message processing, the PATH state esta- 567 blished along the nodes on a path is used to route the RESV message 568 from a receiver to a sender in an RSVP session. As each intermediate 569 node builds the path state, it remembers the previous hop (stores the 570 PHOP IP address available in the RSVP_HOP object of an incoming mes- 571 sage) that sent it the PATH message and, when the RESV message 572 arrives, the intermediate node simply uses the stored PHOP address to 573 forward the RESV after processing it successfully. 575 In our case, we expect the SBM entities residing at L2 devices to act 576 as DSBMs (and, therefore, intermediate RSVP hops in an L2 domain) 577 along the path between a sender (PHOP) and receiver (NHOP). Thus, when 578 a RESV message arrives at a DSBM, it must use the stored PHOP IP 579 address to forward the RESV message to its previous hop. However, it 580 may not be reasonable to expect the L2 devices to have an ARP cache or 581 the ARP capability to map the PHOP IP address to its corresponding L2 582 address before forwarding the RESV message. 584 To obviate the need for such address mapping at L2 devices, we use a 585 RSVP_HOP_L2 object in the PATH message. The RSVP_HOP_L2 object 586 includes the Layer 2 address (L2ADDR) of the previous hop and comple- 587 ments the L3 address information included in the RSVP_HOP object 588 (RSVP_HOP_L3 address). 590 When a L3 device constructs and forwards a PATH message over a managed 591 segment, it includes its IP address (IP address of the interface over 592 which PATH is sent) in the RSVP_HOP object and adds a RSVP_HOP_L2 593 object that includes the corresponding L2 address for the interface. 594 When a device in the L2 domain receives such a PATH message, it 595 remembers the addresses in the RSVP_HOP and RSVP_HOP_L2 objects in its 596 PATH state and then overwrites the RSVP_HOP and RSVP_HOP_L2 objects 597 with its own addresses before forwarding the PATH message over a 598 managed segment. 600 The exact format of RSVP_HOP_L2 object is specified in Appendix B. 602 4.2.2.6 Loop Detection 604 When an RSVP session address is a multicast address and a SBM, DSBM, 606 SBM (Subnet Bandwidth Manager) October, 1999 608 and DSBM clients share the same L2 segment (a shared segment), it is 609 possible for a SBM or a DSBM client to receive one or more copies of a 610 PATH message that it forwarded earlier when a DSBM on the same wire 611 forwards it (See Section 5.8 for an example of such a case). To facil- 612 itate detection of such loops, we use a new RSVP object called the 613 LAN_LOOPBACK object. DSBM clients or SBMs (but not the DSBMs reflect- 614 ing a PATH message onto the interface over which it arrived earlier) 615 must overwrite (or add if the PATH message does NOT already include a 616 LAN_LOOPBACK object) the LAN_LOOPBACK object in the PATH message with 617 their own unicast IP address. 619 Now, a SBM or a DSBM client can easily detect and discard the dupli- 620 cates by checking the contents of the LAN_LOOPBACK object (a duplicate 621 PATH message will list a device's own interface address in the 622 LAN_LOOPBACK object). Appendix B specifies the exact format of the 623 LAN_LOOPBACK object. 625 4.2.2.7 802.1p, User Priority and TCLASS 627 The model proposed by the Integrated Services working group requires 628 isolation of traffic flows from each other during their transit across 629 a network. The motivation for traffic flow separation is to provide 630 Integrated Services flows protection from misbehaving flows and other 631 best-effort traffic that share the same path. The basic IEEE 632 802.3/Ethernet networks do not provide any notion of traffic classes 633 to discriminate among different flows that request different services. 634 However, IEEE 802.1p defines a way for switches to differentiate among 635 several "user_priority" values encoded in packets representing dif- 636 ferent traffic classes (see [IEEE802Q, IEEE8021p] for further 637 details). The user_priority values can be encoded either in native LAN 638 packets (e.g., in IEEE 802.5's FC octet) or by using an encapsulation 639 above the MAC layer (e.g., in the case of Ethernet, the user_priority 640 value assigned to each packet will be carried in the frame header 641 using the new, extended frame format defined by IEEE 802.1Q 642 [IEEE8021Q]. IEEE, however, makes no recommendations about how a 643 sender or network should use the user_priority values. An accompanying 644 document makes recommendations on the usage of the user_priority 645 values (see [RFC-MAP] for details). 647 Under the Integrated Services model, L3 (or higher) entities that 648 transmit traffic flows onto a L2 segment should perform per-flow pol- 649 icing to ensure that the flows do not exceed their traffic specifica- 650 tion as specified during admission control. In addition, L3 devices 651 may label the frames in such flows with a user_priority value to iden- 652 tify their service class. 654 For the purpose of this discussion, we will refer to the user_priority 655 value carried in the extended frame header as the "traffic class" of a 657 SBM (Subnet Bandwidth Manager) October, 1999 659 packet. Under the ISSLL model, the L3 entities, that send traffic and 660 that use the SBM protocol, may select the appropriate traffic class of 661 outgoing packets [RFC-MAP]. This selection may be overridden by DSBM 662 devices, in the following manner. once a sender sends a PATH message, 663 downstream DSBMs will insert a new traffic class object (TCLASS 664 object) in the PATH message that travels to the next L3 device (L3 665 NHOP for the PATH message). To some extent, the TCLASS object contents 666 are treated like the ADSPEC object in the RSVP PATH messages. The L3 667 device that receives the PATH message must remove and store the TCLASS 668 object as part of its PATH state for the session. Later, when the same 669 L3 device needs to forward a RSVP RESV message towards the original 670 sender, it must include the TCLASS object in the RESV message. When 671 the RESV message arrives at the original sender, the sender must use 672 the user_priority value from the TCLASS object to override its selec- 673 tion for the traffic class marked in outgoing packets. 675 The format of the TCLASS object is specified in Appendix B. Note that 676 TCLASS and other SBM-specific objects are carried in a RSVP message in 677 addition to all the other, normal RSVP objects per RFC 2205. 679 4.2.2.8 Processing the TCLASS Object 681 In summary, use of TCLASS objects requires following additions to the 682 conventional RSVP message processing at DSBMs, SBMs, and DSBM clients: 684 * When a DSBM receives a PATH message over a managed segment and 685 the PATH message does not include a TCLASS object, the DSBM MAY 686 add a TCLASS object to the PATH message before forwarding it. 687 The DSBM determines the appropriate user_priority value for the 688 TCLASS object. A mechanism for selecting the appropriate 689 user_priority value is described in an accompanying document 690 [RFC-MAP]. 692 * When SBM or DSBM receives a PATH message with a TCLASS object 693 over a managed segment in a L2 domain and needs to forward it 694 over a managed segment in the same L2 domain, it will store it 695 in its path state and typically forward the message without 696 changing the contents of the TCLASS object. However, if the 697 DSBM/SBM cannot support the service class represented by the 698 user_priority value specified by the TCLASS object in the PATH 699 message, it may change the priority value in the TCLASS to a 700 semantically "lower" service value to reflect its capability 701 and store the changed TCLASS value in its path state. 703 [NOTE: An accompanying document defines the int-serv mappings 705 SBM (Subnet Bandwidth Manager) October, 1999 707 over IEEE 802 networks [RFC-MAP] provides a precise definition 708 of user_priority values and describes how the user_priority 709 values are compared to determine "lower" of the two values or 710 the "lowest" among all the user_priority values.] 712 * When a DSBM receives a RESV message with a TCLASS object, it 713 may use the traffic class information (in addition to the usual 714 flowspec information in the RSVP message) for its own admission 715 control for the managed segment. 717 Note that this document does not specify the actual algorithm 718 or policy used for admission control. At one extreme, a DSBM 719 may use per-flow reservation request as specified by the 720 flowspec for a fine grain admission control. At the other 721 extreme, a DSBM may only consider the traffic class information 722 for a very coarse-grain admission control based on some static 723 allocation of link capacity for each traffic class. Any combi- 724 nation of the options represented by these two extremes may 725 also be used. 727 * When a DSBM (at an L2 or L3) device receives a RESV message 728 without a TCLASS object and it needs to forward the RESV mes- 729 sage over a managed segment within the same L2 domain, it 730 should first check its path state and check whether it has 731 stored a TCLASS value. If so, it should include the TCLASS 732 object in the outgoing RESV message after performing its own 733 admission control. If no TCLASS value is stored, it must for- 734 ward the RESV message without inserting a TCLASS object. 736 * When a DSBM client (residing at an L3 device such as a host or 737 an edge router) receives the TCLASS object in a PATH message 738 that it accepts over an interface, it should store the TCLASS 739 object as part of its PATH state for the interface. Later, when 740 the client forwards a RESV message for the same session on the 741 interface, the client must include the TCLASS object (unchanged 742 from what was received in the previous PATH message) in the 743 RESV message it forwards over the interface. 745 * When a DSBM client receives a TCLASS object in an incoming RESV 746 message over a managed segment and local admission control 747 succeeds for the session for the outgoing interface over the 748 managed segment, the client must pass the user_priority value 749 in the TCLASS object to its local packet classifier. This will 750 ensure that the data packets in the admitted RSVP flow that are 751 subsequently forwarded over the outgoing interface will contain 753 SBM (Subnet Bandwidth Manager) October, 1999 755 the appropriate value encoded in their frame header. 757 * When an L3 device receives a PATH or RESV message over a 758 managed segment in one L2 domain and it needs to forward the 759 PATH/RESV message over an interface outside that domain, the L3 760 device must remove the TCLASS object (along with LAN_NHOP, 761 RSVP_HOP_L2, and LAN_LOOPBACK objects in the case of the PATH 762 message) before forwarding the PATH/RESV message. If the outgo- 763 ing interface is on a separate L2 domain, these objects may be 764 regenerated according to the processing rules applicable to 765 that interface. 767 5. Detailed Message Processing Rules 769 5.1. Additional Notes on Terminology 771 * An L2 device may have several interfaces with attached segments 772 that are part of the same L2 domain. A switch in a L2 domain is 773 an example of such a device. A device which has several inter- 774 faces may contain a SBM protocol entity that acts in different 775 capacities on each interface. For example, a SBM protocol entity 776 could act as a SBM on interface A, and act as a DSBM on interface 777 B. 779 * A SBM protocol entity on a layer 3 device can be a DSBM client, 780 and SBM, a DSBM, or none of the above (SBM transparent). Non- 781 transparent L3 devices can implement any combination of these 782 roles simultaneously. DSBM clients always reside at L3 devices. 784 * A SBM protocol entity residing at a layer 2 device can be a SBM, 785 a DSBM or none of the above (SBM transparent). A layer 2 device 786 will never host a DSBM client. 788 5.2. Use Of Reserved IP Multicast Addresses 790 As stated earlier, we require that the DSBM clients forward the RSVP 791 PATH messages to their DSBMs in a L2 domain before they reach the next 793 SBM (Subnet Bandwidth Manager) October, 1999 795 L3 hop in the path. RSVP PATH messages are addressed, according to 796 RFC-2205, to their destination address (which can be either an IP uni- 797 cast or multicast address). When a L2 device hosts a DSBM, a simple- 798 to-implement mechanism must be provided for the device to capture an 799 incoming PATH message and hand it over to the local DSBM agent without 800 requiring the L2 device to snoop for L3 RSVP messages. 802 In addition, DSBM clients need to know how to address SBM messages to 803 the DSBM. For the ease of operation and to allow dynamic DSBM-client 804 binding, it should be possible to easily detect and address the exist- 805 ing DSBM on a managed segment. 807 To facilitate dynamic DSBM-client binding as well as to enable easy 808 detection and capture of PATH messages at L2 devices, we require that 809 a DSBM be addressed using a logical address rather than a physical 810 address. We make use of reserved IP multicast address(es) for the pur- 811 pose of communication with a DSBM. In particular, we require that 812 when a DSBM client or a SBM forwards a PATH message over a managed 813 segment, it is addressed to a reserved IP multicast address. Thus, a 814 DSBM on a L2 device needs to be configured in a way to make it easy to 815 intercept the PATH message and forward it to the local SBM protocol 816 entity. For example, this may involve simply adding a static entry in 817 the device's filtering database (FDB) for the corresponding MAC multi- 818 cast address to ensure the PATH messages get intercepted and are not 819 forwarded further without the DSBM intervention. 821 Similarly, a DSBM always sends the PATH messages over a managed seg- 822 ment using a reserved IP multicast address and, thus, the SBMs or DSBM 823 clients on the managed segments must simply be configured to intercept 824 messages addressed to the reserved multicast address on the appropri- 825 ate interfaces to easily receive PATH messages. 827 RSVP RESV messages continue to be unicast to the previous hop address 828 stored as part of the PATH state at each intermediate hop. 830 We define use of two reserved IP multicast addresses. We call these 831 the "AllSBM Address" and the "DSBMLogicalAddress". These are chosen 832 from the range of local multicast addresses, such that: 834 * They are not passed through layer 3 devices. 836 * They are passed transparently through layer 2 devices which are 837 SBM transparent. 839 SBM (Subnet Bandwidth Manager) October, 1999 841 * They are configured in the permanent database of layer 2 devices 842 which host SBMs or DSBMs, such that they are directed to the SBM 843 management entity in these devices. This obviates the need for 844 these devices to explicitly snoop for SBM related control pack- 845 ets. 847 * The two reserved addresses are 224.0.0.16 (DSBMLogicalAddress) 848 and 224.0.0.17 (AllSBMAddress). 850 These addresses are used as described in the following table: 852 Type DSBMLogicaladdress AllSBMAddress 854 DSBM * Sends PATH messages * Monitors this address to detect 855 Client to this address the presence of a DSBM 856 * Monitors this address to 857 receive PATH messages 858 forwarded by the DSBM 860 SBM * Sends PATH messages * Monitors and sends on this 861 to this address address to participate in 862 election of the DSBM 863 * Monitors this address to 864 receive PATH messages 865 forwarded by the DSBM 867 DSBM * Monitors this address * Monitors and sends on this 868 for PATH messages to participate in election 869 directed to it of the DSBM 870 * Sends PATH messages to this 871 address 873 The L2 or MAC addresses corresponding to IP multicast addresses are 874 computed algorithmically using a reserved L2 address block (the high 875 order 24-bits are 00:00:5e). The Assigned Numbers RFC [RFC-1700] gives 876 additional details. 878 5.3. Layer 3 to Layer 2 Address Mapping 880 As stated earlier, DSBMs or DSBM clients residing at a L3 device must 881 include a LAN_NHOP_L2 address in the LAN_NHOP information so that L2 882 devices along the path of a PATH message do not need to separately 883 determine the mapping between the LAN_NHOP_L3 address in the LAN_NHOP 884 object and its corresponding L2 address (for example, using ARP). 886 SBM (Subnet Bandwidth Manager) October, 1999 888 For the purpose of such mapping at L3 devices, we assume a mapping 889 function called "map_address" that performs the necessary mapping: 891 L2ADDR object = map_addr(L3Addr) 893 We do not specify how the function is implemented; the implementation 894 may simply involve access to the local ARP cache entry or may require 895 performing an ARP function. The function returns a L2ADDR object that 896 need not be interpreted by an L3 device and can be treated as an 897 opaque object. The format of the L2ADDR object is specified in Appen- 898 dix B. 900 5.4. Raw vs. UDP Encapsulation 902 We assume that the DSBMs, DSBM clients, and SBMs use only raw IP for 903 encapsulating RSVP messages that are forwarded onto a L2 domain. 904 Thus, when a SBM protocol entity on a L3 device forwards a RSVP mes- 905 sage onto a L2 segment, it will only use RAW IP encapsulation. 907 5.5. The Forwarding Rules 909 The message processing and forwarding rules will be described in the 910 context of the sample network illustrated in Figure 2. 912 SBM (Subnet Bandwidth Manager) October, 1999 914 Figure 2 - A sample network or L2 domain consisting of switched and 915 shared L2 segments 917 .......... 918 . 919 +------+ . +------+ seg A +------+ seg C +------+ seg D +------+ 920 | H1 |_______| R1 |_________| S1 |_________| S2 |_________| H2 | 921 | | . | | | | | | | | 922 +------+ . +------+ +------+ +------+ +------+ 923 . | / 924 1.0.0.0 . | / 925 . |___ / 926 . seg B | / seg E 927 .......... | / 928 2.0.0.0 | / 929 +-----------+ 930 | S3 | 931 | | 932 +-----------+ 933 | 934 | 935 | 936 | 937 seg F | ................. 938 ------------------------------ . 939 | | | . 940 +------+ +------+ +------+ . +------+ 941 | H3 | | H4 | | R2 |____________| H5 | 942 | | | | | | . | | 943 +------+ +------+ +------+ . +------+ 944 . 945 . 3.0.0.0 946 ................. 948 Figure 2 illustrates a sample network topology consisting of three IP 949 subnets (1.0.0.0, 2.0.0.0, and 3.0.0.0) interconnected using two 950 routers. The subnet 2.0.0.0 is an example of a L2 domain consisting of 951 switches, hosts, and routers interconnected using switched segments 952 and a shared L2 segment. The sample network contains the following 953 devices: 955 Device Type SBM Type 957 H1, H5 Host (layer 3) SBM Transparent 958 H2-H4 Host (layer 3) DSBM Client 959 R1 Router (layer 3) SBM 960 R2 Router (layer 3) DSBM for segment F 962 SBM (Subnet Bandwidth Manager) October, 1999 964 S1 Switch (layer 2) DSBM for segments A, B 965 S2 Switch (layer 2) DSBM for segments C, D, E 966 S3 Switch (layer 2) SBM 968 The following paragraphs describe the rules, which each of these dev- 969 ices should use to forward PATH messages (rules apply to PATH_TEAR 970 messages as well). They are described in the context of the general 971 network illustrated above. While the examples do not address every 972 scenario, they do address most of the interesting scenarios. Excep- 973 tions can be discussed separately. 975 The forwarding rules are applied to received PATH messages (routers 976 and switches) or originating PATH messages (hosts), as follows: 978 1. Determine the interface(s) on which to forward the PATH message 979 using standard forwarding rules: 981 * If there is a LAN_LOOPBACK object in the PATH message, and it 982 carries the address of this device, silently discard the message. 983 (See the section below on "Additional notes on forwarding the 984 PATH message onto a managed segment). 986 * Layer 3 devices use the RSVP session address and perform a rout- 987 ing lookup to determine the forwarding interface(s). 989 * Layer 2 devices use the LAN_NHOP_L2 address in the LAN_NHOP 990 information and MAC forwarding tables to determine the forwarding 991 interface(s). (See the section below on "Additional notes on for- 992 warding the PATH message onto a managed segment") 994 2. For each forwarding interface: 996 * If the device is a layer 3 device, determine whether the inter- 997 face is on a managed segment managed by a DSBM, based on the 998 presence or absence of I_AM_DSBM messages. If the interface is 999 not on a managed segment, strip out RSVP_HOP_L2, LAN_NHOP, 1000 LAN_LOOPBACK, and TCLASS objects (if present), and forward to 1001 the unicast or multicast destination. 1003 (Note that the RSVP Class Numbers for these new objects are 1005 SBM (Subnet Bandwidth Manager) October, 1999 1007 chosen so that if an RSVP message includes these objects, the 1008 nodes that are RSVP-aware, but do not participate in the SBM 1009 protocol, will ignore and silently discard such objects.) 1011 * If the device is a layer 2 device or it is a layer 3 device 1012 *and* the interface is on a managed segment, proceed to rule 1013 #3. 1015 3. Forward the PATH message onto the managed segment: 1017 * If the device is a layer 3 device, insert LAN_NHOP address 1018 objects, a LAN_LOOPBACK, and a RSVP_HOP_L2 object into the PATH 1019 message. The LAN_NHOP objects carry the LAN_NHOP_L3 and 1020 LAN_NHOP_L2 addresses of the next layer 3 hop. The RSVP_HOP_L2 1021 object carries the device's own L2 address, and the 1022 LAN_LOOPBACK object contains the IP address of the outgoing 1023 interface. 1025 An L3 device should use the map_addr() function described ear- 1026 lier to obtain an L2 address corresponding to an IP address. 1028 * If the device hosts the DSBM for the segment to which the for- 1029 warding interface is attached, do the following: 1031 - Retrieve the PHOP information from the standard RSVP HOP 1032 object in the PATH message, and store it. This will be used 1033 to route RESV messages back through the L2 network. If the 1034 PATH message arrived over a managed segment, it will also 1035 contain the RSVP_HOP_L2 object; then retrieve and store also 1036 the previous hop's L2 address in the PATH state. 1038 - Copy the IP address of the forwarding interface (layer 2 dev- 1039 ices must also have IP addresses) into the standard RSVP HOP 1040 object and the L2 address of the forwarding interface into 1041 the RSVP_HOP_L2 object. 1043 - If the PATH message received does not contain the TCLASS 1044 object, insert a TCLASS object. The user_priority value 1045 inserted in the TCLASS object is based on service mappings 1046 internal to the device that are configured according to the 1047 guidelines listed in [RFC-MAP]. If the message already 1049 SBM (Subnet Bandwidth Manager) October, 1999 1051 contains the TCLASS object, the user_priority value may be 1052 changed based again on the service mappings internal to the 1053 device. 1055 * If the device is a layer 3 device and hosts a SBM for the seg- 1056 ment to which the forwarding interface is attached, it *is 1057 required* to retrieve and store the PHOP info. 1059 If the device is a layer 2 device and hosts a SBM for the seg- 1060 ment to which the forwarding interface is attached, it is *not* 1061 required to retrieve and store the PHOP info. If it does not do 1062 so, the SBM must leave the standard RSVP HOP object and the 1063 RSVP_HOP_L2 objects in the PATH message intact and it will not 1064 receive RESV messages. 1066 If the SBM on a L2 device chooses to overwrite the RSVP HOP and 1067 RSVP_HOP_L2 objects with the IP and L2 addresses of its for- 1068 warding interface, it will receive RESV messages. In this case, 1069 it must store the PHOP address info received in the standard 1070 RSVP_HOP field and RSVP_HOP_L2 objects of the incident PATH 1071 message. 1073 In both the cases mentioned above (L2 or L3 devices), the SBM 1074 must forward the TCLASS object in the received PATH message 1075 unchanged. 1077 * Copy the IP address of the forwarding interface into the 1078 LAN_LOOPBACK object, unless the SBM protocol entity is a DSBM 1079 reflecting a PATH message back onto the incident interface. 1080 (See the section below on "Additional notes on forwarding a 1081 PATH message onto a managed segment"). 1083 * If the SBM protocol entity is the DSBM for the segment to which 1084 the forwarding interface is attached, it must send the PATH 1085 message to the AllSBMAddress. 1087 * If the SBM protocol entity is a SBM or a DSBM Client on the 1088 segment to which the forwarding interface is attached, it must 1089 send the PATH message to the DSBMLogicalAddress. 1091 5.6.1. Additional notes on forwarding a PATH message onto a 1093 SBM (Subnet Bandwidth Manager) October, 1999 1095 managed segment 1097 Rule #1 states that normal IEEE 802.1D forwarding rules should be 1098 used to determine the interfaces on which the PATH message should 1099 be forwarded. In the case of data packets, standard forwarding 1100 rules at a L2 device dictate that the packet should not be for- 1101 warded on the interface from which it was received. However, in 1102 the case of a DSBM that receives a PATH message over a managed 1103 segment, the following exception applies: 1105 E1. If the address in the LAN_NHOP object is a unicast address, 1106 consult the filtering database (FDB) to determine whether 1107 the destination address is listed on the same interface 1108 over which the message was received. If yes, follow the 1109 rule below on "reflecting a PATH message back onto an 1110 interface" described below; otherwise, proceed with the 1111 rest of the message processing as usual. 1113 E2. If there are members of the multicast group address (speci- 1114 fied by the addresses in the LAN_NHOP object), on the seg- 1115 ment from which the message was received, the message 1116 should be forwarded back onto the interface from which it 1117 was received and follow the rule on "reflecting a PATH mes- 1118 sage back onto an interface" described below. 1120 *** Reflecting a PATH message back onto an interface *** 1122 Under the circumstances described above, when a DSBM reflects 1123 the PATH message back onto an interface over which it was 1124 received, it must address it using the AllSBMAddress. 1126 Since it is possible for a DSBM to reflect a PATH message back 1127 onto the interface from which it was received, precautions must 1128 be taken to avoid looping these messages indefinitely. The 1129 LAN_LOOPBACK object addresses this issue. All SBM protocol enti- 1130 ties (except DSBMs reflecting a PATH message) overwrite the 1131 LAN_LOOPBACK object in the PATH message with the IP address of 1132 the outgoing interface. DSBMs which are reflecting a PATH mes- 1133 sage, leave the LAN_LOOPBACK object unchanged. Thus, SBM proto- 1134 col entities will always be able to recognize a reflected multi- 1135 cast message by the presence of their own address in the 1136 LAN_LOOPBACK object. These messages should be silently dis- 1137 carded. 1139 SBM (Subnet Bandwidth Manager) October, 1999 1141 5.7. Applying the Rules -- Unicast Session 1143 Let's see how the rules are applied in the general network illus- 1144 trated previously (see Figure 2). 1146 Assume that H1 is sending a PATH for a unicast session for which 1147 H5 is the receiver. The following PATH message is composed by H1: 1149 RSVP Contents 1150 RSVP session IP address IP address of H5 (3.0.0.35) 1151 Sender Template IP address of H1 (1.0.0.11) 1152 PHOP IP address of H1 (1.0.0.11) 1153 RSVP_HOP_L2 n/a (H1 is not sending onto a managed 1154 segment) 1155 LAN_NHOP n/a (H1 is not sending onto a managed 1156 segment) 1157 LAN_LOOPBACK n/a (H1 is not sending onto a managed 1158 segment) 1160 IP Header 1161 Source address IP address of H1 (1.0.0.11) 1162 Destn address IP addr of H5 (3.0.0.35, assuming raw mode & 1163 router alert) 1165 MAC Header 1166 Destn address The L2 addr corresponding to R1 (determined 1167 by map_addr() and routing tables at H1) 1169 Since H1 is not sending onto a managed segment, the PATH message 1170 is composed and forwarded according to standard RSVP processing 1171 rules. 1173 Upon receipt of the PATH message, R1 composes and forwards a PATH 1174 message as follows: 1176 RSVP Contents 1177 RSVP session IP address IP address of H5 1178 Sender Template IP address of H1 1179 PHOP IP address of R1 (2.0.0.1) 1180 (seed the return path for RESV messages) 1181 RSVP_HOP_L2 L2 address of R1 1182 LAN_NHOP LAN_NHOP_L3 (2.0.0.2) and 1183 LAN_NHOP_L2 address of R2 (L2ADDR) 1184 (this is the next layer 3 hop) 1185 LAN_LOOPBACK IP address of R1 (2.0.0.1) 1187 IP Header 1189 SBM (Subnet Bandwidth Manager) October, 1999 1191 Source address IP address of H1 1192 Destn address DSBMLogical IP address (224.0.0.16) 1194 MAC Header 1195 Destn address DSBMLogical MAC address 1197 * R1 does a routing lookup on the RSVP session address, to 1198 determine the IP address of the next layer 3 hop, R2. 1200 * It determines that R2 is accessible via seg A and that seg A 1201 is managed by a DSBM, S1. 1203 * Therefore, it concludes that it is sending onto a managed 1204 segment, and composes LAN_NHOP objects to carry the layer 3 1205 and layer 2 next hop addresses. To compose the LAN_NHOP 1206 L2ADDR object, it invokes the L3 to L2 address mapping function 1207 ("map_address") to find out the MAC address for the next hop 1208 L3 device, and then inserts a LAN_NHOP_L2ADDR object (that 1209 carries the MAC address) in the message. 1211 * Since R1 is not the DSBM for seg A, it sends the PATH message 1212 to the DSBMLogicalAddress. 1214 Upon receipt of the PATH message, S1 composes and forwards a PATH 1215 message as follows: 1217 RSVP Contents 1218 RSVP session IP address IP address of H5 1219 Sender Template IP address of H1 1220 PHOP IP addr of S1 (seed the return path for RESV 1221 messages) 1222 RSVP_HOP_L2 L2 address of S1 1223 LAN_NHOP LAN_NHOP_L3 (IP) and LAN_NHOP_L2 1224 address of R2 1225 (layer 2 devices do not modify the LAN_NHOP) 1226 LAN_LOOPBACK IP addr of S1 1228 IP Header 1229 Source address IP address of H1 1230 Destn address AllSBMIPaddr (224.0.0.17, since S1 is the 1232 SBM (Subnet Bandwidth Manager) October, 1999 1234 DSBM for seg B). 1236 MAC Header 1237 Destn address All SBM MAC address (since S1 is the DSBM for 1238 seg B). 1240 * S1 looks at the LAN_NHOP address information to determine the 1241 L2 address towards which it should forward the PATH message. 1243 * From the bridge forwarding tables, it determines that the L2 1244 address is reachable via seg B. 1246 * S1 inserts the RSVP_HOP_L2 object and overwrites the RSVP HOP 1247 object (PHOP) with its own addresses. 1249 * Since S1 is the DSBM for seg B, it addresses the PATH message 1250 to the AllSBMAddress. 1252 Upon receipt of the PATH message, S3 composes and forwards a 1253 PATH message as follows: 1255 RSVP Contents 1256 RSVP session IP addr IP address of H5 1257 Sender Template IP address of H1 1258 PHOP IP addr of S3 (seed the return 1259 path for RESV messages) 1260 RSVP_HOP_L2 L2 address of S3 1261 LAN_NHOP LAN_NHOP_L3 (IP) and 1262 LAN_NHOP_L2 (MAC) address of R2 1263 (L2 devices don't modify LAN_NHOP) 1264 LAN_LOOPBACK IP address of S3 1266 IP Header 1267 Source address IP address of H1 1268 Destn address DSBMLogical IP addr (since S3 is 1269 not the DSBM for seg F) 1271 MAC Header 1272 Destn address DSBMLogical MAC address 1274 SBM (Subnet Bandwidth Manager) October, 1999 1276 * S3 looks at the LAN_NHOP address information to determine the 1277 L2 address towards which it should forward the PATH message. 1279 * From the bridge forwarding tables, it determines that the L2 1280 address is reachable via segment F. 1282 * It has discovered that R2 is the DSBM for segment F. It 1283 therefore sends the PATH message to the DSBMLogicalAddress. 1285 * Note that S3 may or may not choose to overwrite the PHOP 1286 objects with its own IP and L2 addresses. If it does so, it 1287 will receive RESV messages. In this case, it must also store 1288 the PHOP info received in the incident PATH message so that 1289 it is able to forward the RESV messages on the correct path. 1291 Upon receipt of the PATH message, R2 composes and forwards a PATH 1292 message as follows: 1294 RSVP Contents 1295 RSVP session IP addr IP address of H5 1296 Sender Template IP address of H1 1297 PHOP IP addr of R2 (seed the return path for RESV 1298 messages) 1299 RSVP_HOP_L2 Removed by R2 (R2 is not sending onto a 1300 managed segment) 1301 LAN_NHOP Removed by R2 (R2 is not sending onto a 1302 managed segment) 1304 IP Header 1305 Source address IP address of H1 1306 Destn address IP address of H5, the RSVP session address 1308 MAC Header 1309 Destn address L2 addr corresponding to H5, the next 1310 layer 3 hop 1312 * R2 does a routing lookup on the RSVP session address, to 1313 determine the IP address of the next layer 3 hop, H5. 1315 * It determines that H5 is accessible via a segment for which 1316 there is no DSBM (not a managed segment). 1318 SBM (Subnet Bandwidth Manager) October, 1999 1320 * Therefore, it removes the LAN_NHOP and RSVP_HOP_L2 objects 1321 and places the RSVP session address in the destination 1322 address of the IP header. It places the L2 address of the 1323 next layer 3 hop, into the destination address of the MAC 1324 header and forwards the PATH message to H5. 1326 5.8. Applying the Rules - Multicast Session 1328 The rules described above also apply to multicast (m/c) sessions. 1329 For the purpose of this discussion, it is assumed that layer 2 1330 devices track multicast group membership on each port individu- 1331 ally. Layer 2 devices which do not do so, will merely generate 1332 extra multicast traffic. This is the case for L2 devices which do 1333 not implement multicast filtering or GARP/GMRP capability. 1335 Assume that H1 is sending a PATH for an m/c session for which H3 1336 and H5 are the receivers. The rules are applied as they are in the 1337 unicast case described previously, until the PATH message reaches 1338 R2, with the following exception. The RSVP session address and the 1339 LAN_NHOP carry the destination m/c addresses rather than the uni- 1340 cast addresses carried in the unicast example. 1342 Now let's look at the processing applied by R2 upon receipt of the 1343 PATH message. Recall that R2 is the DSBM for segment F. Therefore, 1344 S3 will have forwarded its PATH message to the DSBMLogicalAddress, 1345 to be picked up by R2. The PATH message will not have been seen by 1346 H3 (one of the m/c receivers), since it monitors only the 1347 AllSBMAddress, not the DSBMLogicalAddress for incoming PATH mes- 1348 sages. We rely on R2 to reflect the PATH message back onto seg f, 1349 and to forward it to H5. R2 forwards the following PATH message 1350 onto seg f: 1352 RSVP Contents 1353 RSVP session addr m/c session address 1354 Sender Template IP address of H1 1355 PHOP IP addr of R2 (seed the return path for 1356 RESV messages) 1357 RSVP_HOP_L2 L2 addr of R2 1358 LAN_NHOP m/c session address and corresponding L2 address 1359 LAN_LOOPBACK IP addr of S3 (DSBMs reflecting a PATH 1360 message don't modify this object) 1362 IP Header 1363 Source address IP address of H1 1365 SBM (Subnet Bandwidth Manager) October, 1999 1367 Destn address AllSBMIP address (since R2 is the DSBM for seg F) 1369 MAC Header 1370 Destn address AllSBMMAC address (since R2 is the 1371 DSBM for seg F) 1373 Since H3 is monitoring the All SBM Address, it will receive the 1374 PATH message reflected by R2. Note that R2 violated the standard 1375 forwarding rules here by sending an incoming message back onto the 1376 interface from which it was received. It protected against loops 1377 by leaving S3's address in the LAN_LOOPBACK object unchanged. 1379 R2 forwards the following PATH message on to H5: 1381 RSVP Contents 1382 RSVP session addr m/c session address 1383 Sender Template IP address of H1 1384 PHOP IP addr of R2 (seed the return path for RESV 1385 messages) 1386 RSVP_HOP_L2 Removed by R2 (R2 is not sending onto a 1387 managed segment) 1388 LAN_NHOP Removed by R2 (R2 is not sending onto a 1389 managed segment) 1390 LAN_LOOPBACK Removed by R2 (R2 is not sending onto a 1391 managed segment) 1393 IP Header 1394 Source address IP address of H1 1395 Destn address m/c session address 1397 MAC Header 1398 Destn address MAC addr corresponding to the m/c 1399 session address 1401 * R2 determines that there is an m/c receiver accessible via a 1402 segment for which there is no DSBM. Therefore, it removes the 1403 LAN_NHOP and RSVP_HOP_L2 objects and places the RSVP session 1404 address in the destination address of the IP header. It 1405 places the corresponding L2 address into the destination 1406 address of the MAC header and multicasts the message towards 1407 H5. 1409 5.9. Merging Traffic Class objects 1411 SBM (Subnet Bandwidth Manager) October, 1999 1413 When a DSBM client receives TCLASS objects from different senders 1414 (different PATH messages) in the same RSVP session and needs to 1415 combine them for sending back a single RESV message (as in a 1416 wild-card style reservation), the DSBM client must choose an 1417 appropriate value that corresponds to the desired-delay traffic 1418 class. An accompanying document discusses the guidelines for 1419 traffic class selection based on desired service and the TSpec 1420 information [RFC-MAP]. 1422 In addition, when a SBM or DSBM needs to merge RESVs from dif- 1423 ferent next hops at a merge point, it must decide how to handle 1424 the TCLASS values in the incoming RESVs if they do not match. Con- 1425 sider the case when a reservation is in place for a flow at a DSBM 1426 (or SBM) with a successful admission control done for the TCLASS 1427 requested in the first RESV for the flow. If another RESV (not the 1428 refresh of the previously admitted RESV) for the same flow arrives 1429 at the DSBM, the DSBM must first check the TCLASS value in the new 1430 RESV against the TCLASS value in the already installed RESV. If 1431 the two values are same, the RESV requests are merged and the new, 1432 merged RESV installed and forwarded using the normal rules of mes- 1433 sage processing. However, if the two values are not identical, the 1434 DSBM must generate and send a RESV_ERR message towards the sender 1435 (NHOP) of the newer, RESV message. The RESV_ERR must specify the 1436 error code corresponding to the RSVP "traffic control error" 1437 (RESV_ERR code 21) that indicates failure to merge two incompati- 1438 ble service requests (sub-code 01 for the RSVP traffic control 1439 error) [RFC-2205]. The RESV_ERR message may include additional 1440 objects to assist downstream nodes in recovering from this condi- 1441 tion. The definition and usage of such objects is beyond the 1442 scope of this draft. 1444 5.10. Operation of SBM Transparent Devices 1446 SBM transparent devices are unaware of the entire SBM/DSBM proto- 1447 col. They do not intercept messages addressed to either of the SBM 1448 related local group addresses (the DSBMLogicalAddrss and the 1449 ALLSBMAddress), but instead, pass them through. As a result, they 1450 do not divide the DSBM election scope, they do not explicitly par- 1451 ticipate in routing of PATH or RESV messages, and they do not par- 1452 ticipate in admission control. They are entirely transparent with 1453 respect to SBM operation. 1455 According to the definitions provided, physical segments intercon- 1456 nected by SBM transparent devices are considered a single managed 1457 segment. Therefore, DSBMs must perform admission control on such 1458 managed segments, with limited knowledge of the segment's topol- 1459 ogy. In this case, the network administrator should configure the 1461 SBM (Subnet Bandwidth Manager) October, 1999 1463 DSBM for each managed segment, with some reasonable approximation 1464 of the segment's capacity. A conservative policy would configure 1465 the DSBM for the lowest capacity route through the managed seg- 1466 ment. A liberal policy would configure the DSBM for the highest 1467 capacity route through the managed segment. A network administra- 1468 tor will likely choose some value between the two, based on the 1469 level of guarantee required and some knowledge of likely traffic 1470 patterns. 1472 This document does not specify the configuration mechanism or the 1473 choice of a policy. 1475 5.11. Operation of SBMs Which are NOT DSBMs 1477 In the example illustrated, S3 hosts a SBM, but the SBM on S3 did 1478 not win the election to act as DSBM on any segment. One might ask 1479 what purpose such a SBM protocol entity serves. Such SBMs actually 1480 provide two useful functions. First, the additional SBMs remain 1481 passive in the background for fault tolerance. They listen to the 1482 periodic announcements from the current DSBM for the managed seg- 1483 ment (Appendix A describes this in more detail) and step in to 1484 elect a new DSBM when the current DSBM fails or ceases to be 1485 operational for some reason. Second, such SBMs also provide the 1486 important service of dividing the election scope and reducing the 1487 size and complexity of managed segments. For example, consider the 1488 sample topology in Figure 3 again. the device S3 contains an SBM 1489 that is not a DSBM for any f the segments, B, E, or F, attached to 1490 it. However, if the SBM protocol entity on S3 was not present, 1491 segments B and F would not be separate segments from the point of 1492 view of the SBM protocol. Instead, they would constitute a single 1493 managed segment, managed by a single DSBM. Because the SBM entity 1494 on S3 divides the election scope, seg B and seg F are each 1495 managed by separate DSBMs. Each of these segments have a trivial 1496 topology and a well defined capacity. As a result, the DSBMs for 1497 these segments do not need to perform admission control based on 1498 approximations (as would be the case if S3 were SBM transparent). 1500 Note that, SBM protocol entities which are not DSBMs, are not 1501 required to overwrite the PHOP in incident PATH messages with 1502 their own address. This is because it is not necessary for RESV 1503 messages to be routed through these devices. RESV messages are 1504 only required to be routed through the correct sequence of DSBMs. 1505 SBMs may not process RESV messages that do pass through them, 1506 other than to forward them towards their destination address, 1507 using standard forwarding rules. 1509 SBM (Subnet Bandwidth Manager) October, 1999 1511 SBM protocol entities which are not DSBMs are required to 1512 overwrite the address in the LAN_LOOPBACK object with their own 1513 address, in order to avoid looping multicast messages. However, no 1514 state need be stored. 1516 6. Inter-Operability Considerations 1518 There are a few interesting inter-operability issues related to 1519 the deployment of a DSBM-based admission control method in an 1520 environment consisting of network nodes with and without RSVP 1521 capability. In the following, we list some of these scenarios and 1522 explain how SBM-aware clients and nodes can operate in those 1523 scenarios: 1525 6.1. An L2 domain with no RSVP capability. 1527 It is possible to envisage L2 domains that do not use RSVP signal- 1528 ing for requesting resource reservations, but, instead, use some 1529 other (e.g., SNMP or static configuration) mechanism to reserve 1530 bandwidth at a particular network device such as a router. In that 1531 case, the question is how does a DSBM-based admission control 1532 method work and interoperate with the non-RSVP mechanism. The 1533 SBM-based method does not attempt to provide an admission control 1534 solution for such an environment. The SBM-based approach is part 1535 of an end to end signaling approach to establish resource reserva- 1536 tions and does not attempt to provide a solution for SNMP-based 1537 configuration scenario. 1539 As stated earlier, the SBM-based approach can, however, co-exist 1540 with any other, non-RSVP bandwidth allocation mechanism as long as 1541 resources being reserved are either partitioned statically between 1542 the different mechanisms or are resolved dynamically through a 1543 common bandwidth allocator so that there is no over-commitment of 1544 the same resource. 1546 6.2. An L2 domain with SBM-transparent L2 Devices. 1548 This scenario has been addressed earlier in the document. The 1549 SBM-based method is designed to operate in such an environment. 1550 When SBM-transparent L2 devices interconnect SBM-aware devices, 1551 the resulting managed segment is a combination of one or more phy- 1552 sical segments and the DSBM for the managed segment may not be as 1553 efficient in allocating resources as it would if all L2 devices 1554 were SBM-aware. 1556 SBM (Subnet Bandwidth Manager) October, 1999 1558 6.3. An L2 domain on which some RSVP-based senders are not DSBM 1559 clients. 1561 All senders that are sourcing RSVP-based traffic flows onto a 1562 managed segment MUST be SBM-aware and participate in the SBM pro- 1563 tocol. Use of the standard, non-SBM version of RSVP may result in 1564 over-allocation of resources, as such use bypasses the resource 1565 management function of the DSBM. All other senders (i.e., senders 1566 that are not sending streams subject to RSVP admission control) 1567 should be elastic applications that send traffic of lower priority 1568 than the RSVP traffic, and use TCP-like congestion avoidance 1569 mechanisms. 1571 All DSBMs, SBMs, or DSBM clients on a managed segment (a segment 1572 with a currently active DSBM) must not accept PATH messages from 1573 senders that are not SBM-aware. PATH messages from such devices 1574 can be easily detected by SBMs and DSBM clients as they would not 1575 be multicast to the ALLSBMAddress (in case of SBMs and DSBM 1576 clients) or the DSBMLogicalAddress (in case of DSBMs). 1578 6.4. A non-SBM router that interconnects two DSBM-managed L2 1579 domains. 1581 Multicast SBM messages (e.g., election and PATH messages) have 1582 local scope and are not intended to pass between the two domains. 1583 A correctly configured non-SBM router will not pass such messages 1584 between the domains. A broken router implementation that does so 1585 may cause incorrect operation of the SBM protocol and consequent 1586 over- or under-allocation of resources. 1588 6.5. Interoperability with RSVP clients that use UDP encapsulation 1589 and are not capable of receiving/sending RSVP messages using 1590 RAW_IP 1592 This document stipulates that DSBMs, DSBM clients, and SBMs use 1593 only raw IP for encapsulating RSVP messages that are forwarded 1594 onto a L2 domain. RFC-2205 (the RSVP Proposed Standard) includes 1595 support for both raw IP and UDP encapsulation. Thus, a RSVP node 1596 using only the UDP encapsulation will not be able to interoperate 1597 with the DSBM unless DSBM accepts and supports UDP encapsulated 1598 RSVP messages. 1600 7. Guidelines for Implementers 1602 SBM (Subnet Bandwidth Manager) October, 1999 1604 In the following, we provide guidelines for implementers on dif- 1605 ferent aspects of the implementation of the SBM-based admission 1606 control procedure including suggestions for DSBM initialization, 1607 etc. 1609 7.1. DSBM Initialization 1611 As stated earlier, DSBM initialization includes configuration of 1612 maximum bandwidth that can be reserved on a managed segment under 1613 its control. We suggest the following guideline. 1615 In the case of a managed segment consisting of L2 devices inter- 1616 connected by a single shared segment, DSBM entities on such dev- 1617 ices should assume the bandwidth of the interface as the total 1618 link bandwidth. In the case of a DSBM located in a L2 switch, it 1619 might additionally need to be configured with an estimate of the 1620 device's switching capacity if that is less than the link 1621 bandwidth, and possibly with some estimate of the buffering 1622 resources of the switch (see [RFC-FRAME] for the architectural 1623 model assumed for L2 switches). Given the total link bandwidth, 1624 the DSBM may be further configured to limit the maximum amount of 1625 bandwidth for RSVP-enabled flows to ensure spare capacity for 1626 best-effort traffic. 1628 7.2. Operation of DSBMs in Different L2 Topologies 1630 Depending on a L2 topology, a DSBM may be called upon to manage 1631 resources for one or more segments and the implementers must bear 1632 in mind efficiency implications of the use of DSBM in different L2 1633 topologies. Trivial L2 topologies consist of a single "physical 1634 segment". In this case, the 'managed segment' is equivalent to a 1635 single segment. Complex L2 topologies may consist of a number of 1636 'physical segments', separated by SBM-transparent L2 switches. 1637 Admission control on such an L2 extended segment can be performed 1638 from a single pool of resources, similar to a single shared seg- 1639 ment, from the point of view of a single DSBM. 1641 This configuration compromises the efficiency with which the DSBM 1642 can allocate resources. This is because the single DSBM is 1643 required to make admission control decisions for all reservation 1644 requests within the L2 topology, with no knowledge of the actual 1645 physical segments affected by the reservation. 1647 We can realize improvements in the efficiency of resource alloca- 1648 tion by subdividing the complex segment into a number of managed 1649 segments, each managed by their own DSBM. In this case, each DSBM 1651 SBM (Subnet Bandwidth Manager) October, 1999 1653 manages a managed segment having a relatively simple topology. 1654 Since managed segments are simpler, the DSBM can be configured 1655 with a more accurate estimate of the resources available for all 1656 reservations in the managed segment. In the ultimate configura- 1657 tion, each physical segment is a managed segment and is managed by 1658 its own DSBM. We make no assumption about the number of managed 1659 segments but state, simply, that in complex L2 topologies, the 1660 efficiency of resource allocation improves as the granularity of 1661 managed segments increases. 1663 8. Security Considerations 1665 The message formatting and usage rules described in this note 1666 raise security issues, identical to those raised by the use of 1667 RSVP and Integrated Services. It is necessary to control and 1668 authenticate access to enhanced qualities of service enabled by 1669 the technology described in this RFC. This requirement is 1670 discussed further in [RFC-2205], [RFC-2211], and [RFC-2212]. 1672 [RFC-RSVPMD5] describes the mechanism used to protect the 1673 integrity of RSVP messages carrying the information described 1674 here. A SBM implementation should satisfy the requirements of 1675 that RFC and provide 1676 the suggested mechanisms just as though it were a 1677 conventional RSVP implementation. It should further use the 1678 same mechanisms to 1679 protect the additional, SBM-specific objects in a message. 1681 Finally, it is also necessary to authenticate DSBM candidates 1682 during the election process, and a mechanism based on a shared 1683 secret among the DSBM candidates may be used. The mechanism 1684 defined in [RFC-RSVPMD5] should be used. 1686 SBM (Subnet Bandwidth Manager) October, 1999 1688 9. References 1690 [RFC-2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 1691 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1692 Specification ", RFC-2205, September 1997. 1694 [RFC-RSVPMD5] F. Baker., "RSVP Cryptographic Authentication", draft- 1695 ietf-rsvp-md5-05.txt, August 1997. [XXX- is this a RFC yet??] 1697 [RFC-2206] F. Baker, J. Krawczyk, "RSVP Management Information 1698 Base", RFC 2206, September 1997. 1700 [RFC-2211] J. Wroclawski, "Specification of the Controlled-Load 1701 Network Element Service", RFC-2211, September 1997. 1703 [RFC-2212] S. Shenker, C. Partridge, R. Guerin, "Specification of 1704 Guaranteed Quality of Service", RFC-2212, September 1997. 1706 [RFC-2215] S. Shenker, J. Wroclawski, "General Characterization 1707 Parameters for Integrated Service Network Elements", RFC-2215, 1708 September 1997. 1710 [RFC-2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 1711 Services", RFC 2210, September 1997. 1713 [RFC-2213] F. Baker, J. Krawczyk, "Integrated Services Management 1714 Information Base", RFC 2213, September 1997. 1716 [RFC-FRAME] A. Ghanwani, W. Pace, V. Srinivasan, A.Smith, 1717 M.Seaman "A Framework for Providing Integrated Services Over 1718 Shared and Switched LAN Technologies", RFC-XXX, June, 1999. 1720 [RFC-MAP] M. Seaman, A. Smith, E. Crawley, "Integrated Service 1721 Mappings on IEEE 802 Networks", RFC-XXX, June 1999. 1723 [IEEE802Q] "IEEE Standards for Local and Metropolitan Area Net- 1724 works: Virtual Bridged Local Area Networks", Draft Standard 1725 P802.1Q/D9, February 20, 1998. 1727 [IEEEP8021p] "Information technology - Telecommunications and 1728 information exchange between systems - Local and metropolitan area 1729 networks - Common specifications - Part 3: Media Access Control 1730 (MAC) Bridges: Revision (Incorporating IEEE P802.1p: Traffic 1731 Class Expediting and Dynamic Multicast Filtering)", ISO/IEC Final 1732 CD 15802-3 IEEE P802.1D/D15, November 24, 1997. 1734 SBM (Subnet Bandwidth Manager) October, 1999 1736 [IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D- 1737 1993. 1739 SBM (Subnet Bandwidth Manager) October, 1999 1741 Appendix A 1742 DSBM Election Algorithm 1744 A.1. Introduction 1746 To simplify the rest of this discussion, we will assume that there 1747 is a single DSBM for the entire L2 domain (i.e., assume a shared 1748 L2 segment for the entire L2 domain). Later, we will discuss how a 1749 DSBM is elected for a half-duplex or full-duplex switched segment. 1751 To allow for quick recovery from the failure of a DSBM, we assume 1752 that additional SBMs may be active in a L2 domain for fault toler- 1753 ance. When more than one SBM is active in a L2 domain, the SBMs 1754 use an election algorithm to elect a DSBM for the L2 domain. After 1755 the DSBM is elected and is operational, other SBMs remain passive 1756 in the background to step in to elect a new DSBM when necessary. 1757 The protocol for electing and discovering DSBM is called the "DSBM 1758 election protocol" and is described in the rest of this Appendix. 1760 A.1.1. How a DSBM Client Detects a Managed Segment 1762 Once elected, a DSBM periodically multicasts an I_AM_DSBM message 1763 on the AllSBMAddress to indicate its presence. The message is sent 1764 every period (e.g., every 5 seconds) according to the 1765 RefreshInterval timer value (a configuration parameter). 1766 Absence of such a message over a certain time interval (called 1767 "DSBMDeadInterval"; another configuration parameter typically set 1768 to a multiple of RefreshInterval) indicates that the DSBM has 1769 failed or terminated and triggers another round of the DSBM elec- 1770 tion. The DSBM clients always listen for periodic DSBM advertise- 1771 ments. The advertisement includes the unicast IP address of the 1772 DSBM (DSBMAddress) and DSBM clients send their PATH/RESV (or 1773 other) messages to the DSBM. When a DSBM client detects the 1774 failure of a DSBM, it waits for a subsequent I_AM_DSBM advertise- 1775 ment before resuming any communication with the DSBM. During the 1776 period when a DSBM is not present, a DSBM client may forward out- 1777 going PATH messages using the standard RSVP forwarding rules. 1779 The exact message formats and addresses used for communication 1780 with (and among) SBM(s) are described in Appendix B. 1782 A.2. Overview of the DSBM Election Procedure 1784 SBM (Subnet Bandwidth Manager) October, 1999 1786 When a SBM first starts up, it listens for incoming DSBM adver- 1787 tisements for some period to check whether a DSBM already exists 1788 in its L2 domain. If one already exists (and no new election is in 1789 progress), the new SBM stays quiet in the background until an 1790 election of DSBM is necessary. All messages related to the DSBM 1791 election and DSBM advertisements are always sent to the AllSBMAd- 1792 dress. 1794 If no DSBM exists, the SBM initiates the election of a DSBM by 1795 sending out a DSBM_WILLING message that lists its IP address as a 1796 candidate DSBM and its "SBM priority". Each SBM is assigned a 1797 priority to determine its relative precedence. When more than one 1798 SBM candidate exists, the SBM priority determines who gets to be 1799 the DSBM based on the relative priority of candidates. If there is 1800 a tie based on the priority value, the tie is broken using the IP 1801 addresses of tied candidates (one with the higher IP address in 1802 the lexicographic order wins). The details of the election proto- 1803 col start in Section A.4. 1805 A.2.1 Summary of the Election Algorithm 1807 For the purpose of the algorithm, a SBM is in one of the four 1808 states (Idle, DetectDSBM, ElectDSBM, IAMDSBM). 1810 A SBM (call it X) starts up in the DetectDSBM state and waits for 1811 a ListenInterval for incoming I_AM_DSBM (DSBM advertisement) or 1812 DSBM_WILLING messages. If an I_AM_DSBM advertisement is received 1813 during this state, the SBM notes the current DSBM (its IP address 1814 and priority) and enters the Idle state. If a DSBM_WILLING message 1815 is received from another SBM (call it Y) during this state, then X 1816 enters the ElectDSBM state. Before entering the new state, X first 1817 checks to see whether it itself is a better candidate than Y and, 1818 if so, sends out a DSBM_WILLING message and then enters the 1819 ElectDSBM state. 1821 When a SBM (call it X) enters the ElectDSBM state, it sets a timer 1822 (called ElectionIntervalTimer, and typically set to a value at 1823 least equal to the DSBMDeadInterval value) to wait for the elec- 1824 tion to finish and to discover who is the best candidate. In this 1825 state, X keeps track of the best (or better) candidate seen so far 1826 (including itself). Whenever it receives another DSBM_WILLING mes- 1827 sage, it updates its notion of the best (or better) candidate 1828 based on the priority (and tie-breaking) criterion. During the 1829 ElectionInterval, X sends out a DSBM_WILLING message every 1830 RefreshInterval to (re)assert its candidacy. 1832 SBM (Subnet Bandwidth Manager) October, 1999 1834 At the end of the ElectionInterval, X checks whether it is the 1835 best candidate so far. If so, it declares itself to be the DSBM 1836 (by sending out the I_AM_DSBM advertisement) and enters the 1837 IAMDSBM state; otherwise, it decides to wait for the best candi- 1838 date to declare itself the winner. To wait, X re-initializes its 1839 ElectDSBM state and continues to wait for another round of elec- 1840 tion (each round lasts for an ElectionTimerInterval duration). 1842 A SBM is in Idle state when no election is in progress and the 1843 DSBM is already elected (and happens to be someone else). In this 1844 state, it listens for incoming I_AM_DSBM advertisements and uses 1845 a DSBMDeadIntervalTimer to detect the failure of DSBM. Every time 1846 the advertisement is received, the timer is restarted. If the 1847 timer fires, the SBM goes into the DetectDSBM state to prepare to 1848 elect the new DSBM. If a SBM receives a DSBM_WILLING message from 1849 the current DSBM in this state, the SBM enters the ElectDSBM state 1850 after sending out a DSBM_WILLING message (to announce its own 1851 candidacy). 1853 In the IAMDSBM state, the DSBM sends out I_AM_DSBM advertise- 1854 ments every refresh interval. If the DSBM wishes to shut down 1855 (gracefully terminate), it sends out a DSBM_WILLING message (with 1856 SBM priority value set to zero) to initiate the election pro- 1857 cedure. The priority value zero effectively removes the outgoing 1858 DSBM from the election procedure and makes way for the election of 1859 a different DSBM. 1861 A.3. Recovering from DSBM Failure 1863 When a DSBM fails (DSBMDeadIntervalTimer fires), all the SBMs 1864 enter the ElectDSBM state and start the election process. 1866 At the end of the ElectionInterval, the elected DSBM sends out an 1867 I_AM_DSBM advertisement and the DSBM is then operational. 1869 A.4. DSBM Advertisements 1871 The I_AM_DSBM advertisement contains the following information: 1873 1. DSBM address information -- contains the IP and L2 addresses 1874 of the DSBM and its SBM priority (a configuration parameter 1876 SBM (Subnet Bandwidth Manager) October, 1999 1878 -- priority specified by a network administrator). The prior- 1879 ity value is used to choose among candidate SBMs during the 1880 election algorithm. Higher integer values indicate higher 1881 priority and the value is in the range 0..255. The value zero 1882 indicates that the SBM is not eligible to be the DSBM. The 1883 IP address is required and used for breaking ties. The L2 1884 address is for the interface of the managed segment. 1886 2. RegreshInterval -- contains the value of RefreshInterval 1887 in seconds. Value zero indicates the parameter has been 1888 omitted in the message. Receivers may substitute their own 1889 default value in this case. 1891 3. DSBMDeadInterval -- contains the value of DSBMDeadInterval 1892 in seconds. If the value is omitted (or value zero is speci- 1893 fied), a default value (from initial configuration) should be 1894 used. 1896 4. Miscellaneous configuration information to be advertised to 1897 senders on the managed segment. See Appendix C for further 1898 details. 1900 A.5. DSBM_WILLING Messages 1902 When a SBM wishes to declare its candidacy to be the DSBM during 1903 an election phase, it sends out a DSBM_WILLING message. The 1904 DSBM_WILLING message contains the following information: 1906 1. DSBM address information -- Contains the SBM's own addresses 1907 (IP and L2 address), if it wishes to be the DSBM. The IP 1908 address is required and used for breaking ties. The L2 1909 address is the address of the interface for the managed seg- 1910 ment in question. Also, the DSBM address information 1911 includes the corresponding priority of the SBM whose address 1912 is given above. 1914 SBM (Subnet Bandwidth Manager) October, 1999 1916 A.6. SBM State Variables 1918 For each network interface, a SBM maintains the following state 1919 variables related to the election of the DSBM for the L2 domain on 1920 that interface: 1922 a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, 1923 0.0.0.0) and priority. All IP addresses are assumed to be in 1924 network byte order. In addition, current DSBM's L2 address is 1925 also stored as part of this state information. 1927 b) OwnAddrInfo -- SBM's own IP address and L2 address for the 1928 interface and its own priority (a configuration parameter). 1930 c) RefreshInterval in seconds. When the DSBM is not yet 1931 elected, it is set to a default value specified as a confi- 1932 guration parameter. 1934 d) DSBMDeadInterval in seconds. When the DSBM is not yet 1935 elected, it is initially set to a default value specified as 1936 a configuration parameter. 1938 f) ListenInterval in seconds -- a configuration parameter 1939 that decides how long a SBM spends in the DetectDSBM state 1940 (see below). 1942 g) ElectionInterval in seconds -- a configuration parameter 1943 that decides how long a SBM spends in the ElectDSBM state 1944 when it has declared its candidacy. 1946 Figure 3 shows the state transition diagram for the election pro- 1947 tocol and the various states are described below. A complete 1948 description of the state machine is provided in Section A.10. 1950 A.7. DSBM Election States 1952 DOWN -- SBM is not operational. 1954 SBM (Subnet Bandwidth Manager) October, 1999 1956 DetectDSBM -- typically, the initial state of a SBM when it 1957 starts up. In this state, it checks to see whether a DSBM 1958 already exists in its domain. 1960 Idle -- SBM is in this state when no election is in progress 1961 and it is not the DSBM. In this state, SBM passively monitors 1962 the state of the DSBM. 1964 ElectDSBM -- SBM is in this state when a DSBM election is in 1965 progress. 1967 IAMDSBM -- SBM is in this state when it is the DSBM for the 1968 L2 domain. 1970 A.8. Events that cause state changes 1972 StartUp -- SBM starts operation. 1974 ListenInterval Timeout -- The ListenInterval timer has fired. 1975 This means that the SBM has monitored its domain to check for 1976 an existing DSBM or to check whether there are candidates 1977 (other than itself) willing to be the DSBM. 1979 DSBM_WILLING message received -- This means that the SBM 1980 received a DSBM_WILLING message from some other SBM. Such a 1981 message is sent when a SBM wishes to declare its candidacy to 1982 be the DSBM. 1984 I_AM_DSBM message received -- SBM received a DSBM advertise- 1985 ment from the DSBM in its L2 domain. 1987 DSBMDeadInterval Timeout -- The DSBMDeadIntervalTimer has 1988 fired. This means that the SBM did not receive even one DSBM 1989 advertisement during this period and indicates possible 1990 failure of the DSBM. 1992 SBM (Subnet Bandwidth Manager) October, 1999 1994 RefreshInterval Timeout -- The RefreshIntervalTimer has 1995 fired. In the IAMDSBM state, this means it is the time for 1996 sending out the next DSBM advertisement. In the ElectDSBM 1997 state, the event means that it is the time to send out 1998 another DSBM_WILLING message. 2000 ElectionInterval Timeout -- The ElectionIntervalTimer has 2001 fired. This means that the SBM has waited long enough after 2002 declaring its candidacy to determine whether or not it suc- 2003 ceeded. 2005 CONTINUED ON NEXT PAGE 2007 SBM (Subnet Bandwidth Manager) October, 1999 2009 A.9. State Transition Diagram (Figure 3) 2011 +-----------+ 2012 +--<--------------<-|DetectDSBM |---->------+ 2013 | +-----------+ | 2014 | | 2015 | | 2016 | | 2017 | +-------------+ +---------+ | 2018 +->---| Idle |--<>---|ElectDSBM|--<--+ 2019 +-------------+ +---------+ 2020 | | 2021 | | 2022 | | 2023 | +-----------+ | 2024 +<<- +---| IAMDSBM |-<-+ 2025 | +-----------+ 2026 | 2027 | +-----------+ 2028 +>>-| SHUTDOWN | 2029 +-----------+ 2031 A.10. Election State Machine 2033 Based on the events and states described above, the state changes 2034 at a SBM are described below. Each state change is triggered by an 2035 event and is typically accompanied by a sequence of actions. The 2036 state machine is described assuming a single threaded implementa- 2037 tion (to avoid race conditions between state changes and timer 2038 events) with no timer events occurring during the execution of the 2039 state machine. 2041 The following routines will be frequently used in the description 2042 of the state machine: 2044 ComparePrio(FirstAddrInfo, SecondAddrInfo) 2045 -- determines whether the entity represented by the first parameter 2046 is better than the second entity using the priority information 2047 and the IP address information in the two parameters. 2048 If any address is zero, that entity 2049 automatically loses; then first priorities are compared; higher 2050 priority candidate wins. If there is a tie based on 2051 the priority value, the tie is broken using the IP 2052 addresses of tied candidates (one with the higher IP address in the 2053 lexicographic order wins). Returns TRUE if first entity is a better 2055 SBM (Subnet Bandwidth Manager) October, 1999 2057 choice. FALSE otherwise. 2059 SendDSBMWilling Message() 2060 Begin 2061 Send out DSBM_WILLING message listing myself as a candidate for 2062 DSBM (copy OwnAddr and priority into appropriate fields) 2063 start RefreshIntervalTimer 2064 goto ElectDSBM state 2065 End 2067 AmIBetterDSBM(OtherAddrInfo) 2068 Begin 2069 if (ComparePrio(OwnAddrInfo, OtherAddrInfo)) 2070 return TRUE 2072 change LocalDSBMInfo = OtherDSBMAddrInfo 2073 return FALSE 2074 End 2076 UpdateDSBMInfo() 2077 /* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */ 2078 Begin 2079 update LocalDSBMInfo such as IP addr, DSBM L2 address, 2080 DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer 2081 End 2083 A.10.1 State Changes 2085 In the following, the action "continue" or "continue in current 2086 state" means an "exit" from the current action sequence without a 2087 state transition. 2089 State: DOWN 2090 Event: StartUp 2091 New State: DetectDSBM 2092 Action: Initialize the local state variables (LocalDSBMADDR and 2093 LocalDSBMAddrInfo set to 0). Start the ListenIntervalTimer. 2095 State: DetectDSBM 2096 New State: Idle 2097 Event: I_AM_DSBM message received 2098 Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2099 start DeadDSBMInterval timer 2100 goto Idle State 2102 SBM (Subnet Bandwidth Manager) October, 1999 2104 State: DetectDSBM 2105 Event: ListenIntervalTimer fired 2106 New State: ElectDSBM 2107 Action: Start ElectionIntervalTimer 2108 SendDSBMWillingMessage(); 2110 State: DetectDSBM 2111 Event: DSBM_WILLING message received 2112 New State: ElectDSBM 2113 Action: Cancel any active timers 2115 Start ElectionIntervalTimer 2116 /* am I a better choice than this dude? */ 2117 If (ComparePrio(OwnAddrInfo, IncomingDSBMInfo)) { 2118 /* I am better */ 2119 SendDSBMWillingMessage() 2120 } else { 2121 Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2122 goto ElectDSBM state 2123 } 2125 State: Idle 2126 Event: DSBMDeadIntervalTimer fired. 2127 New State: ElectDSBM 2128 Action: start ElectionIntervalTimer 2129 set LocalDSBMAddrInfo = OwnAddrInfo 2130 SendDSBMWiliingMessage() 2132 State: Idle 2133 Event: I_AM_DSBM message received. 2134 New State: Idle 2135 Action: /* first check whether anything has changed */ 2136 if (!ComparePrio(LocalDSBMAddrInfo, IncomingDSBMAddrInfo)) 2137 change LocalDSBMAddrInfo to reflect new info 2138 endif 2139 restart DSBMDeadIntervalTimer; 2140 continue in current state; 2142 State: Idle 2143 Event: DSBM_WILLING Message is received 2144 New State: Depends on action (ElectDSBM or Idle) 2145 Action: /* check whether it is from the DSBM itself (shutdown) */ 2146 if (IncomingDSBMAddr == LocalDSBMAddr) { 2147 cancel active timers 2148 Set LocalDSBMAddrInfo = OwnAddrInfo 2149 Start ElectionIntervalTimer 2150 SendDSBMWillingMessage() /* goto ElectDSBM state */ 2151 } 2153 SBM (Subnet Bandwidth Manager) October, 1999 2155 /* else, ignore it */ 2156 continue in current state 2158 State: ElectDSBM 2159 Event: ElectionIntervalTimer Fired 2160 New State: depends on action (IAMDSBM or Current State) 2161 Action: If (LocalDSBMAddrInfo == OwnAddrInfo) { 2162 /* I won */ 2163 send I_AM_DSBM message 2164 start RefreshIntervalTimer 2165 goto IAMDSBM state 2166 } else { /* someone else won, so wait for it to declare 2167 itself to be the DSBM */ 2168 set LocalDSBMAddressInfo = OwnAddrInfo 2169 start ElectionIntervalTimer 2170 SendDSBMWillingMessage() 2171 continue in current state 2172 } 2174 State: ElectDSBM 2175 Event: I_AM_DSBM message received 2176 New State: Idle 2177 Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2178 Cancel any active timers 2179 start DeadDSBMInterval timer 2180 goto Idle State 2182 State: ElectDSBM 2183 Event: DSBM_WILLING message received 2184 New State: ElectDSBM 2185 Action: Check whether it's a loopback and if so, discard, continue; 2186 if (!AmIBetterDSBM(IncomingDSBMAddrInfo)) { 2187 Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2188 Cancel RefreshIntervalTimer 2189 } else if (LocalDSBMAddrInfo == OwnAddrInfo) { 2190 SendDSBMWillingMessage() 2191 } 2192 continue in current state 2194 State: ElectDSBM 2195 Event: RefreshIntervalTimer fired 2196 New State: ElectDSBM 2197 Action: /* continue to send DSBMWilling messages until 2198 election interval ends */ 2199 SendDSBMWillingMessage() 2201 State: IAMDSBM 2202 Event: DSBM_WILLING message received 2204 SBM (Subnet Bandwidth Manager) October, 1999 2206 New State: depends on action (IAMDSBM or SteadyState) 2207 Action: /* check whether other guy is better */ 2208 If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) { 2209 /* I am better */ 2210 send I_AM_DSBM message 2211 restart RefreshIntervalTimer 2212 continue in current state 2213 } else { 2214 Set LocalDSBMAddrInfo = IncomingAddrInfo 2215 cancel active timers 2216 start DSBMDeadIntervalTimer 2217 goto SteadyState 2218 } 2220 State: IAMDSBM 2221 Event: RefreshIntervalTimer fired 2222 New State: IAMDSBM 2223 Action: send I_AM_DSBM message 2224 restart RefreshIntervalTimer 2226 State: IAMDSBM 2227 Event: I_AM_DSBM message received 2228 New State: depends on action (IAMDSBM or Idle) 2229 Action: /* check whether other guy is better */ 2230 If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) { 2231 /* I am better */ 2232 send I_AM_DSBM message 2233 restart RefreshIntervalTimer 2234 continue in current state 2235 } else { 2236 Set LocalDSBMAddrInfo = IncomingAddrInfo 2237 cancel active timers 2238 start DSBMDeadIntervalTimer 2239 goto Idle State 2240 } 2242 State: IAMDSBM 2243 Event: Want to shut myself down 2244 New State: DOWN 2245 Action: send DSBM_WILLING message with My address filled in, but 2246 priority set to zero 2247 goto Down State 2249 A.10.2 Suggested Values of Interval Timers 2251 To avoid DSBM outages for long period, to ensure quick recovery 2253 SBM (Subnet Bandwidth Manager) October, 1999 2255 from DSBM failures, and to avoid timeout of PATH and RESV state at 2256 the edge devices, we suggest the following values for various 2257 timers. 2259 Assuming that the RSVP implementations use a 30 second timeout for 2260 PATH and RESV refreshes, we suggest that the RefreshIntervalTimer 2261 should be set to about 5 seconds with DSBMDeadIntervalTimer set to 2262 15 seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be 2263 set to a random value between (DSBMDeadIntervalTimer, 2*DSBMDeadInterval- 2264 Timer). The ElectionIntervalTimer should be set at least to the 2265 value of DSBMDeadIntervalTimer to ensure that each SBM has a chance to 2266 have its DSBM_WILLING message (sent every RefreshInterval in 2267 ElectDSBM state) delivered to others. 2269 A.10.3. Guidelines for Choice of Values for SBM_PRIORITY 2271 Network administrators should configure SBM protocol entity at 2272 each SBM-capable device with the device's "SBM priority" for each 2273 of the interfaces attached to a managed segment. SBM_PRIORITY is 2274 an 8-bit, unsigned integer value (in the range 0-255) with higher 2275 integer values denoting higher priority. The value zero for an 2276 interface indicates that the SBM protocol entity on the device is 2277 not eligible to be a DSBM for the segment attached to the inter- 2278 face. 2280 A separate range of values is reserved for each type of SBM- 2281 capable device to reflect the relative priority among different 2282 classes of L2/L3 devices. L2 devices get higher priority followed 2283 by routers followed by hosts. The priority values in the range of 2284 128..255 are reserved for L2 devices, the values in the range of 2285 64..127 are reserved for routers, and values in the range of 1..63 2286 are reserved for hosts. 2288 A.11. DSBM Election over switched links 2290 The election algorithm works as described before in this case 2291 except each SBM-capable L2 device restricts the scope of the elec- 2292 tion to its local segment. As described in Section B.1 below, all 2293 messages related to the DSBM election are sent to a special multi- 2294 cast address (AllSBMAddress). AllSBMAddress (its corresponding MAC 2295 multicast address) is configured in the permanent database of 2296 SBM-capable, layer 2 devices so that all frames with AllSBMAddress 2297 as the destination address are not forwarded and instead directed 2299 SBM (Subnet Bandwidth Manager) October, 1999 2301 to the SBM management entity in those devices. Thus, a DSBM can be 2302 elected separately on each point-to-point segment in a switched 2303 topology. For example, in Figure 2, DSBM for "segment A" will be 2304 elected using the election algorithm between R1 and S1 and none of 2305 the election-related messages on this segment will be forwarded by 2306 S1 beyond "segment A". Similarly, a separate election will take 2307 place on each segment in this topology. 2309 When a switched segment is a half-duplex segment, two senders (one 2310 sender at each end of the link) share the link. In this case, one 2311 of the two senders will win the DSBM election and will be respon- 2312 sible for managing the segment. 2314 If a switched segment is full-duplex, exactly one sender sends on 2315 the link in each direction. In this case, either one or two DSBMs 2316 can exist on such a managed segment. If a sender at each end 2317 wishes to serve as a DSBM for that end, it can declare itself to 2318 be the DSBM by sending out an I_AM_DSBM advertisement and start 2319 managing the resources for the outgoing traffic over the segment. 2320 If one of the two senders does not wish itself to be the DSBM, 2321 then the other DSBM will not receive any DSBM advertisement from 2322 its peer and assume itself to be the DSBM for traffic traversing 2323 in both directions over the managed segment. 2325 SBM (Subnet Bandwidth Manager) October, 1999 2327 Appendix B 2328 Message Encapsulation and Formats 2330 To minimize changes to the existing RSVP implementations and to 2331 ensure quick deployment of a SBM in conjunction with RSVP, all 2332 communication to and from a DSBM will be performed using messages 2333 constructed using the current rules for RSVP message formats and 2334 raw IP encapsulation. For more details on the RSVP message for- 2335 mats, refer to the RSVP specification (RFC 2205). No changes to 2336 the RSVP message formats are proposed, but new message types and 2337 new L2-specific objects are added to the RSVP message formats to 2338 accommodate DSBM-related messages. These additions are described 2339 below. 2341 B.1 Message Addressing 2343 For the purpose of DSBM election and detection, AllSBMAddress is 2344 used as the destination address while sending out both 2345 DSBM_WILLING and I_AM_DSBM messages. A DSBM client first detects a 2346 managed segment by listening to I_AM_DSBM advertisements and 2347 records the DSBMAddress (unicast IP address of the DSBM). 2349 B.2. Message Sizes 2351 Each message must occupy exactly one IP datagram. If it exceeds 2352 the MTU, such a datagram will be fragmented by IP and reassembled 2353 at the recipient node. This has a consequence that a single mes- 2354 sage may not exceed the maximum IP datagram size, approximately 2355 64K bytes. 2357 B.3. RSVP-related Message Formats 2359 All RSVP messages directed to and from a DSBM may contain various 2360 RSVP objects defined in the RSVP specification and messages con- 2361 tinue to follow the formatting rules specified in the RSVP specif- 2362 ication. In addition, an RSVP implementation must also recognize 2363 new object classes that are described below. 2365 B.3.1. Object Formats 2367 SBM (Subnet Bandwidth Manager) October, 1999 2369 All objects are defined using the format specified in the RSVP 2370 specification. Each object has a 32-bit header that contains 2371 length (of the object in bytes including the object header), the 2372 object class number, and a C-Type. All unused fields should be set 2373 to zero and ignored on receipt. 2375 B.3.2. SBM Specific Objects 2377 Note that the Class-Num values for the SBM specific objects 2378 (LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2) are chosen from the 2379 codespace 10XXXXXX. This coding assures that non-SBM aware RSVP 2380 nodes will ignore the objects without forwarding them or generat- 2381 ing an error message. 2383 Within the SBM specific codespace, note the following interpreta- 2384 tion of the third most significant bit of the Class-Num: 2386 a) Objects of the form 100XXXXX are to be silently dis- 2387 carded by SBM nodes that do not recognize them. 2389 b) Objects of the form 101XXXXX are to be silently for- 2390 warded by SBM nodes that do not recognize them. 2392 B.3.3. IEEE 802 Canonical Address Format 2394 The 48-bit MAC Addresses used by IEEE 802 were originally defined 2395 in terms of wire order transmission of bits in the source and des- 2396 tination MAC address fields. The same wire order applied to both 2397 Ethernet and Token Ring. Since the bit transmission order of Ether- 2398 net and Token Ring data differ - Ethernet octets are transmitted 2399 least significant bit first, Token Ring most significant first - 2400 the numeric values naturally associated with the same address on 2401 different 802 media differ. To facilitate the communication of 2402 address values in higher layer protocols which might span both 2403 token ring and Ethernet attached systems connected by bridges, it 2404 was necessary to define one reference format - the so called canon- 2405 ical format for these addresses. Formally the canonical format 2406 defines the value of the address, separate from the encoding rules 2407 used for transmission. It comprises a sequence of octets derived 2408 from the original wire order transmission bit order as follows. The 2409 least significant bit of the first octet is the first bit transmit- 2410 ted, the next least significant bit the second bit, and so on to 2412 SBM (Subnet Bandwidth Manager) October, 1999 2414 the most significant bit of the first octet being the 8th bit 2415 transmitted; the least significant bit of the second octet is the 2416 9th bit transmitted, and so on to the most significant bit of the 2417 sixth octet of the canonical format being the last bit of the 2418 address transmitted. 2420 This canonical format corresponds to the natural value of the 2421 address octets for Ethernet. The actual transmission order or for- 2422 mal encoding rules for addresses on media which do not transmit bit 2423 serially are derived from the canonical format octet values. 2425 This document requires that all L2 addresses used in conjunction 2426 with the SBM protocol be encoded in the canonical format as a 2427 sequence of 6 octets. In the following, we define the object for- 2428 mats for objects that contain L2 addresses that are based on the 2429 canonical representation. 2431 B.3.4. RSVP_HOP_L2 object 2433 RSVP_HOP_L2 object uses object class = 161; it contains the L2 2434 address of the previous hop L3 device in the IEEE Canonical address 2435 format discussed above. 2437 RSVP_HOP_L2 object: class = 161, C-Type represents the addressing format 2438 used. In our case, C-Type=1 represents the IEEE Canonical Address 2439 format. 2441 0 1 2 3 2442 +---------------+---------------+---------------+----------------+ 2443 | Length | 161 |C-Type(addrtype)| 2444 +---------------+---------------+---------------+----------------+ 2445 | Variable length Opaque data | 2446 +---------------+---------------+---------------+----------------+ 2448 C-Type = 1 (IEEE Canonical Address format) 2450 When C-Type=1, the object format is: 2452 0 1 2 3 2453 +---------------+---------------+---------------+---------------+ 2454 | 12 | 161 | 1 | 2455 +---------------+---------------+---------------+---------------+ 2456 | Octets 0-3 of the MAC address | 2457 +---------------+---------------+---------------+---------------+ 2458 | Octets 4-5 of the MAC addr. | /// | /// | 2459 +---------------+---------------+---------------+---------------+ 2461 SBM (Subnet Bandwidth Manager) October, 1999 2463 /// -- unused (set to zero) 2465 B.3.5. LAN_NHOP object 2467 LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address 2468 object and LAN_NHOP_L2 address object. 2469 ::= 2471 LAN_NHOP_L2 address object uses object class = 162 and uses the 2472 same format (but different class number) as the RSVP_HOP_L2 object. 2473 It provides the L2 or MAC address of the next hop L3 device. 2475 0 1 2 3 2476 +---------------+---------------+---------------+----------------+ 2477 | Length | 162 |C-Type(addrtype)| 2478 +---------------+---------------+---------------+----------------+ 2479 | Variable length Opaque data | 2480 +---------------+---------------+---------------+----------------+ 2482 C-Type = 1 (IEEE 802 Canonical Address Format as defined below) 2483 See the RSVP_HOP_L2 address object for more details. 2485 LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP 2486 address of the next hop L3 device. 2488 LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6 address 2489 family used. 2491 IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1 2492 +---------------+---------------+---------------+---------------+ 2493 | Length = 8 | 163 | 1 | 2494 +---------------+---------------+---------------+---------------+ 2495 | IPv4 NHOP address | 2496 +---------------------------------------------------------------+ 2498 IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2 2499 +---------------+---------------+---------------+---------------+ 2500 | Length = 20 | 163 | 2 | 2501 +---------------+---------------+---------------+---------------+ 2502 | IPv6 NHOP address (16 bytes) | 2503 +---------------------------------------------------------------+ 2505 B.3.6. LAN_LOOPBACK Object 2507 SBM (Subnet Bandwidth Manager) October, 1999 2509 The LAN_LOOPBACK object gives the IP address of the outgoing inter- 2510 face for a PATH message and uses object class=164; both IPv4 and 2511 IPv6 formats are specified. 2513 IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1 2515 0 1 2 3 2516 +---------------+---------------+---------------+---------------+ 2517 | Length | 164 | 1 | 2518 +---------------+---------------+---------------+---------------+ 2519 | IPV4 address of an interface | 2520 +---------------+---------------+---------------+---------------+ 2522 IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2 2524 +---------------+---------------+---------------+---------------+ 2525 | Length | 164 | 2 | 2526 +---------------+---------------+---------------+---------------+ 2527 | | 2528 + + 2529 | | 2530 + IPV6 address of an interface + 2531 | | 2532 + + 2533 | | 2534 +---------------+---------------+---------------+---------------+ 2536 B.3.7. TCLASS Object 2538 TCLASS object (traffic class based on IEEE 802.1p) uses object 2539 class = 165. 2541 0 1 2 3 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | Length | 165 | 1 | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | /// | /// | /// | /// | PV | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2548 Only 3 bits in data contain the user_priority value (PV). 2550 B.4. RSVP PATH and PATH_TEAR Message Formats 2552 As specified in the RSVP specification, a PATH and PATH_TEAR mes- 2553 sages contain the RSVP Common Header and the relevant RSVP objects. 2555 SBM (Subnet Bandwidth Manager) October, 1999 2557 For the RSVP Common Header, refer to the RSVP specification (RFC 2558 2205). Enhancements to an RSVP_PATH message include additional 2559 objects as specified below. 2561 ::= [] 2562 2563 [] 2564 [] 2566 ::= [] 2567 2568 [] 2570 If the INTEGRITY object is present, it must immediately follow the 2571 RSVP common header. L2-specific objects must always precede the 2572 SESSION object. 2574 B.5. RSVP RESV Message Format 2576 As specified in the RSVP specification, an RSVP_RESV message con- 2577 tains the RSVP Common Header and relevant RSVP objects. In addi- 2578 tion, it may contain an optional TCLASS object as described ear- 2579 lier. 2581 B.6. Additional RSVP message types to handle SBM interactions 2583 New RSVP message types are introduced to allow interactions between 2584 a DSBM and an RSVP node (host/router) for the purpose of discover- 2585 ing and binding to a DSBM. New RSVP message types needed are as 2586 follows: 2588 RSVP Msg Type (8 bits) Value 2589 DSBM_WILLING 66 2590 I_AM_DSBM 67 2592 All SBM-specific messages are formatted as RSVP messages with an 2593 RSVP common header followed by SBM-specific objects. 2595 ::= 2597 where ::= [] 2599 For each SBM message type, there is a set of rules for the permis- 2600 sible choice of object types. These rules are specified using 2602 SBM (Subnet Bandwidth Manager) October, 1999 2604 Backus-Naur Form (BNF) augmented with square brackets surrounding 2605 optional sub-sequences. The BNF implies an order for the objects in 2606 a message. However, in many (but not all) cases, object order makes 2607 no logical difference. An implementation should create messages 2608 with the objects in the order shown here, but accept the objects in 2609 any permissible order. Any exceptions to this rule will be pointed 2610 out in the specific message formats. 2612 DSBM_WILLING Message 2614 ::= 2615 2617 I_AM_DSBM Message 2619 ::= 2620 2621 [] 2623 For compatibility reasons, receivers of the I_AM_DSBM message must 2624 be prepared to receive additional objects of the Unknown Class type 2625 [RFC-2205]. 2627 All I_AM_DSBM messages are multicast to the well known AllSBMAd- 2628 dress. The default priority of a SBM is 1 and higher priority 2629 values represent higher precedence. The priority value zero indi- 2630 cates that the SBM is not eligible to be the DSBM. 2632 Relevant Objects 2634 DSBM IP ADDRESS objects use object class = 42; IPv4 DSBM IP ADDRESS 2635 object uses and IPv6 DSBM IP ADDRESS object 2636 uses . 2638 IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1 2639 0 1 2 3 2640 +---------------+---------------+---------------+---------------+ 2641 | IPv4 DSBM IP Address | 2642 +---------------+---------------+---------------+---------------+ 2644 IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 2 2646 SBM (Subnet Bandwidth Manager) October, 1999 2648 +---------------+---------------+---------------+---------------+ 2649 | | 2650 + + 2651 | | 2652 + IPv6 DSBM IP Address + 2653 | | 2654 + + 2655 | | 2656 +---------------+---------------+---------------+---------------+ 2658 Object is the same as object with C-Type 2659 =1 for IEEE Canonical Address format. 2661 ::= 2663 a SBM may omit this object by including a NULL L2 address object. For 2664 C-Type=1 (IEEE Canonical address format), such a version of the L2 2665 address object contains value zero in the six octet s corresponding to the 2666 MAC address (see section B.3.4 for the exact format). 2668 SBM_PRIORITY Object: class = 43, C-Type =1 2670 0 1 2 3 2671 +---------------+---------------+---------------+---------------+ 2672 | /// | /// | /// | SBM priority | 2673 +---------------+---------------+---------------+---------------+ 2675 TIMER INTERVAL VALUES. 2677 The two timer intervals, namely, DSBM Dead Interval and DSBM 2678 Refresh Interval, are specified as integer values each in the 2679 range of 0..255 seconds. Both values are included in a single 2680 "DSBM Timer Intervals" object described below. 2682 DSBM Timer Intervals Object: class = 44, C-Type =1 2684 +---------------+---------------+---------------+----------------+ 2685 | /// | /// | DeadInterval | RefreshInterval| 2686 +---------------+---------------+---------------+----------------+ 2688 NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 1 2690 0 1 2 3 2691 +---------------+---------------+---------------+----------------+ 2692 | NonResvSendLimit(limit on traffic allowed to send without RESV)| 2693 | | 2694 +---------------+---------------+---------------+----------------+ 2696 SBM (Subnet Bandwidth Manager) October, 1999 2698 ::= (class=12, C-Type =2) 2700 The NON_RESV_SEND_LIMIT object specifies a per-flow limit on the 2701 profile of traffic which a sending host is allowed to send onto a 2702 managed segment without a valid RSVP reservation (see Appendix C 2703 for further details on the usage of this object). The object con- 2704 tains the NonResvSendLimit parameter. This parameter is equivalent 2705 to the Intserv SENDER_TSPEC (see RFC 2210 for contents and encoding 2706 rules). The SENDER_TSPEC includes five parameters which describe a 2707 traffic profile (r, b, p, m and M). Sending hosts compare the 2708 SENDER_TSPEC describing a sender traffic flow to the SENDER_TSPEC 2709 advertised by the DSBM. If the SENDER_TSPEC of the traffic flow in 2710 question is less than or equal to the SENDER_TSPEC advertised by 2711 the DSBM, it is allowable to send traffic on the corresponding flow 2712 without a valid RSVP reservation in place. Otherwise it is not. 2714 The network administrator may configure the DSBM to disallow any 2715 sent traffic in the absence of an RSVP reservation by configuring a 2716 NonResvSendLimit in which r = 0, b = 0, p = 0, m = infinity and M = 2717 0. Similarly the network administrator may allow any traffic to be 2718 sent in the absence of an RSVP reservation by configuring a Non- 2719 ResvSendLimit in which r = infinity, b = infinity, p = infinity, m 2720 = 0 and M = infinity. Of course, any of these parameters may be set 2721 to values between zero and infinity to advertise finite per-flow 2722 limits. 2724 The NON_RESV_SEND_LIMIT object is optional. Senders on a managed 2725 segment should interpret the absence of the NON_RESV_SEND_LIMIT 2726 object as equivalent to an infinitely large SENDER_TSPEC (it is 2727 permissible to send any traffic profile in the absence of an RSVP 2728 reservation). 2730 SBM (Subnet Bandwidth Manager) October, 1999 2732 Appendix C 2733 The DSBM as a Source of Centralized Configuration Information 2735 There are certain configuration parameters which it may be useful 2736 to distribute to layer-3 senders on a managed segment. The DSBM may 2737 serve as a centralized management point from which such parameters 2738 can easily be distributed. In particular, it is possible for the 2739 network administrator configuring a DSBM to cause certain confi- 2740 guration parameters to be distributed as objects appended to the 2741 I_AM_DSBM messages. The following configuration object is defined 2742 at this time. Others may be defined in the future. See Appendix B 2743 for further details regarding the NON_RESV_SEND_LIMIT object. 2745 C.1. NON_RESV_SEND_LIMIT 2747 As we QoS enable layer 2 segments, we expect an evolution from sub- 2748 nets comprised of traditional shared segments (with no means of 2749 traffic separation and no DSBM), to subnets comprised of dedicated 2750 segments switched by sophisticated switches (with both DSBM and 2751 802.1p traffic separation capability). 2753 A set of intermediate configurations consists of a group of QoS 2754 enabled hosts sending onto a traditional shared segment. A layer-3 2755 device (or a layer-2 device) acts as a DSBM for the shared segment, 2756 but cannot enforce traffic separation. In such a configuration, the 2757 DSBM can be configured to limit the number of reservations approved 2758 for senders on the segment, but cannot prevent them from sending. 2759 As a result, senders may congest the segment even though a network 2760 administrator has configured an appropriate limit for admission 2761 control in the DSBM. 2763 One solution to this problem which would give the network adminis- 2764 trator control over the segment, is to require applications (or 2765 operating systems on behalf of applications) not to send until they 2766 have obtained a reservation. This is problematic as most applica- 2767 tions are used to sending as soon as they wish to and expect to get 2768 whatever service quality the network is able to grant at that time. 2769 Furthermore, it may often be acceptable to allow certain applica- 2770 tions to send before a reservation is received. For example, on a 2771 segment comprised of a single 10 Mbps ethernet and 10 hosts, it may 2772 be acceptable to allow a 16 Kbps telephony stream to be transmitted 2773 but not a 3 Mbps video stream. 2775 A more pragmatic solution then, is to allow the network administra- 2776 tor to set a per-flow limit on the amount of non-adaptive traffic 2777 which a sender is allowed to generate on a managed segment in the 2778 absence of a valid reservation. This limit is advertised by the 2779 DSBM and received by sending hosts. An API on the sending host can 2781 SBM (Subnet Bandwidth Manager) October, 1999 2783 then approve or deny an application's QoS request based on the 2784 resources requested. 2786 The NON_RESV_SEND_LIMIT object can be used to advertise a Flowspec 2787 which describes the shape of traffic that a sender is allowed to 2788 generate on a managed segment when its RSVP reservation requests 2789 have either not yet completed or have been rejected. 2791 SBM (Subnet Bandwidth Manager) October, 1999 2793 ACKNOWLEDGEMENTS 2795 Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel), 2796 David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman 2797 (3COM), Andrew Smith (Extreme Networks) for their constructive com- 2798 ments on the SBM design and the earlier versions of this document. 2800 6. Authors` Addresses 2802 Raj Yavatkar 2803 Intel Corporation 2804 2111 N.E. 25th Avenue, 2805 Hillsboro, OR 97124 2806 USA 2807 phone: +1 503-264-9077 2808 email: yavatkar@ibeam.intel.com 2810 Don Hoffman 2811 Teledesic Corporation 2812 2300 Carillon Point 2813 Kirkland, WA 98033 2814 USA 2815 phone: +1 425-602-0000 2817 Yoram Bernet 2818 Microsoft 2819 1 Microsoft Way 2820 Redmond, WA 98052 2821 USA 2822 phone: +1 206 936 9568 2823 email: yoramb@microsoft.com 2825 Fred Baker 2826 Cisco Systems 2827 519 Lado Drive 2828 Santa Barbara, California 93111 2829 USA 2830 phone: +1 408 526 4257 2831 email: fred@cisco.com 2833 Michael Speer 2834 Sun Microsystems, Inc 2835 901 San Antonio Road UMPK15-215 2836 Palo Alto, CA 94303 2837 phone: +1 650-786-6368 2838 email: speer@Eng.Sun.COM 2840 SBM (Subnet Bandwidth Manager) October, 1999