RFC 4958

A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain

📅 published July 2007, from ietf

Bestie, okay so this is RFC 4958 🎀✨

It's titled A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain 💖. It came out of the Network Working Group, it's by K. Carlberg from G11, and it's dated July 2007. It's Informational, so it's here to give context, not to set a standard 🧚. The title block doesn't list anything it obsoletes or updates, so it isn't replacing or patching any other RFC 💅.

1. Introduction ....................................................3
   1.1. Differences between Single and Inter-Domain ................3
2. Common Practice: Provisioning ...................................4
3. Objective .......................................................5
   3.1. Scenarios ..................................................5
4. Topic Areas .....................................................6
   4.1. MPLS .......................................................6
   4.2. RSVP .......................................................7
        4.2.1. Relation to ETS .....................................8
   4.3. Policy .....................................................8
   4.4. Subnetwork Technologies ....................................9
        4.4.1. IEEE 802.1 VLANs ....................................9
        4.4.2. IEEE 802.11e QoS ...................................10
        4.4.3. Cable Networks .....................................10
   4.5. Multicast .................................................11
        4.5.1. IP Layer ...........................................12
        4.5.2. IEEE 802.1d MAC Bridges ............................12
   4.6. Discovery .................................................13
   4.7. Differentiated Services (Diffserv) ........................14
5. Security Considerations ........................................14
6. Summary Comments ...............................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
   8.1. Normative Reference .......................................15
   8.2. Informative References ....................................15

Status of This Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The IETF Trust (2007).

Abstract 🌸

This doc is a framework that looks at the different protocols and mechanisms that could be candidates for supporting Emergency Telecommunication Services (ETS) inside a single administrative domain. It talks about how they could be used and how they're deployed right now, so the reader gets the full picture 🦋. It does not present specific solutions, bestie.

1. Introduction ✨

So this doc is a framework for supporting Emergency Telecommunications Services (ETS) within the scope of a single administrative domain. That narrow scope gives us a reference point for thinking about which protocols could be deployed to support ETS 🎯. [rfc4375] is the complementary effort, and it lays out requirements for a single administrative domain. It defines that domain as "collection of resources under the control of a single administrative authority". We use that other effort as both our starting point and our guide for this doc 💜.

There's also a different framework for ETS, [rfc4190], which focused on ETS within IP telephony. Its focal point was one particular application whose flows could span multiple autonomous domains 📞. This doc has a somewhat more constrained view than [rfc4190], but we can still expect some overlap in the areas we talk about 🫶.

1.1. Differences between Single and Inter-Domain 🧩

Before we get into the next sections, it helps to know the key differences between the single and inter-domain cases. Here's the general starting point 👑:

  • a) Lined up with the physical topology of resources, each domain is an authority zone, and right now there's no scalable way to transfer authority between zones.
  • b) Each authority zone is under separate management.
  • c) Authority zones are run by competitors, which is a further deterrent to transferring authority 🙈.

Because of (a) through (c) above, a few more observations can be made that separate the single and inter-domain cases:

  • d) Different policies might be implemented in different administrative domains.
  • e) There's no practical method for ingress nodes of a transit domain to authenticate all of the IP network layer packets that have labels indicating a preference or importance. Not ideal 😭.
  • f) Given item (d) above, all current inter-domain QoS mechanisms at the network level generally create easily exploited and significantly painful Denial of Service (DoS) / Distributed Denial of Service (DDoS) attack vectors on the network 💀.
  • g) A single administrative domain can deploy various mechanisms (e.g., access control lists) into each and every edge device (e.g., ethernet switch or router) to make sure that only authorized end-users (or layer 2 interfaces) are able to emit frames/packets with non-default QoS labels into the network 🔒. This isn't feasible in the inter-domain case because the inter-domain link contains aggregated flows. On top of that, distributing access control lists at the network level isn't scalable in the inter-domain case.
  • h) A single domain can deploy mechanisms into the edge devices to enforce its domain-wide policies, without having to trust any third party to configure things correctly 🥰. That isn't possible in the inter-domain case.

