RFC 2815

Integrated Service Mappings on IEEE 802 Networks

📅 published May 2000, from ietf

Part 1 of 5 🎀

RFC 2815: Integrated Service Mappings on IEEE 802 Networks 💖

Okay so, the title block first, because it's the vibe check 🫶

  • Who wrote it: M. Seaman (Telseon), A. Smith (Extreme Networks), E. Crawley (Unisphere Solutions), and J. Wroclawski (MIT LCS) ✨
  • Category: Standards Track 🦋
  • Date: May 2000 🌸
  • Obsoletes / Updates: the title block doesn't list any RFCs it obsoletes or updates 🧚

Status of this Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💅 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 💜

This document is all about mapping IETF Integrated Services over LANs built from IEEE 802 network segments, which can be connected together by IEEE 802.1D MAC Bridges (switches) 🍓 It describes parameter mappings that support Controlled Load and Guaranteed Service. It does this using the built-in abilities of relevant IEEE 802 technologies, especially the 802.1D-1998 queuing features in switches. Lowkey iconic 👑

These mappings are one piece of the Integrated Services over IEEE 802 LANs framework 🧚

Table of Contents 🦋

1 Introduction ............................................... 2
2 Flow Identification and Traffic Class Selection ............ 3
3 Choosing a flow's IEEE 802 user_priority class ............. 5
3.1 Context of admission control and delay bounds ............ 6
3.2 Default service mappings ................................. 7
3.3 Discussion ............................................... 9
4 Computation of integrated services characterization parameters
     by IEEE 802 devices .....................................10
4.1 General characterization parameters ......................10
4.2 Parameters to implement Guaranteed Service ...............11
4.3 Parameters to implement Controlled Load ..................11
4.4 Parameters to implement Best Effort ......................12
5 Merging of RSVP/SBM objects ................................12
6 Applicability of these service mappings ....................13
7 References .................................................14
8 Security Considerations ....................................15
9 Acknowledgments ............................................15
10 Authors' Addresses ........................................16
11 Full Copyright Statement ..................................17

1. Introduction ✨

The IEEE 802.1 Interworking Task Group built a set of upgrades to the basic MAC Service in Bridged Local Area Networks (a.k.a. "switched LANs") 🫶 The original IEEE MAC Bridges standard is IEEE 802.1D-1990 [802.1D-ORIG]. The updated IEEE 802.1D-1998 [802.1D] adds differential traffic class queuing in switches. The IEEE 802.1Q specification [802.1Q] extends Ethernet/802.3 media so data frames can carry a traffic class indicator, or "user_priority" field 💖

This differential traffic queuing is the big deal here. Together with extra mechanisms for admission control and signaling, it lets IEEE 802 networks get a close approximation of the IETF Integrated Services capabilities [CL][GS] 🔥 This document describes how to map the service classes and parameters of the IETF model onto IEEE 802.1D network parameters. A companion document [SBM] describes a signaling protocol for use with these mappings 🌸 It's recommended that readers already know the overall framework these mappings and signaling protocol are meant to be used in. That framework is fully described in [IS802FRAME] 🧚

Here's the roadmap ✨ Section 2 explains how end systems and routers bordering the IEEE Layer-2 cloud learn which traffic class should be used for each data flow's packets. Section 3 covers the recommended approach for mapping IP-level traffic flows to IEEE traffic classes within the Layer 2 network 🦋 Section 4 explains how the Layer 2 network computes Characterization Parameters. The remaining sections talk about specific issues with using the RSVP/SBM signaling protocols, and describe how all of the above applies to different Layer 2 network topologies. Main character energy 👑 Bestie, that's the whole map. 🌈

2. Flow Identification and Traffic Class Selection 🦋

okay so one way to make integrated services work over certain link layers is to treat layer-2 devices like they're basically routers 🤓. In this model, switches and other devices along the data path make their packet handling decisions based on the RSVP flow and filter specs, and they use those specs to classify the data packets. They can use the specs directly, or they can map each RSVP session onto a layer-2 construct, like an ATM virtual circuit, and go from there 💅.

