IPTEL Working Group Manjunath Bangalore, Cisco Systems Inc. Internet Draft Rajneesh Kumar, Cisco Systems Inc. draft-ietf-iptel-tgrep-05.txt Jonathan Rosenberg, Cisco Systems Inc. February 2005 Hussein Salama, Cisco Systems Inc. Expiration Date: August 2005 Dhaval Shah, Cisco Systems Inc. A Telephony Gateway REgistration Protocol (TGREP) Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 21, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP Bangalore, Kumar, Rosenberg, Salama, Shah [Page 1]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 (TRIP) Location Server, which in turn can propagate that routing information within and between internet telephony administrative domains (ITAD). TGREP shares a lot of similarities with the TRIP Protocol. It has similar procedures and Finite State Machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP. TGREP entities are valid trip implementations, but they do only a subset of what they otherwise could. In particular, a gateway is always in Send mode, the LS peering with it is always in Receive mode. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 2]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 Table of Contents 1 Terminology and Definitions .............................. 4 2 Introduction ............................................. 4 3 TGREP: Overview of operation ............................. 6 4 TGREP Attributes ......................................... 7 4.1 TotalCircuitCapacity Attribute ........................... 7 4.2 AvailableCircuits Attribute .............................. 9 4.3 CallSuccess Attribute .................................... 10 4.4 Prefix Attributes ........................................ 12 4.5 TrunkGroup Attribute ..................................... 13 4.6 Carrier Attribute ........................................ 15 4.7 TrunkGroup and Carrier Address Families .................. 16 4.8 Gateway Operation ........................................ 19 4.9 LS/Proxy Behavior ........................................ 21 5 Security Considerations .................................. 26 6 IANA Considerations ...................................... 27 6.1 Attribute Codes .......................................... 27 6.2 Address Family Codes ..................................... 27 7 Change history ........................................... 28 7.1 Changes since draft-ietf-iptel-tgrep-03.txt .............. 28 7.2 Changes since draft-ietf-iptel-tgrep-02.txt .............. 28 7.3 Changes since draft-ietf-iptel-tgrep-01.txt .............. 28 7.4 Changes since draft-ietf-iptel-tgrep-00.txt .............. 28 7.5 Changes since draft-ietf-iptel-trip-gw-00.txt ............ 29 7.6 Changes since -03 ........................................ 29 7.7 Changes since -02 ........................................ 29 7.8 Changes since -01 ........................................ 30 7.9 Changes since -00 ........................................ 30 8 Acknowledgments .......................................... 30 9 References ............................................... 30 9.1 Normative References ..................................... 30 9.2 Informative References ................................... 31 Authors' Addresses ....................................... 31 Intellectual Property Statement .......................... 32 Disclaimer of Validity ................................... 33 Copyright Statement ...................................... 33 Acknowledgment ........................................... 33 Bangalore, Kumar, Rosenberg, Salama, Shah [Page 3]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 1. Terminology and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Some other useful definitions are: Circuit: A circuit is a discrete (specific) path between two or more points along which signals can be carried. In this context, a circuit is a physical path, consisting of one or more wires and possibly intermediate switching points. Trunk: In a network, a communication path connecting two switching systems used in the establishment of an end-to-end connection. In selected applications, it may have both its terminations in the same switching system. TrunkGroup: A set of trunks, traffic engineered as a unit, for the establishment of connections within or between switching systems in which all of the paths are interchangeable except where subgrouped. Carrier: A company offering telephone and data communications between points (end-users and/or exchanges). 2. Introduction It is assumed that reader of this has already gone through TRIP [4]. In typical VoIP networks, Internet Telephony Administrative Domains (ITADs) will deploy numerous gateways for the purposes of geographical diversity, capacity, and redundancy. When a call arrives at the domain, it must be routed to one of those gateways. Frequently, an ITAD will break their network into geographic Points of Presence (POP), with each POP containing some number of gateways, and a proxy server element that fronts those gateways. The proxy server is responsible for managing the access to the POP, and also for determining which of the gateways will receive any given call that arrives at the POP. In conjunction with the proxy server that routes the call signaling, there are two TRIP Speaker components, the "Ingress LS" and the "Egress LS". The Ingress LS maintains TGREP peering relationship with one or more gateways. The routing information received from the gateways are further injected into the Egress LS, which in turn disseminates into the rest of the network on TRIP. This configuration is depicted graphically in Figure 1. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 4]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 +---------+ | | | GW | > +---------+ // // // +---------+ // | | +-------------------------+ // | GW | | | // +---------+ | +-------------+ |/ | | | | TO PSTN | | Routing | | +---------+ | | Proxy | | -------> | | -----> ---> | | |---- | GW | |+---+-----+ +-----+----+ | +---------+ || | | | | || <+-+ | |-- ||Egress LS| |Ingress LS| | --- +---------+ || | | | | -- | | |+---------+ +----------+ | -- | GW | | | -- +---------+ | | --> +-------------------------+ +---------+ | | | GW | +---------+ Figure 1: Gateway and LS Configuration The decision about which gateway to use depends on many factors, including their availability, remaining call capacity and call success statistics to a particular PSTN destination. For the proxy to do this adequately, it needs to have access to this information in real-time, as it changes. This means there must be some kind of communications between the proxy and the gateways to convey this information. In this document, we specify a protocol for registration of routes (destinations) supported by the gateway to the TRIP Location Server [4], known as Telephony Gateway REgistration Protocol (TGREP). TGREP Protocol can be considered an auxiliary protocol to TRIP. Routes learnt through TGREP can be injected into and further processed and/or propagated by the TRIP Location Server. TGREP shares a lot of commonality with TRIP in various aspects. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 5]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 Particularly, TGREP and TRIP have the same session establishment procedures, state machine, etc. TGREP also makes use of a similar UPDATE message to propagate the routes supported. It uses Notification, Keepalive and OPEN message in the same essence as TRIP. TGREP defines few new attributes that are needed to specify certain characteristics of gateways, like Available Capacity for a destination. The document aims at specifying all the attributes related to the TGREP session. This document also specifies some new address families which can be useful in advertising the information on the GWs. As a general rule, because of lot of similarities between TRIP and TGREP, frequent reference will be made to the terminologies and formats defined in TRIP [4]. It is suggested that the reader be familiar with the concepts of TRIP like attributes, flags, route types, address families, etc. 3. TGREP: Overview of operation TGREP is a route registration protocol for telephony destinations on a gateway. These telephony destinations could be prefixes, trunk groups or Carriers. The Speaker of TGREP resides on the GW and gathers all the information from the GW to relay to the TRIP Location Server. A TGREP Receiver is defined, which receives this information and after certain optional operations like consolidation and aggregation. (defined in Sections 3.10.1 and 3.10.2) hands over the reachability information a to TRIP Location Server. The TGREP speaker establishes a session to the TGREP Receiver using the procedures similar to session establishment in TRIP. The TGREP Speaker is however, in "Send only" mode and the receiver is in the "Receive only" mode. After the session establishment the TGREP speaker sends the reachibility information in the UPDATE messages. The UPDATE messages have the same format as in TRIP. However, certain TRIP attributes are not relevant in TGREP; a TGREP speaker MAY ignore them if they are present in a TGREP message. The following TRIP attributes do not apply to TGREP: 1. AdvertisementPath 2. RoutedPath 3. AtomicAggregate 4. LocalPreference 5. MultiExitDisc 6. ITADTopology 7. ConvertedRoute In addition, TGREP defines the following new attributes in this document that can be carried in a TGREP UPDATE message. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 6]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 1. TotalCircuitCapacity 2. AvailableCircuits 3. CallSuccess 4. Prefix (E164) 5. Prefix (Decimal Routing Number) 6. Prefix (Hexadecimal Routing Number) 7. TrunkGroup 8. Carrier In the rest of the document we specify attributes and address families used in TGREP. We also specify the operations of consolidation and aggregation as they apply to the UPDATEs received from the TGREP Gateway by the TGREP Receiver. 4. TGREP Attributes A TGREP UPDATE supports the following attributes: 1. WithdrawnRoutes (as defined in TRIP) 2. ReachableRoutes (as defined in TRIP) 3. NexthopServer (as defined in TRIP) 4. TotalCircuitCapacity 5. AvailableCircuits 6. CallSuccess 7. Prefix (E.164, Pentadecimal routing number, Decimal routing number) 8. TrunkGroup 9. Carrier 10. Communities 4.1. TotalCircuitCapacity Attribute Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 13. The TotalCircuitCapacity identifies the total number of PSTN circuits that are available on a route to complete calls. It is used in conjunction with the AvailableCircuits attribute in gateway selection by the LS. The total number of calls sent to the specified route on the gateway cannot exceed this total circuit capacity under steady state conditions. The TotalCircuitCapacity attribute is used to reflect the administratively provisioned capacity as opposed to the availability at a given point in time as provided by the AvailableCircuits attribute. Because of its relatively static nature, this attribute Bangalore, Kumar, Rosenberg, Salama, Shah [Page 7]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 MAY be propagated beyond the LS that receives it. TotalCircuitCapacity represents the total number of active calls at any instant. This is not expected to change frequently. This can change, for instance, when certain telephony trunks on the gateway are taken out of service for maintenance purposes. 4.1.1. TotalCircuitCapacity Syntax The TotalCircuitCapacity attribute is a 4-octet unsigned integer. It represents the total number of circuits available for terminating calls through this advertised route. This attribute represents a potentially achievable upper bound on the number of calls which can be terminated on this route in total. 4.1.2. Route Origination and TotalCircuitCapacity Routes MAY be originated containing the TotalCircuitCapacity attribute. 4.1.3. Route Selection and TotalCircuitCapacity The TotalCircuitCapacity attribute MAY be used for route selection. Since one of its primary applications is load balancing, an LS will wish to choose a potentially different route (amongst a set of routes for the same destination), on a call by call basis. This can be modeled as re-running the decision process on the arrival of each call. The aggregation and dissemination rules for routes with this attribute ensure that re-running this selection process never results in propagation of a new route to other peers. 4.1.4. Aggregation and TotalCircuitCapacity An LS MAY aggregate routes to the same prefix which contain a TotalCircuitCapacity attribute. It SHOULD add the values of the individual routes to determine the value for the aggregated route in the same ITAD. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 8]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 4.1.5. Route Dissemination and TotalCircuitCapacity Since this attribute reflects the static capacity of the gateway's circuit resources, it is not expected to change frequently. Hence the LS receiving this attribute MAY disseminate it to other peers, both internal and external to the ITAD. 4.2. AvailableCircuits Attribute Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 14. The AvailableCircuits identifies the number of PSTN circuits that are currently available on a route to complete calls. The number of additional calls sent to that gateway for that route cannot exceed the circuit capacity. If it does, the signaling protocol will likely generate errors, and calls will be rejected. The AvailableCircuits attribute is used ONLY between a gateway and its peer LS responsible for managing that gateway. If it is received in a route, it is not propagated. 4.2.1. AvailableCircuits Syntax The AvailableCircuits attribute is a 4-octet unsigned integer. It represents the number of circuits remaining for terminating calls to this route. 4.2.2. Route Origination and AvailableCircuits Routes MAY be originated containing the AvailableCircuits attribute. Since this attribute is highly dynamic, changing with every call, updates MAY be sent as it changes. However, it is RECOMMENDED that measures be taken to help reduce the messaging load from route origination. It is further RECOMMENDED that a sufficiently large window of time be used to provide a useful aggregated statistic. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 9]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 4.2.3. Route Selection and AvailableCircuits The AvailableCircuits attribute MAY be used for route selection. Since one of its primary applications is load balancing, an LS will wish to choose a potentially different route (amongst a set of routes for the same prefix) on a call by call basis. This can be modeled as re-running the decision process on the arrival of each call. The aggregation and dissemination rules for routes with this attribute ensure that re-running this selection process never results in propagation of a new route to other peers. 4.2.4. Aggregation and AvailableCircuits Not applicable 4.2.5. Route Dissemination and AvailableCircuits Routes MUST NOT be disseminated with the AvailableCircuits attribute. The attribute is meant to reflect capacity at the originating gateway only. Its highly dynamic nature makes it inappropriate to disseminate in most cases. 4.3. CallSuccess Attribute Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 15. The CallSuccess attribute is an attribute used ONLY between a gateway and its peer LS responsible for managing that gateway. If it is received in a route, it is not propagated. The CallSuccess attribute provides information about the number of normally terminated calls out of a total number of attempted calls. CallSuccess is to be determined by the gateway based on the Disconnect cause code at call termination. For example, a call that reaches the Alerting stage but does not get connected due to the unavailability of the called party, or the called party being busy, is conventionally considered a successful call. On the other hand, a call that gets disconnected because of a Circuit or Resource being unavailable is conventionally considered a failed call. The exact mapping of disconnect causes to CallSuccess is at the discretion of the gateway reporting the attribute. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 10]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 The CallSuccess attribute is used by the LS to keep track of failures in reaching certain telephony destinations through a gateway(s) and use that information in the gateway selection process to enhance the probability of successful call termination. This information can be used by the LS to consider alternative gateways to terminate calls to those destinations with a better likelihood of success. 4.3.1. CallSuccess Syntax The CallSuccess attribute is comprised of two component fields - each represented as an unsigned 4-octet unsigned integer. The first component field represents the total number of calls terminated successfully for the advertised destination on a given address family over a given window of time. The second component field represents the total number of attempted calls for the advertised destination within the same window of time. 4.3.2. Route Origination and CallSuccess Routes MAY be originated containing the CallSuccess attribute. This attribute is expected to get statistically significant with passage of time as more calls are attempted. It is RECOMMENDED that sufficiently large windows be used to provide a useful aggregated statistic. 4.3.3. Route Selection and CallSuccess The CallSuccess attribute MAY be used for route selection. This attribute represents a measure of success of terminating calls to the advertised destination(s). This information MAY be used to select from amongst a set of alternative routes to increase the probability of successful call termination. 4.3.4. Aggregation and CallSuccess Not applicable Bangalore, Kumar, Rosenberg, Salama, Shah [Page 11]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 4.3.5. Route Dissemination and CallSuccess Routes MUST NOT be disseminated with the CallSuccess attribute. Its potential to change dynamically does not make it suitable to disseminate. 4.4. Prefix Attributes Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Codes: 16 for E164 prefix, 17 for Pentadecimal routing number prefix and 18 for Decimal routing number prefix. The Prefix attribute is used to represent the list of prefixes that the respective route can complete calls to. This attribute is intended to be used with the Carrier or Trunkgroup address family (discussed in Section 3.7). Though it is possible that all prefix ranges may be reachable through a given Carrier, administrative issues could make certain ranges preferable to others. 4.4.1. Prefix Attribute Syntax The Prefix attribute could be E.164, Decimal or PentaDecimal (refer to TRIP [4]), each of them having it's own type code. The Prefix attribute is encoded as a sequence of prefix values in the attribute value field. The prefixes are listed sequentially with no padding as shown in Figure 2. Each prefix includes a 2-octet length field that represents the length of the address field in octets. The order of prefixes in the attribute is not significant. The presence of Prefix Attribute with the length field of the attribute as 0 signifies that the TGREP GW can terminate ALL prefixes of that prefix type (E.164, Decimal or Pentadecimal) for the given Reachable route(s). This is not equivalent to excluding the Prefix attribute in the TGREP update. 1 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 +-------------------------------+-----------+----------------------------------+----------- | Length | Prefix1...| Length | Prefix2... +-------------------------------+-----------+----------------------------------+----------- Figure 2: Prefix Format Bangalore, Kumar, Rosenberg, Salama, Shah [Page 12]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 4.4.2. Route Origination and Prefix Routes MAY be originated containing the Prefix attribute. 4.4.3. Route Selection and Prefix The Prefix attribute MAY be used for route selection. 4.4.4. Aggregation and Prefix Routes with differing Prefix attribute MUST NOT be aggregated. Routes with the same value in the Prefix attribute MAY be aggregated and the same Prefix attribute attached to the aggregated object. 4.4.5. Route Dissemination and Prefix The LS receiving this attribute should disseminate to other peers, both internal and external to the ITAD. 4.5. TrunkGroup Attribute Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 20. The TrunkGroup attribute is used to represent the list of trunkgroups on the gateway used to complete calls. It enables providers to route calls to destinations through preferred trunks. This attribute is relatively static. 4.5.1. TrunkGroup Syntax The TrunkGroup attribute is a variable length attribute that is composed of a sequence of trunkgroup length-value fields. It indicates that the gateway can complete the call through any trunkgroup (represented by the trunkgroup label) in the sequence. Each trunkgroup is a length-value field (shown in Figure 3 below). The length field is a 1-octet unsigned numeric value. The value field is a variable length alphanumeric field and is also called the trunkgroup label field. The length field represents the size of the trunkgroup label in number of octets. The maximum length is 128 Bangalore, Kumar, Rosenberg, Salama, Shah [Page 13]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 octets. The presence of TrunkGroup attribute with the length field of the attribute as 0 signifies that the TGREP GW can terminate ALL trunkgroup for the given Reachable route(s). 0 1 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 ... +---------------+--------------------+---------------+--------------------- | Length | TrunkGroup Label1..| Length | TrunkGroup Label2.. +---------------+--------------------+---------------+--------------------- Figure 3: TrunkGroup Syntax 4.5.2. Route Origination and TrunkGroup Routes MAY be originated containing the TrunkGroupattribute. 4.5.3. Route Selection and TrunkGroup The TrunkGroup attribute MAY be used for route selection. Certain trunkgroups MAY be preferred over others based on provider policy. 4.5.4. Aggregation and TrunkGroup Routes with differing TrunkGroup attribute MUST NOT be aggregated. Routes with the same value in the TrunkGroup attribute MAY be aggregated and the same TrunkGroup attribute attached to the aggregated object. 4.5.5. Route Dissemination and TrunkGroup 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. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 14]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 4.6. Carrier Attribute Mandatory: False. Required Flags: Not well-known. Potential Flags: None. TRIP Type Code: 19. The Carrier attribute is used to represent the list of carriers that the gateway uses to complete calls. It enables providers to route calls to destinations through preferred carriers. This attribute is relatively static. 4.6.1. Carrier Syntax The Carrier attribute is a variable length attribute that is composed of a sequence of carrier values. It indicates that the route can complete the call to any of the carriers represented in the sequence of carrier values. A Carrier value is an 8-octet ASCII-encoded string obtained by concatenation of a CarrierIdCode and a RegionCode ( defined below ). When the length of the Carrier value is less than 8 octets, it is padded with NULL bytes. The CarrierIdCode is the code assigned to a carrier by a regulatory body operating in that region. The RegionCode represents the region where the CarrierIdCode is assigned. The RegionCode is a qualifier that makes the Carrier value globally unique. Regions are currently defined to map to countries. The RegionCode should use E.164 country code used in dialing international telephony destinations. However, regions can evolve in the future to encompass a larger area, beyond a country. For example, if a regulatory body in the European Union that assigns CarrierIds to carriers in the whole of Europe, a corresponding RegionCode would be used. The textual concatenation of CarrierId and RegionCode forms a Carrier. This Carrier is then used as an attribute of the associated destination. When the scope of a CarrierIdCode is known to be unique a priori, the RegionCode is superfluous and MAY be excluded from the Carrier value when advertising in a TGREP UPDATE message. This is possible when the carrier is operating within the same region where the CarrierIdCode was assigned or if the carrier is operating in a controlled environment of networks where CarrierId is privately defined to be unique. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 15]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 The presence of Carrier Attribute with the length field of the attribute as 0 signifies that the TGREP GW can terminate ALL Carriers for the given Reachable route(s). 0 1 2 7 0 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 .. +-------------------------------------------------------------+--------------- | Carrier1 | Carrier2 .. +-------------------------------------------------------------+--------------- Figure 4: Carrier Syntax 4.6.2. Route Origination and Carrier Routes MAY be originated containing the Carrier attribute. 4.6.3. Route Selection and Carrier The Carrier attribute MAY be used for route selection. Certain carriers MAY be preferred over others based on provider policy. 4.6.4. Aggregation and Carrier Routes with differing Carrier attribute MUST NOT be aggregated. Routes with the same value in the Carrier attribute MAY be aggregated and the same Carrier attribute attached to the aggregated object. 4.6.5. Route Dissemination and Carrier This attribute is not expected to change frequently. Hence, the LS receiving this attribute MAY disseminate it to other peers, both internal and external to the ITAD. 4.7. TrunkGroup and Carrier Address Families As described in TRIP [4], the address family field gives the type of address for the route. Two new address families and their codes are defined in this Section: Code Address Family 4 TrunkGroup 5 Carrier Bangalore, Kumar, Rosenberg, Salama, Shah [Page 16]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 When a set of GWs are to managed at the granularity of carriers or trunkgroups then it may be more appropriate for a GW to advertise routes using the Carrier address family or trunkgroup address family respectively. Also, in a TGREP association between the gateway and the LS responsible for managing that gateway, there are some attributes that more naturally fit in as advertised properties of trunkgroups or carriers rather than that of advertised prefixes; for example, the AvailableCircuit information on a particular trunkgroup or a particular carrier. To express this relationship, the existing TRIP address families are inadequate. We need separate address families that can associate certain properties like AvailableCircuits information to trunkgroups or carriers. The primary benefits of this model are as follows: - It allows a service provider to route calls based strictly on the trunkGroups or carriers. - it facilitates more accurate reporting of attributes of a dynamic nature like AvailableCircuits by providing the ability to manage resources at the granularity of a trunkgroup or a carrier. - Gateways can get really large with the ability to provision hundreds or a few thousand circuits and this can increase the potential for traffic that reports dynamic resource information between the gateway and the LS. The model introduced can potentially alleviate this UPDATE traffic hence increasing efficiency and providing a scalable gateway registration model. 4.7.1. Address Family Syntax Consider the generic TRIP route format from TRIP[4] shown below. 0 1 2 3 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 +---------------+---------------+--------------+----------------+ | Address Family | Application Protocol | +---------------+---------------+--------------+----------------+---- | Length | Address (variable) .... +---------------+---------------+--------------+----------------+---- Figure 5: Generic TRIP Route Format The Address Family field will be used to represent the type of the address associated for this family, which is based on the TrunkGroup or Carrier. The codes for the new address families will be allocated by IANA. The code for the trunk group address family is XX [[NOTE TO RFC-ED: Bangalore, Kumar, Rosenberg, Salama, Shah [Page 17]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 Please replace XX with the IANA assigned value for the trunk group address family]] and the code for the carrier address family is XXX [[NOTE TO RFC-ED: Please replace XX with the IANA assigned value for the carrier address family]]. The Application Protocol field is same as the one for the Decimal, PentaDecimal and E.164 address families defined in TRIP[4]. The Length field represents the total size of the Address field in bytes. The value in the Address field represents either the TrunkGroup or the Carrier address families and the syntax is as follows: For the TrunkGroup Address Family, the Address field is a variable length alphanumeric field (trunkgroup label), where length is determined by the length field of the route. The maximum value of the length field for this Address Family is 128 bytes. For the Carrier Address Family, the length field represents the length of the Address field in bytes. The Address field is a fixed length field representing Carrier value. The format of the Carrier value is as specified in the earlier section on "Carrier attribute" The CarrierIdCode is the code assigned to a carrier by a regulatory body operating in that region. The RegionCode represents the region where the CarrierIdCode is assigned. The RegionCode is a qualifier that makes the Carrier value globally unique. Regions are currently defined to map to countries. The RegionCode should use E.164 country code used in dialing international telephony destinations. However, regions can evolve in the future to encompass a larger area, beyond a country. For example, if a regulatory body in the European Union that assigns CarrierIds to carriers in the whole of Europe, a corresponding RegionCode would be used. The textual concatenation of CarrierId and RegionCode forms a Carrier. This is then used as a destination for routing purposes. When the scope of a CarrierIdCode is known to be unique a priori, the RegionCode is superfluous and MAY be excluded from the Carrier value when advertising in a TGREP UPDATE message. This is possible when the carrier is operating within the same region where the CarrierIdCode was assigned or if the carrier is operating in a controlled environment of networks where CarrierId is privately defined to be unique. If a gateway supports any of these address families, it should include that address family as one of the Route types supported in the OPEN message capability negotiation phase. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 18]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 The following attributes are currently defined to be used with all the address families including the TrunkGroup and Carrier address families. - AvailableCircuits Attribute - TotalCircuitCapacity Attribute - CallSuccess Attribute It is recommended that the above three attributes be used by the gateway with the TrunkGroup or Carrier address families, if possible. This will potentially offer a more efficient resource reporting framework, and a scalable model for gateway provisioning. However, when the gateway is not using TrunkGroup or Carrier address family, it MAY use the above attributes with the Decimal, PentaDecimal and E.164 address families. The prefix attribute cannot be used when the address family is E164 numbers, Pentadecimal routing numbers or Decimal routing numbers. The Carrier attribute cannot be used if the address family type is Carrier The TrunkGroup attribute cannot be used if the address family type is TrunkGroup 4.8. Gateway Operation A gateway uses TGREP to advertise its reachability to its domain's Location Server(s) (LS, which are closely coupled with proxies). The gateway operates in TGREP Send Only mode since it is only interested in advertising its reachability, but is not interested in learning about the reachability of other gateways and other domains. Also, the gateway will not create its own call routing database. In this section we describe the operation of TGREP on a gateway. 4.8.1. Session Establishment When opening a peering session with a TGREP Receiver, a TGREP gateway follows exactly the same procedures as any other TRIP speaker. The TGREP gateway sends an OPEN message which includes a Send Receive Capability in the Optional Parameters. The Send Receive Capability is set by the gateway to Send Only. The OPEN message also contains the address families supported by the gateway. The remainder of the peer session establishment is identical to TRIP. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 19]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 4.8.2. UPDATE Messages Once the peer session has been established, the gateway sends UPDATE messages to the TRIP LS with the gateway's entire reachability. The Gateway also sends any attributes associated with the routes. If the gateway's reachability changes at any point in time, the gateway MUST generate UPDATE message(s) with the change. The frequency of successive UPDATE messages MUST follow the same rules specified for TRIP[4]. The TGREP gateway MUST support all mandatory TRIP attributes. If the gateway receives an UPDATE message from the TRIP LS, it MUST silently discard it as specified for TRIP[4]. No further action should be taken. 4.8.3. KEEPALIVE Messages KEEPALIVE messages are periodically exchanged over the peering session between the TGREP gateway and the TRIP LS as specified in Section 4.4 of TRIP [4]. 4.8.4. Error Handling and NOTIFICATION Messages The same procedures used with TRIP, are used with TGREP for error handling and generating NOTIFICATION messages. The only difference is that a TGREP gateway will never generate a NOTIFICATION message in response to an UPDATE message, irrespective of the contents of the UPDATE message. Any UPDATE message is silently discarded. 4.8.5. TGREP Finite State Machine When the TGREP finite state machine is in the Established state and an UPDATE message is received, the UPDATE message is silently discarded and the TGREP gateway remains in the Established state. Other than that the TRIP finite state machine and the TGREP finite state machine are identical. 4.8.6. Call Routing Databases A TGREP gateway may maintain simultaneous sessions with more than one TRIP LSs. A TGREP gateway maintains one call routing database per peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out, and hence we will call them Adj-TRIB-GWs-Out. An Adj-TRIB-GW-Out Bangalore, Kumar, Rosenberg, Salama, Shah [Page 20]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 contains the gateway's reachability information advertised to its peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is outside the scope of this draft (possibly by manual configuration). The TGREP gateway does not have databases equivalent to TRIP's Adj- TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn routes from its peer TRIP LSs, and hence it does not run call route selection. 4.8.7. Multiple Address Families As mentioned above, TGREP supports various address families in order to convey the reachabilty of telephony destinations. A TGREP session MUST NOT send UPDATEs of more than one of the following categories (a) Prefix Address families (E164, Pentadecimal and decimal) (b) Trunkgroup address family (c) Carrier Address family for a given established session. TGREP should specify it's choice address family through the route-type capability in the OPEN message. And route-type specification in the OPEN message violating the above rule should be rejected with a NOTIFICATION message. 4.8.8. Route Selection and Aggregation TRIP's route selection and aggregation operations MUST NOT be implemented by TGREP gateways. 4.9. LS/Proxy Behavior As mentioned earlier, TGREP can be considered as a protocol complimentary to TRIP in providing reachability information that can then be further fed into the Location Server. The architecture of an LS/Proxy system is as follows: There exists a TRIP LS application that functions as a speaker in the I-TRIP/E-TRIP network as documented in TRIP [4]. This component is termed as "LS-Egress" for the purposes of this discussion. Then, there is a signaling server fronting a set of gateways. In conjunction with this signaling server, is also a second TRIP LS component operating in receive mode, that peers with one more gateways, each of them using TGREP to advertise routing information. This TRIP LS component on the receiving end of one or more TGREP sessions is termed as the "LS- Ingress" or "TGREP Receiver" for the purposes of this discussion. The LS-Ingress receiving the TRIP messages takes the resulting routing information from each gateway, and "exports" it to another process we are defining that performs consolidation and aggregation, in that Bangalore, Kumar, Rosenberg, Salama, Shah [Page 21]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 order. These operations would take as input the collective set of routes from all the gateways. Subsequently, the resulting TRIB is passed as input into the LS-Egress process as shown below, that can then disseminate these via TRIP. The interface between the LS-Ingress peering with the GW(s) and the TRIP LS (LS-Egress) is entirely a local matter. The nature of the Consolidation and Aggregation operations and the accompanying motivation are described in the subsections below. The order in which the operations are listed represents an implicit logical sequence in which they are applied. The architecture for an LS/Proxy entity is shown in Figure 7 below. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 22]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 +-------------------------------------------------------+ | +-------------------------------+ | | | +-+ +-+ | | | | |A| |C| | | +-----+ | | |g| |o| | | TGREP | | | +-------------+ | |g| |n| +-------------+ | | -- | GW | | | | | |r| |s| | | | | -- +-----+ | | TRIP | | |e| |o| | | | +-- | | LS <----------|g<--|l<--- TGREP |-++-| +-----+ | | | | |a| |i| | Session | | | | | | | (I-TRIP/ | | |t| |d| | Management |-++-+-------| GW | | | E-TRIP) | | |i| |a| | | | | +-----+ | | (LS-Egress) | | |o| |t| | |-+ -+- | +-----------/-+ | |n| |i| +-------------+ | | --- +-----+ | / | | | |o| | | -- | | | / | | | |n| (LS-Ingress) | | | GW | | / | +-+ +-+ | | +-----+ | / | TGREP Receiver | | | / +-------------------------------+ | | / | | / | +-------/-----------------------------------------------+ / LS/Proxy / / / / / +/----------------+ | | | | | | | LS | | | | | | | | | | | +----------------+ +------------------------------------------------------+ Bangalore, Kumar, Rosenberg, Salama, Shah [Page 23]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 | +-------------------------------+ | | | +-+ +-+ | | | | |A| |C| | | +-----+ | | |g| |o| | | TGREP | | | +-------------+ | |g| |n| +-------------+ | | -- | GW | | | | | |r| |s| | | | | -- +-----+ | | TRIP | | |e| |o| | | | +-- | | LS <----------|g<--|l<--- TGREP |-++-| +-----+ | | | | |a| |i| | Session | | | | | | | (I-TRIP/ | | |t| |d| | Management |-++-+-------| GW | | | E-TRIP) | | |i| |a| | | | | +-----+ | | (LS-Egress) | | |o| |t| | |-+ -+- | +-------------+ | |n| |i| +-------------+ | | --- +-----+ | | | | |o| | | -- | | | | | | |n| | | | GW | | | +-+ +-+ (LS-Ingress) | | +-----+ | | TGREP Receiver | | | +-------------------------------+ | | | | | +-------------------------------------------------------+ LS/Proxy Figure 7: LS Architecture for TRIP-GW 4.9.1. Route consolidation The TGREP receiver (LS-Ingress) may receive routing information from one or more gateways. It is possible that multiple routes are available for the same destination. These different alternative routes may be received from the same gateway, or from multiple gateways. It is RECOMMENDED that the set of gateway routes for each destination be consolidated, before presenting a candidate route, to the LS-Egress entity. The motivation for this operation should be to define a route that can maximally represent the collective routing capabilities of the set of gateways, managed by this TGREP receiver. Let us take an example scenario in order to bring out the motivation for this operation. Let us say, the TGREP receiver maintains peering sessions with gateways A, and B. - Gateway A advertises a route for destination "SIP 408" on the E.164 address family with the Carrier attribute value C1. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 24]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 - Gateway B advertises a route for destination "SIP 408" on the E.164 address family with Carrier attribute value C2. The TGREP receiver that receives these routes can consolidate these constituent routes into a single route for destination "SIP 408" with its Carrier attribute being a union of the the Carrier attribute values of the individual routes, namely, "C1 C2". This operation is referred to as Consolidation. In the above example, it is possible that a route to the destination "SIP 408" through one or more carriers may have been lost if the individual routes were not consolidated. Another example is to consolidate the Prefix attribute from multiple Carrier or Trunkgroup updates received from different gateways for the same destination. Let us say, there are Carrier AF updates from two gateways for Carrier destination X, and the prefix attribute values are {408, 650} from one update and {919, 973} from the other. The prefix values from these two updates can be consolidated into a single Carrier AF route advertisement with prefix value {408, 650, 919, 973}. In general, there is a potential for loss of gateway routing information, when TGREP routes from a set of gateways are not consolidated, when a candidate route is presented to the TRIP LS. The specifics of applying the consolidation operation to different attributes and routes from different address families, is left to the individual TGREP receiver implementations. 4.9.2. Aggregation The set of gateway routes, that are in a consolidated form or otherwise, may be aggregated before importing it to the LS instance that is responsible for I-TRIP/E-TRIP processing (LS-Egress). This operation follows the standard aggregation procedures described in the TRIP [4], while adhering to the aggregation rules for each route attribute. 4.9.3. Consolidation v/s Aggregation To highlight the difference between the two operations discussed above, "Consolidation" combines multiple routes for the same route destination, whereas "Aggregation" combines routes for different route destinations that qualify as candidates to be summarized resulting in route information reduction. To take an example, if there are multiple gateways offering routes to Bangalore, Kumar, Rosenberg, Salama, Shah [Page 25]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 an E.164 destination "408" but with possibly different attributes (Eg: Carrier), the LS/Proxy can combine these to form one route for "408" but representing the attribute information collectively. This process is Consolidation If, for example, the LS/Proxy receives routes for 4080, 4081, 4082, ... 4089 from amongst a set of gateways, it could aggregate these different candidate routes to have a summarized route destination "408" with each of the attributes computed using the Aggregation procedures defined in the TRIP. 5. Security Considerations The Security considerations defined in the TRIP [4] apply to TGREP sessions between Gateways and TGREP Receivers (TRIP LS). The security mechanism for the peering session between TGREP GW and a TRIP LS, in an IP network, is IPsec [6]. IPsec uses two protocols to provide traffic security: Authentication Header (AH) [7] and Encapsulating Security Payload (ESP) [8]. The AH header affords data origin authentication, connectionless integrity and optional anti-replay protection of messages passed between the peer LSs. The ESP header provides origin authentication, connectionless integrity, anti-replay protection, and confidentiality of messages. Implementations of the protocol defined in this document employing the ESP header SHALL comply with section 5 of [8], which defines a minimum set of algorithms for integrity checking and encryption. Similarly, implementations employing the AH header SHALL comply with section 5 of [7], which defines a minimum set of algorithms for integrity checking using manual keys. Implementations SHOULD use IKE [9] to permit more robust keying options. Implementations employing IKE SHOULD support authentication with RSA signatures and RSA public key encryption. A Security Association (SA) [6] is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to a SA by the use of AH, or ESP, but not both. Two types of SAs are defined: transport mode and tunnel mode [12]. A transport mode SA is a security association between two hosts, and is appropriate for protecting the TRIP session between two peer LSs. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 26]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 6. IANA Considerations Both TRIP[4] and TGREP share the same IANA registry for Capabilities, Attributes, Address Families, and Application Protocols. 6.1. Attribute Codes The Attribute Type Codes to be assigned for the new attributes defined in this document are listed below: | Code Attribute Reference | ---- --------- --------- | 13 TotalCircuitCapacity [RFCXXXX] | 14 AvailableCircuits [RFCXXXX] | 15 CallSuccess [RFCXXXX] | 16 E.164 Prefix [RFCXXXX] | 17 Pentadecimal Routing Number Prefix [RFCXXXX] | 18 Decimal Routing Number Prefix [RFCXXXX] | 19 TrunkGroup [RFCXXXX] | 19 Carrier [RFCXXXX] [NOTE TO RFC-ED: please replace XXXX with the rfc number of this specification ] 6.2. Address Family Codes The following subsections show the codes to be assigned for the two new address families introduced in this document 6.2.1. TrunkGroup Address Family | Code Address Family Reference | ---- -------------- --------- | 4 TrunkGroup [RFCXXXX] [NOTE TO RFC-ED: please replace XXXX with the rfc number of this specification ] 6.2.2. Carrier Address Family | Code Address Family Reference | ---- -------------- --------- | 5 Carrier [RFCXXXX] [NOTE TO RFC-ED: please replace XXXX with the rfc number of this specification ] Bangalore, Kumar, Rosenberg, Salama, Shah [Page 27]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 7. Change history [[NOTE TO RFC-ED: Please remove this section prior to publication]] 7.1. Changes since draft-ietf-iptel-tgrep-03.txt - No change in content. Releasing a new revision for renewal of draft. 7.2. Changes since draft-ietf-iptel-tgrep-02.txt - No change in content. Releasing a new revision for renewal of draft. 7.3. Changes since draft-ietf-iptel-tgrep-01.txt - Added a "Security Considerations" Section to the document. - Strengthened the text under "LS/Proxy Behavior" regarding Consolidation and Aggregation with additional examples for better clarity. - Removed the section "Other Attributes" including its subsection on the "Pricing" attribute. - Modified the definition of Carrier in the "Carrier attribute" and "TrunkGroup and Carrier Address Families" sections respectively. - Rectified the section number references in the "IANA Considerations" Section. - Strengthened the text in the attribute sections regarding dissemination of attributes received on TGREP. - Updated the "References" section. - Corrected typos, nits, grammatical errors, and language of the text throughout the document based on feedback from the iptel community. 7.4. Changes since draft-ietf-iptel-tgrep-00.txt - Added recommendations for AvailableCircuits and CallSuccess attributes. - Updated Carrier Attribute with ASCII syntax. - Removed thresholding scheme description. - Updated author addresses. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 28]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 7.5. Changes since draft-ietf-iptel-trip-gw-00.txt - Changed title of the document to TGREP (Telephony Gateway REgistration Protocol). - Changed name of protocol described in this document to TGREP. - Changed Abstract and Introduction sections to position TGREP as an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP). - Modified the section on LS/Proxy Behavior including the diagram. - Added an additional example to the Route Consolidation section. - Changed the format of Carrier (both as an attribute and as an AF) to accommodate representation of Country codes in association with CICs. - Updated text to allow Carrier attribute in TrunkGroup address family and TrunkGroup attribute in Carrier address family. 7.6. Changes since -03 - Removed Carrier-Trunkgroup attribute and address family and references to it. - Added Terminology and Definitions section. - Updated CallSuccess attribute. - Added Prefix attribute. - Added Carrier attribute. - Added TrunkGroup attribute. - Added TrunkGroup Address Family. - Added Carrier Address Family. - Added some more references. 7.7. Changes since -02 - Removed the requirements section. - Discussed the motivation for introducing Carrier information into TRIP. - Defined a new attribute for the E.164 address family. - Defined a new address family for CarrierCode-TrunkGroup combination . - Defined new attributes to advertise dynamic gateway characteristics like resource availability, and call success rate. - Added as section to validate the TGREP solution against the requirements in [7]. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 29]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 7.8. Changes since -01 - Added requirements. - Added more formal analysis of REGISTER and added analysis of SLP. - Removed circuit capacity attribute. 7.9. Changes since -00 - Added text to stress the value of this proposal for managing a gateway cluster. - Added attributes for circuit capacity and DSP capacity. - Added section on LS operation, discussing aggregation issue. 8. Acknowledgments We wish to thank David Oran, Anirudh Sahoo, Kevin McDermott, Jon Peterson, Li Li and Bob Penfield for their insightful comments and suggestions. 9. References 9.1. Normative References [1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 3261, Internet Engineering Task Force, Mar. 1999. [3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service location protocol, version 2," Request for Comments 2608, Internet Engineering Task Force, June 1999. [4] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over IP (TRIP)," Request for Comments 3219, Internet Engineering Task Force, January 2002. [5] J. Rosenberg and H. Schulzrinne, "A framework for telephony routing over IP," Request for Comments 2871, Internet Engineering Task Force, June 2000. [6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 30]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 [7] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. 9.2. Informative References [10] J. Rosenberg, "Requirements for Gateway Registration," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. [11] ITU-T List of ITU Carrier Codes (published periodically in the ITU-T Operational Bulletin). [12] J. Peterson, "An Architecture for Gateway Registration Based on Trunk Groups," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. Authors' Addresses Manjunath Bangalore Cisco Systems Inc. Mail Stop SJC-21/2/2 170 W. Tasman Drive San Jose, CA 95134 email: manjax@cisco.com Rajneesh Kumar Cisco Systems Inc. Mail Stop SJC-14/4/2 170 W. Tasman Drive San Jose, CA 95134 email: rajneesh@cisco.com Bangalore, Kumar, Rosenberg, Salama, Shah [Page 31]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 Jonathan Rosenberg Cisco Systems Inc. Mail Stop PPY02/2 600 Lanidex Plaza Parsippany NJ 07054 email: jdrosen@cisco.com Hussein F. Salama Cisco Systems Inc. Mail Stop CAI1 135 Abdel Aziz Fahmy Street 2nd Floor Apartment #3, Heliopolis Cairo, Egypt email: hsalama@cisco.com Dhaval N. Shah Cisco Systems Inc. Mail Stop SJC-06/4/3 170 W. Tasman Drive San Jose, CA 95134 email: dhaval@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary Bangalore, Kumar, Rosenberg, Salama, Shah [Page 32]
Internet Draft draft-ietf-iptel-tgrep-05.txt February 2005 rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bangalore, Kumar, Rosenberg, Salama, Shah [Page 33]
