idnits 2.17.1 draft-ietf-issll-is802-sbm-08.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. ** 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 51 instances of too long lines in the document, the longest one being 50 characters in excess of 72. ** The abstract seems to contain references ([Ghanwani98], [Ghanwani98,Seaman98], [RFC-2210], [Baker97], [RFC-2205], [IEEEP8021p], [RFC-2206], [RFC-2211], [RFC-2212], [IEEE802Q], [RFC-2213], [RFC-1700], [IEEE802Q,IEEE8021p], [Seaman98], [RFC-2215], [IEEE8021P], [IEEE8021Q], [IEEE8021D], [RFC-1633,RFC-2205,, RFC-2210]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 1795 has weird spacing: '...riority to de...' == Line 1798 has weird spacing: '... tie is broke...' == Line 1842 has weird spacing: '...listens for i...' == Line 1848 has weird spacing: '...sending out a...' == (6 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1999) is 9112 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? 'Ghanwani98' on line 1712 looks like a reference -- Missing reference section? 'Seaman98' on line 1717 looks like a reference -- Missing reference section? 'IEEE8021D' on line 1734 looks like a reference -- Missing reference section? 'IEEE8021P' on line 229 looks like a reference -- Missing reference section? 'IEEE802Q' on line 1721 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 2623 looks like a reference -- Missing reference section? 'RFC-2212' on line 1699 looks like a reference -- Missing reference section? 'Baker97' on line 1690 looks like a reference -- Missing reference section? 'RFC-2211' on line 1696 looks like a reference -- Missing reference section? 'RFC-2206' on line 1693 looks like a reference -- Missing reference section? 'RFC-2215' on line 1702 looks like a reference -- Missing reference section? 'RFC-2210' on line 1706 looks like a reference -- Missing reference section? 'RFC-2213' on line 1709 looks like a reference -- Missing reference section? 'IEEEP8021p' on line 1725 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 20 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 draft-ietf-issll-is802-sbm-08.txt Michael Speer, Sun Microsystems 7 May 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) March, 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) March, 1999 44 1. Introduction 46 New extensions to the Internet architecture and service models have 47 been defined for an integrated services Inernet [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 [Ghanwani98, Seaman98]. 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) March, 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) March, 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) March, 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) March, 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) March, 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 layer2 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) March, 1999 312 single managed segment for the purpose of admission control. 314 SBM (Subnet Bandwidth Manager) March, 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) March, 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) March, 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 RESVERR 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) March, 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) March, 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_CONFM, 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) March, 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) March, 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 [Seaman98] 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) March, 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 [Seaman98]. 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 [Seaman98]. 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) March, 1999 707 over IEEE 802 networks [Seaman98] 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) March, 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) March, 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) March, 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) March, 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) March, 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) March, 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) March, 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 [Seaman98]. If the message already 1049 SBM (Subnet Bandwidth Manager) March, 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) March, 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) March, 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) March, 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 L3L2 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) March, 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) March, 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) March, 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) March, 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) March, 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 [Seaman98]. 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) March, 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) March, 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 end2end 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) March, 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 Implementors 1602 SBM (Subnet Bandwidth Manager) March, 1999 1604 In the following, we provide guidelines for implementors 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 [Ghanwani98] 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 implementors 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) March, 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 some security issues, but they are no different than the 1667 ones raised by the use of RSVP and Integrated Services; the need 1668 to control and authenticate access to enhanced qualities of ser- 1669 vice. This requirement is discussed further in [RFC-2205], [RFC- 1670 2211], and [RFC-2212]. [Baker97] describes the mechanism used to 1671 protect the integrity of RSVP messages carrying the information 1672 described here. A SBM implementation should satisfy these require- 1673 ments and provide the suggested mechanisms just as though it were 1674 a conventional RSVP implementation and also protect the addi- 1675 tional, SBM-specific objects in a message. 1677 In addition, it is also necessary to authenticate DSBM candidates 1678 during the election process, and a mechanism based on a shared 1679 secret among the DSBM candidates may be used. The mechanism 1680 defined in [Baker97] should be used. 1682 SBM (Subnet Bandwidth Manager) March, 1999 1684 9. References 1686 [RFC-2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 1687 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1688 Specification ", RFC-2205, September 1997. 1690 [Baker97] F. Baker., "RSVP Cryptographic Authentication", draft- 1691 ietf-rsvp-md5-05.txt, August 1997. 1693 [RFC-2206] F. Baker, J. Krawczyk, "RSVP Management Information 1694 Base", RFC 2206, September 1997. 1696 [RFC-2211] J. Wroclawski, "Specification of the Controlled-Load 1697 Network Element Service", RFC-2211, September 1997. 1699 [RFC-2212] S. Shenker, C. Partridge, R. Guerin, "Specification of 1700 Guaranteed Quality of Service", RFC-2212, September 1997. 1702 [RFC-2215] S. Shenker, J. Wroclawski, "General Characterization 1703 Parameters for Integrated Service Network Elements", RFC-2215, 1704 September 1997. 1706 [RFC-2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 1707 Services", RFC 2210, September 1997. 1709 [RFC-2213] F. Baker, J. Krawczyk, "Integrated Services Management 1710 Information Base", RFC 2213, September 1997. 1712 [Ghanwani98] A. Ghanwani, W. Pace, V. Srinivasan, A.Smith, 1713 M.Seaman "A Framework for Providing Integrated Services Over 1714 Shared and Switched LAN Technologies", Internet Draft , November 1998. 1717 [Seaman98] M. Seaman, A. Smith, E. Crawley, "Integrated Service 1718 Mappings on IEEE 802 Networks", Internet Draft , November 1998. 1721 [IEEE802Q] "IEEE Standards for Local and Metropolitan Area Net- 1722 works: Virtual Bridged Local Area Networks", Draft Standard 1723 P802.1Q/D9, February 20, 1998. 1725 [IEEEP8021p] "Information technology - Telecommunications and 1726 information exchange between systems - Local and metropolitan area 1727 networks - Common specifications - Part 3: Media Access Control 1728 (MAC) Bridges: Revision (Incorporating IEEE P802.1p: Traffic 1729 Class Expediting and Dynamic Multicast Filtering)", ISO/IEC Final 1730 CD 15802-3 IEEE P802.1D/D15, November 24, 1997. 1732 SBM (Subnet Bandwidth Manager) March, 1999 1734 [IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D- 1735 1993. 1737 SBM (Subnet Bandwidth Manager) March, 1999 1739 Appendix A 1740 DSBM Election Algorithm 1742 A.1. Introduction 1744 To simplify the rest of this discussion, we will assume that there 1745 is a single DSBM for the entire L2 domain (i.e., assume a shared 1746 L2 segment for the entire L2 domain). Later, we will discuss how a 1747 DSBM is elected for a half-duplex or full-duplex switched segment. 1749 To allow for quick recovery from the failure of a DSBM, we assume 1750 that additional SBMs may be active in a L2 domain for fault toler- 1751 ance. When more than one SBM is active in a L2 domain, the SBMs 1752 use an election algorithm to elect a DSBM for the L2 domain. After 1753 the DSBM is elected and is operational, other SBMs remain passive 1754 in the background to step in to elect a new DSBM when necessary. 1755 The protocol for electing and discovering DSBM is called the "DSBM 1756 election protocol" and is described in the rest of this Appendix. 1758 A.1.1. How a DSBM Client Detects a Managed Segment 1760 Once elected, a DSBM periodically multicasts an I_AM_DSBM message 1761 on the AllSBMAddress to indicate its presence. The message is sent 1762 every period (e.g., every 5 seconds) according to the 1763 DSBMRefreshInterval timer value (a configuration parameter). 1764 Absence of such a message over a certain time interval (called 1765 "DSBMDeadInterval"; another configuration parameter typically set 1766 to a multiple of RefreshInterval) indicates that the DSBM has 1767 failed or terminated and triggers another round of the DSBM elec- 1768 tion. The DSBM clients always listen for periodic DSBM advertise- 1769 ments. The advertisement includes the unicast IP address of the 1770 DSBM (DSBMAddress) and DSBM clients send their PATH/RESV (or 1771 other) messages to the DSBM. When a DSBM client detects the 1772 failure of a DSBM, it waits for a subsequent I_AM_DSBM advertise- 1773 ment before resuming any communication with the DSBM. During the 1774 period when a DSBM is not present, a DSBM client may forward out- 1775 going PATH messages using the standard RSVP forwarding rules. 1777 The exact message formats and addresses used for communication 1778 with (and among) SBM(s) are described in Appendix B. 1780 A.2. Overview of the DSBM Election Procedure 1782 SBM (Subnet Bandwidth Manager) March, 1999 1784 When a SBM first starts up, it listens for incoming DSBM adver- 1785 tisements for some period to check whether a DSBM already exists 1786 in its L2 domain. If one already exists (and no new election is in 1787 progress), the new SBM stays quiet in the background until an 1788 election of DSBM is necessary. All messages related to the DSBM 1789 election and DSBM advertisements are always sent to the AllSBMAd- 1790 dress. 1792 If no DSBM exists, the SBM initiates the election of a DSBM by 1793 sending out a DSBM_WILLING message that lists its IP address as a 1794 candidate DSBM and its "SBM priority". Each SBM is assigned a 1795 priority to determine its relative precedence. When more than one 1796 SBM candidate exists, the SBM priority determines who gets to be 1797 the DSBM based on the relative priority of candidates. If there is 1798 a tie based on the priority value, the tie is broken using the IP 1799 addresses of tied candidates (one with the higher IP address in 1800 the lexicographic order wins). The details of the election proto- 1801 col start in Section A.4. 1803 A.2.1 Summary of the Election Algorithm 1805 For the purpose of the algorithm, a SBM is in one of the four 1806 states (Idle, DetectDSBM, ElectDSBM, I_AM_DSBM). 1808 A SBM (call it X) starts up in the DetectDSBM state and waits for 1809 a ListenInterval for incoming I_AM_DSBM (DSBM advertisement) or 1810 DSBM_WILLING messages. If an I_AM_DSBM advertisement is received 1811 during this state, the SBM notes the current DSBM (its IP address 1812 and priority) and enters the Idle state. If a DSBM_WILLING message 1813 is received from another SBM (call it Y) during this state, then X 1814 enters the ElectDSBM state. Before entering the new state, X first 1815 checks to see whether it itself is a better candidate than Y and, 1816 if so, sends out a DSBM_WILLING message and then enters the 1817 ElectDSBM state. 1819 When a SBM (call it X) enters the ElectDSBM state, it sets a timer 1820 (called ElectionIntervalTimer that is typically set to a value at 1821 least equal to the DeadIntervalTimer value) to wait for the elec- 1822 tion to finish and to discover who is the best candidate. In this 1823 state, X keeps track of the best (or better) candidate seen so far 1824 (including itself). Whenever it receives another DSBM_WILLING mes- 1825 sage, it updates its notion of the best (or better) candidate 1826 based on the priority (and tie-breaking) criterion. During the 1827 ElectionInterval, X sends out a DSBM_WILLING message every 1828 RefreshInterval to (re)assert its candidacy. 1830 SBM (Subnet Bandwidth Manager) March, 1999 1832 At the end of the ElectionInterval, X checks whether it is the 1833 best candidate so far. If so, it declares itself to be the DSBM 1834 (by sending out the I_AM_DSBM advertisement) and enters the 1835 I_AM_DSBM state; otherwise, it decides to wait for the best candi- 1836 date to declare itself the winner. To wait, X re-initializes its 1837 ElectDSBM state and continues to wait for another round of elec- 1838 tion (each round lasts for an ElectionTimerInterval duration). 1840 A SBM is in Idle state when no election is in progress and the 1841 DSBM is already elected (and happens to be someone else). In this 1842 state, it listens for incoming I_AM_DSBM advertisements and uses 1843 a DSBMDeadInterval timer to detect the failure of DSBM. Every time 1844 the advertisement is received, the timer is restarted. If the 1845 timer fires, the SBM goes into the DetectDSBM state to prepare to 1846 elect the new DSBM. If a SBM receives a DSBM_WILLING message from 1847 the current DSBM in this state, the SBM enters the ElectDSBM state 1848 after sending out a DSBM_WILLING message (to announce its own 1849 candidacy). 1851 In the I_AM_DSBM state, the DSBM sends out I_AM_DSBM advertise- 1852 ments every refresh interval. If the DSBM wishes to shut down 1853 (gracefully terminate), it sends out a DSBM_WILLING message (with 1854 SBM priority value set to zero) to initiate the election pro- 1855 cedure. The priority value zero effectively removes the outgoing 1856 DSBM from the election procedure and makes way for the election of 1857 a different DSBM. 1859 A.3. Recovering from DSBM Failure 1861 When a DSBM fails (DSBMDeadInterval timer fires), all the SBMs 1862 enter the ElectDSBM state and start the election process. 1864 At the end of the ElectionInterval, the elected DSBM sends out an 1865 I_AM_DSBM advertisement and the DSBM is then operational. 1867 A.4. DSBM Advertisements 1869 The I_AM_DSBM advertisement contains the following information: 1871 1. DSBM address information -- contains the IP and L2 addresses 1872 of the DSBM and its SBM priority (a configuration parameter 1874 SBM (Subnet Bandwidth Manager) March, 1999 1876 -- priority specified by a network administrator). The prior- 1877 ity value is used to choose among candidate SBMs during the 1878 election algorithm. Higher integer values indicate higher 1879 priority and the value is in the range 0..255. The value zero 1880 indicates that the SBM is not eligible to be the DSBM. The 1881 IP address is required and used for breaking ties. The L2 1882 address is for the interface of the managed segment. 1884 2. refresh interval -- contains the value of the refresh inter- 1885 val in seconds. Value zero indicates the parameter has been 1886 omitted in the message. Receivers may substitute their own 1887 default value in this case. 1889 3. SBMDeadInterval -- contains the value of the SBMDeadInterval 1890 in seconds. If the value is omitted (or value zero is speci- 1891 fied), a default value (from initial configuration) should be 1892 used. 1894 4. Miscellaneous configuration information to be advertised to 1895 senders on the managed segment. See Appendix C for further 1896 details. 1898 A.5. DSBM_WILLING Messages 1900 When a SBM wishes to declare its candidacy to be the DSBM during 1901 an election phase, it sends out a DSBM_WILLING message. The 1902 DSBM_WILLING message contains the following information: 1904 1. DSBM address information -- Contains the SBM's own addresses 1905 (IP and L2 address), if it wishes to be the DSBM. The IP 1906 address is required and used for breaking ties. The L2 1907 address is the address of the interface for the managed seg- 1908 ment in question. Also, the DSBM address information 1909 includes the corresponding priority of the SBM whose address 1910 is given above. 1912 SBM (Subnet Bandwidth Manager) March, 1999 1914 A.6. SBM State Variables 1916 For each network interface, a SBM maintains the following state 1917 variables related to the election of the DSBM for the L2 domain on 1918 that interface: 1920 a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, 1921 0.0.0.0) and priority. All IP addresses are assumed to be in 1922 network byte order. In addition, current DSBM's L2 address is 1923 also stored as part of this state information. 1925 b) OwnAddrInfo -- SBM's own IP address and L2 address for the 1926 interface and its own priority (a configuration parameter). 1928 c) DSBM RefreshInterval in seconds. When the DSBM is not yet 1929 elected, it is set to a default value specified as a confi- 1930 guration parameter. 1932 d) DSBMDeadInterval in seconds. When the DSBM is not yet 1933 elected, it is initially set to a default value specified as 1934 a configuration parameter. 1936 f) ListenInterval in seconds -- a configuration parameter 1937 that decides how long a SBM spends in the DetectDSBM state 1938 (see below). 1940 g) ElectionInterval in seconds -- a configuration parameter 1941 that decides how long a SBM spends in the ElectDSBM state 1942 when it has declared its candidacy. 1944 Figure 3 shows the state transition diagram for the election pro- 1945 tocol and the various states are described below. A complete 1946 description of the state machine is provided in Section A.10. 1948 A.7. DSBM Election States 1950 DOWN -- SBM is not operational. 1952 SBM (Subnet Bandwidth Manager) March, 1999 1954 DetectDSBM -- typically, the initial state of a SBM when it 1955 starts up. In this state, it checks to see whether a DSBM 1956 already exists in its domain. 1958 Idle -- SBM is in this state when no election is in progress 1959 and it is not the DSBM. In this state, SBM passively monitors 1960 the state of the DSBM. 1962 ElectDSBM -- SBM is in this state when a DSBM election is in 1963 progress. 1965 IAMDSBM -- SBM is in this state when it is the DSBM for the 1966 L2 domain. 1968 A.8. Events that cause state changes 1970 StartUp -- SBM starts operation. 1972 ListenInterval Timeout -- The ListenInterval timer has fired. 1973 This means that the SBM has monitored its domain to check for 1974 an existing DSBM or to check whether there are candidates 1975 (other than itself) willing to be the DSBM. 1977 DSBM_WILLING message received -- This means that the SBM 1978 received a DSBM_WILLING message from some other SBM. Such a 1979 message is sent when a SBM wishes to declare its candidacy to 1980 be the DSBM. 1982 I_AM_DSBM message received -- SBM received a DSBM advertise- 1983 ment from the DSBM in its L2 domain. 1985 SBMDeadInterval Timeout -- The SBMDeadInterval timer has 1986 fired. This means that the SBM did not receive even one DSBM 1987 advertisement during this period and indicates possible 1988 failure of the DSBM. 1990 SBM (Subnet Bandwidth Manager) March, 1999 1992 RefreshInterval Timeout -- The RefreshInterval timer has 1993 fired. In the I_AM_DSBM state, this means it is the time for 1994 sending out the next DSBM advertisement. In the ElectDSBM 1995 state, the event means that it is the time to send out 1996 another DSBM_WILLING message. 1998 ElectionInterval Timeout -- The ElectionInterval timer has 1999 fired. This means that the SBM has waited long enough after 2000 declaring its candidacy to determine whether or not it suc- 2001 ceeded. 2003 CONTINUED ON NEXT PAGE 2005 SBM (Subnet Bandwidth Manager) March, 1999 2007 A.9. State Transition Diagram (Figure 3) 2009 +-----------+ 2010 +--<--------------<-|DetectDSBM |---->------+ 2011 | +-----------+ | 2012 | | 2013 | | 2014 | | 2015 | +-------------+ +---------+ | 2016 +->---| Idle |--<>---|ElectDSBM|--<--+ 2017 +-------------+ +---------+ 2018 | | 2019 | | 2020 | | 2021 | +-----------+ | 2022 +<<- +---| IAMDSBM |-<-+ 2023 | +-----------+ 2024 | 2025 | +-----------+ 2026 +>>-| SHUTDOWN | 2027 +-----------+ 2029 A.10. Election State Machine 2031 Based on the events and states described above, the state changes 2032 at a SBM are described below. Each state change is triggered by an 2033 event and is typically accompanied by a sequence of actions. The 2034 state machine is described assuming a single threaded implementa- 2035 tion (to avoid race conditions between state changes and timer 2036 events) with no timer events occurring during the execution of the 2037 state machine. 2039 The following routines will be frequently used in the description 2040 of the state machine: 2042 ComparePrio(FirstAddrInfo, SecondAddrInfo) 2043 -- determines whether the entity represented by the first parameter 2044 is better than the second entity using the priority information 2045 and the IP address information in the two parameters. 2046 If any address is zero, that entity 2047 automatically loses; then first priorities are compared; higher 2048 priority candidate wins. If there is a tie based on 2049 the priority value, the tie is broken using the IP 2050 addresses of tied candidates (one with the higher IP address in the 2051 lexicographic order wins). Returns TRUE if first entity is a better 2053 SBM (Subnet Bandwidth Manager) March, 1999 2055 choice. FALSE otherwise. 2057 SendDSBMWilling Message() 2058 Begin 2059 Send out DSBM_WILLING message listing myself as a candidate for 2060 DSBM (copy OwnAddr and priority into appropriate fields) 2061 start RefreshIntervalTimer 2062 goto ElectDSBM state 2063 End 2065 AmIBetterDSBM(OtherAddrInfo) 2066 Begin 2067 if (ComparePrio(OwnAddrInfo, OtherAddrInfo)) 2068 return TRUE 2070 change LocalDSBMInfo = OtherDSBMAddrInfo 2071 return FALSE 2072 End 2074 UpdateDSBMInfo() 2075 /* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */ 2076 Begin 2077 update LocalDSBMInfo such as IP addr, DSBM L2 address, 2078 DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer 2079 End 2081 A.10.1 State Changes 2083 In the following, the action "continue" or "continue in current 2084 state" means an "exit" from the current action sequence without a 2085 state transition. 2087 State: DOWN 2088 Event: StartUp 2089 New State: DetectDSBM 2090 Action: Initialize the local state variables (LocalDSBMADDR and 2091 LocalDSBMAddrInfo set to 0). Start the ListenIntervalTimer. 2093 State: DetectDSBM 2094 New State: Idle 2095 Event: I_AM_DSBM message received 2096 Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2097 start DeadDSBMInterval timer 2098 goto Idle State 2100 SBM (Subnet Bandwidth Manager) March, 1999 2102 State: DetectDSBM 2103 Event: ListenIntervalTimer fired 2104 New State: ElectDSBM 2105 Action: Start ElectionIntervalTimer 2106 SendDSBMWillingMessage(); 2108 State: DetectDSBM 2109 Event: DSBM_WILLING message received 2110 New State: ElectDSBM 2111 Action: Cancel any active timers 2113 Start ElectionIntervalTimer 2114 /* am I a better choice than this dude? */ 2115 If (ComparePrio(OwnAddrInfo, IncomingDSBMInfo)) { 2116 /* I am better */ 2117 SendDSBMWillingMessage() 2118 } else { 2119 Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2120 goto ElectDSBM state 2121 } 2123 State: Idle 2124 Event: SBMDeadInterval timer fired. 2125 New State: ElectDSBM 2126 Action: start ElectionIntervalTimer 2127 set LocalDSBMAddrInfo = OwnAddrInfo 2128 SendDSBMWiliingMessage() 2130 State: Idle 2131 Event: I_AM_DSBM message received. 2132 New State: Idle 2133 Action: /* first check whether anything has changed */ 2134 if (!ComparePrio(LocalDSBMAddrInfo, IncomingDSBMAddrInfo)) 2135 change LocalDSBMAddrInfo to reflect new info 2136 endif 2137 restart DSBMDeadIntervalTimer; 2138 continue in current state; 2140 State: Idle 2141 Event: DSBM_WILLING Message is received 2142 New State: Depends on action (ElectDSBM or Idle) 2143 Action: /* check whether it is from the DSBM itself (shutdown) */ 2144 if (IncomingDSBMAddr == LocalDSBMAddr) { 2145 cancel active timers 2146 Set LocalDSBMAddrInfo = OwnAddrInfo 2147 Start ElectionIntervalTimer 2148 SendDSBMWillingMessage() /* goto ElectDSBM state */ 2149 } 2151 SBM (Subnet Bandwidth Manager) March, 1999 2153 /* else, ignore it */ 2154 continue in current state 2156 State: ElectDSBM 2157 Event: ElectionIntervalTimer Fired 2158 New State: depends on action (I_AM_DSBM or Current State) 2159 Action: If (LocalDSBMAddrInfo == OwnAddrInfo) { 2160 /* I won */ 2161 send I_AM_DSBM message 2162 start RefreshIntervalTimer 2163 goto I_AM_DSBM state 2164 } else { /* someone else won, so wait for it to declare 2165 itself to be the DSBM */ 2166 set LocalDSBMAddressInfo = OwnAddrInfo 2167 start ElectionIntervalTimer 2168 SendDSBMWillingMessage() 2169 continue in current state 2170 } 2172 State: ElectDSBM 2173 Event: I_AM_DSBM message received 2174 New State: Idle 2175 Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2176 Cancel any active timers 2177 start DeadDSBMInterval timer 2178 goto Idle State 2180 State: ElectDSBM 2181 Event: DSBM_WILLING message received 2182 New State: ElectDSBM 2183 Action: Check whether it's a loopback and if so, discard, continue; 2184 if (!AmIBetterDSBM(IncomingDSBMAddrInfo)) { 2185 Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2186 Cancel RefreshIntervalTimer 2187 } else if (LocalDSBMAddrInfo == OwnAddrInfo) { 2188 SendDSBMWillingMessage() 2189 } 2190 continue in current state 2192 State: ElectDSBM 2193 Event: RefreshIntervalTimer fired 2194 New State: ElectDSBM 2195 Action: /* continue to send DSBMWilling messages until 2196 election interval ends */ 2197 SendDSBMWillingMessage() 2199 State: I_AM_DSBM 2200 Event: DSBM_WILLING message received 2202 SBM (Subnet Bandwidth Manager) March, 1999 2204 New State: depends on action (I_AM_DSBM or SteadyState) 2205 Action: /* check whether other guy is better */ 2206 If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) { 2207 /* I am better */ 2208 send I_AM_DSBM message 2209 restart RefreshIntervalTimer 2210 continue in current state 2211 } else { 2212 Set LocalDSBMAddrInfo = IncomingAddrInfo 2213 cancel active timers 2214 start DSBMDeadInterval timer 2215 goto SteadyState 2216 } 2218 State: I_AM_DSBM 2219 Event: RefreshIntervalTimer fired 2220 New State: I_AM_DSBM 2221 Action: send I_AM_DSBM message 2222 restart RefreshIntervalTimer 2224 State: I_AM_DSBM 2225 Event: I_AM_DSBM message received 2226 New State: depends on action (I_AM_DSBM or Idle) 2227 Action: /* check whether other guy is better */ 2228 If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) { 2229 /* I am better */ 2230 send I_AM_DSBM message 2231 restart RefreshIntervalTimer 2232 continue in current state 2233 } else { 2234 Set LocalDSBMAddrInfo = IncomingAddrInfo 2235 cancel active timers 2236 start DSBMDeadInterval timer 2237 goto Idle State 2238 } 2240 State: I_AM_DSBM 2241 Event: Want to shut myself down 2242 New State: DOWN 2243 Action: send DSBM_WILLING message with My address filled in, but 2244 priority set to zero 2245 goto Down State 2247 A.10.2 Suggested Values of Interval Timers 2249 To avoid DSBM outages for long period, to ensure quick recovery 2251 SBM (Subnet Bandwidth Manager) March, 1999 2253 from DSBM failures, and to avoid timeout of PATH and RESV state at 2254 the edge devices, we suggest the following values for various 2255 timers. 2257 Assuming that the RSVP implementations use a 30 second timeout for 2258 PATH and RESV refreshes, we suggest that the RefreshIntervalTimer 2259 should be set to about 5 seconds with DSBMDeadIntervalTimer set to 2260 15 seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be 2261 set to a random value between (DeadIntervalTimer, 2*DeadInterval- 2262 Timer). The ElectionIntervalTimer should be set at least to the 2263 value of DeadIntervalTimer to ensure that each SBM has a chance to 2264 have its DSBM_WILLING message (sent every RefreshInterval in 2265 ElectDSBM state) delivered to others. 2267 A.10.3. Guidelines for Choice of Values for SBM_PRIORITY 2269 Network administrators should configure SBM protocol entity at 2270 each SBM-capable device with the device's "SBM priority" for each 2271 of the interfaces attached to a managed segment. SBM_PRIORITY is 2272 an 8-bit, unsigned integer value (in the range 0-255) with higher 2273 integer values denoting higher priority. The value zero for an 2274 interface indicates that the SBM protocol entity on the device is 2275 not eligible to be a DSBM for the segment attached to the inter- 2276 face. 2278 A separate range of values is reserved for each type of SBM- 2279 capable device to reflect the relative priority among different 2280 classes of L2/L3 devices. L2 devices get higher priority followed 2281 by routers followed by hosts. The priority values in the range of 2282 128..255 are reserved for L2 devices, the values in the range of 2283 64..127 are reserved for routers, and values in the range of 1..63 2284 are reserved for hosts. 2286 A.11. DSBM Election over switched links 2288 The election algorithm works as described before in this case 2289 except each SBM-capable L2 device restricts the scope of the elec- 2290 tion to its local segment. As described in Section B.1 below, all 2291 messages related to the DSBM election are sent to a special multi- 2292 cast address (AllSBMAddress). AllSBMAddress (its corresponding MAC 2293 multicast address) is configured in the permanent database of 2294 SBM-capable, layer 2 devices so that all frames with AllSBMAddress 2295 as the destination address are not forwarded and instead directed 2297 SBM (Subnet Bandwidth Manager) March, 1999 2299 to the SBM management entity in those devices. Thus, a DSBM can be 2300 elected separately on each point-to-point segment in a switched 2301 topology. For example, in Figure 2, DSBM for "segment A" will be 2302 elected using the election algorithm between R1 and S1 and none of 2303 the election-related messages on this segment will be forwarded by 2304 S1 beyond "segment A". Similarly, a separate election will take 2305 place on each segment in this topology. 2307 When a switched segment is a half-duplex segment, two senders (one 2308 sender at each end of the link) share the link. In this case, one 2309 of the two senders will win the DSBM election and will be respon- 2310 sible for managing the segment. 2312 If a switched segment is full-duplex, exactly one sender sends on 2313 the link in each direction. In this case, either one or two DSBMs 2314 can exist on such a managed segment. If a sender at each end 2315 wishes to serve as a DSBM for that end, it can declare itself to 2316 be the DSBM by sending out an I_AM_DSBM advertisement and start 2317 managing the resources for the outgoing traffic over the segment. 2318 If one of the two senders does not wish itself to be the DSBM, 2319 then the other DSBM will not receive any DSBM advertisement from 2320 its peer and assume itself to be the DSBM for traffic traversing 2321 in both directions over the managed segment. 2323 SBM (Subnet Bandwidth Manager) March, 1999 2325 Appendix B 2326 Message Encapsulation and Formats 2328 To minimize changes to the existing RSVP implementations and to 2329 ensure quick deployment of a SBM in conjunction with RSVP, all 2330 communication to and from a DSBM will be performed using messages 2331 constructed using the current rules for RSVP message formats and 2332 raw IP encapsulation. For more details on the RSVP message for- 2333 mats, refer to the RSVP specification (RFC 2205). No changes to 2334 the RSVP message formats are proposed, but new message types and 2335 new L2-specific objects are added to the RSVP message formats to 2336 accommodate DSBM-related messages. These additions are described 2337 below. 2339 B.1 Message Addressing 2341 For the purpose of DSBM election and detection, AllSBMAddress is 2342 used as the destination address while sending out both 2343 DSBM_WILLING and I_AM_DSBM messages. A DSBM client first detects a 2344 managed segment by listening to I_AM_DSBM advertisements and 2345 records the DSBMAddress (unicast IP address of the DSBM). 2347 B.2. Message Sizes 2349 Each message must occupy exactly one IP datagram. If it exceeds 2350 the MTU, such a datagram will be fragmented by IP and reassembled 2351 at the recipient node. This has a consequence that a single mes- 2352 sage may not exceed the maximum IP datagram size, approximately 2353 64K bytes. 2355 B.3. RSVP-related Message Formats 2357 All RSVP messages directed to and from a DSBM may contain various 2358 RSVP objects defined in the RSVP specification and messages con- 2359 tinue to follow the formatting rules specified in the RSVP specif- 2360 ication. In addition, an RSVP implementation must also recognize 2361 new object classes that are described below. 2363 B.3.1. Object Formats 2365 SBM (Subnet Bandwidth Manager) March, 1999 2367 All objects are defined using the format specified in the RSVP 2368 specification. Each object has a 32-bit header that contains 2369 length (of the object in bytes including the object header), the 2370 object class number, and a C-Type. All unused fields should be set 2371 to zero and ignored on receipt. 2373 B.3.2. SBM Specific Objects 2375 Note that the Class-Num values for the SBM specific objects 2376 (LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2) are chosen from the 2377 codespace 10XXXXXX. This coding assures that non-SBM aware RSVP 2378 nodes will ignore the objects without forwarding them or generat- 2379 ing an error message. 2381 Within the SBM specific codespace, note the following interpreta- 2382 tion of the third most significant bit of the Class-Num: 2384 a) Objects of the form 100XXXXX are to be silently dis- 2385 carded by SBM nodes that do not recognize them. 2387 b) Objects of the form 101XXXXX are to be silently for- 2388 warded by SBM nodes that do not recognize them. 2390 B.3.3. IEEE 802 Canonical Address Format 2392 The 48-bit MAC Addresses used by IEEE 802 were originally defined 2393 in terms of wire order transmission of bits in the source and des- 2394 tination MAC address fields. The same wire order applied to both 2395 Ethernet and Token Ring. Since the bit transmission order of Ether- 2396 net and Token Ring data differ - Ethernet octets are transmitted 2397 least significant bit first, Token Ring most significant first - 2398 the numeric values naturally associated with the same address on 2399 different 802 media differ. To facilitate the communication of 2400 address values in higher layer protocols which might span both 2401 token ring and Ethernet attached systems connected by bridges, it 2402 was necessary to define one reference format - the so called canon- 2403 ical format for these addresses. Formally the canonical format 2404 defines the value of the address, separate from the encoding rules 2405 used for transmission. It comprises a sequence of octets derived 2406 from the original wire order transmission bit order as follows. The 2407 least significant bit of the first octet is the first bit transmit- 2408 ted, the next least significant bit the second bit, and so on to 2410 SBM (Subnet Bandwidth Manager) March, 1999 2412 the most significant bit of the first octet being the 8th bit 2413 transmitted; the least significant bit of the second octet is the 2414 9th bit transmitted, and so on to the most significant bit of the 2415 sixth octet of the canonical format being the last bit of the 2416 address transmitted. 2418 This canonical format corresponds to the natural value of the 2419 address octets for Ethernet. The actual transmission order or for- 2420 mal encoding rules for addresses on media which do not transmit bit 2421 serially are derived from the canonical format octet values. 2423 This document requires that all L2 addresses used in conjunction 2424 with the SBM protocol be encoded in the canonical format as a 2425 sequence of 6 octets. In the following, we define the object for- 2426 mats for objects that contain L2 addresses that are based on the 2427 canonical representation. 2429 B.3.4. RSVP_HOP_L2 object 2431 RSVP_HOP_L2 object uses object class = 161; it contains the L2 2432 address of the previous hop L3 device in the IEEE Canonical address 2433 format discussed above. 2435 RSVP_HOP_L2 object: class = 161, C-Type represents the addressing format 2436 used. In our case, C-Type=1 represents the IEEE Canonical Address 2437 format. 2439 0 1 2 3 2440 +---------------+---------------+---------------+----------------+ 2441 | Length | 161 |C-Type(addrtype)| 2442 +---------------+---------------+---------------+----------------+ 2443 | Variable length Opaque data | 2444 +---------------+---------------+---------------+----------------+ 2446 C-Type = 1 (IEEE Canonical Address format) 2448 When C-Type=1, the object format is: 2450 0 1 2 3 2451 +---------------+---------------+---------------+---------------+ 2452 | 12 | 161 | 1 | 2453 +---------------+---------------+---------------+---------------+ 2454 | Octets 0-3 of the MAC address | 2455 +---------------+---------------+---------------+---------------+ 2456 | Octets 4-5 of the MAC addr. | /// | /// | 2457 +---------------+---------------+---------------+---------------+ 2459 SBM (Subnet Bandwidth Manager) March, 1999 2461 /// -- unused (set to zero) 2463 B.3.5. LAN_NHOP object 2465 LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address 2466 object and LAN_NHOP_L2 address object. 2467 ::= 2469 LAN_NHOP_L2 address object uses object class = 162 and uses the 2470 same format (but different class number) as the RSVP_HOP_L2 object. 2471 It provides the L2 or MAC address of the next hop L3 device. 2473 0 1 2 3 2474 +---------------+---------------+---------------+----------------+ 2475 | Length | 162 |C-Type(addrtype)| 2476 +---------------+---------------+---------------+----------------+ 2477 | Variable length Opaque data | 2478 +---------------+---------------+---------------+----------------+ 2480 C-Type = 1 (IEEE 802 Canonical Address Format as defined below) 2481 See the RSVP_HOP_L2 address object for more details. 2483 LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP 2484 address of the next hop L3 device. 2486 LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6 address 2487 family used. 2489 IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1 2490 +---------------+---------------+---------------+---------------+ 2491 | Length = 8 | 163 | 1 | 2492 +---------------+---------------+---------------+---------------+ 2493 | IPv4 NHOP address | 2494 +---------------------------------------------------------------+ 2496 IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2 2497 +---------------+---------------+---------------+---------------+ 2498 | Length = 20 | 163 | 2 | 2499 +---------------+---------------+---------------+---------------+ 2500 | IPv6 NHOP address (16 bytes) | 2501 +---------------------------------------------------------------+ 2503 B.3.6. LAN_LOOPBACK Object 2505 SBM (Subnet Bandwidth Manager) March, 1999 2507 The LAN_LOOPBACK object gives the IP address of the outgoing inter- 2508 face for a PATH message and uses object class=164; both IPv4 and 2509 IPv6 formats are specified. 2511 IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1 2513 0 1 2 3 2514 +---------------+---------------+---------------+---------------+ 2515 | Length | 164 | 1 | 2516 +---------------+---------------+---------------+---------------+ 2517 | IPV4 address of an interface | 2518 +---------------+---------------+---------------+---------------+ 2520 IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2 2522 +---------------+---------------+---------------+---------------+ 2523 | Length | 164 | 2 | 2524 +---------------+---------------+---------------+---------------+ 2525 | | 2526 + + 2527 | | 2528 + IPV6 address of an interface + 2529 | | 2530 + + 2531 | | 2532 +---------------+---------------+---------------+---------------+ 2534 B.3.7. TCLASS Object 2536 TCLASS object (traffic class based on IEEE 802.1p) uses object 2537 class = 165. 2539 0 1 2 3 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 | Length | 165 | 1 | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | /// | /// | /// | /// | PV | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 Only 3 bits in data contain the user_priority value (PV). 2548 B.4. RSVP PATH and PATH_TEAR Message Formats 2550 As specified in the RSVP specification, a PATH and PATH_TEAR mes- 2551 sages contain the RSVP Common Header and the relevant RSVP objects. 2553 SBM (Subnet Bandwidth Manager) March, 1999 2555 For the RSVP Common Header, refer to the RSVP specification (RFC 2556 2205). Enhancements to an RSVP_PATH message include additional 2557 objects as specified below. 2559 ::= [] 2560 2561 [] 2562 [] 2564 ::= [] 2565 2566 [] 2568 If the INTEGRITY object is present, it must immediately follow the 2569 RSVP common header. L2-specific objects must always precede the 2570 SESSION object. 2572 B.5. RSVP RESV Message Format 2574 As specified in the RSVP specification, an RSVP_RESV message con- 2575 tains the RSVP Common Header and relevant RSVP objects. In addi- 2576 tion, it may contain an optional TCLASS object as described ear- 2577 lier. 2579 B.6. Additional RSVP message types to handle SBM interactions 2581 New RSVP message types are introduced to allow interactions between 2582 a DSBM and an RSVP node (host/router) for the purpose of discover- 2583 ing and binding to a DSBM. New RSVP message types needed are as 2584 follows: 2586 RSVP Msg Type (8 bits) Value 2587 DSBM_WILLING 66 2588 I_AM_DSBM 67 2590 All SBM-specific messages are formatted as RSVP messages with an 2591 RSVP common header followed by SBM-specific objects. 2593 ::= 2595 where ::= [] 2597 For each SBM message type, there is a set of rules for the permis- 2598 sible choice of object types. These rules are specified using 2600 SBM (Subnet Bandwidth Manager) March, 1999 2602 Backus-Naur Form (BNF) augmented with square brackets surrounding 2603 optional sub-sequences. The BNF implies an order for the objects in 2604 a message. However, in many (but not all) cases, object order makes 2605 no logical difference. An implementation should create messages 2606 with the objects in the order shown here, but accept the objects in 2607 any permissible order. Any exceptions to this rule will be pointed 2608 out in the specific message formats. 2610 DSBM_WILLING Message 2612 ::= 2613 2615 I_AM_DSBM Message 2617 ::= 2618 2619 [] 2621 For compatibility reasons, receivers of the I_AM_DSBM message must 2622 be prepared to receive additional objects of the Unknown Class type 2623 [RFC-2205]. 2625 All I_AM_DSBM messages are multicast to the well known AllSBMAd- 2626 dress. The default priority of a SBM is 1 and higher priority 2627 values represent higher precedence. The priority value zero indi- 2628 cates that the SBM is not eligible to be the DSBM. 2630 Relevant Objects 2632 DSBM IP ADDRESS objects use object class = 42; IPv4 DSBM IP ADDRESS 2633 object uses and IPv6 DSBM IP ADDRESS object 2634 uses . 2636 IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1 2637 0 1 2 3 2638 +---------------+---------------+---------------+---------------+ 2639 | IPv4 DSBM IP Address | 2640 +---------------+---------------+---------------+---------------+ 2642 IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 2 2644 SBM (Subnet Bandwidth Manager) March, 1999 2646 +---------------+---------------+---------------+---------------+ 2647 | | 2648 + + 2649 | | 2650 + IPv6 DSBM IP Address + 2651 | | 2652 + + 2653 | | 2654 +---------------+---------------+---------------+---------------+ 2656 Object is the same as object with C-Type 2657 =1 for IEEE Canonical Address format. 2659 ::= 2661 a SBM may omit this object by including a NULL L2 address object. For 2662 C-Type=1 (IEEE Canonical address format), such a version of the L2 2663 address object contains value zero in the six octet s corresponding to the 2664 MAC address (see section B.3.4 for the exact format). 2666 SBM_PRIORITY Object: class = 43, C-Type =1 2668 0 1 2 3 2669 +---------------+---------------+---------------+---------------+ 2670 | /// | /// | /// | SBM priority | 2671 +---------------+---------------+---------------+---------------+ 2673 TIMER INTERVAL VALUES. 2675 The two timer intervals, namely, DSBM Dead Interval and DSBM 2676 Refresh Interval, are specified as integer values each in the 2677 range of 0..255 seconds. Both values are included in a single 2678 "DSBM Timer Intervals" object described below. 2680 DSBM Timer Intervals Object: class = 44, C-Type =1 2682 +---------------+---------------+---------------+----------------+ 2683 | /// | /// | DeadInterval |Refresh Interval| 2684 +---------------+---------------+---------------+----------------+ 2686 NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 1 2688 0 1 2 3 2689 +---------------+---------------+---------------+----------------+ 2690 | NonResvSendLimit(limit on traffic allowed to send without RESV)| 2691 | | 2692 +---------------+---------------+---------------+----------------+ 2694 SBM (Subnet Bandwidth Manager) March, 1999 2696 ::= (class=12, C-Type =2) 2698 The NON_RESV_SEND_LIMIT object specifies a per-flow limit on the 2699 profile of traffic which a sending host is allowed to send onto a 2700 managed segment without a valid RSVP reservation (see Appendix C 2701 for further details on the usage of this object). The object con- 2702 tains the NonResvSendLimit parameter. This parameter is equivalent 2703 to the Intserv SENDER_TSPEC (see RFC 2210 for contents and encoding 2704 rules). The SENDER_TSPEC includes five parameters which describe a 2705 traffic profile (r, b, p, m and M). Sending hosts compare the 2706 SENDER_TSPEC describing a sender traffic flow to the SENDER_TSPEC 2707 advertised by the DSBM. If the SENDER_TSPEC of the traffic flow in 2708 question is less than or equal to the SENDER_TSPEC advertised by 2709 the DSBM, it is allowable to send traffic on the corresponding flow 2710 without a valid RSVP reservation in place. Otherwise it is not. 2712 The network administrator may configure the DSBM to disallow any 2713 sent traffic in the absence of an RSVP reservation by configuring a 2714 NonResvSendLimit in which r = 0, b = 0, p = 0, m = infinity and M = 2715 0. Similarly the network administrator may allow any traffic to be 2716 sent in the absence of an RSVP reservation by configuring a Non- 2717 ResvSendLimit in which r = infinity, b = infinity, p = infinity, m 2718 = 0 and M = infinity. Of course, any of these parameters may be set 2719 to values between zero and infinity to advertise finite per-flow 2720 limits. 2722 The NON_RESV_SEND_LIMIT object is optional. Senders on a managed 2723 segment should interpret the absence of the NON_RESV_SEND_LIMIT 2724 object as equivalent to an infinitely large SENDER_TSPEC (it is 2725 permissible to send any traffic profile in the absence of an RSVP 2726 reservation). 2728 SBM (Subnet Bandwidth Manager) March, 1999 2730 Appendix C 2731 The DSBM as a Source of Centralized Configuration Information 2733 There are certain configuration parameters which it may be useful 2734 to distribute to layer-3 senders on a managed segment. The DSBM may 2735 serve as a centralized management point from which such parameters 2736 can easily be distributed. In particular, it is possible for the 2737 network administrator configuring a DSBM to cause certain confi- 2738 guration parameters to be distributed as objects appended to the 2739 I_AM_DSBM messages. The following configuration object is defined 2740 at this time. Others may be defined in the future. See Appendix B 2741 for further details regarding the NON_RESV_SEND_LIMIT object. 2743 C.1. NON_RESV_SEND_LIMIT 2745 As we QoS enable layer 2 segments, we expect an evolution from sub- 2746 nets comprised of traditional shared segments (with no means of 2747 traffic separation and no DSBM), to subnets comprised of dedicated 2748 segments switched by sophisticated switches (with both DSBM and 2749 802.1p traffic separation capability). 2751 A set of intermediate configurations consists of a group of QoS 2752 enabled hosts sending onto a traditional shared segment. A layer-3 2753 device (or a layer-2 device) acts as a DSBM for the shared segment, 2754 but cannot enforce traffic separation. In such a configuration, the 2755 DSBM can be configured to limit the number of reservations approved 2756 for senders on the segment, but cannot prevent them from sending. 2757 As a result, senders may congest the segment even though a network 2758 administrator has configured an appropriate limit for admission 2759 control in the DSBM. 2761 One solution to this problem which would give the network adminis- 2762 trator control over the segment, is to require applications (or 2763 operating systems on behalf of applications) not to send until they 2764 have obtained a reservation. This is problematic as most applica- 2765 tions are used to sending as soon as they wish to and expect to get 2766 whatever service quality the network is able to grant at that time. 2767 Furthermore, it may often be acceptable to allow certain applica- 2768 tions to send before a reservation is received. For example, on a 2769 segment comprised of a single 10 Mbps ethernet and 10 hosts, it may 2770 be acceptable to allow a 16 Kbps telephony stream to be transmitted 2771 but not a 3 Mbps video stream. 2773 A more pragmatic solution then, is to allow the network administra- 2774 tor to set a per-flow limit on the amount of non-adaptive traffic 2775 which a sender is allowed to generate on a managed segment in the 2776 absence of a valid reservation. This limit is advertised by the 2777 DSBM and received by sending hosts. An API on the sending host can 2779 SBM (Subnet Bandwidth Manager) March, 1999 2781 then approve or deny an application's QoS request based on the 2782 resources requested. 2784 The NON_RESV_SEND_LIMIT object can be used to advertise a Flowspec 2785 which describes the shape of traffic that a sender is allowed to 2786 generate on a managed segment when its RSVP reservation requests 2787 have either not yet completed or have been rejected. 2789 SBM (Subnet Bandwidth Manager) March, 1999 2791 ACKNOWLEDGEMENTS 2793 Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel), 2794 David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman 2795 (3COM), Andrew Smith (Extreme Networks) for their constructive com- 2796 ments on the SBM design and the earlier versions of this document. 2798 6. Authors` Addresses 2800 Raj Yavatkar 2801 Intel Corporation 2802 2111 N.E. 25th Avenue, 2803 Hillsboro, OR 97124 2804 USA 2805 phone: +1 503-264-9077 2806 email: yavatkar@ibeam.intel.com 2808 Don Hoffman 2809 Teledesic Corporation 2810 2300 Carillon Point 2811 Kirkland, WA 98033 2812 USA 2813 phone: +1 425-602-0000 2815 Yoram Bernet 2816 Microsoft 2817 1 Microsoft Way 2818 Redmond, WA 98052 2819 USA 2820 phone: +1 206 936 9568 2821 email: yoramb@microsoft.com 2823 Fred Baker 2824 Cisco Systems 2825 519 Lado Drive 2826 Santa Barbara, California 93111 2827 USA 2828 phone: +1 408 526 4257 2829 email: fred@cisco.com 2831 Michael Speer 2832 Sun Microsystems, Inc 2833 901 San Antonio Road UMPK15-215 2834 Palo Alto, CA 94303 2835 phone: +1 650-786-6368 2836 email: speer@Eng.Sun.COM 2838 SBM (Subnet Bandwidth Manager) March, 1999