idnits 2.17.1 draft-ietf-iptel-tgrep-09.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, updated by RFC 4748 on line 1359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1345. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([12]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 1125 -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 4234 (ref. '8') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4305 (ref. '13') (Obsoleted by RFC 4835) Summary: 3 errors (**), 0 flaws (~~), 3 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-09.txt Hussein Salama, Citex Software 5 September 2007 Jonathan Rosenberg, Cisco Systems 6 Expiration Date: March 2008 Dhaval Shah, Moowee Inc. 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 March 15, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (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 [12]. The registration mechanism can also 44 be 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 ................. 21 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 .......................... 22 76 7 LS/Proxy Behavior ........................................ 22 77 7.1 Route consolidation ...................................... 24 78 7.2 Aggregation .............................................. 25 79 7.3 Consolidation v/s Aggregation ............................ 25 80 8 Security Considerations .................................. 25 81 9 IANA Considerations ...................................... 26 82 9.1 Attribute Codes .......................................... 26 83 9.2 Address Family Codes ..................................... 27 84 10 Change history ........................................... 27 85 10.1 Changes since draft-ietf-iptel-tgrep-03.txt .............. 27 86 10.2 Changes since draft-ietf-iptel-tgrep-02.txt .............. 27 87 10.3 Changes since draft-ietf-iptel-tgrep-01.txt .............. 28 88 10.4 Changes since draft-ietf-iptel-tgrep-00.txt .............. 28 89 10.5 Changes since draft-ietf-iptel-trip-gw-00.txt ............ 28 90 10.6 Changes since -03 ........................................ 29 91 10.7 Changes since -02 ........................................ 29 92 10.8 Changes since -01 ........................................ 29 93 10.9 Changes since -00 ........................................ 29 94 11 Acknowledgments .......................................... 30 95 12 References ............................................... 30 96 12.1 Normative References ..................................... 30 97 12.2 Informative References ................................... 30 98 Authors' Addresses ....................................... 31 99 Intellectual Property Statement .......................... 32 100 Copyright Statement ...................................... 32 101 Acknowledgment ........................................... 33 103 1. Terminology and Definitions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [1]. 109 Some other useful definitions are: 111 Circuit: A circuit is a discrete (specific) path between two or more 112 points along which signals can be carried. In this context, a circuit 113 is a physical path, consisting of one or more wires and possibly 114 intermediate switching points. 116 Trunk: In a network, a trunk is a communication path connecting two 117 switching systems used in the establishment of an end-to-end 118 connection. In selected applications, it may have both its 119 terminations in the same switching system. 121 TrunkGroup: A set of trunks, traffic engineered as a unit, for the 122 establishment of connections within or between switching systems in 123 which all of the paths are interchangeable except where subgrouped. 125 Carrier: A company offering telephone and data communications between 126 points (end-users and/or exchanges). 128 2. Introduction 130 It is assumed that reader of this is familiar with TRIP [2,10]. In 131 typical VoIP networks, Internet Telephony Administrative Domains 132 (ITADs) will deploy numerous gateways for the purposes of 133 geographical diversity, capacity, and redundancy. When a call arrives 134 at the domain, it must be routed to one of those gateways. 135 Frequently, an ITAD will break their network into geographic Points 136 of Presence (POP), with each POP containing some number of gateways, 137 and a proxy server element that fronts those gateways. The Proxy 138 element is a SIP Proxy [9] or H.323 Gatekeeper. The proxy server is 139 responsible for managing the access to the POP, and also for 140 determining which of the gateways will receive any given call that 141 arrives at the POP. In conjunction with the proxy server that routes 142 the call signaling, there are two components, the "Ingress LS" 143 (a.k.a. "TGREP Receiver" and the "Egress LS". The "TGREP Receiver" 144 component maintains TGREP peering relationship with one or more 145 gateways. The routing information received from the gateways are 146 further injected into the Egress LS, which in turn disseminates into 147 the rest of the network on TRIP. For convenience, gateway and GW are 148 used interchangably. 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 optionally performs operations like consolidation and aggregation, 235 hands over the reachability information to a 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 (e.g.: 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 a 256 procedure similar to session establishment in TRIP. After the 257 session establishment, the TGREP Sender sends the reachability 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 possible 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 When the value for the total number of attempted calls wraps around, 485 the counter value for the number of successful calls is reset to keep 486 it aligned with the other component over a given window of time. The 487 TGREP receiver using this information should obtain this information 488 frequently enough to prevent loss of significance. 490 4.3.2. Route Origination and CallSuccess 492 Routes MAY be originated containing the CallSuccess attribute. This 493 attribute is expected to get statistically significant with passage 494 of time as more calls are attempted. It is RECOMMENDED that 495 sufficiently large windows be used to provide a useful aggregated 496 statistic. 498 4.3.3. Route Selection and CallSuccess 500 The CallSuccess attribute MAY be used for route selection. This 501 attribute represents a measure of success of terminating calls to the 502 advertised destination(s). This information MAY be used to select 503 from amongst a set of alternative routes to increase the probability 504 of successful call termination. 506 4.3.4. Aggregation and CallSuccess 508 Not applicable 510 4.3.5. Route Dissemination and CallSuccess 512 Routes MUST NOT be disseminated with the CallSuccess attribute. Its 513 potential to change dynamically does not make it suitable to 514 disseminate. 516 4.4. Prefix Attributes 518 Mandatory: False. 519 Required Flags: Not well-known. 520 Potential Flags: None. 521 TRIP Type Codes: 16 for E164 prefix, 17 for Pentadecimal routing 522 number prefix and 18 for Decimal routing number prefix. 524 The Prefix attribute is used to represent the list of prefixes that 525 the respective route can complete calls to. This attribute is 526 intended to be used with the Carrier or Trunkgroup address family 527 (discussed in Section 3.7). 529 Though it is possible that all prefix ranges may be reachable through 530 a given Carrier, administrative issues could make certain ranges 531 preferable to others. 533 4.4.1. Prefix Attribute Syntax 535 The Prefix attribute could be E.164, Decimal or Pentadecimal (refer 536 to TRIP [2]), each of them having it's own type code. The Prefix 537 attribute is encoded as a sequence of prefix values in the attribute 538 value field. The prefixes are listed sequentially with no padding as 539 shown in Figure 2. Each prefix includes a 2-octet length field that 540 represents the length of the address field in octets. The order of 541 prefixes in the attribute is not significant. 543 The presence of Prefix Attribute with the length field of the 544 attribute as 0 signifies that the TGREP GW can terminate ALL prefixes 545 of that prefix type (E.164, Decimal or Pentadecimal) for the given 546 Reachable route(s). This is not equivalent to excluding the Prefix 547 attribute in the TGREP update. 549 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 . . . 550 +-------------------------------+-----------+------------------------ 551 | Length | Prefix1...| Length |Prefix2 552 +-------------------------------+-----------+------------------------ 554 Figure 2: Prefix Format 556 4.4.2. Route Origination and Prefix 558 Routes MAY be originated containing the Prefix attribute. 560 4.4.3. Route Selection and Prefix 562 The Prefix attribute MAY be used for route selection. 564 4.4.4. Aggregation and Prefix 566 Routes with differing Prefix attribute MUST NOT be aggregated. 567 Routes with the same value in the Prefix attribute MAY be aggregated 568 and the same Prefix attribute attached to the aggregated object. 570 4.4.5. Route Dissemination and Prefix 572 The LS receiving this attribute should disseminate to other peers, 573 both internal and external to the ITAD. 575 4.5. TrunkGroup Attribute 577 Mandatory: False. 578 Required Flags: Not well-known. 579 Potential Flags: None. 580 TRIP Type Code: 20. 582 The TrunkGroup attribute is used to represent the list of trunkgroups 583 on the gateway used to complete calls. It enables providers to route 584 calls to destinations through preferred trunks. This attribute is 585 relatively static. 587 4.5.1. TrunkGroup Syntax 589 The TrunkGroup attribute is a variable length attribute that is 590 composed of a sequence of trunkgroup identifiers. It indicates that 591 the gateway can complete the call through any trunkgroup identifier 592 indicated in the sequence. 594 Each trunkgroup identifier is encoded as a length-value field (shown 595 in Figure 3 below). The length field is a 1-octet unsigned numeric 596 value. The value field is a variable length field consisting of two 597 sub-fields, a trunk group label followed by a trunk context, the two 598 sub-fields separated by the delimiter ";" (semicolon). Both the trunk 599 group label and the trunk context sub-fields are of variable length. 600 The length field represents the total size of the value field 601 including the delimiter. 603 The permissible character set for the trunk group label and the trunk 604 group context sub-fields and the associated ABNF [8] is per rules 605 outlined in [4]. 607 The presence of TrunkGroup attribute with the length field of the 608 attribute as 0 signifies that the TGREP GW can terminate ALL 609 trunkgroup for the given Reachable route(s). 611 0 1 612 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 ... 613 +---------------+--------------------+---------------+--------------- 614 | Length | TrunkGroup 1... | Length |TrunkGroup 2... 615 +---------------+--------------------+---------------+--------------- 616 Figure 3: TrunkGroup Syntax 618 4.5.2. Route Origination and TrunkGroup 620 Routes MAY be originated containing the TrunkGroupattribute. 622 4.5.3. Route Selection and TrunkGroup 624 The TrunkGroup attribute MAY be used for route selection. Certain 625 trunkgroups MAY be preferred over others based on provider policy. 627 4.5.4. Aggregation and TrunkGroup 629 Routes with differing TrunkGroup attribute MUST NOT be aggregated. 630 Routes with the same value in the TrunkGroup attribute MAY be 631 aggregated and the same TrunkGroup attribute attached to the 632 aggregated object. 634 4.5.5. Route Dissemination and TrunkGroup 636 This attribute is not expected to change frequently. Hence, the LS 637 receiving this attribute MAY disseminate it to other peers, internal 638 to ITAD. Routes SHOULD not be disseminated external to the ITAD, with 639 TrunkGroup attribute. 641 4.6. Carrier Attribute 643 Mandatory: False. 644 Required Flags: Not well-known. 645 Potential Flags: None. 646 TRIP Type Code: 19. 648 The Carrier attribute is used to represent the list of carriers that 649 the gateway uses to complete calls. It enables providers to route 650 calls to destinations through preferred carriers. This attribute is 651 relatively static. 653 4.6.1. Carrier Syntax 655 The Carrier attribute is a variable length attribute that is composed 656 of a sequence of carrier identifiers. It indicates that the route 657 can complete the call to any of the carriers represented in the 658 sequence of carrier identifiers [11]. 660 Each carrier identifier is encoded as a length-value field (shown in 661 Figure 4 below). The length field is a 1-octet unsigned numeric 662 value. The value field is a variable length field. 664 The permissible character set for the value field and the associated 665 ABNF [9] is per rules outlined in [5]. Specifically, it carries 666 "global-cic" or "local-cic" [5]. In case of "local-cic", the 667 "phonedigit-hex" part and the "cic-context" part would be separated 668 by the delimiter ";". Hence, absence or presence of the delimiter can 669 be used to determine if the value is a "global-cic" or a "local-cic". 670 The length field represents the total size of the value field 671 including the delimiter. 673 The presence of Carrier Attribute with the length field of the 674 attribute as 0 signifies that the TGREP GW can terminate ALL Carriers 675 for the given Reachable route(s). 677 0 1 678 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 ... 679 +---------------+--------------------+---------------+-------------- 680 | Length | Carrier 1... | Length | Carrier 2... 681 +---------------+--------------------+---------------+-------------- 682 Figure 4: Carrier Syntax 684 4.6.2. Route Origination and Carrier 686 Routes MAY be originated containing the Carrier attribute. 688 4.6.3. Route Selection and Carrier 690 The Carrier attribute MAY be used for route selection. Certain 691 carriers MAY be preferred over others based on provider policy. 693 4.6.4. Aggregation and Carrier 695 Routes with differing Carrier attribute MUST NOT be aggregated. 696 Routes with the same value in the Carrier attribute MAY be aggregated 697 and the same Carrier attribute attached to the aggregated object. 699 4.6.5. Route Dissemination and Carrier 701 This attribute is not expected to change frequently. Hence, the LS 702 receiving this attribute MAY disseminate it to other peers, both 703 internal and external to the ITAD. 705 5. TrunkGroup and Carrier Address Families 707 As described in TRIP [2], the address family field gives the type of 708 address for the route. Two new address families and their codes are 709 defined in this Section: 711 Code Address Family 712 4 TrunkGroup 713 5 Carrier 715 When a set of GWs are to be managed at the granularity of carriers or 716 trunkgroups then it may be more appropriate for a GW to advertise 717 routes using the Carrier address family or trunkgroup address family 718 respectively. Also, in a TGREP association between the gateway and 719 the LS responsible for managing that gateway, there are some 720 attributes that more naturally fit in as advertised properties of 721 trunkgroups or carriers rather than that of advertised prefixes; for 722 example, the AvailableCircuit information on a particular trunkgroup 723 or a particular carrier. To express this relationship, the existing 724 TRIP address families are inadequate. We need separate address 725 families that can associate certain properties like AvailableCircuits 726 information to trunkgroups or carriers. 728 The primary benefits of this model are as follows: 730 - It allows a service provider to route calls based strictly on the 731 trunkGroups or carriers. 732 - It facilitates more accurate reporting of attributes of a dynamic 733 nature like AvailableCircuits by providing the ability to manage 734 resources at the granularity of a trunkgroup or a carrier. 735 - It enables scalability as gateways can get really large with the 736 ability to provision hundreds or a few thousand circuits and this 737 can increase the potential for traffic that reports dynamic 738 resource information between the gateway and the LS. The model 739 introduced can potentially alleviate this UPDATE traffic hence 740 increasing efficiency and providing a scalable gateway 741 registration model. 743 5.1. Address Family Syntax 745 Consider the generic TRIP route format from TRIP[2] shown below. 747 0 1 2 3 748 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 749 +---------------+---------------+---------------+---------------+ 750 | Address Family | Application Protocol | 751 +---------------+---------------+---------------+---------------+ 752 | Length | Address (variable) ... 753 +---------------+---------------+---------------+---------------+ 755 Figure 5: Generic TRIP Route Format 757 The Address Family field will be used to represent the type of the 758 address associated for this family, which is based on the TrunkGroup 759 or Carrier. The codes for the new address families will be allocated 760 by IANA. 762 The code for the trunk group address family is 4 and the code for the 763 carrier address family is 5. 765 The Application Protocol field is the same as the one for the 766 Decimal, Pentadecimal and E.164 address families defined in TRIP[2]. 767 The Length field represents the total size of the Address field in 768 bytes. 770 The value in the Address field represents either the TrunkGroup or 771 the Carrier address families and the syntax is as follows: 773 For the TrunkGroup Address Family, the Address field represents a 774 Trunkgroup value that is defined as specified in an earlier Section 775 4.5.1 about the TrunkGroup Attribute. 777 For the Carrier Address Family, the Address field represents a 778 Carrier value. This is the same as the value field specified in an 779 earlier Section 4.6.1 about the Carrier Attribute. 781 The above mentioned address families are not hierarchical, but flat. 782 If a gateway supports any of these address families, it should 783 include that address family as one of the Route types supported in 784 the OPEN message capability negotiation phase. 786 The following attributes are currently defined to be used with all 787 the address families including the TrunkGroup and Carrier address 788 families. 790 - AvailableCircuits Attribute 791 - TotalCircuitCapacity Attribute 792 - CallSuccess Attribute 794 It is recommended that the above three attributes be used by the 795 gateway with the TrunkGroup or Carrier address families, if possible. 796 This will potentially offer a more efficient resource reporting 797 framework, and a scalable model for gateway provisioning. 799 However, when the gateway is not using TrunkGroup or Carrier address 800 family, it MAY use the above attributes with the Decimal, 801 Pentadecimal and E.164 address families. 803 The prefix attribute cannot be used when the address family is E164 804 numbers, Pentadecimal routing numbers or Decimal routing numbers. 806 The Carrier attribute cannot be used if the address family type is 807 Carrier. 809 The TrunkGroup attribute cannot be used if the address family type is 810 TrunkGroup. 812 6. Gateway Operation 814 A gateway uses TGREP to advertise its reachability to its domain's 815 Location Server(s) (LS, which are closely coupled with proxies). The 816 gateway operates in TRIP Send Only mode since it is only interested 817 in advertising its reachability, but is not interested in learning 818 about the reachability of other gateways and other domains. Also, the 819 gateway will not create its own call routing database. In this 820 section we describe the operation of TGREP on a gateway. 822 6.1. Session Establishment 824 When opening a peering session with a TGREP Receiver, a TGREP gateway 825 follows exactly the same procedures as any other TRIP entity. The 826 TGREP gateway sends an OPEN message which includes a Send Receive 827 Capability in the Optional Parameters. The Send Receive Capability is 828 set by the gateway to Send Only. The OPEN message also contains the 829 address families supported by the gateway. The remainder of the peer 830 session establishment is identical to TRIP. 832 6.2. UPDATE Messages 834 Once the peer session has been established, the gateway sends UPDATE 835 messages to the TRIP LS with the gateway's entire reachability. The 836 Gateway also sends any attributes associated with the routes. 838 TGREP processing of the UPDATE message at the gateway is identical to 839 UPDATE processing in TRIP[2]. A TGREP sender MUST support all 840 mandatory TRIP attributes. 842 6.3. KEEPALIVE Messages 844 KEEPALIVE messages are periodically exchanged over the peering 845 session between the TGREP gateway and the TRIP LS as specified in 846 Section 4.4 of TRIP [2]. 848 6.4. Error Handling and NOTIFICATION Messages 850 The same procedures used with TRIP are used with TGREP for error 851 handling and generating NOTIFICATION messages. The only difference is 852 that a TGREP gateway will never generate a NOTIFICATION message in 853 response to an UPDATE message, irrespective of the contents of the 854 UPDATE message. Any UPDATE message is silently discarded. 856 6.5. TGREP Finite State Machine 858 When the TGREP finite state machine is in the Established state and 859 an UPDATE message is received, the UPDATE message is silently 860 discarded and the TGREP gateway remains in the Established state. 861 Other than that the TRIP finite state machine and the TGREP finite 862 state machine are identical. 864 6.6. Call Routing Databases 866 A TGREP gateway may maintain simultaneous sessions with more than one 867 TRIP LSs. A TGREP gateway maintains one call routing database per 868 peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out, 869 and hence we will call them Adj-TRIB-GWs-Out. An Adj-TRIB-GW-Out 870 contains the gateway's reachability information advertised to its 871 peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is 872 outside the scope of this draft (possibly by manual configuration). 874 The TGREP gateway does not have databases equivalent to TRIP's Adj- 875 TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn 876 routes from its peer TRIP LSs, and hence it does not run call route 877 selection. 879 6.7. Multiple Address Families 881 As mentioned above, TGREP supports various address families in order 882 to convey the reachability of telephony destinations. A TGREP session 883 MUST NOT send UPDATEs of more than one of the following categories 884 (a) Prefix Address families (E164, Pentadecimal and decimal) (b) 885 Trunkgroup address family (c) Carrier Address family for a given 886 established session. TGREP should specify its choice address family 887 through the route-type capability in the OPEN message. And route-type 888 specification in the OPEN message violating the above rule should be 889 rejected with a NOTIFICATION message. 891 6.8. Route Selection and Aggregation 893 TRIP's route selection and aggregation operations MUST NOT be 894 implemented by TGREP gateways. 896 7. LS/Proxy Behavior 898 As mentioned earlier, TGREP can be considered as a protocol 899 complimentary to TRIP in providing reachability information which can 900 then be further fed into the Location Server. The architecture of an 901 LS/Proxy system is as follows: There exists a TRIP LS application 902 that functions as a speaker in the I-TRIP/E-TRIP network as 903 documented in TRIP [2]. This component is termed as "LS-Egress" for 904 the purposes of this discussion. Then, there is a signaling server 905 fronting a set of gateways. In conjunction with this signaling 906 server, is also a second component operating in receive mode, that 907 peers with one more gateways, each of them using TGREP to advertise 908 routing information. This component on the receiving end of one or 909 more TGREP sessions is termed as the "LS-Ingress" or "TGREP Receiver" 910 for the purposes of this discussion. Also, the entity (typically, a 911 Gateway) advertising the routes on the TGREP session is termed as the 912 "TGREP Sender". The "TGREP Receiver" receiving the TRIP messages 913 takes the resulting routing information from each gateway, and 914 "exports" it to another process we define below, that performs 915 consolidation and aggregation, in that order. These operations would 916 take as input the collective set of routes from all the gateways. 917 Subsequently, the resulting TRIB is passed as input into the LS- 918 Egress process as shown below, that can then disseminate these via 919 TRIP. The interface between the TGREP Receiver(aka. LS-Ingress) 920 peering with the GW(s) and the TRIP LS (LS-Egress) is entirely a 921 local matter. 923 The nature of the Consolidation and Aggregation operations and the 924 accompanying motivation are described in the subsections below. The 925 order in which the operations are listed represents an implicit 926 logical sequence in which they are applied. The architecture for an 927 LS/Proxy entity is shown in Figure 6 below. 929 +-------------------------------------------------------+ 930 | +-------------------------------+ | 931 | | +-+ +-+ | | TGREP 932 | | |A| |C| | | +-----+ 933 | | |g| |o| | | | | 934 | +-------------+ | |g| |n| +-------------+ | | --| GW | 935 | | | | |r| |s| | | | | +-----+ 936 | | TRIP | | |e| |o| | | | +--- 937 | | LS <----------|g<--|l<--- TGREP |-++-| +-----+ 938 | | | | |a| |i| | Session | | | | | 939 | | (I-TRIP/ | | |t| |d| | Management |-++-+----| GW | 940 | | E-TRIP) | | |i| |a| | | | | +-----+ 941 | | (LS-Egress) | | |o| |t| | |-+ +--- 942 | +-----------/-+ | |n| |i| +-------------+ | | +-----+ 943 | / | | | |o| | | --| | 944 | / | | | |n| (LS-Ingress) | | | GW | 945 | / | +-+ +-+ | | +-----+ 946 | / | TGREP Receiver | | 947 | / +-------------------------------+ | 948 | / | 949 | / | 950 +-------/-----------------------------------------------+ 951 / LS/Proxy 952 / 953 / 954 / 955 / 956 / 957 +/----------------+ 958 | | 959 | | 960 | | 961 | LS | 962 | | 963 | | 964 | | 965 | | 966 | | 967 +-----------------+ 969 Figure 6: LS Architecture for TRIP-GW 971 7.1. Route consolidation 973 The TGREP receiver (LS-Ingress) may receive routing information from 974 one or more gateways. It is possible that multiple routes are 975 available for the same destination. These different alternative 976 routes may be received from the same gateway, or from multiple 977 gateways. It is RECOMMENDED that the set of gateway routes for each 978 destination be consolidated, before presenting a candidate route, to 979 the LS-Egress entity. The motivation for this operation should be to 980 define a route that can maximally represent the collective routing 981 capabilities of the set of gateways, managed by this TGREP receiver. 982 Let us take an example scenario in order to bring out the motivation 983 for this operation. Let us say, the TGREP receiver maintains peering 984 sessions with gateways A, and B. 986 - Gateway A advertises a route for destination "SIP 408" on the 987 E.164 address family with the Carrier attribute value C1. 989 - Gateway B advertises a route for destination "SIP 408" on the 990 E.164 address family with Carrier attribute value C2. 992 The TGREP receiver that receives these routes can consolidate 993 these constituent routes into a single route for destination "SIP 994 408" with its Carrier attribute being a union of the Carrier 995 attribute values of the individual routes, namely, "C1 C2". This 996 operation is referred to as Consolidation. In the above example, 997 it is possible that a route to the destination "SIP 408" through 998 one or more carriers may have been lost if the individual routes 999 were not consolidated. 1001 Another example is to consolidate the Prefix attribute from 1002 multiple Carrier or Trunkgroup updates received from different 1003 gateways for the same destination. Let us say, there are Carrier 1004 AF updates from two gateways for Carrier destination X, and the 1005 prefix attribute values are {408, 650} from one update and {919, 1006 973} from the other. The prefix values from these two updates can 1007 be consolidated into a single Carrier AF route advertisement with 1008 prefix value {408, 650, 919, 973}. 1010 In general, there is a potential for loss of gateway routing 1011 information when TGREP routes from a set of gateways are not 1012 consolidated when a candidate route is presented to the TRIP LS. 1013 The specifics of applying the consolidation operation to 1014 different attributes and routes from different address families, 1015 is left to the individual TGREP receiver implementations. 1017 7.2. Aggregation 1019 The set of gateway routes, that are in a consolidated form or 1020 otherwise, may be aggregated before importing it to the LS instance 1021 which is responsible for I-TRIP/E-TRIP processing (LS-Egress). This 1022 operation follows the standard aggregation procedures described in 1023 the TRIP [2], while adhering to the aggregation rules for each route 1024 attribute. 1026 7.3. Consolidation v/s Aggregation 1028 To highlight the difference between the two operations discussed 1029 above, "Consolidation" combines multiple routes for the same route 1030 destination, whereas "Aggregation" combines routes for different 1031 route destinations that qualify as candidates to be summarized 1032 resulting in route information reduction. 1034 To take an example, if there are multiple gateways offering routes to 1035 an E.164 destination "408" but with possibly different attributes 1036 (e.g.: Carrier), the LS/Proxy can combine these to form one route for 1037 "408" but representing the attribute information collectively. This 1038 process is Consolidation. 1040 If, for example, the LS/Proxy receives routes for 4080, 4081, 4082, 1041 ... 4089 from amongst a set of gateways, it could aggregate these 1042 different candidate routes to have a summarized route destination 1043 "408" with each of the attributes computed using the Aggregation 1044 procedures defined in the TRIP. 1046 8. Security Considerations 1048 The Security considerations for TGREP are identical to that 1049 identified in TRIP [2] and are just restated here for the purposes of 1050 clarity. 1052 The security mechanism for the peering session between TGREP GW and a 1053 TRIP LS, in an IP network, is IPsec [3]. IPsec uses two protocols to 1054 provide traffic security: Authentication Header (AH) [6] and 1055 Encapsulating Security Payload (ESP) [7]. 1057 The AH header affords data origin authentication, connectionless 1058 integrity and optional anti-replay protection of messages passed 1059 between the peer LSs. The ESP header provides origin authentication, 1060 connectionless integrity, anti-replay protection, and confidentiality 1061 of messages. 1063 Implementations of the protocol defined in this document employing 1064 the ESP header SHALL comply with section 3.1.1 of [13], which defines 1065 a minimum set of algorithms for integrity checking and encryption. 1066 Similarly, implementations employing the AH header SHALL comply with 1067 section 3.2 of [13], which defines a minimum set of algorithms for 1068 integrity checking. 1070 Implementations SHOULD use IKEv2 [7] to permit more robust keying 1071 options. Implementations employing IKEv2 SHOULD support 3DES-CBC for 1072 confidentiality and HMAC-SHA1 for integrity. 1074 A Security Association (SA) [3] is a simplex "connection" that 1075 affords security services to the traffic carried by it. Security 1076 services are afforded to a SA by the use of AH, or ESP, but not both. 1077 Two types of SAs are defined: transport mode and tunnel mode. A 1078 transport mode SA is a security association between two hosts, and is 1079 appropriate for protecting the TRIP session between two peer LSs. 1081 9. IANA Considerations 1083 Both TRIP[2] and TGREP share the same IANA registry for Capabilities, 1084 Attributes, Address Families, and Application Protocols. This 1085 specification requests that IANA add the following attribute codes 1086 and address family codes to the TRIP [2] registries. 1088 9.1. Attribute Codes 1090 The Attribute Type Codes to be assigned for the new attributes 1091 defined in this document are listed below: 1093 | Code Attribute Reference 1094 | ---- --------- --------- 1095 | 13 TotalCircuitCapacity [RFCXXXX] 1096 | 14 AvailableCircuits [RFCXXXX] 1097 | 15 CallSuccess [RFCXXXX] 1098 | 16 E.164 Prefix [RFCXXXX] 1099 | 17 Pentadecimal Routing Number Prefix [RFCXXXX] 1100 | 18 Decimal Routing Number Prefix [RFCXXXX] 1101 | 19 TrunkGroup [RFCXXXX] 1102 | 19 Carrier [5] 1104 [NOTE TO RFC-ED: please replace XXXX with the rfc number of this 1105 specification ] 1107 9.2. Address Family Codes 1109 The following subsections show the codes to be assigned for the two 1110 new address families introduced in this document 1112 9.2.1. TrunkGroup Address Family 1114 | Code Address Family Reference 1115 | ---- -------------- --------- 1116 | 4 TrunkGroup [RFCXXXX] 1118 [NOTE TO RFC-ED: please replace XXXX with the rfc number of this 1119 specification ] 1121 9.2.2. Carrier Address Family 1123 | Code Address Family Reference 1124 | ---- -------------- --------- 1125 | 5 Carrier [RFCXXXX] 1127 [NOTE TO RFC-ED: please replace XXXX with the rfc number of this 1128 specification ] 1130 10. Change history 1132 [[NOTE TO RFC-ED: Please remove this section prior to publication]] 1134 10.1. Changes since draft-ietf-iptel-tgrep-03.txt 1136 - No change in content. Releasing a new revision for renewal of 1137 draft. 1139 10.2. Changes since draft-ietf-iptel-tgrep-02.txt 1141 - No change in content. Releasing a new revision for renewal of 1142 draft. 1144 10.3. Changes since draft-ietf-iptel-tgrep-01.txt 1146 - Added a "Security Considerations" Section to the document. 1147 - Strengthened the text under "LS/Proxy Behavior" regarding 1148 Consolidation and Aggregation with additional examples for better 1149 clarity. 1150 - Removed the section "Other Attributes" including its subsection 1151 on the "Pricing" attribute. 1152 - Modified the definition of Carrier in the "Carrier attribute" and 1153 "TrunkGroup and Carrier Address Families" sections respectively. 1154 - Rectified the section number references in the "IANA 1155 Considerations" Section. 1156 - Strengthened the text in the attribute sections regarding 1157 dissemination of attributes received on TGREP. 1158 - Updated the "References" section. 1159 - Corrected typos, nits, grammatical errors, and language of the 1160 text throughout the document based on feedback from the iptel 1161 community. 1163 10.4. Changes since draft-ietf-iptel-tgrep-00.txt 1165 - Added recommendations for AvailableCircuits and CallSuccess 1166 attributes. 1167 - Updated Carrier Attribute with ASCII syntax. 1168 - Removed thresholding scheme description. 1169 - Updated author addresses. 1171 10.5. Changes since draft-ietf-iptel-trip-gw-00.txt 1173 - Changed title of the document to TGREP (Telephony Gateway 1174 REgistration Protocol). 1175 - Changed name of protocol described in this document to TGREP. 1176 - Changed Abstract and Introduction sections to position TGREP as 1177 an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP). 1178 - Modified the section on LS/Proxy Behavior including the diagram. 1179 - Added an additional example to the Route Consolidation section. 1180 - Changed the format of Carrier (both as an attribute and as an AF) 1181 to accommodate representation of Country codes in association 1182 with CICs. 1183 - Updated text to allow Carrier attribute in TrunkGroup address 1184 family and TrunkGroup attribute in Carrier address family. 1186 10.6. Changes since -03 1188 - Removed Carrier-Trunkgroup attribute and address family and 1189 references to it. 1190 - Added Terminology and Definitions section. 1191 - Updated CallSuccess attribute. 1192 - Added Prefix attribute. 1193 - Added Carrier attribute. 1194 - Added TrunkGroup attribute. 1195 - Added TrunkGroup Address Family. 1196 - Added Carrier Address Family. 1197 - Added some more references. 1199 10.7. Changes since -02 1201 - Removed the requirements section. 1202 - Discussed the motivation for introducing Carrier information into 1203 TRIP. 1204 - Defined a new attribute for the E.164 address family. 1205 - Defined a new address family for CarrierCode-TrunkGroup 1206 combination . 1207 - Defined new attributes to advertise dynamic gateway 1208 characteristics like resource availability, and call success 1209 rate. 1210 - Added as section to validate the TGREP solution against the 1211 requirements in [6]. 1213 10.8. Changes since -01 1215 - Added requirements. 1216 - Added more formal analysis of REGISTER and added analysis of SLP. 1217 - Removed circuit capacity attribute. 1219 10.9. Changes since -00 1221 - Added text to stress the value of this proposal for managing a 1222 gateway cluster. 1223 - Added attributes for circuit capacity and DSP capacity. 1224 - Added section on LS operation, discussing aggregation issue. 1226 11. Acknowledgments 1228 We wish to thank Vijay Gurbani, Li Li, Kevin McDermott, David Oran, 1229 Bob Penfield, Jon Peterson, Anirudh Sahoo and James Yu for their 1230 insightful comments and suggestions. 1232 12. References 1234 12.1. Normative References 1236 [1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement 1237 Levels", BCP 14, RFC 2119, March 1997. 1239 [2] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over 1240 IP (TRIP)," Request for Comments 3219, Internet Engineering Task 1241 Force, January 2002. 1243 [3] Kent, S. and Seo K., "Security Architecture for the Internet 1244 Protocol", RFC 4301, December 2005. 1246 [4] V. Gurbani and C. Jennings, "Representing trunk groups in tel/sip 1247 Uniform Resource Identifiers (URIs)," Internet Draft, Internet 1248 Engineering Task Force, August 2006. 1250 [5] J. Yu, "Number Portability Parameters for the "tel" URI", RFC 1251 4694, October 2006. 1253 [6] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 1255 [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1256 December 2005. 1258 [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1259 Specifications: ABNF", RFC 4234, October 2005. 1261 12.2. Informative References 1263 [9] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 1264 session initiation protocol," Request for Comments 3261, Internet 1265 Engineering Task Force, Mar. 1999. 1267 [10] J. Rosenberg and H. Schulzrinne, "A framework for telephony 1268 routing over IP," Request for Comments 2871, Internet Engineering 1269 Task Force, June 2000. 1271 [11] ITU-T List of ITU Carrier Codes (published periodically in the 1272 ITU-T Operational Bulletin). 1274 [12] J. Rosenberg, "Requirements for Gateway Registration," Internet 1275 Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. 1277 [13] D. Eastlake, "Cryptographic Algorithm Implementation 1278 Requirements for Encapsulating Security Payload (ESP) and 1279 Authentication Header (AH)", RFC 4305, December 2005. 1281 Authors' Addresses 1283 Manjunath Bangalore 1284 Cisco Systems Inc. 1285 Mail Stop SJC-14/2/1 1286 3625 Cisco Way 1287 San Jose, CA 95134 1288 Phone: +1-408-525-7555 1289 email: manjax@cisco.com 1291 Rajneesh Kumar 1292 Cisco Systems Inc. 1293 Mail Stop SJC-14/4/2 1294 3625 Cisco Way 1295 San Jose, CA 95134 1296 Phone: +1-408-527-6148 1297 email: rajneesh@cisco.com 1299 Jonathan Rosenberg 1300 Cisco Systems Inc. 1301 Mail Stop PPY02/2 1302 600 Lanidex Plaza 1303 Parsippany 1304 NJ 07054 1305 Phone: +1-973-952-5060 1306 email: jdrosen@cisco.com 1308 Hussein F. Salama 1309 Citex Software Ltd. 1310 4 Dr. Soliman Square 1311 Dokki, Giza 12311 1312 Egypt 1313 Phone: +20-2-33371672/+1-425-7497286 1314 email: h.f.salama@ieee.org 1315 Dhaval N. Shah 1316 Moowee Inc. 1317 4920 El Camino Real, 1318 Los Altos 1319 CA 94022 1320 Phone: +1-408-307-7455 1321 email: dhaval@moowee.tv 1323 Intellectual Property Statement 1325 The IETF takes no position regarding the validity or scope of any 1326 Intellectual Property Rights or other rights that might be claimed to 1327 pertain to the implementation or use of the technology described in 1328 this document or the extent to which any license under such rights 1329 might or might not be available; nor does it represent that it has 1330 made any independent effort to identify any such rights. Information 1331 on the procedures with respect to rights in RFC documents can be 1332 found in BCP 78 and BCP 79. 1334 Copies of IPR disclosures made to the IETF Secretariat and any 1335 assurances of licenses to be made available, or the result of an 1336 attempt made to obtain a general license or permission for the use of 1337 such proprietary rights by implementers or users of this 1338 specification can be obtained from the IETF on-line IPR repository at 1339 http://www.ietf.org/ipr. 1341 The IETF invites any interested party to bring to its attention any 1342 copyrights, patents or patent applications, or other proprietary 1343 rights that may cover technology that may be required to implement 1344 this standard. Please address the information to the IETF at ietf- 1345 ipr@ietf.org. 1347 Copyright Statement 1349 Copyright (C) The IETF Trust (2007). This document is subject to the 1350 rights, licenses and restrictions contained in BCP 78, and except as 1351 set forth therein, the authors retain all their rights. 1353 This document and the information contained herein are provided on an 1354 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1355 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1356 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1357 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1358 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1359 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1361 Acknowledgment 1363 Funding for the RFC Editor function is currently provided by the 1364 Internet Society.