RFC 2746

RSVP Operation Over IP Tunnels

📅 published January 2000, from ietf

RFC 2746: RSVP Operation Over IP Tunnels ✨

Okay bestie, this is RFC 2746 🎀, called RSVP Operation Over IP Tunnels, from the Network Working Group. It's a Standards Track document dated January 2000. The four authors are A. Terzis (UCLA), J. Krawczyk (ArrowPoint Communications), J. Wroclawski (MIT LCS), and L. Zhang (UCLA). The header doesn't list anything it obsoletes or updates, so it's not replacing or amending any other RFC 💅.

Status of this Memo 📜

Okay, the fine print first 🙈. This is an Internet standards track protocol for the Internet community, and it's openly asking for discussion and suggestions for improvements 🥺. To check the current standardization state and status of this protocol, look at the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited, so share away 💖.

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

Abstract 🌸

So this doc is about getting RSVP protocol services to work over IP tunnels 🦋. We quickly describe the problem, the kinds of solutions that could work, and the design goals of the approach. Then we get into the details of an implementation that hits those goals ✨.

1. Introduction 🧚

IP-in-IP "tunnels" are everywhere now 🌈. They're the go-to way to transport datagrams across the Internet. Usually a tunnel is used to route packets through parts of the network that don't directly support the service you want (like IPv6), or to boost and change how the deployed routing setup behaves (like multicast routing, mobile IP, or Virtual Private Net) 💅.

There are a ton of IP-in-IP tunneling protocols out there, and the RFC lineup is iconic 👑. [IP4INIP4] describes tunneling with an extra IPv4 header. [MINENC] shows how to shrink the "inner" IP header that [IP4INIP4] uses when the original datagram isn't fragmented. The generic tunneling method in [IPV6GEN] can tunnel either IPv4 or IPv6 packets inside IPv6. [RFC1933] explains how to tunnel IPv6 datagrams through IPv4 networks. [RFC1701] describes a generic routing encapsulation, and [RFC1702] applies that encapsulation to IPv4. Last but not least, [ESP] describes a mechanism for tunneling an encrypted IP datagram 🔐.

From the view of traditional best-effort IP delivery, a tunnel acts like any other link 🔗. Packets go in one end and come out the other, unless resource overload or an error makes them get lost 💀.

The RSVP setup protocol [RFC2205] is one piece of a framework that extends IP to support multiple, controlled classes of service over a wide range of link-level technologies 🔥. To make this tech as flexible as possible, it's ideal for tunnels to act as RSVP-controllable links inside the network 💜.

A tunnel, or really any kind of link, can take part in an RSVP-aware network in one of three ways. Which one applies depends on what the equipment building the tunnel can do and what the operator wants 🍓.

  1. The (logical) link may not support resource reservation or QoS control at all. This is a best-effort link. We call this a best-effort or type 1 tunnel in this note.
  2. The (logical) link may be able to promise that some overall level of resources is available to carry traffic, but not allocate resources to individual data flows. A configured resource allocation over a tunnel is an example of this. We call this case a type 2 tunnel in this note.
  3. The (logical) link may be able to make reservations for individual end-to-end data flows. We call this case a type 3 tunnel. The key thing that separates type 3 tunnels from type 2 tunnels is that in a type 3 tunnel, new tunnel reservations get created and torn down dynamically as end-to-end reservations come and go ✨.

Type 1 tunnels show up when at least one of the routers making up the tunnel endpoints doesn't support the scheme we describe here 🙅‍♀️. In that case the tunnel acts as a best-effort link. Our goal is just to make sure RSVP messages get across the link correctly, and that the presence of the non-controlled link gets detected, as the integrated services framework requires 🫶.

When both endpoints of the tunnel can support RSVP over tunnels, we want proper resources reserved along the tunnel 🎀. Depending on what the situation needs, this could mean one client's data flow gets placed into a bigger aggregate reservation (type 2 tunnels), or a new, separate reservation gets made just for that data flow (type 3 tunnels). And an RSVP reservation between the two tunnel endpoints doesn't mean every intermediate router along the tunnel path supports RSVP. That's the same as an existing end-to-end RSVP session passing transparently through a non-RSVP cloud ☁️.

