draft-ietf-iptel-tgrep-00.txt   draft-ietf-iptel-tgrep-01.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-00.txt Jonathan Rosenberg, dynamicsoft draft-ietf-iptel-tgrep-01.txt Jonathan Rosenberg, dynamicsoft
October 2002 Hussein Salama, Cisco Systems October 2002 Hussein Salama, Cisco Systems
Expiration Date: April 2003 Dhaval N. Shah, Cisco Systems Expiration Date: August 2003 Dhaval N. Shah, Cisco Systems
A Telephony Gateway REgistration Protocol (TGREP) A Telephony Gateway REgistration Protocol (TGREP)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 7, line 24 skipping to change at page 7, line 24
3.2.1. AvailableCircuits Syntax 3.2.1. AvailableCircuits Syntax
The AvailableCircuits attribute is a 4-octet unsigned numeric value. The AvailableCircuits attribute is a 4-octet unsigned numeric value.
It represents the number of circuits remaining for terminating calls It represents the number of circuits remaining for terminating calls
to this route. to this route.
3.2.2. Route Origination and AvailableCircuits 3.2.2. Route Origination and AvailableCircuits
Routes MAY be originated containing the AvailableCircuits attribute. Routes MAY be originated containing the AvailableCircuits attribute.
Since this attribute is highly dynamic, changing with every call, Since this attribute is highly dynamic, changing with every call,
updates MAY be sent as it changes. However, it is RECOMMENDED that a updates MAY be sent as it changes. However, it is RECOMMENDED that
gateway originating routes with this attribute use thresholds, and measures be taken to help reduce the messaging load from route
that routes are re-originated only when the attribute moves above or origination. It is further RECOMMENDED that sufficiently large
below a threshold. It is also RECOMMENDED that the thresholds in each windows be used to provide a useful aggregated statistic.
direction (going above a threshold and going below a threshold) be
different, thus achieving a form of hysterisis. Both of these
measures help reduce the messaging load from route origination.
3.2.3. Route Selection and AvailableCircuits 3.2.3. Route Selection and AvailableCircuits
The AvailableCircuits attribute MAY be used for route selection. The AvailableCircuits attribute MAY be used for route selection.
Since one of its primary applications is load balancing, an LS will Since one of its primary applications is load balancing, an LS will
wish to choose a potentially different route (amongst a set of routes wish to choose a potentially different route (amongst a set of routes
for the same prefix) on a call by call basis. This can be modeled as for the same prefix) on a call by call basis. This can be modeled as
re-running the decision process on the arrival of each call. The re-running the decision process on the arrival of each call. The
aggregation and dissemination rules for routes with this attribute aggregation and dissemination rules for routes with this attribute
ensure that re-running this selection process never results in ensure that re-running this selection process never results in
skipping to change at page 9, line 10 skipping to change at page 9, line 10
represented as an unsigned 4-octet numeric value. The first represented as an unsigned 4-octet numeric value. The first
component field represents the total number of calls terminated component field represents the total number of calls terminated
normally for the advertised destination on a given address family. normally for the advertised destination on a given address family.
The second component field represents the total number of attempted The second component field represents the total number of attempted
calls for the advertised destination. calls for the advertised destination.
3.3.2. Route Origination and CallSuccess 3.3.2. Route Origination and CallSuccess
Routes MAY be originated containing the CallSuccess attribute. This Routes MAY be originated containing the CallSuccess attribute. This
attribute is expected to get statistically significant with passage attribute is expected to get statistically significant with passage
of time as more calls are attempted. Therefore, it is RECOMMENDED of time as more calls are attempted. It is RECOMMENDED that
that the gateway make a choice based on local thresholds to determine sufficiently large windows be used to provide a useful aggregated
when to report this attribute in an UPDATE. statistic.
3.3.3. Route Selection and CallSuccess 3.3.3. Route Selection and CallSuccess
The CallSuccess attribute MAY be used for route selection. This The CallSuccess attribute MAY be used for route selection. This
attribute represents a measure of success of terminating calls to the attribute represents a measure of success of terminating calls to the
advertised destination(s). This information MAY be used to select advertised destination(s). This information MAY be used to select
from amongst a set of alternative routes to increase the probability from amongst a set of alternative routes to increase the probability
of successful call termination. of successful call termination.
3.3.4. Aggregation and CallSuccess 3.3.4. Aggregation and CallSuccess
skipping to change at page 12, line 47 skipping to change at page 12, line 47
calls to destinations through preferred carriers. This attribute is calls to destinations through preferred carriers. This attribute is
relatively static. relatively static.
3.6.1. Carrier Syntax 3.6.1. Carrier Syntax
The Carrier attribute is a variable length attribute that is composed The Carrier attribute is a variable length attribute that is composed
of a sequence of carrier values. It indicates that the route can of a sequence of carrier values. It indicates that the route can
complete the call to any of the carriers represented in the sequence complete the call to any of the carriers represented in the sequence
of carrier values. of carrier values.
Each carrier value has two fields, a 2-octet CountryCode, and a 2- Each carrier value has two ASCII fields, a 3-octet CountryCode, and a 4-
octet CarrierIdCode. The CountryCode field represents the country octet CarrierIdCode. The CountryCode field represents the country
that corresponds to the Carrier identified by CarrierIdCode. It is that corresponds to the Carrier identified by CarrierIdCode. It is
the same as the E.164 country code used to dial internal telephony the same as the E.164 country code used to dial internal telephony
destinations. The CarrierIdCode or CIC represents a unique code destinations. The CarrierIdCode or CIC represents a unique code
assigned to the Carrier or Telephony service provider offering the assigned to the Carrier or Telephony service provider offering the
service by an administrative body operating in that region. service by an administrative body operating in that region.
The presence of Carrier Attribute with the length field of the The presence of Carrier Attribute with the length field of the
attribute as 0 signifies that the TGREP GW can terminate ALL Carriers attribute as 0 signifies that the TGREP GW can terminate ALL Carriers
for the given Reachable route(s). for the given Reachable route(s).
0 1 2 3 0 1 2 3 5
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 2 3 0 1 2 3 4 5 6 7 8 9 0 .... 0 1 2 3 4 5 6 7 8 9 0 1 2 3 .... 0 1 2 3 4 5
+--------------------------------+-------------------------------+----- +----------------------------------+------------------------------------+-----
| CountryCode | CarrierIdCode | ... | CountryCode | CarrierIdCode .... | ....
+--------------------------------+-------------------------------+----- +----------------------------------+------------------------------------+-----
Figure 4: Carrier Syntax Figure 4: Carrier Syntax
3.6.2. Route Origination and Carrier 3.6.2. Route Origination and Carrier
Routes MAY be originated containing the Carrier attribute. Routes MAY be originated containing the Carrier attribute.
3.6.3. Route Selection and Carrier 3.6.3. Route Selection and Carrier
The Carrier attribute MAY be used for route selection. Certain The Carrier attribute MAY be used for route selection. Certain
carriers MAY be preferred over others based on provider policy. carriers MAY be preferred over others based on provider policy.
skipping to change at page 16, line 40 skipping to change at page 16, line 40
gateway operates in TRIP Send Only mode since it is only interested gateway operates in TRIP Send Only mode since it is only interested
in advertising its reachability, but is not interested in learning in advertising its reachability, but is not interested in learning
about the reachability of other gateways and other domains. Also, the about the reachability of other gateways and other domains. Also, the
gateway will not create its own call routing database. Therefore, the gateway will not create its own call routing database. Therefore, the
gateway does not need a complete implementation of TRIP. A gateway does not need a complete implementation of TRIP. A
lightweight version of the protocol is sufficient. In this section we lightweight version of the protocol is sufficient. In this section we
describe the operation of TRIP on a gateway. describe the operation of TRIP on a gateway.
3.9.1. Session Establishment 3.9.1. Session Establishment
When opening a peering session with a TGREP Receiver, a TGREP When opening a peering session with a TGREP Receiver, a TGREP gateway
gateway follows exactly the same procedures as any other TRIP speaker. follows exactly the same procedures as any other TRIP speaker. The
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 address families supported by the gateway. The remainder of the peer
peer session establishment is identical to TRIP. session establishment is identical to TRIP.
3.9.2. UPDATE Messages 3.9.2. UPDATE Messages
Once the peer session has been established, the gateway sends UPDATE Once the peer session has been established, the gateway sends UPDATE
messages to the TRIP LS with the gateway's entire reachability. The messages to the TRIP LS with the gateway's entire reachability. The
Gateway also sends any attributes associated with the routes. Gateway also sends any attributes associated with the routes.
If the gateway's reachability changes at any point in time, the If the gateway's reachability changes at any point in time, the
gateway MUST generate UPDATE message(s) with the change. The gateway MUST generate UPDATE message(s) with the change. The
frequency of successive UPDATE messages MUST follow the same rules frequency of successive UPDATE messages MUST follow the same rules
skipping to change at page 21, line 44 skipping to change at page 21, line 44
from the same gateway, or from multiple gateways. It is RECOMMENDED from the same gateway, or from multiple gateways. It is RECOMMENDED
that the set of gateway routes for each destination be consolidated, that the set of gateway routes for each destination be consolidated,
before presenting a candidate route, to the TRIP LS. The motivation before presenting a candidate route, to the TRIP LS. The motivation
for this operation should be to define a route that can maximally for this operation should be to define a route that can maximally
represent the collective routing capabilities of the set of gateways, represent the collective routing capabilities of the set of gateways,
managed by this TGREP receiver. Let us take an example scenario in managed by this TGREP receiver. Let us take an example scenario in
order to bring out the motivation for this operation. Let us say, order to bring out the motivation for this operation. Let us say,
the TGREP receiver maintains peering sessions with gateways A, and B. the TGREP receiver maintains peering sessions with gateways A, and B.
o Gateway A advertises a route for destination "SIP 408" on the E.164 o Gateway A advertises a route for destination "SIP 408" on the E.164
address family with the Carrier attribute value C1. address
family with the Carrier attribute value C1.
o Gateway B advertises a route for destination "SIP 408" on the E.164 o Gateway B advertises a route for destination "SIP 408" on the E.164
address family with Carrier attribute value C2. address
family with Carrier attribute value C2.
The TGREP receiver that receives these routes can consolidate these The TGREP receiver that receives these routes can consolidate these
constituent routes into a single route for destination "SIP 408" with constituent routes into a single route for destination "SIP 408" with
its Carrier attribute being a union of the the Carrier attribute its Carrier attribute being a union of the the Carrier attribute
values of the individual routes, namely, "C1 C2". This operation is values of the individual routes, namely, "C1 C2". This operation is
refered to as Consolidation. In the above example, it is possible refered to as Consolidation. In the above example, it is possible
that a route to the destination "SIP 408" through one or more that a route to the destination "SIP 408" through one or more
carriers may have been lost if the individual routes were not carriers may have been lost if the individual routes were not
consolidated. consolidated.
skipping to change at page 23, line 5 skipping to change at page 23, line 5
4. IANA Considerations 4. IANA Considerations
- The Attribute Type Codes for the new attributes: - The Attribute Type Codes for the new attributes:
AvailableCircuits, TotalCircuitCapacity, CallSuccess, Prefix, AvailableCircuits, TotalCircuitCapacity, CallSuccess, Prefix,
TrunkGroup and Carrier described in Sections 4.1, 4.2, 4.3, 4.4, TrunkGroup and Carrier described in Sections 4.1, 4.2, 4.3, 4.4,
4.5 and 4.6 above, respectively, are to be assigned by IANA. 4.5 and 4.6 above, respectively, are to be assigned by IANA.
- The Address Family Codes for the new address families: TrunkGroup - The Address Family Codes for the new address families: TrunkGroup
and Carrier described in Section 4.7, are to be assigned by IANA. and Carrier described in Section 4.7, are to be assigned by IANA.
5. Changes since draft-ietf-iptel-trip-gw-00.txt 5. Changes since draft-ietf-iptel-tgrep-00.txt
- Added recommendation for AvailableCircuits and CallSuccess
attributes.
- Updated Carrier Attribute with ASCII syntax.
- Removed thresholding scheme description.
- Updated author addresses.
6. Changes since draft-ietf-iptel-trip-gw-00.txt
- Changed title of the document to TGREP (Telephony Gateway - Changed title of the document to TGREP (Telephony Gateway
REgistration Protocol) REgistration Protocol)
- Changed name of protocol described in this document to TGREP - Changed name of protocol described in this document to TGREP
- Changed Abstract and Introduction sections to position TGREP as - Changed Abstract and Introduction sections to position TGREP as
an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP) an auxiliary protocol to TRIP (as opposed to a "subset" of TRIP)
- Modified the section on LS/Proxy Behavior including the diagram - Modified the section on LS/Proxy Behavior including the diagram
- Added an additional example to the Route Consolidation section - Added an additional example to the Route Consolidation section
- Changed the format of Carrier (both as an attribute and as an AF) - Changed the format of Carrier (both as an attribute and as an AF)
to accomodate representation of Country codes in association with to accomodate representation of Country codes in association with
CICs. CICs.
- Updated text to allow Carrier attribute in TrunkGroup address - Updated text to allow Carrier attribute in TrunkGroup address
family and TrunkGroup attribute in Carrier address family. family and TrunkGroup attribute in Carrier address family.
6. Changes since -03 7. 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. Changes since -02 8. Changes since -02
- Removed the requirements section. - Removed the requirements section.
- Discussed the motivation for introducing Carrier information into - Discussed the motivation for introducing Carrier information into
TRIP. TRIP.
- Defined a new attribute for the E.164 address family. - Defined a new attribute for the E.164 address family.
- Defined a new address family for CarrierCode-TrunkGroup - Defined a new address family for CarrierCode-TrunkGroup
combination . combination .
- Defined new attributes to advertise dynamic gateway - Defined new attributes to advertise dynamic gateway
characteristics like resource availability, and call success characteristics like resource availability, and call success
rate. rate.
- Added as section to validate the TGREP solution against the - Added as section to validate the TGREP solution against the
requirements in [7]. requirements in [7].
8. Changes since -01 9. 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.
9. Changes since -00 10. Changes since -00
- Added text to stress the value of this proposal for managing a - Added text to stress the value of this proposal for managing a
gateway cluster. gateway cluster.
- Added attributes for circuit capacity and DSP capacity. - Added attributes for circuit capacity and DSP capacity.
- Added section on LS operation, discussing aggregation issue. - Added section on LS operation, discussing aggregation issue.
Authors' Addresses Authors' Addresses
Manjunath Bangalore Manjunath Bangalore
Cisco Systems Cisco Systems
Mail Stop SJC-21/2/2 Mail Stop SJC-21/2/2
771 Alder Drive 170 W. Tasman Drive
Milpitas, CA 95035 San Jose, CA 95134
email: manjax@cisco.com email: manjax@cisco.com
Rajneesh Kumar Rajneesh Kumar
Cisco Systems Cisco Systems
Mail Stop SJC-21/2/2 Mail Stop SJC-21/2/2
771 Alder Drive 170 W. Tasman Drive
Milpitas, CA 95035 San Jose, CA 95134
email: rajneesh@cisco.com email: rajneesh@cisco.com
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
72 Eagle Rock Avenue 72 Eagle Rock Avenue
First Floor First Floor
East Hanover, NJ 07936 East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
Hussein F. Salama Hussein F. Salama
Cisco Systems Cisco Systems
Mail Stop SJC-24/3/2 Mail Stop CAI1
170 W. Tasman Drive 135 Abdel Aziz Fahmy Street
San Jose, CA 95134 2nd Floor Apartment #3, Heliopolis
Cairo, Egypt
email: hsalama@cisco.com email: hsalama@cisco.com
Dhaval N. Shah Dhaval N. Shah
Cisco Systems Cisco Systems
Mail Stop SJC-21/2/2 Mail Stop SJC-06/4/3
771 Alder Drive 170 W. Tasman Drive
Milpitas, CA 95035 San Jose, CA 95134
email: dhaval@cisco.com email: dhaval@cisco.com
Acknowledgments Acknowledgments
We wish to thank David Oran, Anirudh Sahoo, Kevin McDermott, Jon Peterson, We wish to thank David Oran, Anirudh Sahoo, Kevin McDermott, Jon
Li Li and Bob Penfield for their insightful comments and suggestions. Peterson, Li Li and Bob Penfield for their insightful comments and
suggestions.
References References
[1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement [1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
 End of changes. 

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