< draft-ietf-iptel-tgrep-08.txt   draft-ietf-iptel-tgrep-09.txt >
IPTEL Working Group Manjunath Bangalore, Cisco Systems IPTEL Working Group Manjunath Bangalore, Cisco Systems
Internet Draft Rajneesh Kumar, Cisco Systems Internet Draft Rajneesh Kumar, Cisco Systems
draft-ietf-iptel-tgrep-08.txt Hussein Salama, MenaNet Communications draft-ietf-iptel-tgrep-09.txt Hussein Salama, Citex Software
January 2007 Jonathan Rosenberg, Cisco Systems September 2007 Jonathan Rosenberg, Cisco Systems
Expiration Date: July 2007 Dhaval Shah, Cisco Systems Expiration Date: March 2008 Dhaval 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 By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 11, 2007. This Internet-Draft will expire on March 15, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes the Telephony Gateway Registration Protocol This document describes the Telephony Gateway Registration Protocol
(TGREP) for registration of telephony prefixes supported by telephony (TGREP) for registration of telephony prefixes supported by telephony
gateways and soft switches. The registration mechanism can also be gateways and soft switches [12]. The registration mechanism can also
used to export resource information. The prefix and resource be 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 (ITAD). 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 Terminology and Definitions .............................. 4
2 Introduction ............................................. 4 2 Introduction ............................................. 4
3 TGREP: Overview of operation ............................. 6 3 TGREP: Overview of operation ............................. 6
skipping to change at page 3, line 23 skipping to change at page 3, line 23
4.3 CallSuccess Attribute .................................... 11 4.3 CallSuccess Attribute .................................... 11
4.4 Prefix Attributes ........................................ 13 4.4 Prefix Attributes ........................................ 13
4.5 TrunkGroup Attribute ..................................... 14 4.5 TrunkGroup Attribute ..................................... 14
4.6 Carrier Attribute ........................................ 16 4.6 Carrier Attribute ........................................ 16
5 TrunkGroup and Carrier Address Families .................. 17 5 TrunkGroup and Carrier Address Families .................. 17
5.1 Address Family Syntax .................................... 18 5.1 Address Family Syntax .................................... 18
6 Gateway Operation ........................................ 20 6 Gateway Operation ........................................ 20
6.1 Session Establishment .................................... 20 6.1 Session Establishment .................................... 20
6.2 UPDATE Messages .......................................... 20 6.2 UPDATE Messages .......................................... 20
6.3 KEEPALIVE Messages ....................................... 20 6.3 KEEPALIVE Messages ....................................... 20
6.4 Error Handling and NOTIFICATION Messages ................. 20 6.4 Error Handling and NOTIFICATION Messages ................. 21
6.5 TGREP Finite State Machine ............................... 21 6.5 TGREP Finite State Machine ............................... 21
6.6 Call Routing Databases ................................... 21 6.6 Call Routing Databases ................................... 21
6.7 Multiple Address Families ................................ 21 6.7 Multiple Address Families ................................ 21
6.8 Route Selection and Aggregation .......................... 21 6.8 Route Selection and Aggregation .......................... 22
7 LS/Proxy Behavior ........................................ 22 7 LS/Proxy Behavior ........................................ 22
7.1 Route consolidation ...................................... 24 7.1 Route consolidation ...................................... 24
7.2 Aggregation .............................................. 25 7.2 Aggregation .............................................. 25
7.3 Consolidation v/s Aggregation ............................ 26 7.3 Consolidation v/s Aggregation ............................ 25
8 Security Considerations .................................. 26 8 Security Considerations .................................. 25
9 IANA Considerations ...................................... 27 9 IANA Considerations ...................................... 26
9.1 Attribute Codes .......................................... 27 9.1 Attribute Codes .......................................... 26
9.2 Address Family Codes ..................................... 27 9.2 Address Family Codes ..................................... 27
10 Change history ........................................... 28 10 Change history ........................................... 27
10.1 Changes since draft-ietf-iptel-tgrep-03.txt .............. 28 10.1 Changes since draft-ietf-iptel-tgrep-03.txt .............. 27
10.2 Changes since draft-ietf-iptel-tgrep-02.txt .............. 28 10.2 Changes since draft-ietf-iptel-tgrep-02.txt .............. 27
10.3 Changes since draft-ietf-iptel-tgrep-01.txt .............. 28 10.3 Changes since draft-ietf-iptel-tgrep-01.txt .............. 28
10.4 Changes since draft-ietf-iptel-tgrep-00.txt .............. 29 10.4 Changes since draft-ietf-iptel-tgrep-00.txt .............. 28
10.5 Changes since draft-ietf-iptel-trip-gw-00.txt ............ 29 10.5 Changes since draft-ietf-iptel-trip-gw-00.txt ............ 28
10.6 Changes since -03 ........................................ 29 10.6 Changes since -03 ........................................ 29
10.7 Changes since -02 ........................................ 29 10.7 Changes since -02 ........................................ 29
10.8 Changes since -01 ........................................ 30 10.8 Changes since -01 ........................................ 29
10.9 Changes since -00 ........................................ 30 10.9 Changes since -00 ........................................ 29
11 Acknowledgments .......................................... 30 11 Acknowledgments .......................................... 30
12 References ............................................... 30 12 References ............................................... 30
12.1 Normative References ..................................... 30 12.1 Normative References ..................................... 30
12.2 Informative References ................................... 31 12.2 Informative References ................................... 30
Authors' Addresses ....................................... 31 Authors' Addresses ....................................... 31
Intellectual Property Statement .......................... 33 Intellectual Property Statement .......................... 32
Disclaimer of Validity ................................... 33 Copyright Statement ...................................... 32
Copyright Statement ...................................... 33 Acknowledgment ........................................... 33
Acknowledgment ........................................... 34
1. Terminology and Definitions 1. Terminology and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Some other useful definitions are: Some other useful definitions are:
Circuit: A circuit is a discrete (specific) path between two or more Circuit: A circuit is a discrete (specific) path between two or more
points along which signals can be carried. In this context, a circuit points along which signals can be carried. In this context, a circuit
is a physical path, consisting of one or more wires and possibly is a physical path, consisting of one or more wires and possibly
intermediate switching points. intermediate switching points.
Trunk: In a network, a communication path connecting two switching Trunk: In a network, a trunk is a communication path connecting two
systems used in the establishment of an end-to-end connection. In switching systems used in the establishment of an end-to-end
selected applications, it may have both its terminations in the same connection. In selected applications, it may have both its
switching system. terminations in the same switching system.
TrunkGroup: A set of trunks, traffic engineered as a unit, for the TrunkGroup: A set of trunks, traffic engineered as a unit, for the
establishment of connections within or between switching systems in establishment of connections within or between switching systems in
which all of the paths are interchangeable except where subgrouped. which all of the paths are interchangeable except where subgrouped.
Carrier: A company offering telephone and data communications between Carrier: A company offering telephone and data communications between
points (end-users and/or exchanges). points (end-users and/or exchanges).
2. Introduction 2. Introduction
It is assumed that reader of this has already gone through TRIP [2]. It is assumed that reader of this is familiar with TRIP [2,10]. In
In typical VoIP networks, Internet Telephony Administrative Domains typical VoIP networks, Internet Telephony Administrative Domains
(ITADs) will deploy numerous gateways for the purposes of (ITADs) will deploy numerous gateways for the purposes of
geographical diversity, capacity, and redundancy. When a call arrives geographical diversity, capacity, and redundancy. When a call arrives
at the domain, it must be routed to one of those gateways. at the domain, it must be routed to one of those gateways.
Frequently, an ITAD will break their network into geographic Points Frequently, an ITAD will break their network into geographic Points
of Presence (POP), with each POP containing some number of gateways, of Presence (POP), with each POP containing some number of gateways,
and a proxy server element that fronts those gateways. The Proxy and a proxy server element that fronts those gateways. The Proxy
element is a SIP Proxy [10] or H.323 Gatekeeper. The proxy server is element is a SIP Proxy [9] or H.323 Gatekeeper. The proxy server is
responsible for managing the access to the POP, and also for responsible for managing the access to the POP, and also for
determining which of the gateways will receive any given call that determining which of the gateways will receive any given call that
arrives at the POP. In conjunction with the proxy server that routes arrives at the POP. In conjunction with the proxy server that routes
the call signaling, there are two components, the "Ingress LS" the call signaling, there are two components, the "Ingress LS"
(a.k.a. "TGREP Receiver" and the "Egress LS". The "TGREP Receiver" (a.k.a. "TGREP Receiver" and the "Egress LS". The "TGREP Receiver"
component maintains TGREP peering relationship with one or more component maintains TGREP peering relationship with one or more
gateways. The routing information received from the gateways are gateways. The routing information received from the gateways are
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. the rest of the network on TRIP. For convenience, gateway and GW are
used interchangably.
This configuration is depicted graphically in Figure 1. This configuration is depicted graphically in Figure 1.
Signalling TGREP Signalling TGREP
-------------> <---------------- -------------> <----------------
+---------+ +---------+
| | | |
| GW | | GW |
> +---------+ > +---------+
skipping to change at page 6, line 48 skipping to change at page 6, line 48
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 3. TGREP: Overview of operation
TGREP is a route registration protocol for telephony destinations on TGREP is a route registration protocol for telephony destinations on
a gateway. These telephony destinations could be prefixes, trunk a gateway. These telephony destinations could be prefixes, trunk
groups or Carriers. The TGREP sender resides on the GW and gathers groups or Carriers. The TGREP sender resides on the GW and gathers
all the information from the GW to relay to the TRIP Location Server. all the information from the GW to relay to the TRIP Location Server.
A TGREP Receiver is defined, which receives this information and A TGREP Receiver is defined, which receives this information and
after certain optional operations like consolidation and aggregation, optionally performs operations like consolidation and aggregation,
hands over the reachability information a to TRIP Location Server. hands over the reachability information to a TRIP Location Server.
The routing proxy also uses the information to select the gateway for The routing proxy also uses the information to select the gateway for
incoming calls. incoming calls.
"Consolidation" combines multiple routes for the same route "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 candidate routes to be summarized route destinations that qualify as candidate routes to be summarized
resulting in route information reduction. To take an example, if resulting in route information reduction. To take an example, if
there are multiple gateways offering routes to an E.164 destination there are multiple gateways offering routes to an E.164 destination
"408" but with possibly different attributes (Eg: Carrier), the "408" but with possibly different attributes (e.g.: Carrier), the
LS/Proxy can combine these to form one route for "408" but LS/Proxy can combine these to form one route for "408" but
representing the attribute information collectively. This process is representing the attribute information collectively. This process is
Consolidation. 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 the TRIP.
The TGREP Sender establishes a session to the TGREP Receiver using The TGREP Sender establishes a session to the TGREP Receiver using a
the procedures similar to session establishment in TRIP. After the procedure similar to session establishment in TRIP. After the
session establishment the TGREP Sender sends the reachibility 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 same
format as in TRIP. However, certain TRIP attributes are not relevant format as in TRIP. However, certain TRIP attributes are not relevant
in TGREP; a TGREP Receiver MAY ignore them if they are present in a in TGREP; a TGREP Receiver MAY ignore them if they are present in a
TGREP message. The following TRIP attributes do not apply to TGREP: 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
skipping to change at page 9, line 25 skipping to change at page 9, line 25
by the LS. The total number of calls sent to the specified route on by the LS. The total number of calls sent to the specified route on
the gateway cannot exceed this total circuit capacity under steady the gateway cannot exceed this total circuit capacity under steady
state conditions. state conditions.
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 active 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 which can
skipping to change at page 12, line 34 skipping to change at page 12, line 34
4.3.1. CallSuccess Syntax 4.3.1. CallSuccess Syntax
The CallSuccess attribute is comprised of two component fields - each The CallSuccess attribute is comprised of two component fields - each
represented as an unsigned 4-octet unsigned integer. The first represented as an unsigned 4-octet unsigned integer. The first
component field represents the total number of calls terminated component field represents the total number of calls terminated
successfully for the advertised destination on a given address family successfully for the advertised destination on a given address family
over a given window of time. The second component field represents over a given window of time. The second component field represents
the total number of attempted calls for the advertised destination the total number of attempted calls for the advertised destination
within the same window of time. within the same window of time.
When the value for the total number of attempted calls wraps around,
the counter value for the number of successful calls is reset to keep
it aligned with the other component over a given window of time. The
TGREP receiver using this information should obtain this information
frequently enough to prevent loss of significance.
4.3.2. Route Origination and CallSuccess 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
attribute is expected to get statistically significant with passage attribute is expected to get statistically significant with passage
of time as more calls are attempted. It is RECOMMENDED that of time as more calls are attempted. It is RECOMMENDED that
sufficiently large windows be used to provide a useful aggregated sufficiently large windows be used to provide a useful aggregated
statistic. statistic.
4.3.3. Route Selection and CallSuccess 4.3.3. Route Selection and CallSuccess
skipping to change at page 13, line 34 skipping to change at page 13, line 42
the respective route can complete calls to. This attribute is the respective route can complete calls to. 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 3.7).
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 it's 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 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 . . . 3456789012345678|0123... 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 . . .
+-------------------------------+-----------+------------------------ +-------------------------------+-----------+------------------------
| Length | Prefix1...| Length |Prefix2 | Length | Prefix1...| Length |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.
skipping to change at page 15, line 22 skipping to change at page 15, line 24
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 sub-fields, a trunk group label followed by a trunk context, the two
sub-fields separated by the delimiter ";" (semicolon). Both the trunk sub-fields separated by the delimiter ";" (semicolon). Both the trunk
group label and the trunk context sub-fields are of variable length. group label and the trunk context sub-fields are of variable length.
The length field represents the total size of the value field The length field represents the total size of the value field
including the delimiter. 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 trunk
group context sub-fields and the associated ABNF [9] is per rules group context sub-fields 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 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). trunkgroup for the given Reachable route(s).
0 1 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 ... 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... | 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
skipping to change at page 16, line 36 skipping to change at page 16, line 36
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. sequence of carrier identifiers [11].
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 [9] 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 can
be used to determine if the value is a "global-cic" or a "local-cic". be used to determine if the value is a "global-cic" or a "local-cic".
The length field represents the total size of the value field 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 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 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 ... 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... | Length | Carrier 1... | Length | 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
skipping to change at page 18, line 22 skipping to change at page 18, line 22
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.
- Gateways can get really large with the ability to provision - It enables scalability as gateways can get really large with the
hundreds or a few thousand circuits and this can increase the ability to provision hundreds or a few thousand circuits and this
potential for traffic that reports dynamic resource information can increase the potential for traffic that reports dynamic
between the gateway and the LS. The model introduced can resource information between the gateway and the LS. The model
potentially alleviate this UPDATE traffic hence increasing introduced can potentially alleviate this UPDATE traffic hence
efficiency and providing a scalable gateway registration model. increasing efficiency and providing a scalable gateway
registration 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 will be allocated
by IANA. by IANA.
The code for the trunk group address family is 4 and the code for the The code for the trunk group address family is 4 and the code for the
carrier address family is 5. carrier address family is 5.
The Application Protocol field is same as the one for the Decimal, The Application Protocol field is the same as the one for the
PentaDecimal and E.164 address families defined in TRIP[2]. The Decimal, Pentadecimal and E.164 address families defined in TRIP[2].
Length field represents the total size of the Address field in bytes. The Length field represents the total size of the Address field 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: the Carrier address families 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 an earlier Section
4.5.1 about the TrunkGroup Attribute. 4.5.1 about the TrunkGroup Attribute.
For the Carrier Address Family, the Address field represents a For the Carrier Address Family, the Address field represents a
Carrier value. This is 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 about the Carrier Attribute.
The above mentioned address families are not heirarchical, 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 families, 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 TrunkGroup or Carrier address
family, it MAY use the above attributes with the Decimal, family, it MAY use the above attributes with the Decimal,
PentaDecimal and E.164 address families. Pentadecimal and E.164 address families.
The prefix 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.
skipping to change at page 20, line 43 skipping to change at page 21, line 7
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 is
that a TGREP gateway will never generate a NOTIFICATION message in that a TGREP gateway will never generate a NOTIFICATION message in
response to an UPDATE message, irrespective of the contents of the response to an UPDATE message, irrespective of the contents of the
UPDATE message. Any UPDATE message is silently discarded. UPDATE message. Any UPDATE message is silently discarded.
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.
skipping to change at page 21, line 31 skipping to change at page 21, line 39
outside the scope of this draft (possibly by manual configuration). outside the scope of this draft (possibly by manual configuration).
The TGREP gateway does not have databases equivalent to TRIP's Adj- The TGREP gateway does not have databases equivalent to TRIP's Adj-
TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn
routes from its peer TRIP LSs, and hence it does not run call route routes from its peer TRIP LSs, and hence it does not run call route
selection. selection.
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 reachabilty of telephony destinations. A TGREP session to convey the reachability of telephony destinations. A TGREP session
MUST NOT send UPDATEs of more than one of the following categories MUST NOT send UPDATEs of more than one of the following categories
(a) Prefix Address families (E164, Pentadecimal and decimal) (b) (a) Prefix Address families (E164, Pentadecimal and decimal) (b)
Trunkgroup address family (c) Carrier Address family for a given Trunkgroup address family (c) Carrier Address family for a given
established session. TGREP should specify it's choice address family established session. TGREP should specify its choice address family
through the route-type capability in the OPEN message. And route-type through the route-type capability in the OPEN message. And route-type
specification in the OPEN message violating the above rule should be specification in the OPEN message violating the above rule should be
rejected with a NOTIFICATION message. rejected with a NOTIFICATION message.
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 that can complimentary to TRIP in providing reachability information which can
then be further fed into the Location Server. The architecture of an then be further fed into the Location Server. The architecture of an
LS/Proxy system is as follows: There exists a TRIP LS application LS/Proxy system is as follows: There exists a TRIP LS application
that functions as a speaker in the I-TRIP/E-TRIP network as that functions as a speaker in the I-TRIP/E-TRIP network as
documented in TRIP [2]. This component is termed as "LS-Egress" for documented in TRIP [2]. This component is termed as "LS-Egress" for
the purposes of this discussion. Then, there is a signaling server the purposes of this discussion. Then, there is a signaling server
fronting a set of gateways. In conjunction with this signaling fronting a set of gateways. In conjunction with this signaling
server, is also a second component operating in receive mode, that server, is also a second component operating in receive mode, that
peers with one more gateways, each of them using TGREP to advertise peers with one more gateways, each of them using TGREP to advertise
routing information. This component on the receiving end of one or routing information. This component on the receiving end of one or
more TGREP sessions is termed as the "LS-Ingress" or "TGREP Receiver" more TGREP sessions is termed as the "LS-Ingress" or "TGREP Receiver"
skipping to change at page 22, line 36 skipping to change at page 22, line 41
Subsequently, the resulting TRIB is passed as input into the LS- Subsequently, the resulting TRIB is passed as input into the LS-
Egress process as shown below, that can then disseminate these via Egress process as shown below, that can then disseminate these via
TRIP. The interface between the TGREP Receiver(aka. LS-Ingress) TRIP. The interface between the TGREP Receiver(aka. LS-Ingress)
peering with the GW(s) and the TRIP LS (LS-Egress) is entirely a peering with the GW(s) and the TRIP LS (LS-Egress) is entirely a
local matter. 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 7 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 |-++-| +-----+
skipping to change at page 23, line 43 skipping to change at page 23, line 43
+/----------------+ +/----------------+
| | | |
| | | |
| | | |
| LS | | LS |
| | | |
| | | |
| | | |
| | | |
| | | |
+----------------+ +-----------------+
+-------------------------------------------------------+
| +-------------------------------+ |
| | +-+ +-+ | | TGREP
| | |A| |C| | | +-----+
| | |g| |o| | | | |
| +-------------+ | |g| |n| +-------------+ | | --| GW |
| | | | |r| |s| | | | | +-----+
| | TRIP | | |e| |o| | | | +---
| | LS <----------|g<--|l<--- TGREP |-++-| +-----+
| | | | |a| |i| | Session | | | | |
| | (I-TRIP/ | | |t| |d| | Management |-++-+----| GW |
| | E-TRIP) | | |i| |a| | | | | +-----+
| | (LS-Egress) | | |o| |t| | |-+ +---
| +-------------+ | |n| |i| +-------------+ | | +-----+
| | | | |o| | | --| |
| | | | |n| (LS-Ingress) | | | GW |
| | +-+ +-+ | | +-----+
| | TGREP Receiver | |
| +-------------------------------+ |
| |
| |
+-------------------------------------------------------+
LS/Proxy
Figure 7: 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 (LS-Ingress) 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 LS-Egress entity. The motivation for this operation should be to
skipping to change at page 25, line 13 skipping to change at page 24, line 28
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 constituent routes into a single route for destination "SIP these constituent routes into a single route for destination "SIP
408" with its Carrier attribute being a union of the the Carrier 408" with its Carrier attribute being a union of the Carrier
attribute values of the individual routes, namely, "C1 C2". This attribute values of the individual routes, namely, "C1 C2". This
operation is referred to as Consolidation. In the above example, operation is referred to as Consolidation. In the above example,
it is possible that a route to the destination "SIP 408" through it is possible that a route to the destination "SIP 408" through
one or more carriers may have been lost if the individual routes one or more carriers may have been lost if the individual routes
were not consolidated. were not consolidated.
Another example is to consolidate the Prefix attribute from Another example is to consolidate the Prefix attribute from
multiple Carrier or Trunkgroup updates received from different multiple Carrier or Trunkgroup updates received from different
gateways for the same destination. Let us say, there are Carrier gateways for the same destination. Let us say, there are Carrier
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} from the other. The prefix values from these two updates can 973} from the other. The prefix values from these two updates can
be consolidated into a single Carrier AF route advertisement with be consolidated into a single Carrier AF route advertisement with
prefix value {408, 650, 919, 973}. prefix 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 specifics of applying the consolidation operation to The specifics of applying the consolidation operation to
different attributes and routes from different address families, different attributes and routes from different address families,
is left to the individual TGREP receiver implementations. is left to the 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, that are in a consolidated form or
otherwise, may be aggregated before importing it to the LS instance otherwise, may be aggregated before importing it to the LS instance
that is responsible for I-TRIP/E-TRIP processing (LS-Egress). This which is responsible for I-TRIP/E-TRIP processing (LS-Egress). 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 the TRIP [2], while adhering to the aggregation rules for each route
attribute. attribute.
7.3. Consolidation v/s Aggregation 7.3. Consolidation v/s 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
(Eg: 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 the TRIP.
8. Security Considerations 8. Security Considerations
skipping to change at page 26, line 43 skipping to change at page 26, line 6
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 5 of [7], which defines a the ESP header SHALL comply with section 3.1.1 of [13], which defines
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 5 of [6], which defines a minimum set of algorithms for section 3.2 of [13], which defines a minimum set of algorithms for
integrity checking using manual keys. integrity checking.
Implementations SHOULD use IKE [8] to permit more robust keying Implementations SHOULD use IKEv2 [7] to permit more robust keying
options. Implementations employing IKE SHOULD support authentication options. Implementations employing IKEv2 SHOULD support 3DES-CBC for
with RSA signatures and RSA public key encryption. 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 a 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
skipping to change at page 27, line 33 skipping to change at page 26, line 44
| Code Attribute Reference | Code Attribute Reference
| ---- --------- --------- | ---- --------- ---------
| 13 TotalCircuitCapacity [RFCXXXX] | 13 TotalCircuitCapacity [RFCXXXX]
| 14 AvailableCircuits [RFCXXXX] | 14 AvailableCircuits [RFCXXXX]
| 15 CallSuccess [RFCXXXX] | 15 CallSuccess [RFCXXXX]
| 16 E.164 Prefix [RFCXXXX] | 16 E.164 Prefix [RFCXXXX]
| 17 Pentadecimal Routing Number Prefix [RFCXXXX] | 17 Pentadecimal Routing Number Prefix [RFCXXXX]
| 18 Decimal Routing Number Prefix [RFCXXXX] | 18 Decimal Routing Number Prefix [RFCXXXX]
| 19 TrunkGroup [RFCXXXX] | 19 TrunkGroup [RFCXXXX]
| 19 Carrier [RFCXXXX] | 19 Carrier [5]
[NOTE TO RFC-ED: please replace XXXX with the rfc number of this [NOTE TO RFC-ED: please replace XXXX with the rfc number of this
specification ] specification ]
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 to be assigned for the two
new address families introduced in this document new address families introduced in this document
9.2.1. TrunkGroup Address Family 9.2.1. TrunkGroup Address Family
skipping to change at page 30, line 43 skipping to change at page 30, line 22
12.1. Normative References 12.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] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over
IP (TRIP)," Request for Comments 3219, Internet Engineering Task IP (TRIP)," Request for Comments 3219, Internet Engineering Task
Force, January 2002. Force, January 2002.
[3] Kent, S. and R. Atkinson, "Security Architecture for the [3] Kent, S. and Seo K., "Security Architecture for the Internet
Internet Protocol", RFC 2401, November 1998. Protocol", RFC 4301, December 2005.
[4] V. Gurbani and C. Jennings, "Representing trunk groups in tel/sip [4] V. Gurbani and C. Jennings, "Representing trunk groups in tel/sip
Uniform Resource Identifiers (URIs)," Internet Draft, Internet Uniform Resource Identifiers (URIs)," Internet Draft, Internet
Engineering Task Force, August 2006. Engineering Task Force, August 2006.
[5] J. Yu, "New Parameters for the "tel" URI to Support Number [5] J. Yu, "Number Portability Parameters for the "tel" URI", RFC
Portability," Internet Draft, Internet Engineering Task Force, August 4694, October 2006.
2006.
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [6] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
(ESP)", RFC 2406, November 1998.
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
RFC 2409, November 1998. December 2005.
[9] Crocker, D. and P. Overell, "Augmented BNF for Syntax [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 4234, October 2005.
12.2. Informative References 12.2. Informative References
[10] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [9] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 3261, Internet session initiation protocol," Request for Comments 3261, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[11] J. Rosenberg and H. Schulzrinne, "A framework for telephony [10] J. Rosenberg and H. Schulzrinne, "A framework for telephony
routing over IP," Request for Comments 2871, Internet Engineering routing over IP," Request for Comments 2871, Internet Engineering
Task Force, June 2000. Task Force, June 2000.
[12] ITU-T List of ITU Carrier Codes (published periodically in the [11] ITU-T List of ITU Carrier Codes (published periodically in the
ITU-T Operational Bulletin). ITU-T Operational Bulletin).
[13] J. Rosenberg, "Requirements for Gateway Registration," Internet [12] J. Rosenberg, "Requirements for Gateway Registration," Internet
Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. Draft, Internet Engineering Task Force, Nov. 2001. Work in progress.
[14] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service [13] D. Eastlake, "Cryptographic Algorithm Implementation
location protocol, version 2," Request for Comments 2608, Internet Requirements for Encapsulating Security Payload (ESP) and
Engineering Task Force, June 1999. Authentication Header (AH)", RFC 4305, December 2005.
Authors' Addresses Authors' Addresses
Manjunath Bangalore Manjunath Bangalore
Cisco Systems Inc. Cisco Systems Inc.
Mail Stop SJC-14/2/1 Mail Stop SJC-14/2/1
170 W. Tasman Drive 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 Systems Inc.
Mail Stop SJC-14/4/2 Mail Stop SJC-14/4/2
170 W. Tasman Drive 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 Systems Inc.
Mail Stop PPY02/2 Mail Stop PPY02/2
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany Parsippany
NJ 07054 NJ 07054
Phone: +1-973-952-5060 Phone: +1-973-952-5060
email: jdrosen@cisco.com email: jdrosen@cisco.com
Hussein F. Salama Hussein F. Salama
email: h.f.salama@ieee.org Citex Software Ltd.
4 Dr. Soliman Square
Dokki, Giza 12311
Egypt
Phone: +20-2-33371672/+1-425-7497286
email: h.f.salama@ieee.org
Dhaval N. Shah Dhaval N. Shah
Cisco Systems Inc. Moowee Inc.
Mail Stop SJC-20/3/3 4920 El Camino Real,
170 W. Tasman Drive Los Altos
San Jose, CA 95134 CA 94022
Phone: +1-408-527-0436 Phone: +1-408-307-7455
email: dhaval@cisco.com email: dhaval@moowee.tv
Intellectual Property Statement Intellectual Property Statement
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
skipping to change at page 33, line 29 skipping to change at page 32, line 36
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 ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity 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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 69 change blocks. 
150 lines changed or deleted 132 lines changed or added

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