RFC 2998

A Framework for Integrated Services Operation over Diffserv Networks

📅 published November 2000, from ietf

RFC 2998 🎀 A Framework for Integrated Services Operation over Diffserv Networks

okay bestie, this one is the framework doc for running Intserv over Diffserv networks, and it's giving the blueprint for QoS across mixed networks 💅✨

  • RFC number: 2998
  • Title: A Framework for Integrated Services Operation over Diffserv Networks
  • Network Working Group
  • Authors: Y. Bernet, P. Ford (Microsoft), R. Yavatkar (Intel), F. Baker (Cisco), L. Zhang (UCLA), M. Speer (Sun Microsystems), R. Braden (ISI), B. Davie (Cisco), J. Wroclawski (MIT LCS), E. Felstaine (SANRAD)
  • Category: Informational
  • Date: November 2000
  • Obsoletes / Updates: none listed in the title block

Status of this Memo

so this is an informational memo 🧚 It's sharing info with the Internet community, it is not a standard of any kind, and it can be distributed freely with no limits 🌸

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

Abstract

okay so the Integrated Services (Intserv) architecture is all about giving apps end-to-end Quality of Service (QoS) 🔥 across heterogeneous networks (aka networks that are totally different from each other, very messy, very real). To make that end-to-end dream work, Intserv has to run over a bunch of different kinds of network elements. And a network that runs Differentiated Services (Diffserv) can count as one of those elements in the whole path ✨ This doc lays out a framework for how Intserv can be supported over Diffserv networks 🦋

Table of Contents

   1. Introduction .................................................  3
   1.1 Integrated Services Architecture ............................  3
   1.2 RSVP ........................................................  3
   1.3 Diffserv ....................................................  4
   1.4 Roles of Intserv, RSVP and Diffserv .........................  4
   1.5 Components of Intserv, RSVP and Diffserv ....................  5
   1.6 The Framework ...............................................  6
   1.7 Contents ....................................................  6
   2. Benefits of Using Intserv with Diffserv ......................  7
   2.1 Resource Based Admission Control ............................  7
   2.2 Policy Based Admission Control ..............................  8
   2.3 Assistance in Traffic Identification/Classification .........  8
   2.3.1 Host Marking ..............................................  9
   2.3.2 Router Marking ............................................  9
   2.4 Traffic Conditioning ........................................ 10
   3. The Framework ................................................ 10
   3.1 Reference Network ........................................... 11
   3.1.1 Hosts ..................................................... 11
   3.1.2 End-to-End RSVP Signaling ................................. 12
   3.1.3 Edge Routers .............................................. 12
   3.1.4 Border Routers ............................................ 12
   3.1.5 Diffserv Network Region ................................... 13
   3.1.6 Non-Diffserv Network Regions .............................. 13
   3.2 Service Mapping ............................................. 13
   3.2.1 Default Mapping ........................................... 14
   3.2.2 Network Driven Mapping .................................... 14
   3.2.3 Microflow Separation ...................................... 14
   3.3 Resource Management in Diffserv Regions ..................... 15
   4. Detailed Examples of the Operation of
      Intserv over Diffserv Regions ................................ 16
   4.1 Statically Provisioned Diffserv Network Region .............. 16
   4.1.1 Sequence of Events in Obtaining End-to-end QoS ............ 16
   4.2 RSVP-Aware Diffserv Network Region .......................... 18
   4.2.1 Aggregated or Tunneled RSVP ............................... 19
   4.2.3 Per-flow RSVP ............................................. 20
   4.2.4 Granularity of Deployment of RSVP Aware Routers ........... 20
   4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region ..... 21
   5. Implications of the Framework for Diffserv Network Regions ... 21
   5.1 Requirements from Diffserv Network Regions .................. 21
   5.2 Protection of Intserv Traffic from Other Traffic ............ 22
   6. Multicast .................................................... 22
   6.1 Remarking of packets in branch point routers ................ 24
   6.2 Multicast SLSs and Heterogeneous Trees ...................... 25
   7. Security Considerations ...................................... 26
   7.1 General RSVP Security ....................................... 26
   7.2 Host Marking ................................................ 26
   8. Acknowledgments .............................................. 27
   9. References ................................................... 27
   10. Authors' Addresses .......................................... 29
   11.  Full Copyright Statement ................................... 31

1. Introduction

okay so QOS-enabled IP networks have gone two main ways 🌈 One is the Integrated Services architecture (Intserv) [10], with its signaling protocol RSVP [1]. The other is the Differentiated Services architecture (Diffserv) [8]. This doc is all about how a Diffserv network can team up with the Intserv architecture to deliver end-to-end QOS 💖

1.1 Integrated Services Architecture

the Integrated Services architecture added a set of extensions to the classic best-effort model of the Internet 🦋 The goal? Let apps get end-to-end QOS. A key piece of the architecture is its set of service definitions, and right now that set has the controlled load and guaranteed services ✨ The architecture assumes that some explicit setup mechanism passes info to routers, so they can deliver the requested services to the flows that need them. RSVP is the most famous example of that setup mechanism, but Intserv is built to fit other mechanisms too 🧚

Intserv services get implemented by "network elements" 🎀 Usually a network element is a single node, like a router or a link. But bigger things, like ATM "clouds" or 802.3 networks, can also act as network elements. And as we'll get into below, a Diffserv network (or "cloud") can be seen as a network element inside a larger Intserv network 🫶

1.2 RSVP