This list isn't all-inclusive, but it does give some rationale for why you might want to focus on the more constrained scenario of a single administrative domain 💅.

2. Common Practice: Provisioning 🍓

The IEPREP working group and mailing list have had extensive discussions about over-provisioning, and a lot of those conversations have debated whether we need QoS mechanisms or just over-provisioning of links 🤔.

Realistically, most IP network links are provisioned with some percentage of excess capacity beyond the average load. The 'shared' resource model, together with TCP's congestion avoidance algorithms, helps cover the cases where spikes or bursts of traffic hit the network 🌈.

The big question inside the IEPREP working group is whether it's always better to over-provision links enough that spikes in load can still be supported with no loss due to congestion. People on this side point to many ISPs in the US that do exactly that instead of using QoS mechanisms to honor agreements with their peers or customers 💸. They argue for cost effectiveness over the complexity and security issues tied to other approaches.

People arguing for QoS mechanisms say the relatively low cost of bandwidth enjoyed in the US (particularly by large ISPs) isn't necessarily available everywhere in the world 🌍. Beyond cost, some domains are made up of physical networks with a wide disparity in bandwidth capacity, e.g., attachment points connected to high capacity fiber and lower capacity wireless links 📡.

This doc doesn't pick a side. The author does recommend that network administrators/operators perform a cost analysis comparing over-provisioning for spikes against QoS mechanisms, both inside a domain and on its access link to another domain (e.g., a customer and its ISP) 🧮. That analysis, along with the policies and requirements of the administrative domain, should be the key to deciding how (or if) ETS gets supported in the domain ✨.

If the decision is to rely on over-provisioning, then some of the following sections will have little to no bearing on how ETS is supported within a domain. The exception would be labeling mechanisms used to convey information to other communication architectures (e.g., SIP-to-SS7/ISUP gateways) 🧚.

3. Objective 🎯

The main objective is to provide a target measure of service within a domain for flows that have been labeled for ETS. That level might be better than best effort, the best available service the network (or parts of it) can offer, or a specific percentage of resource set aside for ETS 💖. [rfc4375] lays out a set of requirements for hitting this objective.

This framework uses [rfc4375] as a reference point when it talks about existing areas of engineering work or protocols that can play a role in supporting ETS within a domain. Talking about these areas and protocols isn't the same as saying they exist in any given domain 🙅‍♀️. Instead, the subjects in Section 4 below are recognized candidates that can exist and could be used to help ETS users or data flows.

3.1. Scenarios 🗺️

The IEPREP mailing list and working group meetings have talked a lot about the operating environment of the ETS user. You can dream up tons of variations when it comes to underlying network technologies and applications, so instead of getting lost in hundreds of potential scenarios, we boil things down to two simple case examples 🧠.

  • (a) A user in their home network attempts to use or leverage any ETS capability within the domain.
  • (b) A user visits a foreign network and attempts to use or leverage any ETS capability within the domain.

We borrow the terms "home" and "foreign" network from Mobile IP [rfc3344]. Case (a) is the normal, and by far the most common, scenario on today's Internet 🏠. Case (b) can be supported simply by the Dynamic Host Configuration Protocol (DHCP) [rfc2131], or by a static set of addresses assigned to 'visitors' of the network 🧳. This is mostly operational in nature and depends heavily on that network's management and security policies.

A more ambitious way to support the mobile user is the Mobile IP (MIP) protocol 🚀. MIP offers a measure of application-transparent mobility, since a mobile host can move from one subnetwork to another while keeping the same stable IP address registered at a global anchor point. That feature may not always be available or in use, though. Wherever it is in use, at least some of the packets going to and from the mobile host go through the home network 🛣️.

4. Topic Areas 🌷

The topic areas below aren't presented in any particular order, and they don't follow any specific layering model. They're capabilities that may be found within an administrative domain, and a lot of them are topics of ongoing work at the IETF 🫧.

Readers shouldn't expect any of the following to exist within a domain for ETS users. In many cases, some of these areas have been standardized and widely used for years, while others have seen very limited deployment 🥹.

