RFC 4190
Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony
RFC 4190: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony 📞 (part 1 of 7)
okay bestie, let's get into it 🦋 this is RFC 4190, and it's a framework doc about making emergency calls work over IP telephony (VoIP) 🚨
- Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony
- Authors: K. Carlberg (G11), I. Brown (UCL), and C. Beard (UMKC) 🫶
- Category: Informational (so it's giving "here's some info," not a standard ✨)
- Date: November 2005 📅
- Obsoletes / Updates: the title block doesn't list any
Status of This Memo 🌸
This memo is here to give info to the Internet community. It is not a standard of any kind, and it can be shared as much as people want 💖
Copyright Notice 💜
Copyright (C) The Internet Society (2005).
Abstract ✨
okay so the big idea is a framework for supporting authorized, emergency-related calls over IP telephony 📞 the doc sets out a bunch of objectives about how authorized emergency service (in line with ETS) should work inside today's IP architecture and service models 🧚 then it maps those objectives to a set of protocols and capabilities, which gives more specific recommendations about existing IETF protocols 🎀 finally, it walks through two scenarios as guiding models. Those models, plus an example from the PSTN (the old-school phone network) 📱, help narrow down the solution space so it's not a total free-for-all 💅
Table of Contents 🍓
1. Introduction ....................................................2
1.1. Emergency Related Data .....................................4
1.1.1. Government Emergency Telecommunications
Service (GETS) ......................................4
1.1.2. International Emergency Preparedness Scheme (IEPS) ..5
1.2. Scope of This Document .....................................5
2. Objective .......................................................7
3. Considerations ..................................................7
4. Protocols and Capabilities ......................................7
4.1. Signaling and State Information ............................8
4.1.1. SIP .................................................8
4.1.2. Diff-Serv ...........................................8
4.1.3. Variations Related to Diff-Serv and Queuing .........9
4.1.4. RTP ................................................10
4.1.5. GCP/H.248 ..........................................11
4.2. Policy ....................................................12
4.3. Traffic Engineering .......................................12
4.4. Security ..................................................13
4.4.1. Denial of Service ..................................13
4.4.2. User Authorization .................................14
4.4.3. Confidentiality and Integrity ......................15
4.5. Alternate Path Routing ....................................16
4.6. End-to-End Fault Tolerance ................................17
5. Key Scenarios ..................................................18
5.1. Single IP Administrative Domain ...........................18
5.2. Multiple IP Administrative Domains ........................19
6. Security Considerations ........................................20
7. Informative References .........................................20
Appendix A: Government Telephone Preference Scheme (GTPS) .........24
A.1. GTPS and the Framework Document ..........................24
Appendix B: Related Standards Work ................................24
B.1. Study Group 16 (ITU) .....................................25
Acknowledgements ..................................................261. Introduction 🌈
okay so the internet has basically become the main place for worldwide communication 💻 for fun, for business, for all kinds of creative info sharing 🎨 A huge part of its history has been Best Effort as the default service model 🫧 Best Effort basically means the network tries its best to forward your traffic to the destination, but it makes no guarantees and doesn't reserve any resources for specific Quality of Service (QoS) measures 😭 The underlying goal is to be "fair" to all the traffic when it comes to the resources used to get it where it's going ⚖️
so to go beyond best effort, [1] gave an overview of Integrated Services (int-serv) and how it fits into the internet architecture 🔥 then [2] specified the RSVP signaling protocol, which is used to convey QoS requirements 📣 add [3] and [4], which specify controlled load (bandwidth bounds) and guaranteed service (bandwidth & delay bounds) respectively, and suddenly there was a design for hitting specific QoS measures for an end-to-end flow of traffic crossing an IP network 🧚 In this case, a "flow" is pretty granular and applies to specific application sessions 🎀
From a deployment point of view (as of the date of this document), int-serv has mostly been stuck inside single domains 🏝️ At best it looks like isolated "island" reservations for specific kinds of traffic (like audio and video) inside stub domains 🌸 [5] and [6] will probably help int-serv spread to Internet Service Providers (ISPs) and maybe some inter-domain paths 🦋 But honestly, the original dream of end-to-end int-serv between hosts in source and destination stub domains seems unlikely to happen anytime soon (the mid- to far-term is a subject for others to contemplate 🔮)
In 1998, the IETF produced [7], which presented an architecture for Differentiated Services (diff-serv) 💅 This one takes a more aggregated view and classifies packets differently than [1] did 📦 It works with the diff-serv field in the IP header (in IPv4, it replaced the old ToS field) 🫶 That field is used for code points established by IANA, or set aside as experimental 🧪 It can be expected that sets of microflows (a granular identification of a set of packets) will map to a given code point, which achieves aggregated treatment of data 💜
Here's the thing: whenever a new service model shows up, Best Effort stays as the default 🌈 If traffic isn't associated with diff-serv or int-serv (or can't be), it gets treated as Best Effort and uses whatever resources happen to be available 🫠
Beyond new services, the ever-growing traffic load on ISPs has kept intra-domain traffic engineering super important 📈 The huge number of IETF drafts and RFCs in the Multi-Protocol Label Switching (MPLS) area shows how much people care about versatile, manageable mechanisms for intra-domain traffic engineering 🧚 One interesting thing is the work on supporting QoS-related traffic engineering. Specifically, we're talking about MPLS support for differentiated services [8], and the ongoing work on fast bandwidth recovery from routing failures for MPLS [9] 🔥
1.1. Emergency Related Data 🚨
so the evolution of the IP service model has traditionally been centered on the type of application protocols running over a network 💻 That means the distinction (and any possible bounds on QoS) usually depends on the kind of application being referred to, like audio and video tools 🎧
[10] defined a priority field for SMTP, but it's only for mapping with X.400 and isn't meant for general use 📧 SIP [11] has an embedded field called "priority," but it's only aimed at the end user and isn't meant to tell the underlying network or end-to-end applications anything 🙄
Now that IP telephony is a thing, it's a natural move to support existing emergency-related services over it 📞 Usually when people think of emergency calls, they think of "911" in the U.S. or "999" in the U.K. 🇺🇸🇬🇧 Both of those are tied to national boundaries and are open to the general public 🫶 Beyond that, there are emergency telephone services for authorized use only, which we'll cover in the next subsections 🔐
1.1.1. Government Emergency Telecommunications Service (GETS) 🏛️
GETS is an emergency telecommunications service available in the U.S., and it's overseen by the National Communications System (NCS) 🇺🇸 The NCS is an office set up by the White House under an executive order [27], and it's now part of the Department of Homeland Security 🏢 Unlike "911," GETS is only accessible to authorized individuals 🔑 Most of those people come from government agencies like the Department of Transportation, NASA, the Department of Defense, and the Federal Emergency Management Agency (to name a few) 🚀 A select group from private industry (telecommunications companies, utilities, etc.) who work on critical infrastructure recovery are also given access to GETS 🛠️
The whole point of GETS is to give selected authorized personnel a high probability that phone service will be available during emergencies 🌪️ Think hurricanes, earthquakes, and other disasters that can cause call blocking (aka congestion) on the U.S. Public Switched Telephone Network when the general public is all calling at once 📵
GETS is based in part on the ANSI T1.631 standard, which specifies a High Probability of Completion (HPC) for SS7 signaling [12][24] 🦋
1.1.2. International Emergency Preparedness Scheme (IEPS) 🌍
[25] is a recent ITU standard describing emergency-related communications over the international telephone service 🌐 GETS is national in scope, but IEPS extends local or national authorized emergency call setup and provides a building block for a global service 🧩
Just like GETS, IEPS promotes mechanisms like extended queuing, alternate routing, and exemption from restrictive management controls 🚦 The goal is to raise the probability that international emergency calls get established ✨ The specifics of how this is going to be done are to be defined in future ITU document(s) 🔮
1.2. Scope of This Document 🎀
okay bestie, the scope of this doc is all about getting ETS (emergency telecom service) working in the near and mid-term, specifically with IP telephony vs Voice over IP ✨ We split these two up by treating IP telephony as a subset of VoIP. For IP telephony, we assume some kind of application layer signaling is used to explicitly set up and maintain voice data traffic. That explicit signaling is what gives you the hooks to bridge VoIP traffic to the PSTN 💅
Here's an example of the difference. The Robust Audio Tool (RAT) [13] starts sending VoIP packets to a unicast (or multicast) destination. RAT doesn't use explicit signaling like SIP to set up an end-to-end call between two users. It just sends data packets to the target 🦋 "SIP phones," on the other hand, are host devices that use a signaling protocol to establish a call before they send data toward the destination 📞
Another thing we should probably assume with IP telephony is a target level of QoS per session or flow. [28] argues there's a maximum packet loss and delay for VoIP traffic, and that the two are interdependent 🧠 For delays of ~200ms, a corresponding drop rate of 5% is considered acceptable. When delay is lower, a 15-20% drop rate can be experienced and still be considered acceptable. [29] covers the same topic and argues that packet size plays a significant role in what users tolerate as "intelligible" VoIP. The larger the packet (which correlates to a longer sampling rate), the lower the acceptable rate of loss. Note that [28, 29] only give two of several perspectives on VoIP. A more in-depth discussion is outside the scope of this doc, but the choice of codec can significantly alter the results above 🌈
Regardless of a single, definitive characteristic for stressed conditions, interactive voice seems to have a lower threshold for some combinations of loss/delay/jitter than elastic applications like email or web browsers. That places a higher burden on supporting VoIP over the Internet 😭 It gets even more complicated when toll-quality service is expected, because that assumes a default service model that's better than best effort. And that can increase the probability of call-blocking happening with VoIP or IP telephony traffic 🙈
Beyond this, part of our motivation is to give ISPs and telephony carriers a framework for understanding the objectives used to support ETS-related IP telephony traffic. We also want to give potential customers a reference point so they can keep their expectations in check ✨ In particular, we want to avoid any temptation to replicate the exact capabilities of existing emergency voice service in the PSTN over IP and the Internet. Intrinsic differences between the two communications architectures make that impossible anyway. Note, this doesn't stop us from borrowing design concepts or objectives from existing systems 💜
Section 2 presents several primary objectives that articulate what's important in supporting ETS-related IP telephony traffic. These are a generic set of goals and desired capabilities. Section 3 presents additional value-added objectives that are useful but not critical. Section 4 presents protocols and capabilities that relate to, or can play a role in, the objectives in Section 2. Finally, Section 5 presents two scenarios that exist now or are being deployed in the near term over IP networks 👑 These aren't all-inclusive, and they're not the only ones that can be articulated ([34] provides a more extensive discussion on the topology scenarios related to IP telephony). But these scenarios do show where some of the protocols in Section 4 apply, and where some don't.
Last but not least, this document focuses on the IP layer and above. Specific operational procedures for Network Operation Centers (NOC) or Network Information Centers (NIC) are outside its scope 💀 So is everything below IP (the "bits"), other specific technologies, and service-level agreements between ISPs and telephony carriers regarding dedicated links 🫶
2. Objective 🎯
The objective of this document is to present a framework that describes how various protocols and capabilities (or mechanisms) can facilitate and support traffic from ETS users 💖 In several cases, we give a bit of background in each area so the reader has some context and a deeper understanding. We also discuss aspects of a given protocol or capability that could be explored and potentially advanced to support ETS 🔥 This exploration isn't to be confused with specific solutions, since we don't spell out exactly what must be done (e.g., a new header field, or a new code point).
3. Considerations 🧠
When producing a solution, or examining existing protocols and mechanisms, there are some things to keep in mind. One is that inter-domain ETS communications should not rely on ubiquitous or even widespread support along the path between the endpoints 🌸 Potentially, at the network layer, there may be islands of support in the form of overlay networks. There may also be cases where solutions are constrained on an end-to-end basis (i.e., at the transport or application layer). This diversity and possibly partial support is what needs to be taken into account by anyone designing and deploying ETS-related solutions 🦋
Another thing to consider is that there are existing architectures and protocols from other standards bodies that support emergency-related communications. Interoperating with these systems, presumably through gateways or similar nodes running IETF protocols, would foster a need to distinguish ETS flows from other flows 🧚 One reason would be the scenario of triggering ETS service from an IP network.
Finally, we take into consideration the requirements of [35, 36] when discussing the protocols and mechanisms in Section 4 below. We don't make a one-to-one mapping of protocol discussion a requirement. Instead, we make sure the discussion in Section 4 doesn't violate any of the requirements in [35, 36] 💅
4. Protocols and Capabilities ✨
In this section, we take the objectives presented above and present a set of protocols and capabilities that can be used to achieve them 🎀 Since the objectives are mostly atomic in nature, the measures used to address them should be viewed separately, with no specific dependency on each other as a whole. Various protocols and capabilities may be complementary to each other, but there's no need for all of them to exist, depending on the scenario of operation. ETS support is also not expected to be an ubiquitously available service 😭 We divide this section into 5 areas:
- Signaling
- Policy
- Traffic Engineering
- Security
- Routing
4.1. Signaling and State Information 📡
Signaling is used to convey various information to either intermediate nodes or end nodes 💜 It can be out-of-band of a data flow, and thus in a separate flow of its own, such as SIP messages. It can also be in-band, as part of the state information in a datagram containing the voice data. This latter example could be realized in the form of diff-serv code points in the IP packet 🌈
In the following subsections, we discuss the current state of some protocols and how they're used to support ETS. We also discuss potential augmentations to different types of signaling and state information that could help support the distinction of emergency-related communications in general ✨
4.1.1. SIP 📞
When it comes to application-level signaling for IP telephony, we focus our attention on the Session Initiation Protocol (SIP) 🦋 Currently, SIP has an existing priority field in the Request-Header-Field that distinguishes different types of sessions. The five values currently defined are "emergency", "urgent", "normal", "non-urgent", and "other-priority". These values are meant to convey importance to the end-user and have no additional semantics associated with them 🙈
[14] is an RFC that defines the requirements for a new header field for SIP related to resource priority ✨ The requirements are meant to lead to a means of providing an additional measure of distinction that can influence the behavior of gateways and SIP proxies 👑
4.1.2. Diff-Serv 🌸
In accordance with [15], the differentiated services code point (DSCP) field is divided into three sets of values 💖 The first set is assigned by IANA. Within this set, there are currently three types of Per Hop Behaviors that have been specified: Default (correlating to best effort forwarding), Assured Forwarding, and Expedited Forwarding 🔥 The second set of DSCP values is set aside for local or experimental use. The third set of DSCP values is also set aside for local or experimental use, but may later be reassigned to IANA if the first set has been completely assigned 🧠
One approach discussed on the IEPREP mailing list is specifying a new Per-Hop Behaviour (PHB) for emergency-related flows 💅 The logic is that it would provide a baseline for defining specific code points for various emergency-related traffic: authorized emergency sessions (e.g., ETS), general public emergency calls (e.g., "911"), Multi-Level Precedence and Preemption (MLPP) [19], and so on. But to define a new set of code points, a forwarding characteristic also has to be defined. In other words, you can't just identify a set of bits without defining what they mean (e.g., the drop precedence approach of Assured Forwarding) 😭 The one caveat is the set of DSCP bits set aside for experimental purposes. But as the name implies, experimental is for internal examination and use, not for standardization 🙈
Note: It's important to note that when this document was written, the IETF had been taking a conservative approach to specifying new PHBs 🫶 This is because the number of code points that can be defined is relatively small, and it's understandably considered a scarce resource. So the possibility of a new PHB being defined for emergency-related traffic is, at best, a long-term project that may or may not be accepted by the IETF 💀 In the near term, we'd initially suggest using the Assured Forwarding (AF) PHB [18] for distinguishing emergency traffic from other types of flows ✨ At a minimum, AF could be used for the different SIP call signaling messages. If the Expedited Forwarding (EF) PHB [40] is also supported by the domain, then it would be used for IP telephony data packets. Otherwise, another AF class would be used for those data flows 🌈
4.1.3. Variations Related to Diff-Serv and Queuing 🎀
okay so scheduling mechanisms like Weighted Fair Queueing and Class Based Queueing are used to carve out a percentage of the output link bandwidth for each class, assuming every queue is backlogged 🫶 the whole point is managing the rates and delays each class experiences. but bestie, emergency traffic doesn't necessarily need QoS to perform any better or differently than non-emergency traffic 💅 it may just need a higher probability of being forwarded to the next hop, and that could be done simply by dropping precedences within a class ✨
to do preferential dropping between classes (one of which is emergency traffic), you'd probably need a more advanced form of Active Queue Management (AQM) 🔥 right now, current implementations use one overall queue fill measurement to make decisions, and ngl that might end up dropping emergency-classified packets 💀 one new AQM idea is a Multiple Average-Multiple Threshold approach, instead of the Single Average-Multiple Threshold approach we use today 🦋 this lets you create drop probabilities by counting the packets in the queue for each drop precedence individually 😭
so it could be possible to use the current set of AF PHBs if each class were reasonably homogenous in its traffic mix 🌸 but one might still need to tell apart three drop precedences within non-emergency traffic 👑 if so, more drop precedences could be implemented. also, if you wanted discrimination within emergency traffic, like MLPP's five levels of precedence, more drop precedences might be considered too 🧚 those five levels would also line up with a recent effort in Study Group 11 of the ITU to define 5 levels for Emergency Telecommunications Service 🌈
4.1.4. RTP ⭐
okay so the Real-Time Transport Protocol (RTP) is the one that delivers end-to-end data with real-time characteristics 🎧 the data is usually audio or video, and it's often interactive 💖 RTP is typically run over UDP and has a fixed header that identifies a specific type of payload, representing a specific form of application media 🦋 the RTP designers also assumed an underlying network giving best effort service, so RTP doesn't provide any mechanism to ensure timely delivery or any other QoS guarantees 😭 but applications like IP telephony, plus new service models, mean RTP traffic may now be forwarded over networks that support better than best effort service 🔥 so RTP's original scope has expanded to include networks providing services other than best effort 👑
back in 4.1.2 we talked about one means of marking a data packet for emergencies under the diff-serv architecture 🧁 but we also pointed out that diff-serv markings for specific PHBs aren't globally unique, and they may be arbitrarily removed or even changed by intermediary nodes or domains 💀 so for emergency related data packets, we're still missing an in-band marking that stays constant on an end-to-end basis 🥺
there are three choices for defining a persistent marking of data packets, which avoids the transitory diff-serv code points 🌟 you could propose a new PHB dedicated to emergency type traffic (as discussed in 4.1.2), or you could propose a new shim layer protocol at some location above IP, or you could add a new specification to an existing application layer protocol. the first two are probably the "cleanest" architecturally 💅 but they're long term efforts that may never come to pass, because there are a limited number of diff-serv code points and people are worried that yet another shim layer would make the IP stack too large 😩 the third option, placing a marking in an application layer packet, also has drawbacks; the key weakness is that it means specifying a marking on a per-application basis 🙈
the Audio/Visual Transport (AVT) working group has discussed augmenting RTP so it can carry a marking that tells emergency-related traffic apart from everything else 📣 specifically, these discussions centered on a new extension with a "classifier" field showing the condition of the packet (e.g., authorized-emergency, emergency, normal) [26] 🎀 the rationale was that focusing on RTP would give you a point of aggregation that applies to all payloads it encapsulates ✨ but the AVT group has a rough consensus that they don't wish to advance placing an additional classifier state in the RTP header to denote the importance of one flow over another 🙅♀️ objections ranged from relying on SIP to convey the importance of a flow, to the possibility of adversely affecting header compression. there was also the general feeling that the extension header for RTP that acts as a signal should not be used 🫠
4.1.5. GCP/H.248 🌸
okay so the Gateway Control Protocol (GCP) [21] defines the interaction between a media gateway and a media gateway controller 📞 [21] is viewed as an updated version of common text with ITU-T Recommendation H.248 [41], and it's the result of applying the changes of RFC 2886 (Megaco Errata) [43] to the text of RFC 2885 (Megaco Protocol version 0.8) [42] 🧚
in [21], the protocol specifies a Priority and Emergency field for a context attribute and descriptor 🎀 the Emergency is an optional boolean (True or False) condition. the Priority value, which ranges from 0 through 15, specifies the precedence handling for a context 🔢
the protocol doesn't specify individual values for priority. we also do not recommend defining a well known value for the GCP priority, since that's out of scope for this document 🙅♀️ any values set should be a function of any SLAs that have been established regarding the handling of emergency traffic 📜
4.2. Policy 👑
okay, policy is where it gets a little spicy 🌶️ one of the objectives listed in Section 3 above is to treat ETS signaling, and related data traffic, as non-preemptive in nature 🫶 and this treatment is supposed to be the default mode of operation or service. the reason is that existing regulations or laws in certain countries governing how SLAs get established may not allow preemptive actions (e.g., dropping existing telephony flows) 😬 on the other hand, the laws and regulations of other countries influencing the specification of SLA(s) may allow preemption, or even require it to exist 🤯 given that disparity, we rely on local policy to determine how much emergency-related traffic affects the existing traffic load of a given network or ISP 💅
Important note: we reiterate our earlier comment that laws and regulations are generally outside the scope of the IETF and its specification of designs and protocols 🙈 however, these constraints can be used as a guide in producing a baseline capability to be supported. in our case, that's a default policy for non-preemptive call establishment of ETS signaling and data ✨
policy can be static information embedded in various components (e.g., SIP servers or bandwidth brokers), or it can be realized and supported via COPS with respect to allocation of a domain's resources [16] 🧁 there's no requirement on how policy gets accomplished. instead, if a domain takes actions outside the default non-preemptive action of ETS-related communication, then we stipulate that some type of policy mechanism be in place to satisfy the local policies of an SLA established for ETS-type traffic 🫡
4.3. Traffic Engineering 🚦
so when a network operates under SLA constraints, and one or more of them pertain to ETS-based traffic, you can expect some form of traffic engineering to be applied to the network 🛣️ we don't make any recommendations about which type of traffic engineering mechanism gets used. we only care that such a system exists in some form and can distinguish and support ETS signaling and/or data traffic 💖 we do recommend that clients and prospective providers of ETS service review [32], which gives an overview and a set of principles of Internet traffic engineering 📚
MPLS is generally the first protocol that comes to mind when traffic engineering comes up 🧠 that thought gets even louder for IP telephony, because MPLS can permit a quasi-circuit switching capability to be superimposed on the current Internet routing model [30] 🦋
but having said that, MPLS is an intradomain protocol, so it may or may not exist within a given ISP 🤷♀️ other forms of traffic engineering, such as weighted OSPF, may be the mechanism of choice for an ISP 🌸
as a counter example of using a specific protocol to achieve traffic engineering, [37] presents an ISP relying on a high amount of overprovisioning within its core to handle potentially dramatic spikes or bursts of traffic load 😮 in that approach, any configuring of queues for specific customers (neighbors) to support the target QoS is done on the egress edge of the transit network 🧚
Note: as a point of reference, existing SLAs established by the NCS for GETS service tend to focus on a loosely defined maximum allocation of, for example, 1% to 10% of calls allowed to be established through a given LEC using HPC 📊 it's expected, and encouraged, that ETS related SLAs of ISPs will be limited with respect to the amount of traffic distinguished as being emergency related and initiated by an authorized user 🫶
4.4. Security 🔐
this section provides a brief overview of the security issues raised by ETS support 👀
4.4.1. Denial of Service 💀
Okay so, any network mechanism that gives a higher priority to a specific set of flows could get abused to make denial of service (DoS) attacks way more effective 😭. Priority would amplify the effect of attack traffic on bandwidth availability in lower-capacity links, and make it more likely to actually reach its target(s). An attack could also tie up resources like circuits in a PSTN gateway 🙈.
Any provider deploying a priority mechanism (like the QoS systems from Section 4.1) MUST therefore carefully apply the associated access controls and security mechanisms 🔒. For example, the priority level for traffic coming from an unauthorized part of a network or ingress point SHOULD be reset to normal. Users MUST also be authenticated before they can use a priority service (see Section 4.4.2). However, this authentication process SHOULD be lightweight to minimise opportunities for denial of service attacks on the authentication service itself, and ideally SHOULD include its own anti-DoS mechanisms ✨. Other security mechanisms MAY impose an overhead that SHOULD be carefully considered, so they don't create other opportunities for DoS attacks.
As mentioned in Section 4.3, SLAs for ETS facilities often contain maximum limits on the level of ETS traffic that SHOULD be prioritised in a particular network (say 1% of the maximum network capacity). This SHOULD also be the case in IP networks, to again reduce the level of resources that a denial of service attack can consume 📉.
As of this writing, a typical inter-provider IP link uses 1 Gbps Ethernet, OC-48 SONET/SDH, or some similar or faster technology. Also, as of this writing, it is not practical to deploy per-IP packet cryptographic authentication on such inter-provider links 😩, although such authentication might well be needed to provide assurance of IP-layer label integrity in the inter-provider scenario.
While Moore's Law will speed up cryptographic authentication, it is unclear whether that is helpful, because the speed of the typical inter-domain link is also increasing rapidly 🚀.
4.4.2. User Authorization 🎟️
To prevent theft of service and reduce the opportunities for denial of service attacks, it is essential that service providers properly verify the authorization of a specific traffic flow before providing it with ETS facilities 🫶.
Where an ETS call is carried from PSTN to PSTN via one telephony carrier's backbone IP network, very little IP-specific user authorization support is required. The user authenticates itself to the PSTN as usual, for example using a PIN in the US GETS 📞. The gateway from the PSTN connection into the backbone IP network MUST be able to signal that the flow has an ETS label. Conversely, the gateway back into the PSTN MUST similarly signal the call's label. A secure link between the gateways MAY be set up using IPSec or SIP security functionality, to protect the integrity of the signaling information against attackers who have gained access to the backbone network, and to prevent such attackers from placing ETS calls using the egress PSTN gateway 🛡️. If the destination of a call is an IP device, the signaling SHOULD be protected directly between the IP ingress gateway and the end device.
When ETS priority is being provided to a flow within one domain, that network MUST use the security features of the priority mechanism being deployed, to ensure that the flow has originated from an authorized user or process 👀.
The access network MAY authorize ETS traffic over a link as part of its user authentication procedures. These procedures MAY occur at the link, network, or higher layers, but they are at the discretion of a single domain network. That network MUST decide how often it should update its list of authorized ETS users, based on the bounds it is prepared to accept on traffic from recently-revoked users ⏰.
If ETS support moves from intra-domain PSTN and IP networks to inter-domain end-to-end IP, verifying the authorization of a given flow becomes more complex 😵💫. The user's access network MUST verify a user's ETS authorization if network-layer priority is to be provided at that point.
Administrative domains that agree to exchange ETS traffic MUST have the means to securely signal to each other a given flow's ETS status 🤝. They MAY use physical link security combined with traffic conditioning measures to limit the amount of ETS traffic that MAY pass between the two domains. This agreement MUST require the originating network to take responsibility for ensuring that only authorized traffic is marked with ETS priority, but the recipient network cannot rely on this happening with 100% reliability 💀. Both domains SHOULD perform conditioning to prevent the propagation of theft and denial of service attacks. Note that administrative domains that agree to exchange ETS traffic MUST deploy facilities that perform these conditioning and security services at every point at which they interconnect with one another 🚧.
Processes using application-layer protocols, such as SIP, SHOULD use the security functionality in those protocols to verify the authorization of a session before allowing it to use ETS mechanisms. 🔐
4.4.3. Confidentiality and Integrity 🤫
When ETS communications are being used to respond to a deliberate attack, it is important that they cannot be altered or intercepted to make the situation worse 😱. For example, someone could change the orders to first responders such as firefighters, or use knowledge of the emergency response to cause further damage. Nobody wants that.
The integrity and confidentiality of such communications SHOULD therefore be protected as far as possible using end-to-end security protocols such as IPSec, or the security functionality in SIP and SRTP [39] 🔏. Where communications involve other types of networks such as the PSTN, the IP side SHOULD be protected, and any security functionality available in the other network SHOULD be used.
4.5. Alternate Path Routing 🛣️
This subject involves the ability to discover and use a different path to route IP telephony traffic around congestion points, and thus avoid them 🚦. Ideally, the discovery process would be accomplished in an expedient manner (possibly even a priori to the need for it). At this level, we make no assumptions about how the alternate path is accomplished, or even at which layer it is achieved, e.g., the network versus the application layer 🤷♀️. But this kind of capability, at least in a minimal form, would help increase the probability of ETS call completion by making use of noncongested alternate paths. We use the term "minimal form" to emphasize the fact that care must be taken in how the system provides alternate paths, so that it does not significantly contribute to the congestion that is meant to be avoided (e.g., via excess control/discovery messages) 🙅♀️.
Routing protocols at the IP network layer, such as BGP and OSPF, contain mechanisms for determining link failure between routing peers. The discovery of this failure automatically causes information to be propagated to other routers 📡. The form of this information, the extent of its propagation, and the convergence time in determining new routes depend on the routing protocol in use. In the example of OSPF's Equal Cost Multiple Path (ECMP), the impact of link failure is minimized because of pre-existing alternate paths to a destination 💅.
At the time this document was written, we can identify two additional areas in the IETF that can be helpful in providing alternate paths for the specific case of call signaling 🧚. The first is [9], which is focused on network layer routing and describes a framework for enhancements to the LDP specification of MPLS to help achieve fault tolerance. This, in itself, does not provide alternate path routing, but rather helps minimize loss in intradomain connectivity when MPLS is used within a domain.
The second effort comes from the IP Telephony working group and involves Telephony Routing over IP (TRIP) 🎀. To date, a framework document [17] has been published as an RFC that describes the discovery and exchange of IP telephony gateway routing tables between providers. The TRIP protocol [20] specifies application-level telephony routing regardless of the signaling protocol being used (e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises reachability and attributes of destinations. In its current form, several attributes have already been defined, such as LocalPreference and MultiExitDisc, and additional attributes can be registered with IANA 🌸.
Inter-domain routing is not an area that SHOULD be considered in terms of additional alternate path routing support for ETS 🙃. The Border Gateway Protocol is currently strained in meeting its existing requirements, so adding features that would generate an increase in advertised routes will not be well received by the IETF 😮💨. Refer to [38] for a commentary on Inter-Domain routing.
4.6. End-to-End Fault Tolerance 🧯
This topic involves work that has been done to compensate for lossy networks providing best effort service. In particular, we focus on the use of a) Forward Error Correction (FEC), and b) redundant transmissions that can be used to compensate for lost data packets. (Note that our aim is fault tolerance, as opposed to an expectation of always achieving it 💖.)
In the former case, additional FEC data packets are constructed from a set of original data packets and inserted into the end-to-end stream. Depending on the algorithm used, these FEC packets can reconstruct one or more of the original set that were lost by the network. An example may be in the form of a 10:3 ratio, in which 10 original packets are used to generate three additional FEC packets. Thus, if the network loses 30% of packets or less, then the FEC scheme will be able to compensate for that loss 🧮. The drawback to this approach is that, to compensate for the loss, a steady state increase in offered load has been injected into the network. This makes an argument that the act of protection against loss has contributed to additional pressures leading to congestion, which in turn helps trigger packet loss 😤. In addition, by using a ratio of 10:3, the source (or some proxy) MUST "hold" all 10 packets in order to construct the three FEC packets. This contributes to the end-to-end delay of the packets, as well as minor bursts of load, in addition to changes in jitter ⏳.
The other form of fault tolerance we discuss involves the use of redundant transmissions. By this we mean the case in which an original data packet is followed by one or more redundant packets. At first glance, this would appear to be even less friendly to the network than adding FEC packets 🙀. However, the encodings of the redundant packets can be of a different type (or even transcoded into a lower quality) that produce redundant data packets significantly smaller than the original packet 🌈.
Two RFCs [22, 23] have been produced that define RTP payloads for FEC and redundant audio data. An implementation example of a redundant audio application can be found in [13]. We note that both FEC and redundant transmissions can be viewed as rather specific, and to a degree tangential, solutions regarding packet loss and emergency communications. Hence, these topics are placed under the category of value-added objectives 👑.
5. Key Scenarios ✨
okay so bestie, there are a bunch of ways IP telephony can actually show up, and each one can come with its own pile of functional requirements 🧚 some might only need a subset of the stuff we listed earlier. and ngl, there could be a scenario we didn't list at all 🙈 we're not trying to cover every single possible setup for emergency IP telephony, that would be way too much. instead we're keeping it focused with one guideline: we assume there's signaling and data going back and forth between the PSTN and the IP network to support emergency-related calls. this doesn't mean IP-only end-to-end is off the table 💅 it just means the PSTN is in the picture too, and that's the form of voice communication that's basically running the show right now 👑
Note: as stated in Section 1.2, [32] has a much bigger list of places IP telephony can be deployed 📚 the scenarios we picked here are just a couple of examples of how the protocols and capabilities from Section 3 can come into play 🎀
5.1. Single IP Administrative Domain
this one is basically the PSTN glow-up 🌸 picture data networks showing up as a backbone that connects PSTN switches sitting at its edges. this scenario is one isolated IP administrative domain with no directly adjacent IP domains plugged into it. here's Figure 1 so you can see the vibe 👇 there are two kinds of telephony carriers in this one. the legacy carrier still has the classic PSTN switching setup (very vintage 🕰️). then there's the next generation carrier, which uses a data network like IP as its core and has Signaling Gateways at its edges. those gateways "speak" SS7 to peering carriers on the outside, and they talk another protocol like SIP on the inside, riding right on top of the IP infrastructure 💜
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * ISUP * *
SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG
* * (SS7) * (SIP) * (SS7) * (SIP) *
******* *************** **************
SW - Telco Switch, SG - Signaling Gateway
Figure 1the big deal here is that all the resources of each IP "island" fall under one administrative authority 🏝️ so keeping PSTN-type QoS for voice traffic (both data and signaling) as it leaves the IP network isn't a problem. that means the need for stuff like diff-serv, especially when the network is overprovisioned, and the need to expand the defined set of Per-Hop Behaviors both drop off in this scenario 📉 low-key chill 😌
security is also not a huge priority inside the closed IP environment of Figure 1 🔒 each administrative domain peers with the others as part of the PSTN, so the existing security (Personal Identification Number (PIN) authentication, in the context of telephony infrastructure protection) is the default scope. real talk, we are NOT saying PIN-based security is super secure or even something you'd want 🙃 we're just using it as the default so we don't pile extra requirements onto existing authorized emergency telephony systems. it's a whole vibe of "don't fix what isn't broken" 🫶
5.2. Multiple IP Administrative Domains
okay so this scenario is basically a superset of the last one 💖 we still keep the idea that the IP telephony system peers with the existing PSTN. on top of that, segments (aka portions of the Internet) can swap signaling with other IP administrative domains using non-PSTN signaling protocols like SIP 🦋 here's Figure 2 🎀
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * * *
SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG
* * (SS7) * (SIP) * (SIP) * (SIP) *
******* *************** **************
SW - Telco Switch
SG - Signaling Gateway
Figure 2now that there are multiple IP domains, and SLAs for ETS traffic might exist between them, the need for something like diff-serv gets way bigger 📈 it's how you tell emergency traffic apart from everything else. also, IP security matters a LOT more between domains 🔐 it's what makes sure that the act of spotting ETS-type traffic is actually legit for the source it came from. no cap, this part is serious 😤
we're wrapping up this section by mentioning a related work in progress that's giving ISUP transparency across SS7-SIP interworking [33] 💅 the goal is to get access to services in the SIP network while still keeping end-to-end PSTN services transparent. iconic energy 👑
not every service gets mapped (that's the design goal of [33]), so we expect we'll need another document to specify the mapping between new SIP labels and existing PSTN code points like NS/EP and MLPP 🧩 that's a future us problem, periodt 💜
6. Security Considerations 🔐
Information on this topic is presented in sections 2 and 4. 🫶
7. Informative References ✨
Okay bestie, this is the reading list 📚🎀 Every doc here is a source the spec leans on, so I've kept each entry word for word, exactly as the original has it, so nothing gets lost.
[1] Braden, R., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[2] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[3] Shenker, S., Partridge, C., and R. Guerin, "Specification of
Guaranteed Quality of Service", RFC 2212, September 1997.
[4] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[5] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
[6] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
2961, April 2001.
[7] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, "An Architecture for Differentiated Service", RFC 2475,
December 1998.
[8] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,
Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label
Switching (MPLS) Support of Differentiated Services", RFC 3270,
May 2002.
[9] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol
Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[10] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[12] ANSI, "Signaling System No. 7(SS7), High Probability of
Completion (HPC) Network Capability", ANSI T1.631-1993, (R1999).
[13] Robust Audio Tool (RAT): http://www-
mice.cs.ucl.ac.uk/multimedia/software/rat
[14] Schulzrinne, H., "Requirements for Resource Priority Mechanisms
for the Session Initiation Protocol (SIP)", RFC 3487, February
2003.
[15] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[16] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A.
Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 2000.
[17] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony
Routing over IP", RFC 2871, June 2000.
[18] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[19] ITU, "Multi-Level Precedence and Preemption Service, ITU,
Recommendation, I.255.3, July, 1990.
[20] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
over IP (TRIP)", RFC 3219, January 2002.
[21] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
Control Protocol Version 1", RFC 3525, June 2003.
[22] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
for Redundant Audio Data", RFC 2198, September 1997.
[23] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[24] ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-
2000, 2000.
[25] "Description of an International Emergency Preference Scheme
(IEPS)", ITU-T Recommendation E.106 March, 2002
[26] Carlberg, K., "The Classifier Extension Header for RTP", Work In
Progress, October 2001.
[27] National Communications System: http://www.ncs.gov
[28] Bansal, R., Ravikanth, R., "Performance Measures for Voice on
IP", http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-
voiceip/, IETF Presentation: IPPM-Voiceip, Aug, 1997
[29] Hardman, V., et al, "Reliable Audio for Use over the Internet",
Proceedings, INET'95, Aug, 1995.
[30] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", RFC
2702, September 1999.
[31] "Service Class Designations for H.323 Calls", ITU Recommendation
H.460.4, November, 2002.
[32] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao,
"Overview and Principles of Internet Traffic Engineering", RFC
3272, May 2002.
[33] Vemuri, A. and J. Peterson, "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", BCP 63, RFC
3372, September 2002.
[34] Polk, J., "Internet Emergency Preparedness (IEPREP) Telephony
Topology Terminology", RFC 3523, April 2003.
[35] Carlberg, K. and R. Atkinson, "General Requirements for
Emergency Telecommunication Service (ETS)", RFC 3689, February
2004.
[36] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for
Emergency Telecommunication Service (ETS)", RFC 3690, February
2004.
[37] Meyers, D., "Some Thoughts on CoS and Backbone Networks"
http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf IETF
Presentation: IEPREP, Dec, 2002.
[38] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[39] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[40] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J.,
Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March
2002.
[41] ITU, "Gateway Control Protocol", Version 3, ITU, September,
2005.
[42] Cuervo, F., Greene, N., Huitema, C., Rayhan, A., Rosen, B., and
J. Segers, "Megaco Protocol version 0.8", RFC 2885, August 2000.
[43] Taylor, T., "Megaco Errata", RFC 2886, August 2000.Appendix A: Government Telephone Preference Scheme (GTPS) 💜
Okay so this framework doc uses the T1.631 and ITU IEPS standard as its target model 🎯 for building a framework that supports authorized emergency-related communication inside IP telephony. It also takes notes from GETS, which is a super helpful model to learn from 📖 The reason it looks at so many areas is that the problem goes from the application layer all the way down to the (inter)network layer, and it also has to cover policy, security (authorized access), and traffic engineering. That's a LOT, but it's giving thorough 💅
Now the UK has its own thing: the Government Telephone Preference Scheme, or GTPS 🇬🇧 Right now it only covers a subset of the local loop lines in the UK. Those lines are split into Categories 1, 2, and 3. The first two are for authorized personnel who handle emergencies like natural disasters 🚑 Category 3 is the general public. Priority marks sent over C7/NUP are what let a call get past call-gapping for a given Category 🔥 And the power to switch GTPS on can belong to either a central authority or a delegated one 👑
A.1. GTPS and the Framework Document
Here's the tea 🫖 The current GTPS works by giving preference based on physical, static devices, so a bunch of the stuff in this document just isn't needed for it 🙈 BUT the one part that can really line up is the labeling capability of the proposed Resource Priority extension to SIP 🎀 A brand-new label mechanism for SIP could allow transparent interoperation between IP telephony and the U.K. PSTN that supports GTPS. Main character energy for interop 🦋
Appendix B: Related Standards Work 🌈
So the process of defining labels to tell calls apart has been going on in other standards groups, and it's still going 🧚 Like mentioned in Section 1.1.1, the ANSI T1S1 group already defined a label in the SS7 ISUP Initial Address Message. That single label or value is called the National Security and Emergency Preparedness (NS/EP) indicator, and it's part of the T1.631 standard. The subsections below are a quick snapshot of the parallel efforts happening in other standards groups 👀
Also, it's worth noting that the recent work in those other groups has gravitated toward defining 5 labels or levels of priority ✨ The impact on this ETS framework document is minimal, honestly, because it just means defining a matching set of labels for the resource priority header of SIP 💖
B.1. Study Group 16 (ITU)
Study Group 16 (SG16) of the ITU handles studies about multimedia service definition and multimedia systems, including protocols and signal processing 🎬
A contribution [31] was accepted by this group, and it adds a Priority Class parameter to the call establishment messages of H.323 🔥 This class gets split into two parts: one is the Priority Value, and the other is a Priority Extension for indicating subclasses. The former part is the one that roughly matches the labels carried in the Resource Priority field for SIP [14] 💅
The draft recommendation suggests defining PriorityClass information that would be carried in the GenericData parameter in the H323-UU-PDU or RAS messages. The GenericData parameter holds PriorityClassGenericData, and the PriorityClassInfo of that holds the Priority and Priority Extension fields 🫶
Right now, 4 levels have been defined for the Priority Value part of the Priority Class parameter: Normal, High, Emergency-Public, Emergency-Authorized 💜 There's also an extra 8-bit priority extension for subclasses of service at each priority 🍓 The suggested ASN.1 definition of the service class looks like this:
CALL-PRIORITY {itu-t(0) recommendation(0) h(8) 460 4 version1(0)}
DEFINITIONS AUTOMATIC TAGS::=
BEGIN
IMPORTS
ClearToken,
CryptoToken
FROM H235-SECURITY-MESSAGES;
CallPriorityInfo::= SEQUENCE
{
priorityValue CHOICE
{
emergencyAuthorized NULL,
emergencyPublic NULL,
high NULL,
normal NULL,
...
},
priorityExtension INTEGER (0..255) OPTIONAL,
tokens SEQUENCE OF ClearToken OPTIONAL,
cryptoTokens SEQUENCE OF CryptoToken OPTIONAL,
rejectReason CHOICE
{
priorityUnavailable NULL,
priorityUnauthorized NULL,
priorityValueUnknown NULL,
...
} OPTIONAL, -- Only used in CallPriorityConfirm
...
}The big advantage of using the GenericData parameter is that an existing parameter gets reused, instead of defining a new one and causing later changes to existing H.323/H.225 documents 🧠✨
Acknowledgements 🫶
The authors want to thank Stu Goldman, James Polk, Dennis Berg, and Ran Atkinson for their helpful comments, opinions, and clarifications, along with everyone who chimed in on the IEPS and IEPREP mailing lists 💌 Extra thanks to Peter Walker of Oftel for private chats about how GTPS works, and to Gary Thom for clarifying the SG16 draft contribution 🌸
Authors' Addresses 🎀
okay so bestie, here are the three legends who wrote this 🫶 all from UCL and UMKC, so you know they're brainy ✨
Ken Carlberg
University College London
Department of Computer Science
Gower Street
London, WC1E 6BT
United Kingdom
EMail: k.carlberg@cs.ucl.ac.uk
Ian Brown
University College London
Department of Computer Science
Gower Street
London, WC1E 6BT
United Kingdom
EMail: I.Brown@cs.ucl.ac.uk
Cory Beard
University of Missouri-Kansas City
Division of Computer Science
Electrical Engineering
5100 Rockhill Road
Kansas City, MO 64110-2499
USA
EMail: BeardC@umkc.eduFull Copyright Statement 💅
okay the legal bit, but make it cute 🙈 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.
So this doc is provided "AS IS", and honestly the contributor, the org they represent or are sponsored by (if any), the Internet Society and the Internet Engineering Task Force are all like "no promises." They 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 is not picking a side on whether any IP rights might cover the tech in this doc, or whether you could get a license for it. It also doesn't claim it went looking for those rights 🤷♀️ If you want the details on how rights work for RFC docs, check out BCP 78 and BCP 79 ✨
IPR disclosures that were made to the IETF Secretariat, plus any assurances of licenses, or the results of trying to get a general license or permission for implementers or users to use the proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed 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: rfc4190 2005-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms