RFC 2638

RFC 2638: A Two-bit Differentiated Services Architecture for the Internet 🎀

Okay bestie, this is RFC 2638, and the vibe is pure "two bits, infinite possibilities" 🦋. It's from the Network Working Group and it was written by K. Nichols (Cisco), V. Jacobson (Cisco), and L. Zhang (UCLA). It's dated July 1999 and it's classed as Informational, so it's sharing knowledge, not setting a standard 💅. The header doesn't list anything it obsoletes or updates, so it's just doing its own thing 🌸.

Status of This Memo ✨

This memo is here to give info to the Internet community 🫶. It does not specify an Internet standard of any kind. Distribution is unlimited, so share it with everyone you know 🍓.

Copyright Notice 💜

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

Abstract 🌈

Okay so this doc was first submitted as an internet draft in November of 1997. Back then it was one of the papers that came before the IETF's Differentiated Services Working Group existed, and a lot of the ideas in it were key to the work that became RFCs 2474 and 2475 🔥. Dave Clark also gave a presentation at the December 1997 meeting of the IETF Integrated Services Working Group, and that connected to these ideas too ✨. The allocation section is still a timely proposal, which is why it's being published in its original form as a reference 🧚. The forwarding path part is basically a snapshot of where things were in late 1997, not a hint about where things are going 💀.

The postscript version includes Clark's slides as an appendix, plus lots of figures that make it way easier to read 🙈.

1. Introduction ✨

Let's set the scene 🎀. This doc presents a differentiated services architecture for the internet. At the Munich IETF meeting, Dave Clark and Van Jacobson each presented work on differentiated services [2,3]. Each of them showed how one bit of the IP header could deliver a new kind of service to packets. Those were two very different services with pretty different policy assumptions 👀. After discussion, the team agreed that both service types have merit and that both can be built from a set of very similar mechanisms 💖. So this architecture lets both service types exist and takes advantage of how similar they are in the forwarding path 💅.

The goals are each shared with one or both of those two proposals: keep the forwarding path simple 🫶, push complexity to the edges of the network as much as possible 🌸, provide a service that doesn't assume anything about the type of traffic using it 🦋, use an allocation policy that works with both long-term and short-term provisioning 📈, and keep the dominant Internet traffic model best-effort 🍓.

The main contributions are two distinct service types, a set of general forwarding path mechanisms that can be used to build a range of differentiated services, and a flexible framework for provisioning a differentiated services network 🎀. Honestly this kind of architecture is exactly what's needed to deploy differentiated services quickly 🔥. You need a framework and a set of primitives that can be implemented in the short term and still give interoperable services. It also needs to be a "sandbox" 🧚 for experimenting, so more levels of differentiation can be added inside each service over time, as needed ✨.

Now for the analogy, and I'm aware I'm overdoing it 🙈. We want service tiers in a similar way to airlines with first class, business class, and coach. Coach also has tiering built in because of the restrictions put on the purchase 💺. The part we really want to stress is that best-effort traffic, like coach seats on a plane, is still expected to make up the bulk of internet traffic ✈️. Business and first class carry a small number of passengers but are super important to the economics of the airline industry 💜. The economic forces and realities work together to decide how the seats are allocated and to try to fill the plane 💅. We don't expect differentiated services to carry all the traffic on the internet, but we do expect new services to lead to a healthy economic and service environment 🌈.

This document is organized into sections describing the service architecture, the mechanisms, the bandwidth allocation architecture, how this architecture might interoperate with RSVP/int-serv work, and recommendations for deployment 📚.

2. Architecture 🦋

2.1 Background 🌸

The current internet delivers one type of service, best-effort, to all traffic 🍓. A number of proposals have been made to add enhanced services to the Internet ✨. We focus on two particular methods of adding a differentiated level of service to IP, and each one is designated by one bit [1,2,3] 🔥. These services are a radical departure from the Internet's traditional service 😳. They're also a radical departure from traditional "quality of service" architectures, which rely on circuit-based models 💀. Both proposals try to define a single common mechanism that interior network routers use, which pushes most of the complexity and state of differentiated services out to the network edges 🫶. Both use bandwidth as the resource being requested and allocated 💖.

Clark and Wroclawski defined an "Assured" service that follows "expected capacity" usage profiles that are statistically provisioned [3] 🎀. The assurance a user gets from this service is that their traffic is unlikely to be dropped as long as it stays within the expected capacity profile 🛡️. What "unlikely" means depends on how well provisioned the service is 📊. An Assured service traffic flow may exceed its Profile, but the excess traffic doesn't get the same assurance level 😬.

Jacobson defined a "Premium" service [2] 👑. It's provisioned according to peak capacity Profiles that are strictly not oversubscribed, and it gets its own high-priority queue in routers 🔥. A Premium service traffic flow is shaped and hard-limited to its provisioned peak rate, and it's shaped so bursts aren't injected into the network 🧚. Premium service presents a "virtual wire" 🪡. A flow's bursts may queue at the shaper at the edge of the network, but after that they only queue in proportion to the indegree of each router 💅. Even though these two approaches have a lot in common, they result in fundamentally different services 🙈. The Assured one uses buffer management to provide a "better effort" service 🍓. The Premium one creates a service with little jitter and queueing delay, and it doesn't need any queue management on the Premium packets' queue 🌈.

An Assured service was introduced in [3] by Clark and Wroclawski, though we made some changes to its specification for our architecture ✨. Further refinements and an "Expected Capacity" framework are given in Clark and Fang [10] 📚. That framework is focused on "providing different levels of best-effort service at times of network congestion." It also mentions that you can have a separate router queue to implement a "guaranteed" level of assurance 💜. We believe this framework and our Two-bit architecture are compatible, but that needs further exploration 🤔. Since Premium service hasn't been documented anywhere else, we describe it next, and then we follow up with a description of the two-bit architecture 🎀.

2.2 Premium service 💅

okay so, the original RFC already gave us a Premium service in [2], and it is fundamentally different from the Internet's current best effort service 🦋 It's not trying to replace best effort. It's meeting a growing demand for a commercial service that can share the network with best effort traffic, which is lowkey genius because the same network can carry both kinds of traffic 💜 Premium traffic is expected to get a small percentage of total network capacity, and it's priced much higher 💸 One use would be "virtual leased lines," which saves you the cost of building and maintaining a separate network 🌸

