RFC 5979
NSIS Operation over IP Tunnels
RFC 5979: NSIS Operation over IP Tunnels 🎀
okay bestie, this one is about making QoS work inside IP tunnels 🦋 It's an Experimental RFC from the IETF (Internet Engineering Task Force), and the title block is giving credentials ✨
- Request for Comments: 5979 💅
- Category: Experimental 🧪
- ISSN: 2070-1721
- Authors: C. Shen and H. Schulzrinne from Columbia U., S. Lee from Samsung, and J. Bang from Samsung AIT 🫶
- Date: March 2011 🌸
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈
Abstract
NSIS QoS (Quality of Service) signaling lets applications reserve QoS along a data flow path 🔥 But when that path goes through an IP tunnel segment, NSIS QoS signaling just doesn't do anything inside that tunnel 💀 So that tunnel can turn into the weakest QoS link and mess up all the QoS work done on the rest of the end-to-end path. Not ideal, not me!
The reason is the tunnel encapsulation. It hides the packet's original IP header fields, and those fields are what's needed to catch NSIS signaling messages and classify QoS data packets. This document fixes it by mapping end-to-end QoS session requests onto matching QoS sessions in the tunnel, which extends end-to-end QoS signaling into the IP tunnel segments 🦋✨
Status of This Memo
okay this part is the legal-ish bit but it's still important 🧚 This document is not an Internet Standards Track spec. It's published for examination, experimental implementation, and evaluation 🌈
It defines an Experimental Protocol for the Internet community 💜 It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 💅
If you want the current status, any errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc5979 🍓
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as in effect on the publication date 📜 Please read these carefully, because they describe your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭 Unless you get a proper license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be made outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 6
3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 7
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10
4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11
4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 13
5. NSIS Operation over Tunnels with Preconfigured QoS Sessions . 14
5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 14
5.2. Receiver-Initiated Reservation . . . . . . . . . . . . . . 15
6. NSIS Operation over Tunnels with Dynamically Created QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Sender-Initiated Reservation . . . . . . . . . . . . . . . 17
6.2. Receiver-Initiated Reservation . . . . . . . . . . . . . . 19
7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 251. Introduction ✨
okay so IP tunneling [RFC1853] [RFC2003] is when you wrap a packet up and carry it as the payload of another IP packet 🎁 The wrapped packet is the original packet, and the whole wrapped thing is the IP tunnel packet. People use tunneling for explicit forwarding path control (like in Mobile IP [RFC5944]), for secure IP data delivery (like in IPsec [RFC4301]), and to help routing between networks of different kinds (like between IPv6 and IPv4 networks [RFC4213]). Section 3.1 has a list of common IP tunneling protocols, so go peek there 👑
This document is about the case where the packet being tunneled is an NSIS [RFC4080] packet. NSIS is an IP signaling architecture made of two parts: the GIST [RFC5971] sub-layer, which handles signaling transport, and the NSIS Signaling Layer Protocol (NSLP) sub-layer, which can be customized for different applications 💖 The one we focus on is the QoS NSLP [RFC5974], which adds features on top of the older RSVP [RFC2205] signaling. In this document, "NSIS" and "NSIS QoS" mean the same thing 🦋
Here's the tea 🫠 Without extra work, NSIS signaling just doesn't work inside IP tunnel segments of a signaling path. The tunnel encapsulation hides the original packet, header and payload both. But info from the original packet is needed for two things: finding NSIS peer nodes and classifying QoS data flow packets. Without that info, the IP tunnel acts like an NSIS-unaware virtual link inside the end-to-end NSIS signaling path 😭
This document defines a mechanism that extends end-to-end NSIS signaling for QoS reservation into IP tunnels 💜 The NSIS-aware tunnel endpoints that support this mechanism are called NSIS-tunnel-aware endpoints. There are two main operation modes:
- If the tunnel already has preconfigured QoS sessions, the NSIS-tunnel-aware endpoints map end-to-end QoS signaling requests directly onto the existing tunnel sessions, as long as there are enough tunnel session resources 🎀
- If there are no preconfigured tunnel QoS sessions, the NSIS-tunnel-aware endpoints dynamically initiate and maintain tunnel QoS sessions, and associate them with the matching end-to-end QoS sessions 🌈
Whether a tunnel preconfigures QoS sessions at all, and which preconfigured tunnel QoS sessions a given end-to-end QoS signaling request should map to, are policy issues. Those are out of scope for this document 🙈
Here's the map of the rest of the doc 🗺️ Section 2 defines terminology. Section 3 is the problem statement, covering common IP tunneling protocols and how NSIS QoS signaling currently behaves over IP tunnels. Section 4 introduces the design requirements and the overall approach. Sections 5 and 6 go into more detail on how NSIS QoS signaling works with preconfigured QoS and dynamic QoS signaling tunnels. Section 7 describes a way to automatically discover whether a tunnel endpoint node supports the NSIS-tunnel interoperation mechanism from this document. Section 8 covers IANA considerations, and Section 9 is all about security 🧚
2. Terminology 🌸
this doc uses terms defined in [RFC2473], [RFC5971], and [RFC5974] 📚 On top of those, these terms show up too:
- IP Tunnel: A tunnel configured as a virtual link between two IP nodes, where the encapsulating protocol is IP 🦋
- Tunnel IP Header: The IP header that gets prepended to the original packet during encapsulation. It names the tunnel endpoints as the source and destination 💖
- Tunnel-Specific Header: The header fields the encapsulation mechanism inserts after the tunnel IP header and before the original packet. These may or may not exist depending on which tunnel mechanism you're using. An example is the Encapsulation Security Payload (ESP) header for IPsec [RFC4301] tunneling mode 🎀
- Tunnel Intermediate Node (Tmid): A node sitting in the middle of the forwarding path between the tunnel entry-point node and the tunnel exit-point node 🛣️
- Flow Identifier (Flow ID): The set of header fields used to identify a data flow. For example, it can include the flow sender and receiver addresses, plus protocol and port numbers 🔥
- End-to-End QoS Signaling: The signaling process that manipulates QoS control information along the end-to-end path, from the flow sender to the flow receiver. When the end-to-end flow path has tunnel segments, this document uses "end-to-end QoS signaling" to mean the QoS signaling outside the tunnel segments. It uses "end-to-end QoS signaling" and "end-to-end signaling" interchangeably 💅
- Tunnel QoS Signaling: The signaling process that manipulates QoS control information on the path inside a tunnel, between the tunnel entry-point and tunnel exit-point nodes. This document uses "tunnel QoS signaling" and "tunnel signaling" interchangeably 🫶
- NSIS-Aware Node: A node that supports NSIS signaling 🌈
- NSIS-Aware Tunnel Endpoint Node: A tunnel endpoint node that is also an NSIS node 🍓
- NSIS-Tunnel-Aware Endpoint Node: An NSIS-aware tunnel endpoint node that also supports the mechanism for NSIS operating over IP tunnels defined in this document ✨
3. Problem Statement 🧚
the problem statement is up next, bestie, and it's where we get into the nitty-gritty of why tunnels break NSIS QoS 🔥 Stay tuned for part 2 💜
3.1. IP Tunneling Protocols 🦋
Okay bestie, tunneling is literally my favourite thing ✨ Picture this:
Tunnel from node B to node D
<---------------------->
Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point
Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Original Original
Packet Packet
Source Destination
Node Node
Figure 1: IP TunnelThe following description about IP tunneling is derived from [RFC2473] and adapted for both IPv4 and IPv6 🌸
IP tunneling (Figure 1) is a technique for establishing a "virtual link" between two IP nodes for transmitting data packets as payloads of IP packets. From the point of view of the two nodes, this "virtual link", called an IP tunnel, appears as a point-to-point link on which IP acts like a link-layer protocol. The two IP nodes play specific roles 💅 One node encapsulates original packets received from other nodes or from itself and forwards the resulting tunnel packets through the tunnel. The other node decapsulates the received tunnel packets and forwards the resulting original packets towards their destinations, possibly itself. The encapsulating node is called the tunnel entry-point node (Tentry), and it is the source of the tunnel packets. The decapsulating node is called the tunnel exit-point node (Texit), and it is the destination of the tunnel packets.
An IP tunnel is a unidirectional mechanism. The tunnel packet flow takes place in one direction between the IP tunnel entry-point and exit-point nodes 🎀 Bidirectional tunneling is achieved by combining two unidirectional mechanisms, that is, configuring two tunnels, each in opposite direction to the other. The entry-point node of one tunnel is the exit-point node of the other tunnel. Two tunnels, one each way, equals two-way vibes 🫶
Figure 2 illustrates the original packet and the resulting tunnel packet. In a tunnel packet, the original packet is encapsulated within the tunnel header. The tunnel header contains two components, the tunnel IP header and other tunnel-specific headers. The tunnel IP header specifies the tunnel entry-point node as the IP source address and the tunnel exit-point node as the IP destination address, causing the tunnel packet to be forwarded in the tunnel. The tunnel-specific header between the tunnel IP header and the original packet is optional, depending on the tunneling protocol in use 🧚
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Header | |
+----------------------------------//-----+
< Original Packet >
|
v
< Tunnel Headers > < Original Packet >
+---------+-----------+-------------------------//--------------+
| Tunnel | Tunnel- | |
| IP | Specific | Original Packet |
| Header | Header | |
+---------+-----------+-------------------------//--------------+
< Tunnel IP Packet >
Figure 2: IP Tunnel EncapsulationCommonly used IP tunneling protocols include Generic Routing Encapsulation (GRE) [RFC1701][RFC2784], Generic Routing Encapsulation over IPv4 Networks (GREIPv4) [RFC1702] and IP Encapsulation within IP (IPv4INIPv4) [RFC1853][RFC2003], Minimal Encapsulation within IP (MINENC) [RFC2004], IPv6 over IPv4 Tunneling (IPv6INIPv4) [RFC4213], Generic Packet Tunneling in IPv6 Specification (IPv6GEN) [RFC2473] and IPsec tunneling mode [RFC4301] [RFC4303]. So many protocols, so many choices 😭 Among these tunneling protocols, the tunnel headers in IPv4INIPv4, IPv6INIPv4, and IPv6GEN contain only a tunnel IP header, and no tunnel-specific header. All the other tunneling protocols have a tunnel header consisting of both a tunnel IP header and a tunnel-specific header. The tunnel-specific header is the GRE header for GRE and GREIPv4, the minimum encapsulation header for MINENC, and the ESP header for IPsec tunneling mode. As will be discussed in Section 4.3, some of the tunnel-specific headers may be used to identify a flow in the tunnel and facilitate NSIS operating over IP tunnels 👑
3.2. NSIS QoS Signaling in the Presence of IP Tunnels ⭐
Typically, applications use NSIS QoS signaling to reserve resources for a flow along the flow path. NSIS QoS signaling can be initiated by either the flow sender or flow receiver. Figure 3 shows an example scenario with five NSIS nodes, including flow sender node A, flow receiver node E, and intermediate NSIS nodes B, C, and D. Nodes that are not NSIS QoS capable are not shown 🌈
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|----->----|C|---//-->---|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Flow Flow
Sender Receiver
Node Node
Figure 3: Example Scenario of NSIS QoS SignalingFigure 4 illustrates a sender-initiated signaling sequence in the scenario of Figure 3. Sender node A sends a RESERVE message towards receiver node E. The RESERVE message gets forwarded by intermediate NSIS Nodes B, C, and D and finally reaches receiver node E. Receiver node E then sends back a RESPONSE message confirming the QoS reservation, again through the previous intermediate NSIS nodes in the flow path 🦋
There are two important aspects in the above signaling process that are worth mentioning. First, the flow sender does not initially know exactly which intermediate nodes are NSIS-aware and should be involved in the signaling process for a flow from node A to node E. Discovery of those nodes (namely, nodes B, C, and D) is accomplished by a separate NSIS peer discovery process (not shown above; see [RFC5971]). The NSIS peer discovery messages contain special IP header and payload formats or include a Router Alert Option (RAO) [RFC2113] [RFC2711]. The special formats of NSIS discovery messages allow nodes B, C, and D to intercept the messages and subsequently insert themselves into the signaling path for the flow in question. After formation of the signaling path, all signaling messages corresponding to this flow will be passed to these nodes for processing. Other nodes that are not NSIS-aware simply forward all signaling messages, as they would any other IP packets that do not require additional handling 💖
Node A Node B Node C Node D Node E
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | | |
| +------------->| | |
| | | RESERVE | |
| | +------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | | RESPONSE | |
| | |<-------------+ |
| | RESPONSE | | |
| |<-------------+ | |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
Figure 4: Sender-Initiated NSIS QoS SignalingSecond, the goal of QoS signaling is to install control information to give QoS treatment for the flow being signaled. Basic QoS control information includes the data Flow ID for packet classification and the type of QoS treatment those packets are entitled to. The Flow ID contains a set of header fields such as flow sender and receiver addresses, and protocol and port numbers 🍓
Now consider Figure 5 where nodes B, C, and D are endpoints and intermediate nodes of an IP tunnel. During the signaling path discovery process, node B can still intercept and process NSIS peer discovery messages if it recognizes them before performing tunnel encapsulation. Node D can identify NSIS peer discovery messages after performing tunnel decapsulation. A tunnel intermediate node such as node C, however, only sees the tunnel header of the packets and will not be able to identify the original NSIS peer discovery message or insert itself in the flow signaling path. Furthermore, the Flow ID of the original flow is based on IP header fields of the original packet. Those fields are also hidden in the payload of the tunnel packet. So, there is no way node C can classify packets belonging to that flow in the tunnel 🙈
Tunnel from node B to node D
<---------------------->
Tunnel Tunnel Tunnel
Entry-Point Intermediate Exit-Point
NSIS QoS NSIS QoS NSIS QoS NSIS QoS NSIS QoS
Node Node Node Node Node
+-+ +-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>====|C|===//==>===|D|-->--//-->--|E|
+-+ +-+ +-+ +-+ +-+
Flow Flow
Sender Receiver
Node Node
Figure 5: Example Scenario of NSIS QoS Signaling with IP TunnelIn summary, an IP tunnel segment normally appears like a QoS-unaware virtual link. Since the best QoS of an end-to-end path is judged based on its weakest segment, we need a mechanism to extend NSIS into the IP tunnel segments, which should allow the tunnel intermediate nodes to intercept original NSIS signaling messages and classify original data flow packets in the presence of tunnel encapsulation 🔥
4. Design Overview ✨
4.1. Design Requirements 💅
okay so before we get into the nitty gritty, here's the wishlist for NSIS over IP tunnels 🎀
- The mechanism should work with all the common IP tunneling protocols listed in Section 3.1 🦋
- Some tunnels keep preconfigured QoS sessions inside them, and some don't 🧚 The mechanism should work for tunnels both with and without preconfigured tunnel QoS sessions, no exceptions 💖
- The mechanism should minimize the upgrade needed on existing infrastructure so it's actually deployable 🌸 Specifically, the upgrade should be limited to the tunnel endpoints. Nobody wants to replace the whole network just to get this working 😭
- The mechanism should provide a way for one NSIS-tunnel-aware endpoint to discover whether the other endpoint is also NSIS-tunnel-aware, when that's necessary 🫶
- The mechanism should learn from the design experience of earlier work on RSVP over IP tunnels (RSVP-TUNNEL) [RFC2746] 📚 but it also has to deal with the big differences between NSIS and RSVP, which are kind of the main character energy of this whole section ✨
Those differences are:
First, NSIS is designed as a generic framework that can handle lots of different signaling application needs, so it's split into a signaling transport layer and a signaling application layer 🍓 RSVP has no layer split and is only designed for QoS signaling. Second, the NSIS QoS NSLP allows both sender-initiated and receiver-initiated reservations, while RSVP only supports receiver-initiated reservations 🔥 Third, NSIS only deals with unicast, whereas RSVP also supports multicast 🌈 Fourth, NSIS has a brand new SESSION-ID feature, which is different from the session identification concept in RSVP 👑
4.2. Overall Design Approach 🦋
okay the overall design of this NSIS signaling and IP tunnel interworking mechanism borrows similar concepts from RSVP-TUNNEL [RFC2746], but it's been tailored and extended specifically for NSIS operation 💜
Since we only consider unidirectional flows, the tunnel entry-point and the tunnel exit-point both have to be NSIS-tunnel-aware so that flows can go in both directions of a tunnel 🙈 An NSIS-tunnel-aware endpoint finds out whether the other tunnel endpoint is NSIS-tunnel-aware either through preconfiguration or through an NSIS-tunnel capability discovery mechanism defined in Section 7 ✨
Tunnel endpoints need to always intercept NSIS peer discovery messages and insert themselves into the NSIS signaling path. That way they can receive all NSIS signaling messages and coordinate their interaction with tunnel QoS 🎀
To make QoS handling work inside the tunnel, an end-to-end QoS session gets mapped to a tunnel QoS session. That tunnel session is either preconfigured or dynamically created 🧚 The tunnel session uses a tunnel Flow ID based on information that's available in the tunnel headers, which lets tunnel intermediate nodes classify flow packets correctly 💅
For tunnels that maintain preconfigured QoS sessions, when the tunnel endpoint gets a request to reserve resources for an end-to-end session, it maps that end-to-end QoS session to an existing tunnel session 🌸 To keep the design simple, the mapping decision is always made by the tunnel entry-point, no matter whether the end-to-end session uses sender-initiated or receiver-initiated NSIS signaling mode 💖 Which end-to-end session can be mapped to which preconfigured tunnel session depends on policy mechanisms that are outside the scope of this document 🙃
For tunnels that don't maintain preconfigured QoS sessions, the NSIS-tunnel-aware endpoints dynamically create and manage a corresponding tunnel QoS session for the end-to-end session 🛠️ Both QoS sessions can be sender-initiated or receiver-initiated, but to keep things simple, the initiation mode of the tunnel QoS session follows the initiation mode of the end-to-end QoS session 🫶 So the end-to-end QoS session and its corresponding tunnel QoS session are either both sender-initiated or both receiver-initiated. To keep this consistent with the preconfigured case, the tunnel entry-point always initiates the mapping between the tunnel session and the end-to-end session 🔥
As the mapping initiator, the tunnel entry-point records the association between the end-to-end session and its corresponding tunnel session. This happens in tunnels with and without preconfigured QoS sessions alike 🍓 This association does double duty, serving both the signaling plane and the data plane 👑 For the signaling plane, it lets the tunnel entry-point coordinate the necessary interactions between the end-to-end and tunnel QoS sessions, such as QoS adjustment in sender-initiated reservations. For the data plane, it lets the tunnel entry-point encapsulate data flow packets correctly according to the chosen tunnel Flow ID. Since the tunnel Flow ID uses header fields that are visible inside the tunnel, tunnel intermediate nodes can classify the data flow packets and apply the right QoS treatment 🌈
The tunnel exit-point also has to maintain the same association, for similar reasons 🦋 For the signaling plane, this association enables the interaction between the end-to-end and tunnel QoS sessions, such as QoS adjustment in receiver-initiated reservations. For the data plane, it tells the tunnel exit-point that the relevant data flow packets need to be decapsulated according to the corresponding tunnel Flow ID 💜
In tunnels with preconfigured QoS sessions, the tunnel exit-point may also learn the mapping between the corresponding tunnel and end-to-end QoS sessions through preconfiguration 🎀 In tunnels without preconfigured QoS sessions, the tunnel exit-point learns that mapping through the NSIS signaling process that creates the tunnel QoS sessions inside the tunnel, with help from the appropriate QoS NSLP session-binding and message-binding mechanisms 🧚
Now the tricky bit 😭 One problem with NSIS over IP tunnels that dynamically create QoS sessions is that it involves two signaling sequences. The outcome of the tunnel signaling session directly affects the outcome of the end-to-end signaling session. Because the two signaling sessions overlap in time, there are times when a tunnel endpoint has to decide whether to keep going with the end-to-end signaling session while it's still waiting on the tunnel session results 💀 This can be handled in two ways, called sequential mode and parallel mode 🙈
In sequential mode, end-to-end signaling pauses while it waits for the results of tunnel signaling, then resumes once the tunnel signaling outcome arrives 🌸 In parallel mode, end-to-end signaling keeps going outside the tunnel while tunnel signaling is still in process and its outcome is unknown ⭐ Parallel mode may reduce signaling delays if the QoS resources in the tunnel path are sufficient compared to the rest of the end-to-end path 🔥 But if the QoS resources in the tunnel path are more constrained than the rest of the end-to-end path, parallel mode may lead to wasted end-to-end signaling, or it may need renegotiation after the tunnel signaling outcome becomes available 😬 In those cases the parallel mode signaling flow also tends to get complicated 🌀
This document goes with sequential mode for the two signaling sequences 💖 Periodt 👑
4.3. Tunnel Flow ID for Different IP Tunneling Protocols 🧚
a tunnel Flow ID identifies the end-to-end flow for packet classification within the tunnel ✨ It's based on a set of tunnel header fields. Different tunnel Flow IDs can be chosen for different tunneling mechanisms so the classification overhead stays low 💅 This document specifies the following Flow ID formats for the respective tunneling protocols:
- For IPv6 tunneling protocols (
IPv6GEN), the tunnel Flow ID consists of the tunnel entry-point IPv6 address and the tunnel exit-point IPv6 address, plus a unique IPv6 flow label [RFC3697] 🦋 - For IPsec tunnel mode (
IPsec), the tunnel Flow ID contains the tunnel entry-point IP address and the tunnel exit-point IP address, plus the Security Parameter Index (SPI) 🔐 - For all other tunneling protocols (
GRE,GREIPv4,IPv4INIPv4,MINENC,IPv6INIPv4), the tunnel entry-point inserts an additional UDP header between the tunnel header and the original packet 🎀 The Flow ID consists of the tunnel entry-point and tunnel exit-point IP addresses and the source port number in that additional UDP header. The source port number is dynamically chosen by the tunnel entry-point and conveyed to the tunnel exit-point. In these cases it's especially important that the tunnel exit-point understands the additional UDP encapsulation, so it can correctly decapsulate both the normal tunnel header and the additional UDP header. In other words, both tunnel endpoints need to be NSIS-tunnel-aware 🫶
The recommendations above about choosing the tunnel Flow ID apply to dynamically created QoS tunnel sessions 💜 For preconfigured QoS tunnel sessions, the corresponding Flow ID is determined by the configuration mechanism itself. For example, if the tunnel QoS is Diffserv based, the Diffserv Code Point (DSCP) field value may be used to identify the corresponding tunnel session 🌈
5. NSIS Operation over Tunnels with Preconfigured QoS Sessions 🌸
When tunnel QoS is managed by preconfigured QoS sessions, both the tunnel entry-point and the tunnel exit-point need to be configured with information about the Flow ID of the tunnel QoS session 🎀 This lets the tunnel endpoints perform matching encapsulating and decapsulating operations. The procedures for NSIS operating over tunnels with preconfigured QoS sessions depend on whether the end-to-end NSIS signaling is sender-initiated or receiver-initiated 🦋 But in both cases, it's the tunnel entry-point that first creates the mapping between a tunnel session and an end-to-end session 💖
5.1. Sender-initiated Reservation
okay so Figure 6 is the play-by-play for when the end-to-end signaling outside the tunnel is sender-initiated 🎀 When a RESERVE message comes in from the sender, Tentry checks the tunnel QoS configuration and figures out whether (and how) this end-to-end session can be mapped onto a preconfigured tunnel session 🧚 The mapping criteria are part of the preconfiguration and honestly outside the scope of this doc. Then Tentry tunnels the RESERVE over to Texit, Texit forwards it to the receiver, and the receiver replies with a RESPONSE that travels back through Texit and Tentry to the sender 🦋 If the RESPONSE that Tentry gets confirms the overall signaling was successful, Tentry starts encapsulating every incoming packet of the data flow using the tunnel Flow ID for the mapped tunnel session. Texit can decapsulate because it recognizes that mapped tunnel Flow ID, thanks to the info supplied when the tunnel session was preconfigured 💅
Sender Tentry Tmid Texit Receiver
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | |
| +---------------------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<----------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
| | | | |
Figure 6: Sender-Initiated End-to-End Session with Preconfigured
Tunnel QoS Sessions5.2. Receiver-Initiated Reservation
Figure 7 shows the signaling sequence when the end-to-end signaling outside the tunnel is receiver-initiated 🌸 When the first end-to-end Query message arrives, Tentry examines the tunnel QoS configuration, then updates and tunnels the Query message to Texit. Texit decapsulates the QUERY message, processes it, and forwards it toward the receiver. The receiver sends back a RESERVE message that passes through Texit and arrives at Tentry. Tentry decides whether and how the QoS request for this end-to-end session can be mapped to a preconfigured tunnel session, based on criteria outside the scope of this document. Then Tentry forwards the RESERVE message towards the sender 💜 The signaling continues until a RESPONSE message arrives at Tentry, Texit, and finally the receiver. If the RESPONSE that Tentry receives confirms the overall signaling was successful, Tentry starts encapsulating every incoming packet of the data flow using the tunnel Flow ID for the mapped tunnel session. Similarly, Texit can decapsulate the tunnel packets because it recognizes the mapped tunnel Flow ID, based on info supplied during tunnel session preconfiguration ✨
Since separate tunnel QoS signaling isn't involved in preconfigured QoS tunnels, Figures 6 and 7 make the tunnel look like a single virtual link. The signaling path simply skips all tunnel intermediate nodes. However, both Tentry and Texit need to deploy the NSIS-tunnel-related functionalities described above, including acting on the end-to-end NSIS signaling messages based on tunnel QoS status, mapping end-to-end and tunnel QoS sessions, and correctly encapsulating and decapsulating tunnel packets according to the tunnel protocol and the configured tunnel Flow ID 🫶
Sender Tentry Tmid Texit Receiver
| | | | |
| QUERY | | | |
+------------->| | | |
| | QUERY | |
| +---------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | RESERVE | |
| |<----------------------------+ |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +---------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
| | | | |
Figure 7: Receiver-Initiated End-to-End Session with Preconfigured
Tunnel QoS Sessions6. NSIS Operation over Tunnels with Dynamically Created QoS Sessions 🦋
okay this is the dynamic version, and it's giving "build it as you go" 🔥 When there are no preconfigured tunnel QoS sessions, a tunnel can apply the same NSIS QoS signaling mechanism used for the end-to-end path to manage the QoS inside the tunnel. The tunnel NSIS signaling only involves those NSIS nodes that sit in the tunnel forwarding path 💖 The Flow IDs for the tunnel signaling are based on tunnel header fields. NSIS peer discovery messages inside the tunnel tell themselves apart using those tunnel header fields, which solves the problem for tunnel intermediate NSIS nodes that need to intercept signaling messages 🧚
When tunnel endpoints dynamically create tunnel QoS sessions, the initiation mode of the tunnel session always follows the initiation mode of the end-to-end session 🌈 So if the end-to-end session is sender-initiated, the tunnel session should also be sender-initiated; and if the end-to-end session is receiver-initiated, the tunnel session should also be receiver-initiated. Main character energy, the tunnel just copies the end-to-end vibe 👑
The tunnel entry-point passes the matching tunnel Flow ID for an end-to-end session over to the tunnel exit-point during the tunnel signaling process 🎀 The entry-point also tells the exit-point how the tunnel session and the end-to-end session are bound together, using the BOUND_SESSION_ID QoS NSLP message object. And the reservation message dependencies between the tunnel session and the end-to-end session get sorted out with the MSG-ID and BOUND-MSG-ID objects from the QoS NSLP message binding mechanism 💅
6.1. Sender-Initiated Reservation ✨
Okay bestie, Figure 8 🎀 shows the typical messaging sequence of how NSIS operates over IP tunnels when both the end-to-end session and the tunnel session are sender-initiated 💖. Tunnel signaling messages are told apart from end-to-end messages by a prime symbol after the message name, so RESERVE' is the tunnel one and RESERVE is the end-to-end one 🦋. The sender first sends an end-to-end RESERVE message (1) that lands at Tentry 🧚. Tentry picks the tunnel Flow ID, creates the tunnel session, and associates the end-to-end session with the tunnel session 🔗.
Next, Tentry sends a tunnel RESERVE' message (2) towards Texit, matching what the end-to-end session asked for, so the tunnel resources get reserved 💅. This RESERVE' message (2) carries a MSG-ID object holding a randomly generated 128-bit MSG-ID 🎲. Meanwhile, Tentry tucks a BOUND-MSG-ID object (with the same MSG-ID) and a BOUND-SESSION-ID object (with the SESSION-ID of the tunnel session) into the original RESERVE message, then sends that RESERVE message (3) towards Texit using normal tunnel encapsulation 🫧. The Message_Binding_Type flags of both the MSG-ID and BOUND-MSG-ID objects in the RESERVE' and RESERVE messages (2, 3) are SET, which means a bidirectional binding 🔁. The tunnel RESERVE' message (2) is processed hop-by-hop inside the tunnel for the flow identified by the chosen tunnel Flow ID, while the end-to-end RESERVE message (3) passes through the tunnel intermediate nodes (Tmid) just like any other tunneled packet 🚇.
These two messages could show up at Texit in different orders, and Texit's reaction should combine the tunnel QoS message processing rules with the QoS NSLP processing principles for message binding [RFC5974], as shown below 🌸.
Sender Tentry Tmid Texit Receiver
| | | | |
| RESERVE(1) | | | |
+------------->| | | |
| | RESERVE'(2) | | |
| +=============>| | |
| | | RESERVE'(2) | |
| | +=============>| |
| | RESERVE(3) | |
| +---------------------------->| |
| | | RESPONSE'(4) | |
| | |<=============+ |
| | RESPONSE'(4) | | |
| |<=============+ | |
| | | | RESERVE(5) |
| | | +------------->|
| | | | RESPONSE(6) |
| | | |<-------------+
| | RESPONSE(6) | |
| |<----------------------------+ |
| RESPONSE(6) | | | |
|<-------------+ | | |
| | | | |
| | | | |
(1,5): RESERVE w/o BOUND-MSG-ID and BOUND-SESSION-ID
(2): RESERVE' w/ MSG-ID
(3): RESERVE w/ BOUND-MSG-ID and BOUND-SESSION-IDFigure 8: Sender-Initiated Reservation for Both End-to-End and Tunnel Signaling
Possibility one 💫: this is the example in Figure 8, where the tunnel RESERVE' message (2) arrives first. In QoS NSLP message binding terms, it's the triggering message 🔥. Because the binding is bidirectional, Texit records the MSG-ID of RESERVE' (2), enqueues it, and starts a MsgIDWait timer while it waits for the end-to-end RESERVE message (3), which is the bound signaling message in QoS NSLP terms ⏳. The timer value is set to the default retransmission timeout period QOSNSLP_REQUEST_RETRY. When the end-to-end RESERVE (3) arrives, Texit notices a stored MSG-ID that matches the MSG-ID in the BOUND-MSG-ID object of the incoming message, so the message binding condition is satisfied 🫶. Texit then resumes processing the tunnel RESERVE' (2), creates the reservation state for the tunnel session, and sends a tunnel RESPONSE' (4) to Tentry 🎉. At the same time, Texit checks the BOUND-SESSION-ID object of the end-to-end RESERVE (3) and records the binding of the tunnel session with the end-to-end session 🔐. It also updates the end-to-end RESERVE based on the result of the tunnel session reservation, removes its tunnel BOUND-SESSION-ID and BOUND-MSG-ID objects, and forwards the end-to-end RESERVE message (5) along the path towards the receiver 🏃♀️. When the receiver gets RESERVE (5), it sends an end-to-end RESPONSE message (6) back to the sender 💌.
Possibility two 💜: the end-to-end RESERVE message arrives at Texit before the tunnel RESERVE' message. Texit sees a BOUND-SESSION-ID object and a BOUND-MSG-ID object in the end-to-end RESERVE, but realizes the tunnel session doesn't exist yet 😳. So Texit enqueues the RESERVE message and starts a MsgIDWait timer, set to the default retransmission timeout period QOSNSLP_REQUEST_RETRY. When the matching tunnel RESERVE' arrives with a MSG-ID that matches the outstanding BOUND-MSG-ID object, the message binding condition is satisfied 🙌. Texit sends a tunnel RESPONSE' back to Tentry, updates the end-to-end RESERVE by incorporating the result of the tunnel session reservation, and removes the tunnel BOUND-SESSION-ID and BOUND-MSG-ID objects 🧹. Then Texit forwards the end-to-end RESERVE along the path towards the receiver. When the receiver receives the end-to-end RESERVE message, it sends an end-to-end RESPONSE message back to the sender 🌈.
Possibility three 🍓: the tunnel RESERVE' message arrives at Texit first, but the end-to-end RESERVE message never shows up. In that case, the MsgIDWait timer for the queued tunnel RESERVE' message expires. Texit should then send a tunnel RESPONSE' back to Tentry indicating that a reservation error has occurred, and discard the tunnel RESERVE' message 🥲.
Possibility four 💀: the end-to-end RESERVE message arrives at Texit first, but the tunnel RESERVE' message never arrives. Then the MsgIDWait timer for the queued end-to-end RESERVE message expires. Texit should treat this situation as a local reservation failure, and according to [RFC5974], Texit as a stateful QoS NSLP should generate an end-to-end RESPONSE message indicating a RESERVE error to the sender 🚨.
Once the end-to-end and the tunnel QoS sessions have both been successfully created and associated, the tunnel endpoints Tentry and Texit coordinate the signaling between the two sessions 🤝. They make sure that adjustment or teardown of either session may trigger similar actions for the other session as necessary, by invoking appropriate signaling messages. That's the whole vibe, and it's giving well-coordinated ✨👑
6.2. Receiver-Initiated Reservation 🦋
Okay so this is the receiver-initiated version, where the receiver kicks off both the end-to-end and the tunnel sessions 💅. Figure 9 is the whole choreography, so screenshot it.
Sender Tentry Tmid Texit Receiver
| | | | |
| QUERY(1) | | | |
+------------->| | | |
| | QUERY'(2) | | |
| +=============>| | |
| | | QUERY'(2) | |
| | +=============>| |
| | | RESPONSE'(3) | |
| | |<=============+ |
| | RESPONSE'(3) | | |
| |<=============+ | |
| | QUERY(4) | |
| +---------------------------->| |
| | | | QUERY(5) |
| | | +------------->|
| | | | RESERVE(6) |
| | | |<-------------+
| | | RESERVE'(7) | |
| | |<=============+ |
| | RESERVE'(7) | | |
| |<=============+ | |
| | RESERVE(8) | |
| |<----------------------------+ |
| | RESPONSE'(9) | | |
| +=============>| | |
| | | RESPONSE'(9) | |
| | +=============>| |
| RESERVE(10) | | | |
|<-------------+ | | |
| RESPONSE(11) | | | |
+------------->| | | |
| | RESPONSE(11) | |
| +---------------------------->| |
| | | | RESPONSE(11) |
| | | +------------->|
| | | | |
| | | | |
(1), (5): QUERY w/ RESERVE-INIT
(2): QUERY' w/ RII
(4): QUERY w/ RESERVE-INIT and BOUND-SESSION-ID
(6), (10): RESERVE w/o BOUND-SESSION-ID
(7): RESERVE' w/ MSG-ID
(8): RESERVE w/ BOUND-MSG-ID and BOUND-SESSION-ID
Figure 9: Receiver-Initiated Reservation for Both End-to-end and
Tunnel SignalingSo the sender's QUERY (1) lands at Tentry, and Tentry picks the tunnel Flow ID and sends out a tunnel QUERY' (2) that matches the end-to-end request heading toward Texit. This one is more of a scouting trip 🔍. It's meant to figure out the QoS vibe of the tunnel path, not to actually reserve anything, which is why it carries an RII object but doesn't set the RESERVE-INIT flag. The tunnel QUERY' (2) gets processed hop-by-hop inside the tunnel for the flow identified by the tunnel Flow ID. When Texit gets it, Texit sends back a tunnel RESPONSE' (3) with the tunnel path characteristics.
Once Tentry has that RESPONSE' (3), it finally creates the tunnel session 🎀. Then it generates an outgoing end-to-end QUERY (4) that takes the tunnel path characteristics into account, tacks on a tunnel BOUND-SESSION-ID object holding the tunnel SESSION-ID, and sends it to Texit using normal tunnel encapsulation. The end-to-end QUERY (4) rides through the tunnel's intermediate nodes just like any other tunneled packet 🚂. When Texit sees this QUERY (4), it notices the tunnel session binding, creates the tunnel session state, strips out the tunnel BOUND-SESSION-ID object, and passes the end-to-end QUERY (5) along the path.
The QUERY (5) reaches the receiver and triggers a RESERVE (6) 🙌. When Texit gets that RESERVE (6), it realises the session is bound to a receiver-initiated tunnel session, so it fires off a tunnel RESERVE' (7) toward Tentry for the tunnel session reservation. This RESERVE' (7) carries a randomly generated 128-bit MSG-ID. At the same time, Texit slips a BOUND-MSG-ID object with that same MSG-ID, plus a BOUND-SESSION-ID object with the tunnel SESSION-ID, into the end-to-end RESERVE (8), and sends it toward Tentry using normal tunnel encapsulation. In the RESERVE' and RESERVE messages (7, 8), the Message_Binding_Type flags on the MSG-ID and BOUND-MSG-ID objects are SET, which signals a bidirectional binding 🔗.
At Tentry, the tunnel RESERVE' (7) and the end-to-end RESERVE (8) can show up in either order 🤷♀️. In the typical case from Figure 9, the tunnel RESERVE' (7) arrives first. Tentry records its MSG-ID and starts a MsgIDWait timer ⏲️. When the end-to-end RESERVE (8) arrives with a BOUND-MSG-ID object carrying that same MSG-ID, the message binding condition is satisfied and everything clicks. Tentry picks the tunnel RESERVE' (7) back up, creates the reservation state for the tunnel session, and sends a tunnel RESPONSE' (9) to Texit. Then Tentry builds the outgoing end-to-end RESERVE (10), folding in the results of the tunnel session reservation and removing the BOUND-SESSION-ID and BOUND-MSG-ID objects, and forwards it toward the sender. When the sender gets the RESERVE (10), it sends an end-to-end RESPONSE (11) back to the receiver 🎉.
If the end-to-end RESERVE shows up at Tentry before the tunnel RESERVE', or if either of the two messages never arrives at Tentry, Tentry handles things pretty much the way Texit does in the situation from Section 6.1 🧩.
Once both the end-to-end and the tunnel QoS sessions have been created and linked up, the tunnel endpoints Tentry and Texit coordinate signaling between the two sessions 🫶. They make sure that if either session gets adjusted or torn down, the other one gets the matching treatment when needed, by sending the appropriate signaling messages. Iconic teamwork 👑.
7. NSIS-Tunnel Signaling Capability Discovery ✨
Okay, so NSIS over IP tunnels is a team sport 🏀. Both tunnel endpoints have to coordinate on special encapsulation and decapsulation of data flow packets according to the chosen tunnel Flow ID, and on creating and adjusting the end-to-end and tunnel QoS sessions. So before one NSIS-tunnel-aware endpoint starts this whole mechanism, it needs to be sure the other endpoint is NSIS-tunnel-aware too 👀.
Sometimes this is already known. Especially with IP tunnels that have preconfigured QoS sessions, an NSIS-tunnel-aware endpoint can just learn through preconfiguration that the other side is also tunnel-aware 📋. When there's no preconfiguration, the endpoint that's starting things can dynamically discover the other tunnel endpoint's capability using the QoS NSLP NODE_CAPABILITY_TUNNEL object defined in this section 🕵️♀️.
The NODE_CAPABILITY_TUNNEL object is a zero-length object with a standard NSLP object header, and it looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: NODE_CAPABILITY_TUNNEL Object Format- Type:
NODE_CAPABILITY_TUNNEL(0x015) from the shared NSLP object type space - Length:
0
The bits marked A and B decide what happens to objects whose Type field a node doesn't recognise 🤔. If a node doesn't recognise the NODE_CAPABILITY_TUNNEL object, the desired behaviour is "Forward". That means the object must be kept unchanged and forwarded as part of message processing. Setting AB to 10 gets you that behaviour. The r bit is reserved, so it's just sitting there doing nothing 💤.
The NODE_CAPABILITY_TUNNEL object goes into a tunnel QUERY' or RESERVE' message from any tunnel endpoint that wants to learn whether the other endpoint can handle NSIS tunnels 📨. If the receiving endpoint really is NSIS-tunnel-aware, it spots the object, realises the sender is tunnel-aware too, and puts the same object into a tunnel RESPONSE' message to tell the sender "yep, I'm tunnel-aware as well" 💖. Here's how that plays out for each reservation style.
First, say the end-to-end session is sender-initiated like in Figure 8, and the NSIS-tunnel-aware Tentry wants to find out Texit's tunnel capability. After getting the first end-to-end RESERVE (1), Tentry adds an RII object and a NODE_CAPABILITY_TUNNEL object into the tunnel RESERVE' (2) and sends it to Texit. If Texit is NSIS-tunnel-aware, it sees the NODE_CAPABILITY_TUNNEL object, learns that Tentry is tunnel-aware too, and includes the same object in the tunnel RESPONSE' (4) it sends back to Tentry 🥰.
Second, say the end-to-end session is receiver-initiated like in Figure 9, and Tentry again wants to discover Texit's tunnel capability. When the first end-to-end QUERY (1) arrives, Tentry puts an RII object and a NODE_CAPABILITY_TUNNEL object into the tunnel QUERY' (2) and sends it toward Texit. If Texit is NSIS-tunnel-aware, it learns from the NODE_CAPABILITY_TUNNEL object that Tentry is tunnel-aware as well, and includes the same object in the tunnel RESPONSE' (3) sent back to Tentry 🌸.
8. IANA Considerations 💖
This document defines a new object type called NODE_CAPABILITY_TUNNEL for QoS NSLP. IANA has assigned its Type value, 0x015 🎀. The object format and the setting of the extensibility bits are defined in Section 7.
9. Security Considerations 🔒✨
okay bestie, this part is serious, so let's get into it 💀. There are two IPsec-related security implications for this NSIS and IP tunnel interop mechanism 🫶.
First, NSIS messages might need per-hop processing inside the IPsec tunnel, and that can be potentially incompatible with IPsec 😬. RSVP has the same problem when it works with IPsec and the Router Alert option is used (Appendix A.1 of RFC 4302 [RFC4302]). If this mechanism is actually used for NSIS and IPsec tunnels, a so-called covert channel could exist 👀. Someone could create spurious NSIS signaling flows inside the protected network to generate signaling on the outside network, where someone else is watching. For highly secure networks, that's basically a way to smuggle information out, so this channel will need to be rate-limited 🚫. A similar covert channel rate-limit problem exists when using Differentiated Services (DS) or Explicit Congestion Notification (ECN) fields with IPsec (Section 5.1.2 of RFC 4301 [RFC4301]) 💅.
Second, the NSIS-tunnel-aware endpoint is responsible for adapting changes between NSIS signaling inside and outside the tunnel 🔁. So there could be extra risks for an IPsec endpoint that is also an NSIS-tunnel-aware endpoint 😭. For example, a security vulnerability (like a buffer overflow) in the NSIS stack of that IPsec tunnel endpoint might get exposed to the unprotected outside network 💀. That said, it's also worth noting that if any node along the signaling path is compromised, the whole end-to-end QoS signaling could be affected, whether or not the end-to-end path includes an IPsec tunnel 🚨.
Several other documents talk about security issues for NSIS too 📚. General threats for NSIS are in [RFC4081]. Security considerations for the NSIS NTLP and QoS NSLP are discussed in [RFC5971] and [RFC5974], respectively 🫶.
10. Acknowledgments 🌸
The authors want to thank Roland Bless, Francis Dupont, Lars Eggert, Adrian Farrel, Russ Housley, Georgios Karagiannis, Jukka Manner, Martin Rohricht, Peter Saint-Andre, Martin Stiemerling, Hannes Tschofenig, and other members of the NSIS working group for their comments 💖. Thanks also to Yaron Sheffer for pointing out the IPsec-related security considerations 🙌.
11. References 📚
11.1. Normative References 💜
- [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
- [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
- [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
- [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
- [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
- [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
- [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
- [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
- [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
11.2. Informative References 🦋
- [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.
- [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
- [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
- [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
- [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
- [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
- [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
Authors' Addresses 🎀
Here are the people who made this happen, with their contact details 💖.
Charles Shen
Columbia University
Department of Computer Science
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
Phone: +1 212 854 3109
EMail: charles@cs.columbia.eduHenning Schulzrinne
Columbia University
Department of Computer Science
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.eduSung-Hyuck Lee
Convergence Technologies & Standardization Lab
Samsung Information System America, INC.
95 West Plumeria Drive
San Jose, CA 95134
USA
Phone: 1-408-544-5809
EMail: sung1.lee@samsung.comJong Ho Bang
SAMSUNG Advanced Institute of Technology
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
South Korea
Phone: +82 31 280 9585
EMail: jh0278.bang@samsung.com📦 where this page comes from
- ietf: rfc5979 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms