idnits 2.17.1 draft-ietf-iptel-tgrep-04.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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1160. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1144. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1150. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1166), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 39 instances of too long lines in the document, the longest one being 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 325 has weird spacing: '...s to be deter...' == Line 388 has weird spacing: '...refixes that...' == Line 393 has weird spacing: '...ges may be re...' == Line 466 has weird spacing: '...nkgroup for t...' == Line 584 has weird spacing: '...anaging that ...' == (1 more instance...) == 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) == Unused Reference: '2' is defined on line 1102, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1106, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1114, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1124, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2871 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 11 errors (**), 0 flaws (~~), 14 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPTEL Working Group Manjunath Bangalore, Cisco Systems 2 Internet Draft Rajneesh Kumar, Cisco Systems 3 draft-ietf-iptel-tgrep-04.txt Jonathan Rosenberg, dynamicsoft 4 October 21, 2004 Hussein Salama, Cisco Systems 5 Expiration Date: April 21, 2005 Dhaval N. Shah, Cisco Systems 7 A Telephony Gateway REgistration Protocol (TGREP) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 21, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document describes the Telephony Gateway Registration Protocol 43 (TGREP) for registration of telephony prefixes supported by telephony 44 gateways and soft switches. The registration mechanism can also be 45 used to export resource information. The prefix and resource 46 information can then be passed on to a TRIP Location Server, which in 47 turn can propogate that routing information within and between 48 internet telephony administrative domains (ITAD). TGREP shares a lot 49 of similarites with the TRIP Protocol. It has similar procedures and 50 Finite State Machine for session establishment. It also shares the 51 same format for messages and a subset of attributes with TRIP. 53 1. Terminology and Definitions 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [1]. 59 Some other useful definitions are: 61 Circuit: A circuit is a discrete (specific) path between two or more 62 points along which signals can be carried. In this context, a circuit 63 is a physical path, consisting of one or more wires and possibly 64 intermediate switching points. 66 Trunk: In a network, a communication path connecting two switching 67 systems used in the establishment of an end-to-end connection. In 68 selected applications, it may have both its terminations in the same 69 switching system. 71 TrunkGroup: A set of trunks, traffic engineered as a unit, for the 72 establishment of connections within or between switching systems in 73 which all of the paths are interchangeable except where subgrouped. 75 Carrier: A company offering telephone and data communications between 76 points (end-users and/or exchanges). 78 2. Introduction 80 In typical VoIP networks, Internet Telephony Administrative Domains 81 (ITADs) will deploy numerous gateways for the purposes of 82 geographical diversity, capacity, and redundancy. When a call arrives 83 at the domain, it must be routed to one of those gateways. 84 Frequently, an ITAD will break their network into geographic POPs, 85 with each POP containing some number of gateways, and a proxy server 86 element that fronts those gateways. The proxy server is responsible 87 for managing the access to the POP, and also for determining which of 88 the gateways will receive any given call that arrives at the POP. 90 This configuration is depicted graphically in Figure 1. 92 +---------+ 93 | | 94 | GW | 95 -> +---------+ 96 // 97 // 98 // +---------+ 99 // | | 100 // | GW | 101 // +---------+ 102 // 103 +----------+ // TO PSTN 104 | | / +---------+ 105 | Routing | ---------------> | | -----> 106 -------->| Proxy | | GW | 107 | | -- +---------+ 108 | | -- 109 +----------+ -- 110 --- +---------+ 111 -- | | 112 -- | GW | 113 -- +---------+ 114 --> 116 +---------+ 117 | | 118 | GW | 119 +---------+ 121 Figure 1: Gateway and LS Configuration 123 The decision about which gateway to use depends on many factors, 124 including their availability, remaining call capacity and call 125 success statistics to a particular PSTN destination. For the proxy to 126 do this adequately, it needs to have access to this information in 127 real-time, as it changes. This means there must be some kind of 128 communications between the proxy and the gateways to convey this 129 information. 131 In this document, we specify a protocol for registration of routes 132 (destinations) supported by the gateway to the TRIP Location Server, 133 known as Telephony Gateway REgistration Protocol (TGREP). TGREP 134 Protocol can be considered an auxiliary protocol to TRIP. Routes 135 learnt through TGREP can be injected into and further processed 136 and/or propogated by the TRIP Location Server. 138 TGREP shares a lot of commonality with TRIP in various aspects. 140 Particularly, TGREP and TRIP have the same session establishment 141 procedures, state machine, etc. TGREP also makes use of a similar 142 UPDATE message to propogate the routes supported. It uses 143 Notification, Keepalive and OPEN message in the same essence as TRIP. 144 TGREP defines few new attributes that are needed to specify certain 145 characteristics of gateways, like Available Capacity for a 146 destination. The document aims at specifying all the attributes 147 related to the TGREP session. This document also specifies some new 148 address families which can be useful in advertising the information 149 on the GWs. 151 As a general rule, because of lot of similarities between TRIP and 152 TGREP, frequent reference will be made to the terminologies and 153 formats defined in TRIP RFC[4]. It is suggested that the reader be 154 familiar with the concepts of TRIP like attributes, flags, route 155 types, address families, etc. 157 3. Defining TGREP 159 TGREP is a route registration protocol for telephony destinations on 160 a gateway. These telephony destinations could be prefixes, trunk 161 groups or Carriers. The Speaker of TGREP resides on the GW and 162 gathers all the information from the GW to relay to the other side. A 163 TGREP Receiver is defined, which receives this information and after 164 certain optional operations like consolidation and aggregation. 165 (defined in Sections 3.10.1 and 3.10.2) hands over the reachability 166 information a to TRIP Location Server. 168 The TGREP speaker establishes a session to the TGREP Receiver using 169 the procedures similar to session establishment in TRIP. The TGREP 170 Speaker is however, in "Send only" mode and the receiver is in the 171 "Receive only" mode. After the session establishment the TGREP 172 speaker sends the reachibility informaton in the UPDATE messages. The 173 UPDATE messages have the same format as in TRIP. However, certain 174 TRIP attributes are not relevant in TGREP; a TGREP speaker MAY ignore 175 them if they are present in a TGREP message. In addition, TGREP 176 defines the new attributes described in this document to be carried 177 in a TGREP UPDATE message. 179 In the rest of the document we specify attributes and address 180 families used in TGREP. We also specify the operations of 181 consolidation and aggregation as they apply to the UPDATEs received 182 from the TGREP Gateway by the TGREP Receiver. 184 A TGREP UPDATE supports the following attributes: 185 1. WithdrawnRoutes (as defined in TRIP) 186 2. ReachableRoutes (as defined in TRIP) 187 3. NexthopServer (as defined in TRIP) 188 4. TotalCircuitCapacity 189 5. AvailableCircuits 190 6. CallSuccess 191 7. Prefix 192 8. TrunkGroup 193 9. Carrier 195 3.1. TotalCircuitCapacity Attribute 197 Mandatory: False. 198 Required Flags: Not well-known. 199 Potential Flags: None. 200 TRIP Type Code: 13 (To be assigned by IANA) 202 The TotalCircuitCapacity identifies the total number of PSTN circuits 203 that are available on a route to complete calls. It is used in 204 conjunction with the AvailableCircuits attribute in gateway selection 205 by the LS. The total number of calls sent to the specified route on 206 the gateway cannot exceed this total circuit capacity under steady 207 state conditions. 209 The TotalCircuitCapacity attribute is used to reflect the 210 administratively provisioned capacity as opposed to the availability 211 at a given point in time as provided by the AvailableCircuits 212 attribute. Because of its relatively static nature, this attribute 213 MAY be propogated beyond the LS that receives it. 215 TotalCircuitCapacity represents the total number of active calls at 216 any instant. This is not expected to change frequently. This can 217 change, for instance, when certain telephony trunks on the gateway 218 are taken out of service for maintenance purposes. 220 3.1.1. TotalCircuitCapacity Syntax 222 The TotalCircuitCapacity attribute is a 4-octet unsigned numeric 223 value. It represents the total number of circuits available for 224 terminating calls through this advertised route. This attribute 225 represents a potentially achievable upper bound on the number of 226 calls which can be terminated on this route in total. 228 3.1.2. Route Origination and TotalCircuitCapacity 230 Routes MAY be originated containing the TotalCircuitCapacity 231 attribute. 233 3.1.3. Route Selection and TotalCircuitCapacity 235 The TotalCircuitCapacity attribute MAY be used for route selection. 236 Since one of its primary applications is load balancing, an LS will 237 wish to choose a potentially different route (amongst a set of routes 238 for the same destination), on a call by call basis. This can be 239 modeled as re-running the decision process on the arrival of each 240 call. The aggregation and dissemination rules for routes with this 241 attribute ensure that re-running this selection process never results 242 in propagation of a new route to other peers. 244 3.1.4. Aggregation and TotalCircuitCapacity 246 An LS MAY aggregate routes to the same prefix which contain a 247 TotalCircuitCapacity attribute. It SHOULD add the values of the 248 individual routes to determine the value for the aggregated route in 249 the same ITAD. 251 3.1.5. Route Dissemination and TotalCircuitCapacity 253 Since this attribute reflects the static capacity of the gateway's 254 circuit resources, it is not expected to change frequently. Hence the 255 LS receiving this attribute MAY disseminate it to other peers, both 256 internal and external to the ITAD. 258 3.2. AvailableCircuits Attribute 260 Mandatory: False. 261 Required Flags: Not well-known. 262 Potential Flags: None. 263 TRIP Type Code: 14. (To be assigned by IANA) 265 The AvailableCircuits identifies the number of PSTN circuits that are 266 currently available on a route to complete calls. The number of 267 additional calls sent to that gateway for that route cannot exceed 268 the circuit capacity. If it does, the signaling protocol will likely 269 generate errors, and calls will be rejected. 271 The AvailableCircuits attribute is used ONLY between a gateway and 272 its peer LS responsible for managing that gateway. If it is received 273 in a route, it is not propagated. 275 3.2.1. AvailableCircuits Syntax 277 The AvailableCircuits attribute is a 4-octet unsigned numeric value. 278 It represents the number of circuits remaining for terminating calls 279 to this route. 281 3.2.2. Route Origination and AvailableCircuits 283 Routes MAY be originated containing the AvailableCircuits attribute. 284 Since this attribute is highly dynamic, changing with every call, 285 updates MAY be sent as it changes. However, it is RECOMMENDED that 286 measures be taken to help reduce the messaging load from route 287 origination. It is further RECOMMENDED that sufficiently large 288 windows be used to provide a useful aggregated statistic. 290 3.2.3. Route Selection and AvailableCircuits 292 The AvailableCircuits attribute MAY be used for route selection. 293 Since one of its primary applications is load balancing, an LS will 294 wish to choose a potentially different route (amongst a set of routes 295 for the same prefix) on a call by call basis. This can be modeled as 296 re-running the decision process on the arrival of each call. The 297 aggregation and dissemination rules for routes with this attribute 298 ensure that re-running this selection process never results in 299 propagation of a new route to other peers. 301 3.2.4. Aggregation and AvailableCircuits 303 Not applicable 305 3.2.5. Route Dissemination and AvailableCircuits 307 Routes MUST NOT be disseminated with the AvailableCircuits attribute. 308 The attribute is meant to reflect capacity at the originating gateway 309 only. Its highly dynamic nature makes it inappropriate to disseminate 310 in most cases. 312 3.3. CallSuccess Attribute 314 Mandatory: False. 315 Required Flags: Not well-known. 316 Potential Flags: None. 317 TRIP Type Code: 15. (To be assigned by IANA) 319 The CallSuccess attribute is an attribute used ONLY between a gateway 320 and its peer LS responsible for managing that gateway. If it is 321 received in a route, it is not propagated. 323 The CallSuccess attribute provides information about the number of 324 normally terminated calls out of a total number of attempted calls. 325 CallSuccess is to be determined by the gateway based on the 326 Disconnect cause code at call termination. For example, a call that 327 reaches the Alerting stage but does not get connected due to the 328 unavailability of the called party, or the called party being busy, 329 is conventionally considered a successful call. On the other hand, a 330 call that gets disconnected because of a Circuit or Resource being 331 unavailable is conventionally considered a failed call. The exact 332 mapping of disconnect causes to CallSuccess is at the discretion of 333 the gateway reporting the attribute. 335 The CallSuccess attribute is used by the LS to keep track of failures 336 in reaching certain telephony destinations through a gateway(s) and 337 use that information in the gateway selection process to enhance the 338 probability of successful call termination. 340 This information can be used by the LS to consider alternative 341 gateways to terminate calls to those destinations with a better 342 likelihood of success. 344 3.3.1. CallSuccess Syntax 346 The CallSuccess attribute is comprised of two component fields - each 347 represented as an unsigned 4-octet numeric value. The first 348 component field represents the total number of calls terminated 349 successfully for the advertised destination on a given address 350 family. The second component field represents the total number of 351 attempted calls for the advertised destination within some window of 352 time. 354 3.3.2. Route Origination and CallSuccess 356 Routes MAY be originated containing the CallSuccess attribute. This 357 attribute is expected to get statistically significant with passage 358 of time as more calls are attempted. It is RECOMMENDED that 359 sufficiently large windows be used to provide a useful aggregated 360 statistic. 362 3.3.3. Route Selection and CallSuccess 364 The CallSuccess attribute MAY be used for route selection. This 365 attribute represents a measure of success of terminating calls to the 366 advertised destination(s). This information MAY be used to select 367 from amongst a set of alternative routes to increase the probability 368 of successful call termination. 370 3.3.4. Aggregation and CallSuccess 372 Not applicable 374 3.3.5. Route Dissemination and CallSuccess 376 Routes MUST NOT be disseminated with the CallSuccess attribute. Its 377 potential to change dynamically does not make it suitable to 378 disseminate. 380 3.4. Prefix Attributes 382 Mandatory: False. 383 Required Flags: Not well-known. 384 Potential Flags: None. 385 TRIP Type Codes: 16 for E164 prefix, 17 for pentadecimal prefix and 386 18 for decimal prefix (To be assigned by IANA) 388 The Prefix attribute is used to represent the list of prefixes that 389 the respective route can complete calls to. This attribute is 390 intended to be used with the Carrier or Trunkgroup address family 391 (discussed in Section 3.7). 393 Though it is possible that all prefix ranges may be reachable 394 through a given Carrier, administrative issues could make certain 395 ranges preferable to others. 397 3.4.1. Prefix Attribute Syntax 399 The Prefix attribute could be E.164, Decimal or PentaDecimal (refer 400 to TRIP RFC [4]), each of them having it's own type code. The Prefix 401 attribute is encoded as a sequence of prefix values in the attribute 402 value field. The prefixes are listed sequentially with no padding as 403 shown in Figure 2. Each prefix includes a 2-octet length field that 404 represents the length of the address field in octets. The order of 405 prefixes in the attribute is not significant. 407 The presence of Prefix Attribute with the length field of the 408 attribute as 0 signifies that the TGREP GW can terminate ALL prefixes 409 for the given Reachable route(s). 411 1 412 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 413 +-------------------------------+-----------+----------------------------------+----------- 414 | Length | Prefix1...| Length | Prefix2... 415 +-------------------------------+-----------+----------------------------------+----------- 417 Figure 2: Prefix Format 419 3.4.2. Route Origination and Prefix 421 Routes MAY be originated containing the Prefix attribute. 423 3.4.3. Route Selection and Prefix 425 The Prefix attribute MAY be used for route selection. 427 3.4.4. Aggregation and Prefix 429 Routes with differing Prefix attribute MUST NOT be aggregated. 430 Routes with the same value in the Prefix attribute MAY be aggregated 431 and the same Prefix attribute attached to the aggregated object. 433 3.4.5. Route Dissemination and Prefix 435 The LS receiving this attribute should disseminate to other peers, 436 both internal and external to the ITAD. 438 3.5. TrunkGroup Attribute 440 Mandatory: False. 441 Required Flags: Not well-known. 442 Potential Flags: None. 443 TRIP Type Code: 20 (To be assigned by IANA) 445 The TrunkGroup attribute is used to represent the list of trunkgroups 446 on the gateway used to complete calls. It enables providers to route 447 calls to destinations through preferred trunks. This attribute is 448 relatively static. 450 3.5.1. TrunkGroup Syntax 452 The TrunkGroup attribute is a variable length attribute that is 453 composed of a sequence of trunkgroup length-value fields. It 454 indicates that the gateway can complete the call through any 455 trunkgroup (represented by the trunkgroup label) in the sequence. 457 Each trunkgroup is a length-value field (shown in Figure 3 below). 458 The length field is a 1-octet unsigned numeric value. The value field 459 is a variable length alphanumeric field and is also called the 460 trunkgroup label field. The length field represents the size of the 461 trunkgroup label in number of octets. The maximum length is 128 462 octets. 464 The presence of TrunkGroup attribute with the length field of the 465 attribute as 0 signifies that the TGREP GW can terminate ALL 466 trunkgroup for the given Reachable route(s). 468 0 1 469 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 ... 470 +---------------+--------------------+---------------+--------------------- 471 | Length | TrunkGroup Label1..| Length | TrunkGroup Label2.. 472 +---------------+--------------------+---------------+--------------------- 473 Figure 3: TrunkGroup Syntax 475 3.5.2. Route Origination and TrunkGroup 477 Routes MAY be originated containing the TrunkGroupattribute. 479 3.5.3. Route Selection and TrunkGroup 481 The TrunkGroup attribute MAY be used for route selection. Certain 482 trunkgroups MAY be preferred over others based on provider policy. 484 3.5.4. Aggregation and TrunkGroup 486 Routes with differing TrunkGroup attribute MUST NOT be aggregated. 487 Routes with the same value in the TrunkGroup attribute MAY be 488 aggregated and the same TrunkGroup attribute attached to the 489 aggregated object. 491 3.5.5. Route Dissemination and TrunkGroup 493 This attribute is not expected to change frequently. Hence, the LS 494 receiving this attribute MAY disseminate it to other peers, internal 495 to ITAD. Routes SHOULD not be disseminated external to the ITAD, with 496 TrunkGroup attribute. 498 3.6. Carrier Attribute 500 Mandatory: False. 501 Required Flags: Not well-known. 502 Potential Flags: None. 503 TRIP Type Code: 19 (To be assigned by IANA) 505 The Carrier attribute is used to represent the list of carriers that 506 the gateway uses to complete calls. It enables providers to route 507 calls to destinations through preferred carriers. This attribute is 508 relatively static. 510 3.6.1. Carrier Syntax 512 The Carrier attribute is a variable length attribute that is composed 513 of a sequence of carrier values. It indicates that the route can 514 complete the call to any of the carriers represented in the sequence 515 of carrier values. 517 A Carrier value is an 8-octet ASCII-encoded string obtained by 518 concatenation of a CarrierIdCode and a RegionCode ( defined below ). 519 When the length of the Carrier value is less than 8 octets, it is 520 padded with NULL bytes 522 The CarrierIdCode is the code assigned to a carrier by a regulatory 523 body operating in that region. The RegionCode represents the region 524 where the CarrierIdCode is assigned. The RegionCode is a qualifier 525 that makes the Carrier value globally unique. Regions are currently 526 defined to map to countries. The RegionCode should use E.164 country 527 code used in dialing international telephony destinations. However, 528 regions can evolve in the future to encompass a larger area, beyond a 529 country. For example, if a regulatory body in the European Union that 530 assigns CarrierIds to carriers in the whole of Europe, a 531 corresponding RegionCode would be used. 533 The textual concatenation of CarrierId and RegionCode forms a 534 Carrier. This Carrier is then used as an attribute of the associated 535 destination. 537 When the scope of a CarrierIdCode is known to be unique apriori, the 538 RegionCode is superfluous and MAY be excluded from the Carrier value 539 when advertising in a TGREP UPDATE message. This is possible when the 540 carrier is operating within the same region where the CarrierIdCode 541 was assigned or if the carrier is operating in a controlled 542 environment of networks where CarrierId is privately defined to be 543 unique. 545 The presence of Carrier Attribute with the length field of the 546 attribute as 0 signifies that the TGREP GW can terminate ALL Carriers 547 for the given Reachable route(s). 549 0 1 2 7 0 550 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 .....0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 .. 551 +-------------------------------------------------------------+--------------- 552 | Carrier1 | Carrier2 .. 553 +-------------------------------------------------------------+--------------- 555 Figure 4: Carrier Syntax 557 3.6.2. Route Origination and Carrier 559 Routes MAY be originated containing the Carrier attribute. 561 3.6.3. Route Selection and Carrier 563 The Carrier attribute MAY be used for route selection. Certain 564 carriers MAY be preferred over others based on provider policy. 566 3.6.4. Aggregation and Carrier 568 Routes with differing Carrier attribute MUST NOT be aggregated. 569 Routes with the same value in the Carrier attribute MAY be aggregated 570 and the same Carrier attribute attached to the aggregated object. 572 3.6.5. Route Dissemination and Carrier 574 This attribute is not expected to change frequently. Hence, the LS 575 receiving this attribute MAY disseminate it to other peers, both 576 internal and external to the ITAD. 578 3.7. TrunkGroup and Carrier Address Families 580 When a set of GWs are to managed at the granularity of carriers or 581 trunkgroups then it may be more appropriate for a GW to advertise 582 routes using the Carrier address family or trunkgroup address family 583 respectively. Also, in a TGREP association between the gateway and 584 the LS responsible for managing that gateway, there are some 585 attributes that more naturally fit in as advertised properties of 586 trunkgroups or carriers rather than that of advertised prefixes; for 587 example, the AvailableCircuit information on a particular trunkgroup 588 or a particular carrier. To express this relationship, the existing 589 TRIP address families are inadequate. We need separate address 590 families that can associate certain properties like AvailableCircuits 591 information to trunkgroups or carriers. 593 The primary benefits of this model are as follows: 595 - It allows a service provider to route calls based strictly on the 596 trunkGroups or carriers. 597 - it facilitates more accurate reporting of attributes of a dynamic 598 nature like AvailableCircuits by providing the ability to manage 599 resources at the granularity of a trunkgroup or a carrier. 600 - Gateways can get really large with the ability to provision 601 hundreds or a few thousand circuits and this can increase the 602 potential for traffic that reports dynamic resource information 603 between the gateway and the LS. The model introduced can 604 potentially alleviate this UPDATE traffic hence increasing 605 efficiency and providing a scalable gateway registration model. 607 3.7.1. Address Family Syntax 609 Consider the generic TRIP route format from TRIP[4] shown below. 611 0 1 2 3 612 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 613 +---------------+---------------+--------------+----------------+ 614 | Address Family | Application Protocol | 615 +---------------+---------------+--------------+----------------+---- 616 | Length | Address (variable) .... 617 +---------------+---------------+--------------+----------------+---- 619 Figure 5: Generic TRIP Route Format 621 The Address Family field will be used to represent the type of the 622 address associated for this family, which is based on the TrunkGroup 623 or Carrier. The codes for the new address families will be allocated 624 by IANA. 626 The Application Protocol field is same as the one for the Decimal, 627 PentaDecimal and E.164 address families defined in TRIP[4]. The 628 Length field represents the total size of the Address field in bytes. 630 The value in the Address field represents either the TrunkGroup or 631 the Carrier address families and the syntax is as follows: 633 For the TrunkGroup Address Family, the Address field is a variable 634 length alphanumeric field (trunkgroup label), where length is 635 determined by the length field of the route. The maximum value of the 636 length field for this Address Family is 128 bytes. 638 For the Carrier Address Family, the length field represents the 639 length of the Address field in bytes. The Address field is a fixed 640 length field representing Carrier value. A Carrier value is an 8- 641 octet ASCII-encoded string obtained by concatenation of a 642 CarrierIdCode and a RegionCode ( defined below ). When the length of 643 the Carrier value is less than 8 octets, it is padded with NULL bytes 645 The CarrierIdCode is the code assigned to a carrier by a regulatory 646 body operating in that region. The RegionCode represents the region 647 where the CarrierIdCode is assigned. The RegionCode is a qualifier 648 that makes the Carrier value globally unique. Regions are currently 649 defined to map to countries. The RegionCode should use E.164 country 650 code used in dialing international telephony destinations. However, 651 regions can evolve in the future to encompass a larger area, beyond a 652 country. For example, if a regulatory body in the European Union that 653 assigns CarrierIds to carriers in the whole of Europe, a 654 corresponding RegionCode would be used. 656 The textual concatenation of CarrierId and RegionCode forms a 657 Carrier. This is then used as a destination for routing purposes. 659 When the scope of a CarrierIdCode is known to be unique apriori, the 660 RegionCode is superfluous and MAY be excluded from the Carrier value 661 when advertising in a TGREP UPDATE message. This is possible when the 662 carrier is operating within the same region where the CarrierIdCode 663 was assigned or if the carrier is operating in a controlled 664 environment of networks where CarrierId is privately defined to be 665 unique. 667 If a gateway supports any of these address families, it should 668 include that address family as one of the Route types supported in 669 the OPEN message capability negotiation phase. 671 The following attributes are currently defined to be used with all 672 the address families including the TrunkGroup and Carrier address 673 families. 675 - AvailableCircuits Attribute 676 - TotalCircuitCapacity Attribute 677 - CallSuccess Attribute 679 It is recommended that the above three attributes be used by the 680 gateway with the TrunkGroup or Carrier address families, if possible. 681 This will potentially offer a more efficient resource reporting 682 framework, and a scalable model for gateway provisioning. 684 However, when the gateway is not using TrunkGroup or Carrier address 685 family, it MAY use the above attributes with the Decimal, 686 PentaDecimal and E.164 address families. 688 The Prefix, Carrier and TrunkGroup attributes MUST NOT be used with 689 their respective address families. 691 3.8. Gateway Operation 693 A gateway uses TGREP to advertise its reachability to its domain's 694 Location Server(s) (LS, which are closely coupled with proxies). The 695 gateway operates in TGREP Send Only mode since it is only interested 696 in advertising its reachability, but is not interested in learning 697 about the reachability of other gateways and other domains. Also, the 698 gateway will not create its own call routing database. In this 699 section we describe the operation of TGREP on a gateway. 701 3.8.1. Session Establishment 703 When opening a peering session with a TGREP Receiver, a TGREP gateway 704 follows exactly the same procedures as any other TRIP speaker. The 705 TGREP gateway sends an OPEN message which includes a Send Receive 706 Capability in the Optional Parameters. The Send Receive Capability is 707 set by the gateway to Send Only. The OPEN message also contains the 708 address families supported by the gateway. The remainder of the peer 709 session establishment is identical to TRIP. 711 3.8.2. UPDATE Messages 713 Once the peer session has been established, the gateway sends UPDATE 714 messages to the TRIP LS with the gateway's entire reachability. The 715 Gateway also sends any attributes associated with the routes. 717 If the gateway's reachability changes at any point in time, the 718 gateway MUST generate UPDATE message(s) with the change. The 719 frequency of successive UPDATE messages MUST follow the same rules 720 specified for TRIP[4]. The TGREP gateway MUST support all mandatory 721 TRIP attributes. 723 If the gateway receives an UPDATE message from the TRIP LS, it MUST 724 silently discard it as specified for TRIP[4]. No further action 725 should be taken. 727 3.8.3. KEEPALIVE Messages 729 KEEPALIVE messages are periodically exchanged over the peering 730 session between the TGREP gateway and the TRIP LS as specified in 731 Section 4.4 of TRIP RFC[4]. 733 3.8.4. Error Handling and NOTIFICATION Messages 735 The same procedures used with TRIP, are used with TGREP for error 736 handling and generating NOTIFICATION messages. The only difference is 737 that a TGREP gateway will never generate a NOTIFICATION message in 738 response to an UPDATE message, irrespective of the contents of the 739 UPDATE message. Any UPDATE message is silently discarded. 741 3.8.5. TGREP Finite State Machine 743 When the TGREP finite state machine is in the Established state and 744 an UPDATE message is received, the UPDATE message is silently 745 discarded and the TGREP gateway remains in the Established state. 746 Other than that the TRIP finite state machine and the TGREP finite 747 state machine are identical. 749 3.8.6. Call Routing Databases 751 A TGREP gateway may maintain simultaneous sessions with more than one 752 TRIP LSs. A TGREP gateway maintains one call routing database per 753 peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out, 754 and hence we will call them Adj-TRIB-GWs-Out. An Adj-TRIB-GW-Out 755 contains the gateway's reachability information advertised to its 756 peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is 757 outside the scope of this draft (possibly by manual configuration). 759 The TGREP gateway does not have databases equivalent to TRIP's Adj- 760 TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn 761 routes from its peer TRIP LSs, and hence it does not run call route 762 selection. 764 3.8.7. Multiple Address Families 766 As mentioned above, TGREP supports various address families in order 767 to convey the reachibilty of telephony destinations. A TGREP session 768 MUST NOT send UPDATEs of more than one of the following catagories 769 (a) Prefix Address families (E164, Pentadecimal and decimal) (b) 770 Trunkgroup address family (c) Carrier Address family for a given 771 established session. TGREP should specify it's choice address family 772 through the route-type capability in the OPEN message. And route-type 773 specification in the OPEN message violating the above rule should be 774 rejected with a NOTIFICATION message. 776 3.8.8. Route Selection and Aggregation 778 TRIP's route selection and aggregation operations MUST NOT be 779 implemented by TGREP gateways. 781 3.9. LS/Proxy Behavior 783 As mentioned earlier, TGREP can be considered as a protocol 784 complimentary to TRIP in providing reachability information that can 785 then be further fed into the Location Server. The architecture of an 786 LS/Proxy system is as follows: There exists a TRIP LS application 787 that functions as a speaker in the I-TRIP/E-TRIP network as 788 documented in the TRIP RFC [4]. Then, there is a signaling server 789 fronting a set of gateways and receives routing information on one or 790 more TGREP sessions. This routing information from the gateways is 791 received and processed by a TGREP receiver application. Subsequently, 792 this routing information is presented as candidate routes (possibly 793 as local routes) to the TRIP LS. The interface between these two 794 applications is entirely a local matter. However, before importing 795 these routes into the TRIP LS, certain operations may optionally be 796 performed on these routes. The nature of these operations and the 797 accompanying motivation are described in the subsections below. The 798 order in which the operations are listed represents an implicit 799 logical sequence in which they are applied. The architecture for an 800 LS/Proxy entity is shown in Figure 7 below. 802 +-------------------------------------------------------+ 803 | +-------------------------------+ | 804 | | +-+ +-+ | | 805 | | |A| |C| | | +-----+ 806 | | |g| |o| | | TGREP | | 807 | +-------------+ | |g| |n| +-------------+ | | -- | GW | 808 | | | | |r| |s| | | | | -- +-----+ 809 | | TRIP | | |e| |o| | | | +-- 810 | | LS <----------|g<--|l<--- TGREP |-++-| +-----+ 811 | | | | |a| |i| | Session | | | | | 812 | | (I-TRIP/ | | |t| |d| | Mangement |-++-+-------| GW | 813 | | E-TRIP) | | |i| |a| | | | | +-----+ 814 | | | | |o| |t| | |-+ -+- 815 | +-----------/-+ | |n| |i| +-------------+ | | --- +-----+ 816 | / | | | |o| | | -- | | 817 | / | | | |n| | | | GW | 818 | / | +-+ +-+ | | +-----+ 819 | / | TGREP Receiver | | 820 | / +-------------------------------+ | 821 | / | 822 | / | 823 +-------/-----------------------------------------------+ 824 / LS/Proxy 825 / 826 / 827 / 828 / 829 / 830 +/----------------+ 831 | | 832 | | 833 | | 834 | LS | 835 | | 836 | | 837 | | 838 | | 839 | | 840 +----------------+ 842 +------------------------------------------------------+ 843 | +-------------------------------+ | 844 | | +-+ +-+ | | 845 | | |A| |C| | | +-----+ 846 | | |g| |o| | | TGREP | | 847 | +-------------+ | |g| |n| +-------------+ | | -- | GW | 848 | | | | |r| |s| | | | | -- +-----+ 849 | | TRIP | | |e| |o| | | | +-- 850 | | LS <----------|g<--|l<--- TGREP |-++-| +-----+ 851 | | | | |a| |i| | Session | | | | | 852 | | (I-TRIP/ | | |t| |d| | Mangement |-++-+-------| GW | 853 | | E-TRIP) | | |i| |a| | | | | +-----+ 854 | | | | |o| |t| | |-+ -+- 855 | +-------------+ | |n| |i| +-------------+ | | --- +-----+ 856 | | | | |o| | | -- | | 857 | | | | |n| | | | GW | 858 | | +-+ +-+ | | +-----+ 859 | | TGREP Receiver | | 860 | +-------------------------------+ | 861 | | 862 | | 863 +-------------------------------------------------------+ 864 LS/Proxy 866 Figure 7: LS Architecture for TRIP-GW 868 3.9.1. Route consolidation 870 The TGREP receiver may receive routing information from one or more 871 gateways. It is possible that multiple routes are available for the 872 same destination. These different alternative routes may be received 873 from the same gateway, or from multiple gateways. It is RECOMMENDED 874 that the set of gateway routes for each destination be consolidated, 875 before presenting a candidate route, to the TRIP LS. The motivation 876 for this operation should be to define a route that can maximally 877 represent the collective routing capabilities of the set of gateways, 878 managed by this TGREP receiver. Let us take an example scenario in 879 order to bring out the motivation for this operation. Let us say, 880 the TGREP receiver maintains peering sessions with gateways A, and B. 882 o Gateway A advertises a route for destination "SIP 408" on the E.164 883 address 884 family with the Carrier attribute value C1. 886 o Gateway B advertises a route for destination "SIP 408" on the E.164 887 address 888 family with Carrier attribute value C2. 890 The TGREP receiver that receives these routes can consolidate these 891 constituent routes into a single route for destination "SIP 408" with 892 its Carrier attribute being a union of the the Carrier attribute 893 values of the individual routes, namely, "C1 C2". This operation is 894 refered to as Consolidation. In the above example, it is possible 895 that a route to the destination "SIP 408" through one or more 896 carriers may have been lost if the individual routes were not 897 consolidated. 899 Another example is to consolidate the Prefix attribute from multiple 900 Carrier or Trunkgroup updates received from different gateways for 901 the same destination. Let us say, there are Carrier AF updates from 902 two gateways for Carrier destination X, and the prefix attribute 903 values are {408, 650} from one update and {919, 973} from the other. 904 The prefix values from these two updates can be consolidated into a 905 single Carrier AF route advertisement with prefix value {408, 650, 906 919, 973}. 908 In general, there is a potential for loss of gateway routing 909 information, when TGREP routes from a set of gateways are not 910 consolidated, when a candidate route is presented to the TRIP LS. 911 The specifics of applying the consolidation operation to different 912 attributes and routes from different address families, is left to the 913 individual TGREP receiver implementations. 915 3.9.2. Aggregation 917 The set of gateway routes, that are in a consolidated form or 918 otherwise, may be aggregated before importing it to the LS instance 919 that is responsible for I-TRIP/E-TRIP processing. This operation 920 follows the standard aggregation procedures described in the TRIP RFC 921 [4], while adhering to the aggregation rules for each route 922 attribute. 924 3.9.3. Consolidation v/s Aggregation 926 To highlight the difference between the two operations discussed 927 above, "Consolidation" combines multiple routes for the same route 928 destination, whereas "Aggregation" combines routes for different 929 route destinations that qualify as candidates to be summarized 930 resulting in route information reduction. 932 To take an example, if there are multiple gateways offering routes to 933 an E.164 destination "408" but with possibly different attributes 934 (Eg: Carrier), the LS/Proxy can combine these to form one route for 935 "408" but representing the attribute information collectively. This 936 process is Consolidation 938 If, for example, the LS/Proxy receives routes for 4080, 4081, 4082, 939 ... 4089 from amongst a set of gateways, it could aggregate these 940 different candidate routes to have a summarized route destination 941 "408" with each of the attributes computed using the Aggregation 942 procedures defined in the TRIP RFC. 944 4. Security Considerations 946 The Security considerations defined in the TRIP RFC [4] apply to 947 TGREP sessions between Gateways and TGREP Receivers 949 5. IANA Considerations 951 - The Attribute Type Codes for the new attributes: 952 AvailableCircuits, TotalCircuitCapacity, CallSuccess, Prefix, 953 TrunkGroup and Carrier described in Sections 3.1, 3.2, 3.3, 3.4, 954 3.5 and 3.6 above, respectively, are to be assigned by IANA. 955 - The Address Family Codes for the new address families: TrunkGroup 956 and Carrier described in Section 3.7, are to be assigned by IANA. 958 Both TRIP[4] and TGREP share the same IANA registry for Capabilities, 959 Attributes, Address Families, and Application Protocols 961 6. Changes since draft-ietf-iptel-tgrep-03.txt 963 - No change in content. Releasing a new revision for renewal of 964 draft 966 7. Changes since draft-ietf-iptel-tgrep-02.txt 968 - No change in content. Releasing a new revision for renewal of 969 draft 971 8. Changes since draft-ietf-iptel-tgrep-01.txt 973 - Added a "Security Considerations" Section to the document 974 - Strengthened the text under "LS/Proxy Behavior" regarding 975 Consolidation and Aggregation with additional examples for better 976 clarity 977 - Removed the section "Other Attributes" including its subsection 978 on the "Pricing" attribute 979 - Modified the definition of Carrier in the "Carrier attribute" and 980 "TrunkGroup and Carrier Address Families" sections respectively 981 - Rectified the section number references in the "IANA 982 Considerations" Section 983 - Strengthened the text in the attribute sections regarding 984 dissemination of attributes received on TGREP 985 - Updated the "References" section 986 - Corrected typos, nits, grammatical errors, and language of the 987 text throughout the document based on feedback from the iptel 988 community 990 9. Changes since draft-ietf-iptel-tgrep-00.txt 992 - Added recommendations for AvailableCircuits and CallSuccess 993 attributes. 994 - Updated Carrier Attribute with ASCII syntax. 995 - Removed thresholding scheme description. 996 - Updated author addresses. 998 10. Changes since draft-ietf-iptel-trip-gw-00.txt 1000 - Changed title of the document to TGREP (Telephony Gateway 1001 REgistration Protocol) 1002 - Changed name of protocol described in this document to TGREP 1003 - Changed Abstract and Introduction sections to position TGREP as 1004 an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP) 1005 - Modified the section on LS/Proxy Behavior including the diagram 1006 - Added an additional example to the Route Consolidation section 1007 - Changed the format of Carrier (both as an attribute and as an AF) 1008 to accomodate representation of Country codes in association with 1009 CICs. 1010 - Updated text to allow Carrier attribute in TrunkGroup address 1011 family and TrunkGroup attribute in Carrier address family. 1013 11. Changes since -03 1015 - Removed Carrier-Trunkgroup attribute and address family and 1016 references to it. 1017 - Added Terminology and Definitions section. 1018 - Updated CallSuccess attribute. 1019 - Added Prefix attribute. 1020 - Added Carrier attribute. 1021 - Added TrunkGroup attribute. 1022 - Added TrunkGroup Address Family. 1023 - Added Carrier Address Family. 1024 - Added some more references. 1026 12. Changes since -02 1028 - Removed the requirements section. 1029 - Discussed the motivation for introducing Carrier information into 1030 TRIP. 1031 - Defined a new attribute for the E.164 address family. 1032 - Defined a new address family for CarrierCode-TrunkGroup 1033 combination . 1034 - Defined new attributes to advertise dynamic gateway 1035 characteristics like resource availability, and call success 1036 rate. 1037 - Added as section to validate the TGREP solution against the 1038 requirements in [7]. 1040 13. Changes since -01 1042 - Added requirements. 1043 - Added more formal analysis of REGISTER and added analysis of SLP. 1044 - Removed circuit capacity attribute. 1046 14. Changes since -00 1048 - Added text to stress the value of this proposal for managing a 1049 gateway cluster. 1050 - Added attributes for circuit capacity and DSP capacity. 1051 - Added section on LS operation, discussing aggregation issue. 1053 Authors' Addresses 1055 Manjunath Bangalore 1056 Cisco Systems 1057 Mail Stop SJC-21/2/2 1058 170 W. Tasman Drive 1059 San Jose, CA 95134 1060 email: manjax@cisco.com 1062 Rajneesh Kumar 1063 Cisco Systems 1064 Mail Stop SJC-14/4/2 1065 170 W. Tasman Drive 1066 San Jose, CA 95134 1067 email: rajneesh@cisco.com 1069 Jonathan Rosenberg 1070 dynamicsoft 1071 72 Eagle Rock Avenue 1072 First Floor 1073 East Hanover, NJ 07936 1074 email: jdrosen@dynamicsoft.com 1076 Hussein F. Salama 1077 Cisco Systems 1078 Mail Stop CAI1 1079 135 Abdel Aziz Fahmy Street 1080 2nd Floor Apartment #3, Heliopolis 1081 Cairo, Egypt 1082 email: hsalama@cisco.com 1084 Dhaval N. Shah 1085 Cisco Systems 1086 Mail Stop SJC-06/4/3 1087 170 W. Tasman Drive 1088 San Jose, CA 95134 1089 email: dhaval@cisco.com 1091 Acknowledgments 1093 We wish to thank David Oran, Anirudh Sahoo, Kevin McDermott, Jon 1094 Peterson, Li Li and Bob Penfield for their insightful comments and 1095 suggestions. 1097 References 1099 [1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement 1100 Levels", BCP 14, RFC 2119, March 1997. 1102 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 1103 session initiation protocol," Request for Comments 3261, Internet 1104 Engineering Task Force, Mar. 1999. 1106 [3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service 1107 location protocol, version 2," Request for Comments 2608, Internet 1108 Engineering Task Force, June 1999. 1110 [4] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over 1111 IP (TRIP)," Request for Comments 3219, Internet Engineering Task 1112 Force, January 2002. 1114 [5] J. Rosenberg and H. Schulzrinne, "A framework for telephony 1115 routing over IP," Request for Comments 2871, Internet Engineering 1116 Task Force, June 2000. 1118 [6] J. Rosenberg, "Requirements for Gateway Registration," Internet 1119 Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. 1121 [7] ITU-T List of ITU Carrier Codes (published periodically in the 1122 ITU-T Operational Bulletin). 1124 [8] J. Peterson, "An Architecture for Gateway Registration Based on 1125 Trunk Groups," Internet Draft, Internet Engineering Task Force, Feb. 1126 2002. Work in progress. 1128 Intellectual Property Statement 1130 The IETF takes no position regarding the validity or scope of any 1131 Intellectual Property Rights or other rights that might be claimed to 1132 pertain to the implementation or use of the technology described in 1133 this document or the extent to which any license under such rights 1134 might or might not be available; nor does it represent that it has 1135 made any independent effort to identify any such rights. Information 1136 on the procedures with respect to rights in RFC documents can be 1137 found in BCP 78 and BCP 79. 1139 Copies of IPR disclosures made to the IETF Secretariat and any 1140 assurances of licenses to be made available, or the result of an 1141 attempt made to obtain a general license or permission for the use of 1142 such proprietary rights by implementers or users of this 1143 specification can be obtained from the IETF on-line IPR repository at 1144 http://www.ietf.org/ipr. 1146 The IETF invites any interested party to bring to its attention any 1147 copyrights, patents or patent applications, or other proprietary 1148 rights that may cover technology that may be required to implement 1149 this standard. Please address the information to the IETF at ietf- 1150 ipr@ietf.org. 1152 Disclaimer of Validity 1154 This document and the information contained herein are provided on an 1155 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1156 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1157 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1158 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1159 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1160 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1162 Copyright Statement 1164 Copyright (C) The Internet Society (2004). This document is subject 1165 to the rights, licenses and restrictions contained in BCP 78, and 1166 except as set forth therein, the authors retain all their rights. 1168 Acknowledgment 1170 Funding for the RFC Editor function is currently provided by the 1171 Internet Society.