summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5140.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5140.txt')
-rw-r--r--doc/rfc/rfc5140.txt1571
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]
+