[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-iptel-trip-gw) 00 01 02 03 04 05 06 07 08 09 RFC 5140

IPTEL Working Group                  Manjunath Bangalore, Cisco Systems
Internet Draft                            Rajneesh Kumar, Cisco Systems
draft-ietf-iptel-tgrep-07.txt    Hussein Salama, MenaNet Communications
February 2006                         Jonathan Rosenberg, Cisco Systems
Expiration Date: August 2006                 Dhaval Shah, Cisco Systems


           A Telephony Gateway REgistration Protocol (TGREP)


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 16, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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
   (TRIP) Location Server, which in turn can propagate that routing
   information within and between internet telephony administrative



Bangalore, Kumar, Rosenberg, Salama, Shah                       [Page 1]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   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.















































Bangalore, Kumar, Rosenberg, Salama, Shah                       [Page 2]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006




Table of Contents

    1    Terminology and Definitions  ..............................   4
    2    Introduction  .............................................   4
    3    TGREP: Overview of operation  .............................   6
    4    TGREP Attributes  .........................................   8
    4.1  TotalCircuitCapacity Attribute  ...........................   9
    4.2  AvailableCircuits Attribute  ..............................  10
    4.3  CallSuccess Attribute  ....................................  11
    4.4  Prefix Attributes  ........................................  13
    4.5  TrunkGroup Attribute  .....................................  14
    4.6  Carrier Attribute  ........................................  16
    5    TrunkGroup and Carrier Address Families  ..................  17
    5.1  Address Family Syntax  ....................................  18
    6    Gateway Operation  ........................................  20
    6.1  Session Establishment  ....................................  20
    6.2  UPDATE Messages  ..........................................  20
    6.3  KEEPALIVE Messages  .......................................  20
    6.4  Error Handling and NOTIFICATION Messages  .................  20
    6.5  TGREP Finite State Machine  ...............................  21
    6.6  Call Routing Databases  ...................................  21
    6.7  Multiple Address Families  ................................  21
    6.8  Route Selection and Aggregation  ..........................  21
    7    LS/Proxy Behavior  ........................................  22
    7.1  Route consolidation  ......................................  24
    7.2  Aggregation  ..............................................  25
    7.3  Consolidation v/s Aggregation  ............................  26
    8    Security Considerations  ..................................  26
    9    IANA Considerations  ......................................  27
    9.1  Attribute Codes  ..........................................  27
    9.2  Address Family Codes  .....................................  27
   10    Change history  ...........................................  28
   10.1  Changes since draft-ietf-iptel-tgrep-03.txt  ..............  28
   10.2  Changes since draft-ietf-iptel-tgrep-02.txt  ..............  28
   10.3  Changes since draft-ietf-iptel-tgrep-01.txt  ..............  28
   10.4  Changes since draft-ietf-iptel-tgrep-00.txt  ..............  29
   10.5  Changes since draft-ietf-iptel-trip-gw-00.txt  ............  29
   10.6  Changes since -03  ........................................  29
   10.7  Changes since -02  ........................................  29
   10.8  Changes since -01  ........................................  30
   10.9  Changes since -00  ........................................  30
   11    Acknowledgments  ..........................................  30
   12    References  ...............................................  30
   12.1  Normative References  .....................................  30
   12.2  Informative References  ...................................  31
         Authors' Addresses  .......................................  31



Bangalore, Kumar, Rosenberg, Salama, Shah                       [Page 3]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


         Intellectual Property Statement  ..........................  33
         Disclaimer of Validity  ...................................  33
         Copyright Statement  ......................................  33
         Acknowledgment  ...........................................  34





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 [2].
   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
   element is a SIP Proxy [10] or H.323 Gatekeeper. 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