4.1. MPLS ✨

Okay so, Multiprotocol Label Switching (MPLS) is basically the first protocol everyone thinks of when traffic engineering comes up 🫶. MPLS signaling creates Labeled Switched Paths (LSPs) through a network of Label Switch Routers [rfc3031] 🛣️. When traffic hits the ingress boundary of an MPLS domain (which may or may not match up with an administrative domain), the packets get classified, labeled, scheduled, and forwarded along an LSP 💅.

[rfc3270] explains how MPLS can support Differentiated Services 🎀. It talks about using the 3-bit EXP (experimental) field to carry the Per Hop Behavior (PHB) that should be applied to the packet. As we'll see in later sections, this 3-bit field can be mapped to fields in several other protocols 🦋.

Classification, scheduling, and labeling are super symbiotic, so they often get bundled up with other protocols and architectures 💜. RSVP and Differentiated Services are two examples. Below, we look at several cases where a protocol specification or mechanism is known to be paired with MPLS 🧚. That includes the potential labels that may be associated with ETS 🚨. But MPLS is only one of several approaches to traffic engineering, so don't put all your eggs in that basket 🥚. Also, MPLS is complex enough in both its protocol and architecture that it may only be suited for large domains 🏰.

4.2. RSVP 🌸

The original RSVP design, along with the Integrated Services model, was all about end-to-end signaling 💖. The goal was to set up a path of reserved resources that spanned networks and administrative domains [rfc2205]. Honestly? RSVP hasn't really been widely deployed by network admins for QoS across domains 😭. Today, its limited deployment has mostly stayed inside the boundaries of a single domain, and usually alongside MPLS signaling 🫠. Early RSVP deployments ran into scaling issues nobody saw coming 💀, and it's not totally clear how well an RSVP approach would scale across the whole Internet 🌍.

[rfc3209] is an example of RSVP leveling up to work with efforts scoped inside a domain 📈. In this case, RSVP gets extensions that let it set up intra-domain Labeled Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) 🔥.

[rfc2750] adds extensions to RSVP so it can support generic policy-based admission control 👑. This goes beyond the POLICY_DATA object defined in [rfc3209] by defining how access and usage policies get controlled and enforced ✨. The standard doesn't push any one particular policy architecture, but the IETF has defined one that can complement [rfc2750] 🎀. We dig into that in Section 4.3 below 👀.

4.2.1. Relation to ETS 🚑

The ability to reserve resources is basically the ability to give preferential service to specifically classified traffic 🎟️. The classification is a tuple of one or more fields, which may or may not include an ETS-specific label 🏷️. When a tuple includes a label that's been defined for ETS usage, the reservation helps make sure an emergency-related flow gets forwarded toward its destination 🚀. Within the scope of this document, that means RSVP would be used to help forward traffic within a domain 🫡.

We want to note that this puts a lot of importance on defining a label and an associated field that RSVP-capable nodes can set and/or examine 🧐.

Another big observation: major vendor routers currently limit their field examination for classification to the network and transport layers 🙅‍♀️. So application layer labels will most likely get ignored by routers and switches 💀.

4.3. Policy 📜

The Common Open Policy Service (COPS) protocol [rfc2748] was created to provide policy control over QoS signaling protocols like RSVP 💅. COPS works on a query/response model, where Policy Enforcement Points (PEPs) talk to Policy Decision Points (i.e., policy servers) to swap policy information 🤝. COPS gives you application-level security and can run over IPsec or TLS 🔐. It's also a stateful protocol that supports a push model, meaning servers can download new policies or change existing ones on known clients 📲.

[rfc2749] covers how COPS gets used with RSVP 🧩. It specifies COPS client types, context objects, and decision objects 📋. So when a PEP receives an RSVP reservation, it decides whether to accept or reject it based on policy ⚖️. That policy info can be stored a priori, before the RSVP PATH message shows up, or it can be retrieved on demand 🕰️. A similar approach could work when a PEP receives ETS-labeled control flows 🚨. Of course, that would need a new set of associated documents, first describing the types of ETS signaling and then specifying how they're used with COPS 📝.

