idnits 2.17.1 draft-folts-ohno-ieps-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. 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.) -- The document date (June 16, 2000) is 8708 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Folts 3 Internet-Draft NCS, USA 4 Expires: December 15, 2000 H. Ohno 5 Communications Research Lab, Japan 6 June 16, 2000 8 Functional Requirements for 9 Priority Services to Support Critical Communications 11 draft-folts-ohno-ieps-considerations-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full 16 conformance with all provisions of Section 10 of 17 RFC2026. 19 Internet-Drafts are working documents of the Internet 20 Engineering Task Force (IETF), its areas, and its 21 working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum 25 of six months and may be updated, replaced, or 26 obsoleted by other documents at any time. It is 27 inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be 35 accessed at http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 12, 2000. 39 Copyright Notice 41 Copyright (C) The Internet Society (2000). All Rights 42 Reserved. 44 Abstract 46 This draft requests development of detailed specifications for the 47 technical and operational requirements for an Internet-based 48 International Emergency Preparedness Scheme (IEPS) as 50 Internet draft IEPS Considerations June 16, 2000 52 defined by ITU-T Recommendation E.106. Public 53 telecommunications services have long had such a 54 scheme, to ensure priority handling of telephone 55 communications, such as during natural disasters. As a 56 wide range of communication services increasingly rely 57 upon the family of specifications related to Internet 58 Protocol (IP), IETF work needs to include consideration 59 and provision for supporting IEPS. This work needs to 60 be addressed in two phases concurrently - 1) interface 61 for transition from today's public switched telephone 62 network (PSTN) to IP-based network telephony services, 63 and 2) additional and enhanced capabilities, such as 64 application-specific IEPS services. An Email list for discussion 65 and a Web site for background and documents has been established 66 to assist the work 68 1. Introduction 70 There is a need for priority communications among 71 governmental, civil, and other essential users of 72 public telecommunications services in crisis 73 situations, such as earthquakes, severe storms, and 74 floods. Telecommunication services are often restricted 75 during these events due to damage, congestion, and 76 failures. ITU-T Recommendation E.106 describes an 77 International Emergency Preparedness Scheme (IEPS) for 78 telecommunications services that will support recovery 79 activities during crisis situations. 81 The IEPS will enable authorized users to have priority 82 access to telecommunication services and priority 83 processing of communications, in support of recovery 84 operations during emergency events. It is essential 85 that appropriate arrangements exist to permit these 86 operations among the many communications service 87 providers and nations of the world. While many 88 countries have national preparedness schemes in 89 existing telecommunication systems, the challenge at 90 hand is provisioning appropriate priority mechanisms in 91 the newly emerging generation of IP-based networks. 92 There will be the challenge initially of interfacing 93 the emergency handling process in existing telephony 94 services with IP-based services during the transition 95 period where both services will interwork. Measures will 96 also need to be considered for security protection of IEPS 97 communications passing through the IP-based network 99 In addition the broad range of IP-based services, with 100 their enhanced capabilities, can significantly benefit 102 Internet draft IEPS Considerations June 16, 2000 104 IEPS users and operations. These include: 106 Web access * Instant messaging 107 * Remote printing * Email 108 * File transfer * Wireless access 109 * Multicast audio and * Interactive audio 110 video and video 111 * Remote data base * DNS lookups 112 queries 113 * Remote network * Prioritized and 114 management interactions differential IP handling 116 All of these services could be considered for 117 preferential treatment, authorization, and 118 administration for IEPS. Considerable work is currently 119 underway in many standards bodies to define new 120 mechanisms, protocols, and procedures for advancing 121 networking technology. It would be immensely beneficial 122 to telecommunication users, service providers, and 123 nations of the world to support IEPS within the rich 124 communications capabilities inherent in the IP-based 125 operating infrastructure. 127 This draft suggests where work might be undertaken to 128 introduce IEPS in the newly emerging telecommunications 129 environment. The immediate focus needs to be on the 130 interface between PSTN services and IP-based networks 131 for supporting IEPS requirements. At the same time, 132 consideration will need to be taken of the many 133 additional services that will further enhance IEPS 134 capabilities and operations. Realization of IEPS 135 requirements in the next generation of 136 telecommunication services should be accomplished by 137 common mechanisms inherent in the new basic 138 infrastructure. 140 2. IEPS Services Today 142 ITU-T Recommendation E.106 addresses IEPS in terms of 143 the Public Switched Telephone Network (PSTN) and 144 Integrated Services Digital Network (ISDN). Today's 145 systems are based primarily upon well-established circuit- 146 switched technology and principles. The essential 147 features described by E.106 for the successful 148 operation of IEPS are: 150 a) Priority dial tone 151 b) Priority call set-up, including priority queuing 152 schemes 154 Internet draft IEPS Considerations June 16, 2000 156 c) Exemption from restrictive management controls 158 The following paragraphs provide some examples of IEPS services 159 available today. These examples cover both PSTN and Internet-based 160 implementations. They represent the point of departure into the 161 technical work of the IETF to support IEPS requirements in the 162 next generation of specifications. 164 2.1 In the United States, the Government Emergency 165 Telecommunications Service (GETS) uses High Probability 166 of Completion (HPC) network capability for marking 167 emergency calls. In accordance with ANSI T1.631-1993, 168 the Calling Party's Category parameter is used to mark 169 emergency calls within the initial address message 170 (IAM) for call set-up in Signalling System No 7 (SS7). 171 This specific parameter has been set aside by the ITU-T 172 in Recommendation Q.763 for national use. This 173 parameter is used to trigger special applications 174 within the U.S. PSTN to enhance call completion. 176 Alternate carrier routing (ACR) is also employed in the 177 GETS because there are multiple inter-exchange carriers 178 (IXC) supporting the service in the United States. If 179 one IXC is not available, the call is redirected to 180 another IXC until all possibilities are exhausted. 182 2.2 For the past five years an emergency communications system has 183 been under development in Japan to support recovery from major 184 disasters such as the devastating earthquake that hit the city 185 of Kobe in 1995. The WIDE (Widely Integrated Distributed 186 Environment) project, a well-known research consortium on 187 Internet technologies in Japan, developed an emergency system 188 called IAA ("I am alive"). This is a scalable and robust 189 distributed database system that supports voice, touch-tone, 190 cell phone, facsimile, www, and other user interfaces for 191 emergency communications. IAA supports registration and retrieval 192 of information for victims and to support the many recovery 193 activities in a disaster area. It is based upon Internet 194 technology to provide the diversity and flexibility required 195 for supporting emergency communications under the most severe 196 conditions. The development of IAA has been a cooperative effort 197 of Japanese universities, industry, and the Communication Research 198 Laboratory (CRL), Ministry of Posts and Telecommunications. 200 2.3 Other countries also have national operational IEPS capabilities, 201 or ones under development. They employ various access 202 schemes for telephony services. Some identify access 203 lines where all calls originated on that line are 204 treated with priority service. Another approach 205 activates priority service on a per-call basis only 207 Internet draft IEPS Considerations June 16, 2000 209 The dialing plan for GETS uses a universal access 210 number with a non-geographic, toll free Numbering Plan 211 Area (NPA) code that has been assigned by the North 212 American Numbering Plan Administration (NANPA) to the 213 United States Government. After dialing the universal 214 access number, the user is prompted for a Personal 215 Identification Number (PIN). When the PIN is 216 authenticated, the originator will then be requested to 217 enter the destination number. 219 Fulfillment of the basic IEPS capabilities by today's 220 telephony services has required addition of special 221 provisions to existing implementations. They have 222 proven successful and effective, but they have resulted 223 in considerable expenditure of effort and resources. It 224 would be much more desirable that basic mechanisms, 225 which are implemented as an inherent part of the 226 emerging network infrastructure, be used to also 227 support the IEPS communication capabilities. These 228 mechanisms could be adapted from those implemented or 229 under development for other service offerings. 231 3. Next Generation Networks 233 The IEPS requirements of E.106 also need to be 234 fulfilled by the next generation of telecommunications 235 services, which are based upon packet-switched 236 technology. Packet technology provides a significantly 237 different operational environment than exists for 238 today's circuit-oriented telecommunications. As a 239 result, there are many new aspects that must be 240 considered in satisfying IEPS requirements. There is 241 also opportunity for adapting many innovative service 242 features and capabilities that are becoming available 243 to enhance IEPS operations. 245 Implementation of IEPS requirements in IP-based 246 networks ideally should be incorporated into the common 247 mechanisms that are built into the infrastructure as 248 they are being developed and deployed. IEPS 249 requirements should be viewed as another communication 250 service being offered by service providers as part of 251 their business structure. For example, efforts already 252 underway to develop mechanisms for selecting and 253 managing different levels of quality, grade and classes 254 of service could be applied to IEPS. The flexibility of 255 emerging object-oriented and distributed technologies 256 might have the potential for readily and economically 257 supporting a diversity of service features. At a 259 Internet draft IEPS Considerations June 16, 2000 261 minimum, an IEPS indicator to identify emergency 262 communications needs to be defined and conveyed in the 263 IP-based network environment. The IEPS indicator could 264 be similar to the HPC code point used in SS7 for call 265 set-up in traditional PSTN operations. However, the 266 IEPS indicator in IP-based networks must also be 267 applied throughout the duration of the communication 268 and other indicators, such as at the application level, 269 might also be appropriate. 271 Extensive activities are underway in international, 272 regional, and national industry standards bodies to 273 develop specifications for next generation networks. 274 These bodies include IETF, ETSI TIPHON, and ITU-T. 275 Close cooperation needs to be maintained among these 276 organizations to facilitate consistent results and 277 global agreement. There is also considerable ongoing 278 work underway to define the many features and 279 mechanisms needed to support diverse services that will 280 be provided by evolving telecommunications 281 capabilities. While ITU-T Recommendation E.106 is based 282 on PSTN/ISDN services, it is imperative that early 283 attention be given to meeting the IEPS requirements in 284 future telecommunication services supported by next 285 generation of networks. Now is the time to ensure full 286 consideration of the IEPS requirements in both the 287 current and the future IP-based network endeavors 288 before results fully mature and are deployed. 290 4. Issues to be Addressed 292 Compared with circuit-based systems, packet-switched 293 environments often display better statistical 294 reliability and performance, but far less specific 295 predictability. The packet-switched environment 296 introduces many additional variables in processing of 297 supported services. The "send and pray" nature of 298 typical connectionless packet mode is being adapted to 299 support a variety of performance levels required by 300 various communicating applications. For instance, new 301 quality-of-service mechanisms are being developed to 302 support telephony and interactive video applications. 303 Features needed to support IEPS emergency 304 communications on an end-to-end basis include priority 305 access, routing, processing, and egress for the 306 duration of the communication. Important issues include 307 the evolution of services transitioning from today's 308 PSTN/ISDN to the new IP-based environment as 309 illustrated in the TIPHON scenarios defined in ETSI 311 Internet draft IEPS Considerations June 16, 2000 313 Document TR 101 300 v2.1.1. 315 Transition of the existing service requires that an 316 interface between the SS7 HPC code point in the IAM for 317 call set-up and the IP-based network protocols be 318 developed. Most likely is that an IEPS indicator needs 319 to be defined and appropriate protocol fields need to 320 be identified to carry the code point information. Next 321 the code point needs to be recognized, processed, and 322 conveyed through an IP-based network, either to the end 323 application directly or to another interface with SS7. 324 The IEPS indicator must also be recognized and 325 processed during the entire period of the communication 326 in the IP-based environment. 328 4.1 Specific issues to be considered initially to facilitate 329 a transition from PSTN to IP telephony services include the following: 331 4.1.1 - Technical Issues 333 a) The protocol mechanisms of IP-based networks in 334 operation and under development that could convey an HPC- 335 type IEPS indicator to identify set-up of an emergency 336 telephone communication. This would enable priority routing 337 and processing ahead of other traffic being offered. 339 b) A field in the header of any candidate protocol that 340 might be involved in conveying an emergency communication 341 indication needs to be identified and space reserved for a 342 code point. 344 c) Appropriate code point(s) to be used to convey the IEPS 345 indicator through the IP-based environment needs to be 346 registered. 348 d) Measures for security protection of IEPS communications 349 transiting IP-environments. Issues that need to be considered 350 include authentication/authorization for call initiation and 351 protection of IEPS communications from cyber attacks in 352 IP-based networks. 354 4.1.2 - Operational Issues 356 a) Procedures and processes for handling the IEPS 357 indicator in the IP-based environment. This includes 358 priority routing of packets as well as alternate routing 359 capabilities when congestion or outage is encountered during 360 the communication. 361 4.2 Further work will be needed to define specifications for special 362 handling of new IP-based applications, of the type 364 Internet draft IEPS Considerations June 16, 2000 366 and range listed earlier in section 1. At the same time, 367 extension of the basic capability needs specified in the initial 368 work described in 4.1 need to be considered for new features that 369 become available in the new IP-based network environment. 371 The following identifies a number of the technical and operational 372 capabilities that should be studied for enhancing future IEPS 373 services: 375 a) Maintenance of the priority status of a communication 376 for its total duration. 378 b) Maintenance of the required quality of service to 379 support the instance of communication. 381 c) Maintenance of the required grade of service to ensure 382 a minimum bandwidth or throughput level during heavy traffic 383 conditions. 385 d) Dynamic alternate routing of IEPS communications when 386 congestion and failure occurs. This may require quicker 387 adaptation than typical IP-based adaptive routing affords. 389 e) Interchange of critical operational data across the 390 interdomain Telecommunications Management Network (TMN) X- 391 interface, as specified in ITU-T M.3010. Possible examples 392 include: 394 * Registration of authorized users 395 * Monitoring of service performance 396 * Identification of security breaches and unauthorized 397 use of IEPS 398 * Activation/deactivation of IEPS services or priority 399 levels in specific regions 400 * Reports of failure points in telecommunications 401 infrastructure 402 * Status of recover actions 403 * Interchange of critical data related to recovery 404 operations 405 * Reports of usage and billing information 407 f) Preferential treatment for IP-based applications, such 408 as Email, instant messaging, remote printing, web access, 409 file transfer, multi-cast video, interactive audio, remote 410 network management, and DNS lookups. 412 g) Multicast and broadcast services for voice, data, and 413 video. 415 h) Definition of multiple levels of emergency priority, 417 Internet draft IEPS Considerations June 16, 2000 419 possibly including different types of service as well as 420 different degrees. 422 i) Interface for access by mobile and/or constrained IP- 423 based devices, such as are developing with wireless access. 425 As the telecommunications technologies continue to 426 evolve innovations and further enhancements to IEPS 427 support services will emerge. It is critical that 428 efforts to address these many issues are established as 429 early as possible in the work underway and in future 430 work to develop specifications for next generation 431 networks. 433 5. Candidate Work Areas 435 The IEPS requirements could potentially touch on many of 436 the IETF work areas. Initially, the focus should be on 437 specific issues described in section 4 to facilitate the 438 transition from the PSTN to IP telephone services. In particular, 439 the following technology/protocol issues have been identified as 440 initial candidate areas that should be examined: 442 Session Initiation Protocol (SIP) 443 Multimedia Gateway Control Protocol (MGCP) 444 Multi-Queue 445 Differential Services (diffserv) 446 Multi-Protocol Label Switching (MPLS) 447 Aggregated RSVP 449 It is plausible that IEPS requirements could have as pervasive an 450 impact as security in IETF work. Nearly all IETF working groups 451 devoted to specification of infrastructure service, core 452 applications, or reliability and other quality of service features 453 are candidates. Hence, although quite long, the following is 454 merely representative of the range, and part of the early IETF 455 work is to define the complete list: 457 * Applications Area 458 - Common Name Resolution Protocol (cnrp) 459 - Extensions to FTP (ftpext) 460 - HyperText Transfer Protocol (http) 461 - Instant Messaging and Presence Protocol (impp) 462 - Internet Printing Protocol (ipp) 463 - LDAP Duplication/Replication/Update Protocols (ldup) 464 - Message Tracking Protocol (msgtrk) 465 - NNTP Extensions (nntpext) 466 - Web Replication and Caching (wrec) 468 Internet draft IEPS Considerations June 16, 2000 470 * Internet Area 471 - DNS Extensions (dnsext) 472 - IPNG (ipngwg) 473 - Internationalized Domain Name (idn) 474 - Service Location Protocol (svrloc) 475 - Zero Configuration Networking (zeroconf) 477 * Operations and Management Area 478 - Authentication, Authorization and Accounting (aaa) 479 - Domain Name Server Operations (dnsop) 480 - Internet Traffic Engineering (tewg) 481 - Network Access Server Requirements (nasreq) 482 - Next Generation Transition (ngtrans) 483 - Policy Framework (policy) 484 - Resource Allocation Protocol (rap) 485 - Roaming Operations (roamops) 487 * Routing Area 488 - Border Gateway Multicast Protocol (bgmp) 489 - IP Routing for Wireless/Mobile Hosts (mobileip) 490 - IS-IS for IP Internets (isis) 491 - Inter-Domain Routing (idr) 492 - Multicast Source Discovery Protocol (msdp) 493 - Multiprotocol Label Switching (mpls) 494 - Open Shortest Path First IGP (ospf) 495 - UniDirectional Link Routing (udlr) 496 - Virtual Router Redundancy Protocol (vrrp) 498 * Security Area 499 - Authenticated Firewall Traversal (aft) 500 - Common Authentication Technology (cat) 501 - IP Security Policy (ipsp) 502 - IP Security Remote Access (ipsra) 503 - Secure Network Time Protocol (stime) 505 * Transport Area 506 - Audio/Video Transport (avt) 507 - Differentiated Services (diffserv) 508 - Endpoint Congestion Management (ecm) 509 - IP Telephony (iptel) 510 - Integrated Services (intserv) 511 - Integrated Services over Specific Link Layers (issll) 512 - Media Gateway Control (megaco) 513 - Multicast-Address Allocation (malloc) 514 - Network Address Translators (nat) 515 - PSTN and Internet Internetworking (pint) 516 - Resource Reservation Setup Protocol (rsvp) 517 - Service in the PSTN/IN Requesting InTernet Service 518 (spirits) 519 - Session Initiation Protocol (sip) 521 Internet draft IEPS Considerations June 16, 2000 523 - Signaling Transport (sigtran) 524 - Telephone Number Mapping (enum) 526 This list should be modified as other areas are identified as 527 candidates and as development of specifications for these 528 capabilities improve our understanding of them. 530 6. Email List and Web Site 532 An Email list has been established for discussion of the IEPS 533 issues - ieps@listserv.gsfc.nasa.gov, to subscribe send Email to 534 majordomo@listserv.gsfc.nasa.gov indicating: subscribe ieps - in 535 the body (do not include any other text in the body). 537 The Web Site at http://www.iepscheme.net provides background and 538 access to working documents. 540 7. Conclusion 542 NS/EP capabilities within the telecommunications 543 infrastructure can significantly benefit the nations of 544 the world and the telecommunication service providers 545 in recovery from extreme stress on operational 546 facilities and recovery from major disasters. 548 The NS/EP priority capability should be accomplished 549 through application or adaptation of existing or newly 550 developed mechanisms within the telecommunications 551 infrastructure that have broader application within 552 systems. In addition, an assignment of the appropriate 553 code points will be needed to invoke the services when 554 and where required. 556 8. Author's Address 558 Hal Folts 559 National Communications System 560 701 Arlington South Court House Rd. 561 Arlington VA 22204-2198 562 foltsh@ncs.gov 564 Hiroyuki Ohno, PhD 565 Emergency Communications Section 566 Communications Research Laboratory, MTP 567 4-2-1 Nukui-kitamachi, Koganei, Tokyo 184-8795, Japan 568 hohno@ohnolab.org 570 Internet draft IEPS Considerations June 16, 2000 572 9. References 574 ITU-T Recommendation E.106 - Description of an 575 International Emergency Preference Scheme (IEPS) 577 ITU-T Recommendation M.3010 - Principles for a 578 Telecommunications Management Network 580 American National Standard, ANSI T1.631-1993, for 581 Telecommunications - Signalling System No. 7 (SS7) - 582 High Probability of Completion (HPC) Network Capability 584 ETSI TR 101 300 v2.1.1 (1999-10) - Telecommunications 585 and Internet Protocol Harmonization Over Networks 586 (TIPHON); Description of Technical Issues 588 10. Full Copyright Statement 590 Copyright (C) The Internet Society (1999). All rights reserved. 592 This document and translations of it may be copied and furnished 593 to others, and derivative works that comment on or otherwise 594 explain it or assist in its implementation my be prepared, copied, 595 published and distributed, in whole or in part, without 596 restriction of any kind, provided that the above copyright notice 597 and this paragraph are included on all such copies and derivative 598 works. However, this document itself may not be modified in any 599 way, such as by removing the copyright notice or references to the 600 Internet Society or other Internet organizations, except as needed 601 for the purpose of developing Internet Standards process must be 602 followed, or as required to translate it into languages other than 603 English. 605 The limited permissions granted above are perpetual and will not 606 be revoked by the Internet Society or its successors or assigns. 608 This document and the information contained herein is provided as 609 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 610 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 611 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 612 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 613 WARRANTIES OR MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.