Bangalore, Kumar, Rosenberg, Salama, Shah                       [Page 4]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   arrives at the POP. In conjunction with the proxy server that routes
   the call signaling, there are two components, the "Ingress LS"
   (a.k.a. "TGREP Receiver" and the "Egress LS". The "TGREP Receiver"
   component 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.

                     Signalling          TGREP
                   ------------->          <----------------

                                                 +---------+
                                                 |         |
                                                 |   GW    |
                                              >  +---------+
                                            //
                                          //
    SIP                                 //       +---------+
   <---->                             //         |         |
      +-------------------------+   //           |   GW    |
      |                         | //             +---------+
      |    +-------------+      |/
      |    |             |      |
      |    |  Routing    |      |                +---------+   TO PSTN
      |    |   Proxy     |      |                |         |
   --->    |             |      |----------->    |   GW    | ----->
      |+---+-----+ +-----+----+ |                +---------+
      ||         | |          | |
      ||        <+-+          | |--
      ||Egress LS| |Ingress LS| |  ---           +---------+
      ||         | |          | |     --         |         |
      |+---------+ +----------+ |       --       |   GW    |
      |                         |         --     +---------+
      |                         |           -->
      +-------------------------+
    TRIP                                         +---------+
   <---->                                        |         |
                                                 |   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



Bangalore, Kumar, Rosenberg, Salama, Shah                       [Page 5]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   real-time, as it changes. This means there must be some kind of
   communications between the proxy and the gateways to convey this
   information.

   The TRIP protocol [2] is defined for carrying telephony routing
   information between providers, for the purposes of getting a call
   routed to the right provider for termination to the PSTN. However,
   there is no mechanism defined in TRIP that defines how routes get
   injected into the TRIP protocol from within the network.  Nor does it
   define mechanisms which would allow the provider to select the
   specific gateway for terminating a call when it arrives. Those gaps
   are filled by TGREP.

   TGREP allows PSTN gateways or softswitches to inform a signaling
   server, such as a SIP proxy server or H.323 gatekeeper, of routes it
   has to the PSTN. These advertisements include fairly dynamic
   information, such as the remaining capacity in a particular trunk,
   which is essential for selecting the right gateway.

   TGREP is identical in syntax and overall operation to TRIP. However,
   it differs in the route processing rules followed by the TGREP
   receiver, allowing for a route processing function called
   "Consolidation". Consolidation combines multiple routes for the same
   route destination with different attributes to a single route to
   prevent loss of routing information. TGREP also defines a set of new
   attributes, usable by TGREP or TRIP. Finally, TGREP only utilizes a
   subset of overall TRIP capabilities.  Specifically, certain
   attributes are not utilized (as described below), and the TGREP
   entities (the sender and receiver) operate in an asymmetric
   relationship, whereas TRIP allows symmetric and asymmetric.

   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 [2]. 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 TGREP sender 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,
   hands over the reachability information a to TRIP Location Server.
   The routing proxy also uses the information to select the gateway for



Bangalore, Kumar, Rosenberg, Salama, Shah                       [Page 6]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   incoming calls.

   "Consolidation" combines multiple routes for the same route
   destination, whereas "Aggregation" combines routes for different
   route destinations that qualify as candidate routes to be summarized
   resulting in route information reduction.  To take an example, if
   there are multiple gateways offering routes to 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.

   The TGREP Sender establishes a session to the TGREP Receiver using
   the procedures similar to session establishment in TRIP.  After the
   session establishment the TGREP Sender 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 Receiver 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.

     - TotalCircuitCapacity: This attribute identifies the total number
       of PSTN circuits that are available on a route to complete calls.
     - AvailableCircuits: This attribute identifies the number of PSTN
       circuits that are currently available on a route to complete
       calls.
     - CallSuccess: This attribute represents information about the
       number of normally terminated calls out of a total number of
       attempted calls.
     - Prefix (E164): This attribute is used to represent the list of
       E164 prefixes that the respective route can complete calls to.





Bangalore, Kumar, Rosenberg, Salama, Shah                       [Page 7]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


     - Prefix (Decimal Routing Number): This attribute is used to
       represent the list of Decimal prefixes that the respective route
       can complete calls to.
     - Prefix (Hexadecimal Routing Number): This attribute is used to
       represent the list of Hexadecimal prefixes that the respective
       route can complete calls to.
     - TrunkGroup: This attribute enables providers to route calls to
       destinations through preferred trunks.
     - Carrier: This attribute enables providers to route calls to
       destinations through preferred carriers.

       In the rest of the document we specify attributes and address
       families used in TGREP. The new attributes and Address families
       introduced are also applicable for general usage in TRIP except
       where noted (AvailableCircuits attribute for example)


4. TGREP Attributes

   Due to its usage within a service provider network, TGREP makes use
   of a subset of the attributes defined for TRIP, in addition to
   defining several new ones. In particular, the following attributes
   from TRIP are applicable to TGREP:

   1. WithdrawnRoutes 2. ReachableRoutes 3. NexthopServer 4. Prefix 5.
   Communities

   TGREP also defines several new attributes, described in this section.
   These are TotalCircuitCapacity, AvailableCircuits, CallSuccess,
   TrunkGroup and Carrier. As mentioned above, these new attributes are
   usable by TRIP unless noted otherwise.

   A TGREP UPDATE supports the following attributes:
   1. TotalCircuitCapacity
   2. AvailableCircuits
   3. CallSuccess
   4. Prefix (E.164, Pentadecimal routing number, Decimal routing
      number)
   5. TrunkGroup
   6. Carrier











Bangalore, Kumar, Rosenberg, Salama, Shah                       [Page 8]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


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
   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



Bangalore, Kumar, Rosenberg, Salama, Shah                       [Page 9]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   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.


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.





Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 10]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


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.


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.



Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 11]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   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.

   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.




Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 12]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