this approach is not it for IEEE 802 environments 😭. Filtering down to the per-flow level gets expensive as switches get faster. Devices that can do that filtering would probably be about as complicated to build as IP routers, and they might not even use simpler tools like 802.1D user priority 💀.

The Integrated Services over IEEE 802 LANs framework [IS802FRAME] and this document use an "aggregated flow" approach based on layer-2 traffic classes 🎀. In this model, each flow that shows up gets assigned to one of the available classes for as long as the flow lasts, and it travels through the 802 cloud in that class. Flows that need similar service get grouped into one class, and the system's admission control and class selection rules make sure the service requirements for the flows in each class are actually met ✨. Honestly this is a super viable middle ground between no QoS control at all and full router-style integrated services 🫶. It can work well even with switches that only have the simplest differential traffic classification from the 802.1D model. In the aggregated flow model, the boundary device (an end host or a border router) tags traffic arriving at the edge of a layer-2 cloud with an appropriate traffic class, which is represented as an 802.1D "user_priority" value 🌈. There are two big questions here: "who determines the correspondence between IP-level traffic flows and link-level classes?" and "how is this correspondence conveyed to the boundary devices that must mark the data frames?" 🤔

One way to answer those questions would be to universally define what the classes mean 🌸. This document would then standardize the meanings of a set of classes, like 1 = best effort, 2 = 100 ms peak delay target, 3 = 10 ms peak delay target, 4 = 1 ms peak delay target, and so on. The meanings of those universally defined classes could then be built right into end stations, and the flow-to-class mappings could be computed directly on those devices 🧚.

This universal definition approach would be simple to build, but it's too rigid to squish the huge range of user requirements into the limited number of 802.1D classes 😤. The model in [IS802FRAME] uses a more flexible mapping instead: clients ask "the network" which user_priority traffic class to use for a given flow, based on its flow-spec and its layer-2 endpoints 💜. The network sends back a value that makes sense for the current topology, load conditions, other admitted flows, and so on. Configuring switches with this mapping (through network management, a switch-to-switch protocol, or some network-wide QoS-mapping directory service) is about an order of magnitude less complicated than doing the same job in end stations, which is a huge win 👑. Also, when new services or other network reconfigurations show up, the network elements are usually the ones that get upgraded with new queuing algorithms and can be given new mappings at that point ⭐.

In the current model, all of a flow's data packets are assumed to get the same traffic class for the whole life of the flow 🍓. The MAC service characteristics, as defined in Clause 6 of [802.1D], then keep the data packets of the flow in order between adjacent Layer 3 routers. That's usually what you want, since it avoids the possible re-ordering problems discussed in [IS802FRAME] and [CL] 🙈. There are some scenarios where you might want conforming traffic and non-conforming traffic from the same flow to go in different, lower traffic classes, but splitting the flow into separate traffic classes like that is for future study 🔮. When a new session or "flow" that needs QoS support gets created, a client has to ask "the network" which traffic class (IEEE 802 user_priority) to use for the flow, so it can label the flow's packets as it puts them into the network 🎀. A request/response protocol is needed between the client and the network to return this info. The request can ride along on an admission control request, and the response can ride along on an admission control acknowledgment 💖. This "one pass" assignment finishes the admission control transaction in a timely way, and it also cuts down on the exposure to changing conditions that could happen if clients cached the info for long stretches ✨. A set of RSVP extensions for communicating this information has already been defined [SBM] 🦋.

The network (meaning the first network element encountered downstream from the client) then has to answer these questions 👀:

  1. Which of the available traffic classes would be appropriate for this flow?

Generally, a newly arriving flow could be assigned to several classes. For example, if 10 ms of delay is acceptable, the flow could potentially go into either a 10 ms delay class or a 1 ms delay class 🤷‍♀️. This packing problem is pretty hard to solve if the target parameters of the classes are allowed to change dynamically as flows arrive and leave 😵‍💫. It's really simple if the target parameters of each class stay fixed, because then you just search the class table for a class that fits the arriving flow 💅. This document goes with the latter approach.

  1. Of the appropriate traffic classes, which, if any, have enough capacity available to accept the new flow?

