RFC 2430

Bestie, let's get into RFC 2430 💖 It's titled A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE), written by T. Li of Juniper Networks and Y. Rekhter of Cisco Systems, dated October 1998. It's Informational, so it's sharing info rather than setting a standard 🎀 The title block doesn't list anything it obsoletes or updates.

Status of this Memo

Okay so the fine print first 📜 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved. 🌈

1.0 Abstract ✨

This doc describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs) 🌸 The big problem is that ISPs handle SO many flows that keeping per-flow state for all of them becomes unacceptable, literally. On top of that, large ISPs need traffic engineering, which means steering aggregated flows of traffic along specific paths 🦋

PASTE fixes this by using Multiprotocol Label Switching (MPLS) [1] and the Resource Reservation Protocol (RSVP) [2] to build a scalable traffic management architecture that supports differentiated services. It assumes you already have at least some familiarity with both of these technologies, bestie 🧚

2.0 Terminology 💅

In common usage, a packet flow (or just a flow) is a unidirectional stream of packets, spread out over time. Flows are typically super fine-grained and represent a single interchange between hosts, like a TCP connection. An aggregated flow is a bunch of flows that share forwarding state and a single resource reservation along a sequence of routers 🫶

MPLS is one way to support aggregated flows. Packets get tunneled by wrapping them in a minimal header [3]. Each header carries a label, and that label holds both forwarding and resource reservation semantics 🎀 MPLS has mechanisms for installing label-based forwarding information along a series of Label Switching Routers (LSRs) to build a Label Switched Path (LSP). LSPs can also be tied to resource reservation information 💜

RSVP is one protocol for constructing these LSPs [4]. When you pair it with the Explicit Route Object (ERO) [5], RSVP can build an LSP along an explicit route [6]. Iconic 👑

To support differentiated services, packets get divided into separate traffic classes. For conceptual purposes, this doc discusses three: Best Effort, Priority, and Network Control. The exact number of subdivisions within each class is still to be defined 🌸

Network Control traffic is mostly routing protocols and network management traffic. If it gets dropped, routing protocols can fail or flap, and that causes network instability 💀 So Network Control must have very low drop preference. The good news is that it's generally insensitive to moderate delays and only needs a relatively small amount of bandwidth. A small bandwidth guarantee is enough to insure that Network Control traffic operates correctly ✨

Priority traffic can come in lots of flavors depending on the application. Particular flows may need bandwidth guarantees, jitter guarantees, or upper bounds on delay. For the purposes of this memo, the subdivisions of priority traffic aren't distinguished. All priority traffic is assumed to have an explicit resource reservation 🔥

Right now, the vast majority of traffic in ISPs is Best Effort traffic. For the most part it's delay insensitive and reasonably adaptive to congestion 🍓

When flows are aggregated by traffic class and that aggregated flow gets placed inside an LSP, the result is called a traffic trunk, or simply a trunk. A packet's traffic class is orthogonal to the LSP it's on, so many different trunks, each with its own traffic class, can share an LSP if they have different traffic classes 🦋

3.0 Introduction 🌈

The next generation of the Internet brings special challenges that have to be handled by a single, coordinated architecture. This architecture allows for distinction between ISPs, but it also defines a framework where ISPs can provide end-to-end differentiated services in a coordinated and reliable way. With an architecture like that, an ISP can craft common agreements for handling differentiated services consistently, and those agreements can be composed to facilitate end-to-end differentiated services 🫶 So the goal of this doc is to describe an architecture for providing differentiated services within the ISPs of the Internet, while also including support for other forthcoming needs like traffic engineering. While it focuses on the needs of ISPs, it isn't limited to them. The same architecture could be used in any large, multiprovider catenet that needs differentiated services 💅

This doc only discusses unicast services. Extending the architecture to support multicast is a subject for future research 🔮