4.3.4. Aggregation and CallSuccess

   Not applicable


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 [2]), 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.






Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 13]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006



   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 . . . 3456789012345678|0123...
   +-------------------------------+-----------+------------------------
   |             Length            | Prefix1...|   Length      |Prefix2
   +-------------------------------+-----------+------------------------


                          Figure 2: Prefix Format


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.







Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 14]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


4.5.1. TrunkGroup Syntax

   The TrunkGroup attribute is a variable length attribute that is
   composed of a sequence of trunkgroup identifiers. It indicates that
   the gateway can complete the call through any trunkgroup identifier
   indicated in the sequence.

   Each trunkgroup identifier is encoded as 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 field consisting of two
   sub-fields, a trunk group label followed by a trunk context, the two
   sub-fields separated by the delimiter ";" (semicolon). Both the trunk
   group label and the trunk context sub-fields are of variable length.
   The length field represents the total size of the value field
   including the delimiter.

   The permissible character set for the trunk group label and the trunk
   group context sub-fields and the associated ABNF [9] is per rules
   outlined in [4].

   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 1...    |     Length    |TrunkGroup 2...
   +---------------+--------------------+---------------+---------------
                        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.










Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 15]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


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.


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 identifiers.  It indicates that the route
   can complete the call to any of the carriers represented in the
   sequence of carrier identifiers.

   Each carrier identifier is encoded as a length-value field (shown in
   Figure 4 below). The length field is a 1-octet unsigned numeric
   value. The value field is a variable length field.

   The permissible character set for the value field and the associated
   ABNF [9] is per rules outlined in [5]. Specifically, it carries
   "global-cic" or "local-cic" [5]. In case of "local-cic", the
   "phonedigit-hex" part and the "cic-context" part would be separated
   by the delimiter ";". Hence, absence or presence of the delimiter can
   be used to determine if the value is a "global-cic" or a "local-cic".
   The length field represents the total size of the value field
   including the delimiter.



Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 16]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   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
   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     | Carrier 1...       |     Length    | Carrier 2...
   +---------------+--------------------+---------------+--------------
                         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.



5. TrunkGroup and Carrier Address Families

   As described in TRIP [2], 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 17]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   When a set of GWs are to be 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.