Premium is kind of like a regular phone line. The customer expects the capacity to be there the moment they lift the receiver, even if, depending on the household, it sits idle a good chunk of the time 📞 Provisioning Premium this way reduces the capacity of the best effort internet by the amount of Premium allocated, in the worst case, so it has to be priced accordingly 🫶 The bright side is that whenever that capacity isn't being used, best effort traffic can use it 🌈 Compare that with normal best effort traffic, which is bursty and needs queue management to deal fairly with congestion. Premium is designed to create very regular traffic patterns with small or nonexistent queues ✨ Main character energy, honestly 👑

Premium service levels are specified as a desired peak bit-rate for a specific flow, or for an aggregation of flows 🎀 The user contract with the network is not to exceed that peak rate. The network contract is that the contracted bandwidth will be available when traffic is sent 🤝 First-hop routers (or other edge devices) filter the packets entering the network, set the Premium bit on the ones that match a Premium service specification, and do traffic shaping on the flow so that all bursts get smoothed out before they enter the network 💅 The best part is that this approach requires no changes in hosts 🙈 A compliant router along the path needs two levels of priority queueing, and it sends all packets with the Premium bit set first. Best-effort traffic stays unmarked, gets queued, and is sent at the lower priority 🍓 This creates two "virtual networks." One is identical to today's Internet, with buffers designed to absorb traffic bursts. The other is one where traffic is limited and shaped to a contracted peak rate, and packets move through a network of queues where they experience almost no queueing delay 🧚

In this architecture, forwarding path decisions are made separately from setting up service agreements and traffic profiles, and they're much simpler 💖 Except for policing and shaping at administrative or "trust" boundaries, the only things the forwarding path has to handle are classifying a packet into one of two queues based on a single bit, and servicing those two queues using simple priority 🔥 Shaping must include both rate and burst parameters, and the burst is expected to be small, in the one or two packet range 🌸 Policing at boundaries enforces rate compliance, and it may be implemented by a simple token bucket 🦋 The admission and set-up procedures are expected to evolve over time to become dynamically configurable and fairly complex, while the forwarding path mechanisms stay simple 👑

A Premium service built on this architecture can be deployed in a useful way once the forwarding path mechanisms are in place, by making static allocations ✨ Traffic flows can be designated for special treatment through network management configuration 🎀 Flows should be designated by the source, the destination, or any combination of fields in the packet header 💜 First-hop (or leaf) routers filter flows on all or part of the header tuple, which consists of the source IP address, destination IP address, protocol identifier, source port number, and destination port number 🌈 Based on that classification, a first-hop router does traffic shaping and sets the designated Premium bit of the precedence field 🧚 End-hosts aren't required to be "differentiated services aware." Still, if and when end-systems become universally "aware," they might do their own shaping, and first-hop routers would merely police 🫶

Adherence to the subscribed rate and burst size must be enforced at the entry to the network, either by the end-system or by the first-hop router 🔒 Within an intranet, administrative domain, or "trust region," packets can then be classified and serviced solely on the Premium bit 💅 Where packets cross a boundary, policing is critical. The region being entered checks the prioritized packet flow for conformance to a rate that the two regions have agreed upon, and discards packets that exceed it 😭 So it's in the best interests of a region to make sure traffic conforms to the agreed-upon rate at the egress 💖 This requirement means Premium traffic is burst-free. Together with the no oversubscription rule, that leads directly to the observation that Premium queues can easily be sized to prevent the need to drop packets, and therefore the need for a queue management policy 🍓 At each router, the largest queue size is related to the in-degree of other routers, so it's quite small, on the order of ten packets 🌸

Premium bandwidth allocations must not be oversubscribed, because they represent a commitment by the network, and they should be priced accordingly 💸 Note that in this architecture, Premium traffic will also experience considerably less delay variation than either best effort traffic or the Assured data traffic of [3] 🦋 Premium rates might be configured on a subscription basis in the near term, or on demand once dynamic set-up or signaling is available 🌈

Figure 1 shows how a Premium packet flow is established within a particular administrative domain, Company A, and sent across the access link to Company A's ISP 🧚 Let's assume the host's first-hop router has been configured to match a flow from the host's IP address to a destination IP address that's reached through the ISP 🎀 A Premium flow is configured from a host with a rate that is both smaller than the total Premium allocation Company A has from the ISP (that's r bytes per second) and smaller than the amount of that allocation that has been assigned to other hosts in Company A 🙈 Packets aren't marked in any special way when they leave the host 💅 The first-hop router clears the Premium bit on all arriving packets, sets the Premium bit on all packets in the designated flow, shapes the Premium packets to a configured rate and burst size, queues best-effort unmarked packets in the low priority queue and shaped Premium packets in the high priority queue, and sends packets from those two queues using simple priority 👑 Intermediate routers internal to Company A enqueue packets in one of two output queues based on the Premium bit, and service the queues with simple priority ✨ Border routers do quite different things depending on whether they're processing an egress flow or an ingress flow 🔥 An egress border router may reshape the aggregate Premium traffic to conform to rate r, depending on how many Premium flows are aggregated 💖 Ingress border routers only need to do a simple policing function that can be implemented with a token bucket 🫶 In the example, the ISP accepts all Premium packets from A as long as the flow doesn't exceed r bytes per second 🌈

Figure 1. Premium traffic flow from end-host to organization's ISP 🦋

2.3 Two-bit differentiated services architecture 🦋

okay so Clark's and Jacobson's proposals are literally so similar 👯‍♀️ in where they put their functional blocks and what kind of blocks they are. And they offer totally different services that don't clash in a network at all 💅

Premium is giving guaranteed peak bandwidth with negligible queueing delay, and it can't starve best effort traffic. It's also pretty straightforward to allocate ✨ Commercial apps, video broadcasts, voice-over-IP, and VPNs would be obsessed with this 💖 BUT ngl it might be too restrictive with its hard limits, and overdesigned since there's no overallocation, for some apps 🙈 Assured is a different vibe 🌸 It has the same delay as undropped best effort packets, and how firm the guarantee is depends on how well the individual links are provisioned for bursts of Assured packets. The iconic part is that flows can use any extra capacity without penalty, and occasional dropped packets during short congestive periods may be fine for lots of users. This could be what an ISP offers customers who are happy to pay a bit more for internet that doesn't seem affected by congestion 💅 Both services are only as good as their admission control, and that gets harder for traffic that isn't peak-rate allocated 😭

There are some extra perks to running both services 🫶 Premium is a conservative allocation, so bandwidth that was allocated to Premium but isn't used can give some "headroom" to underallocated or bursting Assured traffic, or to best effort. Network elements running both will do RED queue management on all non-Premium traffic, as suggested in [4], and mixing Premium streams with best effort might make the latter less bursty ✨ Assured lets bursts happen in their natural way, which is a major strength, but it also makes provisioning, admission control, and allocation harder. So it may take more time and experimenting before the admission policy for this service is totally defined 🧚 A Premium service could also be deployed with static allocations on peak rates and no statistical sharing 🍓

Okay so here's the plan 👑 There seem to be lots of advantages to having an architecture that allows both of these service types, and they can share a lot of the same mechanisms. So we propose designating two bit-patterns from the IP header precedence field 🎀 We leave the explicit designation of these bit-patterns to the standards process, so we use shorthand: one bit is the Premium or P-bit, and the other is the assurance or A-bit 🌈 A network could implement only one of these services, with network elements that only look at the one relevant bit, but we're focusing on the two-service architecture. We also assume hosts don't change at all, and that the packet marking all happens in the network, at the first-hop or leaf router ✨ We describe the forwarding path architecture in this section, assuming the service has already been allocated through mechanisms we'll talk about in section 4 💜

In a broader sense, Premium service means packets get enqueued at a higher priority than the ordinary best-effort queue 🔥 Assured service means packets get treated preferentially when it comes to their dropping probability inside the "normal" queue 🫶 There are a bunch of ways to add more service levels within each type [7], but this document is all about specifying the base-level services of Premium and Assured 💅

Forwarding path mechanisms split into two groups: the ones that happen at the input interface, before packet forwarding, and the ones that happen at the output interface, after packet forwarding 🦋 Intermediate routers only need the post-forwarding functions. Leaf and border routers, on the other hand, have to do stuff to arriving packets before forwarding. This is just how we're illustrating it, and other ways of composing these functions are possible ✨

Leaf routers get a traffic profile for a particular flow based on its packet header 🧚 This was defined by the RSVP Working Group in RFC 2205. Figure 2 shows what happens to a packet that arrives at a leaf router before it goes to the forwarding engine. All arriving packets must have both the A-bit and the P-bit cleared, and then they get classified by their header. If the header doesn't match any configured values, it gets forwarded right away 🌸 Matched flows go through individual Markers that were configured from that flow's usage profile. That covers the service class (Premium or Assured), the rate (peak for Premium, "expected" for Assured), and the permissible burst size (which may be optional for Premium) 💖 An Assured flow's packets come out of the Marker with their A-bits set when the flow conforms to its Profile, and the flow is otherwise unchanged ✨ For a Premium flow, the Marker holds packets whenever it's needed to enforce the configured rate, so Premium packets come out as a shaped flow with their P-bits set 🔥 (Premium packets can also get dropped inside the Marker, as we'll describe below 🙈) Packets go to the forwarding engine as they emerge from the Markers. And packets that have their P or A bits set are called Marked packets 👑

Figure 2. Block diagram of leaf router input functionality

Figure 3 shows the inner workings of the Marker 🎀 For both Assured and Premium packets, a token bucket "fills" at the flow rate from the usage profile. For Assured service, the token bucket depth is set by the Profile's burst size. For Premium service, the token bucket depth must be limited to the equivalent of only one or two packets, and we suggest one packet in early deployments 🌈 When a token is present, Assured flow packets have their A-bit set to one. Otherwise, the packet goes to the forwarding engine 💅 For a Premium-configured Marker, arriving packets that see a token present get their P-bits set and get forwarded. But when there's no token, Premium packets are held until a token shows up 😭 If a Premium flow bursts enough to overflow the holding queue, its packets get dropped. The flow setup data can be used to set a size limit for the holding queue, and that's what "burst" means for Premium service, but it isn't required 🫶 Unconfigured holding queues should be able to hold at least two bandwidth-delay products, which is enough for TCP connections. A smaller value might be used to match the delay requirements of a specific application 🧚

Figure 3. Markers to implement the two different services

In practice, the token bucket should be implemented in bytes, and a token counts as present if the number of bytes in the bucket is equal to or larger than the packet size 🍓 For Premium, the bucket can only fill up to the maximum packet size. Assured can fill up to the configured burst parameter 💖 Premium traffic is held until enough byte credit has built up, and this holding buffer is the only real queue the flow sees in the network ✨ For Assured traffic, we just check whether the bytes in the bucket are enough for the packet size, and set A if they are. If not, the only difference is that A doesn't get set. Assured traffic goes into a queue after this step, and it can potentially see a queue at every hop along its path 🌸

Each output interface of a router must have two queues and must implement a test on the P-bit to pick a packet's output queue 👑 The two queues must be serviced by simple priority, with Premium packets going first 🔥 Each output interface must also implement the RED-based RIO mechanism described in [3] on the lower priority queue 💅 RIO uses two thresholds for when to start dropping packets. One is a lower threshold based on the total queue occupancy for ordinary best effort traffic, and the other is based on the number of enqueued packets that have their A-bit set 🦋 So any action that favours Assured service only gets taken once the queue's capacity goes past the threshold for ordinary best effort service. In that case, only unmarked packets get dropped (using the RED algorithm), unless the threshold for Assured service has also been reached 🙈 Keeping an accurate count of A-bit packets in a queue means either testing the A-bit on both entry and exit of the queue, or keeping some additional state in the router ✨ Figure 4 is a block diagram of the output interface for all routers 🧚

Figure 4. Router output interface for two-bit architecture

So the packet output of a leaf router is a shaped stream of P-bit packets mixed in with an unshaped best effort stream, and some of those may have A-bits set 💖 Premium service clearly can't starve best effort traffic, because it's both burst and bandwidth controlled 🫶 Assured service might only need a conservative allocation to avoid starving unmarked traffic. But bursts of Assured traffic could still close out best-effort traffic at bottleneck queues during congestive periods 😭

After [3], we call the forwarding path objects that test flows against their usage profiles "Profile Meters" 🎀 Border routers will need Profile Meters at their input interfaces. The bilateral agreement between adjacent administrative domains must specify a peak rate on all P traffic, and a rate and burst for A traffic (and possibly a start time and duration) 🌈 A Profile Meter is required at the ingress of a trust region to make sure differentiated service packet flows comply with their agreed-upon rates. Non-compliant packets of Premium flows get discarded, while non-compliant packets of Assured flows have their A-bits reset 💅 For example, in figure 1, if the ISP has agreed to supply Company A with r bytes/sec of Premium service, then P-bit marked packets that enter the ISP through the link from Company A will be dropped if they go over r 🙈 If the service in figure 1 were Assured service instead, the packets would just be unmarked and forwarded as best effort ✨

The simplest border router input interface is a Profile Meter built from a token bucket configured with the contracted rate across that ingress link (see figure 5) 🧚 Each type, Premium or Assured, and each interface must have its own profile meter for a particular class across a particular boundary 🍓 (This is different from models where every flow that crosses the boundary has to be policed and/or shaped separately 💜) The exact mechanisms required at a border router input interface depend on the allocation policy that's deployed. A more complex approach is presented in section 4 👑

Figure 5. Border router input interface Profile Meters

3. Mechanisms ✨

3.1. Forwarding Path Primitives 🎀

okay so Section 2.3 introduced the two forwarding path objects, Markers and Profile Meters 🧚 in this section we break down the primitive building blocks you need to put them together. There are six of them: general classifier, bit-pattern classifier, bit setter, priority queues, policing token bucket, and shaping token bucket ✨ A Marker is built from either a policing or a shaping token bucket plus a bit setter, and a Profile Meter is built from a policing token bucket plus a dropper or bit setter 💅

General Classifier: Leaf or first-hop routers MUST do transport-level signature matching on a tuple in the packet header. Good news: this is already a feature of any RSVP-capable router 💖 As we said earlier, packets whose tuples match one of the configured flows get conformance tested and have the right service bit set. It's memory- and processing-heavy 😭 but it stays at the edges of the network, where there are fewer flows, so it's lowkey manageable.

Bit-pattern classifier: This one is a simple two-way decision based on whether a particular bit pattern in the IP header is set 🦋 As in figure 4, a non-leaf router tests the P-bit when a packet arrives to decide whether it goes into the high priority output queue or the low priority packet queue. Packets headed for the low priority queue get their A-bit tested for two reasons: 1) to bump the count of Assured packets in the queue if the bit is set, and 2) to figure out which drop probability applies to that packet. Packets leaving the low priority queue MUST also have their A-bit tested, so the count of enqueued Assured packets can go down when it needs to 🔥

