Internet Draft Andrzej Bartosiewicz draft-bartosiewicz-enterprise-enum-00.txt NASK February 16, 2004 Expires in six months Intended status: Informational Cost optimization based on Enterprise-ENUM 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 This paper presents an extension of NAPTR Resource Records and an application of the local DNS (called in further part of this document "Enterprise -ENUM") in order to keep information required for costs optimization of telecommunication connections. The optimization should cover the cost reduction through the selection of cheapest form of telecommunication connections for the calling party (a person initializing a telecommunication connection). Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [9]. Introduction Currently, the selection of the form and way of establishing connection assumes that the caller selects the way of connection through the selection of an operator (by whom a telecommunication connection will be initiated - it's usually fixed phone operator, mobile network operator or access to VoIP trough the Internet Service Provider). At the same time, the calling party selects a service identifier (especially a phone number) of a called person, by whom the connection will be finished. Accessible forms of contact depend on operators with whom the Calling Party has contracts and of operators' services that are used by the called person. In an optimal establishing of telecommunication connection the biggest obstacles are as follows: 1. Calling Party selects the only one known way of connection's initiation, which means that in the local phone directory there is the only one telephone number by the certain person. 2. Calling Party selects the simplest by its side form of contact (for example: mobile phone instead of VoIP connection). 3. Calling Party does not have knowledge about valid price-lists (telecommunication rates), then contacts another side in the first possible way. 4. Calling Party does not try to start a connection in the cheapest way, like for instance VoIP, but it not always result in successful connection. Instead of that, the Calling Party selects the most possible and effective form of contact (telephone connection), and usually there is a mobile phone number. Additionally, in everyday communication one of the biggest obstacles is a problem of identifiers used for contacts (like telephone numbers, Fax, www addresses, e-mail or postal adresses). The change of numbers can be connected with a change of telephone numbers (for example as a result of a postal addresse change) or with the change of the operator. This problem is especially increasing in those countries, where the number portability hasn't been implemented or when an implementation of that mechanism was not fully completed. Concept of the solution based on Enterprise-ENUM. In order to make an optimal choice of the way of connection, the user (subscriber) can use information included in DNS (see [7],[8]) in form of ENUM domains and NAPTR records (see [2],[3],[4],[6]). The public available ENUM base (User-ENUM) includes information regarding accessible for the subscriber forms of contact as well as information about preferred forms of contact. Unfortunately, the information regarding preferred forms of contact shows only preferences of the called person, not preferences of a person who initiated a connection. That is why this information could be not adequate for The Caller. The assumption of solution presented in this document is made as follows: on the basis of the history of established connections as well as information about actual and obligatory telecommunications rates, a switchboard (or external to it module) will analyze data and the results (preferences regarding contacts) will be saved in the local DNS. In case when the subscriber (The Caller) initiating a connection, would inquire the ENUM database about available forms of contact (and this inquiry will be transferred to Enterprise -ENUM instead to User -ENUM database), The Caller will get an information, which will let him to choose the cheapest form of telecommunication connection. Remark: Assuming that on the basis of previous established connections and valid pricelists for telecommunication services, the costs of connections are analyzed and on that basis Enterprise-ENUM database is filled. The method of optimization as well as information structure of databases concerning established connections and telecommunication rates is not a part of presented paper and will be described in another document. In this document, in chapter "Overview of Enterprise-ENUM updating algorithm" is only presented a general overview of the algorithm which describes updating of data included in local DNS (Enterprise-ENUM). Availability of "Enterprise-ENUM" database "Enterprise-ENUM" is based on that same mechanism as "User-ENUM". The only difference between them is in their availability. In case of "user-ENUM" an access is unlimited (public). For "Enterprise-ENUM" database an access is not public, and particularly an access is possible only for certain persons (e.g. employees of the company that owns that database). "Enterprise -ENUM" could be considered in some cases as an "Infrastructure ENUM" in accordance with description given by ETSI [1]. Thanks to that approach it is possible to: a. Consider saved information as confidential information. We assume, that data in "Enterprise-ENUM " database might have a confidential character because of included contacts to subscribers, with whom we have been contacted. On basis of this data, it would be possible to conclude other information, for instance preferred way of communication. At the same time it would give information about habits of subscriber. b. Save information in DNS, which could be valuable only in particular part of the network and they might not be applicable for persons in other environment (other point of network, serviced by other provider and according to his pricelist) Content of "User-ENUM" and content of "Enterprise -ENUM". "User-ENUM" stores one ENUM domain and set of NAPTR records for every subscriber. An exemplary record taken from "User-ENUM" database: 0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 100 10 "up" "tel+E2U" "!^.*$!tel:+48225231200!". 0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "up" "tel+E2U" "!^.*$!tel:+48225231204!". 0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 300 10 "up" "sip+E2U" "!^.*$!sip:204@obelix.nask.waw.pl!". 0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 300 20 "up" "mailto+E2U" "!^.*$!email: info@nask.biz!". 0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 300 30 "up" "tel+E2U" "!^.*$!tel:+48225231395!". For every subscriber, Enterprise-ENUM stores as many domains as identifiers of services (phone numbers) he has. At the same time, for every domain name NAPTR records describing other forms of contact are kept An exemplary record in "Enterprise -ENUM" database related with mentioned above record in "User-ENUM" database: 0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 100 50 "5oup" "sip+E2U" "!^.*$!sip:204@obelix.nask.waw.pl!". 0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U" "!^.*$!tel:+48225231200!". 0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U" "!^.*$!tel:+48225231204!". 0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 100 "oup" "tel+E2U" "!^.*$!tel:+48225231395!". 4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 100 50 "5oup" "sip+E2U" "!^.*$!sip:204@obelix.nask.waw.pl!". 4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U" "!^.*$!tel:+48225231200!". 4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U" "!^.*$!tel:+48225231204!". 4.0.2.1.3.2.5.2.2.e164.arpa NAPTR 200 100 "oup" "tel+E2U" "!^.*$!tel:+48225231395!". 0.0.2.1.3.2.5.2.2.e164.arpa NAPTR 100 50 "5oup" "sip+E2U" "!^.*$!sip:204@obelix.nask.waw.pl!". 5.9.3.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U" "!^.*$!tel:+48225231200!". 5.9.3.1.3.2.5.2.2.e164.arpa NAPTR 200 10 "9oup" "tel+E2U" "!^.*$!tel:+48225231204!". 5.9.3.1.3.2.5.2.2.e164.arpa NAPTR 200 100 "oup" "tel+E2U" "!^.*$!tel:+48225231395!". Extensive meaning of NAPTR fields in "Enterprise-ENUM" Format (The packet format of the NAPTR RR) of the NAPTR record is not changed and is in accordance with [4]. The packet format for the NAPTR record is as follows: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / ORDER / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / PREFERENCE / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / FLAGS / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / SERVICES / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / REGEXP / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / REPLACEMENT / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ We assume, that in NAPTR records we store following additional data related with every contact: -[ORDER] of initiating a connection regarding to order of choosing contacts (in accordance with an order of choosing NAPTR records). Preferences of the Caller do not have to be the same as preferences of the called person which are to be found in "public" DNS (User ENUM). -[PROBAILITY] probability of correct initiation of connection with a certain telephone number (remark: it refers to every NAPTR record, also NAPTR record for an e-mail addresse, being the integer in range from 0 to 100. -[QUALITY] Overal quality indicator from the point of view of the Caller. Mentioned above indicator will be marked with a flag having value from 0 to 9 (range limited by RFC 3403), where "0" indicates not acceptable quality of connection, and "9" indicates an "ideal" connection (it means with a constant and acceptable delay, without lost of packets etc.). The quality of connection can be determined on the basis of any parameter identifying the quality of connection; in particular for VoiP it could be the parameter MOS-LQ (Mean Opinion Score Listening Quality) or MOS-CQ (Mean Opinion Score Conversional-Quality). Parameters MOS-LQ and MOS-CQ are in the range from 1 to 5. For MOS-LQ and MOS-CQ the value [QUALITY] will be defined with following formula: [QUALITY]=MOS-LQ *2-1 or [QUALITY]=MOS-CQ *2-1 Fields described in this paragraph will be coded in existing fields of NAPTR RR in the following way: -[ORDER] field of modified standard will be saved as [ORDER] field of an existing standard (the meaning of that field will be changed). -[PROBABILITY] field of modified standard will be saved as the [PREFERNCE] field of existing standard (the meaning of this field will be changed) -[QUALITY] field will be changed to a flag (integer from 0 to 9), placed in [FLAGS] field of existing standard. Updating of DNS zone files for Enterprise-ENUM Another problem is the definition of DNS zone files for Enterprise-ENUM updating frequency. Having limited (particularly it might be one) number of DNS servers for "Enterprise-ENUM", and moreover definitely smaller number of NAPTR records in comparison with "User-ENUM" (in this case the number of NAPTR records depends on the number of subscribers with whom the company contacts and on number of unique contacts to subscribers), DNS zone files can be updated many times within 24 hours. It is possible to make general estimations in order to compare "User-ENUM"with "Enterprise -ENUM": Assuming that for every ENUM domain five NAPTR RRs are existing (one record for mobile number, home number, fax, e-mail addressee and addressee for SIP [5]).Simplifying, we can assume, that the company contacts 10 000 subscribers, what gives 50 000 NAPTR records. For comparison, in public DNS we can expect 27 millions domains ENUM (the number of telephones in Poland in the year 2003), what makes 135 millions of NAPTR RRs. As we can see from this comparison, use of the local DNS for ENUM gives an advantage because of possible much easier updating of zone files ("Enterprise-ENUM " is potentially four times smaller than the "User-ENUM). Optimization algorithm using Enterprise-ENUM database During establishing of connection, switchboard (telephone exchange) checks Enterprise - ENUM and User - ENUM databases according to the following algorithm: Establishment of connection 1. The Switchboard MUST query the "Enterprise-ENUM" database. 2. In response a switchboard receives a list of NAPTR records or information about lack of record in DNS. 3. The switchboard is trying to establish a connection, considering the sequence of NAPTR records by including parameters saved in fields: ORDER and PREFERENCE. When connection is established, an algorithm is finished. 4. If there is a lack of record in Enterprise-ENUM database, the switchboard MUST query User-ENUM database. 5. As a response, switchboard receives a list of NAPTR records or information about lack of record in DNS. 6. Switchboard is trying to establish a connection, considering the sequence of NAPTR records by including parameters saved in fields: ORDER and PREFERENCE. Enterprise-ENUM database has to be filled in with correct data, before it will be used for optimization. Overview of "Enterprise-ENUM" updating algorithm For the presentation of below algorithm, we assume (simplifying) that history of previous connections (phone calls) is stored in Connections Database, information about cost are kept in Rates database, and subsystem responsible for cost analysis will be called as "Optimization Module" (Detailed description of Optimization Module, Rates database, and Connection database will be presented in separate document). 1. Optimization Module selects first contact from Connections database and retrieves from the contact (history of particular connection), identifier (phone number, SIP address) of subscriber 2. For given identifier, Optimization Module retrieves from "User-ENUM" database lists of available NAPTR records. 3. Optimization Module retrieves from Connection database all contacts (histories of particular phone connections), performed for particular subscriber, regarding each identifier (phone number, SIP adress) received in step 2 of this algorithm. As the result, there is a list of all contacts (history of calls) realized in every possible way (voice calls for all known numbers - subscriber's identifiers), that were in Connection database. 4. On the basis of data stored in Connection database and Rates database, sequence of contacts to particular subscriber is being determined (from cheapest to most expensive). Additionally, for each identifier, there is determination of probability of correcting initiation contact, and evaluation of average connection quality. a. Algorithm may consider those forms of contact, which were not considered in history of connections, determining in advance some values for quality of the connection and probability (i.e. [QUALITY]=5 for all contacts) 5. All identifiers with determined parameters are saved in zone file in "Enterprise-ENUM" database in accordance with fields description (see subsection "Extensive meaning of NAPTR fields in Enterprise-ENUM") a. For every identifier , internet domain is created and for this domain NAPTR records are created, related with all other contacts (e.g. for 3 numeric contacts there are 3 domains and totally 9 NAPTR records being created) 6. Optimization Module marks all contacts (calls) stored in Connection Database that has been completed with given subscriber, in order to omit these records within next loop of the algorithm. 7. Optimization Module searches another possible contact from Connection Database and goes to the step 2 of this algorithm. a. If there are no records to be retrieved from Connection Database, algorithm ends, saving the results as a file of "Enterprise-ENUM" database. IANA Considerations This document introduces no new values for IANA registration Terms and Definitions Calling Party- The end user trying to establish a voice call by using an E.164 number related to the called user. Called Party - The end user related to the Identifier (i.e. E164 number) given by the calling user. Address - definition of telecommunication or IT subscriber address (in accordance with E.164), addresses of VoIP subscribers ( SIP URL-adresses [5]), addresses of applications like Instant Messenger etc. SIP URL - address for VoIP connection using SIP. SIP URL takes a form similar to a "mail to" form i.e. user@host. The user part is a user name or a telephone number. The host part is either a domain name or a numeric network address. Operator - provider of telecommunication and IT services, which offers different types of services, e.g. fixed (stationary) lines, mobile telecommunications, VoIP etc. Abbreviations and Acronyms DNS: Domain Name System IETF:Internet Engineering Task Force ITU: International Telecommunication Union NAPTR: Number Authority Pointer Record RFC: Request For Comment (IETF related standard) SIP: Session Initiation Protocol RRs: (DNS) Resource Record E.164: "The International Public Telecommunications Numbering Plan" ENUM: TElephone NUmber Mapping - both a protocol and an IETF Working Group ETSI: European Telecommunications Standards Institute References [1] "TS 102 055 Services and Protocols for Advanced Networks (SPAN); Scenarios for User and Infrastructure ENUM" the European Telecommunication Standards Institute [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard", RFC 3401, www.ietf.org, February 2002. [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, www.ietf.org, February 2002. [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database", RFC 3403, www.ietf.org, February 2002. [5] Handley, "SIP: Session Initiation Protocol", RFC 2543, www.ietf.org, March 1999 [6] Bartosiewicz, A., "ENUM - how does it work" Newsletter ISOC-UK http://www.england.isoc.org/newsletter/Issue-04-January-03.rhtm [7] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, www.ietf.org, November 1987. [8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, www.ietf.org, November 1987. [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, www.ietf.org, March 1997 Copyright Statement: Copyright (C) NASK 2004. All Rights Reserved. Author address: Andrzej Bartosiewicz Head of DNS Dept. NASK 18 Wawozowa Str. PL-00-796 WARSAW Andrzej.Bartosiewicz@NASK.pl