idnits 2.17.1 draft-peterson-iptel-gwreg-arch-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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 are 6 instances of too long lines in the document, the longest one being 7 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 (February 22, 2002) is 8092 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) -- Looks like a reference, but probably isn't: 'TG1' on line 332 == Unused Reference: '2' is defined on line 723, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Downref: Normative reference to an Informational RFC: RFC 2805 (ref. '2') ** Obsolete normative reference: RFC 3015 (ref. '3') (Obsoleted by RFC 3525) -- Duplicate reference: RFC2805, mentioned in '4', was also mentioned in '2'. ** Downref: Normative reference to an Informational RFC: RFC 2805 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft NeuStar 4 Expires: August 23, 2002 February 22, 2002 6 An Architecture for Gateway Registration based on Trunk Groups 7 draft-peterson-iptel-gwreg-arch-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in 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 This Internet-Draft will expire on August 23, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document presents a framework in which gateways (points of 39 interconnection between the Public Switched Telephone Network and 40 Internet-based telephone systems) register themselves with a location 41 service in order to communicate their own availability and the 42 availability of the resources and services they provide. Unlike 43 previous approaches to this problem, this document considers trunk 44 groups as a resource which gateways register. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Defining Trunk Groups . . . . . . . . . . . . . . . . . . . . 6 50 3. Gateway Deployment Architecture . . . . . . . . . . . . . . . 7 51 4. Trunk Group Attributes . . . . . . . . . . . . . . . . . . . . 11 52 5. Reachability and Preference . . . . . . . . . . . . . . . . . 14 53 6. Building a Route List . . . . . . . . . . . . . . . . . . . . 17 54 7. An example of Gateway Registration . . . . . . . . . . . . . . 19 55 8. Gateway Registration & Route Selection in TRIP . . . . . . . . 20 56 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 58 References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 59 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 60 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24 62 1. Introduction 64 Gateway registration is a process by which a gateway can in real-time 65 inform a server of its availability and the state of any resources it 66 controls. This information is then used by a server to make optimal 67 routing decisions in a network. The scope of this document is 68 restricted to gateways that interwork between the Public Switched 69 Telephone Network (PSTN) and Internet-based telephone services that 70 use protocols such as SIP [1] - in other words, gateways that handle 71 IP telephone calls. 73 This document describes a particular scenario for gateway 74 registration, namely, a case in which it could be used by a sizeable 75 Voice over IP (VoIP) carrier. It outlines an architecture, a 76 framework for gateway registration, and some conclusions on protocol 77 selection that reflect the preceding considerations. In particular, 78 this document focuses on the expression of the state and capabilities 79 of trunk groups associated with gateways. It is the contention of 80 this document that focusing on trunk groups provides us with new 81 leverage to attack the whole gateway registration problem. 83 The sort of VoIP carrier network discussed in this draft is comprised 84 of entities responsible for routing call setup requests (like SIP 85 proxy servers) and entities that generate and receive call setup 86 requests (in the scope of this problem, PSTN gateways). However, 87 there are many different types of PSTN gateways; the broad 88 delineation is between distributed media gateway controllers (MGCs, 89 which manage 'slave' gateways) and self-contained 'smart' gateways. 90 The formal distinction here between smart and slave gateways is that 91 smart gateways speak a call setup protocol (like SIP) and presumably 92 the gateway registration protocol themselves, whereas slave gateways 93 speak only a device control protocol (like Megaco [3]), and rely on 94 their MGC to handle call setup and gateway registration protocols. 96 In the field, smart gateways commonly have low capacities (on the 97 order of a couple of DS1s) whereas the scale of slave gateways can 98 get very large (many DS3s). High-density slave gateways tend to have 99 support for SS7 intermachine trunks (IMTs), whereas low-density smart 100 gateways often forgo IMT support for ISDN PRI or multifrequency (MF) 101 trunk support; the signaling channels for all PRI and MF trunks 102 physically terminate on the gateway themselves, but SS7 requires a 103 consolidated point at which signaling arrives for the trunks 104 associated with multiple gateways, and hence is conducive to the 105 MGC/slave gateway model. Some very low-density residential gateways 106 support POTS lines on the DS0 level, but these are considered out of 107 the scope of this architecture. 109 For reasons of economics, operation and management, among others, 110 large carriers are predominantly SS7-based, so this document assumes 111 that MGCs and large slave gateways constitute the majority of the 112 network in this scenario. Smaller smart gateways may also be sparing 113 deployed in the network to face specific resources (mostly PBXs). 115 A great deal of the problem of gateway registrations concerns the 116 'reachability' of the resources managed by gateways; a registration 117 expresses specifically that a given set of resources is reachable. 118 In the past, and notably in TRIP [5]), protocols have expressed 119 reachability information for a range of E.164 [6] numbers. 120 Traditional PSTN switches do not support dynamic gateway 121 registration, and therefore the PSTN has no concept of reachability 122 nor a need for a protocol that propagates reachability information. 123 For those unfamiliar with this term, we define whether a resource is 124 reachable through a gateway or not as follows: if a call sent to the 125 gateway addressed to the resource in question will be routed properly 126 to the final destination in the PSTN, then the resource is reachable 127 through the gateway. This document argues for a shift in the 128 'reachability' model that focuses on the reachability of resources 129 through particular trunk groups located on gateways, rather than just 130 considering the problem from the vantage of the gateways themselves. 132 The IPTEL working group is chartered to provide a gateway 133 registration mechanism for 'the exchange of dynamic information'. It 134 is important to note that the reason why the exchange of dynamic 135 information is interesting to a carrier network is that it 136 facilitates provisioning and network management. Autodiscovery of a 137 location server by gateways or vice versa wouldn't seem to really 138 make a VoIP carrier's network substantially easier to manage or 139 provision in any obvious way; although it has been discussed in the 140 context of gateway registration, this document assumes that 141 autodiscovery is unnecessary and that either the gateway or the 142 location server is configured with the location of the other. Also 143 note that the registrations performed by gateways are unlike those 144 used in SIP, for example, which has its own registration process by 145 which a user agent can register the identity of its user with a 146 registrar, than in turn provisions an association in a location 147 service that will be used to route requests for the user to the 148 correct user agent. Neither gateways nor trunk groups have 149 identities and contact addresses that are comparable to those used in 150 SIP registrations. 152 Finally, this document discusses practices that may be specific to 153 North American telephone networks, such as describing 24-channel DS1 154 trunks. The authors believe, however, that these principles probably 155 roughly apply to gateways deployed in any segment of the PSTN/GSTN. 156 The work in this document provides additional architectures and 157 considerations that should be understood in the framework for 158 Internet telephony routing given in RFC2871 [4]; many terms 159 (including 'location server') defined in that document are used here. 161 2. Defining Trunk Groups 163 Before we take the discussion of trunks any further, we must define 164 both a trunk and a trunk group and explain the difference between the 165 two. The following definitions are taken from [7]. 167 Trunk: In a network, a communication path connecting two switching 168 systems used in the establishment of an end-to-end connection. In 169 selected applications, it may have both its terminations in the 170 same switching system. 172 Trunk Group: A set of trunks, traffic engineered as a unit, for the 173 establishment of connections within or between switching systems 174 in which all of the paths are interchangeable except where 175 subgrouped. 177 Since the introduction of ubiquitous digital trunking, which resulted 178 in the allocation of DS0s between end offices in minimum groups of 24 179 (in North America), it has become common to refer to bundles of DS0s 180 as a trunk. Strictly speaking, however, a trunk is a single DS0 181 between two PSTN end offices - however, for the purposes of this 182 document, the PSTN interface of a gateway acts effectively as an end 183 office (i.e. if the gateway interfaces with SS7, it has its own SS7 184 point code, and so on). A trunk group, then, is a bundle of DS0s 185 (that need not be numerically contiguous in an SS7 Trunk Circuit 186 Identification Code (TCIC) numbering scheme) which are grouped under 187 a common administrative policy for routing. 189 This definition does not include what the resources are that are 190 available through a trunk group; nor for the purposes of gateway 191 registration does the definition of a gateway include the E.164 192 number ranges that can be reached through it (following the TRIP 193 model). This document contends that considering the resources that 194 are available through a trunk group may offer us slightly greater 195 leverage on the problems we are trying to solve than considering the 196 resources that are available through a gateway - partially because 197 there are many varieties of gateways that would require different 198 handling in a location server, while trunk groups can be treated 199 relatively uniformly. 201 3. Gateway Deployment Architecture 203 Trunks 204 Gateway 205 Registration 206 IMT 207 Carrier Architecture +----+ ----> +1 208 (H.248)| | 209 Device +---- | GW1| ----> +1703,+1571... 210 Control| | | 211 | +----+ -TG1> +1202,+1703... 212 | 213 | IMT 214 | +----+ ----> +1 215 (SIP) +-----+ | | | 216 +----------->| MGC |----+-----| GW2| ----> +1540,+1804... 217 | +--+--+ | | | 218 | | | +----+ -TG1> +1202,+1703... 219 | | | 220 Call +----------+ | | IMT 221 Setup | | | | +----+ ----> +1 222 (SIP) | Routing | | | | | 223 -------->| Proxy | | +-----| GW3| ----> +1202555, 224 | (LS) | | | | +122544... 225 +----------+ | +----+ -TG2> +44 226 | | | SS7 227 | | +------------------------> TO PSTN 228 | | 229 | | 230 | | +----+ PRI (B&D) 231 | +-------------------------->| GW4| -TG3> +1202533 232 | +----+ 233 | (SIP) 234 | +----+ MF 235 +-------------------------------> GW5| ----> +1703989 236 +----+ 238 In the illustration above, all of the entities that speak SIP are 239 candidates to use the gateway registration mechanism postulated in 240 this document. The SIP proxy server (designated the 'Routing Proxy') 241 also acts as a location server ('LS'), making routing decisions among 242 the appropriate gateways for call setup requests it receives. 244 By way of explanation, the diagram above shows multiple physical 245 interfaces associated with each of the large slave gateways (GW1, GW2 246 and GW3), each of which we'll say for simplicity's sake consists of a 247 DS1 worth of trunks (in reality they would command many times that). 248 One or more E.164 number ranges are associated with each of these 249 DS1s. '+1' indicates that all telephone numbers in the United States 250 are reachable through this DS1 (this DS1 is characteristic of an 251 interexchange (IXC) carrier). The second DS1 on GW1 (pointed to 252 +1703,+1571...) contains a set of reachable area codes within the 253 same rate center, suggesting that the DS1 is wired to a local 254 exchange carrier (LEC) tandem. The second DS1 on GW3 (pointed to 255 +1202555, +1202544...) is associated with a set of specific exchange 256 codes, and is therefore probably an end office DS1 pointing to a 257 class 5 switch. The smaller gateways (GW4 and GW5) have trunks that 258 are associated with smaller range ranges that have most likely been 259 assigned to enterprise customers, possibly PBXs. Finally, note that 260 trunk groups can span multiple slave gateways under the control of an 261 MGC, as is the case with [TG1], the third trunks on GW1 and GW2 (each 262 pointing to +1202,+1703...). 264 In this architecture, the fundamental question about gateway 265 registration is 'what are the resources whose availability is 266 advertised by gateway registration?'. Some possible answers include: 268 Availability of a gateway itself: In the case in which an MGC 269 performs gateway registration, it could notify the LS of the 270 availability of any individual gateway (for example GW1 above). 271 If a standalone gateway (like GW4) does not go offline gracefully, 272 then of course no gateway de-registration message could be sent, 273 but the LS would presumably have some other mechanism (such as the 274 absence of keepalive messages) to determine that the gateway is 275 unavailable. Since an MGC is not coupled to physical trunk 276 resources, it can take advantage of reliability mechanisms that a 277 standalone gateway cannot, and therefore it is well positioned to 278 broker availability information for gateways. Either way, clearly 279 the availability of gateway themselves can be made known to the 280 LS. Limiting the problem space of gateway registration just to 281 gateway availability would be appropriate if any gateway 282 attributes needed to make routing decisions were pre-configured in 283 the location server and were not subject to change over time. 285 Availability of an E.164 number prefix: This is the traditional TRIP 286 model, in which an E.164 range (e.g. '+1303') is propagated from 287 the gateway to the LS. This model works best in the case of 288 standalone smart gateways (like GW4). In the MGC case, it is 289 harder to see what prefixes should be propagated by the MGC to the 290 LS - merely propagating that '+1' is available through the MGC 291 doesn't take into account the different policies that are 292 potentially available on different trunks, which may have all 293 sorts of implications about the desirability of a route. For 294 example, on GW1, the second interface might be a more desirable 295 route for a call than the first, so if the second interface goes 296 down the desirability of GW1 as a route for this particular call 297 should also be lessened - but if the routes associated with the 298 interfaces are aggregated solely on the basis of E.164 number 299 ranges, the loss of the second interface would not even be 300 communicated to the LS. The question this begs is whether the MGC 301 should aggregate routes on behalf of its gateways, and if so, how. 303 Availability of other sorts of PSTN addresses: Also note that in 304 order to allow for more complex PSTN features, routing by non- 305 E.164 addresses such as location routing numbers (LRNs) and 306 carrier identification codes (CICs, see Section 5) should also be 307 permitted, and that the availability of particular CICs or LRNs 308 through an MGC should be advertised. One complication that may 309 arise from this is priority of various addresses, especially if a 310 gateway registration mechanism that requires an innate priority 311 for these addressing schemes is considered. 313 Availability of the PSTN interfaces: Gateways generally have more 314 than one physical interface capable of supporting trunks (as is 315 the case on GW1, GW2 and GW3, each of which sports three 316 interfaces). Once trunks have been established on a physical 317 interface, they will have one of many dynamic states; trunks can 318 be busy, administratively blocked, idle, and so forth. Trunks 319 also have many different static attributes (some of which are 320 detailed below). Clearly, the availability of particular number 321 ranges in a gateway is predicated on the availability of these 322 trunks, and the availability of trunks is predicated on the 323 underlying physical interface (i.e. if the third physical 324 interface on GW3 goes off-line, and all of its trunks are lost, 325 then the +44 country code will no longer be available in the MGC). 327 Availability of trunk groups: For the purposes of scalability and 328 reliability, a more useful construct is a logical set of trunks 329 known as a trunk group, which allows multiple trunks, potentially 330 on different physical interfaces, to be grouped under the same set 331 of administrative policies. A trunk group can also span multiple 332 gateways (as [TG1] spans the third circuits of GW1 and GW2) in 333 order to provide even greater reliability and independence of the 334 underlying physical network. Consider, for example, that if GW2 335 were to go offline, the trunk group consisting of the third 336 physical interfaces of GW1 and GW2 would still be available (with 337 diminished capacity). Note that these properties of trunk groups 338 also generally apply to ISDN NFAS trunks. 340 In summary, the points above argue that the trunk group is the 341 foundational element that determines reachability - access to PSTN 342 address ranges is granted to gateways by the common administrative 343 policies of trunk groups, but the availability of trunk groups 344 themselves is not necessarily predicated on the availability of any 345 single gateway. This document contends that bundling number 346 prefix/address-based routed into trunk groups is the right way for an 347 MGC to aggregate routes for delivery to an LS. Also, by treating 348 trunk groups as routes, the LS can also handle gateway registrations 349 from MGCs and smart gateways uniformly. 351 4. Trunk Group Attributes 353 By shifting the conceptual model to the availability of trunk groups, 354 rather than gateways, we are able to ascribe attributes to trunk 355 groups that might not have made sense for the gateways themselves, 356 which will (as we show below) provide a more versatile framework for 357 routing calls in the location server. Overall, we group these 358 attributes into static and dynamic qualities. This is a 359 representative rather than exhaustive list of possible attributes. 360 Static attributes are qualities that do not change in real-time, but 361 are associated with a trunk group for its lifetime. Whether or not 362 these static qualities are propagated in the gateway registration 363 protocol (which is scoped to consider dynamic attributes), they might 364 be useful factors in making routing decisions. 366 o A trunk group has directionality. It may be one-way inbound, one- 367 way outbound, or two-way. If it is inbound, then obviously it 368 cannot accept any outbound calls routed from a location server. A 369 location server can also have a much better idea of the exact 370 capacity at any given moment of a one-way outbound trunk group 371 than of a two-way trunk group (since it may be in a position to 372 know exactly how many calls have been sent to the one-way outbound 373 trunks). 375 o A single PSTN protocol (Q.931, ISUP, MF, etc) is used to establish 376 calls on a trunk group. In some instances, VoIP messages might 377 rely on signaling mechanisms that are specific to a particular 378 PSTN termination protocol. A good example would be if number 379 portability information is present in the VoIP signaling data - 380 this information will be lost if the call terminates on a Q.931 381 PRI trunk (possibly resulting in an error condition). Location 382 servers may therefore want to take this protocol information into 383 account. 385 Various PSTN addresses (which remain relatively static on a per-trunk 386 group basis) can also usefully be construed as attributes of trunk 387 groups: 389 o E.164 number ranges, if applicable - since every E.164 number is 390 reachable through almost every trunk group, only administrative 391 issues (such as cost and so forth) would make certain ranges 392 preferable to others. 394 o Carrier identification codes. There is one and only one carrier 395 that is responsible for the switch on the other side of a trunk 396 group. Note however that one or more carrier identification codes 397 (CICs) can be associated with a given carrier. And of course, 398 other carriers are also probably in turn reachable through the 399 remote carrier's network. This matter is explored in further 400 detail in Section 5. 402 o Location routing numbers. Trunks to end offices may be associated 403 with a location routing number (LRN) used to route calls for local 404 number portability. Each NP-compliant end office switch in the 405 (North American) PSTN is associated with one LRN. 407 Note that neither of these latter two forms of address are 408 international in scope, i.e. absolutely all the carrier 409 identification codes in the world are not typically reachable by a 410 call setup request sent through a North American trunk. 412 In the traditional (TRIP-like) understanding of gateway registration, 413 it is this static set of PSTN addresses that is registered (with 414 capacity and so forth potentially as an attribute). However, most of 415 the dynamic information that would be exchanged by gateway 416 registration messages are attributes of trunk groups themselves. 417 Given the scope of the gateway registration problem this disparity is 418 interesting. Consider for instance: 420 o The total capacity of a trunk might seem like a static attribute, 421 but over the long term it is actually dynamic. Existing trunk 422 groups are frequently augmented. The total capacity of a trunk 423 group can change over time due to capacity constraints. Large 424 carriers are constantly in the process of augmenting existing 425 trunk groups. The addition of circuits to an existing trunk group 426 is preferable to creating new trunk groups when the policy of the 427 trunks will remain the same. 429 o Trunk groups fill up with calls. If a trunk group is one-way 430 outbound, then in some architectures an LS could track the 431 congestion of particular trunk groups itself without any gateway 432 registration attributes. However, if the trunk group is two-way, 433 it is much more difficult for an LS to keep an accurate count of 434 idle trunks in a trunk group without reporting from gateways. One 435 of the difficult problems with propagating dynamic capacity is the 436 thresholds for reporting - sending a gateway registration message 437 each time the state of a single trunk changes is probably not 438 feasible, so perhaps some fuzzier states for the entire trunk 439 group (e.g. 'almost full') would be needed. 441 o Trunk groups have maintenance conditions - most notably blocking 442 and unblocking. Sending a block for a trunk group prevents new 443 calls from being received on the group. Blocking can be used when 444 a hardware failure occurs that takes a trunk out of service, or as 445 a pre-emptive measure (quiescence) to empty a trunk gradually. 447 o Finally, trunk groups themselves are created and destroyed. 448 Switches associated with major carriers are in an almost constant 449 state of creating trunk groups as connections to new switches are 450 required or connections to existing switches require augmentation 451 with distinct policies. 453 5. Reachability and Preference 455 For each of the PSTN address-related attributes listed in Section 4, 456 there is a concept that a particular trunk group is a favorable or 457 unfavorable route for a particular call. For example, on GW1 in 458 Figure 1, we might like to say that for calls within the 703 NPA, we 459 would like to say that the trunk group to which the second PSTN 460 interface belongs is a more favorable route that the first PSTN 461 interface. This suggests that there is a concept of preference over 462 and above reachability associated with PSTN address attributes. In 463 this section the carrier identification code (CIC) is used as an 464 example to demonstrate various forms of reachability, although 465 similar arguments could be raised regarding the other forms of PSTN 466 addressing as well. 468 There are a number of ways that a user can directly or indirectly 469 select a carrier for a particular call, administratively or on a per- 470 call basis. It is certainly true that a CIC does not necessarily 471 correspond to some physical network - that is, the concept of a 472 'carrier' chosen by a user is largely a matter of who issues your 473 bill, not what physical infrastructure your call crosses. For 474 example, there are resellers of long-distance service whose CICs are 475 really just aliases for the CIC of a major carrier. Large carriers 476 may own several CICs they use to target their services. There is no 477 one-to-one mapping from CICs to physical infrastructure. 479 However, this doesn't mean that a decision isn't made, in some places 480 in the telephone network, about how a call is routed based on the 481 CIC. In SS7, when a CIC has been selected for a call, it is carried 482 within the TNS or (ANSIfied) CIC parameter of the Initial Address 483 Message. The presence of this parameter modifies how a call is 484 routed through the telephone network, especially at tandems. 486 As is noted in the introduction, we say that a given CIC is reachable 487 through a trunk group when an SS7 IAM message carrying this CIC is 488 sent over the trunk group, this call will (eventually) be routed to 489 the administrative domain responsible for the CIC (and presumably get 490 delivered appropriately). One might contend, as an opposing 491 position, that only the carrier that owns the switch on the far side 492 of the trunk should be considered to be reachable through a trunk - 493 but, in a pinch (due to congestion, say) most operators would be 494 content to send calls through less preferred routes, even if doing so 495 introduced a middle-man network, complicating routing and potentially 496 settlement. 498 This suggests that there is a balance between reachability and some 499 form of preference, one that is possibly based on where a trunk group 500 terminates. Let's say for the time being that one or more CICs may 501 be 'directly' reachable over a particular trunk group (largely 502 because of who happens to own the equipment on the other side), but 503 in addition all CICs are usually 'indirectly' reachable through such 504 trunk groups. The same is true of E.164 numbers; certain ranges may 505 be preferred (due to settlement concerns, perhaps) for particular 506 trunk groups, but all number ranges are usually available. This 507 preference follows from the proximity of the PSTN resource on the 508 other side of the trunk group to the network or resource that is 509 identified by the PSTN address. 511 Basing routing logic on the assumption that resources might be 512 directly or indirectly reachable over a particular trunk group has no 513 corollary in traditional telephone networks. However, in the PSTN 514 there is a difference between a trunk group being directly connected 515 to a given carrier and a trunk group being identified as a route to 516 multiple carriers (for example, a trunk group pointing to an access 517 tandem). 'Directly' and 'indirectly' reachable are attempts to 518 capture these sorts of characteristics of a trunk group in the scope 519 of 'reachability', although this does not necessarily to speak to how 520 characteristics might be processed during a route decision in a proxy 521 (which is discussed in Section 6). Propagating routes to proxies and 522 making routing decisions within proxies are related but distinct 523 problems - for now we are focused on the former, not the latter. 525 Indeed, the very terms 'directly' and 'indirectly' reachable have 526 been brought up only to give a sense of the sort of data that needs 527 to be propagated in gateway registration. In fact, finer degrees of 528 granularity than these might be necessarily to adequately capture the 529 necessary routing logic. When the owner of the gateway turns up a 530 trunk group, the gateway would have to be provisioned with this a 531 certain set of information about the new trunk group so it can 532 describe itself properly to a location server. 534 But given these two categories, how would the owners of the GWs 535 decide on the 'directly' and 'indirectly' reachable settings for 536 their TGs with respect to particular CICs? Maybe this information is 537 learned directly from the carrier whose switch terminates the other 538 end of the trunk group - in any event it is learned 539 administratively, not through any PSTN protocol activity. 540 Ultimately, the gateway operator must ascertain if the carrier on the 541 other side of trunk group (which to TG1 is 'directly' reachable) is 542 addressed by one or more specific CICs. The gateway operator could 543 also discover whether or not any or all CICs are 'indirectly' 544 reachable through this carrier in the same manner. 546 Finally, as an aside it's important to note that CICs are national in 547 scope, and that therefore trunk groups are most likely only routes to 548 the set of CICs within a particular nationality (this applies to 549 location routing numbers as well). There have been suggestions in 550 the past that identifiers for CICs in the gateway registration 551 mechanism should be concatenated with some sort of country code to 552 provide a scope of a CIC, which leads to an architecture in which all 553 carriers for a given nationality could be 'available' through a trunk 554 group. 556 6. Building a Route List 558 Once we have determined what information a gateway should send to a 559 location server, we must then grow mildly curious about how a 560 location server decides on a route, or more properly an ordered set 561 of available routes known as a route list, for a particular call 562 (when a proxy server needs to make a routing decision). To what 563 extent does the forwarding logic in location servers influence the 564 requirements for gateway registration? 566 The information that is propagated by the gateway registration 567 protocol is a set of potential routes, just a set of trunk groups and 568 their attributes. These potential routes are eligible to become 569 actual routes for a specific call when a proxy server makes a routing 570 decision. 572 However, this doesn't mean that gateway registration should dictate 573 the route selection algorithm itself - for example, by somehow 574 providing an ordered list of trunk groups to the location server that 575 will apply to some set of calls. Multiple gateways will be sending 576 routes for various trunk groups to the location server in gateway 577 registration messages. Presumably, these gateways can be unaware of 578 one another, and if any one gateway dictated how the location service 579 selected routes, it would probably be to the detriment of other 580 gateways as well as the overall capability of the network. In a 581 better model, the location server receives routes from these various 582 gateways, and for a particular call the location server should be 583 allowed to add trunk groups located on various gateways to the route 584 list - therefore no gateway should be dictating route lists to the 585 location server. 587 So, we can declare location server policy decisions outside the scope 588 of gateway registration signaling - rather, gateway registration 589 influences the construction of a route list. Trunk groups have state 590 that changes dynamically, and these states in turn determine the 591 availability of PSTN addresses. One or more trunk groups could be 592 eligible to receive a particular call, meaning that the requisite 593 PSTN addresses are reachable through the trunk group, the trunk group 594 has available capacity, and so on. On the basis of this data 595 location server that is asked to provide a route for a particular 596 call will construct an ordered 'route list,' as it were, of 597 alternative trunk groups that meet the routing criteria of the call. 599 Note that the construction of a route list should not assumes that it 600 is necessarily desirable for the PSTN path to be minimized at the 601 expense of a more direct IP path, or even that routing calls is 602 necessarily a least-cost problem. This is ultimately a routing 603 policy question, and really either head-end hop-off or tail-end hop- 604 off or any other routing scheme should be enabled by a gateway 605 registration mechanism. 607 The construction of a route list will be performed by the location 608 server that has been provisioned with data by the gateway 609 registration process. The location server then uses a route 610 selection algorithm on this data that introduces necessarily local 611 policy constraints and preferences to optimize amongst the potential 612 routes. Thanks to all of the timely information the location server 613 has learned from gateway registration, it will construct a list that 614 will be more likely to result in the prompt termination of the call 615 than it would have if it had no gateway registration data. It will 616 make this decision by inspecting the signaling for call setup 617 (including the dialed number, a CIC if available, and so forth), and 618 comparing these criteria with the attributes it has learned from the 619 gateway registration process, which tell the location server what 620 possible trunk groups for termination are available, including 621 whether the addressed resources are 'directly' or 'indirectly' 622 available through the trunk groups. This will presumably be taken 623 into account by the routing logic in a proxy server in order to 624 construct a route list for a particular call. 626 So, with a few simple principles (prefer directly available routes to 627 indirectly available routes, etc) for a route selection algorithm, 628 the PS can make a good route list based on the data it receives. 629 This is the whole purpose of gateway registration. However, it is 630 important that gateway registration not limit the capabilities of the 631 route selection algorithm. The data that is provided by gateway 632 registration can be communicated without restricting the sorts of 633 choices that the location server can make. 635 7. An example of Gateway Registration 637 Consider a simple example. The location service in Figure 1 receives 638 gateway registrations for three trunk groups, TG1, TG2 and TG3. For 639 TG1, CIC 0288 is 'directly' reachable and all other CICs are 640 'indirectly' reachable. For TG2, only CIC 5062 is 'directly' 641 reachable. For TG3, all CICs are 'indirectly' reachable. These are 642 the potential routes based on the CIC attribute. 644 Now imagine that a call comes to the PS, and the PS is required to 645 make a routing decision - to construct the actual route list. We'll 646 say that the call is for CIC 0288. The PS constructs, on the basis 647 of the gateway registrations it has received, an ordered route list 648 of: TG1, TG3. Why? TG1 is first because it is the only available 649 trunk group for which the CIC associated with the call is 'directly' 650 reachable. TG2 is ineligible because 0288 is not available through 651 TG2. TG3 is 'indirectly' connected to 0288 (as it is for all CICs), 652 so it ends up on the route list as a less preferred option than TG1. 654 With the route list provided by the location server in mind, the 655 proxy server forwards the call to the MGC responsible for TG1, which 656 will internally choose between GW1 and GW3. If the call doesn't 657 succeed at the MGC for some avoidable reason, the PS will 658 subsequently forward the call to GW4, which is the less preferred 659 route. 661 Finally, note that when a call arrives at the proxy server, it has 662 many routable attributes other than a CIC. Calls also, for example, 663 have a dialed number. The route selection algorithm in the location 664 server, however, decided that it should look at the CIC before the 665 dialed number, and use the CIC to figure out how to route the call, 666 and that it should prefer 'directly' reachable routes to 'indirectly' 667 reachable routes, and so on. This route selection algorithm should 668 if possible be totally independent of the gateway registration 669 protocol - that is to say, the gateway registration protocol should 670 just provide the data and let the location server worry about how 671 that data will be used to route calls. 673 8. Gateway Registration & Route Selection in TRIP 675 The preceding sections show that there is a relationship between the 676 attributes propagated by the gateway registration protocol and the 677 routing decisions (for call setup signaling) made by the proxies that 678 receive these registrations. TRIP in particular strongly couples the 679 two - in fact, TRIP provides for three major functions: 681 1. The protocol itself for propagating routes from one point to the 682 next 684 2. A way of making forwarding decisions for calls based on 685 discriminators propagated in the protocol (TRIBs) 687 3. A way of deciding what routes you will share with peers based on 688 routes you have received 690 By ruling interdomain route propagation outside of the scope of the 691 gateway registration problem, the IPTEL WG has essentially made the 692 third item above out of scope. None of the existing gateway 693 registration requirements really address the second problem - and 694 thus it isn't totally clear whether or not it is in scope (although 695 we discuss is above in Section 6. It is furthermore is not clear if 696 these functions in TRIP are separable. Any gateway registration 697 protocol proposal that seems to limit the sort of forwarding 698 decisions that might be made within the proxy server should be met 699 with caution. Note that TRIP seems to build in some limitations 700 along these lines (like hierarchical discriminators, which are 701 concatenated from most specific to least specific). 703 9. Security Considerations 705 Clearly, any proposed protocol for gateway registration would require 706 security. While this document has not focused on concrete protocol 707 requirements as such, this framework entails a general need in the 708 gateway registration protocol for mutual authentication between 709 gateways and location servers, as well as assurance of message 710 integrity and prevention of replay attacks. Confidentiality is also 711 probably desirable but not an immediate need. 713 Since the focus of this protocol would be an intradomain environment, 714 in which all of the elements speaking the protocol are owned and 715 operated by the same administrative domain, it is likely the security 716 requirements are comparable to those of Megaco [3]. 718 References 720 [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 721 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 723 [2] Greene, N., Ramalho, M. and B. Rosen, "Media Gateway Control 724 Protocol Architecture and Requirements", RFC 2805, April 2000. 726 [3] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and 727 J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 728 2000. 730 [4] Schulzrinne, H. and J. Rosenberg, "A Framework for Telephony 731 Routing over IP", RFC 2805, June 2000. 733 [5] Salama, H., Rosenberg, J. and M. Squire, "A Framework for 734 Telephony Routing over IP", RFC 3219, January 2002. 736 [6] International Telecommunications Union, "Recommendation E.164: 737 The international public telecommunication numbering plan", May 738 1997, . 740 [7] Telcordia, "SR2275: Bellcore Notes on the Network", December 741 1997, . 743 Author's Address 745 Jon Peterson 746 NeuStar, Inc. 747 1800 Sutter St 748 Suite 570 749 Concord, CA 94520 750 US 752 Phone: +1 925/363-8720 753 EMail: jon.peterson@neustar.biz 754 URI: http://www.neustar.biz/ 756 Appendix A. Acknowledgments 758 This gateway registration architecture was discussed and evaluated by 759 the IPTEL working group, especially Mike Pierce, Matt Hammer, and Tom 760 Taylor. 762 Full Copyright Statement 764 Copyright (C) The Internet Society (2002). All Rights Reserved. 766 This document and translations of it may be copied and furnished to 767 others, and derivative works that comment on or otherwise explain it 768 or assist in its implementation may be prepared, copied, published 769 and distributed, in whole or in part, without restriction of any 770 kind, provided that the above copyright notice and this paragraph are 771 included on all such copies and derivative works. However, this 772 document itself may not be modified in any way, such as by removing 773 the copyright notice or references to the Internet Society or other 774 Internet organizations, except as needed for the purpose of 775 developing Internet standards in which case the procedures for 776 copyrights defined in the Internet Standards process must be 777 followed, or as required to translate it into languages other than 778 English. 780 The limited permissions granted above are perpetual and will not be 781 revoked by the Internet Society or its successors or assigns. 783 This document and the information contained herein is provided on an 784 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 785 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 786 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 787 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 788 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Acknowledgement 792 Funding for the RFC Editor function is currently provided by the 793 Internet Society.