idnits 2.17.1 draft-ietf-ieprep-reference-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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 (July 2002) is 7956 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) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'Dierks99') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. 'Schulzrinne96') (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2411 (ref. 'Thayer98') (Obsoleted by RFC 6071) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force I. Brown 2 INTERNET-DRAFT University College London 3 Expiration Date: 31 January 2003 July 2002 5 Terms of Reference for an Emergency Telecommunications Service 6 8 Status of This Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright 32 Copyright (C) Internet Society 2002. All rights reserved. 33 Reproduction or translation of the complete document, but not of 34 extracts, including this notice, is freely permitted. 36 Abstract 38 An Emergency Telecommunications Service gives authorised emergency 39 personnel a higher probability of successful communication under 40 high network load conditions. This document explains the different 41 terms and acronyms used in defining and implementing this service, 42 and is intended to be used as a common basis for negotiations when 43 emergency service providers are contracting with telecommunications 44 operators to provide the service. It can also be used in procurement 45 of and tendering for ETS provision. 47 1. Definitions 49 Assured Forwarding (AF) 51 A set of DiffServ Per-Hop Behaviours that group packets into one of 52 four independent classes, each of which has three levels of drop 53 precedence [Heinanen99]. 55 Diameter 57 A protocol that provides authentication, authorisation and 58 accounting services between home and remote networks and their 59 users [Calhoun02]. 61 Differentiated Services Code Point (DSCP) 63 The value used in the DiffServ field of a packet header that selects 64 a specific Per-Hop Behaviour [Grossman02]. 66 Differentiated Services (DiffServ) 68 A mechanism for classifying traffic flows into aggregates and 69 providing specific forwarding treatment within a network. Flows 70 are classified and policed at the edge of a network and forwarded 71 according to the service provider's policies 72 [Blake98]. 74 Expedited Forwarding (EF) 76 A DiffServ Per-Hop Behaviour that provides a flow with low loss, 77 jitter and delay. This is achieved by ensuring that the output rate 78 of an EF queue in a router is higher than the arrival rate of EF- 79 marked packets over short and long time intervals [Davie02]. 81 Government Emergency Telecommunications Service (GETS) 83 A scheme operated under contract by US telecommunications providers 84 that provides a High Probability of Completion for calls made by 85 authorised emergency personnel in the Public Switched Telephone 86 Network [Folts02]. 88 Global System for Mobile communications (GSM) 90 The family of European Telecommunications Standards Institute 91 standards for first generation digital mobile telecommunications, 92 used in many countries around the world for public land mobile 93 networks. Contains an extended version of MLPP to allow precedence 94 and preemption for calls from authorised users. 96 High Probability of Completion (HPC) 97 Emergency prioritised calls in the Public Switched Telephone Network 98 are given a higher chance of successful setup by the network. These 99 calls can be queued, exempted from restrictive management controls 100 and routed via alternate carriers when they encounter congestion 101 [ANSI93]. 103 International Emergency Multimedia Service (IEMS) 105 A counterpart to the International Emergency Preference Scheme that 106 provides enhanced treatment for a wide range of multimedia services 107 [ITU02]. 109 International Emergency Preference Scheme (IEPS) 111 An International Telecommunications Union standard that provides a 112 High Probability of Completion for calls made by authorised emergency 113 personnel in the international Public Switched Telephone Network 114 [ITU00]. 116 Integrated Services (IntServ) 118 An extension to the Internet architecture to support real-time 119 services for communications sessions [Braden94]. Bandwidth can be 120 reserved using the Resource ReSerVation Protocol [Braden97]. IntServ 121 is usually only supported within specific domains. 123 Internet Protocol Security (IPSec) 125 A set of extensions to the standard Internet Protocol that allows 126 packets or the data they contain to be encrypted and signed, 127 ensuring their confidentiality and integrity [Thayer98]. 129 ISDN User Part (ISUP) 131 A set of protocols used in SS7 networks to support ISDN services 132 such as controlling telephone calls, and network maintenance such 133 as blocking or resetting circuits [ITU99]. The ISUP Initial Address 134 Message is used to carry the National Security/Emergency 135 Preparedness codepoint which marks a GETS call as prioritised. 137 Multimedia Internet Keying (MIKEY) 139 A key agreement protocol designed to meet the low latency 140 requirements of real-time media streams and to work with signalling 141 protocols such as SIP [Arkko02]. 143 Multi-Level Precedence and Preemption (MLPP) 145 A system that allows higher-priority telephony calls to receive 146 resources ahead of (and if necessary to tear down) lower priority 147 calls [ITU90]. 149 National Security/Emergency Preparedness (NS/EP) 151 A codepoint set for GETS calls in the Calling Party Category of the 152 SS7 ISUP Initial Address Message, indicating that the setup should 153 have a High Probability of Completion. 155 Per-Hop Behaviour (PHB) 157 The forwarding behaviour applied by a DiffServ node to flows marked 158 with a specific DSCP. 160 Real-time Transport Protocol 162 A network-independent end-to-end transport protocol for real-time 163 data such as audio,video and simulation results [Schulzrinne96]. 165 Secure Real-time Transport Protocol 167 A Real-time Transport Protocol profile that provides 168 confidentiality, authentication and replay protection for RTP and 169 associated control traffic [Baugher02]. 171 Session Initiation Protocol (SIP) 173 A signalling protocol used to set up, manage and tear down 174 communications sessions between one or more participants. Telephone 175 calls, video conferences and multimedia distribution are all 176 supported [Rosenberg02]. 178 Signalling System No. 7 (SS7) 180 The procedures and protocols by which network elements in the Public 181 Switched Telephone Network exchange information over a digital 182 signalling network for call setup, routing and control [ITU93]. 184 Telephony Routing over IP (TRIP) 186 A protocol that allows IP telephony gateways to advertise and 187 exchange routes to specific numbers in the Public Switched 188 Telephone Network [Rosenberg00]. 190 Traffic Class 192 DiffServ packets are marked as part of a specific traffic 193 aggregate using a DiffServ Code Point. This DSCP goes in 194 the traffic class field of the packet header [Grossman02]. 196 Transport Layer Security (TLS) 198 A set of cryptographic protocols that allow processes running on two 199 separate hosts to communicate across an insecure network such as the 200 Internet with protection against eavesdropping and modification of 201 data [Dierks99]. 203 2. Security Considerations 205 The security aspects of an Emergency Telecommunications Service are 206 described in [Brown02]. 208 3. Acknowledgements 210 Thanks to Alistair Munro for comments on this document. 212 4. Author's Address 214 Ian Brown 215 Department of Computer Science 216 University College London 217 Gower Street 218 London WC1E 6BT 219 United Kingdom 221 Phone: +44 20 7679 3704 222 Fax: +44 20 7387 1397 223 E-mail: I.Brown@cs.ucl.ac.uk 225 5. Informative References 227 [ANSI93] ANSI Recommendation T1.631, "Signaling System No. 7 (SS7) - 228 High Probability of Completion (HPC) Network Capability", 1993. 230 [Arkko02] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and 231 K. Norrman, "MIKEY: Multimedia Internet KEYing", Internet draft, 232 July 2002. 234 [Blake98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 235 and W. Weiss, "An Architecture for Differentiated Services", RFC 236 2475, December 1998. 238 [Baugher02] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, 239 M., Norrman, K., and D. Oran, "The Secure Real-time Transport 240 Protocol", IETF work-in-progress, June 2002. 242 [Braden94] Braden, B., Clark, D. and S. Shenker, "Integrated 243 Services in the Internet Architecture: an Overview", RFC 1633, June 244 1994. 246 [Braden97] Braden, B. (Ed.), "Resource ReSerVation Protocol (RSVP) 247 -- Version 1 Functional Specification", RFC 2205, September 1997. 249 [Brown02] Brown, I., "A Security Framework for Emergency 250 Communications", IETF work-in-progress, June 2002. 252 [Calhoun02] Calhoun, P., Arkko, J., Guttman, E., Zorn, G. and J. 254 Loughney, "Diameter Base Protocol", IETF work-in-progress, April 255 2002. 257 [Davie02] Davie, B. et al., "An Expedited Forwarding PHB (Per-Hop 258 Behavior)", RFC 3246, March 2002. 260 [Dierks99] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 261 RFC 2246, January 1999. 263 [Folts02] Folts, H. and C. Beard, "Requirements for Emergency 264 Telecommunication Capabilities in the Internet", Internet draft, 265 June 2002. 267 [Grossman02] D. Grossman, "New Terminology and Clarifications for 268 Diffserv", RFC 3260, April 2002. 270 [Heinanen99] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, 271 "Assured Forwarding PHB Group", RFC 2597, June 1999. 273 [ITU90] ITU-T Recommendation I.255.3, "Multilevel precedence and 274 preemption service (MLPP)", July 1990. 276 [ITU93] ITU-T Recommendation Q.700, "Introduction to CCITT Signalling 277 System No. 7", March 1993. 279 [ITU99] ITU-T Recommendation ITU-T Q.764, "Signaling System 280 No. 7; ISDN User Part Signaling procedures", December 1999. 282 [ITU00] ITU-T Recommendation E.106, "Description of an International 283 Emergency Preference Scheme (IEPS)", March 2000. 285 [ITU02] ITU-T Draft Recommendation F.706, "International Emergency 286 Multimedia Service", 2002. 288 [Rosenberg00] Rosenberg, J. and H. Schulzrinne, "A Framework for 289 Telephony Routing over IP", RFC 2871, June 2000. 291 [Rosenberg02] Rosenberg, J. et al, "SIP: Session Initiation Protocol", 292 RFC 3261, June 2002. 294 [Schulzrinne96] Schulzrinne, H., Casner, S., Frederick, R. and V. 295 Jacobson, "RTP: A Transport Protocol for Real-time Applications", RFC 296 1889, January 1996. 298 [Thayer98] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security 299 Document Roadmap", RFC 2411, November 1998. 301 6. Full Copyright Statement 303 Copyright (C) The Internet Society (2002). All Rights Reserved. 305 This document and translations of it may be copied and furnished to 306 others, and derivative works that comment on or otherwise explain 307 it or assist in its implementation may be prepared, copied, 308 published and distributed, in whole or in part, without restriction 309 of any kind, provided that the above copyright notice and this 310 paragraph are included on all such copies and derivative works. 311 However, this document itself may not be modified in any way, such 312 as by removing the copyright notice or references to the Internet 313 Society or other Internet organizations, except as needed for the 314 purpose of developing Internet standards in which case the 315 procedures for copyrights defined in the Internet Standards process 316 must be followed, or as required to translate it into languages 317 other than English. 319 The limited permissions granted above are perpetual and will not be 320 revoked by the Internet Society or its successors or assigns. 322 This document and the information contained herein is provided on 323 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 324 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 325 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 326 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 327 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.