5.1. Address Family Syntax

   Consider the generic TRIP route format from TRIP[2] 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 4 and the code for the



Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 18]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   carrier address family is 5.

   The Application Protocol field is same as the one for the Decimal,
   PentaDecimal and E.164 address families defined in TRIP[2].  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 represents a
   Trunkgroup value that is defined as specified in an earlier Section
   4.5.1 about the TrunkGroup Attribute.

   For the Carrier Address Family, the Address field represents a
   Carrier value. This is same as the value field specified in an
   earlier Section 4.6.1 about the Carrier Attribute.

   The above mentioned address families are not heirarchical, but flat.
   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.

   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.




Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 19]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


6. 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 TRIP 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.


6.1. Session Establishment

   When opening a peering session with a TGREP Receiver, a TGREP gateway
   follows exactly the same procedures as any other TRIP entity. 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.


6.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.

   TGREP processing of the UPDATE message at the gateway is identical to
   UPDATE processing in TRIP[2]. A TGREP sender MUST support all
   mandatory TRIP attributes.


6.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 [2].


6.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.




Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 20]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


6.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.


6.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
   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.



6.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.


6.8. Route Selection and Aggregation

   TRIP's route selection and aggregation operations MUST NOT be
   implemented by TGREP gateways.








Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 21]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


7. 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 [2]. 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 component operating in receive mode, that
   peers with one more gateways, each of them using TGREP to advertise
   routing information. This 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. Also, the entity (typically, a
   Gateway) advertising the routes on the TGREP session is termed as the
   "TGREP Sender".  The "TGREP Receiver" receiving the TRIP messages
   takes the resulting routing information from each gateway, and
   "exports" it to another process we define below, that performs
   consolidation and aggregation, in that 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 TGREP Receiver(aka. 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-07.txt         February 2006



    +-------------------------------------------------------+
    |                    +-------------------------------+  |
    |                    |     +-+  +-+                  |  | TGREP
    |                    |     |A|  |C|                  |  |    +-----+
    |                    |     |g|  |o|                  |  |    |     |
    |   +-------------+  |     |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-07.txt         February 2006




    +-------------------------------------------------------+
    |                    +-------------------------------+  |
    |                    |     +-+  +-+                  |  | TGREP
    |                    |     |A|  |C|                  |  |    +-----+
    |                    |     |g|  |o|                  |  |    |     |
    |   +-------------+  |     |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


                   Figure 7: LS Architecture for TRIP-GW


7.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.







Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 24]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


     - Gateway A advertises a route for destination "SIP 408" on the
       E.164 address family with the Carrier attribute value C1.

     - 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.


7.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 [2], while adhering to the aggregation rules for each route
   attribute.











Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 25]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


7.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
   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.


8. Security Considerations

   The Security considerations for TGREP are identical to that
   identified in TRIP [2] and are just restated here for the purposes of
   clarity.

   The security mechanism for the peering session between TGREP GW and a
   TRIP LS, in an IP network, is IPsec [3].  IPsec uses two protocols to
   provide traffic security: Authentication Header (AH) [6] and
   Encapsulating Security Payload (ESP) [7].

   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 [7], which defines a
   minimum set of algorithms for integrity checking and encryption.
   Similarly, implementations employing the AH header SHALL comply with
   section 5 of [6], which defines a minimum set of algorithms for
   integrity checking using manual keys.

   Implementations SHOULD use IKE [8] to permit more robust keying
   options.  Implementations employing IKE SHOULD support authentication
   with RSA signatures and RSA public key encryption.



Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 26]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   A Security Association (SA) [3] 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.  A
   transport mode SA is a security association between two hosts, and is
   appropriate for protecting the TRIP session between two peer LSs.


9. IANA Considerations

   Both TRIP[2] and TGREP share the same IANA registry for Capabilities,
   Attributes, Address Families, and Application Protocols. This
   specification requests that IANA add the following attribute codes
   and address family codes to the TRIP [2] registries.