Bit setter: The A-bits and P-bits MUST be set or cleared in several places 🌸 The most general option is a functional block that sets the right bits of the IP header to a configured bit pattern. Very versatile, very iconic.

Priority queues: Every network element MUST include (at least) two levels of simple priority queueing 👑 The high priority queue is for Premium traffic, and the rule is to send packets from that queue first, until it's empty. Remember, Premium traffic MUST NOT be oversubscribed, so Premium traffic SHOULD see little or no queue 🫶

Shaping token bucket: This is the token bucket a leaf router needs for Premium traffic, and it's shown in figure 3 🌈 Shaping is also useful at the egress points of a trust region, and we'll see why soon. A packet that shows up gets forwarded right away if there's a token in the bucket. If not, the packet gets queued until the bucket has enough tokens to send it. Shaping needs clocking mechanisms, packet memory, and some state for each flow, so it's a memory- and computation-heavy process 💀

Policing token bucket: This is the token bucket Profile Meters need, and it's shown in figure 5 ⭐ Policing token buckets never hold arriving packets. Instead, they check on arrival whether a token is available for the packet's service class. If there is one, the packet is forwarded immediately. If not, the policing action kicks in: Premium packets get dropped, and Assured packets get reclassified or unmarked 🍓

3.2. Passing configuration information 🧚

Okay, but how does the leaf router even find out about the request? 🙈 We need mechanisms to pass the information about the request to the leaf router. That configuration information covers the rate, the burst, and whether the request is a Premium or Assured type. There MAY also need to be a specific field to set or clear this configuration 🌸 The information can be passed in a number of ways. You could use the semantics of RSVP, use SNMP, or a network administrator could set it directly in some other way. There MUST be some mechanisms for authenticating the sender of this information 🔐 We expect configuration to be done in a bunch of different ways in early deployments, and a protocol and mechanism for it is a topic for future standards work 💜

3.3. Discussion 🫧

Shapers are placed at the edges of the network, and that makes sense because the state per router can be smaller there than in the middle of a network 💖 The heaviest load for flow matching and shaping lands on leaf routers, where the speeds and buffering needed should be lower than what might be needed deeper in the network. This functionality is not required at every network element on the path ✨ Routers inside a trust region won't need to shape traffic. Border routers MAY need or want to shape the aggregate flow of Marked packets at their egress, so they don't burst into non-compliance with the policing mechanism at the ingress of the other domain. (This MAY not be necessary if the in-degree of the router is low.) Also, shaping applies to an aggregate of all the Premium flows that exit the domain via that path, not to each flow individually 🦋

These mechanisms are totally within reach of today's technology 🎀 We honestly think Premium and Assured services are all the Internet needs. But if these services turn out to be insufficient over time, this architecture gives us a migration path to deliver other kinds of service levels 🌈 The A- and P-bits would keep being used to identify traffic that gets Marked service, and further filter matching could be done on packet headers to differentiate service levels even more. Using the bits this way cuts down on the number of packets that need extra matching, so you're not filtering every incoming packet 🙌 More queue levels and more complex scheduling could be added for P-bit traffic, and more levels of drop priority could be added for A-bit traffic, if experience shows they're needed and processing speeds are fast enough 🔥 We suggest treating these services as "at least" services. So a network element SHOULD at least be capable of mapping all P-bit traffic to Premium service, and of mapping all A-bit traffic to be treated with one level of priority in the "best effort" queue. (It looks like the single level of A-bit traffic should map to a priority equal to the best level in a multi-level element that's also on the path 💅)

But wait, what's the downside of deploying an architecture for both classes of service if later we decide only one is needed? 🤔 Honestly, the functional blocks for both service classes are pretty similar, so the same mechanism can provide them, just parameterized differently 🍓 If Assured service isn't used, very little is lost. A RED-managed best effort queue has been strongly recommended in [4], and to the extent that deploying this architecture pushes RED-managed best effort queues into existence, that's clearly a win 💜 If Premium service goes unused, though, the two queues with simple priority service aren't required, and the shaping function of the Marker MAY be unused. Those would just be an unnecessary implementation cost 😭

