doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc5140.txt b/doc/rfc/rfc5140.txt
new file mode 100644
index 0000000..3f3c11c
--- /dev/null
+++ b/doc/rfc/rfc5140.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+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.
+
+      - 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]
+
+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]
+
+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:
+
+   - 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]
+
+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]
+
+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]
+
+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.
+
+     - 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]
+
+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]
+