HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 09:39:19 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Sat, 02 Mar 1996 14:13:38 GMT ETag: "361da3-402a-31385792" Accept-Ranges: bytes Content-Length: 16426 Connection: close Content-Type: text/plain INTERNET DRAFT Int-Serv & L2 Frame Switching February 1996 INTERNET DRAFT John J. Krawczyk draft-krawczyk-intserv-l2-switch-00.txt Bay Networks, Inc. February 21, 1996 Expires: August, 1996 Providing Integrated Services in the Presence of Layer-2 Frame Switching Devices 1. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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). 2. Abstract The presence of Layer-2 (L2) frame switching devices, such as ethernet and token-ring switches, as well as Frame Relay [FR1990], creates problems in delivering the end-to-end behavior as defined by the service models being developed by the Integrated Services Working Group [Guar95] [CL95] [Pred95] [CD95]. Resource reservation protocols (RSVP [RSVP96], ST2 [RFC1190], and ST2+ [RFC1819]) are used to signal the required Quality of Service (QoS) to the router nodes along the paths JJ Krawczyk Expires August 1996 [Page 1] INTERNET DRAFT Int-Serv & L2 Frame Switching February 1996 (or trees in the multicast case) from sender(s) to receiver(s). The hosts and routers are required to act as proxies for their attached media and, consequently, any L2 devices attached to that media. Unfortunately, most of these L2 devices do not have the ability to participate in the activities required to achieve the new service models. L2 frame switches are growing in popularity and are the "last hop" for many IP end-systems. While it is not proper for the IETF to provide L2 solutions, the presence of such popular devices needs to be taken into account as the Integrated Services architecture is developed. The L2 requirements must be articulated to the organizations that can or are in the process of trying to solve these problems. In some cases, it may be necessary to invent mechanisms to work around the deficiencies of the L2 devices. This memo briefly talks about the popularity of L2 frame switches and examines the problems with providing Integrated Services when these devices are present. Some current activities aimed at solving the problems are presented. The memo concludes with suggestions as to how the Integrated Services working group should proceed to hasten these solutions. JJ Krawczyk Expires August 1996 [Page 2] INTERNET DRAFT Int-Serv & L2 Frame Switching February 1996 3. Introduction This memo is a first attempt to generate discussion and activity regarding Integrated Services and layer-2 frame switching devices (and only L2 frame switching devices). It is definitely not a complete document at this time. 4. Popularity of L2 Frame Switches Ethernet and token-ring switches are being used as an alternative to shared media. The main reason for this is to provide increased bandwidth per user. While routers can functionally provide the same result, both the cost and management complexity of the L2 frame switches are less. The forwarding performance of the L2 frame switches is also a lure. Frame Relay offers an inexpensive WAN transport with burst capability, link management and congestion control. It is standards based, conceptually simple, and has quickly established itself around the world as a flexible WAN solution. In response to users' needs, the Frame Relay Forum is continually issuing new implementation agreements to enrich the protocol's feature set. 5. The Problems In a nutshell, in order to achieve end-to-end service in networks with L2 frame switches, the switches have to implement the same functions as the routers: signalling, admission control, classification, policing, and link scheduling (note that this does not imply that the switches have to implement the exact same protocols/mechanisms as the routers to achieve this; e.g., a switch does not have to use RSVP for signalling). L2 LAN switches currently do not participate in any of these activities. In the WAN realm, Frame Relay does provide these functions. The major drawback is that the signalling does not allow for any characterization of delay. It does allow the specification of Committed Information Rate (CIR) for a JJ Krawczyk Expires August 1996 [Page 3] INTERNET DRAFT Int-Serv & L2 Frame Switching February 1996 Virtual Circuit (VC) via a time interval (Tc) and the number of "committed" bytes allowed during the interval (Bc). Additionally, burst rates are handled by specifying the number of "excess" bytes allowed during the interval (Be). The CIR is the rate that is "guaranteed" to be delivered without drops (this "guarantee" is usually qualified by the carrier with a percentage that is close to 100). When the rate exceeds CIR but the burst is within Be for the interval, the excess packets are marked Discard Eligible (DE) and will only be dropped due to congestion. When a burst exceeds Be, all excess packets are dropped. An end system also has the option of marking packets DE; these are not counted against the "guarantee". In terms of realizing the service models with today's equipment and without the addition of any "adaptation protocols" (see the Conclusions section), any model that requires the advertisement of delay information cannot be supported. That leaves Controlled-Load. If an L2 network is sufficiently over-provisioned and rarely experiences congestion, an adequate Controlled-Load service will be possible. Frame Relay can reasonably support Controlled-Load even in the presence of congestion. The CIR parameters for a VC can be used to emulate a constant-bit-rate pipe. One or more Controlled-Load flows can be scheduled into the VC as long as the sum of the token bucket rates is less than the CIR. Otherwise, crossing a frame switched subnet is analogous to encountering an IP router that does not participate in the service model. 6. Current Work The following sub-sections describe some of the current efforts to provide QoS support in L2 frame switches. This list is definitely not complete. JJ Krawczyk Expires August 1996 [Page 4] INTERNET DRAFT Int-Serv & L2 Frame Switching February 1996 6.1. 802.1D Extensions [802.1p] is a draft standard that describes extensions to 802.1D that would add the concepts of Traffic Class and Dynamic Multicast Filtering. Here, we are only concerned with the former (although the latter is a very important topic). Note that [802.1p] is definitely in "draft" stage and any comments here apply to the state of the document as of this writing. The draft describes a means of classifying frames for insertion into priority queues for transmission. While the "user_priority" for a frame has eight possible values, the recommendation is to map this to two queues: one for what is termed "time and safety critical traffic" and "time critical traffic"; the other for "non-time critical traffic". The queues are serviced in a pure priority fashion; i.e., the non-time critical queue will not be serviced unless the time- critical queue is empty. "The provision of guaranteed QoS levels for expedited traffic classes" is an explicitly stated non-goal. The user_priority of a frame can be carried in the frame itself (with the exception of CSMA/CD) or can be learned via classification, which involves a lookup in the "filtering database". Classification can be performed on the source and destination MAC addresses. The filtering database can be modified either through management or via the Group Address Registration Protocol (GARP). The latter method allows a receiving end-station to assign a user_priority to a particular multicast MAC address. To summarize, the current state of [802.1p] only somewhat addresses classification and link-scheduling and, to a much lesser extent, signalling. The weaknesses of the current approach are: Suboptimal signalling. Except for the GARP hook, the filtering database must be modified via "management". No admission control. Limiting classification to source and destination MAC addresses. This restriction would force end-stations to JJ Krawczyk Expires August 1996 [Page 5] INTERNET DRAFT Int-Serv & L2 Frame Switching February 1996 use separate MAC addresses for each flow that needed to be isolated. This may be an acceptable solution, since we probably don't want to be peeking into the layer 3 information. Allowing a sender to set its user_priority may be a problem. No policing on entry into the time-critical queue. The non-time-critical queue will never be serviced if time- critical traffic arrives at the outbound port's rate. No link scheduling support that can realize a guaranteed service. 6.2. Mother-May-I Protocols The term "Mother-May-I Protocol" has been floating around for some time to describe a protocol that would provide signalling and admission control functions over shared and segmented LANs. [AC-LAN] describes just such a protocol. Using this approach, one or more "Rservers" are responsible for admission control on one or more segments of a LAN. When the admission control element on a router or host needs to allocate bandwidth on the LAN, it must first interact with its Rserver to see if the resources are available on the LAN segments carrying the flow. If not, the router or host must refuse the reservation request. The Rserver function is separate from any of the router, host, or LAN devices, although nothing in the design prohibits it from being implemented there. The Rserver does not attempt to influence classification, policing, or link scheduling on any of the affected nodes in the LAN. 7. Conclusions The Integrated Services Working Group needs to take a proactive role in resolving these problems. In particular, a dialog with 802.1 is necessary to make known the needs of the int-serv service models. A dialog with the Frame Relay Forum JJ Krawczyk Expires August 1996 [Page 6] INTERNET DRAFT Int-Serv & L2 Frame Switching February 1996 is necessary to discuss the need for delay characterization. A revised version of this document can be the starting point for these dialogs. In order to implement integrated services in a more timely fashion, or in case it becomes impossible to resolve certain issues in the L2 space, the Integrated Services Working Group can develop mechanisms and "adaptation protocols" as work- arounds. [AC-LAN] is an example. Another possibility is to develop a protocol to measure delays across a Frame Relay VC in order to support models other than Controlled-Load. The authors of [AC-LAN] have indicated that they will be submitting an Internet Draft describing the Rserver architecture, so it will be possible to continue this work within the IETF. In the meantime, in order to deploy integrated services, the following suggestions are made: Controlled-Load over L2 LAN switches can be reduced to the problem of Controlled-Load over routers that do not implement the service, if the end-systems requesting the service are made aware of this fact (i.e., the service will be acceptable if and only if the L2 switched subnet is not experiencing congestion). To achieve this, RSVP should set the "non-RSVP" flag in the SESSION object of the PATH message if a router knows that the last or previous hop was reached via a frame switched LAN. Controlled-Load can be implemented over Frame Relay using the mechanism described previously in this document. 8. Security Considerations Security considerations are not discussed in this memo. 9. References [Guar95] S. Shenker, C. Partridge. "Specification of Guaranteed Quality of Service", Internet Draft, December 1995, JJ Krawczyk Expires August 1996 [Page 7] INTERNET DRAFT Int-Serv & L2 Frame Switching February 1996 [CL95] J. Wroclawski. "Specification of Controlled-Load Network Element Service", Internet Draft, November 1995, [Pred95] S. Shenker, C. Partridge, B. Davie, and L. Breslau. "Specification of Predictive Quality of Service", Internet Draft, ?? 1995, [CD95] S. Shenker, C. Partridge, J. Wroclawski. "Specification of Controlled Delay Quality of Service", Internet Draft, November 1995, [RSVP96] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", Internet Draft, February 1996, [RFC1190] C. Topolcic. "Experimental Internet Stream Protocol, Version 2 (ST-II)", Internet Working Group Request for Comments 1213. Network Information Center, SRI International, Menlo Park, California, October 1990. [RFC1819] L. Delgrossi, L. Berger. "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", Internet Working Group Request for Comments 1213. Network Information Center, SRI International, Menlo Park, California, August 1995. [FR1990] "Integrated Services Digital Network (ISDN) - Architectural Framework and Service Description for Frame- Relaying Bearer Service", ANSI Standard T1.606, 1990. [802.1p] Interworking Task Group of IEEE 802.1. "Draft Standard for Traffic Class and Dynamic Multicast Filter Services in Bridged Local Area Networks (Draft Supplement to 802.1D)", P802.1p/D1, November, 1995. [AC-LAN] E Patki, R. Yavatkar. "A Design for Admission Control in a LAN Environment", Intel Corporation, February, 1996. JJ Krawczyk Expires August 1996 [Page 8] INTERNET DRAFT Int-Serv & L2 Frame Switching February 1996 10. Author's Address John J. Krawczyk Bay Networks, Inc. 2 Federal Street Billerica, MA 01821 jj@baynetworks.com JJ Krawczyk Expires August 1996 [Page 9]