---

4. The Architectural Framework for Marked Traffic Allocation 👑

So far we've focused on the service definitions and the forwarding path mechanisms 🧚 Now we get to the question of how to allocate the level of Marked traffic across the whole Internet ✨ Most organizations have fixed chunks of their budgets, including data communications, that get decided on an annual or quarterly basis. Some extra money might be attached to specific projects for short-term discretionary costs 💖 Service providers (ISPs and NSPs) MUST do their planning on annual and quarterly bases, so they can't be expected to provide differentiated services purely "on call" 🙈 Provisioning sets up static levels of Marked traffic, while call setup creates an allocation of Marked traffic for a single flow's duration. Static levels can be provisioned with time-of-day specs, but they can't be changed in response to a dynamic message 🌸 We expect both kinds of bandwidth allocation to matter.

Buyers of Marked services can generally be expected to work on longer-term budget cycles, where these services get accounted for much like many information services today 💅 For example, a mail-order house MAY want to buy a fixed allocation of bandwidth in and out of its web server, so browsing its site feels "fast" to potential customers 🛍️ That allocation might be based on the previous quarter's hit rates, or on some kind of industry-based averages. There also needs to be a dynamic allocation capability for responding to particular events, like a demo, a network broadcast by a company's CEO, or a particular network test 🔥 And a dynamic capability MAY be needed to meet a precommitted service level when the particular source or destination is allowed to be "anywhere on the Internet" 🦋 "Dynamic" covers everything from a phoned-in or emailed request all the way to a signalling-type model. A strictly static allocation scenario is expected to be useful during initial deployment of differentiated services, and to make up a big portion of Marked traffic for the foreseeable future 🌈

Without a "per call" dynamic setup, preconfiguring usage profiles can always be seen as "paying for bits you don't use," whether the service is Premium or Assured 😭 We'd rather think of it as paying for the level of service you expect to have available at any time. Think of paying for a telephone line 📞 A customer might pay an extra flat fee for the privilege of calling a wide local area at no additional charge, or they might pay by the call. Even though a customer could pay "per call" for every call made anywhere, that usually turns out not to be the most economical option for most people 💜 It's possible similar pricing structures might show up on the Internet too 🧚

We use Allocation to refer to the process of making Marked traffic commitments anywhere along this range, from strictly preallocated to dynamic call setup 🎀 We require an Allocation architecture that can cover this whole spectrum in any mix. We also observe that Allocation MUST follow organizational hierarchies. Each organization MUST have complete responsibility for allocating the Marked traffic resource within its own domain 👑 Finally, we observe that the only real chance of success for incremental deployment is an Allocation architecture built on bilateral agreements, since multilateral agreements are far too complex to administer 🤝 So the Allocation architecture is made up of agreements across boundaries about how much Marked traffic will be allowed to pass. Honestly, it's a lot like the "settlement" models used today 💖

4.1 Bandwidth Brokers: Allocating and Controlling Bandwidth Shares ✨

okay so the whole point of differentiated services is controlled sharing of an organization's Internet bandwidth 🫶 Somebody has to decide whose traffic gets the good stuff, and there are two ways to do it. Either individuals set bit(s) in their own packets to flag their most important traffic, or agents who actually know the organization's priorities and policies hand out bandwidth based on those rules 💅 Self-labeling is super easy to build, but ngl it's unlikely to be enough, because it's unreasonable to expect everyone to know every priority and how the network is being used right now, and then always mark their traffic correctly 💀 So this architecture uses agents called bandwidth brokers (BB) [2]. They get configured with the organization's policies, keep track of how much marked traffic is already allocated, and look at new requests to mark traffic in light of those policies and that allocation 🎀

Honestly, agents like this are basically required for any sharing that isn't super trivial 🧚 Neither individuals nor the routers their packets pass through have the info needed to figure out which packets matter most to the organization. Since those agents have to exist anyway, we might as well use them to allocate bandwidth for end-to-end connections. That's way less state and way simpler trust relationships than setting up per-flow or per-filter guarantees in every network element on an end-to-end path 😭 BBs let bandwidth allocation follow organizational hierarchies, and combined with the forwarding path mechanisms from section 3, they cut down the state needed to set up and maintain a flow. That matters a lot in architectures that have to check the full flow header at every network element 🌸

On the org side, the BB design comes from the observation that multilateral agreements rarely work out 💜 This architecture lets end-to-end services be built out of purely bilateral agreements instead. BBs only need limited trust with their peers in adjacent domains. Compare that to schemes that need flow specifications set in routers all along the path, which is a whole mess 🙈 In practical terms, the BB approach lets state live on an administrative domain basis instead of at every router, and the Premium and Assured service definitions mean per-flow state only has to exist in the leaf routers 🦋

BBs have two jobs. The main one is to parcel out their region's Marked traffic allocations and set up the leaf routers in the local domain ✨ The other is to handle the messages that cross boundaries to the BBs in adjacent regions 🍓 Each trust region has one BB, one per domain. Every BB has a policy database that tracks who can do what, and when, plus a way to use that database to authenticate requesters 👑 Only a BB can configure leaf routers to deliver a particular service to flows, which is crucial for a secure system, no cap 🔥 Once dynamically allocated, marked flows between two adjacent domains become possible, BBs are also the hook you need to make that happen 🌈 Each domain's BB sets up a secure association with its peer in the adjacent domain, so they can negotiate or configure a rate and a service class (Premium or Assured) across the shared boundary and through the peer's domain 💖 As we'll see, some types of service, especially in early implementations, don't get that secure association automatically. It can be done through human negotiation and then manual configuration of the adjacent BBs to match the agreement ⭐ That negotiated rate is a capability the BB controls for all hosts in its region 💅

When somebody wants an allocation for a particular flow, a request goes to the BB 🦋 A request includes a service type, a target rate, a maximum burst, and the time period when the service is needed. It can come from a network administrator or a user by hand, or from another region's BB 🎀 The BB first authenticates the requester's credentials, then checks that there's enough unallocated bandwidth to meet the request 💜 If it passes both tests, the available bandwidth goes down by the requested amount and the flow specification gets recorded 🌸 If the flow's destination is outside this trust region, the request must fall within the class allocation through the "next hop" trust region, which was set up through a bilateral agreement between the two trust regions 🫶 The requester's BB tells the adjacent region's BB that it's going to use some of that rate allocation ✨ Then the BB configures the right leaf router with info about the packet flow, so it gets its service once the service is supposed to start 🧚 That configuration is "soft state," which means the BB keeps refreshing it periodically 😭 The BB in the adjacent region handles configuring the border router so the allocated flow can pass, plus any other configuration and negotiation within and across its borders needed to get the flow to its final destination 🔥