9.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 ]

9.2. Address Family Codes

   The following subsections show the codes to be assigned for the two
   new address families introduced in this document

9.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 ]



Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 27]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


9.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 ]


10. Change history

   [[NOTE TO RFC-ED: Please remove this section prior to publication]]


10.1. Changes since draft-ietf-iptel-tgrep-03.txt

     - No change in content. Releasing a new revision for renewal of
       draft.


10.2. Changes since draft-ietf-iptel-tgrep-02.txt

     - No change in content. Releasing a new revision for renewal of
       draft.


10.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.






Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 28]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


10.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.


10.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.


10.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.


10.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.






Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 29]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


     - 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 [6].



10.8. Changes since -01

     - Added requirements.
     - Added more formal analysis of REGISTER and added analysis of SLP.
     - Removed circuit capacity attribute.


10.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.


11. Acknowledgments

   We wish to thank Vijay Gurbani, Li Li, Kevin McDermott, David Oran,
   Bob Penfield, Jon Peterson, Anirudh Sahoo and James Yu for their
   insightful comments and suggestions.


12. References

12.1. Normative References

   [1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997.

   [2] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over
   IP (TRIP)," Request for Comments 3219, Internet Engineering Task
   Force, January 2002.

   [3]  Kent, S. and R. Atkinson, "Security Architecture for the
   Internet Protocol", RFC 2401, November 1998.

   [4] V. Gurbani and C. Jennings, "Representing trunk groups in tel/sip
   Uniform Resource Identifiers (URIs)," Internet Draft, Internet



Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 30]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   Engineering Task Force, August 2006.

   [5] J. Yu, "New Parameters for the "tel" URI to Support Number
   Portability," Internet Draft, Internet Engineering Task Force, August
   2006.

   [6]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
   November 1998.

   [7]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
   (ESP)", RFC 2406, November 1998.

   [8]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
   RFC 2409, November 1998.

   [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.


12.2. Informative References

   [10] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 3261, Internet
   Engineering Task Force, Mar. 1999.

   [11] J. Rosenberg and H. Schulzrinne, "A framework for telephony
   routing over IP," Request for Comments 2871, Internet Engineering
   Task Force, June 2000.

   [12] ITU-T List of ITU Carrier Codes (published periodically in the
   ITU-T Operational Bulletin).

   [13] J. Rosenberg, "Requirements for Gateway Registration," Internet
   Draft, Internet Engineering Task Force, Nov. 2001.  Work in progress.

   [14] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service
   location protocol, version 2," Request for Comments 2608, Internet
   Engineering Task Force, June 1999.


Authors' Addresses


   Manjunath Bangalore
   Cisco Systems Inc.
   Mail Stop SJC-21/2/2
   170 W. Tasman Drive
   San Jose, CA 95134



Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 31]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


   Phone: +1-408-902-3239
   email: manjax@cisco.com


   Rajneesh Kumar
   Cisco Systems Inc.
   Mail Stop SJC-14/4/2
   170 W. Tasman Drive
   San Jose, CA 95134
   Phone: +1-408-527-6148
   email: rajneesh@cisco.com


   Jonathan Rosenberg
   Cisco Systems Inc.
   Mail Stop PPY02/2
   600 Lanidex Plaza
   Parsippany
   NJ 07054
   Phone: +1-973-952-5060
   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
   Phone: +202-4166200
   email: hsalama@sysdsoft.com


   Dhaval N. Shah
   Cisco Systems Inc.
   Mail Stop SJC-20/3/3
   170 W. Tasman Drive
   San Jose, CA 95134
   Phone: +1-408-527-0436
   email: dhaval@cisco.com











Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 32]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


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
   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 (2006).  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.










Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 33]

Internet Draft       draft-ietf-iptel-tgrep-07.txt         February 2006


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















































Bangalore, Kumar, Rosenberg, Salama, Shah                      [Page 34]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/