Internet Draft T. Do Document: draft-walker-iptel-trip-tns-00.txt J. Jiang Category: Informational L. Li Expires: January 2001 D. Walker SS8 Networks Inc July 2000 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. 1. 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 long distance carrier) is such a case. This draft describes three ways that a Transit Network Selection (or TNS) mechanism can be added to the TRIP protocol. 2. Background 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, Do/Jiang/Li/Walker 1 Internet Draft TRIP Transit Network Selection July 2000 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 long distance 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. 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). Telephony routing over IP [2] provides a powerful means of distributing routing information. As it is currently defined, destinations (or ReachableRoutes in TRIP parlance) may be any form of address family defined in RFC 1700 (or the more recent list maintained by IANA). Many of the address families in this list are not directly applicable to telephony, and in practice, only E.164 addresses are fully supported by TRIP. The reader should be familiar with TRIP concepts. 3. 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 [3]. 4. Adding Transit Network Support to TRIP 4.1. Increasing Importance of the RoutedPath attribute The first question that has to be asked is, "why isn't ITAD sufficient?" On the surface, it would appear to be very similar to the Network Identification used for Transit Networks, and it is already distributed in RoutedPath (and also in AdvertisedPath, whose semantics aren't applicable). Transit Network Selection as it is currently defined applies to the PSTN, but there is no reason why it should not apply equally to networks used for IP telephony, so routing on the basis of ITAD is a possibility. However, the focus of this paper is on TRIP to PSTN gateways which have access to the desired TNS for the PSTN, in the same way as TRIP concentrates on E.164 gateways. Do/Jiang/Li/Walker 2 Internet Draft TRIP Transit Network Selection July 2000 TRIP defines ITAD as ranging from 0-65535, with assignment being done by IANA. ITAD values are likely to be assigned on a global basis, which will make them difficult to associate with TNS identifiers assigned on a national basis. RoutedPath only indicates the path that would be followed by the call signalling; the intention behind network selection is that an end-user can select the network that will be used to carry both signalling and media, as billing may be generated from either (more likely media). For IP telephony, routing of the media is performed at the transport layer, independent of the routing of call signalling. So network selection is primarily of importance at the point where call signalling and media transport merge: the PSTN gateway (or so-called softswitch). So, in fact, RoutedPath is of little use in providing PSTN transit network selection support. 4.2. Adding Transit Network as a New 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 networks that can be reached by a particular gateway. This is an appealing solution if there is no need for a linkage between Transit Network and E.164 numbers, i.e. if 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.164s carry country code. If the definition of Transit Network which would be distributed by TRIP includes the associated country code, then this problem can be averted, but only on a national basis - it is still possible that not all E.164s within a particular administration are reachable by every network under the administration. So with an association required between E.164 address ranges and Transit Network values, TRIP UPDATE construction and processing becomes more complicated. For example, within one UPDATE there could be a mix of E.164 and TN addresses within a single ReachableRoute attribute, with the meaning being that each of the TNs can reach all of the E.164 addresses (if no E.164 address is present, then the assumption is that all E.164 addresses are reachable). 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. Do/Jiang/Li/Walker 3 Internet Draft TRIP Transit Network Selection July 2000 In general, the existence of interdependency between E.164 addresses and Transit Networks indicates that, in fact, Transit Network should be considered as an attribute of E.164 routes (or E.164 addresses are attributes of Transit Network routes). So another alternative is to create a new attribute to carry a list of Transit Numbers that can be used to reach the E.164 addresses in the ReachableRoute (or WithDrawnRoute) attribute. 4.3 Adding Transit Network as a New Attribute This solution proposes that UPDATES carry a new "transit-network" attribute, which would be a sequence of transit network prefixes that can reach the addresses carried in the ReachableRoutes attribute. This solution addresses the issue where a particular network is unable to reach all of the E.164 addresses within its own national boundaries. The essential feature of this approach is that no combination of E.164 address and transit network can be withheld by an originating LS. Where two routes to the same destination, but via different Transit Networks, are made known to an LS, without aggregation driven by the different in TN, the TRIP decision process would normally select only one route for propagation. Access to the route through the less preferred Transit Network will not be available to other LSs. TRIP could be changed to allow flooding of all routes within a domain, and then when the route is advertised out of the domain, all Transit Networks would be indicated (a suitable NextHopServer would have to be selected in the domain). However, it may not be desirable for TRIP to flood all routes within a domain as this could result in a significant increase in traffic and in processing on the TRIP servers. An alternative to full intra-domain link-state flooding requires that multiple routes to the same destination (E.164) be aggregated if they have different associated transit network attributes. For example, given an external/local route to E.164 addresses E(a) with transit networks N(a) (represented by [E(a),N(a)]), and an external or local route [E(a),N(b)] becomes available, an aggregation to [E(a),N(a,b)] must be flooded within the domain - the relative preference for the two component routes isnĘt relevant. If the two RoutedPaths to E(a) are different, then a new NextHopServer must be identified and other attributes aggregated as specified in [2]. When one route to E(a) is external/local, and the other is internal, a similar form of aggregation must take place. This aggregation may be performed by all LSs originating a route to E(a) based on external/local sources. Other LSs within the domain will receive Do/Jiang/Li/Walker 4 Internet Draft TRIP Transit Network Selection July 2000 all such routes via flooded updates, and should choose the preferred path based on LocalPreference and other standard TRIP processing rules. For two otherwise equivalent routes, the prefernce should be given to the route whose list of TNs is a superset of the other list. The LocalPreference of such an aggregated route should not be lower than the preference of any aggregated route. It may be necessary to de-aggregate E.164 addresses in order to advertise all transit networks. For example, given [E(a,b),N(x,y)] and [E(a,c),N(x,z)], the resultant routes would be [E(a),N(x,y,z)] (which may need a new NextHopServer), [E(b),N(x,y)] and [E(c),N(x,z)]. UPDATEs to external peers will thus carry a list of all transit networks which can reach the E.164 addresses in the ReachableRoute. Appropriate settings for the Attribute Flags is: Optional Flag=optional; Transitive Flag=non-transitive(?); Dependent Flag=independent; Partial Flag=complete; Link-state Encapsulated Flag=N.A. 4.4. TRIP Representation of Transit Network A Transit Network can contain both an indication of the country to which it applies and the actual Transit Network value (or prefix). Country codes are defined in [4]. 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 are therefore aggregatable (although knowledge of "black-holes" may be requried). If these network identifiers are prefixed by a fixed length E.164 Country Code, it becomes possible to aggregate across administrative boundaries. The following syntax specification is to be used to represent a transit network prefix. It uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [5]. transit-network = country-code network-identifier country-code = 3DIGIT network-identifier = *network-digit network-digit = DIGIT|'A'|'B'|'C'|'D'|'E'|'F' 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". Do/Jiang/Li/Walker 5 Internet Draft TRIP Transit Network Selection July 2000 A single transit-network has 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) | +---------------+---------------+--------------+----------------+ and the Transit-Networks attribute is encoded as a sequence of transit-networks (the number of transit-network prefixes is determined by the overall length of the attribute +----------------------+----------------------+... | transit-network1... | transit-network2... | +----------------------+----------------------+... Other encoding details are to be determined. 4.5. Transit-Network Aggregation A defined in the previous section, a transit-network can be fully specified, or may be represented as a prefix. If the transit- network contains only the country-code, then all national transit networks are reachable via the advertised path. As some values of network-digit are not used by some administrations, 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. 5. Conclusion This paper has briefly explored three ways in which support for Transit Network Selection can be added to TRIP. Among those suggestions, the creation of a new attribute seems preferrable. Other approaches are possible. For example, a variant the E.164 address family could be created that would carry TNs prepended to the E.164 prefixes (this would make aggregation of TN difficult unless TN and E.164 are both represented as distinct subfields - which then begins to resemble the new address family type solution described above). 6. Security Considerations This draft does not introduce the need for any new security measures beyond what is provided by the TRIP protocol itself. Do/Jiang/Li/Walker 6 Internet Draft TRIP Transit Network Selection July 2000 7. 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 (TRIP)", draft-ietf-iptel-trip-02.txt, work in progress. 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 4 ITU-T, "List of ITU-T Recommendation E.164 Assigned Country Codes", Annex to ITU Operational Bulletin No.717, June 2000. 5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 6 ITU-T, " ISDN user-network interface layer 3 specification for basic call control", Recommendation Q.931, 1998. 7 ITU-T, " Signalling System No. 7 - ISDN user part formats and codes", Recommendation Q.763, 1997. 8 ANSI, "Signalling System No. 7 (SS7) - Integrated Services Digital Network (ISDN) User Part", 1995. 8. Acknowledgments [...] 9. Author's Addresses Tu Do SS8 Networks Inc 80 Hines Road, Kanata, ON Canada K2K 2T8 Phone: +1 613 592 2100 Email: tu@ss8networks.com Jianping Jiang SS8 Networks Inc 80 Hines Road, Kanata, ON Canada K2K 2T8 Phone: +1 613 592 2100 Email: jianping@ss8networks.com Li Li SS8 Networks Inc Do/Jiang/Li/Walker 7 Internet Draft TRIP Transit Network Selection July 2000 80 Hines Road, Kanata, ON Canada K2K 2T8 Phone: +1 613 592 2100 Email: lili@ss8networks.com Dave Walker SS8 Networks Inc 80 Hines Road, Kanata, ON Canada K2K 2T8 Phone: +1 613 592 2100 Email: drwalker@ss8networks.com 10. Full Copyright Statement "Copyright (C) The Internet Society (2000). 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 implmentation 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 as 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 OR MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Do/Jiang/Li/Walker 8