idnits 2.17.1 draft-ietf-iptel-tgrep-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1362. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 'SHOULD 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 SHOULD 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 1140 == Unused Reference: '11' is defined on line 1288, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1292, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1295, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1298, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. '3') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2402 (ref. '6') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '7') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '8') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2234 (ref. '9') (Obsoleted by RFC 4234) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 10 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-08.txt Hussein Salama, MenaNet Communications 5 January 2007 Jonathan Rosenberg, Cisco Systems 6 Expiration Date: July 2007 Dhaval Shah, Cisco Systems 8 A Telephony Gateway REgistration Protocol (TGREP) 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 11, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2007). 39 Abstract 41 This document describes the Telephony Gateway Registration Protocol 42 (TGREP) for registration of telephony prefixes supported by telephony 43 gateways and soft switches. The registration mechanism can also be 44 used to export resource information. The prefix and resource 45 information can then be passed on to a Telephony Routing over IP 46 (TRIP) Location Server, which in turn can propagate that routing 47 information within and between internet telephony administrative 48 domains (ITAD). TGREP shares a lot of similarities with the TRIP 49 Protocol. It has similar procedures and Finite State Machine for 50 session establishment. It also shares the same format for messages 51 and a subset of attributes with TRIP. 53 Table of Contents 55 1 Terminology and Definitions .............................. 4 56 2 Introduction ............................................. 4 57 3 TGREP: Overview of operation ............................. 6 58 4 TGREP Attributes ......................................... 8 59 4.1 TotalCircuitCapacity Attribute ........................... 9 60 4.2 AvailableCircuits Attribute .............................. 10 61 4.3 CallSuccess Attribute .................................... 11 62 4.4 Prefix Attributes ........................................ 13 63 4.5 TrunkGroup Attribute ..................................... 14 64 4.6 Carrier Attribute ........................................ 16 65 5 TrunkGroup and Carrier Address Families .................. 17 66 5.1 Address Family Syntax .................................... 18 67 6 Gateway Operation ........................................ 20 68 6.1 Session Establishment .................................... 20 69 6.2 UPDATE Messages .......................................... 20 70 6.3 KEEPALIVE Messages ....................................... 20 71 6.4 Error Handling and NOTIFICATION Messages ................. 20 72 6.5 TGREP Finite State Machine ............................... 21 73 6.6 Call Routing Databases ................................... 21 74 6.7 Multiple Address Families ................................ 21 75 6.8 Route Selection and Aggregation .......................... 21 76 7 LS/Proxy Behavior ........................................ 22 77 7.1 Route consolidation ...................................... 24 78 7.2 Aggregation .............................................. 25 79 7.3 Consolidation v/s Aggregation ............................ 26 80 8 Security Considerations .................................. 26 81 9 IANA Considerations ...................................... 27 82 9.1 Attribute Codes .......................................... 27 83 9.2 Address Family Codes ..................................... 27 84 10 Change history ........................................... 28 85 10.1 Changes since draft-ietf-iptel-tgrep-03.txt .............. 28 86 10.2 Changes since draft-ietf-iptel-tgrep-02.txt .............. 28 87 10.3 Changes since draft-ietf-iptel-tgrep-01.txt .............. 28 88 10.4 Changes since draft-ietf-iptel-tgrep-00.txt .............. 29 89 10.5 Changes since draft-ietf-iptel-trip-gw-00.txt ............ 29 90 10.6 Changes since -03 ........................................ 29 91 10.7 Changes since -02 ........................................ 29 92 10.8 Changes since -01 ........................................ 30 93 10.9 Changes since -00 ........................................ 30 94 11 Acknowledgments .......................................... 30 95 12 References ............................................... 30 96 12.1 Normative References ..................................... 30 97 12.2 Informative References ................................... 31 98 Authors' Addresses ....................................... 31 99 Intellectual Property Statement .......................... 33 100 Disclaimer of Validity ................................... 33 101 Copyright Statement ...................................... 33 102 Acknowledgment ........................................... 34 104 1. Terminology and Definitions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [1]. 110 Some other useful definitions are: 112 Circuit: A circuit is a discrete (specific) path between two or more 113 points along which signals can be carried. In this context, a circuit 114 is a physical path, consisting of one or more wires and possibly 115 intermediate switching points. 117 Trunk: In a network, a communication path connecting two switching 118 systems used in the establishment of an end-to-end connection. In 119 selected applications, it may have both its terminations in the same 120 switching system. 122 TrunkGroup: A set of trunks, traffic engineered as a unit, for the 123 establishment of connections within or between switching systems in 124 which all of the paths are interchangeable except where subgrouped. 126 Carrier: A company offering telephone and data communications between 127 points (end-users and/or exchanges). 129 2. Introduction 131 It is assumed that reader of this has already gone through TRIP [2]. 132 In typical VoIP networks, Internet Telephony Administrative Domains 133 (ITADs) will deploy numerous gateways for the purposes of 134 geographical diversity, capacity, and redundancy. When a call arrives 135 at the domain, it must be routed to one of those gateways. 136 Frequently, an ITAD will break their network into geographic Points 137 of Presence (POP), with each POP containing some number of gateways, 138 and a proxy server element that fronts those gateways. The Proxy 139 element is a SIP Proxy [10] or H.323 Gatekeeper. The proxy server is 140 responsible for managing the access to the POP, and also for 141 determining which of the gateways will receive any given call that 142 arrives at the POP. In conjunction with the proxy server that routes 143 the call signaling, there are two components, the "Ingress LS" 144 (a.k.a. "TGREP Receiver" and the "Egress LS". The "TGREP Receiver" 145 component maintains TGREP peering relationship with one or more 146 gateways. The routing information received from the gateways are 147 further injected into the Egress LS, which in turn disseminates into 148 the rest of the network on TRIP. 150 This configuration is depicted graphically in Figure 1. 152 Signalling TGREP 153 -------------> <---------------- 155 +---------+ 156 | | 157 | GW | 158 > +---------+ 159 // 160 // 161 SIP // +---------+ 162 <----> // | | 163 +-------------------------+ // | GW | 164 | | // +---------+ 165 | +-------------+ |/ 166 | | | | 167 | | Routing | | +---------+ TO PSTN 168 | | Proxy | | | | 169 ---> | | |-----------> | GW | -----> 170 |+---+-----+ +-----+----+ | +---------+ 171 || | | | | 172 || <+-+ | |-- 173 ||Egress LS| |Ingress LS| | --- +---------+ 174 || | | | | -- | | 175 |+---------+ +----------+ | -- | GW | 176 | | -- +---------+ 177 | | --> 178 +-------------------------+ 179 TRIP +---------+ 180 <----> | | 181 | GW | 182 +---------+ 184 Figure 1: Gateway and LS Configuration 186 The decision about which gateway to use depends on many factors, 187 including their availability, remaining call capacity and call 188 success statistics to a particular PSTN destination. For the proxy to 189 do this adequately, it needs to have access to this information in 190 real-time, as it changes. This means there must be some kind of 191 communications between the proxy and the gateways to convey this 192 information. 194 The TRIP protocol [2] is defined for carrying telephony routing 195 information between providers, for the purposes of getting a call 196 routed to the right provider for termination to the PSTN. However, 197 there is no mechanism defined in TRIP that defines how routes get 198 injected into the TRIP protocol from within the network. Nor does it 199 define mechanisms which would allow the provider to select the 200 specific gateway for terminating a call when it arrives. Those gaps 201 are filled by TGREP. 203 TGREP allows PSTN gateways or softswitches to inform a signaling 204 server, such as a SIP proxy server or H.323 gatekeeper, of routes it 205 has to the PSTN. These advertisements include fairly dynamic 206 information, such as the remaining capacity in a particular trunk, 207 which is essential for selecting the right gateway. 209 TGREP is identical in syntax and overall operation to TRIP. However, 210 it differs in the route processing rules followed by the TGREP 211 receiver, allowing for a route processing function called 212 "Consolidation". Consolidation combines multiple routes for the same 213 route destination with different attributes to a single route to 214 prevent loss of routing information. TGREP also defines a set of new 215 attributes, usable by TGREP or TRIP. Finally, TGREP only utilizes a 216 subset of overall TRIP capabilities. Specifically, certain 217 attributes are not utilized (as described below), and the TGREP 218 entities (the sender and receiver) operate in an asymmetric 219 relationship, whereas TRIP allows symmetric and asymmetric. 221 As a general rule, because of lot of similarities between TRIP and 222 TGREP, frequent reference will be made to the terminologies and 223 formats defined in TRIP [2]. It is suggested that the reader be 224 familiar with the concepts of TRIP like attributes, flags, route 225 types, address families, etc. 227 3. TGREP: Overview of operation 229 TGREP is a route registration protocol for telephony destinations on 230 a gateway. These telephony destinations could be prefixes, trunk 231 groups or Carriers. The TGREP sender resides on the GW and gathers 232 all the information from the GW to relay to the TRIP Location Server. 233 A TGREP Receiver is defined, which receives this information and 234 after certain optional operations like consolidation and aggregation, 235 hands over the reachability information a to TRIP Location Server. 236 The routing proxy also uses the information to select the gateway for 237 incoming calls. 239 "Consolidation" combines multiple routes for the same route 240 destination, whereas "Aggregation" combines routes for different 241 route destinations that qualify as candidate routes to be summarized 242 resulting in route information reduction. To take an example, if 243 there are multiple gateways offering routes to an E.164 destination 244 "408" but with possibly different attributes (Eg: Carrier), the 245 LS/Proxy can combine these to form one route for "408" but 246 representing the attribute information collectively. This process is 247 Consolidation. 249 If, for example, the LS/Proxy receives routes for 4080, 4081, 4082, 250 ... 4089 from amongst a set of gateways, it could aggregate these 251 different candidate routes to have a summarized route destination 252 "408" with each of the attributes computed using the Aggregation 253 procedures defined in the TRIP. 255 The TGREP Sender establishes a session to the TGREP Receiver using 256 the procedures similar to session establishment in TRIP. After the 257 session establishment the TGREP Sender sends the reachibility 258 information in the UPDATE messages. The UPDATE messages have the same 259 format as in TRIP. However, certain TRIP attributes are not relevant 260 in TGREP; a TGREP Receiver MAY ignore them if they are present in a 261 TGREP message. The following TRIP attributes do not apply to TGREP: 262 1. AdvertisementPath 263 2. RoutedPath 264 3. AtomicAggregate 265 4. LocalPreference 266 5. MultiExitDisc 267 6. ITADTopology 268 7. ConvertedRoute 270 In addition, TGREP defines the following new attributes in this 271 document that can be carried in a TGREP UPDATE message. 273 - TotalCircuitCapacity: This attribute identifies the total number 274 of PSTN circuits that are available on a route to complete calls. 275 - AvailableCircuits: This attribute identifies the number of PSTN 276 circuits that are currently available on a route to complete 277 calls. 278 - CallSuccess: This attribute represents information about the 279 number of normally terminated calls out of a total number of 280 attempted calls. 281 - Prefix (E164): This attribute is used to represent the list of 282 E164 prefixes that the respective route can complete calls to. 284 - Prefix (Decimal Routing Number): This attribute is used to 285 represent the list of Decimal prefixes that the respective route 286 can complete calls to. 287 - Prefix (Hexadecimal Routing Number): This attribute is used to 288 represent the list of Hexadecimal prefixes that the respective 289 route can complete calls to. 290 - TrunkGroup: This attribute enables providers to route calls to 291 destinations through preferred trunks. 292 - Carrier: This attribute enables providers to route calls to 293 destinations through preferred carriers. 295 In the rest of the document we specify attributes and address 296 families used in TGREP. The new attributes and Address families 297 introduced are also applicable for general usage in TRIP except 298 where noted (AvailableCircuits attribute for example) 300 4. TGREP Attributes 302 Due to its usage within a service provider network, TGREP makes use 303 of a subset of the attributes defined for TRIP, in addition to 304 defining several new ones. In particular, the following attributes 305 from TRIP are applicable to TGREP: 307 1. WithdrawnRoutes 2. ReachableRoutes 3. NexthopServer 4. Prefix 5. 308 Communities 310 TGREP also defines several new attributes, described in this section. 311 These are TotalCircuitCapacity, AvailableCircuits, CallSuccess, 312 TrunkGroup and Carrier. As mentioned above, these new attributes are 313 usable by TRIP unless noted otherwise. 315 A TGREP UPDATE supports the following attributes: 316 1. TotalCircuitCapacity 317 2. AvailableCircuits 318 3. CallSuccess 319 4. Prefix (E.164, Pentadecimal routing number, Decimal routing 320 number) 321 5. TrunkGroup 322 6. Carrier 324 4.1. TotalCircuitCapacity Attribute 326 Mandatory: False. 327 Required Flags: Not well-known. 328 Potential Flags: None. 329 TRIP Type Code: 13. 331 The TotalCircuitCapacity identifies the total number of PSTN circuits 332 that are available on a route to complete calls. It is used in 333 conjunction with the AvailableCircuits attribute in gateway selection 334 by the LS. The total number of calls sent to the specified route on 335 the gateway cannot exceed this total circuit capacity under steady 336 state conditions. 338 The TotalCircuitCapacity attribute is used to reflect the 339 administratively provisioned capacity as opposed to the availability 340 at a given point in time as provided by the AvailableCircuits 341 attribute. Because of its relatively static nature, this attribute 342 MAY be propagated beyond the LS that receives it. 344 TotalCircuitCapacity represents the total number of active calls at 345 any instant. This is not expected to change frequently. This can 346 change, for instance, when certain telephony trunks on the gateway 347 are taken out of service for maintenance purposes. 349 4.1.1. TotalCircuitCapacity Syntax 351 The TotalCircuitCapacity attribute is a 4-octet unsigned integer. It 352 represents the total number of circuits available for terminating 353 calls through this advertised route. This attribute represents a 354 potentially achievable upper bound on the number of calls which can 355 be terminated on this route in total. 357 4.1.2. Route Origination and TotalCircuitCapacity 359 Routes MAY be originated containing the TotalCircuitCapacity 360 attribute. 362 4.1.3. Route Selection and TotalCircuitCapacity 364 The TotalCircuitCapacity attribute MAY be used for route selection. 365 Since one of its primary applications is load balancing, an LS will 366 wish to choose a potentially different route (amongst a set of routes 367 for the same destination), on a call by call basis. This can be 368 modeled as re-running the decision process on the arrival of each 369 call. The aggregation and dissemination rules for routes with this 370 attribute ensure that re-running this selection process never results 371 in propagation of a new route to other peers. 373 4.1.4. Aggregation and TotalCircuitCapacity 375 An LS MAY aggregate routes to the same prefix which contain a 376 TotalCircuitCapacity attribute. It SHOULD add the values of the 377 individual routes to determine the value for the aggregated route in 378 the same ITAD. 380 4.1.5. Route Dissemination and TotalCircuitCapacity 382 Since this attribute reflects the static capacity of the gateway's 383 circuit resources, it is not expected to change frequently. Hence the 384 LS receiving this attribute MAY disseminate it to other peers, both 385 internal and external to the ITAD. 387 4.2. AvailableCircuits Attribute 389 Mandatory: False. 390 Required Flags: Not well-known. 391 Potential Flags: None. 392 TRIP Type Code: 14. 394 The AvailableCircuits identifies the number of PSTN circuits that are 395 currently available on a route to complete calls. The number of 396 additional calls sent to that gateway for that route cannot exceed 397 the circuit capacity. If it does, the signaling protocol will likely 398 generate errors, and calls will be rejected. 400 The AvailableCircuits attribute is used ONLY between a gateway and 401 its peer LS responsible for managing that gateway. If it is received 402 in a route, it is not propagated. 404 4.2.1. AvailableCircuits Syntax 406 The AvailableCircuits attribute is a 4-octet unsigned integer. It 407 represents the number of circuits remaining for terminating calls to 408 this route. 410 4.2.2. Route Origination and AvailableCircuits 412 Routes MAY be originated containing the AvailableCircuits attribute. 413 Since this attribute is highly dynamic, changing with every call, 414 updates MAY be sent as it changes. However, it is RECOMMENDED that 415 measures be taken to help reduce the messaging load from route 416 origination. It is further RECOMMENDED that a sufficiently large 417 window of time be used to provide a useful aggregated statistic. 419 4.2.3. Route Selection and AvailableCircuits 421 The AvailableCircuits attribute MAY be used for route selection. 422 Since one of its primary applications is load balancing, an LS will 423 wish to choose a potentially different route (amongst a set of routes 424 for the same prefix) on a call by call basis. This can be modeled as 425 re-running the decision process on the arrival of each call. The 426 aggregation and dissemination rules for routes with this attribute 427 ensure that re-running this selection process never results in 428 propagation of a new route to other peers. 430 4.2.4. Aggregation and AvailableCircuits 432 Not applicable 434 4.2.5. Route Dissemination and AvailableCircuits 436 Routes MUST NOT be disseminated with the AvailableCircuits attribute. 437 The attribute is meant to reflect capacity at the originating gateway 438 only. Its highly dynamic nature makes it inappropriate to disseminate 439 in most cases. 441 4.3. CallSuccess Attribute 443 Mandatory: False. 444 Required Flags: Not well-known. 445 Potential Flags: None. 446 TRIP Type Code: 15. 448 The CallSuccess attribute is an attribute used ONLY between a gateway 449 and its peer LS responsible for managing that gateway. If it is 450 received in a route, it is not propagated. 452 The CallSuccess attribute provides information about the number of 453 normally terminated calls out of a total number of attempted calls. 455 CallSuccess is to be determined by the gateway based on the 456 Disconnect cause code at call termination. For example, a call that 457 reaches the Alerting stage but does not get connected due to the 458 unavailability of the called party, or the called party being busy, 459 is conventionally considered a successful call. On the other hand, a 460 call that gets disconnected because of a Circuit or Resource being 461 unavailable is conventionally considered a failed call. The exact 462 mapping of disconnect causes to CallSuccess is at the discretion of 463 the gateway reporting the attribute. 465 The CallSuccess attribute is used by the LS to keep track of failures 466 in reaching certain telephony destinations through a gateway(s) and 467 use that information in the gateway selection process to enhance the 468 probability of successful call termination. 470 This information can be used by the LS to consider alternative 471 gateways to terminate calls to those destinations with a better 472 likelihood of success. 474 4.3.1. CallSuccess Syntax 476 The CallSuccess attribute is comprised of two component fields - each 477 represented as an unsigned 4-octet unsigned integer. The first 478 component field represents the total number of calls terminated 479 successfully for the advertised destination on a given address family 480 over a given window of time. The second component field represents 481 the total number of attempted calls for the advertised destination 482 within the same window of time. 484 4.3.2. Route Origination and CallSuccess 486 Routes MAY be originated containing the CallSuccess attribute. This 487 attribute is expected to get statistically significant with passage 488 of time as more calls are attempted. It is RECOMMENDED that 489 sufficiently large windows be used to provide a useful aggregated 490 statistic. 492 4.3.3. Route Selection and CallSuccess 494 The CallSuccess attribute MAY be used for route selection. This 495 attribute represents a measure of success of terminating calls to the 496 advertised destination(s). This information MAY be used to select 497 from amongst a set of alternative routes to increase the probability 498 of successful call termination. 500 4.3.4. Aggregation and CallSuccess 502 Not applicable 504 4.3.5. Route Dissemination and CallSuccess 506 Routes MUST NOT be disseminated with the CallSuccess attribute. Its 507 potential to change dynamically does not make it suitable to 508 disseminate. 510 4.4. Prefix Attributes 512 Mandatory: False. 513 Required Flags: Not well-known. 514 Potential Flags: None. 515 TRIP Type Codes: 16 for E164 prefix, 17 for Pentadecimal routing 516 number prefix and 18 for Decimal routing number prefix. 518 The Prefix attribute is used to represent the list of prefixes that 519 the respective route can complete calls to. This attribute is 520 intended to be used with the Carrier or Trunkgroup address family 521 (discussed in Section 3.7). 523 Though it is possible that all prefix ranges may be reachable through 524 a given Carrier, administrative issues could make certain ranges 525 preferable to others. 527 4.4.1. Prefix Attribute Syntax 529 The Prefix attribute could be E.164, Decimal or PentaDecimal (refer 530 to TRIP [2]), each of them having it's own type code. The Prefix 531 attribute is encoded as a sequence of prefix values in the attribute 532 value field. The prefixes are listed sequentially with no padding as 533 shown in Figure 2. Each prefix includes a 2-octet length field that 534 represents the length of the address field in octets. The order of 535 prefixes in the attribute is not significant. 537 The presence of Prefix Attribute with the length field of the 538 attribute as 0 signifies that the TGREP GW can terminate ALL prefixes 539 of that prefix type (E.164, Decimal or Pentadecimal) for the given 540 Reachable route(s). This is not equivalent to excluding the Prefix 541 attribute in the TGREP update. 543 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 . . . 3456789012345678|0123... 544 +-------------------------------+-----------+------------------------ 545 | Length | Prefix1...| Length |Prefix2 546 +-------------------------------+-----------+------------------------ 548 Figure 2: Prefix Format 550 4.4.2. Route Origination and Prefix 552 Routes MAY be originated containing the Prefix attribute. 554 4.4.3. Route Selection and Prefix 556 The Prefix attribute MAY be used for route selection. 558 4.4.4. Aggregation and Prefix 560 Routes with differing Prefix attribute MUST NOT be aggregated. 561 Routes with the same value in the Prefix attribute MAY be aggregated 562 and the same Prefix attribute attached to the aggregated object. 564 4.4.5. Route Dissemination and Prefix 566 The LS receiving this attribute should disseminate to other peers, 567 both internal and external to the ITAD. 569 4.5. TrunkGroup Attribute 571 Mandatory: False. 572 Required Flags: Not well-known. 573 Potential Flags: None. 574 TRIP Type Code: 20. 576 The TrunkGroup attribute is used to represent the list of trunkgroups 577 on the gateway used to complete calls. It enables providers to route 578 calls to destinations through preferred trunks. This attribute is 579 relatively static. 581 4.5.1. TrunkGroup Syntax 583 The TrunkGroup attribute is a variable length attribute that is 584 composed of a sequence of trunkgroup identifiers. It indicates that 585 the gateway can complete the call through any trunkgroup identifier 586 indicated in the sequence. 588 Each trunkgroup identifier is encoded as a length-value field (shown 589 in Figure 3 below). The length field is a 1-octet unsigned numeric 590 value. The value field is a variable length field consisting of two 591 sub-fields, a trunk group label followed by a trunk context, the two 592 sub-fields separated by the delimiter ";" (semicolon). Both the trunk 593 group label and the trunk context sub-fields are of variable length. 594 The length field represents the total size of the value field 595 including the delimiter. 597 The permissible character set for the trunk group label and the trunk 598 group context sub-fields and the associated ABNF [9] is per rules 599 outlined in [4]. 601 The presence of TrunkGroup attribute with the length field of the 602 attribute as 0 signifies that the TGREP GW can terminate ALL 603 trunkgroup for the given Reachable route(s). 605 0 1 606 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 ... 607 +---------------+--------------------+---------------+--------------- 608 | Length | TrunkGroup 1... | Length |TrunkGroup 2... 609 +---------------+--------------------+---------------+--------------- 610 Figure 3: TrunkGroup Syntax 612 4.5.2. Route Origination and TrunkGroup 614 Routes MAY be originated containing the TrunkGroupattribute. 616 4.5.3. Route Selection and TrunkGroup 618 The TrunkGroup attribute MAY be used for route selection. Certain 619 trunkgroups MAY be preferred over others based on provider policy. 621 4.5.4. Aggregation and TrunkGroup 623 Routes with differing TrunkGroup attribute MUST NOT be aggregated. 624 Routes with the same value in the TrunkGroup attribute MAY be 625 aggregated and the same TrunkGroup attribute attached to the 626 aggregated object. 628 4.5.5. Route Dissemination and TrunkGroup 630 This attribute is not expected to change frequently. Hence, the LS 631 receiving this attribute MAY disseminate it to other peers, internal 632 to ITAD. Routes SHOULD not be disseminated external to the ITAD, with 633 TrunkGroup attribute. 635 4.6. Carrier Attribute 637 Mandatory: False. 638 Required Flags: Not well-known. 639 Potential Flags: None. 640 TRIP Type Code: 19. 642 The Carrier attribute is used to represent the list of carriers that 643 the gateway uses to complete calls. It enables providers to route 644 calls to destinations through preferred carriers. This attribute is 645 relatively static. 647 4.6.1. Carrier Syntax 649 The Carrier attribute is a variable length attribute that is composed 650 of a sequence of carrier identifiers. It indicates that the route 651 can complete the call to any of the carriers represented in the 652 sequence of carrier identifiers. 654 Each carrier identifier is encoded as a length-value field (shown in 655 Figure 4 below). The length field is a 1-octet unsigned numeric 656 value. The value field is a variable length field. 658 The permissible character set for the value field and the associated 659 ABNF [9] is per rules outlined in [5]. Specifically, it carries 660 "global-cic" or "local-cic" [5]. In case of "local-cic", the 661 "phonedigit-hex" part and the "cic-context" part would be separated 662 by the delimiter ";". Hence, absence or presence of the delimiter can 663 be used to determine if the value is a "global-cic" or a "local-cic". 664 The length field represents the total size of the value field 665 including the delimiter. 667 The presence of Carrier Attribute with the length field of the 668 attribute as 0 signifies that the TGREP GW can terminate ALL Carriers 669 for the given Reachable route(s). 671 0 1 672 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 ... 673 +---------------+--------------------+---------------+-------------- 674 | Length | Carrier 1... | Length | Carrier 2... 675 +---------------+--------------------+---------------+-------------- 676 Figure 4: Carrier Syntax 678 4.6.2. Route Origination and Carrier 680 Routes MAY be originated containing the Carrier attribute. 682 4.6.3. Route Selection and Carrier 684 The Carrier attribute MAY be used for route selection. Certain 685 carriers MAY be preferred over others based on provider policy. 687 4.6.4. Aggregation and Carrier 689 Routes with differing Carrier attribute MUST NOT be aggregated. 690 Routes with the same value in the Carrier attribute MAY be aggregated 691 and the same Carrier attribute attached to the aggregated object. 693 4.6.5. Route Dissemination and Carrier 695 This attribute is not expected to change frequently. Hence, the LS 696 receiving this attribute MAY disseminate it to other peers, both 697 internal and external to the ITAD. 699 5. TrunkGroup and Carrier Address Families 701 As described in TRIP [2], the address family field gives the type of 702 address for the route. Two new address families and their codes are 703 defined in this Section: 705 Code Address Family 706 4 TrunkGroup 707 5 Carrier 709 When a set of GWs are to be managed at the granularity of carriers or 710 trunkgroups then it may be more appropriate for a GW to advertise 711 routes using the Carrier address family or trunkgroup address family 712 respectively. Also, in a TGREP association between the gateway and 713 the LS responsible for managing that gateway, there are some 714 attributes that more naturally fit in as advertised properties of 715 trunkgroups or carriers rather than that of advertised prefixes; for 716 example, the AvailableCircuit information on a particular trunkgroup 717 or a particular carrier. To express this relationship, the existing 718 TRIP address families are inadequate. We need separate address 719 families that can associate certain properties like AvailableCircuits 720 information to trunkgroups or carriers. 722 The primary benefits of this model are as follows: 724 - It allows a service provider to route calls based strictly on the 725 trunkGroups or carriers. 726 - it facilitates more accurate reporting of attributes of a dynamic 727 nature like AvailableCircuits by providing the ability to manage 728 resources at the granularity of a trunkgroup or a carrier. 729 - Gateways can get really large with the ability to provision 730 hundreds or a few thousand circuits and this can increase the 731 potential for traffic that reports dynamic resource information 732 between the gateway and the LS. The model introduced can 733 potentially alleviate this UPDATE traffic hence increasing 734 efficiency and providing a scalable gateway registration model. 736 5.1. Address Family Syntax 738 Consider the generic TRIP route format from TRIP[2] shown below. 740 0 1 2 3 741 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 742 +---------------+---------------+--------------+----------------+ 743 | Address Family | Application Protocol | 744 +---------------+---------------+--------------+----------------+ 745 | Length | Address (variable) ... 746 +---------------+---------------+--------------+----------------+ 748 Figure 5: Generic TRIP Route Format 750 The Address Family field will be used to represent the type of the 751 address associated for this family, which is based on the TrunkGroup 752 or Carrier. The codes for the new address families will be allocated 753 by IANA. 755 The code for the trunk group address family is 4 and the code for the 756 carrier address family is 5. 758 The Application Protocol field is same as the one for the Decimal, 759 PentaDecimal and E.164 address families defined in TRIP[2]. The 760 Length field represents the total size of the Address field in bytes. 762 The value in the Address field represents either the TrunkGroup or 763 the Carrier address families and the syntax is as follows: 765 For the TrunkGroup Address Family, the Address field represents a 766 Trunkgroup value that is defined as specified in an earlier Section 767 4.5.1 about the TrunkGroup Attribute. 769 For the Carrier Address Family, the Address field represents a 770 Carrier value. This is same as the value field specified in an 771 earlier Section 4.6.1 about the Carrier Attribute. 773 The above mentioned address families are not heirarchical, but flat. 774 If a gateway supports any of these address families, it should 775 include that address family as one of the Route types supported in 776 the OPEN message capability negotiation phase. 778 The following attributes are currently defined to be used with all 779 the address families including the TrunkGroup and Carrier address 780 families. 782 - AvailableCircuits Attribute 783 - TotalCircuitCapacity Attribute 784 - CallSuccess Attribute 786 It is recommended that the above three attributes be used by the 787 gateway with the TrunkGroup or Carrier address families, if possible. 788 This will potentially offer a more efficient resource reporting 789 framework, and a scalable model for gateway provisioning. 791 However, when the gateway is not using TrunkGroup or Carrier address 792 family, it MAY use the above attributes with the Decimal, 793 PentaDecimal and E.164 address families. 795 The prefix attribute cannot be used when the address family is E164 796 numbers, Pentadecimal routing numbers or Decimal routing numbers. 798 The Carrier attribute cannot be used if the address family type is 799 Carrier. 801 The TrunkGroup attribute cannot be used if the address family type is 802 TrunkGroup. 804 6. Gateway Operation 806 A gateway uses TGREP to advertise its reachability to its domain's 807 Location Server(s) (LS, which are closely coupled with proxies). The 808 gateway operates in TRIP Send Only mode since it is only interested 809 in advertising its reachability, but is not interested in learning 810 about the reachability of other gateways and other domains. Also, the 811 gateway will not create its own call routing database. In this 812 section we describe the operation of TGREP on a gateway. 814 6.1. Session Establishment 816 When opening a peering session with a TGREP Receiver, a TGREP gateway 817 follows exactly the same procedures as any other TRIP entity. The 818 TGREP gateway sends an OPEN message which includes a Send Receive 819 Capability in the Optional Parameters. The Send Receive Capability is 820 set by the gateway to Send Only. The OPEN message also contains the 821 address families supported by the gateway. The remainder of the peer 822 session establishment is identical to TRIP. 824 6.2. UPDATE Messages 826 Once the peer session has been established, the gateway sends UPDATE 827 messages to the TRIP LS with the gateway's entire reachability. The 828 Gateway also sends any attributes associated with the routes. 830 TGREP processing of the UPDATE message at the gateway is identical to 831 UPDATE processing in TRIP[2]. A TGREP sender MUST support all 832 mandatory TRIP attributes. 834 6.3. KEEPALIVE Messages 836 KEEPALIVE messages are periodically exchanged over the peering 837 session between the TGREP gateway and the TRIP LS as specified in 838 Section 4.4 of TRIP [2]. 840 6.4. Error Handling and NOTIFICATION Messages 842 The same procedures used with TRIP, are used with TGREP for error 843 handling and generating NOTIFICATION messages. The only difference is 844 that a TGREP gateway will never generate a NOTIFICATION message in 845 response to an UPDATE message, irrespective of the contents of the 846 UPDATE message. Any UPDATE message is silently discarded. 848 6.5. TGREP Finite State Machine 850 When the TGREP finite state machine is in the Established state and 851 an UPDATE message is received, the UPDATE message is silently 852 discarded and the TGREP gateway remains in the Established state. 853 Other than that the TRIP finite state machine and the TGREP finite 854 state machine are identical. 856 6.6. Call Routing Databases 858 A TGREP gateway may maintain simultaneous sessions with more than one 859 TRIP LSs. A TGREP gateway maintains one call routing database per 860 peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out, 861 and hence we will call them Adj-TRIB-GWs-Out. An Adj-TRIB-GW-Out 862 contains the gateway's reachability information advertised to its 863 peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is 864 outside the scope of this draft (possibly by manual configuration). 866 The TGREP gateway does not have databases equivalent to TRIP's Adj- 867 TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn 868 routes from its peer TRIP LSs, and hence it does not run call route 869 selection. 871 6.7. Multiple Address Families 873 As mentioned above, TGREP supports various address families in order 874 to convey the reachabilty of telephony destinations. A TGREP session 875 MUST NOT send UPDATEs of more than one of the following categories 876 (a) Prefix Address families (E164, Pentadecimal and decimal) (b) 877 Trunkgroup address family (c) Carrier Address family for a given 878 established session. TGREP should specify it's choice address family 879 through the route-type capability in the OPEN message. And route-type 880 specification in the OPEN message violating the above rule should be 881 rejected with a NOTIFICATION message. 883 6.8. Route Selection and Aggregation 885 TRIP's route selection and aggregation operations MUST NOT be 886 implemented by TGREP gateways. 888 7. LS/Proxy Behavior 890 As mentioned earlier, TGREP can be considered as a protocol 891 complimentary to TRIP in providing reachability information that can 892 then be further fed into the Location Server. The architecture of an 893 LS/Proxy system is as follows: There exists a TRIP LS application 894 that functions as a speaker in the I-TRIP/E-TRIP network as 895 documented in TRIP [2]. This component is termed as "LS-Egress" for 896 the purposes of this discussion. Then, there is a signaling server 897 fronting a set of gateways. In conjunction with this signaling 898 server, is also a second component operating in receive mode, that 899 peers with one more gateways, each of them using TGREP to advertise 900 routing information. This component on the receiving end of one or 901 more TGREP sessions is termed as the "LS-Ingress" or "TGREP Receiver" 902 for the purposes of this discussion. Also, the entity (typically, a 903 Gateway) advertising the routes on the TGREP session is termed as the 904 "TGREP Sender". The "TGREP Receiver" receiving the TRIP messages 905 takes the resulting routing information from each gateway, and 906 "exports" it to another process we define below, that performs 907 consolidation and aggregation, in that order. These operations would 908 take as input the collective set of routes from all the gateways. 909 Subsequently, the resulting TRIB is passed as input into the LS- 910 Egress process as shown below, that can then disseminate these via 911 TRIP. The interface between the TGREP Receiver(aka. LS-Ingress) 912 peering with the GW(s) and the TRIP LS (LS-Egress) is entirely a 913 local matter. 915 The nature of the Consolidation and Aggregation operations and the 916 accompanying motivation are described in the subsections below. The 917 order in which the operations are listed represents an implicit 918 logical sequence in which they are applied. The architecture for an 919 LS/Proxy entity is shown in Figure 7 below. 921 +-------------------------------------------------------+ 922 | +-------------------------------+ | 923 | | +-+ +-+ | | TGREP 924 | | |A| |C| | | +-----+ 925 | | |g| |o| | | | | 926 | +-------------+ | |g| |n| +-------------+ | | --| GW | 927 | | | | |r| |s| | | | | +-----+ 928 | | TRIP | | |e| |o| | | | +--- 929 | | LS <----------|g<--|l<--- TGREP |-++-| +-----+ 930 | | | | |a| |i| | Session | | | | | 931 | | (I-TRIP/ | | |t| |d| | Management |-++-+----| GW | 932 | | E-TRIP) | | |i| |a| | | | | +-----+ 933 | | (LS-Egress) | | |o| |t| | |-+ +--- 934 | +-----------/-+ | |n| |i| +-------------+ | | +-----+ 935 | / | | | |o| | | --| | 936 | / | | | |n| (LS-Ingress) | | | GW | 937 | / | +-+ +-+ | | +-----+ 938 | / | TGREP Receiver | | 939 | / +-------------------------------+ | 940 | / | 941 | / | 942 +-------/-----------------------------------------------+ 943 / LS/Proxy 944 / 945 / 946 / 947 / 948 / 949 +/----------------+ 950 | | 951 | | 952 | | 953 | LS | 954 | | 955 | | 956 | | 957 | | 958 | | 959 +----------------+ 960 +-------------------------------------------------------+ 961 | +-------------------------------+ | 962 | | +-+ +-+ | | TGREP 963 | | |A| |C| | | +-----+ 964 | | |g| |o| | | | | 965 | +-------------+ | |g| |n| +-------------+ | | --| GW | 966 | | | | |r| |s| | | | | +-----+ 967 | | TRIP | | |e| |o| | | | +--- 968 | | LS <----------|g<--|l<--- TGREP |-++-| +-----+ 969 | | | | |a| |i| | Session | | | | | 970 | | (I-TRIP/ | | |t| |d| | Management |-++-+----| GW | 971 | | E-TRIP) | | |i| |a| | | | | +-----+ 972 | | (LS-Egress) | | |o| |t| | |-+ +--- 973 | +-------------+ | |n| |i| +-------------+ | | +-----+ 974 | | | | |o| | | --| | 975 | | | | |n| (LS-Ingress) | | | GW | 976 | | +-+ +-+ | | +-----+ 977 | | TGREP Receiver | | 978 | +-------------------------------+ | 979 | | 980 | | 981 +-------------------------------------------------------+ 982 LS/Proxy 984 Figure 7: LS Architecture for TRIP-GW 986 7.1. Route consolidation 988 The TGREP receiver (LS-Ingress) may receive routing information from 989 one or more gateways. It is possible that multiple routes are 990 available for the same destination. These different alternative 991 routes may be received from the same gateway, or from multiple 992 gateways. It is RECOMMENDED that the set of gateway routes for each 993 destination be consolidated, before presenting a candidate route, to 994 the LS-Egress entity. The motivation for this operation should be to 995 define a route that can maximally represent the collective routing 996 capabilities of the set of gateways, managed by this TGREP receiver. 997 Let us take an example scenario in order to bring out the motivation 998 for this operation. Let us say, the TGREP receiver maintains peering 999 sessions with gateways A, and B. 1001 - Gateway A advertises a route for destination "SIP 408" on the 1002 E.164 address family with the Carrier attribute value C1. 1004 - Gateway B advertises a route for destination "SIP 408" on the 1005 E.164 address family with Carrier attribute value C2. 1007 The TGREP receiver that receives these routes can consolidate 1008 these constituent routes into a single route for destination "SIP 1009 408" with its Carrier attribute being a union of the the Carrier 1010 attribute values of the individual routes, namely, "C1 C2". This 1011 operation is referred to as Consolidation. In the above example, 1012 it is possible that a route to the destination "SIP 408" through 1013 one or more carriers may have been lost if the individual routes 1014 were not consolidated. 1016 Another example is to consolidate the Prefix attribute from 1017 multiple Carrier or Trunkgroup updates received from different 1018 gateways for the same destination. Let us say, there are Carrier 1019 AF updates from two gateways for Carrier destination X, and the 1020 prefix attribute values are {408, 650} from one update and {919, 1021 973} from the other. The prefix values from these two updates can 1022 be consolidated into a single Carrier AF route advertisement with 1023 prefix value {408, 650, 919, 973}. 1025 In general, there is a potential for loss of gateway routing 1026 information, when TGREP routes from a set of gateways are not 1027 consolidated, when a candidate route is presented to the TRIP LS. 1028 The specifics of applying the consolidation operation to 1029 different attributes and routes from different address families, 1030 is left to the individual TGREP receiver implementations. 1032 7.2. Aggregation 1034 The set of gateway routes, that are in a consolidated form or 1035 otherwise, may be aggregated before importing it to the LS instance 1036 that is responsible for I-TRIP/E-TRIP processing (LS-Egress). This 1037 operation follows the standard aggregation procedures described in 1038 the TRIP [2], while adhering to the aggregation rules for each route 1039 attribute. 1041 7.3. Consolidation v/s Aggregation 1043 To highlight the difference between the two operations discussed 1044 above, "Consolidation" combines multiple routes for the same route 1045 destination, whereas "Aggregation" combines routes for different 1046 route destinations that qualify as candidates to be summarized 1047 resulting in route information reduction. 1049 To take an example, if there are multiple gateways offering routes to 1050 an E.164 destination "408" but with possibly different attributes 1051 (Eg: Carrier), the LS/Proxy can combine these to form one route for 1052 "408" but representing the attribute information collectively. This 1053 process is Consolidation. 1055 If, for example, the LS/Proxy receives routes for 4080, 4081, 4082, 1056 ... 4089 from amongst a set of gateways, it could aggregate these 1057 different candidate routes to have a summarized route destination 1058 "408" with each of the attributes computed using the Aggregation 1059 procedures defined in the TRIP. 1061 8. Security Considerations 1063 The Security considerations for TGREP are identical to that 1064 identified in TRIP [2] and are just restated here for the purposes of 1065 clarity. 1067 The security mechanism for the peering session between TGREP GW and a 1068 TRIP LS, in an IP network, is IPsec [3]. IPsec uses two protocols to 1069 provide traffic security: Authentication Header (AH) [6] and 1070 Encapsulating Security Payload (ESP) [7]. 1072 The AH header affords data origin authentication, connectionless 1073 integrity and optional anti-replay protection of messages passed 1074 between the peer LSs. The ESP header provides origin authentication, 1075 connectionless integrity, anti-replay protection, and confidentiality 1076 of messages. 1078 Implementations of the protocol defined in this document employing 1079 the ESP header SHALL comply with section 5 of [7], which defines a 1080 minimum set of algorithms for integrity checking and encryption. 1081 Similarly, implementations employing the AH header SHALL comply with 1082 section 5 of [6], which defines a minimum set of algorithms for 1083 integrity checking using manual keys. 1085 Implementations SHOULD use IKE [8] to permit more robust keying 1086 options. Implementations employing IKE SHOULD support authentication 1087 with RSA signatures and RSA public key encryption. 1089 A Security Association (SA) [3] is a simplex "connection" that 1090 affords security services to the traffic carried by it. Security 1091 services are afforded to a SA by the use of AH, or ESP, but not both. 1092 Two types of SAs are defined: transport mode and tunnel mode. A 1093 transport mode SA is a security association between two hosts, and is 1094 appropriate for protecting the TRIP session between two peer LSs. 1096 9. IANA Considerations 1098 Both TRIP[2] and TGREP share the same IANA registry for Capabilities, 1099 Attributes, Address Families, and Application Protocols. This 1100 specification requests that IANA add the following attribute codes 1101 and address family codes to the TRIP [2] registries. 1103 9.1. Attribute Codes 1105 The Attribute Type Codes to be assigned for the new attributes 1106 defined in this document are listed below: 1108 | Code Attribute Reference 1109 | ---- --------- --------- 1110 | 13 TotalCircuitCapacity [RFCXXXX] 1111 | 14 AvailableCircuits [RFCXXXX] 1112 | 15 CallSuccess [RFCXXXX] 1113 | 16 E.164 Prefix [RFCXXXX] 1114 | 17 Pentadecimal Routing Number Prefix [RFCXXXX] 1115 | 18 Decimal Routing Number Prefix [RFCXXXX] 1116 | 19 TrunkGroup [RFCXXXX] 1117 | 19 Carrier [RFCXXXX] 1119 [NOTE TO RFC-ED: please replace XXXX with the rfc number of this 1120 specification ] 1122 9.2. Address Family Codes 1124 The following subsections show the codes to be assigned for the two 1125 new address families introduced in this document 1127 9.2.1. TrunkGroup Address Family 1129 | Code Address Family Reference 1130 | ---- -------------- --------- 1131 | 4 TrunkGroup [RFCXXXX] 1133 [NOTE TO RFC-ED: please replace XXXX with the rfc number of this 1134 specification ] 1136 9.2.2. Carrier Address Family 1138 | Code Address Family Reference 1139 | ---- -------------- --------- 1140 | 5 Carrier [RFCXXXX] 1142 [NOTE TO RFC-ED: please replace XXXX with the rfc number of this 1143 specification ] 1145 10. Change history 1147 [[NOTE TO RFC-ED: Please remove this section prior to publication]] 1149 10.1. Changes since draft-ietf-iptel-tgrep-03.txt 1151 - No change in content. Releasing a new revision for renewal of 1152 draft. 1154 10.2. Changes since draft-ietf-iptel-tgrep-02.txt 1156 - No change in content. Releasing a new revision for renewal of 1157 draft. 1159 10.3. Changes since draft-ietf-iptel-tgrep-01.txt 1161 - Added a "Security Considerations" Section to the document. 1162 - Strengthened the text under "LS/Proxy Behavior" regarding 1163 Consolidation and Aggregation with additional examples for better 1164 clarity. 1165 - Removed the section "Other Attributes" including its subsection 1166 on the "Pricing" attribute. 1167 - Modified the definition of Carrier in the "Carrier attribute" and 1168 "TrunkGroup and Carrier Address Families" sections respectively. 1169 - Rectified the section number references in the "IANA 1170 Considerations" Section. 1171 - Strengthened the text in the attribute sections regarding 1172 dissemination of attributes received on TGREP. 1173 - Updated the "References" section. 1174 - Corrected typos, nits, grammatical errors, and language of the 1175 text throughout the document based on feedback from the iptel 1176 community. 1178 10.4. Changes since draft-ietf-iptel-tgrep-00.txt 1180 - Added recommendations for AvailableCircuits and CallSuccess 1181 attributes. 1182 - Updated Carrier Attribute with ASCII syntax. 1183 - Removed thresholding scheme description. 1184 - Updated author addresses. 1186 10.5. Changes since draft-ietf-iptel-trip-gw-00.txt 1188 - Changed title of the document to TGREP (Telephony Gateway 1189 REgistration Protocol). 1190 - Changed name of protocol described in this document to TGREP. 1191 - Changed Abstract and Introduction sections to position TGREP as 1192 an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP). 1193 - Modified the section on LS/Proxy Behavior including the diagram. 1194 - Added an additional example to the Route Consolidation section. 1195 - Changed the format of Carrier (both as an attribute and as an AF) 1196 to accommodate representation of Country codes in association 1197 with CICs. 1198 - Updated text to allow Carrier attribute in TrunkGroup address 1199 family and TrunkGroup attribute in Carrier address family. 1201 10.6. Changes since -03 1203 - Removed Carrier-Trunkgroup attribute and address family and 1204 references to it. 1205 - Added Terminology and Definitions section. 1206 - Updated CallSuccess attribute. 1207 - Added Prefix attribute. 1208 - Added Carrier attribute. 1209 - Added TrunkGroup attribute. 1210 - Added TrunkGroup Address Family. 1211 - Added Carrier Address Family. 1212 - Added some more references. 1214 10.7. Changes since -02 1216 - Removed the requirements section. 1217 - Discussed the motivation for introducing Carrier information into 1218 TRIP. 1219 - Defined a new attribute for the E.164 address family. 1221 - Defined a new address family for CarrierCode-TrunkGroup 1222 combination . 1223 - Defined new attributes to advertise dynamic gateway 1224 characteristics like resource availability, and call success 1225 rate. 1226 - Added as section to validate the TGREP solution against the 1227 requirements in [6]. 1229 10.8. Changes since -01 1231 - Added requirements. 1232 - Added more formal analysis of REGISTER and added analysis of SLP. 1233 - Removed circuit capacity attribute. 1235 10.9. Changes since -00 1237 - Added text to stress the value of this proposal for managing a 1238 gateway cluster. 1239 - Added attributes for circuit capacity and DSP capacity. 1240 - Added section on LS operation, discussing aggregation issue. 1242 11. Acknowledgments 1244 We wish to thank Vijay Gurbani, Li Li, Kevin McDermott, David Oran, 1245 Bob Penfield, Jon Peterson, Anirudh Sahoo and James Yu for their 1246 insightful comments and suggestions. 1248 12. References 1250 12.1. Normative References 1252 [1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement 1253 Levels", BCP 14, RFC 2119, March 1997. 1255 [2] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over 1256 IP (TRIP)," Request for Comments 3219, Internet Engineering Task 1257 Force, January 2002. 1259 [3] Kent, S. and R. Atkinson, "Security Architecture for the 1260 Internet Protocol", RFC 2401, November 1998. 1262 [4] V. Gurbani and C. Jennings, "Representing trunk groups in tel/sip 1263 Uniform Resource Identifiers (URIs)," Internet Draft, Internet 1264 Engineering Task Force, August 2006. 1266 [5] J. Yu, "New Parameters for the "tel" URI to Support Number 1267 Portability," Internet Draft, Internet Engineering Task Force, August 1268 2006. 1270 [6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1271 November 1998. 1273 [7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1274 (ESP)", RFC 2406, November 1998. 1276 [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1277 RFC 2409, November 1998. 1279 [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1280 Specifications: ABNF", RFC 2234, November 1997. 1282 12.2. Informative References 1284 [10] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 1285 session initiation protocol," Request for Comments 3261, Internet 1286 Engineering Task Force, Mar. 1999. 1288 [11] J. Rosenberg and H. Schulzrinne, "A framework for telephony 1289 routing over IP," Request for Comments 2871, Internet Engineering 1290 Task Force, June 2000. 1292 [12] ITU-T List of ITU Carrier Codes (published periodically in the 1293 ITU-T Operational Bulletin). 1295 [13] J. Rosenberg, "Requirements for Gateway Registration," Internet 1296 Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. 1298 [14] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service 1299 location protocol, version 2," Request for Comments 2608, Internet 1300 Engineering Task Force, June 1999. 1302 Authors' Addresses 1304 Manjunath Bangalore 1305 Cisco Systems Inc. 1306 Mail Stop SJC-14/2/1 1307 170 W. Tasman Drive 1308 San Jose, CA 95134 1309 Phone: +1-408-525-7555 1310 email: manjax@cisco.com 1312 Rajneesh Kumar 1313 Cisco Systems Inc. 1314 Mail Stop SJC-14/4/2 1315 170 W. Tasman Drive 1316 San Jose, CA 95134 1317 Phone: +1-408-527-6148 1318 email: rajneesh@cisco.com 1320 Jonathan Rosenberg 1321 Cisco Systems Inc. 1322 Mail Stop PPY02/2 1323 600 Lanidex Plaza 1324 Parsippany 1325 NJ 07054 1326 Phone: +1-973-952-5060 1327 email: jdrosen@cisco.com 1329 Hussein F. Salama 1330 email: h.f.salama@ieee.org 1332 Dhaval N. Shah 1333 Cisco Systems Inc. 1334 Mail Stop SJC-20/3/3 1335 170 W. Tasman Drive 1336 San Jose, CA 95134 1337 Phone: +1-408-527-0436 1338 email: dhaval@cisco.com 1340 Intellectual Property Statement 1342 The IETF takes no position regarding the validity or scope of any 1343 Intellectual Property Rights or other rights that might be claimed to 1344 pertain to the implementation or use of the technology described in 1345 this document or the extent to which any license under such rights 1346 might or might not be available; nor does it represent that it has 1347 made any independent effort to identify any such rights. Information 1348 on the procedures with respect to rights in RFC documents can be 1349 found in BCP 78 and BCP 79. 1351 Copies of IPR disclosures made to the IETF Secretariat and any 1352 assurances of licenses to be made available, or the result of an 1353 attempt made to obtain a general license or permission for the use of 1354 such proprietary rights by implementers or users of this 1355 specification can be obtained from the IETF on-line IPR repository at 1356 http://www.ietf.org/ipr. 1358 The IETF invites any interested party to bring to its attention any 1359 copyrights, patents or patent applications, or other proprietary 1360 rights that may cover technology that may be required to implement 1361 this standard. Please address the information to the IETF at ietf- 1362 ipr@ietf.org. 1364 Disclaimer of Validity 1366 This document and the information contained herein are provided on an 1367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1369 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1370 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1371 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1374 Copyright Statement 1376 Copyright (C) The Internet Society (2007). This document is subject 1377 to the rights, licenses and restrictions contained in BCP 78, and 1378 except as set forth therein, the authors retain all their rights. 1380 Acknowledgment 1382 Funding for the RFC Editor function is currently provided by the 1383 Internet Society.