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]