idnits 2.17.1 draft-ietf-iptel-tgrep-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 43 instances of too long lines in the document, the longest one being 19 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 319 has weird spacing: '...s to be deter...' == Line 381 has weird spacing: '...refixes that...' == Line 386 has weird spacing: '...ges may be re...' == Line 459 has weird spacing: '...nkgroup for t...' == Line 488 has weird spacing: '...minated exter...' == (3 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 TrunkGroup 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 1013, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1017, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1039, 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' Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPTEL Working Group Manjunath Bangalore, Cisco Systems 3 Internet Draft Rajneesh Kumar, Cisco Systems 4 draft-ietf-iptel-tgrep-00.txt Jonathan Rosenberg, dynamicsoft 5 October 2002 Hussein Salama, Cisco Systems 6 Expiration Date: April 2003 Dhaval N. Shah, Cisco Systems 8 A Telephony Gateway REgistration Protocol (TGREP) 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-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 Abstract 32 This document describes the Telephony Gateway Registration Protocol 33 (TGREP) for registration of telephony prefixes supported by telephony 34 gateways and soft switches. The registration mechanism can also be 35 used to export resource information. The prefix and resource 36 information can then be passed on to a TRIP Location Server, which in 37 turn can propogate that routing information within the same, and 38 other internet telephony administrative domains (ITAD). TGREP shares 39 a lot of similarites with the TRIP Protocol. It has similar 40 procedures and Finite State Machine for session establishment. It 41 also shares the same format for messaages and a subset of attributes 42 with TRIP. 44 1. Terminology and Definitions 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [1]. 50 Some other useful definitions are: 52 Trunk: In a network, a communication path connecting two switching 53 systems used in the establishment of an end-to-end connection. In 54 selected applications, it may have both its terminations in the same 55 switching system. 57 TrunkGroup: A set of trunks, traffic engineered as a unit, for the 58 establishment of connections within or between switching systems in 59 which all of the paths are interchangeable except where subgrouped. 61 Carrier: An organization that provides connections for telephony 62 services between end-users and/or exchanges. 64 2. Introduction 66 In typical VoIP networks, Internet Telephony Administrative Domains 67 (ITADs) will deploy numerous gateways for the purposes of 68 geographical diversity, capacity, and redundancy. When a call arrives 69 at the domain, it must be routed to one of those gateways. 70 Frequently, an ITAD will break their network into geographic POPs, 71 with each POP containing some number of gateways, and a proxy server 72 element that fronts those gateways. The proxy server is responsible 73 for managing the access to the POP, and also for determining which of 74 the gateways will receive any given call that arrives at the POP. 76 This configuration is depicted graphically in Figure 1. 78 +---------+ 79 | | 80 | GW | 81 -> +---------+ 82 // 83 // 84 // +---------+ 85 // | | 86 // | GW | 87 // +---------+ 88 // 89 +----------+ // TO PSTN 90 | | / +---------+ 91 | Routing | ---------------> | | -----> 92 -------->| Proxy | | GW | 93 | | -- +---------+ 94 | | -- 95 +----------+ -- 96 --- +---------+ 97 -- | | 98 -- | GW | 99 -- +---------+ 100 --> 102 +---------+ 103 | | 104 | GW | 105 +---------+ 107 Figure 1: Gateway and LS Configuration 109 The decision about which gateway to use depends on many factors, 110 including their availability, remaining call capacity and call 111 success statistics particular POTS destination. For the proxy to do 112 this adequately, it needs to have access to this information in 113 real-time, as it changes. This means there must be some kind of 114 communications between the proxy and the gateways to convey this 115 information. 117 In this document, we specify a protocol for registration of routes 118 (destinations) supported by the gateway to the TRIP Location Server, 119 known as Telephony Gateway REgistration Protocol (TGREP). TGREP 120 Protocol can be considered an auxiliary protocol to TRIP. Routes 121 learnt through TGREP can be injected into and further processed 122 and/or propogated by the TRIP Location Server. 124 TGREP shares a lot of commonality with the TRIP in various aspects. 126 Particularly, TGREP and TRIP have the same session establishment 127 procedures, state machine etc. TGREP also makes use of a similar 128 UPDATE message to propogate the routes supported. It uses 129 Notification, Keepalive and OPEN message in the same essence as TRIP. 130 TGREP defines few new attributes that are needed to specify certain 131 characterstics of gateways, like Available Capacity for a destination 132 etc. The document aims at specifying all the attributes that can go 133 in on the TGREP session. The document also specified some new address 134 families which can be useful in advertising the information on the 135 GWs. The type codes for the new attributes and address families are 136 yet to be obtained from IANA. An attempt will be made to assign the 137 codes in such a way that they are in continuation with the codes 138 assigned for attributes and families defined in the the TRIP RFC[4]. 140 As a general rule, because of lot of similarities between TRIP and 141 TGREP, frequent reference will be made to the terminologies and 142 formats defined in TRIP RFC[4]. It is suggested that the reader be 143 familiar with the concepts of TRIP like attributes, flags, route 144 types, address families etc. 146 3. Defining TGREP 148 TGREP is a route registration protocol for telephony destinations on 149 a gateway. These telephony destinations could be prefixes, trunk 150 groups or Carriers. The Speaker of TGREP resides on the GW and 151 gathers all the information from the GW to relay to the other side. A 152 TGREP Receiver is defined, which receives this information and after 153 certain optional operations like consolidation, aggregation etc. 154 (defined in Sections 3.10.1 and 3.10.2) hands over the reachability 155 information a to TRIP Location Server. 157 The TGREP speaker establishes a session to the TGREP Receiver using 158 the procedures similar to session establishment in TRIP. The TGREP 159 Speaker is however, in "Send only" mode and the receiver is in the 160 "Receive only" mode. After the session establishment the TGREP 161 speaker sends the reachibility informaton in the UPDATE messages. The 162 UPDATE messages have the same format as in TRIP. However, there are 163 certain attributes that are not relevant in TGREP. TGREP also defines 164 certain new attributes that find a use in a TGREP update. 166 In the rest of the document we specify attributes and address 167 families used in TGREP. We also specify the operations of 168 consolidation and aggregation as they apply to the UPDATEs received 169 from the TGREP Gateway by the TGREP Receiver. 171 A TGREP UPDATE supports the following attributes: 172 1. WithdrawnRoutes (as defined in TRIP) 173 2. ReachableRoutes (as defined in TRIP) 174 3. NexthopServer (as defined in TRIP) 175 4. TotalCircuitCapacity 176 5. AvailableCircuits 177 6. CallSuccess 178 7. Prefix 179 8. TrunkGroup 180 9. Carrier 182 3.1. TotalCircuitCapacity Attribute 184 Mandatory: False. 185 Required Flags: Not well-known. 186 Potential Flags: None. 187 TRIP Type Code: 13 (To be assigned by IANA) 189 The TotalCircuitCapacity attribute is used to reflect the 190 administratively provisioned capacity as opposed to the availability 191 at a given point in time as provided by the AvailableCircuits 192 attribute. Because of its relatively static nature, this attribute 193 MAY be propogated beyond the LS that receives it. 195 The TotalCircuitCapacity identifies the total number of PSTN circuits 196 that are available on a route to complete calls. It is used in 197 conjunction with the AvailableCircuits attribute in gateway selection 198 by the LS. The total number of calls sent to the specified route on 199 the gateway cannot exceed this total circuit capacity under steady 200 state conditions. 202 TotalCircuitCapacity is measured in integral number of calls. This is 203 not expected to change frequently. This can change, for instance, 204 when certain telephony trunks on the gateway are taken out of service 205 for maintenance purposes. 207 3.1.1. TotalCircuitCapacity Syntax 209 The TotalCircuitCapacity attribute is a 4-octet unsigned numeric 210 value. It represents the total number of circuits available for 211 terminating calls through this advertised route. This attribute 212 represents a potentially achievable upper bound on the number of 213 calls which can be terminated on this route in total. 215 3.1.2. Route Origination and TotalCircuitCapacity 217 Routes MAY be originated containing the TotalCircuitCapacity 218 attribute. 220 3.1.3. Route Selection and TotalCircuitCapacity 222 The TotalCircuitCapacity 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 destination), on a call by call basis. This can be 226 modeled as re-running the decision process on the arrival of each 227 call. The aggregation and dissemination rules for routes with this 228 attribute ensure that re-running this selection process never results 229 in propagation of a new route to other peers. 231 3.1.4. Aggregation and TotalCircuitCapacity 233 An LS MAY aggregate routes to the same prefix which contain a 234 TotalCircuitCapacity attribute. It SHOULD add the values of the 235 individual routes to determine the value for the aggregated route in 236 the same ITAD. 238 3.1.5. Route Dissemination and TotalCircuitCapacity 240 Since this attribute reflects the static capacity of the gateway's 241 circuit resources, it is not expected to change frequently. Hence the 242 LS receiving this attribute MAY disseminate it to other peers, both 243 internal and external to the ITAD. 245 3.2. AvailableCircuits Attribute 247 Mandatory: False. 248 Required Flags: Not well-known. 249 Potential Flags: None. 250 TRIP Type Code: 14. (To be assigned by IANA) 252 The AvailableCircuits attribute is used ONLY between a gateway and 253 its peer LS responsible for managing that gateway. If it is received 254 in a route, it MUST NOT be propagated unless the LS is sure that it 255 is relatively static. 257 The AvailableCircuits identifies the number of PSTN circuits that are 258 currently available on a route to complete calls. The number of 259 additional calls sent to that gateway for that route cannot exceed 260 the circuit capacity. If it does, the signaling protocol will likely 261 generate errors, and calls will be rejected. 263 AvailableCircuits is measured in integral number of calls. It is very 264 dynamic. 266 3.2.1. AvailableCircuits Syntax 268 The AvailableCircuits attribute is a 4-octet unsigned numeric value. 269 It represents the number of circuits remaining for terminating calls 270 to this route. 272 3.2.2. Route Origination and AvailableCircuits 274 Routes MAY be originated containing the AvailableCircuits attribute. 275 Since this attribute is highly dynamic, changing with every call, 276 updates MAY be sent as it changes. However, it is RECOMMENDED that a 277 gateway originating routes with this attribute use thresholds, and 278 that routes are re-originated only when the attribute moves above or 279 below a threshold. It is also RECOMMENDED that the thresholds in each 280 direction (going above a threshold and going below a threshold) be 281 different, thus achieving a form of hysterisis. Both of these 282 measures help reduce the messaging load from route origination. 284 3.2.3. Route Selection and AvailableCircuits 286 The AvailableCircuits attribute MAY be used for route selection. 287 Since one of its primary applications is load balancing, an LS will 288 wish to choose a potentially different route (amongst a set of routes 289 for the same prefix) on a call by call basis. This can be modeled as 290 re-running the decision process on the arrival of each call. The 291 aggregation and dissemination rules for routes with this attribute 292 ensure that re-running this selection process never results in 293 propagation of a new route to other peers. 295 3.2.4. Aggregation and AvailableCircuits 297 Not applicable 299 3.2.5. Route Dissemination and AvailableCircuits 301 Routes MUST NOT be disseminated with the AvailableCircuits attribute. 302 The attribute is meant to reflect capacity at the originating gateway 303 only. Its highly dynamic nature makes it inappropriate to disseminate 304 in most cases. 306 3.3. CallSuccess Attribute 308 Mandatory: False. 309 Required Flags: Not well-known. 310 Potential Flags: None. 311 TRIP Type Code: 15. (To be assigned by IANA) 313 The CallSuccess attribute is an attribute used ONLY between a gateway 314 and its peer LS responsible for managing that gateway. If it is 315 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 3.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 3.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 3.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 3.3.4. Aggregation and CallSuccess 365 Not applicable 367 3.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 3.4. Prefix Attributes 375 Mandatory: False. 376 Required Flags: Not well-known. 377 Potential Flags: None. 378 TRIP Type Codes: 16 for E164 prefix, 17 for pentadecimal prefix and 379 18 for decimal prefix (To be assigned by IANA) 381 The Prefix attribute is used to represent the list of prefixes that 382 the respective route can complete calls to. This attribute is 383 intended to be used with the Carrier or Trunkgroup address family 384 (discussed in Section 3.7). 386 Though it is possible that all prefix ranges may be reachable 387 through a given Carrier, administrative issues could make certain 388 ranges preferable to others. 390 3.4.1. Prefix Attribute Syntax 392 The Prefix attribute could be E.164, Decimal or PentaDecimal (refer 393 to TRIP RFC [4]), each of them having it's own type code. The Prefix 394 attribute is encoded as a sequence of prefix values in the attribute 395 value field. The prefixes are listed sequentially with no padding as 396 shown in Figure 2. Each prefix includes a 2-octet length field that 397 represents the length of the address field in octets. The order of 398 prefixes in the attribute is not significant. 400 The presence of Prefix Attribute with the length field of the 401 attribute as 0 signifies that the TGREP GW can terminate ALL prefixes 402 for the given Reachable route(s). 404 1 405 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 406 +-------------------------------+-----------+----------------------------------+----------- 407 | Length | Prefix1...| Length | Prefix2... 408 +-------------------------------+-----------+----------------------------------+----------- 410 Figure 2: Prefix Format 412 3.4.2. Route Origination and Prefix 414 Routes MAY be originated containing the Prefix attribute. 416 3.4.3. Route Selection and Prefix 418 The Prefix attribute MAY be used for route selection. 420 3.4.4. Aggregation and Prefix 422 Routes with differing Prefix attribute MUST NOT be aggregated. 423 Routes with the same value in the Prefix attribute MAY be aggregated 424 and the same Prefix attribute attached to the aggregated object. 426 3.4.5. Route Dissemination and Prefix 428 The LS receiving this attribute should disseminate it to other peers, 429 both internal and external to the ITAD. 431 3.5. TrunkGroup Attribute 433 Mandatory: False. 434 Required Flags: Not well-known. 435 Potential Flags: None. 436 TRIP Type Code: 20 (To be assigned by IANA) 438 The TrunkGroup attribute is used to represent the list of trunkgroups 439 on the gateway that the gateway can complete the calls to. It enables 440 providers to route calls to destinations through preferred trunks. 441 This attribute is relatively static. 443 3.5.1. TrunkGroup Syntax 445 The TrunkGroup attribute is a variable length attribute that is 446 composed of a sequence of trunkgroup length-value fields. It 447 indicates that the gateway can complete the call through any 448 trunkgroup (represented by the trunkgroup label) in the sequence. 450 Each trunkgroup is a length-value field (shown in Figure 3 below). 451 The length field is a 1-octet unsigned numeric value. The value field 452 is a variable length alphanumeric field and is also called the 453 trunkgroup label field. The length field represents the size of the 454 trunkgroup label in number of octets. The maximum length is 128 455 octets. 457 The presence of TrunkGroup attribute with the length field of the 458 attribute as 0 signifies that the TGREP GW can terminate ALL 459 trunkgroup for the given Reachable route(s). 461 0 1 462 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 ... 463 +---------------+--------------------+---------------+--------------------- 464 | Length | TrunkGroup Label1..| Length | TrunkGroup Label2.. 465 +---------------+--------------------+---------------+--------------------- 466 Figure 3: TrunkGroup Syntax 468 3.5.2. Route Origination and TrunkGroup 470 Routes MAY be originated containing the TrunkGroupattribute. 472 3.5.3. Route Selection and TrunkGroup 474 The TrunkGroup attribute MAY be used for route selection. Certain 475 trunkgroups MAY be preferred over others based on provider policy. 477 3.5.4. Aggregation and TrunkGroup 479 Routes with differing TrunkGroup attribute MUST NOT be aggregated. 480 Routes with the same value in the TrunkGroup attribute MAY be 481 aggregated and the same TrunkGroup attribute attached to the 482 aggregated object. 484 3.5.5. Route Dissemination and TrunkGroup 486 This attribute is not expected to change frequently. Hence, the LS 487 receiving this attribute MAY disseminate it to other peers, internal 488 to ITAD. Routes MUST not be disseminated external to the ITAD, with 489 TrunkGroup attribute. 491 3.6. Carrier Attribute 493 Mandatory: False. 494 Required Flags: Not well-known. 495 Potential Flags: None. 496 TRIP Type Code: 19 (To be assigned by IANA) 498 The Carrier attribute is used to represent the list of carriers that 499 the gateway can complete calls to. It enables providers to route 500 calls to destinations through preferred carriers. This attribute is 501 relatively static. 503 3.6.1. Carrier Syntax 505 The Carrier attribute is a variable length attribute that is composed 506 of a sequence of carrier values. It indicates that the route can 507 complete the call to any of the carriers represented in the sequence 508 of carrier values. 510 Each carrier value has two fields, a 2-octet CountryCode, and a 2- 511 octet CarrierIdCode. The CountryCode field represents the country 512 that corresponds to the Carrier identified by CarrierIdCode. It is 513 the same as the E.164 country code used to dial internal telephony 514 destinations. The CarrierIdCode or CIC represents a unique code 515 assigned to the Carrier or Telephony service provider offering the 516 service by an administrative body operating in that region. 518 The presence of Carrier Attribute with the length field of the 519 attribute as 0 signifies that the TGREP GW can terminate ALL Carriers 520 for the given Reachable route(s). 522 0 1 2 3 523 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 524 +--------------------------------+-------------------------------+----- 525 | CountryCode | CarrierIdCode | ... 526 +--------------------------------+-------------------------------+----- 527 Figure 4: Carrier Syntax 529 3.6.2. Route Origination and Carrier 531 Routes MAY be originated containing the Carrier attribute. 533 3.6.3. Route Selection and Carrier 535 The Carrier attribute MAY be used for route selection. Certain 536 carriers MAY be preferred over others based on provider policy. 538 3.6.4. Aggregation and Carrier 540 Routes with differing Carrier attribute MUST NOT be aggregated. 541 Routes with the same value in the Carrier attribute MAY be aggregated 542 and the same Carrier attribute attached to the aggregated object. 544 3.6.5. Route Dissemination and Carrier 546 This attribute is not expected to change frequently. Hence, the LS 547 receiving this attribute MAY disseminate it to other peers, both 548 internal and external to the ITAD. 550 3.7. TrunkGroup and Carrier Address Families 552 When a set of GWs are to managed at the granularity of carriers or 553 trunkgroups then it may be more appropriate for a GW can advertise 554 routes using the Carrier address family or trunkgroup address family 555 respectively. Also, in a TGREP association between the gateway and 556 the LS responsible for managing that gateway, there are some 557 attributes that more naturally fit in as advertised properties of 558 trunkgroups or carriers rather than that of advertised prefixes, For 559 example: the AvailableCircuit information on a particular trunkgroup 560 or a particular carrier. To express this relationship, the existing 561 TRIP address families are inadequate. We need separate address 562 families that can associate certain properties like AvailableCircuits 563 information to trunkgroups or carriers. 565 The primary benefits of this model are as follows: 567 - It allows a service provider to route calls based strictly on the 568 trunkGroups or carriers. 569 - it facilitates more accurate reporting of attributes of a dynamic 570 nature like AvailableCircuits by providing the ability to manage 571 resources at the granularity of a trunkgroup or a carrier. 572 - Gateways can get really large with the ability to provision 573 hundreds or a few thousand circuits and this can increase the 574 potential for traffic that reports dynamic resource information 575 between the gateway and the LS. The model introduced can 576 potentially alleviate this UPDATE traffic hence increasing 577 efficiency and providing a scalable gateway registration model. 579 3.7.1. Address Family Syntax 581 Consider the generic TRIP route format from TRIP[4] shown below. 583 0 1 2 3 584 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 585 +---------------+---------------+--------------+----------------+ 586 | Address Family | Application Protocol | 587 +---------------+---------------+--------------+----------------+---- 588 | Length | Address (variable) .... 589 +---------------+---------------+--------------+----------------+---- 591 Figure 5: Generic TRIP Route Format 593 The Address Family field will be used to represent the type of the 594 address associated for this family, which is based on the TrunkGroup 595 or Carrier. The codes for the new address families will be allocated 596 by IANA. 598 The Application Protocol field is same as the one for the Decimal, 599 PentaDecimal and E.164 address families defined in TRIP[4]. The 600 Length field represents the total size of the Address field in bytes. 602 The value in the Address field represents either the TrunkGroup or 603 the Carrier address families and the syntax is as follows: 605 For the TrunkGroup Address Family, the Address field is a variable 606 length alphanumeric field (trunkgroup label), where length is 607 determined by the length field of the route. The maximum value of the 608 length field for this Address Family is 128 bytes. 610 For the Carrier Address Family, the length field represents the 611 length of the Address field in bytes. The Address field is a fixed 612 length field representing Carrier value. It is encoded as a fixed 613 length 4-octet value consisting of two fields : Country code and the 614 CarrierId. 616 If a gateway supports any of these address families, it should 617 include that address family as one of the Route types supported in 618 the OPEN message capability negotiation phase. 620 The following attributes are currently defined to be used with all 621 the address families including the TrunkGroup and Carrier address 622 families. 624 - AvailableCircuits Attribute 625 - TotalCircuitCapacity Attribute 626 - CallSuccess Attribute 628 It is recommended that the above three attributes be used by the 629 gateway with the TrunkGroup or Carrier address families, if 630 possible. This will potentially offer a more efficient resource 631 reporting framework, and a scalable model for gateway 632 provisioning. 634 However, when the gateway is not using TrunkGroup or Carrier 635 address family, it MAY use the above attributes with the Decimal, 636 PentaDecimal and E.164 address families. 638 The Prefix, Carrier and TrunkGroup attributes MUST NOT be used 639 with their respective address families. 641 3.8. Other attribute considerations 643 3.8.1. Cost/Pricing attribute 645 In exploring attributes suitable for the GW-LS communications, 646 Pricing is another attribute that was considered. Though at first 647 glance, it seems like a useful piece of information to be advertised 648 by the gateway to express the price offered by carriers to different 649 destinations, in reality, the computation of pricing can get quite 650 complex. For example, the price offered by a provider can vary by 651 time of day, it can be based on an agreement between two service 652 providers interconnecting with each other, it could be based on one 653 price for the first 'n' minutes and a different price after that, 654 Least Cost routing choices and Grades of service offered by a carrier 655 can affect pricing. There could be other factors as well. Expressing 656 this complex interplay between different factors that determine 657 pricing is non-trivial to represent. It will be a subject of further 658 investigation to determine whether advertising pricing associated 659 with carriers in its simple form without any dependencies adds value 660 to be included as an attribute in the TGREP communications. 662 3.9. Gateway Operation 664 A gateway uses TRIP to advertise its reachability to its domain's 665 Location Server(s) (LS, which are closely coupled with proxies). The 666 gateway operates in TRIP Send Only mode since it is only interested 667 in advertising its reachability, but is not interested in learning 668 about the reachability of other gateways and other domains. Also, the 669 gateway will not create its own call routing database. Therefore, the 670 gateway does not need a complete implementation of TRIP. A 671 lightweight version of the protocol is sufficient. In this section we 672 describe the operation of TRIP on a gateway. 674 3.9.1. Session Establishment 676 When opening a peering session with a TGREP Receiver, a TGREP 677 gateway follows exactly the same procedures as any other TRIP speaker. 678 The TGREP gateway sends an OPEN message which includes a Send Receive 679 Capability in the Optional Parameters. The Send Receive Capability is 680 set by the gateway to Send Only. The OPEN message also contains the 681 address families supported by the gateway. The remainder of the 682 peer session establishment is identical to TRIP. 684 3.9.2. UPDATE Messages 686 Once the peer session has been established, the gateway sends UPDATE 687 messages to the TRIP LS with the gateway's entire reachability. The 688 Gateway also sends any attributes associated with the routes. 690 If the gateway's reachability changes at any point in time, the 691 gateway MUST generate UPDATE message(s) with the change. The 692 frequency of successive UPDATE messages MUST follow the same rules 693 specified for TRIP[4]. The TGREP gateway MUST support all mandatory 694 TRIP attributes. 696 If the gateway receives an UPDATE message from the TRIP LS, it MUST 697 silently discard it as specified for TRIP[4]. No further action 698 should be taken. 700 3.9.3. KEEPALIVE Messages 702 KEEPALIVE messages are periodically exchanged over the peering 703 session between the TGREP gateway and the TRIP LS as specified in 704 Section 4.4 of TRIP RFC[4]. 706 3.9.4. Error Handling and NOTIFICATION Messages 708 The same procedures used with TRIP, are used with TGREP for error 709 handling and generating NOTIFICATION messages. The only difference is 710 that a TGREP gateway will never generate a NOTIFICATION message in 711 response to an UPDATE message, irrespective of the contents of the 712 UPDATE message. Any UPDATE message is silently discarded. 714 3.9.5. TGREP Finite State Machine 716 When the TGREP finite state machine is in the Established state and 717 an UPDATE message is received, the UPDATE message is silently 718 discarded and the TGREP gateway remains in the Established state. 719 Other than that the TRIP finite state machine and the TGREP finite 720 state machine are identical. 722 3.9.6. Call Routing Databases 724 A TGREP gateway may maintain simultaneous sessions with more than one 725 TRIP LSs. A TGREP gateway maintains one call routing database per 726 peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out, 727 and hence we will call them Adj-TRIB-GWs-Out. An Adj-TRIB-GW-Out 728 contains the gateway's reachability information advertised to its 729 peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is 730 outside the scope of this draft (possibly by manual configuration). 732 The TGREP gateway does not have databases equivalent to TRIP's Adj- 733 TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn 734 routes from its peer TRIP LSs, and hence it does not run call route 735 selection. 737 3.9.7. Multiple Address Families 739 As mentioned above, TGREP supports various address families in order 740 to convey the reachibilty of telephony destinations. A TGREP session 741 MUST NOT send UPDATEs of more than one of the following catagories 742 (a) Prefix Address families (E164, Pentadecimal and decimal) (b) 743 Trunkgroup address family (c) Carrier Address family for a given 744 established session. TGREP should specify it's choice address family 745 through the route-type capability in the OPEN message. And route-type 746 specification in the OPEN message violating the above rule should be 747 rejected with a NOTIFICATION message. 749 3.9.8. Route Selection and Aggregation 751 TRIP's route selection and aggregation operations MUST NOT be 752 implemented by TGREP gateways. 754 3.10. LS/Proxy Behavior 756 As mentioned earlier, TGREP can be considered as a protocol 757 complimentary to TRIP in providing reachability information that can 758 then be further fed into the Location Server for propogation. The 759 architecture of an LS/Proxy system is as follows: There exists a TRIP 760 LS application that functions as a speaker in the I-TRIP/E-TRIP 761 network as documented in the TRIP RFC [4]. Then, there is a signaling 762 server fronting a set of gateways and receives routing information on 763 one or more TGREP sessions. This routing information from the 764 gateways is received and processed by a TGREP receiver application. 765 Subsequently, this routing information is presented as candidate 766 routes (possibly as local routes) to the TRIP LS. The interface 767 between these two applications is entirely a local matter. However, 768 before importing these routes into the TRIP LS, certain operations 769 may optionally be performed on these routes. The nature of these 770 operations and the accompanying motivation are described in the 771 subsections below. The order in which the operations are listed 772 represents an implicit logical sequence in which they are applied. 773 The architecture for an LS/Proxy entity is shown in Figure 7 below. 775 +-------------------------------------------------------+ 776 | +-------------------------------+ | 777 | | +-+ +-+ | | 778 | | |A| |C| | | +-----+ 779 | | |g| |o| | | TGREP | | 780 | +-------------+ | |g| |n| +-------------+ | | -- | GW | 781 | | | | |r| |s| | | | | -- +-----+ 782 | | TRIP | | |e| |o| | | | +-- 783 | | LS <----------|g<--|l<--- TGREP |-++-| +-----+ 784 | | | | |a| |i| | Session | | | | | 785 | | (I-TRIP/ | | |t| |d| | Mangement |-++-+-------| GW | 786 | | E-TRIP) | | |i| |a| | | | | +-----+ 787 | | | | |o| |t| | |-+ -+- 788 | +-----------/-+ | |n| |i| +-------------+ | | --- +-----+ 789 | / | | | |o| | | -- | | 790 | / | | | |n| | | | GW | 791 | / | +-+ +-+ | | +-----+ 792 | / | TGREP Receiver | | 793 | / +-------------------------------+ | 794 | / | 795 | / | 796 +-------/-----------------------------------------------+ 797 / LS/Proxy 798 / 799 / 800 / 801 / 802 / 803 +/----------------+ 804 | | 805 | | 806 | | 807 | LS | 808 | | 809 | | 810 | | 811 | | 812 | | 813 +\----------------+ 814 \ 815 \ 816 \ 817 \ 818 \ 819 \ 820 \ 821 +--------\---------------------------------------------+ 822 \ 824 | \ +-------------------------------+ | 825 | \ | +-+ +-+ | | 826 | \ | |A| |C| | | +-----+ 827 | \ | |g| |o| | | TGREP | | 828 | +------------\+ | |g| |n| +-------------+ | | -- | GW | 829 | | | | |r| |s| | | | | -- +-----+ 830 | | TRIP | | |e| |o| | | | +-- 831 | | LS <----------|g<--|l<--- TGREP |-++-| +-----+ 832 | | | | |a| |i| | Session | | | | | 833 | | (I-TRIP/ | | |t| |d| | Mangement |-++-+-------| GW | 834 | | E-TRIP) | | |i| |a| | | | | +-----+ 835 | | | | |o| |t| | |-+ -+- 836 | +-------------+ | |n| |i| +-------------+ | | --- +-----+ 837 | | | | |o| | | -- | | 838 | | | | |n| | | | GW | 839 | | +-+ +-+ | | +-----+ 840 | | TGREP Receiver | | 841 | +-------------------------------+ | 842 | | 843 | | 844 +-------------------------------------------------------+ 845 LS/Proxy 847 Figure 7: LS Architecture for TRIP-GW 849 3.10.1. Route consolidation 851 The TGREP receiver may receive routing information from one or more 852 gateways. It is possible that multiple routes are available for the 853 same destination. These different alternative routes may be received 854 from the same gateway, or from multiple gateways. It is RECOMMENDED 855 that the set of gateway routes for each destination be consolidated, 856 before presenting a candidate route, to the TRIP LS. The motivation 857 for this operation should be to define a route that can maximally 858 represent the collective routing capabilities of the set of gateways, 859 managed by this TGREP receiver. Let us take an example scenario in 860 order to bring out the motivation for this operation. Let us say, 861 the TGREP receiver maintains peering sessions with gateways A, and B. 863 o Gateway A advertises a route for destination "SIP 408" on the E.164 864 address family with the Carrier attribute value C1. 866 o Gateway B advertises a route for destination "SIP 408" on the E.164 867 address family with Carrier attribute value C2. 869 The TGREP receiver that receives these routes can consolidate these 870 constituent routes into a single route for destination "SIP 408" with 871 its Carrier attribute being a union of the the Carrier attribute 872 values of the individual routes, namely, "C1 C2". This operation is 873 refered to as Consolidation. In the above example, it is possible 874 that a route to the destination "SIP 408" through one or more 875 carriers may have been lost if the individual routes were not 876 consolidated. 878 Another example is to consolidate the Prefix attribute from multiple 879 Carrier or Trunkgroup updates received from different gateways for 880 the same destination. Let us say, there are Carrier AF updates from 881 two gateways for Carrier destination X, and the prefix attribute 882 values are {408, 650} from one update and {919, 973} from the other. 883 The prefix values from these two updates can be consolidated into a 884 single Carrier AF route advertisement with prefix value {408, 650, 885 919, 973}. 887 In general, there is a potential for loss of gateway routing 888 information, when TGREP routes from a set of gateways are not 889 consolidated, when a candidate route is presented to the TRIP LS. 890 The specifics of applying the consolidation operation to different 891 attributes and routes from different address families, is left to the 892 individual TGREP receiver implementations. 894 3.10.2. Aggregation 896 The set of gateway routes, that are in a consolidated form or 897 otherwise, may be aggregated before importing it to the LS instance 898 that is responsible for I-TRIP/E-TRIP processing. This operation 899 follows the standard aggregation procedures described in the TRIP RFC 900 [4], while adhering to the aggregation rules for each route 901 attribute. 903 4. IANA Considerations 905 - The Attribute Type Codes for the new attributes: 906 AvailableCircuits, TotalCircuitCapacity, CallSuccess, Prefix, 907 TrunkGroup and Carrier described in Sections 4.1, 4.2, 4.3, 4.4, 908 4.5 and 4.6 above, respectively, are to be assigned by IANA. 909 - The Address Family Codes for the new address families: TrunkGroup 910 and Carrier described in Section 4.7, are to be assigned by IANA. 912 5. Changes since draft-ietf-iptel-trip-gw-00.txt 914 - Changed title of the document to TGREP (Telephony Gateway 915 REgistration Protocol) 916 - Changed name of protocol described in this document to TGREP 917 - Changed Abstract and Introduction sections to position TGREP as 918 an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP) 919 - Modified the section on LS/Proxy Behavior including the diagram 920 - Added an additional example to the Route Consolidation section 921 - Changed the format of Carrier (both as an attribute and as an AF) 922 to accomodate representation of Country codes in association with 923 CICs. 924 - Updated text to allow Carrier attribute in TrunkGroup address 925 family and TrunkGroup attribute in Carrier address family. 927 6. Changes since -03 929 - Removed Carrier-Trunkgroup attribute and address family and 930 references to it. 931 - Added Terminology and Definitions section. 932 - Updated CallSuccess attribute. 933 - Added Prefix attribute. 934 - Added Carrier attribute. 935 - Added TrunkGroup attribute. 936 - Added TrunkGroup Address Family. 937 - Added Carrier Address Family. 938 - Added some more references. 940 7. Changes since -02 942 - Removed the requirements section. 943 - Discussed the motivation for introducing Carrier information into 944 TRIP. 945 - Defined a new attribute for the E.164 address family. 946 - Defined a new address family for CarrierCode-TrunkGroup 947 combination . 948 - Defined new attributes to advertise dynamic gateway 949 characteristics like resource availability, and call success 950 rate. 951 - Added as section to validate the TGREP solution against the 952 requirements in [7]. 954 8. Changes since -01 956 - Added requirements. 957 - Added more formal analysis of REGISTER and added analysis of SLP. 958 - Removed circuit capacity attribute. 960 9. Changes since -00 962 - Added text to stress the value of this proposal for managing a 963 gateway cluster. 964 - Added attributes for circuit capacity and DSP capacity. 965 - Added section on LS operation, discussing aggregation issue. 967 Authors' Addresses 969 Manjunath Bangalore 970 Cisco Systems 971 Mail Stop SJC-21/2/2 972 771 Alder Drive 973 Milpitas, CA 95035 974 email: manjax@cisco.com 976 Rajneesh Kumar 977 Cisco Systems 978 Mail Stop SJC-21/2/2 979 771 Alder Drive 980 Milpitas, CA 95035 981 email: rajneesh@cisco.com 983 Jonathan Rosenberg 984 dynamicsoft 985 72 Eagle Rock Avenue 986 First Floor 987 East Hanover, NJ 07936 988 email: jdrosen@dynamicsoft.com 990 Hussein F. Salama 991 Cisco Systems 992 Mail Stop SJC-24/3/2 993 170 W. Tasman Drive 994 San Jose, CA 95134 995 email: hsalama@cisco.com 996 Dhaval N. Shah 997 Cisco Systems 998 Mail Stop SJC-21/2/2 999 771 Alder Drive 1000 Milpitas, CA 95035 1001 email: dhaval@cisco.com 1003 Acknowledgments 1005 We wish to thank David Oran, Anirudh Sahoo, Kevin McDermott, Jon Peterson, 1006 Li Li and Bob Penfield for their insightful comments and suggestions. 1008 References 1010 [1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement 1011 Levels", BCP 14, RFC 2119, March 1997. 1013 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 1014 session initiation protocol," Request for Comments 2543, Internet 1015 Engineering Task Force, Mar. 1999. 1017 [3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service 1018 location protocol, version 2," Request for Comments 2608, Internet 1019 Engineering Task Force, June 1999. 1021 [4] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over 1022 IP (TRIP)," Request for Comments 3219, Internet Engineering Task 1023 Force, January 2002. 1025 [5] J. Rosenberg and H. Schulzrinne, "A framework for telephony 1026 routing over IP," Request for Comments 2871, Internet Engineering 1027 Task Force, June 2000. 1029 [6] International Telecommunication Union, "Packet based multimedia 1030 communication systems," Recommendation H.323, Telecommunication 1031 Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. 1033 [7] J. Rosenberg, "Requirements for Gateway Registration," Internet 1034 Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. 1036 [8] ITU-T List of ITU Carrier Codes (published periodically in the 1037 ITU-T Operational Bulletin). 1039 [9] J. Peterson, "An Architecture for Gateway Registration Based on 1040 Trunk Groups," Internet Draft, Internet Engineering Task Force, Feb. 1041 2002. Work in progress. 1043 Full Copyright Statement 1045 Copyright (C) The Internet Society (1999). All Rights Reserved. 1047 This document and translations of it may be copied and furnished to 1048 others, and derivative works that comment on or otherwise explain it 1049 or assist in its implementation may be prepared, copied, published 1050 and distributed, in whole or in part, without restriction of any 1051 kind, provided that the above copyright notice and this paragraph are 1052 included on all such copies and derivative works. However, this 1053 document itself may not be modified in any way, such as by removing 1054 the copyright notice or references to the Internet Society or other 1055 Internet organizations, except as needed for the purpose of 1056 developing Internet standards in which case the procedures for 1057 copyrights defined in the Internet Standards process must be 1058 followed, or as required to translate it into languages other than 1059 English. 1061 The limited permissions granted above are perpetual and will not be 1062 revoked by the Internet Society or its successors or assigns. 1064 This document and the information contained herein is provided on an 1065 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1066 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1067 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1068 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1069 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.