idnits 2.17.1 draft-ietf-ieprep-domain-frame-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 798. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 18) being 59 lines == It seems as if not all pages are separated by form feeds - found 16 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Baker' on line 578 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Ken Carlberg 3 INTERNET DRAFT G11 4 Dec, 2006 6 A Framework for Supporting Emergency Telecommunications 7 Services (ETS) Within a Single Administrative Domain 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2006). 37 Abstract 39 This document presents a framework discussing the role of various 40 protocols and mechanisms that could be considered candidates for 41 supporting Emergency Telecommunication Services (ETS) within a single 42 administrative domain. Comments about their potential usage as well 43 as their current deployment are provided to the reader. Specific 44 solutions are not presented. 46 1. Introduction 48 This document presents a framework for supporting Emergency Telecom- 49 munications Services (ETS) within the scope of a single administra- 50 tive domain. This narrow scope provides a reference point for con- 51 sidering protocols that could be deployed to support ETS. [rfc4375] 52 is a complementary effort that articulates requirements for a single 53 administrative domain and defines it as "collection of resources 54 under the control of a single administrative authority". We use this 55 other effort as both a starting point and guide for this document. 57 A different example of a framework document for ETS is [rfc4190], 58 which focused on support for ETS within IP telephony. In this case, 59 the focal point was a particular application whose flows could span 60 multiple autonomous domains. Even though this document uses a some- 61 what more constrained perspective than [rfc4190], we can still expect 62 some measure of overlap in the areas that are discussed. 64 1.1. Differences between Single and Inter-domain 66 The progression of our work in the following sections is helped by 67 stating some key differences between the single and inter-domain 68 cases. From a general perspective, one can start by observing the 69 following 71 a) Congruent with physical topology of resources, each domain 72 is an authority zone and there is currently no scalable way 73 to transfer authority between zones. 74 b) Each authority zone is under separate management 75 c) Authority zones are run by competitors, which acts as 76 further deterrent to transferring authority. 78 As a result of the initial statements in (a) through (c) above, addi- 79 tional observations can be made that distinguish the single and 80 inter-domain case, as stated in the following" 82 d) Different policies might be implemented in different 83 administrative domains. 85 e) There is an absence of any practical method for ingress nodes of 86 a transit domain to authenticate all of the IP network layer 87 packets that have labels indicating a preference or importance. 89 f) Given item (d) above, all current inter-domain QoS mechanisms 90 at the network level generally create easily exploited and 91 significantly painful DoS/DDoS attack vectors on the network. 93 g) A single administrative domain can deploy various mechanisms 94 (e.g., Access Control Lists) into each and every edge device 95 (e.g., ethernet switch or router) to ensure that only 96 authorized end-users (or layer 2 interfaces) are able to emit 97 frames/packets with non-default QoS labels into the network. 98 This is not feasible in the inter-domain case because the 99 inter-domain link contains aggregated flows. In addition, the 100 dissemination of Access Control Lists at the network level is 101 not scalable in the inter-domain case. 103 h) A single domain can deploy mechanisms into the edge devices to 104 enforce its domain-wide policies -- without having to trust any 105 3rd party to configure things correctly. This is not possible 106 in the inter-domain case. 108 While the above is not an all-inclusive set of differences, it does 109 provide some rationale why one may wish to focus efforts in the more 110 constrained scenario of a single administrative domain. 112 2. Common Practice: Provisioning 114 The IEPREP working group, and mailing list, has had extensive discus- 115 sions about over-provisioning. Many of these exchanges have debated 116 the need for QoS mechanisms versus over-provisioning of links. 118 In reality, most IP network links are provisioned with a percentage 119 of excess capacity beyond that of the average load. The 'shared' 120 resource model together with TCP's congestion avoidance algorithms 121 helps compensate for those cases where spikes or bursts of traffic 122 are experienced by the network. 124 The thrust of the debate within the IEPREP working group is whether 125 it is always better to over provision links to such a degree that 126 spikes in load can still be supported with no loss due to congestion. 127 Advocates of this position point to many ISPs in the U.S. that take 128 this approach instead of using QoS mechanisms to honor agreements 129 with their peers or customers. These advocates point to cost effec- 130 tiveness in comparison to complexity and security issues associated 131 with other approaches. 133 Proponents of QoS mechanisms argue that the relatively low cost of 134 bandwidth enjoyed in the US (particularly, by large ISPs) is not 135 necessarily available throughout the world. Beyond the subject of 136 cost, some domains are comprised of physical networks that support 137 wide disparity in bandwidth capacity -- e.g., attachment points con- 138 nected to high capacity fiber and lower capacity wireless links. 140 This document does not advocate one of these positions over the 141 other. The author does advocate that network 142 administrators/operators should perform a cost analysis between over 143 provisioning for spikes versus QoS mechanisms as applied within a 144 domain and its access link to another domain (e.g., a customer and 145 its ISP). This analysis, in addition to examining policies and 146 requirements of the administrative domain, should be the key to 147 deciding how (or if) ETS should be supported within the domain. 149 If the decision is to rely on over provisioning, then some of the 150 following sections will have little to no bearing on how ETS is sup- 151 ported within a domain. The exception would be labeling mechanisms 152 used to convey information to other communication architectures 153 (e.g., SIP-to-SS7/ISUP gateways). 155 3. Objective 157 The primary objective is to provide a target measure of service 158 within a domain for flows that have been labeled for ETS. This level 159 may be better than best effort, the best available service that the 160 network (or parts thereof) can offer, or a specific percentage of 161 resource set aside for ETS. [rfc4375] presents a set of requirements 162 in trying to achieve this objective. 164 This framework document uses [rfc4375] as a reference point in dis- 165 cussing existing areas of engineering work or protocols that can play 166 a role in supporting ETS within a domain. Discussion of these areas 167 and protocols are not to be confused with expectations that they 168 exist within a given domain. Rather, the subjects discussed in Sec- 169 tion 4 below are ones that are recognized as candidates that can 170 exist and could be used to facilitate ETS users or data flows. 172 3.1. Scenarios 174 One of the topics of discussion that arises on the IEPREP mailing 175 list, and the working group meetings, is the operating environment of 176 the ETS user. Many variations can be dreamed of with respect to 177 underlying network technologies and applications. Instead of getting 178 lost in hundreds of potential scenarios, we attempt to abstract the 179 limit the scenarios into two simple case examples. 181 (a) A user in their home network attempts to use or leverage any 182 ETS capability within the domain. 184 (b) A user visits a foreign network and attempts to use or 185 leverage any ETS capability within the domain. 187 We borrow the terms "home" and "foreign" network from that used in 188 Mobile IP [rfc3344]. Case (a) is considered the normal and vastly 189 most prevalent scenario in today's Internet. Case (b) above may sim- 190 ply be supported by the Dynamic Host Configuration Protocol (DHCP) 191 [rfc2131], or a static set of addresses, that are assigned to 'visi- 192 tors' of the network. This effort is predominantly operational in 193 nature and heavily reliant on the management and security policies of 194 that network. 196 A more ambitious way of supporting the mobile user is through the use 197 of the Mobile IP (MIP) protocol. In this case and at the IP level, 198 foreign networks introduce the concept of triangle routing and the 199 potential for multiple access points and service context within a 200 subnetwork. In addition, policy plays a critical role in dictating 201 the measure of available services to the mobile user. 203 The beaconing capability of MIP allows it to offer a measure of 204 application transparent mobility as a mobile host (MH) moves from one 205 subnetwork to another. However, this feature may not be available in 206 most domains. In addition, its management requirements may 207 discourage its widespread deployment and use. Hence, users should 208 probably not rely on its existence, but rather may want to expect a 209 more simpler approach based on DHCP as described above. The subject 210 of mobile IP is discussed below in Section 4. 212 4. Topic Areas 214 The topic areas presented below are not presented in any particular 215 order or along any specific layering model. They represent capabili- 216 ties that may be found within an administrative domain. Many are 217 topics of on-going work within the IETF. 219 It must be stressed that readers of this document should not expect 220 any of the following to exist within a domain for ETS users. In many 221 cases, while some of the following areas have been standardized and 222 in wide use for several years, others have seen very limited deploy- 223 ment. 225 4.1. MPLS 227 Multi-Protocol Label Switching (MPLS) is generally the first protocol 228 that comes to mind when the subject of traffic engineering is brought 229 up. MPLS signaling produces Labeled Switched Paths (LSP) through a 230 network of Label Switch Routers [rfc3031]. When traffic reaches the 231 ingress boundary of an MPLS domain (which may or may not be congruent 232 with an administrative domain), the packets are classified, labeled, 233 scheduled, and forwarded along an LSP. 235 [rfc3270] describes how MPLS can be used to support Differentiated 236 Services. The RFC discusses the use of the 3 bit EXP (experimental) 237 field to convey the Per Hop Behavior (PHB) to be applied to the 238 packet. As we shall see in later subsections, this three bit field 239 can be mapped to fields in several other protocols. 241 The inherent feature of classification, scheduling, and labeling are 242 viewed as symbiotic and therefore many times it is integrated with 243 other protocols and architectures. Examples of this include RSVP and 244 Differentiated Services. Below, we discuss several instances where a 245 given protocol specification or mechanism has been known to be com- 246 plemented with MPLS. This includes the potential labels that may be 247 associated with ETS. However, we stress that MPLS is only one of 248 several approaches to support traffic engineering. In addition, the 249 complexity of the MPLS protocol and architecture may make it suited 250 for only large domains. 252 4.2. RSVP 254 The original design of RSVP, together with the Integrated Services 255 model, was one of an end-to-end signaling capability to set up a path 256 of reserved resources that spanned networks and administrative 257 domains [rfc2205]. Currently, RSVP has not been widely deployed by 258 network administrators for QoS across domains. Today's limited 259 deployment by network administrators so far has been mostly con- 260 strained to boundaries within a domain, and commonly in conjunction 261 with MPLS signaling. Early deployments of RSVP ran into unantici- 262 pated scaling issues; it is not entirely clear how scalable an RSVP 263 approach would be across the Internet. 265 [rfc3209] is one example of how RSVP has evolved to complement 266 efforts that are scoped to operate within a domain. In this case, 267 extensions to RSVP are defined that allow it to establish intra- 268 domain Labeled Switched Paths (LSP) in Multi-Protocol Labeled Switch- 269 ing (MPLS). 271 [rfc2750] specifies extensions to RSVP so that it can support generic 272 policy based admission control. This standard goes beyond the sup- 273 port of the POLICY_DATA object stipulated in [rfc3209], by defining 274 the means of control and enforcement of access and usage policies. 275 While the standard does not advocate a particular policy architec- 276 ture, the IETF has defined one that can complement [rfc2750] -- we 277 expand on this in subsection 4.3 below. 279 4.2.1. Relation to ETS 281 The ability to reserve resources correlates to an ability to provide 282 preferential service for specifically classified traffic -- the clas- 283 sification being a tuple of 1 or more fields which may or may not 284 include an ETS specific label. In cases where a tuple includes a 285 label that has been defined for ETS usage, the reservation helps 286 ensure that an emergency related flow will be forwarded towards its 287 destination. Within the scope of this document, this means that RSVP 288 would be used to facilitate the forwarding of traffic within a 289 domain. 291 We note that this places an importance on defining a label and an 292 associated field that can be set and/or examined by RSVP capable 293 nodes. 295 Another important observation is that major vendor routers currently 296 constrain their examination of fields for classification to the net- 297 work and transport layers. This means that application layer labels 298 will mostly likely be ignored by routers/switches. 300 4.3. Policy 302 The Common Open Policy Service (COPS) protocol [rfc2748] was defined 303 to provide policy control over QoS signaling protocols, such as RSVP. 304 COPS is based on a query/response model in which Policy Enforcement 305 Points (PEPs) interact with Policy Decision Points (i.e., policy 306 servers) to exchange policy information. COPS provides application 307 level security and can operate over IPsec or TLS. COPS is also a 308 stateful protocol that also supports a push model. This means that 309 servers can download new policies, or alter existing ones to known 310 clients. 312 [rfc2749] articulates the usage of COPS with RSVP. This document 313 specifies COPS client types, context objects, and decision objects. 314 Thus, when an RSVP reservation is received by a PEP, the PEP decides 315 whether to accept or reject it based on policy. This policy informa- 316 tion can be stored a priori to the reception of the RSVP PATH mes- 317 sage, or it can be retrieved in an on-demand basis. A similar course 318 of action could be applied in cases where ETS labeled control flows 319 are received by the PEP. This of course would require an associated 320 (and new) set of documents that first articulates types of ETS sig- 321 naling and then specifies its usage with COPS. 323 A complementary document to the COPS protocols is COPS Usage for Pol- 324 icy Provisioning (COPS-PR) [rfc3084]. 326 As a side note, the current lack in deployment by network administra- 327 tors of RSVP has also played at least an indirect role in the subse- 328 quent lack of implementation & deployment of COPS-PR. [rfc3535] is 329 an output from the IAB Network Management Workshop in which the topic 330 of COPS and its current state of deployment was discussed. At the 331 time of that workshop in 2002, COPS-PR was considered a 332 technology/architecture that did not fully meet the needs of network 333 operators. It should also be noted that at the 60'th IETF meeting 334 held in San Diego in 2004, COPS was discussed as a candidate protocol 335 that should be declared as historic because of its lack of use and 336 concerns about its design. In the future, an altered design of COPS 337 may emerge that addresses the concern of operators, but speculation 338 of that or other possibilities is beyond the scope of this document. 340 4.4. Subnetwork Technologies 342 This is a generalization of work that is considered "under" IP and 343 for the most part outside of the IETF standards body. We discuss 344 some specific topics here because there is a relationship between 345 them and IP in the sense that each physical network interacts at its 346 edge with IP. 348 4.4.1. IEEE 802.1 VLANs 350 The IEEE 802.1q standard defined a tag appended to a Media Access 351 Controller (MAC) frame for support of layer 2 Virtual Local Area Net- 352 works (VLAN). This tag has two parts: a VLAN identifier (12 bits) 353 and a Prioritization field of three bits. A subsequent standard, 354 IEEE 802.1p, later incorporated into a revision of IEEE 802.1d, 355 defined the Prioritization field of this new tag [iso15802]. It con- 356 sists of eight levels of priority, with the highest priority being a 357 value of 7. Vendors may choose a queue per priority codepoint, or 358 aggregate several codepoints to a single queue. 360 The three bit Prioritization field can be easily mapped to the old 361 ToS field of the upper layer IP header. In turn, these bits can also 362 be mapped to a subset of differentiated code points. Bits in the IP 363 header that could be used to support ETS (e.g., specific Diff-Serv 364 code points) can in turn be mapped to the Prioritization bits of 365 802.1p. This mapping could be accomplished in a one-to-one manner 366 between the 802.1p field and the IP ToS bits, or in an aggregate 367 manner if one considers the entire Diff-Serv field in the IP header. 368 In either case, because of the scarcity of bits, ETS users should 369 expect that their traffic will be combined or aggregated with the 370 same level of priority as some other types of "important" traffic. 371 In other words, given the existing 3 bit Priority Field for 802.1p, 372 there will not be an exclusive bit value reserved for ETS traffic. 374 Certain vendors are currently providing mappings between 802.1p field 375 and the ToS bits. This is in addition to integrating the signaling 376 of RSVP with the low level inband signaling offered in the Priority 377 field of 802.1p. 379 It is important to note that the 802.1p standard does not specify the 380 correlation of a layer 2 codepoint to a physical network bandwidth 381 reservation. Instead, this standard provides what has been termed as 382 "best effort QoS". The value of the 802.1p Priority code points is 383 realized at the edges: either as the MAC payload is passed to upper 384 layers (like IP), or bridged to other physical networks like Frame 385 Relay. Either of these actions help provide an intra-domain wide 386 propagation of a labeled flow for both layer 2 and layer 3 flows. 388 4.4.2. IEEE 802.11e QoS 390 The 802.11e standard is a proposed enhancement that specifies mechan- 391 isms to provide QoS to the 802.11 family of protocols for wireless 392 LANs. 394 Previously, 802.11 had two modes of operation. One was Distributed 395 Coordination Function (DCF) , which is based on the classic collision 396 detection schema of "listen before sending". A second optional mode 397 is the Point Coordination Function (PCF). The modes splits access 398 time into contention-free and contention-active periods -- transmit- 399 ting data during the former. 401 The 802.11e standard enhances DCF by adding support for eight dif- 402 ferent traffic categories or classifications. Each higher category 403 waits a little less time than the next lower one before it sends its 404 data. 406 In the case of PCF, a Hybrid Coordination Function has been added 407 that polls stations during contention-free time slots and grants them 408 a specific start time and maximum duration for transmission. This 409 second mode is more complex than enhanced DCF, but the QoS can be 410 more finely tuned to offer specific bandwidth control and jitter. It 411 must be noted that neither enhancement offers a guarantee of service. 413 4.4.3. Cable Networks 415 The Data Over Cable Service Interface Specification (DOCSIS) is a 416 standard used to facilitate the communication and interaction of the 417 cable subnetwork with upper layer IP networks [docsis]. Cable sub- 418 networks tend to be asynchronous in terms of data load capacity: 419 typically, 27M downstream, and anywhere from 320kb to 10M upstream 420 (i.e., in the direction of the user towards the Internet). 422 The evolution of the DOCSIS specification, from 1.0 to 1.1, brought 423 about changes to support a service other than best effort. One of 424 the changes was indirectly added when the 802.1D protocol added the 425 Priority field, which was incorporated within the DOCSIS 1.1 specifi- 426 cation. Another change was the ability to perform packet fragmenta- 427 tion of large packets so that Priority marked packets (i.e., packets 428 marked with non-best effort labels) can be multiplexed in between the 429 fragmented larger packet. 431 Its important to note that the DOCSIS specifications do not specify 432 how vendors implement classification, policing, and scheduling of 433 traffic. Hence, operators must rely on mechanisms in Cable Modem 434 Termination Systems (CMTS) and edge routers to leverage indirectly or 435 directly the added specifications of DOCSIS 1.1. As in the case of 436 802.1p, ETS labeled traffic would most likely be aggregated with 437 other types of traffic, which implies that an exclusive bit (or set 438 of bits) will not be reserved for ETS users. Policies and other 439 managed configurations will determine the form of the service experi- 440 enced by ETS labeled traffic. 442 Traffic engineering and management of ETS labeled flows, including 443 its classification and scheduling at the edges of the DOCSIS cloud, 444 could be accomplished in several ways. A simple schema could be 445 based on non-FIFO queuing mechanisms like class based queuing, 446 weighted fair queuing (or combinations and derivations thereof). The 447 addition of active queue management like Random Early Detection could 448 provide simple mechanisms for dealing with bursty traffic contribut- 449 ing to congestion. A more elaborate scheme for traffic engineering 450 would include the use of MPLS. However, the complexity of MPLS 451 should be taken into consideration before its deployment in networks. 453 4.5. Multicast 455 Network layer multicast has existed for quite a few years. Efforts 456 such as the Mbone have provided a form of tunneled multicast that 457 spans domains, but the routing hierarchy of the Mbone can be con- 458 sidered flat and non-congruent with unicast routing. Efforts like 459 the Multicast Source Discovery Protocol [rfc3618] together with the 460 Protocol Independent Multicast Sparse Mode (PIM-SM) have been used by 461 a small subset of Internet Service Providers to provide form of 462 inter-domain multicast [rfc2362]. However, network layer multicast 463 has for the most part not been accepted as a common production level 464 service by a vast majority of ISPs. 466 In contrast, intra-domain multicast in domains has gained more accep- 467 tance as an additional network service. Multicast can produce denial 468 of service attacks using the any sender model, with the problem made 469 more acute with flood & prune algorithms. Source specific multicast 470 [rfc3569], together with access control lists of who is allowed to be 471 a sender, reduces the potential and scope of such attacks. 473 4.5.1. IP Layer 475 The value of IP multicast is its efficient use of resources in send- 476 ing the same datagram to multiple receivers. An extensive discussion 477 on the strengths and concerns about multicast is outside the scope of 478 this document. However, one can argue that multicast can very natur- 479 ally complement the push-to-talk feature of land mobile radio net- 480 works (LMR). 482 Push-to-talk is a form of group communication where every user in the 483 "talk group" can participate in the same conversation. LMR is the 484 type of network used by First Responders (e.g., police, fireman, and 485 medical personnel) that are involved in emergencies. Currently, cer- 486 tain vendors and providers are offering push-to-talk service to the 487 general public in addition to First Responders. Some of these sys- 488 tems are operated over IP networks, or are interfaced with IP net- 489 works to extend the set of users that can communicate with each 490 other. We can consider at least a subset of these systems as either 491 closed IP networks, or domains, since they do not act as transits to 492 other parts of the Internet. 494 The potential integration of LMR talk groups with IP multicast is an 495 open issue. LMR talk groups are established in a static manner with 496 man-in-the-loop participation in their establishment and teardown. 497 The seamless integration of these talk groups with multicast group 498 addresses is a feature that has not been discussed in open forums. 500 4.5.2. IEEE 802.1d MAC Bridges 502 The IEEE 802.1d standard specifies fields and capabilities for a 503 number of features. In subsection 4.3.2 above, we discussed its use 504 for defining a Prioritization field. The 802.1d standard also covers 505 the topic of filtering MAC layer multicast frames. 507 One of the concerns about multicast are broadcast storms that can 508 arise and generate a denial of service against other users/nodes. 509 Some administrators purposely filter out multicast frames in cases 510 where the subnetwork resource is relatively small (e.g., 802.11 net- 511 works). Operational considerations with respect to ETS may wish to 512 consider doing this in an as-needed basis based on the conditions of 513 the network against the perceived need for multicast. In cases where 514 filtering out multicast can be activated dynamically, COPS may be a 515 good means of providing consistent domain-wide policy control. 517 4.6. Discovery 519 If a service is being offered to explicitly support ETS, then it 520 would seem reasonable that discovery of the service may be of bene- 521 fit. For example, if a domain has a subset of servers that recognize 522 ETS labeled traffic, then dynamic discovery of where these servers 523 are (or even if they exist) would be more beneficial compared to 524 relying on statically configured information. 526 The Service Location Protocol (SLP) [rfc2608] is designed to provide 527 information about the existence, location, and configuration of 528 networked services. In many cases, the name of the host supporting 529 the desired service is needed to be known a priori in order for users 530 to access it. SLP eliminates this requirement by using a descriptive 531 model that identifies the service. Based on this description, SLP 532 then resolves the network address of the service and returns this 533 information to the requester. An interesting design element of SLP 534 is that it assumes that the protocol is run over a collection of 535 nodes that are under the control of a single administrative author- 536 ity. This model follows the scope of this framework document. How- 537 ever, the scope of SLP may be better suited for parts of an enter- 538 prise network versus an entire domain. 540 Anycasting [rfc1546] is another means of discovering nodes that sup- 541 port a given service. Interdomain anycast addresses, propagated by 542 BGP, represent anycast in a wide scope and have been used by multiple 543 root servers for a while. Anycast can also be realized in a more 544 constrained and limited scope (i.e., solely within a domain or sub- 545 net), and as in the case of multicast may not be supported. 547 [rfc3513] covers the topic of anycast addresses for IPv6. Unlike 548 SLP, users/applications must know the anycast address associated with 549 the target service. In addition, responses to multiple requests to 550 the anycast address may come from different servers. Lack of 551 response (not due to connectivity problems) correlates to the 552 discovery that a target service is not available. Detailed tradeoffs 553 between this approach and SLP is outside the scope of this framework 554 document. 556 The Dynamic Delegation Discovery System is used to implement a 557 binding of strings to data, in order to support dynamically config- 558 ured delegation systems [rfc3401]. The DDDS functions by mapping 559 some unique string to data stored within a DDDS Database by itera- 560 tively applying string transformation rules until a terminal condi- 561 tion is reached. The potential then exists where a client could 562 specify a set of known tags (e.g., RetrieveMail:Pop3) which would 563 identify/discover the appropriate server with which it can communi- 564 cate. 566 4.7. Differentiated Services (Diff-Serv) 568 There are a number of examples where Diff-Serv [rfc2274] has been 569 deployed strictly within a domain, with no extension of service to 570 neighboring domains. Various reasons exist for Diff-Serv not being 571 widely deployed in an inter-domain context, including ones rooted in 572 the complexity and problems in supporting the security requirements 573 for Diff-Serv code points. An extensive discussion on Diff-Serv 574 deployment is outside the scope of this document. 576 [Baker] presents common examples of various codepoints used for well 577 known applications. The document does not recommend these associa- 578 tions as being standard or fixed. Rather, the examples in [Baker] 579 provide a reference point for known deployments that can act as a 580 guide for other network administrators. 582 An argument can be made that Diff-Serv, with its existing code point 583 specifications of Assured Forwarding (AF) and Expedited Forwarding 584 (EF), goes beyond what would be needed to support ETS within a 585 domain. By this we mean that the complexity in terms of maintenance 586 and support of AF or EF may exceed or cause undue burden on the 587 management resources of a domain. Given this possibility, users or 588 network administrators may wish to determine if various queuing 589 mechanisms, like class based weighted fair queuing, is sufficient to 590 support ETS flows through a domain. Note, as we stated earlier in 591 section 2, over provisioning is another option to consider. We 592 assume that if the reader is considering something like Diff-Serv, 593 then it has been determined that over provisioning is not a viable 594 option given their individual needs or capabilities. 596 5. Security Considerations 598 Services used to offer better or best available service for a partic- 599 ular set of users (in the case of this document, ETS users) are prime 600 targets for security attacks, or simple misuse. Hence, administra- 601 tors that choose to incorporate additional protocols/services to 602 support ETS are strongly encouraged to consider new policies to 603 address the added potential of security attacks. These policies, and 604 any additional security measures, should be considered independent of 605 any mechanisms or equipment that restricts access to the administra- 606 tive domain. 608 Determining how authorization is accomplished is open issue. Many 609 times the choice is a function of the service that is deployed. One 610 example is source addresses in an access list permitting senders to 611 the multicast group (as described in section 4.5). Within a single 612 domain environment, cases can be found where network administrators 613 tend to find this approach acceptable. However, other services may 614 require more stringent measures that employ detailed credentials, and 615 possibly multiple levels of access and authentication. Ease of use, 616 deployment, scalability, and susceptability to security breach all 617 play a role in determining authorization schemas. The potential is 618 that accomplishing this for only a single domain may be easier than 619 at the inter-domain scope if only in terms of scalability and trust. 621 6. Summary Comments 623 This document has presented a number of protocols and complementary 624 technologies that can be used to support ETS users. Their selection 625 is dictated by the fact that all or significant portions of the pro- 626 tocols can be operated and controlled within a single administrative 627 domain. It is this reason why other protocols like those under 628 current development in the Next Steps in Signaling (NSIS) working 629 group have not be discussed. 631 By listing a variety of efforts in this document, we avoid taking on 632 the role of "king maker" and at the same time indirectly point out 633 that a variety of solutions exist in support of ETS. These solutions 634 may involve QoS, traffic engineering, or simply protection against 635 detrimental conditions (e.g., spikes in traffic load). Again, the 636 choice is up to the reader. 638 7. Acknowledgements 640 Thanks to Ran Atkinson, Scott Bradner, Jon Peterson, and Kimberly 641 King for comments and suggestions on this draft. 643 8. IANA Considerations 645 This document has no considerations for IANA 647 9. References 649 9.1. Normative Reference 651 [rfc4375] Carlberg, K., "Requirements for Supporting Emergency 652 Telecommunications Services in Single Domains", 653 RFC 4375, January 2006 655 9.2. Informative References 657 [baker] Baker, F., et. al., "Configuration Guidelines for 658 DiffServ Service Classes", Internet Draft, 659 draft-ietf-tsvwg-diffserv-service-classes-02, Work In 660 Progress, Feb 2006 662 [docsis] "Data-Over-Cable Service Interface Specifications: Cable 663 Modem to Customer Premise Equipment Interface 664 Specification SP-CMCI-I07-020301", DOCSIS, March 2002, 665 http://www.cablemodem.com. 667 [iso15802] "Information technology - Telecommunications and 668 information exchange between systems - Local and 669 metropolitan area networks - Common specifications - 670 Part 3: Media Access Control (MAC) Bridges: Revision. 671 This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 672 and 802.6k-1992. It incorporates P802.11c, P802.1p 673 and P802.12e." ISO/IEC 15802-3:1998" 675 [rfc1546] Partridge, C., et al, "Host Anycasting Service", RFC 676 1546, November 1993 678 [rfc2131] Droms, R., "Dynamic Host Configuration Protocol", 679 RFC 2131, March 1997 681 [rfc2205] Braden, R., et al, "Resource Reservation Protocol (RSVP) 682 Version 1 Functional Specification", RFC 2205, Sept 1997 684 [rfc2362] Estrin, D., et al, "Protocol Independent Multicast-Sparse 685 Mode (PIM-SM): Protocol Specification", RFC 2362, June 686 1998 688 [rfc2474] Nichols, K., et al, "Definition of the Differentiated 689 Services Field (DS Field) in the IPv4 and IPv6 Headers", 690 RFC 2474, December 1998. 692 [rfc2608] Guttman, C., et al, "Service Location Protocol, Version 693 2", RFC 2608, June 1999. 695 [rfc2748] Durham, D., et al, "The COPS (Common Open Policy 696 Service) Protocol", RFC 2748, January 2000. 698 [rfc2749] Herzog, S., et al, "COPS Usage for RSVP", RFC 2749, 699 January 2000 701 [rfc2750] Herzog, S., "RSVP Extensions for Policy Control", 702 RFC 2750, January 2000 704 [rfc3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 705 Label Switching Architecture", RFC 3031, January 2001. 707 [rfc3270] Le Faucheur, F., et al, "MPLS Support of Differentiated 708 Services", RFC 3270, May 2002 710 [rfc3209] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP 711 Tunnels", RFC 3209, December 2001 713 [rfc3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 714 August 2002 716 [rfc3084] Chan, K., et al, "COPS Usage for Policy Provisioning 717 (COPS-PR)", RFC 3084, March 2001 719 [rfc3401] Mealling, M., "Dynamic Delegation Discovery System 720 (DDDS) Part One: The Comprehensive DDDS", RFC 3401 721 Oct 2002 723 [rfc3513] Hinden, R., Deering, S., "Internet Protocol Version 6 724 (IPv6) Addressing Architecture", RFC 3513, April 2003 726 [rfc3535] Schoenwaelder, J., "Overview of the 2002 IAB Network 727 Management Workshop", RFC 3535, May 2003 729 [rfc3569] Bhattacharyya, S., "An Overview of Source-Specific 730 Multicast (SSM)", RFC 3569, July, 2003 732 [rfc3618] Meyer, D., Fenner, B., "Multicast Source Discovery 733 Protocol (MSDP)", RFC 3618, October 2003 735 [rfc4190] Carlberg, K,. et. al, "Framework for Supporting ETS in 736 IP Telephony", RFC 4190, IETF, November 2005. 738 Table of Contents 740 1. Introduction ................................................... 2 741 1.1 Differences between Single and Inter-domain .................. 2 742 2. Common Practice: Provisioning .................................. 3 743 3. Objective ...................................................... 4 744 3.1 Scenarios ..................................................... 4 745 4. Topic Areas .................................................... 5 746 4.1 MPLS .......................................................... 5 747 4.2 RSVP .......................................................... 6 748 4.2.1 Relation to ETS ............................................. 7 749 4.3 Policy ........................................................ 7 750 4.4 Subnetwork Technologies ....................................... 8 751 4.4.1 IEEE 802.1 VLANs ........................................... 8 752 4.4.2 IEEE 802.11e QoS ........................................... 9 753 4.4.3 Cable Networks ............................................. 9 754 4.5 Multicast ..................................................... 10 755 4.5.1 IP Layer ................................................... 11 756 4.5.2 IEEE 802.1d MAC Bridges .................................... 11 757 4.6 Discovery ..................................................... 12 758 4.7 Differentiated Services (Diff-Serv) ........................... 13 759 5. Security Considerations ....................................... 13 760 6. Summary Comments .............................................. 14 761 7. Acknowledgements ............................................... 14 762 8. IANA Considerations ............................................ 14 763 9. References ..................................................... 15 764 9.1 Normative Reference ........................................... 15 765 9.2 Informative References ........................................ 15 767 10. Author's Address 769 Ken Carlberg 770 G11 771 123a Versailles Circle 772 Baltimore, MD 773 USA 774 carlberg@g11.org.uk 776 Intellectual Property Statement 778 The IETF takes no position regarding the validity or scope of any 779 Intellectual Property Rights or other rights that might be claimed to 780 pertain to the implementation or use of the technology described in 781 this document or the extent to which any license under such rights 782 might or might not be available; nor does it represent that it has 783 made any independent effort to identify any such rights. Information 784 on the procedures with respect to rights in RFC documents can be 785 found in BCP 78 and BCP 79. 787 Copies of IPR disclosures made to the IETF Secretariat and any 788 assurances of licenses to be made available, or the result of an 789 attempt made to obtain a general license or permission for the use of 790 such proprietary rights by implementers or users of this specifica- 791 tion can be obtained from the IETF on-line IPR repository at 792 http://www.ietf.org/ipr. 794 The IETF invites any interested party to bring to its attention any 795 copyrights, patents or patent applications, or other proprietary 796 rights that may cover technology that may be required to implement 797 this standard. Please address the information to the IETF at ietf- 798 ipr@ietf.org. 800 Disclaimer of Validity 802 This document and the information contained herein are provided on an 803 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 804 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 805 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 806 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 807 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 808 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 810 Copyright Statement 812 Copyright (C) The Internet Society (2006). This document is subject 813 to the rights, licenses and restrictions contained in BCP 78, and 814 except as set forth therein, the authors retain all their rights. 816 Acknowledgment 818 Funding for the RFC Editor function is currently provided by the 819 Internet Society