Internet Engineering Task Force Raj Yavatkar, Intel INTERNET-DRAFT Don Hoffman, Sun Microsystems Yoram Bernet, Microsoft Ema Patki, Intel September 1996 Expires: December 31, 1996 SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over Ethernet Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This document is a product of the ISSLL subgroup of the Integrated Services working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at issll@mercury.lcs.mit.edu, and/or the author(s). Abstract This document outlines an architecture for RSVP-based admission control over an IEEE 802.3 ethernet environment. The proposed architecture is designed to work with the current generation of Ethernet infrastructure (NICs, bridges, hubs, and switches) and should be considered as a first step towards discovering solutions for implementation of IntServ capabilities over Ethernet. This draft is intended for discussions in ISSLL working group's interim meeting (Boston, October 1996) and is a revision of an earlier draft presented at the Montreal IETF meeting in June 1996. draft-yavatkar-sbm-ethernet-01.txt [Page 1] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 1. Introduction RSVP and Integrated-Services specifications together define an admission control and traffic control framework for providing end-to-end QoS guarantees over the Internet. However, specific algorithms, mechanisms, and protocols are needed to map the proposed integrated services over specific link-layer technologies such as Ethernet. Our goal is to propose an architecture for achieving admission control and traffic control over Ethernet on the basis of the framework proposed in the RSVP and Int-Serv working groups. Our proposal is based on the following architectural goals and assumptions: I. Our goal is to define an architecture that provides a step-by-step solution to the problem of managing bandwidth that works with the existing, legacy Ethernet infrastructure and takes advantage of additional functionality (such as an explicit support for integrated services) as it becomes available in new generation of Ethernet NICs, switches, hubs, or bridges. As a result, our archi- tecture would allow for a range of LAN bandwidth management solu- tions that vary from one that exercises purely administrative con- trol (over the amount of bandwidth consumed by RSVP-enabled traffic flows) to one that requires cooperation (and enforcement) from all the end-systems attached to a shared sub-network. II. To support integrated services on a specific networking technology, we must specify both admission control and traffic control com- ponents. Our goal is to specify an architecture for admission con- trol in this document and suggest possible approaches for traffic control in end-systems and Ethernet infrastructure (switches, hubs, etc.) III. An effective admission control mechanism for Ethernet requires managing and controlling bandwidth usage so that the aggregate traffic load on any Ethernet segment does not exceed its capacity. This requires controlling the amount of traffic generated by both RSVP-enabled and best-effort traffic flows. On one hand, RSVP pro- vides a framework for achieving admission control over RSVP-enabled flows under which receivers must request reservation of resources for the traffic they wish to receive. Thus, amount of traffic load imposed by RSVP-enabled flows can be controlled to stay within a limit. On the other hand, the best-effort traffic generated by TCP/IP based sources is generally rate-adaptive (using "slow start" type congestion avoidance mechanisms or feedback-based rate adapta- tion used by sources based on RTP/RTCP protocols) and limits the amount of traffic generated to adapt to available capacity. Thus, specification of an RSVP-based admission control mechanism for Eth- ernet typically suffices to control the total amount of traffic draft-yavatkar-sbm-ethernet-01.txt [Page 2] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 over a shared LAN. This is especially true in a switched Ethernet environment if switches and NICs support at least two levels of priority. In such a multi-priority LAN, assignment of higher prior- ity to RSVP traffic (to separate it from best-effort traffic) cou- pled with a combination of admission control (over RSVP traffic to keep it within a fraction of any link's capacity) and per-flow pol- icing at end-systems should suffice to realize an approximation to "controlled load" service specified in the int-serv working group. However, in some cases and topologies such as a shared Ethernet segment, best-effort traffic can interfere with traffic from RSVP-enabled traffic and, therefore, an explicit control over the amount of best-effort traffic that can be sent over Ethernet may also be necessary to implement a particular service class. Such a control may be exercised at end-nodes through a combination of pol- icing and admission control for best-effort traffic without an explicit QoS specification by and participation of applications that generate such traffic. To accommodate such needs, our proposal includes mechanisms for reservation of bandwidth by both RSVP- enabled and non-RSVP traffic. IV. RSVP uses a receiver-initiated approach for resource reservation. Under this approach, a sender notifies the (network and the) receivers about its traffic characteristics and the receiver ini- tiates a reservation request that propagates back to the sender. As the reservation request propagates back to the sender, each intermediate RSVP node (a host or a router) reserves resources on its downstream interface. We propose to retain the same model of receiver-based reservations for RSVP flows. However, to allow for reservation of bandwidth by non-RSVP flows, a sender-based reser- vation mechanism is also included for unicast flows. We will show that these two can coexist. V. For traffic control, we assume that end-systems will police indivi- dual flows to ensure that each flow stays within its traffic specification stipulated in its reservation request for admission control. Additional traffic scheduling mechanisms may also be employed to realize a particular QoS service class. No explicit support for integrated services is assumed from Ethernet NICs, switches, hubs, or bridges. This document mainly concentrates on the admission control component. At the end of this document, we identify possible alternatives for traffic control support in both end-systems and Ethernet switches. VI. In the absence of any policing or traffic shaping mechanism for limiting outgoing traffic on an end-system, our architecture only provides an administrative control over the maximum amount of RSVP-capable traffic admitted on any segment of a LAN. We assume that all the RSVP nodes on a LAN will utilize the proposed draft-yavatkar-sbm-ethernet-01.txt [Page 3] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 admission control procedure to reserve bandwidth in advance of sending any RSVP-enabled data flows and will not send/forward such traffic if the reservation request fails. Thus, if all the mul- timedia traffic on a LAN is sent using RSVP for resource reserva- tion, the proposed architecture would restrict the total mul- timedia traffic on any LAN segment within the bounds desired by a LAN administrator. This does not assure that non-RSVP traffic will not interfere with the RSVP traffic. 2. Overview 2.1 Terminology Our architecture is based on a logical entity called an SBM (Subnet Bandwidth Manager) responsible for handling admission control requests. We assume that a Designated SBM (DSBM) exists for each LAN segment (called a Managed Segment or MS) and services reservation requests (manages bandwidth) for that segment. An SBM is an application-level entity that uses the raw IP protocol with its own pro- tocol identifier for communication with its clients. The architecture makes no assumptions about the number of SBMs within a LAN; an SBM may act as a DSBM for one or more segments, or a single DSBM may exist for each LAN segment. In the following, we refer to an entity requesting bandwidth reservation as an "SBM client". 2.1 Basic Algorithm Figure 1 - Example Managed Segment. Host Host _______ === ------- === | | | C | | SBM | | B | | Router| | | - /---- | | |_R2____| === / === | | / | | | / | ==============================================================LAN | | | | === __|_____ | A | | Router | | | | R1 | === |________| Host draft-yavatkar-sbm-ethernet-01.txt [Page 4] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 Figure 1 shows an example topology with hosts and routers interconnected across a LAN. For the purpose of this discussion, we ignore the actual physical topology of the LAN and a single SBM is assumed to be the DSBM for the entire LAN. The basic SBM algorithm works as follows: 1. DSBM Initialization: As part of its initial configuration, DSBM obtains information such as maximum bandwidth that can be reserved on each LAN segment under its control. Configuration is likely to be static with the current Ethernet devices. Future work may allow for dynamic discovery of this information. Section 3 discusses some of these issues in more detail. 2 SBM Client Initialization: At the start, an SBM client discovers and binds to its DSBM using a "SBM Discovery Protocol" (described in section 2.4). 3. SBM Message Types: Admission control under SBM has two parts. The first part is an RSVP-based admission control mechanism that sup- ports receiver-initiated reservations for RSVP-enabled flows. The second part provides admission control for non-RSVP flows and allows resource reservation by sources of such traffic. Therefore, DSBM recognizes two types of messages: RSVP-based RESERVE (and related) messages and additional message types defined explicitly for interaction with non-RSVP enabled SBM clients. 4. RSVP-based Admission Control: To reserve Ethernet bandwidth, RSVP nodes (RSVP-capable hosts and routers) follow the following steps: a) As in conventional RSVP processing, Path messages from a sender are sent/forwarded to potential receivers using the destination session address or using the standard RSVP encapsulation. For example, if the sender to a session is outside the LAN and router R1 (see Figure 1) is on the path to the receivers, R1 will forward a PATH message from the sender to the session address. b) When a receiver (say, host A) wishes to make a reservation request for the session, it sends a RSVP RESERVE message to its DSBM using that DSBM's unicast address. The RESERVE message must contain an additional, new RSVP object called LAN_PHOP object. This object specifies the IP address of the PHOP (previous hop) associated with the RESERVE message and has the same structure as the RSVP_HOP object. c) The DSBM processes the RSVP RESERVE message based on the bandwidth available and returns an RSVP_ERROR to the requester (host A) if the request cannot be granted. In case of a success- ful reservation, DSBM forwards the RESERVE message towards the draft-yavatkar-sbm-ethernet-01.txt [Page 5] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 PHOP specified in the LAN_PHOP object. The RESERVE message lists DSBM as the NHOP and, thus, DSBM effectively inserts itself as an intermediate node between the actual NHOP (receiver) and the PHOP (router or sender specified in the LAN_PHOP object). The DSBM merges reservation requests for the same session as and when pos- sible using the rules similar to the conventional RSVP process- ing. d) The RESERVE message eventually reaches the original PHOP on that MS (as specified in the LAN_PHOP object) if all reservation requests within the MS succeed. 5. Admission Control for non-RSVP flows: To reserve bandwidth for non-RSVP flows, SBM clients that are traffic sources also reserve bandwidth as follows. An SBM client sends an SBM_RESV message to its DSBM that specifies the source IP address, destination IP address, the QoS control ser- vice desired (as per the int-serv specification), and the service- specific flow specification (FLOWSPEC object). The DSBM processes the SBM_RESV message and returns an SBM_ERROR or SBM_CONFM message back to the requester depending on the result of admission con- trol. The error message indicates the reason for failure and pro- vides a hint on available bandwidth if the request failed due to in availability of bandwidth. 2.2 Changes to conventional RSVP operation The SBM algorithm requires following changes to the RSVP operation on part of RSVP end-nodes: - Outgoing RESERVE messages on an Ethernet interface are unicast to the DSBM. - RESERVE messages sent to a DSBM contain a new, additional object called LAN_PHOP that specifies the IP address of the PHOP for the RESERVE message. - RESERVE messages are sent from an RSVP node to the DSBM, and not the PHOP. - Because DSBM inserts itself as a hop between PHOP and the receiver, all RSVP_RESERVE related messages (such as RESV_CONFM, RESV_TEAR, and RESV_ERR) flow through the DSBM. draft-yavatkar-sbm-ethernet-01.txt [Page 6] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 2.3 Co-Existence of RSVP and non-RSVP flows On the shared segment shown in Figure 1, it is possible for both RSVP and non-RSVP flows to exist simultaneously without compromising the QoS granted to the RSVP flows. To this end, it is necessary for all non- RSVP traffic sent on the segment, to be subject to admission control by the same DSBM as RSVP traffic, and for non-RSVP traffic to be policed (or shaped) in the same manner as RSVP traffic, at each sender. As an example, consider an RSVP reservation initiated by host A for a flow generated by host B; the reservation will flow through the SBM, where it will be subjected to admission control. Assuming that it passes admission control, the reservation will be forwarded to host B. Host B`s traffic control elements will be configured to transmit traffic for the new flow such that it is conformant with the accepted reserva- tion. Now consider that an application on host C, which is not RSVP aware, begins sending traffic to host A. No RSVP reservation will be generated on behalf of this traffic. Instead, traffic control elements in host C will signal to the DSBM, using the described sender initiated protocol, requesting a reservation for the new traffic flow. This reservation will be subject to the same admission control procedure as RSVP reservations, based on the availability of resources in the same shared pool. 2.4 Discovering and Binding to a DSBM DSBM listens to a well-known SBM multicast address (SBM_GRP - an IP multicast address) and an SBM client locates its DSBM by multicasting a LOCATE_SBM request to SBM_GRP with a restricted multicast scope (multi- cast TTL=1). After the initial handshake between the DSBM and an SBM client, the SBM client is considered bound to its DSBM. The SBM client must listen to the subsequent, periodic I_AM_DSBM refresh messages from its DSBM to detect the DSBM failure. The client must repeat the binding procedure if original DSBM fails (or is replaced by another one). 2.5 More than one active SBM on a LAN segment For the sake of redundancy and fault tolerance, it is possible to have more than one active SBM on any LAN segment that can act as a backup DSBM if necessary. In such a case, exactly one SBM acts as the DSBM at any time and is elected using an DSBM election algorithm. Once a DSBM is elected, other SBMs stay around and step in to elect a new DSBM if the previously elected DSBM terminates or crashes for some reason. The elec- tion algorithm works as follows. When a SBM comes up on an IP subnet, it must first discover whether a DSBM already exists on the subnet. It does so by listening for incoming draft-yavatkar-sbm-ethernet-01.txt [Page 7] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 I_AM_DSBM messages for a random amount of time. If no other DSBM is present, it announces its willingness to be a DSBM by periodically mul- ticasting a DSBM WILLING message to the SBM_GRP address with restricted multicast scope (TTL=1). If another SBM exists on the same subnet and considers itself a current or a better choice, it replies to the new SBM via a multicast I AM DSBM message to the same group. Ties between can- didate DSBMs may be broken based on a priority field in the I_AM_DSBM message (priority specified by the network administrator) or simply based on IP address ordering. (e.g. candidate with the lower IP address wins). If the new SBM does not hear a response from a better choice within K periodic announcements, it declares itself to be the SBM by multicasting a I_AM_DSBM message. The designated SBM of the MS periodically multicasts the I_AM_DSBM mes- sage. Other SBMs in the MS listen to the periodic announcements and assume that the SBM has terminated functioning if they do not hear K successive periodic announcements. In that case, all the SBMs initiate the election algorithm to elect a new DSBM. 2.6 Application Behavior This proposal makes no assumptions about any traffic separation or pol- icing mechanisms on the MS. Consequently, there are no network enforced mechanisms to keep non adaptive traffic intended to be part of a reserved flow, but that did not receive a reservation due to admission control, from interfering with traffic running with valid reservations. Instead, applications are expected to be well behaved and follow the following set of rules in such environments: - For both unicast and multicast flows, an RSVP-based sender is not to transmit any traffic on a RSVP flow until at least one RESERVE has been received for that flow. The outgo- ing flow should be policed at the sender to be less than or equal to the maximum flow reserved. RESERVE TEARS are indications that the sender should no longer send a flow. - For multicast flows, the receiver is to leave the session multicast group if a reservation error (RESV_ERROR) or a Path Tear (PTEAR) is received. This rule may create some difficulty in environments where source specific multicast pruning is not implemented (the default case in the current MBONE). A reservation error from a path toward any one specific sender would result in the receiver dropping all senders, even those with fully reserved paths. Applications running in such environments should restrict ses- sions to a single sender if at all possible. draft-yavatkar-sbm-ethernet-01.txt [Page 8] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 - For non-RSVP flows, the sender must first contact the DSBM to suc- cessfully reserve the resources before sending any traffic. Also, the outgoing flow must be policed at the sender to be less than or equal to the maximum flow reserved. 2.6.1 Non-RSVP Flows The primary goal in supporting reservations for non-RSVP flows is to protect RSVP flows on a shared segment from non-RSVP flows on that segment. While this mechanism may be used to grant a specific QoS to a specific flow, it is only its secondary benefit when the application generating the flow is RSVP-unaware. Applications requiring a specific QoS should obtain it using RSVP and non-RSVP flows are intended to be used primarily to provide best-effort service to non-RSVP aware applications. Traffic control components on end-stations are expected to track the offered load of the aggregate non-RSVP traffic generated on that end- station and to request reservations on its behalf, from the SBM. The SBM will allocate resources, as available, for non-RSVP traffic. These will be allocated from that fraction of the shared segments resource pool, designated to be available for best-effort traffic. End stations are expected to limit their aggregate transmitted best-effort traffic per the parameters indicated in the SBM`s response to the reservation request. draft-yavatkar-sbm-ethernet-01.txt [Page 9] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 3. Handling Complex LAN Physical Topologies The physical topology of a LAN may vary from a single, shared segment to a more complex, multi-hop topology (e.g., an interconnected network of bridges, hubs, and switches). In such a complex topology, the SBM algo- rithm should handle two cases that may arise: - In a multi-hub (or bridged) LAN topology, unicast data flows between two entities on the subnet only traverse a subset of LAN segments. Similarly, if Ethernet switches/hubs support IP multicast traffic filtering, multicast data flows would also traverse a sub- set of segments based on the location of IP multicast group members. Thus, the SBM algorithm must reserve bandwidth only on affected segments in such cases. - Instead of a single SBM acting as a centralized DSBM for the entire multi-hop LAN, it may be desirable to deploy many SBMs with each SBM responsible for managing bandwidth on a separate portion of the LAN. To handle such a case of many DSBMs within a LAN, our SBM algorithm must include mechanisms for discovering and communicating with peer DSBMs within a LAN. In the remainder of this document, we address each of these issues in more detail. 3.1 Discovering Physical Topology of a LAN We assume that an SBM can discover the topological information about the physical interconnections among hubs, switches, and bridges using a variety of methods such as using a static topology configuration database or using MIBs and techniques used by network management utilities. Using a static topology database is suffi- cient when the multi-hop LAN uses a star-based topology with no alternate, redundant interconnections between bridges and hubs. However, when alternate paths exist in a rich topology, bandwidth reservation optimizations require access to information that reveals the LAN segments traversed between two endpoints. Ideally, a standard interface to information such as the spanning tree con- figuration should be made available by IEEE 802.3 (or associated) working groups. Until such an interface is available, we propose a topology discovery protocol that relies on the "Topology Mapping" section (section 4.0) of the hub MIB WG specification being con- sidered in IETF [3]. 3.1.1 Topology Discovery Protocol Figure 2 -- Alternative representation of the LAN in figure 1. draft-yavatkar-sbm-ethernet-01.txt [Page 10] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 Switch Host ____ === | Sw1| | A | |____|-------------| | / === / / _/__ === | Sw2|-------------| C | |____| | | / === / Host __/__ ____ | SW3 | | Sw4 | |_____| |_____| / / === _/____ | B |------| Sw5| | | |____| === Host As described above, in a multi-hop LAN, a DSBM should identify the relevant physical segments on a path between a sender and a receiver and perform admission control over one or more such seg- ments. Figure 2 shows an example multi-hop topology. Communication between endpoints (e.g., between hosts A and B, or between B and C) requires reservation of bandwidth across only few of the LAN seg- ments segments that lie on the path between the two endpoints. Given a topology map, the DSBM needs to place the two endpoints on the map and identify the LAN segments on the path between them. An SBM follows the following steps to achieve the goal: 1. The SBM determines the MAC address of the endpoint it wishes to place on the map. 2. The SBM tells all managed hubs in the collision domain to watch for packets with that source MAC address. 3. The SBM sends an echo datagram ("ping") to the endpoint to cause it to transmit. The SBM then uses the hub MIB interface to read the group and port of the targeted MAC address from the managed hubs. The information obtained identifies the location of the endpoint on draft-yavatkar-sbm-ethernet-01.txt [Page 11] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 the map and the LAN segments currently used to reach the endpoint. Similar information can be gathered for the other endpoint. 4. Once the endpoints and the traversed hops are placed on the topol- ogy map, the SBM can identify the affected segments between the two endpoints assuming a spanning tree topology. 3.2 Handling Multiple, Peer DSBMs in a LAN We assume that each DSBM has information on which LAN segments are under its control and needs to communicate with its peer DSBMs whenever admission control involves LAN segments that are not under its control. Thus, peer-to-peer DSBM communication involves two parts: - Discovering peer DSBMs (and information on which segments they manage). - Coordinating with peer DSBMs when a reservation request involves LAN segments under the control of more than one SBM. 3.2.1 Discovery of Peer SBMs All SBMs maintain a local cache of information on peer SBMs and segments under their control. The cache is periodically updated to flush outdated entries. When an SBM processes a reservation request involving segment(s) that are not under its control, it checks its cache to locate appropriate DSBMs for the segment(s) of interest. If no DSBM is known, it multicasts (with TTL=1) a PEER_SEARCH query to the SBM_GRP specifying the segment(s) of interest. When the appropriate DSBM receives such a request, it multicasts its reply to the group giving its unicast address and the list of segments under its control. The requesting SBM (and others) then include the information in their cache. 3.2.2 Peer-to-Peer Communication When a reservation request involves segments outside the domain of a DSBM, it first performs admission control on segments under its control. If the admission control succeeds, the DSBM forwards the RSVP RESERVE request to the peer DSBM responsible for the next segment(s) on the path towards the LAN_PHOP using the peer`s uni- cast address. The peer DSBM will repeat similar procedure and for- ward the RESERVE to the next DSBM if necessary. Finally, the DSBM responsible for the final segment for the LAN_PHOP will forward the RESERVE to the LAN_PHOP if admission control succeeds up to and draft-yavatkar-sbm-ethernet-01.txt [Page 12] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 including the final segment. If admission control fails at any intervening SBM, that SBM sends back an RSVP_ERROR message to its previous peer and the error message propagates hop-by-hop (using the information in the reservation state at intermediate SBMs) back to the first DSBM which then communicates the RSVP_ERROR back to the RSVP node that initiated the RESERVE. DSBMs merge reservation requests (and handle killer reservation problems) for the same session on segments under their control according to the rules specified in the RSVP specification. 4. ADDITIONAL NOTES It should be noted that our design allows for one DSBM per switch in a LAN. However, our design will benefit from definition of standard interface for accessing routing (spanning tree) informa- tion available at switches and other 802.3 medium attachment units. We also hope the draft to be a starting point of discussion between IETF and IEEE 802.1P/Q subcommittee(s) to identify Level 2 mechan- isms that will help in implementation of integrated-services capa- bilities over Ethernets. In particular, per-flow traffic shaping and scheduling mechanisms might be necessary in both end-systems and Ethernet switches to provide guarantees on end-to-end delays and such mechanisms should be investigated further. Acknowledgements The authors wish to thank John Flick of HP for explanation of the "Topology Mapping" section of the hub MIB specification. 5. References [1] R Braden, L Zhang, S Berson, S Herzog, J Wroclaswki, "Resource Reservation Protocol", Internet Draft draft-ietf-rsvp- spec12.txt,May 1996. [2] S.Shenker, "Specification of General Characterization Parame- ters", draft-ietf-intserv-charac-00.txt,Nov 1995 [3] D Romascanu, "Definitions of Managed Objects for IEEE 802.3 Repeater Devices", draft-ietf-hubmib-repeater-dev-03.txt, Sept. 1996. 6. Authors` Addresses Raj Yavatkar Intel Corporation MS : JF2-74 draft-yavatkar-sbm-ethernet-01.txt [Page 13] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996 2111 N.E. 25th Avenue, Hillsboro, OR 97124 USA phone: +1 503-264-9077 email: yavatkar@ibeam.intel.com Don Hoffman Sun Microsystems, Inc. MS: UMPK14-305 2550 Garcia Avenue Mountain View, California 94043-1100 USA phone: +1 503-297-1580 email: don.hoffman@eng.sun.com Yoram Bernet Microsoft 1 Microsoft Way Redmond, WA 98052 phone: +1 206 936 9568 email: yoramb@microsoft.com Ema Patki Intel Corporation MS: JF2-74 2111 N.E. 25th Avenue, Hillsboro, OR 97124 USA phone: +1 503-264-0440 email: epatki@ibeam.intel.com draft-yavatkar-sbm-ethernet-01.txt [Page 14]