A companion document to the COPS protocols is COPS Usage for Policy Provisioning (COPS-PR) [rfc3084] 🎁.

Side note, but it matters: the current lack of RSVP deployment by network admins has also played at least an indirect role in the lack of COPS-PR implementation and deployment that followed 😔. [rfc3535] is the output of the IAB Network Management Workshop, where COPS and its current deployment state were discussed 🗣️. At the time of that 2002 workshop, COPS-PR was seen as a technology/architecture that didn't fully meet what network operators needed 🙃. It's also worth noting that at the 60th IETF meeting, held in San Diego in 2004, COPS was discussed as a candidate to be declared historic, because of lack of use and concerns about its design 🪦. Maybe a future, altered COPS design will show up and address operators' concerns 🌈, but speculating on that or other possibilities is beyond the scope of this document 🤷‍♀️.

4.4. Subnetwork Technologies 🧱

This is a generalization of work that's considered "under" IP and mostly sits outside the IETF standards body 🏢. We talk about some specific topics here because there's a relationship between them and IP: each physical network interacts with IP at its edge 🤝.

4.4.1. IEEE 802.1 VLANs 🏷️

The IEEE 802.1q standard defined a tag that gets appended to a Media Access Controller (MAC) frame to support layer 2 Virtual Local Area Networks (VLANs) 🫧. This tag has two parts: a VLAN identifier (12 bits) and a Prioritization field of 3 bits 🎀. A later standard, IEEE 802.1p, which was eventually folded into a revision of IEEE 802.1d, defined the Prioritization field of this new tag [iso15802] 💅. It has 8 levels of priority, with the highest being 7 👑. Vendors can pick a queue per priority codepoint, or aggregate several codepoints into a single queue 🪣.

The 3-bit Prioritization field can be easily mapped to the old ToS field of the upper-layer IP header 🔁. Those bits can also be mapped to a subset of differentiated codepoints 🦋. Bits in the IP header that could support ETS (e.g., specific Diffserv codepoints) can be mapped to the Prioritization bits of 802.1p 🚑. That mapping could be one-to-one between the 802.1p field and the IP ToS bits, or aggregate if you look at the entire Diffserv field in the IP header 🧮. Either way, because bits are scarce, ETS users should expect their traffic to be combined or aggregated with the same priority level as some other kinds of "important" traffic 😬. Basically, with only a 3-bit Priority field in 802.1p, there won't be an exclusive bit value reserved for ETS traffic 💔.

Certain vendors are already providing mappings between the 802.1p field and the ToS bits 🛠️. They're also integrating RSVP signaling with the low-level inband signaling in the 802.1p Priority field 🧠.

It's important to note that the 802.1p standard doesn't specify how a layer 2 codepoint maps to a physical network bandwidth reservation ❌. Instead, it provides what's been termed "best effort QoS" 🫤. The value of 802.1p Priority codepoints actually gets realized at the edges: either when the MAC payload is passed up to upper layers (like IP), or when it's bridged to other physical networks like Frame Relay 🌉. Either of those actions helps provide intra-domain wide propagation of a labeled flow, for both layer 2 and layer 3 flows 🌊.

4.4.2. IEEE 802.11e QoS 📶

The 802.11e standard is a proposed enhancement that specifies mechanisms for providing QoS to the 802.11 family of protocols for wireless LANs 🛜.

Before that, 802.11 had two modes of operation 🕰️. The first was the Distributed Coordination Function (DCF), which is based on the classic collision detection scheme of "listen before sending" 👂. The second, optional mode is the Point Coordination Function (PCF) ✨. These modes split access time into contention-free and contention-active periods, and data gets transmitted during the former 🍰.

The 802.11e standard enhances DCF by adding support for 8 different traffic categories or classifications 🎉. Each higher category waits a little less time than the next lower one before it sends its data 🏃‍♀️.

