Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-yavatkar-sbm-ethernet-02.txt < prev next >

Wrap

Text File | 1996-11-26 | 41.0 KB | 1,140 lines

Internet Engineering Task Force Raj Yavatkar, Intel INTERNET-DRAFT Don Hoffman, Sun Microsystems Yoram Bernet, Microsoft December 1996 Expires: June 30, 1997 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). Changes From Last Version This draft reflects the following changes to its previous version: 1. SBM now accepts and processes the RSVP PATH messages. A PATH mes- sage sent over a LAN now contains LAN_NHOP and LAN_PHOP objects. Section 2.2 describes changes to the RSVP operation. 2. Message encapsulation rules and message formats are added. 3. A section that describes the SBM operation over different LAN topo- logies has been added. draft-yavatkar-sbm-ethernet-02.txt [Page 1] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 Abstract This document outlines an architecture for RSVP-based admission control over IEEE 802-style LANs. The proposed architecture is designed to work with the current generation of IEEE 802 LANs and should be considered as a first step towards discovering solutions for implementation of IntServ capabilities over such networks. draft-yavatkar-sbm-ethernet-02.txt [Page 2] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 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 pro- posed integrated services over specific link-layer technologies such as the IEEE 802-style LANs. Our goal is to propose an archi- tecture for achieving admission control over the 802-style networks such as Ethernet on the basis of the framework proposed in the RSVP and Int-Serv working groups. Our proposal is based on the follow- ing architectural goals and assumptions: I. We define an architecture that provides a step-by-step solution to the problem of managing bandwidth over shared subnetworks (such as an Ethernet) that works with the existing, legacy LAN infrastruc- ture and takes advantage of the additional functionality (such as an explicit support for integrated services) as it becomes avail- able in the new generation of switches, hubs, or bridges. As a result, our architecture would allow for a range of LAN bandwidth management solutions that vary from one that exercises purely administrative control (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, one needs to define mechanisms for admission control, traffic flow separation, and traffic scheduling (the latter two are usually grouped together under "traffic control"). For instance, an effec- tive admission control mechanism for shared subnetworks requires managing and controlling bandwidth usage so that the aggregate traffic load on any shared segment does not exceed its capacity. This requires controlling the amount of traffic generated by both RSVP-enabled and non-RSVP traffic flows. Additional link level mechanisms for traffic flow separation and traffic control may be necessary to achieve the goal. Appendix A elaborates further on the traffic control mechanisms necessary for this purpose. In the short term, our goal is to specify only a signaling method and protocol for LAN-based admission control over RSVP flows and leave the task of specifying link layer mechanisms for traffic con- trol to the appropriate IEEE 802 working groups. Thus, the proposed mechanism explicitly controls only the total draft-yavatkar-sbm-ethernet-02.txt [Page 3] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 amount of traffic load imposed by RSVP-enabled flows on a shared LAN. However, the best-effort traffic generated by the TCP/IP sources is generally rate-adaptive (using "slow start" type conges- tion avoidance mechanisms or feedback-based rate adaptation used by sources based on RTP/RTCP protocols) and limits the amount of traffic generated to adapt to available capacity. A specification of an RSVP-based admission control mechanism for a LAN should typi- cally suffice to control the total amount of traffic 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 priority to the RSVP traffic (to separate it from best-effort traffic) coupled with a combination of admission control (over RSVP traffic to keep it within a fraction of any link's capacity) and per-flow policing at end-systems should suffice to realize an approximation to the "con- trolled load" service specified in the int-serv working group. III. For traffic control, we assume that end-systems will police indivi- dual RSVP-enabled data 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. IV. As an interim measure until 802-mediated traffic control mechanisms become available, we assume that all the RSVP nodes on a LAN will utilize the proposed 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 multimedia traffic on a LAN is sent using RSVP for resource reservation, the proposed architecture would restrict the total multimedia traffic on any LAN segment within the bounds desired by a LAN administrator. This does not, however, assure that non-RSVP traffic will not interfere with the RSVP traffic. Appendix A.1 discusses this approach in more detail. 2. Overview Our architecture is based on a logical entity called an SBM (Subnet Bandwidth Manager) responsible for handling admission control requests. We assume that an IP subnet corresponds to a single L2 (Layer 2) domain [3]. An L2 domain is defined to be a set of nodes and links intercon- nected without passing through a L3 (IP or Layer 3) forwarding function. We refer to links (point-to-point or shared segments) that interconnect nodes within a L2 domain simply as LAN segments. We assume that a Desig- nated SBM (DSBM) exists for each LAN segment (also called a Managed draft-yavatkar-sbm-ethernet-02.txt [Page 4] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 Segment or a MS) and services reservation requests (manages bandwidth) for that segment. An SBM is an application-level entity that uses UDP for communication with its clients. The architecture makes no assump- tions about the number of SBMs within a LAN; a single DSBM may manage a shared LAN segment whereas a separate SBM may run on each switch in a switched LAN topology (Section 3 discusses this point in greater detail). In the following, we use the term "SBM client" to refer to an entity (host or router) that communicates with a DSBM for the purpose of establishing a QoS reservation. 2.1 Basic Algorithm Figure 1 - An Example of a Managed Segment. Host Host _______ === ------- === | | | C | | SBM | | B | | Router| | | - /---- | | |_R2____| === / === | | / | | | / | ==============================================================LAN | | | | === __|_____ | A | | Router | | | | R1 | === |________| Host Figure 1 shows an example topology consisting of 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. Section 3 describes how an SBM operates over different LAN topologies. The basic SBM algorithm works as follows: 1. DSBM Initialization: As part of its initial configuration, DSBM obtains information such as the 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. 2 SBM Client Initialization: At the start, an SBM client discovers and binds to its DSBM using a "DSBM Discovery Protocol" (described draft-yavatkar-sbm-ethernet-02.txt [Page 5] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 in section 2.3). 3. RSVP-based Admission Control: To reserve LAN bandwidth, RSVP nodes (RSVP-capable hosts and routers) follow the following steps: a) When an RSVP node sends or forwards a PATH message over a LAN interface, it unicasts the PATH message to its DSBM instead of sending it to the destination address (as is done in conventional RSVP processing). After processing (and possibly updating an ADSPEC), the DSBM will forward the PATH message toward its desti- nation address (See Section 3 for the case involving multiple Layer 2 hops between a sender and a destination). As part of its processing, the DSBM builds and maintains a path state for the session and notes the previous hop that sent it the PATH message. 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 its DSBM (the DSBM's unicast address) and the DSBM will eventually send the PATH mes- sage to the RSVP session address. In the process, the DSBM builds the PATH state, remembers the sender (router R1 in Figure 1) as the previous hop for the session, and effectively inserts itself as an intermediate node between the sender (or R1 in Figure 1) and the receivers (or routers) on the LAN. b) When a receiver (say, host A) wishes to make a reservation request for the session, it follows standard RSVP rules and sends a RSVP RESERVE message to the previous hop address obtained from the PHOP object in the previously received PATH message. 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. Admission control algorithm at DSBM ensures that sufficient bandwidth is available on managed segments (MS) between the NHOP (requester) and the PHOP (sender/router). In case of a successful reservation, DSBM forwards the RESERVE message towards the PHOP(s) based on the contents of the RESERVE message and its local path state for the session. 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 (sender/router) on that MS if all reservation requests within the MS succeed. draft-yavatkar-sbm-ethernet-02.txt [Page 6] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 2.2 Changes to conventional RSVP operation The addition of an SBM for admission control over Ethernet results in the following changes to the RSVP operation on an Ethernet: - Outgoing PATH messages on an Ethernet interface are unicast to the DSBM. - In conventional RSVP processing over point-to-point links, RSVP nodes (hosts/routers) use NHOP and PHOP objects to keep track of the next hop (and the previous hop) nodes on the path between a sender and a receiver. Over a shared LAN such as an Ethernet, we introduce an SBM (subnet Bandwidth Manager) as a logical entity that performs admission control over the LAN. Such a LAN may span multiple switched or shared segments between a RSVP PHOP node and a RSVP NHOP node. For the purpose of Layer 3 routing and RSVP seman- tics between two Layer 3 entities, however, the entire LAN acts a logical segment and the connection between RSVP PHOP and NHOP nodes must be maintained for the correct operation and routing of RSVP messages. Therefore, we introduce two new RSVP objects called LAN_PHOP and LAN_NHOP that keep track of the peer RSVP nodes on a path between a RSVP sender (or a previous hop router) and a RSVP receiver (or a next hop router). When an RSVP entity (a host or a router acting as the originator of a PATH message) sends out a PATH message over an Ethernet inter- face, it needs to include both LAN_NHOP and LAN_PHOP objects in the message as described below. When a DSBM receives a PATH message it passes on LAN_PHOP and LAN_NHOP objects unchanged and only modifies PHOP and NHOP (i.e., RSVP_HOP) objects in those messages. Thus, when an RSVP node finally receives the PATH message, it has the necessary information about RSVP peer-to-peer association (and, therefore, the layer 3 routing information) through the contents of the LAN_PHOP and LAN_NHOP objects. When sending out a PATH message over an Ethernet interface, first RSVP node (sender or an edge router forwarding the PATH message) must include two new objects, namely, a LAN_NHOP object and a LAN_PHOP object. The LAN_NHOP object specifies the destination IP address of the PATH message. In case of a unicast destination, the LAN_NHOP address specifies the destination address or the address of the next hop router towards the destination. The LAN_PHOP object in the PATH message specifies the IP address of the RSVP node (sender or forwarding router) that originated the PATH message on the LAN. - When an SBM receives a RSVP PATH message, it processes it according draft-yavatkar-sbm-ethernet-02.txt [Page 7] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 to the PATH processing rules described in the RSVP specification. In particular, it remembers the PHOP address from which it received the messages and forwards the path message with the PHOP object modified to reflect its IP address. LAN_PHOP and LAN_NHOP objects in the PATH message are passed along unchanged. - The path state in SBM is used for forwarding subsequent RESV mes- sages for the same session. When an SBM receives a RESV message, it processes the message and forwards it to appropriate PHOP(s) based on its path state. - Because a DSBM inserts itself as a hop between a source of traffic on the LAN (sender or router) and the receiver, all RSVP related messages (such as PATH, PATH_TEAR, RESV, RESV_CONFM, RESV_TEAR, and RESV_ERR) now flow through the DSBM. - When RSVP session address is a multicast address, it is possible for a router that originated a PATH message to receive one or more copies of the PATH message when a DSBM on the path to the destina- tion forwards it (i.e., multicasts it). However, the router can detect and discard the duplicates either based on the contents of the LAN_PHOP object (lists one of its interface addresses) or based on who forwarded it (any PATH message coming from a SBM other than its own DSBM). 2.3 Discovering and Binding to a DSBM DSBM listens to a well-known SBM multicast address (SBM_GRP - an UDP multicast address with a local scope -- of the form, <224.0.0.x, port XXXX>, TBD) and an SBM client locates its DSBM by multicasting a LOCATE_SBM request to the SBM_GRP address with a restricted multicast scope (multicast TTL=1). DSBM replies to the client's query and provides its unicast address for further communication. After the initial handshake between the DSBM and an SBM client, the SBM client is con- sidered bound to its DSBM and SBM client uses DSBM's unicast address for subsequent communication. To allow recovery from DSBM failures and binding to a newly elected DSBM, the SBM client must listen to the subsequent, periodic I_AM_DSBM refresh messages from its DSBM to detect the DSBM failure. These refresh draft-yavatkar-sbm-ethernet-02.txt [Page 8] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 messages (or "DSBM advertisements") are sent to the SBM_GRP address every refresh interval (e.g., every 30 seconds; the refresh interval is a configuration parameter). The client must repeat the binding pro- cedure if original DSBM fails (or is replaced by another one). 2.4 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 for the segment 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 election algorithm works as follows: When a SBM comes up on an IP subnet, it must first discover whether a DSBM already exists on the sub- net. It does so by listening for incoming I_AM_DSBM messages for a ran- dom amount of time. If no other DSBM is present, it announces its wil- lingness to be a DSBM by periodically multicasting a DSBM WILLING mes- sage to the SBM_GRP address with the 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 candidate 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 (K >= 3) 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 (K >= 3) successive periodic announcements. In that case, all the SBMs ini- tiate the election algorithm to elect a new DSBM. 3. Various LAN Topologies Our goal is to offer an admission control solution that works with the existing, shared segments LANs as well as newer, switched LAN topolo- gies. In the following, we consider three different LAN topologies and describe how our solution works in each case. 3.1 Shared LAN segments Figure 1 shows a sample topology where entire IP subnet spans a single draft-yavatkar-sbm-ethernet-02.txt [Page 9] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 shared segment. Actual physical topology in this case may consist of multiple physical segments interconnected by hubs. However, for practi- cal purposes, such a LAN acts as if all hosts are attached to a single shared segment. In this case, a single DSBM manages shared bandwidth for the entire subnet. 3.2 Switched LAN segments Figure 2 shows a sample topology where an IP subnet spans a switched Ethernet consisting of one or more switches interconnecting all the end-systems within the subnet. In this case, we assume that one SBM resides at each switch, the DSBM is responsible for managing outgoing interfaces at the switch, and that the DSBM accesses its switch's local MAC address table to discern forwarding information. In this case, PATH and RESV messages between two end-systems on the sub- net will propagate hop-by-hop from one DSBM to another DSBM as they travel across the switches along the path. For example, let us assume a unicast RSVP session addressed to host D in Figure 2. Let us also assume that the sender in the session resides out- side the LAN shown in Figure 2 and the router R1 forwards a PATH message towards its receiver on the LAN. When a PATH message for the session arrives at R1, the following sequence of events will happen: 1. R1 forwards the PATH message to its DSBM (B1 in Figure 2). 2. B1 processes the PATH message, builds the path state, and then for- wards the PATH message to the next DSBM on the path towards the LAN_NHOP address (forwarding information discerned from the MAC address table). In the case of a LAN with multiple hops (segments) between an RSVP sender (LAN_PHOP) and a destination (LAN_NHOP), the DSBMs forward the PATH message hop-by-hop until it reaches a managed segment where the destination resides. At that point, the DSBM for the managed segment will send the PATH message directly to the destina- tion. In the case of a multicast destination where many receivers are scattered across a LAN, the DSBM at each intermediate hop must for- ward the PATH message to the session destination address for all outgoing interfaces where group members reside. We assume that the DSBM has access to a switch's local MAC address table to discern draft-yavatkar-sbm-ethernet-02.txt [Page 10] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 such forwarding information. 3. B2 will then process the PATH message and forward it to the LAN_NHOP address. 4. When the host D decides to make a reservation for the session, it looks up its path state to determine the previous hop(s) for the session and sends the RSVP RESV message to its PHOP (B2). If the admission control at B2 succeeds, it will forward the RESV message to the PHOP (B1) according to its path state, and finally, the RSVP RESV message will arrive at R1 if admission control at intermediate switches succeeds. 5. Any admission control failure results in a RESV_ERROR being sent to the requester and the RESV state at intermediate nodes is removed. Figure 2 - An example of a switched topology --------- | Router | | R1 | |_________| / / / ++++++ Switch + B1 + S1 + + ++++++ / |__ / | / | ++++++ ++++++ switch + B2 + + B3 + switch S2 + + + + S3 ++++++ ++++++ / |__ |_____ / | | / | | Host Host Host === ==== === | D | | E | | F | | | | | | | === === === draft-yavatkar-sbm-ethernet-02.txt [Page 11] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 3.3 Combination of Shared and Switched segments (heterogeneous case) Previous two cases represent two popular topologies (shared segment topology is popular among legacy LANs and switched topology is popular with the newer installations). However, we must also consider a more general case when an IP subnet spans a combination of shared and switched segments. In this case, we still assume that a DSBM exists at each switch. However, the DSBM at a switch is not only responsible for managing bandwidth across its incident point-to-point links to its peers, but also manages shared segments that are incident to it. When more than one switch is attached to a shared segment, the DSBM will determine the directly attached segments that it manages >From the con- figuration information supplied at the startup time. Shared segments (and any non-SBM switches attached to them) are treated as a single log- ical segment for the purpose of admission control. When a RESV request arrives at the DSBM, it will perform admission control over all the managed segments under its domain that are affected by the RESV message before forwarding the RESV towards the previous hop address. 4. Layer 2 Support Issues When an SBM resides on a switch, we assume that it has access to the local MAC address table so that it can discern the information necessary for forwarding PATH and RESV messages to their respective LAN_NHOP and LAN_PHOP addresses. An accompanying document [3] describes the require- ments for mapping IP Integrated Services over IEEE 802 traffic control mechanisms. 5. Message Encapsulation and Formats To minimize changes to existing RSVP implementations and to ensure quick deployment of an SBM in conjunction with RSVP, all communication to and from a DSBM will be performed using messages constructed using the current rules for RSVP message formats. For more details on the RSVP message formats, refer to the RSVP specification (draft-ietf-rsvp-spec- 14.ps). No changes to the RSVP message formats are proposed, but new message types and new LAN_NHOP and LAN_PHOP objects are added to the RSVP message formats to accommodate DSBM-related messages. These addi- tions are described below. All messages to a DSBM (except messages related to DSBM discovery and advertizements) are addressed to the DSBM's unicast address. In partic- ular, all RSVP-related messages (PATH, RESV, and other TEAR and ERROR messages) directed to a DSBM are sent to the DSBM's unicast address. An RSVP node discovers its DSBM (and DSBM's unicast address) using a discovery method described in Section 2.3 earlier. draft-yavatkar-sbm-ethernet-02.txt [Page 12] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 Each message must occupy exactly one IP datagram. If it exceeds the MTU, such a datagram will be fragmented by IP and reassembled at the reci- pient node. This has a consequence that a single message may not exceed the maximum IP datagram size, approximately 64K bytes. 5.1. RSVP-related Message Formats All RSVP messages directed to and from a DSBM may contain various RSVP objects defined in the RSVP specification and messages continue to fol- low the formatting rules specified in the RSVP specification. In addi- tion, an RSVP implementation must also recognize two new object classes, LAN_NHOP and LAN_PHOP, that are described below. 5.2 LAN_NHOP and LAN_PHOP Objects Both LAN_NHOP and LAN_PHOP objects have the same structure as the RSVP_HOP object, but are identified as separate object classes to dis- tinguish them from each other and from the RSVP_HOP objects. LAN_NHOP objects use object class = 40; IPv4 LAN_NHOP object uses <Class=40, C-Type=1> and IPv6 LAN_NHOP object uses <Class=40, C-Type=2>. IPv4 LAN_NHOP object: class = 40, C-Type =1 +---------------+---------------+---------------+---------------+ | IPv4 Next Hop Address | +---------------+---------------+---------------+---------------+ | Logical Interface Handle | +---------------+---------------+---------------+---------------+ IPv6 LAN_NHOP object: Class = 40, C-Type = 2 +---------------+---------------+---------------+---------------+ | | + + | | + IPv6 next Hop Address + | | + + | | +---------------+---------------+---------------+---------------+ | Logical Interface Handle | +---------------+---------------+---------------+---------------+ LAN_PHOP objects use class=41; IPv4 LAN_PHOP and IPv6 LAN_PHOP objects use C-Types 1 and 2 respectively. These objects are structured same as those shown above. draft-yavatkar-sbm-ethernet-02.txt [Page 13] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 5.3 RSVP PATH Message Format As specified in the RSVP specification, an RSVP_PATH message contains the RSVP Common Header and the relevant RSVP objects. For the RSVP Com- mon Header, refer to the RSVP specification (draft-ietf-rsvp-spec- 14.ps). Changes to an RSVP_PATH message include addition of the LAN_NHOP and the LAN_PHOP objects as specified below. <RSVP_PATH> ::= <RSVP Common Header> [INTEGRITY>] <LAN_PHOP> <LAN_NHOP> <SESSION><RSVP_HOP><TIME_VALUES> [<POLICY DATA>] <sender descriptor> If the INTEGRITY object is present, it must immediately follow the RSVP common header. LAN_NHOP object must always precede the SESSION object. 5.4 RSVP RESV Message Format As specified in the RSVP specification, an RSVP_RESV message contains the RSVP Common Header and relevant RSVP objects. No Changes to the RESV message format are needed with the SBM protocol. 5.5. Additional RSVP message types to handle SBM interactions New RSVP message types are introduced to allow interactions between a DSBM and an RSVP node (host/router) for the purpose of discovering and binding to a DSBM. New RSVP message types needed are as follows: RSVP Msg Type (8 bits) Value SBM_QUERY 64 SBM_REPLY 65 DSBM_WILLING 66 I_AM_DSBM 67 All SBM-specific messages are formatted as RSVP messages with an RSVP common header followed by SBM-specific objects. <SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects> where <SBMP common header> ::= <RSVP common Header> [<INTEGRITY>] For each SBM message type, there is a set of rules for the permissible choice of object types. These rules are specified using Backus-Naur Form (BNF) augmented with square brackets surrounding optional sub-sequences. The BNF implies an order for the objects in a message. However, in many draft-yavatkar-sbm-ethernet-02.txt [Page 14] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 (but not all) cases, object order makes no logical difference. An imple- mentation should create messages with the objects in the order shown here, but accept the objects in any permissible order. Any exceptions to this rule will be pointed out in the specific message formats. 5.5.1 SBM_QUERY Message SBM_QUERY message contains a single address object in the format that is same as the RSVP SESSION object and gives the IP address of the request- ing node. The SBM_QUERY message is multicast to the well known DSBM_GROUP address as described earlier. <SBM_QUERY message> ::= <SBMP common header> <IP address> where <IP address> object is same as the <SESSION> object. 5.5.2 SBM_REPLY Message SBM_REPLY message provides the IP address of the node sending out the reply. <SBM_REPLY Message> ::= <SBM Common Header> <IP ADDRESS> The SBM_REPLY message is unicast to the sender of the SBM_QUERY message . 5.5.3 DSBM_WILLING Message <DSBM_WILLING message> ::= <SBM Common Header> <IP ADDRESS> IP ADDRESS is the address of the DSBM sending out this message. All DSBM_WILLING messages are multicast to the well known DSBM_GROUP address. 5.5.4 I_AM_DSBM Message <I_AM_DSBM> ::= <SBM Common Header> <IP ADDRESS> [<PRIORITY>] IP ADDRESS is the address of the DSBM sending out this message. All I_AM_DSBM messages are multicast to the well known DSBM_GROUP address. The optional PRIORITY object specifies the relative priority of the requesting SBM. When multiple, redundant SBMs are present on a LAN, a priority level is assigned to each one of them by a network administra- tor and is used to break ties when multiple candidate DSBMs participate in the DSBM election algorithm. The default priority of an SBM is 1 and higher priority values represent higher precedence. PRIORITY Object: class = 42, C-Type =1 draft-yavatkar-sbm-ethernet-02.txt [Page 15] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 +---------------+---------------+---------------+---------------+ | //// | //// | //// | priority | +---------------+---------------+---------------+---------------+ 6. 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 Parameters", draft-ietf-intserv-charac-00.txt,Nov 1995 [3] D.Hoffman, "Integrated Services/RSVP Requirements for Layer 2 Traffic Control", draft-hoffman-issll-l2tcreq-00.txt, December 1996. [4] Y.Bernet, "Admission Control for Best-Effort Traffic", in prepara- tion. draft-yavatkar-sbm-ethernet-02.txt [Page 16] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 APPENDIX A Traffic Control Issues on a LAN A.1 Application Behavior Because of its goal to support existing 802 infrastructures, this propo- sal makes no assumptions about any traffic separation or policing mechanisms on the MS. Consequently, there are no network enforced mechanisms to keep non-adaptive traffic from interfering with the traffic over reserved flows. In these sorts of environments we propose that applications are expected to be well behaved and follow the follow- ing set of rules: - 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 outgoing flow should be pol- iced at the sender host 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 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 drop- ping all senders, even those with the fully reserved paths. Appli- cations running in such environments should restrict sessions to a single sender if at all possible. A.2 Traffic Control Mechanisms in Layer 2 An effective admission control mechanism for shared subnetworks requires managing and controlling bandwidth usage so that the aggregate traffic load on any shared segment does not exceed its capacity. This requires controlling the amount of traffic generated by both RSVP-enabled and best-effort traffic flows. We do not assume any particular explicit support for integrated ser- vices is assumed from the LAN infrastructure (NICs, switches, hubs, or bridges) and assume that an appropriate IEEE 802 working group will specify the traffic control solutions for the link-level devices (an accompanying document [3] provides recommendations to the IEEE 802.1 committee on the Layer 2 facilities needed to facilitate mapping of int-serv services over Ethernet). draft-yavatkar-sbm-ethernet-02.txt [Page 17] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 In the absence of any layer 2 support, some topologies such as a shared Ethernet segment may pose a problem when unrestricted best-effort traffic can interfere with the traffic from RSVP-enabled traffic. Therefore, an explicit end-system based control over the amount of best-effort traffic that can be sent over Ethernet may be necessary to implement a particular service class. Further investigation and experi- mentation is necessary in this area [4]. ACKNOWLEDGEMENTS Many thanks to Ema Patki for her active participation with the earlier versions of this draft. Authors are also thankful to Fred Baker of Cisco Systems and John ("JJ") Krawczyk of Bay Networks for their constructive comments on the SBM design and the earlier versions of this draft. 6. Authors` Addresses Raj Yavatkar Intel Corporation MS: JF3-206 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 USA phone: +1 206 936 9568 email: yoramb@microsoft.com draft-yavatkar-sbm-ethernet-02.txt [Page 18] INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996 draft-yavatkar-sbm-ethernet-02.txt [Page 19]