idnits 2.17.1 draft-ietf-issll-is802-sbm-10.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 67 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 430 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 65 instances of lines with control characters in the document. == There are 13 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 685: '... include a TCLASS object, the DSBM MAY...' RFC 2119 keyword, line 1562: '... managed segment MUST be SBM-aware and...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 1434 has weird spacing: '...nd send a RES...' == Line 1794 has weird spacing: '...riority to de...' == Line 1797 has weird spacing: '... tie is broke...' == Line 1841 has weird spacing: '...listens for i...' == Line 1847 has weird spacing: '...sending out a...' == (5 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 (January 2000) is 8868 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC-FRAME' on line 1714 looks like a reference -- Missing reference section? 'RFC-MAP' on line 1718 looks like a reference -- Missing reference section? 'IEEE8021D' on line 1734 looks like a reference -- Missing reference section? 'IEEE8021P' on line 230 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 2621 looks like a reference -- Missing reference section? 'RFC-2211' on line 1698 looks like a reference -- Missing reference section? 'RFC-2212' on line 1701 looks like a reference -- Missing reference section? 'RFC-RSVPMD5' on line 1692 looks like a reference -- Missing reference section? 'RFC-2206' on line 1695 looks like a reference -- Missing reference section? 'RFC-2215' on line 1704 looks like a reference -- Missing reference section? 'RFC-2210' on line 1708 looks like a reference -- Missing reference section? 'RFC-2213' on line 1711 looks like a reference -- Missing reference section? 'IEEEP8021p' on line 1725 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 11 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 Michael Speer, Sun Microsystems 7 January 2000 9 SBM (Subnet Bandwidth Manager): 10 A Protocol for RSVP-based Admission Control over IEEE 802-style networks 11 draft-ietf-issll-is802-sbm-10.txt 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) January, 2000 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 to 39 work both with the current generation of IEEE 802 LANs as well as with 40 the recent work completed by the IEEE 802.1 committee. 42 SBM (Subnet Bandwidth Manager) January, 2000 44 1. Introduction 46 New extensions to the Internet architecture and service models have been 47 defined for an integrated services Internet [RFC-1633, RFC-2205, 48 RFC-2210] so that applications can request specific qualities or levels 49 of service from an internetwork in addition to the current IP 50 best-effort service. These extensions include RSVP, a resource 51 reservation 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 54 technologies and it is necessary to define the mapping of RSVP and 55 Integrated Services specifications onto specific subnetwork 56 technologies. For example, a definition of service mappings and 57 reservation setup protocols is needed for specific link-layer 58 technologies such as shared and switched IEEE-802-style LAN 59 technologies. 61 This document defines SBM, a signaling protocol for RSVP-based admission 62 control over IEEE 802-style networks. SBM provides a method for mapping 63 an internet-level setup protocol such as RSVP onto IEEE 802 style 64 networks. In particular, it describes the operation of RSVP- enabled 65 hosts/routers and link layer devices (switches, bridges) to support 66 reservation of LAN resources for RSVP-enabled data flows. A framework 67 for providing Integrated Services over shared and switched 68 IEEE-802-style LAN technologies and a definition of service mappings 69 have been described in separate documents [RFC-FRAME, RFC-MAP]. 71 2. Goals and Assumptions 73 The SBM (Subnet Bandwidth Manager) protocol and its use for admission 74 control and bandwidth management in IEEE 802 level-2 networks is based 75 on the following architectural goals and assumptions: 77 I. Even though the current trend is towards increased use of 78 switched LAN topologies consisting of newer switches that support 79 the priority queuing mechanisms specified by IEEE 802.1p, we assume 80 that the LAN technologies will continue to be a mix of legacy 81 shared/ switched LAN segments and newer switched segments based on 82 IEEE 802.1p specification. Therefore, we specify a signaling 83 protocol for managing bandwidth over both legacy and newer LAN 84 topologies and that takes advantage of the additional functionality 85 (such as an explicit support for different traffic classes or 86 integrated service classes) as it becomes available in the new 87 generation of switches, hubs, or bridges. As a result, the SBM 88 protocol would allow for a range of LAN bandwidth 90 SBM (Subnet Bandwidth Manager) January, 2000 92 management solutions that vary from one that exercises purely 93 administrative control (over the amount of bandwidth consumed by 94 RSVP-enabled traffic flows) to one that requires cooperation (and 95 enforcement) from all the end-systems or switches in a IEEE 802 96 LAN. 98 II. This document specifies only a signaling method and protocol 99 for LAN-based admission control over RSVP flows. We do not define 100 here any traffic control mechanisms for the link layer; the 101 protocol is designed to use any such mechanisms defined by IEEE 102 802. In addition, we assume that the Layer 3 end-systems (e.g., a 103 host or a router) will exercise traffic control by policing 104 Integrated Services traffic flows to ensure that each flow stays 105 within its traffic specifications stipulated in an earlier 106 reservation request submitted for admission control. This then 107 allows a system using SBM admission control combined with per flow 108 shaping at end systems and IEEE-defined traffic control at link 109 layer to realize some approximation of Controlled Load (and even 110 Guaranteed) services over IEEE 802-style LANs. 112 III. In the absence of any link-layer traffic control or priority 113 queuing mechanisms in the underlying LAN (such as a shared LAN 114 segment), the SBM-based admission control mechanism only limits the 115 total amount of traffic load imposed by RSVP-enabled flows on a 116 shared LAN. In such an environment, no traffic flow separation 117 mechanism exists to protect the RSVP-enabled flows from the 118 best-effort traffic on the same shared media and that raises the 119 question of the utility of such a mechanism outside a topology 120 consisting only of 802.1p-compliant switches. However, we assume 121 that the SBM-based admission control mechanism will still serve a 122 useful purpose in a legacy, shared LAN topology for two reasons. 123 First, assuming that all the nodes that generate Integrated 124 Services traffic flows utilize the SBM-based admission control 125 procedure to request reservation of resources before sending any 126 traffic, the mechanism will restrict the total amount of traffic 127 generated by Integrated Services flows within the bounds desired by 128 a LAN administrator (see discussion of the NonResvSendLimit 129 parameter in Appendix C). Second, the best-effort traffic 130 generated by the TCP/IP-based traffic sources is generally rate 131 adaptive (using a TCP-style "slow start" congestion avoidance 132 mechanism or a feedback-based rate adaptation mechanism used by 133 audio/video streams based on RTP/RTCP protocols) and adapts to stay 134 within the available network bandwidth. Thus, the combination of 135 admission control and rate adaptation should avoid persistent 136 traffic congestion. This does not, however, guarantee that 137 non-Integrated-Services traffic will not interfere with the 139 SBM (Subnet Bandwidth Manager) January, 2000 141 Integrated Services traffic in the absence of traffic control 142 support in the underlying LAN infrastructure. 144 3. Organization of the rest of this document 146 The rest of this document provides a detailed description of the 147 SBM-based admission control procedure(s) for IEEE 802 LAN technologies. 148 The document is organized as follows: 150 * Section 4 first defines the various terms used in the document 151 and then provides an overview of the admission control procedure 152 with an example of its application to a sample network. 154 * Section 5 describes the rules for processing and forwarding PATH 155 (and PATH_TEAR) messages at DSBMs (Designated Subnet Bandwidth 156 Managers), SBMs, and DSBM clients. 158 * Section 6 addresses the inter-operability issues when a DSBM may 159 operate in the absence of RSVP signaling at Layer 3 or when 160 another signaling protocol (such as SNMP) is used to reserve 161 resources on a LAN segment. 163 * Appendix A describes the details of the DSBM election algorithm 164 used for electing a designated SBM on a LAN segment when more than 165 one SBM is present. It also describes how DSBM clients discover 166 the presence of a DSBM on a managed segment. 168 * Appendix B specifies the formats of SBM-specific messages used 169 and the formats of new RSVP objects needed for the SBM operation. 171 * Appendix C describes usage of the DSBM to distribute configuration 172 information to senders on a managed segment. 174 4. Overview 176 4.1. Definitions 178 SBM (Subnet Bandwidth Manager) January, 2000 180 - Link Layer or Layer 2 or L2: We refer to data-link layer 181 technologies such as IEEE 802.3/Ethernet as L2 or layer 2. 183 - Link Layer Domain or Layer 2 domain or L2 domain: a set of nodes 184 and links interconnected without passing through a L3 forwarding 185 function. One or more IP subnets can be overlaid on a L2 domain. 187 - Layer 2 or L2 devices: We refer to devices that only implement 188 Layer 2 functionality as Layer 2 or L2 devices. These include 189 802.1D bridges or switches. 191 - Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO 7 layer 192 model. This document is primarily concerned with networks that 193 use the Internet Protocol (IP) at this layer. 195 - Layer 3 Device or L3 Device or End-Station: these include hosts 196 and routers that use L3 and higher layer protocols or application 197 programs that need to make resource reservations. 199 - Segment: A L2 physical segment that is shared by one or more 200 senders. Examples of segments include (a) a shared Ethernet or 201 Token-Ring wire resolving contention for media access using CSMA 202 or token passing ("shared L2 segment"), (b) a half duplex link 203 between two stations or switches, (c) one direction of a switched 204 full-duplex link. 206 - Managed segment: A managed segment is a segment with a DSBM 207 present and responsible for exercising admission control over 208 requests for resource reservation. A managed segment includes 209 those interconnected parts of a shared LAN that are not separated 210 by DSBMs. 212 - Traffic Class: An aggregation of data flows which are given 213 similar service within a switched network. 215 - User_priority: User_priority is a value associated with the 216 transmission and reception of all frames in the IEEE 802 service 217 model: it is supplied by the sender that is using the MAC 218 service. It is provided along with the data to a receiver using the 219 MAC service. It may or may not be actually carried over the 221 SBM (Subnet Bandwidth Manager) January, 2000 223 network: Token-Ring/802.5 carries this value (encoded in its FC 224 octet), basic Ethernet/802.3 does not, 802.12 may or may not 225 depending on the frame format in use. 802.1p defines a consistent 226 way to carry this value over the bridged network on Ethernet, 227 Token Ring, Demand-Priority, FDDI or other MAC-layer media using 228 an extended frame format. The usage of user_priority is fully 229 described in section 2.5 of 802.1D [IEEE8021D] and 802.1p 230 [IEEE8021P] "Support of the Internal Layer Service by Specific 231 MAC Procedures". 233 - Subnet: used in this memo to indicate a group of L3 devices 234 sharing a common L3 network address prefix along with the set 235 of segments making up the L2 domain in which they are located. 237 - Bridge/Switch: a layer 2 forwarding device as defined by IEEE 238 802.1D. The terms bridge and switch are used synonymously in this 239 document. 241 - DSBM: Designated SBM (DSBM) is a protocol entity that resides in 242 a L2 or L3 device and manages resources on a L2 segment. At most 243 one DSBM exists for each L2 segment. 245 - SBM: the SBM is a protocol entity that resides in a L2 or L3 device 246 and is capable of managing resources on a segment. However, 247 only a DSBM manages the resources for a managed segment. When 248 more than one SBM exists on a segment, one of the SBMs is elected 249 to be the DSBM. 251 - Extended segment: An extended segment includes those parts of a 252 network which are members of the same IP subnet and therefore are 253 not separated by any layer 3 devices. Several managed segments, 254 interconnected by layer 2 devices, constitute an extended segment. 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) January, 2000 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 control 274 procedure over a managed segment. Such a device uses standard 275 forwarding rules appropriate for the device and is transparent 276 with respect to SBM. An example of such a L2 device is a 277 legacy switch that does not participate in resource reservation. 279 - Layer 3 and layer 2 addresses: We refer to layer 3 addresses of 280 L3/L2 devices as "L3 addresses" and layer 2 addresses as "L2 281 addresses". This convention will be used in the rest of the document 282 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 segment. 297 For example, many SBM-capable devices may be attached to a 298 shared L2 segment whereas two SBM-capable switches may share a 299 half-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". Sometimes, 306 two or more L2 segments may be interconnected by SBM transparent 307 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) January, 2000 312 single managed segment for the purpose of admission control. 314 SBM (Subnet Bandwidth Manager) January, 2000 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 336 discussion, 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) January, 2000 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 384 destination address. As part of its processing, the DSBM builds 385 and maintains a PATH state for the session and notes the 386 previous 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 399 Section 5). In the process, the DSBM builds the PATH state, 400 remembers the router R1 (its L2 and l3 addresses) as the previous 401 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 405 segment. 407 b) When an application on host A wishes to make a reservation for 409 SBM (Subnet Bandwidth Manager) January, 2000 411 the RSVP session, host A follows the standard RSVP message 412 processing rules and sends a RSVP RESV message to the previous hop 413 L2/L3 address (the DSBMs address) obtained from the PHOP 414 object(s) in the previously received PATH message. 416 c) The DSBM processes the RSVP RESV message based on the bandwidth 417 available and returns an RESV_ERR message to the requester (host 418 A) if the request cannot be granted. If sufficient resources 419 are available and the reservation request is granted, the DSBM 420 forwards the RESV message towards the PHOP(s) based on its 421 local PATH state for the session. The DSBM merges reservation 422 requests for the same session as and when possible using the 423 rules similar to those used in the conventional RSVP processing 424 (except for an additional criterion described in Section 5.9). 426 d) If the L2 domain contains more than one managed segment, the 427 requester (host A) and the forwarder (router R1) may be 428 separated by more than one managed segment. In that case, the 429 original PATH message would propagate through many DSBMs (one 430 for each managed segment on the path from R1 to A) setting up 431 PATH state at each DSBM. Therefore, the RESV message would 432 propagate 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) January, 2000 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 462 destination 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 forwards 477 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 481 additional 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 destination, 493 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 acting 497 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) January, 2000 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 destination 517 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 521 Appendix 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 modified 531 to reflect its own IP address (RSVP_HOP_L3 address). Thus, 532 the DSBM inserts itself as an intermediate hop in the chain of 533 nodes in the path between two L3 nodes across the L2 domain. 535 - The PATH state in a DSBM is used for forwarding subsequent RESV 536 messages as per the standard RSVP message processing rules. When 537 the DSBM receives a RESV message, it processes the message and 538 forwards it to appropriate PHOP(s) based on its PATH state. 540 - Because a DSBM inserts itself as a hop between two RSVP nodes in 541 the path of a RSVP flow, all RSVP related messages (such as PATH, 542 PATH_TEAR, RESV, RESV_CONF, RESV_TEAR, and RESV_ERR) now flow 543 through the DSBM. In particular, a PATH_TEAR message is routed 544 exactly through the intermediate DSBM(s) as its corresponding 545 PATH message and the local PATH state is first cleaned up at each 546 intermediate hop before the PATH_TEAR message gets forwarded. 548 - So far, we have described how the PATH message propagates through 549 the L2 domain establishing PATH state at each DSBM along the 550 managed segments in the path. The layer 2 address (LAN_NHOP_L2 551 address) in the LAN_NHOP object should be used by the L2 devices 552 along the path to decide how to forward the PATH message toward 553 the next L3 hop. Such devices will apply the standard IEEE 555 SBM (Subnet Bandwidth Manager) January, 2000 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 567 established 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 571 message) 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 complements 587 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) January, 2000 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 facilitate 612 detection of such loops, we use a new RSVP object called the 613 LAN_LOOPBACK object. DSBM clients or SBMs (but not the DSBMs reflecting 614 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 duplicates 620 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 different 636 traffic classes (see [IEEE802Q, IEEE8021p] for further 637 details). The user_priority values can be encoded either in native LAN 638 packets (e.g., in IEEE 802.5's FC octet) or by using an encapsulation 639 above the MAC layer (e.g., in the case of Ethernet, the user_priority 640 value assigned to each packet will be carried in the frame header 641 using the new, extended frame format defined by IEEE 802.1Q 642 [IEEE8021Q]. IEEE, however, makes no recommendations about how a 643 sender or network should use the user_priority values. An accompanying 644 document makes recommendations on the usage of the user_priority 645 values (see [RFC-MAP] for details). 647 Under the Integrated Services model, L3 (or higher) entities that 648 transmit traffic flows onto a L2 segment should perform per-flow policing 649 to ensure that the flows do not exceed their traffic specification 650 as specified during admission control. In addition, L3 devices 651 may label the frames in such flows with a user_priority value to 652 identify 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) January, 2000 659 packet. Under the ISSLL model, the L3 entities, that send traffic and 660 that use the SBM protocol, may select the appropriate traffic class of 661 outgoing packets [RFC-MAP]. This selection may be overridden by DSBM 662 devices, in the following manner. once a sender sends a PATH message, 663 downstream DSBMs will insert a new traffic class object (TCLASS 664 object) in the PATH message that travels to the next L3 device (L3 665 NHOP for the PATH message). To some extent, the TCLASS object contents 666 are treated like the ADSPEC object in the RSVP PATH messages. The L3 667 device that receives the PATH message must remove and store the TCLASS 668 object as part of its PATH state for the session. Later, when the same 669 L3 device needs to forward a RSVP RESV message towards the original 670 sender, it must include the TCLASS object in the RESV message. When 671 the RESV message arrives at the original sender, the sender must use 672 the user_priority value from the TCLASS object to override its 673 selection for the traffic class marked in outgoing packets. 675 The format of the TCLASS object is specified in Appendix B. Note that 676 TCLASS and other SBM-specific objects are carried in a RSVP message in 677 addition to all the other, normal RSVP objects per RFC 2205. 679 4.2.2.8 Processing the TCLASS Object 681 In summary, use of TCLASS objects requires following additions to the 682 conventional RSVP message processing at DSBMs, SBMs, and DSBM clients: 684 * When a DSBM receives a PATH message over a managed segment and 685 the PATH message does not include a TCLASS object, the DSBM MAY 686 add a TCLASS object to the PATH message before forwarding it. 687 The DSBM determines the appropriate user_priority value for the 688 TCLASS object. A mechanism for selecting the appropriate 689 user_priority value is described in an accompanying document 690 [RFC-MAP]. 692 * When SBM or DSBM receives a PATH message with a TCLASS object 693 over a managed segment in a L2 domain and needs to forward it 694 over a managed segment in the same L2 domain, it will store it 695 in its path state and typically forward the message without 696 changing the contents of the TCLASS object. However, if the 697 DSBM/SBM cannot support the service class represented by the 698 user_priority value specified by the TCLASS object in the PATH 699 message, it may change the priority value in the TCLASS to a 700 semantically "lower" service value to reflect its capability 701 and store the changed TCLASS value in its path state. 703 [NOTE: An accompanying document defines the int-serv mappings 705 SBM (Subnet Bandwidth Manager) January, 2000 707 over IEEE 802 networks [RFC-MAP] provides a precise definition 708 of user_priority values and describes how the user_priority 709 values are compared to determine "lower" of the two values or 710 the "lowest" among all the user_priority values.] 712 * When a DSBM receives a RESV message with a TCLASS object, it 713 may use the traffic class information (in addition to the usual 714 flowspec information in the RSVP message) for its own admission 715 control for the managed segment. 717 Note that this document does not specify the actual algorithm 718 or policy used for admission control. At one extreme, a DSBM 719 may use per-flow reservation request as specified by the 720 flowspec for a fine grain admission control. At the other 721 extreme, a DSBM may only consider the traffic class information 722 for a very coarse-grain admission control based on some static 723 allocation of link capacity for each traffic class. Any 724 combination of the options represented by these two extremes 725 may 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 729 message 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 734 forward 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) January, 2000 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 outgoing 763 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 interfaces 774 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). 781 Non-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) January, 2000 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 unicast 797 or multicast address). When a L2 device hosts a DSBM, a 798 simple-to-implement mechanism must be provided for the device to 799 capture an incoming PATH message and hand it over to the local DSBM 800 agent without 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 existing 805 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 purpose 811 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 multicast 818 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 segment 822 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 appropriate 825 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) January, 2000 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 845 packets. 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) January, 2000 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 898 Appendix 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 905 message 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) January, 2000 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) January, 2000 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 devices 969 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. 973 Exceptions 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 routing 987 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 992 forwarding 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 997 interface is on a managed segment managed by a DSBM, based on 998 the presence or absence of I_AM_DSBM messages. If the interface 999 is 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) January, 2000 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 earlier 1026 to obtain an L2 address corresponding to an IP address. 1028 * If the device hosts the DSBM for the segment to which the 1029 forwarding 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 devices 1039 must also have IP addresses) into the standard RSVP HOP 1040 object and the L2 address of the forwarding interface into 1041 the RSVP_HOP_L2 object. 1043 - If the PATH message received does not contain the TCLASS 1044 object, insert a TCLASS object. The user_priority value 1045 inserted in the TCLASS object is based on service mappings 1046 internal to the device that are configured according to the 1047 guidelines listed in [RFC-MAP]. If the message already 1049 SBM (Subnet Bandwidth Manager) January, 2000 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 segment 1056 to which the forwarding interface is attached, it *is required* 1057 to retrieve and store the PHOP info. 1059 If the device is a layer 2 device and hosts a SBM for the segment 1060 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 forwarding 1068 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) January, 2000 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 1101 forwarded 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 1114 (specified by the addresses in the LAN_NHOP object), on the 1115 segment 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 1118 message 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 entities 1130 (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 1133 message, leave the LAN_LOOPBACK object unchanged. Thus, SBM 1134 protocol entities will always be able to recognize a reflected 1135 multicast message by the presence of their own address in the 1136 LAN_LOOPBACK object. These messages should be silently 1137 discarded. 1139 SBM (Subnet Bandwidth Manager) January, 2000 1141 5.7. Applying the Rules -- Unicast Session 1143 Let's see how the rules are applied in the general network 1144 illustrated 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) January, 2000 1191 Source address IP address of H1 1192 Destn address DSBMLogical IP address (224.0.0.16) 1194 MAC Header 1195 Destn address DSBMLogical MAC address 1197 * R1 does a routing lookup on the RSVP session address, to 1198 determine the IP address of the next layer 3 hop, R2. 1200 * It determines that R2 is accessible via seg A and that seg A 1201 is managed by a DSBM, S1. 1203 * Therefore, it concludes that it is sending onto a managed 1204 segment, and composes LAN_NHOP objects to carry the layer 3 1205 and layer 2 next hop addresses. To compose the LAN_NHOP 1206 L2ADDR object, it invokes the L3 to L2 address mapping function 1207 ("map_address") to find out the MAC address for the next hop 1208 L3 device, and then inserts a LAN_NHOP_L2ADDR object (that 1209 carries the MAC address) in the message. 1211 * Since R1 is not the DSBM for seg A, it sends the PATH message 1212 to the DSBMLogicalAddress. 1214 Upon receipt of the PATH message, S1 composes and forwards a PATH 1215 message as follows: 1217 RSVP Contents 1218 RSVP session IP address IP address of H5 1219 Sender Template IP address of H1 1220 PHOP IP addr of S1 (seed the return path for RESV 1221 messages) 1222 RSVP_HOP_L2 L2 address of S1 1223 LAN_NHOP LAN_NHOP_L3 (IP) and LAN_NHOP_L2 1224 address of R2 1225 (layer 2 devices do not modify the LAN_NHOP) 1226 LAN_LOOPBACK IP addr of S1 1228 IP Header 1229 Source address IP address of H1 1230 Destn address AllSBMIPaddr (224.0.0.17, since S1 is the 1232 SBM (Subnet Bandwidth Manager) January, 2000 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) January, 2000 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) January, 2000 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 individually. 1331 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 1340 unicast 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 1348 messages. 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) January, 2000 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) January, 2000 1413 When a DSBM client receives TCLASS objects from different senders 1414 (different PATH messages) in the same RSVP session and needs to 1415 combine them for sending back a single RESV message (as in a 1416 wild-card style reservation), the DSBM client must choose an 1417 appropriate value that corresponds to the desired-delay traffic 1418 class. An accompanying document discusses the guidelines for 1419 traffic class selection based on desired service and the TSpec 1420 information [RFC-MAP]. 1422 In addition, when a SBM or DSBM needs to merge RESVs from different 1423 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. 1425 Consider 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 message 1433 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 incompatible 1438 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 1441 condition. 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 protocol. 1447 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 1451 participate in routing of PATH or RESV messages, and they do not 1452 participate in admission control. They are entirely transparent with 1453 respect to SBM operation. 1455 According to the definitions provided, physical segments interconnected 1456 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 topology. 1459 In this case, the network administrator should configure the 1461 SBM (Subnet Bandwidth Manager) January, 2000 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 administrator 1468 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 segment 1483 (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) January, 2000 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 signaling 1528 for requesting resource reservations, but, instead, use some 1529 other (e.g., SNMP or static configuration) mechanism to reserve 1530 bandwidth at a particular network device such as a router. In that 1531 case, the question is how does a DSBM-based admission control 1532 method work and interoperate with the non-RSVP mechanism. The 1533 SBM-based method does not attempt to provide an admission control 1534 solution for such an environment. The SBM-based approach is part 1535 of an end to end signaling approach to establish resource reservations 1536 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 1552 physical 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) January, 2000 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 protocol. 1563 Use of the standard, non-SBM version of RSVP may result in 1564 over-allocation of resources, as such use bypasses the resource 1565 management function of the DSBM. All other senders (i.e., senders 1566 that are not sending streams subject to RSVP admission control) 1567 should be elastic applications that send traffic of lower priority 1568 than the RSVP traffic, and use TCP-like congestion avoidance 1569 mechanisms. 1571 All DSBMs, SBMs, or DSBM clients on a managed segment (a segment 1572 with a currently active DSBM) must not accept PATH messages from 1573 senders that are not SBM-aware. PATH messages from such devices 1574 can be easily detected by SBMs and DSBM clients as they would not 1575 be multicast to the ALLSBMAddress (in case of SBMs and DSBM 1576 clients) or the DSBMLogicalAddress (in case of DSBMs). 1578 6.4. A non-SBM router that interconnects two DSBM-managed L2 1579 domains. 1581 Multicast SBM messages (e.g., election and PATH messages) have 1582 local scope and are not intended to pass between the two domains. 1583 A correctly configured non-SBM router will not pass such messages 1584 between the domains. A broken router implementation that does so 1585 may cause incorrect operation of the SBM protocol and consequent 1586 over- or under-allocation of resources. 1588 6.5. Interoperability with RSVP clients that use UDP encapsulation 1589 and are not capable of receiving/sending RSVP messages using 1590 RAW_IP 1592 This document stipulates that DSBMs, DSBM clients, and SBMs use 1593 only raw IP for encapsulating RSVP messages that are forwarded 1594 onto a L2 domain. RFC-2205 (the RSVP Proposed Standard) includes 1595 support for both raw IP and UDP encapsulation. Thus, a RSVP node 1596 using only the UDP encapsulation will not be able to interoperate 1597 with the DSBM unless DSBM accepts and supports UDP encapsulated 1598 RSVP messages. 1600 7. Guidelines for Implementers 1602 SBM (Subnet Bandwidth Manager) January, 2000 1604 In the following, we provide guidelines for implementers on different 1605 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 1616 interconnected by a single shared segment, DSBM entities on such 1617 devices should assume the bandwidth of the interface as the total 1618 link bandwidth. In the case of a DSBM located in a L2 switch, it 1619 might additionally need to be configured with an estimate of the 1620 device's switching capacity if that is less than the link 1621 bandwidth, and possibly with some estimate of the buffering 1622 resources of the switch (see [RFC-FRAME] for the architectural 1623 model assumed for L2 switches). Given the total link bandwidth, 1624 the DSBM may be further configured to limit the maximum amount of 1625 bandwidth for RSVP-enabled flows to ensure spare capacity for 1626 best-effort traffic. 1628 7.2. Operation of DSBMs in Different L2 Topologies 1630 Depending on a L2 topology, a DSBM may be called upon to manage 1631 resources for one or more segments and the implementers must bear 1632 in mind efficiency implications of the use of DSBM in different L2 1633 topologies. Trivial L2 topologies consist of a single "physical 1634 segment". In this case, the 'managed segment' is equivalent to a 1635 single segment. Complex L2 topologies may consist of a number of 1636 'physical segments', separated by SBM-transparent L2 switches. 1637 Admission control on such an L2 extended segment can be performed 1638 from a single pool of resources, similar to a single shared segment, 1639 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 allocation 1648 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) January, 2000 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 configuration, 1657 each physical segment is a managed segment and is managed by 1658 its own DSBM. We make no assumption about the number of managed 1659 segments but state, simply, that in complex L2 topologies, the 1660 efficiency of resource allocation improves as the granularity of 1661 managed segments increases. 1663 8. Security Considerations 1665 The message formatting and usage rules described in this note 1666 raise security issues, identical to those raised by the use of 1667 RSVP and Integrated Services. It is necessary to control and 1668 authenticate access to enhanced qualities of service enabled by 1669 the technology described in this RFC. This requirement is discussed 1670 further in [RFC-2205], [RFC-2211], and [RFC-2212]. 1672 [RFC-RSVPMD5] describes the mechanism used to protect the integrity of 1673 RSVP messages carrying the information described here. A SBM 1674 implementation should satisfy the requirements of that RFC and provide 1675 the suggested mechanisms just as though it were a conventional RSVP 1676 implementation. It should further use the same mechanisms to 1677 protect the additional, SBM-specific objects in a message. 1679 Finally, it is also necessary to authenticate DSBM candidates 1680 during the election process, and a mechanism based on a shared 1681 secret among the DSBM candidates may be used. The mechanism 1682 defined in [RFC-RSVPMD5] should be used. 1684 SBM (Subnet Bandwidth Manager) January, 2000 1686 9. References 1688 [RFC-2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 1689 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1690 Specification ", RFC-2205, September 1997. 1692 [RFC-RSVPMD5] F. Baker., "RSVP Cryptographic Authentication", 1693 draft-ietf-rsvp-md5-05.txt, August 1997. [XXX- is this a RFC yet??] 1695 [RFC-2206] F. Baker, J. Krawczyk, "RSVP Management Information 1696 Base", RFC 2206, September 1997. 1698 [RFC-2211] J. Wroclawski, "Specification of the Controlled-Load 1699 Network Element Service", RFC-2211, September 1997. 1701 [RFC-2212] S. Shenker, C. Partridge, R. Guerin, "Specification of 1702 Guaranteed Quality of Service", RFC-2212, September 1997. 1704 [RFC-2215] S. Shenker, J. Wroclawski, "General Characterization 1705 Parameters for Integrated Service Network Elements", RFC-2215, 1706 September 1997. 1708 [RFC-2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 1709 Services", RFC 2210, September 1997. 1711 [RFC-2213] F. Baker, J. Krawczyk, "Integrated Services Management 1712 Information Base", RFC 2213, September 1997. 1714 [RFC-FRAME] A. Ghanwani, W. Pace, V. Srinivasan, A.Smith, 1715 M.Seaman "A Framework for Providing Integrated Services Over 1716 Shared and Switched LAN Technologies", RFC-XXX, June, 1999. 1718 [RFC-MAP] M. Seaman, A. Smith, E. Crawley, "Integrated Service 1719 Mappings on IEEE 802 Networks", RFC-XXX, June 1999. 1721 [IEEE802Q] "IEEE Standards for Local and Metropolitan Area 1722 Networks: 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) January, 2000 1734 [IEEE8021D] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993. 1736 SBM (Subnet Bandwidth Manager) January, 2000 1738 Appendix A 1739 DSBM Election Algorithm 1741 A.1. Introduction 1743 To simplify the rest of this discussion, we will assume that there 1744 is a single DSBM for the entire L2 domain (i.e., assume a shared 1745 L2 segment for the entire L2 domain). Later, we will discuss how a 1746 DSBM is elected for a half-duplex or full-duplex switched segment. 1748 To allow for quick recovery from the failure of a DSBM, we assume 1749 that additional SBMs may be active in a L2 domain for fault tolerance. 1750 When more than one SBM is active in a L2 domain, the SBMs 1751 use an election algorithm to elect a DSBM for the L2 domain. After 1752 the DSBM is elected and is operational, other SBMs remain passive 1753 in the background to step in to elect a new DSBM when necessary. 1754 The protocol for electing and discovering DSBM is called the "DSBM 1755 election protocol" and is described in the rest of this Appendix. 1757 A.1.1. How a DSBM Client Detects a Managed Segment 1759 Once elected, a DSBM periodically multicasts an I_AM_DSBM message 1760 on the AllSBMAddress to indicate its presence. The message is sent 1761 every period (e.g., every 5 seconds) according to the 1762 RefreshInterval timer value (a configuration parameter). 1763 Absence of such a message over a certain time interval (called 1764 "DSBMDeadInterval"; another configuration parameter typically set 1765 to a multiple of RefreshInterval) indicates that the DSBM has 1766 failed or terminated and triggers another round of the DSBM 1767 election. The DSBM clients always listen for periodic DSBM 1768 advertisements. The advertisement includes the unicast IP address of 1769 the DSBM (DSBMAddress) and DSBM clients send their PATH/RESV (or 1770 other) messages to the DSBM. When a DSBM client detects the 1771 failure of a DSBM, it waits for a subsequent I_AM_DSBM advertisement 1772 before resuming any communication with the DSBM. During the 1773 period when a DSBM is not present, a DSBM client may forward 1774 outgoing PATH messages using the standard RSVP forwarding rules. 1776 The exact message formats and addresses used for communication 1777 with (and among) SBM(s) are described in Appendix B. 1779 A.2. Overview of the DSBM Election Procedure 1781 SBM (Subnet Bandwidth Manager) January, 2000 1783 When a SBM first starts up, it listens for incoming DSBM 1784 advertisements for some period to check whether a DSBM already exists 1785 in its L2 domain. If one already exists (and no new election is in 1786 progress), the new SBM stays quiet in the background until an 1787 election of DSBM is necessary. All messages related to the DSBM 1788 election and DSBM advertisements are always sent to the 1789 AllSBMAddress. 1791 If no DSBM exists, the SBM initiates the election of a DSBM by 1792 sending out a DSBM_WILLING message that lists its IP address as a 1793 candidate DSBM and its "SBM priority". Each SBM is assigned a 1794 priority to determine its relative precedence. When more than one 1795 SBM candidate exists, the SBM priority determines who gets to be 1796 the DSBM based on the relative priority of candidates. If there is 1797 a tie based on the priority value, the tie is broken using the IP 1798 addresses of tied candidates (one with the higher IP address in 1799 the lexicographic order wins). The details of the election 1800 protocol start in Section A.4. 1802 A.2.1 Summary of the Election Algorithm 1804 For the purpose of the algorithm, a SBM is in one of the four 1805 states (Idle, DetectDSBM, ElectDSBM, IAMDSBM). 1807 A SBM (call it X) starts up in the DetectDSBM state and waits for 1808 a ListenInterval for incoming I_AM_DSBM (DSBM advertisement) or 1809 DSBM_WILLING messages. If an I_AM_DSBM advertisement is received 1810 during this state, the SBM notes the current DSBM (its IP address 1811 and priority) and enters the Idle state. If a DSBM_WILLING message 1812 is received from another SBM (call it Y) during this state, then X 1813 enters the ElectDSBM state. Before entering the new state, X first 1814 checks to see whether it itself is a better candidate than Y and, 1815 if so, sends out a DSBM_WILLING message and then enters the 1816 ElectDSBM state. 1818 When a SBM (call it X) enters the ElectDSBM state, it sets a timer 1819 (called ElectionIntervalTimer, and typically set to a value at 1820 least equal to the DSBMDeadInterval value) to wait for the election 1821 to finish and to discover who is the best candidate. In this 1822 state, X keeps track of the best (or better) candidate seen so far 1823 (including itself). Whenever it receives another DSBM_WILLING 1824 message it updates its notion of the best (or better) candidate 1825 based on the priority (and tie-breaking) criterion. During the 1826 ElectionInterval, X sends out a DSBM_WILLING message every 1827 RefreshInterval to (re)assert its candidacy. 1829 SBM (Subnet Bandwidth Manager) January, 2000 1831 At the end of the ElectionInterval, X checks whether it is the 1832 best candidate so far. If so, it declares itself to be the DSBM 1833 (by sending out the I_AM_DSBM advertisement) and enters the 1834 IAMDSBM state; otherwise, it decides to wait for the best candidate 1835 to declare itself the winner. To wait, X re-initializes its 1836 ElectDSBM state and continues to wait for another round of election 1837 (each round lasts for an ElectionTimerInterval duration). 1839 A SBM is in Idle state when no election is in progress and the 1840 DSBM is already elected (and happens to be someone else). In this 1841 state, it listens for incoming I_AM_DSBM advertisements and uses 1842 a DSBMDeadIntervalTimer to detect the failure of DSBM. Every time 1843 the advertisement is received, the timer is restarted. If the 1844 timer fires, the SBM goes into the DetectDSBM state to prepare to 1845 elect the new DSBM. If a SBM receives a DSBM_WILLING message from 1846 the current DSBM in this state, the SBM enters the ElectDSBM state 1847 after sending out a DSBM_WILLING message (to announce its own 1848 candidacy). 1850 In the IAMDSBM state, the DSBM sends out I_AM_DSBM advertisements 1851 every refresh interval. If the DSBM wishes to shut down 1852 (gracefully terminate), it sends out a DSBM_WILLING message (with 1853 SBM priority value set to zero) to initiate the election 1854 procedure. The priority value zero effectively removes the outgoing 1855 DSBM from the election procedure and makes way for the election of 1856 a different DSBM. 1858 A.3. Recovering from DSBM Failure 1860 When a DSBM fails (DSBMDeadIntervalTimer fires), all the SBMs 1861 enter the ElectDSBM state and start the election process. 1863 At the end of the ElectionInterval, the elected DSBM sends out an 1864 I_AM_DSBM advertisement and the DSBM is then operational. 1866 A.4. DSBM Advertisements 1868 The I_AM_DSBM advertisement contains the following information: 1870 1. DSBM address information -- contains the IP and L2 addresses 1871 of the DSBM and its SBM priority (a configuration parameter 1873 SBM (Subnet Bandwidth Manager) January, 2000 1875 -- priority specified by a network administrator). The priority 1876 value is used to choose among candidate SBMs during the 1877 election algorithm. Higher integer values indicate higher 1878 priority and the value is in the range 0..255. The value zero 1879 indicates that the SBM is not eligible to be the DSBM. The 1880 IP address is required and used for breaking ties. The L2 1881 address is for the interface of the managed segment. 1883 2. RegreshInterval -- contains the value of RefreshInterval 1884 in seconds. Value zero indicates the parameter has been 1885 omitted in the message. Receivers may substitute their own 1886 default value in this case. 1888 3. DSBMDeadInterval -- contains the value of DSBMDeadInterval 1889 in seconds. If the value is omitted (or value zero is specified), 1890 a default value (from initial configuration) should be 1891 used. 1893 4. Miscellaneous configuration information to be advertised to 1894 senders on the managed segment. See Appendix C for further 1895 details. 1897 A.5. DSBM_WILLING Messages 1899 When a SBM wishes to declare its candidacy to be the DSBM during 1900 an election phase, it sends out a DSBM_WILLING message. The 1901 DSBM_WILLING message contains the following information: 1903 1. DSBM address information -- Contains the SBM's own addresses 1904 (IP and L2 address), if it wishes to be the DSBM. The IP 1905 address is required and used for breaking ties. The L2 1906 address is the address of the interface for the managed 1907 segment in question. Also, the DSBM address information 1908 includes the corresponding priority of the SBM whose address 1909 is given above. 1911 SBM (Subnet Bandwidth Manager) January, 2000 1913 A.6. SBM State Variables 1915 For each network interface, a SBM maintains the following state 1916 variables related to the election of the DSBM for the L2 domain on 1917 that interface: 1919 a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, 1920 0.0.0.0) and priority. All IP addresses are assumed to be in 1921 network byte order. In addition, current DSBM's L2 address is 1922 also stored as part of this state information. 1924 b) OwnAddrInfo -- SBM's own IP address and L2 address for the 1925 interface and its own priority (a configuration parameter). 1927 c) RefreshInterval in seconds. When the DSBM is not yet 1928 elected, it is set to a default value specified as a 1929 configuration parameter. 1931 d) DSBMDeadInterval in seconds. When the DSBM is not yet 1932 elected, it is initially set to a default value specified as 1933 a configuration parameter. 1935 f) ListenInterval in seconds -- a configuration parameter 1936 that decides how long a SBM spends in the DetectDSBM state 1937 (see below). 1939 g) ElectionInterval in seconds -- a configuration parameter 1940 that decides how long a SBM spends in the ElectDSBM state 1941 when it has declared its candidacy. 1943 Figure 3 shows the state transition diagram for the election 1944 protocol and the various states are described below. A complete 1945 description of the state machine is provided in Section A.10. 1947 A.7. DSBM Election States 1949 DOWN -- SBM is not operational. 1951 SBM (Subnet Bandwidth Manager) January, 2000 1953 DetectDSBM -- typically, the initial state of a SBM when it 1954 starts up. In this state, it checks to see whether a DSBM 1955 already exists in its domain. 1957 Idle -- SBM is in this state when no election is in progress 1958 and it is not the DSBM. In this state, SBM passively monitors 1959 the state of the DSBM. 1961 ElectDSBM -- SBM is in this state when a DSBM election is in 1962 progress. 1964 IAMDSBM -- SBM is in this state when it is the DSBM for the 1965 L2 domain. 1967 A.8. Events that cause state changes 1969 StartUp -- SBM starts operation. 1971 ListenInterval Timeout -- The ListenInterval timer has fired. 1972 This means that the SBM has monitored its domain to check for 1973 an existing DSBM or to check whether there are candidates 1974 (other than itself) willing to be the DSBM. 1976 DSBM_WILLING message received -- This means that the SBM 1977 received a DSBM_WILLING message from some other SBM. Such a 1978 message is sent when a SBM wishes to declare its candidacy to 1979 be the DSBM. 1981 I_AM_DSBM message received -- SBM received a DSBM advertisement 1982 from the DSBM in its L2 domain. 1984 DSBMDeadInterval Timeout -- The DSBMDeadIntervalTimer has 1985 fired. This means that the SBM did not receive even one DSBM 1986 advertisement during this period and indicates possible 1987 failure of the DSBM. 1989 SBM (Subnet Bandwidth Manager) January, 2000 1991 RefreshInterval Timeout -- The RefreshIntervalTimer has 1992 fired. In the IAMDSBM state, this means it is the time for 1993 sending out the next DSBM advertisement. In the ElectDSBM 1994 state, the event means that it is the time to send out 1995 another DSBM_WILLING message. 1997 ElectionInterval Timeout -- The ElectionIntervalTimer has 1998 fired. This means that the SBM has waited long enough after 1999 declaring its candidacy to determine whether or not it 2000 succeeded. 2002 CONTINUED ON NEXT PAGE 2004 SBM (Subnet Bandwidth Manager) January, 2000 2006 A.9. State Transition Diagram (Figure 3) 2008 +-----------+ 2009 +--<--------------<-|DetectDSBM |---->------+ 2010 | +-----------+ | 2011 | | 2012 | | 2013 | | 2014 | +-------------+ +---------+ | 2015 +->---| Idle |--<>---|ElectDSBM|--<--+ 2016 +-------------+ +---------+ 2017 | | 2018 | | 2019 | | 2020 | +-----------+ | 2021 +<<- +---| IAMDSBM |-<-+ 2022 | +-----------+ 2023 | 2024 | +-----------+ 2025 +>>-| SHUTDOWN | 2026 +-----------+ 2028 A.10. Election State Machine 2030 Based on the events and states described above, the state changes 2031 at a SBM are described below. Each state change is triggered by an 2032 event and is typically accompanied by a sequence of actions. The 2033 state machine is described assuming a single threaded implementation 2034 (to avoid race conditions between state changes and timer 2035 events) with no timer events occurring during the execution of the 2036 state machine. 2038 The following routines will be frequently used in the description 2039 of the state machine: 2041 ComparePrio(FirstAddrInfo, SecondAddrInfo) 2042 -- determines whether the entity represented by the first parameter 2043 is better than the second entity using the priority information 2044 and the IP address information in the two parameters. 2045 If any address is zero, that entity 2046 automatically loses; then first priorities are compared; higher 2047 priority candidate wins. If there is a tie based on 2048 the priority value, the tie is broken using the IP 2049 addresses of tied candidates (one with the higher IP address in the 2050 lexicographic order wins). Returns TRUE if first entity is a better 2052 SBM (Subnet Bandwidth Manager) January, 2000 2054 choice. FALSE otherwise. 2056 SendDSBMWilling Message() 2057 Begin 2058 Send out DSBM_WILLING message listing myself as a candidate for 2059 DSBM (copy OwnAddr and priority into appropriate fields) 2060 start RefreshIntervalTimer 2061 goto ElectDSBM state 2062 End 2064 AmIBetterDSBM(OtherAddrInfo) 2065 Begin 2066 if (ComparePrio(OwnAddrInfo, OtherAddrInfo)) 2067 return TRUE 2069 change LocalDSBMInfo = OtherDSBMAddrInfo 2070 return FALSE 2071 End 2073 UpdateDSBMInfo() 2074 /* invoked in an assignment such as LocalDSBMInfo = OtherAddrInfo */ 2075 Begin 2076 update LocalDSBMInfo such as IP addr, DSBM L2 address, 2077 DSBM priority, RefreshIntervalTimer, DSBMDeadIntervalTimer 2078 End 2080 A.10.1 State Changes 2082 In the following, the action "continue" or "continue in current 2083 state" means an "exit" from the current action sequence without a 2084 state transition. 2086 State: DOWN 2087 Event: StartUp 2088 New State: DetectDSBM 2089 Action: Initialize the local state variables (LocalDSBMADDR and 2090 LocalDSBMAddrInfo set to 0). Start the ListenIntervalTimer. 2092 State: DetectDSBM 2093 New State: Idle 2094 Event: I_AM_DSBM message received 2095 Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2096 start DeadDSBMInterval timer 2097 goto Idle State 2099 SBM (Subnet Bandwidth Manager) January, 2000 2101 State: DetectDSBM 2102 Event: ListenIntervalTimer fired 2103 New State: ElectDSBM 2104 Action: Start ElectionIntervalTimer 2105 SendDSBMWillingMessage(); 2107 State: DetectDSBM 2108 Event: DSBM_WILLING message received 2109 New State: ElectDSBM 2110 Action: Cancel any active timers 2112 Start ElectionIntervalTimer 2113 /* am I a better choice than this dude? */ 2114 If (ComparePrio(OwnAddrInfo, IncomingDSBMInfo)) { 2115 /* I am better */ 2116 SendDSBMWillingMessage() 2117 } else { 2118 Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2119 goto ElectDSBM state 2120 } 2122 State: Idle 2123 Event: DSBMDeadIntervalTimer fired. 2124 New State: ElectDSBM 2125 Action: start ElectionIntervalTimer 2126 set LocalDSBMAddrInfo = OwnAddrInfo 2127 SendDSBMWiliingMessage() 2129 State: Idle 2130 Event: I_AM_DSBM message received. 2131 New State: Idle 2132 Action: /* first check whether anything has changed */ 2133 if (!ComparePrio(LocalDSBMAddrInfo, IncomingDSBMAddrInfo)) 2134 change LocalDSBMAddrInfo to reflect new info 2135 endif 2136 restart DSBMDeadIntervalTimer; 2137 continue in current state; 2139 State: Idle 2140 Event: DSBM_WILLING Message is received 2141 New State: Depends on action (ElectDSBM or Idle) 2142 Action: /* check whether it is from the DSBM itself (shutdown) */ 2143 if (IncomingDSBMAddr == LocalDSBMAddr) { 2144 cancel active timers 2145 Set LocalDSBMAddrInfo = OwnAddrInfo 2146 Start ElectionIntervalTimer 2147 SendDSBMWillingMessage() /* goto ElectDSBM state */ 2148 } 2150 SBM (Subnet Bandwidth Manager) January, 2000 2152 /* else, ignore it */ 2153 continue in current state 2155 State: ElectDSBM 2156 Event: ElectionIntervalTimer Fired 2157 New State: depends on action (IAMDSBM or Current State) 2158 Action: If (LocalDSBMAddrInfo == OwnAddrInfo) { 2159 /* I won */ 2160 send I_AM_DSBM message 2161 start RefreshIntervalTimer 2162 goto IAMDSBM state 2163 } else { /* someone else won, so wait for it to declare 2164 itself to be the DSBM */ 2165 set LocalDSBMAddressInfo = OwnAddrInfo 2166 start ElectionIntervalTimer 2167 SendDSBMWillingMessage() 2168 continue in current state 2169 } 2171 State: ElectDSBM 2172 Event: I_AM_DSBM message received 2173 New State: Idle 2174 Action: set LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2175 Cancel any active timers 2176 start DeadDSBMInterval timer 2177 goto Idle State 2179 State: ElectDSBM 2180 Event: DSBM_WILLING message received 2181 New State: ElectDSBM 2182 Action: Check whether it's a loopback and if so, discard, continue; 2183 if (!AmIBetterDSBM(IncomingDSBMAddrInfo)) { 2184 Change LocalDSBMAddrInfo = IncomingDSBMAddrInfo 2185 Cancel RefreshIntervalTimer 2186 } else if (LocalDSBMAddrInfo == OwnAddrInfo) { 2187 SendDSBMWillingMessage() 2188 } 2189 continue in current state 2191 State: ElectDSBM 2192 Event: RefreshIntervalTimer fired 2193 New State: ElectDSBM 2194 Action: /* continue to send DSBMWilling messages until 2195 election interval ends */ 2196 SendDSBMWillingMessage() 2198 State: IAMDSBM 2199 Event: DSBM_WILLING message received 2201 SBM (Subnet Bandwidth Manager) January, 2000 2203 New State: depends on action (IAMDSBM or SteadyState) 2204 Action: /* check whether other guy is better */ 2205 If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) { 2206 /* I am better */ 2207 send I_AM_DSBM message 2208 restart RefreshIntervalTimer 2209 continue in current state 2210 } else { 2211 Set LocalDSBMAddrInfo = IncomingAddrInfo 2212 cancel active timers 2213 start DSBMDeadIntervalTimer 2214 goto SteadyState 2215 } 2217 State: IAMDSBM 2218 Event: RefreshIntervalTimer fired 2219 New State: IAMDSBM 2220 Action: send I_AM_DSBM message 2221 restart RefreshIntervalTimer 2223 State: IAMDSBM 2224 Event: I_AM_DSBM message received 2225 New State: depends on action (IAMDSBM or Idle) 2226 Action: /* check whether other guy is better */ 2227 If (ComparePrio(OwnAddrInfo, IncomingAddrInfo)) { 2228 /* I am better */ 2229 send I_AM_DSBM message 2230 restart RefreshIntervalTimer 2231 continue in current state 2232 } else { 2233 Set LocalDSBMAddrInfo = IncomingAddrInfo 2234 cancel active timers 2235 start DSBMDeadIntervalTimer 2236 goto Idle State 2237 } 2239 State: IAMDSBM 2240 Event: Want to shut myself down 2241 New State: DOWN 2242 Action: send DSBM_WILLING message with My address filled in, but 2243 priority set to zero 2244 goto Down State 2246 A.10.2 Suggested Values of Interval Timers 2248 To avoid DSBM outages for long period, to ensure quick recovery 2250 SBM (Subnet Bandwidth Manager) January, 2000 2252 from DSBM failures, and to avoid timeout of PATH and RESV state at 2253 the edge devices, we suggest the following values for various 2254 timers. 2256 Assuming that the RSVP implementations use a 30 second timeout for 2257 PATH and RESV refreshes, we suggest that the RefreshIntervalTimer 2258 should be set to about 5 seconds with DSBMDeadIntervalTimer set to 2259 15 seconds (K=3, K*RefreshInterval). The DetectDSBMTimer should be 2260 set to a random value between (DSBMDeadIntervalTimer, 2261 2*DSBMDeadIntervalTimer). The ElectionIntervalTimer should be set at 2262 least to the value of DSBMDeadIntervalTimer to ensure that each SBM 2263 has a chance to have its DSBM_WILLING message (sent every 2264 RefreshInterval in ElectDSBM state) delivered to others. 2266 A.10.3. Guidelines for Choice of Values for SBM_PRIORITY 2268 Network administrators should configure SBM protocol entity at 2269 each SBM-capable device with the device's "SBM priority" for each 2270 of the interfaces attached to a managed segment. SBM_PRIORITY is 2271 an 8-bit, unsigned integer value (in the range 0-255) with higher 2272 integer values denoting higher priority. The value zero for an 2273 interface indicates that the SBM protocol entity on the device is 2274 not eligible to be a DSBM for the segment attached to the 2275 interface. 2277 A separate range of values is reserved for each type of SBM-capable 2278 device to reflect the relative priority among different 2279 classes of L2/L3 devices. L2 devices get higher priority followed 2280 by routers followed by hosts. The priority values in the range of 2281 128..255 are reserved for L2 devices, the values in the range of 2282 64..127 are reserved for routers, and values in the range of 1..63 2283 are reserved for hosts. 2285 A.11. DSBM Election over switched links 2287 The election algorithm works as described before in this case 2288 except each SBM-capable L2 device restricts the scope of the election 2289 to its local segment. As described in Section B.1 below, all 2290 messages related to the DSBM election are sent to a special multicast 2291 address (AllSBMAddress). AllSBMAddress (its corresponding MAC 2292 multicast address) is configured in the permanent database of 2293 SBM-capable, layer 2 devices so that all frames with AllSBMAddress 2294 as the destination address are not forwarded and instead directed 2296 SBM (Subnet Bandwidth Manager) January, 2000 2298 to the SBM management entity in those devices. Thus, a DSBM can be 2299 elected separately on each point-to-point segment in a switched 2300 topology. For example, in Figure 2, DSBM for "segment A" will be 2301 elected using the election algorithm between R1 and S1 and none of 2302 the election-related messages on this segment will be forwarded by 2303 S1 beyond "segment A". Similarly, a separate election will take 2304 place on each segment in this topology. 2306 When a switched segment is a half-duplex segment, two senders (one 2307 sender at each end of the link) share the link. In this case, one 2308 of the two senders will win the DSBM election and will be 2309 responsible for managing the segment. 2311 If a switched segment is full-duplex, exactly one sender sends on 2312 the link in each direction. In this case, either one or two DSBMs 2313 can exist on such a managed segment. If a sender at each end 2314 wishes to serve as a DSBM for that end, it can declare itself to 2315 be the DSBM by sending out an I_AM_DSBM advertisement and start 2316 managing the resources for the outgoing traffic over the segment. 2317 If one of the two senders does not wish itself to be the DSBM, 2318 then the other DSBM will not receive any DSBM advertisement from 2319 its peer and assume itself to be the DSBM for traffic traversing 2320 in both directions over the managed segment. 2322 SBM (Subnet Bandwidth Manager) January, 2000 2324 Appendix B 2325 Message Encapsulation and Formats 2327 To minimize changes to the existing RSVP implementations and to 2328 ensure quick deployment of a SBM in conjunction with RSVP, all 2329 communication to and from a DSBM will be performed using messages 2330 constructed using the current rules for RSVP message formats and 2331 raw IP encapsulation. For more details on the RSVP message formats, 2332 refer to the RSVP specification (RFC 2205). No changes to 2333 the RSVP message formats are proposed, but new message types and 2334 new L2-specific objects are added to the RSVP message formats to 2335 accommodate DSBM-related messages. These additions are described 2336 below. 2338 B.1 Message Addressing 2340 For the purpose of DSBM election and detection, AllSBMAddress is 2341 used as the destination address while sending out both 2342 DSBM_WILLING and I_AM_DSBM messages. A DSBM client first detects a 2343 managed segment by listening to I_AM_DSBM advertisements and 2344 records the DSBMAddress (unicast IP address of the DSBM). 2346 B.2. Message Sizes 2348 Each message must occupy exactly one IP datagram. If it exceeds 2349 the MTU, such a datagram will be fragmented by IP and reassembled 2350 at the recipient node. This has a consequence that a single 2351 message may not exceed the maximum IP datagram size, approximately 2352 64K bytes. 2354 B.3. RSVP-related Message Formats 2356 All RSVP messages directed to and from a DSBM may contain various 2357 RSVP objects defined in the RSVP specification and messages continue 2358 to follow the formatting rules specified in the RSVP specification. 2359 In addition, an RSVP implementation must also recognize 2360 new object classes that are described below. 2362 B.3.1. Object Formats 2364 SBM (Subnet Bandwidth Manager) January, 2000 2366 All objects are defined using the format specified in the RSVP 2367 specification. Each object has a 32-bit header that contains 2368 length (of the object in bytes including the object header), the 2369 object class number, and a C-Type. All unused fields should be set 2370 to zero and ignored on receipt. 2372 B.3.2. SBM Specific Objects 2374 Note that the Class-Num values for the SBM specific objects 2375 (LAN_NHOP, LAN_LOOPBACK, and RSVP_HOP_L2) are chosen from the 2376 codespace 10XXXXXX. This coding assures that non-SBM aware RSVP 2377 nodes will ignore the objects without forwarding them or 2378 generating an error message. 2380 Within the SBM specific codespace, note the following interpretation 2381 of the third most significant bit of the Class-Num: 2383 a) Objects of the form 100XXXXX are to be silently 2384 discarded by SBM nodes that do not recognize them. 2386 b) Objects of the form 101XXXXX are to be silently 2387 forwarded by SBM nodes that do not recognize them. 2389 B.3.3. IEEE 802 Canonical Address Format 2391 The 48-bit MAC Addresses used by IEEE 802 were originally defined 2392 in terms of wire order transmission of bits in the source and 2393 destination MAC address fields. The same wire order applied to both 2394 Ethernet and Token Ring. Since the bit transmission order of Ethernet 2395 and Token Ring data differ - Ethernet octets are transmitted 2396 least significant bit first, Token Ring most significant first - 2397 the numeric values naturally associated with the same address on 2398 different 802 media differ. To facilitate the communication of 2399 address values in higher layer protocols which might span both 2400 token ring and Ethernet attached systems connected by bridges, it 2401 was necessary to define one reference format - the so called canonical 2402 format for these addresses. Formally the canonical format 2403 defines the value of the address, separate from the encoding rules 2404 used for transmission. It comprises a sequence of octets derived 2405 from the original wire order transmission bit order as follows. The 2406 least significant bit of the first octet is the first bit transmitted, 2407 the next least significant bit the second bit, and so on to 2409 SBM (Subnet Bandwidth Manager) January, 2000 2411 the most significant bit of the first octet being the 8th bit 2412 transmitted; the least significant bit of the second octet is the 2413 9th bit transmitted, and so on to the most significant bit of the 2414 sixth octet of the canonical format being the last bit of the 2415 address transmitted. 2417 This canonical format corresponds to the natural value of the 2418 address octets for Ethernet. The actual transmission order or formal 2419 encoding rules for addresses on media which do not transmit bit 2420 serially are derived from the canonical format octet values. 2422 This document requires that all L2 addresses used in conjunction 2423 with the SBM protocol be encoded in the canonical format as a 2424 sequence of 6 octets. In the following, we define the object formats 2425 for objects that contain L2 addresses that are based on the 2426 canonical representation. 2428 B.3.4. RSVP_HOP_L2 object 2430 RSVP_HOP_L2 object uses object class = 161; it contains the L2 2431 address of the previous hop L3 device in the IEEE Canonical address 2432 format discussed above. 2434 RSVP_HOP_L2 object: class = 161, C-Type represents the addressing format 2435 used. In our case, C-Type=1 represents the IEEE Canonical Address 2436 format. 2438 0 1 2 3 2439 +---------------+---------------+---------------+----------------+ 2440 | Length | 161 |C-Type(addrtype)| 2441 +---------------+---------------+---------------+----------------+ 2442 | Variable length Opaque data | 2443 +---------------+---------------+---------------+----------------+ 2445 C-Type = 1 (IEEE Canonical Address format) 2447 When C-Type=1, the object format is: 2449 0 1 2 3 2450 +---------------+---------------+---------------+---------------+ 2451 | 12 | 161 | 1 | 2452 +---------------+---------------+---------------+---------------+ 2453 | Octets 0-3 of the MAC address | 2454 +---------------+---------------+---------------+---------------+ 2455 | Octets 4-5 of the MAC addr. | /// | /// | 2456 +---------------+---------------+---------------+---------------+ 2458 SBM (Subnet Bandwidth Manager) January, 2000 2460 /// -- unused (set to zero) 2462 B.3.5. LAN_NHOP object 2464 LAN_NHOP object represents two objects, namely, LAN_NHOP_L3 address 2465 object and LAN_NHOP_L2 address object. 2466 ::= 2468 LAN_NHOP_L2 address object uses object class = 162 and uses the 2469 same format (but different class number) as the RSVP_HOP_L2 object. 2470 It provides the L2 or MAC address of the next hop L3 device. 2472 0 1 2 3 2473 +---------------+---------------+---------------+----------------+ 2474 | Length | 162 |C-Type(addrtype)| 2475 +---------------+---------------+---------------+----------------+ 2476 | Variable length Opaque data | 2477 +---------------+---------------+---------------+----------------+ 2479 C-Type = 1 (IEEE 802 Canonical Address Format as defined below) 2480 See the RSVP_HOP_L2 address object for more details. 2482 LAN_NHOP_L3 object uses object class = 163 and gives the L3 or IP 2483 address of the next hop L3 device. 2485 LAN_NHOP_L3 object: class = 163, C-Type specifies IPv4 or IPv6 address 2486 family used. 2488 IPv4 LAN_NHOP_L3 object: class =163, C-Type = 1 2489 +---------------+---------------+---------------+---------------+ 2490 | Length = 8 | 163 | 1 | 2491 +---------------+---------------+---------------+---------------+ 2492 | IPv4 NHOP address | 2493 +---------------------------------------------------------------+ 2495 IPv6 LAN_NHOP_L3 object: class =163, C-Type = 2 2496 +---------------+---------------+---------------+---------------+ 2497 | Length = 20 | 163 | 2 | 2498 +---------------+---------------+---------------+---------------+ 2499 | IPv6 NHOP address (16 bytes) | 2500 +---------------------------------------------------------------+ 2502 B.3.6. LAN_LOOPBACK Object 2504 SBM (Subnet Bandwidth Manager) January, 2000 2506 The LAN_LOOPBACK object gives the IP address of the outgoing 2507 interface for a PATH message and uses object class=164; both IPv4 2508 and IPv6 formats are specified. 2510 IPv4 LAN_LOOPBACK object: class = 164, C-Type = 1 2512 0 1 2 3 2513 +---------------+---------------+---------------+---------------+ 2514 | Length | 164 | 1 | 2515 +---------------+---------------+---------------+---------------+ 2516 | IPV4 address of an interface | 2517 +---------------+---------------+---------------+---------------+ 2519 IPv6 LAN_LOOPBACK object: class = 164, C-Type = 2 2521 +---------------+---------------+---------------+---------------+ 2522 | Length | 164 | 2 | 2523 +---------------+---------------+---------------+---------------+ 2524 | | 2525 + + 2526 | | 2527 + IPV6 address of an interface + 2528 | | 2529 + + 2530 | | 2531 +---------------+---------------+---------------+---------------+ 2533 B.3.7. TCLASS Object 2535 TCLASS object (traffic class based on IEEE 802.1p) uses object 2536 class = 165. 2538 0 1 2 3 2539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2540 | Length | 165 | 1 | 2541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2542 | /// | /// | /// | /// | PV | 2543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 Only 3 bits in data contain the user_priority value (PV). 2547 B.4. RSVP PATH and PATH_TEAR Message Formats 2549 As specified in the RSVP specification, a PATH and PATH_TEAR messages 2550 contain the RSVP Common Header and the relevant RSVP objects. 2552 SBM (Subnet Bandwidth Manager) January, 2000 2554 For the RSVP Common Header, refer to the RSVP specification (RFC 2555 2205). Enhancements to an RSVP_PATH message include additional 2556 objects as specified below. 2558 ::= [] 2559 2560 [] 2561 [] 2563 ::= [] 2564 2565 [] 2567 If the INTEGRITY object is present, it must immediately follow the 2568 RSVP common header. L2-specific objects must always precede the 2569 SESSION object. 2571 B.5. RSVP RESV Message Format 2573 As specified in the RSVP specification, an RSVP_RESV message contains 2574 the RSVP Common Header and relevant RSVP objects. In addition, it may 2575 contain an optional TCLASS object as described earlier. 2577 B.6. Additional RSVP message types to handle SBM interactions 2579 New RSVP message types are introduced to allow interactions between 2580 a DSBM and an RSVP node (host/router) for the purpose of discovering 2581 and binding to a DSBM. New RSVP message types needed are as 2582 follows: 2584 RSVP Msg Type (8 bits) Value 2585 DSBM_WILLING 66 2586 I_AM_DSBM 67 2588 All SBM-specific messages are formatted as RSVP messages with an 2589 RSVP common header followed by SBM-specific objects. 2591 ::= 2593 where ::= [] 2595 For each SBM message type, there is a set of rules for the 2596 permissible choice of object types. These rules are specified using 2598 SBM (Subnet Bandwidth Manager) January, 2000 2600 Backus-Naur Form (BNF) augmented with square brackets surrounding 2601 optional sub-sequences. The BNF implies an order for the objects in 2602 a message. However, in many (but not all) cases, object order makes 2603 no logical difference. An implementation should create messages 2604 with the objects in the order shown here, but accept the objects in 2605 any permissible order. Any exceptions to this rule will be pointed 2606 out in the specific message formats. 2608 DSBM_WILLING Message 2610 ::= 2611 2613 I_AM_DSBM Message 2615 ::= 2616 2617 [] 2619 For compatibility reasons, receivers of the I_AM_DSBM message must 2620 be prepared to receive additional objects of the Unknown Class type 2621 [RFC-2205]. 2623 All I_AM_DSBM messages are multicast to the well known AllSBMAddress. 2624 The default priority of a SBM is 1 and higher priority 2625 values represent higher precedence. The priority value zero 2626 indicates that the SBM is not eligible to be the DSBM. 2628 Relevant Objects 2630 DSBM IP ADDRESS objects use object class = 42; IPv4 DSBM IP ADDRESS 2631 object uses and IPv6 DSBM IP ADDRESS object 2632 uses . 2634 IPv4 DSBM IP ADDRESS object: class = 42, C-Type =1 2635 0 1 2 3 2636 +---------------+---------------+---------------+---------------+ 2637 | IPv4 DSBM IP Address | 2638 +---------------+---------------+---------------+---------------+ 2640 IPv6 DSBM IP ADDRESS object: Class = 42, C-Type = 2 2642 SBM (Subnet Bandwidth Manager) January, 2000 2644 +---------------+---------------+---------------+---------------+ 2645 | | 2646 + + 2647 | | 2648 + IPv6 DSBM IP Address + 2649 | | 2650 + + 2651 | | 2652 +---------------+---------------+---------------+---------------+ 2654 Object is the same as object with 2655 C-Type = 1 for IEEE Canonical Address format. 2657 ::= 2659 a SBM may omit this object by including a NULL L2 address object. For 2660 C-Type=1 (IEEE Canonical address format), such a version of the L2 2661 address object contains value zero in the six octet s corresponding to the 2662 MAC address (see section B.3.4 for the exact format). 2664 SBM_PRIORITY Object: class = 43, C-Type =1 2666 0 1 2 3 2667 +---------------+---------------+---------------+---------------+ 2668 | /// | /// | /// | SBM priority | 2669 +---------------+---------------+---------------+---------------+ 2671 TIMER INTERVAL VALUES. 2673 The two timer intervals, namely, DSBM Dead Interval and DSBM 2674 Refresh Interval, are specified as integer values each in the 2675 range of 0..255 seconds. Both values are included in a single 2676 "DSBM Timer Intervals" object described below. 2678 DSBM Timer Intervals Object: class = 44, C-Type =1 2680 +---------------+---------------+---------------+----------------+ 2681 | /// | /// | DeadInterval | RefreshInterval| 2682 +---------------+---------------+---------------+----------------+ 2684 NON_RESV_SEND_LIMIT Object: class = 45, C-Type = 1 2686 0 1 2 3 2687 +---------------+---------------+---------------+----------------+ 2688 | NonResvSendLimit(limit on traffic allowed to send without RESV)| 2689 | | 2690 +---------------+---------------+---------------+----------------+ 2692 SBM (Subnet Bandwidth Manager) January, 2000 2694 ::= (class=12, C-Type =2) 2696 The NON_RESV_SEND_LIMIT object specifies a per-flow limit on the 2697 profile of traffic which a sending host is allowed to send onto a 2698 managed segment without a valid RSVP reservation (see Appendix C 2699 for further details on the usage of this object). The object contains 2700 the NonResvSendLimit parameter. This parameter is equivalent 2701 to the Intserv SENDER_TSPEC (see RFC 2210 for contents and encoding 2702 rules). The SENDER_TSPEC includes five parameters which describe a 2703 traffic profile (r, b, p, m and M). Sending hosts compare the 2704 SENDER_TSPEC describing a sender traffic flow to the SENDER_TSPEC 2705 advertised by the DSBM. If the SENDER_TSPEC of the traffic flow in 2706 question is less than or equal to the SENDER_TSPEC advertised by 2707 the DSBM, it is allowable to send traffic on the corresponding flow 2708 without a valid RSVP reservation in place. Otherwise it is not. 2710 The network administrator may configure the DSBM to disallow any 2711 sent traffic in the absence of an RSVP reservation by configuring a 2712 NonResvSendLimit in which r = 0, b = 0, p = 0, m = infinity and M = 2713 0. Similarly the network administrator may allow any traffic to be 2714 sent in the absence of an RSVP reservation by configuring a 2715 NonResvSendLimit in which r = infinity, b = infinity, p = infinity, m 2716 = 0 and M = infinity. Of course, any of these parameters may be set 2717 to values between zero and infinity to advertise finite per-flow 2718 limits. 2720 The NON_RESV_SEND_LIMIT object is optional. Senders on a managed 2721 segment should interpret the absence of the NON_RESV_SEND_LIMIT 2722 object as equivalent to an infinitely large SENDER_TSPEC (it is 2723 permissible to send any traffic profile in the absence of an RSVP 2724 reservation). 2726 SBM (Subnet Bandwidth Manager) January, 2000 2728 Appendix C 2729 The DSBM as a Source of Centralized Configuration Information 2731 There are certain configuration parameters which it may be useful 2732 to distribute to layer-3 senders on a managed segment. The DSBM may 2733 serve as a centralized management point from which such parameters 2734 can easily be distributed. In particular, it is possible for the 2735 network administrator configuring a DSBM to cause certain 2736 configuration parameters to be distributed as objects appended to the 2737 I_AM_DSBM messages. The following configuration object is defined 2738 at this time. Others may be defined in the future. See Appendix B 2739 for further details regarding the NON_RESV_SEND_LIMIT object. 2741 C.1. NON_RESV_SEND_LIMIT 2743 As we QoS enable layer 2 segments, we expect an evolution from subnets 2744 comprised of traditional shared segments (with no means of 2745 traffic separation and no DSBM), to subnets comprised of dedicated 2746 segments switched by sophisticated switches (with both DSBM and 2747 802.1p traffic separation capability). 2749 A set of intermediate configurations consists of a group of QoS 2750 enabled hosts sending onto a traditional shared segment. A layer-3 2751 device (or a layer-2 device) acts as a DSBM for the shared segment, 2752 but cannot enforce traffic separation. In such a configuration, the 2753 DSBM can be configured to limit the number of reservations approved 2754 for senders on the segment, but cannot prevent them from sending. 2755 As a result, senders may congest the segment even though a network 2756 administrator has configured an appropriate limit for admission 2757 control in the DSBM. 2759 One solution to this problem which would give the network administrator 2760 control over the segment, is to require applications (or 2761 operating systems on behalf of applications) not to send until they 2762 have obtained a reservation. This is problematic as most applications 2763 are used to sending as soon as they wish to and expect to get 2764 whatever service quality the network is able to grant at that time. 2765 Furthermore, it may often be acceptable to allow certain applications 2766 to send before a reservation is received. For example, on a 2767 segment comprised of a single 10 Mbps ethernet and 10 hosts, it may 2768 be acceptable to allow a 16 Kbps telephony stream to be transmitted 2769 but not a 3 Mbps video stream. 2771 A more pragmatic solution then, is to allow the network administrator 2772 to set a per-flow limit on the amount of non-adaptive traffic 2773 which a sender is allowed to generate on a managed segment in the 2774 absence of a valid reservation. This limit is advertised by the 2775 DSBM and received by sending hosts. An API on the sending host can 2777 SBM (Subnet Bandwidth Manager) January, 2000 2779 then approve or deny an application's QoS request based on the 2780 resources requested. 2782 The NON_RESV_SEND_LIMIT object can be used to advertise a Flowspec 2783 which describes the shape of traffic that a sender is allowed to 2784 generate on a managed segment when its RSVP reservation requests 2785 have either not yet completed or have been rejected. 2787 SBM (Subnet Bandwidth Manager) January, 2000 2789 ACKNOWLEDGEMENTS 2791 Authors are grateful to Eric Crawley (Argon), Russ Fenger (Intel), 2792 David Melman (Siemens), Ramesh Pabbati (Microsoft), Mick Seaman 2793 (3COM), Andrew Smith (Extreme Networks) for their constructive 2794 comments on the SBM design and the earlier versions of this document. 2796 6. Authors` Addresses 2798 Raj Yavatkar 2799 Intel Corporation 2800 2111 N.E. 25th Avenue, 2801 Hillsboro, OR 97124 2802 USA 2803 phone: +1 503-264-9077 2804 email: yavatkar@ibeam.intel.com 2806 Don Hoffman 2807 Teledesic Corporation 2808 2300 Carillon Point 2809 Kirkland, WA 98033 2810 USA 2811 phone: +1 425-602-0000 2813 Yoram Bernet 2814 Microsoft 2815 1 Microsoft Way 2816 Redmond, WA 98052 2817 USA 2818 phone: +1 206 936 9568 2819 email: yoramb@microsoft.com 2821 Fred Baker 2822 Cisco Systems 2823 519 Lado Drive 2824 Santa Barbara, California 93111 2825 USA 2826 phone: +1 408 526 4257 2827 email: fred@cisco.com 2829 Michael Speer 2830 Sun Microsystems, Inc 2831 901 San Antonio Road UMPK15-215 2832 Palo Alto, CA 94303 2833 phone: +1 650-786-6368 2834 email: speer@Eng.Sun.COM