With PCF, a Hybrid Coordination Function was added. It polls stations during contention-free time slots and grants each one a specific start time and maximum transmission duration ⏱️. This second mode is more complex than enhanced DCF, but QoS can be tuned much more finely to offer specific bandwidth and jitter control 🎚️. Still, it must be noted that neither enhancement offers a guarantee of service 🥲.

4.4.3. Cable Networks 🎀

Okay so the Data Over Cable Service Interface Specification (DOCSIS) is a standard that helps the cable subnetwork talk to and interact with upper-layer IP networks [docsis] 🔌. Cable subnetworks are kinda asynchronous when it comes to data load capacity: typically, 27 M downstream, and anywhere from 320 kb to 10 M upstream (i.e., in the direction of the user towards the Internet) 📡.

The evolution of DOCSIS from 1.0 to 1.1 was a total glow-up 💅✨. It brought in support for a service other than best effort. One of the changes came in indirectly when the 802.1d protocol added the Priority field, which got folded into the DOCSIS 1.1 specification 🫶. Another change was the ability to fragment large packets, so Priority-marked packets (i.e., packets marked with non-best effort labels) can be multiplexed in between the fragmented larger packet 🧩.

ngl this part is important: the DOCSIS specifications do not specify how vendors implement classification, policing, and scheduling of traffic 🙈

So, operators have to lean on mechanisms in Cable Modem Termination Systems (CMTS) and edge routers to use the added DOCSIS 1.1 specifications, whether indirectly or directly 🛠️. Just like with 802.1p, ETS-labeled traffic would most likely get aggregated with other types of traffic, which means an exclusive bit (or set of bits) will not be reserved for ETS users 🥺. Policies and other managed configurations will decide the form of the service that ETS labeled traffic gets 📋.

Traffic engineering and management of ETS labeled flows, including their classification and scheduling at the edges of the DOCSIS cloud, could be done in a few different ways 🌈. A simple schema could be based on non-FIFO queuing mechanisms like class-based weighted fair queuing (or combinations and derivations of it) 🍓. Adding active queue management like Random Early Detection could give you simple tools for handling bursty traffic that contributes to congestion 🫧. A more elaborate scheme for traffic engineering would include the use of MPLS. However, the complexity of MPLS should be taken into consideration before it gets deployed in networks 🧠.

4.5. Multicast 🎶

Network layer multicast has been around for quite a few years 🕰️. Efforts like the Mbone (multicast backbone) have provided a form of tunneled multicast that spans domains, but the routing hierarchy of the Mbone can be considered flat and non-congruent with unicast routing 🤷‍♀️. Efforts like the Multicast Source Discovery Protocol [rfc3618], together with the Protocol Independent Multicast - Sparse Mode (PIM-SM), have been used by a small subset of Internet Service Providers to provide forms of inter-domain multicast [rfc4601]. Still, network layer multicast has not been accepted as a common production level service by a vast majority of ISPs 😔.

Intra-domain multicast, on the other hand, has gained more acceptance as an additional network service 📈. Multicast can produce denial-of-service attacks using the any sender model, and the problem gets even more intense with flood and prune algorithms 🚨. Source-specific multicast [rfc3569], together with access control lists of who is allowed to be a sender, reduces the potential and scope of such attacks 🔒.

4.5.1. IP Layer 📡

The value of IP multicast is its efficient use of resources when sending the same datagram to multiple receivers 💜. An extensive discussion of the strengths of and concerns about multicast is outside the scope of this document. But one can argue that multicast can very naturally complement the push-to-talk feature of land mobile radio (LMR) networks 📻.

Push-to-talk is a form of group communication where every user in the "talk group" can take part in the same conversation 🗣️. LMR is the type of network used by First Responders (e.g., police, firemen, and medical personnel) who are involved in emergencies 🚑🚒. Right now, certain vendors and providers are offering push-to-talk service to the general public as well as First Responders. Some of these systems are operated over IP networks or are interfaced with IP networks to extend the set of users that can communicate with each other 🌐. We can consider at least a subset of these systems as either closed IP networks, or domains, since they do not act as transits to other parts of the Internet 🏝️.

