draft-ietf-iptel-tgrep-09.txt   rfc5140.txt 
IPTEL Working Group Manjunath Bangalore, Cisco Systems Network Working Group M. Bangalore
Internet Draft Rajneesh Kumar, Cisco Systems Request for Comments: 5140 R. Kumar
draft-ietf-iptel-tgrep-09.txt Hussein Salama, Citex Software Category: Standards Track J. Rosenberg
September 2007 Jonathan Rosenberg, Cisco Systems Cisco
Expiration Date: March 2008 Dhaval Shah, Moowee Inc. H. Salama
Citex Software
D.N. Shah
Moowee Inc.
A Telephony Gateway REgistration Protocol (TGREP) A Telephony Gateway REgistration Protocol (TGREP)
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007). 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 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 [12]. The registration mechanism can also gateways and soft switches. The registration mechanism can also be
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 Telephony Routing over IP information can then be passed on to a Telephony Routing over IP
(TRIP) Location Server, which in turn can propagate that routing (TRIP) Location Server, which in turn can propagate that routing
information within and between Internet telephony administrative information within and between Internet Telephony Administrative
domains (ITAD). TGREP shares a lot of similarities with the TRIP Domains (ITADs). TGREP shares a lot of similarities with the TRIP
Protocol. It has similar procedures and Finite State Machine for protocol. It has similar procedures and finite state machine for
session establishment. It also shares the same format for messages session establishment. It also shares the same format for messages
and a subset of attributes with TRIP. and a subset of attributes with TRIP.
Table of Contents Table of Contents
1 Terminology and Definitions .............................. 4 1. Introduction ....................................................3
2 Introduction ............................................. 4 2. Terminology and Definitions .....................................5
3 TGREP: Overview of operation ............................. 6 3. TGREP: Overview of Operation ....................................6
4 TGREP Attributes ......................................... 8 4. TGREP Attributes ................................................7
4.1 TotalCircuitCapacity Attribute ........................... 9 4.1. TotalCircuitCapacity Attribute .............................8
4.2 AvailableCircuits Attribute .............................. 10 4.2. AvailableCircuits Attribute ................................9
4.3 CallSuccess Attribute .................................... 11 4.3. CallSuccess Attribute .....................................10
4.4 Prefix Attributes ........................................ 13 4.4. Prefix Attributes .........................................12
4.5 TrunkGroup Attribute ..................................... 14 4.5. TrunkGroup Attribute ......................................13
4.6 Carrier Attribute ........................................ 16 4.6. Carrier Attribute .........................................15
5 TrunkGroup and Carrier Address Families .................. 17 5. TrunkGroup and Carrier Address Families ........................16
5.1 Address Family Syntax .................................... 18 5.1. Address Family Syntax .....................................17
6 Gateway Operation ........................................ 20 6. Gateway Operation ..............................................18
6.1 Session Establishment .................................... 20 6.1. Session Establishment .....................................18
6.2 UPDATE Messages .......................................... 20 6.2. UPDATE Messages ...........................................19
6.3 KEEPALIVE Messages ....................................... 20 6.3. KEEPALIVE Messages ........................................19
6.4 Error Handling and NOTIFICATION Messages ................. 21 6.4. Error Handling and NOTIFICATION Messages ..................19
6.5 TGREP Finite State Machine ............................... 21 6.5. TGREP Finite State Machine ................................19
6.6 Call Routing Databases ................................... 21 6.6. Call Routing Databases ....................................19
6.7 Multiple Address Families ................................ 21 6.7. Multiple Address Families .................................20
6.8 Route Selection and Aggregation .......................... 22 6.8. Route Selection and Aggregation ...........................20
7 LS/Proxy Behavior ........................................ 22 7. LS/Proxy Behavior ..............................................20
7.1 Route consolidation ...................................... 24 7.1. Route Consolidation .......................................22
7.2 Aggregation .............................................. 25 7.2. Aggregation ...............................................23
7.3 Consolidation v/s Aggregation ............................ 25 7.3. Consolidation versus Aggregation ..........................23
8 Security Considerations .................................. 25 8. Security Considerations ........................................23
9 IANA Considerations ...................................... 26 9. IANA Considerations ............................................24
9.1 Attribute Codes .......................................... 26 9.1. Attribute Codes ...........................................24
9.2 Address Family Codes ..................................... 27 9.2. Address Family Codes ......................................24
10 Change history ........................................... 27 10. Acknowledgments ...............................................25
10.1 Changes since draft-ietf-iptel-tgrep-03.txt .............. 27 11. References ....................................................25
10.2 Changes since draft-ietf-iptel-tgrep-02.txt .............. 27 11.1. Normative References .....................................25
10.3 Changes since draft-ietf-iptel-tgrep-01.txt .............. 28 11.2. Informative References ...................................26
10.4 Changes since draft-ietf-iptel-tgrep-00.txt .............. 28
10.5 Changes since draft-ietf-iptel-trip-gw-00.txt ............ 28
10.6 Changes since -03 ........................................ 29
10.7 Changes since -02 ........................................ 29
10.8 Changes since -01 ........................................ 29
10.9 Changes since -00 ........................................ 29
11 Acknowledgments .......................................... 30
12 References ............................................... 30
12.1 Normative References ..................................... 30
12.2 Informative References ................................... 30
Authors' Addresses ....................................... 31
Intellectual Property Statement .......................... 32
Copyright Statement ...................................... 32
Acknowledgment ........................................... 33
1. 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.
TrunkGroup: 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 company offering telephone and data communications between
points (end-users and/or exchanges).
2. Introduction 1. Introduction
It is assumed that reader of this is familiar with TRIP [2,10]. In It is assumed that the reader of this document is familiar with TRIP
typical VoIP networks, Internet Telephony Administrative Domains [2, 12]. In typical Voice over IP (VoIP) networks, Internet
(ITADs) will deploy numerous gateways for the purposes of Telephony Administrative Domains (ITADs) will deploy numerous
geographical diversity, capacity, and redundancy. When a call arrives gateways for the purposes of geographical diversity, capacity, and
at the domain, it must be routed to one of those gateways. redundancy. When a call arrives at the domain, it must be routed to
Frequently, an ITAD will break their network into geographic Points one of those gateways. Frequently, an ITAD will break its network
of Presence (POP), with each POP containing some number of gateways, into geographic Points of Presence (POPs), with each POP containing
and a proxy server element that fronts those gateways. The Proxy some number of gateways, and a proxy server element that fronts those
element is a SIP Proxy [9] or H.323 Gatekeeper. The proxy server is gateways. The proxy element is a SIP proxy [11] or H.323 gatekeeper.
responsible for managing the access to the POP, and also for The proxy server is responsible for managing the access to the POP,
determining which of the gateways will receive any given call that and also for determining which of the gateways will receive any given
arrives at the POP. In conjunction with the proxy server that routes call that arrives at the POP. In conjunction with the proxy server
the call signaling, there are two components, the "Ingress LS" that routes the call signaling, there are two components, the
(a.k.a. "TGREP Receiver" and the "Egress LS". The "TGREP Receiver" "Ingress LS" (aka "TGREP receiver") and the "Egress LS". The TGREP
component maintains TGREP peering relationship with one or more receiver component maintains TGREP peering relationship with one or
gateways. The routing information received from the gateways are more gateways. The routing information received from the gateways is
further injected into the Egress LS, which in turn disseminates into further injected into the Egress LS, which in turn disseminates into
the rest of the network on TRIP. For convenience, gateway and GW are the rest of the network on TRIP. For convenience, gateway and GW are
used interchangably. used interchangeably.
This configuration is depicted graphically in Figure 1. This configuration is depicted graphically in Figure 1.
Signalling TGREP Signaling TGREP
-------------> <---------------- -------------> <----------------
+---------+ +---------+
| | | |
| GW | | GW |
> +---------+ > +---------+
// //
// //
SIP // +---------+ SIP // +---------+
<----> // | | <----> // | |
skipping to change at page 5, line 49 skipping to change at page 4, line 40
| | --> | | -->
+-------------------------+ +-------------------------+
TRIP +---------+ TRIP +---------+
<----> | | <----> | |
| 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 to a particular PSTN destination. For the proxy to success statistics to a particular Public Switched Telephone Network
do this adequately, it needs to have access to this information in (PSTN) destination (see [14]). For the proxy to do this adequately,
real-time, as it changes. This means there must be some kind of it needs to have access to this information in real-time, as it
communications between the proxy and the gateways to convey this changes. This means there must be some kind of communications
information. between the proxy and the gateways to convey this information.
The TRIP protocol [2] is defined for carrying telephony routing The TRIP protocol [2] is defined for carrying telephony routing
information between providers, for the purposes of getting a call information between providers, for the purposes of getting a call
routed to the right provider for termination to the PSTN. However, routed to the right provider for termination to the PSTN. However,
there is no mechanism defined in TRIP that defines how routes get there is no mechanism defined in TRIP that defines how routes get
injected into the TRIP protocol from within the network. Nor does it injected into the TRIP protocol from within the network. Nor does it
define mechanisms which would allow the provider to select the define mechanisms that would allow the provider to select the
specific gateway for terminating a call when it arrives. Those gaps specific gateway for terminating a call when it arrives. Those gaps
are filled by TGREP. are filled by TGREP.
TGREP allows PSTN gateways or softswitches to inform a signaling TGREP allows PSTN gateways or softswitches to inform a signaling
server, such as a SIP proxy server or H.323 gatekeeper, of routes it server, such as a SIP proxy server or H.323 gatekeeper, of routes it
has to the PSTN. These advertisements include fairly dynamic has to the PSTN. These advertisements include fairly dynamic
information, such as the remaining capacity in a particular trunk, information, such as the remaining capacity in a particular trunk,
which is essential for selecting the right gateway. which is essential for selecting the right gateway.
TGREP is identical in syntax and overall operation to TRIP. However, TGREP is identical in syntax and overall operation to TRIP. However,
it differs in the route processing rules followed by the TGREP it differs in the route processing rules followed by the TGREP
receiver, allowing for a route processing function called receiver, allowing for a route processing function called
"Consolidation". Consolidation combines multiple routes for the same "consolidation". Consolidation combines multiple routes for the same
route destination with different attributes to a single route to route destination with different attributes to a single route to
prevent loss of routing information. TGREP also defines a set of new prevent loss of routing information. TGREP also defines a set of new
attributes, usable by TGREP or TRIP. Finally, TGREP only utilizes a attributes, usable by TGREP or TRIP. Finally, TGREP only utilizes a
subset of overall TRIP capabilities. Specifically, certain subset of overall TRIP capabilities. Specifically, certain
attributes are not utilized (as described below), and the TGREP attributes are not utilized (as described below), and the TGREP
entities (the sender and receiver) operate in an asymmetric entities (the sender and receiver) operate in an asymmetric
relationship, whereas TRIP allows symmetric and asymmetric. relationship, whereas TRIP allows symmetric and asymmetric.
As a general rule, because of lot of similarities between TRIP and As a general rule, because of a 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 [2]. It is suggested that the reader be formats defined in TRIP [2]. 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. TGREP: Overview of operation 2. Terminology and Definitions
TGREP is a route registration protocol for telephony destinations on The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
a gateway. These telephony destinations could be prefixes, trunk "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
groups or Carriers. The TGREP sender resides on the GW and gathers document are to be interpreted as described in RFC 2119 [1].
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,
hands over the reachability information to a TRIP Location Server.
The routing proxy also uses the information to select the gateway for
incoming calls.
"Consolidation" combines multiple routes for the same route Some other useful definitions are:
destination, whereas "Aggregation" combines routes for different
route destinations that qualify as candidate routes 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, Circuit: A circuit is a discrete (specific) path between two or more
... 4089 from amongst a set of gateways, it could aggregate these points along which signals can be carried. In this context, a
different candidate routes to have a summarized route destination circuit is a physical path, consisting of one or more wires and
"408" with each of the attributes computed using the Aggregation possibly intermediate switching points.
procedures defined in the TRIP.
The TGREP Sender establishes a session to the TGREP Receiver using a 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.
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 procedure similar to session establishment in TRIP. After the
session establishment, the TGREP Sender sends the reachability session establishment, the TGREP sender sends the reachability
information in the UPDATE messages. The UPDATE messages have the same information in the UPDATE messages. The UPDATE messages have the
format as in TRIP. However, certain TRIP attributes are not relevant same format as in TRIP. However, certain TRIP attributes are not
in TGREP; a TGREP Receiver MAY ignore them if they are present in a relevant in TGREP; a TGREP receiver MAY ignore them if they are
TGREP message. The following TRIP attributes do not apply to TGREP: present in a TGREP message. The following TRIP attributes do not
apply to TGREP:
1. AdvertisementPath 1. AdvertisementPath
2. RoutedPath 2. RoutedPath
3. AtomicAggregate 3. AtomicAggregate
4. LocalPreference 4. LocalPreference
5. MultiExitDisc 5. MultiExitDisc
6. ITADTopology 6. ITADTopology
7. ConvertedRoute 7. ConvertedRoute
In addition, TGREP defines the following new attributes in this In addition, TGREP defines the following new attributes in this
document that can be carried in a TGREP UPDATE message. document that can be carried in a TGREP UPDATE message.
- TotalCircuitCapacity: This attribute identifies the total number - TotalCircuitCapacity: This attribute identifies the total number
of PSTN circuits that are available on a route to complete calls. of PSTN circuits that are available on a route to complete
calls.
- AvailableCircuits: This attribute identifies the number of PSTN - AvailableCircuits: This attribute identifies the number of PSTN
circuits that are currently available on a route to complete circuits that are currently available on a route to complete
calls. calls.
- CallSuccess: This attribute represents information about the - CallSuccess: This attribute represents information about the
number of normally terminated calls out of a total number of number of normally terminated calls out of a total number of
attempted calls. attempted calls.
- Prefix (E164): This attribute is used to represent the list of - Prefix (E164): This attribute is used to represent the list of
E164 prefixes that the respective route can complete calls to. E164 prefixes to which the respective route can complete calls.
- Prefix (Decimal Routing Number): This attribute is used to - Prefix (Decimal Routing Number): This attribute is used to
represent the list of Decimal prefixes that the respective route represent the list of Decimal prefixes to which the respective
can complete calls to. route can complete calls.
- Prefix (Hexadecimal Routing Number): This attribute is used to - Prefix (Hexadecimal Routing Number): This attribute is used to
represent the list of Hexadecimal prefixes that the respective represent the list of Hexadecimal prefixes to which the
route can complete calls to. respective route can complete calls.
- TrunkGroup: This attribute enables providers to route calls to - TrunkGroup: This attribute enables providers to route calls to
destinations through preferred trunks. destinations through preferred trunks.
- Carrier: This attribute enables providers to route calls to - Carrier: This attribute enables providers to route calls to
destinations through preferred carriers. destinations through preferred carriers.
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. The new attributes and Address families families used in TGREP. The new attributes and address families
introduced are also applicable for general usage in TRIP except introduced are also applicable for general usage in TRIP except where
where noted (AvailableCircuits attribute for example) noted (AvailableCircuits attribute, for example).
4. TGREP Attributes 4. TGREP Attributes
Due to its usage within a service provider network, TGREP makes use Due to its usage within a service provider network, TGREP makes use
of a subset of the attributes defined for TRIP, in addition to of a subset of the attributes defined for TRIP, in addition to
defining several new ones. In particular, the following attributes defining several new ones. In particular, the following attributes
from TRIP are applicable to TGREP: from TRIP are applicable to TGREP:
1. WithdrawnRoutes 2. ReachableRoutes 3. NexthopServer 4. Prefix 5. 1. WithdrawnRoutes
Communities 2. ReachableRoutes
3. NexthopServer
4. Prefix
5. Communities
TGREP also defines several new attributes, described in this section. TGREP also defines several new attributes, described in this section.
These are TotalCircuitCapacity, AvailableCircuits, CallSuccess, These are TotalCircuitCapacity, AvailableCircuits, CallSuccess,
TrunkGroup and Carrier. As mentioned above, these new attributes are TrunkGroup, and Carrier. As mentioned above, these new attributes
usable by TRIP unless noted otherwise. are usable by TRIP unless noted otherwise.
A TGREP UPDATE supports the following attributes: A TGREP UPDATE supports the following attributes:
1. TotalCircuitCapacity 1. TotalCircuitCapacity
2. AvailableCircuits 2. AvailableCircuits
3. CallSuccess 3. CallSuccess
4. Prefix (E.164, Pentadecimal routing number, Decimal routing 4. Prefix (E.164, Pentadecimal routing number, Decimal routing
number) number)
5. TrunkGroup 5. TrunkGroup
6. Carrier 6. Carrier
4.1. TotalCircuitCapacity Attribute 4.1. TotalCircuitCapacity Attribute
skipping to change at page 9, line 12 skipping to change at page 8, line 22
5. TrunkGroup 5. TrunkGroup
6. Carrier 6. Carrier
4.1. TotalCircuitCapacity Attribute 4.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. TRIP Type Code: 13.
The TotalCircuitCapacity identifies the total number of PSTN circuits The TotalCircuitCapacity attribute identifies the total number of
that are available on a route to complete calls. It is used in PSTN circuits that are available on a route to complete calls. It is
conjunction with the AvailableCircuits attribute in gateway selection used in conjunction with the AvailableCircuits attribute in gateway
by the LS. The total number of calls sent to the specified route on selection by the LS. The total number of calls sent to the specified
the gateway cannot exceed this total circuit capacity under steady route on the gateway cannot exceed this total circuit capacity under
state conditions. steady state conditions.
The TotalCircuitCapacity attribute is used to reflect the The TotalCircuitCapacity attribute is used to reflect the
administratively provisioned capacity as opposed to the availability administratively provisioned capacity as opposed to the availability
at a given point in time as provided by the AvailableCircuits at a given point in time as provided by the AvailableCircuits
attribute. Because of its relatively static nature, this attribute attribute. Because of its relatively static nature, this attribute
MAY be propagated beyond the LS that receives it. MAY be propagated beyond the LS that receives it.
TotalCircuitCapacity represents the total number of possible calls at TotalCircuitCapacity represents the total number of possible calls at
any instant. This is not expected to change frequently. This can any instant. This is not expected to change frequently. This can
change, for instance, when certain telephony trunks on the gateway change, for instance, when certain telephony trunks on the gateway
are taken out of service for maintenance purposes. are taken out of service for maintenance purposes.
4.1.1. TotalCircuitCapacity Syntax 4.1.1. TotalCircuitCapacity Syntax
The TotalCircuitCapacity attribute is a 4-octet unsigned integer. It The TotalCircuitCapacity attribute is a 4-octet unsigned integer. It
represents the total number of circuits available for terminating represents the total number of circuits available for terminating
calls through this advertised route. This attribute represents a calls through this advertised route. This attribute represents a
potentially achievable upper bound on the number of calls which can potentially achievable upper bound on the number of calls that can be
be terminated on this route in total. terminated on this route in total.
4.1.2. Route Origination and TotalCircuitCapacity 4.1.2. Route Origination and TotalCircuitCapacity
Routes MAY be originated containing the TotalCircuitCapacity Routes MAY be originated containing the TotalCircuitCapacity
attribute. attribute.
4.1.3. Route Selection and TotalCircuitCapacity 4.1.3. Route Selection and TotalCircuitCapacity
The TotalCircuitCapacity attribute MAY be used for route selection. The TotalCircuitCapacity attribute MAY be used for route selection.
Since one of its primary applications is load balancing, an LS will Since one of its primary applications is load balancing, an LS will
wish to choose a potentially different route (amongst a set of routes 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 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 modeled as re-running the decision process on the arrival of each
call. The aggregation and dissemination rules for routes with this call. The aggregation and dissemination rules for routes with this
attribute ensure that re-running this selection process never results attribute ensure that re-running this selection process never results
in propagation of a new route to other peers. in propagation of a new route to other peers.
4.1.4. Aggregation and TotalCircuitCapacity 4.1.4. Aggregation and TotalCircuitCapacity
An LS MAY aggregate routes to the same prefix which contain a An LS MAY aggregate routes to the same prefix that contains a
TotalCircuitCapacity attribute. It SHOULD add the values of the TotalCircuitCapacity attribute. It SHOULD add the values of the
individual routes to determine the value for the aggregated route in individual routes to determine the value for the aggregated route in
the same ITAD. the same ITAD.
4.1.5. Route Dissemination and TotalCircuitCapacity 4.1.5. Route Dissemination and TotalCircuitCapacity
Since this attribute reflects the static capacity of the gateway's Since this attribute reflects the static capacity of the gateway's
circuit resources, it is not expected to change frequently. Hence the circuit resources, it is not expected to change frequently. Hence,
LS receiving this attribute MAY disseminate it to other peers, both the LS receiving this attribute MAY disseminate it to other peers,
internal and external to the ITAD. both internal and external to the ITAD.
4.2. AvailableCircuits Attribute 4.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. TRIP Type Code: 14.
The AvailableCircuits identifies the number of PSTN circuits that are The AvailableCircuits attribute identifies the number of PSTN
currently available on a route to complete calls. The number of circuits that are currently available on a route to complete calls.
additional calls sent to that gateway for that route cannot exceed The number of additional calls sent to that gateway for that route
the circuit capacity. If it does, the signaling protocol will likely cannot exceed the circuit capacity. If it does, the signaling
generate errors, and calls will be rejected. protocol will likely generate errors, and calls will be rejected.
The AvailableCircuits attribute is used ONLY between a gateway and The AvailableCircuits attribute is used ONLY between a gateway and
its peer LS responsible for managing that gateway. If it is received its peer LS responsible for managing that gateway. If it is received
in a route, it is not propagated. in a route, it is not propagated.
4.2.1. AvailableCircuits Syntax 4.2.1. AvailableCircuits Syntax
The AvailableCircuits attribute is a 4-octet unsigned integer. It The AvailableCircuits attribute is a 4-octet unsigned integer. It
represents the number of circuits remaining for terminating calls to represents the number of circuits remaining for terminating calls to
this route. this route.
skipping to change at page 11, line 19 skipping to change at page 10, line 19
updates MAY be sent as it changes. However, it is RECOMMENDED that updates MAY be sent as it changes. However, it is RECOMMENDED that
measures be taken to help reduce the messaging load from route measures be taken to help reduce the messaging load from route
origination. It is further RECOMMENDED that a sufficiently large origination. It is further RECOMMENDED that a sufficiently large
window of time be used to provide a useful aggregated statistic. window of time be used to provide a useful aggregated statistic.
4.2.3. Route Selection and AvailableCircuits 4.2.3. Route Selection and AvailableCircuits
The AvailableCircuits attribute MAY be used for route selection. The AvailableCircuits attribute MAY be used for route selection.
Since one of its primary applications is load balancing, an LS will Since one of its primary applications is load balancing, an LS will
wish to choose a potentially different route (amongst a set of routes 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 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 re-running the decision process on the arrival of each call. The
aggregation and dissemination rules for routes with this attribute aggregation and dissemination rules for routes with this attribute
ensure that re-running this selection process never results in ensure that re-running this selection process never results in
propagation of a new route to other peers. propagation of a new route to other peers.
4.2.4. Aggregation and AvailableCircuits 4.2.4. Aggregation and AvailableCircuits
Not applicable Not applicable.
4.2.5. Route Dissemination and AvailableCircuits 4.2.5. Route Dissemination and AvailableCircuits
Routes MUST NOT be disseminated with the AvailableCircuits attribute. Routes MUST NOT be disseminated with the AvailableCircuits attribute.
The attribute is meant to reflect capacity at the originating gateway The attribute is meant to reflect capacity at the originating gateway
only. Its highly dynamic nature makes it inappropriate to disseminate only. Its highly dynamic nature makes it inappropriate to
in most cases. disseminate in most cases.
4.3. CallSuccess Attribute 4.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. TRIP Type Code: 15.
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 is not 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 due to the reaches the Alerting stage but does not get connected due to the
unavailability of the called party, or the called party being busy, unavailability of the called party, or the called party being busy,
is conventionally considered a successful call. On the other hand, a is conventionally considered a successful call. On the other hand, a
call that gets disconnected because of a Circuit or Resource being call that gets disconnected because of a circuit or resource being
unavailable is conventionally considered a failed call. The exact unavailable is conventionally considered a failed call. The exact
mapping of disconnect causes to CallSuccess is at the discretion of mapping of disconnect causes to CallSuccess is at the 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 to use that information in the gateway selection process to enhance
probability of successful call termination. the 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.
4.3.1. CallSuccess Syntax 4.3.1. CallSuccess Syntax
The CallSuccess attribute is comprised of two component fields - each The CallSuccess attribute is composed of two component fields -- each
represented as an unsigned 4-octet unsigned integer. The first represented as a 4-octet unsigned integer. The first component field
component field represents the total number of calls terminated represents the total number of calls terminated successfully for the
successfully for the advertised destination on a given address family advertised destination on a given address family over a given window
over a given window of time. The second component field represents of time. The second component field represents the total number of
the total number of attempted calls for the advertised destination attempted calls for the advertised destination within the same window
within the same window of time. of time.
When the value for the total number of attempted calls wraps around, 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 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 it aligned with the other component over a given window of time. The
TGREP receiver using this information should obtain this information TGREP receiver using this information should obtain this information
frequently enough to prevent loss of significance. frequently enough to prevent loss of significance.
4.3.2. Route Origination and CallSuccess 4.3.2. Route Origination and CallSuccess
Routes MAY be originated containing the CallSuccess attribute. This Routes MAY be originated containing the CallSuccess attribute. This
skipping to change at page 13, line 15 skipping to change at page 12, line 7
4.3.3. Route Selection and CallSuccess 4.3.3. Route Selection and CallSuccess
The CallSuccess attribute MAY be used for route selection. This The CallSuccess attribute MAY be used for route selection. This
attribute represents a measure of success of terminating calls to the attribute represents a measure of success of terminating calls to the
advertised destination(s). This information MAY be used to select advertised destination(s). This information MAY be used to select
from amongst a set of alternative routes to increase the probability from amongst a set of alternative routes to increase the probability
of successful call termination. of successful call termination.
4.3.4. Aggregation and CallSuccess 4.3.4. Aggregation and CallSuccess
Not applicable Not applicable.
4.3.5. Route Dissemination and CallSuccess 4.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. disseminate.
4.4. Prefix Attributes 4.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 routing TRIP Type Codes: 16 for E164 Prefix, 17 for Pentadecimal Routing
number prefix and 18 for Decimal routing number prefix. Number Prefix, and 18 for Decimal Routing Number Prefix.
The Prefix attribute is used to represent the list of prefixes that The Prefix attribute is used to represent the list of prefixes to
the respective route can complete calls to. This attribute is which the respective route can complete calls. This attribute is
intended to be used with the Carrier or Trunkgroup address family intended to be used with the Carrier or TrunkGroup address family
(discussed in Section 3.7). (discussed in Section 5).
Though it is possible that all prefix ranges may be reachable through Though it is possible that all prefix ranges may be reachable through
a given Carrier, administrative issues could make certain ranges a given carrier, administrative issues could make certain ranges
preferable to others. preferable to others.
4.4.1. Prefix Attribute Syntax 4.4.1. Prefix Attribute Syntax
The Prefix attribute could be E.164, Decimal or Pentadecimal (refer The Prefix attribute could be E.164, Decimal, or Pentadecimal (refer
to TRIP [2]), each of them having it's own type code. The Prefix 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 attribute is encoded as a sequence of prefix values in the attribute
value field. The prefixes are listed sequentially with no padding as Value field. The prefixes are listed sequentially with no padding as
shown in Figure 2. Each prefix includes a 2-octet length field that 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 represents the length of the Address field in octets. The order of
prefixes in the attribute is not significant. prefixes in the attribute is not significant.
The presence of Prefix Attribute with the length field of the The presence of the Prefix Attribute with the Length field of the
attribute as 0 signifies that the TGREP GW can terminate ALL prefixes attribute as 0 signifies that the TGREP GW can terminate ALL prefixes
of that prefix type (E.164, Decimal or Pentadecimal) for the given of that prefix type (E.164, Decimal, or Pentadecimal) for the given
Reachable route(s). This is not equivalent to excluding the Prefix Reachable route(s). This is not equivalent to excluding the Prefix
attribute in the TGREP update. attribute in the TGREP update.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 . . . < 2 octets > < Length1 octets > < 2 octets > < Length2 octets >
+-------------------------------+-----------+------------------------
| Length | Prefix1...| Length |Prefix2 +------------+--------------//--+------------+--------------//--+-
+-------------------------------+-----------+------------------------ | Length1 | Prefix1 | Length2 | Prefix2 | ...
+------------+--------------//--+------------+--------------//--+-
Figure 2: Prefix Format Figure 2: Prefix Format
4.4.2. Route Origination and Prefix 4.4.2. Route Origination and Prefix
Routes MAY be originated containing the Prefix attribute. Routes MAY be originated containing the Prefix attribute.
4.4.3. Route Selection and Prefix 4.4.3. Route Selection and Prefix
The Prefix attribute MAY be used for route selection. The Prefix attribute MAY be used for route selection.
4.4.4. Aggregation and Prefix 4.4.4. Aggregation and Prefix
Routes with differing Prefix attribute MUST NOT be aggregated. Routes with differing Prefix attributes 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.
4.4.5. Route Dissemination and Prefix 4.4.5. Route Dissemination and Prefix
The LS receiving this attribute should disseminate 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.
4.5. TrunkGroup Attribute 4.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. TRIP Type Code: 19.
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 used to complete calls. It enables providers to route on the gateway used to complete calls. It enables providers to route
calls to destinations through preferred trunks. This attribute is calls to destinations through preferred trunks. This attribute is
relatively static. relatively static.
4.5.1. TrunkGroup Syntax 4.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 identifiers. It indicates that composed of a sequence of trunkgroup identifiers. It indicates that
the gateway can complete the call through any trunkgroup identifier the gateway can complete the call through any trunkgroup identifier
indicated in the sequence. indicated in the sequence.
Each trunkgroup identifier is encoded as a length-value field (shown Each trunkgroup identifier is encoded as a Length-Value field (shown
in Figure 3 below). The length field is a 1-octet unsigned numeric in Figure 3 below). The Length field is a 1-octet unsigned numeric
value. The value field is a variable length field consisting of two value. The Value field is a variable-length field consisting of two
sub-fields, a trunk group label followed by a trunk context, the two subfields, a trunkgroup label followed by a trunk context, the two
sub-fields separated by the delimiter ";" (semicolon). Both the trunk subfields separated by the delimiter ";" (semicolon). Both the
group label and the trunk context sub-fields are of variable length. trunkgroup label and the trunk context subfields are of variable
The length field represents the total size of the value field length. The Length field represents the total size of the Value
including the delimiter. field including the delimiter.
The permissible character set for the trunk group label and the trunk The permissible character set for the trunk group label and the
group context sub-fields and the associated ABNF [8] is per rules trunkgroup context subfields and the associated ABNF [8] is per rules
outlined in [4]. outlined in [4].
The presence of TrunkGroup attribute with the length field of the The presence of the TrunkGroup attribute with the Length field of the
attribute as 0 signifies that the TGREP GW can terminate ALL attribute as 0 signifies that the TGREP GW can terminate ALL
trunkgroup for the given Reachable route(s). trunkgroups for the given Reachable route(s).
< 1 octet > < Length1 octets > < 1 octet > < Length2 octets >
+-----------+--------------//--+-----------+--------------//--+-
| Length1 | TrunkGroup 1 | Length2 | TrunkGroup 2 | ...
+-----------+--------------//--+-----------+--------------//--+-
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ... 7 8 9 0 1 2 3 4 5 ...
+---------------+--------------------+---------------+---------------
| Length | TrunkGroup 1... | Length |TrunkGroup 2...
+---------------+--------------------+---------------+---------------
Figure 3: TrunkGroup Syntax Figure 3: TrunkGroup Syntax
4.5.2. Route Origination and TrunkGroup 4.5.2. Route Origination and TrunkGroup
Routes MAY be originated containing the TrunkGroupattribute. Routes MAY be originated containing the TrunkGroupattribute.
4.5.3. Route Selection and TrunkGroup 4.5.3. Route Selection and TrunkGroup
The TrunkGroup attribute MAY be used for route selection. Certain The TrunkGroup attribute MAY be used for route selection. Certain
trunkgroups MAY be preferred over others based on provider policy. trunkgroups MAY be preferred over others based on provider policy.
4.5.4. Aggregation and TrunkGroup 4.5.4. Aggregation and TrunkGroup
Routes with differing TrunkGroup attribute MUST NOT be aggregated. Routes with differing TrunkGroup attributes 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.
4.5.5. Route Dissemination and TrunkGroup 4.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 SHOULD not be disseminated external to the ITAD, with to ITAD. Routes SHOULD not be disseminated external to the ITAD,
TrunkGroup attribute. with TrunkGroup attribute.
4.6. Carrier Attribute 4.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. TRIP Type Code: 20.
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 uses to complete calls. 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.
4.6.1. Carrier Syntax 4.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 identifiers. It indicates that the route of a sequence of carrier identifiers. It indicates that the route
can complete the call to any of the carriers represented in the can complete the call to any of the carriers represented in the
sequence of carrier identifiers [11]. sequence of carrier identifiers [13].
Each carrier identifier is encoded as a length-value field (shown in Each carrier identifier is encoded as a Length-Value field (shown in
Figure 4 below). The length field is a 1-octet unsigned numeric Figure 4 below). The Length field is a 1-octet unsigned numeric
value. The value field is a variable length field. value. The Value field is a variable-length field.
The permissible character set for the value field and the associated The permissible character set for the Value field and the associated
ABNF [9] is per rules outlined in [5]. Specifically, it carries ABNF [8] is per rules outlined in [5]. Specifically, it carries
"global-cic" or "local-cic" [5]. In case of "local-cic", the "global-cic" or "local-cic" [5]. In case of "local-cic", the
"phonedigit-hex" part and the "cic-context" part would be separated "phonedigit-hex" part and the "cic-context" part would be separated
by the delimiter ";". Hence, absence or presence of the delimiter can by the delimiter ";". Hence, absence or presence of the delimiter
be used to determine if the value is a "global-cic" or a "local-cic". can be used to determine if the value is a "global-cic" or a "local-
The length field represents the total size of the value field cic". The Length field represents the total size of the Value field
including the delimiter. including the delimiter.
The presence of Carrier Attribute with the length field of the The presence of the 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 < 1 octet > < Length1 octets > < 1 octet > < Length2 octets >
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ... 7 8 9 0 1 2 3 4 5 ...
+---------------+--------------------+---------------+-------------- +-----------+--------------//--+-----------+--------------//--+-
| Length | Carrier 1... | Length | Carrier 2... | Length1 | Carrier 1 | Length2 | Carrier 2 | ...
+---------------+--------------------+---------------+-------------- +-----------+--------------//--+-----------+--------------//--+-
Figure 4: Carrier Syntax Figure 4: Carrier Syntax
4.6.2. Route Origination and Carrier 4.6.2. Route Origination and Carrier
Routes MAY be originated containing the Carrier attribute. Routes MAY be originated containing the Carrier attribute.
4.6.3. Route Selection and Carrier 4.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.
4.6.4. Aggregation and Carrier 4.6.4. Aggregation and Carrier
Routes with differing Carrier attribute MUST NOT be aggregated. Routes with differing Carrier attributes MUST NOT be aggregated.
Routes with the same value in the Carrier attribute MAY be aggregated Routes with the same value in the Carrier attribute MAY be aggregated
and the same Carrier attribute attached to the aggregated object. and the same Carrier attribute attached to the aggregated object.
4.6.5. Route Dissemination and Carrier 4.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.
5. TrunkGroup and Carrier Address Families 5. TrunkGroup and Carrier Address Families
As described in TRIP [2], the address family field gives the type of 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 address for the route. Two new address families and their codes are
defined in this Section: defined in this section:
Code Address Family Code Address Family
4 TrunkGroup 4 TrunkGroup
5 Carrier 5 Carrier
When a set of GWs are to be managed at the granularity of carriers or
trunkgroups then it may be more appropriate for a GW to advertise When a set of GWs is to be managed at the granularity of carriers or
routes using the Carrier address family or trunkgroup address family 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 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
nature like AvailableCircuits by providing the ability to manage nature like AvailableCircuits by providing the ability to manage
resources at the granularity of a trunkgroup or a carrier. resources at the granularity of a trunkgroup or a carrier.
- It enables scalability as gateways can get really large with the - It enables scalability as gateways can get really large with the
ability to provision hundreds or a few thousand circuits and this ability to provision hundreds or a few thousand circuits, and this
can increase the potential for traffic that reports dynamic can increase the potential for traffic that reports dynamic
resource information between the gateway and the LS. The model resource information between the gateway and the LS. The model
introduced can potentially alleviate this UPDATE traffic hence introduced can potentially alleviate this UPDATE traffic, hence
increasing efficiency and providing a scalable gateway increasing efficiency and providing a scalable gateway registration
registration model. model.
5.1. Address Family Syntax 5.1. Address Family Syntax
Consider the generic TRIP route format from TRIP[2] shown below. Consider the generic TRIP route format from TRIP[2] shown below.
0 1 2 3 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 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 | | Address Family | Application Protocol |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Length | Address (variable) ... | Length | Address (variable) ...
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 5: Generic TRIP Route Format Figure 5: Generic TRIP Route Format
The Address Family field will be used to represent the type of the The Address Family field will be used to represent the type of the
address associated for this family, which is based on the TrunkGroup address associated for this family, which is based on the TrunkGroup
or Carrier. The codes for the new address families will be allocated or Carrier. The codes for the new address families have been
by IANA. allocated by IANA.
The code for the trunk group address family is 4 and the code for the The code for the TrunkGroup address family is 4, and the code for the
carrier address family is 5. Carrier address family is 5.
The Application Protocol field is the same as the one for the The Application Protocol field is the same as the one for the
Decimal, Pentadecimal and E.164 address families defined in TRIP[2]. Decimal, Pentadecimal, and E.164 address families defined in TRIP
The Length field represents the total size of the Address field in [2]. The Length field represents the total size of the Address field
bytes. in bytes.
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: Carrier address family, and the syntax is as follows:
For the TrunkGroup Address Family, the Address field represents a For the TrunkGroup address family, the Address field represents a
Trunkgroup value that is defined as specified in an earlier Section TrunkGroup value that is defined as specified in Section 4.5.1,
4.5.1 about the TrunkGroup Attribute. "TrunkGroup Syntax".
For the Carrier Address Family, the Address field represents a For the Carrier address family, the Address field represents a
Carrier value. This is the same as the value field specified in an Carrier value. This is the same as the Value field specified in an
earlier Section 4.6.1 about the Carrier Attribute. earlier Section 4.6.1, "Carrier Syntax".
The above mentioned address families are not hierarchical, but flat. The above mentioned address families are not hierarchical, but flat.
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 possible. gateway with the TrunkGroup or Carrier address family, if possible.
This will potentially offer a more efficient resource reporting This will potentially offer a more efficient resource reporting
framework, and a scalable model for gateway provisioning. framework, and a scalable model for gateway provisioning.
However, when the gateway is not using TrunkGroup or Carrier address However, when the gateway is not using the TrunkGroup or Carrier
family, it MAY use the above attributes with the Decimal, address family, it MAY use the above attributes with the Decimal,
Pentadecimal and E.164 address families. Pentadecimal, and E.164 address families.
The prefix attribute cannot be used when the address family is E164 The Prefix attribute cannot be used when the address family is E164
numbers, Pentadecimal routing numbers or Decimal routing numbers. numbers, Pentadecimal routing numbers, or Decimal routing numbers.
The Carrier attribute cannot be used if the address family type is The Carrier attribute cannot be used if the address family type is
Carrier. Carrier.
The TrunkGroup attribute cannot be used if the address family type is The TrunkGroup attribute cannot be used if the address family type is
TrunkGroup. TrunkGroup.
6. Gateway Operation 6. Gateway Operation
A gateway uses TGREP 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 TRIP 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,
gateway will not create its own call routing database. In this the gateway will not create its own call routing database. In this
section we describe the operation of TGREP on a gateway. section, we describe the operation of TGREP on a gateway.
6.1. Session Establishment 6.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 entity. The follows exactly the same procedures as any other TRIP entity. The
TGREP gateway sends an OPEN message which includes a Send Receive TGREP gateway sends an OPEN message that includes a Send Receive
Capability in the Optional Parameters. The Send Receive Capability is Capability in the Optional Parameters. The Send Receive Capability
set by the gateway to Send Only. The OPEN message also contains the is set by the gateway to Send Only. The OPEN message also contains
address families supported by the gateway. The remainder of the peer the address families supported by the gateway. The remainder of the
session establishment is identical to TRIP. peer session establishment is identical to TRIP.
6.2. UPDATE Messages 6.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.
TGREP processing of the UPDATE message at the gateway is identical to TGREP processing of the UPDATE message at the gateway is identical to
UPDATE processing in TRIP[2]. A TGREP sender MUST support all UPDATE processing in TRIP[2]. A TGREP sender MUST support all
mandatory TRIP attributes. mandatory TRIP attributes.
6.3. KEEPALIVE Messages 6.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 [2]. Section 4.4 of TRIP [2].
6.4. Error Handling and NOTIFICATION Messages 6.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
that a TGREP gateway will never generate a NOTIFICATION message in is 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.
6.5. TGREP Finite State Machine 6.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.
6.6. Call Routing Databases 6.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 LS. 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-
and hence we will call them Adj-TRIB-GWs-Out. An Adj-TRIB-GW-Out Out, and hence we will call them Adj-TRIBs-GW-Out. An Adj-TRIB-GW-
contains the gateway's reachability information advertised to its Out 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 document (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
TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn 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 routes from its peer TRIP LSs, and hence it does not run call route
selection. selection.
6.7. Multiple Address Families 6.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 reachability of telephony destinations. A TGREP session to convey the reachability of telephony destinations. A TGREP
MUST NOT send UPDATEs of more than one of the following categories session MUST NOT send UPDATEs of more than one of the following
(a) Prefix Address families (E164, Pentadecimal and decimal) (b) categories (a) Prefix address families (E164, Pentadecimal, and
Trunkgroup address family (c) Carrier Address family for a given Decimal), (b) TrunkGroup address family, or (c) Carrier address
established session. TGREP should specify its choice address family family for a given established session. TGREP should specify its
through the route-type capability in the OPEN message. And route-type choice address family through the route-type capability in the OPEN
specification in the OPEN message violating the above rule should be message. And route-type specification in the OPEN message violating
rejected with a NOTIFICATION message. the above rule should be rejected with a NOTIFICATION message.
6.8. Route Selection and Aggregation 6.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.
7. LS/Proxy Behavior 7. 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 which can complimentary to TRIP in providing reachability information, which
then be further fed into the Location Server. The architecture of an can then be further fed into the Location Server. The architecture
LS/Proxy system is as follows: There exists a TRIP LS application of an LS/Proxy system is as follows: There exists a TRIP LS
that functions as a speaker in the I-TRIP/E-TRIP network as application that functions as a speaker in the I-TRIP/E-TRIP network
documented in TRIP [2]. This component is termed as "LS-Egress" for as documented in TRIP [2]. This component is termed as "Egress LS"
the purposes of this discussion. Then, there is a signaling server for the purposes of this discussion. Then, there is a signaling
fronting a set of gateways. In conjunction with this signaling server fronting a set of gateways. In conjunction with this
server, is also a second component operating in receive mode, that signaling server is also a second component operating in receive
peers with one more gateways, each of them using TGREP to advertise mode, which peers with one or more gateways, each of them using TGREP
routing information. This component on the receiving end of one or to advertise routing information. This component on the receiving
more TGREP sessions is termed as the "LS-Ingress" or "TGREP Receiver" end of one or more TGREP sessions is termed as the "Ingress LS" or
for the purposes of this discussion. Also, the entity (typically, a "TGREP receiver" for the purposes of this discussion. Also, the
Gateway) advertising the routes on the TGREP session is termed as the entity (typically, a gateway) advertising the routes on the TGREP
"TGREP Sender". The "TGREP Receiver" receiving the TRIP messages session is termed as the "TGREP sender". The TGREP receiver
takes the resulting routing information from each gateway, and receiving the TRIP messages takes the resulting routing information
"exports" it to another process we define below, that performs from each gateway, and "exports" it to another process we define
consolidation and aggregation, in that order. These operations would below, that performs consolidation and aggregation, in that order.
take as input the collective set of routes from all the gateways. These operations would take as input the collective set of routes
Subsequently, the resulting TRIB is passed as input into the LS- from all the gateways. Subsequently, the resulting TRIB is passed as
Egress process as shown below, that can then disseminate these via input into the LS-Egress process as shown below, that can then
TRIP. The interface between the TGREP Receiver(aka. LS-Ingress) disseminate these via TRIP. The interface between the TGREP receiver
peering with the GW(s) and the TRIP LS (LS-Egress) is entirely a (aka Ingress LS) peering with the GW(s) and the TRIP LS (Egress LS)
local matter. is entirely a local matter.
The nature of the Consolidation and Aggregation operations and the The nature of the consolidation and aggregation operations and the
accompanying motivation are described in the subsections below. The accompanying motivation are described in the subsections below. The
order in which the operations are listed represents an implicit order in which the operations are listed represents an implicit
logical sequence in which they are applied. The architecture for an logical sequence in which they are applied. The architecture for an
LS/Proxy entity is shown in Figure 6 below. LS/Proxy entity is shown in Figure 6 below.
+-------------------------------------------------------+ +-------------------------------------------------------+
| +-------------------------------+ | | +-------------------------------+ |
| | +-+ +-+ | | TGREP | | +-+ +-+ | | TGREP
| | |A| |C| | | +-----+ | | |A| |C| | | +-----+
| | |g| |o| | | | | | | |g| |o| | | | |
| +-------------+ | |g| |n| +-------------+ | | --| GW | | +-------------+ | |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| | Management |-++-+----| GW | | | (I-TRIP/ | | |t| |d| | Management |-++-+----| GW |
| | E-TRIP) | | |i| |a| | | | | +-----+ | | E-TRIP) | | |i| |a| | | | | +-----+
| | (LS-Egress) | | |o| |t| | |-+ +--- | | (Egress LS) | | |o| |t| | |-+ +---
| +-----------/-+ | |n| |i| +-------------+ | | +-----+ | +-----------/-+ | |n| |i| +-------------+ | | +-----+
| / | | | |o| | | --| | | / | | | |o| | | --| |
| / | | | |n| (LS-Ingress) | | | GW | | / | | | |n| (Ingress LS) | | | GW |
| / | +-+ +-+ | | +-----+ | / | +-+ +-+ | | +-----+
| / | TGREP Receiver | | | / | TGREP Receiver | |
| / +-------------------------------+ | | / +-------------------------------+ |
| / | | / |
| / | | / |
+-------/-----------------------------------------------+ +-------/-----------------------------------------------+
/ LS/Proxy / LS/Proxy
/ /
/ /
/ /
skipping to change at page 24, line 5 skipping to change at page 22, line 5
| LS | | LS |
| | | |
| | | |
| | | |
| | | |
| | | |
+-----------------+ +-----------------+
Figure 6: LS Architecture for TRIP-GW Figure 6: LS Architecture for TRIP-GW
7.1. Route consolidation 7.1. Route Consolidation
The TGREP receiver (LS-Ingress) may receive routing information from The TGREP receiver (Ingress LS) may receive routing information from
one or more gateways. It is possible that multiple routes are one or more gateways. It is possible that multiple routes are
available for the same destination. These different alternative available for the same destination. These different alternative
routes may be received from the same gateway, or from multiple routes may be received from the same gateway or from multiple
gateways. It is RECOMMENDED that the set of gateway routes for each gateways. It is RECOMMENDED that the set of gateway routes for each
destination be consolidated, before presenting a candidate route, to destination be consolidated, before presenting a candidate route, to
the LS-Egress entity. The motivation for this operation should be to the Egress LS entity. The motivation for this operation should be to
define a route that can maximally represent the collective routing define a route that can maximally represent the collective routing
capabilities of the set of gateways, managed by this TGREP receiver. capabilities of the set of gateways, managed by this TGREP receiver.
Let us take an example scenario in order to bring out the motivation Let us take an example scenario in order to bring out the motivation
for this operation. Let us say, the TGREP receiver maintains peering for this operation. Let us say, the TGREP receiver maintains peering
sessions with gateways A, and B. sessions with gateways A and B.
- Gateway A advertises a route for destination "SIP 408" on the - Gateway A advertises a route for destination "SIP 408" on the
E.164 address family with the Carrier attribute value C1. E.164 address family with the Carrier attribute value C1.
- Gateway B advertises a route for destination "SIP 408" on the - Gateway B advertises a route for destination "SIP 408" on the
E.164 address family with Carrier attribute value C2. E.164 address family with Carrier attribute value C2.
The TGREP receiver that receives these routes can consolidate The TGREP receiver that receives these routes can consolidate these
these constituent routes into a single route for destination "SIP constituent routes into a single route for destination "SIP 408" with
408" with its Carrier attribute being a union of the Carrier its Carrier attribute being a union of the Carrier attribute values
attribute values of the individual routes, namely, "C1 C2". This of the individual routes, namely, "C1 C2". This operation is
operation is referred to as Consolidation. In the above example, referred to as consolidation. In the above example, it is possible
it is possible that a route to the destination "SIP 408" through that a route to the destination "SIP 408" through one or more
one or more carriers may have been lost if the individual routes carriers may have been lost if the individual routes were not
were not consolidated. consolidated.
Another example is to consolidate the Prefix attribute from Another example is to consolidate the Prefix attribute from multiple
multiple Carrier or Trunkgroup updates received from different Carrier or TrunkGroup updates received from different gateways for
gateways for the same destination. Let us say, there are Carrier the same destination. Let us say, there are Carrier address family
AF updates from two gateways for Carrier destination X, and the (AF) updates from two gateways for Carrier destination X, and the
prefix attribute values are {408, 650} from one update and {919, prefix attribute values are {408, 650} from one update and {919, 973}
973} from the other. The prefix values from these two updates can from the other. The prefix values from these two updates can be
be consolidated into a single Carrier AF route advertisement with consolidated into a single Carrier AF route advertisement with prefix
prefix value {408, 650, 919, 973}. value {408, 650, 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
The specifics of applying the consolidation operation to specifics of applying the consolidation operation to different
different attributes and routes from different address families, attributes and routes from different address families is left to the
is left to the individual TGREP receiver implementations. individual TGREP receiver implementations.
7.2. Aggregation 7.2. Aggregation
The set of gateway routes, that are in a consolidated form or The set of gateway routes, which 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
which is responsible for I-TRIP/E-TRIP processing (LS-Egress). This that is responsible for I-TRIP/E-TRIP processing (Egress LS). This
operation follows the standard aggregation procedures described in operation follows the standard aggregation procedures described in
the TRIP [2], while adhering to the aggregation rules for each route TRIP [2], while adhering to the aggregation rules for each route
attribute. attribute.
7.3. Consolidation v/s Aggregation 7.3. Consolidation versus Aggregation
To highlight the difference between the two operations discussed To highlight the difference between the two operations discussed
above, "Consolidation" combines multiple routes for the same route above, "consolidation" combines multiple routes for the same route
destination, whereas "Aggregation" combines routes for different destination, whereas "aggregation" combines routes for different
route destinations that qualify as candidates to be summarized route destinations that qualify as candidates to be summarized
resulting in route information reduction. resulting in route information reduction.
To take an example, if there are multiple gateways offering routes to To take an example, if there are multiple gateways offering routes to
an E.164 destination "408" but with possibly different attributes an E.164 destination "408" but with possibly different attributes
(e.g.: Carrier), the LS/Proxy can combine these to form one route for (e.g., Carrier), the LS/Proxy can combine these to form one route for
"408" but representing the attribute information collectively. This "408" but representing the attribute information collectively. This
process is Consolidation. process is consolidation.
If, for example, the LS/Proxy receives routes for 4080, 4081, 4082, If, for example, the LS/Proxy receives routes for 4080, 4081, 4082,
... 4089 from amongst a set of gateways, it could aggregate these ... 4089 from amongst a set of gateways, it could aggregate these
different candidate routes to have a summarized route destination different candidate routes to have a summarized route destination
"408" with each of the attributes computed using the Aggregation "408" with each of the attributes computed using the aggregation
procedures defined in the TRIP. procedures defined in TRIP.
8. Security Considerations 8. Security Considerations
The Security considerations for TGREP are identical to that The security considerations for TGREP are identical to that
identified in TRIP [2] and are just restated here for the purposes of identified in TRIP [2] and are just restated here for the purposes of
clarity. clarity.
The security mechanism for the peering session between TGREP GW and a 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 TRIP LS, in an IP network, is IPsec [3]. IPsec uses two protocols to
provide traffic security: Authentication Header (AH) [6] and provide traffic security: Authentication Header (AH) [6] and
Encapsulating Security Payload (ESP) [7]. Encapsulating Security Payload (ESP) [7].
The AH header affords data origin authentication, connectionless The AH header affords data origin authentication, connectionless
integrity and optional anti-replay protection of messages passed integrity, and optional anti-replay protection of messages passed
between the peer LSs. The ESP header provides origin authentication, between the peer LSs. The ESP header provides origin authentication,
connectionless integrity, anti-replay protection, and confidentiality connectionless integrity, anti-replay protection, and confidentiality
of messages. of messages.
Implementations of the protocol defined in this document employing Implementations of the protocol defined in this document employing
the ESP header SHALL comply with section 3.1.1 of [13], which defines the ESP header SHALL comply with Section 3.1.1 of [10], which defines
a minimum set of algorithms for integrity checking and encryption. a minimum set of algorithms for integrity checking and encryption.
Similarly, implementations employing the AH header SHALL comply with Similarly, implementations employing the AH header SHALL comply with
section 3.2 of [13], which defines a minimum set of algorithms for Section 3.2 of [10], which defines a minimum set of algorithms for
integrity checking. integrity checking.
Implementations SHOULD use IKEv2 [7] to permit more robust keying Implementations SHOULD use the Internet Key Exchange Protocol (IKEv2)
options. Implementations employing IKEv2 SHOULD support 3DES-CBC for [9] to permit more robust keying options. Implementations employing
confidentiality and HMAC-SHA1 for integrity. IKEv2 SHOULD support 3DES-CBC for confidentiality and HMAC-SHA1 for
integrity.
A Security Association (SA) [3] is a simplex "connection" that A Security Association (SA) [3] is a simplex "connection" that
affords security services to the traffic carried by it. Security affords security services to the traffic carried by it. Security
services are afforded to a SA by the use of AH, or ESP, but not both. 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 Two types of SAs are defined: transport mode and tunnel mode. A
transport mode SA is a security association between two hosts, and is transport mode SA is a security association between two hosts, and is
appropriate for protecting the TRIP session between two peer LSs. appropriate for protecting the TRIP session between two peer LSs.
9. IANA Considerations 9. IANA Considerations
Both TRIP[2] and TGREP share the same IANA registry for Capabilities, Both TRIP [2] and TGREP share the same IANA registry for
Attributes, Address Families, and Application Protocols. This Capabilities, Attributes, Address Families, and Application
specification requests that IANA add the following attribute codes Protocols. IANA has added the following attribute codes and address
and address family codes to the TRIP [2] registries. family codes to the TRIP [2] registries.
9.1. Attribute Codes 9.1. Attribute Codes
The Attribute Type Codes to be assigned for the new attributes The Attribute Type Codes assigned for the new attributes defined in
defined in this document are listed below: this document are listed below:
| Code Attribute Reference
| ---- --------- ---------
| 13 TotalCircuitCapacity [RFCXXXX]
| 14 AvailableCircuits [RFCXXXX]
| 15 CallSuccess [RFCXXXX]
| 16 E.164 Prefix [RFCXXXX]
| 17 Pentadecimal Routing Number Prefix [RFCXXXX]
| 18 Decimal Routing Number Prefix [RFCXXXX]
| 19 TrunkGroup [RFCXXXX]
| 19 Carrier [5]
[NOTE TO RFC-ED: please replace XXXX with the rfc number of this Code Attribute Reference
specification ] ---- --------- ---------
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 9.2. Address Family Codes
The following subsections show the codes to be assigned for the two The following subsections show the codes that have been assigned for
new address families introduced in this document the two new address families introduced in this document.
9.2.1. TrunkGroup Address Family 9.2.1. TrunkGroup Address Family
| Code Address Family Reference Code Address Family Reference
| ---- -------------- --------- ---- -------------- ---------
| 4 TrunkGroup [RFCXXXX] 4 TrunkGroup [RFC5140]
[NOTE TO RFC-ED: please replace XXXX with the rfc number of this
specification ]
9.2.2. Carrier Address Family 9.2.2. Carrier Address Family
| Code Address Family Reference Code Address Family Reference
| ---- -------------- --------- ---- -------------- ---------
| 5 Carrier [RFCXXXX] 5 Carrier [RFC5140]
[NOTE TO RFC-ED: please replace XXXX with the rfc number of this
specification ]
10. Change history
[[NOTE TO RFC-ED: Please remove this section prior to publication]]
10.1. Changes since draft-ietf-iptel-tgrep-03.txt
- No change in content. Releasing a new revision for renewal of
draft.
10.2. Changes since draft-ietf-iptel-tgrep-02.txt
- No change in content. Releasing a new revision for renewal of
draft.
10.3. 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.
10.4. Changes since draft-ietf-iptel-tgrep-00.txt
- Added recommendations for AvailableCircuits and CallSuccess
attributes.
- Updated Carrier Attribute with ASCII syntax.
- Removed thresholding scheme description.
- Updated author addresses.
10.5. Changes since draft-ietf-iptel-trip-gw-00.txt
- Changed title of the document to TGREP (Telephony Gateway
REgistration Protocol).
- Changed name of protocol described in this document to TGREP.
- Changed Abstract and Introduction sections to position TGREP as
an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP).
- Modified the section on LS/Proxy Behavior including the diagram.
- Added an additional example to the Route Consolidation section.
- Changed the format of Carrier (both as an attribute and as an AF)
to accommodate representation of Country codes in association
with CICs.
- Updated text to allow Carrier attribute in TrunkGroup address
family and TrunkGroup attribute in Carrier address family.
10.6. Changes since -03
- Removed Carrier-Trunkgroup attribute and address family and
references to it.
- Added Terminology and Definitions section.
- Updated CallSuccess attribute.
- Added Prefix attribute.
- Added Carrier attribute.
- Added TrunkGroup attribute.
- Added TrunkGroup Address Family.
- Added Carrier Address Family.
- Added some more references.
10.7. Changes since -02
- Removed the requirements section.
- Discussed the motivation for introducing Carrier information into
TRIP.
- Defined a new attribute for the E.164 address family.
- Defined a new address family for CarrierCode-TrunkGroup
combination .
- Defined new attributes to advertise dynamic gateway
characteristics like resource availability, and call success
rate.
- Added as section to validate the TGREP solution against the
requirements in [6].
10.8. Changes since -01
- Added requirements.
- Added more formal analysis of REGISTER and added analysis of SLP.
- Removed circuit capacity attribute.
10.9. Changes since -00
- Added text to stress the value of this proposal for managing a
gateway cluster.
- Added attributes for circuit capacity and DSP capacity.
- Added section on LS operation, discussing aggregation issue.
11. Acknowledgments 10. Acknowledgments
We wish to thank Vijay Gurbani, Li Li, Kevin McDermott, David Oran, We wish to thank Vijay Gurbani, Li Li, Kevin McDermott, David Oran,
Bob Penfield, Jon Peterson, Anirudh Sahoo and James Yu for their Bob Penfield, Jon Peterson, Anirudh Sahoo, and James Yu for their
insightful comments and suggestions. insightful comments and suggestions.
12. References 11. References
12.1. Normative References 11.1. Normative 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] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over [2] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
IP (TRIP)," Request for Comments 3219, Internet Engineering Task over IP (TRIP)", RFC 3219, January 2002.
Force, January 2002.
[3] Kent, S. and Seo K., "Security Architecture for the Internet [3] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
[4] V. Gurbani and C. Jennings, "Representing trunk groups in tel/sip [4] Gurbani, V. and C. Jennings, "Representing Trunk Groups in
Uniform Resource Identifiers (URIs)," Internet Draft, Internet tel/sip Uniform Resource Identifiers (URIs)", RFC 4904, June
Engineering Task Force, August 2006. 2007.
[5] J. Yu, "Number Portability Parameters for the "tel" URI", RFC [5] Yu, J., "Number Portability Parameters for the "tel" URI", RFC
4694, October 2006. 4694, October 2006.
[6] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [6] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005. December 2005.
[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax [8] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", STD 68, RFC 5234, January 2008.
12.2. Informative References [9] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[9] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [10] Manral, V., "Cryptographic Algorithm Implementation Requirements
session initiation protocol," Request for Comments 3261, Internet for Encapsulating Security Payload (ESP) and Authentication
Engineering Task Force, Mar. 1999. Header (AH)", RFC 4835, April 2007.
[10] J. Rosenberg and H. Schulzrinne, "A framework for telephony 11.2. Informative References
routing over IP," Request for Comments 2871, Internet Engineering
Task Force, June 2000.
[11] ITU-T List of ITU Carrier Codes (published periodically in the [11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
ITU-T Operational Bulletin). Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[12] J. Rosenberg, "Requirements for Gateway Registration," Internet [12] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony
Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. Routing over IP", RFC 2871, June 2000.
[13] D. Eastlake, "Cryptographic Algorithm Implementation [13] ITU-T List of ITU Carrier Codes (published periodically in the
Requirements for Encapsulating Security Payload (ESP) and ITU-T Operational Bulletin).
Authentication Header (AH)", RFC 4305, December 2005.
[14] Rosenberg, J., "Requirements for Gateway Registration", Work in
Progress, November 2001.
Authors' Addresses Authors' Addresses
Manjunath Bangalore Manjunath S. Bangalore
Cisco Systems Inc. Cisco
Mail Stop SJC-14/2/1 Mail Stop SJC-14/2/1
3625 Cisco Way 3625 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
Phone: +1-408-525-7555 Phone: +1-408-525-7555
email: manjax@cisco.com EMail: manjax@cisco.com
Rajneesh Kumar Rajneesh Kumar
Cisco Systems Inc. Cisco
Mail Stop SJC-14/4/2 Mail Stop SJC-14/4/2
3625 Cisco Way 3625 Cisco Way
San Jose, CA 95134 San Jose, CA 95134
Phone: +1-408-527-6148 Phone: +1-408-527-6148
email: rajneesh@cisco.com EMail: rajneesh@cisco.com
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Inc. Cisco
Mail Stop PPY02/2 Edison, NJ 08837
600 Lanidex Plaza EMail: jdrosen@cisco.com
Parsippany
NJ 07054
Phone: +1-973-952-5060
email: jdrosen@cisco.com
Hussein F. Salama Hussein F. Salama
Citex Software Ltd. Citex Software
4 Dr. Soliman Square Giza, Egypt
Dokki, Giza 12311 EMail: hsalama@citexsoftware.com
Egypt
Phone: +20-2-33371672/+1-425-7497286 Dhaval Niranjan Shah
email: h.f.salama@ieee.org
Dhaval N. Shah
Moowee Inc. Moowee Inc.
4920 El Camino Real, 4920 El Camino Real
Los Altos Los Altos, CA 94022
CA 94022
Phone: +1-408-307-7455 Phone: +1-408-307-7455
email: dhaval@moowee.tv EMail: dhaval@moowee.tv
Intellectual Property Statement 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Copyright Statement
Copyright (C) The IETF Trust (2007). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 156 change blocks. 
585 lines changed or deleted 464 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/