idnits 2.17.1 draft-mcgarry-nnp-use-case-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2016) is 2984 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'I-D.peterson-modern-problems' on line 200 -- Looks like a reference, but probably isn't: 'TBA' on line 354 == Unused Reference: '1' is defined on line 362, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MODERN Working Group J. Brewer 2 Internet-Draft Peerless Network, Inc. 3 Intended Status: Informational T. McGarry 4 Expires: August 27, 2016 Neustar, Inc. 5 C. Wendt 6 Comcast 7 February 24, 2016 9 Nationwide Number Portability: a MODERN Use Case 10 draft-mcgarry-nnp-use-case-00.txt 12 Abstract 14 A proposed solution for geographic number portability in the USA 15 calls for a new non-geographic numbering resource. This draft uses 16 this proposal as a use case for a MODERN solution. While this 17 focuses on an effort occurring in the USA the concepts are 18 applicable to any country. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 27, 2016 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction...................................................2 55 2. Definitions....................................................5 56 3. Use Cases......................................................5 57 3.1 CSP Acquires an NGRN from a Registry.......................6 58 3.2 User Ports a Geographic TN to an NGRN......................6 59 3.3 User Acquires an NGTN from a CSP...........................7 60 3.4 Call to an NGRN Via and NG Transport Provider..............7 61 3.5 Call to an NGTN from a TDM Network.........................8 62 4. Security Considerations........................................8 63 5. IANA Considerations............................................8 64 6. Normative References...........................................8 66 1. Introduction 68 The Federal Communications Commission (FCC) in the USA has asked the 69 North American Numbering Council, an advisory body, to recommend 70 actions to enable nationwide number portability (NNP). NNP is the 71 ability to port a geographic TN to a different geographic area than 72 the one to which it is associated. One solution proposes 73 establishing a new non-geographic numbering space to be used for 74 call routing for NNP TNs. 76 The format of a USA TN is: 78 o NXX-NXX-XXXX, where N=digits 2-9 and X=digits 0-9 80 o The first 3 digits (NXX) is called the area code 82 o The area code is assigned to a geographic area or a specific 83 service 85 o The first 6 digits (NXX-NXX) is called the central office code 86 (CO Code) 88 o The CO code in a geographic area code is assigned to a 89 specific service provider and switch and is used as an 90 address for that switch 92 o In some geographic areas all ten thousand TNs in a CO code 93 (NXX-NXX-0000 to 9999) are assigned to that service provider 94 as inventory 96 o In most geographic areas one thousand TNs identified by the 97 first 7 digits (NXX-NXX-X) are assigned to service providers 98 as inventory 100 o The full 10 digits is called the line number 102 o Line numbers are ultimately assigned to users 104 Area codes can be either geographic or non-geographic. Geographic 105 area codes are assigned to a specific geographic region. For 106 example, the 202 area code is assigned to Washington, DC. TNs 107 within the 202 area code are assigned as inventory to service 108 providers. Service providers use this inventory to assign TNs to 109 users who have a presence on their networks in Washington, DC. CO 110 codes assigned to switches in the 202 area code have a connection to 111 the PSTN in the Washington, DC area. Mobile and landline networks 112 both use CO codes and TN inventory in the same geographic area 113 codes. 115 Non-geographic area codes do not designate a specific geographic 116 region. They are considered nationwide, i.e., TNs within the area 117 code can be assigned to a User anywhere in the country. Today non- 118 geographic area codes are used to designate a specific service. For 119 example, the 800 area code is used to designate toll free service. 121 Networks use the CO codes of geographic TNs to route calls. For TNs 122 that have been ported the TN is assigned a routing number (RN). (In 123 the USA, the term local routing number (LRN) is used. The term RN 124 is used in this document.) The assignment of the RN to the TN is 125 done in an industry database called the number portability 126 administration center (NPAC). Networks use the CO code of the RN to 127 route calls to a ported TN. Today all calls to geographic TNs are 128 routed based on a CO code. 130 Portability is limited to the geographic area associated with the 131 TN. One of the ways this is achieved is by implementing an edit in 132 the NPAC that ensures the RN and the TN are in the same geographic 133 area. The request by the FCC is asking the industry to remove this 134 limitation. 136 One way to enable NNP is to remove the NPAC edit and allow the TN 137 and RN to be in different geographic areas. However, there are many 138 technical and operational aspects of the communications networks 139 that rely on the TN and RN being in the same geography. These would 140 have to be investigated, tested, and resolved. It's been reported 141 that a call of this type in certain older technology switches will 142 fail. If so, then new software would have to be developed for these 143 switches to implement this solution. 145 An alternative solution has been proposed that would use a new non- 146 geographic area code for RNs. These are called non-geographic 147 routing numbers (NGRN). They would be hosted on an all-IP network 148 of switches called non-geographic gateways (NGGW), rather than the 149 existing TDM tandems operated by the incumbent local exchange 150 carriers (ILECs). The non-geographic area code would indicate to 151 older technology infrastructure the need to send the call to an IP 152 network for call processing. Once on the IP network the NGGW is 153 identified and the call is routed. 155 A call to an NGRN can involve four entities: 157 o Originating CSP - the CSP that has performed the number 158 portability dip and is routing to the NGRN 160 o NG Transport Provider - the network that can route the call to 161 the correct NGGW 163 o NGGW - the switch that hosts the NGRN 165 o Terminating CSP - the CSP that is connected to the NGGW and is 166 assigned the NGRN or NGTN and completes the call to the User 168 Some of these entities can be collapsed, for example NGGW and 169 terminating CSP or originating CSP and NG transport provider. There 170 can also be additional entities involved in transporting the call. 171 It's also been proposed that TNs within the non-geographic area code 172 can be used for assignment to Users for traditional voice and text 173 service. These are called non-geographic TNs (NGTNs). Today 174 consumer voice and text service is limited to TNs from geographic 175 area codes. 177 This document is a MODERN use case for a new non-geographic 178 numbering space proposed to enable GNP in the USA. It uses the 179 following assumptions: 181 o Numbering space to be managed is a non-geographic area code in 182 the format of NXX-NXX-XXXX 184 o Both NGRNs and NGTNs are assigned from this space 185 o NGRNs are assigned on a 10-digit basis - not a 6-digit basis, as 186 they are for geographic RNs 188 o The service provider and the NGGW associated with an NGRN can 189 change 191 o NGTNs are assigned on a 10-digit basis to CSPs - not in blocks, 192 as they are for geographic TNs 194 o NGTNs have an associated NGRN, i.e., calls to NGTNs are routed 195 based on the NGRN 197 o The service provider, NGRN, and NGGW associated with an NGTN can 198 change 200 This document uses definitions from [I-D.peterson-modern-problems]. 201 It also assumes that either a single authoritative registry or a 202 distributed registry can perform the Registry functions. Here the 203 term Registry is used to cover both types of solutions. 204 2. Definitions 206 These mostly address terms associated with numbering in the USA or 207 new terms created for this document. 209 o Nationwide number portability (NNP) - the ability to port a 210 geographic TN to a different geographic area than the one to 211 which it is associated 213 o Area code - the first 3 digits of a TN that is assigned to a 214 geographic area or a service 216 o Central office code (CO code) - the first 6 digits of a TN that 217 is assigned to a specific service provider and switch 219 o Routing number (RN) - a geographic TN that is associated with a 220 ported TN for the purposes of call routing 222 o Non-geographic routing number (NGRN) - a TN from a non-geographic 223 area code that is used to route calls to NNP TNs 225 o Non-geographic gateway (NGGW) - an IP switch that hosts NGRNs 227 o Number portability administration center (NPAC) - an industry 228 database that manages number portability information 230 3. Use Cases 232 The use cases cover processes for actors acquiring, managing, and 233 retrieving data related to NGRNs and NGTNs. 235 3.1. CSP Acquires an NGRN from a Registry 237 A CSP is preparing to offer NNP service to its Users. The first 238 step would be to register as a CSP with the Registry by providing 239 profile information. The CSP profile should be data that will be 240 referenced whenever the CSP attempts a transaction with the 241 Registry. This could include administrative data such as CSP 242 contact information. There could be multiple contacts in the CSP 243 such as, administrative, billing, and technical. It could include 244 administrative data about the CSP's NGGW provider(s). It could also 245 include service data such as addressing data for the NGGW(s). 247 During the registration process the Registry should certify that the 248 CSP is qualified to request an NGRN. This could be a credential or 249 some other authorization provided by the Numbering Authority. It 250 could also include verification that the CSP has the ability to 251 offer service to the NGRN, such as an agreement with an NGGW 252 provider. Upon assignment the CSP assigns it to an NGGW provider 253 and NGGW addressing information and shares this with the Registry. 254 The CSP and the NGGW provider can be the same company. 256 The Registry would make the assignment data available to others 257 based on local policies. It can do this by providing an API or by 258 distributing the data. Administrative data is more likely provided 259 by API, reference addresses and service data could be provided by 260 distribution. 262 There should be policies as to which and how many NGRNs the CSP can 263 request. It could request a specific NGRN, or perhaps the Registry 264 would assign one randomly or in sequence. Given that there should 265 be a relatively small number of NGGWs there should be some 266 limitation on how many NGRNs a CSP can request, perhaps some number 267 per NGGW. 269 When the Registry assigns the NGRN they would issue a credential to 270 the CSP. The credential can be used in future transactions. 272 3.2. User Ports a Geographic TN to an NGRN 274 There are seven regional NPACs that manage the process of porting 275 geographic TNs. These are divided geographically by area code. 276 Each area code is dedicated to a specific NPAC and no area code is 277 shared across two NPACs. For example, A CSP would port a 212 TN 278 from New York in the Northeast regional NPAC. Geographic RNs are 279 also specific to a region. Some CSPs only connect to some regions, 280 i.e., a CSP may only connect to one region. If so, they can only 281 port TNs and get porting information in the region(s) to which they 282 connect. Those CSPs have arrangements with other CSPs to handle 283 portability call processing for TNs in other regions. This is 284 likely a transport provider that has connectivity to all NPACs. 286 NGRNs would have to be able to be in any and multiple regions. This 287 is possible with current NPAC processes. The most efficient way to 288 port numbers in this environment is to maintain the ported TN-to- 289 region association. For example, if a CSP is porting a 212 TN to an 290 NGRN, they would port it in the Northeast region. 292 When a CSP is porting a TN to an NGRN the CSP will first register 293 the NGRN in the region associated with the porting TN. Then they 294 will port the TN as they would today, except it is to an NGRN, not a 295 geographic RN. The NPAC downloads the ported TN-to-NGRN data to all 296 interconnected service providers. 298 3.3. User Acquires an NGTN from a CSP 300 A User requests service from a CSP, the CSP submits its credential 301 to the Registry and requests an NGTN. It provides the Registry with 302 NGGW information, administrative and service, related to the NGTN. 303 The Registry verifies the CSP and assigns an NGTN along with a 304 credential for that NGTN. The CSP could provide the User with the 305 credential for them to use in future transactions. 307 The User provides contact information to the CSP. The CSP can 308 either store the contact information and provide a reference address 309 to the Registry, or it could send the contact data to the Registry 310 for storage. 312 The CSP establishes service to the User and NGTN. 314 3.4. Call to an NGRN Via an NG Transport Provider 316 The originating CSP provisions the non-geographic area code as a 317 valid area code on its network. When a call originates to an NNP 318 TN, the CSP will perform an NP dip and will receive an NGRN. It 319 routes the call based on the area code of the NGRN to an NG 320 Transport Provider that it has an agreement with. The NG Transport 321 Provider routes the call to the NGGW based on routing information 322 related to the NGRN. 324 The routing information could simply be the NGRN itself. Most CSPs 325 use traditional PSTN routing and interconnection techniques when 326 routing IP traffic. They create SIP trunk groups (SIP TGs) between 327 their session border controllers (SBCs). They choose a SIP TG based 328 on the CO code. Because the number of NGGWs and NGRNs will be 329 relatively small, it would be possible to create routing tables 330 based on 10 digit NGRNs. Also there will be no need to route calls 331 based on the first 6 digits of an NGRN, therefore there will be no 332 conflict with the 10 digit tables. 334 Alternatively there could be some other routing information 335 associated with the NGRN, such as a unique service provider 336 identifier or a URI. This could be used to consolidate multiple 337 NGRNs into a smaller number of identifiers. But this would likely 338 require changes to the SIP protocol to add the new identifier to NP 339 call processing. 341 3.5. Call to an NGTN from a TDM Network 343 The CSP provisions the NG area code as a valid area code in its 344 network. When a call originates to an NGTN it can either do the NP 345 query and hand the call off to an NG Transport Provider (as 346 described above), or it can send the call to the NG Transport 347 Provider and let it perform the NP dip. 349 Once on the NG Transport Provider's network it will route to the 350 correct NGGW, as described above. 352 4. Security Considerations 354 [TBA] 356 5. IANA Considerations 358 This memo includes no request to IANA. 360 6. Normative References 362 [1] Peterson, J. and McGarry, T. (Editors), "draft-peterson- 363 modern-problems-02.txt", October 19, 2105 364 Authors' Addresses 366 Tom McGarry 367 Neustar, Inc. 368 46000 Center Oak Plaza 369 Sterling, VA 20164 370 USA 372 Email: tom.mcgarry@neustar.biz 374 Jim Brewer 375 Peerless Network, Inc. 376 222 S. Riverside Plaza, Suite 2730 377 Chicago, IL 60606 378 USA 380 Email: jbrewer@peerlessnetwork.com 382 Chris Wendt 383 Comcast 384 One Comcast Center 385 Philadelphia, PA 19103 386 USA 388 Email: chris-ietf@chriswendt.net