At DMZs, there must be an unambiguous way to determine the local source of a packet. 🙈

The source of an interface could be figured out from its MAC address, and that would be used to classify packets as arriving over a logical link directly from the source domain tied to that MAC address 💅 Because of this, we can keep using figures that show a single pipe between two different domains 🍓

---

All agreements and negotiations happen between two adjacent domains only 💖 An initial request might kick off communication between BBs on several domains along a path, but every single conversation is only between two adjacent BBs 👑 At the start, these agreements are going to be prenegotiated and fairly static, but some may get more dynamic as the service evolves 🌈

4.2 Examples

Okay bestie, let's look at some examples of BB transactions in a non-trivial, multi-transit-domain Internet 🌐✨. The BB framework lets you pick an operating point anywhere on a spectrum, from "no signalling across boundaries" all the way to "each flow set up dynamically" 🦋. We might slide along that spectrum over time as the mechanisms get deployed everywhere and BBs get more sophisticated, but the statically allocated end should always have uses 💅. Being able to support this whole range at once matters a lot, both for rolling things out gradually and for letting ISPs offer and price stuff in lots of different ways 💖. These examples roughly go from simplest to most sophisticated 🎀. Heads up: we assume domains contract for some amount of Marked traffic that can be requested as either Assured or Premium in each individual flow setup transaction. The examples just say "Marked," but real transactions would have to specify Assured or Premium 🙈.

A statically configured example with no BB messages exchanged: Here all allocations are statically preallocated through purely bilateral agreements between users (individual TCPs, individual hosts, campus networks, or whole ISPs) [6]. The allocations are in the form of usage profiles of rate, burst, and a time during which that profile is to be active. Users and providers negotiate these Profiles, which are then installed in the user domain BB and in the provider domain BB. No BB messages cross the boundary, because we assume this negotiation is done by human representatives of each domain 🤝. In this case, BBs only have to perform one of their two functions, which is allocating this Profile within their local domain. It's even possible to set all of these suballocations up in advance, and then the BB only needs to set up and tear down the Profile at the proper time and refresh the soft state in the leaf routers 🧚. From the user domain BB, the Profile is sent as soft state to the first hop router of the flow during the specified time. These Profiles might be set using RSVP, a variant of RSVP, SNMP, or some vendor-specific mechanism. Although this static approach can work for all Marked traffic, due to the strictly not oversubscribed requirement, it is only appropriate for Premium traffic as long as it is kept to a small percentage of the bottleneck path through a domain or is otherwise constrained to a well-known behavior. Similar restrictions might hold for Assured, depending on the expectation associated with the service 😬.

In figure 6, we show an example of setting a Profile in a leaf router 🍓. A usage profile has been negotiated with the ISP for the entire domain, and the BB parcels it out among individual flows as requested. The leaf router mechanism is the one shown in figure 3, with the token bucket set to the parameters from the usage profile. The ISP's BB would configure its own Profile Meter at the ingress router from that customer to make sure the Profile was maintained. This mechanism was shown in figure 5. We assume that the time duration and start times for any Profile to be active are maintained in the BB. The Profile is sent to the ingress device, or cleared from the ingress device, by messages sent from the BB. In this example, we assume that van@lbl wants to talk to ddc@mit 💌. The LBL-BB is sent a request from Van asking that premium service be assigned to a flow that is designated as having source address V:4 and going to destination address D:8. This flow should be configured for a rate of 128kb/sec and allocated from 1pm to 3pm. The request must be "signed" in a secure, verifiable manner 🔐. The request might be sent as data to the LBL-BB, as an e-mail message to a network administrator, or as a phone call to a network administrator. The LBL-BB receives this message, verifies that there is 128kb/sec of unused Premium service for the domain from 1-3pm, then sends a message to Leaf1 that sets up an appropriate Profile Meter. The message to Leaf1 might be an RSVP message, an SNMP message, or some proprietary method. All the domains passed must have sufficient reserve capacity to meet this request 🛤️.

Figure 6. Bandwidth Broker setting Profiles in leaf routers