Here's the tea though: right now, RSVP signaling over tunnels isn't possible 😭. RSVP packets entering the tunnel get wrapped in an outer IP header with a protocol number other than 46 (it's 4 for IP-in-IP encapsulation), and they don't carry the Router-Alert option. That makes them basically "invisible" to RSVP routers between the two tunnel endpoints 👻. On top of that, the current IP-in-IP encapsulation only adds an IP header as the outer wrapper. So it's impossible to tell apart packets that use reservations from those that don't, or to differentiate packets from different RSVP Sessions while they're inside the tunnel, because the encapsulation has no distinguishing info like a UDP port 🙃.

This document describes an IP tunneling enhancement that lets RSVP make reservations across all IP-in-IP tunnels 🦋. This mechanism can support both type 2 and type 3 tunnels, as described above, and it requires minimal changes to both RSVP and other parts of the integrated services framework 💅.

2. The Design 🛠️

2.1. Design Goals 🎯

Our design choices are driven by a few goals 💖.

  • Co-existing with most, if not all, current IP-in-IP tunneling schemes.
  • Limiting the changes to the RSVP spec to the minimum possible.
  • Limiting the necessary changes to only the two end points of a tunnel. This requirement leads to simpler deployment, lower overhead in the intermediate routers, and less chance of failure when the set of intermediate routers is modified due to routing changes.
  • Supporting correct inter-operation with RSVP routers that have not been upgraded to handle RSVP over tunnels, and with non-RSVP tunnel endpoint routers. In these cases, the tunnel behaves as a non-RSVP link.

2.2. Basic Approach 🧠

The basic idea is to recursively apply RSVP over the tunnel portion of the path 🔁. In this new session, the tunnel entry point Rentry sends PATH messages, and the tunnel exit point Rexit sends RESV messages, to reserve resources for the end-to-end sessions over the tunnel 🌸.

We'll talk through two different parts of the design next: how to upgrade an IP-in-IP tunnel with RSVP capability, and how to map end-to-end RSVP sessions onto a tunnel session 🧚.

2.2.1. Design Decisions 📝

To set up an RSVP reservation over a unicast IP-in-IP tunnel, we made these design decisions:

One or more Fixed-Filter style unicast reservations between the two end points of the tunnel will be used to reserve resources for packets traversing the tunnel. In the type 2 case, these reservations will be configured statically by a management interface. In the type 3 case, these reservations will be created and torn down on demand, as end-to-end reservation requests come and go ✨.

Packets that don't require reservations get encapsulated in the normal way, e. g. wrapped with an IP header only, with the tunnel entry point as the source and the exit point as the destination 📦.

Data packets that require resource reservations within a tunnel must have some attribute other than the IP addresses visible to the intermediate routers, so the routers can map the packet to an appropriate reservation 🗺️. To let intermediate routers use standard RSVP filterspec handling, we chose to encapsulate these data packets by prepending an IP and a UDP header, and to use UDP port numbers to tell apart packets from different RSVP sessions 🎀. The protocol number in the outer IP header in this case will be UDP 💜.

Figure 1 shows RSVP operating over a tunnel. Rentry is the tunnel entry router, which encapsulates data into the tunnel. Some number of intermediate routers forward the data across the network based on the encapsulating IP header added by Rentry 🌈. Rexit is the endpoint of the tunnel. It decapsulates the data and forwards it based on the original, "inner" IP header 🦋.

  ...........             ...............            .............
            :   _______   :             :   _____    :
            :  |       |  :             :  |     |   :
  Intranet  :--| Rentry|===================|Rexit|___:Intranet
            :  |_______|  :             :  |_____|   :
  ..........:             :   Internet  :            :...........
                          :..............
                       |___________________|

              Figure 1.  An example IP Tunnel

2.2.2. Mapping between End-to-End and Tunnel Sessions ✨

Okay, so Figure 2 is a super simple setup: one tunnel and a few hosts 🌸 The senders are H1 and H3. They can be one IP hop away from Rentry or several hops away, and that's totally fine. The receivers are H2 and H4, and they can also be one or many IP hops away from Rexit 💅

             H1                                          H2
             :                                            :
             :                                            :
         +--------+     +---+     +---+     +---+     +-------+
         |        |     |   |     |   |     |   |     |       |
   H3... | Rentry |===================================| Rexit |.....  H4
         |        |     |   |     |   |     |   |     |       |
         +--------+     +---+     +---+     +---+     +-------+

            Figure 2: An example end-to-end path with
                      a tunnel in the middle.

So there can be an RSVP session between the endpoints at H1 and H2 🦋 We call that one the "end-to-end" (E2E for short) or "original" session, and its PATH and RESV messages are the end-to-end messages. Then there can be one or more RSVP sessions between Rentry and Rexit that reserve resources over the tunnel. We call those the tunnel RSVP sessions, and their PATH and RESV messages are the tunnel or tunneling messages. A tunnel RSVP session can exist all on its own, without any end-to-end session attached. For example, through a network management interface, you could make an RSVP session over the tunnel to give QoS support to the data flow from H3 to H4, even though there's no end-to-end RSVP session between H3 and H4. That's giving independent main character energy 👑

Now, when an end-to-end RSVP session crosses an RSVP-capable tunnel, there are two cases to think about when designing how to support an end-to-end reservation over the tunnel. The first is mapping the E2E session onto an existing tunnel RSVP session, which is the type 2 tunnel. The second is dynamically creating a brand-new tunnel RSVP session for each end-to-end session, which is the type 3 tunnel 🎀 Either way, it basically looks like RSVP being applied recursively. The tunnel RSVP session sees the two tunnel endpoints as two end hosts with a unicast Fixed-Filter style reservation in between. The original, end-to-end RSVP session sees the whole tunnel as one single (logical) link on the path between the source(s) and destination(s). It's so layered 🧚

Also, in practice a tunnel can mix type 2 and type 3 vibes. Some end-to-end RSVP sessions might trigger the creation of new tunnel sessions, while others get mapped into an existing tunnel RSVP session. How an end-to-end session gets treated at the tunnel is a matter of local policy 🍓

When an end-to-end RSVP session crosses an RSVP-capable tunnel, the two RSVP sessions have to coordinate. They need to figure out whether or when the tunnel RSVP session should be created and torn down, and they have to correctly pass error and ADSPEC information between each other. We made the following design decision:

  • End-to-end RSVP control messages being forwarded through a tunnel are encapsulated in the same way as normal IP packets, e.g. being wrapped with the tunnel IP header only, specifying the tunnel entry point as source and the exit point as destination.

2.3. Major Issues 🔥

IP-in-IP tunnels are getting used more and more for network traffic management, so it's clear we have to support type 2 tunnels (tunnel reservations for aggregate end-to-end sessions) 🫶 On top of that, these type 2 tunnels should let more than one reservation be in use at once. The reservations are configurable and static, so different traffic classes can live inside the tunnel. Whether we also need type 3 tunnels (a dynamic, per-end-to-end-session tunnel reservation) is a policy question, so we're leaving that one open. Our design supports both cases 💖

If only one RSVP session is configured over a tunnel, then every end-to-end RSVP session that's allowed to use that tunnel will be bound to that one configured tunnel session. But when more than one RSVP session is in use over an IP tunnel, a second design issue shows up: how the association, or binding, between an original RSVP reservation and a tunnel reservation gets created and passed from one end of the tunnel to the other 😭 Rentry and Rexit have to agree on these associations. That way, changes in the original reservation state can be correctly mapped into changes in the tunnel reservation state. It also means that errors reported by intermediate routers to the tunnel endpoints can be correctly turned into errors reported by the tunnel endpoints back to the end-to-end RSVP session.

We need this same association mechanism to work for both the bundled reservation over a tunnel (type 2 tunnel) and the one-to-one mapping between original and tunnel reservations (type 3 tunnel) ✨ In our scheme, the association gets created when a tunnel entry point first sees an end-to-end session's RESV message. At that moment it either sets up a new tunnel session or adds to an existing one. This new association has to be conveyed to Rexit, so Rexit can reserve resources for the end-to-end sessions inside the tunnel. The information includes the identifier and certain parameters of the tunnel session, plus the identifier of the end-to-end session the tunnel session is being bound to. In our scheme, all RSVP sessions between the same two routers, Rentry and Rexit, have identical values for source IP address, destination IP address, and destination UDP port number. An individual session gets identified mainly by its source port value 🦋

We came up with three possible choices for a binding mechanism:

  1. Define a new RSVP message that is exchanged only between the two tunnel end points to convey the binding information.
  2. Define a new RSVP object to be attached to end-to-end PATH messages at Rentry, associating the end-to-end session with one of the tunnel sessions. Rexit interprets this new object as associating the end-to-end session with one of the tunnel sessions generated at Rentry.
  3. Apply the same UDP encapsulation to the end-to-end PATH messages as to the data packets of the session. When Rexit decapsulates the PATH message, it works out the relation between the source UDP port used in the encapsulation and the RSVP session specified in the original PATH message.

The last approach doesn't need any new design, which is nice 💅 But it needs extra resources reserved for PATH messages, since they're now subject to the tunnel reservation. It also requires knowing ahead of time whether Rexit supports RSVP over tunnels using UDP encapsulation. If Rentry encapsulates all the end-to-end PATH messages with UDP encapsulation, but Rexit doesn't understand that encapsulation, then the encapsulated PATH messages will get lost at Rexit 💀

Options (1) and (2), on the other hand, can handle that case transparently 🌈 They let Rexit pass on end-to-end PATHs received via the tunnel (since they get decapsulated normally), while throwing away the tunnel PATHs. And all of that works without any extra configuration. We chose Option (2) because it's simpler 🧚 We describe this object in the following section.

Packet exchanges have to follow these constraints:

  1. Rentry encapsulates and sends end-to-end PATH messages over the tunnel to Rexit, where they get decapsulated and forwarded downstream.
  2. When a corresponding end-to-end RESV message arrives at Rexit, Rexit encapsulates it and sends it to Rentry.
  3. Based on some or all of the information in the end-to-end PATH messages, the flowspec in the end-to-end RESV message, and local policies, Rentry decides if and how to map the end-to-end session to a tunnel session.
  4. If the end-to-end session should be mapped to a tunnel session, Rentry either sends a PATH message for a new tunnel session or updates an existing one.
  5. Rentry sends an E2E Path containing a SESSION_ASSOC object that associates the end-to-end session with the tunnel session above. Rexit records the association and removes the object before forwarding the Path message further.
  6. Rexit responds to the tunnel PATH message by sending a tunnel RESV message, reserving resources inside the tunnel.
  7. Rentry UDP-encapsulates arriving packets only if a corresponding tunnel session reservation is actually in place for those packets.

2.3.1. SESSION_ASSOC Object 🎀

The new object is called SESSION_ASSOC, and it has the following format:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          length               |  class        |     c-type    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |          SESSION object  (for the end-to-end session)         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |           Sender FILTER-SPEC (for the tunnel session)         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           SESSION_ASSOC Object

Length 📏 This field holds the size of the SESSION_ASSOC object in bytes.

Class 🧁 should be 192.

Ctype 🫧 should be sent as zero and ignored on receipt.

SESSION object 💜 The end-to-end SESSION in the object is the one that gets mapped to the tunnel session described by the Sender FILTER-SPEC below.

Sender FILTER-SPEC 🌸 This is the tunnel session that the end-to-end session above maps to over the tunnel. Like we said earlier, a tunnel session is identified mainly by its source port. That's exactly why we use a Sender Filter-Spec for the tunnel session, in place of a SESSION object 🦋

2.3.2. NODE_CHAR Object 💜

Okay bestie, so here's the thing 🧐. Rexit needs a way to tell Rentry "hey, I'm a tunnel endpoint and I speak this scheme" 📡, and it can't just be configured by hand. So we made a brand-new object called NODE_CHAR to carry that info ✨. If a node gets this object and doesn't understand it, it should just drop it quietly with no error report 🤫. Objects with Class-Num = 10bbbbbb (b is a bit) from the RSVP spec [RFC2205] are exactly the vibe we need 💅. Right now this object only carries one bit of info, but later it can describe other stuff about an RSVP-capable node that isn't in the original RSVP spec 🌈.

The NODE_CHAR object looks like this:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          length               |  class        |     c-type    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Reserved                            |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length 📏 This field holds the size of the NODE_CHAR object in bytes. It should be set to eight 🍓.

Class 🎀 An appropriate value should be assigned by the IANA. We're proposing 128 for this one ✨.

Ctype 🌸 Should be sent as zero and ignored on receipt 🙈.

T bit 🦋 This bit shows that the node is an RSVP-tunnel capable node 👑.

Here's how the magic goes down 🧚. When Rexit gets an end-to-end reservation, it tacks a NODE_CHAR object with the T bit set onto the RESV object, encapsulates everything, and sends it along to Rentry 📨. When Rentry gets this RESV message, it figures out that Rexit uses this mechanism, so it creates or adjusts a tunnel session and links that tunnel session to the end-to-end session with a SESSION_ASSOC object 🔗. Rentry should strip the NODE_CHAR object before it forwards the RESV message upstream 💅. And if Rentry doesn't support RSVP Tunnels at all? It just ignores the NODE_CHAR object and doesn't pass it further upstream 🫶.

3. Implementation ✨

So in this section we're gonna talk through a few cases separately 🗺️, starting with the simplest one and working up to the more complicated ones 📈.

3.1. Single Configured RSVP Session over an IP-in-IP Tunnel 🦋

Okay so if you treat the two tunnel endpoints like a source host and a destination host, setting up a FF-style reservation between them is super easy 💅. The real question is what kind of filterspec to use for the tunnel reservation, because that's what decides how packets get encapsulated over the tunnel 🤔. We're gonna look at two cases.

3.1.1. In the Absence of End-to-End RSVP Session 🌸

If every packet going through a tunnel is using the reserved resources, then the current IP-in-IP encapsulation can totally be used ✨. The RSVP session over the tunnel just specifies a FF style reservation (with zero port number), with Rentry as the source address and Rexit as the destination address 📍.

BUT if only some of the packets going through the tunnel should get the reservation, then we have to wrap the qualified packets in IP and UDP 🎁. This way intermediate routers can use standard RSVP filterspec handling and don't need to know tunnels exist at all 🙈.

We decided not to support both cases, because it's way simpler for implementers if every data packet using a reservation has to get an outer IP and UDP header 💖. Fewer special cases, less headache 🫶.

3.1.2. In the Presence of End-to-End RSVP Session(s) 💜

So the tunnel control policies, set up through some management interface, can decide that some or all end-to-end RSVP sessions are allowed to map onto the single RSVP session over the tunnel 🎀. In this case you don't need any dynamic binding info between end-to-end sessions and the tunnel session, since the tunnel session is unique, pre-configured, and therefore well-known 👑.

Now, mapping multiple end-to-end sessions onto one tunnel session raises a new question: when and how should the size of the tunnel reservation get adjusted to fit all the end-to-end sessions on it? 🤯 Again, that's a call the tunnel manager makes as policy. There are a few options. In the first, the tunnel reservation is never adjusted, so the tunnel is basically like a fixed-capacity hardware link 🔒. In the second, the tunnel reservation gets adjusted every time a new end-to-end reservation shows up or an old one gets torn down 🔄. In the third, the tunnel reservation gets nudged up or down now and then, whenever the end-to-end reservation level has changed enough to be worth it ✨. This one trades extra resource usage in the tunnel for less control traffic and overhead ⚖️.

We call a tunnel whose reservation can't be adjusted a "hard pipe" 🧱, and a "soft pipe" is one where the amount of allocated resources can be adjusted 🌊. Section 5.2 explains how that adjustment can be done for soft pipes 📖.

3.2. Multiple Configured RSVP Sessions over an IP-in-IP Tunnel 🌈

Building on the single configured RSVP session over a tunnel is honestly pretty straightforward 😌. You just set up multiple FF-style reservations between the two tunnel endpoints using a management interface 🎛️. In this case Rentry has to be super careful to encapsulate data packets with the right UDP port numbers, so the intermediate RSVP routers can tell packets from different tunnel sessions apart 🕵️‍♀️. Also, this case and the one before it are what we call type 2 tunnels 🏷️.

3.2.1. In the Absence of End-to-End RSVP Session 🌸

Nothing much more to say here 🤷‍♀️. Rentry classifies the packets and encapsulates them accordingly 📦. Packets with no reservations get an outer IP header only, while packets that qualify for reservations get a UDP header as well as an IP header 🎁. The UDP source port value should be set properly so it maps to the corresponding tunnel reservation the packet is supposed to use 🎯.

3.2.2. In the Presence of End-to-End RSVP Session(s) 💖

Okay, so in this case more than one RSVP session is running over the tunnel, which means you have to explicitly bind each end-to-end RSVP session to its matching tunnel session 🔗. Like we talked about earlier, this binding is provided by the new SESSION_ASSOC object carried in the end-to-end PATH messages 💜.

3.3. Dynamically Created Tunnel RSVP Sessions 🧚

This is the type 3 tunnel case 🦋. The only differences between this case and the one in Section 4.2 are:

  • The tunnel session gets created when a new end-to-end session shows up ✨.
  • There's a one-to-one mapping between the end-to-end and tunnel RSVP sessions 💅, as opposed to the possibly many-to-one mapping that's allowed in the case described in Section 4.2 🌈.

4. RSVP Messages handling over an IP-in-IP Tunnel 🎀

4.1. RSVP Messages for Configured Session(s) Over A Tunnel 🌸

So here, one or more RSVP sessions get set up over a tunnel through a management interface 🎛️. For a "hard pipe" tunnel, the session reservation parameters never change 🧱. For a "soft pipe" tunnel, they can change 🌊. Tunnel session PATH messages that Rentry generates are addressed to Rexit, where they get processed and deleted 🗑️.

4.2. Handling of RSVP Messages at Tunnel Endpoints 💜

4.2.1. Handling End-to-End PATH Messages at Rentry 👑

So when a router acting as the tunnel entry point, Rentry, forwards an end-to-end PATH message, it does different things depending on which end-to-end session the message is for 🧠. There are two possible cases:

  1. The end-to-end PATH message is a refresh of a previously known end-to-end session 🔁.
  2. The end-to-end PATH message is from a new end-to-end session 🆕.

If the PATH message is a refresh of a session Rentry already knows about, then Rentry refreshes the Path state for that end-to-end session and checks whether it's mapped to a tunnel session 🔍. If it is, then when Rentry refreshes the end-to-end session, it adds a SESSION_ASSOC object to the end-to-end PATH message that links the session to its corresponding tunnel session 🔗. Then it encapsulates the end-to-end PATH message and sends it over the tunnel to Rexit 🚀. If the tunnel session was dynamically created, the end-to-end PATH message doubles as a refresh for the local tunnel state at Rentry and for the end-to-end session 💖.

Otherwise, if the PATH message is from a new end-to-end session that hasn't been mapped to a tunnel session yet, Rentry creates Path state for this new session and sets the outgoing interface to the tunnel interface 🛤️. After that, Rentry encapsulates the PATH message and sends it to Rexit without adding a SESSION_ASSOC message 🙅‍♀️.

When Rentry receives an end-to-end PATH TEAR, it encapsulates the message and forwards it to Rexit 📤. If this end-to-end session has a one-to-one mapping to a tunnel session, or if it's the last one of many end-to-end sessions mapping to a tunnel session, Rentry tears down the tunnel session by sending a PATH TEAR for that session to Rexit 💥. But if there are still other end-to-end sessions mapping to the tunnel session, Rentry sends a tunnel PATH message that adjusts the Tspec of the tunnel session 🎚️. Iconic behaviour, honestly 👏.

4.2.2. Handling End-to-End PATH Messages at Rexit ✨

okay so the encapsulated end-to-end PATH messages get unwrapped and processed at Rexit 🎀 what Rexit does next depends on whether the end-to-end PATH message has a SESSION_ASSOC object in it or not 💅

  1. bestie, if the end-to-end PATH message doesn't have a SESSION_ASSOC object, Rentry sets the Non_RSVP flag on the Path state it has stored for this end-to-end sender, sets the global break bit in the ADSPEC, and forwards the packets downstream 🦋 BUT, if tunnel sessions exist and none of them has the Non_RSVP flag set, Rexit can grab the worst-case Path ADSPEC params from those existing tunnel sessions and use them to update the end-to-end ADSPEC 🧚 this is a conservative estimate of the composed ADSPEC, and the perk is that it avoids setting the break bit in the end-to-end ADSPEC before the mapping info is available 🙈 in this case the Non_RSVP flag on the end-to-end Path state is not set. ngl this is such a clever little move 😭
  2. if the PATH message has a SESSION_ASSOC object and there's no association for this end-to-end session yet, Rexit records the association between the end-to-end session and the tunnel session that the object describes 🌸 if the end-to-end PATH shows up early, before the tunnel PATH message does, it creates PATH state at Rexit for the tunnel session. then when the real tunnel PATH message arrives, it gets treated as an update to that existing PATH state, and it fills in whatever info was missing 💜 we believe this is just another transient, like the others that already exist in RSVP, and it doesn't have any long-term effects on how this mechanism works correctly 🫶

before passing the message along to the next hop toward the destination, Rexit finds the matching tunnel session's recorded state, and if the Non_RSVP bit was turned on for that tunnel session, it turns on the Non_RSVP flag in the end-to-end Path state too 🔥 if the end-to-end PATH message carries an ADSPEC object, Rexit composes the characterization parameters inside it. it does this by treating the tunnel session's overall (composed) characterization parameters as the local parameters for the logical link that the tunnel implements, and then composing those with the parameters in the end-to-end ADSPEC by running each parameter's defined composition function 👑 in the logical link's characterization parameters, the minimum path latency may account for the encapsulation/decapsulation delay, and the bandwidth estimate can reflect the drop in available bandwidth caused by the extra UDP header 🍓 ADSPECs and composition functions get the full deep dive in [RFC2210], so go check that out if you're curious 🌈

if the end-to-end session has reservation state, but the matching tunnel session has no reservation state, Rexit sends a tunnel RESV message to Rentry that matches the reservation in the end-to-end session 🌷

if Rentry doesn't support RSVP tunneling, then Rexit won't have any PATH state for the tunnel. in that case Rexit just turns on the global break bit in the decapsulated end-to-end PATH message and forwards it 💀

4.2.3. Handling End-to-End RESV Messages at Rexit 🦋

so when a router acting as the exit router, Rexit, is forwarding a RESV message upstream, it might notice that one of the upstream interfaces is a tunnel 👀 when that happens, the router runs a few tests 💅

Step 1: Rexit has to figure out whether there's a tunnel session bound to the end-to-end session named in the RESV message. if there isn't, the tunnel gets treated as a non-RSVP link. Rexit appends a NODE_CHAR object with the T bit set to the RESV message and forwards it over the tunnel interface, where it gets encapsulated as a normal IP datagram and sent on toward Rentry 🌸

Step 2: if a bound tunnel session is found, Rexit checks whether a reservation is already in place for the tunnel session bound to that end-to-end session. if the arriving end-to-end RESV message is a refresh of existing RESV state, Rexit sends the original RESV through the tunnel interface (after adding the NODE_CHAR object) 💖 for dynamic tunnel sessions, the end-to-end RESV message acts as a refresh for the tunnel session's reservation state, while for configured tunnel sessions, reservation state never expires 🧚

if the arriving end-to-end RESV message changes the flowspec parameters of the end-to-end RESV, it might also kick off an attempt to change the tunnel session's flowspec parameters. in that case Rexit sends a tunnel session RESV, and it includes a RESV_CONFIRM object 🎀

with a "hard pipe" tunnel, a new end-to-end reservation, or a change in how many resources an existing reservation asks for, could push the total resources needed by the end-to-end reservations past what the tunnel reservation has set aside 😭 that's treated as an admission control failure, exactly the same as when RSVP requests go over what a hardware link has available 🔥 a RESV_ERR message with Error Code set to 01 (Admission Control failure) should be sent back to whoever originated the end-to-end RESV message.

if a RESV CONFIRM response shows up, the original RESV gets encapsulated and sent through the tunnel. if the updated tunnel reservation fails, Rexit has to send a RESV ERR to the originator of the end-to-end RESV message, using the error code and value fields from the ERROR_SPEC object in the received tunnel session RESV ERR message 🥺 the pre-existing reservations through the tunnel stay right where they are, and Rexit keeps refreshing the tunnel RESV using the old flowspec 🫶

for a "soft pipe", the tunnel session state can also get adjusted when an end-to-end reservation is deleted 🍓 the tunnel session shrinks whenever one of the end-to-end sessions using it goes away (or shrinks itself). but even when the very last end-to-end session bound to that tunnel is gone, the configured tunnel session stays active, maybe with a configured minimal flowspec 💜

it's often a good idea to add some hysteresis when adjusting the tunnel reservation parameters, instead of bouncing the tunnel reservation up and down with every end-to-end reservation that arrives or leaves 🙈 doing that means the tunnel exit router has to keep track of the resources allocated to the tunnel (the tunnel flowspec) and the resources actually being used by end-to-end reservations (the sum, or statistical sum, of the end-to-end reservation flowspecs) separately.

when Rexit receives an end-to-end RESV TEAR, it encapsulates the message and forwards it to Rentry 🦋 if the end-to-end session had created a dynamic tunnel session, Rexit also sends a RESV TEAR for the matching tunnel session 🌈

4.2.4. Handling of End-to-End RESV Messages at Rentry. 🧚

if the RESV message is a refresh of an existing reservation, Rentry updates the reservation state and forwards the message upstream ✨ but if this is the first RESV message for this end-to-end session and a NODE_CHAR object with the T bit set is present, Rentry should start the mapping between this end-to-end session and some (possibly new) tunnel session 👑 that mapping is based on some or all of the contents of the end-to-end PATH message, the contents of the end-to-end RESV message, and local policies. for example, there could be different tunnel sessions for different bandwidth or delay requirements of end-to-end sessions 💅

if Rentry decides this end-to-end session should map to an existing configured tunnel session, it binds the end-to-end session to that tunnel session 🎀

if this end-to-end RSVP session is allowed to set up a new tunnel session, Rentry sets up tunnel session PATH state as if it were a source of data, by starting to send tunnel-session PATH messages to Rexit, which is treated as the unicast destination of the data 🌸 the Tspec in this new PATH message is computed from the original PATH message by adjusting the Tspec parameters to include the tunnel overhead of encapsulating the data packets. in this case Rentry should also send a PATH message from the end-to-end session, this time containing the SESSION_ASSOC object that links the two sessions 🫶 when Rexit receives that PATH message, it triggers an update of the end-to-end Path state, which in turn has the effect of Rexit sending a tunnel RESV message to allocate resources inside the tunnel 💖

the last case is when the end-to-end session isn't allowed to use the tunnel resources. then no association gets created between the end-to-end session and a tunnel session, and no new tunnel session gets made 🥀

one limitation of our scheme: the first RESV message of an end-to-end session decides the mapping between that end-to-end session and its corresponding session over the tunnel 😭 and as long as the reservation is active, that mapping can't change 🔒

5. Forwarding Data 🌊

when data packets arrive at the tunnel entry point, Rentry, Rentry must decide whether to forward them using the normal IP-in-IP tunnel encapsulation or the IP+UDP encapsulation that the tunnel session expects 🦋 that decision comes down to whether there's a resource reservation (not just PATH state) actually in place for the tunnel session bound to the arriving packet. in other words, does the packet match any active filterspec? 🔍

if a reservation is in place, that means both Rentry and Rexit are RSVP-tunneling aware routers, and the data will get decapsulated correctly at Rexit 👑

if no tunnel session reservation is in place, the data should be encapsulated in the tunnel's normal format, whether or not end-to-end PATH state covering the data is present 🧚

6. Details 🎀

6.1. Selecting UDP port numbers 🌷

there can be multiple end-to-end RSVP sessions between the same two end points, Rentry and Rexit 💖 these sessions are told apart by their source UDP port. the other parts of the session ID (the source and destination IP addresses and the destination UDP port) are identical for all of them ✨

the source UDP port is picked by the tunnel entry point, Rentry, when it sets up the initial PATH state for a new tunnel session 🫶 the source UDP port for the new session is then passed along to Rexit in the SESSION_ASSOC object 🍓

the destination UDP port used in tunnel sessions should be the one assigned by IANA (363). 🌈

6.2. Error Reporting 🚨

when a tunnel session PATH message runs into an error, the error gets reported back to Rentry 💅 Rentry must relay the error report back to the original source of the end-to-end session 💜

when a tunnel session RESV request fails, an error message comes back to Rexit 🥺 Rexit must treat this as an error in crossing the logical link (the tunnel) and forward the error message back to the end host 🔥

6.3. MTU Discovery 📏

since UDP encapsulated packets shouldn't be fragmented, tunnel entry routers must support tunnel MTU discovery, as discussed in section 5.1 of [IP4INIP4] 🫧 the alternative is the Path MTU Discovery mechanism discussed in RFC 2210 [RFC2210], which can be used instead 🌸

6.4. Tspec and Flowspec Calculations 🎀

okay bestie, so when a bunch of End-to-End sessions get squished into ONE tunnel session, somebody has to add up all the senders' Tspecs ✨ That total becomes the Tspec of the representative tunnel session 💖 Same energy for the flowspecs of End-to-End reservations showing up at Rexit 🦋

The semantics of these operations aren't addressed here 🤷‍♀️ The simplest way is to just sum the end-to-end Tspecs, as defined in the Controlled-Load and Guaranteed services specs (found at [RFC2211] and [RFC2212] respectively) 💅 But it might also be appropriate to compute the aggregate reservation level for the tunnel with something fancier, like a statistical or measurement-based computation 🧠 ngl that's big brain energy

7. IPSEC Tunnels 🔐

okay so if the IP-in-IP tunnel supports IPSEC (especially ESP in Tunnel-Mode, with or without AH) 🌸 then the Tunnel Session uses the GPI SESSION and GPI SENDER_TEMPLATE/FILTER_SPEC as defined in [RSVPESP] for the PATH and RESV messages 💜

Data packets are NOT encapsulated with a UDP header, because the SPI can be used by the intermediate nodes for classification purposes 👀 Notice that user oriented keying must be used between Rentry and Rexit, so that different SPIs get assigned to data packets with a reservation vs. "best effort" packets 🍓 and also to packets that belong to different Tunnel Sessions, if those are supported ✨

8. RSVP Support for Multicast and Multipoint Tunnels 🦋

The mechanisms above are super useful for unicast tunnels 🌈 Unicast tunnels give you logical point-to-point links in the IP infrastructure, though they can encapsulate and carry either unicast or multicast traffic between those points 💖

There are two other types of tunnels you could imagine 🧚 The first is a "multicast" tunnel. In this type, packets arriving at an entry point get encapsulated and transported (multicast) to all of the exit points 📡 This could be handy for building a hierarchical multicast distribution network, or for efficiently emulating some portion of a native multicast distribution tree 🌳

The second possible type is the "multipoint" tunnel. In this type, packets arriving at an entry point are normally encapsulated and transported to one of the exit points, based on some route selection algorithm 🎯

This type is different from all the previous ones, because the "shape" of the usual data distribution path doesn't match the "shape" of the tunnel 😳 The tunnel's topology doesn't by itself define the data transmission function it performs. Instead, the tunnel becomes a way to express some shared property of the set of connected tunnel endpoints 🫶 For example, the "tunnel" can be used to create and embed a logical shared broadcast network inside a larger network 📶 In that case, the tunnel endpoints are the nodes connected to that logical shared broadcast network. Data traffic can be unicast between two such nodes, broadcast to all connected nodes, or multicast between some subset of them 🔥 The tunnel itself is used to define a domain in which to manage routing and resource management, which is essentially a virtual private network 👑

Note that while a VPN like this can always be built using a multicast tunnel to emulate the broadcast medium, that approach will be very inefficient for wide area VPNs 🙈 A multipoint tunnel with appropriate control mechanisms will be preferable ✨

The following paragraphs give some brief commentary on using RSVP in these situations 💅 Future versions of this note will provide more concrete details and specifications 🔮

Using RSVP to provide resource management over a multicast tunnel is relatively straightforward 🥰 As in the unicast case, one or more RSVP sessions may be used, and end-to-end RSVP sessions may be mapped onto tunnel RSVP sessions on a many-to-one or one-to-one basis. Unlike the unicast case, though, the mapping gets complicated by RSVP's heterogeneity semantics 🌀 If different receivers have made different reservation requests, the RESV messages arriving at the tunnel might logically map the receivers' requests to different tunnel sessions. Since the data can actually be placed into only one session, the choice of session has to be reconciled (merged) to select the one that will meet the needs of all applications 🤝 This requires a relatively simple extension to the session mapping mechanism 💖

Using RSVP to support multipoint tunnels is somewhat harder 😭 In this case, the goal is to give the tunnel as a whole a specific level of resources. For example, we might want to emulate a "logical shared 10 megabit Ethernet" rather than a "logical shared Ethernet" 🧃 The problem is that in this type of tunnel, the data doesn't always go to all tunnel endpoints. That means we cannot use the destination address of the encapsulated packets as part of the packet classification filter, because the destination address will vary for different packets within the tunnel 🙃

This calls for an extension to current RSVP session semantics, where the Session ID (destination IP address) is used only to identify the session state within network nodes, but is not used to classify packets 🧩 Other than that, using RSVP for multipoint tunnels follows the same pattern as multicast tunnels. A multicast group is created to represent the set of nodes that are tunnel endpoints, and one or more tunnel RSVP sessions are created to reserve resources for the encapsulated packets 🎀 For a tunnel implementing a simple VPN, it's most likely there will be one session reserving resources for the whole VPN. Each tunnel endpoint will participate both as a source of PATH messages and as a source of (FF or SE) RESV messages for this single session, effectively creating a single shared reservation for the entire logical shared medium 🫧

Tunnel endpoints MUST NOT make wildcard reservations over multipoint tunnels. 🚫

9. Extensions to the RSVP/Routing Interface 🧭

The RSVP specification [RFC2205] says that through the RSVP/Routing Interface, the RSVP daemon must be able to learn the list of local interfaces along with their IP addresses 📋 In the RSVP Tunnels case, the RSVP daemon also needs to learn which of the local interface(s) is (are) IP-in-IP tunnel(s) having the capabilities described here 🕵️‍♀️ The RSVP daemon can get this info either by directly querying the underlying network and physical layers, or by using any existing interface between RSVP and the routing protocol, properly extended to provide this information 💅

10. Security Considerations 🔒💀

Okay bestie, listen closely 🫢 The introduction of RSVP Tunnels raises no new security issues beyond those already associated with RSVP and tunnels. For RSVP, the major issue is the need to control and authenticate access to enhanced qualities of service 🚨 This requirement is discussed further in [RFC2205]. [RSVPCRYPTO] describes the mechanism used to protect the integrity of RSVP messages carrying the information described here 🛡️ The security issues associated with IP-in-IP tunnels are discussed in [IPINIP4] and [IPV6GEN] 😤 Please go read those, no cap 🙏

11. IANA Considerations 📚

IANA should assign a Class number for the NODE_CHAR object defined in Section 3.3.2 🔢 This number should be in the 10bbbbbb range, and the suggested value is 128 💜

12. Acknowledgments 🫶

We thank Bob Braden for his insightful comments that helped us produce this updated version of the document 🙌 Iconic of him, honestly ✨

13. References 📖

  • [ESP] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995. 🔐
  • [IP4INIP4] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. 🎁
  • [IPV6GEN] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. 🌐
  • [MINENC] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. 🪶
  • [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. 🧵
  • [RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation over IPv4 Networks", RFC 1702, October 1994. 🧶
  • [RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. 🦋
  • [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. ⭐
  • [RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. 🌸
  • [RFC2212] Shenker, S., Partridge, C. and R. Guerin, "Specification of the Guaranteed Quality of Service", RFC 2212, September 1997. 🌸
  • [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. 🏗️
  • [RSVPESP] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. 🔗
  • [RSVPCRYPTO] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. 🗝️

14. Authors' Addresses 💌

John Krawczyk ArrowPoint Communications 50 Nagog Park Acton, MA 01720

Phone: 978-206-3027 EMail: jj@arrowpoint.com

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

Phone: 617-253-7885 Fax: 617-253-2673 EMail: jtw@lcs.mit.edu

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

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

Andreas Terzis UCLA 4677 Boelter Hall Los Angeles, CA 90095

Phone: 310-267-2190 EMail: terzis@cs.ucla.edu

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

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

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

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

Acknowledgement 💖

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

📦 where this page comes from