RFC 2816
A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies
RFC 2816: A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies ✨
Part 1 of 12 🎀
- Network Working Group: A. Ghanwani (Nortel Networks), W. Pace (IBM), V. Srinivasan (CoSine Communications), A. Smith (Extreme Networks), M. Seaman (Telseon)
- Category: Informational 🌸
- Date: May 2000 📅
- Obsoletes / Updates: the header doesn't list any RFCs that this one obsoletes or updates 🦋
Status of this Memo 💅
okay so this memo is just here to give information to the Internet community 📚 It is NOT a standard of any kind, so don't go treating it like one 🙈 Distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2000). All Rights Reserved. 🔒
Abstract 🧚
okay this memo is about a framework for getting IETF Integrated Services working on shared and switched LAN infrastructure 🏠 It gives background on how IEEE 802-style networks handle the stuff that matters for Integrated Services, like access latency, delay variation, and queuing support in LAN switches ⏱️ It also talks about parts of the IETF Integrated Services model that are hard to fit into different LAN environments 😭 Then it lays out a functional model for supporting the Resource Reservation Protocol (RSVP) in those LAN environments 💜 The details of the RSVP extensions for LANs live in an accompanying memo [14], and the mappings of the various Integrated Services onto IEEE 802 LANs are covered in another memo [13] ✨
Contents 📋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Outline . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
4. Frame Forwarding in IEEE 802 Networks . . . . . . . . . . 5
4.1. General IEEE 802 Service Model . . . . . . . . . . . 5
4.2. Ethernet/IEEE 802.3 . . . . . . . . . . . . . . . . . 7
4.3. Token Ring/IEEE 802.5 . . . . . . . . . . . . . . . . 8
4.4. Fiber Distributed Data Interface . . . . . . . . . . 10
4.5. Demand Priority/IEEE 802.12 . . . . . . . . . . . . . 10
5. Requirements and Goals . . . . . . . . . . . . . . . . . . 11
5.1. Requirements . . . . . . . . . . . . . . . . . . . . 11
5.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Non-goals . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Assumptions . . . . . . . . . . . . . . . . . . . . . 14
6. Basic Architecture . . . . . . . . . . . . . . . . . . . . 15
6.1. Components . . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Requester Module . . . . . . . . . . . . . . 15
6.1.2. Bandwidth Allocator . . . . . . . . . . . . . 16
6.1.3. Communication Protocols . . . . . . . . . . . 16
6.2. Centralized vs. Distributed Implementations . . . . 17
7. Model of the Bandwidth Manager in a Network . . . . . . . 18
7.1. End Station Model . . . . . . . . . . . . . . . . . . 19
7.1.1. Layer 3 Client Model . . . . . . . . . . . . 19
7.1.2. Requests to Layer 2 ISSLL . . . . . . . . . . 19
7.1.3. At the Layer 3 Sender . . . . . . . . . . . . 20
7.1.4. At the Layer 3 Receiver . . . . . . . . . . . 21
7.2. Switch Model . . . . . . . . . . . . . . . . . . . . 22
7.2.1. Centralized Bandwidth Allocator . . . . . . . 22
7.2.2. Distributed Bandwidth Allocator . . . . . . . 23
7.3. Admission Control . . . . . . . . . . . . . . . . . . 25
7.4. QoS Signaling . . . . . . . . . . . . . . . . . . . . 26
7.4.1. Client Service Definitions . . . . . . . . . 26
7.4.2. Switch Service Definitions . . . . . . . . . 27
8. Implementation Issues . . . . . . . . . . . . . . . . . . 28
8.1. Switch Characteristics . . . . . . . . . . . . . . . 29
8.2. Queuing . . . . . . . . . . . . . . . . . . . . . . . 30
8.3. Mapping of Services to Link Level Priority . . . . . 31
8.4. Re-mapping of Non-conforming Aggregated Flows . . . . 31
8.5. Override of Incoming User Priority . . . . . . . . . 32
8.6. Different Reservation Styles . . . . . . . . . . . . 32
8.7. Receiver Heterogeneity . . . . . . . . . . . . . . . 33
9. Network Topology Scenarios . . . . . . . . . . . . . . . 35
9.1. Full Duplex Switched Networks . . . . . . . . . . . . 36
9.2. Shared Media Ethernet Networks . . . . . . . . . . . 37
9.3. Half Duplex Switched Ethernet Networks . . . . . . . 38
9.4. Half Duplex Switched and Shared Token Ring Networks . 39
9.5. Half Duplex and Shared Demand Priority Networks . . . 40
10. Justification . . . . . . . . . . . . . . . . . . . . . . 42
11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43
References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Security Considerations . . . . . . . . . . . . . . . . . . . 45
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 471. Introduction 🌈
okay so the Internet has traditionally only done best effort traffic 🥺 But with the recent advances in link layer technology, and with a bunch of emerging real time apps like video conferencing and Internet telephony, everyone got SO into the idea of real time services over the Internet 🎥📞 A framework for meeting these new requirements was set out in RFC 1633 [8], and that's what drove the Integrated Services working group of the IETF to specify different classes of network service, like Controlled Load and Guaranteed Service [6,7] 👑 Each of these service classes is designed to provide a certain Quality of Service (QoS) to traffic that conforms to a specified set of parameters ✨ Applications are expected to pick one of these classes based on their QoS requirements 💅
One way for end stations to use these services in an IP network is a QoS signaling protocol, the Resource Reservation Protocol (RSVP) [5], which was developed by the RSVP working group of the IETF 🦋 The IEEE, under its Project 802, has defined standards for lots of different local area network technologies 🌸 These all typically offer the same MAC layer datagram service [1] to higher layer protocols like IP, although they often have different dynamic behavior characteristics, and those are the bits that really matter when you're thinking about whether they can support real time services 🙈 We describe some of the relevant characteristics of the different MAC layer LAN technologies later in this memo 🍓 IEEE 802 has also defined standards for bridging multiple LAN segments together using devices known as "MAC Bridges" or "Switches" [2] 🔥 Recent work has defined traffic classes, multicast filtering, and virtual LAN capabilities for these devices too [3,4] 💜
Okay here's the thing: these LAN technologies often make up the last hop(s) between users and the Internet, and they're a primary building block for entire campus networks 🏫 So it's necessary to provide standardized mechanisms for using these technologies to support end-to-end real time services 🫶 To do that, there has to be some mechanism for resource management at the data link layer 🔧 In this context, resource management covers functions like admission control, scheduling, traffic policing, etc. 📋 The ISSLL (Integrated Services over Specific Link Layers) working group in the IETF was chartered to explore and standardize these mechanisms for various link layer technologies 🎀
2. Document Outline 🗺️
bestie, this document is about specifying a framework for providing Integrated Services over shared and switched LAN technologies like Ethernet/IEEE 802.3, Token Ring/IEEE 802.5, FDDI, etc. 🌟 We start in Section 4 with a discussion of the capabilities of various IEEE 802 MAC layer technologies 🧠 Section 5 lists the requirements and goals for a mechanism that can provide Integrated Services in a LAN 📝 The resource management functions outlined in Section 5 are provided by an entity called a Bandwidth Manager (BM) 👑 The architectural model of the BM is described in Section 6, and its various components are discussed in Section 7 🧩 Some implementation issues for link layer support of Integrated Services are examined in Section 8 🔍 Section 9 covers a taxonomy of topologies for the LAN technologies under consideration, focusing on what each one offers that can be leveraged for enabling Integrated Services 🌐 This framework makes no assumptions about the topology at the link layer 🫧 It's meant to be as exhaustive as possible, which means not every function discussed may be supportable by a particular topology or technology, but that shouldn't stop anyone from using this model for it 💖
3. Definitions 📖✨
Okay bestie, here's the glossary for this doc and the other ISSLL docs. Read these first, they're the vocab we use everywhere 💅
- Link Layer or Layer 2 or L2: Data link layer techs like Ethernet/IEEE 802.3 and Token Ring/IEEE 802.5 are called Layer 2 or L2. 🦋
- Link Layer Domain or Layer 2 Domain or L2 Domain: A set of nodes and links that are interconnected without going through an L3 forwarding function. One or more IP subnets can be overlaid on an L2 domain. 🌸
- Layer 2 or L2 Devices: Devices that only do Layer 2 stuff, so they count as Layer 2 or L2 devices. These include IEEE 802.1D [2] bridges or switches. 🎀
- Internetwork Layer or Layer 3 or L3: Layer 3 of the ISO OSI model. This memo is mainly about networks that use the Internet Protocol (IP) at this layer. 🧚
- Layer 3 Device or L3 Device or End Station: These include hosts and routers that use L3 and higher layer protocols, or application programs that need to make resource reservations. 💜
- Segment: A physical L2 segment that's shared by one or more senders. Examples of segments include: (a) a shared Ethernet or Token Ring wire resolving contention for media access using CSMA or token passing; (b) a half duplex link between two stations or switches; (c) one direction of a switched full duplex link. 🌈
- Managed Segment: A managed segment is a segment with a DSBM (designated subnet bandwidth manager, see [14]) present and responsible for exercising admission control over requests for resource reservation. A managed segment includes those interconnected parts of a shared LAN that are not separated by DSBMs. 👑
- Traffic Class: An aggregation of data flows that get similar service within a switched network. 💅
- Subnet: Used in this memo to mean a group of L3 devices sharing a common L3 network address prefix, along with the set of segments making up the L2 domain they're located in. 🍓
- Bridge/Switch: A Layer 2 forwarding device as defined by IEEE 802.1D [2]. The terms bridge and switch are used synonymously in this memo. ✨
4. Frame Forwarding in IEEE 802 Networks 🚀
4.1. General IEEE 802 Service Model
Okay so the user_priority is a value tied to sending and receiving all frames in the IEEE 802 service model. 🫶 The sender using the MAC service supplies it, and it's handed to a receiver using the MAC service along with the data. It may or may not actually get carried over the network. Token Ring/IEEE 802.5 carries this value encoded in its FC octet, while basic Ethernet/IEEE 802.3 does not carry it at all. IEEE 802.12 may or may not carry it depending on the frame format in use. When the frame format is IEEE 802.5, the user_priority is carried explicitly. When IEEE 802.3 frame format is used, only the two levels of priority (high/low) that are used to determine access priority can be recovered. That's based on the value of priority encoded in the start delimiter of the IEEE 802.3 frame. 😭
NOTE: The original IEEE 802.1D standard [2] contains the specifications for how MAC bridges operate. This has recently been extended to include support for traffic classes and dynamic multicast filtering [3]. In this document, when we say IEEE 802.1D, we mean [3], unless it's explicitly noted otherwise. 📝
IEEE 802.1D [3] defines a consistent way to carry the user_priority value over a bridged network made of Ethernet, Token Ring, Demand Priority, FDDI, or other MAC layer media, using an extended frame format. The usage of user_priority is summarized below. If you're curious, go read the IEEE 802.1D spec for more info. 🔥
If the user_priority is carried explicitly in packets, it works as a simple label. That lets packets in different classes within a data stream get told apart easily by downstream nodes, without having to parse the packet in more detail. 🦋
Having an explicit field is a big deal for desktop or wiring closet switches. They don't have to change hardware or software as the rules for classifying packets evolve, e.g. based on new protocols or new policies. 💖 More sophisticated Layer 3 switches, maybe deployed in the core of a network, can add value by classifying packets more accurately. That means they use network resources more efficiently and give better isolation between flows. This seems like a good economic choice, since there are likely to be way more desktop/wiring closet switches in a network than switches that need Layer 3 functionality. 💅
The IEEE 802 specs make no assumptions about how user_priority is used by end stations or by the network. IEEE 802.1D defines static priority queuing as the default mode for switches that implement multiple queues. Still, user_priority is only loosely a priority, because it depends on how many traffic classes a switch actually implements. user_priority is defined as a 3 bit quantity, where a value of 7 is the highest priority and 0 is the lowest. Here's the general switch algorithm: packets are queued within a particular traffic class based on the received user_priority. That value either comes straight from the packet, if an IEEE 802.1Q header or IEEE 802.5 network is used, or it's assigned according to some local policy. The queue is selected by mapping user_priority (0 through 7) onto the number of available traffic classes. A switch may implement one or more traffic classes. The advertised IntServ parameters and the switch's admission control behavior may be used to decide the mapping from user_priority to traffic classes within the switch. A switch isn't prevented from using other scheduling algorithms, like weighted fair queuing and round robin. 🌸
IEEE 802.1D makes no recommendations about how a sender should pick the value for user_priority. One of the main purposes of this document is to propose usage rules for that, and to talk about communicating what these values mean between switches and end stations. For the rest of this document, we use the term traffic class interchangeably with user_priority. 🧚✨
4.2. Ethernet/IEEE 802.3
No explicit traffic class or user_priority field gets carried in Ethernet packets. 🥺 That means user_priority has to be regenerated at a downstream receiver or switch, either using some defaults or by parsing further into higher layer protocol fields in the packet. Alternatively, IEEE 802.1Q encapsulation [4] may be used, which provides an explicit user_priority field on top of the basic MAC frame format. 🎀
For the different IP packet encapsulations used over Ethernet/IEEE 802.3, you'll need to adjust any admission control calculations for the framing and padding requirements shown in Table 1. Here, "ip_len" refers to the length of the IP packet, including its headers. 📏
Table 1: Ethernet encapsulations
---------------------------------------------------------------
Encapsulation Framing Overhead IP MTU
bytes/pkt bytes
---------------------------------------------------------------
IP EtherType (ip_len<=46 bytes) 64-ip_len 1500
(1500>=ip_len>=46 bytes) 18 1500
IP EtherType over 802.1D/Q (ip_len<=42) 64-ip_len 1500*
(1500>=ip_len>=42 bytes) 22 1500*
IP EtherType over LLC/SNAP (ip_len<=40) 64-ip_len 1492
(1500>=ip_len>=40 bytes) 24 1492
---------------------------------------------------------------Footnote for those asterisks: the packet length of an Ethernet frame using the IEEE 802.1Q specification goes over the current IEEE 802.3 maximum packet length values by 4 bytes. 🙈 The change of maximum MTU size for IEEE 802.1Q frames is being accommodated by IEEE 802.3ac [21]. ✨
4.3. Token Ring/IEEE 802.5 🦋
okay bestie, Token Ring has a whole priority system built in and it is SO iconic 💅 The Token Ring standard [6] gives you priority mechanisms that control both how packets get lined up for sending and how packets get access to the shared media. The bits live in the AC and FC fields of an LLC frame. The first three bits of the AC field are the Token Priority bits, and the last three bits of the AC field are the Reservation bits. Together they decide which stations get to use the ring 👑
The last three bits of the FC field are the User Priority bits. They come from the higher layer, through the user_priority parameter, whenever it asks to transmit a packet. That same parameter also sets the Access Priority the MAC uses. The user_priority value travels end-to-end in those FC bits and usually survives Token Ring bridges of every type ✨ Quick reminder that 0 is the lowest priority, so 7 is the top 🔥
Token Ring also has a concept called Reserved Priority 🎀 That's the priority a station uses when it reserves the token for its next transmission on the ring. When a free token is going around, only a station whose Access Priority is greater than or equal to the Reserved Priority in the token can grab it for transmitting. Honestly it's giving very strict bouncer energy. If you want the full tea on this, go read [14] 🧚
A Token Ring station can, in theory, queue each of the eight user_priority levels separately and then transmit frames in priority order 🌈 A station sets its Reservation bits based on the user_priority of the frames waiting in its highest priority queue. This lets the access mechanism make sure the frame with the highest priority anywhere on the ring goes out before any lower priority frame. Annex I to the IEEE 802.5 Token Ring standard recommends how stations should send and relay frames, and here's the table 🍓
Table 2: Recommended use of Token Ring User Priority
-------------------------------------
Application User Priority
-------------------------------------
Non-time-critical data 0
- 1
- 2
- 3
LAN management 4
Time-sensitive data 5
Real-time-critical data 6
MAC frames 7
-------------------------------------To cut down on frame jitter for high priority traffic, the annex also recommends sending only one frame per token. It additionally recommends a maximum information field size of 4399 octets whenever delay sensitive traffic is crossing the ring 💖 Most existing Token Ring bridge implementations forward all LLC frames with a default access priority of 4. Annex I recommends that bridges forward LLC frames with a user_priority greater than 4 using a reservation equal to the user_priority. IEEE 802.1D [3] does allow network management to override this behavior, though 🙈 Features like User Priority and Reserved Priority can give real support to Integrated Services flows that need QoS guarantees, so this stuff really matters 🫶
For the different IP packet encapsulations over Token Ring/IEEE 802.5, you will need to adjust any admission control calculations for the framing requirements, shown in Table 3 🧮
Table 3: Token Ring encapsulations
---------------------------------------------------------------
Encapsulation Framing Overhead IP MTU
bytes/pkt bytes
---------------------------------------------------------------
IP EtherType over 802.1D/Q 29 4370*
IP EtherType over LLC/SNAP 25 4370*
---------------------------------------------------------------*The suggested MTU from RFC 1042 [13] is 4464 bytes, but there are issues with discovering the maximum supported MTU between any two points, both within and between Token Ring subnets 😭 The MTU reported here is consistent with the IEEE 802.5 Annex I recommendation.
4.4. Fiber Distributed Data Interface 🌸
Next up is FDDI, which is giving Token Ring energy (lowkey a lot of the same vibes). The Fiber Distributed Data Interface (FDDI) standard [16] has a priority mechanism that controls both queuing for transmission and packet access to the shared media. It uses mechanisms similar to the Token Ring ones we just went over ✨
FDDI also makes provision for "Synchronous" data traffic, which comes with strict media access and delay guarantees. That mode isn't discussed further here. It's an area within the scope of the ISSLL working group that still needs more work 🦋 For the rest of this document, when we talk about QoS mechanisms, FDDI gets treated as a 100 Mbps Token Ring technology that uses a service interface compatible with IEEE 802 networks. Slay for simplicity 💅
4.5. Demand Priority/IEEE 802.12 💜
IEEE 802.12 [19] is a standard for a shared 100 Mbps LAN 🌈 Its data packets are transmitted using either the IEEE 802.3 or the IEEE 802.5 frame format. The MAC protocol is called Demand Priority. Its main QoS features are support for two service priority levels, normal priority and high priority, plus the order of service for each of those. Data packets from every network node, whether end hosts or bridges/switches, are served using a simple round robin algorithm 🔁
If the IEEE 802.3 frame format is used for data transmission, the user_priority is encoded in the starting delimiter of the IEEE 802.12 data packet 🎀 If the IEEE 802.5 frame format is used, the user_priority is additionally encoded in the YYY bits of the FC field in the IEEE 802.5 packet header (see also Section 4.3). On top of that, the IEEE 802.1Q encapsulation with its own user_priority field may also be applied in IEEE 802.12 networks. In all cases, switches are able to recover any user_priority supplied by a sender 🙌
The same rules apply for IEEE 802.12 user_priority mapping in a bridge as they do with other media types. The only extra info is that normal priority is used by default for user_priority values 0 through 4 inclusive, and high priority is used for user_priority levels 5 through 7. This makes sure the default Token Ring user_priority level of 4 for IEEE 802.5 bridges maps to normal priority on IEEE 802.12 segments 🍓
The medium access in IEEE 802.12 LANs is deterministic 🧚 The Demand Priority mechanism makes sure that, once the normal priority service has been preempted, all high priority packets have strict priority over packets with normal priority. And if a normal priority packet has been waiting at the head of line of a MAC transmit queue for longer than PACKET_PROMOTION (200 - 300 ms) [19], its priority gets automatically promoted to high priority. So even normal priority packets have a maximum guaranteed access time to the medium. Iconic, honestly 👑
Integrated Services can be built on top of the IEEE 802.12 medium access mechanism. When it's combined with admission control and bandwidth enforcement mechanisms, delay guarantees like the ones a Guaranteed Service requires can be provided without any changes to the existing IEEE 802.12 MAC protocol ✨
Since the IEEE 802.12 standard supports both the IEEE 802.3 and IEEE 802.5 frame formats, the same framing overhead reported in Sections 4.2 and 4.3 must be considered in the admission control computations for IEEE 802.12 links 🧮 Don't skip it, bestie 🫶
5. Requirements and Goals 🎯
This section talks about the requirements and goals that should drive the design of an architecture for supporting Integrated Services over LAN technologies 💖 Requirements are the functions and features that must be supported. Goals are the functions and features that are desirable but not an absolute necessity. Lots of the requirements and goals come from the functionality that Integrated Services and RSVP support 🌸
5.1. Requirements 💖
- Resource Reservation: okay so the mechanism MUST be capable of reserving resources on a single segment or multiple segments, and at the bridges/switches connecting them 🌸. It MUST be able to provide reservations for both unicast and multicast sessions. It SHOULD be possible to change the level of reservation while the session is in progress ✨.
- Admission Control: the mechanism MUST be able to estimate how many resources it takes to meet the QoS the session asked for, so it can decide whether or not the session gets in 💅. For management purposes, it's useful to be able to answer questions about whether resources are available 🫶. It MUST be able to make admission control decisions for different types of services, like Guaranteed Service, Controlled Load, etc. 🦋.
- Flow Separation and Scheduling: we need a way to separate traffic flows so real time flows get the VIP treatment over best effort flows 👑. Packets from real time flows can then be isolated and scheduled based on what their service needs are 🎀.
- Policing/Shaping: traffic MUST be shaped and/or policed by end stations (workstations, routers) so it stays within the negotiated traffic parameters 🔥. Shaping is the RECOMMENDED behavior for traffic sources 💜. A router that starts an ISSLL session MUST have implemented traffic control mechanisms that follow the IntServ requirements, so every flow it sends stays in conformance 🧚. The ISSLL mechanisms at the link layer lean really hard on higher layer devices correctly doing policing/shaping, because bridges and switches usually can't keep per flow state, which they'd need to check flows for conformance 💀. Policing is left as an option for bridges and switches, and if they implement it, it MAY be used to enforce tighter control over traffic flows 🌈. This issue is discussed more in Section 8 🍓.
- Soft State: the mechanism MUST maintain soft state info about the reservations 🌸. That means state info MUST periodically be refreshed if the reservation is going to stick around; otherwise the state info and the reservations that go with it will expire after some pre-specified interval 😭.
- Centralized or Distributed Implementation: with a centralized setup, one entity manages the resources of the whole subnet ✨. This is easier to deploy, since bridges and switches MAY not need to be upgraded with extra functionality 🫶. BUT it scales poorly as the subnet gets bigger geographically and as more end stations get attached 🙈. In a fully distributed setup, each segment has its own local entity managing its resources 🦋. That scales better than the former, but ALL bridges and switches in the network have to support the new mechanisms 💅. You can also have a semi-distributed setup, with more than one entity, each managing the resources of a subset of segments and bridges/switches in the subnet 🧚. Ideally, implementation SHOULD be flexible, so a centralized approach MAY be used for small subnets and a distributed approach can be used for larger ones 👑. Examples of both are in Section 6 🎀.
- Scalability: the mechanism and protocols SHOULD have low overhead and SHOULD scale to the biggest receiver groups likely to show up in a single link layer domain 🔥.
- Fault Tolerance and Recovery: the mechanism MUST be able to keep working when stuff fails, meaning there SHOULD NOT be a single point of failure 💀. For example, in a centralized setup, some mechanism MUST be specified for backup and recovery if something goes wrong 😭.
- Interaction with Existing Resource Management Controls: we have to spell out how this works with the infrastructure that already exists for resource management 🌈. For example, FDDI has a resource management mechanism called the "Synchronous Bandwidth Manager" 🍓. The mechanism MUST be designed so it takes advantage of existing controls where they're available, and specifies how it interacts with them ✨.
5.2. Goals 🌸
- Independence from higher layer protocols: the mechanism SHOULD, as far as possible, be independent of higher layer protocols like RSVP and IP 💖. Being independent from RSVP is desirable so it can work with other reservation protocols like ST2 [10] 🦋. Being independent from IP is desirable so it can work with other network layer protocols like IPX, NetBIOS, etc. 🧚.
- Receiver heterogeneity: this is about multicast communication where different receivers ask for different levels of service 👑. For example, in a multicast group with lots of receivers, one of them might want a lower delay bound than the rest 🙈. A better delay bound MAY be provided by increasing the amount of resources reserved along the path to that receiver, while leaving the reservations for the other receivers unchanged 🎀. In its most complex form, receiver heterogeneity means being able to provide several levels of service at the same time, as requested by different receivers 🔥. In its simplest form, some receivers use best effort service and the ones that need guarantees make a reservation 💅. Receiver heterogeneity, especially for the reserved/best effort scenario, is a seriously desirable feature 😭. More details on supporting it are in Section 8 🍓.
- Support for different filter styles: it's desirable to support the different filter styles RSVP defines, like fixed filter, shared explicit, and wildcard 🌈. Some of the issues with supporting those filter styles in the link layer domain are looked at in Section 8 ✨.
- Path Selection: in source routed LAN technologies like Token Ring/IEEE 802.5, it MAY be useful for the mechanism to include path selection 💜. Using an appropriate path selection mechanism MAY optimize how network resources get used 🫶.
5.3. Non-goals 🦋
This document describes service mappings onto existing IEEE and ANSI defined standard MAC layers, and it uses standard MAC layer services like in IEEE 802.1 bridging 💅. It doesn't try to use or describe what other proprietary or standard MAC layer protocols can do 🧚. That said, it SHOULD be noted that published work about MAC layers suitable for QoS mappings exists 👑. All of that is outside the scope of the ISSLL working group charter 🙈.
5.4. Assumptions 🎀
This framework assumes that typical subnetworks that care about QoS will be "switch rich" 🔥. In other words, most communication between end stations using integrated services support is expected to pass through at least one switch 💀. The mechanisms and protocols described here will be trivially extensible to systems talking on the same shared medium, but it's important not to let the problem get generalized in a way that complicates the targeted practical application to switch rich LAN topologies 😭. There have also been developments in MAC enhancements that make delay deterministic access on network links possible, like IEEE 802.12 [19], plus some proprietary schemes 🌈.
We illustrate most examples for this model using RSVP as the upper layer QoS signaling protocol, but there are honestly no real dependencies on it 🍓. RSVP could be replaced by some other dynamic protocol, or the requests could come from network management or other policy entities ✨. The SBM signaling protocol [14], which is based on RSVP, is designed to work seamlessly in the architecture described in this memo 🌸.
There MAY be a heterogeneous mix of switches with different capabilities, all compliant with IEEE 802.1D [2,3], but implementing different queuing and forwarding mechanisms 💖. That ranges from simple systems with two queues per port and static priority scheduling, to more complex systems with multiple queues using WFQ or other algorithms 🦋.
The problem is broken into smaller independent parts, which may lead to sub-optimal use of network resources 🧚. We contend that those benefits are often equivalent to a very small improvement in network efficiency in a LAN environment 👑. So it's a goal that the switches in a network operate on a much simpler set of information than the RSVP engine in a router 🙈. In particular, it's assumed that such switches don't need to implement per flow queuing and policing, although they aren't precluded from doing so 🎀.
A fundamental assumption of the IntServ model is that flows stay isolated from each other the whole time they're crossing a network 🔥. Intermediate queuing nodes are expected to shape or police traffic so it stays in conformance with the negotiated traffic flow specification 💅. For the architecture proposed here, mapping to Layer 2, we diverge from that assumption in the interest of simplicity 😭. The policing/shaping functions are assumed to be implemented in end stations 🌈. In some LAN environments it's reasonable to assume end stations are trusted to stick to their negotiated contracts at the inputs to the network, and that we can afford to over-allocate resources during admission control to make up for the inevitable packet jitter/bunching the switched network introduces itself 🍓. This divergence has some implications for the types of receiver heterogeneity that can be supported, and for the statistical multiplexing gains that MAY be exploited, especially for Controlled Load flows ✨. This is discussed in Section 8.7 of this document 💜.
6. Basic Architecture 🧚
The functional requirements described in Section 5 will be performed by an entity we refer to as the Bandwidth Manager (BM) 💖. The BM is responsible for providing mechanisms for an application or higher layer protocol to request QoS from the network 🦋. For architectural purposes, the BM consists of the following components 🫶.
6.1. Components 🌸
6.1.1. Requester Module ✨
okay so the Requester Module (RM) lives in every single end station in the subnet 💅. Its main job is being the middle layer between applications or higher layer protocols (like RSVP, ST2, SNMP, etc.) and the BM 🫶. An app calls the BM's functions by using the primitives for talking to the RM and handing it the right parameters.
To start a reservation at the link layer, you have to pass the RM three things: the service you want (Guaranteed Service or Controlled Load), the traffic descriptors in the TSpec, and an RSpec saying how many resources to reserve [9]. More deets on these are in the Integrated Services docs [6,7,8,9]. When RSVP does signaling at the network layer, this info is already there and just needs to be pulled out of the RSVP PATH and RSVP RESV messages (see [5] for the full tea) 🍵. On top of all that, the network layer addresses of the endpoints have to be specified too. Then the RM has to translate those network layer addresses into link layer addresses and convert the request into a format that the other BM components responsible for admission control actually understand 🔥. The RM is also the one that sends the status of requests processed by the BM back to the app or higher layer protocol that asked 💜.
6.1.2. Bandwidth Allocator ✨
The Bandwidth Allocator (BA) is the boss of admission control 👑. It keeps track of the allocation of resources in the subnet. An end station can ask for all kinds of stuff: bandwidth reservations, modifying an existing reservation, queries about resource availability, etc. The BA processes all of these requests, and the end station talks to it through the RM 🧚.
Where the BA lives depends a lot on how you implement things. In a centralized setup, the BA may sit on a single station in the subnet. In a distributed setup, its functions can be spread across all the end stations and bridges/switches as necessary 🌸. The BA is also responsible for deciding how to label flows. For example, after an admission control decision, the BA may tell the RM that packets belonging to a particular flow should be tagged with some priority value that maps to the right traffic class 🏷️.
6.1.3. Communication Protocols ✨
The protocols for communication between the various components of the BM system have to be specified. Here's the lineup:
- Communication between the higher layer protocols and the RM: The BM must define primitives so the application can start reservations, query the BA about available resources, change or delete reservations, etc. These primitives could be implemented as an API that lets an application call BM functions through the RM 💖.
- Communication between the RM and the BA: A signaling mechanism must be defined for talking between the RM and the BA. This protocol specifies the messages that must be exchanged between the RM and the BA to service the various requests from the higher layer entity 📨.
- Communication between peer BAs: If there's more than one BA in the subnet, a way for them to communicate must be specified. The BAs must be able to decide among themselves which BA is responsible for which segments and bridges or switches. Also, if a request for resource reservation spans the domain of multiple BAs, the BAs must be able to handle that scenario correctly. Inter-BA communication is also responsible for back-up and recovery if there's a failure 🛟.
6.2. Centralized vs. Distributed Implementations ✨
Here are example scenarios showing where the components of the bandwidth manager live in centralized and fully distributed implementations. Note that in either case, the RM must be present in all end stations that need to make reservations. Basically, centralized or distributed refers to how the BA is implemented. The BA is the component responsible for resource reservation and admission control 🎀. In the figures below, "App" means the application making use of the BM. It could be a user application or a higher layer protocol process like RSVP.
.-->| BA |<--.
/ +---------+ \
/ .-->| Layer 2 |<--. \
/ / +---------+ \ \
/ / \ \
/ / \ \
+---------+ / / \ \ +---------+
| App |<----- /-/---------------------------\-\----->| App |
+---------+ / / \ \ +---------+
| RM |<----. / \ .--->| RM |
+---------+ / +---------+ +---------+ \ +---------+
| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |
+---------+ +---------+ +---------+ +---------+
RSVP Host/ Intermediate Intermediate RSVP Host/
Router Bridge/Switch Bridge/Switch Router
Figure 1: Bandwidth Manager with centralized Bandwidth AllocatorFigure 1 shows a centralized setup where a single BA is responsible for admission control decisions for the entire subnet. Every end station has an RM. Intermediate bridges and switches don't need any BM functions, since they aren't actively participating in admission control. The RM at the end station requesting a reservation starts communicating with its BA.
For larger subnets, a single BA might not be able to handle the reservations for the whole subnet. In that case, you'd deploy multiple BAs, each managing the resources of a non-overlapping subset of segments. In a centralized implementation, the BA has to have some knowledge of the Layer 2 topology of the subnet, e.g. link layer spanning tree information, so it can reserve resources on the right segments. Without this topology information, the BM would have to reserve resources on all segments for all flows. In a switched network, that would lead to very inefficient use of resources 😭.
+---------+ +---------+
| App |<-------------------------------------------->| App |
+---------+ +---------+ +---------+ +---------+
| RM/BA |<------>| BA |<------>| BA |<------>| RM/BA |
+---------+ +---------+ +---------+ +---------+
| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |
+---------+ +---------+ +---------+ +---------+
RSVP Host/ Intermediate Intermediate RSVP Host/
Router Bridge/Switch Bridge/Switch Router
Figure 2: Bandwidth Manager with fully
distributed Bandwidth AllocatorFigure 2 is the fully distributed bandwidth manager. In this case, every device in the subnet has BM functionality. All the end hosts still need an RM, and on top of that, every station actively takes part in admission control 🧩. With this approach, each BA only needs local topology information, since it's responsible for the resources on segments directly connected to it. This local info (like a list of ports active on the spanning tree and which unicast addresses are reachable from which ports) is readily available in today's switches ✨. Also, in the figures above, the arrows between peer layers are used to show logical connectivity 🦋.
7. Model of the Bandwidth Manager in a Network ✨
In this section we describe how the model above fits with the existing IETF Integrated Services model of IP hosts and routers. First, we cover Layer 3 host and router implementations. Next, we describe how the model applies in Layer 2 switches. Throughout, we point out any differences between centralized and distributed implementations. Occasional references are made to terminology from the Subnet Bandwidth Manager specification [14].
7.1. End Station Model ✨
7.1.1. Layer 3 Client Model ✨
We assume the same client model as IntServ and RSVP, where we use the term "client" to mean the entity handling QoS in the Layer 3 device at each end of a Layer 2 Domain. In this model, the sending client is responsible for local admission control and packet scheduling onto its link in accordance with the negotiated service. As with the IntServ model, this involves per flow scheduling with possible traffic shaping/policing in every such originating node 🚀.
For now, we assume the client runs an RSVP process that presents a session establishment interface to applications, provides signaling over the network, programs a scheduler and classifier in the driver, and interfaces to a policy control module. In particular, RSVP also interfaces to a local admission control module, which is the focus of this section 🎯.
The following figure, reproduced from the RSVP specification, depicts the RSVP process in sending hosts 📦.
+-----------------------------+
| +-------+ +-------+ | RSVP
| |Appli- | | RSVP <------------------->
| | cation<--> | |
| | | |process| +-----+|
| +-+-----+ | +->Polcy||
| | +--+--+-+ |Cntrl||
| |data | | +-----+|
|===|===========|==|==========|
| | +--------+ | +-----+|
| | | | +--->Admis||
| +-V--V-+ +---V----+ |Cntrl||
| |Class-| | Packet | +-----+|
| | ifier|==>Schedulr|===================>
| +------+ +--------+ | data
+-----------------------------+
Figure 3: RSVP in Sending Hosts7.1.2. Requests to Layer 2 ISSLL ✨
The local admission control entity within a client is responsible for mapping Layer 3 session establishment requests into Layer 2 semantics 🧠.
The upper layer entity makes a request to ISSLL in generalized terms. It's basically asking:
"May I reserve for traffic with <traffic characteristic> with
<performance requirements> from <here> to <there> and how should I
label it?"where
<traffic characteristic> = Sender Tspec (e.g. bandwidth, burstiness,
MTU)
<performance requirements> = FlowSpec (e.g. latency, jitter bounds)
<here> = IP address(es)
<there> = IP address(es) - may be multicast7.1.3. At the Layer 3 Sender ✨
okay bestie, now we're on the sending side 💖 The ISSLL stuff happening in the sender is drawn out in Figure 4, so peep that 🦋
The Requester Module is lowkey the main character here 👑 Its jobs go like this:
- Maps the endpoints of the conversation to Layer 2 addresses in the LAN, so the client can figure out what traffic is going where 🗺️ This function probably makes reference to the ARP protocol cache for unicast, or performs an algorithmic mapping for multicast destinations.
- Communicates with any local Bandwidth Allocator module for local admission control decisions 🤝
- Formats a SBM request to the network with the mapped addresses and flow/filter specs 📨
- Receives a response from the network and reports the admission control decision to the higher layer entity, along with any negotiated modifications to the session parameters ✅
- Saves any returned
user_priorityto be associated with this session in a"802 header"table 🎀 This gets used when constructing the Layer 2 headers for future data packets belonging to this session. This table might, for example, be indexed by the RSVP flow identifier.
from IP from RSVP
+----|------------|------------+
| +--V----+ +---V---+ |
| | Addr <---> | | SBM signaling
| |mapping| |Request|<----------------------->
| +---+---+ |Module | |
| | | | |
| +---+---+ | | |
| | 802 <---> | |
| | header| +-+-+-+-+ |
| +--+----+ / | | |
| | / | | +-----+ |
| | +-----+ | +->|Band-| |
| | | | |width| |
| +--V-V-+ +-----V--+ |Alloc| |
| |Class-| | Packet | +-----+ |
| | ifier|==>Schedulr|=========================>
| +------+ +--------+ | data
+------------------------------+
Figure 4: ISSLL in a Sending End StationThe Bandwidth Allocator (BA) component is only present when a distributed BA model is implemented 🧁 When it's there, its function is basically to apply local admission control for the outgoing link bandwidth and driver's queuing resources.
7.1.4. At the Layer 3 Receiver ✨
The ISSLL functionality in the receiver is simpler (yay for less drama 🫶) and is illustrated in Figure 5.
The Requester Module's jobs on this side are:
- Handles any received SBM protocol indications 📬
- Communicates with any local BA for local admission control decisions 🤝
- Passes indications up to RSVP if OK ✅
- Accepts confirmations from RSVP and relays them back via SBM signaling towards the requester 🔁
to RSVP to IP
^ ^
+----|------------|------+
| +--+----+ | |
SBM signaling | |Request| +---+---+ |
<-------------> |Module | | Strip | |
| +--+---++ |802 hdr| |
| | \ +---^---+ |
| +--v----+\ | |
| | Band- | \ | |
| | width| \ | |
| | Alloc | . | |
| +-------+ | | |
| +------+ +v---+----+ |
data | |Class-| | Packet | |
<==============>| ifier|==>|Scheduler| |
| +------+ +---------+ |
+------------------------+
Figure 5: ISSLL in a Receiving End Station- May program a receive classifier and scheduler, if used, to identify traffic classes of received packets and accord them appropriate treatment e.g., reservation of buffers for particular traffic classes 🪣
- Programs the receiver to strip away link layer header information from received packets 🧹
The Bandwidth Allocator, which only shows up in a distributed implementation, applies local admission control to see if a request can be supported with appropriate local receive resources 💅
7.2. Switch Model 🍓
7.2.1. Centralized Bandwidth Allocator 🦋
Where a centralized Bandwidth Allocator model is implemented, switches do not take part in the admission control process 🙅♀️ Admission control is handled by a centralized BA, e.g., a "Subnet Bandwidth Manager" (SBM) as described in [14]. This centralized BA may actually be co-located with a switch, but its functions would not necessarily then be closely tied with the switch's forwarding functions, which is the case with the distributed BA described below.
7.2.2. Distributed Bandwidth Allocator 💜
The model of Layer 2 switch behavior described here uses the terminology of the SBM protocol as an example of an admission control protocol. The model is equally applicable when other mechanisms, e.g. static configuration or network management, are in use for admission control 🌈 We define the following entities within the switch:
- Local Admission Control Module: One of these on each port accounts for the available bandwidth on the link attached to that port. For half duplex links, this involves taking account of the resources allocated to both transmit and receive flows. For full duplex links, the input port accountant's task is trivial 🧮
- Input SBM Module: One instance on each port performs the "network" side of the signaling protocol for peering with clients or other switches. It also holds knowledge about the mappings of IntServ classes to
user_priority🧠 - SBM Propagation Module: Relays requests that have passed admission control at the input port to the relevant output ports' SBM modules. This will require access to the switch's forwarding table (Layer-2 "routing table" cf. RSVP model) and port spanning tree state 🌳
- Output SBM Module: Forwards requests to the next Layer 2 or Layer 3 hop ➡️
- Classifier, Queue and Scheduler Module: The functions of this module are basically as described by the Forwarding Process of IEEE 802.1D (see Section 3.7 of [3]). The Classifier module identifies the relevant QoS information from incoming packets and uses this, together with the normal bridge forwarding database, to decide at which output port and traffic class to enqueue the packet. Different types of switches will use different techniques for flow identification (see Section 8.1). In IEEE 802.1D switches this information is the regenerated
user_priorityparameter, which has already been decoded by the receiving MAC service and potentially remapped by the forwarding process (see Section 3.7.3 of [3]). This does not preclude more sophisticated classification rules, such as the classification of individual IntServ flows. The Queue and Scheduler implement the output queues for ports and provide the algorithm for servicing the queues for transmission onto the output link, in order to provide the promised IntServ service. Switches will implement one or more output queues per port, and all will implement at least a basic static priority dequeuing algorithm as their default, in accordance with IEEE 802.1D 🚦 - Ingress Traffic Class Mapping and Policing Module: Its functions are as described in IEEE 802.1D Section 3.7. This optional module may police the data within traffic classes for conformance to the negotiated parameters, and may discard packets or re-map the
user_priority. The default behavior is to pass things through unchanged 🛂 - Egress Traffic Class Mapping Module: Its functions are as described in IEEE 802.1D Section 3.7. This optional module may perform re-mapping of traffic classes on a per output port basis. The default behavior is to pass things through unchanged 🛫
Figure 6 shows all of the modules in an ISSLL enabled switch 🔍 The ISSLL model is a superset of the IEEE 802.1D bridge model, so it's giving "everything the bridge does, plus more" ✨
+-------------------------------+
SBM signaling | +-----+ +------+ +------+ | SBM signaling
<------------------>| IN |<->| SBM |<->| OUT |<---------------->
| | SBM | | prop.| | SBM | |
| +-++--+ +---^--+ /----+-+ |
| / | | / | |
______________| / | | | | +-------------+
| \ /+--V--+ | | +--V--+ / |
| \ ____/ |Local| | | |Local| / |
| \ / |Admis| | | |Admis| / |
| \/ |Cntrl| | | |Cntrl| / |
| +-----V+\ +-----+ | | +-----+ /+-----+ |
| |traff | \ +---+--+ +V-------+ / |egrss| |
| |class | \ |Filter| |Queue & | / |traff| |
| |map & |=====|==========>|Data- |=| Packet |=|===>|class| |
| |police| | | base| |Schedule| | |map | |
| +------+ | +------+ +--------+ | +-+---+ |
+----^---------+-------------------------------+------|------+
data in | |data out
========+ +========>
Figure 6: ISSLL in a Switch7.3. Admission Control ✨
Okay so when a switch gets an admission control request 💅, it runs through a few steps. We're using SBM as the example again 🧚. What it does depends on whether the "Designated SBM" for this segment lives inside this switch or not. If you want the full DSBM/SBM details, check out [14] 📚.
- Ingress SBM is the Designated SBM: it either translates any received user_priority, or it picks a Layer 2 traffic class that looks compatible with the request and whose use doesn't break any administrative policies in force. Basically it matches the requested service with the available traffic classes and chooses the "best" one 👑. It makes sure that, if the reservation works out, the user_priority value for that traffic class gets passed back to the client 🎀.
- Ingress DSBM checks resources: it observes the current state of resource allocation on the input port/link and decides whether the new resource allocation from the mapped traffic class can fit 📦. If it's accepted, the request goes to the reservation propagator 🚀.
- Ingress SBM is not the Designated SBM: it just passes the request straight on to the reservation propagator 🦋.
- Reservation propagator relays: it sends the request to the bandwidth accountants on each of the switch's outbound links that this reservation would apply to 📨. This implies an interface to the routing/forwarding database 🗂️.
- Egress bandwidth accountant checks: it observes the current state of allocation of queuing resources on its outbound port and bandwidth on the link itself, then decides whether the new allocation can be accommodated 🔍. Note that this is only a local decision at this switch hop. Further Layer 2 hops through the network may veto the request as it passes along 🙈.
- Forwarding: if this switch accepts the request, it gets propagated on each output link selected. Any user_priority described in the forwarded request must be translated according to any egress mapping table 🔁.
- Accepted: the switch must notify the client of the user_priority to be used for packets belonging to that flow. Again, this is an optimistic approach that assumes admission control succeeds, so downstream switches may still refuse the request 🤞.
- Rejected: if this switch wants to reject the request, it can do so by notifying the client that originated the request, using its Layer 2 address 🚫.
7.4. QoS Signaling 📡
Okay, the mechanisms in this document use a signaling protocol so devices can communicate their admission control requests across the network 🌐. The service definitions that such a protocol provides, e.g. [14], are described below. We illustrate the primitives and information that need to be exchanged with that signaling protocol entity 🧚. In all of the examples, appropriate delete/cleanup mechanisms will also have to be provided for tearing down established sessions 🧹.
7.4.1. Client Service Definitions 💖
The following interfaces can be identified from Figures 4 and 5 ✨.
- SBM <-> Address Mapping: this is a simple lookup function 🔍 which may require ARP protocol interactions or an algorithmic mapping. The Layer 2 addresses are needed by SBM for inclusion in its signaling messages, so that switches taking part in the signaling don't need Layer 3 information to do the mapping 🫶.
l2_addr = map_address( ip_addr )- SBM <-> Session/Link Layer Header: this is for notifying the transmit path how to add Layer 2 header information, e.g. user_priority values to the traffic of each outgoing flow 📤. The transmit path will provide the user_priority value when it requests a MAC layer transmit operation for each packet. The user_priority is one of the parameters passed in the packet transmit primitive defined by the IEEE 802 service model 💅.
bind_l2_header( flow_id, user_priority )- SBM <-> Classifier/Scheduler: this is for notifying the transmit classifier/scheduler of any additional Layer 2 information associated with scheduling the transmission of a packet flow 🗓️. This primitive may be unused in some implementations. Or it may be used, for example, to give information to a transmit scheduler that's doing per traffic class scheduling on top of the per flow scheduling required by IntServ. The Layer 2 header may be a pattern (in addition to the FilterSpec) used to identify the flow's traffic 🕵️♀️.
bind_l2schedulerinfo( flow_id, , l2_header, traffic_class )- SBM <-> Local Admission Control: this is used for applying local admission control for a session, e.g. is there enough transmit bandwidth still uncommitted for this new session? Are there sufficient receive buffers? 🤔 This should commit the necessary resources if it succeeds. It will be necessary to release these resources at a later stage if admission control fails at a subsequent node 😬. This call would be made, for example, by a segment's Designated SBM 👑.
status = admit_l2session( flow_id, Tspec, FlowSpec )- SBM <-> RSVP: this is outlined above in Section 7.1.2 and fully described in [14] 🦋.
- Management Interfaces: some or all of the modules described by this model will also require configuration management. It is expected that details of the manageable objects will be specified by future work in the ISSLL WG 🛠️.
7.4.2. Switch Service Definitions 🍓
The following interfaces are identified from Figure 6 ✨.
- SBM <-> Classifier: this is for notifying the receive classifier how to match incoming Layer 2 information with the associated traffic class 📥. It may in some cases consist of a set of read only default mappings.
bind_l2classifierinfo( flow_id, l2_header, traffic_class )- SBM <-> Queue and Packet Scheduler: this is for notifying the transmit scheduler of additional Layer 2 information associated with a given traffic class 🗂️. It may be unused in some cases (see discussion in previous section).
bind_l2schedulerinfo( flow_id, l2_header, traffic_class )- SBM <-> Local Admission Control: same as for the host discussed above 🔁.
- SBM <-> Traffic Class Map and Police: this is optional configuration of any user_priority remapping that might be implemented on ingress to and egress from the ports of a switch 🎛️. For IEEE 802.1D switches, it is likely that these mappings will have to be consistent across all ports 🌈.
bind_l2ingressprimap( inport, in_user_pri, internal_priority )
bind_l2egressprimap( outport, internal_priority, out_user_pri )This is also optional configuration of any Layer 2 policing function to be applied on a per class basis to traffic matching the Layer 2 header 🚦. If the switch is capable of per flow policing, then the existing IntServ/RSVP models will provide a service definition for that configuration 💜.
bind_l2policing( flow_id, l2_header, Tspec, FlowSpec )- SBM <-> Filtering Database: SBM propagation rules need access to the Layer 2 forwarding database to determine where to forward SBM messages 🧭. This is analogous to the RSRR interface in Layer 3 RSVP.
output_portlist = lookup_l2dest( l2_addr )- Management Interfaces: some or all of the modules described by this model will also require configuration management. It is expected that details of the manageable objects will be specified by future work in the ISSLL working group 🛠️.
8. Implementation Issues ✨
As stated earlier, the Integrated Services working group has defined various service classes offering varying degrees of QoS guarantees 🌸. Initial effort will concentrate on enabling the Controlled Load [6] and Guaranteed Service classes [7]. The Controlled Load service provides a loose guarantee, informally stated as "the same as best effort would be on an unloaded network" 🛣️. The Guaranteed Service provides an upper bound on the transit delay of any packet ⏱️.
The extent to which these services can be supported at the link layer will depend on many factors, including the topology and technology used. Some of the mapping issues are discussed below in light of the emerging link layer standards and the functions supported by higher layer protocols 🧩. Considering the limitations of some of the topologies, it may not be possible to satisfy all the requirements for Integrated Services on a given topology 😭. In such cases, it is useful to consider providing support for an approximation of the service, which may suffice in most practical instances 🍬. For example, it may not be feasible to provide policing/shaping at each network element (bridge/switch) as required by the Controlled Load specification. But if this task is left to the end stations, a reasonably good approximation to the service can be obtained 💻.
8.1. Switch Characteristics 🌈
There are many LAN bridges/switches with varied capabilities for supporting QoS 💜. We discuss below the various kinds of devices one may expect to find in a LAN environment 🔎.
The most basic bridge is one which conforms to the IEEE 802.1D specification of 1993 [2]. This device has a single queue per output port and uses the spanning tree algorithm to eliminate topology loops 🌳. Networks built from this kind of device can't be expected to provide service guarantees of any kind, because of the complete lack of traffic isolation 💀.
The next level of bridges/switches are those which conform to the more recently revised IEEE 802.1D specification [3]. They include support for queuing up to eight traffic classes separately 🎀. The level of traffic isolation provided is coarse, because all flows corresponding to a particular traffic class are aggregated. Further, it is likely that more than one priority will map to a traffic class, depending on the number of queues implemented in the switch 🫠. It would be difficult for such a device to offer protection against misbehaving flows 😤. The scope of multicast traffic may be limited by using GMRP to reach only those segments on the path to interested receivers 📡.
A step above these devices are bridges/switches that implement optional parts of the IEEE 802.1D specification, such as mapping the received user_priority to some internal set of canonical values on a per-input-port basis 🔄. They may also support mapping these internal canonical values onto transmitted user_priority on a per-output-port basis. With these extra capabilities, network administrators can map traffic classes between specific pairs of ports, and in doing so gain more control over admission of traffic into the protected classes 👑.
Other entirely optional features that some bridges/switches may support include classification of IntServ flows using fields in the network layer header 🕵️♀️. They may also offer per-flow policing and/or reshaping, which is essential for supporting Guaranteed Service 🚦, and more sophisticated scheduling algorithms, such as variants of weighted fair queuing, to limit the bandwidth consumed by a traffic class 🧁. Note that it is advantageous to perform flow isolation and for all network elements to police each flow in order to support the Controlled Load and Guaranteed Service 🫶.
8.2. Queuing 🎀
okay so connectionless packet networks, and LANs especially, basically work today because of how people provision them 💅. There's usually extra bandwidth and buffering sitting around to soak up traffic from higher layer protocols. It's often enough that their transmission windows run out on a statistical basis, so overloads are rare and transient and the expected loading is super low ✨.
But with time-critical traffic showing up, over-provisioning is way harder to pull off 😭. Time-critical frames can get stuck waiting for annoyingly long stretches behind temporary bursts of file transfer traffic, especially at bottleneck points, e.g. at the 100 Mbps to 10 Mbps transition between the riser to the wiring closet and the final link to the user from a desktop switch. If it's known a priori (by application design, statistics, or administrative control) that time-critical traffic is a small fraction of the total bandwidth, then it's enough to give it strict priority over the non-time-critical traffic 💖. The worst case delay for time-critical traffic is roughly the maximum transmission time of a maximum length non-time-critical frame. That's less than a millisecond for 10 Mbps Ethernet, and well below the end to end delay budget based on human perception times 🙈.
When a network element offers more than one priority service, e.g. one supporting both Controlled Load and Guaranteed Service, the requirements for the scheduling discipline get more complex 🧚. To get the required isolation between the service classes, it'll probably be necessary to queue them separately. Then there's the question of how to service those queues, which takes a mix of admission control and more intelligent queuing disciplines. Like with the service specifications themselves, specifying queuing algorithms is beyond the scope of this document 🌸.
8.3. Mapping of Services to Link Level Priority
The number of traffic classes supported and the access methods of the technology under consideration decide how many and which services can be supported 👑. Native Token Ring/IEEE 802.5, for instance, has eight priority levels that can be mapped to one or more traffic classes. Ethernet/IEEE 802.3 has no support for signaling priorities within frames 😬. BUT the IEEE 802 standards committee has recently developed a new standard for bridges/switches related to multimedia traffic expediting and dynamic multicast filtering [3]. A packet format for carrying a user_priority field on all IEEE 802 LAN media types is now defined in [4]. These standards allow for up to eight traffic classes on all media ✨.
The user_priority bits carried in the frame get mapped to a particular traffic class within a bridge/switch. The user_priority is signaled on an end-to-end basis, unless bridge/switch management overrides it. The traffic class a flow uses should depend on the quality of service desired and on whether the reservation is successful or not 🦋. So a sender should use the user_priority value that maps to the best effort traffic class until the BM tells it otherwise. Once resource reservation completes successfully, the BM will specify the user_priority value the sender should use for that session's data 💅. An accompanying memo [13] addresses how to map the various Integrated Services to appropriate traffic classes.
8.4. Re-mapping of Non-conforming Aggregated Flows
Another hot topic in the IntServ context is how to handle traffic from data flows whose sources go over their negotiated traffic contract with the network 🚫. An approach that shows some promise is treating that traffic with "somewhat less than best effort" service, so that normal best effort traffic doesn't have to back off. Best effort traffic is often adaptive, using TCP or other congestion control algorithms, and it would be unfair to penalize those flows because of badly behaved traffic from reserved flows, which are often set up by non-adaptive applications 😤.
One possible solution is to assign normal best effort traffic to one user_priority and label the excess non-conforming traffic as a lower user_priority. But the re-ordering problems that might come from this may make it undesirable, particularly if the flows are using TCP 💀. For this reason, the controlled load service recommends dropping excess traffic rather than re-mapping it to a lower priority. This is discussed further below 🎀.
8.5. Override of Incoming User Priority
Sometimes a network administrator doesn't trust the user_priority values in packets from a source and wants to map them into a more suitable set of values 🫶. Or, due perhaps to equipment limitations or transition periods, the user_priority values may need to be re-mapped as the data flows to and from different regions of a network 🌈.
Some switches may implement a function on input that maps the received user_priority to some internal set of values. This function is provided by a table known in IEEE 802.1D as the User Priority Regeneration Table (Table 3-1 in [3]). These values can then be mapped, using an output table described above, onto outgoing user_priority values. These same mappings must also be used when applying admission control to requests that use the user_priority values (see e.g. [14]). More sophisticated approaches are also possible, where a device polices traffic flows and adjusts their onward user_priority based on their conformance to the admitted traffic flow specifications ⭐.
8.6. Different Reservation Styles
Okay, check out this figure 👀. In it, SW is a bridge/switch in the link layer domain. S1, S2, S3, R1 and R2 are end stations that are members of a group associated with the same RSVP flow. S1, S2 and S3 are the upstream end stations. R1 and R2 are the downstream end stations, and they receive traffic from all the senders 🧚. RSVP lets receivers R1 and R2 specify reservations that can apply to: (a) one specific sender only (fixed filter); (b) any of two or more explicitly specified senders (shared explicit filter); and (c) any sender in the group (shared wildcard filter) 💜.
Support for the fixed filter style is straightforward, since a separate reservation is made for the traffic from each sender. The other two filter styles are more complicated, though, because they affect policing. The merged flow from the different senders must be policed so that it conforms to the traffic parameters specified in the filter's RSpec. This gets even more complicated if the services requested by R1 and R2 are different 😵. So, in the absence of policing within bridges/switches, it may only be possible to support fixed filter reservations at the link layer 🌸.
+-----+ +-----+ +-----+
| S1 | | S2 | | S3 |
+-----+ +-----+ +-----+
| | |
| v |
| +-----+ |
+--------->| SW |<---------+
+-----+
| |
+----+ +----+
| |
v V
+-----+ +-----+
| R1 | | R2 |
+-----+ +-----+
Figure 7: Illustration of filter styles8.7. Receiver Heterogeneity ✨
Okay so at Layer 3, the IntServ model is totally fine with heterogeneous receivers for multicast flows 🦋. Different branches of the same tree can have different types of reservations for one multicast destination. It's also giving "some branches get reserved flows and some just get best effort service" 💅. If we treat a Layer 2 subnet as a single network element (as defined in [8]), then every branch of the distribution tree inside that subnet can be assumed to need the same QoS treatment, so they all get handled as one atomic unit for admission control and friends 🎀. With that assumption, IntServ and RSVP already give enough support for multicast heterogeneity 🫶. Ngl, the catch is that an admission control request can get rejected just because one link in the subnet is oversubscribed, and then the reservation for the WHOLE subnet is toast 😭.
Let's look at Figure 8. SW is a Layer 2 device (bridge/switch) taking part in resource reservation, S is the upstream source end station, and R1 and R2 are downstream end station receivers. R1 wants a reservation for the flow, while R2 wants to receive the flow as best effort service. S sends RSVP PATH messages that are multicast to both R1 and R2. R1 sends an RSVP RESV message to S requesting the reservation of resources.
+-----+
| S |
+-----+
|
v
+-----+ +-----+ +-----+
| R1 |<-----| SW |----->| R2 |
+-----+ +-----+ +-----+
Figure 8: Example of receiver heterogeneityIf the reservation is successful at Layer 2, the frames addressed to the group will be categorized in the traffic class that matches the service R1 asked for 🌸. At SW, there must be some mechanism that forwards the packet with the service matching the reserved traffic class on the interface to R1, while using the best effort traffic class on the interface to R2. This may involve changing the contents of the frame itself, or ignoring the frame priority at the interface to R2 🧚.
Another possibility for supporting heterogeneous receivers would be to have separate groups with distinct MAC addresses, one for each class of service 💜. By default, a receiver would join the "best effort" group, where the flow is classified as best effort. If the receiver makes a reservation successfully, it can be transferred to the group for the class of service it wants. The dynamic multicast filtering capabilities of bridges and switches implementing the IEEE 802.1D standard would be a very useful feature in this scenario ✨. A given flow would be transmitted only on those segments that are on the path between the sender and the receivers of that flow. The obvious disadvantage is that the sender needs to send out multiple copies of the same packet, one for each class of service desired, which can potentially duplicate the traffic on a portion of the distribution tree 😬.
The above approaches would provide very sub-optimal utilization of resources, given the expected size and complexity of Layer 2 subnets 🙈. So it's desirable to let switches apply QoS differently on different egress branches of a tree that divide at that switch 👑.
IEEE 802.1D specifies a basic model for multicast, where a switch makes multicast forwarding decisions based on the destination address. This produces a list of output ports to which the packet should be forwarded. In its default mode, such a switch uses the user_priority value in received packets, or a value regenerated on a per input port basis when there's no explicit value, to enqueue the packets at each output port 🍓. Any IEEE 802.1D switch that supports multiple traffic classes can support this operation 💅.
If a switch selects per port output queues based only on the incoming user_priority, as described by IEEE 802.1D, it must treat all branches of all multicast sessions within that user_priority class with the same queuing mechanism. Receiver heterogeneity is then not possible, and this could well lead to the failure of an admission control request for the whole multicast session because of a single oversubscribed link 💀. Note that in the Layer 2 case, unlike the Layer 3 case with RSVP/IntServ, the option of having some receivers get the session with the requested QoS and others get it best effort does not exist, since basic IEEE 802.1 switches are unable to re-map the user_priority on a per link basis. This could become an issue with heavy use of dynamic multicast sessions 😭.
If a switch were to implement a separate user_priority mapping at each output port, then in some cases reservations can use a different traffic class on different paths that branch at such a switch, in order to provide multiple receivers with different QoS 🌈. This is possible if all flows within a traffic class at the ingress to a switch egress in the same traffic class on a port. For example, traffic may be forwarded using user_priority 4 on one branch, where receivers have performed admission control, and as user_priority 0 on ones where they have not 🦋. We assume that per user_priority queuing, without taking account of input or output ports, is the minimum standard functionality for switches in a LAN environment (IEEE 802.1D). More functional Layer 2 or even Layer 3 switches (i.e. routers) can be used if even more flexible forms of heterogeneity are considered necessary to achieve more efficient resource utilization 🔥. The behavior of Layer 3 switches in this context is already well standardized by the IETF 🎀.
9. Network Topology Scenarios ✨
The extent to which service guarantees can be provided by a network depends to a large degree on the ability to provide the key functions of flow identification and scheduling, in addition to admission control and policing 💖. This section talks about some of the capabilities of the LAN technologies under consideration and gives a taxonomy of possible topologies, emphasizing what each one can do for those functions. For the technologies considered here, the basic topology of a LAN may be shared, switched half duplex, or switched full duplex 🌸.
In the shared topology, multiple senders share a single segment. Contention for media access is resolved using protocols such as CSMA/CD in Ethernet and token passing in Token Ring and FDDI 🧚. Switched half duplex is basically a shared topology with the restriction that there are only two transmitters contending for resources on any segment 🍓. Finally, in a switched full duplex topology, a full bandwidth path is available to the transmitter at each end of the link at all times 🦋. So in this topology there's no need for any access control mechanism like CSMA/CD or token passing, since there's no contention between the transmitters. Obviously, this topology gives the best QoS capabilities 👑.
Another important element is whether or not there's support for multiple traffic classes. These were discussed earlier in Section 4.1 💅. Depending on the basic topology used and the ability to support traffic classes, we identify six scenarios as follows:
- Shared topology without traffic classes.
- Shared topology with traffic classes.
- Switched half duplex topology without traffic classes.
- Switched half duplex topology with traffic classes.
- Switched full duplex topology without traffic classes.
- Switched full duplex topology with traffic classes.
There's also the possibility of hybrid topologies, where two or more of the above coexist 🌈. For instance, within a single subnet there might be some switches that support traffic classes and some that don't. If the flow in question traverses both kinds of switches in the network, the least common denominator will prevail 😭. In other words, as far as that flow is concerned, the network is of the type corresponding to the least capable topology that is traversed. In the following sections, we go into these scenarios in more detail for some of the different IEEE 802 network types, with discussion of their abilities to support the IntServ services 🫶.
9.1. Full Duplex Switched Networks
On a full duplex switched LAN, the MAC protocol doesn't matter for access, but it must be factored into the characterization parameters the device advertises, since the access latency is equal to the time required to transmit the largest packet ⏱️. Approximate values for the characteristics on various media are in the table below 🎀. These delays should also be considered in the context of the speed of light delay, which is approximately 400 ns for typical 100 m UTP links and 7 us for typical 2 km multimode fiber links ✨.
Table 4: Full duplex switched media access latency
--------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
--------------------------------------------------
Ethernet 10 Mbps 1.2 ms 1.2 ms
100 Mbps 120 us 120 us
1 Gbps 12 us 12 us
Token Ring 4 Mbps 9 ms 9 ms
16 Mbps 9 ms 9 ms
FDDI 100 Mbps 360 us 8.4 ms
Demand Priority 100 Mbps 120 us 120 us
--------------------------------------------------Full duplex switched network topologies offer good QoS capabilities for both Controlled Load and Guaranteed Service, when supported by suitable queuing strategies in the switches 💖.
9.2. Shared Media Ethernet Networks ✨
Okay so we haven't even talked about how messy it is to allocate bandwidth on a single shared CSMA/CD segment 😭. The second any CSMA/CD algorithm shows up, the ability to give any form of Guaranteed Service is seriously compromised, unless the multiple senders on the link are tightly coupled to each other. There are a few reasons we aren't offering a better fix for this one 💅.
Firstly, we don't think this is a truly solvable problem, because it would need changes to the MAC protocol. IEEE 802.1 looked at research showing disappointing simulation results for performance guarantees on shared CSMA/CD Ethernet without MAC enhancements. There have been proposals for MAC layer enhancements, e.g. BLAM and enhanced flow control in IEEE 802.3. But any solution involving an enhanced software MAC running above the traditional IEEE 802.3 MAC, or other proprietary MAC protocols, is outside the scope of the ISSLL working group and this document 🙈.
Secondly, we aren't convinced it's really an interesting problem 🥱. Yes, there will be end stations on shared segments for a while, but the number of deployed switches keeps climbing relative to the number of stations on shared segments. This trend is heading toward a point where it may be perfectly fine to have a solution that assumes any network communication needing resource reservations goes through at least one switch or router 🦋. Put another way, the easiest upgrade to existing Layer 2 infrastructure for QoS support is installing segment switching. Only once that's done is it worth looking into more complex solutions involving admission control 🎀.
Thirdly, the core of campus networks is typically built on switches rather than repeated segments 🏫. There may be special circumstances in the future, e.g. Gigabit buffered repeaters, but those devices have different characteristics from existing CSMA/CD repeaters anyway 🤷♀️.
Table 5: Shared Ethernet media access latency
--------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
--------------------------------------------------
Ethernet 10 Mbps 1.2 ms unbounded
100 Mbps 120 us unbounded
1 Gbps 12 us unbounded
--------------------------------------------------9.3. Half Duplex Switched Ethernet Networks 🍓
A lot of the same arguments for sub optimal support of Guaranteed Service on shared media Ethernet apply here too, bestie 😤. Basically, this topology is still a medium that's shared between at least two senders fighting for packet transmission. Unless those senders are tightly coupled and cooperative, there's always a chance that one sender's best effort traffic interferes with the other sender's reserved traffic. Handling that coupling would require some form of modification to the MAC protocol.
Even so, half duplex switched topologies seem to offer a shot at providing Controlled Load service ✨. Here's the thing: there are exactly two potential senders, and both use prioritization for their Controlled Load traffic over best effort flows. With admission control done for those flows based on that knowledge, the media access characteristics are not deterministic, but they're somewhat predictable 🔮. This is probably a close enough useful approximation to the Controlled Load service 💜.
Table 6: Half duplex switched Ethernet media access latency
------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
------------------------------------------
Ethernet 10 Mbps 1.2 ms unbounded
100 Mbps 120 us unbounded
1 Gbps 12 us unbounded
------------------------------------------9.4. Half Duplex Switched and Shared Token Ring Networks 💫
On a shared Token Ring network, the network access time for high priority traffic at any station is bounded, and it's given by (N+1)*THTmax. Here, N is the number of stations sending high priority traffic, and THTmax is the maximum token holding time [14]. This assumes network adapters have priority queues, so the token is reserved for whatever traffic has the highest priority currently queued in the adapter. It's easy to see that access times can be improved by reducing N or THTmax 📉. The recommended default for THTmax is 10 ms [6]. N is an integer from 2 to 256 for a shared ring and 2 for a switched half duplex topology. A similar analysis applies for FDDI 🌈.
Table 7: Half duplex switched and shared Token
Ring media access latency
----------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
----------------------------------------------------
Token Ring 4/16 Mbps shared 9 ms 2570 ms
4/16 Mbps switched 9 ms 30 ms
FDDI 100 Mbps 360 us 8 ms
----------------------------------------------------Since access time is bounded, it's possible to provide an upper bound for end-to-end delays, as Guaranteed Service requires, assuming this class of traffic uses the highest priority allowable for user traffic 👑. The actual number of stations sending traffic mapped into the same traffic class as Guaranteed Service may vary over time. But from an admission control standpoint, this value is needed a priori 🧠. So the admission control entity must use a fixed value for N, which may be the total number of stations on the ring or some lower value if you want to keep the offered delay guarantees smaller. If the N value used is lower than the total number of stations on the ring, admission control must ensure that the number of stations sending high priority traffic never exceeds this number 🚦. This approach lets admission control estimate worst case access delays by assuming all of the N stations are sending high priority data. Even though, in most cases, this means delays get significantly overestimated 😅.
Assuming Controlled Load flows use a traffic class lower than the one used by Guaranteed Service, no upper bound on access latency can be provided for Controlled Load flows. Still, Controlled Load flows will get better service than best effort flows 🫶.
Note that on many existing shared Token Rings, bridges transmit frames using an Access Priority (see Section 4.3) value of 4, no matter what user_priority is carried in the frame control field of the frame. Because of that, existing bridges would need to be reconfigured or modified before the above access time bounds can actually be used ⚠️.
9.5. Half Duplex and Shared Demand Priority Networks ✨
okay so bestie, IEEE 802.12 networks talk to each other with link control signals 🎀 Those signals are how end nodes, hubs, and the hubs themselves decide who gets to use the shared medium. If a hub gets a high priority request while another hub is busy serving normal priority requests, the second hub can get preempted so the high priority one goes first 🔥 Once the network finishes all the high priority work, it picks the normal priority service back up right where it stopped. ngl that's so organized 💅
The network access time for high priority packets is basically however long it takes to preempt normal priority service ⏱️ That time is bounded, and it depends on the physical layer and on the topology of the shared network 🌸 The physical layer matters a lot in half duplex mode. Like, when you're running over unshielded twisted pair cabling (UTP) links, link control signals can't be exchanged while a packet is going over the link 😭 That means the topology matters too. In bigger shared networks, the link control signals might have to go through several links and hubs before they reach the hub that runs the network control function 🧚 That can delay the preemption of normal priority service, and it can push up the upper bound you're able to guarantee 💀
Here are upper bounds on the high priority access time for a UTP physical layer, with a cable length of 100 m between all end nodes and hubs and a maximum propagation delay of 570 ns as defined in [19] 🦋 These numbers account for the worst case signaling overhead, and they assume maximum sized normal priority data packets are being transmitted while normal priority service is getting preempted 🍓
------------------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt, UTP 120 us 254 us
802.5 pkt, UTP 360 us 733 us
------------------------------------------------------------
Table 8: Half duplex switched Demand Priority UTP access latencyShared IEEE 802.12 topologies get classified by their hub cascading level, which is written as "N" 🌈 The simplest topology is the single hub network, where N = 1. For a UTP physical layer, the standard supports a maximum cascading level of N = 5 🫶 Big shared networks with many hundreds of nodes can be built with a level 2 topology. The bandwidth manager could be told about the actual cascading level through network management mechanisms, and it can use that info in its admission control algorithms 👑
Now the fiber optic physical layer is different, because it runs in dual simplex mode, unlike UTP ✨ Upper bounds for the high priority access time with 2 km multimode fiber links and a propagation delay of 10 us are below 🔥
For shared media with distances of up to 2 km between all end nodes and hubs, the IEEE 802.12 standard allows a maximum cascading level of 2 💖 Higher levels of cascaded topologies are supported, but they require a reduction of the distances [15] 🙈
The bounded access delay and deterministic network access let you support the service commitments that Guaranteed Service and Controlled Load require, even on shared media topologies 🎀 Just be aware that 802.12 only has two priority levels, which limits how many services can run across the network at the same time 💅
----------------------------------------------------------------
Type Speed Max Pkt Max Access Topology
Length Latency
----------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt 120 us 262 us N = 1
120 us 554 us N = 2
120 us 878 us N = 3
120 us 1.24 ms N = 4
120 us 1.63 ms N = 5
Demand Priority 100 Mbps, 802.5 pkt 360 us 722 us N = 1
360 us 1.41 ms N = 2
360 us 2.32 ms N = 3
360 us 3.16 ms N = 4
360 us 4.03 ms N = 5
-----------------------------------------------------------------
Table 9: Shared Demand Priority UTP access latency ------------------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
-------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt, fiber 120 us 139 us
802.5 pkt, fiber 360 us 379 us
-------------------------------------------------------------
Table 10: Half duplex switched Demand Priority
fiber access latency ---------------------------------------------------------------
Type Speed Max Pkt Max Access Topology
Length Latency
---------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt 120 us 160 us N = 1
120 us 202 us N = 2
Demand Priority 100 Mbps, 802.5 pkt 360 us 400 us N = 1
360 us 682 us N = 2
---------------------------------------------------------------
Table 11: Shared Demand Priority fiber access latency10. Justification 🧠
okay real talk, the obvious concern is that this model is complicated 😭 It basically does what RSVP already does at Layer 3, so why would we reinvent the solution to this problem at Layer 2? The answer is that there are a bunch of simple Layer 2 scenarios that cover a big chunk of the real QoS problems people are going to run into 🦋 A solution that handles most of the problems at way lower cost is super worth it. Full RSVP/IntServ with per flow queuing in strategically positioned high function switches or routers might be needed to fully fix everything, but devices implementing the architecture described in herein will give you a much simpler network 💖
11. Summary 🎀
so to wrap up this whole doc 🌸 It specified a framework for providing Integrated Services over shared and switched LAN technologies. Guaranteeing QoS needs some kind of admission control and resource management. The requirements and goals of a resource management scheme for subnets got identified and discussed, and the whole scheme is called a Bandwidth Manager 👑 We talked about architectural considerations and gave examples of how a Bandwidth Manager could be implemented 🧚 We also covered some of the issues with mapping services from higher layers down to the link layer ✨ The accompanying memos from the ISSLL working group deal with service mapping issues [13], and they give a protocol spec for the Bandwidth Manager protocol [14] based on the requirements and goals in this document 🫶
References 📚✨
okay bestie, here's the full reading list, copied exactly so you can actually find everything 🫶
[1] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[2] ISO/IEC 10038 Information technology - Telecommunications and
information exchange between systems - Local area networks -
Media Access Control (MAC) Bridges, (also ANSI/IEEE Std 802.1D-
1993), 1993.
[3] ISO/IEC 15802-3 Information technology - Telecommunications and
information exchange between systems - Local and metropolitan
area networks - Common specifications - Part 3: Media Access
Control (MAC) bridges (also ANSI/IEEE Std 802.1D-1998), 1998.
[4] IEEE Standards for Local and Metropolitan Area Networks:
Virtual Bridged Local Area Networks, IEEE Std 802.1Q-1998, 1998.
[5] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource Reservation Protocol (RSVP) - Version 1 Functional
Specification", RFC 2205, September 1997.
[6] Wroclawski, J., "Specification of the Controlled Load Network
Element Service", RFC 2211, September 1997.
[7] Shenker, S., Partridge, C. and R. Guerin, "Specification of
Guaranteed Quality of Service", RFC 2212, September 1997.
[8] Braden, R., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: An Overview", RFC 1633, June 1994.
[9] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997.
[10] Shenker, S. and J. Wroclawski, "Network Element Service
Specification Template", RFC 2216, September 1997.
[11] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC 2215,
September 1997.
[12] Delgrossi, L. and L. Berger (Editors), "Internet Stream Protocol
Version 2 (ST2) Protocol Specification - Version ST2+", RFC
1819, August 1995.
[13] Seaman, M., Smith, A. and E. Crawley, "Integrated Service
Mappings on IEEE 802 Networks", RFC 2815, May 2000.
[14] Yavatkar, R., Hoffman, D., Bernet, Y. and F. Baker, "SBM Subnet
Bandwidth Manager): Protocol for RSVP-based Admission Control
Over IEEE 802-style Networks", RFC 2814, May 2000.
[15] ISO/IEC 8802-3 Information technology - Telecommunications and
information exchange between systems - Local and metropolitan
area networks - Common specifications - Part 3: Carrier Sense
Multiple Access with Collision Detection (CSMA/CD) Access Method
and Physical Layer Specifications, (also ANSI/IEEE Std 802.3-
1996), 1996.
[15] ISO/IEC 8802-5 Information technology - Telecommunications and
information exchange between systems - Local and metropolitan
area networks - Common specifications - Part 5: Token Ring
Access Method and Physical Layer Specifications, (also ANSI/IEEE
Std 802.5-1995), 1995.
[17] Postel, J. and J. Reynolds, "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February
1988.
[18] C. Bisdikian, B. V. Patel, F. Schaffa, and M Willebeek-LeMair,
The Use of Priorities on Token Ring Networks for Multimedia
Traffic, IEEE Network, Nov/Dec 1995.
[19] IEEE Standards for Local and Metropolitan Area Networks: Demand
Priority Access Method, Physical Layer and Repeater
Specification for 100 Mb/s Operation, IEEE Std 802.12-1995.
[20] Fiber Distributed Data Interface MAC, ANSI Std. X3.139-1987.
[21] ISO/IEC 15802-3 Information technology - Telecommunications and
information exchange between systems - Local and metropolitan
area networks - Specific requirements - Supplement to Carrier
Sense Multiple Access with Collision Detection (CSMA/CD) Access
Method and Physical Layer Specifications - Frame Extensions for
Virtual Bridged Local Area Network (VLAN) Tagging on 802.3
Networks, IEEE Std 802.3ac-1998 (Supplement to IEEE 802.3 1998
Edition), 1998.Security Considerations 🔐💀
okay this part is serious, so listen up 👀 implementing the model in this memo does not create any known new avenues for malicious attack on the network infrastructure 🙌 BUT, if you want the full tea on how admission control signaling protocols can affect network security, go read Section 2.8 of the RSVP specification [5] 🕵️♀️✨
Acknowledgements 🫶🌸
this doc owes a huge thank you to the Integrated Services over Specific Link Layers (ISSLL) working group 💖 so much of the work here came out of their meetings and the mailing list chats, and every participant who showed up with ideas gets a big hug 🤗 special shoutout to Eric Crawley, Don Hoffman and Raj Yavatkar for their contributions through earlier Internet drafts, and to Peter Kim for writing the text about Demand Priority networks 👑
Authors' Addresses 💌🦋
here's who to thank (and where to find them) ✨
Anoop Ghanwani
Nortel Networks
600 Technology Park Dr
Billerica, MA 01821, USA
Phone: +1-978-288-4514
EMail: aghanwan@nortelnetworks.com
Wayne Pace
IBM Corporation
P. O. Box 12195
Research Triangle Park, NC 27709, USA
Phone: +1-919-254-4930
EMail: pacew@us.ibm.com
Vijay Srinivasan
CoSine Communications
1200 Bridge Parkway
Redwood City, CA 94065, USA
Phone: +1-650-628-4892
EMail: vijay@cosinecom.com
Andrew Smith
Extreme Networks
3585 Monroe St
Santa Clara, CA 95051, USA
Phone: +1-408-579-2821
EMail: andrew@extremenetworks.com
Mick Seaman
Telseon
480 S. California Ave
Palo Alto, CA 94306
USA
Email: mick@telseon.comFull Copyright Statement ⚖️🌈
the legal bit, but it's important, so read it 🙏
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 🍓
That's the whole RFC, bestie! 2816 is officially slayed 👑🌈💅
📦 where this page comes from
- ietf: rfc2816 2000-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms