idnits 2.17.1 draft-ietf-iptel-trip-gw-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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 39 instances of too long lines in the document, the longest one being 16 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 == Line 127 has weird spacing: '...rmation along...' == Line 319 has weird spacing: '...s to be deter...' == Line 380 has weird spacing: '...refixes that...' == Line 480 has weird spacing: '...minated exter...' == Line 495 has weird spacing: '...defined in t...' == (4 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This attribute is not expected to change frequently. Hence, the LS receiving this attribute MAY disseminate it to other peers, internal to ITAD. Routes MUST not be disseminated external to the ITAD, with TrunkGroups attribute. -- 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) == Unused Reference: '2' is defined on line 977, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 981, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 993, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1007, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Downref: Normative reference to an Informational RFC: RFC 2871 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPTEL Working Group Manjunath Bangalore, Cisco Systems 2 Internet Draft Rajneesh Kumar, Cisco Systems 3 draft-ietf-iptel-trip-gw-00.txt Jonathan Rosenberg, dynamicsoft 4 June 2002 Hussein Salama, Cisco Systems 5 Expiration Date: December 2002 Dhaval N. Shah, Cisco Systems 7 Usage of TRIP in Gateways for Exporting Phone Routes 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 other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes a new application of the Telephony Routing 32 over IP (TRIP) protocol. TRIP was engineered as a tool for inter- 33 domain exchange of telephone routing information. However, it can 34 also be used as a means for gateways and soft switches to export 35 their routing information to a Location Server (LS), which may be 36 co-resident with a proxy or gatekeeper. This LS can then manage those 37 gateway resources. We discuss the motivations for this application, 38 and then show how a subset of TRIP is needed for this application. 40 1. Terminology and Definitions 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [1]. 46 Some other useful definitions are: 48 Trunk: In a network, a communication path connecting two switching 49 systems used in the establishment of an end-to-end connection. In 50 selected applications, it may have both its terminations in the same 51 switching system. 53 TrunkGroup: A set of trunks, traffic engineered as a unit, for the 54 establishment of connections within or between switching systems in 55 which all of the paths are interchangeable except where subgrouped. 57 Carrier: An organization that provides connections for telephony 58 services between end-users and/or exchanges. 60 2. Introduction 62 In typical VoIP networks, Internet Telephony Administrative Domains 63 (ITADs) will deploy numerous gateways for the purposes of 64 geographical diversity, capacity, and redundancy. When a call arrives 65 at the domain, it must be routed to one of those gateways. 66 Frequently, an ITAD will break their network into geographic POPs, 67 with each POP containing some number of gateways, and a proxy server 68 element that fronts those gateways. The proxy server is responsible 69 for managing the access to the POP, and also for determining which of 70 the gateways will receive any given call that arrives at the POP. 72 This configuration is depicted graphically in Figure 1. 74 +---------+ 75 | | 76 | GW | 77 -> +---------+ 78 // 79 // 80 // +---------+ 81 // | | 82 // | GW | 83 // +---------+ 84 // 85 +----------+ // TO PSTN 86 | | / +---------+ 87 | Routing | ---------------> | | -----> 88 -------->| Proxy | | GW | 89 | | -- +---------+ 90 | | -- 91 +----------+ -- 92 --- +---------+ 93 -- | | 94 -- | GW | 95 -- +---------+ 96 --> 98 +---------+ 99 | | 100 | GW | 101 +---------+ 103 Figure 1: Gateway and LS Configuration 105 The decision about which gateway to use depends on many factors, 106 including their availability, remaining call capacity and call 107 success statistics particular POTS destination. For the proxy to do 108 this adequately, it needs to have access to this information in 109 real-time, as it changes. This means there must be some kind of 110 communications between the proxy and the gateways to convey this 111 information. 113 In this document, we specify a usage of TRIP to communicate this 114 information from the gateways to the location servers associated with 115 the proxies that make call routing decisions. Section 3 looks at TRIP 116 [4,5]. We then describe the details of a TRIP solution in Section 4. 117 It is assumed that the reader is familiar with TRIP. 119 3. TRIP 121 TRIP was engineered as a tool for interdomain route exchange. At 122 first glance, it may not seem appropriate for application in a 123 gateway. However, TRIP provides exactly the features needed to solve 124 the problem at hand. TRIP allows one entity (in this case, a gateway) 125 to convey to another (in this case, a proxy) a set of telephony 126 routes which terminate through it. These routes are represented by 127 telephony addressing information along with attributes that can 128 express resource availability and preferences. In TRIP, the routing 129 tables are exchanged once. Only when they change are updates sent. 130 This is exactly the capability needed for a gateway to send its 131 routing information to a proxy, and hence allows TRIP to be leveraged 132 for this purpose. Since routing information is sent when it changes, 133 using TRIP does not require communications on the critical path of 134 call setup signaling. 136 TRIP also supports a keepalive between peers. This keepalive is a 137 short message, sent fairly frequently. It does not contain routing 138 information. The period of the keepalive is negotiated once at 139 startup time. If one of the entities crashes, the other flushes all 140 routes received from it. 142 TRIP can contain attributes describing a route. New attributes can 143 easily be added. The available capacity of a route is needed by the 144 proxies to properly load balance and route to a set of gateways. This 145 capacity can be expressed as an attribute. 147 TRIP can be run over IPSec or TLS between two peers, providing 148 authentication, integrity and privacy. 150 Another advantage of using TRIP here is that it makes the 151 redistribution of local gateway reachability information into inter- 152 domain TRIP relatively simple (refer to Figure 6), because it's the 153 same protocol. 155 While it is true that TRIP is complex, almost all of this complexity 156 is related to the processing of routes *received* from other peers. 157 An element, such as a gateway, which only *sends* routes to a peer 158 (the proxy), does not need to implement any of those functions. In 159 particular, any processing related to aggregation, TRIB updates, 160 route propagation and advertisement, handling of transitivity and 161 unknown routes, or the decision process need not be implemented. The 162 resulting set of functions are very small. They are composed of only: 164 - The initial OPEN phase, exchange of keepalive timers, and the 165 process of bringing up the state machine. 166 - Sending of one or more UPDATE messages containing the routes and 167 parameters of the gateways. 168 - Sending of a periodic keepalive. 170 4. Defining TRIP-GW 172 We call the subset of TRIP needed for this application "TRIP-GW", 173 "TRIP-Lite", or TRIP for gateways. We note that this is a valid 174 subset defined by the specification, so that a TRIP-GW speaker is a 175 conformant TRIP speaker. In this section, we include the various 176 attributes, some of them new and also introduce two new address 177 families. The gateway and proxy behaviors are discussed in more 178 details in sections 4.9 and 4.10 respectively. 180 4.1. AvailableCircuits Attribute 182 Mandatory: False. 183 Required Flags: optional, non-transitive 184 Potential Flags: None. 185 TRIP Type Code: To be assigned by IANA. 187 The AvailableCircuits attribute is used ONLY between a gateway and 188 its peer LS responsible for managing that gateway. It is for this 189 reason that this attribute is non-transitive. If it is received in a 190 route, it MUST NOT be propagated unless the LS is sure that it is 191 relatively static. 193 The AvailableCircuits identifies the number of PSTN circuits that are 194 currently available on a route to complete calls. The number of 195 additional calls sent to that gateway for that route cannot exceed 196 the circuit capacity. If it does, the signaling protocol will likely 197 generate errors, and calls will be rejected. 199 AvailableCircuits is measured in integral number of calls. It is very 200 dynamic. 202 4.1.1. AvailableCircuits Syntax 204 The AvailableCircuits attribute is a 4-octet unsigned numeric value. 205 It represents the number of circuits remaining for terminating calls 206 to this route. 208 4.1.2. Route Origination and AvailableCircuits 210 Routes MAY be originated containing the AvailableCircuits attribute. 211 Since this attribute is highly dynamic, changing with every call, 212 updates MAY be sent as it changes. However, it is RECOMMENDED that a 213 gateway originating routes with this attribute use thresholds, and 214 that routes are re-originated only when the attribute moves above or 215 below a threshold. It is also RECOMMENDED that the thresholds in each 216 direction (going above a threshold and going below a threshold) be 217 different, thus achieving a form of hysterisis. Both of these 218 measures help reduce the messaging load from route origination. 220 4.1.3. Route Selection and AvailableCircuits 222 The AvailableCircuits attribute MAY be used for route selection. 223 Since one of its primary applications is load balancing, an LS will 224 wish to choose a potentially different route (amongst a set of routes 225 for the same prefix) on a call by call basis. This can be modeled as 226 re-running the decision process on the arrival of each call. The 227 aggregation and dissemination rules for routes with this attribute 228 ensure that re-running this selection process never results in 229 propagation of a new route to other peers. 231 4.1.4. Aggregation and AvailableCircuits 233 Not applicable 235 4.1.5. Route Dissemination and AvailableCircuits 237 Routes MUST NOT be disseminated with the AvailableCircuits attribute. 238 The attribute is meant to reflect capacity at the originating gateway 239 only. Its highly dynamic nature makes it inappropriate to disseminate 240 in most cases. 242 4.2. TotalCircuitCapacity Attribute 244 Mandatory: False. 245 Required Flags: optional, transitive 246 Potential Flags: None. 247 TRIP Type Code: To be assigned by IANA. 249 The TotalCircuitCapacity attribute is used to reflect the 250 administratively provisioned capacity as opposed to the availability 251 at a given point in time as provided by the AvailableCircuits 252 attribute. Because of its relatively static nature, this attribute 253 MAY be propogated beyond the LS that receives it, hence making this 254 attribute transitive. 256 The TotalCircuitCapacity identifies the total number of PSTN circuits 257 that are available on a route to complete calls. It is used in 258 conjunction with the AvailableCircuits attribute in gateway selection 259 by the LS. The total number of calls sent to the specified route on 260 the gateway cannot exceed this total circuit capacity under steady 261 state conditions. 263 TotalCircuitCapacity is measured in integral number of calls. This is 264 not expected to change frequently. This can change, for instance, 265 when certain telephony trunks on the gateway are taken out of service 266 for maintenance purposes. 268 4.2.1. TotalCircuitCapacity Syntax 270 The TotalCircuitCapacity attribute is a 4-octet unsigned numeric 271 value. It represents the total number of circuits available for 272 terminating calls through this advertised route. This attribute 273 represents a potentially achievable upper bound on the number of 274 calls which can be terminated on this route in total. 276 4.2.2. Route Origination and TotalCircuitCapacity 278 Routes MAY be originated containing the TotalCircuitCapacity 279 attribute. 281 4.2.3. Route Selection and TotalCircuitCapacity 283 The TotalCircuitCapacity attribute MAY be used for route selection. 284 Since one of its primary applications is load balancing, an LS will 285 wish to choose a potentially different route (amongst a set of routes 286 for the same destination), on a call by call basis. This can be 287 modeled as re-running the decision process on the arrival of each 288 call. The aggregation and dissemination rules for routes with this 289 attribute ensure that re-running this selection process never results 290 in propagation of a new route to other peers. 292 4.2.4. Aggregation and TotalCircuitCapacity 294 An LS MAY aggregate routes to the same prefix which contain a 295 TotalCircuitCapacity attribute. It SHOULD add the values of the 296 individual routes to determine the value for the aggregated route in 297 the same ITAD. 299 4.2.5. Route Dissemination and TotalCircuitCapacity 301 Since this attribute reflects the static capacity of the gateway's 302 circuit resources, it is not expected to change frequently. Hence the 303 LS receiving this attribute MAY disseminate it to other peers, both 304 internal and external to the ITAD. 306 4.3. CallSuccess Attribute 308 Mandatory: False. 309 Required Flags: optional, non-transitive 310 Potential Flags: None. 311 TRIP Type Code: To be assigned by IANA. 313 The CallSuccess attribute is a non-transitive attribute used ONLY 314 between a gateway and its peer LS responsible for managing that 315 gateway. If it is received in a route, it MUST NOT be propagated. 317 The CallSuccess attribute provides information about the number of 318 normally terminated calls out of a total number of attempted calls. 319 CallSuccess is to be determined by the gateway based on the 320 Disconnect cause code at call termination. For example, a call that 321 reaches the Alerting stage but does not get connected because of 322 called party being unavailable is conventionally considered a 323 successful call. Similar is the case when the called party is busy. 324 On the other hand, a call that gets disconnected because of a Circuit 325 or Resource being unavailable is conventionally considered a failed 326 call. The exact mapping of disconnect causes to CallSuccess is at the 327 discretion of the gateway reporting the attribute. 329 The CallSuccess attribute is used by the LS to keep track of failures 330 in reaching certain telephony destinations through a gateway(s) and 331 use that information in the gateway selection process to enhance the 332 probability of successful call termination. 334 This information can be used by the LS to consider alternative 335 gateways to terminate calls to those destinations with a better 336 likelihood of success. 338 4.3.1. CallSuccess Syntax 340 The CallSuccess attribute is comprised of two component fields - each 341 represented as an unsigned 4-octet numeric value. The first 342 component field represents the total number of calls terminated 343 normally for the advertised destination on a given address family. 344 The second component field represents the total number of attempted 345 calls for the advertised destination. 347 4.3.2. Route Origination and CallSuccess 349 Routes MAY be originated containing the CallSuccess attribute. This 350 attribute is expected to get statistically significant with passage 351 of time as more calls are attempted. Therefore, it is RECOMMENDED 352 that the gateway make a choice based on local thresholds to determine 353 when to report this attribute in an UPDATE. 355 4.3.3. Route Selection and CallSuccess 357 The CallSuccess attribute MAY be used for route selection. This 358 attribute represents a measure of success of terminating calls to the 359 advertised destination(s). This information MAY be used to select 360 from amongst a set of alternative routes to increase the probability 361 of successful call termination. 363 4.3.4. Aggregation and CallSuccess 365 Not applicable 367 4.3.5. Route Dissemination and CallSuccess 369 Routes MUST NOT be disseminated with the CallSuccess attribute. Its 370 potential to change dynamically does not make it suitable to 371 disseminate in most cases. 373 4.4. Prefix Attributes 375 Mandatory: Conditional Mandatory (if ReachableRoutes is present). 376 Required Flags: Well-known. 377 Potential Flags: None. 378 TRIP Type Codes: To be assigned by IANA. 380 The Prefix attribute is used to represent the list of prefixes that 381 the respective route can complete calls to. This attribute is 382 intended to be used with the Carrier or Trunkgroups address family 383 (discussed in a later section). 385 Though it is possible that all prefix ranges MAY be reachable through 386 a given Carrier, administrative issues could make certain ranges 387 preferable to others. 389 4.4.1. Prefix Attribute Syntax 391 The Prefix attribute could be E.164, Decimal or PentaDecimal (refer 392 to TRIP RFC [4]), each of them having it's own type code. The Prefix 393 attribute is encoded as a sequence of prefix values in the attribute 394 value field. The prefixes are listed sequentially with no padding as 395 shown in Figure 2. Each prefix includes a 2-octet length field that 396 represents the length of the address field in octets. The order of 397 prefixes in the attribute is not significant. 399 1 400 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 . . . 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 401 +-------------------------------+-----------+-------------------------------+----------- 402 | Length | Prefix1...| Length | Prefix2... 403 +-------------------------------+-----------+-------------------------------+----------- 405 Figure 2: Prefix Format 407 4.4.2. Route Origination and Prefix 409 Routes MAY be originated containing the Prefix attribute. 411 4.4.3. Route Selection and Prefix 413 The Prefix attribute MAY be used for route selection. 415 4.4.4. Aggregation and Prefix 417 Routes with differing Prefix attribute MUST NOT be aggregated. 418 Routes with the same value in the Prefix attribute MAY be aggregated 419 and the same Prefix attribute attached to the aggregated object. 421 4.4.5. Route Dissemination and Prefix 423 The LS receiving this attribute should disseminate it to other peers, 424 both internal and external to the ITAD. 426 4.5. TrunkGroups Attribute 428 Mandatory: False. 429 Required Flags: optional, transitive 430 Potential Flags: None. 431 TRIP Type Code: To be assigned by IANA. 433 The TrunkGroups attribute is used to represent trunkgroups on the 434 gateway that the gateway can complete the calls to. It allows 435 providers to route calls to destinations through preferred trunks. 436 This attribute is relatively static. 438 4.5.1. TrunkGroups Syntax 440 The TrunkGroups attribute is a variable length attribute that is 441 composed of a sequence of trunkgroup length-value fields. It 442 indicates that the gateway can complete the call through any 443 trunkgroup in the sequence. 445 Each trunkgroup is a length-value field (shown in Figure 3 below). 446 The length field is a 1-octet unsigned numeric value. The value field 447 is a variable length alphanumeric field and is also called the 448 trunkgroup label field. The length field represents the size of the 449 trunkgroup label in number of octets. The maximum length is 128 450 octets. 452 0 1 453 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ... 7 8 9 0 1 2 3 4 5 ... 454 +---------------+--------------------+---------------+--------------------- 455 | Length | TrunkGroup Label...| Length | TrunkGroup Label... 456 +---------------+--------------------+---------------+--------------------- 458 Figure 3: TrunkGroups Syntax 460 4.5.2. Route Origination and TrunkGroups 462 Routes MAY be originated containing the TrunkGroups attribute. 464 4.5.3. Route Selection and TrunkGroups 466 The TrunkGroups attribute MAY be used for route selection. Certain 467 trunkgroups MAY be preferred over others based on provider policy. 469 4.5.4. Aggregation and TrunkGroups 471 Routes with differing TrunkGroups attribute MUST NOT be aggregated. 472 Routes with the same value in the TrunkGroups attribute MAY be 473 aggregated and the same TrunkGroups attribute attached to the 474 aggregated object. 476 4.5.5. Route Dissemination and TrunkGroups 478 This attribute is not expected to change frequently. Hence, the LS 479 receiving this attribute MAY disseminate it to other peers, internal 480 to ITAD. Routes MUST not be disseminated external to the ITAD, with 481 TrunkGroups attribute. 483 4.6. Carrier Attribute 485 Mandatory: False. 486 Required Flags: optional, transitive 487 Potential Flags: None. 488 TRIP Type Code: To be assigned by IANA. 490 The Carrier attribute is used to represent the list of Carrier 491 Identification Codes(CIC's) that the gateway can complete the calls 492 to. It enables providers to route calls to destinations through 493 preferred carriers. A CIC represents a unique code assigned to the 494 carrier or telephony service provider offering the service The CIC 495 definition is as defined in the ITU specification referenced 496 below[8,9]. 498 This attribute is relatively static. 500 4.6.1. Carrier Syntax 502 The Carrier attribute is a variable length attribute that is composed 503 of a sequence of carrier identification codes. It indicates that the 504 route can complete the call to any of the carriers represented by the 505 carrier identification codes in the sequence. 507 Each carrier identification code in the sequence is a fixed length 508 2-octet unsigned numeric value as shown below. 510 0 1 2 3 511 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 2 3 512 +-------------------------------+-------------------------------+----- 513 | CarrierIdCode1 | CarrierIdCode2 | ... 514 +-------------------------------+-------------------------------+----- 516 Figure 4: Carrier Syntax 518 4.6.2. Route Origination and Carrier 520 Routes MAY be originated containing the Carrier attribute. 522 4.6.3. Route Selection and Carrier 524 The Carrier attribute MAY be used for route selection. Certain 525 carriers MAY be preferred over others based on provider policy. 527 4.6.4. Aggregation and Carrier 529 Routes with differing Carrier attribute MUST NOT be aggregated. 530 Routes with the same value in the Carrier attribute MAY be aggregated 531 and the same Carrier attribute attached to the aggregated object. 533 4.6.5. Route Dissemination and Carrier 535 This attribute is not expected to change frequently. Hence, the LS 536 receiving this attribute MAY disseminate it to other peers, both 537 internal and external to the ITAD. 539 4.7. TrunkGroup and Carrier Address Families 541 When a set of GWs are to managed at the granularity of carriers or 542 trunkgroups then it may be more appropriate for a GW can advertise 543 routes using the Carrier address family or trunkgroup address family 544 respectively. Also, in a TRIP-GW association between the gateway and 545 the LS responsible for managing that gateway, there are some 546 attributes that more naturally fit in as advertised properties of 547 trunkgroups or carriers rather than that of advertised prefixes, For 548 example: the AvailableCircuit information on a particular trunkgroup 549 or a particular carrier. To express this relationship, the existing 550 TRIP address families are inadequate. We need separate address 551 families that can associate certain properties like AvailableCircuits 552 information to trunkgroups or carriers. 554 The primary benefits of this model are as follows: 556 - It allows a service provider to route calls based strictly on the 557 trunkGroups or carriers. 558 - it facilitates more accurate reporting of attributes of a dynamic 559 nature like AvailableCircuits by providing the ability to manage 560 resources at the granularity of a trunkgroup or a carrier. 561 - Gateways can get really large with the ability to provision 562 hundreds or a few thousand circuits and this can increase the 563 potential for traffic that reports dynamic resource information 564 between the gateway and the LS. The model introduced can 565 potentially alleviate this UPDATE traffic hence increasing 566 efficiency and providing a scalable gateway registration model. 568 4.7.1. Address Family Syntax 570 Consider the generic TRIP route format from TRIP[4] shown below. 572 0 1 2 3 573 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 574 +---------------+---------------+--------------+----------------+ 575 | Address Family | Application Protocol | 576 +---------------+---------------+--------------+----------------+---- 577 | Length | Address (variable) .... 578 +---------------+---------------+--------------+----------------+---- 580 Figure 5: Generic TRIP Route Format 582 The Address Family field will be used to represent the type of the 583 address associated for this family, which is based on the TrunkGroup 584 or Carrier. The codes for the new address families will be allocated 585 by IANA. 587 The Application Protocol field is same as the one for the Decimal, 588 PentaDecimal and E.164 address families defined in TRIP[4]. The 589 Length field represents the total size of the Address field in bytes. 591 The value in the Address field represents either the TrunkGroup or 592 the Carrier address families and the syntax is as follows: 594 For the TrunkGroup Address Family, the Address field is a variable 595 length alphanumeric field (trunkgroup label), where length is 596 determined by the length field of the route. The maximum value of the 597 length field for this Address Family is 128 bytes. 599 For the Carrier Address Family, the length field represents the 600 length of the Address field in bytes. The Address field is a fixed 601 length field that consists of the CarrierIdCode (CIC). Again, the 602 CIC is as defined in ITU specification M.400[8]. CIC is a fixed 603 length 2-octet unsigned numeric value as shown in Figure 4 above. 605 If a gateway supports any of these address families, it should 606 include that address family as one of the Route types supported in 607 the OPEN message capability negotiation phase. 609 The following attributes are currently defined to be used with all 610 the address families including the TrunkGroup and Carrier address 611 families. 613 - AvailableCircuits Attribute 614 - TotalCircuitCapacity Attribute 615 - CallSuccess Attribute 617 It is recommended that the above three attributes be used by the 618 gateway with the TrunkGroup or Carrier address families, if 619 possible. This will potentially offer a more efficient resource 620 reporting framework, and a scalable model for gateway 621 provisioning. 623 However, when the gateway is not using TrunkGroup or Carrier 624 address family, it MAY use the above attributes with the Decimal, 625 PentaDecimal and E.164 address families. 627 The Prefix attributes MUST NOT be used with the Prefix address 628 families. 630 The Carrier attribute MUST NOT be used with the Carrier and 631 TrunkGroup address families. 633 The TrunkGroups attribute MUST NOT be used with the TrunkGroup 634 and Carrier address families. 636 4.8. Other attribute considerations 638 4.8.1. Cost/Pricing attribute 640 In exploring attributes suitable for the GW-LS communications, 641 Pricing is another attribute that was considered. Though at first 642 glance, it seems like a useful piece of information to be advertised 643 by the gateway to express the price offered by carriers to different 644 destinations, in reality, the computation of pricing can get quite 645 complex. For example, the price offered by a provider can vary by 646 time of day, it can be based on an agreement between two service 647 providers interconnecting with each other, it could be based on one 648 price for the first 'n' minutes and a different price after that, 649 Least Cost routing choices and Grades of service offered by a carrier 650 can affect pricing. There could be other factors as well. Expressing 651 this complex interplay between different factors that determine 652 pricing is non-trivial to represent. It will be a subject of further 653 investigation to determine whether advertising pricing associated 654 with carriers in its simple form without any dependencies adds value 655 to be included as an attribute in the TRIP-GW communications. 657 4.9. Gateway Operation 659 A gateway uses TRIP to advertise its reachability to its domain's 660 Location Server(s) (LS, which are closely coupled with proxies). The 661 gateway operates in TRIP Send Only mode since it is only interested 662 in advertising its reachability, but is not interested in learning 663 about the reachability of other gateways and other domains. Also, the 664 gateway will not create its own call routing database. Therefore, the 665 gateway does not need a complete implementation of TRIP. A 666 lightweight version of the protocol is sufficient. In this section we 667 describe the operation of TRIP on a gateway. 669 4.9.1. Session Establishment 671 When opening a peering session with a TRIP LS, a TRIP-GW gateway 672 follows exactly the same procedures as any other TRIP speaker. The 673 TRIP-GW gateway sends an OPEN message which includes a Send Receive 674 Capability in the Optional Parameters. The Send Receive Capability is 675 set by the gateway to Send Only. The OPEN message also contains the 676 address families supported by the gateway. When the TRIP LS receives 677 the gateway's OPEN message, it sets its local policy such that no 678 UPDATE messages are sent to the TRIP-GW gateway. The remainder of the 679 peer session establishment is identical to TRIP. 681 4.9.2. UPDATE Messages 683 Once the peer session has been established, the gateway sends UPDATE 684 messages to the TRIP LS with the gateway's entire reachability. The 685 Gateway also sends any attributes associated with the routes. 687 If the gateway's reachability changes at any point in time, the 688 gateway MUST generate UPDATE message(s) with the change. The 689 frequency of successive UPDATE messages MUST follow the same rules 690 specified for TRIP[4]. The TRIP-GW gateway MUST support all 691 mandatory TRIP attributes. 693 If the gateway receives an UPDATE message from the TRIP LS, it MUST 694 silently discard it as specified for TRIP[4]. No further action 695 should be taken. 697 4.9.3. KEEPALIVE Messages 699 KEEPALIVE messages are periodically exchanged over the peering 700 session between the TRIP-GW gateway and the TRIP LS as specified in 701 Section 4.4 of TRIP RFC[4]. 703 4.9.4. Error Handling and NOTIFICATION Messages 705 The same procedures used with TRIP, are used with TRIP-GW for error 706 handling and generating NOTIFICATION messages. The only difference is 707 that a TRIP-GW gateway will never generate a NOTIFICATION message in 708 response to an UPDATE message, irrespective of the contents of the 709 UPDATE message. Any UPDATE message is silently discarded. 711 4.9.5. TRIP-GW Finite State Machine 713 When the TRIP-GW finite state machine is in the Established state and 714 an UPDATE message is received, the UPDATE message is silently 715 discarded and the TRIP-GW gateway remains in the Established state. 716 Other than that the TRIP finite state machine and the TRIP-GW finite 717 state machine are identical. 719 4.9.6. Call Routing Databases 721 A TRIP-GW gateway may maintain simultaneous sessions with more than 722 one TRIP LSs. A TRIP-GW gateway maintains one call routing database 723 per peer TRIP LS. These databases are equivalent to TRIP's Adj- 724 TRIBs-Out, and hence we will call them Adj-TRIB-GWs-Out. An Adj- 725 TRIB-GW-Out contains the gateway's reachability information 726 advertised to its peer TRIP LS. How an Adj-TRIB-GW-Out database gets 727 populated is outside the scope of this draft (possibly by manual 728 configuration). 730 The TRIP-GW gateway does not have databases equivalent to TRIP's 731 Adj-TRIBs-In and Loc-TRIB, because the TRIP-GW gateway does not learn 732 routes from its peer TRIP LSs, and hence it does not run call route 733 selection. 735 4.9.7. Route Selection and Aggregation 737 TRIP's route selection and aggregation operations MUST NOT be 738 implemented by TRIP-GW gateways. 740 4.10. LS/Proxy Behavior 742 TRIP completely specifies the behavior of the LS as a TRIP speaker. 743 However, the primary question is: is an LS connected to a gateway an 744 internal or external peer of the gateway? 746 The most obvious choice, internal peer, is not the best choice. If 747 an LS has ten peer GWs, all of them advertising reachability to 748 1408*, it will flood all ten routes to all other LSs in the same 749 ITAD. This won't scale, because each LS in the ITAD will have to 750 create a separate Adj-TRIB-In for each GW in that ITAD. In addition, 751 it doesn't allow a SIP Proxy server or a H.323 GK to load balance 752 among the GWs of its zone/subdomain. 754 A similar problem exists when an LS is an external peer to the 755 gateways, and has direct peering relationships with one or more 756 internal peers. However, an ingress LS to an ITAD does not perform 757 aggregation. Only the egress LS aggregates routes. 759 Therefore, it is RECOMMENDED that the LS actually run two instances 760 of TRIP; one with an external peering relationship to the gateways, 761 and the other with an internal peering relationship with one or more 762 LS's within the ITAD. The interface between these instances is 763 largely a local matter; routes are exported from one and imported to 764 the other. In the process of exporting routes from the GW instance, 765 it may be useful to consolidate the routes before importing them to 766 the other LS instance. Some details and motivation for this operation 767 are provided below. In addition, the routes may also be aggregated. 768 This architecture is shown in Figure 6. 770 . . 771 . . 772 . +----------------.---------------------------+ 773 . | .+-+ +-+ | 774 . | .|A| |C| | +-----+ 775 . | .|g| |o| | | | 776 . |+-------------+ .|g| |n| +-------------+ | -- | GW | 777 . || | .|r| |s| | | | -- +-----+ 778 . || TRIP | .|e| |o| | TRIP | | --- 779 . || Instance <-.|g<--|l<--- Instance |--+- +-----+ 780 . || | .|a| |i| | | | | | 781 . || (I-TRIP/ | .|t| |d| | (TRIP-Lite |--+---------| GW | 782 . || E-TRIP) | .|i| |a| | Receiver) | | +-----+ 783 . || | .|o| |t| | |--+--- 784 . |+-/-----------+ .|n| |i| +-------------+ | --- +-----+ 785 . | / .| | |o| | -- | | 786 . |/ .| | |n| | | GW | 787 . / .+-+ +-+ | +-----+ 788 . /| LS . | 789 . / +----------------.---------------------------+ 790 . / . 791 . / . 792 . / . 793 . / . 794 . / . 795 .+/------------+ . 796 .| | . 797 .| | . 798 .| | . 799 .| LS | . 800 .| | . 801 .| | . 802 .| | . 803 .| | . 804 .+\-----------+ . 805 . \ . 806 . \ . 807 . \ . 808 . \ +-----------------.---------------------------+ 809 . \ | .+-+ +-+ | 810 . \| .|A| |C| | +-----+ 811 . \ .|g| |o| | | | 812 . \-------------+ .|g| |n| +-------------+ | -- | GW | 813 . || | .|r| |s| | | | -- +-----+ 814 . || TRIP | .|e| |o| | TRIP | | --- 815 . || Instance <-.|g<--|l<--- Instance |--+- +-----+ 816 . || | .|a| |i| | | | | | 817 . || (I-TRIP/ | .|t| |d| | (TRIP-Lite |--+---------| GW | 818 . || E-TRIP) | .|i| |a| | Receiver) | | +-----+ 819 . || | .|o| |t| | |--+--- 820 . |+-------------+ .|n| |i| +-------------+ | --- +-----+ 821 . | .| | |o| | -- | | 822 . | .| | |n| | | GW | 823 . | .+-+ +-+ | +-----+ 824 . | LS . | 825 . +----------------.---------------------------+ 826 . . 827 . ITAD . 828 ............................ 830 Figure 6: LS Architecture for TRIP-GW 832 4.10.1. Route consolidation 834 A signaling server/Location Server(LS) fronting a set of gateways, 835 receives routing information on several TRIP-Lite sessions. 836 Subsequently, this routing information is presented as candidate 837 routes (possibly as local routes) to the TRIP Decision Process, for 838 every destination for which a route is available. The LS may 839 potentially receive two or more TRIP-Lite routes for the same 840 destination. These alternative routes may be received from the same 841 gateway, or from multiple gateways. It is recommended that the LS 842 consolidate the set of TRIP-Lite routes for every destination, before 843 presenting a candidate route, to the TRIP Decision Process. The 844 purpose of this operation should be to represent the collective 845 routing capabilities of the set of gateways, managed by this LS, and 846 subsequently propagate this information into the core of the TRIP 847 network. An example scenario is shown below. Consider an LS that 848 maintains TRIP-Lite peering sessions with gateways A and B. 850 o Gateway A advertises a route for destination "SIP 408" on the E.164 851 address family with the Carrier attribute being C1 853 o Gateway B advertises a route for destination "SIP 408" on the E.164 854 address family with Carrier attribute C2 856 The LS that receives these TRIP-Lite routes can consolidate these 857 routes into a single route for destination "SIP 408" with its Carrier 858 attribute being a union of the the Carrier attribute values of the 859 individual routes, namely, "C1 C2" This operation is refered to as 860 "Consolidation." In the above example, it is possible that a route to 861 the destination "SIP 408" through one or more carriers may have been 862 lost if the individual routes were not consolidated. In general, 863 there is a potential for loss of gateway routing information, when 864 TRIP-Lite routes from a set of gateways are not consolidated, when a 865 candidate route is presented to the TRIP Decision process. The 866 specifics of applying the consolidation operation to different 867 attributes and routes from different address families, is left to the 868 individual TRIP-Lite receiver implementations. In addition, the 869 route selection procedures as documented in the TRIP RFC [4], do not 870 apply to processing of TRIP-Lite routes received from the gateways. 872 4.10.2. Aggregation 874 The set of gateway routes, that are in a consolidated form or 875 otherwise, MAY be aggregated before importing it to the LS instance 876 that is responsible for I-TRIP/E-TRIP processing. This operation 877 follows the standard aggregation procedures described in the TRIP 878 RFC[4], while adhering to the aggregation rules for each route 879 attribute. 881 5. IANA Considerations 883 - The Attribute Type Codes for the new attributes: 884 AvailableCircuits, TotalCircuitCapacity, CallSuccess, Prefix, 885 TrunkGroups and Carrier described in Sections 4.1, 4.2, 4.3, 4.4, 886 4.5 and 4.6 above, respectively, are to be assigned by IANA. 887 - The Address Family Codes for the new address families: TrunkGroup 888 and Carrier described in Section 4.7, are to be assigned by IANA. 890 6. Changes since -03 892 - Removed Carrier-Trunkgroup attribute and address family and 893 references to it. 894 - Added Terminology and Definitions section. 895 - Updated CallSuccess attribute. 896 - Added Prefix attribute. 897 - Added Carrier attribute. 898 - Added TrunkGroups attribute. 899 - Added TrunkGroup Address Family. 900 - Added Carrier Address Family. 901 - Added some more references. 903 7. Changes since -02 905 - Removed the requirements section. 906 - Discussed the motivation for introducing Carrier information into 907 TRIP. 908 - Defined a new attribute for the E.164 address family. 909 - Defined a new address family for CarrierCode-TrunkGroup 910 combination . 911 - Defined new attributes to advertise dynamic gateway 912 characteristics like resource availability, and call success 913 rate. 914 - Added as section to validate the TRIP-GW solution against the 915 requirements in [7]. 917 8. Changes since -01 919 - Added requirements. 920 - Added more formal analysis of REGISTER and added analysis of SLP. 921 - Removed circuit capacity attribute. 923 9. Changes since -00 925 - Added text to stress the value of this proposal for managing a 926 gateway cluster. 927 - Added attributes for circuit capacity and DSP capacity. 928 - Added section on LS operation, discussing aggregation issue. 930 Authors' Addresses 932 Manjunath Bangalore 933 Cisco Systems 934 Mail Stop SJC-21/2/2 935 771 Alder Drive 936 Milpitas, CA 95035 937 email: manjax@cisco.com 939 Rajneesh Kumar 940 Cisco Systems 941 Mail Stop SJC-21/2/2 942 771 Alder Drive 943 Milpitas, CA 95035 944 email: rajneesh@cisco.com 945 Jonathan Rosenberg 946 dynamicsoft 947 72 Eagle Rock Avenue 948 First Floor 949 East Hanover, NJ 07936 950 email: jdrosen@dynamicsoft.com 952 Hussein F. Salama 953 Cisco Systems 954 Mail Stop SJC-24/3/2 955 170 W. Tasman Drive 956 San Jose, CA 95134 957 email: hsalama@cisco.com 959 Dhaval N. Shah 960 Cisco Systems 961 Mail Stop SJC-21/2/2 962 771 Alder Drive 963 Milpitas, CA 95035 964 email: dhaval@cisco.com 966 Acknowledgments 968 We wish to thank David Oran, Anirudh Sahoo, Kevin McDermott, Randy 969 Baird, Cullen Jennings, Jon Peterson and Li Li for their 970 insightful comments and suggestions. 972 References 974 [1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement 975 Levels", BCP 14, RFC 2119, March 1997. 977 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 978 session initiation protocol," Request for Comments 2543, Internet 979 Engineering Task Force, Mar. 1999. 981 [3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service 982 location protocol, version 2," Request for Comments 2608, Internet 983 Engineering Task Force, June 1999. 985 [4] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over 986 IP (TRIP)," Request for Comments 3219, Internet Engineering Task 987 Force, January 2002. 989 [5] J. Rosenberg and H. Schulzrinne, "A framework for telephony 990 routing over IP," Request for Comments 2871, Internet Engineering 991 Task Force, June 2000. 993 [6] International Telecommunication Union, "Packet based multimedia 994 communication systems," Recommendation H.323, Telecommunication 995 Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. 997 [7] J. Rosenberg, "Requirements for Gateway Registration," Internet 998 Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. 1000 [8] ITU-T M.1400 Specification titled "Designations for 1001 interconnections among network operators," published October 10, 1002 2001. 1004 [9] ITU-T List of ITU Carrier Codes (published periodically in the 1005 ITU-T Operational Bulletin). 1007 [10] J. Peterson, "An Architecture for Gateway Registration Based on 1008 Trunk Groups," Internet Draft, Internet Engineering Task Force, Feb. 1009 2002. Work in progress. 1011 Full Copyright Statement 1013 Copyright (C) The Internet Society (1999). All Rights Reserved. 1015 This document and translations of it may be copied and furnished to 1016 others, and derivative works that comment on or otherwise explain it 1017 or assist in its implementation may be prepared, copied, published 1018 and distributed, in whole or in part, without restriction of any 1019 kind, provided that the above copyright notice and this paragraph are 1020 included on all such copies and derivative works. However, this 1021 document itself may not be modified in any way, such as by removing 1022 the copyright notice or references to the Internet Society or other 1023 Internet organizations, except as needed for the purpose of 1024 developing Internet standards in which case the procedures for 1025 copyrights defined in the Internet Standards process must be 1026 followed, or as required to translate it into languages other than 1027 English. 1029 The limited permissions granted above are perpetual and will not be 1030 revoked by the Internet Society or its successors or assigns. 1032 This document and the information contained herein is provided on an 1033 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1034 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1035 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1036 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1037 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.