The potential integration of LMR talk groups with IP multicast is an open issue 🤔. LMR talk groups get established in a static manner, with man-in-the-loop participation in their establishment and teardown 🧍‍♀️. The seamless integration of these talk groups with multicast group addresses is a feature that has not been discussed in open forums 🙊.

4.5.2. IEEE 802.1d MAC Bridges 🌉

The IEEE 802.1d standard specifies fields and capabilities for a number of features. In Section 4.3.2 above, we talked about its use for defining a Prioritization field 🏷️. The 802.1d standard also covers the topic of filtering MAC layer multicast frames 🧹.

One of the concerns about multicast is that broadcast storms can arise and generate a denial of service against other users/nodes 🌪️. Some administrators purposely filter out multicast frames where the subnetwork resource is relatively small (e.g., 802.11 networks) 📶. Operational considerations with respect to ETS may want to think about doing this on an as-needed basis, balancing the conditions of the network with the perceived need for multicast ⚖️. In cases where filtering out multicast can be turned on dynamically, COPS may be a good means of providing consistent domain-wide policy control 🎯.

4.6. Discovery 🔍

If a service is being offered to explicitly support ETS, then it would seem reasonable that discovery of that service may be of benefit 🧭. For example, if a domain has a subset of servers that recognize ETS-labeled traffic, then dynamic discovery of where these servers are (or even whether they exist) would be way more beneficial than relying on statically configured information 🙌.

The Service Location Protocol (SLP) [rfc2608] is designed to provide information about the existence, location, and configuration of networked services 🗺️. In many cases, the name of the host supporting the desired service needs to be known a priori in order for users to access it. SLP eliminates this requirement by using a descriptive model that identifies the service. Based on that description, SLP then resolves the network address of the service and returns this information to the requester 🪄. An interesting design element of SLP is that it assumes the protocol runs over a collection of nodes that are under the control of a single administrative authority 👑. This model follows the scope of this framework document. However, the scope of SLP may be better suited for parts of an enterprise network rather than an entire domain 🏢.

Anycasting [rfc1546] is another way of discovering nodes that support a given service 🎯. Interdomain anycast addresses, propagated by BGP, represent anycast in a wide scope and have been used by multiple root servers for a while 🌍. Anycast can also be realized in a more constrained and limited scope (i.e., solely within a domain or subnet), and as in the case of multicast, it may not be supported 🫠.

[rfc4291] covers the topic of anycast addresses for IPv6 💫. Unlike SLP, users/applications must know the anycast address associated with the target service 🫣. Also, responses to multiple requests to the anycast address may come from different servers. A lack of response (not due to connectivity problems) correlates to the discovery that a target service is not available 📭. Detailed tradeoffs between this approach and SLP are outside the scope of this framework document 🙃.

The Dynamic Delegation Discovery System (DDDS) is used to implement a binding of strings to data, in order to support dynamically configured delegation systems [rfc3401] 🧩. The DDDS works by mapping some unique string to data stored within a DDDS Database, iteratively applying string transformation rules until a terminal condition is reached 🔁. The potential then exists for a client to specify a set of known tags (e.g., RetrieveMail:Pop3) that would identify and discover the appropriate server it can communicate with 📬.

4.7. Differentiated Services (Diffserv) 🧁

There are a bunch of examples where Diffserv [rfc2474] has been deployed strictly within a domain, with no extension of service to neighboring domains 🏡. There are various reasons Diffserv isn't widely deployed in an inter-domain context, including ones rooted in the complexity and the problems of supporting the security requirements for Diffserv codepoints 😵‍💫. An extensive discussion of Diffserv deployment is outside the scope of this document.

[Baker] presents common examples of various codepoints used for well-known applications 📚. The document does not recommend these associations as being standard or fixed. Instead, the examples in [Baker] provide a reference point for known deployments that can act as a guide for other network administrators 🧭.