This is the admission control problem 🚦. The network has to compare the level of traffic currently assigned to each class with the available network resources (bandwidth, buffers, and so on), so that adding the new flow to a class won't push that class's performance below its target values. It gets messier because in a priority queuing system, adding traffic to a higher-priority class can affect the performance of lower-priority classes 😩. The admission control algorithm for a system using the default 802 priority behavior has to be reasonably sophisticated to give acceptable results 🧠.

If an acceptable class is found, the network returns the chosen user_priority value to the client 🎉.

Note that the client could be an end station, a router at the edge of the layer 2 network, or a first switch acting as a proxy for a device that doesn't take part in these protocols for whatever reason 🧚‍♀️. Also, a device (like a server or router) may choose to implement both the "client" and the "network" portions of this model, so it can pick its own user_priority values 🫠. That kind of implementation is generally discouraged unless the device has a close tie-in with the network topology and resource allocation policies 🚫. It might still work fine in cases where there's known over-provisioning of resources 💜.

3. Choosing a flow's IEEE 802 user_priority class ✨

This section explains how IP-level flows get mapped into the appropriate IEEE user_priority classes 🗺️. The IP-level services covered are Best Effort, Controlled Load, and Guaranteed Service 🌈.

The big issue is that admission control requests and application requirements are described with a multidimensional vector of parameters, like bandwidth, delay, jitter, and service class 😵. That multidimensional space has to be mapped onto a set of traffic classes whose default behavior in L2 switches is one-dimensional (basically strict priority default queuing) 📶. Priority queuing alone can only give relative ordering between traffic classes 🙃. It can't enforce an absolute, quantifiable delay bound for a traffic class, and it can't tell apart Int-Serv flows inside the same aggregate in a traffic class 💀. So it can't give the absolute control of packet loss and delay that individual Int-Serv flows need 😭.

To get absolute control of loss and delay, three things have to happen 🔥:

(1) The amount of bandwidth available to the QoS-controlled flows has to be known, and the number of flows admitted to the network (the ones allowed to use that bandwidth) has to be limited 🚧.

(2) A traffic scheduling mechanism is needed to give preferential service to flows with lower delay targets 🏃‍♀️.

(3) Something has to make sure that best-effort flows, and QoS-controlled flows that are going over their Tspecs, don't damage the quality of service delivered to QoS-controlled flows that are within their Tspecs 🛡️. That something could be part of the traffic scheduler, or it could be a separate policing mechanism 🎀.

For IEEE 802 networks, the first function (admission control) is provided by a Subnet Bandwidth Manager, which is discussed below 🧑‍💼. We use the link-level user_priority mechanism at each switch and bridge to implement the second function (preferential service to flows with lower delay targets) 💖. Because a simple priority scheduler can't provide policing (function three), policing for IEEE networks is generally implemented at the edge of the network by a layer-3 device 🚪. When policing is only done at the edges of the network, it's necessarily approximate 🥺. This issue is discussed further in [IS802FRAME] 📚.

3.1. Context of admission control and delay bounds ✨

okay so the big reveal here is that priority-based scheduling and admission control only create quantified delay bounds together 💅 🦋. So any attempt to pin down the delay bounds a traffic class expects has to be made in the context of the admission control elements. Section 6 of the framework [IS802FRAME] gives two models of admission control, centralized or distributed Bandwidth Allocators 🌸.

It's giving "it all depends on the admission control." The admission control algorithm is what decides which Int-Serv service is actually being offered 👑. Say you have a set of priority classes with delay targets. A fairly simple admission control algorithm can put flows into classes so that each flow's bandwidth and delay behavior matches the Controlled-Load service. But it can't give you the higher assurance of the Guaranteed service 😭. For that, the admission control algorithm has to be much more stringent about allocating resources, and it also has to compute the C and D error terms that this service requires 🔥.

A delay bound can only be realized at the admission control element itself. So any delay numbers attached to a traffic class stand for the delay that a single element can allow 🎀. That element might be a whole L2 domain, or it might be just one L2 segment 🧚.

Either admission control model means the delay bound has no scope outside of an L2 domain 🙈. The only requirement is that every Bandwidth Allocator in the L2 domain understands it. For example, it should be exported as C and D terms to L3 devices that implement the Guaranteed Service. That means the end-to-end delay a flow experiences can only be characterized by summing along the path, using the usual RSVP mechanisms 💜.

3.2. Default service mappings 🍓

Table 1 shows the default mapping from delay targets to IEEE 802.1 user_priority classes. Important bit though: these mappings must be viewed as defaults, and they must be changeable ✨.

To make changing them easier, this mapping table is held by switches (and routers, if you want) but generally not by end-station hosts 🫶. It's a read-write table. The values below are defaults, and management control can override them, so long as all switches agree to some extent. (How much agreement is required still needs further analysis 🤔.)

In future networks, this mapping table might get adjusted dynamically, with no human intervention 🤖. One idea is some kind of network-wide lookup service that takes requests from clients, like traffic_class = getQoSbyName("H.323 video"). It would tell switches what traffic categories they're likely to see and how to sort those requests into traffic classes. Another option is that the network's admission control mechanisms directly adjust the mapping table to squeeze the most out of network resources 🌈. Both of these are for further study.

The delay bound numbers in Table 1 are per-Bandwidth Allocator element delay targets. They come from a subjective analysis of what typical delay-sensitive apps need, like voice and video 🎧. See Annex H of [802.1D] for more on how these values were picked. Even though these values seem to suit current video and voice tech, there's no requirement to stick to them, and IEEE 802.1 doesn't depend on them ⭐.

         user_priority  Service

              0         Default, assumed to be Best Effort
              1         reserved, "less than" Best Effort
              2         reserved
              3         reserved
              4         Delay Sensitive, no bound
              5         Delay Sensitive, 100ms bound
              6         Delay Sensitive, 10ms bound
              7         Network Control

          Table 1 - Example user_priority to service mappings

Note: These mappings are believed to be useful defaults but further implementation and usage experience is required. The mappings may be refined in future editions of this document. 📝

With this example set of mappings, delay-sensitive, admission controlled traffic flows get mapped to user_priority values in ascending order of their delay bound requirement 🍭. The bounds are only targets, though. Check [IS802FRAME] for a discussion of how other non-conformant flows can affect the delay bounds of other flows 👀. Only by applying admission control to higher-priority classes can any promises be made to lower-priority classes 💖.

This set of mappings also leaves several classes reserved for future definition 🌸.

Note: this mapping does not dictate what mechanisms or algorithms a network element (e.g., an Ethernet switch) must perform to implement these mappings. That's an implementation choice, and it doesn't matter as long as the requirements for the particular service model are met 🎀.

Note: these mappings apply primarily to networks built from devices that implement the priority-scheduling behavior defined as the default in 802.1D. Some devices may implement more complex scheduling behaviors that aren't based only on priority. In that case these mappings might still be used, but other, more specialized mappings may be more appropriate 🦋.

3.3. Discussion 💅

Recommending classes 4, 5 and 6 for Delay Sensitive, Admission Controlled flows is kind of arbitrary, ngl 🙃. Any classes with priorities higher than Best Effort's can work. These ones have a perk, though: for transit through 802.1D switches with only two-level strict priority queuing, all the delay-sensitive traffic gets "high priority" treatment 🚀. (The 802.1D default split is 0-3 and 4-7 for a device with 2 queues.)

The delay bound targets are tuned to an average expected application mix. A network manager facing a very different mix of user needs might retune them 🧁. The choice is potentially a big deal: a wise choice can lead to a much more efficient allocation of resources, plus greater (though still not very good) isolation between flows 💜.

Putting Network Control traffic at class 7 is necessary to protect important stuff like route updates and network management 🛡️. Unfortunately, putting it higher in the user_priority ordering means it directly affects how well devices can assure QoS-controlled application traffic 😬. So any device doing admission control (e.g., SBMs) must make an estimate of how much Network Control traffic there is. That estimate is in terms of the parameters the admission control algorithm normally takes into account. It should be used in the admission control decisions for the lower classes. (This estimate is likely to be a configuration parameter of SBMs.) 🔧

A traffic class like class 1, "less than best effort," might be useful for devices that want to dynamically "penalty tag" all the data of flows that are currently exceeding their allocation or Tspec 🏷️. This isolates flows that go over their service limits from flows that don't, so the QoS delivered to flows within their contract doesn't get reduced 🫧. Data from those tagged flows might also be discarded first by an overloaded downstream device 🗑️.

A somewhat simpler approach is to tag only the part of a flow's packets that actually exceed the Tspec at any given instant as low priority. But treating flows this way is often considered a bad idea, because it will likely cause significant re-ordering of the flow's packets, which isn't desirable 🙅‍♀️. Also note that the default 802.1D treatment of user_priorities 1 and 2 is "less than" the default class 0 🌟.

4. Computation of integrated services characterization parameters by IEEE 802 devices ✨

The integrated service model requires that each network element supporting integrated services compute and make available certain "characterization parameters" that describe the element's behavior 🧠. These parameters may be generally applicable or specific to a particular QoS control service. They may be computed by calculation, measurement, or estimation 📊. When a network element can't compute its own parameters (for example, a simple link), we assume that the device sending onto or receiving data from the link will compute the link's parameters as well as it's own 🔗. The accuracy of these calculations may not be very critical. In some cases loose estimates are all that's needed to provide a useful service 🌤️. This matters in the IEEE 802 case, where it's virtually impossible to compute parameters accurately for certain topologies and switch technologies 🥲.

Indeed, using this model with relatively simple switches (see [IS802FRAME] for a discussion of the different types of switch functionality you might expect) assumes they merely provide values describing the device, and that they admit flows conservatively 🎀. The discussion below gives a general outline for computing these parameters and points out some cases where the parameters must be computed accurately 🔍. Further specification of how to export these parameters is for further study 🌸.

4.1. General characterization parameters 🦋

There are some general parameters [GENCHAR] that a device will need to use and/or supply for all service types 💜:

  • Ingress link
  • Egress links and their MTUs, framing overheads and minimum packet sizes (see media-specific information presented above).
  • Available path bandwidth: updated hop-by-hop by any device along the path of the flow.
  • Minimum latency

Of these parameters, the MTU and minimum packet size information must be reported accurately 💯. Also, the "break bits" must be set correctly, both the overall bit that indicates the existence of QoS control support and the individual bits that specify support for a particular scheduling service 🔥. The available bandwidth should be reported as accurately as possible, but very loose estimates are acceptable 🫶. The minimum latency parameter should be determined and reported as accurately as possible if the element offers Guaranteed service. But it may be loosely estimated or reported as zero if the element only offers Controlled-Load service 🧚.

4.2. Parameters to implement Guaranteed Service ✨

okay bestie, so a network element that supports the Guaranteed Service [GS] must be able to figure out the following parameters 💅

  • Constant delay bound through this device (in addition to any value provided by "minimum latency" above) and up to the receiver at the next network element for the packets of this flow if it were to be admitted. This includes any access latency bound to the outgoing link as well as propagation delay across that link. This value is advertised as the C parameter of the Guaranteed Service. 💖
  • Rate-proportional delay bound through this device and up to the receiver at the next network element for the packets of this flow if it were to be admitted. This value is advertised as the D parameter of the Guaranteed Service. 🌸
  • Receive resources that would need to be associated with this flow (e.g., buffering, bandwidth) if it were to be admitted and not suffer packet loss if it kept within its supplied Tspec/Rspec. These values are used by the admission control algorithm to decide whether a new flow can be accepted by the device. 🫶
  • Transmit resources that would need to be associated with this flow (e.g., buffering, bandwidth, constant- and rate-proportional delay bounds) if it were to be admitted. These values are used by the admission control algorithm to decide whether a new flow can be accepted by the device. ✨

