draft-ietf-iptel-tgrep-01.txt   draft-ietf-iptel-tgrep-02.txt 
IPTEL Working Group Manjunath Bangalore, Cisco Systems IPTEL Working Group Manjunath Bangalore, Cisco Systems
Internet Draft Rajneesh Kumar, Cisco Systems Internet Draft Rajneesh Kumar, Cisco Systems
draft-ietf-iptel-tgrep-01.txt Jonathan Rosenberg, dynamicsoft draft-ietf-iptel-tgrep-02.txt Jonathan Rosenberg, dynamicsoft
October 2002 Hussein Salama, Cisco Systems June 2003 Hussein Salama, Cisco Systems
Expiration Date: August 2003 Dhaval N. Shah, Cisco Systems Expiration Date: December 2003 Dhaval N. Shah, Cisco Systems
A Telephony Gateway REgistration Protocol (TGREP) A Telephony Gateway REgistration Protocol (TGREP)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 38 skipping to change at page 1, line 38
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes the Telephony Gateway Registration Protocol This document describes the Telephony Gateway Registration Protocol
(TGREP) for registration of telephony prefixes supported by telephony (TGREP) for registration of telephony prefixes supported by telephony
gateways and soft switches. The registration mechanism can also be gateways and soft switches. The registration mechanism can also be
used to export resource information. The prefix and resource used to export resource information. The prefix and resource
information can then be passed on to a TRIP Location Server, which in information can then be passed on to a TRIP Location Server, which in
turn can propogate that routing information within the same, and turn can propogate that routing information within and between
other internet telephony administrative domains (ITAD). TGREP shares internet telephony administrative domains (ITAD). TGREP shares a lot
a lot of similarites with the TRIP Protocol. It has similar of similarites with the TRIP Protocol. It has similar procedures and
procedures and Finite State Machine for session establishment. It Finite State Machine for session establishment. It also shares the
also shares the same format for messaages and a subset of attributes same format for messages and a subset of attributes with TRIP.
with TRIP.
1. Terminology and Definitions 1. Terminology and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Some other useful definitions are: Some other useful definitions are:
Circuit: A circuit is a discrete (specific) path between two or more
points along which signals can be carried. In this context, a circuit
is a physical path, consisting of one or more wires and possibly
intermediate switching points.
Trunk: In a network, a communication path connecting two switching Trunk: In a network, a communication path connecting two switching
systems used in the establishment of an end-to-end connection. In systems used in the establishment of an end-to-end connection. In
selected applications, it may have both its terminations in the same selected applications, it may have both its terminations in the same
switching system. switching system.
TrunkGroup: A set of trunks, traffic engineered as a unit, for the TrunkGroup: A set of trunks, traffic engineered as a unit, for the
establishment of connections within or between switching systems in establishment of connections within or between switching systems in
which all of the paths are interchangeable except where subgrouped. which all of the paths are interchangeable except where subgrouped.
Carrier: An organization that provides connections for telephony Carrier: A company offering telephone and data communications between
services between end-users and/or exchanges. points (end-users and/or exchanges).
2. Introduction 2. Introduction
In typical VoIP networks, Internet Telephony Administrative Domains In typical VoIP networks, Internet Telephony Administrative Domains
(ITADs) will deploy numerous gateways for the purposes of (ITADs) will deploy numerous gateways for the purposes of
geographical diversity, capacity, and redundancy. When a call arrives geographical diversity, capacity, and redundancy. When a call arrives
at the domain, it must be routed to one of those gateways. at the domain, it must be routed to one of those gateways.
Frequently, an ITAD will break their network into geographic POPs, Frequently, an ITAD will break their network into geographic POPs,
with each POP containing some number of gateways, and a proxy server with each POP containing some number of gateways, and a proxy server
element that fronts those gateways. The proxy server is responsible element that fronts those gateways. The proxy server is responsible
skipping to change at page 3, line 38 skipping to change at page 3, line 38
+---------+ +---------+
| | | |
| GW | | GW |
+---------+ +---------+
Figure 1: Gateway and LS Configuration Figure 1: Gateway and LS Configuration
The decision about which gateway to use depends on many factors, The decision about which gateway to use depends on many factors,
including their availability, remaining call capacity and call including their availability, remaining call capacity and call
success statistics particular POTS destination. For the proxy to do success statistics to a particular PSTN destination. For the proxy to
this adequately, it needs to have access to this information in 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 real-time, as it changes. This means there must be some kind of
communications between the proxy and the gateways to convey this communications between the proxy and the gateways to convey this
information. information.
In this document, we specify a protocol for registration of routes In this document, we specify a protocol for registration of routes
(destinations) supported by the gateway to the TRIP Location Server, (destinations) supported by the gateway to the TRIP Location Server,
known as Telephony Gateway REgistration Protocol (TGREP). TGREP known as Telephony Gateway REgistration Protocol (TGREP). TGREP
Protocol can be considered an auxiliary protocol to TRIP. Routes Protocol can be considered an auxiliary protocol to TRIP. Routes
learnt through TGREP can be injected into and further processed learnt through TGREP can be injected into and further processed
and/or propogated by the TRIP Location Server. and/or propogated by the TRIP Location Server.
TGREP shares a lot of commonality with the TRIP in various aspects. TGREP shares a lot of commonality with TRIP in various aspects.
Particularly, TGREP and TRIP have the same session establishment Particularly, TGREP and TRIP have the same session establishment
procedures, state machine etc. TGREP also makes use of a similar procedures, state machine, etc. TGREP also makes use of a similar
UPDATE message to propogate the routes supported. It uses UPDATE message to propogate the routes supported. It uses
Notification, Keepalive and OPEN message in the same essence as TRIP. Notification, Keepalive and OPEN message in the same essence as TRIP.
TGREP defines few new attributes that are needed to specify certain TGREP defines few new attributes that are needed to specify certain
characterstics of gateways, like Available Capacity for a destination characteristics of gateways, like Available Capacity for a
etc. The document aims at specifying all the attributes that can go destination. The document aims at specifying all the attributes
in on the TGREP session. The document also specified some new address related to the TGREP session. This document also specifies some new
families which can be useful in advertising the information on the address families which can be useful in advertising the information
GWs. The type codes for the new attributes and address families are on the GWs.
yet to be obtained from IANA. An attempt will be made to assign the
codes in such a way that they are in continuation with the codes
assigned for attributes and families defined in the the TRIP RFC[4].
As a general rule, because of lot of similarities between TRIP and As a general rule, because of lot of similarities between TRIP and
TGREP, frequent reference will be made to the terminologies and TGREP, frequent reference will be made to the terminologies and
formats defined in TRIP RFC[4]. It is suggested that the reader be formats defined in TRIP RFC[4]. It is suggested that the reader be
familiar with the concepts of TRIP like attributes, flags, route familiar with the concepts of TRIP like attributes, flags, route
types, address families etc. types, address families, etc.
3. Defining TGREP 3. Defining TGREP
TGREP is a route registration protocol for telephony destinations on TGREP is a route registration protocol for telephony destinations on
a gateway. These telephony destinations could be prefixes, trunk a gateway. These telephony destinations could be prefixes, trunk
groups or Carriers. The Speaker of TGREP resides on the GW and groups or Carriers. The Speaker of TGREP resides on the GW and
gathers all the information from the GW to relay to the other side. A gathers all the information from the GW to relay to the other side. A
TGREP Receiver is defined, which receives this information and after TGREP Receiver is defined, which receives this information and after
certain optional operations like consolidation, aggregation etc. certain optional operations like consolidation and aggregation.
(defined in Sections 3.10.1 and 3.10.2) hands over the reachability (defined in Sections 3.10.1 and 3.10.2) hands over the reachability
information a to TRIP Location Server. information a to TRIP Location Server.
The TGREP speaker establishes a session to the TGREP Receiver using The TGREP speaker establishes a session to the TGREP Receiver using
the procedures similar to session establishment in TRIP. The TGREP the procedures similar to session establishment in TRIP. The TGREP
Speaker is however, in "Send only" mode and the receiver is in the Speaker is however, in "Send only" mode and the receiver is in the
"Receive only" mode. After the session establishment the TGREP "Receive only" mode. After the session establishment the TGREP
speaker sends the reachibility informaton in the UPDATE messages. The speaker sends the reachibility informaton in the UPDATE messages. The
UPDATE messages have the same format as in TRIP. However, there are UPDATE messages have the same format as in TRIP. However, certain
certain attributes that are not relevant in TGREP. TGREP also defines TRIP attributes are not relevant in TGREP; a TGREP speaker MAY ignore
certain new attributes that find a use in a TGREP update. them if they are present in a TGREP message. In addition, TGREP
defines the new attributes described in this document to be carried
in a TGREP UPDATE message.
In the rest of the document we specify attributes and address In the rest of the document we specify attributes and address
families used in TGREP. We also specify the operations of families used in TGREP. We also specify the operations of
consolidation and aggregation as they apply to the UPDATEs received consolidation and aggregation as they apply to the UPDATEs received
from the TGREP Gateway by the TGREP Receiver. from the TGREP Gateway by the TGREP Receiver.
A TGREP UPDATE supports the following attributes: A TGREP UPDATE supports the following attributes:
1. WithdrawnRoutes (as defined in TRIP) 1. WithdrawnRoutes (as defined in TRIP)
2. ReachableRoutes (as defined in TRIP) 2. ReachableRoutes (as defined in TRIP)
3. NexthopServer (as defined in TRIP) 3. NexthopServer (as defined in TRIP)
skipping to change at page 5, line 20 skipping to change at page 5, line 19
8. TrunkGroup 8. TrunkGroup
9. Carrier 9. Carrier
3.1. TotalCircuitCapacity Attribute 3.1. TotalCircuitCapacity Attribute
Mandatory: False. Mandatory: False.
Required Flags: Not well-known. Required Flags: Not well-known.
Potential Flags: None. Potential Flags: None.
TRIP Type Code: 13 (To be assigned by IANA) TRIP Type Code: 13 (To be assigned by IANA)
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 propogated beyond the LS that receives it.
The TotalCircuitCapacity identifies the total number of PSTN circuits The TotalCircuitCapacity identifies the total number of PSTN circuits
that are available on a route to complete calls. It is used in that are available on a route to complete calls. It is used in
conjunction with the AvailableCircuits attribute in gateway selection conjunction with the AvailableCircuits attribute in gateway selection
by the LS. The total number of calls sent to the specified route on by the LS. The total number of calls sent to the specified route on
the gateway cannot exceed this total circuit capacity under steady the gateway cannot exceed this total circuit capacity under steady
state conditions. state conditions.
TotalCircuitCapacity is measured in integral number of calls. This is The TotalCircuitCapacity attribute is used to reflect the
not expected to change frequently. This can change, for instance, administratively provisioned capacity as opposed to the availability
when certain telephony trunks on the gateway are taken out of service at a given point in time as provided by the AvailableCircuits
for maintenance purposes. attribute. Because of its relatively static nature, this attribute
MAY be propogated beyond the LS that receives it.
TotalCircuitCapacity represents the total number of active calls at
any instant. This is not expected to change frequently. This can
change, for instance, when certain telephony trunks on the gateway
are taken out of service for maintenance purposes.
3.1.1. TotalCircuitCapacity Syntax 3.1.1. TotalCircuitCapacity Syntax
The TotalCircuitCapacity attribute is a 4-octet unsigned numeric The TotalCircuitCapacity attribute is a 4-octet unsigned numeric
value. It represents the total number of circuits available for value. It represents the total number of circuits available for
terminating calls through this advertised route. This attribute terminating calls through this advertised route. This attribute
represents a potentially achievable upper bound on the number of represents a potentially achievable upper bound on the number of
calls which can be terminated on this route in total. calls which can be terminated on this route in total.
3.1.2. Route Origination and TotalCircuitCapacity 3.1.2. Route Origination and TotalCircuitCapacity
skipping to change at page 6, line 42 skipping to change at page 6, line 42
LS receiving this attribute MAY disseminate it to other peers, both LS receiving this attribute MAY disseminate it to other peers, both
internal and external to the ITAD. internal and external to the ITAD.
3.2. AvailableCircuits Attribute 3.2. AvailableCircuits Attribute
Mandatory: False. Mandatory: False.
Required Flags: Not well-known. Required Flags: Not well-known.
Potential Flags: None. Potential Flags: None.
TRIP Type Code: 14. (To be assigned by IANA) TRIP Type Code: 14. (To be assigned by IANA)
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 MUST NOT be propagated unless the LS is sure that it
is relatively static.
The AvailableCircuits identifies the number of PSTN circuits that are The AvailableCircuits identifies the number of PSTN circuits that are
currently available on a route to complete calls. The number of currently available on a route to complete calls. The number of
additional calls sent to that gateway for that route cannot exceed additional calls sent to that gateway for that route cannot exceed
the circuit capacity. If it does, the signaling protocol will likely the circuit capacity. If it does, the signaling protocol will likely
generate errors, and calls will be rejected. generate errors, and calls will be rejected.
AvailableCircuits is measured in integral number of calls. It is very The AvailableCircuits attribute is used ONLY between a gateway and
dynamic. its peer LS responsible for managing that gateway. If it is received
in a route, it is not propagated.
3.2.1. AvailableCircuits Syntax 3.2.1. AvailableCircuits Syntax
The AvailableCircuits attribute is a 4-octet unsigned numeric value. The AvailableCircuits attribute is a 4-octet unsigned numeric value.
It represents the number of circuits remaining for terminating calls It represents the number of circuits remaining for terminating calls
to this route. to this route.
3.2.2. Route Origination and AvailableCircuits 3.2.2. Route Origination and AvailableCircuits
Routes MAY be originated containing the AvailableCircuits attribute. Routes MAY be originated containing the AvailableCircuits attribute.
skipping to change at page 8, line 21 skipping to change at page 8, line 14
3.3. CallSuccess Attribute 3.3. CallSuccess Attribute
Mandatory: False. Mandatory: False.
Required Flags: Not well-known. Required Flags: Not well-known.
Potential Flags: None. Potential Flags: None.
TRIP Type Code: 15. (To be assigned by IANA) TRIP Type Code: 15. (To be assigned by IANA)
The CallSuccess attribute is an attribute used ONLY between a gateway The CallSuccess attribute is an attribute used ONLY between a gateway
and its peer LS responsible for managing that gateway. If it is and its peer LS responsible for managing that gateway. If it is
received in a route, it MUST NOT be propagated. received in a route, it is not propagated.
The CallSuccess attribute provides information about the number of The CallSuccess attribute provides information about the number of
normally terminated calls out of a total number of attempted calls. normally terminated calls out of a total number of attempted calls.
CallSuccess is to be determined by the gateway based on the CallSuccess is to be determined by the gateway based on the
Disconnect cause code at call termination. For example, a call that Disconnect cause code at call termination. For example, a call that
reaches the Alerting stage but does not get connected because of reaches the Alerting stage but does not get connected due to the
called party being unavailable is conventionally considered a unavailability of the called party, or the called party being busy,
successful call. Similar is the case when the called party is busy. is conventionally considered a successful call. On the other hand, a
On the other hand, a call that gets disconnected because of a Circuit call that gets disconnected because of a Circuit or Resource being
or Resource being unavailable is conventionally considered a failed unavailable is conventionally considered a failed call. The exact
call. The exact mapping of disconnect causes to CallSuccess is at the mapping of disconnect causes to CallSuccess is at the discretion of
discretion of the gateway reporting the attribute. the gateway reporting the attribute.
The CallSuccess attribute is used by the LS to keep track of failures The CallSuccess attribute is used by the LS to keep track of failures
in reaching certain telephony destinations through a gateway(s) and in reaching certain telephony destinations through a gateway(s) and
use that information in the gateway selection process to enhance the use that information in the gateway selection process to enhance the
probability of successful call termination. probability of successful call termination.
This information can be used by the LS to consider alternative This information can be used by the LS to consider alternative
gateways to terminate calls to those destinations with a better gateways to terminate calls to those destinations with a better
likelihood of success. likelihood of success.
3.3.1. CallSuccess Syntax 3.3.1. CallSuccess Syntax
The CallSuccess attribute is comprised of two component fields - each The CallSuccess attribute is comprised of two component fields - each
represented as an unsigned 4-octet numeric value. The first represented as an unsigned 4-octet numeric value. The first
component field represents the total number of calls terminated component field represents the total number of calls terminated
normally for the advertised destination on a given address family. successfully for the advertised destination on a given address
The second component field represents the total number of attempted family. The second component field represents the total number of
calls for the advertised destination. attempted calls for the advertised destination within some window of
time.
3.3.2. Route Origination and CallSuccess 3.3.2. Route Origination and CallSuccess
Routes MAY be originated containing the CallSuccess attribute. This Routes MAY be originated containing the CallSuccess attribute. This
attribute is expected to get statistically significant with passage attribute is expected to get statistically significant with passage
of time as more calls are attempted. It is RECOMMENDED that of time as more calls are attempted. It is RECOMMENDED that
sufficiently large windows be used to provide a useful aggregated sufficiently large windows be used to provide a useful aggregated
statistic. statistic.
3.3.3. Route Selection and CallSuccess 3.3.3. Route Selection and CallSuccess
skipping to change at page 9, line 30 skipping to change at page 9, line 29
of successful call termination. of successful call termination.
3.3.4. Aggregation and CallSuccess 3.3.4. Aggregation and CallSuccess
Not applicable Not applicable
3.3.5. Route Dissemination and CallSuccess 3.3.5. Route Dissemination and CallSuccess
Routes MUST NOT be disseminated with the CallSuccess attribute. Its Routes MUST NOT be disseminated with the CallSuccess attribute. Its
potential to change dynamically does not make it suitable to potential to change dynamically does not make it suitable to
disseminate in most cases. disseminate.
3.4. Prefix Attributes 3.4. Prefix Attributes
Mandatory: False. Mandatory: False.
Required Flags: Not well-known. Required Flags: Not well-known.
Potential Flags: None. Potential Flags: None.
TRIP Type Codes: 16 for E164 prefix, 17 for pentadecimal prefix and TRIP Type Codes: 16 for E164 prefix, 17 for pentadecimal prefix and
18 for decimal prefix (To be assigned by IANA) 18 for decimal prefix (To be assigned by IANA)
The Prefix attribute is used to represent the list of prefixes that The Prefix attribute is used to represent the list of prefixes that
skipping to change at page 11, line 7 skipping to change at page 10, line 43
The Prefix attribute MAY be used for route selection. The Prefix attribute MAY be used for route selection.
3.4.4. Aggregation and Prefix 3.4.4. Aggregation and Prefix
Routes with differing Prefix attribute MUST NOT be aggregated. Routes with differing Prefix attribute MUST NOT be aggregated.
Routes with the same value in the Prefix attribute MAY be aggregated Routes with the same value in the Prefix attribute MAY be aggregated
and the same Prefix attribute attached to the aggregated object. and the same Prefix attribute attached to the aggregated object.
3.4.5. Route Dissemination and Prefix 3.4.5. Route Dissemination and Prefix
The LS receiving this attribute should disseminate it to other peers, The LS receiving this attribute should disseminate to other peers,
both internal and external to the ITAD. both internal and external to the ITAD.
3.5. TrunkGroup Attribute 3.5. TrunkGroup Attribute
Mandatory: False. Mandatory: False.
Required Flags: Not well-known. Required Flags: Not well-known.
Potential Flags: None. Potential Flags: None.
TRIP Type Code: 20 (To be assigned by IANA) TRIP Type Code: 20 (To be assigned by IANA)
The TrunkGroup attribute is used to represent the list of trunkgroups The TrunkGroup attribute is used to represent the list of trunkgroups
on the gateway that the gateway can complete the calls to. It enables on the gateway used to complete calls. It enables providers to route
providers to route calls to destinations through preferred trunks. calls to destinations through preferred trunks. This attribute is
This attribute is relatively static. relatively static.
3.5.1. TrunkGroup Syntax 3.5.1. TrunkGroup Syntax
The TrunkGroup attribute is a variable length attribute that is The TrunkGroup attribute is a variable length attribute that is
composed of a sequence of trunkgroup length-value fields. It composed of a sequence of trunkgroup length-value fields. It
indicates that the gateway can complete the call through any indicates that the gateway can complete the call through any
trunkgroup (represented by the trunkgroup label) in the sequence. trunkgroup (represented by the trunkgroup label) in the sequence.
Each trunkgroup is a length-value field (shown in Figure 3 below). Each trunkgroup is a length-value field (shown in Figure 3 below).
The length field is a 1-octet unsigned numeric value. The value field The length field is a 1-octet unsigned numeric value. The value field
skipping to change at page 12, line 25 skipping to change at page 12, line 21
Routes with differing TrunkGroup attribute MUST NOT be aggregated. Routes with differing TrunkGroup attribute MUST NOT be aggregated.
Routes with the same value in the TrunkGroup attribute MAY be Routes with the same value in the TrunkGroup attribute MAY be
aggregated and the same TrunkGroup attribute attached to the aggregated and the same TrunkGroup attribute attached to the
aggregated object. aggregated object.
3.5.5. Route Dissemination and TrunkGroup 3.5.5. Route Dissemination and TrunkGroup
This attribute is not expected to change frequently. Hence, the LS This attribute is not expected to change frequently. Hence, the LS
receiving this attribute MAY disseminate it to other peers, internal receiving this attribute MAY disseminate it to other peers, internal
to ITAD. Routes MUST not be disseminated external to the ITAD, with to ITAD. Routes SHOULD not be disseminated external to the ITAD, with
TrunkGroup attribute. TrunkGroup attribute.
3.6. Carrier Attribute 3.6. Carrier Attribute
Mandatory: False. Mandatory: False.
Required Flags: Not well-known. Required Flags: Not well-known.
Potential Flags: None. Potential Flags: None.
TRIP Type Code: 19 (To be assigned by IANA) TRIP Type Code: 19 (To be assigned by IANA)
The Carrier attribute is used to represent the list of carriers that The Carrier attribute is used to represent the list of carriers that
the gateway can complete calls to. It enables providers to route the gateway uses to complete calls. It enables providers to route
calls to destinations through preferred carriers. This attribute is calls to destinations through preferred carriers. This attribute is
relatively static. relatively static.
3.6.1. Carrier Syntax 3.6.1. Carrier Syntax
The Carrier attribute is a variable length attribute that is composed The Carrier attribute is a variable length attribute that is composed
of a sequence of carrier values. It indicates that the route can of a sequence of carrier values. It indicates that the route can
complete the call to any of the carriers represented in the sequence complete the call to any of the carriers represented in the sequence
of carrier values. of carrier values.
Each carrier value has two ASCII fields, a 3-octet CountryCode, and a 4- A Carrier value is an 8-octet ASCII-encoded string obtained by
octet CarrierIdCode. The CountryCode field represents the country concatenation of a CarrierIdCode and a RegionCode ( defined below ).
that corresponds to the Carrier identified by CarrierIdCode. It is When the length of the Carrier value is less than 8 octets, it is
the same as the E.164 country code used to dial internal telephony padded with NULL bytes
destinations. The CarrierIdCode or CIC represents a unique code
assigned to the Carrier or Telephony service provider offering the The CarrierIdCode is the code assigned to a carrier by a regulatory
service by an administrative body operating in that region. body operating in that region. The RegionCode represents the region
where the CarrierIdCode is assigned. The RegionCode is a qualifier
that makes the Carrier value globally unique. Regions are currently
defined to map to countries. The RegionCode should use E.164 country
code used in dialing international telephony destinations. However,
regions can evolve in the future to encompass a larger area, beyond a
country. For example, if a regulatory body in the European Union that
assigns CarrierIds to carriers in the whole of Europe, a
corresponding RegionCode would be used.
The textual concatenation of CarrierId and RegionCode forms a
Carrier. This Carrier is then used as an attribute of the associated
destination.
When the scope of a CarrierIdCode is known to be unique apriori, the
RegionCode is superfluous and MAY be excluded from the Carrier value
when advertising in a TGREP UPDATE message. This is possible when the
carrier is operating within the same region where the CarrierIdCode
was assigned or if the carrier is operating in a controlled
environment of networks where CarrierId is privately defined to be
unique.
The presence of Carrier Attribute with the length field of the The presence of Carrier Attribute with the length field of the
attribute as 0 signifies that the TGREP GW can terminate ALL Carriers attribute as 0 signifies that the TGREP GW can terminate ALL Carriers
for the given Reachable route(s). for the given Reachable route(s).
0 1 2 3 5 0 1 2 7 0
0 1 2 3 4 5 6 7 8 9 0 .... 0 1 2 3 4 5 6 7 8 9 0 1 2 3 .... 0 1 2 3 4 5 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 .....0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 ..
+----------------------------------+------------------------------------+----- +-------------------------------------------------------------+---------------
| CountryCode | CarrierIdCode .... | .... | Carrier1 | Carrier2 ..
+----------------------------------+------------------------------------+----- +-------------------------------------------------------------+---------------
Figure 4: Carrier Syntax Figure 4: Carrier Syntax
3.6.2. Route Origination and Carrier 3.6.2. Route Origination and Carrier
Routes MAY be originated containing the Carrier attribute. Routes MAY be originated containing the Carrier attribute.
3.6.3. Route Selection and Carrier 3.6.3. Route Selection and Carrier
The Carrier attribute MAY be used for route selection. Certain The Carrier attribute MAY be used for route selection. Certain
carriers MAY be preferred over others based on provider policy. carriers MAY be preferred over others based on provider policy.
skipping to change at page 14, line 8 skipping to change at page 14, line 20
3.6.5. Route Dissemination and Carrier 3.6.5. Route Dissemination and Carrier
This attribute is not expected to change frequently. Hence, the LS This attribute is not expected to change frequently. Hence, the LS
receiving this attribute MAY disseminate it to other peers, both receiving this attribute MAY disseminate it to other peers, both
internal and external to the ITAD. internal and external to the ITAD.
3.7. TrunkGroup and Carrier Address Families 3.7. TrunkGroup and Carrier Address Families
When a set of GWs are to managed at the granularity of carriers or When a set of GWs are to managed at the granularity of carriers or
trunkgroups then it may be more appropriate for a GW can advertise trunkgroups then it may be more appropriate for a GW to advertise
routes using the Carrier address family or trunkgroup address family routes using the Carrier address family or trunkgroup address family
respectively. Also, in a TGREP association between the gateway and respectively. Also, in a TGREP association between the gateway and
the LS responsible for managing that gateway, there are some the LS responsible for managing that gateway, there are some
attributes that more naturally fit in as advertised properties of attributes that more naturally fit in as advertised properties of
trunkgroups or carriers rather than that of advertised prefixes, For trunkgroups or carriers rather than that of advertised prefixes; for
example: the AvailableCircuit information on a particular trunkgroup example, the AvailableCircuit information on a particular trunkgroup
or a particular carrier. To express this relationship, the existing or a particular carrier. To express this relationship, the existing
TRIP address families are inadequate. We need separate address TRIP address families are inadequate. We need separate address
families that can associate certain properties like AvailableCircuits families that can associate certain properties like AvailableCircuits
information to trunkgroups or carriers. information to trunkgroups or carriers.
The primary benefits of this model are as follows: The primary benefits of this model are as follows:
- It allows a service provider to route calls based strictly on the - It allows a service provider to route calls based strictly on the
trunkGroups or carriers. trunkGroups or carriers.
- it facilitates more accurate reporting of attributes of a dynamic - it facilitates more accurate reporting of attributes of a dynamic
skipping to change at page 15, line 19 skipping to change at page 15, line 38
The value in the Address field represents either the TrunkGroup or The value in the Address field represents either the TrunkGroup or
the Carrier address families and the syntax is as follows: the Carrier address families and the syntax is as follows:
For the TrunkGroup Address Family, the Address field is a variable For the TrunkGroup Address Family, the Address field is a variable
length alphanumeric field (trunkgroup label), where length is length alphanumeric field (trunkgroup label), where length is
determined by the length field of the route. The maximum value of the determined by the length field of the route. The maximum value of the
length field for this Address Family is 128 bytes. length field for this Address Family is 128 bytes.
For the Carrier Address Family, the length field represents the For the Carrier Address Family, the length field represents the
length of the Address field in bytes. The Address field is a fixed length of the Address field in bytes. The Address field is a fixed
length field representing Carrier value. It is encoded as a fixed length field representing Carrier value. A Carrier value is an 8-
length 4-octet value consisting of two fields : Country code and the octet ASCII-encoded string obtained by concatenation of a
CarrierId. CarrierIdCode and a RegionCode ( defined below ). When the length of
the Carrier value is less than 8 octets, it is padded with NULL bytes
The CarrierIdCode is the code assigned to a carrier by a regulatory
body operating in that region. The RegionCode represents the region
where the CarrierIdCode is assigned. The RegionCode is a qualifier
that makes the Carrier value globally unique. Regions are currently
defined to map to countries. The RegionCode should use E.164 country
code used in dialing international telephony destinations. However,
regions can evolve in the future to encompass a larger area, beyond a
country. For example, if a regulatory body in the European Union that
assigns CarrierIds to carriers in the whole of Europe, a
corresponding RegionCode would be used.
The textual concatenation of CarrierId and RegionCode forms a
Carrier. This is then used as a destination for routing purposes.
When the scope of a CarrierIdCode is known to be unique apriori, the
RegionCode is superfluous and MAY be excluded from the Carrier value
when advertising in a TGREP UPDATE message. This is possible when the
carrier is operating within the same region where the CarrierIdCode
was assigned or if the carrier is operating in a controlled
environment of networks where CarrierId is privately defined to be
unique.
If a gateway supports any of these address families, it should If a gateway supports any of these address families, it should
include that address family as one of the Route types supported in include that address family as one of the Route types supported in
the OPEN message capability negotiation phase. the OPEN message capability negotiation phase.
The following attributes are currently defined to be used with all The following attributes are currently defined to be used with all
the address families including the TrunkGroup and Carrier address the address families including the TrunkGroup and Carrier address
families. families.
- AvailableCircuits Attribute - AvailableCircuits Attribute
- TotalCircuitCapacity Attribute - TotalCircuitCapacity Attribute
- CallSuccess Attribute - CallSuccess Attribute
It is recommended that the above three attributes be used by the It is recommended that the above three attributes be used by the
gateway with the TrunkGroup or Carrier address families, if gateway with the TrunkGroup or Carrier address families, if possible.
possible. This will potentially offer a more efficient resource This will potentially offer a more efficient resource reporting
reporting framework, and a scalable model for gateway framework, and a scalable model for gateway provisioning.
provisioning.
However, when the gateway is not using TrunkGroup or Carrier However, when the gateway is not using TrunkGroup or Carrier address
address family, it MAY use the above attributes with the Decimal, family, it MAY use the above attributes with the Decimal,
PentaDecimal and E.164 address families. PentaDecimal and E.164 address families.
The Prefix, Carrier and TrunkGroup attributes MUST NOT be used The Prefix, Carrier and TrunkGroup attributes MUST NOT be used with
with their respective address families. their respective address families.
3.8. Other attribute considerations
3.8.1. Cost/Pricing attribute
In exploring attributes suitable for the GW-LS communications,
Pricing is another attribute that was considered. Though at first
glance, it seems like a useful piece of information to be advertised
by the gateway to express the price offered by carriers to different
destinations, in reality, the computation of pricing can get quite
complex. For example, the price offered by a provider can vary by
time of day, it can be based on an agreement between two service
providers interconnecting with each other, it could be based on one
price for the first 'n' minutes and a different price after that,
Least Cost routing choices and Grades of service offered by a carrier
can affect pricing. There could be other factors as well. Expressing
this complex interplay between different factors that determine
pricing is non-trivial to represent. It will be a subject of further
investigation to determine whether advertising pricing associated
with carriers in its simple form without any dependencies adds value
to be included as an attribute in the TGREP communications.
3.9. Gateway Operation 3.8. Gateway Operation
A gateway uses TRIP to advertise its reachability to its domain's A gateway uses TGREP to advertise its reachability to its domain's
Location Server(s) (LS, which are closely coupled with proxies). The Location Server(s) (LS, which are closely coupled with proxies). The
gateway operates in TRIP Send Only mode since it is only interested gateway operates in TGREP Send Only mode since it is only interested
in advertising its reachability, but is not interested in learning in advertising its reachability, but is not interested in learning
about the reachability of other gateways and other domains. Also, the about the reachability of other gateways and other domains. Also, the
gateway will not create its own call routing database. Therefore, the gateway will not create its own call routing database. In this
gateway does not need a complete implementation of TRIP. A section we describe the operation of TGREP on a gateway.
lightweight version of the protocol is sufficient. In this section we
describe the operation of TRIP on a gateway.
3.9.1. Session Establishment 3.8.1. Session Establishment
When opening a peering session with a TGREP Receiver, a TGREP gateway When opening a peering session with a TGREP Receiver, a TGREP gateway
follows exactly the same procedures as any other TRIP speaker. The follows exactly the same procedures as any other TRIP speaker. The
TGREP gateway sends an OPEN message which includes a Send Receive TGREP gateway sends an OPEN message which includes a Send Receive
Capability in the Optional Parameters. The Send Receive Capability is Capability in the Optional Parameters. The Send Receive Capability is
set by the gateway to Send Only. The OPEN message also contains the set by the gateway to Send Only. The OPEN message also contains the
address families supported by the gateway. The remainder of the peer address families supported by the gateway. The remainder of the peer
session establishment is identical to TRIP. session establishment is identical to TRIP.
3.9.2. UPDATE Messages 3.8.2. UPDATE Messages
Once the peer session has been established, the gateway sends UPDATE Once the peer session has been established, the gateway sends UPDATE
messages to the TRIP LS with the gateway's entire reachability. The messages to the TRIP LS with the gateway's entire reachability. The
Gateway also sends any attributes associated with the routes. Gateway also sends any attributes associated with the routes.
If the gateway's reachability changes at any point in time, the If the gateway's reachability changes at any point in time, the
gateway MUST generate UPDATE message(s) with the change. The gateway MUST generate UPDATE message(s) with the change. The
frequency of successive UPDATE messages MUST follow the same rules frequency of successive UPDATE messages MUST follow the same rules
specified for TRIP[4]. The TGREP gateway MUST support all mandatory specified for TRIP[4]. The TGREP gateway MUST support all mandatory
TRIP attributes. TRIP attributes.
If the gateway receives an UPDATE message from the TRIP LS, it MUST If the gateway receives an UPDATE message from the TRIP LS, it MUST
silently discard it as specified for TRIP[4]. No further action silently discard it as specified for TRIP[4]. No further action
should be taken. should be taken.
3.9.3. KEEPALIVE Messages 3.8.3. KEEPALIVE Messages
KEEPALIVE messages are periodically exchanged over the peering KEEPALIVE messages are periodically exchanged over the peering
session between the TGREP gateway and the TRIP LS as specified in session between the TGREP gateway and the TRIP LS as specified in
Section 4.4 of TRIP RFC[4]. Section 4.4 of TRIP RFC[4].
3.9.4. Error Handling and NOTIFICATION Messages 3.8.4. Error Handling and NOTIFICATION Messages
The same procedures used with TRIP, are used with TGREP for error The same procedures used with TRIP, are used with TGREP for error
handling and generating NOTIFICATION messages. The only difference is handling and generating NOTIFICATION messages. The only difference is
that a TGREP gateway will never generate a NOTIFICATION message in that a TGREP gateway will never generate a NOTIFICATION message in
response to an UPDATE message, irrespective of the contents of the response to an UPDATE message, irrespective of the contents of the
UPDATE message. Any UPDATE message is silently discarded. UPDATE message. Any UPDATE message is silently discarded.
3.9.5. TGREP Finite State Machine 3.8.5. TGREP Finite State Machine
When the TGREP finite state machine is in the Established state and When the TGREP finite state machine is in the Established state and
an UPDATE message is received, the UPDATE message is silently an UPDATE message is received, the UPDATE message is silently
discarded and the TGREP gateway remains in the Established state. discarded and the TGREP gateway remains in the Established state.
Other than that the TRIP finite state machine and the TGREP finite Other than that the TRIP finite state machine and the TGREP finite
state machine are identical. state machine are identical.
3.9.6. Call Routing Databases 3.8.6. Call Routing Databases
A TGREP gateway may maintain simultaneous sessions with more than one A TGREP gateway may maintain simultaneous sessions with more than one
TRIP LSs. A TGREP gateway maintains one call routing database per TRIP LSs. A TGREP gateway maintains one call routing database per
peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out, peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out,
and hence we will call them Adj-TRIB-GWs-Out. An Adj-TRIB-GW-Out and hence we will call them Adj-TRIB-GWs-Out. An Adj-TRIB-GW-Out
contains the gateway's reachability information advertised to its contains the gateway's reachability information advertised to its
peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is
outside the scope of this draft (possibly by manual configuration). outside the scope of this draft (possibly by manual configuration).
The TGREP gateway does not have databases equivalent to TRIP's Adj- The TGREP gateway does not have databases equivalent to TRIP's Adj-
TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn 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 routes from its peer TRIP LSs, and hence it does not run call route
selection. selection.
3.9.7. Multiple Address Families 3.8.7. Multiple Address Families
As mentioned above, TGREP supports various address families in order As mentioned above, TGREP supports various address families in order
to convey the reachibilty of telephony destinations. A TGREP session to convey the reachibilty of telephony destinations. A TGREP session
MUST NOT send UPDATEs of more than one of the following catagories MUST NOT send UPDATEs of more than one of the following catagories
(a) Prefix Address families (E164, Pentadecimal and decimal) (b) (a) Prefix Address families (E164, Pentadecimal and decimal) (b)
Trunkgroup address family (c) Carrier Address family for a given Trunkgroup address family (c) Carrier Address family for a given
established session. TGREP should specify it's choice address family established session. TGREP should specify it's choice address family
through the route-type capability in the OPEN message. And route-type through the route-type capability in the OPEN message. And route-type
specification in the OPEN message violating the above rule should be specification in the OPEN message violating the above rule should be
rejected with a NOTIFICATION message. rejected with a NOTIFICATION message.
3.9.8. Route Selection and Aggregation 3.8.8. Route Selection and Aggregation
TRIP's route selection and aggregation operations MUST NOT be TRIP's route selection and aggregation operations MUST NOT be
implemented by TGREP gateways. implemented by TGREP gateways.
3.10. LS/Proxy Behavior 3.9. LS/Proxy Behavior
As mentioned earlier, TGREP can be considered as a protocol As mentioned earlier, TGREP can be considered as a protocol
complimentary to TRIP in providing reachability information that can complimentary to TRIP in providing reachability information that can
then be further fed into the Location Server for propogation. The then be further fed into the Location Server. The architecture of an
architecture of an LS/Proxy system is as follows: There exists a TRIP LS/Proxy system is as follows: There exists a TRIP LS application
LS application that functions as a speaker in the I-TRIP/E-TRIP that functions as a speaker in the I-TRIP/E-TRIP network as
network as documented in the TRIP RFC [4]. Then, there is a signaling documented in the TRIP RFC [4]. Then, there is a signaling server
server fronting a set of gateways and receives routing information on fronting a set of gateways and receives routing information on one or
one or more TGREP sessions. This routing information from the more TGREP sessions. This routing information from the gateways is
gateways is received and processed by a TGREP receiver application. received and processed by a TGREP receiver application. Subsequently,
Subsequently, this routing information is presented as candidate this routing information is presented as candidate routes (possibly
routes (possibly as local routes) to the TRIP LS. The interface as local routes) to the TRIP LS. The interface between these two
between these two applications is entirely a local matter. However, applications is entirely a local matter. However, before importing
before importing these routes into the TRIP LS, certain operations these routes into the TRIP LS, certain operations may optionally be
may optionally be performed on these routes. The nature of these performed on these routes. The nature of these operations and the
operations and the accompanying motivation are described in the accompanying motivation are described in the subsections below. The
subsections below. The order in which the operations are listed order in which the operations are listed represents an implicit
represents an implicit logical sequence in which they are applied. logical sequence in which they are applied. The architecture for an
The architecture for an LS/Proxy entity is shown in Figure 7 below. LS/Proxy entity is shown in Figure 7 below.
+-------------------------------------------------------+ +-------------------------------------------------------+
| +-------------------------------+ | | +-------------------------------+ |
| | +-+ +-+ | | | | +-+ +-+ | |
| | |A| |C| | | +-----+ | | |A| |C| | | +-----+
| | |g| |o| | | TGREP | | | | |g| |o| | | TGREP | |
| +-------------+ | |g| |n| +-------------+ | | -- | GW | | +-------------+ | |g| |n| +-------------+ | | -- | GW |
| | | | |r| |s| | | | | -- +-----+ | | | | |r| |s| | | | | -- +-----+
| | TRIP | | |e| |o| | | | +-- | | TRIP | | |e| |o| | | | +--
| | LS <----------|g<--|l<--- TGREP |-++-| +-----+ | | LS <----------|g<--|l<--- TGREP |-++-| +-----+
skipping to change at page 20, line 43 skipping to change at page 20, line 43
+/----------------+ +/----------------+
| | | |
| | | |
| | | |
| LS | | LS |
| | | |
| | | |
| | | |
| | | |
| | | |
+\----------------+ +----------------+
\
\ +------------------------------------------------------+
\ | +-------------------------------+ |
\ | | +-+ +-+ | |
\ | | |A| |C| | | +-----+
\ | | |g| |o| | | TGREP | |
\ | +-------------+ | |g| |n| +-------------+ | | -- | GW |
+--------\---------------------------------------------+
\
| \ +-------------------------------+ |
| \ | +-+ +-+ | |
| \ | |A| |C| | | +-----+
| \ | |g| |o| | | TGREP | |
| +------------\+ | |g| |n| +-------------+ | | -- | GW |
| | | | |r| |s| | | | | -- +-----+ | | | | |r| |s| | | | | -- +-----+
| | TRIP | | |e| |o| | | | +-- | | TRIP | | |e| |o| | | | +--
| | LS <----------|g<--|l<--- TGREP |-++-| +-----+ | | LS <----------|g<--|l<--- TGREP |-++-| +-----+
| | | | |a| |i| | Session | | | | | | | | | |a| |i| | Session | | | | |
| | (I-TRIP/ | | |t| |d| | Mangement |-++-+-------| GW | | | (I-TRIP/ | | |t| |d| | Mangement |-++-+-------| GW |
| | E-TRIP) | | |i| |a| | | | | +-----+ | | E-TRIP) | | |i| |a| | | | | +-----+
| | | | |o| |t| | |-+ -+- | | | | |o| |t| | |-+ -+-
| +-------------+ | |n| |i| +-------------+ | | --- +-----+ | +-------------+ | |n| |i| +-------------+ | | --- +-----+
| | | | |o| | | -- | | | | | | |o| | | -- | |
| | | | |n| | | | GW | | | | | |n| | | | GW |
| | +-+ +-+ | | +-----+ | | +-+ +-+ | | +-----+
| | TGREP Receiver | | | | TGREP Receiver | |
| +-------------------------------+ | | +-------------------------------+ |
| | | |
| | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
LS/Proxy LS/Proxy
Figure 7: LS Architecture for TRIP-GW Figure 7: LS Architecture for TRIP-GW
3.10.1. Route consolidation 3.9.1. Route consolidation
The TGREP receiver may receive routing information from one or more The TGREP receiver may receive routing information from one or more
gateways. It is possible that multiple routes are available for the gateways. It is possible that multiple routes are available for the
same destination. These different alternative routes may be received same destination. These different alternative routes may be received
from the same gateway, or from multiple gateways. It is RECOMMENDED from the same gateway, or from multiple gateways. It is RECOMMENDED
that the set of gateway routes for each destination be consolidated, that the set of gateway routes for each destination be consolidated,
before presenting a candidate route, to the TRIP LS. The motivation before presenting a candidate route, to the TRIP LS. The motivation
for this operation should be to define a route that can maximally for this operation should be to define a route that can maximally
represent the collective routing capabilities of the set of gateways, represent the collective routing capabilities of the set of gateways,
managed by this TGREP receiver. Let us take an example scenario in managed by this TGREP receiver. Let us take an example scenario in
skipping to change at page 22, line 30 skipping to change at page 22, line 30
single Carrier AF route advertisement with prefix value {408, 650, single Carrier AF route advertisement with prefix value {408, 650,
919, 973}. 919, 973}.
In general, there is a potential for loss of gateway routing In general, there is a potential for loss of gateway routing
information, when TGREP routes from a set of gateways are not information, when TGREP routes from a set of gateways are not
consolidated, when a candidate route is presented to the TRIP LS. consolidated, when a candidate route is presented to the TRIP LS.
The specifics of applying the consolidation operation to different The specifics of applying the consolidation operation to different
attributes and routes from different address families, is left to the attributes and routes from different address families, is left to the
individual TGREP receiver implementations. individual TGREP receiver implementations.
3.10.2. Aggregation 3.9.2. Aggregation
The set of gateway routes, that are in a consolidated form or The set of gateway routes, that are in a consolidated form or
otherwise, may be aggregated before importing it to the LS instance otherwise, may be aggregated before importing it to the LS instance
that is responsible for I-TRIP/E-TRIP processing. This operation that is responsible for I-TRIP/E-TRIP processing. This operation
follows the standard aggregation procedures described in the TRIP RFC follows the standard aggregation procedures described in the TRIP RFC
[4], while adhering to the aggregation rules for each route [4], while adhering to the aggregation rules for each route
attribute. attribute.
4. IANA Considerations 3.9.3. Consolidation v/s Aggregation
To highlight the difference between the two operations discussed
above, "Consolidation" combines multiple routes for the same route
destination, whereas "Aggregation" combines routes for different
route destinations that qualify as candidates to be summarized
resulting in route information reduction.
To take an example, if there are multiple gateways offering routes to
an E.164 destination "408" but with possibly different attributes
(Eg: Carrier), the LS/Proxy can combine these to form one route for
"408" but representing the attribute information collectively. This
process is Consolidation
If, for example, the LS/Proxy receives routes for 4080, 4081, 4082,
... 4089 from amongst a set of gateways, it could aggregate these
different candidate routes to have a summarized route destination
"408" with each of the attributes computed using the Aggregation
procedures defined in the TRIP RFC.
4. Security Considerations
The Security considerations defined in the TRIP RFC [4] apply to
TGREP sessions between Gateways and TGREP Receivers
5. IANA Considerations
- The Attribute Type Codes for the new attributes: - The Attribute Type Codes for the new attributes:
AvailableCircuits, TotalCircuitCapacity, CallSuccess, Prefix, AvailableCircuits, TotalCircuitCapacity, CallSuccess, Prefix,
TrunkGroup and Carrier described in Sections 4.1, 4.2, 4.3, 4.4, TrunkGroup and Carrier described in Sections 3.1, 3.2, 3.3, 3.4,
4.5 and 4.6 above, respectively, are to be assigned by IANA. 3.5 and 3.6 above, respectively, are to be assigned by IANA.
- The Address Family Codes for the new address families: TrunkGroup - The Address Family Codes for the new address families: TrunkGroup
and Carrier described in Section 4.7, are to be assigned by IANA. and Carrier described in Section 3.7, are to be assigned by IANA.
5. Changes since draft-ietf-iptel-tgrep-00.txt Both TRIP[4] and TGREP share the same IANA registry for Capabilities,
Attributes, Address Families, and Application Protocols
- Added recommendation for AvailableCircuits and CallSuccess 6. Changes since draft-ietf-iptel-tgrep-01.txt
- Added a "Security Considerations" Section to the document
- Strengthened the text under "LS/Proxy Behavior" regarding
Consolidation and Aggregation with additional examples for better
clarity
- Removed the section "Other Attributes" including its subsection
on the "Pricing" attribute
- Modified the definition of Carrier in the "Carrier attribute" and
"TrunkGroup and Carrier Address Families" sections respectively
- Rectified the section number references in the "IANA
Considerations" Section
- Strengthened the text in the attribute sections regarding
dissemination of attributes received on TGREP
- Updated the "References" section
- Corrected typos, nits, grammatical errors, and language of the
text throughout the document based on feedback from the iptel
community
7. Changes since draft-ietf-iptel-tgrep-00.txt
- Added recommendations for AvailableCircuits and CallSuccess
attributes. attributes.
- Updated Carrier Attribute with ASCII syntax. - Updated Carrier Attribute with ASCII syntax.
- Removed thresholding scheme description. - Removed thresholding scheme description.
- Updated author addresses. - Updated author addresses.
6. Changes since draft-ietf-iptel-trip-gw-00.txt 8. Changes since draft-ietf-iptel-trip-gw-00.txt
- Changed title of the document to TGREP (Telephony Gateway - Changed title of the document to TGREP (Telephony Gateway
REgistration Protocol) REgistration Protocol)
- Changed name of protocol described in this document to TGREP - Changed name of protocol described in this document to TGREP
- Changed Abstract and Introduction sections to position TGREP as - Changed Abstract and Introduction sections to position TGREP as
an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP) an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP)
- Modified the section on LS/Proxy Behavior including the diagram - Modified the section on LS/Proxy Behavior including the diagram
- Added an additional example to the Route Consolidation section - Added an additional example to the Route Consolidation section
- Changed the format of Carrier (both as an attribute and as an AF) - Changed the format of Carrier (both as an attribute and as an AF)
to accomodate representation of Country codes in association with to accomodate representation of Country codes in association with
CICs. CICs.
- Updated text to allow Carrier attribute in TrunkGroup address - Updated text to allow Carrier attribute in TrunkGroup address
family and TrunkGroup attribute in Carrier address family. family and TrunkGroup attribute in Carrier address family.
7. Changes since -03 9. Changes since -03
- Removed Carrier-Trunkgroup attribute and address family and - Removed Carrier-Trunkgroup attribute and address family and
references to it. references to it.
- Added Terminology and Definitions section. - Added Terminology and Definitions section.
- Updated CallSuccess attribute. - Updated CallSuccess attribute.
- Added Prefix attribute. - Added Prefix attribute.
- Added Carrier attribute. - Added Carrier attribute.
- Added TrunkGroup attribute. - Added TrunkGroup attribute.
- Added TrunkGroup Address Family. - Added TrunkGroup Address Family.
- Added Carrier Address Family. - Added Carrier Address Family.
- Added some more references. - Added some more references.
8. Changes since -02 10. Changes since -02
- Removed the requirements section. - Removed the requirements section.
- Discussed the motivation for introducing Carrier information into - Discussed the motivation for introducing Carrier information into
TRIP. TRIP.
- Defined a new attribute for the E.164 address family. - Defined a new attribute for the E.164 address family.
- Defined a new address family for CarrierCode-TrunkGroup - Defined a new address family for CarrierCode-TrunkGroup
combination . combination .
- Defined new attributes to advertise dynamic gateway - Defined new attributes to advertise dynamic gateway
characteristics like resource availability, and call success characteristics like resource availability, and call success
rate. rate.
- Added as section to validate the TGREP solution against the - Added as section to validate the TGREP solution against the
requirements in [7]. requirements in [7].
9. Changes since -01 11. Changes since -01
- Added requirements. - Added requirements.
- Added more formal analysis of REGISTER and added analysis of SLP. - Added more formal analysis of REGISTER and added analysis of SLP.
- Removed circuit capacity attribute. - Removed circuit capacity attribute.
10. Changes since -00 12. Changes since -00
- Added text to stress the value of this proposal for managing a - Added text to stress the value of this proposal for managing a
gateway cluster. gateway cluster.
- Added attributes for circuit capacity and DSP capacity. - Added attributes for circuit capacity and DSP capacity.
- Added section on LS operation, discussing aggregation issue. - Added section on LS operation, discussing aggregation issue.
Authors' Addresses Authors' Addresses
Manjunath Bangalore Manjunath Bangalore
Cisco Systems Cisco Systems
skipping to change at page 25, line 38 skipping to change at page 26, line 38
We wish to thank David Oran, Anirudh Sahoo, Kevin McDermott, Jon We wish to thank David Oran, Anirudh Sahoo, Kevin McDermott, Jon
Peterson, Li Li and Bob Penfield for their insightful comments and Peterson, Li Li and Bob Penfield for their insightful comments and
suggestions. suggestions.
References References
[1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement [1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet session initiation protocol," Request for Comments 3261, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service [3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service
location protocol, version 2," Request for Comments 2608, Internet location protocol, version 2," Request for Comments 2608, Internet
Engineering Task Force, June 1999. Engineering Task Force, June 1999.
[4] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over [4] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over
IP (TRIP)," Request for Comments 3219, Internet Engineering Task IP (TRIP)," Request for Comments 3219, Internet Engineering Task
Force, January 2002. Force, January 2002.
[5] J. Rosenberg and H. Schulzrinne, "A framework for telephony [5] J. Rosenberg and H. Schulzrinne, "A framework for telephony
routing over IP," Request for Comments 2871, Internet Engineering routing over IP," Request for Comments 2871, Internet Engineering
Task Force, June 2000. Task Force, June 2000.
[6] International Telecommunication Union, "Packet based multimedia [6] J. Rosenberg, "Requirements for Gateway Registration," Internet
communication systems," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998.
[7] J. Rosenberg, "Requirements for Gateway Registration," Internet
Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. Draft, Internet Engineering Task Force, Nov. 2001. Work in progress.
[8] ITU-T List of ITU Carrier Codes (published periodically in the [7] ITU-T List of ITU Carrier Codes (published periodically in the
ITU-T Operational Bulletin). ITU-T Operational Bulletin).
[9] J. Peterson, "An Architecture for Gateway Registration Based on [8] J. Peterson, "An Architecture for Gateway Registration Based on
Trunk Groups," Internet Draft, Internet Engineering Task Force, Feb. Trunk Groups," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress. 2002. Work in progress.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/