A statically configured example with BB messages exchanged: Next we present an example where all allocations are statically preallocated, but BB messages are exchanged for greater flexibility 🦋. Figure 7 shows an end-to-end example for Marked traffic in a statically allocated internet. The numbers at the trust region boundaries indicate the total statically allocated Marked packet rates that will be accepted across those boundaries. For example, 100kbps of Marked traffic can be sent from LBL to ESNet, and a Profile Meter at the ESNet egress boundary would have a token bucket set to rate 100kbps. (There MAY be a shaper set at LBL's egress to ensure that the Marked traffic conforms to the aggregate Profile 🫶.) The tables inside the transit network "bubbles" show their policy databases and reflect the values after the transaction is complete. In Figure 7, V wants to transmit a flow from LBL to D at MIT at 10 Kbps. As in figure 6, a request for this profile is made of LBL's BB. LBL's BB authenticates the request and checks to see if there is 10kbps left in its Marked allocation going in that direction. There is, so the LBL-BB passes a message to the ESNet-BB saying that it would like to use 10kbps of its Marked allocation for this flow. ESNet authenticates the message, checks its database, and sees that it has a 10kbps Marked allocation to NEARNet (the next region in that direction) that is unused. The policy is that ESNet-BB must always inform ("ask") NEARNet-BB when it is about to use part of its allocation. NEARNET-BB authenticates the message, checks its database, and discovers that 20kbps of the allocation to MIT is unused, and the policy at that boundary is to not inform MIT when part of the allocation is about to be used ("<50 ok" where the total allocation is 50). The dotted lines indicate the "implied" transaction, which is the transaction that would have happened if the policy hadn't said "don't ask me" 👀. Now each BB can pass an "ok" message for this request across its boundary. This allows V to send to D, but not vice versa. It would also be possible for the request to originate from D 💜.

Figure 7. End-to-end example with static allocation.

Consider the same example where the ESNet-BB finds all of its Marked allocation to NEARNet, 10 kbps, in use 😭. With static allocations, ESNet must transmit a "no" to this request back to the LBL-BB. Presumably, the LBL-BB would record this information so it can complain to ESNet about the overbooking at the end of the month 📅! One solution to this sort of "busy signal" is for ESNet to get better at anticipating its customers' needs, or to require long advance bookings for every flow. It's also possible for bandwidth brokerage decisions to become dynamic 🌈.

Figure 8. End-to-end static allocation example with no remaining allocation

Dynamic Allocation and additional mechanism: As we shall see, dynamic allocation requires more complex BBs as well as more complex border policing, including the necessity to keep more state. However, it enables an important service with only a small increase in state 🧠✨.

The next set of figures (starting with figure 9) shows what happens in the case of dynamic allocation. As before, V requests 10kbps to talk to D at MIT. Since the allocation is dynamic, the border policers do not have a preset value. Instead, they are set to reflect the current peak value of Marked traffic permitted to cross that boundary. The request is sent to the LBL-BB 🚀.

Figure 9. First step in end-to-end dynamic allocation example.

In figure 10, note that ESNet has no allocation set up to NEARNet. This system is capable of dynamic allocations in addition to static ones, so it asks NEARNet if it can "add 10" to its allocation from ESNet. As in the figure 7 example, MIT's policy is set to "don't ask" for this case, so the dotted lines represent "implicit transactions" where no messages were exchanged. However, NEARNet does update its table to indicate that it is now using 20kbps of the Marked allocation to MIT 📊.

Figure 10. Second step in end-to-end dynamic allocation example

In figure 11, we see the third step, where MIT's "virtual ok" allows the NEARNet-BB to tell its border router to increase the Marked allocation across the ESNet-NEARNet boundary by 10 kbps 🙌.

Figure 11. Third step in end-to-end dynamic allocation example

Figure 11 shows NEARNet-BB's "ok" for that request transmitted back to ESNet-BB. This causes ESNet-BB to send its border router a message to create a 10 kbps subclass for the flow "V->D". This is required in order to ensure that the 10kpbs that has just been dynamically allocated gets used only for that connection 🎯. Note that this does require the per flow state to be passed from LBL-BB to ESNet-BB, but this is the only boundary that needs that level of flow information, and this further classification will only need to be done at that one boundary router and only on packets coming from LBL. Thus dynamic allocation requires more complex Profile Metering than that shown in figure 5 🧐.

Figure 12. Fourth step in end-to-end dynamic allocation example.

In figure 12, the ESNet border router gives the "ok" that a subclass has been created, causing the ESNet-BB to send an "ok" to the LBL-BB, which lets V know the request has been approved 🥳.

Figure 13. Final step in end-to-end dynamic allocation example

For dynamic allocation, a basic version of a CBQ scheduler [5] would have all the required functionality to set up the subclasses. RSVP currently provides a way to move the TSpec for the flow 🧩.

For multicast flows, we assume that packets that are bound for at least one egress can be carried through a domain at that level of service to all egress points. If a particular multicast branch has been subscribed to at best-effort when upstream branches are Marked, it will have its bit settings cleared before it crosses the boundary. The information required for this flow identification is used to augment the existing state that is already kept on this flow because it is a multicast flow. We note that we are already "catching" this flow, but now we must potentially clear the bit-pattern 🌸.

---

5. RSVP/int-serv and this architecture ✨

Much work has been done in recent years on the definition of related integrated services for the internet and on the specification of the RSVP signalling protocol 📚. The two-bit architecture proposed in this work can easily interoperate with those specifications 💞. In this section, we first discuss how the forwarding mechanisms described in section 3 can be used to support integrated services. Second, we discuss how RSVP could interoperate with the administrative structure of the BBs to provide better scaling 🫧.

5.1 Providing Controlled-Load and Guaranteed Service ✨

okay so we think the forwarding path mechanisms from section 3 are general enough to also give you Controlled-Load service [8] and a version of Guaranteed Quality of Service [9], which the int-serv WG cooked up 🍓. First things first: Premium service is basically a constrained version of Controlled-Load, where the burst size is capped at one packet and non-conforming packets get dropped 💅. So a network element that already does Premium can level up to Controlled-Load with a couple of minor parameter tweaks. You can lift the constraint on the token bucket size, or set the Premium service rate using the peak traffic rate parameter from the Controlled-Load spec. Then you just switch the policing action on out-of-profile packets from dropping them to sending them to the Best-effort queue 🦋.

Guaranteed service is also doable with Premium mechanisms, and it's giving full main character energy 👑. RFC 2212 [9] explains it like this: "The definition of guaranteed service relies on the result that the fluid delay of a flow obeying a token bucket (r, b) and being served by a line with bandwidth R is bounded by b/R as long as R is no less than r. Guaranteed service with a service rate R, where now R is a share of bandwidth rather than the bandwidth of a dedicated line approximates this behavior." The Premium service model clearly fits this picture ✨. RFC 2212 also says "Non-conforming datagrams SHOULD be treated as best-effort datagrams." So a policing Profile Meter that drops non-conforming datagrams would be acceptable, but you can also change the action for non-compliant packets from drop to sending them to the best-effort queue 🌈.

5.2 RSVP and BBs 🎀

in this section we talk about how RSVP signaling can work together with the BBs from section 4 to get a more scalable, end-to-end resource setup for Integrated Services 🧚. first, the BB architecture has three major differences from the original RSVP resource setup model, and I'm obsessed with all of them:

1. There exist apriori bilateral business relations between BBs of adjacent trust regions before one can set up end-to-end resource allocation. Real-time signaling is used only to activate or confirm that pre-negotiated Marked bandwidth is available, and to dynamically readjust the allocation amount when necessary. We note that this real-time signaling across domains is not required, but it depends on the nature of the bilateral agreement (e.g., the agreement might state "I'll tell you whenever I'm going to use some of my allocation" or not). 🤝
2. A few bits in the packet header, i.e. the P-bit and A-bit, are used to mark the service class of each packet. That means a full packet classification (checking all relevant fields in the header) only needs to happen once, at the leaf router. After that, packets get served according to their class bit settings ⭐.
3. RSVP resource setup assumes that resources will be reserved hop-by-hop at each router along the entire end-to-end path 🙈.

RSVP messages that hosts send to leaf routers can be intercepted and sent to the local domain's BB 💜. The BB processes the message and, if the request is approved, forwards a message to the leaf router that sets up the right per-flow packet classification. A message should also go to the egress border router so it can add to the aggregate Marked traffic allocation for packet shaping by the Profile Meter on outbound traffic. (It's possible that this is always set to the full allocation.) An RSVP message must also be sent across the boundary to the adjacent ISP's border router, either from the local domain's border router or from the local domain's BB. If the ISP is also implementing RSVP with a BB and diff-serv framework, its border router forwards the message to the ISP's local BB 🌸. A similar process to what happened in the first domain can then be carried out in the ISP domain, and then an RSVP message gets forwarded to the next ISP along the path. Inside a domain, packets are served solely according to the Marked bits 💖. The local BB knows exactly how much Premium traffic is permitted to enter at each border router, and which border router packets exit from. iconic, honestly 🔥.

