Internet Engineering Task Force D. Walker Internet Draft SS8 Networks Inc Document: draft-walker-iptel-trip-tns-01.txt February 2001 Expires: August 2001 TRIP Transit Network Selection Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 Conventional telephony signalling commonly uses E.164 addresses to route calls to their destination. However, selection of the signalling and media paths can be influenced by other considerations. Some such considerations may be user specified, and may differ from that which the network operator would normally choose. In some cases, support for such user-specified options may be required by national regulation. The choice of Transit Network (e.g. selection of inter-exchange carrier) is such a case. This draft describes a mechanism that allows Telephony Routing over IP [2] to support a Transit Network Selection (or TNS) TRIP Address Family. 1. Introduction Conventional telephony signalling commonly uses E.164 addresses to route calls to their destination. However, selection of the signalling and media paths can be influenced by other Walker 1 Internet Draft TRIP Transit Network Selection February 2001 considerations. Some such considerations may be user specified, and may differ from that which the network operator would normally choose. In some cases, support for such user-specified options may be required by national regulation. The choice of Transit Network (e.g. selection of inter-exchange carrier) is such a case. An originating user may presubscribe to a particular transit network, or may specify a particular selection on a per-call basis (perhaps over-riding a presubscription). Regardless of how it is specified, the expectation is that a network will try to route the call via the specified transit network. When a telephony signaling message can be routed by either dialed number (or E.164) or Transit Network Selection value, the TNS takes precedence. If there is a TNS explicitly specified by user signalling, or implicitly included by subscription, the network is normally expected to route the call to the indicated network if it can. This is irrespective of efficiency considerations. If multiple ingress points into the TN exist, local policy may be used to make an appropriate choice. Transit Network values are typically only of national significance, and are assigned by national numbering authorities, who do not necessarily all use the same format. For instance, in North America, assignment is done by NANPA, and networks are identified by a three or four character sequence (of hex digits, with a few values unused). Transit Network selection can be represented in a number of ways in SIP signaling. As suggested in [3], a "tel" URL can include a "cic" parameter. In order for a call signaling entity (such as a SIP client or H.323 endpoint) to route calls destined for particular TNs, it must be able to obtain an IP address of a destination that can reach that TN. The IETF has developed TRIP [2], Telephony Routing over IP, a powerful mechanism for determining and distributing preferred paths to telephony destinations based on destination and path attributes. The destination, or "Route", as it is called in TRIP, is a combination of the Application Protocol (such as SIP or H.323) and the range of addresses (or address prefixes) that the destination supports. TRIP explicitly defines two types of address (referred to as an Address Family), Decimal Routing Numbers and Hexadecimal Routing Numbers, but allows for additional Address Families to be defined (with Address Family code points assigned by IANA). This draft describes a mechanism that allows TRIP to support a Transit Network Selection (or TNS) Address Family. Walker 2 Internet Draft TRIP Transit Network Selection February 2001 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. 3. Adding Transit Network Support to TRIP 3.1. Transit Network Address Family By creating a new value for the Address Family used in the Reachable Route (and Withdrawn Route) attribute, it is possible to advertise the transit networks that can be reached by a particular gateway. This is an appealing solution as there is no need for a linkage between Transit Network and E.164 numbers, i.e. it can be assumed that all networks can reach all E.164 addresses. If this is the case, then it can be assumed that any signalling message addressed with both an E.164 address and a network selection can be routed by the network selection only. But, as has been pointed out, Transit Network is only of national significance, so the assumption here is not strictly valid as E.164 numbers carry country code (Country codes are defined in [5]). If the definition of a Transit Network Address Family to be distributed by TRIP includes an associated country code, then this problem can be averted. Of course, support for such a combination of address families also has an impact on the Route Types Supported capability that is present in the OPEN message. 3.2. TRIP Representation of Transit Network The following syntax specification SHALL be used to represent a transit network prefix. It uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [6], and uses rule names defined by TRIP. transit-network = country-code network-identifier country-code = 3decimal-digit network-identifier = *hexadecimal-digit The country code is the value assigned to the national administration under whose jurisdiction the given transit network can be accessed using a TNS corresponding to the specified network- identifier value. In cases where the length of the country code is less than three digits, it MUST be padded with zeroes on the left. For example, the country code for Barbados is "1", so its representation would be "001". Walker 3 Internet Draft TRIP Transit Network Selection February 2001 A single transit-network SHALL have the following TRIP encoding: 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 +---------------+---------------+--------------+----------------+ | Length | TN prefix (variable) ... +---------------+---------------+--------------+----------------+ A TN prefix must be at least one byte in length, so it is not possible for a single prefix to represent all possible TNs (this would require ten different single byte TNs: '0' to '9'). 3.3. Transit-Network Aggregation Aggregation of routes specified by Transit Network is complicated by the ability of national administrations to define their own formats. However, all national network identifiers are constructed as a sequence of hexadecimal digits and can therefore be aggregated (although knowledge of "black-holes" may be required). If these network identifiers are prefixed by a fixed length E.164 Country Code, it becomes possible to aggregate across administrative boundaries. As defined in the previous section, a transit-network can be fully specified, or may be represented as a prefix. Normally the prefix will include at least three digits (the country-code). If the transit-network contains only a country-code, then all national transit networks are reachable via the advertised path. Some values of network-identifier are not used by some administrations, or may be reserved for special purposes. If particular examples of such black-holes are known to a TRIP Location Server, it can use this knowledge for aggregation of transit-network values. Aggregation of Transit Networks is further complicated by the non- hierarchical nature of their assignment. This tends to make them inherently non-aggregatable. Without aggregation, the worst case would consume [ 2 bytes (length) + 3 bytes (country code) + 4 bytes (TN)] for every TN to be conveyed in the route. When very large numbers of non-aggregated TNs need to be conveyed, it may be more efficient to use an 8 Kbyte bit map to represent the TNs. This option is not explored in this draft. 3.4. TNS Address Family Capability A TRIP Location Server that supports the Transit Network Address Family SHOULD signal this when establishing a peer connection. This is done by including the Route Types Supported capability, specifying the Application Protocols for which TNS distribution is Walker 4 Internet Draft TRIP Transit Network Selection February 2001 supported. Rules for handling capability negociation are described in [2]. 4. IANA Considerations The TRIP Address Family code point to be used for Transit Network is assigned by IANA. Refer to http://www.iana.org/numbers.htm (note that TRIP Address Family is different from simple Address Family. 5. Security Considerations This draft does not introduce the need for any security measures beyond what is provided by TRIP itself. 6. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Rosenberg, J., Salama, H., and Squire, M., "Telephony Routing over IP", IETF Internet Draft, draft-ietf-iptel-trip-04.txt, work in progress. 3 Yu, J., "Extensions to the "tel" and "fax" URLs to Support Number Portability and Freephone Service", IETF Internet Draft, draft- yu-tel-url-02.txt, work in progress. 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5 ITU-T, "List of ITU-T Recommendation E.164 Assigned Country Codes", Annex to ITU Operational Bulletin No.717, June 2000. 6 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 7 ITU-T, " ISDN user-network interface layer 3 specification for basic call control", Recommendation Q.931, 1998. 8 ITU-T, " Signalling System No. 7 - ISDN user part formats and codes", Recommendation Q.763, 1997. 9 ANSI, "Signalling System No. 7 (SS7) - Integrated Services Digital Network (ISDN) User Part", 1995. Walker 5 Internet Draft TRIP Transit Network Selection February 2001 7. Author's Address Dave Walker SS8 Networks Inc. 495 March Road Ottawa, ON K2K 3G1 Canada Phone: +1 613 592 2100 Email: drwalker@ss8.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. 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. Walker 6