path: root/doc/rfc/rfc5140.txt

Network Working Group                                       M. Bangalore
Request for Comments: 5140                                      R. Kumar
Category: Standards Track                                   J. Rosenberg
                                                                   Cisco
                                                               H. Salama
                                                          Citex Software
                                                               D.N. Shah
                                                             Moowee Inc.
                                                              March 2008


           A Telephony Gateway REgistration Protocol (TGREP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

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
   Domains (ITADs).  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, et al.           Standards Track                     [Page 1]
^L
RFC 5140                         TGREP                        March 2008


Table of Contents

   1. Introduction ....................................................3
   2. Terminology and Definitions .....................................5
   3. TGREP: Overview of Operation ....................................6
   4. TGREP Attributes ................................................7
      4.1. TotalCircuitCapacity Attribute .............................8
      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
   5. TrunkGroup and Carrier Address Families ........................16
      5.1. Address Family Syntax .....................................17
   6. Gateway Operation ..............................................18
      6.1. Session Establishment .....................................18
      6.2. UPDATE Messages ...........................................19
      6.3. KEEPALIVE Messages ........................................19
      6.4. Error Handling and NOTIFICATION Messages ..................19
      6.5. TGREP Finite State Machine ................................19
      6.6. Call Routing Databases ....................................19
      6.7. Multiple Address Families .................................20
      6.8. Route Selection and Aggregation ...........................20
   7. LS/Proxy Behavior ..............................................20
      7.1. Route Consolidation .......................................22
      7.2. Aggregation ...............................................23
      7.3. Consolidation versus Aggregation ..........................23
   8. Security Considerations ........................................23
   9. IANA Considerations ............................................24
      9.1. Attribute Codes ...........................................24
      9.2. Address Family Codes ......................................24
   10. Acknowledgments ...............................................25
   11. References ....................................................25
      11.1. Normative References .....................................25
      11.2. Informative References ...................................26
















Bangalore, et al.           Standards Track                     [Page 2]
^L
RFC 5140                         TGREP                        March 2008


1.  Introduction

   It is assumed that the reader of this document is familiar with TRIP
   [2, 12].  In typical Voice over IP (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 its network
   into geographic Points of Presence (POPs), with each POP containing
   some number of gateways, and a proxy server element that fronts those
   gateways.  The proxy element is a SIP proxy [11] 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 arrives at the POP.  In conjunction with the proxy server
   that routes the call signaling, there are two components, the
   "Ingress LS" (aka "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 is
   further injected into the Egress LS, which in turn disseminates into
   the rest of the network on TRIP.  For convenience, gateway and GW are
   used interchangeably.

   This configuration is depicted graphically in Figure 1.




























Bangalore, et al.           Standards Track                     [Page 3]
^L
RFC 5140                         TGREP                        March 2008


                     Signaling                 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 Public Switched Telephone Network
   (PSTN) destination (see [14]).  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.

   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




Bangalore, et al.           Standards Track                     [Page 4]
^L
RFC 5140                         TGREP                        March 2008


   define mechanisms that 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 soft switches 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 a 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.

2.  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 trunk is 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.






Bangalore, et al.           Standards Track                     [Page 5]
^L
RFC 5140                         TGREP                        March 2008


   TrunkGroup: A trunkgroup is 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 carrier is a company offering telephone and data
   communications between points (end-users and/or exchanges).

3.  TGREP: Overview of Operation

   TGREP is a route registration protocol for telephony destinations on
   a gateway.  These telephony destinations could be prefixes,
   trunkgroups, 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 optionally performs operations like consolidation and aggregation
   (see Section 7.3), and hands over the reachability information to a
   TRIP Location Server.  The routing proxy also uses the information to
   select the gateway for incoming calls.

   The TGREP sender establishes a session to the TGREP receiver using a
   procedure similar to session establishment in TRIP.  After the
   session establishment, the TGREP sender sends the reachability
   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.




Bangalore, et al.           Standards Track                     [Page 6]
^L
RFC 5140                         TGREP                        March 2008


      - 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 to which the respective route can complete calls.

      - Prefix (Decimal Routing Number): This attribute is used to
        represent the list of Decimal prefixes to which the respective
        route can complete calls.

      - Prefix (Hexadecimal Routing Number): This attribute is used to
        represent the list of Hexadecimal prefixes to which the
        respective route can complete calls.

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








Bangalore, et al.           Standards Track                     [Page 7]
^L
RFC 5140                         TGREP                        March 2008


   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

4.1.  TotalCircuitCapacity Attribute

   Mandatory: False.
   Required Flags: Not well-known.
   Potential Flags: None.
   TRIP Type Code: 13.

   The TotalCircuitCapacity attribute 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 possible 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 that can be
   terminated on this route in total.

4.1.2.  Route Origination and TotalCircuitCapacity

   Routes MAY be originated containing the TotalCircuitCapacity
   attribute.




Bangalore, et al.           Standards Track                     [Page 8]
^L
RFC 5140                         TGREP                        March 2008


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 that contains 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 attribute 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, et al.           Standards Track                     [Page 9]
^L
RFC 5140                         TGREP                        March 2008


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.

   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



Bangalore, et al.           Standards Track                    [Page 10]
^L
RFC 5140                         TGREP                        March 2008


   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
   to 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 composed of two component fields -- each
   represented as a 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.

   When the value for the total number of attempted calls wraps around,
   the counter value for the number of successful calls is reset to keep
   it aligned with the other component over a given window of time.  The
   TGREP receiver using this information should obtain this information
   frequently enough to prevent loss of significance.

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, et al.           Standards Track                    [Page 11]
^L
RFC 5140                         TGREP                        March 2008


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 to
   which the respective route can complete calls.  This attribute is
   intended to be used with the Carrier or TrunkGroup address family
   (discussed in Section 5).

   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 its 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 the 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, et al.           Standards Track                    [Page 12]
^L
RFC 5140                         TGREP                        March 2008


    < 2 octets > < Length1 octets > < 2 octets > < Length2 octets >

   +------------+--------------//--+------------+--------------//--+-
   |   Length1  |    Prefix1       |   Length2  |   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 attributes 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: 19.

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



Bangalore, et al.           Standards Track                    [Page 13]
^L
RFC 5140                         TGREP                        March 2008


   value.  The Value field is a variable-length field consisting of two
   subfields, a trunkgroup label followed by a trunk context, the two
   subfields separated by the delimiter ";" (semicolon).  Both the
   trunkgroup label and the trunk context subfields 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
   trunkgroup context subfields and the associated ABNF [8] is per rules
   outlined in [4].

   The presence of the TrunkGroup attribute with the Length field of the
   attribute as 0 signifies that the TGREP GW can terminate ALL
   trunkgroups for the given Reachable route(s).

    < 1 octet > < Length1 octets > < 1 octet > < Length2 octets >

   +-----------+--------------//--+-----------+--------------//--+-
   |  Length1  |  TrunkGroup 1    |  Length2  |  TrunkGroup 2    | ...
   +-----------+--------------//--+-----------+--------------//--+-

                        Figure 3: TrunkGroup Syntax

4.5.2.  Route Origination and TrunkGroup

   Routes MAY be originated containing the TrunkGroup attribute.

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 attributes 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, et al.           Standards Track                    [Page 14]
^L
RFC 5140                         TGREP                        March 2008


4.6.  Carrier Attribute

   Mandatory: False.
   Required Flags: Not well-known.
   Potential Flags: None.
   TRIP Type Code: 20.

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

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

   The presence of the 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).

    < 1 octet > < Length1 octets > < 1 octet > < Length2 octets >

   +-----------+--------------//--+-----------+--------------//--+-
   |  Length1  |  Carrier 1       |  Length2  |  Carrier 2       | ...
   +-----------+--------------//--+-----------+--------------//--+-

                         Figure 4: Carrier Syntax

4.6.2.  Route Origination and Carrier

   Routes MAY be originated containing the Carrier attribute.




Bangalore, et al.           Standards Track                    [Page 15]
^L
RFC 5140                         TGREP                        March 2008


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

   When a set of GWs is 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.



Bangalore, et al.           Standards Track                    [Page 16]
^L
RFC 5140                         TGREP                        March 2008


   - It enables scalability as 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 have been
   allocated by IANA.

   The code for the TrunkGroup address family is 4, and the code for the
   Carrier address family is 5.

   The Application Protocol field is the 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
   Carrier address family, and the syntax is as follows:

   For the TrunkGroup address family, the Address field represents a
   TrunkGroup value that is defined as specified in Section 4.5.1,
   "TrunkGroup Syntax".

   For the Carrier address family, the Address field represents a
   Carrier value.  This is the same as the Value field specified in an
   earlier Section 4.6.1, "Carrier Syntax".






Bangalore, et al.           Standards Track                    [Page 17]
^L
RFC 5140                         TGREP                        March 2008


   The above mentioned address families are not hierarchical, 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 family, 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 the 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.

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 that includes a Send Receive
   Capability in the Optional Parameters.  The Send Receive Capability




Bangalore, et al.           Standards Track                    [Page 18]
^L
RFC 5140                         TGREP                        March 2008


   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.

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 LS.  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-TRIBs-GW-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 document (possibly by manual
   configuration).





Bangalore, et al.           Standards Track                    [Page 19]
^L
RFC 5140                         TGREP                        March 2008


   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 reachability 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, or (c) Carrier address
   family for a given established session.  TGREP should specify its
   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.

7.  LS/Proxy Behavior

   As mentioned earlier, TGREP can be considered as a protocol
   complimentary to TRIP in providing reachability information, which
   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 "Egress LS"
   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, which peers with one or 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 "Ingress LS" 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 Ingress LS) peering with the GW(s) and the TRIP LS (Egress LS)
   is entirely a local matter.



Bangalore, et al.           Standards Track                    [Page 20]
^L
RFC 5140                         TGREP                        March 2008


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

    +-------------------------------------------------------+
    |                    +-------------------------------+  |
    |                    |     +-+  +-+                  |  | 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|  |             | |  |    +-----+
    |   | (Egress LS) |  |     |o|  |t|  |             |-+  +---
    |   +-----------/-+  |     |n|  |i|  +-------------+ |  |    +-----+
    |              /     |     | |  |o|                  |  |  --|     |
    |             /      |     | |  |n|    (Ingress LS)  |  |    | GW  |
    |            /       |     +-+  +-+                  |  |    +-----+
    |           /        |              TGREP Receiver   |  |
    |          /         +-------------------------------+  |
    |         /                                             |
    |        /                                              |
    +-------/-----------------------------------------------+
           /                            LS/Proxy
          /
         /
        /
       /
      /
    +/----------------+
    |                 |
    |                 |
    |                 |
    |       LS        |
    |                 |
    |                 |
    |                 |
    |                 |
    |                 |
    +-----------------+

                   Figure 6: LS Architecture for TRIP-GW




Bangalore, et al.           Standards Track                    [Page 21]
^L
RFC 5140                         TGREP                        March 2008


7.1.  Route Consolidation

   The TGREP receiver (Ingress LS) 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 Egress LS 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.

     - 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 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 address family
   (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.






Bangalore, et al.           Standards Track                    [Page 22]
^L
RFC 5140                         TGREP                        March 2008


7.2.  Aggregation

   The set of gateway routes, which 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 (Egress LS).  This
   operation follows the standard aggregation procedures described in
   TRIP [2], while adhering to the aggregation rules for each route
   attribute.

7.3.  Consolidation versus 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
   (e.g., 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 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.






Bangalore, et al.           Standards Track                    [Page 23]
^L
RFC 5140                         TGREP                        March 2008


   Implementations of the protocol defined in this document employing
   the ESP header SHALL comply with Section 3.1.1 of [10], which defines
   a minimum set of algorithms for integrity checking and encryption.
   Similarly, implementations employing the AH header SHALL comply with
   Section 3.2 of [10], which defines a minimum set of algorithms for
   integrity checking.

   Implementations SHOULD use the Internet Key Exchange Protocol (IKEv2)
   [9] to permit more robust keying options.  Implementations employing
   IKEv2 SHOULD support 3DES-CBC for confidentiality and HMAC-SHA1 for
   integrity.

   A Security Association (SA) [3] is a simplex "connection" that
   affords security services to the traffic carried by it.  Security
   services are afforded to an 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.  IANA has added the following attribute codes and address
   family codes to the TRIP [2] registries.

9.1.  Attribute Codes

   The Attribute Type Codes assigned for the new attributes defined in
   this document are listed below:

      Code      Attribute                        Reference
      ----      ---------                        ---------
      13     TotalCircuitCapacity                [RFC5140]
      14     AvailableCircuits                   [RFC5140]
      15     CallSuccess                         [RFC5140]
      16     E.164 Prefix                        [RFC5140]
      17     Pentadecimal Routing Number Prefix  [RFC5140]
      18     Decimal Routing Number Prefix       [RFC5140]
      19     TrunkGroup                          [RFC5140]
      20     Carrier                             [RFC5140]

9.2.  Address Family Codes

   The following subsections show the codes that have been assigned for
   the two new address families introduced in this document.





Bangalore, et al.           Standards Track                    [Page 24]
^L
RFC 5140                         TGREP                        March 2008


9.2.1.  TrunkGroup Address Family

      Code      Address Family                   Reference
      ----      --------------                   ---------
       4          TrunkGroup                     [RFC5140]

9.2.2.  Carrier Address Family

      Code      Address Family                   Reference
      ----      --------------                   ---------
       5          Carrier                        [RFC5140]

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

11.  References

11.1.  Normative References

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

   [2]  Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
        over IP (TRIP)", RFC 3219, January 2002.

   [3]  Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", RFC 4301, December 2005.

   [4]  Gurbani, V. and C. Jennings, "Representing Trunk Groups in
        tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, June
        2007.

   [5]  Yu, J., "Number Portability Parameters for the "tel" URI", RFC
        4694, October 2006.

   [6]  Kent, S., "IP Authentication Header", RFC 4302, December 2005.

   [7]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
        December 2005.

   [8]  Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [9]  Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
        4306, December 2005.



Bangalore, et al.           Standards Track                    [Page 25]
^L
RFC 5140                         TGREP                        March 2008


   [10] Manral, V., "Cryptographic Algorithm Implementation Requirements
        for Encapsulating Security Payload (ESP) and Authentication
        Header (AH)", RFC 4835, April 2007.

11.2. Informative References

   [11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [12] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony
        Routing over IP", RFC 2871, June 2000.

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

   [14] Rosenberg, J., "Requirements for Gateway Registration", Work in
        Progress, November 2001.

































Bangalore, et al.           Standards Track                    [Page 26]
^L
RFC 5140                         TGREP                        March 2008


Authors' Addresses

   Manjunath S. Bangalore
   Cisco
   Mail Stop SJC-14/2/1
   3625 Cisco Way
   San Jose, CA 95134
   Phone: +1-408-525-7555
   EMail: manjax@cisco.com

   Rajneesh Kumar
   Cisco
   Mail Stop SJC-14/4/2
   3625 Cisco Way
   San Jose, CA 95134
   Phone: +1-408-527-6148
   EMail: rajneesh@cisco.com

   Jonathan Rosenberg
   Cisco
   Edison, NJ 08837
   EMail: jdrosen@cisco.com

   Hussein F. Salama
   Citex Software
   Giza, Egypt
   EMail: hsalama@citexsoftware.com

   Dhaval Niranjan Shah
   Moowee Inc.
   4920 El Camino Real
   Los Altos, CA 94022
   Phone: +1-408-307-7455
   EMail: dhaval@moowee.tv

















Bangalore, et al.           Standards Track                    [Page 27]
^L
RFC 5140                         TGREP                        March 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.

Intellectual Property

   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.












Bangalore, et al.           Standards Track                    [Page 28]
^L