One of the primary considerations in any ISP architecture is scalability. Solutions whose state grows in proportion to the size of the Internet grow faster than Moore's law, which makes them intractable in the long term 😭 That's why solutions using mechanisms with very limited growth rates are strongly preferred 💖

Differentiated services discussions to date have often produced solutions that need per-flow state or per-flow queuing. The number of flows in an ISP within the "default-free zone of the Internet" scales with the size of the Internet, so that growth rate is hard to support and strongly argues for a solution with lower state requirements. At the same time, supporting differentiated services is a big benefit to most ISPs 👑 It lets providers offer special services, like priority bandwidth for mission critical services, to users willing to pay a service premium. Customers would contract with ISPs for these services under Service Level Agreements (SLAs). An agreement may specify the traffic volume, how the traffic is handled (in an absolute or relative manner), and the compensation the ISP receives 💸

Differentiated services are likely to be deployed across a single ISP first, to support applications like a single enterprise's Virtual Private Network (VPN). But that's only the first wave. Right after, there'll be a need for differentiated services to support extranets, enterprise VPNs that span ISPs, or industry interconnection networks like the ANX [7]. Because those applications span enterprises and therefore span ISPs, there's a clear need for inter-domain SLAs. This doc discusses the technical architecture that would allow creating those inter-domain SLAs 🎀

Another important consideration here is the arrival of traffic engineering within ISPs. Traffic engineering is the ability to move trunks away from the path selected by the ISP's IGP and onto a different path. That lets an ISP route traffic around known points of congestion in its network, which makes more efficient use of the available bandwidth. In turn, the ISP can get more competitive in its market by passing lower costs and better service on to its customers 🧚

Finally, providing end-to-end differentiated services means the architecture has to support consistent inter-provider differentiated services. Most flows on the Internet today traverse multiple ISPs, so a consistent description and treatment of priority flows across ISPs is a necessity 🫶

4.0 Components of the Architecture 🧩

The Differentiated Services Backbone architecture is the integration of several mechanisms that, when used in a coordinated way, achieve the goals outlined above. This section describes each mechanism in some detail, and later sections detail how they interoperate 🦋

4.1 Traffic classes

As described above, packets may fall into a variety of traffic classes. For ISP operations, it's essential that packets get accurately classified before they enter the ISP, and that it's really easy for an ISP device to figure out the traffic class of a particular packet 👀

The traffic class of MPLS packets can be encoded in the three bits reserved for CoS within the MPLS label header. Traffic classes for IPv4 packets can also be classified via the IPv4 ToS byte, possibly using the three precedence bits within that byte. Note that a consistent interpretation of the traffic class, no matter which bits are used to indicate it, is an important feature of PASTE 💜

In this architecture, it isn't overly important to control which packets entering the ISP have a particular traffic class. From the ISP's perspective, each Priority packet should come with some economic premium for delivery. So the ISP doesn't need to judge whether the traffic class is appropriate for the application 💅

It's important that any Network Control traffic entering an ISP gets handled carefully. Its contents must also be carefully authenticated. Right now there's no need for traffic generated outside a domain to transit a border router of the ISP, so that's a big deal to keep in mind 🔥

4.2 Trunks ✨

Okay so, traffic from one traffic class that gets squished into a single LSP is called a traffic trunk, or just a trunk 🎀. Trunks are the whole vibe of this architecture because they keep the infrastructure overhead from growing with the size of the network or the amount of traffic. As traffic scales up, the traffic inside the trunks gets bigger, but the number of trunks stays the same. Iconic 💅

The worst case is one trunk per traffic class from each entry router to each exit router. With N routers and C classes of service, that's (N * (N-1) * C) trunks 😭. Thankfully, you don't always need that many.

Trunks with a single exit point that share a common internal path can be merged into one sink tree 🌳. Figuring out whether two trunks can merge is pretty straightforward. When a new trunk is being set up and it crosses an existing trunk with the same traffic class and the same remaining explicit route, the new trunk can be spliced into the existing one right at the crossing point 🦋. The splice is simple: both incoming trunks do a normal label switching operation, but they both end up with the same outbound label. Each sink tree made this way touches each router at most once, and there's one sink tree per exit router, so you end up with N * C sink trees. Literally so clean 🧚

You can cut the count down even more if trunks or sink trees for different classes take the same path. This works because the traffic class of a trunk or sink tree is orthogonal to the path its LSP defines, which is a very fancy way of saying they don't interfere with each other 💜. So two trunks with different classes can share a label for any shared part of the topology that ends at the exit router. That means the whole topology can be overlaid with just N trunks. No cap, that's elegant 👑

Now, if Best Effort trunks and individual Best Effort flows are treated the exact same way, you don't need to set up any Best Effort trunk that would follow the IGP-computed path. The packets can just be forwarded directly without an LSP 🍓. Traffic engineering might need Best Effort trunks to be treated differently from individual Best Effort flows, though, and then you do need to set up LSPs for Best Effort trunks. Also, Priority trunks must be instantiated, because end-to-end RSVP packets supporting the aggregated Priority flows have to be tunneled 🔥.

Trunks can also be aggregated with other trunks by pushing a new label onto the label stack for each trunk, which bundles them into a single tunnel 🫶. For this document, that's still considered a trunk, but if we need to be specific, it's called an aggregated trunk. Two trunks can be aggregated if they share a portion of their path. There's no requirement on how long that shared portion has to be, so the exact requirements for forming an aggregated trunk are out of scope for this document 🙈. Also, the traffic class (the QoS indication) gets carried along when an extra label is added to a trunk, so trunks of different classes can be aggregated together ✨.

Trunks can be terminated at any point, which causes a deaggregation of the traffic. The obvious catch is that the deaggregation point needs enough switching capacity to handle the resulting traffic 💀.

For high reliability, a trunk can have one or more backup trunks 🛟. Backup trunks can be started either by the same router that would start the primary trunk or by a different backup router. The router that started the backup trunk can figure out the status of the primary trunk through out-of-band information, such as the IGP. (That router might be the same one that started the primary trunk, or a different one, fr fr.) If a backup trunk has been set up and the primary trunk comes back online, the backup trunk can be deactivated and the primary trunk used instead 🌈.

4.3 RSVP 🎀

So originally, RSVP was designed to install state for resource reservations on individual flows going to or from hosts, where the path was picked by destination-based routing 🧸. In its own words, "The RSVP protocol is used by a host, on behalf of an application data stream, to request a specific quality of service (QoS) from the network for particular data streams or flows" [RFC2205].

PASTE uses RSVP in a pretty different way 👀. First, RSVP is used to install state that covers a whole bunch of flows that all share a common path and a common pool of reserved resources. Second, RSVP is used to install forwarding-related state, including label switching information, on top of resource reservations. Third, the path this state gets installed along is no longer tied to destination-based routing. Main character energy 👑

The reason RSVP works for PASTE is the set of mechanisms it already has. Quoting the RSVP specifications again, "RSVP protocol mechanisms provide a general facility for creating and maintaining distributed reservation state across a mesh of multicast or unicast delivery paths." RSVP also gives you a straightforward way to extend it by creating new RSVP Objects 🔧. That flexibility means we can use those same mechanisms to create and maintain distributed state for things that aren't pure resource reservation, and also to create forwarding state alongside resource reservation state 🧚.

The original RSVP design says that "RSVP itself transfers and manipulates QoS control parameters as opaque data, passing them to the appropriate traffic control modules for interpretation". That idea can be extended to explicit route parameters and label binding parameters too 🦋. Just like QoS parameters, RSVP can carry and manipulate explicit route parameters and label binding parameters as opaque data. It passes explicit route parameters to the appropriate forwarding module, and label parameters to the appropriate MPLS module 💅.

An RSVP session in PASTE also isn't limited to a pair of hosts. It can run between pairs of routers that act as the originator and terminator of a traffic trunk 🫶.

Using RSVP in PASTE helps consolidate the procedures for three things: (a) setting up forwarding along an explicit route, (b) setting up a label switched path, and (c) RSVP's existing resource reservation procedures 🌸. These can all be combined in any way you like. The big win here is that those three tasks aren't independent. They're inter-related 🔗. Any alternative that handled each function with its own separate set of procedures would need extra coordination between the functions, which would add more complexity to the whole system 😭.

4.4 Traffic Engineering 🛣️

The whole point of traffic engineering is to give the ISP precise control over how traffic flows through its network 💖. It's needed because standard IGPs compute the shortest path across the ISP's network based only on the metric each link was administratively given. They don't take each link's load into account 🙃. If the ISP's network isn't a full mesh of physical links, there may not be an obvious way to assign metrics so that no congestion happens, given the known traffic patterns. Traffic engineering can be thought of as backup for the routing infrastructure, giving it extra info so traffic goes along specific paths, with the end goal of using network resources more efficiently ⭐.

Traffic engineering works by directing trunks along explicit paths inside the ISP's topology 🧭. That pulls traffic off the shortest path the IGP computed and, hopefully, onto links that aren't congested, while still arriving at the same destination. The explicit route is specified by listing out the routers along the path. Given that list, traffic engineering trunks can be built in a few different ways. For example, a trunk could be configured manually along the explicit path. That means configuring each router on the path with the state needed to forward the particular label. Some ISPs are doing exactly this for traffic engineering today 🍓.

Alternatively, a protocol like RSVP can be used with an Explicit Route Object (ERO) so the first router on the path can set up the trunk 🚀. Working out the explicit route is beyond the scope of this document, but it might take into account policy, static and dynamic bandwidth allocation, congestion in the topology, and manually configured alternatives 🧠.

4.5 Resource reservation 🌟

Priority traffic has certain requirements for capacity and traffic handling 💜. To give differentiated services, the ISP's infrastructure has to know about those requirements and support them 😤. The mechanism used to communicate these requirements dynamically is RSVP 📡. The flow specification inside RSVP can describe lots of characteristics of a flow or trunk. An LSR that receives RSVP info about a flow or trunk can look at it and then either accept or reject the reservation, based on its local policy 🧑‍⚖️. That policy will probably include constraints on which traffic handling functions the network can support, and on the total capacity the network is willing to provide for Priority traffic 🎀.

4.6 Inter-Provider SLAs (IPSs) ✨

Okay so, trunks that span multiple ISPs are basically built on legal agreements and other outside stuff 📜. That means one thing we'd totally expect to see in this kind of architecture is a bilateral agreement between ISPs to support differentiated services 🤝. Besides the obvious payment stuff, this agreement will likely spell out the acceptable traffic handling policies and the capacities both parties will use 💅.

Agreements like this already exist for Best Effort traffic. They're called peering agreements 🌸. If you extend a peering agreement to cover differentiated services, you get an Inter-Provider SLA (IPS) 💖. An IPS can list the kinds of differentiated services one ISP offers the other, plus the upper bound on how much traffic for each service the ISP is willing to accept and carry from the other ISP 📦. It can also limit which differentiated services are allowed, and set an upper bound on how much traffic can come from a third-party ISP and get passed from one signer of the IPS to the other 🚧. Not me being dramatic, but that's a lot of control! 😭

If the costs of the IPS aren't symmetric, the parties can agree that one ISP pays the other an appropriate amount 💸. The cost gap might come from unequal traffic exchange, the expense of delivering the exchanged traffic, or the overhead of running the protocols the two ISPs trade 🔧.

Heads up, bestie: PASTE gives us the technical basis for setting up IPSs, but the procedures for actually creating them are outside PASTE's scope 🙈.

4.7 Traffic shaping and policing 🚦

To make IPSs work, the interconnect between ISPs needs special facilities 🔌. These mechanisms keep the network that's sending a trunk of Priority traffic inside the agreed traffic characterization and capacity 🎯. A super simple example would be a token bucket system running on a per-trunk basis 🪣. There also need to be mechanisms that make sure, per trunk, that the receiving ISP only gets traffic that complies with the agreement between the ISPs 🛡️. Honestly, the whole point is that nobody gets surprise traffic. Iconic behaviour from the network 👑.

4.8 Multilateral IPSs 🌈

Trunks can span multiple ISPs, so setting up one particular trunk might need more than two ISPs 🫶. The result is a multilateral IPS. This is kinda unusual for the Internet, because it needs several participating parties just to get a useful result 🙃. It's also a challenge: without a commonly accepted service level definition, there will need to be a multilateral definition, and that definition might not be compatible with the IPSs between the same parties 😵‍💫.

Because this new type of agreement could be a lot, it may sometimes be simpler for certain ISPs to set up aggregated trunks through other ISPs, then contract with customers to aggregate their trunks 🧚. That way, trunks can span multiple ISPs without needing multilateral IPSs ✨.

Both of these options are possible and acceptable in this architecture. Which one to use is up to the participants, and they decide case by case 💜.

---

5.0 The Provider Architecture for differentiated Services and Traffic Engineering (PASTE) 🎀

The Provider Architecture for differentiated Services and Traffic Engineering (PASTE) is built on MPLS and RSVP as the tools for setting up differentiated service connections across ISPs 🦋. It stays scalable by bundling differentiated flows into traffic class specific MPLS tunnels, which are also called traffic trunks 🚂.

An ISP can give a trunk an explicit route, which decides where the trunk sits inside the ISP's infrastructure. That lets the ISP traffic engineer its own network 🗺️. Trunks can also be aggregated and merged. This helps the architecture scale, because it cuts down on how many individual trunks the intermediate systems have to handle 📉.

Special traffic handling, like specific queuing algorithms or drop computations, can be run by a network on a per-trunk basis. That means these services can scale with the number of trunks in the network 📈.

Agreements for handling trunks between ISPs need both legal documentation and conformance mechanisms on both sides 📑. A trunk is unidirectional, so it's enough for the transmitter to monitor and shape its outbound traffic, while the receiver polices the traffic profile 👀.

Trunks can either be aggregated across other ISPs, or they can be the subject of a multilateral agreement for carrying the trunk 🤝. RSVP information about individual flows gets tunneled inside the trunk to provide an end-to-end reservation 🔁. To make sure the return RSVP traffic is handled properly, each trunk also needs another tunnel running in the opposite direction 🔄. The reverse tunnel can be a different trunk, or it can be an independent tunnel that terminates at the same routers as the trunk. Routing symmetry between a trunk and its return is not assumed 🙅‍♀️.

RSVP already has local path repair built in 🛠️. When a trunk fails, that capability, together with the ability to specify abstractions in the ERO, lets RSVP re-establish the trunk in lots of failure scenarios 💪.

---

6.0 Traffic flow in the PASTE architecture 💌

To see how this architecture works, let's walk through a single differentiated flow 🎬. Say a user wants to make a phone call using a Voice over IP service 📞. The call is full duplex, but we can think about the data flow in each direction as half duplex, because the architecture works symmetrically 🪞.

Say the data packets for this voice call are created at a node S and need to reach a node D 📨. Since it's a voice call, the packets get encoded as Priority packets 🔊. If there's more granularity within the traffic classes, these packets might be encoded as wanting low jitter and having low drop preference 🧁. At first, this gets encoded in the precedence bits of the IPv4 ToS byte 🔢.

6.1 Propagation of RSVP messages 📣

To set up the flow to node D, node S first generates an RSVP PATH message that describes the flow in more detail 📝. For example, the flow might need 3kbps of bandwidth, be insensitive to jitter of less than 50ms, and need a delay of less than 200ms ⏱️. This message goes through node S's local network and eventually shows up in node S's ISP. Let's say that ISP is ISP F 🏢.

