Internet Engineering Task Force IPTEL WG
Internet Draft J. Peterson
draft-jfp-trip-servicecodes-00.txt Level(3) Communications
November 17, 2000
Expires: April, 2001
The ServiceCode Attribute for TRIP
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as work in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Telephony Routing over IP (TRIP) [2] provides a means for entities in
a VoIP network to advertise telephony routes to their peers. No
assumption can be made about the treatment which is offered by an
endpoint propagating a route - it could intend to terminate the call
in some fashion or apply services to the call. This document proposes
an optional ServiceCode attribute propagated along with such routes
which provides more information about the services offered by the
originator.
1. Introduction
TRIP [2] provides a means for entities in a VoIP network to advertise
telephony routes to their peers. The primary proposal describes TRIP
Location Servers which act as focal points for the aggregation of
routes offered by a network; these routes are then shared with peer
Peterson [Page 1]
Internet-Draft TRIP ServiceCode Nov 2000
networks. Presumably, these Location Servers are associated with
VoIP call-routing instruments (such as Proxy Servers in SIP [3] or
gatekeepers in H.323 [4]), and the routes collected by a Location
Server are used to make decisions about routing VoIP calls.
A subsequent TRIP proposal [5] introduces an intradomain version of
TRIP which allows endpoints in a VoIP network (such as gateways and
softswitches) to propagate the availability of routes to Location
Servers. Previous to this effort, it was assumed that network
administrators would be responsible for the redundant provisioning of
these devices.
TRIP propagates routes associated with an address family; currently,
E.164 [6] telephone numbers and routing numbers (special phone
numbers used in local number portability) have been identified as
address families in TRIP. Routes that use telephone-number based
address families generally support prefix matching (e.g. '+1800'
signifies that all calls in the North American Numbering Plan in the
800 NPA are eligible for termination at the endpoint that has
propagated this route) for cases in which a large set of telephone
numbers (an address range) needs to be propagated.
Service codes are proposed as an optional mechanism (specifically a
TRIP attribute) that support the advertisement of routes associated
with services in TRIP. A service code may be propagated along with
the route in order to provide information about the type of service
that the endpoint originating this route offers.
This information ultimately will assist the Location Server and call
routing system in making decisions about routing calls; as well as
potentially realising other advantages for network administrators.
Specifically, service codes can be used for the following:
o Feature interactivity: By understanding the type of service that
a particular route represents, a Location Server/call routing
system can potentially make better decisions about routing calls,
particularly when multiple endpoints are eligible to field a call.
o Differentiating between types of termination: Some calls may
require features that are only available when the terminating
endpoint supports certain PSTN protocols or features.
o Operational advantages: The presence of an explicit service code
in TRIP signaling would facilitate debugging of network route
exchanges. Additionally, network administrators would have the
opportunity to execute policies based on the service code.
o Aggregation changes: Some routes that would otherwise have been
Peterson [Page 2]
Internet-Draft TRIP ServiceCode Nov 2000
aggregated are kept distinct, potentially allowing Location Servers
and call routing systems to select the most proper network or
resource for a call.
Service codes are well suited to an environment of dynamic
registration of services in which the administrators of application
servers do not control the Location Servers to which routes are
propagated - especially if these resources are in distinct Internet
Telephony Administrative Domains.
2. TRIP for Services
A service, as described in this document, is a network application
residing on an endpoint that speaks a VoIP protocol (such as SIP or
H.323). The applications with which this document is primarily
concerned are those that implement telephony service logic which
modifies some aspect of a VoIP call. The endpoints that house these
applications are generally referred to as application servers or
service nodes.
TRIP as envisioned in [5] is a protocol used by gateways and
softswitches to propagate the ranges of telephony addresses that can
be reached through them. Conventionally, these ranges are understood
to be sets of telephone numbers (or prefixes representing groups of
numbers) to which a gateway is adjacent, and which consequently a
gateway can service at a favorable cost. However, nothing prevents an
application server from similarly propagating address ranges that are
appropriate to its services.
In other words, TRIP is already enabled for basic service routing,
and requires no special additions to allow an application server to
propagate routes. However, it is not clear that TRIP has mechanisms
to address feature interaction problems that may arise when multiple
routes are available for a single call.
To take a simple example, an LS which governs the configuration of a
SIP Proxy Server might have received several propagated routes that
are applicable to a given call. Without insight into the sort of
service that had propagated the route, the LS must make decisions
about precedence based on factors like the longest prefix match,
which might not necessarily reflect the fact that a call forwarding
service should be consulted before a termination service.
Similarly, without service codes an LS might not be able to detect
that several routes it had received are in fact associated with the
same service (say, local number portability services being operated
by several independent application service providers), which could
result in services being accessed redundantly.
Peterson [Page 3]
Internet-Draft TRIP ServiceCode Nov 2000
Although this document is primarily concerned with routes propagated
by application servers, termination (offered by a gateway or
softswitch) can also be considered a service. Using service codes, a
conventional gateway can provide a greater degree of specificity
about its termination capabilities. For example, a gateway providing
PRI termination can be distinguished from a softswitch providing SS7
termination when certain features of the call would make one
termination type preferable to another.
Finally, gateways that have their own service logic can specify both
their services and their termination capabilities. This is in essence
no different than an application server that harbors several
independent services. In either of these cases, it's possible that
several discrete address ranges will be propagated for different
services from the same endpoint.
3. Propagating Routes with Service Codes
Consider the following example:
+--------+
PRI | |
-------+Gateway1| +1720 +--------+
| |-------------->| |
+--------+ UDPATE | | UDPATE
|Location|------------->
|Server |------------->
+--------+ UDPATE | | UDPATE
| |-------------->| |
|App | +17208885 +----+---+
|Server | |
+--------+ +----+---+
|NumTrans| |SIP |
+--------+ |Proxy |
|Server |
+--------+
Gateway1 is a SIP-PRI gateway that is located in the 720 NPA in the
US. Consequently, it propagates a route to its Location Server
(using intradomain TRIP) with an address range of '+1720'. It also
includes a ServiceCode indicating 'PRI Termination'.
Meanwhile, App Server is running a number translation application of
some kind. This application is a consumer of calls destined for a
particular thousand-block in the 720 NPA. Therefore, the App Server
propagates its own route to the LS with an address range of
'+17208885' and with a ServiceCode indicating 'Number Translation'.
Peterson [Page 4]
Internet-Draft TRIP ServiceCode Nov 2000
When the Location Server receives these routes, it has two
responsibilities. Firstly, it must provide some instruction to the
SIP proxy with which it is associated. Secondly, it must propagate
these routes onwards to peer Location Servers, possibly in other
administrative domains.
How the LS will provision the PS as a result of these two routes is a
matter of administrative policy. Somehow, the LS will most likely
insert a preference for the AppServer route over the Gateway route,
when both rules apply to a call - provided that the general policy of
the LS is that a Number Translation service should be accessed before
a Termination service. The administrator responsible for setting
policy on the LS will certainly be aware that sending the call to a
Termination service is the final step in the call's lifecycle. The
decisions made on the basis of administrator policy by the LS will
determine how the PS will route calls that might terminate at these
resources.
The LS will also determine what routes it should propagate to its
peers. Without ServiceCodes, obviously, '+1720' and '+17208885'
would aggregate to '+1720'. However, with ServiceCodes, these two
routes clearly are indicating the availability of different
resources, and consequently they cannot be aggregated. This concept
is explored further below in section 6.
4. ServiceCode Attribute
Mandatory: False
Required Flags: optional, non-transitive
Potential Flags: None
TRIP Type Code: TBD
The ServiceCode attribute may appear in ReachableRoutes and
WithdrawnRoutes in a TRIP UPDATE message. If a route has been
propagated with a ServiceCode, it must also be withdrawn with the
ServiceCode to avoid potential ambiguity.
While today TRIP specifies only telephone numbers as address
families, the ServiceCode attribute will most likely be applicable to
any present or future address family used in TRIP.
Note that the ServiceCode attribute is optional. If the attribute
does not appear in an UPDATE, the service is assumed to be
'Termination - unspecified' (ServiceCode 0).
Given that there are potentially a large number of VoIP services,
this proposal recommends that two bytes be used for ServiceCodes.
Also, rather than enumerating the possible ServiceCodes in this
Peterson [Page 5]
Internet-Draft TRIP ServiceCode Nov 2000
document, it is submitted that IANA should maintain the list of
standard ServiceCodes. Some examples of potential services are:
o SS7 Termination
o Freephone Number Translation
o Conferencing
Finally, note that more than one ServiceCode can be associated with a
given address range - this may become especially prevalent in
interdomain cases in which the capabilities of several application
servers are aggregated.
A more detailed examination of the byte structure used for
ServiceCodes shall be explored in a future version of this document.
5. Operating with ServiceCodes
There are several potential benefits for network administrators using
ServiceCodes.
The arrival of a propagation of a route for the address range
'+17208885' at a given LS might not be immediately understood to
signify that conferencing services are available to the network.
However, an accompanying ServiceCode that can easily be referenced
would allow a human or an application to understand which services
are available in the network at any given moment. The presence of
ServiceCodes could also aid the analysis of network failures in logs
that record TRIP packets.
ServiceCodes might also be used as triggers for various policies
executed by a network administrator. These policies could be as
simple as the denial of a particular ServiceCode from a particular
ITAD or gateway. On the other end of the spectrum, policies could be
used to determine route precedence; general rules like 'services
before termination' could be applied by the Location Server to the
decision matrix of the call routing system.
As a special case of policy deployment, a network administrator might
elect to verify that the address range associated with a particular
ServiceCode is appropriate for the service in question. For example,
if the ServiceCode is 'Freephone Translation', then the set of
address ranges in the US should be limited to '+1800', '+1877',
'+1888' - the established freephone NPAs. Any network administrator
attempting to block particular ServiceCodes might require this added
security.
Peterson [Page 6]
Internet-Draft TRIP ServiceCode Nov 2000
6. Aggregation of Address Families with ServiceCodes
Clearly, the specification of a ServiceCode associated with a route
should affect the way aggregation with other routes is performed.
Three consequences follow from this:
o Two routes which specify adjacent address ranges with different
ServiceCodes cannot be aggregated. For example, consider a case in
which two routes are propagated by a network, one representing the
address range '+17208880' through '+17208884' with a ServiceCode
indicating 'SS7 Termination', and another representing '+17208885'
through '+17208889' with a ServiceCode representing 'Number
Translation'. An LS could not aggregate these two routes into a
single route with an address range of '+1720888' due to the
incompatibility of the ServiceCodes.
o Two routes specifying the same address range with different
ServiceCodes can be aggregated. For example, one route indicating
an address range of '+1720' with a ServiceCode of 'SS7 Termination'
and another route indicating an address range of '+1720' with a
ServiceCode of 'Number Translation' can be aggregated into a single
route with an address range of '+1720' with two ServiceCodes, 'SS7
Termination' and 'NumberTranslation'.
o Routes without ServiceCodes can only be aggregated with one
another, or with routes bearing the ServiceCode 'Termination -
unspecified' defined above.
This is to be further examined in a future version of this draft.
7. IANA Considerations
The intention of this proposal is that users of this mechanism will
register ServiceCodes with IANA. A block of ServiceCodes shall be
reserved as spare for non-standard usage.
As is noted above, ServiceCodes shall be two bytes in length.
ServiceCode 0 is reserved (signifying unspecified termination).
It may be desirable to divide the available namespace for
ServiceCodes into sections representative of classes of service. For
example, one class might be 'Termination' and another 'Number
Translation'.
ServiceCodes may also wish to distinguish between those services of
which a given instance returns a unique result to a given query and
services whose instances all necessarily return the same result to a
given query. For example, all freephone translation services will
Peterson [Page 7]
Internet-Draft TRIP ServiceCode Nov 2000
return the same result for a given query (provided they are up to
date), and hence all of these services are isomorphic. However, a
call forwarding application operated by one ASP may return radically
different results than that of another ASP - both of these ASPs are
offering the same service, but the services are not isomorphic.
8. Security
Several security concerns are described in the operational section
(5) above.
It is especially important in the context of ServiceCode propagation
that an LS only accept TRIP routes from authorized sources - fraud
and DoS are possible consequences.
References
[1] S. Bradner, "The Internet Standards Process", BCP 9, RFC 2026,
Internet Engineering Task Force, October 1996
[2] J. Rosenberg, H. Salama, M. Squire, "Telephony Routing over IP
(TRIP)", draft-ietf-iptel-trip-03.txt, Internet Engineering Task
Force, July 2000 (work in progress)
[3] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
Session Initiation Protocol", RFC2543 (Standards Track), March 1999
[4] International Telecommunication Union, "Visual Telephone Systems
and Equipment for Local Area Networks which Provide a Non-Guaranteed
Quality of Service," Recommendation H.323, May 1996
[5] J. Rosenberg, H. Salama, "Usage of TRIP in Gateways for Exporting
Phone Routes", draft-rs-trip-gw-01.txt, Internet Engineering Task
Force, July 2000 (work in progress)
[6] International Telecommunication Union, "The International Public
Telecommunication Numbering Plan", Recommendation E.164, May 1997
Author's Address
Jon Peterson
1025 Eldorado Blvd
Broomfield, CO
jon.peterson@level3.com
Full Copyright Statement
Copyright (c) The Internet Society (2000). All Rights Reserved.
Peterson [Page 8]
Internet-Draft TRIP ServiceCode Nov 2000
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Peterson [Page 9]