idnits 2.17.1 draft-ietf-iptel-tgrep-06.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1326. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** There are 43 instances of too long lines in the document, the longest one being 22 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 400 has weird spacing: '...s to be deter...' == Line 463 has weird spacing: '...refixes that...' == Line 468 has weird spacing: '...ges may be re...' == Line 549 has weird spacing: '...nkgroup for t...' == Line 659 has weird spacing: '...anaging that ...' == (2 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 '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 1096 == Unused Reference: '2' is defined on line 1210, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1222, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1254, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2871 (ref. '5') ** Obsolete normative reference: RFC 2401 (ref. '6') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '7') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '8') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '9') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2234 (ref. '10') (Obsoleted by RFC 4234) Summary: 12 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPTEL Working Group Manjunath Bangalore, Cisco Systems Inc. 3 Internet Draft Rajneesh Kumar, Cisco Systems Inc. 4 draft-ietf-iptel-tgrep-06.txt Hussein Salama, MenaNet Communications S.A.E. 5 July 2005 Jonathan Rosenberg, Cisco Systems Inc. 6 Expiration Date: January 2006 Dhaval N. Shah, Cisco Systems Inc. 8 A Telephony Gateway REgistration Protocol (TGREP) 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she becomes aware will be disclosed, in accordance with 17 Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 16, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes the Telephony Gateway Registration Protocol 44 (TGREP) for registration of telephony prefixes supported by telephony 45 gateways and soft switches. The registration mechanism can also be 46 used to export resource information. The prefix and resource 47 information can then be passed on to a Telephony Routing over IP 48 (TRIP) Location Server, which in turn can propagate that routing 49 information within and between internet telephony administrative 50 domains (ITAD). TGREP shares a lot of similarities with the TRIP 51 Protocol. It has similar procedures and Finite State Machine for 52 session establishment. It also shares the same format for messages 53 and a subset of attributes with TRIP. 55 TGREP entities are valid trip implementations, but they do only a 56 subset of what they otherwise could. In particular, a gateway is 57 always in Send mode, the LS peering with it is always in Receive 58 mode. 60 Table of Contents 62 1 Terminology and Definitions .............................. 4 63 2 Introduction ............................................. 4 64 3 TGREP: Overview of operation ............................. 6 65 4 TGREP Attributes ......................................... 7 66 4.1 TotalCircuitCapacity Attribute ........................... 7 67 4.2 AvailableCircuits Attribute .............................. 9 68 4.3 CallSuccess Attribute .................................... 10 69 4.4 Prefix Attributes ........................................ 12 70 4.5 TrunkGroup Attribute ..................................... 13 71 4.6 Carrier Attribute ........................................ 15 72 4.7 TrunkGroup and Carrier Address Families .................. 16 73 4.8 Gateway Operation ........................................ 18 74 4.9 LS/Proxy Behavior ........................................ 21 75 5 Security Considerations .................................. 25 76 6 IANA Considerations ...................................... 26 77 6.1 Attribute Codes .......................................... 26 78 6.2 Address Family Codes ..................................... 26 79 7 Change history ........................................... 27 80 7.1 Changes since draft-ietf-iptel-tgrep-03.txt .............. 27 81 7.2 Changes since draft-ietf-iptel-tgrep-02.txt .............. 27 82 7.3 Changes since draft-ietf-iptel-tgrep-01.txt .............. 27 83 7.4 Changes since draft-ietf-iptel-tgrep-00.txt .............. 27 84 7.5 Changes since draft-ietf-iptel-trip-gw-00.txt ............ 28 85 7.6 Changes since -03 ........................................ 28 86 7.7 Changes since -02 ........................................ 28 87 7.8 Changes since -01 ........................................ 29 88 7.9 Changes since -00 ........................................ 29 89 8 Acknowledgments .......................................... 29 90 9 References ............................................... 29 91 9.1 Normative References ..................................... 29 92 9.2 Informative References ................................... 30 93 Authors' Addresses ....................................... 30 94 Intellectual Property Statement .......................... 31 95 Disclaimer of Validity ................................... 32 96 Copyright Statement ...................................... 32 97 Acknowledgment ........................................... 32 99 1. Terminology and Definitions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [1]. 105 Some other useful definitions are: 107 Circuit: A circuit is a discrete (specific) path between two or more 108 points along which signals can be carried. In this context, a circuit 109 is a physical path, consisting of one or more wires and possibly 110 intermediate switching points. 112 Trunk: In a network, a communication path connecting two switching 113 systems used in the establishment of an end-to-end connection. In 114 selected applications, it may have both its terminations in the same 115 switching system. 117 TrunkGroup: A set of trunks, traffic engineered as a unit, for the 118 establishment of connections within or between switching systems in 119 which all of the paths are interchangeable except where subgrouped. 121 Carrier: A company offering telephone and data communications between 122 points (end-users and/or exchanges). 124 2. Introduction 126 It is assumed that reader of this has already gone through TRIP [4]. 127 In typical VoIP networks, Internet Telephony Administrative Domains 128 (ITADs) will deploy numerous gateways for the purposes of 129 geographical diversity, capacity, and redundancy. When a call arrives 130 at the domain, it must be routed to one of those gateways. 131 Frequently, an ITAD will break their network into geographic Points 132 of Presence (POP), with each POP containing some number of gateways, 133 and a proxy server element that fronts those gateways. The proxy 134 server is responsible for managing the access to the POP, and also 135 for determining which of the gateways will receive any given call 136 that arrives at the POP. In conjunction with the proxy server that 137 routes the call signaling, there are two TRIP Speaker components, the 138 "Ingress LS" and the "Egress LS". The Ingress LS maintains TGREP 139 peering relationship with one or more gateways. The routing 140 information received from the gateways are further injected into the 141 Egress LS, which in turn disseminates into the rest of the network on 142 TRIP. 144 This configuration is depicted graphically in Figure 1. 146 +---------+ 147 | | 148 | GW | 149 > +---------+ 150 // 151 // 152 // +---------+ 153 // | | 154 +-------------------------+ // | GW | 155 | | // +---------+ 156 | +-------------+ |/ 157 | | | | 158 | | Routing | | +---------+ TO PSTN 159 | | Proxy | | | | 160 ---> | | |-----------> | GW | -----> 161 |+---+-----+ +-----+----+ | +---------+ 162 || | | | | 163 || <+-+ | |-- 164 ||Egress LS| |Ingress LS| | --- +---------+ 165 || | | | | -- | | 166 |+---------+ +----------+ | -- | GW | 167 | | -- +---------+ 168 | | --> 169 +-------------------------+ 170 +---------+ 171 | | 172 | GW | 173 +---------+ 175 Figure 1: Gateway and LS Configuration 177 The decision about which gateway to use depends on many factors, 178 including their availability, remaining call capacity and call 179 success statistics to a particular PSTN destination. For the proxy to 180 do this adequately, it needs to have access to this information in 181 real-time, as it changes. This means there must be some kind of 182 communications between the proxy and the gateways to convey this 183 information. 185 In this document, we specify a protocol for registration of routes 186 (destinations) supported by the gateway to the TRIP Location Server 187 [4], known as Telephony Gateway REgistration Protocol (TGREP). TGREP 188 Protocol can be considered an auxiliary protocol to TRIP. Routes 189 learnt through TGREP can be injected into and further processed 190 and/or propagated by the TRIP Location Server. 192 TGREP shares a lot of commonality with TRIP in various aspects. 194 Particularly, TGREP and TRIP have the same session establishment 195 procedures, state machine, etc. TGREP also makes use of a similar 196 UPDATE message to propagate the routes supported. It uses 197 Notification, Keepalive and OPEN message in the same essence as TRIP. 198 TGREP defines few new attributes that are needed to specify certain 199 characteristics of gateways, like Available Capacity for a 200 destination. The document aims at specifying all the attributes 201 related to the TGREP session. This document also specifies some new 202 address families which can be useful in advertising the information 203 on the GWs. 205 As a general rule, because of lot of similarities between TRIP and 206 TGREP, frequent reference will be made to the terminologies and 207 formats defined in TRIP [4]. It is suggested that the reader be 208 familiar with the concepts of TRIP like attributes, flags, route 209 types, address families, etc. 211 3. TGREP: Overview of operation 213 TGREP is a route registration protocol for telephony destinations on 214 a gateway. These telephony destinations could be prefixes, trunk 215 groups or Carriers. The Speaker of TGREP resides on the GW and 216 gathers all the information from the GW to relay to the TRIP Location 217 Server. A TGREP Receiver is defined, which receives this information 218 and after certain optional operations like consolidation and 219 aggregation. (defined in Sections 3.10.1 and 3.10.2) hands over the 220 reachability information a to TRIP Location Server. 222 The TGREP speaker establishes a session to the TGREP Receiver using 223 the procedures similar to session establishment in TRIP. The TGREP 224 Speaker is however, in "Send only" mode and the receiver is in the 225 "Receive only" mode. After the session establishment the TGREP 226 speaker sends the reachibility information in the UPDATE messages. 227 The UPDATE messages have the same format as in TRIP. However, certain 228 TRIP attributes are not relevant in TGREP; a TGREP speaker MAY ignore 229 them if they are present in a TGREP message. The following TRIP 230 attributes do not apply to TGREP: 231 1. AdvertisementPath 232 2. RoutedPath 233 3. AtomicAggregate 234 4. LocalPreference 235 5. MultiExitDisc 236 6. ITADTopology 237 7. ConvertedRoute 239 In addition, TGREP defines the following new attributes in this 240 document that can be carried in a TGREP UPDATE message. 242 1. TotalCircuitCapacity 243 2. AvailableCircuits 244 3. CallSuccess 245 4. Prefix (E164) 246 5. Prefix (Decimal Routing Number) 247 6. Prefix (Hexadecimal Routing Number) 248 7. TrunkGroup 249 8. Carrier 251 In the rest of the document we specify attributes and address 252 families used in TGREP. We also specify the operations of 253 consolidation and aggregation as they apply to the UPDATEs received 254 from the TGREP Gateway by the TGREP Receiver. 256 4. TGREP Attributes 258 A TGREP UPDATE supports the following attributes: 259 1. WithdrawnRoutes (as defined in TRIP) 260 2. ReachableRoutes (as defined in TRIP) 261 3. NexthopServer (as defined in TRIP) 262 4. TotalCircuitCapacity 263 5. AvailableCircuits 264 6. CallSuccess 265 7. Prefix (E.164, Pentadecimal routing number, Decimal routing number) 266 8. TrunkGroup 267 9. Carrier 268 10. Communities 270 4.1. TotalCircuitCapacity Attribute 272 Mandatory: False. 273 Required Flags: Not well-known. 274 Potential Flags: None. 275 TRIP Type Code: 13. 277 The TotalCircuitCapacity identifies the total number of PSTN circuits 278 that are available on a route to complete calls. It is used in 279 conjunction with the AvailableCircuits attribute in gateway selection 280 by the LS. The total number of calls sent to the specified route on 281 the gateway cannot exceed this total circuit capacity under steady 282 state conditions. 284 The TotalCircuitCapacity attribute is used to reflect the 285 administratively provisioned capacity as opposed to the availability 286 at a given point in time as provided by the AvailableCircuits 287 attribute. Because of its relatively static nature, this attribute 288 MAY be propagated beyond the LS that receives it. 290 TotalCircuitCapacity represents the total number of active calls at 291 any instant. This is not expected to change frequently. This can 292 change, for instance, when certain telephony trunks on the gateway 293 are taken out of service for maintenance purposes. 295 4.1.1. TotalCircuitCapacity Syntax 297 The TotalCircuitCapacity attribute is a 4-octet unsigned integer. It 298 represents the total number of circuits available for terminating 299 calls through this advertised route. This attribute represents a 300 potentially achievable upper bound on the number of calls which can 301 be terminated on this route in total. 303 4.1.2. Route Origination and TotalCircuitCapacity 305 Routes MAY be originated containing the TotalCircuitCapacity 306 attribute. 308 4.1.3. Route Selection and TotalCircuitCapacity 310 The TotalCircuitCapacity attribute MAY be used for route selection. 311 Since one of its primary applications is load balancing, an LS will 312 wish to choose a potentially different route (amongst a set of routes 313 for the same destination), on a call by call basis. This can be 314 modeled as re-running the decision process on the arrival of each 315 call. The aggregation and dissemination rules for routes with this 316 attribute ensure that re-running this selection process never results 317 in propagation of a new route to other peers. 319 4.1.4. Aggregation and TotalCircuitCapacity 321 An LS MAY aggregate routes to the same prefix which contain a 322 TotalCircuitCapacity attribute. It SHOULD add the values of the 323 individual routes to determine the value for the aggregated route in 324 the same ITAD. 326 4.1.5. Route Dissemination and TotalCircuitCapacity 328 Since this attribute reflects the static capacity of the gateway's 329 circuit resources, it is not expected to change frequently. Hence the 330 LS receiving this attribute MAY disseminate it to other peers, both 331 internal and external to the ITAD. 333 4.2. AvailableCircuits Attribute 335 Mandatory: False. 336 Required Flags: Not well-known. 337 Potential Flags: None. 338 TRIP Type Code: 14. 340 The AvailableCircuits identifies the number of PSTN circuits that are 341 currently available on a route to complete calls. The number of 342 additional calls sent to that gateway for that route cannot exceed 343 the circuit capacity. If it does, the signaling protocol will likely 344 generate errors, and calls will be rejected. 346 The AvailableCircuits attribute is used ONLY between a gateway and 347 its peer LS responsible for managing that gateway. If it is received 348 in a route, it is not propagated. 350 4.2.1. AvailableCircuits Syntax 352 The AvailableCircuits attribute is a 4-octet unsigned integer. It 353 represents the number of circuits remaining for terminating calls to 354 this route. 356 4.2.2. Route Origination and AvailableCircuits 358 Routes MAY be originated containing the AvailableCircuits attribute. 359 Since this attribute is highly dynamic, changing with every call, 360 updates MAY be sent as it changes. However, it is RECOMMENDED that 361 measures be taken to help reduce the messaging load from route 362 origination. It is further RECOMMENDED that a sufficiently large 363 window of time be used to provide a useful aggregated statistic. 365 4.2.3. Route Selection and AvailableCircuits 367 The AvailableCircuits attribute MAY be used for route selection. 368 Since one of its primary applications is load balancing, an LS will 369 wish to choose a potentially different route (amongst a set of routes 370 for the same prefix) on a call by call basis. This can be modeled as 371 re-running the decision process on the arrival of each call. The 372 aggregation and dissemination rules for routes with this attribute 373 ensure that re-running this selection process never results in 374 propagation of a new route to other peers. 376 4.2.4. Aggregation and AvailableCircuits 378 Not applicable 380 4.2.5. Route Dissemination and AvailableCircuits 382 Routes MUST NOT be disseminated with the AvailableCircuits attribute. 383 The attribute is meant to reflect capacity at the originating gateway 384 only. Its highly dynamic nature makes it inappropriate to disseminate 385 in most cases. 387 4.3. CallSuccess Attribute 389 Mandatory: False. 390 Required Flags: Not well-known. 391 Potential Flags: None. 392 TRIP Type Code: 15. 394 The CallSuccess attribute is an attribute used ONLY between a gateway 395 and its peer LS responsible for managing that gateway. If it is 396 received in a route, it is not propagated. 398 The CallSuccess attribute provides information about the number of 399 normally terminated calls out of a total number of attempted calls. 400 CallSuccess is to be determined by the gateway based on the 401 Disconnect cause code at call termination. For example, a call that 402 reaches the Alerting stage but does not get connected due to the 403 unavailability of the called party, or the called party being busy, 404 is conventionally considered a successful call. On the other hand, a 405 call that gets disconnected because of a Circuit or Resource being 406 unavailable is conventionally considered a failed call. The exact 407 mapping of disconnect causes to CallSuccess is at the discretion of 408 the gateway reporting the attribute. 410 The CallSuccess attribute is used by the LS to keep track of failures 411 in reaching certain telephony destinations through a gateway(s) and 412 use that information in the gateway selection process to enhance the 413 probability of successful call termination. 415 This information can be used by the LS to consider alternative 416 gateways to terminate calls to those destinations with a better 417 likelihood of success. 419 4.3.1. CallSuccess Syntax 421 The CallSuccess attribute is comprised of two component fields - each 422 represented as an unsigned 4-octet unsigned integer. The first 423 component field represents the total number of calls terminated 424 successfully for the advertised destination on a given address family 425 over a given window of time. The second component field represents 426 the total number of attempted calls for the advertised destination 427 within the same window of time. 429 4.3.2. Route Origination and CallSuccess 431 Routes MAY be originated containing the CallSuccess attribute. This 432 attribute is expected to get statistically significant with passage 433 of time as more calls are attempted. It is RECOMMENDED that 434 sufficiently large windows be used to provide a useful aggregated 435 statistic. 437 4.3.3. Route Selection and CallSuccess 439 The CallSuccess attribute MAY be used for route selection. This 440 attribute represents a measure of success of terminating calls to the 441 advertised destination(s). This information MAY be used to select 442 from amongst a set of alternative routes to increase the probability 443 of successful call termination. 445 4.3.4. Aggregation and CallSuccess 447 Not applicable 449 4.3.5. Route Dissemination and CallSuccess 451 Routes MUST NOT be disseminated with the CallSuccess attribute. Its 452 potential to change dynamically does not make it suitable to 453 disseminate. 455 4.4. Prefix Attributes 457 Mandatory: False. 458 Required Flags: Not well-known. 459 Potential Flags: None. 460 TRIP Type Codes: 16 for E164 prefix, 17 for Pentadecimal routing number prefix 461 and 18 for Decimal routing number prefix. 463 The Prefix attribute is used to represent the list of prefixes that 464 the respective route can complete calls to. This attribute is 465 intended to be used with the Carrier or Trunkgroup address family 466 (discussed in Section 3.7). 468 Though it is possible that all prefix ranges may be reachable 469 through a given Carrier, administrative issues could make certain 470 ranges preferable to others. 472 4.4.1. Prefix Attribute Syntax 474 The Prefix attribute could be E.164, Decimal or PentaDecimal (refer 475 to TRIP [4]), each of them having it's own type code. The Prefix 476 attribute is encoded as a sequence of prefix values in the attribute 477 value field. The prefixes are listed sequentially with no padding as 478 shown in Figure 2. Each prefix includes a 2-octet length field that 479 represents the length of the address field in octets. The order of 480 prefixes in the attribute is not significant. 482 The presence of Prefix Attribute with the length field of the 483 attribute as 0 signifies that the TGREP GW can terminate ALL prefixes 484 of that prefix type (E.164, Decimal or Pentadecimal) for the given 485 Reachable route(s). This is not equivalent to excluding the Prefix 486 attribute in the TGREP update. 488 1 489 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 490 +-------------------------------+-----------+----------------------------------+----------- 491 | Length | Prefix1...| Length | Prefix2... 492 +-------------------------------+-----------+----------------------------------+----------- 494 Figure 2: Prefix Format 496 4.4.2. Route Origination and Prefix 498 Routes MAY be originated containing the Prefix attribute. 500 4.4.3. Route Selection and Prefix 502 The Prefix attribute MAY be used for route selection. 504 4.4.4. Aggregation and Prefix 506 Routes with differing Prefix attribute MUST NOT be aggregated. 507 Routes with the same value in the Prefix attribute MAY be aggregated 508 and the same Prefix attribute attached to the aggregated object. 510 4.4.5. Route Dissemination and Prefix 512 The LS receiving this attribute should disseminate to other peers, 513 both internal and external to the ITAD. 515 4.5. TrunkGroup Attribute 517 Mandatory: False. 518 Required Flags: Not well-known. 519 Potential Flags: None. 520 TRIP Type Code: 20. 522 The TrunkGroup attribute is used to represent the list of trunkgroups 523 on the gateway used to complete calls. It enables providers to route 524 calls to destinations through preferred trunks. This attribute is 525 relatively static. 527 4.5.1. TrunkGroup Syntax 529 The TrunkGroup attribute is a variable length attribute that is 530 composed of a sequence of trunkgroup identifiers. It indicates that 531 the gateway can complete the call through any trunkgroup identifier 532 indicated in the sequence. 534 Each trunkgroup identifier is encoded as a length-value field (shown 535 in Figure 3 below). The length field is a 1-octet unsigned numeric 536 value. The value field is a variable length field consisting of two 537 sub-fields, a trunk group label followed by a trunk context, the two 538 sub-fields separated by the delimiter ";" (semicolon). Both the trunk 539 group label and the trunk context sub-fields are of variable length. 540 The length field represents the total size of the value field 541 including the delimiter. 543 The permissible character set for the trunk group label and the trunk 544 group context sub-fields and the associated ABNF [10] is per rules 545 outlined in [13]. 547 The presence of TrunkGroup attribute with the length field of the 548 attribute as 0 signifies that the TGREP GW can terminate ALL 549 trunkgroup for the given Reachable route(s). 551 0 1 552 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 ... 553 +---------------+--------------------+---------------+--------------------- 554 | Length | TrunkGroup 1... | Length | TrunkGroup 2... 555 +---------------+--------------------+---------------+--------------------- 556 Figure 3: TrunkGroup Syntax 558 4.5.2. Route Origination and TrunkGroup 560 Routes MAY be originated containing the TrunkGroupattribute. 562 4.5.3. Route Selection and TrunkGroup 564 The TrunkGroup attribute MAY be used for route selection. Certain 565 trunkgroups MAY be preferred over others based on provider policy. 567 4.5.4. Aggregation and TrunkGroup 569 Routes with differing TrunkGroup attribute MUST NOT be aggregated. 570 Routes with the same value in the TrunkGroup attribute MAY be 571 aggregated and the same TrunkGroup attribute attached to the 572 aggregated object. 574 4.5.5. Route Dissemination and TrunkGroup 576 This attribute is not expected to change frequently. Hence, the LS 577 receiving this attribute MAY disseminate it to other peers, internal 578 to ITAD. Routes SHOULD not be disseminated external to the ITAD, with 579 TrunkGroup attribute. 581 4.6. Carrier Attribute 583 Mandatory: False. 584 Required Flags: Not well-known. 585 Potential Flags: None. 586 TRIP Type Code: 19. 588 The Carrier attribute is used to represent the list of carriers that 589 the gateway uses to complete calls. It enables providers to route 590 calls to destinations through preferred carriers. This attribute is 591 relatively static. 593 4.6.1. Carrier Syntax 595 The Carrier attribute is a variable length attribute that is composed 596 of a sequence of carrier identifiers. It indicates that the route 597 can complete the call to any of the carriers represented in the 598 sequence of carrier identifiers. 600 Each carrier identifier is encoded as a length-value field (shown in 601 Figure 4 below). The length field is a 1-octet unsigned numeric 602 value. The value field is a variable length field. 604 The permissible character set for the value field and the associated 605 ABNF [10] is per rules outlined in [15]. Specifically, it carries 606 "global-cic" or "local-cic"[15]. In case of "local-cic", the 607 "phonedigit-hex" part and the "cic-context" part would be separated 608 by the delimiter ";". Hence absence or presence of the delimiter can 609 be used to determine if the value is a "global-cic" or a "local-cic". 610 The length field represents the total size of the value field 611 including the delimiter. 613 The presence of Carrier Attribute with the length field of the 614 attribute as 0 signifies that the TGREP GW can terminate ALL Carriers 615 for the given Reachable route(s). 617 0 1 618 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 ... 619 +---------------+--------------------+---------------+--------------------- 620 | Length | Carrier 1... | Length | Carrier 2... 621 +---------------+--------------------+---------------+--------------------- 622 Figure 4: Carrier Syntax 624 4.6.2. Route Origination and Carrier 626 Routes MAY be originated containing the Carrier attribute. 628 4.6.3. Route Selection and Carrier 630 The Carrier attribute MAY be used for route selection. Certain 631 carriers MAY be preferred over others based on provider policy. 633 4.6.4. Aggregation and Carrier 635 Routes with differing Carrier attribute MUST NOT be aggregated. 636 Routes with the same value in the Carrier attribute MAY be aggregated 637 and the same Carrier attribute attached to the aggregated object. 639 4.6.5. Route Dissemination and Carrier 641 This attribute is not expected to change frequently. Hence, the LS 642 receiving this attribute MAY disseminate it to other peers, both 643 internal and external to the ITAD. 645 4.7. TrunkGroup and Carrier Address Families 647 As described in TRIP [4], the address family field gives the type of 648 address for the route. Two new address families and their codes are 649 defined in this Section: 651 Code Address Family 652 4 TrunkGroup 653 5 Carrier 655 When a set of GWs are to managed at the granularity of carriers or 656 trunkgroups then it may be more appropriate for a GW to advertise 657 routes using the Carrier address family or trunkgroup address family 658 respectively. Also, in a TGREP association between the gateway and 659 the LS responsible for managing that gateway, there are some 660 attributes that more naturally fit in as advertised properties of 661 trunkgroups or carriers rather than that of advertised prefixes; for 662 example, the AvailableCircuit information on a particular trunkgroup 663 or a particular carrier. To express this relationship, the existing 664 TRIP address families are inadequate. We need separate address 665 families that can associate certain properties like AvailableCircuits 666 information to trunkgroups or carriers. 668 The primary benefits of this model are as follows: 670 - It allows a service provider to route calls based strictly on the 671 trunkGroups or carriers. 672 - it facilitates more accurate reporting of attributes of a dynamic 673 nature like AvailableCircuits by providing the ability to manage 674 resources at the granularity of a trunkgroup or a carrier. 675 - Gateways can get really large with the ability to provision 676 hundreds or a few thousand circuits and this can increase the 677 potential for traffic that reports dynamic resource information 678 between the gateway and the LS. The model introduced can 679 potentially alleviate this UPDATE traffic hence increasing 680 efficiency and providing a scalable gateway registration model. 682 4.7.1. Address Family Syntax 684 Consider the generic TRIP route format from TRIP[4] shown below. 686 0 1 2 3 687 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 688 +---------------+---------------+--------------+----------------+ 689 | Address Family | Application Protocol | 690 +---------------+---------------+--------------+----------------+---- 691 | Length | Address (variable) .... 692 +---------------+---------------+--------------+----------------+---- 694 Figure 5: Generic TRIP Route Format 696 The Address Family field will be used to represent the type of the 697 address associated for this family, which is based on the TrunkGroup 698 or Carrier. The codes for the new address families will be allocated 699 by IANA. 701 The code for the trunk group address family is XX [[NOTE TO RFC-ED: 702 Please replace XX with the IANA assigned value for the trunk group 703 address family]] and the code for the carrier address family is XXX 704 [[NOTE TO RFC-ED: Please replace XX with the IANA assigned value for 705 the carrier address family]]. 707 The Application Protocol field is same as the one for the Decimal, 708 PentaDecimal and E.164 address families defined in TRIP[4]. The 709 Length field represents the total size of the Address field in bytes. 711 The value in the Address field represents either the TrunkGroup or 712 the Carrier address families and the syntax is as follows: 714 For the TrunkGroup Address Family, the Address field represents a 715 Trunkgroup value that is defined as specified in an 716 earlier Section 4.5.1 about the TrunkGroup Attribute. 718 For the Carrier Address Family, the Address field represents a 719 Carrier value that is defined as specified in an 720 earlier Section 4.6.1 about the Carrier Attribute. 722 If a gateway supports any of these address families, it should 723 include that address family as one of the Route types supported in 724 the OPEN message capability negotiation phase. 726 The following attributes are currently defined to be used with all 727 the address families including the TrunkGroup and Carrier address 728 families. 730 - AvailableCircuits Attribute 731 - TotalCircuitCapacity Attribute 732 - CallSuccess Attribute 734 It is recommended that the above three attributes be used by the 735 gateway with the TrunkGroup or Carrier address families, if possible. 736 This will potentially offer a more efficient resource reporting 737 framework, and a scalable model for gateway provisioning. 739 However, when the gateway is not using TrunkGroup or Carrier address 740 family, it MAY use the above attributes with the Decimal, 741 PentaDecimal and E.164 address families. 743 The prefix attribute cannot be used when the address family is E164 744 numbers, Pentadecimal routing numbers or Decimal routing numbers. 746 The Carrier attribute cannot be used if the address family type is 747 Carrier 749 The TrunkGroup attribute cannot be used if the address family type is 750 TrunkGroup 752 4.8. Gateway Operation 754 A gateway uses TGREP to advertise its reachability to its domain's 755 Location Server(s) (LS, which are closely coupled with proxies). The 756 gateway operates in TGREP Send Only mode since it is only interested 757 in advertising its reachability, but is not interested in learning 758 about the reachability of other gateways and other domains. Also, the 759 gateway will not create its own call routing database. In this 760 section we describe the operation of TGREP on a gateway. 762 4.8.1. Session Establishment 764 When opening a peering session with a TGREP Receiver, a TGREP gateway 765 follows exactly the same procedures as any other TRIP speaker. The 766 TGREP gateway sends an OPEN message which includes a Send Receive 767 Capability in the Optional Parameters. The Send Receive Capability is 768 set by the gateway to Send Only. The OPEN message also contains the 769 address families supported by the gateway. The remainder of the peer 770 session establishment is identical to TRIP. 772 4.8.2. UPDATE Messages 774 Once the peer session has been established, the gateway sends UPDATE 775 messages to the TRIP LS with the gateway's entire reachability. The 776 Gateway also sends any attributes associated with the routes. 778 If the gateway's reachability changes at any point in time, the 779 gateway MUST generate UPDATE message(s) with the change. The 780 frequency of successive UPDATE messages MUST follow the same rules 781 specified for TRIP[4]. The TGREP gateway MUST support all mandatory 782 TRIP attributes. 784 If the gateway receives an UPDATE message from the TRIP LS, it MUST 785 silently discard it as specified for TRIP[4]. No further action 786 should be taken. 788 4.8.3. KEEPALIVE Messages 790 KEEPALIVE messages are periodically exchanged over the peering 791 session between the TGREP gateway and the TRIP LS as specified in 792 Section 4.4 of TRIP [4]. 794 4.8.4. Error Handling and NOTIFICATION Messages 796 The same procedures used with TRIP, are used with TGREP for error 797 handling and generating NOTIFICATION messages. The only difference is 798 that a TGREP gateway will never generate a NOTIFICATION message in 799 response to an UPDATE message, irrespective of the contents of the 800 UPDATE message. Any UPDATE message is silently discarded. 802 4.8.5. TGREP Finite State Machine 804 When the TGREP finite state machine is in the Established state and 805 an UPDATE message is received, the UPDATE message is silently 806 discarded and the TGREP gateway remains in the Established state. 807 Other than that the TRIP finite state machine and the TGREP finite 808 state machine are identical. 810 4.8.6. Call Routing Databases 812 A TGREP gateway may maintain simultaneous sessions with more than one 813 TRIP LSs. A TGREP gateway maintains one call routing database per 814 peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out, 815 and hence we will call them Adj-TRIB-GWs-Out. An Adj-TRIB-GW-Out 816 contains the gateway's reachability information advertised to its 817 peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is 818 outside the scope of this draft (possibly by manual configuration). 820 The TGREP gateway does not have databases equivalent to TRIP's Adj- 821 TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn 822 routes from its peer TRIP LSs, and hence it does not run call route 823 selection. 825 4.8.7. Multiple Address Families 827 As mentioned above, TGREP supports various address families in order 828 to convey the reachabilty of telephony destinations. A TGREP session 829 MUST NOT send UPDATEs of more than one of the following categories 830 (a) Prefix Address families (E164, Pentadecimal and decimal) (b) 831 Trunkgroup address family (c) Carrier Address family for a given 832 established session. TGREP should specify it's choice address family 833 through the route-type capability in the OPEN message. And route-type 834 specification in the OPEN message violating the above rule should be 835 rejected with a NOTIFICATION message. 837 4.8.8. Route Selection and Aggregation 839 TRIP's route selection and aggregation operations MUST NOT be 840 implemented by TGREP gateways. 842 4.9. LS/Proxy Behavior 844 As mentioned earlier, TGREP can be considered as a protocol 845 complimentary to TRIP in providing reachability information that can 846 then be further fed into the Location Server. The architecture of an 847 LS/Proxy system is as follows: There exists a TRIP LS application 848 that functions as a speaker in the I-TRIP/E-TRIP network as 849 documented in TRIP [4]. This component is termed as "LS-Egress" for 850 the purposes of this discussion. Then, there is a signaling server 851 fronting a set of gateways. In conjunction with this signaling 852 server, is also a second TRIP LS component operating in receive mode, 853 that peers with one more gateways, each of them using TGREP to 854 advertise routing information. This TRIP LS component on the 855 receiving end of one or more TGREP sessions is termed as the "LS- 856 Ingress" or "TGREP Receiver" for the purposes of this discussion. The 857 LS-Ingress receiving the TRIP messages takes the resulting routing 858 information from each gateway, and "exports" it to another process we 859 are defining that performs consolidation and aggregation, in that 860 order. These operations would take as input the collective set of 861 routes from all the gateways. Subsequently, the resulting TRIB is 862 passed as input into the LS-Egress process as shown below, that can 863 then disseminate these via TRIP. The interface between the LS-Ingress 864 peering with the GW(s) and the TRIP LS (LS-Egress) is entirely a 865 local matter. 867 The nature of the Consolidation and Aggregation operations and the 868 accompanying motivation are described in the subsections below. The 869 order in which the operations are listed represents an implicit 870 logical sequence in which they are applied. The architecture for an 871 LS/Proxy entity is shown in Figure 7 below. 873 +-------------------------------------------------------+ 874 | +-------------------------------+ | 875 | | +-+ +-+ | | 876 | | |A| |C| | | +-----+ 877 | | |g| |o| | | TGREP | | 878 | +-------------+ | |g| |n| +-------------+ | | -- | GW | 879 | | | | |r| |s| | | | | -- +-----+ 880 | | TRIP | | |e| |o| | | | +-- 881 | | LS <----------|g<--|l<--- TGREP |-++-| +-----+ 882 | | | | |a| |i| | Session | | | | | 883 | | (I-TRIP/ | | |t| |d| | Management |-++-+-------| GW | 884 | | E-TRIP) | | |i| |a| | | | | +-----+ 885 | | (LS-Egress) | | |o| |t| | |-+ -+- 886 | +-----------/-+ | |n| |i| +-------------+ | | --- +-----+ 887 | / | | | |o| | | -- | | 888 | / | | | |n| (LS-Ingress) | | | GW | 889 | / | +-+ +-+ | | +-----+ 890 | / | TGREP Receiver | | 891 | / +-------------------------------+ | 892 | / | 893 | / | 894 +-------/-----------------------------------------------+ 895 / LS/Proxy 896 / 897 / 898 / 899 / 900 / 901 +/----------------+ 902 | | 903 | | 904 | | 905 | LS | 906 | | 907 | | 908 | | 909 | | 910 | | 911 +\---------------+ 912 \ 913 \ 914 \ 915 \ 916 \ 917 \ 918 \ 919 +--------\---------------------------------------------+ 920 | \ +-------------------------------+ | 921 | \ | +-+ +-+ | | 922 | \ | |A| |C| | | +-----+ 923 | \ | |g| |o| | | TGREP | | 924 | +---------\---+ | |g| |n| +-------------+ | | -- | GW | 925 | | | | |r| |s| | | | | -- +-----+ 926 | | TRIP | | |e| |o| | | | +-- 927 | | LS <----------|g<--|l<--- TGREP |-++-| +-----+ 928 | | | | |a| |i| | Session | | | | | 929 | | (I-TRIP/ | | |t| |d| | Management |-++-+-------| GW | 930 | | E-TRIP) | | |i| |a| | | | | +-----+ 931 | | (LS-Egress) | | |o| |t| | |-+ -+- 932 | +-------------+ | |n| |i| +-------------+ | | --- +-----+ 933 | | | | |o| | | -- | | 934 | | | | |n| | | | GW | 935 | | +-+ +-+ (LS-Ingress) | | +-----+ 936 | | TGREP Receiver | | 937 | +-------------------------------+ | 938 | | 939 | | 940 +-------------------------------------------------------+ 941 LS/Proxy 943 Figure 7: LS Architecture for TRIP-GW 945 4.9.1. Route consolidation 947 The TGREP receiver (LS-Ingress) may receive routing information from 948 one or more gateways. It is possible that multiple routes are 949 available for the same destination. These different alternative 950 routes may be received from the same gateway, or from multiple 951 gateways. It is RECOMMENDED that the set of gateway routes for each 952 destination be consolidated, before presenting a candidate route, to 953 the LS-Egress entity. The motivation for this operation should be to 954 define a route that can maximally represent the collective routing 955 capabilities of the set of gateways, managed by this TGREP receiver. 956 Let us take an example scenario in order to bring out the motivation 957 for this operation. Let us say, the TGREP receiver maintains peering 958 sessions with gateways A, and B. 960 - Gateway A advertises a route for destination "SIP 408" on the 961 E.164 address family with the Carrier attribute value C1. 963 - Gateway B advertises a route for destination "SIP 408" on the 964 E.164 address family with Carrier attribute value C2. 966 The TGREP receiver that receives these routes can consolidate 967 these constituent routes into a single route for destination "SIP 968 408" with its Carrier attribute being a union of the the Carrier 969 attribute values of the individual routes, namely, "C1 C2". This 970 operation is referred to as Consolidation. In the above example, 971 it is possible that a route to the destination "SIP 408" through 972 one or more carriers may have been lost if the individual routes 973 were not consolidated. 975 Another example is to consolidate the Prefix attribute from 976 multiple Carrier or Trunkgroup updates received from different 977 gateways for the same destination. Let us say, there are Carrier 978 AF updates from two gateways for Carrier destination X, and the 979 prefix attribute values are {408, 650} from one update and {919, 980 973} from the other. The prefix values from these two updates can 981 be consolidated into a single Carrier AF route advertisement with 982 prefix value {408, 650, 919, 973}. 984 In general, there is a potential for loss of gateway routing 985 information, when TGREP routes from a set of gateways are not 986 consolidated, when a candidate route is presented to the TRIP LS. 987 The specifics of applying the consolidation operation to 988 different attributes and routes from different address families, 989 is left to the individual TGREP receiver implementations. 991 4.9.2. Aggregation 993 The set of gateway routes, that are in a consolidated form or 994 otherwise, may be aggregated before importing it to the LS instance 995 that is responsible for I-TRIP/E-TRIP processing (LS-Egress). This 996 operation follows the standard aggregation procedures described in 997 the TRIP [4], while adhering to the aggregation rules for each route 998 attribute. 1000 4.9.3. Consolidation v/s Aggregation 1002 To highlight the difference between the two operations discussed 1003 above, "Consolidation" combines multiple routes for the same route 1004 destination, whereas "Aggregation" combines routes for different 1005 route destinations that qualify as candidates to be summarized 1006 resulting in route information reduction. 1008 To take an example, if there are multiple gateways offering routes to 1009 an E.164 destination "408" but with possibly different attributes 1010 (Eg: Carrier), the LS/Proxy can combine these to form one route for 1011 "408" but representing the attribute information collectively. This 1012 process is Consolidation 1014 If, for example, the LS/Proxy receives routes for 4080, 4081, 4082, 1015 ... 4089 from amongst a set of gateways, it could aggregate these 1016 different candidate routes to have a summarized route destination 1017 "408" with each of the attributes computed using the Aggregation 1018 procedures defined in the TRIP. 1020 5. Security Considerations 1022 The Security considerations defined in the TRIP [4] apply to TGREP 1023 sessions between Gateways and TGREP Receivers (TRIP LS). 1025 The security mechanism for the peering session between TGREP GW and a 1026 TRIP LS, in an IP network, is IPsec [6]. IPsec uses two protocols to 1027 provide traffic security: Authentication Header (AH) [7] and 1028 Encapsulating Security Payload (ESP) [8]. 1030 The AH header affords data origin authentication, connectionless 1031 integrity and optional anti-replay protection of messages passed 1032 between the peer LSs. The ESP header provides origin authentication, 1033 connectionless integrity, anti-replay protection, and confidentiality 1034 of messages. 1036 Implementations of the protocol defined in this document employing 1037 the ESP header SHALL comply with section 5 of [8], which defines a 1038 minimum set of algorithms for integrity checking and encryption. 1039 Similarly, implementations employing the AH header SHALL comply with 1040 section 5 of [7], which defines a minimum set of algorithms for 1041 integrity checking using manual keys. 1043 Implementations SHOULD use IKE [9] to permit more robust keying 1044 options. Implementations employing IKE SHOULD support authentication 1045 with RSA signatures and RSA public key encryption. 1047 A Security Association (SA) [6] is a simplex "connection" that 1048 affords security services to the traffic carried by it. Security 1049 services are afforded to a SA by the use of AH, or ESP, but not both. 1050 Two types of SAs are defined: transport mode and tunnel mode [12]. A 1051 transport mode SA is a security association between two hosts, and is 1052 appropriate for protecting the TRIP session between two peer LSs. 1054 6. IANA Considerations 1056 Both TRIP[4] and TGREP share the same IANA registry for Capabilities, 1057 Attributes, Address Families, and Application Protocols. 1059 6.1. Attribute Codes 1061 The Attribute Type Codes to be assigned for the new attributes 1062 defined in this document are listed below: 1064 | Code Attribute Reference 1065 | ---- --------- --------- 1066 | 13 TotalCircuitCapacity [RFCXXXX] 1067 | 14 AvailableCircuits [RFCXXXX] 1068 | 15 CallSuccess [RFCXXXX] 1069 | 16 E.164 Prefix [RFCXXXX] 1070 | 17 Pentadecimal Routing Number Prefix [RFCXXXX] 1071 | 18 Decimal Routing Number Prefix [RFCXXXX] 1072 | 19 TrunkGroup [RFCXXXX] 1073 | 19 Carrier [RFCXXXX] 1075 [NOTE TO RFC-ED: please replace XXXX with the rfc number of this 1076 specification ] 1078 6.2. Address Family Codes 1080 The following subsections show the codes to be assigned for the two 1081 new address families introduced in this document 1083 6.2.1. TrunkGroup Address Family 1085 | Code Address Family Reference 1086 | ---- -------------- --------- 1087 | 4 TrunkGroup [RFCXXXX] 1089 [NOTE TO RFC-ED: please replace XXXX with the rfc number of this 1090 specification ] 1092 6.2.2. Carrier Address Family 1094 | Code Address Family Reference 1095 | ---- -------------- --------- 1096 | 5 Carrier [RFCXXXX] 1098 [NOTE TO RFC-ED: please replace XXXX with the rfc number of this 1099 specification ] 1101 7. Change history 1103 [[NOTE TO RFC-ED: Please remove this section prior to publication]] 1105 7.1. Changes since draft-ietf-iptel-tgrep-03.txt 1107 - No change in content. Releasing a new revision for renewal of 1108 draft. 1110 7.2. Changes since draft-ietf-iptel-tgrep-02.txt 1112 - No change in content. Releasing a new revision for renewal of 1113 draft. 1115 7.3. Changes since draft-ietf-iptel-tgrep-01.txt 1117 - Added a "Security Considerations" Section to the document. 1118 - Strengthened the text under "LS/Proxy Behavior" regarding 1119 Consolidation and Aggregation with additional examples for better 1120 clarity. 1121 - Removed the section "Other Attributes" including its subsection 1122 on the "Pricing" attribute. 1123 - Modified the definition of Carrier in the "Carrier attribute" and 1124 "TrunkGroup and Carrier Address Families" sections respectively. 1125 Pz - Rectified the section number references in the "IANA 1126 Considerations" Section. 1127 - Strengthened the text in the attribute sections regarding 1128 dissemination of attributes received on TGREP. 1129 - Updated the "References" section. 1130 - Corrected typos, nits, grammatical errors, and language of the 1131 text throughout the document based on feedback from the iptel 1132 community. 1134 7.4. Changes since draft-ietf-iptel-tgrep-00.txt 1136 - Added recommendations for AvailableCircuits and CallSuccess 1137 attributes. 1138 - Updated Carrier Attribute with ASCII syntax. 1139 - Removed thresholding scheme description. 1140 - Updated author addresses. 1142 7.5. Changes since draft-ietf-iptel-trip-gw-00.txt 1144 - Changed title of the document to TGREP (Telephony Gateway 1145 REgistration Protocol). 1146 - Changed name of protocol described in this document to TGREP. 1147 - Changed Abstract and Introduction sections to position TGREP as 1148 an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP). 1149 - Modified the section on LS/Proxy Behavior including the diagram. 1150 - Added an additional example to the Route Consolidation section. 1151 - Changed the format of Carrier (both as an attribute and as an AF) 1152 to accommodate representation of Country codes in association 1153 with CICs. 1154 - Updated text to allow Carrier attribute in TrunkGroup address 1155 family and TrunkGroup attribute in Carrier address family. 1157 7.6. Changes since -03 1159 - Removed Carrier-Trunkgroup attribute and address family and 1160 references to it. 1161 - Added Terminology and Definitions section. 1162 - Updated CallSuccess attribute. 1163 - Added Prefix attribute. 1164 - Added Carrier attribute. 1165 - Added TrunkGroup attribute. 1166 - Added TrunkGroup Address Family. 1167 - Added Carrier Address Family. 1168 - Added some more references. 1170 7.7. Changes since -02 1172 - Removed the requirements section. 1173 - Discussed the motivation for introducing Carrier information into 1174 TRIP. 1175 - Defined a new attribute for the E.164 address family. 1176 - Defined a new address family for CarrierCode-TrunkGroup 1177 combination . 1178 - Defined new attributes to advertise dynamic gateway 1179 characteristics like resource availability, and call success 1180 rate. 1181 - Added as section to validate the TGREP solution against the 1182 requirements in [7]. 1184 7.8. Changes since -01 1186 - Added requirements. 1187 - Added more formal analysis of REGISTER and added analysis of SLP. 1188 - Removed circuit capacity attribute. 1190 7.9. Changes since -00 1192 - Added text to stress the value of this proposal for managing a 1193 gateway cluster. 1194 - Added attributes for circuit capacity and DSP capacity. 1195 - Added section on LS operation, discussing aggregation issue. 1197 8. Acknowledgments 1199 We wish to thank Vijay Gurbani, Li Li, Kevin McDermott, David Oran, 1200 Bob Penfield, Jon Peterson, Anirudh Sahoo and James Yu for their 1201 insightful comments and suggestions. 1203 9. References 1205 9.1. Normative References 1207 [1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement 1208 Levels", BCP 14, RFC 2119, March 1997. 1210 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 1211 session initiation protocol," Request for Comments 3261, Internet 1212 Engineering Task Force, Mar. 1999. 1214 [3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service 1215 location protocol, version 2," Request for Comments 2608, Internet 1216 Engineering Task Force, June 1999. 1218 [4] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over 1219 IP (TRIP)," Request for Comments 3219, Internet Engineering Task 1220 Force, January 2002. 1222 [5] J. Rosenberg and H. Schulzrinne, "A framework for telephony 1223 routing over IP," Request for Comments 2871, Internet Engineering 1224 Task Force, June 2000. 1226 [6] Kent, S. and R. Atkinson, "Security Architecture for the 1227 Internet Protocol", RFC 2401, November 1998. 1229 [7] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1230 November 1998. 1232 [8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1233 (ESP)", RFC 2406, November 1998. 1235 [9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1236 RFC 2409, November 1998. 1238 [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1239 Specifications: ABNF", RFC 2234, November 1997. 1241 9.2. Informative References 1243 [11] ITU-T List of ITU Carrier Codes (published periodically in the 1244 ITU-T Operational Bulletin). 1246 [12] J. Peterson, "An Architecture for Gateway Registration Based on 1247 Trunk Groups," Internet Draft, Internet Engineering Task Force, Feb. 1248 2002. Work in progress. 1250 [13] V. Gurbani and C. Jennings, "Representing trunk groups in 1251 tel/sip Uniform Resource Identifiers (URIs)," Internet Draft, 1252 Internet Engineering Task Force, May 2005. 1254 [14] J. Rosenberg, "Requirements for Gateway Registration," Internet 1255 Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. 1257 [15] J. Yu, "New Parameters for the "tel" URI to Support Number 1258 Portability," Internet Draft, Internet Engineering Task Force, July 1259 2005. 1261 Authors' Addresses 1263 Manjunath Bangalore 1264 Cisco Systems Inc. 1265 Mail Stop SJC-21/2/2 1266 170 W. Tasman Drive 1267 San Jose, CA 95134 1268 Phone: +1-408-853-3239 1269 email: manjax@cisco.com 1270 Rajneesh Kumar 1271 Cisco Systems Inc. 1272 Mail Stop SJC-14/4/2 1273 170 W. Tasman Drive 1274 San Jose, CA 95134 1275 Phone: +1-408-527-6148 1276 email: rajneesh@cisco.com 1278 Jonathan Rosenberg 1279 Cisco Systems Inc. 1280 Mail Stop PPY02/2 1281 600 Lanidex Plaza 1282 Parsippany 1283 NJ 07054 1284 Phone: +1-973-952-5060 1285 email: jdrosen@cisco.com 1287 Hussein F. Salama 1288 Cisco Systems Inc. 1289 Mail Stop CAI1 1290 135 Abdel Aziz Fahmy Street 1291 2nd Floor Apartment #3, Heliopolis 1292 Cairo, Egypt 1293 Phone: +202-4166200 1294 email: hsalama@sysdsoft.com 1296 Dhaval N. Shah 1297 Cisco Systems Inc. 1298 Mail Stop SJC-20/3/3 1299 170 W. Tasman Drive 1300 San Jose, CA 95134 1301 Phone: +1-408-527-0436 1302 email: dhaval@cisco.com 1304 Intellectual Property Statement 1306 The IETF takes no position regarding the validity or scope of any 1307 Intellectual Property Rights or other rights that might be claimed to 1308 pertain to the implementation or use of the technology described in 1309 this document or the extent to which any license under such rights 1310 might or might not be available; nor does it represent that it has 1311 made any independent effort to identify any such rights. Information 1312 on the procedures with respect to rights in RFC documents can be 1313 found in BCP 78 and BCP 79. 1315 Copies of IPR disclosures made to the IETF Secretariat and any 1316 assurances of licenses to be made available, or the result of an 1317 attempt made to obtain a general license or permission for the use of 1318 such proprietary rights by implementers or users of this 1319 specification can be obtained from the IETF on-line IPR repository at 1320 http://www.ietf.org/ipr. 1322 The IETF invites any interested party to bring to its attention any 1323 copyrights, patents or patent applications, or other proprietary 1324 rights that may cover technology that may be required to implement 1325 this standard. Please address the information to the IETF at ietf- 1326 ipr@ietf.org. 1328 Disclaimer of Validity 1330 This document and the information contained herein are provided on an 1331 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1332 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1333 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1334 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1335 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1336 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1338 Copyright Statement 1340 Copyright (C) The Internet Society (2005). This document is subject 1341 to the rights, licenses and restrictions contained in BCP 78, and 1342 except as set forth therein, the authors retain all their rights. 1344 Acknowledgment 1346 Funding for the RFC Editor function is currently provided by the 1347 Internet Society.