ISP F has a lot of freedom at this point 🦸‍♀️. The one requirement on F is to put the flow into a trunk before it leaves F's infrastructure 🚪. One thing F might do is run admission control at the first hop router 🚧. At that point, F would decide whether it has the capacity and capability to carry the flow across its own infrastructure to an exit router E 🤔. If the admission control decision is negative, the first hop router can tell node S using RSVP 🙅. Or it can pass the RSVP PATH message along the path to exit router E 🏃‍♀️. This is just normal RSVP operation on a differentiated flow ✅.

At exit router E, there's a trunk that ISP F maintains. It transits ISP X, Y, and Z and terminates in ISP L 🌉. Based on BGP path information or out of band information, node D is known to be a customer of ISP L 🕵️‍♀️. Exit router E matches the flow requirements in the RSVP PATH message against the characteristics of the trunk to ISP L, like the remaining capacity 📊. If the requirements are compatible, E notes that the flow should be aggregated into the trunk 💕.

To make sure the flow reservation happens end to end, the RSVP PATH message gets encapsulated into the trunk itself, and it's sent on to ISP L 📦. It eventually reaches the end of the trunk, where router U decapsulates it 🔓. PATH messages then keep going all the way to the final destination D 🎯.

Note that router U has to handle the end-to-end RSVP RESV messages really carefully 🧐. The RESV messages from router U to E have to come back through a tunnel to router E 🔙.

RSVP is also used by exit router E to set up and maintain the trunk to ISP L 🔧. The RSVP messages for this trunk are not placed inside the trunk itself, but the end-to-end RSVP messages are 🫧. Having multiple overlapping RSVP sessions in PASTE is pretty straightforward, but you do have to list them out explicitly whenever you talk about a particular RSVP session 📋.

6.2 Propagation of user data 🚀

Data packets created by S flow through ISP F's network, following the flow reservation, and eventually reach router E 🛤️. At that point, they get an MPLS label and get placed in the trunk 🏷️. Normal MPLS switching carries the packet across ISP X's network 🔀. The same traffic class still applies, because the class encoding gets carried over from the precedence bits of the IPv4 header into the CoS bits in the MPLS label 🎨. When the packet leaves ISP X's network, it can be aggregated into another trunk for the express purpose of transiting ISP Y 🧳.

Again, label switching brings the packet across ISP Y's network. Then the aggregated trunk terminates at a router in ISP Z's network 🌐. That router deaggregates the trunk and forwards the resulting trunk toward ISP L 🔀. This trunk transits ISP Z and terminates in ISP L at router U 🏁. At that point, the data packets are removed from the trunk and forwarded along the path computed by RSVP, and the call finally reaches node D 📞💖

6.3 Trunk establishment and maintenance 🎀

okay so in this example there are two trunks running around 💅 Trunk one starts at ISP F, goes through ISPs X, Y, and Z, and then ends at ISP L. Trunk two is an aggregated one that starts at ISP X, passes through ISP Y, and ends at ISP Z.

Trunk one can be set up through a multilateral agreement between ISPs F, X, Z, and L. ngl this part is kinda spicy 🌶️ ISP Y is NOT in that agreement, and ISP X is contractually on the hook for carrying the trunk into ISP Z. Also under this deal, ISP F maintains the tunnel, and it gets set up and kept alive using RSVP plus an explicit route object that lists ISP X, Z, and L. ISP X and ISP L are marked as strict hops, so nobody else can sneak in between F and X or between Z and L. 🙅‍♀️ There's no constraint on the path between X and Z, though, and there's no constraint on which router inside L's network terminates the trunk.

Usually, one of ISP F's routers that's adjacent to ISP X maintains this trunk. For robustness, ISP F also has a second router next to ISP X that provides a backup trunk. Backup energy, iconic 🦋