An argument can be made that Diffserv, with its existing codepoint specifications of Assured Forwarding (AF) and Expedited Forwarding (EF), goes beyond what would be needed to support ETS within a domain 🤯. What we mean is that the complexity in terms of maintenance and support of AF or EF may exceed or put undue burden on the management resources of a domain 🥵. Given this possibility, users or network administrators may want to figure out whether various queuing mechanisms, like class-based weighted fair queuing, are sufficient to support ETS flows through a domain 🔎. Note, as we stated earlier in Section 2, over-provisioning is another option to consider 🛏️. We assume that if the reader is considering something like Diffserv, then it has already been determined that over-provisioning is not a viable option given their individual needs or capabilities 💭.

5. Security Considerations 🚨🔐

Services used to offer better or best available service for a particular set of users (in the case of this document, ETS users) are prime targets for security attacks or simple misuse 🎯😱. Administrators that choose to add protocols or services to support ETS are strongly encouraged to consider new policies to address the added potential for security attacks 🛡️. These policies, and any additional security measures, should be considered independent of any mechanism or equipment that restricts access to the administrative domain 🔑.

Determining how authorization is accomplished is an open issue 🤨. Many times the choice depends on the service that is deployed. One example is source addresses in an access list permitting senders to the multicast group (as described in Section 4.5). Within a single domain environment, network administrators tend to find this approach acceptable in some cases 👍. However, other services may require more stringent measures that employ detailed credentials, and possibly multiple levels of access and authentication 🪪. Ease of use, deployment, scalability, and susceptibility to security breaches all play a role in determining authorization schemas 🧮. The potential is that accomplishing this for only a single domain may be easier than at the inter-domain scope, if only in terms of scalability and trust 🫶💯.

6. Summary Comments 💅

okay so bestie, let's wrap this up 🎀 this document has walked through a bunch of protocols and complementary technologies that can be used to support ETS users ✨ they were picked because all or most of the important parts can be run and controlled inside a single administrative domain 🏠 that's the main reason other protocols, like the ones being worked on in the Next Steps in Signaling (NSIS) working group, didn't get a spot here 🫶

we're also not trying to be the "king maker" 👑 by listing a bunch of different efforts, we get to show that there are lots of different solutions out there for ETS 🌈 these solutions might involve QoS, traffic engineering, or just protection against bad stuff (like sudden spikes in traffic load) 🚦 honestly, the choice is totally up to you, bestie 💖

7. Acknowledgements 🫶

thank you to Ran Atkinson, Scott Bradner, Jon Peterson, and Kimberly King for the comments and suggestions on this document 💜

8. References 📚

8.1. Normative Reference 🌸

  • [rfc4375]: Carlberg, K., "Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain", RFC 4375, January 2006. 💅

8.2. Informative References 🦋

  • [Baker]: Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. ✨
  • [docsis]: "Data-Over-Cable Service Interface Specifications: Cable Modem to Customer Premise Equipment Interface Specification SP-CMCI-I07-020301", DOCSIS, March 2002, http://www.cablemodem.com. 🎀
  • [iso15802]: "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3:1998 🌈
  • [rfc1546]: Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. 🧚
  • [rfc2131]: Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. 🍓
  • [rfc2205]: Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. 💜
  • [rfc2474]: 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. ⭐
  • [rfc2608]: Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. 🌸
  • [rfc2748]: Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. 🦋
  • [rfc2749]: Herzog, S., Ed., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000. 🎀
  • [rfc2750]: Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. ✨
  • [rfc3031]: Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. 💖
  • [rfc3270]: 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. 🫶
  • [rfc3209]: Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. 🔥
  • [rfc3344]: Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002. 🌈
  • [rfc3084]: Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. 💅
  • [rfc3401]: Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401 October 2002. 🧚
  • [rfc3535]: Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003. 🍓
  • [rfc3569]: Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. 💜
  • [rfc3618]: Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. ⭐
  • [rfc4190]: Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005. 🌸
  • [rfc4291]: Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 🦋
  • [rfc4601]: Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. 🎀

Author's Address 🏡

Ken Carlberg G11 123a Versailles Circle Baltimore, MD USA

EMail: carlberg@g11.org.uk 📮

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🫠

Intellectual Property 💎

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌷

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

📦 where this page comes from