draft-ietf-iptel-tgrep-06.txt   draft-ietf-iptel-tgrep-07.txt 
IPTEL Working Group Manjunath Bangalore, Cisco Systems Inc. IPTEL Working Group Manjunath Bangalore, Cisco Systems
Internet Draft Rajneesh Kumar, Cisco Systems Inc. Internet Draft Rajneesh Kumar, Cisco Systems
draft-ietf-iptel-tgrep-06.txt Hussein Salama, MenaNet Communications S.A.E. draft-ietf-iptel-tgrep-07.txt Hussein Salama, MenaNet Communications
July 2005 Jonathan Rosenberg, Cisco Systems Inc. February 2006 Jonathan Rosenberg, Cisco Systems
Expiration Date: January 2006 Dhaval N. Shah, Cisco Systems Inc. Expiration Date: August 2006 Dhaval Shah, Cisco Systems
A Telephony Gateway REgistration Protocol (TGREP) A Telephony Gateway REgistration Protocol (TGREP)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 January 16, 2005. This Internet-Draft will expire on August 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes the Telephony Gateway Registration Protocol This document describes the Telephony Gateway Registration Protocol
(TGREP) for registration of telephony prefixes supported by telephony (TGREP) for registration of telephony prefixes supported by telephony
gateways and soft switches. The registration mechanism can also be gateways and soft switches. The registration mechanism can also be
used to export resource information. The prefix and resource used to export resource information. The prefix and resource
information can then be passed on to a 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.
TGREP entities are valid trip implementations, but they do only a
subset of what they otherwise could. In particular, a gateway is
always in Send mode, the LS peering with it is always in Receive
mode.
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
4 TGREP Attributes ......................................... 7 4 TGREP Attributes ......................................... 8
4.1 TotalCircuitCapacity Attribute ........................... 7 4.1 TotalCircuitCapacity Attribute ........................... 9
4.2 AvailableCircuits Attribute .............................. 9 4.2 AvailableCircuits Attribute .............................. 10
4.3 CallSuccess Attribute .................................... 10 4.3 CallSuccess Attribute .................................... 11
4.4 Prefix Attributes ........................................ 12 4.4 Prefix Attributes ........................................ 13
4.5 TrunkGroup Attribute ..................................... 13 4.5 TrunkGroup Attribute ..................................... 14
4.6 Carrier Attribute ........................................ 15 4.6 Carrier Attribute ........................................ 16
4.7 TrunkGroup and Carrier Address Families .................. 16 5 TrunkGroup and Carrier Address Families .................. 17
4.8 Gateway Operation ........................................ 18 5.1 Address Family Syntax .................................... 18
4.9 LS/Proxy Behavior ........................................ 21 6 Gateway Operation ........................................ 20
5 Security Considerations .................................. 25 6.1 Session Establishment .................................... 20
6 IANA Considerations ...................................... 26 6.2 UPDATE Messages .......................................... 20
6.1 Attribute Codes .......................................... 26 6.3 KEEPALIVE Messages ....................................... 20
6.2 Address Family Codes ..................................... 26 6.4 Error Handling and NOTIFICATION Messages ................. 20
7 Change history ........................................... 27 6.5 TGREP Finite State Machine ............................... 21
7.1 Changes since draft-ietf-iptel-tgrep-03.txt .............. 27 6.6 Call Routing Databases ................................... 21
7.2 Changes since draft-ietf-iptel-tgrep-02.txt .............. 27 6.7 Multiple Address Families ................................ 21
7.3 Changes since draft-ietf-iptel-tgrep-01.txt .............. 27 6.8 Route Selection and Aggregation .......................... 21
7.4 Changes since draft-ietf-iptel-tgrep-00.txt .............. 27 7 LS/Proxy Behavior ........................................ 22
7.5 Changes since draft-ietf-iptel-trip-gw-00.txt ............ 28 7.1 Route consolidation ...................................... 24
7.6 Changes since -03 ........................................ 28 7.2 Aggregation .............................................. 25
7.7 Changes since -02 ........................................ 28 7.3 Consolidation v/s Aggregation ............................ 26
7.8 Changes since -01 ........................................ 29 8 Security Considerations .................................. 26
7.9 Changes since -00 ........................................ 29 9 IANA Considerations ...................................... 27
8 Acknowledgments .......................................... 29 9.1 Attribute Codes .......................................... 27
9 References ............................................... 29 9.2 Address Family Codes ..................................... 27
9.1 Normative References ..................................... 29 10 Change history ........................................... 28
9.2 Informative References ................................... 30 10.1 Changes since draft-ietf-iptel-tgrep-03.txt .............. 28
Authors' Addresses ....................................... 30 10.2 Changes since draft-ietf-iptel-tgrep-02.txt .............. 28
Intellectual Property Statement .......................... 31 10.3 Changes since draft-ietf-iptel-tgrep-01.txt .............. 28
Disclaimer of Validity ................................... 32 10.4 Changes since draft-ietf-iptel-tgrep-00.txt .............. 29
Copyright Statement ...................................... 32 10.5 Changes since draft-ietf-iptel-trip-gw-00.txt ............ 29
Acknowledgment ........................................... 32 10.6 Changes since -03 ........................................ 29
10.7 Changes since -02 ........................................ 29
10.8 Changes since -01 ........................................ 30
10.9 Changes since -00 ........................................ 30
11 Acknowledgments .......................................... 30
12 References ............................................... 30
12.1 Normative References ..................................... 30
12.2 Informative References ................................... 31
Authors' Addresses ....................................... 31
Intellectual Property Statement .......................... 33
Disclaimer of Validity ................................... 33
Copyright Statement ...................................... 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
skipping to change at page 4, line 32 skipping to change at page 4, line 36
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 [4]. It is assumed that reader of this has already gone through TRIP [2].
In typical VoIP networks, Internet Telephony Administrative Domains In typical VoIP networks, Internet Telephony Administrative Domains
(ITADs) will deploy numerous gateways for the purposes of (ITADs) will deploy numerous gateways for the purposes of
geographical diversity, capacity, and redundancy. When a call arrives geographical diversity, capacity, and redundancy. When a call arrives
at the domain, it must be routed to one of those gateways. at the domain, it must be routed to one of those gateways.
Frequently, an ITAD will break their network into geographic 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
server is responsible for managing the access to the POP, and also element is a SIP Proxy [10] or H.323 Gatekeeper. The proxy server is
for determining which of the gateways will receive any given call responsible for managing the access to the POP, and also for
that arrives at the POP. In conjunction with the proxy server that determining which of the gateways will receive any given call that
routes the call signaling, there are two TRIP Speaker components, the arrives at the POP. In conjunction with the proxy server that routes
"Ingress LS" and the "Egress LS". The Ingress LS maintains TGREP the call signaling, there are two components, the "Ingress LS"
peering relationship with one or more gateways. The routing (a.k.a. "TGREP Receiver" and the "Egress LS". The "TGREP Receiver"
information received from the gateways are further injected into the component maintains TGREP peering relationship with one or more
Egress LS, which in turn disseminates into the rest of the network on gateways. The routing information received from the gateways are
TRIP. further injected into the Egress LS, which in turn disseminates into
the rest of the network on TRIP.
This configuration is depicted graphically in Figure 1. This configuration is depicted graphically in Figure 1.
Signalling TGREP
-------------> <----------------
+---------+ +---------+
| | | |
| GW | | GW |
> +---------+ > +---------+
// //
// //
// +---------+ SIP // +---------+
// | | <----> // | |
+-------------------------+ // | GW | +-------------------------+ // | GW |
| | // +---------+ | | // +---------+
| +-------------+ |/ | +-------------+ |/
| | | | | | | |
| | Routing | | +---------+ TO PSTN | | Routing | | +---------+ TO PSTN
| | Proxy | | | | | | Proxy | | | |
---> | | |-----------> | GW | -----> ---> | | |-----------> | GW | ----->
|+---+-----+ +-----+----+ | +---------+ |+---+-----+ +-----+----+ | +---------+
|| | | | | || | | | |
|| <+-+ | |-- || <+-+ | |--
||Egress LS| |Ingress LS| | --- +---------+ ||Egress LS| |Ingress LS| | --- +---------+
|| | | | | -- | | || | | | | -- | |
|+---------+ +----------+ | -- | GW | |+---------+ +----------+ | -- | GW |
| | -- +---------+ | | -- +---------+
| | --> | | -->
+-------------------------+ +-------------------------+
+---------+ 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 PSTN destination. For the proxy to
do this adequately, it needs to have access to this information in do this adequately, it needs to have access to this information in
real-time, as it changes. This means there must be some kind of real-time, as it changes. This means there must be some kind of
communications between the proxy and the gateways to convey this communications between the proxy and the gateways to convey this
information. information.
In this document, we specify a protocol for registration of routes The TRIP protocol [2] is defined for carrying telephony routing
(destinations) supported by the gateway to the TRIP Location Server information between providers, for the purposes of getting a call
[4], known as Telephony Gateway REgistration Protocol (TGREP). TGREP routed to the right provider for termination to the PSTN. However,
Protocol can be considered an auxiliary protocol to TRIP. Routes there is no mechanism defined in TRIP that defines how routes get
learnt through TGREP can be injected into and further processed injected into the TRIP protocol from within the network. Nor does it
and/or propagated by the TRIP Location Server. define mechanisms which would allow the provider to select the
specific gateway for terminating a call when it arrives. Those gaps
are filled by TGREP.
TGREP shares a lot of commonality with TRIP in various aspects. TGREP allows PSTN gateways or softswitches to inform a signaling
server, such as a SIP proxy server or H.323 gatekeeper, of routes it
has to the PSTN. These advertisements include fairly dynamic
information, such as the remaining capacity in a particular trunk,
which is essential for selecting the right gateway.
Particularly, TGREP and TRIP have the same session establishment TGREP is identical in syntax and overall operation to TRIP. However,
procedures, state machine, etc. TGREP also makes use of a similar it differs in the route processing rules followed by the TGREP
UPDATE message to propagate the routes supported. It uses receiver, allowing for a route processing function called
Notification, Keepalive and OPEN message in the same essence as TRIP. "Consolidation". Consolidation combines multiple routes for the same
TGREP defines few new attributes that are needed to specify certain route destination with different attributes to a single route to
characteristics of gateways, like Available Capacity for a prevent loss of routing information. TGREP also defines a set of new
destination. The document aims at specifying all the attributes attributes, usable by TGREP or TRIP. Finally, TGREP only utilizes a
related to the TGREP session. This document also specifies some new subset of overall TRIP capabilities. Specifically, certain
address families which can be useful in advertising the information attributes are not utilized (as described below), and the TGREP
on the GWs. entities (the sender and receiver) operate in an 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 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 [4]. 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 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 Speaker of TGREP resides on the GW and groups or Carriers. The TGREP sender resides on the GW and gathers
gathers all the information from the GW to relay to the TRIP Location all the information from the GW to relay to the TRIP Location Server.
Server. A TGREP Receiver is defined, which receives this information A TGREP Receiver is defined, which receives this information and
and after certain optional operations like consolidation and after certain optional operations like consolidation and aggregation,
aggregation. (defined in Sections 3.10.1 and 3.10.2) hands over the hands over the reachability information a to TRIP Location Server.
reachability information a to TRIP Location Server. The routing proxy also uses the information to select the gateway for
incoming calls.
The TGREP speaker establishes a session to the TGREP Receiver using "Consolidation" combines multiple routes for the same route
the procedures similar to session establishment in TRIP. The TGREP destination, whereas "Aggregation" combines routes for different
Speaker is however, in "Send only" mode and the receiver is in the route destinations that qualify as candidate routes to be summarized
"Receive only" mode. After the session establishment the TGREP resulting in route information reduction. To take an example, if
speaker sends the reachibility information in the UPDATE messages. there are multiple gateways offering routes to an E.164 destination
The UPDATE messages have the same format as in TRIP. However, certain "408" but with possibly different attributes (Eg: Carrier), the
TRIP attributes are not relevant in TGREP; a TGREP speaker MAY ignore LS/Proxy can combine these to form one route for "408" but
them if they are present in a TGREP message. The following TRIP representing the attribute information collectively. This process is
attributes do not apply to TGREP: Consolidation.
If, for example, the LS/Proxy receives routes for 4080, 4081, 4082,
... 4089 from amongst a set of gateways, it could aggregate these
different candidate routes to have a summarized route destination
"408" with each of the attributes computed using the Aggregation
procedures defined in the TRIP.
The TGREP Sender establishes a session to the TGREP Receiver using
the procedures similar to session establishment in TRIP. After the
session establishment the TGREP Sender sends the reachibility
information in the UPDATE messages. The UPDATE messages have the same
format as in TRIP. However, certain TRIP attributes are not relevant
in TGREP; a TGREP Receiver MAY ignore them if they are present in a
TGREP message. The following TRIP attributes do not apply to TGREP:
1. AdvertisementPath 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.
1. TotalCircuitCapacity - TotalCircuitCapacity: This attribute identifies the total number
2. AvailableCircuits of PSTN circuits that are available on a route to complete calls.
3. CallSuccess - AvailableCircuits: This attribute identifies the number of PSTN
4. Prefix (E164) circuits that are currently available on a route to complete
5. Prefix (Decimal Routing Number) calls.
6. Prefix (Hexadecimal Routing Number) - CallSuccess: This attribute represents information about the
7. TrunkGroup number of normally terminated calls out of a total number of
8. Carrier attempted calls.
- Prefix (E164): This attribute is used to represent the list of
E164 prefixes that the respective route can complete calls to.
- Prefix (Decimal Routing Number): This attribute is used to
represent the list of Decimal prefixes that the respective route
can complete calls to.
- Prefix (Hexadecimal Routing Number): This attribute is used to
represent the list of Hexadecimal prefixes that the respective
route can complete calls to.
- TrunkGroup: This attribute enables providers to route calls to
destinations through preferred trunks.
- Carrier: This attribute enables providers to route calls to
destinations through preferred carriers.
In the rest of the document we specify attributes and address In the rest of the document we specify attributes and address
families used in TGREP. We also specify the operations of families used in TGREP. The new attributes and Address families
consolidation and aggregation as they apply to the UPDATEs received introduced are also applicable for general usage in TRIP except
from the TGREP Gateway by the TGREP Receiver. where noted (AvailableCircuits attribute for example)
4. TGREP Attributes 4. TGREP Attributes
Due to its usage within a service provider network, TGREP makes use
of a subset of the attributes defined for TRIP, in addition to
defining several new ones. In particular, the following attributes
from TRIP are applicable to TGREP:
1. WithdrawnRoutes 2. ReachableRoutes 3. NexthopServer 4. Prefix 5.
Communities
TGREP also defines several new attributes, described in this section.
These are TotalCircuitCapacity, AvailableCircuits, CallSuccess,
TrunkGroup and Carrier. As mentioned above, these new attributes are
usable by TRIP unless noted otherwise.
A TGREP UPDATE supports the following attributes: A TGREP UPDATE supports the following attributes:
1. WithdrawnRoutes (as defined in TRIP) 1. TotalCircuitCapacity
2. ReachableRoutes (as defined in TRIP) 2. AvailableCircuits
3. NexthopServer (as defined in TRIP) 3. CallSuccess
4. TotalCircuitCapacity 4. Prefix (E.164, Pentadecimal routing number, Decimal routing
5. AvailableCircuits number)
6. CallSuccess 5. TrunkGroup
7. Prefix (E.164, Pentadecimal routing number, Decimal routing number) 6. Carrier
8. TrunkGroup
9. Carrier
10. Communities
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 identifies the total number of PSTN circuits
that are available on a route to complete calls. It is used in that are available on a route to complete calls. It is used in
skipping to change at page 12, line 16 skipping to change at page 13, line 20
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 number prefix TRIP Type Codes: 16 for E164 prefix, 17 for Pentadecimal routing
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 that
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 Though it is possible that all prefix ranges may be reachable through
through a given Carrier, administrative issues could make certain a given Carrier, administrative issues could make certain ranges
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 [4]), 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.
1 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 . . . 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-------------------------------+-----------+------------------------
+-------------------------------+-----------+----------------------------------+----------- | 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.
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.
skipping to change at page 14, line 9 skipping to change at page 15, line 22
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 [10] is per rules group context sub-fields and the associated ABNF [9] is per rules
outlined in [13]. 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
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.
skipping to change at page 15, line 29 skipping to change at page 16, line 43
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.
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 [10] is per rules outlined in [15]. Specifically, it carries ABNF [9] is per rules outlined in [5]. Specifically, it carries
"global-cic" or "local-cic"[15]. 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
The Carrier attribute MAY be used for route selection. Certain The Carrier attribute MAY be used for route selection. Certain
carriers MAY be preferred over others based on provider policy. carriers MAY be preferred over others based on provider policy.
skipping to change at page 16, line 26 skipping to change at page 17, line 37
Routes with differing Carrier attribute MUST NOT be aggregated. Routes with differing Carrier attribute 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.
4.7. TrunkGroup and Carrier Address Families 5. TrunkGroup and Carrier Address Families
As described in TRIP [4], 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
When a set of GWs are to managed at the granularity of carriers or
trunkgroups then it may be more appropriate for a GW to advertise trunkgroups then it may be more appropriate for a GW to advertise
routes using the Carrier address family or trunkgroup address family routes using the Carrier address family or trunkgroup address family
respectively. Also, in a TGREP association between the gateway and respectively. Also, in a TGREP association between the gateway and
the LS responsible for managing that gateway, there are some the LS responsible for managing that gateway, there are some
attributes that more naturally fit in as advertised properties of attributes that more naturally fit in as advertised properties of
trunkgroups or carriers rather than that of advertised prefixes; for trunkgroups or carriers rather than that of advertised prefixes; for
example, the AvailableCircuit information on a particular trunkgroup example, the AvailableCircuit information on a particular trunkgroup
or a particular carrier. To express this relationship, the existing or a particular carrier. To express this relationship, the existing
TRIP address families are inadequate. We need separate address TRIP address families are inadequate. We need separate address
families that can associate certain properties like AvailableCircuits families that can associate certain properties like AvailableCircuits
skipping to change at page 17, line 19 skipping to change at page 18, line 31
- 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 - Gateways can get really large with the ability to provision
hundreds or a few thousand circuits and this can increase the hundreds or a few thousand circuits and this can increase the
potential for traffic that reports dynamic resource information potential for traffic that reports dynamic resource information
between the gateway and the LS. The model introduced can between the gateway and the LS. The model introduced can
potentially alleviate this UPDATE traffic hence increasing potentially alleviate this UPDATE traffic hence increasing
efficiency and providing a scalable gateway registration model. efficiency and providing a scalable gateway registration model.
4.7.1. Address Family Syntax 5.1. Address Family Syntax
Consider the generic TRIP route format from TRIP[4] 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 XX [[NOTE TO RFC-ED: The code for the trunk group address family is 4 and the code for the
Please replace XX with the IANA assigned value for the trunk group carrier address family is 5.
address family]] and the code for the carrier address family is XXX
[[NOTE TO RFC-ED: Please replace XX with the IANA assigned value for
the carrier address family]].
The Application Protocol field is same as the one for the Decimal, The Application Protocol field is same as the one for the Decimal,
PentaDecimal and E.164 address families defined in TRIP[4]. The PentaDecimal and E.164 address families defined in TRIP[2]. The
Length field represents the total size of the Address field in bytes. 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 Trunkgroup value that is defined as specified in an earlier Section
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 that is defined as specified in an Carrier value. This is 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.
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
skipping to change at page 18, line 36 skipping to change at page 19, line 47
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.
4.8. 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 TGREP 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, the
gateway will not create its own call routing database. In this 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.
4.8.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 speaker. 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 which includes a Send Receive
Capability in the Optional Parameters. The Send Receive Capability is Capability in the Optional Parameters. The Send Receive Capability is
set by the gateway to Send Only. The OPEN message also contains the set by the gateway to Send Only. The OPEN message also contains the
address families supported by the gateway. The remainder of the peer address families supported by the gateway. The remainder of the peer
session establishment is identical to TRIP. session establishment is identical to TRIP.
4.8.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.
If the gateway's reachability changes at any point in time, the TGREP processing of the UPDATE message at the gateway is identical to
gateway MUST generate UPDATE message(s) with the change. The UPDATE processing in TRIP[2]. A TGREP sender MUST support all
frequency of successive UPDATE messages MUST follow the same rules mandatory TRIP attributes.
specified for TRIP[4]. The TGREP gateway MUST support all mandatory
TRIP attributes.
If the gateway receives an UPDATE message from the TRIP LS, it MUST
silently discard it as specified for TRIP[4]. No further action
should be taken.
4.8.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 [4]. Section 4.4 of TRIP [2].
4.8.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.
4.8.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.
4.8.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 LSs. A TGREP gateway maintains one call routing database per
peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out, peer TRIP LS. These databases are equivalent to TRIP's Adj-TRIBs-Out,
and hence we will call them Adj-TRIB-GWs-Out. An Adj-TRIB-GW-Out and hence we will call them Adj-TRIB-GWs-Out. An Adj-TRIB-GW-Out
contains the gateway's reachability information advertised to its contains the gateway's reachability information advertised to its
peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is peer TRIP LS. How an Adj-TRIB-GW-Out database gets populated is
outside the scope of this draft (possibly by manual configuration). outside the scope of this draft (possibly by manual configuration).
The TGREP gateway does not have databases equivalent to TRIP's Adj- The TGREP gateway does not have databases equivalent to TRIP's Adj-
TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn TRIBs-In and Loc-TRIB, because the TGREP gateway does not learn
routes from its peer TRIP LSs, and hence it does not run call route routes from its peer TRIP LSs, and hence it does not run call route
selection. selection.
4.8.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 reachabilty 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 it's choice address family
through the route-type capability in the OPEN message. And route-type through the route-type capability in the OPEN message. And route-type
specification in the OPEN message violating the above rule should be specification in the OPEN message violating the above rule should be
rejected with a NOTIFICATION message. rejected with a NOTIFICATION message.
4.8.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.
4.9. 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 that 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 [4]. 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 TRIP LS component operating in receive mode, server, is also a second component operating in receive mode, that
that peers with one more gateways, each of them using TGREP to peers with one more gateways, each of them using TGREP to advertise
advertise routing information. This TRIP LS component on the routing information. This component on the receiving end of one or
receiving end of one or more TGREP sessions is termed as the "LS- more TGREP sessions is termed as the "LS-Ingress" or "TGREP Receiver"
Ingress" or "TGREP Receiver" for the purposes of this discussion. The for the purposes of this discussion. Also, the entity (typically, a
LS-Ingress receiving the TRIP messages takes the resulting routing Gateway) advertising the routes on the TGREP session is termed as the
information from each gateway, and "exports" it to another process we "TGREP Sender". The "TGREP Receiver" receiving the TRIP messages
are defining that performs consolidation and aggregation, in that takes the resulting routing information from each gateway, and
order. These operations would take as input the collective set of "exports" it to another process we define below, that performs
routes from all the gateways. Subsequently, the resulting TRIB is consolidation and aggregation, in that order. These operations would
passed as input into the LS-Egress process as shown below, that can take as input the collective set of routes from all the gateways.
then disseminate these via TRIP. The interface between the LS-Ingress Subsequently, the resulting TRIB is passed as input into the LS-
Egress process as shown below, that can then disseminate these via
TRIP. The interface between the TGREP Receiver(aka. 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 7 below.
+-------------------------------------------------------+ +-------------------------------------------------------+
| +-------------------------------+ | | +-------------------------------+ |
| | +-+ +-+ | | | | +-+ +-+ | | TGREP
| | |A| |C| | | +-----+ | | |A| |C| | | +-----+
| | |g| |o| | | TGREP | | | | |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| | |-+ -+- | | (LS-Egress) | | |o| |t| | |-+ +---
| +-----------/-+ | |n| |i| +-------------+ | | --- +-----+ | +-----------/-+ | |n| |i| +-------------+ | | +-----+
| / | | | |o| | | -- | | | / | | | |o| | | -- | |
| / | | | |n| (LS-Ingress) | | | GW | | / | | | |n| (LS-Ingress) | | | GW |
| / | +-+ +-+ | | +-----+ | / | +-+ +-+ | | +-----+
| / | TGREP Receiver | | | / | TGREP Receiver | |
| / +-------------------------------+ | | / +-------------------------------+ |
| / | | / |
| / | | / |
+-------/-----------------------------------------------+ +-------/-----------------------------------------------+
/ LS/Proxy / LS/Proxy
/ /
skipping to change at page 22, 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| | | | +---
| \ +-------------------------------+ |
| \ | +-+ +-+ | |
| \ | |A| |C| | | +-----+
| \ | |g| |o| | | TGREP | |
| +---------\---+ | |g| |n| +-------------+ | | -- | GW |
| | | | |r| |s| | | | | -- +-----+
| | 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| | |-+ -+- | | (LS-Egress) | | |o| |t| | |-+ +---
| +-------------+ | |n| |i| +-------------+ | | --- +-----+ | +-------------+ | |n| |i| +-------------+ | | +-----+
| | | | |o| | | -- | | | | | | |o| | | -- | |
| | | | |n| | | | GW | | | | | |n| (LS-Ingress) | | | GW |
| | +-+ +-+ (LS-Ingress) | | +-----+ | | +-+ +-+ | | +-----+
| | TGREP Receiver | | | | TGREP Receiver | |
| +-------------------------------+ | | +-------------------------------+ |
| | | |
| | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
LS/Proxy LS/Proxy
Figure 7: LS Architecture for TRIP-GW Figure 7: LS Architecture for TRIP-GW
4.9.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
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.
skipping to change at page 24, line 33 skipping to change at page 25, line 36
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.
4.9.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 that 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 [4], while adhering to the aggregation rules for each route the TRIP [2], while adhering to the aggregation rules for each route
attribute. attribute.
4.9.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 (Eg: 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.
5. Security Considerations 8. Security Considerations
The Security considerations defined in the TRIP [4] apply to TGREP The Security considerations for TGREP are identical to that
sessions between Gateways and TGREP Receivers (TRIP LS). identified in TRIP [2] and are just restated here for the purposes of
clarity.
The security mechanism for the peering session between TGREP GW and a The security mechanism for the peering session between TGREP GW and a
TRIP LS, in an IP network, is IPsec [6]. 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) [7] and provide traffic security: Authentication Header (AH) [6] and
Encapsulating Security Payload (ESP) [8]. 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 [8], which defines a the ESP header SHALL comply with section 5 of [7], which defines a
minimum set of algorithms for integrity checking and encryption. 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 [7], which defines a minimum set of algorithms for section 5 of [6], which defines a minimum set of algorithms for
integrity checking using manual keys. integrity checking using manual keys.
Implementations SHOULD use IKE [9] to permit more robust keying Implementations SHOULD use IKE [8] to permit more robust keying
options. Implementations employing IKE SHOULD support authentication options. Implementations employing IKE SHOULD support authentication
with RSA signatures and RSA public key encryption. with RSA signatures and RSA public key encryption.
A Security Association (SA) [6] 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 [12]. 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.
6. IANA Considerations 9. IANA Considerations
Both TRIP[4] and TGREP share the same IANA registry for Capabilities, Both TRIP[2] and TGREP share the same IANA registry for Capabilities,
Attributes, Address Families, and Application Protocols. Attributes, Address Families, and Application Protocols. This
specification requests that IANA add the following attribute codes
and address family codes to the TRIP [2] registries.
6.1. Attribute Codes 9.1. Attribute Codes
The Attribute Type Codes to be assigned for the new attributes The Attribute Type Codes to be assigned for the new attributes
defined in this document are listed below: defined in this document are listed below:
| 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 [RFCXXXX]
[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 ]
6.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
6.2.1. TrunkGroup Address Family 9.2.1. TrunkGroup Address Family
| Code Address Family Reference | Code Address Family Reference
| ---- -------------- --------- | ---- -------------- ---------
| 4 TrunkGroup [RFCXXXX] | 4 TrunkGroup [RFCXXXX]
[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 ]
6.2.2. Carrier Address Family 9.2.2. Carrier Address Family
| Code Address Family Reference | Code Address Family Reference
| ---- -------------- --------- | ---- -------------- ---------
| 5 Carrier [RFCXXXX] | 5 Carrier [RFCXXXX]
[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 ]
7. Change history 10. Change history
[[NOTE TO RFC-ED: Please remove this section prior to publication]] [[NOTE TO RFC-ED: Please remove this section prior to publication]]
7.1. Changes since draft-ietf-iptel-tgrep-03.txt 10.1. Changes since draft-ietf-iptel-tgrep-03.txt
- No change in content. Releasing a new revision for renewal of - No change in content. Releasing a new revision for renewal of
draft. draft.
7.2. Changes since draft-ietf-iptel-tgrep-02.txt 10.2. Changes since draft-ietf-iptel-tgrep-02.txt
- No change in content. Releasing a new revision for renewal of - No change in content. Releasing a new revision for renewal of
draft. draft.
7.3. Changes since draft-ietf-iptel-tgrep-01.txt 10.3. Changes since draft-ietf-iptel-tgrep-01.txt
- Added a "Security Considerations" Section to the document. - Added a "Security Considerations" Section to the document.
- Strengthened the text under "LS/Proxy Behavior" regarding - Strengthened the text under "LS/Proxy Behavior" regarding
Consolidation and Aggregation with additional examples for better Consolidation and Aggregation with additional examples for better
clarity. clarity.
- Removed the section "Other Attributes" including its subsection - Removed the section "Other Attributes" including its subsection
on the "Pricing" attribute. on the "Pricing" attribute.
- Modified the definition of Carrier in the "Carrier attribute" and - Modified the definition of Carrier in the "Carrier attribute" and
"TrunkGroup and Carrier Address Families" sections respectively. "TrunkGroup and Carrier Address Families" sections respectively.
Pz - Rectified the section number references in the "IANA - Rectified the section number references in the "IANA
Considerations" Section. Considerations" Section.
- Strengthened the text in the attribute sections regarding - Strengthened the text in the attribute sections regarding
dissemination of attributes received on TGREP. dissemination of attributes received on TGREP.
- Updated the "References" section. - Updated the "References" section.
- Corrected typos, nits, grammatical errors, and language of the - Corrected typos, nits, grammatical errors, and language of the
text throughout the document based on feedback from the iptel text throughout the document based on feedback from the iptel
community. community.
7.4. Changes since draft-ietf-iptel-tgrep-00.txt 10.4. Changes since draft-ietf-iptel-tgrep-00.txt
- Added recommendations for AvailableCircuits and CallSuccess - Added recommendations for AvailableCircuits and CallSuccess
attributes. attributes.
- Updated Carrier Attribute with ASCII syntax. - Updated Carrier Attribute with ASCII syntax.
- Removed thresholding scheme description. - Removed thresholding scheme description.
- Updated author addresses. - Updated author addresses.
7.5. Changes since draft-ietf-iptel-trip-gw-00.txt 10.5. Changes since draft-ietf-iptel-trip-gw-00.txt
- Changed title of the document to TGREP (Telephony Gateway - Changed title of the document to TGREP (Telephony Gateway
REgistration Protocol). REgistration Protocol).
- Changed name of protocol described in this document to TGREP. - Changed name of protocol described in this document to TGREP.
- Changed Abstract and Introduction sections to position TGREP as - Changed Abstract and Introduction sections to position TGREP as
an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP). an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP).
- Modified the section on LS/Proxy Behavior including the diagram. - Modified the section on LS/Proxy Behavior including the diagram.
- Added an additional example to the Route Consolidation section. - Added an additional example to the Route Consolidation section.
- Changed the format of Carrier (both as an attribute and as an AF) - Changed the format of Carrier (both as an attribute and as an AF)
to accommodate representation of Country codes in association to accommodate representation of Country codes in association
with CICs. with CICs.
- Updated text to allow Carrier attribute in TrunkGroup address - Updated text to allow Carrier attribute in TrunkGroup address
family and TrunkGroup attribute in Carrier address family. family and TrunkGroup attribute in Carrier address family.
7.6. Changes since -03 10.6. Changes since -03
- Removed Carrier-Trunkgroup attribute and address family and - Removed Carrier-Trunkgroup attribute and address family and
references to it. references to it.
- Added Terminology and Definitions section. - Added Terminology and Definitions section.
- Updated CallSuccess attribute. - Updated CallSuccess attribute.
- Added Prefix attribute. - Added Prefix attribute.
- Added Carrier attribute. - Added Carrier attribute.
- Added TrunkGroup attribute. - Added TrunkGroup attribute.
- Added TrunkGroup Address Family. - Added TrunkGroup Address Family.
- Added Carrier Address Family. - Added Carrier Address Family.
- Added some more references. - Added some more references.
7.7. Changes since -02 10.7. Changes since -02
- Removed the requirements section. - Removed the requirements section.
- Discussed the motivation for introducing Carrier information into - Discussed the motivation for introducing Carrier information into
TRIP. TRIP.
- Defined a new attribute for the E.164 address family. - Defined a new attribute for the E.164 address family.
- Defined a new address family for CarrierCode-TrunkGroup - Defined a new address family for CarrierCode-TrunkGroup
combination . combination .
- Defined new attributes to advertise dynamic gateway - Defined new attributes to advertise dynamic gateway
characteristics like resource availability, and call success characteristics like resource availability, and call success
rate. rate.
- Added as section to validate the TGREP solution against the - Added as section to validate the TGREP solution against the
requirements in [7]. requirements in [6].
7.8. Changes since -01 10.8. Changes since -01
- Added requirements. - Added requirements.
- Added more formal analysis of REGISTER and added analysis of SLP. - Added more formal analysis of REGISTER and added analysis of SLP.
- Removed circuit capacity attribute. - Removed circuit capacity attribute.
7.9. Changes since -00 10.9. Changes since -00
- Added text to stress the value of this proposal for managing a - Added text to stress the value of this proposal for managing a
gateway cluster. gateway cluster.
- Added attributes for circuit capacity and DSP capacity. - Added attributes for circuit capacity and DSP capacity.
- Added section on LS operation, discussing aggregation issue. - Added section on LS operation, discussing aggregation issue.
8. Acknowledgments 11. 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.
9. References 12. References
9.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] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [2] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over
session initiation protocol," Request for Comments 3261, Internet
Engineering Task Force, Mar. 1999.
[3] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service
location protocol, version 2," Request for Comments 2608, Internet
Engineering Task Force, June 1999.
[4] J. Rosenberg, H. Salama, and M. Squire, "Telephony routing over
IP (TRIP)," Request for Comments 3219, Internet Engineering Task IP (TRIP)," Request for Comments 3219, Internet Engineering Task
Force, January 2002. Force, January 2002.
[5] J. Rosenberg and H. Schulzrinne, "A framework for telephony [3] Kent, S. and R. Atkinson, "Security Architecture for the
routing over IP," Request for Comments 2871, Internet Engineering
Task Force, June 2000.
[6] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[7] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [4] V. Gurbani and C. Jennings, "Representing trunk groups in tel/sip
Uniform Resource Identifiers (URIs)," Internet Draft, Internet
Engineering Task Force, August 2006.
[5] J. Yu, "New Parameters for the "tel" URI to Support Number
Portability," Internet Draft, Internet Engineering Task Force, August
2006.
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998. November 1998.
[8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998. (ESP)", RFC 2406, November 1998.
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
9.2. Informative References 12.2. Informative References
[11] ITU-T List of ITU Carrier Codes (published periodically in the [10] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
ITU-T Operational Bulletin). session initiation protocol," Request for Comments 3261, Internet
Engineering Task Force, Mar. 1999.
[12] J. Peterson, "An Architecture for Gateway Registration Based on [11] J. Rosenberg and H. Schulzrinne, "A framework for telephony
Trunk Groups," Internet Draft, Internet Engineering Task Force, Feb. routing over IP," Request for Comments 2871, Internet Engineering
2002. Work in progress. Task Force, June 2000.
[13] V. Gurbani and C. Jennings, "Representing trunk groups in [12] ITU-T List of ITU Carrier Codes (published periodically in the
tel/sip Uniform Resource Identifiers (URIs)," Internet Draft, ITU-T Operational Bulletin).
Internet Engineering Task Force, May 2005.
[14] J. Rosenberg, "Requirements for Gateway Registration," Internet [13] 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.
[15] J. Yu, "New Parameters for the "tel" URI to Support Number [14] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service
Portability," Internet Draft, Internet Engineering Task Force, July location protocol, version 2," Request for Comments 2608, Internet
2005. Engineering Task Force, June 1999.
Authors' Addresses Authors' Addresses
Manjunath Bangalore Manjunath Bangalore
Cisco Systems Inc. Cisco Systems Inc.
Mail Stop SJC-21/2/2 Mail Stop SJC-21/2/2
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
Phone: +1-408-853-3239 Phone: +1-408-902-3239
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 170 W. Tasman Drive
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.
skipping to change at page 32, line 32 skipping to change at page 33, line 41
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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 Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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. 120 change blocks. 
294 lines changed or deleted 334 lines changed or added

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