Trunk two can be set up through a bilateral agreement between ISP X and ISP Y. ISP Z isn't involved at all 🙈 This trunk is constrained so it ends on the last hop router inside Y's infrastructure. It gets initialized and maintained with RSVP and an explicit route that lists that last hop router in ISP Y's network. To handle the case where that last hop router fails, ISP X's routers have multiple explicit routes configured, and they can pick one working route from that list. 🌈 And to guard against ISP X's primary router failing, X provides a backup router with a backup trunk too. so many backups, bestie 😭

6.4 Robustness 💖

Here's the vibe: in this example there are no single points of failure once the traffic is inside ISP F's network ✨ Every trunk has a backup trunk ready to take over if the primary one dies. To protect against any single router going down, each trunk can be configured with several explicit route objects, and those objects end at one of several acceptable routers. main character energy for resilience 👑

---

7.0 Security Considerations 💀

Okay, serious moment, bestie 🥺 Priority traffic is inherently more 'valuable' than Best Effort traffic, so the ability to inject Priority traffic into a network must be carefully controlled. The signaling about Priority traffic also has to be authenticated, because that signaling will probably lead to specific accounting and eventually billing for the Priority services 🧾 ISPs are warned to make sure the Priority traffic they accept really comes from a known previous hop. This is a simple thing to nail at private peerings, but it's way harder at public interconnects. So exchanging Priority traffic at public interconnects should be done with great care 🫣

RSVP traffic needs to be authenticated too. One possible way to do this is to use the Integrity Object 🔐

8.0 Conclusion 🌸

PASTE, which stands for the Provider Architecture for differentiated Services and Traffic Engineering, gives you a robust and scalable way to deploy differentiated services on the Internet ✨ It scales by aggregating flows into class-specific MPLS tunnels. These tunnels, also called trunks, can be aggregated again, which creates a hierarchy of aggregated traffic. it's giving layers 🧅

Trunk setup and maintenance is done with RSVP, building on existing work in differentiated services. Explicit routes inside the RSVP signaling let providers do traffic engineering by putting trunks on particular links in their network 🛣️

The end result is an architecture that can scale to meet ISP needs, provide differentiated services at large scale, support traffic engineering, and keep growing alongside the Internet 🚀🦋

8.1 Acknowledgments 🫶

Thanks to Noel Chiappa, Der-Hwa Gan, Robert Elz, Lisa Bourgeault, and Paul Ferguson, who all inspired this document and left comments on it. iconic supporting cast 👑

9.0 References 📚

[1] Rosen, E., Viswanathan, A., and R. Callon, "A Proposed Architecture for MPLS", Work in Progress.

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

[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow,, G., Li, T., and A. Conta, "MPLS Label Stack Encoding", Work in Progress.

[4] Davie, B., Rekhter, Y., Rosen, E., Viswanathan, A., and V. Srinivasan, "Use of Label Switching With RSVP", Work in Progress.

[5] Gan, D.-H., Guerin, R., Kamat, S., Li, T., and E. Rosen, "Setting up Reservations on Explicit Paths using RSVP", Work in Progress.

[6] Davie, B., Li, T., Rosen, E., and Y. Rekhter, "Explicit Route Support in MPLS", Work in Progress.

[7] http://www.anxo.com/

10.0 Authors' Addresses 🖋️

Tony Li
Juniper Networks, Inc.
385 Ravendale Dr.
Mountain View, CA 94043

Phone: +1 650 526 8006
Fax:   +1 650 526 8001
EMail: tli@juniper.net


Yakov Rekhter
cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134

EMail:  yakov@cisco.com

11. Full Copyright Statement ⭐

Copyright (C) The Internet Society (1998). All Rights Reserved. 🌈

This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with its implementation, may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The one exception is when it's needed to develop Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed. The other exception is translating it into languages other than English. 🌍

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

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