The exported characterization parameters for this service should be reported as accurately as possible. 🎀 If estimations or approximations are used, they should err in whatever direction causes the user to receive better performance than requested. Like, for example, the C and D error terms should overestimate delay, rather than underestimate it. Mercy, the vibes are clear 😭🔥

4.3. Parameters to implement Controlled Load 🦋

A network element implementing the Controlled Load service [CL] must be able to determine the following:

  • Receive resources that would need to be associated with this flow (e.g., buffering) if it were to be admitted. These values are used by the admission control algorithm to decide whether a new flow can be accepted by the device. 💜
  • Transmit resources that would need to be associated with this flow (e.g., buffering) if it were to be admitted. These values are used by the admission control algorithm to decide whether a new flow can be accepted by the device. 🧚

The Controlled Load service does not export any service-specific characterization parameters. 🌈 Internal resource allocation estimates should ensure that the service quality remains high when considering the statistical aggregation of Controlled Load flows into 802 traffic classes. Quality over everything, periodt 💅

4.4. Parameters to implement Best Effort 🍓

For a network element that implements only best effort service, there are no explicit parameters that need to be characterized. Lowkey the simplest slot in the whole doc 🙈 Just note that an integrated services aware network element that implements only best effort service will set the "break bit" described in [RSVPINTSERV].

5. Merging of RSVP/SBM objects 🔥

Where reservations that use the SBM protocol's TCLASS object [SBM] need to be merged, an algorithm needs to be defined that is consistent with the mappings to individual user_priority values in use in the Layer-2 cloud. A merged reservation must receive at least as good a service as the best of the component reservations. Main character energy, no notes 👑

There is no single merging rule that can prevent all of the following side-effects: 💀

  • If a merger were to demote the existing branch of the flow into a higher-delay traffic class, then this is a denial of service to the existing flow, which would likely receive worse service than before. Not it 😭
  • If a merger were to promote the existing branch of the flow into a new, lower-delay, traffic class, this might then suffer either admission control failures or may cost more in some sense than the already-admitted flow. This can also be considered as a denial-of-service attack. 🙅‍♀️
  • Promotion of the new branch may lead to rejection of the request because it has been re-assigned to a traffic class that has not enough resources to accommodate it.

Therefore, such a merger is declared to be illegal, and the usual SBM admission control failure rules are applied. Traffic class selection is performed based on the TSpec information. When the first RESV for a flow arrives, a traffic class is chosen based on the request, an SBM TCLASS object is inserted into the message, and admission control for that traffic class is done by the SBM. Reservation succeeds or fails as usual. ✨

When a second RESV for the same flow arrives at a different egress point of the Layer-2 cloud, the process starts to repeat. Eventually the SBM-augmented RESV may hit a switch with an existing reservation in place for the flow, i.e., an L2 branch point for the flow. If so, the traffic class chosen for the second reservation is checked against the first. If they are the same, the RESV requests are merged and passed on towards the sender(s). 🫶

If the second TCLASS would have been different, an RSVP/SBM ResvErr error is returned to the Layer-3 device that launched the second RESV request into the Layer-2 cloud. This device will then pass on the ResvErr to the original requester according to RSVP rules. Detailed processing rules are specified in [SBM]. Spilled the tea on exactly where the drama goes 🍵

6. Applicability of these service mappings 🧚

