idnits 2.17.1 draft-carlberg-trip-attribute-rp-04.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 3978, Section 5.5, updated by RFC 4748 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 112 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 224: '... (LS) MUST include that attribute in...' RFC 2119 keyword, line 228: '...Priority token values MUST NOT be...' RFC 2119 keyword, line 230: '...rity attribute MAY be aggregated...' RFC 2119 keyword, line 235: '... An LS MUST include the ResourcePrio...' RFC 2119 keyword, line 238: '...nother domain, an LS MUST propagate...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 12 has weird spacing: '... author repre...' == Line 13 has weird spacing: '...licable paten...' == Line 14 has weird spacing: '...hich he or s...' == Line 18 has weird spacing: '...), its areas...' == Line 19 has weird spacing: '...ups May also ...' == (107 more instances...) -- 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) -- Looks like a reference, but probably isn't: '4234' on line 194 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 8 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 Nov 8, 2007 Piers O'Hanlon 5 UCL 7 Telephony Routing over IP (TRIP) Attribute for Resource Priority 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 IETF Trust (2007). 37 Abstract 39 This document defines a new attribute for the Telephony Routing over 40 IP (TRIP) protocol. The attribute associates protocols/services in 41 the PSTN offering authorized prioritization during call setup that 42 are reachable through a TRIP gateway. Current examples of 43 preferential service in the PSTN are Government Emergency 44 Telecommunications Service (GETS) in the U.S. and Government 45 Telephone Preference Scheme (GTPS) in the U.K. The proposed 46 attribute for TRIP is based on the NameSpace.Value tupple defined for 47 the SIP resource Priority field. 49 1. Introduction 51 An IP telephony gateway allows nodes on an IP based network to 52 communicate with other entities on the circuit switched telephone 53 network. The Telephony Routing over IP (TRIP) protocol [rfc3219] 54 provides a way for nodes on the IP network to locate a suitable 55 gateway through the use of Location Servers. TRIP is a policy driven 56 inter-administrative domain protocol for advertising the 57 reachability, negotiate capabilities, and specify attributes about 58 these gateways. 60 The TRIP protocol is modeled after BGP-4 [rfc4271] and uses path- 61 vector advertisements distributed in a hop-by-hop manner (resembling 62 a Bellman-Ford routing algorithm) via Location Servers. These 63 Location Servers are grouped in administrative clusters known as an 64 Internet Telephony Administrative Domains (ITAD). A more extensive 65 framework discussion on TRIP can be found in [rfc2871]. 67 This document defines a new attribute to be registered with IANA. 68 The purpose of this new attribute, and the rationale behind its 69 specification, is explained in the following sections. 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [rfc2119]. 75 2. Emergency Telecommunications Service 77 Emergency Telecommunications Service is a broad term that refers to 78 the services provided by systems used to support emergency 79 communications. One example of these systems is the U.S. Government 80 Emergency Telecommunications System (GETS). This system currently 81 operates over the U.S. Public Switched Telephone Network (PSTN) as a 82 pay-per-use system by authorized personnel. It uses the T1.631-1993 83 ANSI standard [ANSI] to signal the presence of the National Security 84 / Emergency Preparedness code point in an ISDN User Part (ISUP) 85 Initial Address Message (IAM) for SS7. A key aspect of GETS is that 86 a signaling standard in the U.S. PSTN is used to convey the 87 activation/request of the GETS service. 89 From a protocol perspective, other examples of priority (and which 90 can be argued as emergency/disaster related) standards are the 91 H.460.4 ITU [itu460] standard on Call Priority designation for H.323 92 calls, and the I.255.3 [itu255] ITU standard on Multi-Level 93 Precedence and Preemption Service. The latter has been integrated 94 into private telephony systems like AUTOVON. In both cases, 95 signaling code-points exist to distinguish telephony calls by 96 authenticated and prioritized end-user from the normal end-user. The 97 form of this distinction varies and is outside the scope of this 98 document. [rfc3689] and [rfc3690] provides additional information on 99 ETS and its requirements. 101 3. SIP Resource-Priority Effort 103 The initial discussions in the IEPREP list, along with the 104 presentation at the Adelaide-IETF [ADEL00], led to strawman 105 requirements to augment SIP to have the ability to prioritize call 106 signaling. This effort was then advanced formally in the SIPPING 107 working group so that SIP would be able to prioritize access to 108 circuit-switched networks, end system, and proxy resources for 109 emergency preparedness communication [rfc3487]. 111 The requirements in [rfc3487] produced the corresponding document 112 [rfc4412] in the SIP working group, which defines a new header for 113 SIP called Resource-Priority. This new header, which is optional, is 114 divided into two parts: a NameSpace and a Value. The NameSpace part 115 uniquely identifies a group of one or more priorities. The Value 116 part identifies one of a set of priorities used for a SIP message. 118 3.1 Benefits 120 There are three basic benefits derived from the addition of the 121 Resource Priority header in SIP. The first is an ability to signal 122 the priority within a SIP message to other entities in an IP network. 123 The caveat is that some entities may not recognize/support the 124 priority or namespace, but at least the ability to signal the 125 priority with respect to resources has been specified in the SIP 126 protocol. 128 The second benefit is that telephony related protocol/codepoints from 129 other standards can have a corresponding mapping to SIP NameSpace & 130 Value tokens its the Resource-Priority header. Hence, the current 131 NS/EP codepoint in ANSI standard T1.631-1993 could have a 132 corresponding NameSpace.Value token set for the IETF standards body. 133 And as a result, this mapping would facilitate the transparent 134 bridging of signals (i.e., code points) between standards defined by 135 various organizations -- be they private or public. 137 The third benefit of the Resource Priority header, and its definition 138 of alphanumeric tokens, is that it is highly versatile. The 139 NameSpace allows for wide set of priorities to be defined, and 140 updated if the need arises by simply defining a new NameSpace token. 141 Hence, there is no reliance on a single set of priorities applied for 142 all cases. 144 3.2 Issue 146 Having defined a means of signaling priority through gateways, the 147 follow on question arises of how does one determine which gateways 148 support a given NameSpace. The dissemination of this type of 149 information is within the scope of TRIP. However, the current 150 specification of TRIP does not include a component that advertises 151 associations of gateways with specific NameSpaces. To address this 152 omission, the following section defines a new TRIP attribute that 153 associates one or more NameSpaces with a gateway. 155 4. New Attribute: ResourcePriority 157 This section provides details on the syntax and semantics of the 158 ResourcePriority TRIP attribute. Its presentation reflects the form 159 of existing attributes presented in Section 5 of [rfc3219]. 161 Attribute Flags, whose field is shown in Figure 3 above, are set to 162 the following: 164 Conditional Mandatory: False 165 Required Flags: Not Well-Known, Independent Transitive 166 Potential Flags: None 167 TRIP Type Code: TBD (proposed to be 12) 169 There are no dependencies on other attributes, thus Conditional 170 Mandatory is set to "False". 172 Since the Resource-Priority field in SIP, with its corresponding 173 NameSpace Token, is optional, the ResourcePriority Attribute in TRIP 174 is also optional. Hence, it is set to "Not Well-Known". 176 The Independent Transitive condition indicates that the attribute is 177 to be forwarded amongst all ITADs. The Location Server that does not 178 recognize the attribute sets the Partial flag as well. 180 4.1 Syntax of ResourcePriority 182 The ResourcePriority attribute contains one or more NameSpace token 183 identifiers. An initial set of identifiers are defined in [rfc4412], 184 with subsequent identifiers to be found in the IANA registry. The 185 syntax of the ResourcePriority attribute is copied from the 186 "namespace" token syntax from [rfc4412], which in turn imported 187 "alphanum" from [rfc3261], and is an alphanumeric value as shown 188 below: 190 namespace = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" 191 / "`" / "'" / "~" ) 193 Note that an augmented version of Backus-Naur From is found in 194 [4234]. 196 Since NameSpaces are arbitrary in length, each tuple consists of a 197 Length value with a NameSpace value as shown in Figure 4 below. 198 There is no padding between tuples. 200 0 1 2 3 201 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 202 +---------------+---------------+--------------+----------------+ 203 | NameSpace Length | NameSpace Value (variable) | 204 +---------------+---------------+--------------+----------------+ 206 It is important to note that the priority (i.e., "r-priority" token 207 syntax) from [rfc4412] is NOT used in the ResourcePriority attribute. 208 This is because the objective of the attribute is to advertise the 209 NameSpace associated with a gateway and not the individual priorities 210 within that NameSpace. 212 4.2 Additional TRIP Considerations 214 Section 5.12 of TRIP lists a number of considerations that should be 215 addressed when defining new attributes. The first three 216 considerations (use of the attribute, its flags, and syntax) have 217 been discussed above in this section. The final three considerations 218 are: 220 4.2.1 Route Origination 222 The ResourcePriority attribute is not well-known. If a route has a 223 ResourcePriority attribute associated with it, the Location Server 224 (LS) MUST include that attribute in the advertisement it originates. 226 4.2.2 Route Aggregation 228 Routes with differing ResourcePriority token values MUST NOT be 229 aggregated. Routes with the same token values in the 230 ResourcePriority attribute MAY be aggregated and the same 231 ResourcePriority attribute attached to the aggregated object. 233 4.2.3 Route Dissemination and Attribute Scope 235 An LS MUST include the ResourcePriority attribute when communicating 236 with peer LSs within its own domain. 238 If received from a peer LS in another domain, an LS MUST propagate 239 the ResourcePriority attribute to other LSs within its domain. 241 An LS MAY add the ResourcePriority attribute when propagating routing 242 objects to an LS in another domain. The inclusion of the 243 ResourcePriority attribute is a matter of local administrative 244 policy. 246 5 Security Considerations 248 The document defines a new attribute for the TRIP protocol and has no 249 direct security considerations applied to it. However, the security 250 considerations for TRIP and its messages remain the same and are 251 articulated in Section 14 of [rfc3219]. 253 6. IANA Considerations 255 As described in Section 4 above, one new "TRIP attribute" has been 256 defined. Its name and code value are the following: 258 Code Attribute Name 259 ---- ---------------- 260 TBD (suggest 12) ResourcePriority 262 These assignments are recorded in the following registry: 263 http://www.iana.org/assignments/trip-parameters 265 7. Acknowledgements 267 The authors appreciate review and subsequent comments from James Polk 268 and Henning Schulzrinne. 270 8. References 272 8.1 Normative References 274 [rfc2871] Rosenberg, J. and H. Schulzrinne, "A Framework for 275 Telephony Routing over IP", RFC 2871, IETF, June 2000. 277 [rfc3219] Rosenberg, J. et. al., "Telephony Routing over IP (TRIP)", 278 RFC 3219, IETF, January 2002. 280 [rfc4412] Schulzrinne, H. and J. Polk, "Communications Resource 281 Priority for the Session Initiation Protocol (SIP)", 282 RFC 4412, IETF, Feb 2006. 284 8.2 Informative References 286 [ADEL00] IETF Proceedings (47'th), SIP Working Group, Adelaide, 287 Australia, June 2000 289 [ANSI] ANSI, "Signaling System No. 7(SS7): High Probability of 290 Completion (HPC) Network Capability", ANSI T1.631, 1993. 292 [itu460] ITU "Call Priority Designation for H.323 Calls", ITU 293 Recommendation H.460.4, November, 2002. 295 [itu255] ITU, "Multi-Level Precedence and Preemption Service, ITU, 296 Recommendation, I.255.3, July, 1990. 298 [rfc2119] Bradner, S., "Key Words for use in RFCs to Indicate 299 Requirement Levels", RFC 2119, IETF, march 1997. 301 [rfc3261] Rosenberg, J., et.. al., "SIP: Session Initiation 302 Protocol", RFC 3261, IETF, June 2002. 304 [rfc3487] Schulzrinne, H., "Requirements for Resource Priority 305 Mechanisms for the Session Initiation Protocol (SIP)", 306 RFC 3487, IETF, February 2003. 308 [rfc3689] Carlberg, K. and R. Atkinson, "General Requirements for 309 Emergency Telecommunications Service (ETS)", RFC 3689, 310 IETF, February 2004. 312 [rfc3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements 313 for Emergency Telecommunications Service (ETS)", 314 RFC 3690, IETF, February 2004. 316 [rfc4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 317 Specifications: ABNF", RFC 4234, IETF, October 2005 319 [rfc4271] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 320 (BGP-4)", RFC 4271, IETF, January 2006. 322 Author's Addresses 324 Ken Carlberg Piers O'Hanlon 325 G11 University College London 326 123a Versailles Circle Gower Street 327 Baltimore, MD London 328 USA UK 330 carlberg@g11.org.uk p.ohanlon@cs.ucl.ac.uk 332 Intellectual Property Statement 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at ietf- 354 ipr@ietf.org. 356 Disclaimer of Validity 358 This document and the information contained herein are provided on an 359 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 360 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 361 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 362 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 363 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 364 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 366 Copyright Statement 368 Copyright (C) The The IETF Trust (2007). This document is subject to 369 the rights, licenses and restrictions contained in BCP 78, and except 370 as set forth therein, the authors retain all their rights. 372 Acknowledgment 374 Funding for the RFC Editor function is currently provided by the 375 Internet Society.