diff options
Diffstat (limited to 'doc/rfc/rfc4958.txt')
| -rw-r--r-- | doc/rfc/rfc4958.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc4958.txt b/doc/rfc/rfc4958.txt new file mode 100644 index 0000000..2df3e54 --- /dev/null +++ b/doc/rfc/rfc4958.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group K. Carlberg +Request for Comments: 4958 G11 +Category: Informational July 2007 + + +A Framework for Supporting Emergency Telecommunications Services (ETS) + within a Single Administrative Domain + +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 Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document presents a framework discussing the role of various + protocols and mechanisms that could be considered candidates for + supporting Emergency Telecommunication Services (ETS) within a single + administrative domain. Comments about their potential usage as well + as their current deployment are provided to the reader. Specific + solutions are not presented. + + + + + + + + + + + + + + + + + + + + + + + + + +Carlberg Informational [Page 1] + +RFC 4958 ETS Single Domain Framework July 2007 + + +Table of Contents + + 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 + + + + + + + + + + + + + + + + + + + + + + + + +Carlberg Informational [Page 2] + +RFC 4958 ETS Single Domain Framework July 2007 + + +1. Introduction + + This document presents a framework for supporting Emergency + Telecommunications Services (ETS) within the scope of a single + administrative domain. This narrow scope provides a reference point + for considering protocols that could be deployed to support ETS. + [rfc4375] is a complementary effort that articulates requirements for + a single administrative domain and defines it as "collection of + resources under the control of a single administrative authority". + We use this other effort as both a starting point and guide for this + document. + + A different example of a framework document for ETS is [rfc4190], + which focused on support for ETS within IP telephony. In this case, + the focal point was a particular application whose flows could span + multiple autonomous domains. Even though this document uses a + somewhat more constrained perspective than [rfc4190], we can still + expect some measure of overlap in the areas that are discussed. + +1.1. Differences between Single and Inter-Domain + + The progression of our work in the following sections is helped by + stating some key differences between the single and inter-domain + cases. From a general perspective, one can start by observing the + following. + + a) Congruent with physical topology of resources, each domain is + an authority zone, and there is currently no scalable way to + transfer authority between zones. + + b) Each authority zone is under separate management. + + c) Authority zones are run by competitors; this acts as further + deterrent to transferring authority. + + As a result of the initial statements in (a) through (c) above, + additional observations can be made that distinguish the single and + inter-domain cases, as follows. + + d) Different policies might be implemented in different + administrative domains. + + e) There is an absence of any 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. + + + + + + +Carlberg Informational [Page 3] + +RFC 4958 ETS Single Domain Framework July 2007 + + + 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 ensure that only + authorized end-users (or layer 2 interfaces) are able to emit + frames/packets with non-default QoS labels into the network. + This is not feasible in the inter-domain case because the + inter-domain link contains aggregated flows. In addition, the + dissemination of access control lists at the network level is + not 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. This is not + possible in the inter-domain case. + + While the above is not an all-inclusive set of differences, it does + provide some rationale why one may wish to focus efforts in 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. Many of these exchanges have + debated the need for QoS mechanisms versus over-provisioning of + links. + + In reality, most IP network links are provisioned with a percentage + of excess capacity beyond that of the average load. The 'shared' + resource model together with TCP's congestion avoidance algorithms + helps compensate for those cases where spikes or bursts of traffic + are experienced by the network. + + The thrust of the debate within the IEPREP working group is whether + it is always better to over-provision links to such a degree that + spikes in load can still be supported with no loss due to congestion. + Advocates of this position point to many ISPs in the US that take + this approach instead of using QoS mechanisms to honor agreements + with their peers or customers. These advocates point to cost + effectiveness in comparison to complexity and security issues + associated with other approaches. + + + + + + +Carlberg Informational [Page 4] + +RFC 4958 ETS Single Domain Framework July 2007 + + + Proponents of QoS mechanisms argue that the relatively low cost of + bandwidth enjoyed in the US (particularly, by large ISPs) is not + necessarily available throughout the world. Beyond the subject of + cost, some domains are comprised of physical networks that support + wide disparity in bandwidth capacity -- e.g., attachment points + connected to high capacity fiber and lower capacity wireless links. + + This document does not advocate one of these positions over the + other. The author does advocate that network + administrators/operators should perform a cost analysis between + over-provisioning for spikes versus QoS mechanisms as applied within + a domain and its access link to another domain (e.g., a customer and + its ISP). This analysis, in addition to examining policies and + requirements of the administrative domain, should be the key to + deciding how (or if) ETS should be supported within 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 primary objective is to provide a target measure of service + within a domain for flows that have been labeled for ETS. This level + may be better than best effort, the best available service that the + network (or parts thereof) can offer, or a specific percentage of + resource set aside for ETS. [rfc4375] presents a set of requirements + in trying to achieve this objective. + + This framework document uses [rfc4375] as a reference point in + discussing existing areas of engineering work or protocols that can + play a role in supporting ETS within a domain. Discussion of these + areas and protocols are not to be confused with expectations that + they exist within a given domain. Rather, the subjects discussed in + Section 4 below are ones that are recognized as candidates that can + exist and could be used to facilitate ETS users or data flows. + +3.1. Scenarios + + One of the topics of discussion on the IEPREP mailing list and in the + working group meetings is the operating environment of the ETS user. + Many variations can be dreamed of with respect to underlying network + technologies and applications. Instead of getting lost in hundreds + of potential scenarios, we attempt to abstract the scenarios into two + simple case examples. + + + + +Carlberg Informational [Page 5] + +RFC 4958 ETS Single Domain Framework July 2007 + + + (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 that used in + Mobile IP [rfc3344]. Case (a) is considered the normal and vastly + most prevalent scenario in today's Internet. Case (b) above may + simply be supported by the Dynamic Host Configuration Protocol (DHCP) + [rfc2131], or a static set of addresses, that are assigned to + 'visitors' of the network. This effort is predominantly operational + in nature and heavily reliant on the management and security policies + of that network. + + A more ambitious way of supporting the mobile user is through the use + of the Mobile IP (MIP) protocol. MIP offers a measure of + application-transparent mobility as a mobile host moves from one + subnetwork to another while keeping the same stable IP address + registered at a global anchor point. However, this feature may not + always be available or in use. In any case, where it is in use, at + least some of the packets destined to and from the mobile host go + through the home network. + +4. Topic Areas + + The topic areas presented below are not presented in any particular + order or along any specific layering model. They represent + capabilities that may be found within an administrative domain. Many + are topics of on-going work within the IETF. + + It must be stressed that readers of this document should not expect + any of the following to exist within a domain for ETS users. In many + cases, while some of the following areas have been standardized and + in wide use for several years, others have seen very limited + deployment. + +4.1. MPLS + + Multiprotocol Label Switching (MPLS) is generally the first protocol + that comes to mind when the subject of traffic engineering is brought + up. MPLS signaling produces Labeled Switched Paths (LSPs) through a + network of Label Switch Routers [rfc3031]. When traffic reaches the + ingress boundary of an MPLS domain (which may or may not be congruent + with an administrative domain), the packets are classified, labeled, + scheduled, and forwarded along an LSP. + + + + + +Carlberg Informational [Page 6] + +RFC 4958 ETS Single Domain Framework July 2007 + + + [rfc3270] describes how MPLS can be used to support Differentiated + Services. The RFC discusses the use of the 3-bit EXP (experimental) + field to convey the Per Hop Behavior (PHB) to be applied to the + packet. As we shall see in later sections, this 3-bit field can be + mapped to fields in several other protocols. + + The inherent features of classification, scheduling, and labeling are + viewed as symbiotic, and therefore, they are often integrated with + other protocols and architectures. Examples of this include RSVP and + Differentiated Services. Below, we discuss several instances where a + given protocol specification or mechanism has been known to be + complemented with MPLS. This includes the potential labels that may + be associated with ETS. However, we stress that MPLS is only one of + several approaches to support traffic engineering. In addition, the + complexity of the MPLS protocol and architecture may make it suited + only for large domains. + +4.2. RSVP + + The original design of RSVP, together with the Integrated Services + model, was one of an end-to-end signaling capability to set up a path + of reserved resources that spanned networks and administrative + domains [rfc2205]. Currently, RSVP has not been widely deployed by + network administrators for QoS across domains. Today's limited + deployment by network administrators has been mostly constrained to + boundaries within a domain, and commonly in conjunction with MPLS + signaling. Early deployments of RSVP ran into unanticipated scaling + issues; it is not entirely clear how scalable an RSVP approach would + be across the Internet. + + [rfc3209] is one example of how RSVP has evolved to complement + efforts that are scoped to operate within a domain. In this case, + extensions to RSVP are defined that allow it to establish intra- + domain Labeled Switched Paths (LSPs) in Multiprotocol Label Switching + (MPLS). + + [rfc2750] specifies extensions to RSVP so that it can support generic + policy-based admission control. This standard goes beyond the + support of the POLICY_DATA object stipulated in [rfc3209], by + defining the means of control and enforcement of access and usage + policies. While the standard does not advocate a particular policy + architecture, the IETF has defined one that can complement [rfc2750] + -- we expand on this in Section 4.3 below. + + + + + + + + +Carlberg Informational [Page 7] + +RFC 4958 ETS Single Domain Framework July 2007 + + +4.2.1. Relation to ETS + + The ability to reserve resources correlates to an ability to provide + preferential service for specifically classified traffic -- the + classification being a tuple of 1 or more fields which may or may not + include an ETS specific label. In cases where a tuple includes a + label that has been defined for ETS usage, the reservation helps + ensure that an emergency-related flow will be forwarded towards its + destination. Within the scope of this document, this means that RSVP + would be used to facilitate the forwarding of traffic within a + domain. + + We note that this places an importance on defining a label and an + associated field that can be set and/or examined by RSVP-capable + nodes. + + Another important observation is that major vendor routers currently + constrain their examination of fields for classification to the + network and transport layers. This means that application layer + labels will mostly likely be ignored by routers/switches. + +4.3. Policy + + The Common Open Policy Service (COPS) protocol [rfc2748] was defined + to provide policy control over QoS signaling protocols, such as RSVP. + COPS is based on a query/response model in which Policy Enforcement + Points (PEPs) interact with Policy Decision Points (i.e., policy + servers) to exchange policy information. COPS provides application- + level security and can operate over IPsec or TLS. COPS is also a + stateful protocol that supports a push model. This means that + servers can download new policies or alter existing ones to known + clients. + + [rfc2749] articulates the usage of COPS with RSVP. It specifies COPS + client types, context objects, and decision objects. Thus, when an + RSVP reservation is received by a PEP, the PEP decides whether to + accept or reject it based on policy. This policy information can be + stored a priori to the reception of the RSVP PATH message, or it can + be retrieved on an on-demand basis. A similar course of action could + be applied in cases where ETS-labeled control flows are received by + the PEP. This of course would require an associated (and new) set of + documents that first articulates types of ETS signaling and then + specifies its usage with COPS. + + A complementary document to the COPS protocols is COPS Usage for + Policy Provisioning (COPS-PR) [rfc3084]. + + + + + +Carlberg Informational [Page 8] + +RFC 4958 ETS Single Domain Framework July 2007 + + + As a side note, the current lack of deployment by network + administrators of RSVP has also played at least an indirect role in + the subsequent lack of implementation and deployment of COPS-PR. + [rfc3535] is an output from the IAB Network Management Workshop in + which the topic of COPS and its current state of deployment was + discussed. At the time of that workshop in 2002, COPS-PR was + considered a technology/architecture that did not fully meet the + needs of network operators. It should also be noted that at the 60th + IETF meeting held in San Diego in 2004, COPS was discussed as a + candidate protocol that should be declared as historic because of + lack of use and concerns about its design. In the future, an altered + design of COPS may emerge that addresses the concern of operators, + but speculation on that or other possibilities is beyond the scope of + this document. + +4.4. Subnetwork Technologies + + This is a generalization of work that is considered "under" IP and + for the most part outside of the IETF standards body. We discuss + some specific topics here because there is a relationship between + them and IP in the sense that each physical network interacts at its + edge with IP. + +4.4.1. IEEE 802.1 VLANs + + The IEEE 802.1q standard defined a tag appended to a Media Access + Controller (MAC) frame for support of 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 subsequent standard, + IEEE 802.1p, later incorporated into a revision of IEEE 802.1d, + defined the Prioritization field of this new tag [iso15802]. It + consists of 8 levels of priority, with the highest priority being a + value of 7. Vendors may choose a queue per priority codepoint, or + aggregate several codepoints to a single queue. + + The 3-bit Prioritization field can be easily mapped to the old ToS + field of the upper-layer IP header. In turn, these bits can also be + mapped to a subset of differentiated codepoints. Bits in the IP + header that could be used to support ETS (e.g., specific Diffserv + codepoints) can in turn be mapped to the Prioritization bits of + 802.1p. This mapping could be accomplished in a one-to-one manner + between the 802.1p field and the IP ToS bits, or in an aggregate + manner if one considers the entire Diffserv field in the IP header. + In either case, because of the scarcity of bits, ETS users should + expect that their traffic will be combined or aggregated with the + same level of priority as some other types of "important" traffic. + In other words, given the existing 3-bit Priority Field for 802.1p, + there will not be an exclusive bit value reserved for ETS traffic. + + + +Carlberg Informational [Page 9] + +RFC 4958 ETS Single Domain Framework July 2007 + + + Certain vendors are currently providing mappings between the 802.1p + field and the ToS bits. This is in addition to integrating the + signaling of RSVP with the low-level inband signaling offered in the + Priority field of 802.1p. + + It is important to note that the 802.1p standard does not specify the + correlation of a layer 2 codepoint to a physical network bandwidth + reservation. Instead, this standard provides what has been termed as + "best effort QoS". The value of the 802.1p Priority codepoints is + realized at the edges: either as the MAC payload is passed to upper + layers (like IP), or as it is bridged to other physical networks like + Frame Relay. Either of these actions help provide an 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 to provide QoS to the 802.11 family of protocols for + wireless LANs. + + Previously, 802.11 had two modes of operation. One was Distributed + Coordination Function (DCF) , which is based on the classic collision + detection schema of "listen before sending". A second optional mode + is the Point Coordination Function (PCF). The modes splits access + time into contention-free and contention-active periods -- + transmitting data 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. + + In the case of PCF, a Hybrid Coordination Function has been added + that polls stations during contention-free time slots and grants them + a specific start time and maximum duration for transmission. This + second mode is more complex than enhanced DCF, but the QoS can be + more finely tuned to offer specific bandwidth and jitter control. It + must be noted that neither enhancement offers a guarantee of service. + +4.4.3. Cable Networks + + The Data Over Cable Service Interface Specification (DOCSIS) is a + standard used to facilitate the communication and interaction of the + cable subnetwork with upper-layer IP networks [docsis]. Cable + subnetworks tend to be asynchronous in terms of 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). + + + + +Carlberg Informational [Page 10] + +RFC 4958 ETS Single Domain Framework July 2007 + + + The evolution of the DOCSIS specification, from 1.0 to 1.1, brought + about changes to support a service other than best effort. One of + the changes was indirectly added when the 802.1d protocol added the + Priority field, which was incorporated within the DOCSIS 1.1 + specification. Another change was the ability to perform packet + fragmentation of large packets so that Priority-marked packets (i.e., + packets marked with non-best effort labels) can be multiplexed in + between the fragmented larger packet. + + It's important to note that the DOCSIS specifications do not specify + how vendors implement classification, policing, and scheduling of + traffic. Hence, operators must rely on mechanisms in Cable Modem + Termination Systems (CMTS) and edge routers to leverage indirectly or + directly the added specifications of DOCSIS 1.1. As in the case of + 802.1p, ETS-labeled traffic would most likely be aggregated with + other types of traffic, which implies that an exclusive bit (or set + of bits) will not be reserved for ETS users. Policies and other + managed configurations will determine the form of the service + experienced by ETS labeled traffic. + + Traffic engineering and management of ETS labeled flows, including + its classification and scheduling at the edges of the DOCSIS cloud, + could be accomplished in several ways. A simple schema could be + based on non-FIFO queuing mechanisms like class-based weighted fair + queuing (or combinations and derivations thereof). The addition of + active queue management like Random Early Detection could provide + simple mechanisms for dealing with bursty traffic contributing 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 its deployment in networks. + +4.5. Multicast + + Network layer multicast has existed for quite a few years. Efforts + such as 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]. + However, network layer multicast has not been accepted as a common + production level service by a vast majority of ISPs. + + In contrast, intra-domain multicast in domains has gained more + acceptance as an additional network service. Multicast can produce + denial-of-service attacks using the any sender model, with the + problem made more acute with flood and prune algorithms. Source- + + + +Carlberg Informational [Page 11] + +RFC 4958 ETS Single Domain Framework July 2007 + + + 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 in + sending the same datagram to multiple receivers. An extensive + discussion on the strengths of and concerns about multicast is + outside the scope of this document. However, 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 participate in the same conversation. LMR is the + type of network used by First Responders (e.g., police, firemen, and + medical personnel) that are involved in emergencies. Currently, + certain vendors and providers are offering push-to-talk service to + the general public in addition to 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 are 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 discussed 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 in cases + where the subnetwork resource is relatively small (e.g., 802.11 + networks). Operational considerations with respect to ETS may wish + to consider 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 activated dynamically, + COPS may be a good means of providing consistent domain-wide policy + control. + + + +Carlberg Informational [Page 12] + +RFC 4958 ETS Single Domain Framework July 2007 + + +4.6. Discovery + + If a service is being offered to explicitly support ETS, then it + would seem reasonable that discovery of the 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 if they exist) would be 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 is needed 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 this 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 that the protocol is run 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 versus an entire domain. + + Anycasting [rfc1546] is another means 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. In addition, responses to multiple requests to + the anycast address may come from different servers. 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 functions by mapping some + unique string to data stored within a DDDS Database by iteratively + applying string transformation rules until a terminal condition is + reached. The potential then exists that a client could specify a set + of known tags (e.g., RetrieveMail:Pop3) that would identify/discover + the appropriate server with which it can communicate. + + + + +Carlberg Informational [Page 13] + +RFC 4958 ETS Single Domain Framework July 2007 + + +4.7. Differentiated Services (Diffserv) + + There are a number of examples where Diffserv [rfc2474] has been + deployed strictly within a domain, with no extension of service to + neighboring domains. Various reasons exist for Diffserv not being + widely deployed in an inter-domain context, including ones rooted in + the complexity and problems in supporting the security requirements + for Diffserv codepoints. An extensive discussion on 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. Rather, 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. By this we mean that the complexity in terms of maintenance + and support of AF or EF may exceed or cause undue burden on the + management resources of a domain. Given this possibility, users or + network administrators may wish to determine if various queuing + mechanisms, like class-based weighted fair queuing, is 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 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. Hence, + administrators that choose to incorporate additional + protocols/services to support ETS are strongly encouraged to consider + new policies to address the added potential of 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 is a function of 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, cases can be found where network administrators + tend to find this approach acceptable. However, other services may + + + +Carlberg Informational [Page 14] + +RFC 4958 ETS Single Domain Framework July 2007 + + + 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 breach 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 + + This document has presented a number of protocols and complementary + technologies that can be used to support ETS users. Their selection + is dictated by the fact that all or significant portions of the + protocols can be operated and controlled within a single + administrative domain. It is this reason why other protocols, like + those under current development in the Next Steps in Signaling (NSIS) + working group, have not been discussed. + + By listing a variety of efforts in this document, we avoid taking on + the role of "king maker" and at the same time indirectly point out + that a variety of solutions exist in support of ETS. These solutions + may involve QoS, traffic engineering, or simply protection against + detrimental conditions (e.g., spikes in traffic load). Again, the + choice is up to the reader. + +7. Acknowledgements + + Thanks to Ran Atkinson, Scott Bradner, Jon Peterson, and Kimberly + King for 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. + + + + +Carlberg Informational [Page 15] + +RFC 4958 ETS Single Domain Framework July 2007 + + + [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. + + + + + + +Carlberg Informational [Page 16] + +RFC 4958 ETS Single Domain Framework July 2007 + + + [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 + + + + + + + +Carlberg Informational [Page 17] + +RFC 4958 ETS Single Domain Framework July 2007 + + +Full Copyright Statement + + 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. + + + + + + + +Carlberg Informational [Page 18] + |