RFC 4080
Next Steps in Signaling (NSIS): Framework
RFC 4080: Next Steps in Signaling (NSIS): Framework 🦋
Okay bestie, this is RFC 4080, "Next Steps in Signaling (NSIS): Framework," and it's from June 2005 ✨. It's an Informational doc from the Network Working Group, so it's giving "here's some useful context," not "you must do this" 💅. The authors are R. Hancock (Siemens/RMR), G. Karagiannis (University of Twente/Ericsson), J. Loughney (Nokia), and S. Van den Bosch (Alcatel) 👑. The title block doesn't list anything it obsoletes or updates, so it's a standalone vibe 🎀.
Status of This Memo 📜
This memo is for the Internet community, for information only. It doesn't specify an Internet standard of any kind, so nobody's getting a standards-track stamp here 🌸. Distribution of this memo is unlimited, so share it with everyone 🫶.
Copyright Notice ©️
Copyright (C) The Internet Society (2005). 💜
Abstract ✨
So the Next Steps in Signaling (NSIS) working group is looking into protocols for signaling information about a data flow along its path through the network 🛣️. The NSIS suite is meant to support all kinds of signaling apps that need to install and/or manipulate that state in the network, which is a lot of apps 🔥. Building on existing work on signaling requirements, this doc proposes an architectural framework for these signaling protocols, and it's honestly the blueprint everything else is built on 🧚.
This document gives a model for the network entities that take part in that signaling, plus how signaling relates to the rest of network operation 🍓. The big move is splitting the whole signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application. Main character energy for the lower layer, ngl 👑.
Table of Contents 📚
1. Introduction ....................................................3
1.1. Definition of the Signaling Problem ........................3
1.2. Scope and Structure of the NSIS Framework ..................3
2. Terminology .....................................................4
3. Overview of Signaling Scenarios and Protocol Structure ..........6
3.1. Fundamental Signaling Concepts .............................6
3.1.1. Simple Network and Signaling Topology ...............6
3.1.2. Path-Coupled and Path-Decoupled Signaling ...........7
3.1.3. Signaling to Hosts, Networks, and Proxies ...........8
3.1.4. Signaling Messages and Network Control State .......10
3.1.5. Data Flows and Sessions ............................10
3.2. Layer Model for the Protocol Suite ........................11
3.2.1. Layer Model Overview ...............................11
3.2.2. Layer Split Concept ................................12
3.2.3. Bypassing Intermediate Nodes .......................13
3.2.4. Core NSIS Transport Layer Functionality ............15
3.2.5. State Management Functionality .....................16
3.2.6. Path-Decoupled Operation ...........................17
3.3. Signaling Application Properties ..........................18
3.3.1. Sender/Receiver Orientation ........................18
3.3.2. Uni- and Bi-Directional Operation ..................19
3.3.3. Heterogeneous Operation ............................19
3.3.4. Aggregation ........................................20
3.3.5. Peer-Peer and End-End Relationships ................21
3.3.6. Acknowledgements and Notifications .................21
3.3.7. Security and Other AAA Issues ......................22
4. The NSIS Transport Layer Protocol ..............................23
4.1. Internal Protocol Components ..............................23
4.2. Addressing ................................................24
4.3. Classical Transport Functions .............................24
4.4. Lower Layer Interfaces ....................................26
4.5. Upper Layer Services ......................................27
4.6. Identity Elements .........................................28
4.6.1. Flow Identification ................................28
4.6.2. Session Identification .............................28
4.6.3. Signaling Application Identification ...............29
4.7. Security Properties .......................................30
5. Interactions with Other Protocols ..............................30
5.1. IP Routing Interactions ...................................30
5.1.1. Load Sharing and Policy-Based Forwarding ...........31
5.1.2. Route Changes ......................................31
5.2. Mobility and Multihoming Interactions .....................33
5.3. Interactions with NATs ....................................36
5.4. Interactions with IP Tunneling ............................36
6. Signaling Applications .........................................37
6.1. Signaling for Quality of Service ..........................37
6.1.1. Protocol Message Semantics .........................38
6.1.2. State Management ...................................39
6.1.3. Route Changes and QoS Reservations .................39
6.1.4. Resource Management Interactions ...................41
6.2. Other Signaling Applications ..............................42
7. Security Considerations ........................................42
8. References .....................................................43
8.1. Normative References ......................................43
8.2. Informative References ....................................441. Introduction ✨
1.1. Definition of the Signaling Problem 🎯
Okay so the NSIS working group is looking at protocols for signaling information about a data flow along its path in the network 🛤️.
It's assumed that the path the data flow takes is already decided by network configuration and routing protocols, totally separate from the signaling itself 💖. So signaling to set up the routes themselves is not considered ngl. Instead, the signaling just talks to the nodes along the data flow path 🧚. Two more simplifications: the actual signaling messages go straight through those nodes (that's the 'path-coupled' case, see Section 3.1.2 🦋), and only unicast data flows are considered 💅.
The signaling problem here is very similar to what RSVP handles 🌸. But there are two big generalizations, bestie 👑. First, the NSIS protocol suite components should be usable in different parts of the Internet, for different needs, without needing a complete end-to-end deployment. Like, the signaling protocol messages may not need to run all the way between the data flow endpoints 🙈.
Second, signaling is meant for more than just QoS (resource reservation) 🔥. The way they get that flexibility is by splitting the signaling protocol stack into two layers: a generic (lower) layer, and an upper layer specific to each signaling application. The NSIS scope is to define the generic protocol and, to start, upper layers suitable for QoS signaling (similar to the RSVP QoS functionality) and middlebox signaling. Further applications may be considered later 🌈.
1.2. Scope and Structure of the NSIS Framework 🗺️
The underlying requirements for NSIS signaling are defined in [1], and there's a separate security threats document [2] too 🔐. Other related requirements are in [3] and [4], for QoS/Mobility and middlebox communication respectively 🎀. This framework does not replace or update these requirements, so they're still the source of truth 💜. Discussions about lessons to be learned from existing signaling and resource management protocols are in separate analysis documents [5], [6] 📚.
The role of this framework is to explain how NSIS signaling should work within the broader networking context, and to describe the overall structure of the protocol suite itself ✨. So it digs into important protocol considerations like routing, mobility, security, and interactions with network 'resource' management (in the broadest sense) 🫶.
The basic context for NSIS protocols is in Section 3. Section 3.1 covers the fundamental elements of NSIS protocol operation compared to RSVP [7]. Specifically, Section 3.1.3 describes more general signaling scenarios, and Section 3.1.4 defines a broader class of signaling applications the NSIS protocols should be useful for 🧚. The two-layer protocol architecture that makes all this generality work is described in Section 3.2, and Section 3.3 gives examples of how particular signaling application properties can be accommodated within signaling layer protocol behavior 💅.
The overall functionality required from the lower (generic) protocol layer is in Section 4. This isn't meant to define the detailed design of the protocol, or even the design options, although a few are described as examples 🌸. It describes the interfaces between this lower-layer protocol and the IP layer (below) and signaling application protocols (above), including the identifier elements that appear on these interfaces (Section 4.6) 🦋. Then Section 5 describes how signaling applications that use NSIS can interact sensibly with network layer operations: specifically routing (and re-routing), IP mobility, and network address translation (NAT) 👑.
Section 6 describes particular signaling applications 🔥. The QoS example (comparable to core RSVP QoS signaling functionality) is covered in detail in Section 6.1, which describes both the signaling application specific protocol and example modes of interaction with network resource management and other deployment aspects 💖. But heads up, these examples are included only as background and for explanation. The authors do not intend to define an over-arching architecture for carrying out resource management in the Internet 🙈. Further possible signaling applications are outlined in Section 6.2 🌈.
Part 1 done, more parts are coming next bestie 💖✨
2. Terminology ✨
okay bestie, let's get the vocab down first 📚 these definitions are the foundation for everything else, so we're gonna be precise 💅
- Classifier: an entity that selects packets based on their contents according to defined rules. 🎯
- [Data] flow: a stream of packets from sender to receiver that is a distinguishable subset of a packet stream. Each flow is distinguished by some flow identifier (see Section 4.6.1). 🌊
- Edge node: an (NSIS-capable) node on the boundary of some administrative domain. 🚪
- Interior nodes: the set of (NSIS-capable) nodes that form an administrative domain, excluding the edge nodes. 🏠
- NSIS Entity (NE): the function within a node that implements an NSIS protocol. In the case of path-coupled signaling, the NE will always be on the data path. 🧚
- NSIS Signaling Layer Protocol (NSLP): generic term for an NSIS protocol component that supports a specific signaling application. See also Section 3.2.1. 🎀
- NSIS Transport Layer Protocol (NTLP): placeholder name for the NSIS protocol component that will support lower-layer (signaling application-independent) functions. See also Section 3.2.1. 🦋
- Path-coupled signaling: a mode of signaling in which the signaling messages follow a path that is tied to the data messages. 🔗
- Path-decoupled signaling: signaling for state manipulation related to data flows, but only loosely coupled to the data path; e.g., at the AS level. 🌙
- Peer discovery: the act of locating and/or selecting which NSIS peer to carry out signaling exchanges with for a specific data flow. 🔍
- Peer relationship: signaling relationship between two adjacent NSIS entities (i.e., NEs with no other NEs between them). 🫶
- Receiver: the node in the network that is receiving the data packets in a flow. 📥
- Sender: the node in the network that is sending the data packets in a flow. 📤
- Session: application layer flow of information for which some network control state information is to be manipulated or monitored (see Section 3.1.5). 💜
- Signaling application: the purpose of the NSIS signaling. A signaling application could be QoS management, firewall control, and so on. Totally distinct from any specific user application. 👑
3. Overview of Signaling Scenarios and Protocol Structure
okay now we get to the fun part, the big picture 🌈 this section is about who talks to who and where
3.1. Fundamental Signaling Concepts
3.1.1. Simple Network and Signaling Topology
so the NSIS suite is built to support all kinds of signaling applications that need to install and/or manipulate state in the network 🕸️ that state is tied to a data flow and gets installed and maintained on the NSIS Entities (NEs) along the flow's path. not every node has to have an NE, which is lowkey important to remember ✨ the basic protocol concepts don't depend on the signaling application, but the details of how it runs and what info gets carried totally do 💅 this section covers the basic entities and the interfaces between them.
Two NSIS entities that communicate directly are said to be in a 'peer relationship'. 🤝 this is loosely described as an 'NSIS hop', but there's no implication that it matches a single IP hop, so don't mix those up 🙈 either or both NEs might store some state about the other, but there's no assumption that they'll set up a long-term signaling connection between themselves.
It's common to think of a network as made of different domains (for admin or routing purposes), and signaling can be influenced by those domain boundaries 🗺️ however, there's no real reason to expect an 'NSIS domain' to line up exactly with an IP domain (AS, area). it's more likely that its boundaries will be made of the boundaries (segments) of one or several IP domains 🧩
Figure 1 is basically the simplest signaling setup possible 🍓 a single data flow runs from an app on the sender to the receiver through routers R1, R2, and R3. each host and two of the routers have NEs that swap signaling messages (possibly in both directions) about the flow. this is basically the same as what RSVP does for QoS signaling, the main difference being that we don't assume any particular sequence of signaling messages will be invoked 🎀
Sender Receiver
+-----------+ +----+ +----+ +----+ +-----------+
|Application|----->| R1 |----->| R2 |----->| R3 |----->|Application|
| +--+ | |+--+| |+--+| +----+ | +--+ |
| |NE|====|======||NE||======||NE||==================|===|NE| |
| +--+ | |+--+| |+--+| | +--+ |
+-----------+ +----+ +----+ +-----------+
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
Figure 1: Simple Signaling and Data Flows3.1.2. Path-Coupled and Path-Decoupled Signaling
there are two basic paradigms for resource reservation signaling, and we call them "path-coupled" and "path-decoupled" 🦋
so for path-coupled, signaling messages only get routed through NEs that are on the data path. they don't have to reach every node on the data path though! 🙃 for example, there could be intermediate signaling-unaware nodes, or proxies (like the ones in Figure 2) could stop the signaling from reaching the path end points. between adjacent NEs, the route taken by signaling and data might diverge. the path-coupled case can be supported by different addressing styles: messages can be explicitly addressed to the neighbor on-path NE, or addressed identically to the data packets but with the router alert option (see [8] and [9]) and intercepted. these cases get covered in Section 4.2. in that second case, some network setups may split the signaling and data paths (see Section 5.1.1), and that's treated as an error case for path-coupled signaling 😬
for path-decoupled, signaling messages get routed to nodes (NEs) that aren't assumed to be on the data path, but that are (presumably) aware of it. signaling messages will always be directly addressed to the neighbor NE, and the signaling endpoints may have no relation at all to the ultimate data sender or receiver 🌙 the implications of path-decoupled operation for the NSIS protocols get a brief look in Section 3.2.6. however, the initial goal of NSIS and this framework is to focus mainly on path-coupled 💜
3.1.3. Signaling to Hosts, Networks, and Proxies
signaling can be triggered by all sorts of things: user apps (using NSIS signaling services), other signaling apps, network management actions, some network events, and more 🌸 that means signaling has to be startable and stoppable in different parts of the network: hosts, domain boundary nodes (edge nodes), or interior domain nodes.
NSIS extends the RSVP model to cover this wider range of signaling exchanges 🚀 besides the basic end-to-end model, things like end-to-edge and edge-to-edge can be considered. in edge-to-edge, the edge nodes might talk directly, and also via the interior nodes.
the end-to-edge (host-to-network) scenario only needs intra-domain signaling, but the other cases might need inter-domain NSIS signaling too, if the signaling endpoints (hosts or network edges) are connected to different domains 🌍 depending on the trust relation between concatenated NSIS domains, edge-to-edge might cover a single domain or multiple concatenated NSIS domains. the latter case assumes trust relations exist between those domains 🫶
sometimes you want to start or end NSIS signaling not from the end host that sends or receives the data flow, but from some other entity in the network called a signaling proxy 🧚 there are a bunch of reasons for this: signaling on behalf of end hosts that aren't NSIS-aware, consolidating customer accounting (authentication, authorization) for consumed application and transport resources, security considerations, limiting the physical connection between host and network, and so on. this setup counts as a kind of "proxy on the data path," see Figure 2 🔥
Proxy1 Proxy2
+------+ +----+ +----+ +----+ +----+ +--------+
|Sender|-...->|Appl|--->| R |--->| R |--->|Appl|-...->|Receiver|
| | |+--+| |+--+| |+--+| |+--+| | |
+------+ ||NE||====||NE||====||NE||====||NE|| +--------+
|+--+| |+--+| |+--+| |+--+|
+----+ +----+ +----+ +----+
+--+
|NE| = NSIS ==== = Signaling ---> = Data flow messages
+--+ Entity Messages (unidirectional)
Appl = signaling application
Figure 2: "On path" NSIS proxythis setup comes with two specific challenges for the signaling:
- A proxy that terminates signaling on behalf of the NSIS-unaware host (or part of the network) should be able to determine that it is the last NSIS-aware node along the path. 🕵️
- Where a proxy initiates NSIS signaling on behalf of the NSIS-unaware host, interworking with some other "local" technology might be required (for example, to provide QoS reservation from proxy to the end host in the case of a QoS signaling application). 🧩
+------+ +----+ +----+ +----+ +--------+
|Sender|----->| PA |----->| R2 |----->| R3 |----->|Receiver|
| | |+--+| |+--+| +----+ | +--+ |
+------+ ||NE||======||NE||==================|==|NE| |
|+--+| |+--+| | +--+ |
+-..-+ +----+ +--------+
..
..
+-..-+
|Appl|
+----+
Appl = signaling PA = Proxy for signaling
application application
Figure 3: "Off path" NSIS proxythere's also another possible setup, shown in Figure 3, where an NE can send and receive signaling info to a remote processor 🖥️ NSIS may or may not be suitable for this remote interaction, but either way it isn't currently part of the NSIS problem. this setup is handled by treating the NE as a proxy at the signaling application level. it's a natural approach for some policy control and centralized control architectures, see also Section 6.1.4 ✨
3.1.4. Signaling Messages and Network Control State ✨
okay so the big differences that make NSIS signaling its own thing 💅 are that it's tied to specific flows (not just network operation in general), and it involves nodes in the network (instead of quietly running between the end hosts) 🧚
so every signaling application (upper-layer) protocol has to carry per-flow info for the bits of network-internal operation it cares about 🎀 like, for an RSVP-like QoS signaling app, that's state data for resource reservations. but it's more general than that 🌈 the per-flow info could be about some other control function in routers and middleboxes along the path. and honestly the signaling could just be used to gather per-flow info, without changing how the network operates at all 👀
we call this info 'network control state' generically 💜 signaling messages can install, modify, refresh, or just read this state from network elements for particular data flows. usually a network element also manages this info at the per-flow level, though coarser-grained ('per-class') state management is also possible 🫶
3.1.5. Data Flows and Sessions 🦋
formally, a data flow is a (unidirectional) sequence of packets between the same endpoints that all follow a unique path through the network (determined by IP routing and other network configuration) 🛤️ a flow is defined by a packet classifier (in the simplest cases, just the destination address and topological origin are needed). generally we assume that when we're only talking about the data flow path, we only need to consider 'simple' fixed classifiers (e.g., IPv4 5-tuple or equivalent) 💖
a session is an application layer concept for an exchange of packets between two endpoints, where some network state is to be allocated or monitored 🌸 in simple cases, a session may map to a specific flow, but signaling applications are allowed to create more flexible flow:session relationships 🎀 (ngl this 'session' idea is different from RSVP's, which defines a session as a flow with a specific destination address and transport protocol. NSIS is way closer to the session concepts of higher-layer protocols 🙈)
the simplest service NSIS signaling protocols provide is managing network control state at the level of a specific flow, like we covered in the previous subsection ✨ especially, it should be possible to monitor routing updates as they change the path a flow takes and, for example, update network state appropriately 🔥 this is no different from the RSVP case (local path repair). where there's a 1:1 flow:session relationship, this is all that's required 💅
BUT for some more complex scenarios (especially mobility and multihoming ones; see [1] and the mobility discussion of [5]) 😭 it's desirable to update the flow:session mapping during the session's lifetime. like, a new flow can be added and the old one deleted (maybe in that order, for a 'make-before-break' handover), effectively moving the network control state between data flows so it stays associated with the same session 🦋 these updates are best managed by the end systems (generally, systems that understand the flow:session mapping and are aware of the packet classifier change) 👑 so to make this work, it must be possible to relate signaling messages to sessions as well as to data flows. a session identifier (Section 4.6.2) is one component of the solution 🫶
3.2. Layer Model for the Protocol Suite 🌈
3.2.1. Layer Model Overview 💜
so to get a modular solution for the NSIS requirements, the NSIS protocol suite is going to be structured in two layers:
- a 'signaling transport' layer, responsible for moving signaling messages around, which should be independent of any particular signaling application; and
- a 'signaling application' layer, which contains stuff like message formats and sequences, specific to a particular signaling application.
for this document, we use the term 'NSIS Transport Layer Protocol' (NTLP) to refer to the component used in the transport layer 🚚 we also use the term 'NSIS Signaling Layer Protocol' (NSLP) to refer generically to any protocol within the signaling application layer. in the end there'll be several NSLPs, largely independent of each other 🧩 these relationships are illustrated in Figure 4. note that the NTLP may or may not have an interesting internal structure (e.g., including existing transport protocols), but that doesn't matter at this level of description 🤷♀️
^ +-----------------+
| | NSIS Signaling |
| | Layer Protocol |
NSIS | +----------------| for middleboxes |
Signaling | | NSIS Signaling | +-----------------+
Layer | | Layer Protocol +--------| NSIS Signaling |
| | for QoS | | Layer Protocol |
| +-----------------+ | for ... |
V +-----------------+
=============================================
NSIS ^ +--------------------------------+
Transport | | NSIS Transport Layer Protocol |
Layer V +--------------------------------+
=============================================
+--------------------------------+
. IP and lower layers .
. .
Figure 4: NSIS Protocol Componentsnote that not every generic function has to live in the NTLP 🙌 another option is having re-usable components within the signaling application layer. functionality within the NTLP should be restricted to what interacts strongly with other transport and lower-layer operations 💅
3.2.2. Layer Split Concept 🍓
this section breaks down the basic concepts behind how the NTLP works 🧠 first, we make a working assumption that the NTLP's protocol mechanisms only operate between adjacent NEs (informally, the NTLP is a 'hop-by-hop' protocol). any larger-scope issues (including e2e aspects) are left to the upper layers 🪜
here's how it goes: when a signaling message is ready to be sent from one NE, it's handed to the NTLP along with info about what flow it's for. then it's up to the NTLP to get it to the next NE along the path (upstream or downstream), where it's received and the NTLP's responsibility ends 📬 there's no assumption here about how the messages are actually addressed (that's a protocol design issue, and the options are outlined in Section 4.2). the key point is that the NTLP for a given NE doesn't use any knowledge about the addresses, capabilities, or status of any NEs other than its direct peers 🫣
the NTLP in the receiving NE either forwards the message directly or, if there's an appropriate signaling application locally, passes it upwards for further processing. the signaling application can then generate another message to send via the NTLP 🔁 that's how larger-scope (including end-to-end) message delivery gets achieved ✨
this definition is about NTLP operation. it doesn't restrict an NSLP's ability to send messages by other means 📣 for example, an NE in the middle or at the end of the signaling path could send a message directly to the other end as a notification or acknowledgement of some signaling application event. but the issues in sending such messages (endpoint discovery, security, NAT traversal, and so on) are so different from the direct peer-to-peer case that there's no benefit in extending the NTLP to include that non-local functionality 🙅♀️ instead, an NSLP that needs such messages and wants to avoid traversing the path of NEs should use some other existing transport protocol. for example, UDP or DCCP would be a good match for many of the scenarios that have been proposed 🦋 acknowledgements and notifications of this type are considered further in Section 3.3.6.
one reason for restricting the NTLP to peer-relationship scope is that if there are any options or variants in the design approach (or, worse, in basic functionality), it's way easier to manage the resulting complexity if it only impacts direct peers rather than potentially the whole Internet 🌍💖
3.2.3. Bypassing Intermediate Nodes ✨
Okay so, the NSIS problem has lots of signaling applications going on, bestie 💅 which means an NSLP is probably only gonna run on a subset of the NSIS-aware nodes on a path, like in Figure 5. Also, a node sitting inside an aggregation region still wants to ignore per-flow signaling messages, even when they're for an app it's generally able to handle 🙈
+------+ +------+ +------+ +------+
| NE | | NE | | NE | | NE |
|+----+| | | |+----+| |+----+|
||NSLP|| | | ||NSLP|| ||NSLP||
|| 1 || | | || 2 || || 1 ||
|+----+| | | |+----+| |+----+|
| || | | | | | | || |
|+----+| |+----+| |+----+| |+----+|
====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
|+----+| |+----+| |+----+| |+----+|
+------+ +------+ +------+ +------+
Figure 5: Signaling with Heterogeneous NSLPsSo when signaling messages cross these NSIS-aware intermediate nodes, it's giving "process them as low as possible" (ideally on the fastest path) 🏎️ To offer a non-trivial message transfer service (think security, reliability and so on) to the peer NSLP nodes, the NTLP at intermediate nodes needs to be as transparent as possible. That means it does minimal processing 🫶 And if intermediate nodes had to do slow-path processing on every NSIS message, that would wreck a lot of the scaling perks of aggregation, unless tunneling is used 😭
Now, for messages sent with the router alert option, there are two complementary ways to get this bypass going:
- At the IP layer, a set of protocol numbers or a range of values in the router alert option can be used. That way, messages get marked with an implied granularity, and routers can choose to apply further slow-path processing only to configured subsets of messages. This is the method used in [10] to tell per-flow and per-aggregate signaling apart.
- The NTLP could process the message but figure out there was no local signaling application it was relevant to. At that point, the message can be returned unchanged to the IP layer for normal forwarding. The intermediate NE has effectively chosen to be transparent to that message. 🦋
In both cases, the existence of the intermediate NE is totally hidden from the NSLP nodes ✨ If later stages of the signaling use directly addressed messages (for example, for reverse routing), they won't involve the intermediate NE at all, except maybe as a normal router. Iconic, honestly.
There may be cases where the intermediate NE wants to do some restricted protocol processing, like:
- Translating addresses in message payloads (compare Section 4.6.1). Note that this would have to be done to messages passing in both directions through a node 👀
- Updating signaling application payloads with local status information (for example, path property measurement inside a domain) 📊
If this can be done without fully terminating the NSIS protocols, the intermediate NE could be a lot more lightweight, and you'd get a more direct 'end-to-end' NTLP association between the peer NSLPs, where the signaling application is fully processed 💜 BUT, lowkey, this only works with a limited class of possible NTLP designs, and it makes it harder for the NTLP to offer a security service, since messages have to be partially protected 💀 The feasibility of this approach will be evaluated during the NTLP design.
3.2.4. Core NSIS Transport Layer Functionality 🎀
This section covers the basic functionality the NTLP is supposed to support. Real talk, the overall signaling solution is always the result of the NTLP and the signaling layer protocols (NSLPs) working together. For example, we can always assume an NSLP is running above the NTLP and handling the end-to-end stuff (like recovering messages after restarts) 🧚
So NTLP functionality is basically just efficient upstream and downstream peer-to-peer message delivery, across a wide variety of network scenarios 🌈 Message delivery includes the act of locating and/or selecting which NTLP peer to do signaling exchanges with for a specific data flow. That discovery might be active (using specific signaling packets) or passive (a side effect of using a particular addressing mode). Also, the NTLP can sensibly handle a lot of the stuff that lets signaling messages get through middleboxes, since that's closely related to just routing the signaling messages in the first place 🔥 More details about NTLP functionality are in Sections 3.2.5 and 4.3.
3.2.5. State Management Functionality 🌸
Internet signaling needs state to exist and be managed inside the network, for a bunch of reasons. This section describes how state management gets split across the NSIS layers. (Quick note, how the NTLP's internal state gets managed is up to its design and, honestly, its implementation too 🙈)
- Conceptually, the NTLP provides a uniform message delivery service. It's unaware of the difference in state semantics between different types of signaling application messages (e.g., whether a message changes state, just refreshes signaling application state, or even has nothing to do with signaling application state at all). Main character energy from the NTLP: it just delivers 💅
- An NTLP instance processes and, if necessary, forwards all signaling application messages "immediately". (It might offer different service classes, but these would be distinguished by, for example, reliability or priority, not by state aspects.) This means the NTLP doesn't know explicit timer or message sequence information for the signaling application, and that signaling application messages pass immediately through an NSLP-unaware node. (Their timing can't be jittered there, and messages can't be stored up to be re-sent on a new path in case of a later re-routing event.) No stashing, no waiting, just vibes ⚡
- Within any node, it's an implementation decision whether to generate/jitter/filter refreshes separately within each signaling application that needs this functionality, or to integrate it with the NTLP implementation as a generic "soft-state management toolbox". The choice doesn't affect the NTLP specification at all. Implementations might piggyback NTLP soft-state refresh information (if the NTLP works this way) on signaling application messages, or they might even combine soft-state management between layers. The state machines of the NTLP and NSLPs remain logically independent, but an implementation is free to let them interact to reduce the load on the network to the same level that a monolithic model would achieve. Very flexible, very slay 🦋
- It may be helpful for signaling applications to receive state-management related 'triggers' from the NTLP indicating that a peer has failed or become available ("down/up notifications"). These triggers would be about adjacent NTLP peers, rather than signaling application peers. We can consider this another case of route change detection/notification (which the NTLP is also allowed to do anyway). However, apart from generating such triggers, the NTLP takes no action itself on such events, other than to make sure subsequent signaling messages are routed correctly 🧭
- The existence of these triggers doesn't replace NSLP refreshes as the mechanism for maintaining liveness at the signaling application level. So, in this sense, up/down notifications are advisories that allow a faster reaction to events in the network, but they shouldn't be built into NSLP semantics. (This is essentially the same distinction, with the same rationale, that SNMP makes between notifications and normal message exchanges.) Okay, that's a whole vibe check ✨
3.2.6. Path-Decoupled Operation 🦋
Path-decoupled signaling is defined as signaling for state installation along the data path, without the restriction of only passing through nodes that are located on the data path 👀 Signaling messages can be routed to nodes that are off the data path, but that are (presumably) aware of it. This allows a looser coupling between signaling and data plane nodes (e.g., at the autonomous system level). Although path-decoupled operation isn't one of the initial goals of the NSIS work, this section is included for completeness and to capture some early considerations for future reference 🗂️
The main advantages of path-decoupled signaling are ease of deployment and support of additional functionality. The ease of deployment comes from restricting the number of impacted nodes when you deploy or upgrade an NSLP. Path-decoupled signaling would allow, for instance, deploying a solution without upgrading any of the routers in the data plane. Additional functionality that can be supported includes the use of off-path proxies to support authorization or accounting architectures 💖
There are potentially significant differences in how the two signaling paradigms should be analyzed. Using a single centralized off-path NE may increase the requirements in terms of message handling. On the other hand, path-decoupled signaling is equally applicable to distributed off-path entities. Failure recovery scenarios need to be analyzed differently, because fate-sharing between data and control planes can no longer be assumed 😭 Furthermore, the interpretation of sender/receiver orientation becomes less natural. With the local operation of the NTLP, the impact of path-decoupled signaling on the routing of signaling messages is presumably restricted to the problem of peer determination. The assumption that the off-path NSIS nodes are loosely tied to the data path suggests, however, that peer determination can still be based on L3 routing information. This means that a path-decoupled signaling solution could be implemented using a lower-layer protocol that presents the same service interface to NSLPs as the path-coupled NTLP. A new message transport protocol (possibly derived from the path-coupled NTLP) would be needed, but NSLP specifications and the inter-layer interaction would be unchanged from the path-coupled case 🎀
3.3. Signaling Application Properties 💜
It's clear that many signaling applications will need specific protocol behavior in their NSLP. This section outlines some of the options for NSLP behavior. Further work on selecting from these options would depend on a detailed analysis of the signaling application in question 🔍✨
3.3.1. Sender/Receiver Orientation ✨
okay so in some signaling apps, one end of the data flow takes charge of asking the network for special treatment (like a resource reservation) 💅. Which end does it can depend on the app itself, or on how the network is deployed 🎀.
In a sender-initiated approach, the sender of the data flow requests and maintains the treatment for that flow. In a receiver-initiated approach, the receiver of the data flow requests and maintains the treatment for that flow. The NTLP itself has no freedom in this area: Next NTLP peers have to be discovered in the sender-to-receiver direction, but after that the default assumption is that signaling is possible both upstream and downstream (unless a signaling application specifically indicates that this is not required). This implies that backward routing state must be maintained by the NTLP or that backward routing information must be available in the signaling message. 🧚
The sender- and receiver-initiated approaches have several differences in how they operate. The main ones are as follows:
- In a receiver-initiated approach, the signaling messages traveling from the receiver to the sender must be backward routed such that they follow exactly the same path as was followed by the signaling messages belonging to the same flow traveling from the sender to the receiver. In a sender-initiated approach, provided that acknowledgements and notifications can be delivered securely to the sending node, backward routing is not necessary, and nodes do not have to maintain backward routing state. 🦋
- In a sender-initiated approach, a mobile node can initiate a reservation for its outgoing flows as soon as it has moved to another roaming subnetwork. In a receiver-initiated approach, a mobile node has to inform the receiver about its handover, thus allowing the receiver to initiate a reservation for these flows. For incoming flows, the reverse argument applies. 🌸
- In general, setup and modification will be fastest if the node responsible for authorizing these actions can initiate them directly within the NSLP. A mismatch between authorizing and initiating NEs will cause additional message exchanges, either in the NSLP or in a protocol executed prior to NSIS invocation. Depending on how the authorization for a particular signaling application is done, this may favor either sender- or receiver-initiated signaling. Note that this may complicate modification of network control state for existing flows. 💀
3.3.2. Uni- and Bi-Directional Operation 🌈
For some signaling applications and scenarios, signaling may only be considered for a unidirectional data flow. However, in other cases, there may be interesting relationships in the signaling between the two flows of a bi-directional session; an example is QoS for a voice call. Note that the path in the two directions may differ due to asymmetric routing. In the basic case, bi-directional signaling can simply use a separate instance of the same signaling mechanism in each direction. 📞
In constrained topologies where parts of the route are symmetric, it may be possible to use a more unified approach to bi-directional signaling; e.g., carrying the two signaling directions in common messages. This optimization might be used for example to make mobile QoS signaling more efficient. 🫶
In either case, the correlation of the signaling for the two flow directions is carried out in the NSLP. The NTLP would simply be enabled to bundle the messages together. 💜
3.3.3. Heterogeneous Operation 🍓
It is likely that the appropriate way to describe the state for which NSIS is signaling will vary from one part of the network to another (depending on the signaling application). For example, in the QoS case, resource descriptions that are valid for inter-domain links will probably be different from those useful for intra-domain operation (and the latter will differ from one domain to another). 🌍
One way to address this issue is to consider the state description used within the NSLP as carried in globally-understood objects and locally-understood objects. The local objects are only applicable for intra-domain signaling, while the global objects are mainly used in inter-domain signaling. Note that the local objects are still part of the protocol but are inserted, used, and removed by one single domain. 🔥
The purpose of this division is to provide additional flexibility in defining the objects carried by the NSLP such that only the objects applicable in a particular setting are used. One approach for reflecting the distinction is that local objects could be put into separate local messages that are initiated and terminated within one single domain; an alternative is that they could be "stacked" within the NSLP messages that are used anyway for inter-domain signaling. ✨
3.3.4. Aggregation 👑
It is a well-known problem that per-flow signaling in large-scale networks presents scaling challenges because of the large number of flows that may traverse individual nodes. 😭
The possibilities for aggregation at the level of the NTLP are quite limited; the primary scaling approach for path-coupled signaling is for a signaling application to group flows together and to perform signaling for the aggregate, rather than for the flows individually. The aggregate may be created in a number of ways; for example, the individual flows may be sent down a tunnel, or given a common Differentiated Services Code Point (DSCP) marking. The aggregation and de-aggregation points perform per flow signaling, but nodes within the aggregation region should only be forced to process signaling messages for the aggregate. This depends on the ability of the interior nodes to ignore the per-flow signaling as discussed in Section 3.2.3. 🎀
Individual NSLPs will need to specify what aggregation means in their context, and how it should be performed. For example, in the QoS context it is possible to add together the resources specified in a number of separate reservations. In the case of other applications, such as signaling to NATs and firewalls, the feasibility (and even the meaning) of aggregation is less clear. 🙈
3.3.5. Peer-Peer and End-End Relationships 🦋
The assumption in this framework is that the NTLP will operate 'locally'; that is, just over the scope of a single peer relationship. End-to-end operation is built up by concatenating these relationships. Non-local operation (if any) will take place in NSLPs. 🧚
The peering relations may also have an impact on the required amount of state at each NSIS entity. When direct interaction with remote peers is not allowed, it may be required to keep track of the path that a message has followed through the network. This could be achieved by keeping per-flow state at the NSIS entities, as is done in RSVP. Another approach would be to maintain a record route object in the messages; this object would be carried within the NSIS protocols, rather than depend on the route-recording functionality provided by the IP layer. 💅
3.3.6. Acknowledgements and Notifications 💜
We are assuming that the NTLP provides a simple message transfer service, and that any acknowledgements or notifications it generates are handled purely internally (and apply within the scope of a single NTLP peer relationship). 🌸
However, we expect that some signaling applications will require acknowledgements regarding the failure/success of state installation along the data path, and this will be an NSLP function. 🔥
Acknowledgements can be sent along the sequence of NTLP peer relationships towards the signaling initiator, which relieves the requirements on the security associations that need to be maintained by NEs and that can allow NAT traversal in both directions. (If this direction is towards the sender, it implies maintaining reverse routing state in the NTLP.) In certain circumstances (e.g., trusted domains), an optimization could be to send acknowledgements directly to the signaling initiator outside the NTLP (see Section 3.2.2), although any such approach would have to take into account the necessity of handling denial of service attacks launched from outside the network. 🛡️
The semantics of the acknowledgement messages are of particular importance. An NE sending a message could assume responsibility for the entire downstream chain of NEs, indicating (for instance) the availability of reserved resources for the entire downstream path. Alternatively, the message could have a more local meaning, indicating (for instance) that a certain failure or degradation occurred at a particular point in the network. 🌈
Notifications differ from acknowledgements because they are not (necessarily) generated in response to other signaling messages. This means that it may not be obvious how to determine where the notification should be sent. Other than that, the same considerations apply as for acknowledgements. One useful distinction to make would be to differentiate between notifications that trigger a signaling action and others that don't. The security requirements for the latter are less stringent, which means they could be sent directly to the NE they are destined for (provided that this NE can be determined). 🍓
3.3.7. Security and Other AAA Issues 🔐
In some cases, it will be possible to achieve the necessary level of signaling security by using basic 'channel security' mechanisms [11] at the level of the NTLP, and the possibilities are described in Section 4.7. In other cases, signaling applications may have specific security requirements, in which case they are free to invoke their own authentication and key exchange mechanisms and to apply 'object security' to specific fields within the NSLP messages. 🫶
In addition to authentication, the authorization (to manipulate network control state) has to be considered as functionality above the NTLP level, since it will be entirely application specific. Indeed, authorization decisions may be handed off to a third party in the protocol (e.g., for QoS, the resource management function as described in Section 6.1.4). Many different authorization models are possible, and the variations impact:
- what message flows take place -- for example, whether authorization information is carried along with a control state modification request or is sent in the reverse direction in response to it;
- what administrative relationships are required -- for example, whether authorization takes place only between peer signaling applications, or over longer distances.
Because the NTLP operates only between adjacent peers and places no constraints on the direction or order in which signaling applications can send messages, these authorization aspects are left open to be defined by each NSLP. Further background discussion of this issue is contained in [12]. 👑
4. The NSIS Transport Layer Protocol ✨
okay so this section is where we talk about what the NTLP has to do 🫶 it covers the overall functionality it needs, the possible protocol pieces that can live inside the NTLP layer, the addressing modes it can use, and the transport and state management stuff it's assumed to have. it also maps out the interfaces between the NTLP and the layers above and below it, with the identity elements that show up on those interfaces 🧚
btw this isn't trying to design the NTLP or list every possible design option. some options get mentioned as examples, but the real goal is a general look at the required functionality and the issues that come with it 💅
4.1. Internal Protocol Components 🧩
the NTLP includes everything below the signaling application layer and above the IP layer 💖 the functionality it has to have is outlined in Section 3.2.4, with more detail in Sections 3.2.5 and 4.3.
some NTLP functionality could be handled by components running as sublayers inside the NTLP design. for example, if you need specific transport capabilities (like congestion avoidance, retransmission, and security), then existing protocols (like TCP+TLS or DCCP+IPsec) could be brought into the NTLP. this framework neither requires nor rules that out, so it's left open 🦋
if peer-peer addressing (Section 4.2) is used for some messages, then active next-peer discovery will be required within the NTLP so those messages can be explicitly addressed. this could use message exchanges for dynamic peer discovery as a sublayer inside the NTLP. there could also be an interface to external mechanisms that handle this job 🔍
==================== ===========================
^ +------------------+ +-------------------------+
| | | | NSIS Specific Functions |
| | | | .............|
NSIS | | Monolithic | |+----------+. Peer .|
Transport | | Protocol | || Existing |. Discovery .|
Layer | | | || Protocol |. Aspects .|
| | | |+----------+.............|
V +------------------+ +-------------------------+
==================== ===========================
Figure 6: Options for NTLP Structure4.2. Addressing 📬
there are two ways to address a signaling message going between NTLP peers:
- peer-peer: the message is addressed to a neighboring NSIS entity that is known to be closer to the destination NE.
- end-to-end: the message is addressed directly to the flow destination, and an intervening NE intercepts it.
with peer-peer addressing, an NE works out the address of the next NE from the message payload (and maybe from the previous NE too 👀). this only works if the destination NE's address can be derived from what's in the payload, either through some local routing table or through active peer discovery message exchanges. peer-peer addressing naturally supports tunneling messages between NEs, and it works just as well for both the path-coupled and path-decoupled cases 🌸
with end-to-end addressing, the message is addressed to the data flow receiver, and (some of) the NEs along the data path intercept the messages. the routing of these messages should follow exactly the same path as the associated data flow (but see Section 5.1.1 on this point) 🛣️ securing messages sent this way raises some interesting security issues, which are discussed in [2] 😳 also, it's a matter of protocol design what should be used as the source address of the message: the flow source or the signaling source.
it's not possible at this stage to mandate one addressing mode or the other. each one is actually necessary for some parts of NTLP operation: initial discovery of the next downstream peer will usually need end-to-end addressing, while reverse routing will always need peer-peer addressing. for other message types, the choice is a matter of protocol design. the NSLP can't see which mode is used, and the info needed in each case is available from the flow identifier (Section 4.6.1) or from locally stored NTLP state 🎀
4.3. Classical Transport Functions 🚚
the NSIS signaling protocols are responsible for carrying (signaling) data around the network, and that generally needs stuff like congestion management, reliability, and so on 💪 this section talks about how much of that functionality should live inside the NTLP. it doesn't seem to change the basic way the NSLP and NTLP layers relate to each other (like the semantics of the inter-layer interaction). it's more of a question of the overall performance/complexity tradeoff that comes from putting certain functions in each layer ⚖️
heads up: per the discussion at the end of Section 3.2.3, intermediate nodes may want to modify messages in transit even if they don't do full signaling application processing. in that case, not all of the following functionality would be invoked at every intermediate node 👑
the following functionality is assumed to live within the NTLP:
- bundling together small messages (comparable to [13]) can be provided locally by the NTLP as an option, if you want it. it doesn't affect the operation of the network elsewhere. the NTLP should always support unbundling, so you don't have to negotiate the feature as an option (that's the cost it avoids 🙃). the related function of refresh summarization (where objects in a refresh message get replaced with a reference to a previous message identifier) is left to NSLPs, which can do it in a way tuned to the state management needs of the signaling application 🧠 additional transparent compression functionality could be added to the NTLP design later as a local option. note that end-to-end addressed messages for different flows cannot be bundled safely unless the next node on the outgoing interface is known to be NSIS-aware ⚠️
- when needed, message fragmentation should be provided by the NTLP. using IP fragmentation for large messages may lead to reduced reliability and may be incompatible with some addressing schemes, so this functionality should be provided within the NTLP as a service for NSLPs that generate large messages 📦 how the NTLP determines and accommodates Maximum Transmission Unit (MTU) constraints is left as a matter of protocol design. to avoid making intermediate nodes pay the cost of reassembly, the fragmentation scheme used should allow individual fragments to be forwarded independently towards a node hosting an interested NSLP 🧩
- there can be big benefits for signaling applications if state-changing messages are delivered reliably (as introduced in [13] for RSVP; see also the more general analysis of [14]) 🤝 this doesn't change any assumption about NSLPs using soft-state to manage signaling application state, and it leaves the responsibility for detecting and recovering from application layer error conditions in the NSLP. what it does mean is that this functionality doesn't have to be tuned for fast recovery from message loss caused by congestion or corruption in the lower layers, and the NTLP can stop the amplification of message loss rates that fragmentation would otherwise cause 📉 reliable delivery functionality is invoked by the NSLP on a message-by-message basis, and it's always optional to use ✨
- the NTLP should not allow signaling messages to cause congestion in the network (i.e., at the IP layer) 🚫🌊 congestion could be caused by retransmission of lost signaling packets, or by upper layer actions (like a flood of signaling updates to recover from a route change). in some cases, the network can be engineered so signaling can't overload it. in others, the NTLP would have to detect congestion and adapt the rate at which it allows signaling messages to be sent. principles of congestion control in Internet protocols are given in [15] 📚 the NTLP may or may not be able to detect overload in the control plane itself (for example, an NSLP-aware node several NTLP-hops away that can't keep up with the incoming message rate) and report it as a flow-control condition to local signaling applications. however, for both the congestion and overload cases, it's up to the signaling applications themselves to adapt their behavior accordingly 🙌
4.4. Lower Layer Interfaces 🪜
the NTLP talks to the 'lower layers' of the protocol stack to send and receive signaling messages. this framework puts the lower boundary of the NTLP at the IP layer, so the interface to the lower layer is pretty simple 💜
- the NTLP sends raw IP packets
- the NTLP receives raw IP packets. with peer-peer addressing, they've been addressed directly to it. with end-to-end addressing, this is done by intercepting packets that have been marked in some special way (by a special protocol number, or by some option interpreted within the IP layer, such as the router alert option) 🕵️
- the NTLP receives indications from the IP layer (including local forwarding tables and routing protocol state) that give some info about route changes and similar events (see Section 5.1) 🗺️
for correct message routing, the NTLP needs some information about the link and IP layer configuration of the local networking stack. in general, it needs to know how to pick the outgoing interface for a signaling message, and that has to match the interface the corresponding flow will use 🎯 this could be as simple as letting the IP layer handle the message with its own routing table. there's no intention to do anything different from IP routing (for end-to-end addressed messages). however, some hosts let applications bypass routing for their data flows, and NTLP processing has to account for that 🙈 further network layer information would be needed to handle scoped addresses (if such things ever exist) 🌈
configuration of lower-layer operation to handle flows in particular ways is handled by the signaling application 🫧
4.5. Upper Layer Services 🎀
Okay so the NTLP gives transport-layer services to the higher-layer signaling apps, and it does this for two things: sending and receiving signaling messages, and swapping control and feedback info 💅
For sending and receiving messages, two basic control primitives are required:
- Send Message, to allow the signaling application to pass data to the NTLP for transport.
- Receive Message, to allow the NTLP to pass received data to the signaling application.
The NTLP and signaling application may also want to exchange other control information, such as the following:
- Signaling application registration/de-registration, so that particular signaling application instances can register their presence with the transport layer. This may also require some identifier to be agreed upon between the NTLP and signaling application to support the exchange of further control information and to allow the de-multiplexing of incoming data. 🫶
- NTLP configuration, allowing signaling applications to indicate what optional NTLP features they want to use, and to configure NTLP operation, such as controlling what transport layer state should be maintained. ✨
- Error messages, to allow the NTLP to indicate error conditions to the signaling application, and vice versa. 😭
- Feedback information, such as route change indications so that the signaling application can decide what action to take. 🦋
4.6. Identity Elements 🧚
4.6.1. Flow Identification 🌸
The flow identification is a method of identifying a flow in a unique way. All packets associated with the same flow will be identified by the same flow identifier. The key aspect of the flow identifier is to provide enough information such that the signaling flow receives the same treatment along the data path as the actual data itself; i.e., consistent behavior is applied to the signaling and data flows by a NAT or policy-based forwarding engine. It's giving main character energy, honestly 👑
Information that could be used in flow identification may include:
- source IP address;
- destination IP address;
- protocol identifier and higher layer (port) addressing;
- flow label (typical for IPv6);
- SPI field for IPsec encapsulated data; and
- DSCP/TOS field.
It is assumed that at most limited wildcarding on these identifiers is needed.
We assume here that the flow identification is not hidden within the NSLP, but is explicitly part of the NTLP. The justification for this is that being able to do NSIS processing, even at a node which was unaware of the specific signaling application (see Section 3.2.3) might be valuable. An example scenario would be messages passing through an addressing boundary where the flow identification had to be re-written. 💅
4.6.2. Session Identification 💜
There are circumstances in which being able to refer to signaling application state independently of the underlying flow is important. For example, if the address of one of the flow endpoints changes due to a mobility event, it is desirable to be able to change the flow identifier without having to install a completely new reservation. The session identifier provides a method to correlate the signaling about the different flows with the same network control state. This is so iconic 🦋
The session identifier is essentially a signaling application concept, since it is only used in non-trivial state management actions that are application specific. However, we assume here that it should be visible within the NTLP. This enables it to be used to control NTLP behavior; for example, by controlling how the transport layer should forward packets belonging to this session (as opposed to this signaling application). In addition, the session identifier can be used by the NTLP to demultiplex received signaling messages between multiple instances of the same signaling application, if such an operational scenario is supported (see Section 4.6.3 for more information on signaling application identification).
To be useful for mobility support, the session identifier should be globally unique, and it should not be modified end-to-end. It is well known that it is practically impossible to generate identifiers in a way that guarantees this property; however, using a large random number makes it highly likely. In any case, the NTLP ascribes no valuable semantics to the identifier (such as 'session ownership'); this problem is left to the signaling application, which may be able to secure it to be used for this purpose. 🔥
4.6.3. Signaling Application Identification 🍓
Because the NTLP can be used to support several NSLP types, there is a need to identify which type a particular signaling message exchange is being used for. This is to support:
- processing of incoming messages -- the NTLP should be able to demultiplex these towards the appropriate signaling applications; and
- processing of general messages at an NSIS-aware intermediate node -- if the node does not handle the specific signaling application, it should be able to make a forwarding decision without having to parse upper-layer information.
No position is taken on the form of the signaling application identifier, or even the structure of the signaling application 'space': free-standing applications, potentially overlapping groups of capabilities, etc. These details should not influence the rest of the NTLP design. 🌈
4.7. Security Properties 🔐
It is assumed that the only security service required within the NTLP is channel security. Channel security requires a security association to be established between the signaling endpoints, which is carried out via some authentication and key management exchange. This functionality could be provided by reusing a standard protocol.
In order to protect a particular signaling exchange, the NSIS entity needs to select the security association that it has in place with the next NSIS entity that will be receiving the signaling message. The ease of doing this depends on the addressing model in use by the NTLP (see Section 4.2).
Channel security can provide many different types of protection to signaling exchanges, including integrity and replay protection and encryption. It is not clear which of these is required at the NTLP layer, although most channel security mechanisms support them all. It is also not clear how tightly an NSLP can 'bind' to the channel security service provided by the NTLP. 🤔
Channel security can also be applied to the signaling messages with differing granularity; i.e., all or parts of the signaling message may be protected. For example, if the flow is traversing a NAT, only the parts of the message that do not need to be processed by the NAT should be protected. (Alternatively, if the NAT takes part in NTLP security procedures, it only needs to be given access to the message fields containing addresses, often just the flow id.) Which parts of the NTLP messages need protecting is an open question, as is what type of protection should be applied to each. 💀
5. Interactions with Other Protocols ✨
5.1. IP Routing Interactions 🛣️
The NTLP is responsible for determining the next node to be visited by the signaling protocol. For path-coupled signaling, this next node should be one that will be visited by the data flow. In practice, this peer discovery will be approximate, as any node could use any feature of the peer discovery packet to route it differently from the corresponding data flow packets. Divergence between the data and signaling paths can occur due to load sharing or load balancing (Section 5.1.1). An example specific to the case of QoS is given in Section 6.1.1. Route changes cause a temporary divergence between the data path and the path on which signaling state has been installed. The occurrence, detection, and impact of route changes is described in Section 5.1.2. A description of this issue in the context of QoS is given in Section 6.1.2. 🧭
5.1.1. Load Sharing and Policy-Based Forwarding 🎀
Load sharing or load balancing is a network optimization technique that exploits the existence of multiple paths to the same destination in order to obtain benefits in terms of protection, resource efficiency, or network stability. It has been proposed for a number of routing protocols, such as OSPF [16] and others. In general, load sharing means that packet forwarding will take into account header fields in addition to the destination address; a general discussion of such techniques and the problems they cause is provided in [17].
The significance of load sharing in the context of NSIS is that routing of signaling messages using end-to-end addressing does not guarantee that these messages will follow the data path. Policy-based forwarding for data packets -- where the outgoing link is selected based on policy information about fields additional to the packet destination address -- has the same impact. Signaling and data packets may diverge because of both of these techniques. 🔀
If signaling packets are given source and destination addresses identical to data packets, signaling and data may still diverge because of layer-4 load balancing (based on protocol or port). Such techniques would also cause ICMP errors to be misdirected to the source of the data because of source address spoofing. If signaling packets are made identical in the complete 5-tuple, divergence may still occur because of the presence of router alert options. The same ICMP misdirection applies, and it becomes difficult for the end systems to distinguish between data and signaling packets. Finally, QoS routing techniques may base the routing decision on any field in the packet header (e.g., DSCP). 😭
5.1.2. Route Changes
Okay so in a connectionless network, every packet gets routed on its own based on its header info 🎀. Whenever a better route to the destination shows up, it gets installed in the forwarding table and used for all the subsequent (data and signaling) packets 🦋. This can cause a divergence between the path where state got installed and the path where forwarding actually happens 💀. Route pinning helps with this! Route pinning means certain data packets take a path that doesn't depend on reachability changes from routing updates from an Interior Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP) ✨. Nothing about NSIS signaling stops route pinning from being used as a network engineering technique, as long as it's done in a way that keeps the routing of signaling and data the same 🫶. Even so, route pinning can't be depended on to prevent every route change (like when a link fails) 😭.
Handling route changes needs three processes in the signaling protocol 👑:
- route change detection
- installation of state on the new path
- removal of state on the old path
There are lots of ways to detect a route change 🔍. Some need explicit protocol support, and some happen inside the implementation itself. They differ in how fast they react and in what kinds of change they can spot. Roughly in order of increasing applicability, they go like this:
- monitoring changes in local forwarding table state
- monitoring topology changes in a link-state routing protocol
- inference from changes in data packet TTL
- inference from loss of packet stream in a flow-aware router
- inference from changes in signaling packet TTL
- changed route of an end-to-end addressed signaling packet
- changed route of a specific end-to-end addressed probe packet
These methods can be sorted into groups: network monitoring (methods 1-2), data packet monitoring (methods 3-4), and monitoring signaling protocol messages (methods 5-7). Method 6 is the baseline method of RSVP 🌸. The network monitoring methods can only detect local changes. In particular, method 1 can only detect an event that changes the immediate next downstream hop, and method 2 can only detect changes within the scope of the link-state protocol 🙈. Methods 5-7 depend on monitoring signaling messages, so they get less effective as soft-state refresh rates go down 📉.
When a route change has been detected, it's important that state gets installed along the new path as quickly as possible ⚡. The new path isn't guaranteed to offer the same characteristics that the old path had, so that's a whole thing. To avoid duplicate state installation or, worse, having the signaling message rejected because of state that's already installed, it's important to recognize the new signaling message as belonging to an existing session 💜. Here's the distinction: route changes with a change of the flow identification (for example, in a mobility event where the IP source might change) and route changes without a change of the flow identification (for example, a link failure along the path) 🧚. The former case needs an identifier that's independent from the flow identification, which is the session identifier (Section 4.6.2). Mobility issues get a deeper dive in Section 5.2 🌈.
Once state has been installed along the new path, the existing state on the old path needs to be removed 🧹. With the soft-state principle, this happens automatically because the refresh messages stop coming. Depending on the refresh timer, though, it might be necessary to tear down that state much faster (for example, because it's tied to an accounting record) 💅. In that case, the teardown message needs to be able to tell the new path apart from the old path.
In some environments, it's desirable to provide connectivity and per-flow or per-class state management with high-availability characteristics, meaning rapid transparent recovery even when route changes happen 🛡️. This may require interacting with protocols used to manage routing in that situation, such as the Virtual Router Redundancy Protocol (VRRP) [18] 🍓.
Our basic assumption about these interactions is that the NTLP would be responsible for detecting the route change and making sure signaling messages get re-routed consistently, the same way as the data traffic 🫶. However, further state re-synchronization (including failover between 'main' and 'standby' nodes in the high-availability case) is the job of the signaling application and its NSLP, and it could possibly be triggered by the NTLP 🔥.
5.2. Mobility and Multihoming Interactions
Mobility and multihoming are basically a generalization of the basic route change case from the previous section 🦋. On top of the fact that packets for a given session are no longer traveling over a single topological path, the following extra considerations come up 👀:
- The use of IP-layer mobility and multihoming means that more than one IP source or destination address will be associated with a single session. The same applies if application-layer solutions (e.g., SIP-based approaches) are used.
- Mobile IP and associated protocols use some special encapsulations for some segments of the data path.
- The double route may persist for some time in the network (e.g., in the case of a 'make-before-break' handover being done by a multihomed host).
- Conversely, the re-routing may be rapid and routine (unlike network-internal route changes), which increases the importance of rapid state release on old paths 🏃♀️.
The interactions between mobility and signaling have been analyzed extensively in recent years 📚, mainly in the context of RSVP and Mobile IP interaction (e.g., the mobility discussion of [5]), but also in that of other types of network (e.g., [19]). A general review of the fundamental interactions is given in [20], which goes into more detail on many of the subjects covered in this section 🌟.
We assume that the signaling will refer to 'outer' IP headers when defining the flows it is controlling 🎀. There are two main reasons for this. The first is that the data plane will usually be unable to work in terms of anything else when implementing per-flow treatment (e.g., we can't expect a router to analyze inner headers to decide how to schedule packets) 🙅♀️. The second reason is that we're implicitly relying on the security provided by the network infrastructure to make sure the correct packets get the special treatment being signaled for, and this is built on the relationship between packet source and destination addresses and network topology 🔐. (This is essentially the same approach used as the basis of route optimization security in Mobile IPv6 [21] 💖.) The consequence is that we see the packet streams to (or from) different addresses as different flows. Where a flow is carried inside a tunnel, it's seen as a different flow again 🧁. The encapsulation issues (point (2) above) are therefore handled the same way as other tunneling cases (Section 5.4).
So the most critical aspect is that multiple flows are being used, and the signaling for them needs to be correlated 🔗. This is the intended role of the session identifier (see Section 4.6.2, which also describes some of the security requirements for such an identifier) 🔑. Although the session identifier is visible at the NTLP, the signaling application is responsible for doing the correlation (and for doing it securely) 🛡️. The NTLP's responsibility is limited to delivering the signaling messages for each flow between the correct signaling application peers 📬. The locations where correlation takes place are the end system and the signaling-application-aware node in the network where the flows meet. (This node is generally referred to as the "crossover router"; it can be anywhere in the network 🗺️.)
Although a lot of work has been done in the past on finding the crossover router directly from information held in particular mobility signaling protocols, the initial focus of NSIS work should be a solution that isn't tightly bound to any single mobility approach 🧩. In other words, it should be possible to determine the crossover router based on NSIS signaling. (This doesn't rule out that some implementations may be able to do this discovery faster, e.g., by being tightly integrated with local mobility management protocols. That's directly comparable to spotting route changes in fixed networks by being routing aware 🧠.)
Note that crossover router discovery may involve end-to-end signaling exchanges (especially for flows towards the mobile or multihomed node), which raises a latency concern ⏱️. On the other hand, end-to-end signaling will have been necessary in any case, at the application level, not only to communicate changed addresses but also to update packet classifiers along the path 📡. How these exchanges could be combined or carried out in parallel is a matter for further analysis 🔬.
On the shared part of the path, signaling is needed at least to update the packet classifiers to include the new flow 🧾. If correlation with the existing flow is possible, though, it should be possible to bypass any policy or admission control processing 🌷. State installation on the new path (and possibly release on the old one) is also required 💫. Which entity controls all these procedures (one of the end hosts or the crossover router) depends on which entities are authorized to carry out network state manipulations, so it's a matter of signaling application and NSLP design 🎭. The approach may depend on the sender/receiver orientation of the original signaling (see Section 3.3.1). In addition, in the mobility case, the old path may no longer be directly accessible to the mobile node, so inter-access-router communication may be required to release state in these circumstances 📶.
The frequency of handovers in some network types makes fast handover support protocols desirable 🏎️. These are useful for selecting the optimal access router for handover (for example, [22]) and for transferring state information so it doesn't have to be regenerated in the new access router after handover (for example, [23]) 🎁. Both of these procedures could have strong interactions with signaling protocols 💞. The access router selection might depend on the network control state that could be supported on the path through the new access router. Transfer of signaling application state or NTLP/NSLP protocol state may be a candidate for context transfer ✨.
5.3. Interactions with NATs 🦋
Okay bestie, so messages almost always carry addresses, and sometimes higher-layer info in the payload too. That means we have to think about NATs (address translation devices) 💅 These considerations cover 'traditional' NATs of various types (as defined in [24]) and also some IPv4/v6 transition mechanisms, like Stateless IP/ICMP Translation (SIIT) [25] ✨
Simplest case: there's an NSIS-unaware NAT in the path. The payloads will be uncorrected, and the signaling will refer to the flow incorrectly 💀 Apps could try STUN [26] or similar techniques to detect and recover from the NAT. Even then, NSIS protocols would have to use a well-known encapsulation (TCP/UDP/ICMP) so they don't get dropped by the more cautious low-end NAT devices 🙈
A simple 'NSIS-aware' NAT would need the flow identification info to be in the clear and not integrity protected. An alternative way to think about it is treating the NAT function as part of message processing itself. Then the translating node can take part natively in any NSIS protocol security mechanisms 🔥 Depending on how the NSIS protocol layers are set up, this processing could happen in an NSIS entity that doesn't know anything about any particular signaling application. This is the reason basic flow identification info is included in the NTLP (Section 4.6.1) 🎀
Note that all of this is independent of using a specific NSLP for general control of NATs (and firewalls). That case is covered in Section 6.2 🌸
5.4. Interactions with IP Tunneling 🧚
Tunneling is everywhere on the Internet, bestie 🌈 It's used for flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual private networking, and so on. An NSIS solution has to keep working when these techniques are in play. The tunnel shouldn't cause problems for end-to-end signaling, and it should also be possible to use NSIS signaling to control how the tunneled packets get treated ✨
The assumption is that the NSIS approach will be similar to that of [27], where the signaling for the end-to-end data flow gets tunneled along with that data flow and is invisible to nodes along the tunnel's path (other than the endpoints) 🦋 This gives backwards compatibility with networks where the tunnel endpoints don't support the NSIS protocols. We assume NEs will not unwrap tunnel encapsulations to find and process tunneled signaling messages 🙈
To signal for the packets carrying the tunneled data, the tunnel is treated as a brand-new data flow in its own right, and NSIS signaling gets applied to it recursively 💜 This needs signaling support in at least one tunnel endpoint. In some cases (where the signaling initiator is at the opposite end of the data flow from the tunnel initiator, i.e., receiver initiated signaling), you need to be able to bind the original flow identification to the one for the tunneled flow. It's left open here whether this should be an NTLP or an NSLP function 🤷♀️
6. Signaling Applications 👑
This section gives an overview of NSLPs for particular signaling applications. The assumption is that the NSLP uses the generic functionality of the NTLP we covered earlier, and this section describes the specific bits of NSLP operation 💖 It includes simple examples to make it clear how NSLPs fit into the framework. It does not replace or even form part of the formal NSLP protocol specifications. Initial designs are being developed for NSLPs for resource reservation [28] and middlebox communication [29], so stay tuned 👀
6.1. Signaling for Quality of Service ⭐
For QoS signaling, all the basic NSIS concepts from Section 3.1 apply. On top of that, the signaling process has an assumed directionality: one end of the signaling flow takes responsibility for actually requesting the resource 🍓 That leads to these definitions:
- QoS NSIS Initiator (QNI): the signaling entity that makes the resource request, usually as a result of a user application request.
- QoS NSIS Responder (QNR): the signaling entity that acts as the endpoint for the signaling and that can optionally interact with applications as well.
- QoS NSIS Forwarder (QNF): a signaling entity between a QNI and QNR that propagates NSIS signaling further through the network.
Each of these entities interacts with a resource management function (RMF) that actually allocates network resources (router buffers, interface bandwidth, and so on) 🌸
Also, there's no constraint on which end of the signaling flow takes the QNI role. With respect to the data flow direction, it could be the sending or the receiving end. Iconic flexibility 💅
6.1.1. Protocol Message Semantics 💌
The QoS NSLP will include a set of messages to carry out resource reservations along the signaling path. A possible set of message semantics for the QoS NSLP is shown below. Note that the 'direction' column in the table only indicates the 'orientation' of the message. Messages can be originated and absorbed at QNF nodes as well as at the QNI or QNR. An example might be QNFs at the edge of a domain exchanging messages to set up resources for a flow across a it 🧚 Also, it's left open whether the responder can release or modify a reservation, during or after setup. This seems mainly to be a matter of assumptions about authorization, and the possibilities might depend on resource type specifics 🤔
The table also explicitly includes a refresh operation. This does nothing to a reservation except extend its lifetime, and it's one possible state management mechanism (see next section) ✨
+-----------+-----------+-------------------------------------------+
| Operation | Direction | Operation |
+-----------+-----------+-------------------------------------------+
| Request | I-->R | Create a new reservation for a flow |
| | | |
| Modify | I-->R | Modify an existing reservation |
| | (&R-->I?) | |
| | | |
| Release | I-->R | Delete (tear down) an existing |
| | (&R-->I?) | reservation |
| | | |
| Accept/ | R-->I | Confirm (possibly modified?) or reject a |
| Reject | | reservation request |
| | | |
| Notify | I-->R & | Report an event detected within the |
| | R-->I | network |
| | | |
| Refresh | I-->R | State management (see Section 6.1.2) |
+-----------+-----------+-------------------------------------------+6.1.2. State Management 🌈
The primary purpose of NSIS is to manage state information along the path a data flow takes 🦋 The state management issues within the NTLP (state related to message transport) are described in Section 4. The QoS NSLP will typically have to handle additional state related to the desired resource reservation to be made 💜
There are two critical issues to think about when building a robust NSLP to handle this problem 🔥
- The protocol must be scalable. It should allow minimization of the resource reservation state-storage demands it implies for intermediate nodes. In particular, storing state per 'micro' flow is likely to be impossible except at the very edge of the network 😭 A QoS signaling application might need per-flow or lower granularity state. Examples of each for QoS would be IntServ [30] or RMD [31] (per 'class' state), respectively.
- The protocol must be robust against failure and other conditions that imply the stored resource reservation state has to be moved or removed 🫶
For resource reservations, soft-state management is typically used as a general robustness mechanism 🍓 According to the discussion in Section 3.2.5, the soft-state protocol mechanisms are built into the NSLP for the specific signaling application that needs them. The NTLP just sees this as a sequence of (presumably identical) messages ✨
6.1.3. Route Changes and QoS Reservations ✨
okay so this section is about how resource signaling and routing updates vibe with each other (and the precise source of those routing updates doesn't matter, bestie 💅). normal NSIS operation ends up looking like Figure 7, where the reserved resources line up perfectly with the data path 🫶
reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF |
+-----+ +-----+
--------------------------------------->
data path
Figure 7: Normal NSIS Protocol Operationa route change can totally happen while a reservation is already in place 😭 when that happens, the route change gets installed immediately and any data gets forwarded on the new path. this is the situation shown in Figure 8.
here's the tea: resource reservation on the new path doesn't start until the next control message gets routed along that new path. so for a little while, certain parts of the data path just aren't reserved 💀 and delay- or drop-sensitive apps need that gap to be as short as possible. there are a few techniques people could consider. as an example, RSVP [7] has the concept of local repair, where a router can get triggered by a route change. in that case the RSVP node can start sending PATH messages right after the route has changed 🦋. heads up though, this option might not be available if no per-flow state is kept in the QNF. another approach would be to pre-install backup state, and it would be the QoS-NSLP's job to do that. BUT mechanisms for identifying backup paths and routing the necessary signaling messages along them aren't currently considered in the NSIS requirements and framework 🙈
Route update
|
v
reserved +-----+ reserved +-----+
=========>| QNF |===========>| QNF |
+-----+ +-----+
-------- ||
\ || +-----+
| ===========>| QNF |
| +-----+
+--------------------------->
data path
Figure 8: Route Changethe new path might not be able to give the same guarantees the old one did 😬 so it might be desirable for the QNF to wait until resources have been reserved on the new path before letting the route change get installed (unless, obviously, the old path no longer exists). however, holding up the route change installation while waiting for reservation setup needs careful analysis of how it interacts with the routing protocol being used, so you don't end up with routing loops 🌀
another route-change example is called severe congestion, and it's explained in [31]. this one adapts to a route change when that route change creates congestion on the new routed path ✨
6.1.4. Resource Management Interactions
the QoS NSLP itself isn't involved in any specific resource allocation or management techniques 🎀 but defining an NSLP for resource reservation with Quality of Service does imply the notion of admission control. for a QoS NSLP, the measure of signaling success is being able to reserve resources from the total resource pool that's provisioned in the network. we call the function responsible for allocating that pool the Resource Management Function (RMF). the RMF handles all the resource provisioning, monitoring, and assurance functions in the network 👑
a QoS NSLP relies on the RMF to do resource management and to provide inputs for admission control. in this model the RMF acts like a server towards the client NSLP(s). note, though, that the RMF may in turn use another NSLP instance to do the actual resource provisioning in the network. in that case the RMF acts as the initiator (client) of an NSLP 🧚
this basically corresponds to a multi-level signaling paradigm, with an 'upper' level handling internetworking QoS signaling (possibly running end-to-end) and a 'lower' level handling the more specialized intra-domain QoS signaling (running between just the edges of the network). (See [10], [32], and [33] for a discussion of similar architectures.) since NSIS signaling is already supposed to be able to support multiple instances of NSLPs for a given flow and for limited-scope (e.g., edge-to-edge) operation, it's not currently clear that supporting the multi-level model leads to any new protocol requirements for the QoS NSLP 🤔
the RMF may or may not be co-located with a QNF (and co-location with a QNI/QNR can be handled logically as a combination between QNF and QNI/QNR). to cater for both cases, we define a (possibly logical) QNF-RMF interface. over this interface, information may be provided from the RMF about monitoring, resource availability, topology, and configuration. in the other direction, the interface may be used to trigger requests for resource provisioning. one way to formalize the interface between the QNF and the RMF is via a Service Level Agreement (SLA). the SLA may be static, or it may be dynamically updated by means of a negotiation protocol. that protocol is outside the scope of NSIS 💅
there's no assumed restriction on where the RMF is placed. it could be a centralized RMF per domain, several off-path distributed RMFs, or an on-path RMF per router. the advantages and disadvantages of both approaches are well-known. centralization typically allows decisions to be taken using more global information, with more efficient resource utilization as a result. it also facilitates deployment or upgrade of policies. distribution allows local decision processes and rapid response to data path changes ⭐
6.2. Other Signaling Applications
so yeah, as well as the use for 'traditional' QoS signaling, it should be possible to develop NSLPs for other signaling applications that operate on different types of network control state 🌈 one specific case is setting up flow-related state in middleboxes (firewalls, NATs, and so on). requirements for that kind of communication are given in [4]. other examples include network monitoring and testing, and tunnel endpoint discovery 🍓
7. Security Considerations 🔥
okay bestie, this part is SERIOUS, so read it carefully 😭 this document describes a framework for signaling protocols that assumes a two-layer decomposition, with a common lower layer (NTLP) supporting a family of signaling-application-specific upper-layer protocols (NSLPs). the overall security considerations for the signaling therefore depend on the joint security properties assumed or demanded for each layer.
security for the NTLP is discussed in Section 4.7. we've assumed that, apart from being resistant to denial of service attacks against itself, the main role of the NTLP will be to provide message protection over the scope of a single peer relationship, between adjacent signaling application entities. (See Section 3.2.3 for a discussion of the case where these entities are separated by more than one NTLP hop.) these functions can ideally be provided by an existing channel security mechanism, preferably using an external key management mechanism based on mutual authentication. examples of possible mechanisms are TLS, IPsec and SSH. however, there are interactions between the actual choice of security protocol and the rest of the NTLP design. mainly, most existing channel security mechanisms require explicit identification of the peers involved at the network and/or transport level. this clashes with those aspects of path-coupled signaling operation (e.g., discovery) where this information isn't even implicitly available because peer identities are unknown. the impact of this 'next-hop problem' on RSVP design is discussed in the security properties document [6], and it also influences many parts of the threat analysis [2]. so, this framework does not mandate the use of any specific channel security protocol. instead, this has to be integrated with the design of the NTLP as a whole 🫶
security for the NSLPs is entirely dependent on signaling application requirements. in some cases, no additional protection may be required compared to what is provided by the NTLP. in other cases, more sophisticated object-level protection and the use of public-key-based solutions may be required. on top of that, the NSLP needs to consider the authorization requirements of the signaling application. authorization is a complex topic, for which a very brief overview is provided in Section 3.3.7 👑
another factor is that NTLP security mechanisms operate only locally, whereas NSLP mechanisms may also need to operate over larger regions (not just between adjacent peers), especially for authorization aspects. this complicates the analysis of basing signaling application security on NTLP protection 😬
an additional concern for signaling applications is the session identifier security issue (Sections 4.6.2 and 5.2). the purpose of this identifier is to decouple session identification (as a handle for network control state) from session "location" (i.e., the data flow endpoints). the identifier/locator distinction has been extensively discussed in the user plane for end-to-end data flows, and it is known to lead to non-trivial security issues in binding the two together again. our problem is the analogue in the control plane, and it is at least similarly complex, because of the need to involve nodes in the interior of the network as well 💀
further work on this and other security design will depend on a refinement of the NSIS threats work begun in [2] 🔥
8. References ✨
8.1. Normative References
- [1] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004.
- [2] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
- [3] Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3583, September 2003.
- [4] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002.
8.2. Informative References 📚✨
okay so this is the reading list bit, bestie 🤓 these are all the RFCs and drafts the spec leans on for background. the "Work in Progress" ones are still drafts, so heads up on those 💅
[5] Manner, J. and X. Fu, "Analysis of Existing Quality of Service Signaling Protocols", Work in Progress, December 2004.
[6] Tschofenig, H., "RSVP Security Properties", Work in Progress, February 2005.
[7] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[9] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[10] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[11] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[12] Tschofenig, H., "NSIS Authentication, Authorization and Accounting Issues", Work in Progress, March 2003.
[13] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[14] Ji, P., Ge, Z., Kurose, J., and D. Townsley, "A Comparison of Hard-State and Soft-State Signaling Protocols", Computer Communication Review, Volume 33, Number 4, October 2003.
[15] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[16] Apostolopoulos, G., Kamat, S., Williams, D., Guerin, R., Orda, A., and T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC 2676, August 1999.
[17] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[18] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.
[19] Heijenk, G., Karagiannis, G., Rexhepi, V., and L. Westberg, "DiffServ Resource Management in IP-based Radio Access Networks", Proceedings of 4th International Symposium on Wireless Personal Multimedia Communications WPMC'01, September 9 - 12 2001.
[20] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth, E., and Y. Khouaja, "Evaluation of Mobility and QoS Interaction", Computer Networks Volume 38, Issue 2, p. 137-163, 5 February 2002.
[21] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[22] Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", Work in Progress, May 2005.
[23] Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002.
[24] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[25] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[26] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[27] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[28] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service signaling", Work in Progress, February 2005.
[29] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, February 2005.
[30] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[31] Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., Partain, D., Pop, O., Rexhepi, V., Szabo, R., and A. Takacs, "Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview", Seventh International Workshop on Protocols for High-Speed networks PfHSN 2002, 22 - 24 April 2002.
[32] Ferrari, D., Banerjea, A., and H. Zhang, "Network Support for Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92-072, November 1992.
[33] Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999.
Appendix A. Contributors 🌷
okay shoutout time 🥹 parts of the intro sections (specifically Sections 3.1 and 3.3) are based on contributions from Ilya Freytsis, who was at Cetacean Networks, Inc. at the time 💜
and Bob Braden originally proposed "A Two-Level Architecture for Internet Signalling" as an Internet-Draft in November 2001. that proposal was a huge starting point for the framework in here, so the authors owe Bob a massive debt of gratitude 🙌
Appendix B. Acknowledgements 🫶
the authors thanked Bob Braden, Maarten Buchli, Eleanor Hepworth, Andrew McDonald, Melinda Shore, and Hannes Tschofenig for big contributions in specific areas 👑
they also gave a shoutout to a whole squad of people for insights and input during this and earlier framework work: Cedric Aoun, Attila Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness, Xiaoming Fu, Ruediger Geib, Danny Goderis, Kim Hui, Cornelia Kappler, Sung Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De Neve, Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne, Tom Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars Westberg, and Lixia Zhang 🌸
and finally, Dave Oran, Michael Richardson, and Alex Zinin gave super valuable comments during the final review stages 💖
Authors' Addresses 🗺️
Here's where you can find the authors. Their contact details are kept exactly as written:
Robert Hancock
Siemens/Roke Manor Research
Old Salisbury Lane
Romsey, Hampshire SO51 0ZN
UK
EMail: robert.hancock@roke.co.uk
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE Enschede
The Netherlands
EMail: g.karagiannis@ewi.utwente.nl
John Loughney
Nokia Research Center
11-13 Itamerenkatu
Helsinki 00180
Finland
EMail: john.loughney@nokia.com
Sven Van den Bosch
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen
Belgium
EMail: sven.van_den_bosch@alcatel.beFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🔐
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society.
bestie, that's the whole thing! 🎀🦋 we made it to the end of RFC 4080 ✨ you're officially a QoS-signaling legend now 👑
📦 where this page comes from
- ietf: rfc4080 2005-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms