Network Working Group HF Zhu INTERNET-DRAFT UTAustin Expire in six months November, 1997 Framework for Interconnecting Internet with Public Circuit-Switching Network Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract Recently there are a number of efforts trying to connect the packet- switching network with circuit-switching network, especially the Internet with public telephone networks. The first problem of such interconnection is naming and addressing, which are described in some other drafts ([dnsurl], [telurl1], [faxemail]). This draft gives a brief framework on what the problems we may have in architecture and technology when connecting these two networks, and the possible solutions for these problems. 1. Requirements Requirements are indicated as specified in [RFC2119]. 2. Possible Structures When we connect IP networks with circuit-switching networks (shortened as CSW below), there may be two kinds of "connection points": server and gateway (router), run by different providers. Roughly, the server here means the host that can support many high level applications in the Internet, e.g. a Web server. The gateway/router here means some companies may provide high performance routers that only support IP layer (or a bit more when necessary) to allow large traffic, which is possible in the future of Internet. Considering the two big networks (Internet and CSW networks) where Internet is made of IP clouds, there may be boundaries among the IP clouds and different CSW networks. The boundary here means the place where different policies (including pricing, etc.) may be applied. Here, we use public telephone switching network as a model in discussing CSW networks (although they are a bit different). A data flow going between Internet and the devices of CSW networks will across the boundaries within Internet and the connection points of the Internet and the CSW networks. The situation is like: Host + IP cloud + ... + IP cloud + Connection Point + CSW network + ... + CSW network + End User of Tel/fax, etc. Logically, it is also possible for the "CSW networks" to appear within "IP cloud + ... + IP cloud" and IP cloud to appear within "CSW network + ... + CSW network". However, when a CSW network appears among IP cloud, they often support IP interface so it can still be regarded a whole IP network. This draft discusses the situation of "IP cloud + ... + IP cloud (which is Internet) + Connection Point + CSW network". It can be used to solve the problem of other situations by applying it repeatedly. On the boundaries, the information about price, QoS, policies, etc. at each "+" point may need to be obtained or exchanged by protocols or applications. A typical example is: Internet + Connection Point + Local CSW network + End User of Tel/fax, etc.. This means, the connection point is local to the end user (say, in the same city) where fixed low costs are paid by the end users. This is already adopted in many implementations. 3. Current Related Research 3.1 MMUSIC of IETF There is an expectation in associating the use of telephone and some other devices in the telephone networks (such as visual phones, etc.) with the multimedia conferencing service in the Internet, or vice versa. The Multiparty Multimedia Session Control Working Group (MMUSIC) of IETF has been developing a set of protocols [confarch] [sdp] [sip] [rtsp] [sap-sec] that allow multiparty multimedia conferencing over Internet. The protocols are based on IP hosts, and also allow connection with entities with H.323 [h.323], a standard for multimedia conferencing for various packet-switching networks defined by ITU (International Telecommunication Union). 3.2 ITU H.323 H. 323 is defined within ITU, to support multimedia conferencing on packet-switch networks. It specifies two abstract roles: Gatekeeper and Gateway, which are respectively responsible for address translation and communication between H.323 terminals and packet-switched network or other ITU terminals on a circuit-switched network. However, it does not give a technology that is efficient in IP networks. 3.3 Some Internet Drafts There are a number of efforts related with a certain degree of integrating services from circuit-switched networks, such as telephony (including fax), into Internet. IETF currently has PINT and IETF-FAX WG working on similar topics. PINT gives a service model based on Web server and mainly devotes efforts towards the interface between this Web server and elements in Intelligent Network (IN). IETF-FAX is working on fax service based on email systems. 4. Frameworks There are some problems needed to solve in order to support real interconnection of Internet and CSW networks, to provide a certain degree of service integration. 4.1 Directory Lookup Since it is impossible to allow only one provider to cover all the interconnection services, directory service is inevitable. In fact, interconnection services may be a very hot area and many providers may join when technical problems are solved. Basic directory service required is: for a certain tel/fax number, or a group of tel/fax numbers, list all the IP addresses of the connection points (servers, routers, gateways) that can reach it or them. The information listed may be along with the services offered by these points (together with prices, QoS, and optional items for extended uses). The QoS parameters can be those defined in RFC 2210 [RFC 2210] or others. It must allow many different new services. An examples can be: someone can leave a message or several messages on the phone and give different access permissions for those messages to different people, etc. . Almost all the services that are being provided by current telephone companies can be offered, and more. Therefore, a protocol providing a bit more flexible query service may be needed (can be one of the current protocols or its extension), please refer to [dnsurl]. The protocol should be able to work with protocols for conferencing currently developed within IETF-MMUSIC, such as SIP. The directory service should be distributed so that the lookup action can be done quickly. It should also be dynamic and well-controlled. Being dynamic allows connection points and the tel/fax numbers they support (very probably be their customers) to be changed dynamically. Some services may have different prices when time changes during a day or a week, etc.. Being well-controlled means the information of these services must be ensured to be correct, which is a problem of both administration and security. 4.2 Choice of connection points and the routing problems 4.2.1 From the eye of a host in the Internet When a user in the Internet wants to connect to a specific tel/fax number, there are several factors that affect the choice of the "connection point" if there are more than one choice for that number. They are the services that the connection point provides, the route to that point, and the policies of that point or the owner of that tel/fax number. For example, someone may prefer telling some friends to use a certain service while other people not to use that service, or give a default choice among these providers, etc.. Extension should be allowed here to provide more factors. A broker like function is needed here. However, the choice of connection point will affect routing. Different choice of connection point may lead to different route and the QoS along that route maybe different or very different. Routing may also need to be dynamically adapted to the load of the Internet if a lot of users are using it, e.g. attending multimedia conferencing in the MBone. Efficiency of routing is important under such circumstance because the traffic is real-time. If a company provides several interconnection routers/gateways on several different ISPs, packets go into different routers/gateways can be transferred to the same tel/fax during one session with that tel/fax. Under such circumstance, the connection point can be changed during one session. Here, we define the "basic requirement" of routing and connection point decision to be that once the connection point is chosen and a session begins, we will not change that connection point we chose before the session is over. The "advanced requirement" is that the connection point can be changed during one session. Meeting the advanced requirement among routers/gateways of different interconnection providers may need to route through intelligent networks, if they don't build specific network to connect them for this purpose. In this case, routing among them won't be used for voice or video services unless the connection re-setup speed is quick enough in IN (say, with in 100 ms, which is significant to real-time traffic). Although this may not easy to obtain currently, extension should be allowed for the future Internet. 4.2.2 QoS Test and Estimation Test of QoS is needed according to the above. Several scopes can be defined here: 1. QoS test between two ends; 2. QoS test under multicast; 3. QoS at end points (such as connection points). The solutions should rely as much as possible on the intelligence of end points (hosts or connection points here), or if necessary, adding appropriate servers making use of current Internet routing facilities. For example, There are a lot of mechanisms can be used to test the QoS from one IP address to the other. The simplest method for testing delay can be using ICMP ping messages, or algorithms like Jacobson/Karels or Karn/Partridge used in TCP for estimation especially the traffic is transferred by TCP. Novel methods are encouraged. QoS routing [qosroute] or reservation [rsvp] also preferred in order to obtain a better performance. The work may need to be done with related working-group of IETF (i.e.: working groups of QoS routing, IP Performance Metrics and Benchmarking). 4.2.3 The Decision on Connection Points As long as information from Directory Service (costs, services, etc.) and tested QoS is available, a decision can be made to choose a connection point. At this time, the preference of users (may include Internet users and tel/fax users) can be decided according to user choice manually or through a given formula automatically. A default mechanism (say, shortest end-to-end delay first) can be used to decide automatically too. When the connection points that can be chosen contain more than one gateways/routers, and dynamic entrance is possible and needed, a formula to decide which gateway/router to choose is required to be given by the users or protocols. 4.3 Possible Solutions Some efforts may need to be carried out in several layers, depending on what degrees of services we need to provide on the Internet. For example, in order to obtain the "advanced requirement", some efforts may be needed in the IP layer, such as routing information lookup, multicast support. However, if providing "basic requirement", address lookup, decision of connection point are relatively simple. QoS routing and QoS reservation (with RSVP [rsvp]) can be optional according to application needs. The solutions can be based on Internet Integrated Service Model but can also follow the best-efforts based on QoS-test and estimation. 5. Security Considerations Security is important to ensure the servers that provide information for connection points store and deliver the correct information for each connection providers. Security in the data packets is handled by other protocols. 6. Author's Address Haifeng Zhu Department of Electrical & Computer Engineering The University of Texas at Austin Austin, TX 78712-1084 USA Email: zhf@ece.utexas.edu Tel: +1-512-475-6875 Fax: +1-512-232-1739 7. References [utrpt] Haifeng Zhu, "Interconnecting Internet and Public Circuit- Switching Networks: Architecture and Technology", Research Report CS97395T, The University of Texas at Austin, 1997 [dnsurl] Haifeng Zhu, "DNS and URL Naming for Public Circuit-Switching Network Devices", Internet-Draft, draft-zhu-dns-url-level-addr-00.txt, "Work in progress", 1997 [urltel1] A. Vaha-Sipila, URLs for Telephony, draft-antti-telephony-url-01.txt, Sep. 19, 1997 [sip] MMUSIC WG of IETF, Handley, Schulzrinne, Schooler, SIP: Session Initiation Protocol, draft-ietf-mmusic-sdp-04.ps, 2nd Sept, 1997 [confarch] M. Handley, J. Crowcroft, C.Bormann, J.Ott, The Internet Multimedia Conferencing Architecture, draft-ietf-mmusic-confarch- 00.txt, July, 1997 [sdp] MMUSIC WG, Mark Handley, Van Jacobson, SDP: Session Description Protocol, draft-ietf-mmusic-sdp-04.ps, 2nd Sept,1997 [rtsp] MMUSICWG, H. Schulzrinne, A. Rao, R. Lanphier, Real Time Streaming Protocol (RTSP), Spet.17,1997 [sap-sec] MMUSIC WG, P. Kirstein, G. Montasser-Kohsari, E. Whelan, Specification of Security in SAP Using Public Key Algorithms, draft- ietf-mmusic-sap-sec-01.txt, July 29,1997 [h.323] International Telecommunication Union, Packet Based Multimedia Communications Systems, ITU-T H.323 [sw1] I. Faynberg,, M. Krishnaswamy, H. Lu, A Proposal for Internet and Public Swithced Telephone Networks Internetworking,draft-faynberg- telephone-sw-net-00.txt, March,1997 [sw2] M. Krishnaswamy, H.Lu, Information Exchange to Be Supported by the Service Support Transfer Protocol (SSTP), draft-krishna-telephone- sw-net-00.txt, July, 1997 [in] L. Conroy, M. Lautenbacher, R. Scholl, Analysis of Services and Interfaces used when Interworking Between the Internet and the Intelligent Network (I.N.),draft-conroy-interfaces-in-net-00.txt, expire on Jan 7,1998 [telurl1] A. Vaha-Sipila, URLs for Telephony, draft-antti-telephony- url-01.txt, Sep.19,1997 [faxemail] C. Allocchio, Fax address format in e-mail services v3.1, draft-ietf-fax-addressing-00.txt, Sept,1997 [inetp] C. Yang, INETPhone: Telephone Services and Servers on Internet, RFC 1789 [mimefax] Harald T. Alvestrand, A MIME body part for FAX, draft-ietf- mixer-fax-01.txt, Aug. 19, 1996 [ipv6] S. Deering, R. Hinden, Internet Protocol, Version 6 Specification, RFC 1883, December, 1995 [ipv6sec] RFC 1825 - 1829, RFC 1851-1852 [ipv4v6] R. Gilligan and R. Callon, "IP v6 Transition Mechanisms Overview", Connexions, Oct. 1995 [qosroute] Eric Crawley, Raj Nair, Bala Rajagopalan, Hal Sandick, "A Framework for QoS-based Routing in the Internet", draft-ietf-qosr- framework-01.txt [RFC 1633] R. Braden, D. Clark, S. Shenker, Integrated Services in the Internet Architecture: an Overview, RFC 1633, July 1994 [RFC 1944] S. Bradner, J. McQuaid, Benchmarking Methodology for Network Interconnect Devices, RFC 1944, May 1996 [rfc2052] A. Gulbrandsen, P. Vixie, A DNS RR for specifying the location of services (DNS SRV), RFC 2052, Oct. 1996 [rsvp] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resourse ReSerVation Protocol (RSVP) - Version 1 Functional Specification, RFC 2205, Sep.,1997 [RFC 2210] J. Wroclawski, The Use of RSVP with IETF Integrated Services, RFC 2210, Sep., 1997 [RFC 2215] S. Shenker, J. Wroclawski,General Characterization Parameters for Integrated Services, RFC 2215, Spe.,1997 [tpc] RFC 1530-1569, RFC 1703, TPC.INT experiments' RFCs [LDAP] RFC 1777, RFC 1778, and a draft proposal for LDAP version 3 [rfc2119] S. Bradner, Keywords for use in RFCs to Indicate Requirement Levels some more ...