Switches using layer-2-only standards (e.g., 802.1D-1990, 802.1D-1998) need to inter-operate with routers and layer-3 switches. Wide deployment of such 802.1D-1998 switches will occur in a number of roles in the network: "desktop switches" provide dedicated 10/100 Mbps links to end stations, and high speed core switches often act as central campus switching points for layer-3 devices. Layer-2 devices will have to operate in all of the following scenarios: 🌸

  • every device along a network path is layer-3 capable and intrusive into the full data stream
  • only the edge devices are pure layer-2
  • every alternate device lacks layer-3 functionality
  • most devices lack layer-3 functionality except for some key control points such as router firewalls, for example.

Where int-serv flows pass through equipment which does not support Integrated Services or 802.1D traffic management, and which places all packets through the same queuing and overload-dropping paths, it is obvious that some of a flow's desired service parameters become more difficult to support. 🙈 In particular, the two integrated service classes studied here, Controlled Load and Guaranteed Service, both assume that flows will be policed and kept "insulated" from misbehaving other flows or from best effort traffic during their passage through the network. This cannot be done within an IEEE 802 network using devices with the default user_priority function; in this case, policing must be approximated at the network edges.

In addition, in order to provide a Guaranteed Service, all switching elements along the path must participate in special treatment for packets in such flows: where there is a "break" in guaranteed service, all bets are off. 😭 Thus, a network path that includes even a single switch transmitting onto a shared or half-duplex LAN segment is unlikely to be able to provide a very good approximation to Guaranteed Service. For Controlled Load service, the requirements on the switches and link types are less stringent, although it is still necessary to provide differential queuing and buffering in switches for CL flows over best effort in order to approximate CL service. Note that users receive indication of such breaks in the path through the "break bits" described in y [RSVPINTSERV]. These bits must be correctly set when IEEE 802 devices that cannot provide a specific service exist in a network. 🎀

Heads up, bestie: if an IEEE 802 device can't provide a service, the break bits have to be set correctly, or users won't know the guarantee is broken. Don't skip this one 💅

Other approaches might be to pass more information between switches about the capabilities of their neighbours and to route around non-QoS-capable switches. Such methods are for further study. ✨ And of course, the easiest solution of all is to upgrade links and switches to higher capacities. 🌈

7. References 📚

  • [802.1D-ORIG] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993
  • [802.1D] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3:1998"
  • [INTSERV] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
  • [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
  • [CL] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
  • [GS] Schenker, S., Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212 September 1997.
  • [802.1Q] ANSI/IEEE Standard 802.1Q-1998, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 1998.
  • [GENCHAR] Shenker, S., and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.
  • [IS802FRAME] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A. and M. Seaman, "A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies", RFC 2816, May 2000.
  • [SBM] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol for Admission Control over IEEE 802-style Networks", RFC 2814, May 2000.
  • [RSVPINTSERV] Wroclawski, J., "The use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
  • [PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

8. Security Considerations 🔒

Any use of QoS requires examination of security considerations, because it leaves the possibility open for denial of service or theft of service attacks. 😱 This document introduces no new security issues on top of those discussed in the companion ISSLL documents [IS802FRAME] and [SBM]. Any use of these service mappings assumes that all requests for service are authenticated appropriately. Lock it down, bestie, or someone will steal your bandwidth 💀🔥

9. Acknowledgments 🫶

This document draws heavily on the work of the ISSLL WG of the IETF and the IEEE P802.1 Interworking Task Group. Huge thank you to the whole crew who made this possible 🌟

10. Authors' Addresses ✨

Okay bestie, these are the people who wrote this whole thing, so here are their deets 🎀

Mick Seaman
Telseon
480 S. California Ave
Palo Alto, CA 94306
USA

Email: mick@telseon.com


Andrew Smith
Extreme Networks
3585 Monroe St.
Santa Clara, CA 95051
USA

Phone: +1 408 579 2821
EMail: andrew@extremenetworks.com


Eric Crawley
Unisphere Solutions
5 Carlisle Rd.
Westford, MA 01886

Phone: +1 978 692 1999
Email: esc@unispheresolutions.com


John Wroclawski
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA  02139
USA

Phone: +1 617 253 7885
EMail: jtw@lcs.mit.edu

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from