GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5140

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] 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] 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] 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] 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] 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.
  1. TotalCircuitCapacity: This attribute identifies the total number

of PSTN circuits that are available on a route to complete

      calls.
  1. 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] RFC 5140 TGREP March 2008

  1. CallSuccess: This attribute represents information about the

number of normally terminated calls out of a total number of

      attempted calls.
  1. Prefix (E164): This attribute is used to represent the list of

E164 prefixes to which the respective route can complete calls.

  1. Prefix (Decimal Routing Number): This attribute is used to

represent the list of Decimal prefixes to which the respective

      route can complete calls.
  1. Prefix (Hexadecimal Routing Number): This attribute is used to

represent the list of Hexadecimal prefixes to which the

      respective route can complete calls.
  1. TrunkGroup: This attribute enables providers to route calls to

destinations through preferred trunks.

  1. 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] 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] 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] 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] 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] 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] 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] 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] 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] 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:
  1. It allows a service provider to route calls based strictly on the

trunkgroups or carriers.

  1. 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] RFC 5140 TGREP March 2008

  1. 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] 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.
  1. AvailableCircuits attribute
  2. TotalCircuitCapacity attribute
  3. 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] 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] 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] 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] 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.
  1. Gateway A advertises a route for destination "SIP 408" on the

E.164 address family with the Carrier attribute value C1.

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

/data/webs/external/dokuwiki/data/pages/rfc/rfc5140.txt · Last modified: 2008/03/06 19:49 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki