RFC 3726
Requirements for Signaling Protocols
Requirements for Signaling Protocols 🎀
Okay bestie, let's start with the title block 💖 This one is RFC 3726, called Requirements for Signaling Protocols. It was written by M. Brunner (listed as editor, "Ed.") from NEC. It's marked as Informational and dated April 2004 🌸 The title block doesn't list any RFCs that it obsoletes or updates, so it's standing completely on its own ✨
Status of this Memo 🧚
Real talk, this memo is information only for the Internet community 💅 It does not specify an Internet standard of any kind, so nobody's getting a standards badge from this one. Distribution is unlimited, so share it with everyone 🌈
Copyright Notice 📝
The Internet Society holds the copyright on this document (2004), and all rights are reserved 🔒
Abstract 🦋
This doc sets out the requirements for signaling across different network environments, like when you're crossing administrative or technology domains. Signaling is mostly thought of as a way to handle Quality of Service (Qos), with the Resource Reservation Protocol (RSVP) as the famous example. But lately signaling has gone way beyond QoS. Two examples are signaling for label distribution in Multiprotocol Label Switching (MPLS), and signaling to middleboxes. To make the requirements useful everywhere, the authors start from a whole bunch of different scenarios and use cases, covering lots of network types and app interactions. The doc lays out its assumptions first, then lists the requirements. Those requirements are grouped by areas: architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility ✨
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement and Scope. . . . . . . . . . . . . . . . . . 6
4. Assumptions and Exclusions . . . . . . . . . . . . . . . . . . 8
4.1. Assumptions and Non-Assumptions. . . . . . . . . . . . . 8
4.2. Exclusions . . . . . . . . . . . . . . . . . . . . . . . 9
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Architecture and Design Goals. . . . . . . . . . . . . . 11
5.1.1. NSIS SHOULD Provide Availability Information
on Request . . . . . . . . . . . . . . . . . . . 11
5.1.2. NSIS MUST be Designed Modularly. . . . . . . . . 11
5.1.3. NSIS MUST Decouple Protocol and Information. . . 12
5.1.4. NSIS MUST Support Independence of Signaling and
Network Control Paradigm . . . . . . . . . . . . 12
5.1.5. NSIS SHOULD be Able to Carry Opaque Objects. . . 12
5.2. Signaling Flows. . . . . . . . . . . . . . . . . . . . . 12
5.2.1. The Placement of NSIS Initiator, Forwarder, and
Responder Anywhere in the Network MUST be
Allowed. . . . . . . . . . . . . . . . . . . . . 12
5.2.2. NSIS MUST Support Path-Coupled and MAY Support
Path-Decoupled Signaling . . . . . . . . . . . . 13
5.2.3. Concealment of Topology and Technology
Information SHOULD be Possible . . . . . . . . . 13
5.2.4. Transparent Signaling Through Networks SHOULD be
Possible . . . . . . . . . . . . . . . . . . . . 13
5.3. Messaging. . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Explicit Erasure of State MUST be Possible . . . 13
5.3.2. Automatic Release of State After Failure MUST be
Possible . . . . . . . . . . . . . . . . . . . . 14
5.3.3. NSIS SHOULD Allow for Sending Notifications
Upstream . . . . . . . . . . . . . . . . . . . . 14
5.3.4. Establishment and Refusal to set up State MUST
be Notified. . . . . . . . . . . . . . . . . . . 15
5.3.5. NSIS MUST Allow for Local Information Exchange . 15
5.4. Control Information. . . . . . . . . . . . . . . . . . . 16
5.4.1. Mutability Information on Parameters SHOULD be
Possible . . . . . . . . . . . . . . . . . . . . 16
5.4.2. It SHOULD be Possible to Add and Remove Local
Domain Information . . . . . . . . . . . . . . . 16
5.4.3. State MUST be Addressed Independent of Flow
Identification . . . . . . . . . . . . . . . . . 16
5.4.4. Modification of Already Established State SHOULD
be Seamless. . . . . . . . . . . . . . . . . . . 16
5.4.5. Grouping of Signaling for Several Micro-Flows
MAY be Provided. . . . . . . . . . . . . . . . . 17
5.5. Performance. . . . . . . . . . . . . . . . . . . . . . . 17
5.5.1. Scalability. . . . . . . . . . . . . . . . . . . 17
5.5.2. NSIS SHOULD Allow for Low Latency in Setup . . . 18
5.5.3. NSIS MUST Allow for Low Bandwidth Consumption
for the Signaling Protocol . . . . . . . . . . . 18
5.5.4. NSIS SHOULD Allow to Constrain Load on Devices . 18
5.5.5. NSIS SHOULD Target the Highest Possible Network
Utilization. . . . . . . . . . . . . . . . . . . 18
5.6. Flexibility. . . . . . . . . . . . . . . . . . . . . . . 19
5.6.1. Flow Aggregation . . . . . . . . . . . . . . . . 19
5.6.2. Flexibility in the Placement of the NSIS
Initiator/Responder. . . . . . . . . . . . . . . 19
5.6.3. Flexibility in the Initiation of State Change. . 19
5.6.4. SHOULD Support Network-Initiated State Change. . 19
5.6.5. Uni / Bi-directional State Setup . . . . . . . . 20
5.7. Security . . . . . . . . . . . . . . . . . . . . . . . . 20
5.7.1. Authentication of Signaling Requests . . . . . . 20
5.7.2. Request Authorization. . . . . . . . . . . . . . 20
5.7.3. Integrity Protection . . . . . . . . . . . . . . 20
5.7.4. Replay Protection. . . . . . . . . . . . . . . . 21
5.7.5. Hop-by-Hop Security. . . . . . . . . . . . . . . 21
5.7.6. Identity Confidentiality and Network Topology
Hiding . . . . . . . . . . . . . . . . . . . . . 21
5.7.7. Denial-of-Service Attacks. . . . . . . . . . . . 21
5.7.8. Confidentiality of Signaling Messages. . . . . . 22
5.7.9. Ownership of State . . . . . . . . . . . . . . . 22
5.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 22
5.8.1. Allow Efficient Service Re-Establishment After
Handover . . . . . . . . . . . . . . . . . . . . 22
5.9. Interworking with Other Protocols and Techniques . . . . 22
5.9.1. MUST Interwork with IP Tunneling . . . . . . . . 22
5.9.2. MUST NOT Constrain Either to IPv4 or IPv6. . . . 23
5.9.3. MUST be Independent from Charging Model. . . . . 23
5.9.4. SHOULD Provide Hooks for AAA Protocols . . . . . 23
5.9.5. SHOULD work with Seamless Handoff Protocols. . . 23
5.9.6. MUST Work with Traditional Routing . . . . . . . 23
5.10. Operational. . . . . . . . . . . . . . . . . . . . . . . 23
5.10.1. Ability to Assign Transport Quality to Signaling
Messages . . . . . . . . . . . . . . . . . . . . 23
5.10.2. Graceful Fail Over . . . . . . . . . . . . . . . 24
5.10.3. Graceful Handling of NSIS Entity Problems. . . . 24
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 24
8. Appendix: Scenarios/Use Cases. . . . . . . . . . . . . . . . . 26
8.1. Terminal Mobility. . . . . . . . . . . . . . . . . . . . 26
8.2. Wireless Networks. . . . . . . . . . . . . . . . . . . . 28
8.3. An Example Scenario for 3G Wireless Networks . . . . . . 29
8.4. Wired Part of Wireless Network . . . . . . . . . . . . . 31
8.5. Session Mobility . . . . . . . . . . . . . . . . . . . . 33
8.6. QoS Reservation/Negotiation from Access to Core Network. 34
8.7. QoS Reservation/Negotiation Over Administrative
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 34
8.8. QoS Signaling Between PSTN Gateways and Backbone Routers 35
8.9. PSTN Trunking Gateway. . . . . . . . . . . . . . . . . . 36
8.10. An Application Requests End-to-End QoS Path from the
Network. . . . . . . . . . . . . . . . . . . . . . . . . 38
8.11. QOS for Virtual Private Networks . . . . . . . . . . . . 39
8.11.1. Tunnel End Points at the Customer Premises . . . 39
8.11.2. Tunnel End Points at the Provider Premises . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Normative References . . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . . 40
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 421. Introduction 🌟
This doc comes from the Next Steps in Signaling (NSIS) Working Group 🫶 It defines requirements for signaling across different network environments. It does not list any problems with existing signaling protocols, like [RSVP].
To figure out what signaling requirements should be, you first need to know where they apply 🎯 So the doc lists use cases and scenarios where an NSIS protocol could be used. Those scenarios help derive the requirements, and they're also how you test the requirements against real use cases 💅
The requirements don't depend on any particular application ✨ Still, resource reservation and QoS issues get used as examples throughout the text. QoS isn't the only place signaling shows up on the Internet though, obviously 🙄 Signaling can also work as a communication protocol that sets up and maintains state in middleboxes [RFC3234] 🔥
One last thing: this doc doesn't cover requirements for some networking areas, especially interaction with host and site multihoming. Those are left for future analysis 🧚
1.1. Keywords 🔑
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [KEYWORDS] 💜
2. Terminology ✨
okay so bestie, this section is basically our glossary 📖 These are the terms that pop up the most in the doc. Real talk though, they can't be made fully precise until there's a more complete architectural model, and they're not trying to prescribe any solution. Where it makes sense, the protocol docs will define them properly 💅
- NSIS Entity (NE): the function inside a node that runs an NSIS protocol 🧚 For path-coupled signaling, the NE is always on the data path, no exceptions.
- NSIS Forwarder (NF): an NSIS Entity sitting between an NI and an NR 🦋 It might poke at local state management functions in the network, and it also passes NSIS signaling further along the network.
- NSIS Initiator (NI): an NSIS Entity that kicks off NSIS signaling to set up or change network state 🚀
- NSIS Responder (NR): an NSIS Entity that ends NSIS signaling and can optionally chat with applications too 🫶
- Flow: a traffic stream (a sequence of IP packets between two end systems) that gets a specific packet-level treatment 🌊 A flow can be unicast (uni- or bi-directional) or multicast. For multicast, a flow can split into multiple flows as it heads toward the receiver. For multi-sender multicast, a flow can also split when you look at it in reverse, toward the senders. Iconic 😭
- Data Path: the route across the networks taken by a flow or aggregate. In other words, which domains and subdomains it goes through, plus the egress and ingress points for each one 🗺️
- Signaling Path: the route across the networks taken by a signaling flow or aggregate. Same deal: which domains and subdomains it passes through, and the egress and ingress points for each 🛤️
- Path-coupled signaling: a mode where the signaling messages follow a path that's tied to the data packets. The signaling only gets routed through nodes (NEs) that are on the data path. Very loyal energy 💜
- Path-decoupled signaling: signaling where the data and signaling paths are independent 🌈 The signaling gets routed to nodes (NEs) that are not assumed to be on the data path, but that are (presumably) aware of it. Signaling messages are always directly addressed to the neighbor NE, and the NI or NR might have no connection at all to the ultimate data sender or receiver. Not me being like "who even are you" 🙈
- Service: a generic something provided by one entity and consumed by another ✨ It can be built by allocating resources. The network can offer it to users, or a network node can offer it to packets.
3. Problem Statement and Scope 🎀
okay here's a preliminary architectural picture, basically a starting point for discussion 💭 We'll come back to it in the requirement sections later.
Quick note: this model is NOT meant to box in the technical approach we take afterwards. It just exists so we can phrase requirements concretely (for example, requirements about where the NSIS Initiator gets placed) 📍
Roughly, the scope of NSIS is assumed to be the interaction between the NSIS Initiator, the NSIS Forwarder(s), and the NSIS Responder. That includes a protocol to carry the information, plus the syntax and semantics of the information being exchanged 📦 More on assumptions and exclusions is in the next section.
Here are the main elements:
- The NSIS Initiator: something that starts the request for state to be set up in the network. 🚀 It might live in the end system or somewhere else in the network. What makes the NSIS Initiator special is that it acts on triggers coming (directly or indirectly) from the higher layers in the end systems. It has to map the services those layers ask for, and it also gives feedback up to the higher layers, which transport layer algorithms or adaptive applications might use 🔄
- The NSIS Forwarder: something that helps manage state further along the signaling path. 🦋 The NSIS Forwarder doesn't interact with higher layers. It interacts with the NSIS Initiator, the NSIS Responder, and possibly one or more other NSIS Forwarders on the signaling path, either edge-to-edge or end-to-end.
- The NSIS Responder: something that terminates the signaling path. 👑 The NSIS Responder might be in an end system or inside other equipment. What makes it special is that it responds to requests at the end of a signaling path.
- The signaling path traverses an underlying network covering one or more IP hops. 🌐 That underlying network might use locally different technology. For example, QoS technology has to be provisioned appropriately for the service being requested. In the QoS example, an NSIS Forwarder maps service-specific information to technology-related QoS parameters, and it receives indications of success or failure in response 💅
- We can look at the network at the level of domains and subdomains, not individual routers. 🗂️ The exception is the special case where a domain contains just one link. Domains are assumed to be administrative entities, so security requirements might apply differently to signaling between domains versus signaling within a domain. This document deals with both cases 🔐
4. Assumptions and Exclusions 🌸
4.1. Assumptions and Non-Assumptions 🧁
- NSIS signaling could run end-to-end, end-to-edge, edge-to-edge, or network-to-network (between providers). 🌍 It depends on which point in the network acts as the NSIS Initiator, and how far toward the other end of the network the signaling propagates. In general, we could expect NSIS Forwarders to get more "dense" toward the edges of the network, but that's not a requirement. For example, in the QoS case, an over-provisioned domain might contain no NSIS Forwarders at all and be NSIS transparent. At the other extreme, NSIS Forwarders might be placed at every router. In that latter case, QoS provisioning can be carried out in a local, implementation-dependent way without further signaling. With remote NSIS Forwarders, though, a protocol might be needed to control the routers along the path. That protocol would then be independent of the end-to-end NSIS signaling 🧩
- We do not consider "pure" end-to-end signaling that isn't interpreted anywhere within the network. 🚫 Such signaling is a higher-layer issue, and IETF protocols such as SIP etc. can be used for it 📞
- Where the signaling covers several domains, we do not exclude using different signaling protocols in each domain. 🔀 We only place requirements on the universality of the control information being transported. (The goal here is to allow the use of signaling protocols that are matched to the characteristics of the portion of the network being traversed.) Note that the outcome of NSIS work might result in various flavors of the same protocol 🍓
- We assume the service definitions an NSIS Initiator can ask for are known in advance of the signaling protocol running. 📚 For instance, in the QoS example, the service definition includes QoS parameters, the lifetime of a QoS guarantee, and so on, or any other service-specific parameters. There are lots of ways service requesters can find out about available services 👀 There might be standardized services. The definition can be negotiated along with a contract. The service definition can be published in some online directory (for example, on a Web page), and so on.
- We assume there are means for discovering NSIS entities, so that signaling peers can be known. 🔍 Solutions include static configuration, automatic discovery, or implicitly running over the right nodes along the data path, among others. The discovery of NSIS entities has security implications that need to be addressed properly ⚠️ For some security mechanisms (i.e., Kerberos, pre-shared secret), it is required to know the identity of the other entity. So the discovery mechanism may provide ways to learn that identity, which is then later used to retrieve the required keys and parameters 🔑
- NSIS assumes layer 3 routing, and determining the next data node selection is not done by NSIS. 🛣️ Routing is somebody else's job, bestie 💖
4.2. Exclusions 🎀
- okay so, the development of specific mechanisms and algorithms for application and transport layer adaptation is not considered 🙅♀️, and neither are the protocols that would support it.
- specific mechanisms (APIs and so on) for interaction between transport/applications and the network layer are not considered, except to clarify the requirements on the negotiation capabilities and information semantics that would be needed of the signaling protocol. 💭
- specific mechanisms and protocols for provisioning or other network control functions within a domain/subdomain are not considered. the goal is to reuse existing functions and protocols unchanged. however, NSIS itself can be used for signaling within a domain/subdomain. 🧚
for instance, in the QoS example, it means that the setting of QoS mechanisms in a domain is out of scope, but if we have a tunnel, NSIS could also be used for tunnel setup with QoS guarantees. it should be possible to exploit these mechanisms optimally within the end-to-end context. consideration of how to do this might generate new requirements for NSIS however. for example, the information needed by a NSIS Forwarder to manage a radio subnetwork needs to be provided by the NSIS solution. 📡
- specific mechanisms (APIs and so on) for interaction between the network layer and underlying provisioning mechanisms are not considered. 🙈
- interaction with resource management or other internal state management capabilities is not considered. standard protocols might be used for this. this may imply requirements for the sort of information that should be exchanged between the NSIS entities. 🍓
- security implications related to multicasting are outside the scope of the signaling protocol. 🔒
- service definitions and in particular QoS services and classes are out of scope. together with the service definition, any definition of service specific parameters is not considered in this document. only the base NSIS signaling protocol for transporting the service information is addressed. 💜
- similarly, specific methods, protocols, and ways to express service information in the Application/Session level are not considered (e.g., SDP, SIP, RTSP, etc.). 🌸
- the specification of any extensions needed to signal information via application level protocols (e.g., SDP), and the mapping to NSIS information are considered outside of the scope of NSIS working group, as this work is in the direct scope of other IETF working groups (e.g., MMUSIC). 🫶
- Handoff decision and trigger sources: an NSIS protocol is not used to trigger handoffs in mobile IP, nor is it used to decide whether to handoff or not. as soon as or in some situations even before a handoff happened, an NSIS protocol might be used for signaling for the particular service again. the basic underlying assumption is that the route comes first (defining the path) and the signaling comes after it (following the path). this doesn't prevent a signaling application at some node interacting with something that modifies the path, but the requirement is then just for NSIS to live with that possibility. however, NSIS must interwork with several protocols for mobility management. 🦋
- service monitoring is out of scope. it is heavily dependent on the type of the application and or transport service, and in what scenario it is used. 👑
5. Requirements 💅
this section defines more detailed requirements for a signaling solution, respecting the problem statement, scoping assumptions, and terminology considered earlier. the requirements are in subsections, grouped roughly according to general technical aspects: architecture and design goals, topology issues, parameters, performance, security, information, and flexibility. ✨
two general (and potentially contradictory) goals for the solution are that it should be applicable in a very wide range of scenarios, and at the same time be lightweight in implementation complexity and resource consumption requirements in NSIS Entities. we use the terms 'access' and 'core' informally in the discussion of some particular requirements to refer to deployment conditions where particular protocol attributes, especially performance characteristics, have special importance. specifically, 'access' refers to lower capacity networks with fewer users and sessions. 'core' refers to high capacity networks with a large number of users and sessions. 🌈
one approach to this is that the solution could deal with certain requirements via modular components or capabilities, which are optional to implement or use in individual nodes. 🧩
5.1. Architecture and Design Goals 🌷
this section contains requirements related to desirable overall characteristics of a solution, e.g., enabling flexibility, or independence of parts of the framework.
5.1.1. NSIS SHOULD Provide Availability Information on Request
NSIS SHOULD provide a mechanism to check whether state to be setup is available without setting it up. for the resource reservation example this translates into checking resource availability without performing resource reservation. in some scenarios, e.g., the mobile terminal scenario, it is required to query, whether resources are available, without performing a reservation on the resource. 🔍
5.1.2. NSIS MUST be Designed Modularly
a modular design allows for more lightweight implementations, if fewer features are needed. mutually exclusive solutions are supported. examples for modularity:
- work over any kind of network (narrowband versus broadband, error-prone versus reliable, ...). this implies low bandwidth signaling, and elimination of redundant information MUST be supported if necessary.
- state setup for uni- and bi-directional flows is possible.
- extensible in the future with different add-ons for certain environments or scenarios.
- protocol layering, where appropriate. this means NSIS MUST provide a base protocol, which can be adapted to different environments. 🧱
5.1.3. NSIS MUST Decouple Protocol and Information
the signaling protocol MUST be clearly separated from the control information being transported. this provides for the independent development of these two aspects of the solution, and allows for this control information to be carried within other protocols, including application layer ones, existing ones or those being developed in the future. the flexibility gained in the transport of information allows for the applicability of the same protocol in various scenarios. 🎁
however, note that the information carried needs to be standardized; otherwise interoperability is difficult to achieve. ⚠️
5.1.4. NSIS MUST Support Independence of Signaling and Network Control Paradigm
the signaling MUST be independent of the paradigm and mechanism of network control. e.g., in the case of signaling for QoS, the independence of the signaling protocol from the QoS provisioning allows for using the NSIS protocol together with various QoS technologies in various scenarios. 🧠
5.1.5. NSIS SHOULD be Able to Carry Opaque Objects
NSIS SHOULD be able to pass around opaque objects, which are interpreted only by some NSIS-capable nodes. 📦
5.2. Signaling Flows 🛣️
this section contains requirements related to the possible signaling flows that should be supported, e.g., over what parts of the flow path, between what entities (end-systems, routers, middleboxes, management systems), in which direction. 🗺️
5.2.1. The placement of NSIS Initiator, Forwarder, and Responder Anywhere in the Network MUST be Allowed
the protocol MUST work in various scenarios such as host-to-network-to-host, edge-to-edge, (e.g., just within one provider's domain), user-to-network (from end system into the network, ending, e.g., at the entry to the network and vice versa), and network-to-network (e.g., between providers). 🌍
placing the NSIS Forwarder and NSIS Initiator functions at different locations allows for various scenarios to work with the same protocol. 🔁
5.2.2. NSIS MUST Support Path-Coupled and MAY Support Path-Decoupled Signaling.
the path-coupled signaling mode MUST be supported. NSIS signaling messages are routed only through nodes (NEs) that are in the data path. 🛤️
however, there is a set of scenarios, where signaling is not on the data path. therefore, NSIS MAY support the path-decoupled signaling mode, where signaling messages are routed to nodes (NEs), which are not assumed to be on the data path, but which are aware of it. 🦄
5.2.3. Concealment of Topology and Technology Information SHOULD be Possible
the NSIS protocol SHOULD allow for hiding the internal structure of a NSIS domain from end-nodes and from other networks. hence an adversary should not be able to learn the internal structure of a network with the help of the signaling protocol. 🕵️♀️
in various scenarios, topology information should be hidden for various reasons. from a business point of view, some administrations don't want to reveal the topology and technology used. 🤫
5.2.4. Transparent Signaling Through Networks SHOULD be Possible
it SHOULD be possible that the signaling for some flows traverses path segments transparently, i.e., without interpretation at NSIS Forwarders within the network. an example would be a subdomain within a core network, which only interpreted signaling for aggregates established at the domain edge, with the signaling for individual flows passing transparently through it. 🫧
in other words, NSIS SHOULD work in hierarchical scenarios, where big pipes/trunks are setup using NSIS signaling, but also flows which run within that big pipe/trunk are setup using NSIS. 🧁
5.3. Messaging 💌
5.3.1. Explicit Erasure of State MUST be Possible
when state along a path is no longer necessary, e.g., because the application terminates, or because a mobile host experienced a hand-off, it MUST be possible to erase the state explicitly. 🧹
5.3.2. Automatic Release of State After Failure MUST be Possible
when the NSIS Initiator goes down, the state it requested in the network SHOULD be released, since it will most likely no longer be necessary. 📉
after detection of a failure in the network, any NSIS Forwarder/Initiator MUST be able to release state it is involved in. for example, this may require signaling of the "Release after Failure" message upstream as well as downstream, or soft state timing out. 🔄
the goal is to prevent stale state within the network and add robustness to the operation of NSIS. so in other words, an NSIS signaling protocol or mechanisms MUST provide means for an NSIS entity to discover and remove local stale state. 🛡️
note that this might need to work together with a notification mechanism. note as well, that transient failures in NSIS processing shouldn't necessarily have to cause all state to be released immediately. ⏳
5.3.3. NSIS SHOULD Allow for Sending Notifications Upstream 📣
okay so NSIS Forwarders SHOULD notify the NSIS Initiator or any other NSIS Forwarder upstream if the state changes inside the network 👀. there are a few kinds of network changes, like:
- Recoverable errors 🛠️: the network nodes can fix this kind locally, so they don't have to tell the users right away. this is when the danger of degradation (or actual short term degradation) of the provided service was overcome by the network (NSIS Forwarder) itself. ✨
- Unrecoverable errors 🚨: the network nodes can't handle this one, so they have to notify the users as soon as possible.
- Service degradation 📉: when the service can't be provided completely, only partially.
- Repair indication 🩹: if an error happened and it got fixed, this triggers the sending of a notification.
- Service upgrade available 🚀: if a previously requested better service becomes available.
the content of the notification is super service specific, but it must at least carry type information. 🏷️ it may also carry the location of the state change.
the notifications may or may not be in response to an NSIS message. that means an NSIS entity has to be able to handle notifications at any time 🕰️💅
ok but now the big security moment 🚨💀: there are a bunch of security considerations that need to be solved with notification, and it's even more important if the notification is sent without prior request (asynchronously). the problem basically is that everybody could send notifications to any NSIS entity, and the NSIS entity most likely reacts on the notification. like, if it gets an error notification it might erase state, even if everything is ok 😭. so the notification might depend on security associations between the sender of the notification and its receiver. and if a hop-by-hop security mechanism is chosen, this also implies that notifications need to be sent on the reverse path. 🔐
5.3.4. Establishment and Refusal to Set Up State MUST be Notified 🤝
A NR MUST acknowledge establishment of state on behalf of the NI requesting establishment of that state. 🎀 A refusal to set up state MUST be replied with a negative acknowledgement by the NE refusing to set up state. it MUST be sent to the NI. depending on the signaling application, the (positive or negative) notifications may have to pass through further NEs upstream. 🔁 information on the reason of the refusal to set up state MAY be made available. for example, in the resource reservation example, together with a negative answer, the amount of resources available might also be returned. 📦
5.3.5. NSIS MUST Allow for Local Information Exchange 🏠
the signaling protocol MUST be able to exchange local information between NSIS Forwarders located within one single administrative domain. 🫶 the local information exchange is done with a bunch of separate messages that don't belong to an end-to-end signaling process. local information might be things like IP addresses, notifications of successful or erroneous processing of signaling messages, or other conditions. 🧩
in some cases, the NSIS signaling protocol MAY carry identification of the NSIS Forwarders located at the boundaries of a domain. however, the identification of edge should not be visible to the end host (NSIS Initiator), and it only applies within one administrative domain. 🚪🙈
5.4. Control Information 🎛️
this section has the requirements for the control information that needs to be exchanged. 💜
5.4.1. Mutability Information on Parameters SHOULD be Possible 🧬
it's possible that nodes modify parameters of a signaling message. however, it SHOULD be possible for the NSIS Initiator to control the mutability of the signaled information. for example, the NSIS Initiator should be able to control what is requested end-to-end, without the request getting gradually mutated as it passes through a sequence of nodes. 🙅♀️✨
5.4.2. It SHOULD be Possible to Add and Remove Local Domain Information 🔄
it SHOULD be possible to add and remove local scope elements. compared to Requirement 5.3.5, this requirement does use the normal signaling process and message exchange for transporting local information. for example, at the entrance to a domain, domain-specific information gets added, which is used in this domain only, and the information is removed again when a signaling message leaves the domain. 🚶♀️ the motivation is the economy of re-using the protocol for domain internal signaling of various pieces of information (smart, right? 🧠). where additional information is needed within a particular domain, it should be possible to carry it at the same time as the end-to-end information. 🎁
5.4.3. State MUST be Addressed Independent of Flow Identification 🗺️
addressing or identifying state MUST be independent of the flow identifier (flow end-points, topological addresses). 🦋 various scenarios in the mobility area need this independence, because flows resulting from handoff might have changed end-points etc. but still have the same service requirement. also, several proxy-based signaling methods profit from this independence, though these are not chartered work items for NSIS. 💅
5.4.4. Modification of Already Established State SHOULD be Seamless 🌊
in many cases, the established state needs to be updated (in the QoS example, an upgrade or downgrade of resource usage). this SHOULD happen seamlessly without service interruption. 🫧 at the very least, the signaling protocol should allow for it, even if some data path elements might not be capable of doing so. 🙃
5.4.5. Grouping of Signaling for Several Micro-Flows MAY be Provided 📦🌸
NSIS MAY group signaling information for several micro-flows into one signaling message. the goal is optimization in terms of setup delay, which can happen in parallel. ⚡ this helps applications requesting several flows at once. also, potential refreshes (in case of a soft state solution) might profit from grouping. 🔁
however, the network doesn't need to know that a relationship between the grouped flows exists. there MUST NOT be any transactional semantic associated with the grouping. it's only meant for optimization purposes. 🚫🧁
5.5. Performance 🏎️
this section talks about performance requirements and evaluation criteria, and the way in which these could and should be traded off against each other in various parts of the solution. 📊
scalability is always an important requirement for signaling protocols. however, the type of scalability and how important it is varies from one scenario to another. 🌈
note that many of the performance issues are heavily dependent on the scenario assumed, and they're normally a trade-off between speed, reliability, complexity, and scalability. the trade-off varies in different parts of the network. for example, in radio access networks, low bandwidth consumption will outweigh the low latency requirement, while in core networks it may be the reverse. 📡💖
5.5.1. Scalability 📈
NSIS MUST be scalable in the number of messages received by a signaling communication partner (NSIS Initiator, NSIS Forwarder, and NSIS Responder). the major concern is the core of the network, where large numbers of messages arrive. 🌐
it MUST be scalable in the number of hand-offs in mobile environments. this mainly applies in access networks, because the core is transparent to mobility in most cases. 📱
it MUST be scalable in the number of interactions for setting up state. this applies to end-systems setting up several states. some servers might be expected to set up a large number of states. 🖥️
scalability in the amount of state per entity MUST be achieved for NSIS Forwarders in the core of the network. 🧠
scalability in CPU usage MUST be achieved on end terminals and intermediate nodes in the case of many state setup processes at the same time. 🔥
specifically, NSIS MUST work in Internet scale deployments, where the use of signaling by hosts becomes universal. note that requirement 5.2.4 requires the functionality of transparently signaling through networks without interpretation. additionally, requirement 5.6.1 lists the capability to aggregate. furthermore, requirement 5.5.4 states that NSIS should be able to constrain the load on devices. basically, the performance of the signaling MUST degrade gracefully rather than catastrophically under overload conditions. 🫠💀
5.5.2. NSIS SHOULD Allow for Low Latency in Setup ⏱️
NSIS SHOULD allow for low latency setup of states. this is only needed in scenarios where state setups are required on a short time scale (e.g., handover in mobile environments), or where human interaction is immediately concerned (e.g., voice communication setup delay). 📞
5.5.3. NSIS MUST Allow for Low Bandwidth Consumption for the Signaling Protocol 📶
NSIS MUST allow for low bandwidth consumption in certain access networks. again, only small sets of scenarios call for low bandwidth, mainly those where wireless links are involved. 📻
5.5.4. NSIS SHOULD Allow to Constrain Load on Devices 🔋
the NSIS architecture SHOULD give the ability to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) on devices where it is needed. one of the reasons is that the protocol handling should have a minimal impact on interior (core) nodes. 🧘♀️
this can be achieved by many different methods. examples include message aggregation, header compression, minimizing functionality, or ignoring signaling in core nodes. NSIS may choose any method, as long as the requirement is met. 🎯
5.5.5. NSIS SHOULD Target the Highest Possible Network Utilization 🚄
this requirement applies specifically to QoS signaling. 💎
there are networking environments that require high network utilization for various reasons, and the signaling protocol SHOULD to its best ability support high resource utilization while maintaining appropriate service quality. 🙌
in networks where resources are very expensive (as is the case for many wireless networks), efficient network utilization for signaling traffic is of critical financial importance. 💸 on the other hand, there are other parts of the network where high utilization isn't required. 🫶
5.6. Flexibility 🤸♀️
this section lists the various ways the protocol can be flexibly employed. 🌷
5.6.1. Flow Aggregation 🧺
NSIS MUST allow for flow aggregation, including the capability to select and change the level of aggregation. 🍓
5.6.2. Flexibility in the Placement of the NSIS Initiator/Responder 📍
NSIS MUST be flexible in placing an NSIS Initiator and NSIS Responder. the NSIS Initiator might be located at the sending or the receiving side of a data stream, and the NSIS Responder naturally sits on the other side. 🔀
also, network-initiated signaling and termination MUST be allowed in various scenarios such as PSTN gateways, some VPNs, and mobility. this means the NSIS Initiator and NSIS Responder might not be at the end points of the data stream. 🧚
5.6.3. Flexibility in the Initiation of State Change 🔔
the NSIS Initiator or the NSIS Responder SHOULD be able to initiate a change of state. in the example of resource reservation, this is often called resource re-negotiation. 🤝 it can happen for various reasons, such as local resource shortage (CPU, memory on end-system) or a user changed application preference/profiles. 🎀
5.6.4. SHOULD Support Network-Initiated State Change ✨
Okay so NSIS SHOULD support network-initiated state change 💅 In the QoS example, this comes in handy when the network can't guarantee resources anymore and wants to, like, downgrade a resource reservation 🥺
5.6.5. Uni / Bi-Directional State Setup 🦋
Both unidirectional and bi-directional state setup SHOULD be possible 🌸 When we say bi-directional, we mean the state for bi-directional data flows gets set up. Those flows have the same end-points, but the path going one way doesn't have to be the same path going back 🧚
The whole point of bi-directional state setup is mainly to speed up setup delay ⚡ There are no requirements or constraints here, like needing to use the same data path and stuff 🙈
5.7. Security 🔐
This section is all about the security requirements. Okay, so the NSIS protocol MUST provide means for security, but it MUST be allowed that nodes implementing NSIS signaling do not have to use those security means 💜
5.7.1. Authentication of Signaling Requests 🪪
A signaling protocol MUST make provision for letting different entities authenticate each other using strong authentication mechanisms 🔑 "Strong" is the key word here, because weak plain-text password mechanisms must not be used for authentication. No plain-text passwords, bestie 🙅♀️
5.7.2. Request Authorization 🎟️
The signaling protocol MUST provide means to authorize state setup requests 👑 This needs a hook that talks to a policy entity to ask for authorization data. That way, an authenticated entity can be linked to its authorization data and the request can get checked. Authorization stops unauthorized entities from setting up state, stops setups that break policy, and stops theft of service 🚫 It also limits denial of service attacks on parts of the network, or the whole network, that come from unrestricted state setups 💀 Plus, it might be helpful to have some way to tell other protocols about participating nodes in the same administrative domain after a previous successful authorization event 🫶
5.7.3. Integrity Protection 🛡️
The signaling protocol MUST provide means to protect the message payloads against modifications 🔒 Integrity protection keeps an adversary from messing with parts of a signaling message, and from launching denial of service or theft of service attacks against the network elements taking part in the protocol 😤
5.7.4. Replay Protection 🔁
To stop replays of old signaling messages, the signaling protocol MUST provide means to detect old messages, meaning ones that were already sent 📼 A solution has to deal with synchronization problems when a participating network element restarts or crashes 🥲
5.7.5. Hop-by-Hop Security 🧩
Channel security between signaling entities MUST be implemented 🌈 It's a well known and proven concept in Quality of Service and other signaling protocols to have intermediate nodes that actively take part in the protocol and modify messages as their processing rules require 🤓 This requirement doesn't rule out end-to-end or network-to-network security for a signaling message, though 💅 End-to-end security between the NSIS Initiator and the NSIS Responder may be used to protect non-mutable data fields 🎀 Network-to-network security is about protecting messages across several hops but not end-to-end, meaning protected over one particular network 🌸
5.7.6. Identity Confidentiality and Network Topology Hiding 🕵️♀️
Identity confidentiality SHOULD be supported 🦋 It gives privacy and stops an eavesdropper on the signaling traffic along the path from profiling entities 👀 The identity used during authentication can also be hidden, to a limited extent, from the network the initiator is attached to 🙈 Still, the identity MUST provide enough information for the nodes in the access network to collect accounting data 🧾
Network topology hiding MAY be supported, so entities along the path can't learn the topology of a network 🗺️ Heads up though, supporting this might clash with a diagnostic capability 😬
5.7.7. Denial-of-Service Attacks 🚨
A signaling protocol SHOULD provide prevention of Denial-of-Service attacks 🛑 To actually prevent them, the security and protocol mechanisms used MUST have low computational complexity when verifying a state setup request, and that check has to happen before authenticating the requesting entity 🧮 Also, the signaling protocol and its security mechanisms SHOULD NOT eat up large resources on NSIS Entities (like main memory or extra message exchanges) before authentication succeeds 💀
5.7.8. Confidentiality of Signaling Messages 🤫
Based on the signaling info exchanged between nodes in the protocol, an adversary could learn both the identities and the content of the signaling messages 👂 That matters because being able to listen in on signaling channels is a major clue about which data channels are the interesting ones 👀
To stop that, confidentiality of signaling messages SHOULD be provided on a hop-by-hop basis 🔐 Most messages need hop-by-hop protection because the entities actively taking part in the signaling protocol have to be able to read, and sometimes modify, those messages 💖
5.7.9. Ownership of State 👑
When existing state has to be modified, we need a session identifier to uniquely identify the established state 🪪 The signaling protocol MUST provide means of security protection so adversaries can't modify state 🛡️
5.8. Mobility 🛫
5.8.1. Allow Efficient Service Re-Establishment After Handover 📶
Handover is an essential function in wireless networks 📱 After a handover, states may need to be completely or partially re-established because the routes changed 🔀 The re-establishment can be requested by the mobile node itself, or triggered by the access point the mobile node is attached to 🙌 In the first case, the signaling MUST allow efficient re-establishment after handover ⚡ Re-establishment after handover MUST be as quick as possible, so the mobile node doesn't get service interruption or service degradation 😭 The re-establishment SHOULD be localized and shouldn't need end-to-end signaling 🧚
5.9. Interworking with Other Protocols and Techniques 🤝
Hooks SHOULD be provided to enable efficient interworking between the various protocols and techniques listed below 🎀
5.9.1. MUST Interwork with IP Tunneling 🚇
IP tunneling for various applications MUST be supported 🌐 IPSec tunnels are especially important here. This mainly affects how flows get identified, because when IPSec is used, some of the info commonly used for flow identification (like transport protocol info and ports) may be hidden by encryption 🔐
5.9.2. MUST NOT Constrain Either to IPv4 or IPv6 🌸
That's the whole section, bestie 💅
5.9.3. MUST be Independent from Charging Model 💸
Signaling MUST NOT be constrained by charging models or the charging infrastructure used 🙅♀️
5.9.4. SHOULD Provide Hooks for AAA Protocols 🧾
The NSIS protocol SHOULD be developed so that it can collect usage records from one or more network elements 📊
5.9.5. SHOULD Work with Seamless Handoff Protocols 🦋
An NSIS protocol SHOULD work with seamless handoff protocols, like context transfer and candidate access router (CAR) discovery 🛫
5.9.6. MUST Work with Traditional Routing 🗺️
NSIS assumes traditional L3 routing, which is purely based on L3 destination addresses 📍 NSIS MUST work with L3 routing, and in particular it MUST work when route changes happen 🔁 That means state on the old route MUST be released, and state on the new route MUST be established by an NSIS protocol 🫶
Networks doing non-traditional routing should not break NSIS signaling 🙏 NSIS MAY work for some of these situations 🤞 Combining NSIS-unaware nodes with non-traditional routing causes some problems, though 😬 Non-traditional routing includes things like routing decisions based on port numbers, IP header fields other than the destination address, or splitting traffic based on header hash values 🧩 In these routing environments, the signaling path can end up being different from the data path 🙃
5.10. Operational ⚙️
5.10.1. Ability to Assign Transport Quality to Signaling Messages 🚦
The NSIS architecture SHOULD allow the network operator to assign a certain transport quality to NSIS protocol messages 🎛️ Signaling opens the door to denial of service attacks, so this requirement gives the network operator a means, and also the obligation, to trade off signaling latency against the impact the signaling messages have on devices in the network ⚖️ From a protocol design point of view, this means the protocol messages SHOULD be detectable, at least wherever the control and assignment of message priority happens 👀
The protocol design also has to take reliability into account 🛠️ Communication reliability counts as part of the quality assigned to signaling messages, so procedures MUST be defined for how an NSIS signaling system behaves if a request it sent stays unanswered 📭 The basic transport protocol used between adjacent NSIS Entities MAY ensure message integrity and reliable transport 🤍
5.10.2. Graceful Fail Over 🪂
Any unit taking part in NSIS signaling MUST NOT cause further damage to other systems involved in NSIS signaling when it has to go out of service 🫡
5.10.3. Graceful Handling of NSIS Entity Problems 🛟
NSIS entities SHOULD be able to detect a malfunctioning peer 🔍 A malfunctioning peer may be reported to the NSIS Initiator or to another NSIS entity involved in the signaling process 📣 The NSIS peer may handle the problem itself, for example by switching to a backup NSIS entity 🔄 In that last case, note that state has to be synchronized between the primary and the backup entity 🧠
6. Security Considerations 🔐
Section 5.7 of this document is where you'll find the security related requirements for a signaling protocol 💜
7. Acknowledgments 🫶
Okay bestie, SO many people helped make this doc happen, and I'm not gonna pretend I could list every single one. This list is without a guarantee on completeness, so if your name isn't here, it doesn't mean you didn't matter 💜. Changpeng Fan (Siemens), Krishna Paul (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical University Berlin), Xiaoming Fu (Technical University Berlin), Hans-Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph Niedermeier (Siemens), Andreas Kassler (University of Ulm), and Ilya Freytsis all added ideas, requirements, and more during the discussions 🌸
Some of the text, ideas for text, requirements, and scenarios came from an Internet Draft by David Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars Westberg (Ericsson), and Haihong Zheng (Nokia). Some of them even came back and wrote brand-new text for this doc too, which is such a power move 👑
Another Internet Draft that had a big impact on this doc was written by Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel), and they also contributed new text 🦋
Huge thanks to Kwok Ho Chan (Nortel) for the text changes ✨ And thanks to Alison Mankin for the thorough AD review, plus Harald Tveit Alvestrand and Steve Bellovin for the IESG review comments 💅
8. Appendix: Scenarios/Use Cases 🧚
Okay so this part is basically a scenario lineup. These are the situations that are super important to cover, and they help us talk through all the different requirements. Some people see these as use cases that a signaling protocol needs to cover 🍓 Mostly, these scenarios look at signaling for QoS (resource reservation), but a lot of the issues carry over directly to other signaling types too, so it's not just a QoS thing 💖
8.1. Terminal Mobility 📱
The scenario we're looking at is when a mobile terminal (MT) switches from one access point to another access point. The access points live in separate QoS domains, which is where it gets spicy 🌶️ We assume Mobile IP handles mobility at the network layer here, and we look at the different extensions (i.e., IETF proposals) to Mobile IP that aim to give 'fast handover' for roaming Mobile Terminals. The big goal is providing, keeping, and adapting the requested QoS for the ongoing IP sessions when a handover happens. Also, negotiating QoS parameters with the new domain over the old connection might be needed, so the different 'fast handover' proposals within the IETF can work 🦋
The entities involved in this scenario are a mobile terminal, access points, an access network manager, and the communication partners of the MT (the other end(s) of the communication association). Technically, terminal mobility just means changing the access point of a mobile terminal (MT). But technologies can change in lots of different directions (access technology, QoS technology, administrative domain), so it can get messy 😭 If the access points are within one specific QoS technology (no matter the access technology), we call this an intra-QoS technology handoff. In an inter-QoS technology handoff, you change from e.g., a DiffServ to an IntServ domain, but you're still using the same access technology. And finally, if the access points use different access technologies, we call it an inter-technology hand-off ✨
The following issues are of special importance in this scenario:
1) Handoff decision
- The QoS management requests handoff. The QoS management can decide to change the access point, since the traffic conditions of the new access point are better at supporting the QoS requirements. The metric may be different (optimized towards a single or a group/class of users). Note that the MT or the network (see below) might trigger the handoff. 💅
- The mobility management forces handoff. This can happen for several reasons. The operator optimizes his network, or admission is no longer granted (e.g., emptied prepaid condition). Or another example is when the MT is reaching the focus of another base station. However, this might be detected via measurements of QoS on the physical layer, so it's out of scope of QoS signaling in IP. Note again that the MT or the network (see below) might trigger the handoff. 🌈
- This scenario shows that local decisions might not be enough. The rest of the path to the other end of the communication needs to be considered as well. Hand-off decisions in a QoS domain don't only depend on the local resource availability, e.g., the wireless part, but involve the rest of the path too. Additionally, decomposition of an end-to-end signaling might be needed, so you can change only parts of it 🧩
2) Trigger sources
- Mobile terminal: If the end-system QoS management identifies another (better-suited) access point, it will request the handoff from the terminal itself. This will be especially likely when two different provider networks are involved. Another important example is when the current access point bearer disappears (e.g., removing the Ethernet cable). In this case, the NSIS Initiator is basically located on the mobile terminal 📱
- Network (access network manager): Sometimes, the handoff trigger will be issued from the network management to optimize the overall load situation. Most likely this will result in changing the base-station of a single providers network. Most likely the NSIS Initiator is located on a system within the network 🖥️
3) Integration with other protocols
- Interworking with other protocol must be considered in one form or another. E.g., it might be worth combining QoS signaling between different QoS domains with mobility signaling at hand-over 🔗
4) Handover rates
In mobile networks, the admission control process has to cope with way more admission requests than call setups alone would generate. For example, in the GSM (Global System for Mobile communications) case, mobility usually generates an average of one to two handovers per call. For third generation networks (such as UMTS), where it's necessary to keep radio links to several cells at the same time (macro-diversity), the handover rate is significantly higher 📈
5) Fast state installation
Handover can also cause packet losses. This happens when the processing of an admission request causes a delayed handover to the new base station. In this situation, some packets might be discarded, and the overall speech quality might be degraded significantly 😭 Moreover, a delay in handover may cause degradation for other users. In the worst-case scenario, a delay in handover may cause the connection to be dropped if the handover occurred due to bad air link quality. Therefore, it is critical that QoS signaling in connection with handover is carried out very quickly ⚡
6) Call blocking in case of overload
Furthermore, when the network is overloaded, it is preferable to keep states for previously established flows while blocking new requests. Therefore, the resource reservation requests in connection with handover should be given higher priority than new requests for resource reservation 👑
8.2. Wireless Networks 📶
In this scenario, the user is using the packet services of a wireless system (such as the 3rd generation wireless system 3GPP/UMTS, 3GPP2/cdma2000). The region between the End Host and the Edge Node (Edge Router) that connects the wireless network to another QoS domain is considered to be a single QoS domain 🌸
The issues in this environment regarding QoS include:
1) Wireless networks
The wireless networks provide their own QoS technology with specialized parameters to coordinate the QoS provided by both the radio access and wired access networks. Provisioning of QoS technologies within a wireless network can be described mainly in terms of calling bearer classes, service options, and service instances. These QoS technologies need to be invoked with suitable parameters when higher layers trigger a request for QoS. Therefore, these involve mapping the requested higher layer QoS parameters onto specific bearer classes or service instances. The request for allocation of resources might be triggered by signaling at the IP level that passes across the wireless system, and possibly other QoS domains. Typically, wireless network specific messages are invoked to set up the underlying bearer classes or service instances in parallel with the IP layer QoS negotiation, so resources get allocated within the radio access network 🛜
2) Placement of NSIS entities
The IP signaling messages are initiated by the NSIS Initiator and interpreted by the NSIS Forwarder. The most efficient placement of the NSIS Initiator and NSIS Forwarder has not been determined in wireless networks, but a few potential scenarios can be envisioned. The NSIS Initiator could be located at the End Host (e.g., 3G User equipment (UE)), the Access Gateway, or at a node that is not directly on the data path, such as a Policy Decision Function. The Access Gateway could act as a proxy NSIS Initiator on behalf of the End Host. The Policy Decision Function that controls per-flow/aggregate resources with respect to the session within its QoS domain (e.g., the 3G wireless network) may act as a proxy NSIS Initiator for the end host or the Access Gateway. Depending on the placement of the NSIS Initiator, the NSIS Forwarder may be located at an appropriate point in the wireless network 🧚
3) Re-negotiation after host mobility
There's a need for re-negotiation of resources in a new wireless domain due to host mobility. In this case, the NSIS Initiator and the NSIS Forwarder should detect mobility events and autonomously trigger re-negotiation of resources 🔄
8.3. An Example Scenario for 3G Wireless Networks ✨
Okay bestie, this one is a pure hypothetical 🧚. Nobody is telling anyone how an integration has to happen. We borrow 3GPP architecture terms (P-CSCF, IMS, which get expanded below) so things feel specific, but this is a made-up design that has NOT been developed or reviewed by 3GPP. The whole point is to help design an NSIS signaling protocol that can work across all sorts of environments 🌈.
The 3G wireless access scenario is shown in Figure 1. The Proxy-Call State Control Function (P-CSCF) is the outbound SIP proxy, and it's only used in IP Multimedia Subsystems (IMS) 📞. The Access Gateway is the egress router of the 3G wireless domain, and it connects the radio access network to the Edge Router (ER) of the backbone IP network 🛣️. The Policy Decision Function (PDF) is the entity in charge of controlling bearer level resource allocations and de-allocations in relation to session level services, e.g., SIP. The PDF may also tell the Access Gateway to open and close the gates and to set up per-flow policies, i.e., to authorize or forbid user traffic 🚦. The P-CSCF (only used in IMS) and the Access Gateway both talk to the PDF when they need network resource allocation or de-allocation decisions. The User Equipment (UE) or the Mobile Station (MS) is made up of a Mobile Terminal (MT) and Terminal Equipment (TE), e.g., a laptop 💻.
+--------+
+--------->| P-CSCF |---------> SIP signaling
/ +--------+
/ SIP |
| |
| +-----+ +----------------+
| | PDF |<---------->| NSIS Forwarder |<--->
| +-----+ +----------------+
| | ^
| | |
| | |
| |COPS |
| | |
+------+ +---------+ |
| UE/MS|----------| Access |<-----------+ +----+
+------+ | Gateway |------------------| ER |
+---------+ +----+
Figure 1: 3G wireless access scenarioThe PDF has all the required QoS info for per-flow or aggregate admission control in 3G wireless networks 🎀. It gets resource allocation and de-allocation requests from the P-CSCF and/or the Access Gateway (etc.), and it replies with policy decisions 📨. So the PDF could be a good candidate to host the NSIS Initiator functionality, kicking off NSIS QoS signaling toward the backbone IP network 🚀. On the flip side, the UE/MS could act as the NSIS Initiator, or the Access Gateway could act as a Proxy NSIS Initiator on behalf of the UE/MS 🙈. In the first case, the P-CSCF/PDF has to map codec types and media descriptors (derived from SIP/SDP signaling) to an IP traffic descriptor. In the second case, the UE/MS may use any appropriate QoS signaling mechanism as the NSIS Initiator. And if the Access Gateway is acting as the Proxy NSIS initiator on behalf of the UE/MS, then it may have to map parameters from radio access specific QoS to IP QoS traffic parameters before forwarding the request to the NSIS Forwarder 🔁.
The NSIS Forwarder isn't part of the standard 3G wireless architecture yet 🙃. But to get end-to-end QoS, you NEED an NSIS Forwarder so the NSIS Initiators can request a QoS connection to the IP network. Just like in the previous example, the NSIS Forwarder could manage a set of pre-provisioned resources in the IP network (bandwidth pipes, i.e., pipes of bandwidth), and do per-flow admission control into those pipes 🧃. This way, a connection can be made between two 3G wireless access networks, so end-to-end QoS can be achieved 🌍. Here, the NSIS Initiator and NSIS Forwarder are clearly two separate logical entities. The Access Gateway and/or the Edge Router in Fig.1 may contain the NSIS Forwarder functionality, depending on where the NSIS Initiator is placed, as discussed in scenario 2 in section 8.2 🧩. This use case really shows why an NSIS QoS signaling protocol is needed between the NSIS Initiator and NSIS Forwarder 💜. An important application of this protocol could be setting up, end-to-end, a connection with specific QoS characteristics between a mobile host and another party (e.g., an end host or a content server) 🫶.
8.4. Wired Part of Wireless Network 📡
Okay so, from a QoS domain perspective, a wireless network usually has three parts: a wireless interface part (the "radio interface"), a wired part of the wireless network (i.e., the Radio Access Network), and the backbone of the wireless network 🧱. Check out Figure 2. It's NOT meant to be an architectural overview of wireless networks, just a picture of the conceptual QoS domains 🖼️.
In this scenario, a mobile host can roam and do a handover between base stations/access routers 🏃♀️. The NSIS QoS protocol can be applied between a base station and the gateway (GW). A GW can also be seen as a local handover anchor point ⚓. And here's the bonus: the NSIS QoS protocol can also be applied between two GWs, or between two edge routers (ER) 💅.
|--|
|GW|
|--| |--|
|MH|--- .
|--| / |-------| .
/--|base | |--| .
|station|-|ER|...
|-------| |--| . |--| back- |--| |---| |----|
..|ER|.......|ER|..|BGW|.."Internet"..|host|
-- |-------| |--| . |--| bone |--| |---| |----|
|--| \ |base |-|ER|... .
|MH| \ |station| |--| .
|--|--- |-------| . MH = mobile host
|--| ER = edge router
<----> |GW| GW = gateway
Wireless link |--| BGW = border gateway
... = interior nodes
<------------------->
Wired part of wireless network
<---------------------------------------->
Wireless Network
Figure 2. QoS architecture of wired part of wireless networkEach of these parts brings its own issues that the QoS signaling solution has to deal with 🤓:
- Wireless interface: The solution for the air interface link has to ensure flexibility and spectrum efficient transmission of IP packets. However, this link layer QoS can be handled the same way as any other last hop problem, by letting a host request the proper QoS profile 📶.
- Wired part of the wireless network: This is the part of the network closest to the base stations/access routers. It's an IP network, although some parts logically perform tunneling of the end user data 🚇. In cellular networks, the wired part of the wireless network is called a radio access network.
This part has different signaling protocol requirements compared to traditional IP networks 😤:
- The network must support mobility. Many wireless networks can provide a combination of soft and hard handover procedures. When a handover happens, reservations need to be established on new paths. The establishment time has to be as short as possible, since long establishment times for s degrade the performance of the wireless network ⏱️. Moreover, for maximal utilization of the radio spectrum, frequent handover operations are required 🔄.
- These links are typically rather bandwidth-limited 🪢.
- The wired transmission in such a network contains a relatively high volume of expensive leased lines. Overprovisioning might therefore be prohibitively expensive 💸.
- The radio base stations are spread over a wide geographical area and are generally situated a large distance from the backbone 🗺️.
- Backbone of the wireless network: The requirements imposed by this network are similar to the requirements imposed by other types of backbone networks 🏛️.
Because of these very different, often contradictory, characteristics and requirements, different QoS signaling solutions might be needed in each of the three network parts 🌸.
8.5. Session Mobility 🦋
In this scenario, a session is moved from one end-system to another 📲. Ongoing sessions are kept, and QoS parameters need to be adapted, since the new device very likely has different capabilities 🔧. Heads up: it's open which entity initiates the move, which means the NSIS Initiator might be triggered by different entities 👀.
User mobility (a user changing devices and therefore moving sessions to the new device) is considered a special case within the session mobility scenario 💁♀️.
Note that this scenario is different from terminal mobility. The terminal (end-system) hasn't moved to a different access point. Both terminals are still connected to an IP network at their original points 🙌.
The issues include 📋:
- Keeping the QoS guarantees negotiated implies that the end-point(s) of communication are changed without changing the s.
- The trigger of the session move might be the user or any other party involved in the session 🎬.
8.6. QoS Reservation/Negotiation from Access to Core Network ⭐
This scenario covers the signaling between access networks and core networks, used to set up and change reservations, together with potential negotiation 🤝. The issues here are totally different from the previous ones, so buckle up 🎢.
- The entity of reservation is most likely an aggregate 📦.
- The time scales of states might be different (long living states of aggregates, with less often re-negotiation) ⌛.
- The specification of the traffic (the amount of traffic) that a particular QoS is guaranteed for needs to be changed. E.g., if additional flows are added to the aggregate, the traffic specification of the flow needs to be added if it isn't already included in the aggregates specification ➕.
- The flow specification is more complex, including network addresses and sets of different addresses for the source as well as for the destination of the flow 🕸️.
8.7. QoS Reservation/Negotiation Over Administrative Boundaries 🌐✨
okay so this scenario is about signaling between two or more core networks to get QoS sorted 💅. It might also cover access-to-core signaling that crosses administrative boundaries. Compared to the last one, this time the networks are not in the same administrative domain 😭. Basically this is the inter-domain / inter-provider signaling zone, bestie 🫶.
The domain boundary is the big problem to solve, and a QoS signaling protocol has to deal with a few different flavors of it:
- Competing administrations: normally, only basic information should be exchanged when the signaling is between competing administrations 🙈. Core network internals (for example topology, technology, and so on) should not be exchanged, no cap. Some information about the "access points" of the core networks may still need to be exchanged, though, because that's topology info and it's needed for proper signaling 🧚.
- Aggregates: as in scenario 4, the signaling most likely works on aggregates, and all the issues that come with aggregates show up here too 💜.
- Authorization: it is critical that the NSIS Initiator is authorized to perform a QoS path setup 🔥. Not a vibe, a must-have 👑.
- Accountability: signaling might be used as a way to charge money, so the interoperation with accounting needs to be available 💸. Iconic, but also serious 💀.
8.8. QoS Signaling Between PSTN Gateways and Backbone Routers 📞🎀
okay picture this: a PSTN gateway (which is a host, fyi 🧚) needs to know whether the network can carry voice traffic across it 🍓. Voice quality suffers from packet loss, latency, and jitter, and nobody wants a glitchy call 😭. So signaling is used to identify and admit a flow where those impairments are minimized ✨. On top of that, the result of the signaling request lets the PSTN GW make a call routing decision before the call is actually accepted and delivered to the final destination 🦋.
PSTN gateways can handle thousands of calls at once, and a single provider network may have hundreds of them 🌈. Those numbers will probably only climb as the network grows, so scalability is a major issue 💅.
There are a few ways a PSTN gateway can get assurances that the network can carry its traffic:
- Over-provisioning a high availability network.
- Handling admission control through some policy server that has a global view of the network and its resources.
- Per PSTN GW pair admission control.
- Per call admission control (where a call is defined as the 5-tuple used to carry a single RTP flow) 🎀.
Item 1 needs no signaling at all, so it's outside the scope of this working group 🙈.
Item 2 is basically a smarter version of item 1, but it's also outside the scope of this working group, because it relies on a particular telephony signaling protocol rather than a packet admission control protocol 🧚.
Item 3 looks super attractive at first because it seems to scale nicely 🌸. The catch is that its scaling properties only really work when there are relatively few PSTN GWs 😬. In the more general case, a PSTN GW shrinks down to a single IP phone sitting behind some access network, so there's way less room for aggregation, and the problem becomes item 4 💀.
Item 4 is the most general case, and it also has the hardest scaling problems 😭. The goal here is to set the requirements on item 4 so that a scalable per-flow admission control protocol (or protocol suite) can be developed 🦋.
When per-flow signaling extends all the way to individual IP end-points, IP phones on cable, DSL, wireless, or other access networks get included in this scenario too 📱💖.
Call Scenario 📞
A PSTN GW signals end-to-end for some 5-tuple-defined flow, asking for a bandwidth and QoS requirement 💅. The 5-tuple might include masking/wildcarding, so keep that in mind 👀. The access network admits this flow according to its local policy and the specifics of the access technology 🌸.
At the edge router (the border node), the flow is admitted again, with an optional authentication process that might involve an external policy server 🔐. The relationship between the PSTN GW, the policy server, and the routers, and between the routers and the policy server, is outside the scope of NSIS, so that's not on us 🙈. The edge router then admits the flow into the core of the network, possibly using some aggregation technique 💜.
At the interior nodes, NSIS host-to-host signaling should either be ignored or invisible, since the Edge router already made the admission control decision for some aggregate 🦋.
At the inter-provider router (the border node), NSIS host-to-host signaling should again either be ignored or invisible, because the Edge router has already made an admission control decision about an aggregate across a carrier network 🌈.
8.9. PSTN Trunking Gateway 🎙️💖
one of the main use cases for the NSIS signaling protocol is interconnecting PSTN gateways with an IP network that supports QoS 🫶.
Four different scenarios are considered here ✨.
- In-band QoS signaling is used. In this case the Media Gateway (MG) acts as the NSIS Initiator and the Edge Router (ER) is the NSIS Forwarder. So the ER should do admission control (into pre-provisioned traffic trunks) for the individual traffic flows 🔥. This scenario isn't considered further here 🙈.
- Out-of-band signaling in a single domain, where the NSIS forwarder is integrated in the Media Gateway Controller (MGC). In this case no NSIS protocol is required 🧚.
- Out-of-band signaling in a single domain, where the NSIS forwarder is a separate box. In this case NSIS signaling is used between the MGC and the NSIS Forwarder 💜.
- Out-of-band signaling between multiple domains, where the NSIS Forwarder (which may be integrated in the MGC) triggers the NSIS Forwarder of the next domain 🌐.
When out-of-band QoS signaling is used, the Media Gateway Controller (MGC) acts as the NSIS Initiator 💅.
In the second scenario, the voice provider manages a set of traffic trunks leased from a network provider 📞. The MGC does the admission control here. Since the NSIS Forwarder acts as both a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is required 🎀. This scenario is shown in Figure 3 ✨.
+-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+
: / : \
: / : \
: / +--------:----------+ \
: MEGACO / / : \ \
: / / +-----+ \ \
: / / | NMS | \ \
: / | +-----+ | \
: : | | :
+--------------+ +----+ | bandwidth pipe (SLS) | +----+
| PSTN network |--| MG |--|ER|======================|ER|-| MG |--
+--------------+ +----+ \ / +----+
\ QoS network /
+-------------------+Figure 3: PSTN trunking gateway scenario 🦋
In the third scenario, the voice provider does not lease traffic trunks in the network 🙅. Another entity may lease traffic trunks and use a NSIS Forwarder to do per-flow admission control 🌸. In this case NSIS signaling is used between the MGC and the NSIS Forwarder, which is a separate box here. So the MGC only acts as a NSIS Initiator 🫶. This scenario is depicted in Figure 4 ✨.
+-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+
: / : \
: / +-----+ \
: / | NF | \
: / +-----+ \
: / : \
: / +--------:----------+ \
: MEGACO : / : \ :
: : / +-----+ \ :
: : / | NMS | \ :
: : | +-----+ | :
: : | | :
+--------------+ +----+ | bandwidth pipe (SLS) | +----+
| PSTN network |--| MG |--|ER|======================|ER|-| MG |--
+--------------+ +----+ \ / +----+
\ QoS network /
+-------------------+Figure 4: PSTN trunking gateway scenario 💜
In the fourth scenario, multiple transport domains are involved 🌈. In the originating network, either the MGC may have an overview of the overlay network's resources, or a separate NSIS Forwarder will have that overview 👀. Depending on which one applies, either the MGC or the NSIS Forwarder of the originating domain will contact the NSIS Forwarder of the next domain 🌐. The MGC always acts as a NSIS Initiator, and it may also be acting as a NSIS Forwarder in the first domain 🎀.
8.10. An Application Requests End-to-End QoS Path from the Network 📱✨
this one is honestly the conceptually simplest case 🧚. A multimedia application requests a guaranteed service from an IP network 🎬. We assume here that the application is somehow able to specify the network service 💅. The characteristics are that many hosts might do this, but the requested service is low capacity (bounded by the access line) 🌸. There is an issue of scaling, though, in the number of applications requesting this service in the core of the network 😬.
8.11. QOS for Virtual Private Networks 🔐💜
in a Virtual Private Network (VPN), a bunch of tunnels might be used between its edges 🛤️. These tunnels could be IPSec, GRE, and IP-IP, for example 🦋. One of the biggest issues in VPNs is how a flow is identified and what quality it gets 👑. Flow identification might consist of things like the transport protocol port numbers, among others 🔍. In an IP-Sec tunnel, though, this gets tricky, because the transport protocol information is encrypted 🙈.
There are two types of L3 VPNs, distinguished by where the tunnel endpoints live. The endpoints may either be on the customer (CPE) or on the provider equipment, the provider edge (PE) 🏢.
Virtual Private Networks are also likely to request bandwidth or some other type of service, in addition to the premium services that the PSTN GW is likely to use 💖.
8.11.1. Tunnel End Points at the Customer Premises ✨
okay so when the tunnel endpoints are the CPE 💅 the CPE may want to signal across the public IP network asking for a specific amount of bandwidth and QoS for the tunnel aggregate. this is giving flexibility, bestie, because a customer can vary their network cost with demand instead of paying a flat rate 💰 and that signaling lives between the two CPE routers 🦋
the intermediate access and edge routers do the exact same call admission control, authentication and aggregation as the PSTN GW scenario 🔥 the only differences are that the endpoints are CPE tunnel endpoints instead of PSTN GWs, and the 5-tuple describing the RTP flow gets swapped out for the matching flow spec so the tunnels can be uniquely identified 🧚 tunnels can be any variety, like IP-Sec, GRE, or IP-IP 🌈
and honestly? this is iconic for customer managed VPNs 👑 NSIS would partly allow them, which means a customer can set up VPNs by sending later NSIS signaling to various end-points. the tunnel end-points aren't necessarily tied to one application either 🙈 the customer administrator might be the one who triggers the NSIS signaling, so main character energy all around 💜
8.11.2. Tunnel End Points at the Provider Premises 🌸
so in the case where the tunnel end-points exist on the provider edge, bandwidth requests can be signaled either per flow (where a flow is defined from a customer's address space) or between customer sites 🎀
for per flow signaling, the PE router must map the bandwidth request to the tunnel carrying traffic to the destination specified in the flow spec 🔥 that tunnel is a member of an aggregate the flow has to be admitted to. the admission control works a lot like the PSTN GW case, just with an extra layer of indirection from the VPN tunnel 🧚 which is why authentication, accounting and policing may be required on the PE router 💅
for per site signaling, you have to identify a site 🦋 this can be done by specifying the network serviced at that site through an IP prefix. in this case, admission control is performed on the aggregate going to the PE router connected to that site ✨
9. References 📚
9.1. Normative References 💖
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.9.2. Informative References 🫶
[RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.10. Authors' Addresses 🧚
Marcus Brunner (Editor)
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
D-69115 Heidelberg
Germany
EMail: brunner@netlab.nec.de
Robert Hancock
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
EMail: robert.hancock@roke.co.uk
Eleanor Hepworth
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
EMail: eleanor.hepworth@roke.co.uk
Cornelia Kappler
Siemens AG
Berlin 13623
Germany
EMail: cornelia.kappler@siemens.com
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munchen
Germany
EMail: Hannes.Tschofenig@mchp.siemens.de11. Full Copyright Statement 🌈
Copyright (C) The Internet Society (2004). 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 they represent or are sponsored by (if any), the Internet Society and the Internet Engineering Task Force disclaim all of the following, no cap 🙈
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 on 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 on the extent to which any license under such rights might or might not be available. it also doesn't claim to have made any independent effort to identify any such rights 🔥 info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use those proprietary rights can be found in the IETF online 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 required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💅
Acknowledgement 💖
funding for the RFC Editor function is currently provided by the Internet Society 🫶✨
📦 where this page comes from
- ietf: rfc3726 2004-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms