idnits 2.17.1 draft-malas-enum-trunk-sip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4904], [RFC3261], [RFC3403]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5293 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Malas 3 Internet-Draft CableLabs 4 Intended status: Informational T. Creighton 5 Expires: April 29, 2010 Comcast 6 October 26, 2009 8 Trunk Group Use in ENUM 9 draft-malas-enum-trunk-sip-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 29, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes a method for incorporating trunk group 48 parameters into an E.164 Number Mapping (ENUM) response for the 49 Session Initiation Protocol (SIP) [RFC3261] service URI. It defines 50 the use of trunk group contexts as defined in [RFC4904] as additional 51 parameters in the E2U+SIP enumservice NAPTR record [RFC3403] URI. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Trunk use in the 'E2U+SIP' enumservice URI . . . . . . . . 4 58 1.3. Why Not Create a new ENUM Service Type? . . . . . . . . . . 6 59 1.4. ENUM Client, Proxy, and User Agent Considerations . . . . . 7 60 1.5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 61 1.6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 62 1.7. Security Considerations . . . . . . . . . . . . . . . . . . 8 63 2. Normative References . . . . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms 69 E.164 numbers into SIP URIs and then uses DNS [RFC1034] features such 70 as delegation through NS records, or the use of Naming Authority 71 Pointer (NAPTR) records, to provide the communication services 72 available for a specific domain name. This draft refers to the 73 resulting SIP enumservice NAPTR record type received by an ENUM 74 client request. Simplified methods for provisioning call routing 75 data in ENUM servers have developed a desire among SIP Service 76 Providers (SSPs) to manage all call routing data in an ENUM database 77 versus managing some call routing in both ENUM and DNS. 79 The use of trunk groups is well described in [RFC4904] for IP to PSTN 80 gateway scenarios. In addition to this trunk group usage, more and 81 more SIP service providers (SSPs) are defining trunk groups as SIP IP 82 network end-points. This can be thought of as a SIP trunk group. 83 While there have been other attempts to define a SIP trunk group, in 84 this draft, they are simply referred to as an IPv4/v6 address or a 85 fully qualified domain name (FQDN) representing the target SIP UA or 86 proxy. In addition, SIP trunk groups are becoming popular for 87 defining an associated egress Signaling Path Border Element (SBE) for 88 preferred routing to a peer's ingress SBE. 90 +=====================++ ++====================+ 91 || || 92 SSP1 Network +--------+ || SSP2 Network 93 ssp1.example.com | | || ssp2.example.com 94 +--->| SBE1 |---+ || 95 | | | | || 96 | +--------+ | || 97 | || | || 98 | || | || 99 +-------+ | || | +--------+ +-------+ 100 | |---+ || +---->| |---->| | 101 | Proxy | || | SBE3 | | Proxy | 102 | |---+ || +---->| |---->| | 103 +-------+ | || | +--------+ +-------+ 104 | || | || 105 | || | || 106 | +--------+ | || 107 | | | | || 108 +--->| SBE2 |---+ || 109 | | || 110 +--------+ || 111 || || 112 +=====================++ ++====================+ 113 The above figure illustrates the problem. SSP1 has two options to 114 send a request to SSP2. For reasons outside the scope of this draft, 115 SSP1 would prefer to use SBE2 to send a request to SSP2. Based on 116 the information from SSP2, an example ENUM response for SSP1 would 117 look something like the following: 119 $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. 120 NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1@sbe3.ssp2.example.com!" . 122 While SSP1 can use a subsequent private DNS look-up on 123 sbe3.ssp2.example.com to discover and manipulate a preferred call 124 routing path to SBE3, it prefers to use defined trunk group 125 parameters to specify SBE2 as the egress point to reach SBE3. Trunk 126 group use is especially applicable if SSP2 uses an IPv4/v6 address to 127 specify SBE3 with no additional DNS look-ups to discover the 128 preferred path via SBE2. This draft defines a method for SSP1 to 129 determine the preferred call routing path to reach SBE3 through the 130 results of an ENUM query. 132 1.1. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 Additional terms used in this document for describing aspects of the 139 problem and solution are defined in RFC 5486 [RFC5486]. 141 1.2. Trunk use in the 'E2U+SIP' enumservice URI 143 The following example shows how the'trunk group' parameters are 144 returned in the existing 'SIP' ENUM service type. 146 NOTE: The NAPTR records shown in this section are intended for 147 illustration purposes only, and are not intended as good examples of 148 how to do ENUM provisioning. 150 Example: 152 $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. 153 NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1;tgrp=TG-1; 154 trunk-context=+44-207@sbe1.example.com;user=phone!" . 155 NAPTR 10 101 "u" "E2U+sip" "!^.*$!sip:\1;tgrp=TG-2; 156 trunk-context=+44-207@sbe2.example.com;user=phone!" . 158 In this example, the additional 'trunk' parameters defined in 159 [RFC4904] are included in the SIP URI NAPTR response. Since, the 160 result of the query provides a URI response for the Service field 161 'E2U+sip', the client now has all of the information available to it 162 to route the call. The following figure and subsequent explanation 163 illustrates this in more detail: 165 +=====================++ ++====================+ 166 || || 167 SSP1 Network +--------+ || SSP2 Network 168 ssp1.example.com | | || ssp2.example.com 169 +--->| SBE1 |---+ || 170 | | | | || 171 | +--------+ | || 172 | || | || 173 | || | || 174 +-------+ | || | +--------+ +-------+ 175 | |---+ || +---->| |---->| | 176 | Proxy | || | SBE3 | | Proxy | 177 | |---+ || +---->| |---->| | 178 +-------+ | || | +--------+ +-------+ 179 | || | || 180 | || | || 181 | +--------+ | || 182 | | | | || 183 +--->| SBE2 |---+ || 184 | | || 185 +--------+ || 186 || || 187 +=====================++ ++====================+ 189 In the above figure, SSP2 notifies SSP1 to reach +442079460148, send 190 your SIP request to sbe3.ssp2.example.com. SSP1 decides it prefers 191 to send all requests to sbe3.ssp2.example.com via SBE2. In order to 192 do this, it assigns a trunk group to SBE2. The trunk group, for 193 example purposes, is SBE3-SSP2. The Trunk Context is 194 sbe2.ssp1.example.com. In order for the request to be routed 195 correctly from SBE2 to SSP2, there is a logical association on SBE2 196 to interpret sbe3-ssp2 to sbe3.ssp2.example.com. The trunk group and 197 context are provisioned into the ENUM server, so when the Proxy (in 198 this example, also the ENUM client) queries for +442079460148 it 199 receives the following response: 201 $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. 202 NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1;tgrp=SBE3-SSP2; 203 trunk-context=sbe2.ssp1.example.com 204 @sbe3.ssp2.example.com;user=phone!" . 206 If SSP1 desires SBE1 to be a fail-over solution to SBE2, then this 207 would be an example response: 209 $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. 210 NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1;tgrp=TG1-SBE3-SSP2; 211 trunk-context=sbe2.ssp1.example.com 212 @sbe3.ssp2.example.com;user=phone!" . 213 NAPTR 10 101 "u" "E2U+sip" "!^.*$!sip:\1;tgrp=TG2-SBE3-SSP2; 214 trunk-context=sbe1.ssp1.example.com 215 @sbe3.ssp2.example.com;user=phone!" . 217 In the above fail-over solution a logical association to 218 sbe3.ssp2.example.com would be required on both SBE1 and SBE2. 220 1.3. Why Not Create a new ENUM Service Type? 222 One method for identifying a trunk group in ENUM could be to define a 223 new service type "trunk". This new service type would return a tel 224 URI containing the "tgrp" and "trunk context" parameters that can 225 then be carried in IP signaling to control trunk group selection in 226 downstream gateways. While this new ENUM service type may work in 227 production environments, it places an unnecessary burden on ENUM 228 clients to either assume a trunk group exists by always initiating a 229 second ENUM query for the "trunk" service type, or evaluating the 230 entire list of NAPTRs in the response for additional service types, 231 potentially beyond what it originally queried for. 233 An evaluation of [RFC3402], [RFC3403], and [RFC5483] reveals there is 234 no clear definition that says an ENUM client MUST only determine the 235 use of one returned NAPTR and ignore any other NAPTRs returned by the 236 server. While this may be true, it can also be argued that an ENUM 237 client will only choose one NAPTR (and ignore the rest) after 238 evaluating the Services field value, along with the ORDER and 239 PREFERENCE/PRIORITY values, and assuming the NAPTR identifies an 240 acceptable URI that is not rejected by the client due to some other 241 circumstance. Assuming the ENUM client accepts a NAPTR based on this 242 criteria, it is possible a client may never evaluate additional 243 service field values. 245 This is illustrated in the following example of a client querying the 246 server for a SIP URI available for the telephone number 247 +442079460148. The example illustrates a potential additional 248 service type mechanism, where the trunk group parameters are returned 249 in a new ENUM 'trunk' service type. 251 NOTE: The NAPTR records shown in this section are intended for 252 illustration purposes only, and are not intended as good examples of 253 how to do ENUM provisioning. 255 The following example illustrates a potential scenario indicating how 256 an ENUM client MAY not ever evaluate a NAPTR with the 'trunk' service 257 type. 259 $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. 260 NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1@sbe3.ssp2.example.com!" . 261 NAPTR 10 101 "u" "E2U+sip" "!^.*$!sip:\1@sbe3.ssp2.example.com!" . 262 NAPTR 11 100 "u" "E2U+trunk" "!^.*$!trunk:sip\1;tgrp=SSP2-SBE3; 263 trunk-context=sbe2.ssp1.example.com 264 @sbe3.ssp2.example.com;user=phone!" . 266 In this example, the ENUM client will likely select the first NAPTR, 267 because of a match on the queried Services field value, and the ORDER 268 and PREFERENCE/PRIORITY value. It will never evaluate the 'trunk' 269 NAPTR unless the previous two fail for some other circumstance. Even 270 if the client does not specify a service in the original query, the 271 ENUM client will likely choose one of the first two NAPTRs due to the 272 inherent choice based on the clients understanding of the preferred 273 service. In order for the client to choose the 'trunk' NAPTR, it 274 would need to either evaluate two NAPTRs in the response based on a 275 client configuration to look for both, or it would have to place a 276 query specifically for the 'trunk' service regardless of knowing 277 whether trunk parameters exist or not. This is due to the fact the 278 client will always have to assume trunk parameters exist as to avoid 279 routing failures due to not having the complete information 280 associated with the destination SIP URI. 282 It is recognized that one potential option is to change the order of 283 the service types to process the 'trunk' service type first. While 284 more and more SIP user agents are supporting ENUM clients, they are 285 only supporting a subset of ENUM service types (primarily SIP). 286 Adding a new service requires two changes to the SIP ENUM client 288 o it needs to support the new URI type (in this case 'trunk:'), and 290 o a new ENUM service type and processing logic. 292 Eliminating the new service type in favor of embedding the parameters 293 in the SIP URIs now only requires the SIP ENUM client to support the 294 URI extensions with no impact to how it processes NAPTR records or 295 how it queries the ENUM server. 297 1.4. ENUM Client, Proxy, and User Agent Considerations 299 It should not be assumed the originating proxy or user agent (UA), 300 acting as the ENUM client, will perform an action based on the 301 received trunk group information. With this in mind, it is 302 recommended that if the proxy or UA does not know how to interpret or 303 act on the trunk group parameters it should simply forward the URI as 304 received from the ENUM server to the next downstream SIP signaling 305 element. 307 1.5. Acknowledgments 309 The authors of this draft would like to recognize Kevin Johns, David 310 Hancock, and Jean-Francois Mule for their comments. 312 1.6. IANA Considerations 314 This memo includes no request to IANA. 316 1.7. Security Considerations 318 This draft contains no additional security considerations other than 319 those already defined within [RFC3764], [RFC4904], and [RFC3761]. 321 2. Normative References 323 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 324 STD 13, RFC 1034, November 1987. 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 330 A., Peterson, J., Sparks, R., Handley, M., and E. 331 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 332 June 2002. 334 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 335 Part Two: The Algorithm", RFC 3402, October 2002. 337 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 338 Part Three: The Domain Name System (DNS) Database", 339 RFC 3403, October 2002. 341 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 342 Resource Identifiers (URI) Dynamic Delegation Discovery 343 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 345 [RFC3764] Peterson, J., "enumservice registration for Session 346 Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, 347 April 2004. 349 [RFC4904] Gurbani, V. and C. Jennings, "Representing Trunk Groups in 350 tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, 351 June 2007. 353 [RFC5483] Conroy, L. and K. Fujiwara, "ENUM Implementation Issues 354 and Experiences", RFC 5483, March 2009. 356 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 357 Interconnect (SPEERMINT) Terminology", RFC 5486, 358 March 2009. 360 Authors' Addresses 362 Daryl Malas 363 CableLabs 364 858 Coal Creek Circle 365 Louisville, CO 80027 366 US 368 Phone: +1 303 661 3302 369 Email: d.malas@cablelabs.com 371 Tom Creighton 372 Comcast 373 One Comcast Center 374 Philadelphia, PA 19103 375 US 377 Phone: +1 215 286 8617 378 Email: tom_creighton@cable.comcast.com