RSVP is a signaling protocol that apps can use to ask the network for resources 💅 The network replies by explicitly admitting or rejecting those requests. Apps that have quantifiable resource needs describe them with Intserv parameters, as defined in the right Intserv service specification 🍓 Like we said, RSVP and Intserv are separable: RSVP is a signaling protocol that can carry Intserv info 💜 Intserv defines the models for describing service types, quantifying resource needs, and checking whether the requested resources are available at each relevant network element (that's admission control) 👑

the way RSVP usually gets used today is through a combined RSVP/Intserv architecture 🔥 In this model, RSVP signals per-flow resource needs to network elements using Intserv parameters. Those network elements run Intserv admission control on the signaled requests. On top of that, traffic control on each network element is set up so every admitted flow gets its requested service in strict isolation from other traffic 🌸 To pull this off, RSVP signaling configures microflow (MF) [8] packet classifiers in Intserv-capable routers along the traffic flow's path. These classifiers sort packets per flow, based on IP addresses and port numbers 🦋

the following factors have held back RSVP (and the Intserv architecture) from rolling out across the Internet at large 🙈

  1. Per-flow state and per-flow processing raise scalability concerns for large networks.
  2. Only a small number of hosts currently generate RSVP signaling. That number is expected to grow dramatically, but many applications may never generate RSVP signaling.
  3. The necessary policy control mechanisms (access control, authentication, and accounting) have only recently become available [17].

1.3 Diffserv

so Diffserv is the total opposite of RSVP's per-flow vibe 🌈 Instead of tracking every flow, Diffserv networks sort packets into a small number of aggregated flows, called "classes," based on the Diffserv codepoint (DSCP) in the packet's IP header ✨ This is known as behavior aggregate (BA) classification [8]. At each Diffserv router, packets get a "per-hop behavior" (PHB), and the DSCP is what triggers it 🎀 The big win here is scalability. Diffserv gets rid of per-flow state and per-flow processing, so it scales beautifully to large networks 💖

1.4 Roles of Intserv, RSVP and Diffserv

we see Intserv, RSVP and Diffserv as complementary technologies, all working toward end-to-end QoS 🫶 Together they can make apps like IP-telephony, video-on-demand, and various non-multimedia mission-critical applications actually work well 🔥 Intserv lets hosts request per-flow, quantifiable resources along end-to-end data paths and get feedback on whether those requests can be admitted 👑 Diffserv is what keeps everything scalable across large networks 🦋

1.5 Components of Intserv, RSVP and Diffserv ✨

Okay bestie, before we go any further we need to name the pieces 💅 Here's the cast of characters for these QoS technologies:

RSVP signaling 📣 is the standard RSVP signaling protocol. Hosts use it to signal their application's resource requirements to the network (and to each other). Network elements use RSVP signaling to send an admission control decision back to hosts. RSVP signaling may or may not carry Intserv parameters.

Admission control at a network element may or may not be based on the Intserv model 🤷‍♀️

MF traffic control is traffic control applied to individual traffic flows, so it has to recognize each flow on its own through MF classification 🔍

Aggregate traffic control is traffic control applied to whole sets of traffic flows together. Those sets are recognized through BA (DSCP) classification. In this document, "aggregate traffic control" and "Diffserv" mean the same thing, so we use them interchangeably 🦋

Aggregate RSVP. Plain RSVP only does per-flow reservations, but extensions are being developed so RSVP can reserve resources for aggregated traffic, meaning sets of flows that can be recognized by BA classification. This use of RSVP may help control how bandwidth gets allocated in Diffserv networks 🌸

Per-flow RSVP. This is the conventional use of RSVP, doing resource reservations for individual microflows 🎯

RSVP/Intserv is the prevailing model of RSVP usage. It includes RSVP signaling with Intserv parameters, Intserv admission control, and per-flow traffic control at network elements. Very classic, very iconic 👑

Diffserv Region. This is a set of contiguous routers that support BA classification and traffic control. Such a region may also support MF classification too, but the goal of this document is to explain how a region like this can deliver end-to-end QOS when only BA classification happens inside the Diffserv region 💖

Non-Diffserv Region. This is everything in the network outside the Diffserv region. Such a region may also offer a variety of different types of classification and traffic control 🌈

Note that, for the purposes of this document, the defining feature of a Diffserv region is the type of classification and traffic control used to deliver end-to-end QOS for a particular application. So even if you can't call a region "purely Diffserv" for all the traffic flowing through it, you can totally define it that way from the perspective of how one application's traffic gets treated 🫶

1.6 The Framework 🧚

In the framework we present, end-to-end, quantitative QoS is delivered by applying the Intserv model end-to-end across a network that contains one or more Diffserv regions. The Diffserv regions may, but are not required to, take part in end-to-end RSVP signaling in order to optimize resource allocation and support admission control 💜

From the perspective of Intserv, Diffserv regions of the network are treated as virtual links connecting Intserv capable routers or hosts. It's kind of like how an 802.1p network region is treated as a virtual link in [5] 🔗 Inside the Diffserv regions, routers implement specific PHBs (aggregate traffic control). The total amount of traffic admitted into the Diffserv region that will receive a certain PHB may be limited by policing at the edge. Because of that, we expect the Diffserv regions of the network will be able to support the Intserv style services requested from the periphery ✨

In our framework, we address the support of end-to-end Integrated Services over the Diffserv regions of the network. Our goal is to enable seamless inter-operation 🥰 So the network administrator is free to choose which regions of the network act as Diffserv regions. At one extreme, the Diffserv region is pushed all the way out to the periphery, with hosts alone having full Intserv capability. At the other extreme, Intserv is pushed all the way to the core, with no Diffserv region at all 🌟

1.7 Contents 📚

In section 3 we discuss the benefits you can get from using the aggregate traffic control provided by Diffserv network regions, in the broader context of the Intserv architecture. In section 4, we present the framework and the reference network. Section 5 details two possible realizations of the framework. Section 6 discusses the implications of the framework for Diffserv. Section 7 presents some issues specific to multicast flows 🍓

2. Benefits of Using Intserv with Diffserv 🎀

The primary benefit of Diffserv aggregate traffic control is its scalability 📈 In this section, we talk about the benefits that interoperation with Intserv can bring to a Diffserv network region. Note that this discussion is specifically about servicing quantitative QoS applications. By this we mean the applications that are able to quantify their traffic and QoS requirements 🧮

2.1 Resource Based Admission Control 🚦

In Intserv networks, quantitative QoS applications use an explicit setup mechanism (e.g., RSVP) to request resources from the network. The network may accept or reject these requests in response. This is "explicit admission control". Explicit and dynamic admission control helps make sure network resources are optimally used 💅 To really get this, think about a Diffserv network region that provides only aggregate traffic control with no signaling. In that region, admission control is applied in a relatively static way, by provisioning policing parameters at network elements. For example, a network element at the ingress to a Diffserv network region could be provisioned to accept only 50 Kbps of traffic for the EF DSCP.

Static admission control protects the network to some degree, but it can be super ineffective 😭 For example, imagine there are 10 IP telephony sessions originating outside the Diffserv network region, each needing 10 Kbps of EF service from the Diffserv network region. The network element protecting the Diffserv region is provisioned to accept only 50 Kbps of traffic for the EF DSCP, so it will discard half the offered traffic. That traffic gets discarded from the aggregation of traffic marked EF, with no regard to the microflow it came from. So it's likely that none of the ten IP telephony sessions will get satisfactory service, even though there are actually enough resources in the Diffserv network region to satisfy five sessions 💀

With explicitly signaled, dynamic admission control, the network signals rejection in response to requests for resources that would go over the 50 Kbps limit. So upstream network elements (including originating hosts) and applications have the info they need to take corrective action 🧠 The application might stop transmitting, or request admission for a smaller traffic profile. The host operating system might mark the application's traffic with the DSCP that corresponds to best-effort service. Upstream network elements might re-mark packets on the rejected flow to a lower service level. In some cases, it may be possible to reroute traffic over alternate paths or even alternate networks (e.g., the PSTN for voice calls). Either way, the integrity of the flows that were admitted is preserved, at the expense of the flows that were not admitted 🫡 So by appointing an Intserv-conversant admission control agent for the Diffserv region, you can enhance the service that the network provides to quantitative QoS applications. Iconic glow-up 🌸

2.2 Policy Based Admission Control 🔐

In network regions where RSVP is used, resource requests can be intercepted by RSVP-aware network elements and reviewed against policies stored in policy databases. These resource requests securely identify the user and the application that the resources are requested for. That means the network element can consider per-user and/or per-application policy when deciding whether or not to admit a resource request 👀 So, in addition to optimizing the use of resources in a Diffserv network region (as discussed in 3.1), RSVP conversant admission control agents can apply specific customer policies to decide which customer traffic flows are entitled to use the Diffserv network region's resources. Customer policies can be used to allocate resources to specific users and/or applications 💖

By comparison, in Diffserv network regions without RSVP signaling, policies are typically applied based on the Diffserv customer network that traffic originates from, not on the originating user or application inside that customer network 🙈

2.3 Assistance in Traffic Identification/Classification 🏷️

Within Diffserv network regions, traffic gets its service based on the DSCP marked in each packet's IP header. So, to get a particular level of service inside the Diffserv network region, the correct DSCP has to be marked in the packet headers. There are two mechanisms for doing that: host marking and router marking. With host marking, the host operating system marks the DSCP in transmitted packets. With router marking, routers in the network are configured to identify specific traffic (typically based on MF classification) and to mark the DSCP as packets transit the router. Each scheme has advantages and disadvantages. Regardless of which scheme is used, explicit signaling offers significant benefits 🌈

2.3.1 Host Marking 💻

With host marking, the host operating system marks the DSCP in transmitted packets. This approach has the benefit of shifting per-flow classification and marking to the source of the traffic, which is where it scales best 📈 It also lets the host decide which mark is appropriate for each transmitted packet, and therefore the relative importance attached to each packet. The host is generally better equipped to make that decision than the network is 🧠 Furthermore, if IPSEC encryption is used, the host may be the only device in the network able to make a meaningful determination of the appropriate marking for each packet, since fields such as port numbers would be unavailable to routers for MF classification 🔒

Host marking requires that the host be aware of how the network interprets DSCPs. This information can be configured into each host. However, that configuration imposes a management burden 😩 Alternatively, hosts can use an explicit signaling protocol such as RSVP to query the network for a suitable DSCP or set of DSCPs to apply to packets for which a certain Intserv service has been requested. An example of how this can be achieved is described in [14] 🦋

2.3.2 Router Marking 🦋

okay so for router marking, the MF classification criteria have to be configured in the router somehow 💅. That can happen dynamically (like using COPS provisioning), by a request from the host operating system, or statically through manual configuration or automated scripts.

Static setup is where it gets messy 😭. Often you want to give service to traffic based on the application and/or the user who's sending it. Sometimes you can spot packets from a certain app by their IP port numbers in the headers, and packets from a certain user by their source IP address. BUT those criteria change frequently 💀. Users get different IP addresses from DHCP, apps use transient ports, and multiple users can share one IP address. All of that makes it super hard to manage the static config needed to mark traffic in routers.

The iconic alternative is letting host operating systems signal the classification criteria to the router on behalf of users and apps 🫶. RSVP signaling is literally made for this job, and we'll get into why later in this doc 🎀. On top of keeping the MF criteria dynamically and accurately updated, RSVP signaling also lets routers classify IPSEC [13] packets (by using the SPI), which otherwise would be totally unrecognizable 🙈.

2.4 Traffic Conditioning ✨

Intserv-capable network elements can condition traffic at a per-flow level, using shaping and/or policing (or some mix of both) 🌸. Pre-conditioning traffic like this before it's submitted to the Diffserv region of the network is a real W 👑. It boosts the ability of the Diffserv region to provide quantitative services using aggregate traffic control.

3. The Framework 🌈

In the big picture we're imagining, the Integrated Services architecture is used to deliver end-to-end QOS to applications 🧚. The network is a mix of Intserv-capable nodes (where MF classification and per-flow traffic control get applied) and Diffserv regions (where aggregate traffic control gets applied). Individual routers may or may not take part in RSVP signaling, no matter where they live in the network.

We'll look at two specific realizations of the framework. In the first one, resources inside the Diffserv regions are statically provisioned, and those regions have no RSVP aware devices at all. In the second one, resources inside the Diffserv region are dynamically provisioned, and select devices in the Diffserv network regions do participate in RSVP signaling 🦋.

3.1 Reference Network

We'll talk about both realizations using this reference network 💖:

         ________         ______________         ________
        /        \       /              \       /        \
       /          \     /                \     /          \
|---| |        |---|   |---|          |---|   |---|        | |---|
|Tx |-|        |ER1|---|BR1|          |BR2|---|ER2|        |-|Rx |
|---| |        |-- |   |---|          |---|   |---|        | |---|
       \          /     \                /     \          /
        \________/       \______________/       \________/

    Non-Diffserv region   Diffserv region     Non-Diffserv region

             Figure 1: Sample Network Configuration

So this reference network has a Diffserv region in the middle of a bigger network that supports Intserv end-to-end 🧁. The Diffserv region is a mesh of routers, and at least some of them provide aggregate traffic control. The regions outside it (the non-Diffserv regions) are meshes of routers and attached hosts, and at least some of those support the Integrated Services architecture.

To keep things simple, we're only looking at one QoS sender, Tx, talking across this network to one QoS receiver, Rx 🎀. The edge routers (ER1, ER2) that sit next to the Diffserv region connect to the border routers (BR1, BR2) inside the Diffserv region.

Economically speaking, the Diffserv region sells service to the network outside of it, and that network turns around and provides service to hosts 💅. So the non-Diffserv regions are basically clients or customers of the Diffserv region. From here on we use the term "customer" for the non-Diffserv regions. Also, the boundaries of the regions may or may not line up with administrative domain boundaries, and one region might contain multiple administrative domains 👑.

We'll now define the major components of the reference network.

3.1.1 Hosts

We assume that both sending and receiving hosts use RSVP to communicate the quantitative QoS requirements of QoS-aware applications running on the host ✨. In principle, other mechanisms could be used to set up resource reservations in Intserv-capable nodes, but RSVP is clearly the prevalent mechanism for this 🫶.

Usually, a QoS process inside the host operating system generates RSVP signaling on behalf of the applications 🌈. This process may also invoke local traffic control.

Like we talked about above, traffic control in the host may mark the DSCP in transmitted packets, and shape transmitted traffic to match the requirements of the Intserv service in use 🦋. Or, the first Intserv-capable router downstream from the host can handle these traffic control functions instead 🧚.

3.1.2 End-to-End RSVP Signaling

We assume RSVP signaling messages travel end-to-end between hosts Tx and Rx, to support RSVP/Intserv reservations outside the Diffserv network region 💖. We require that these end-to-end RSVP messages are at least carried across the Diffserv region 🎀. Depending on the specific realization of the framework, these messages may be processed by none, some or all of the routers in the Diffserv region 🌸.

3.1.3 Edge Routers

ER1 and ER2 are edge routers, sitting right next to the Diffserv network regions 🍓. What the edge routers do depends on the specific realization of the framework. When the Diffserv network region is RSVP unaware, the edge routers act as admission control agents to the Diffserv network 🛡️. They process signaling messages from both Tx and Rx, and apply admission control based on resource availability inside the Diffserv network region and on customer defined policy. When the Diffserv network region is RSVP aware, the edge routers apply admission control based on local resource availability and on customer defined policy instead. In that case, the border routers become the admission control agent to the Diffserv network region 👑.

We'll explain the edge routers in more depth later on, for each of the two realizations 🫶.

3.1.4 Border Routers

BR1 and BR2 are border routers, and they live inside the Diffserv network region 🌈. What they do depends on the specific realization of the framework too. When the Diffserv network region is RSVP-unaware, these routers act as pure Diffserv routers 🦋. Their only job is to police submitted traffic based on the service level in the DSCP and the agreement negotiated with the customer (aggregate trafficcontrol). When the Diffserv network region is RSVP-aware, the border routers take part in RSVP signaling and act as admission control agents for the Diffserv network region 💅.

We'll describe the border routers in more depth later, for each of the two realizations ✨.

3.1.5 Diffserv Network Region

The Diffserv network region supports aggregate traffic control, and it's assumed NOT to be capable of MF classification 🙈. Depending on the specific realization of the framework, some routers inside the Diffserv region may be RSVP aware, which makes them capable of per-flow signaling and admission control 🧁. If devices in the Diffserv region aren't RSVP aware, they'll pass RSVP messages transparently with negligible performance impact (see [6]) 💖.

The Diffserv network region provides two or more levels of service based on the DSCP in packet headers 👑. It might be a single administrative domain, or it might span multiple domains.

3.1.6 Non-Diffserv Network Regions

The network outside the Diffserv region is made up of Intserv capable hosts and other network elements 🌸. Those other elements may include routers and maybe various types of network (e.g., 802, ATM, etc.) 🧚. We can reasonably assume these network elements support Intserv, although that might not be required if the network is over-provisioned 🎀. Even if these elements aren't Intserv capable, we assume they'll pass RSVP messages unhindered 🫶. Routers outside the Diffserv network region aren't ruled out from providing aggregate traffic control to some subset of the traffic passing through them 🦋.

3.2 Service Mapping

Intserv service requests specify an Intserv service type and a set of quantitative parameters known as a "flowspec" 💅. At each hop in an Intserv network, the Intserv service requests get interpreted in a form that makes sense for the specific link layer medium. For example, at an 802.1 hop, the Intserv parameters are mapped to an appropriate 802.1p priority level [5] 🌈.

In our framework, Diffserv regions of the network are analogous to the 802.1p capable switched segments described in [5] ✨. Requests for Intserv services must be mapped onto the underlying capabilities of the Diffserv network region 🍓. Aspects of the mapping include:

  • selecting an appropriate PHB, or set of PHBs, for the requested service;
  • performing appropriate policing (including, perhaps, shaping or remarking) at the edges of the Diffserv region;
  • exporting Intserv parameters from the Diffserv region (e.g., for the updating of ADSPECs);
  • performing admission control on the Intserv requests that takes into account the resource availability in the Diffserv region.

How exactly these functions get performed depends on the way bandwidth is managed inside the Diffserv network region 🫶. We cover that topic in Section 4.3.

When the PHB (or set of PHBs) has been selected for a particular Intserv flow, it may be necessary to communicate the choice of DSCP for the flow to other network elements 💜. There are two schemes that can achieve this, and we'll go through them below 🔥.

3.2.1 Default Mapping

In this scheme, there's some standard, well-known mapping from Intserv service type to a DSCP that invokes the appropriate behavior in the Diffserv network 🧚. Easy peasy 💖.

3.2.2. Network Driven Mapping 🎀

Okay so in this scheme, RSVP-conversant routers in the Diffserv network region (maybe at its edge) can override the well-known mapping from 4.2.1. If DSCPs get marked at the ingress to the Diffserv region, they can simply be remarked at the boundary routers. 💅 But if DSCP marking happens upstream of the Diffserv region, either in a host or a router, then the right mapping has to be communicated upstream to whatever is doing the marking. RSVP can handle that, as described in [14]. 🫶

Where DSCP gets marked and whether the well-known service mapping gets overridden is a policy decision. The administrator of the Diffserv network region makes that call together with the administrator of the network next to it. 👑

3.2.3. Microflow Separation 🦋

Boundary routers at the edge of the Diffserv region will typically police traffic coming in from outside the Diffserv region, so the resources inside stay protected. ✨ This policing happens on an aggregate basis, and it doesn't care about the individual microflows inside each aggregate. 😭 So a misbehaving microflow can grab more than its fair share of resources within the aggregate, and that drags down the service for every other microflow. Yikes. 💀 There are a few ways to fix this:

  1. Per microflow policing at the edge routers. Honestly this is the most appropriate spot for microflow policing 🧚, because it pushes the per-flow work out to the edges of the network, where it scales better. Also, Intserv-capable routers outside the Diffserv region are responsible for giving microflow service to their customers, while the Diffserv region is responsible for giving aggregate service to its customers. So this setup just mirrors who is responsible for what. Iconic. 👑
  2. Per microflow policing at the border routers. This one scales worse than the option above 🥴 and it also adds a management burden on the Diffserv region. Still, it might make sense in certain cases, where the Diffserv boundary routers offer per microflow policing as a value-add to their Intserv customers. 🍓
  3. Relying on upstream shaping and policing. Sometimes the customer trusts the shaping of certain groups of hosts enough that it doesn't need reshaping or policing at the edge of the Diffserv region. 🌸 But here's the tea: even if the hosts shape their microflows properly, those shaped flows can get distorted while they transit the non-Diffserv region of the network. ⭐ Depending on how much distortion there is, the aggregate capacities in the Diffserv region might need some over-provisioning, or you might need to re-police using either option 1 or option 2 above. Which mechanism you pick is a policy call, made by the administrator of the network outside the Diffserv region. 💜

3.3. Resource Management in Diffserv Regions 🌈

There are a bunch of ways to manage resources (like bandwidth) in the Diffserv network regions so they can meet the needs of end-to-end Intserv flows. 💖 The options are:

  • statically provisioned resources;
  • resources dynamically provisioned by RSVP;
  • resources dynamically provisioned by other means (e.g., a form of Bandwidth Broker).

We'll get into the details of using each of these approaches in the next section. 🫶

4. Detailed Examples of the Operation of Intserv over Diffserv Regions ✨

Now for the fun part, where we see the framework actually in action! 🔥 We walk through two examples. In one, the Diffserv network region is RSVP unaware. In the other, it's RSVP aware. 🧚

4.1. Statically Provisioned Diffserv Network Region 💅

In this example, none of the devices in the Diffserv network region are RSVP aware. The Diffserv network region is statically provisioned. The customer(s) of the Diffserv network region and the owner of that region have negotiated a static contract (service level specification, or SLS) for the transmit capacity to be provided to the customer at each of a number of standard Diffserv service levels. 🎀 The "transmit capacity" can be as simple as an amount of bandwidth, or it can be a more complex "profile" involving factors like burst size, peak rate, time of day, etc. 🌸

It helps to picture each edge router in the customer network as having two halves. There's a standard Intserv half, which interfaces to the customer's network regions, and a Diffserv half, which interfaces to the Diffserv network region. 🦋 The Intserv half can identify and process traffic at per-flow granularity. 💜

The Diffserv half of the router can be thought of as a number of virtual transmit interfaces, one for each Diffserv service level negotiated in the SLS. 👑 The router has a table that shows the transmit capacity provisioned per the SLS at each Diffserv service level. This table, together with the default mapping described in 4.2.1, is used to make admission control decisions on Intserv flows that cross the Diffserv network region. ✨

4.1.1. Sequence of Events in Obtaining End-to-end QoS 🌈

This is the play-by-play of how an application gets end-to-end QoS when the hosts use RSVP. 🍓

  1. The QoS process on the sending host Tx generates an RSVP PATH message that describes the traffic the sending application offers. 📨
  2. The PATH message gets carried toward the receiving host, Rx. In the network region the sender is attached to, standard RSVP/Intserv processing gets applied at capable network elements. 🧚
  3. At the edge router ER1, the PATH message goes through standard RSVP processing, and PATH state gets installed in the router. Then the PATH message is sent onward to the Diffserv network region. 🦋
  4. The PATH message gets ignored by the routers in the Diffserv network region, then processed at ER2 under standard RSVP processing rules. 🌸
  5. When the PATH message reaches the receiving host Rx, the operating system generates an RSVP RESV message. It indicates interest in the offered traffic of a certain Intserv service type. 💖
  6. The RESV message is carried back toward the Diffserv network region and the sending host. Consistent with standard RSVP/Intserv processing, it may be rejected at any RSVP-capable node on the path if resources aren't deemed sufficient to carry the requested traffic. 🥴
  7. At ER2, the RESV message goes through standard RSVP/Intserv processing. It may be rejected if resources on ER2's downstream interface aren't deemed sufficient for the requested resources. If it isn't rejected, it gets carried transparently through the Diffserv network region and arrives at ER1. ✨
  8. In ER1, the RESV message triggers admission control processing. ER1 compares the resources requested in the RSVP/Intserv request to the resources available in the Diffserv network region at the corresponding Diffserv service level. That corresponding service level is determined by the Intserv to Diffserv mapping we talked about earlier. The availability of resources is determined by the capacity provisioned in the SLS. ER1 may also apply a policy decision, so the resource request can be rejected based on the customer's specific policy criteria, even when the aggregate resources are determined to be available per the SLS. 👑
  9. If ER1 approves the request, the RESV message is admitted and allowed to continue upstream toward the sender. If ER1 rejects the request, the RESV isn't forwarded, and the appropriate RSVP error messages are sent. If the request is approved, ER1 updates its internal tables to show the reduced capacity available at the admitted service level on its transmit interface. 🫶
  10. The RESV message proceeds through the network region the sender is attached to. Any RSVP node in this region may reject the reservation request due to inadequate resources or policy. If the request isn't rejected, the RESV message arrives at the sending host, Tx. 🌈
  11. At Tx, the QoS process receives the RESV message. It reads receipt of the message as an indication that the specified traffic flow has been admitted for the specified Intserv service type (in the Intserv-capable nodes). It may also learn the appropriate DSCP marking to apply to packets for this flow from the information provided in the RESV. 💅
  12. Tx may mark the DSCP in the headers of packets transmitted on the admitted traffic flow. The DSCP may be the default value that maps to the Intserv service type specified in the admitted RESV message, or it may be a value explicitly provided in the RESV. 🎀

And that's how it all comes together! ✨ End-to-end QoS gets delivered through a combo of networks that support RSVP/Intserv and networks that support Diffserv, and it's literally giving main character energy. 👑💖

4.2. RSVP-Aware Diffserv Network Region ✨

okay so in this example, the customer's edge routers are standard RSVP routers 💅, and the border router, BR1, is RSVP aware 🦋. there may also be other routers inside the Diffserv network region that are RSVP aware 🌸. ngl this is my favorite part: those routers can take part in some form of RSVP signaling, but they classify and schedule traffic in aggregate, based on DSCP, and not on the per-flow classification criteria that standard RSVP/Intserv routers use 🙈. so you could say their control-plane is RSVP while their data-plane is Diffserv 🧚. you get the benefits of RSVP signaling and keep most of the scalability that comes with Diffserv 💖.

In the example before this one, there's no signaling between the Diffserv network region and anything outside it 🫶. the only explicit exchange of resource availability information between the two network regions is the negotiation of an SLS. ER1 is configured with the information the SLS represents, so it can act as an admission control agent for the Diffserv network region. but this setup doesn't really support SLSs that change dynamically, since ER1 needs reconfiguring every single time the SLS changes 😭. it's also hard to use the resources in the Diffserv region efficiently, because admission control doesn't look at the resources in the Diffserv network region along the specific path that would be impacted 💀.

by contrast, when the Diffserv network region is RSVP aware, the admission control agent is part of the Diffserv network 👑. that means changes in the capacity available in the Diffserv region can be indicated to the Intserv-capable nodes outside it via RSVP. if you include routers inside the Diffserv region in the RSVP signaling, you can improve how efficiently resources get used inside the region, and you get more confidence that the resources requested at admission control are actually available at that moment 🎀. this works because admission control can be linked to the availability of resources along the specific path that would be impacted. we call this benefit of RSVP signaling "topology aware admission control" 🌈. another perk is that supporting RSVP signaling inside the Diffserv region lets you change how the Diffserv region is provisioned (for example, giving the EF queue in a router more or less bandwidth) in response to resource requests coming from outside the Diffserv region ✨.

there are a few ways to support dynamic provisioning and topology aware admission control inside the Diffserv network region 🦋. these include aggregated RSVP, per-flow RSVP and bandwidth brokers, which we'll go through in the following paragraphs.

4.2.1. Aggregated or Tunneled RSVP

a number of documents [3,6,15,16] propose ways to extend RSVP so it can reserve resources for an aggregation of flows between the edges of a network 🍓. border routers may talk to core routers and other border routers using aggregated RSVP to reserve resources between the edges of the Diffserv network region. initial reservation levels for each service level may be set up between major border routers, based on expected traffic patterns. border routers could trigger changes in reservation levels when the cumulative per-flow RSVP requests coming from the non-Diffserv regions hit high or low-water marks 📈.

in this approach, admission of per-flow RSVP requests from nodes outside the Diffserv region gets counted against the matching aggregate reservations for the corresponding service level 🧾. the size of those aggregate reservations may or may not be dynamically adjusted to handle changes in the per-flow reservations 🤷‍♀️.

the advantage here is that it gives the Diffserv network region dynamic, topology aware admission control without needing the amount of RSVP signaling processing that per-flow RSVP would require 💜.

we should note that managing resources in a Diffserv region with aggregated RSVP is most likely to be feasible only within a single administrative domain 🙃, because each domain will probably pick its own mechanism for managing its resources.

4.2.3. Per-flow RSVP

in this approach, described in [3], routers in the Diffserv network region respond to the standard per-flow RSVP signaling that comes from the Intserv-capable nodes outside the Diffserv region 🎠. this gives you the benefits of the previous approach (dynamic, topology aware admission control) without needing aggregated RSVP support 🫧. resources also get used more efficiently, because admission control happens per flow. the catch is that the demands on RSVP signaling resources inside the Diffserv network region may be significantly higher than with an aggregated RSVP approach 😬.

also, per-flow RSVP and aggregated RSVP aren't mutually exclusive in a single Diffserv region 🤝. you can use per-flow RSVP at the edges of the Diffserv region and only use aggregation in some "core" region inside it 💅.

4.2.4. Granularity of Deployment of RSVP Aware Routers

in 4.2.2 and 4.2.3, some subset of the routers inside the Diffserv network is RSVP signaling aware (though traffic control is aggregated rather than per-flow) ⭐. how many routers in the core take part in RSVP signaling is a provisioning decision that must be made by the network administrator 🧑‍💻.

in one extreme case, only the border routers take part in RSVP signaling 😳. in that case, either the Diffserv network region must be extremely over-provisioned (and so inefficiently used), or it must be carefully and statically provisioned for limited traffic patterns. the border routers must enforce these patterns 🚧.

in the other extreme case, every router in the Diffserv network region might take part in RSVP signaling 🌟. then resources can be used with optimal efficiency, but the signaling processing requirements and the associated overhead go up. as noted above, RSVP aggregation is one way to limit the signaling overhead, at the cost of some loss of optimality in resource utilization 🍰.

it's likely that some network administrators will compromise by enabling RSVP signaling on some subset of routers in the Diffserv network region 🫶. those routers will probably be major traffic switching points, with over-provisioned or statically provisioned regions of RSVP unaware routers in between them 🌈.

4.3. Dynamically Provisioned, Non-RSVP-aware Diffserv Region

border routers might not use any form of RSVP signaling inside the Diffserv network region, and might use custom protocols instead to talk to an "oracle" 🔮. the oracle is an agent with enough knowledge of resource availability and network topology to make admission control decisions. the set of RSVP aware routers in the previous two examples can be thought of collectively as a kind of distributed oracle 🧠. in various definitions of the "bandwidth broker" [4], it acts as a centralized oracle 👑.

5. Implications of the Framework for Diffserv Network Regions 🎀

we've described a framework where RSVP/Intserv style QoS can be provided across end-to-end paths that include Diffserv network regions 💖. this section talks through some of the implications of that framework for the Diffserv network region 🦋.

5.1. Requirements from Diffserv Network Regions

a Diffserv network region must meet the following requirements in order for it to support the framework described in this document 📋.

  1. A Diffserv network region must be able to provide support for the standard Intserv QoS services between its border routers. it must be possible to invoke these services by use of standard PHBs within the Diffserv region and appropriate behavior at the edge of the Diffserv region 🧚.
  2. Diffserv network regions must provide admission control information to their "customer" (non-Diffserv) network regions. this information can be provided by a dynamic protocol or through static service level agreements enforced at the edges of the Diffserv region 📨.
  3. Diffserv network regions must be able to pass RSVP messages, in such a manner that they can be recovered at the egress of the Diffserv network region. the Diffserv network region may, but is not required to, process these messages. mechanisms for transparently carrying RSVP messages across a transit network are described in [3,6,15,16] 🚚.

to meet these requirements, additional work is required in the areas of:

  1. Mapping Intserv style service specifications to services that can be provided by Diffserv network regions 🗺️.
  2. Definition of the functionality required in network elements to support RSVP signaling with aggregate traffic control (for network elements residing in the Diffserv network region) 🛠️.
  3. Definition of mechanisms to efficiently and dynamically provision resources in a Diffserv network region (e.g., aggregated RSVP, tunneling, MPLS, etc.). this might include protocols by which an "oracle" conveys information about resource availability within a Diffserv region to border routers. one example of such a mechanism is the so-called "bandwidth broker" proposed in [19,20,21] 🔥.

5.2. Protection of Intserv Traffic from Other Traffic

network administrators must be able to share resources in the Diffserv network region between three types of traffic 🫶.

a. End-to-end Intserv traffic. this is typically traffic associated with quantitative QoS applications. it requires a specific quantity of resources with a high degree of assurance 👑.

b. Non-Intserv traffic. the Diffserv region may allocate resources to traffic that doesn't use Intserv techniques to quantify its requirements, e.g., through static provisioning and SLSs enforced at the edges of the region 🌸. this kind of traffic might be tied to applications whose QoS requirements aren't easily quantifiable but which still need a "better than best-effort" level of service 🍓.

c. All other (best-effort) traffic. these three classes of traffic must be isolated from each other by the appropriate configuration of policers and classifiers at ingress points to the Diffserv network region, and by appropriate provisioning within the Diffserv network region 🚧. to protect Intserv traffic in Diffserv regions of the network, we suggest that the DSCPs assigned to such traffic not overlap with the DSCPs assigned to other traffic 💅✨.

6. Multicast ✨

okay so multicast is where Intserv over Diffserv gets way more complicated than unicast 😭 every participating region has ONE ingress router and zero, one, or several egress routers, and the drama is all about regions with several egress routers 💅 (multicast outside the Diffserv region is honestly easy, because every Intserv-capable router along the tree stores state for each flow 🦋)

Picture this reference network:

                                      Non-Diffserv region 2
                                                ________
                                               /        \
                                              |          | |---|
         ________         _____________       |          |-|Rx1|
        /        \       /          |--\      |---|      | |---|
       /          \     /          /|BR2\-----\ER2|     /
|---| |        |---|   |---|  |--|/ |---|      \--|____/
|Tx |-|        |ER1|---|BR1|--|RR|      |       ________
|---| |        |-- |   |---|  |--|\ |---|      /--|     \
       \          /     \          \|BR3/-----|ER3|      | |---|
        \________/       \__________|--/      |---|      |-|Rx2|
                                              |          | |---|
Non-Diffserv region 1   Diffserv region        \        /
                                                \______/

                                      Non-Diffserv region 3

       Figure 2: Sample Multicast Network Configuration

This is basically Figure 1's setup, BUT in Figure 2 copies of the packets sent by Tx get delivered to multiple receivers outside the Diffserv region, namely Rx1 and Rx2 😍 And the packets get copied inside the Diffserv region at a "branch point" router RR 🌸 In this network BR1 is the ingress router to the Diffserv region, and BR2 and BR3 are the egress routers.

In the simplest case, Rx1 and Rx2 need identical reservations 🎀 The Diffserv framework [18] supports service level specifications (SLS) from an ingress router to one, some, or all of the egress routers. So we get a "one to many" SLS inside the Diffserv region, going from BR1 to BR2 and BR3. Once the Diffserv region grants that SLS, the ingress router BR1 (or maybe an upstream node like ER1) marks packets entering the Diffserv region with the right DSCP ✨ The packets get routed to the egresses of the Diffserv domain using the original multicast address.

The two big problems, which we'll get into, come from heterogeneous multicast trees with branch points inside the Diffserv region. Those are trees where the resource requirement is NOT uniform across all receivers 😤 An example in the Figure 2 network is when both Rx1 and Rx2 need to receive multicast data from Tx1, but only ONE of them has asked for a service above best effort. Let's dig into those scenarios 🔍

6.1 Remarking of packets in branch point routers

In that scenario, packets arriving at BR1 get marked with the appropriate DSCP for the requested Intserv service and then get sent to RR 🦋 Packets arriving at the branch point must be sent towards BR2 with the same DSCP, otherwise the service to Rx1 is degraded. BUT the packets heading from RR towards BR3 don't need to keep that high assurance level anymore 🙃 They may be demoted to best effort, so the QoS for other packets on that branch of the tree isn't disrupted. Several problems show up in this scenario:

  • In the Diffserv region, DSCP marking happens at the edge routers (ingress), but a branch point router might be a core router, and core routers don't mark packets 💀
  • Being a core Diffserv router, RR classifies based on aggregate traffic streams (BA), not per flow (MF) classification. So it doesn't necessarily have a way to tell apart the packets that belong to a specific multicast tree and need demotion from the other packets in the behavior aggregate, which all carry the same DSCP 😭
  • Since RR may be RSVP-unaware, it may not take part in the admission control process, so it wouldn't store any per-flow state about the reservations for the multicast tree. So even if RR could do MF classification and DSCP remarking, it wouldn't know enough about downstream reservations to remark the DSCP intelligently 🙈

There are a bunch of ways to deal with these problems 🌈 We'll list some below, but none is ideal in every case, and more mechanisms may be developed in the future:

  1. If some Intserv-capable routers are placed inside the Diffserv region, it might be possible to administer the network topology and routing parameters so that branch points only occur at those routers 🧚 These routers would support MF classification and remarking, and hold per-flow state for the heterogeneous reservations they're the branch point for. Note that in this case, branch point routers would have basically the same functionality as ingress routers of an RSVP-aware Diffserv domain 👑
  2. Packets sent on the "non-reserved" branch (from RR towards BR3) get marked with the "wrong" DSCP. That means they aren't demoted to best effort and keep their DSCP instead 🤷‍♀️ This requires over-reserving resources along that link, or it risks degrading service to packets that legitimately carry the same DSCP along that path. BUT it lets the Diffserv routers stay free of per-flow state ✨
  3. A combination of mechanisms 1 and 2 may be an effective compromise 💖 In this case there are some Intserv-capable routers in the core of the network, but the network can't be administered so that ALL branch points fall at those routers.
  4. Administrators of Diffserv regions may decide not to enable heterogeneous sub-trees in their domains. With different downstream reservations, a ResvErr message would be sent according to the RSVP rules. This is similar to the approach taken for Intserv over IEEE 802 Networks [2,5] 🫶
  5. In [3], a scheme was introduced where branch point routers inside the aggregation region (i.e., the Diffserv region) keep reduced state information about the reservations, using measurement-based admission control 🔥 Under this scheme, packets get tagged by the more knowledgeable Intserv edge routers with scheduling information, which is used in place of the detailed Intserv state. If the Diffserv region and branch point routers are designed following that framework, demotion of packets becomes possible 🎉

6.2 Multicast SLSs and Heterogeneous Trees

Multicast flows with heterogeneous reservations bring some real challenges for SLSs 😩 For example, a common SLS says a certain amount of traffic may enter a Diffserv region marked with a certain DSCP, and that traffic may be destined for any egress router of that region. We call that a homogeneous, or uniform, SLS 💅 BUT in a multicast environment, a single packet admitted to the Diffserv region may use resources along many paths in the region, because it gets replicated and forwarded towards many egress routers. Alternatively, it may flow along just a single path 🦋 It gets even more complicated because of the possibility described above (and shown in Figure 2), where a multicast packet might be treated as best effort along some branches while getting higher QOS treatment along others 🌀 We're just noting here that specifying meaningful SLSs that meet the needs of heterogeneous flows, and that providers can actually meet, is likely to be challenging 😬

Dynamic SLSs may help with these issues 💜 For example, by using RSVP to signal the resources needed along different branches of a multicast tree, it may be possible to get much closer to allocating resources only where they're needed, instead of overprovisioning or underprovisioning certain branches 🎀 This is essentially the approach described in [15].

7. Security Considerations

7.1 General RSVP Security

We're proposing that RSVP signaling be used to obtain resources in both Diffserv and non-Diffserv regions of a network 🔐 So all RSVP security considerations apply [9]. On top of that, network administrators are expected to protect network resources by configuring secure policers at interfaces with untrusted customers. This part is SERIOUS, bestie 🚨

7.2 Host Marking

Even though it doesn't mandate host marking of the DSCP, our proposal does allow it 👀 Letting hosts set the DSCP directly may alarm network administrators, and honestly that's fair 😰 The obvious worry is that hosts may try to "steal" resources. In fact, hosts may try to exceed negotiated capacity in Diffserv network regions at a particular service level, whether they invoke that service level directly (by setting the DSCP) or indirectly (by submitting traffic that gets classified in an intermediate marking router to a particular DSCP) 🙅‍♀️

Either way, it will generally be necessary for each Diffserv network region to protect its resources by policing, to make sure customers don't use more resources than they're entitled to at each service level (DSCP) 🛡️ The exception is when the host is known to be trusted, e.g., a server under the control of the network administrators. If an untrusted sending host does NOT perform DSCP marking, the boundary router (or trusted intermediate routers) must provide MF classification, mark, and police. If an untrusted sending host DOES perform marking, the boundary router only needs to provide BA classification and police to make sure the customer isn't exceeding the aggregate capacity negotiated for the service level 🔥

In summary, there are no additional security concerns raised by marking the DSCP at the edge of the network, since Diffserv providers will have to police at their boundaries anyway 💅 Furthermore, this approach reduces the granularity at which border routers must police, which pushes finer grain shaping and policing responsibility to the edges of the network. That's where it scales better and provides the other benefits described in Section 3.3.1 🦋

The bigger Diffserv network regions get to focus on protecting their networks, while the Intserv-capable nodes focus on shaping and policing their own traffic so it stays in compliance with their negotiated Intserv parameters ✨ Main character energy for everyone 👑

8. Acknowledgments

Authors thank the following individuals for their comments that led to improvements to the previous version(s) of this document: David Oran, Andy Veitch, Curtis Villamizer, Walter Weiss, Francois le Faucheur and Russell White 🫶 Thank you, babes 🥹

Many of the ideas in this document have been previously discussed in the original Intserv architecture document [10] 🌸

9. References 📚

Okay bestie, here are all the sources this doc leans on, numbered exactly like the original so you can cross-check them 🧚

  • [1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", RFC 2205, September 1997.
  • [2] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F. and M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol For RSVP-based Admission Control Over IEEE 802 Style Networks", RFC 2814, May 2000.
  • [3] Berson, S. and R. Vincent, "Aggregation of Internet Integrated Services State", Work in Progress.
  • [4] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.
  • [5] Seaman, M., Smith, A., Crawley, E. and J. Wroclawski, "Integrated Service Mappings on IEEE 802 Networks", RFC 2815, May 2000.
  • [6] Guerin, R., Blake, S. and Herzog, S., "Aggregating RSVP based QoS Requests", Work in Progress.
  • [7] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  • [8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
  • [9] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
  • [10] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
  • [11] Garrett, M. and M. Borden, "Interoperation of Controlled-Load Service and Guaranteed Service with ATM", RFC 2381, August 1998.
  • [12] Weiss, Walter, Private communication, November 1998.
  • [13] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
  • [14] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
  • [15] Baker, F., Iturralde, C., le Faucheur, F., and Davie, B. "RSVP Reservation Aggregation", Work in Progress.
  • [16] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
  • [17] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, D. and A. Sastry, "COPS Usage for RSVP", RFC 2749, January 2000.
  • [18] Bernet, Y., "A Framework for Differentiated Services", Work in Progress.
  • [19] Jacobson Van, "Differentiated Services Architecture", talk in the Int-Serv WG at the Munich IETF, August 1997.
  • [20] Jacobson, V., Nichols K. and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, June 1999.
  • [21] First Internet2 bandwidth broker operability event http://www.merit.edu/internet/working.groups/i2-qbone-bb/inter-op/index.htm

10. Authors' Addresses 🎀

Meet the squad who wrote this! Here's how to reach each of them 💌

Yoram Bernet 💖

Yoram Bernet
Microsoft
One Microsoft Way
Redmond, WA 98052

Phone: +1 425-936-9568
EMail: yoramb@microsoft.com

Raj Yavatkar ✨

Raj Yavatkar
Intel Corporation
JF3-206 2111 NE 25th. Avenue
Hillsboro, OR 97124

Phone: +1 503-264-9077
EMail: raj.yavatkar@intel.com

Peter Ford 🦋

Peter Ford
Microsoft
One Microsoft Way
Redmond, WA 98052

Phone: +1 425-703-2032
EMail: peterf@microsoft.com

Fred Baker 🌸

Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, CA 93111

Phone: +1 408-526-4257
EMail: fred@cisco.com

Lixia Zhang 👑

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

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

Michael Speer 🌈

Michael Speer
Sun Microsystems
901 San Antonio Road, UMPK15-215
Palo Alto, CA 94303

Phone: +1 650-786-6368
EMail: speer@Eng.Sun.COM

Bob Braden 🍓

Bob Braden
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695

Phone: +1 310-822-1511
EMail: braden@isi.edu

Bruce Davie 🧚

Bruce Davie
Cisco Systems
250 Apollo Drive
Chelmsford, MA 01824

Phone: +1 978-244-8000
EMail: bsd@cisco.com

Eyal Felstaine 💜

Eyal Felstaine
SANRAD Inc.
24 Raul Wallenberg st
Tel Aviv, Israel

Phone: +972-50-747672
Email: eyal@sanrad.com

John Wroclawski ⭐

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

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

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

Here's the legal stuff, and it matters, so read it carefully 🫶

You're totally allowed to copy this document and share it with others, and to make derivative works that comment on or explain it or help with implementing it. You can also publish and distribute those, in whole or in part, with no restrictions of any kind. The one condition is that the copyright notice and this paragraph have to be included on all copies and derivative works.

BUT this document itself can't be modified in any way. That means no removing the copyright notice, and no removing the references to the Internet Society or other Internet organizations. The exceptions are: when it's needed for developing Internet standards (then the copyright procedures in the Internet Standards process must be followed), or when it's being translated into languages other than English.

The limited permissions above are perpetual, and the Internet Society and its successors or assigns won't revoke them. Ever 🔒

Now the disclaimer, which is in caps because it's serious:

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. Thank you, Internet Society, for keeping the lights on for the RFC Editor! 🙌

📦 where this page comes from