---

6. Recommendations 🌸

This document has presented a reference architecture for differentiated services. Several variations can be envisioned, particularly for early and partial deployments, but we're not going to list all of them here 🦋. There has been a huge market demand for differentiated services lately, and this memo is one of the many efforts to meet it. It sketches out the framework of a flexible architecture for offering differential services, and in particular it defines a simple set of packet forwarding path mechanisms to support two basic types of differential services ✨. There are still a number of issues and parameters that need more exploration and refinement, but we believe it's both possible and feasible to start deploying differentiated services incrementally 🚀.

First, given that the basic mechanisms required in the packet forwarding path are clearly understood, both Assured and Premium services can be implemented today with manually configured BBs and static resource allocation. Initially we recommend conservative choices on the amount of Marked traffic that gets admitted into the network 🫶. Second, we plan to keep going with the effort started in this memo, plus the experimental work of the authors, to define and deploy increasingly sophisticated BBs. We hope to turn the experience gained from in-progress trial implementations on ESNet and CAIRN into future proposals to the IETF 💜.

Future revisions of this memo will present the receiver-based and multicast flow allocations in detail 👀. Once that step is finished, we believe the basic picture of a scalable, robust, secure resource management and allocation system will be complete. In this memo we described how the proposed architecture supports two services that seem to us to be at least a good starting point for trial deployment of differentiated services 🎀. Our main intent is to define an architecture with three services (Premium, Assured, and Best effort) that can be determined by specific bit-patterns, but without precluding additional levels of differentiation within each service. It seems more experimentation and experience is required before we could standardize more than one level per service class 🤓. Our base-level approach says that everyone has to provide "at least" Premium service and Assured service as documented.

We feel rather strongly about two things. First, we should not try to define, at this time, something beyond the minimalist two-service approach. Second, the architecture we define must be open-ended, so that more levels of differentiation might be standardized in the future 😭. We believe this architecture is completely compatible with approaches that would define more levels of differentiation within a particular service, if the benefits of doing so become well understood 🌈.

7. Acknowledgments 🫶

The authors have benefited from many discussions, both in person and electronically, and they want to particularly thank Dave Clark, who has been responsible for the genesis of many of the ideas presented here, even though he does not agree with all of the content of this document 🙈. They also thank Sally Floyd for comments on an earlier draft. A comment from Jon Crowcroft was partially responsible for including section 5. Comments from Fred Baker made the authors try to make it clearer that we are defining two base-level services, irrespective of the bit patterns used to encode them 💅.

8. Security Considerations 💀

There are no security considerations associated with this document. Zero. None. Not one. We checked. Still, stay alert out there, bestie 🚨.

9. References 📚

[1] D. Clark, "Adding Service Discrimination to the Internet", Proceedings of the 23rd Annual Telecommunications Policy Research Conference (TPRC), Solomons, MD, October 1995.

[2] V. Jacobson, "Differentiated Services Architecture", talk in the Int-Serv WG at the Munich IETF, August, 1997.

[3] Clark, D. and J. Wroclawski, "An Approach to Service Allocation in the Internet", Work in Progress, also talk by D. Clark in the Int-Serv WG at the Munich IETF, August, 1997.

[4] Braden, et al., "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.

[4] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.

[5] S. Floyd and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, pp 365-386, August 1995.

[6] D. Clark, private communication, October 26, 1997.

[7] "Advanced QoS Services for the Intelligent Internet", Cisco Systems White Paper, 1997.

[8] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.

[9] Shenker, S., Partirdge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.

[10] D. Clark and W. Fang, "Explicit Allocation of Best Effort packet Delivery Service", IEEE/ACM Transactions on Networking, August, 1998, Vol6, No 4, pp. 362-373. also at: http://diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf

Authors' Addresses 💌

Kathleen Nichols
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706

Phone: 408-525-4857
EMail:   kmn@cisco.com


Van Jacobson
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706

EMail: van@cisco.com


Lixia Zhang
UCLA
4531G Boelter Hall
Los Angeles, CA  90095

Phone: 310-825-2695
EMail: lixia@cs.ucla.edu

Appendix: A Combined Approach to Differential Service in the Internet by David D. Clark 🌟

After draft-nichols-diff-svc-00 was submitted, the co-authors had a discussion with Dave Clark and John Wroclawski, which resulted in Clark using the presentation slot for the draft at the December 1997 IETF Integrated Services Working Group meeting. A reading of the slides shows that it was Clark's proposal on "mechanisms", "services", and "rules", and how to proceed in the standards process, that has guided much of the process in the subsequently formed IETF Differentiated Services Working Group. We believe Dave Clark's talk gave us a solid approach for bringing quality of service to the Internet in a manner that is compatible with its strengths 🧚.

The slides presented at the December 1997 IETF Integrated Services Working Group are included with the Postscript version 📎.

Full Copyright Statement ✨

Copyright (C) The Internet Society (1999). All Rights Reserved. 🎀

okay so this is the legal bit, and I promise it's actually chill. 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. So you can share it, explain it, build stuff from it, all good 💖

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. Basically: don't edit the original and pass it off as yours 🙅‍♀️ The only exceptions are standards work (which follows its own process) or translating it into another language 🌈

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Translation: these permissions don't expire, and nobody can take them back later. Forever and ever 🦋

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. So the doc comes as-is, and the authors aren't promising it's perfect or non-infringing or fit for any specific job 💅 Read it, use your brain, you know the drill 🧠

---

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. 🫶 Basically, the folks who keep the RFC series running (the RFC Editor) are funded by the Internet Society right now. Iconic behind-the-scenes support 👑