Internet Engineering Task Force Radhika R. Roy Internet Draft AT&T draft-roy-iptel-intra-itad-fw-00.txt January 7, 2002 Expires: July 7, 2002 A Framework for Intra-ITAD Communications Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as 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 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 document describes a framework for the intra-Internet Telephony Administrative Domain (Intra-ITAD) communications protocol. The intra-ITAD communications scenarios are analyzed. The requirements how the protocol will provide alias addresses resolution for routing a call to the appropriate gateway are described along with other attributes like capacity and QoS. The document describes specifics for communications between the gateways and servers as well as among the servers for discovery, registration, efficient selective updates of addresses, address aggregation, and reliability. The document also provides the framework how the intra-domain protocol will complement the inter-domain routing protocol, TRIP, in the broader context of Internet Telephony. Radhika R. Roy [Page 1] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 Table of Contents 1. Introduction 3 2. Conventions used in this document 3 3. Terminology 3 4. Motivation for Intra-ITAD Communications Protocol 4 5. Intra- and Inter-ITAD Communications Protocol Characteristics 5 5.1 Inter-ITAD Communications Protocol 5 5.2 Intra-ITAD Communications Protocol 6 6. Scenarios and Architectures for Intra-ITAD Communications 7 6.1 ITAD Topology 10 6.1.1 Star ITAD Topology 11 6.1.2 Mesh and Star ITAD Topology 11 6. Intra-ITAD Communications Protocol Requirements 14 7. Functional Entities 15 7.1 Internet Telephony Administrative Domain 15 7.2 Gateway 16 7.3 Location Server 17 7.4 End Users 17 8. Functional Entity Interactions 18 8.1 Gateways and Location Servers 18 8.2 Location Server to Location Server 19 8.3 Nature of Exchanged of Information 20 8.4 Quality of Service 21 8.5 Cost Information 21 9. Alias Address Translations 22 10. Security 23 11. References 23 Acknowledgments 23 Author's Addresses 23 Full Copyright Statement 23 Radhika R. Roy [Page 2] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 1. Introduction The framework of the intra-Internet Telephony Administrative Domain (Intra-ITAD) communications protocol is described in this document. The primary objective has been to specify requirements how the protocol will provide alias addresses resolution for routing a call to the appropriate gateway, not route processing, aggression, or propagation. In addition, the attributes like capacity and quality- of-service that are localized to the gateways, not between the source-destination path, are also addressed. The communications specifics like discovery, registration, efficient selective updates of addresses, address aggregation, and reliability are also described as a part of the requirements. The document also provides the framework how the intra-ITAD protocol will complement the inter-ITAD TRIP protocol [2] in the broader context of the Internet Telephony. 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 [3]. 3. Terminology Gateway: A gateway can be a SIP-ISUP telephony gateway, SIP-H.323 telephony gateway, or other type of gateways. A SIP-ISUP telephony gateway can be a device with some sort of circuit switched network (e.g., PSTN) connectivity and IP connectivity, capable of initiating and terminating IP telephony signaling protocols, and capable of initiating and terminating telephone network signaling protocols (e.g., ISUP). A SIP-H.323 telephony gateway can provide connectivity between the two IP networks, but uses SIP and H.323 call control signaling protocol in two sides of the interworking gateway. All types of gateways will abstract the address families (e.g., E.164, email Ids, URL Ids, etc.), capacity, quality-of- service (QOS), grade-of-service (GOS), and/or other attributes in a common format that will form the basis for the intra-ITAD communications protocol. End User: The end user is usually (but not necessarily) a human being, and is the party who is the ultimate initiator or recipient of calls. Calling Device: The calling device is a physical entity which has IP connectivity. It is under the direction of an end user who wishes to place a call. The end user may or may not be directly controlling the calling device. If the calling device is a PC, the end user is Radhika R. Roy [Page 3] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 directly controlling it. If, however, the calling device is a telephony gateway, the end user may be accessing it through a telephone. Location Server (LS): A logical entity with IP connectivity which has the knowledge of gateways that can be used to terminate calls towards the PSTN and/or the IP network. The LS is the main entity that participates in routing a call to a particular gateway. The LS is generally a point of contact for end users for completing calls to the telephony network. An LS may also be responsible for propagation of gateway information to other LS's. An LS may be coresident with an H.323 gatekeeper or SIP server, but this is not required. Internet Telephony Administrative Domain (ITAD): The set of resources (gateways and Location Servers) under the control of a single administrative authority. End users are customers of an ITAD. Provider: The administrator of an ITAD. Location Server Policy: The set of rules which dictate how a location server processes information it sends and receives via the intra-ITAD communications protocol. This includes rules for aggregating, propagating, generating, and accepting information. End User Policy: Preferences that an end user has about how a call towards the PSTN should be routed. 4. Motivation for Intra-ITAD Communications Protocol An Internet Telephony Administrative Domain (ITAD) can be a collection of gateways (GW), location servers (LS), IP Telephony End users, IP Telephony Call Signaling servers and/or other functional entities administered by one administrative entity [2]. An ITAD can consist of one or more location server, zero or more gateways, and zero or more end users. This means that there is one authority responsible for dictating the policies and configuration of the GWs and LSs. A GW may provide the interface between the IP and PSTN Telephony network or an interface between the SIP- and ISUP-based telephony network or SIP- and H.323-based telephony network. As telephony gateways grow in terms of numbers and usage, managing their operation will become increasingly complex. There may need to be many LSs within an ITAD to manage those GWs. The GWs may relay the reachability of the address information to the LS while the LS will relay the address information among themselves. Each LS may have its own policy in associating GWs with it. Radhika R. Roy [Page 4] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 It appears that a protocol is needed for communications between GWs and LSs, and among LSs. In intra-ITAD communications environment, the following functions need to be performed by the routing protocol: . First, a GW needs to discover who will be its location server for sending the reachability of the address information or it may so happen if a call comes to a LS and it does not know which GW to route a call, it may also need to discover GWs. . Second, once the discovery is done, a GW need to register all the address reachability information to the LS to which it has made association at the time of the discovery process. . Third, once a LS obtains the information for GWs, the said also needs to be shared among all other LSs within the ITAD. This information needs to be synchronized among all LSs. . Fourth, if there is any update in the prior registered address information, a GW needs to send an update to the LS selectively. The said information also needs to be updated among all other LSs by the location server that has received an update from the GW. . Fifth, syntax and semantics of the data which describe the address information of the telephony GW as well as signaling messages that are sent between the GWs and LSs, and among the LSs. 5. Intra- and Inter-ITAD Communications Protocol Characteristics The inter-domain framework document [2] has provided the basic outline what is required for a inter-ITAD protocol and, TRIP [4] has been designed to meet those requirements considering the routing of E.164/Decimel/Penta-Decimel numbers only. However, TRIP [2], designed for inter-domain communications, does not deal with the intra-ITAD communications. 5.1 Inter-ITAD Communications Protocol The primary characteristics of the inter-domain routing protocol, TRIP [4], fulfilling the requirements defined in the framework document [2] can be summarized as follows: . It propagates only the E.164/Decimel/Penta-Decimel addresses among the ITADs maintained by different providers. . The LSs maintain the peering relationship between the ITADs of different administrative domains. Radhika R. Roy [Page 5] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 . The association between the LSs of different ITADs is pre- provisioned and, no auto-discovery mechanism exists. . How the route information is obtained from the telephony GWs or other LSs by a LS of a given ITAD is not defined. . It determines the IP address of a gateway capable of completing a call to a phone number given that a phone number which corresponds to a terminal on a circuit switched network. . It provides the exchange and synchronization of telephony gateway routing information between providers. . The stable routing loops for IP telephony signaling protocols are prevented. . The propagation of learned gateway routing information is provided to other providers in a timely and scalable fashion. 5.2 Intra-ITAD Communications Protocol The intended intra-ITAD communications protocol that needs to be designed should have the following characteristics: . Should maintain the relationship between GWs and LSs and among LSs within ITAD administered by a single provider and, GWs can be such as telephony GWs and SIP-H.323 GWs. . Need to auto-discover LSs by GWs and vice versa, GWs by LSs, and LSs by LSs. . Should make association between GWs and LSs as well as among LSs dynamically. . Should define the mechanism how the address information to be transferred between GWs and LSs as well as among LSs. . Should determine the IP address of a gateway capable of completing a call: . To a E.164/Decimel/Penta-Decimel phone number given that a E.164/Decimel/Penta-Decimel phone number which corresponds to a terminal on a circuit switched network like PSTN. . To an alias address like email ID, URL ID, etc. to a terminal that is residing in a packet-switched network like IP. . Should synchronize the address information (E.164/Decimel/Penta- Decimel numbers, email ID, URL ID, etc.) in all LSs of an ITAD administered by a single provider. Radhika R. Roy [Page 6] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 . Should provide the address resolution (E.164/Decimel/Penta-Decimel numbers, email ID, URL ID, etc.) and not to perform any route processing, route path selection, or route path propagation. . Need to provide the update of the address information of the GWs among the LSs in a timely and scalable fashion. The above points explain the differences between the intra- and inter-ITAD communications protocol. It appears that the intra-ITAD communications protocol that needs to be developed will be complementing the already developed inter-ITAD protocol known as TRIP [4] for the E.164/Decimel/Penta-Decimel telephony route information. 6. Scenarios and Architectures for Intra-ITAD Communications Figure 1 depicts that a simple configuration where a single SIP Server, with multiple SIP-ISUP telephony or SIP-H.323 telephony GWs, resides in an IP network. However, a SIP-ISUP telephony GW will have interfaces with both IP and PSTN network or a SIP-H.323 telephony GW will have interfaces with both SIP- and H.323-based IP Telephony network. ------------------------------------------------------------------ | | | | ------- ------ | | |SIP | <----------> |GW 1| | | |Serv.| ------ | | IP |/LS | | PSTN | | NETWORK | | ------ Network | |(SIP-based | | <----------> |GW 2| (ISUP-based | | Tel) | | ------ Tel) | | | | . | | | | . | | | | ------ | | | | <----------> |GW n| IP | | | | ------ NETWORK | | | | | (H.323-based | | ------- | Tel) | | | | ------------------------------------------------------------------ Figure 1: A Single SIP Server/LS with Multiple GWs Radhika R. Roy [Page 7] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 In Figure 1, the key features can be described as follows: . The SIP-ISUP telephony/SIP-H.323 telephony GWs and SIP Servers/LSs are deployed by the Internet Telephony Administrator in its own domain and, this can be designated as the Internet Telephony Administrative Domain (ITAD). . It is assumed that SIP Servers are co-located with the Location Server (LS). . The SIP Server and a given GW are, as if, one-hop away for communications and, GWs do not propagate route among themselves using the discovery/registration protocol. . A GW can have association for many more alias addresses over the PSTN/IP network that can be reached through it. . A GW can have its own policy to take decision how a specific destination point can be reachable or whether a call will be accepted for routing. . A GW can also take the decision whether or not it will register/communicate with a particular SIP Server/location server based on its policy. . A GW can have its many attributes like capacity, cost preferences, quality-of-service (QoS), grade-of-service (GoS), extensible parameters (e.g., ISUP variants - ITU-T, ANSI, ETSI), H.323 versions, etc., and others in addition to the reachable destination addresses and policy. . A GW needs to discover a Server/LS (and vice versa, if needed), and, will be able to register/establish communications with the information that is reachable through it for the PSTN or IP network. If needed, the capabilities can also be checked during the discovery phase before registration. . A SIP Server/LS will also be able to discover its peer SIP Servers/LSs, and register with them for communications, if needed. Capability negotiations may also be done during the registration phase if it is not indicated at the time of discovery. Radhika R. Roy [Page 8] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 . A GW (or Server) will be able to know during the registration process which alternate servers (or GWs) it will be able to communicate with in accordance to priority in case the primary server fails to enhance reliability. (Figure 1 does not show this situation, but Figure 2 can be used to depict more than one Server.) . A SIP Server/LS may also be capable to choose any GW independently if multiple GWs are available to route a call in accordance to its policy either based on cost-performance trade-offs or due to failure of the primary GW of its choice for enhancing reliability. Figure 2 provides a scenario where more than one Server/LS are available and, GWs will have the choice to choose any Server for registration in a given ITAD based on its policy. However, a GW should have the mechanism to discover how many Servers are available to register/communicate with in a given ITAD. Radhika R. Roy [Page 9] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 ------------------------------------------------------------------ | | | | ------- ------ | | |SIP | <----------> |GW 1| | | |Serv.| ------ | | IP |1/ | | | | NETWORK |LS 1 | ------ PSTN | |(SIP-based | | <----------> |GW 2| NETWORK | | Tel) | | ------ (ISUP-based | | | | . Tel) | | | | . | | | | ------ | | | | <----------> |GW n| | | | | ------ | | | | . | | ------- . . . . . . . . . . . . | | . | | . | | ------- ------- | | |SIP | <----------> |GW k1| | | |Serv.| ------- | | IP |m/ | | | | NETWORK |LS m | ------- IP | |(SIP-based | | <----------> |GW k2| NETWORK | | Tel) | | ------- (H.323-based | | | | . Tel) | | | | . | | | | ------- | | | | <----------> |GW kj| | | | | ------- | | | | | | | ------- | | | | | ------------------------------------------------------------------ Figure 2: Multiple SIP Servers/LSs with Multiple GWs 6.1 ITAD Topology A Internet Telephony Administrative Domain (ITAD) is expected to have at least one Location Server (LS). It is also expected that there will be gateways (GWs) that interconnect the SIP-based Telephony (e.g., SIP) network to the ISUP-based Telephony Radhika R. Roy [Page 10] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 network. In another scenario, a SIP-based Telephony network may be connected to the H.323-based Telephony network via SIP-H.323 telephony GWs [4]. 6.1.1 Star ITAD Topology Figure 1 shows a simplified ITAD architecture where a single SS/LS is controlling all the GWs (e.g., SIP-ISUP Telephony, SIP-H.323 Telephony). In this star-type architecture the simple discovery and registration are sufficient to satisfy the requirements. In Figure 2, two SSs/LSs are controlling two sets of GWs in their own areas independently. The following situations may arise: . Case 1: No communications exist between the SSs/LSs. That is, communications only exist between a SS/LS and the GWs. . Case 2: Same as case 1, but each SS/LS supplies the address of the other SS/LS as a backup to the GWs at the time of their discovery or registration. . Case 3: Communications exist between SSs/LSs and GWs as well as among SSs/LSs. For simple scenarios like Cases 1 and 2, the discovery and registration mechanisms are good enough to satisfy the requirements. However, additional messages are needed to cover the scenario like case 3 because discovery and registration mechanisms may not be efficient enough. Message updates, confirmations, keep-alive mechanisms, and error notifications are also needed. In other words, we need to build the intra-ITAD protocol to cover all cases efficiently. 6.1.2 Mesh and Star ITAD Topology An ITAD may consist of many GWs and LSs and, Figure 3 shows an ITAD architecture that uses the intra-ITAD Protocol. In Figure 3, an example is shown that the SIP Server is co-located with the LS. The SIP-based IP Telephony ITAD is being interconnected to the ISUP-based Telephony and H.323-based Telephony networks via SIP- ISUP Telephony and SIP-H.323 Telephony GWs, respectively. The intra-ITAD protocol is used between the SIP servers (SSs)/Location Servers (LSs) and GWs as well as among the SSs/LSs. An important observation is that the logical connectivity between the SSs/LSs and the GWs is like star-type architecture and, there is no direct connectivity between the GWs. However, the logical Radhika R. Roy [Page 11] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 connectivity among the SSs/LSs can be star, mesh, or a combination of both. The implication is that the intra-ITAD (iITAD) protocol needs to have the in-built capacity to take care of the redundancy provided because the back-up GWs or SSs/LSs may not be co-located or may not have the same address. SIP-ISUP Tel GWs SIP-ISUP SIP-H.323 Tel GWs Tel GWs | | | | | ... | | ... | ---|----------|---------------------------|----------|-------- | O GW-11... O GW-1i O GW-21 . .O GW-2j | | | | | | | | | iITAD | | iITAD | | | -------------- iITAD -------------- | | | SS/LS-1 |-------------------------| SS/LS-2 | | | | | | | | | -------------- -------------- | | | | | | | | | | iITAD | (SIP-based) IP Telephony Network | iITAD | | | | | | | | | | | | | | -------------- iITAD -------------- | | | SS/LS-3 |-------------------------| SS/LS-4 | | | | | | | | | -------------- -------------- | | | iITAD | | iITAD | | | | | | | | | O GW-31... O GW-3k O GW-41 . .O GW-4m | ---|----------|---------------------------|----------|-------- | ... | | ... | | | | | SIP-ISUP Tel GWs SIP-ISUP SIP-H.323 Tel GWs Tel GWs Notes: iITAD = Intra-ITAD Communications Protocol SS = SIP Server (Proxy, Register, Re-direct) LS = Location Server Figure 3: ITAD Architecture using the Intra-IP Telephony Administrative Domain Communications Protocol Although Figure 3 shows a mesh-like architecture between the SSs/LSs, it can also be star architecture or a combination of both Radhika R. Roy [Page 12] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 star and mesh. However, SSs/LSs can communicate among themselves either directly or indirectly. The intra-ITAD protocol needs to be smart enough to exploit this situation of the logical connectivity among SSs/LSs. Finally, the connectivity among the GWs and the SSs/LSs are logical. The logical connection between GW-31 and SS/LS-3 shown in Figure 3 can be changed using the intra-ITAD communications protocol. That is, it will also be possible to have logical connectivity changed from GW-31 <-> SS/LS-3 to GW31 <-> SS/LS-4 for example. The intra-ITAD protocol needs to be designed in such a way that will allow to auto-discover the GWs and SSs/LSs and registration should be made by the GWs to the SSs/LSs based on the association provided during the discovery process. In this way, the logical connectivity can also be changed dynamically. This simple example explains the fact that the intra-ITAD protocol needs to satisfy the two sets distinct requirements in the following areas for communications: . Between GW and SS/LS - where GWs cannot communicate among themselves (other than via SSs/LSs). . Among SSs/LSs - where SSs/LSs can communicate among themselves directly or indirectly. . Information related to addresses and other attributes between the GW and the SS/LS: GW _ Send mode only and SS/LS _ Receive mode only. That is, a kind of one-way registration type information exchange will be OK. In addition, the intra-ITAD protocol also needs to satisfy other requirements as described later. The operation of the intra-ITAD protocol is independent of any particular IP Telephony signaling protocol (e.g., SIP) and can be used as the routing protocol for any of these protocols (e.g., SIP). The SS/LS topology within a given ITAD is independent of the physical topology of the network. SSs/LSs communicate with the GWs in the application signaling layer (above layer 4) and the logical topology between the SSs/LSs and GWs will also be independent of the physical topology of the network whether the GWs are decomposed or not. Radhika R. Roy [Page 13] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 6. Intra-ITAD Communications Protocol Requirements The intra-domain ITAD communications protocol needs to have unique features. In brief, any protocol method or functional features should have the following: . Need to have a single protocol to optimize the protocol development because the intra-ITAD protocol has unique characteristics that need to be satisfied. . Should maintain the relationship between GWs and LSs and among LSs within ITAD administered by a single provider and, GWs can be such as SIP-ISUP telephony GWs, SIP-H.323 telephony GWs, and others. . Need to auto-discover LSs by GWs and vice versa, GWs by LSs, and LSs by LSs. . Should make association between GWs and LSs as well as among LSs dynamically. . Should define the mechanism how the address information to be transferred between GWs and LSs as well as among LSs. . Should determine the IP address of a gateway capable of completing a call: . To a phone number given that a phone number which corresponds to a terminal on a circuit switched network like PSTN. . To an alias address like email ID, URL ID, etc. to a terminal that is residing in a packet-switched network like IP. . Should synchronize the address information (telephone numbers, email ID, URL ID, etc.) in all LSs of an ITAD administered by a single provider. . Should provide the address resolution (telephone numbers, email ID, URL ID, etc.) and not to perform any route processing, route path selection, or route path propagation. . Need to provide the update of the address information of the GWs among the LSs in a timely and scalable fashion. . Need to deal with telephone addresses in addition to other alias addresses that are reachable through the GWs and, these addresses may not reside in the SIP (or other IP Telephony) network. . Should have the fast call set-up time. Radhika R. Roy [Page 14] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 . Should have the failure detection capability should a failure occurs either to a SIP Server/LS or to a GW. . Need to have the knowledge of the alternate GWs or Servers to contact in order of priority if the primary one fails. . Should have the automatic capability to restart communications with the SIP Server/LS or the GW should a failure occur. . Should have the knowledge of capacity (e.g., number of calls [total, spare], number of ports [total, spare], number of circuits and speeds [total, spare], etc.), QOS, GoS, codecs, bridging capabilities, and other features before forwarding the SIP calls. . Security (authentication, integrity, privacy). . Should convey the gateway selection preferences with probable trade-offs, if possible, between cost and performance. . Should be able to obtain the information (e.g., cost performance trade-offs along with routing preferences,) about both SIP Server/LS and the GW on time along with extensible attributes (e.g., ISUP variant _ ITU-T/ANSI/ETSI, codec support, etc.). . Need to be efficient without generating too many messages while satisfying the requirements. . Should need to have the control with SIP Server/LS how to select a GW and when to forward a call based on the centralized policy. . Should have the independent policy for each SIP Server and the GW residing within a given ITAD. 7. Functional Entities The topologies shown in Figures 1 through 3 consist of number of functional entities that reside in an ITAD. These entities include Internet Telephony Administrative Domain, gateways, location servers, and end users as described in the framework document [2]. 7.1 Internet Telephony Administrative Domain The characteristics of an Internet Telephony Administrative Domain for the intra-ITAD communications protocol can be summarized as follows: . Will have at least one gateway and at least one location server, and zero or more users for using the intra-ITAD protocol. Radhika R. Roy [Page 15] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 . Will be under a single administrative control with one authority responsible dictating the policies and configurations of the gateways and location servers. . Will allow end users in an ITAD to access the gateways to complete the calls. 7.2 Gateway A gateway is a logical device that will connect the two networks of different call control protocols. The one side of the connectivity of the gateway will be the IP network while the other side can be either a telephone network or an IP Network. A gateway is considered a generic term where it can be a monolithic or decomposed. A monolithic gateway (e.g., SIP-ISUP telephony GW, SIP-H.323 telephony GW) deals with both media and signaling in the same entity. A decomposed gateway like MEGACO [5] that can provide SIP- ISUP interworking or SIP-H.323 IWF [6] that handles SIP-H.323 interworking [6] deals with media and signaling in two different entities. For development of the intra-ITAD protocol, it is the signaling part of the gateway that is considered. However, in a generic sense, the function of the gateway is to translate the media and signaling protocols from one network technology to the other, achieving a transparent connection for the users of the system. It may be noted that all types of GWs (e.g., SIP-ISUP Telephony GW, SIP-H.323 Telephony GW) will abstract the address family (e.g., E.164/Decimel/Penta-Decimel), capacity, QOS, GOS, and other attributes in a common format that will form the basis for the intra-ITAD communications protocol. The important attributes of the gateway can be summarized as follows: . Range and sub-range of phone numbers, email IDs, URL IDs, and/or others that a gateway wants to provide services. . Preferences (cost or other factors) associated with each range or sub-range of phone numbers, email IDs, URL IDs, and/or others. . Indicator of capacity or volume of service (e.g., number of simultaneous calls handled/port capacity, access link speed, etc.). . Type of services that a gateway provides (e.g., signaling protocol supported, telephony features provided, speech codecs understood, encryption algorithms implemented, etc.). Radhika R. Roy [Page 16] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 . Type of call services to be provided (e.g., business call with minimal amount of probability of blocking at any time, ordinary call that can be blocked if needed, etc.). In intra-ITAD communications environment, these attributes can be used to select a gateway. However, care will be taken not to make the protocol too complex in choosing the attributes while making it scalable. The another aspect should be to have all attributes that TRIP [4] support to complement each other. 7.3 Location Server A location server (LS) will have the access to the database of the address information that is collected from the gateways. A gateway can be co-located or remotely located to the location server in an ITAD. If the gateway is remotely located, the intra-ITAD protocol that is to be developed needs to be used between the gateways and the location server. A given location server will be controlling a set of gateways and may not have the information of all gateways in an ITAD. There may be more that one location server in an ITAD and, each location server may be controlling a set of gateways within the sphere of its own control. So, the location servers also need to communicate among themselves to transfer information once it is obtained from the gateways to synchronize their databases. TRIP [4] assumes that there will some sort of communications among the locations servers of a given ITAD to have their databases synchronized. Therefore, the intra-ITAD protocol that is to be developed will complement the inter-ITAD TRIP [4] protocol. 7.4 End Users An end user logged into an IP network may wish to call another user who is located in a network that needs to traverse through a gateway. A gateway can be a telephony gateway or a SIP-H.323 gateway although an end user may not be aware that the call is passing through a gateway. In some situations, an user may be aware that the call will be passing through a gateway (e.g., SIP-ISUP telephony gateway, SIP- H.323 telephony GW) and may have preferences how the call should be completed. The preferences can be expressed in call features that should be supported, QoS metrics for each media, owner or administrator, cost preferences, security criteria, and others. The intra-ITAD protocol may also need to deal with end users' preferences indirectly although the protocol itself will nor dictate Radhika R. Roy [Page 17] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 how these preferences will be used in selecting a gateway. The selection of a gateway based on preferences needs to be done by some other means, not to be addressed by the intra-ITAD protocol. 8. Functional Entity Interactions Figures 1 through 3 provide some configurations for the gateways and location servers in an ITAD. A more detail about the interaction among those functional entities is described here. 8.1 Gateways and Location Servers A gateway can be a SIP-ISUP (PSTN) telephony gateway, SIP-H.323 telephony gateway, or other kind of gateway. First of all, gateways need to propagate information to the location servers in an ITAD. To do so, a gateway needs to discover who will be its location server. In an ITAD there can be more than one location server. A location server will control a set of gateways because a many-to-many relationship among the gateways and servers will create problems in managing a large network. Each location server may have its own policy for registering a gateway for advertising the reachable addresses. In the initial stage, a gateway may need to multicast a message in order to discover a location server. If the discovery message is multicast, many location servers may send confirming the request back in a unicast fashion to the gateway depending on the policy and other service criteria. The confirmation message may contain the list of alternate location servers in accordance to priority if the primary one fails. If the criteria are such that a location server will not allow registration of a particular gateway, it should send the reject message. If a gateway receives the reply more than one location server, it will only choose one location server and, will proceed to register with the location server. During registration, the gateway will send the registration message containing all the alias addresses including telephone numbers with range and sub-ranges along with capacity, list of alternate gateways in accordance to priority if the primary one fails and other information. In response, the location server will confirm the registration of the gateway. If any problems, the location server will reject the registration and will send the reason why the registration has been rejected. It may so happen that a location server may not have any information related to the gateway while a call has arrived. In this situation, a location server may also send the discover message to discover the gateway. In response, the gateway will send the registration message to the location server based on its policy if it is not already Radhika R. Roy [Page 18] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 registered with the location server. Then the process will follow as described above. Once the registration process in completed, there may be some changes in the information registered with the location server. If it is so, the gateway will send the update message containing only the information that does not match with the original registration. This information may be of the category of each item: Add, Delete, or Change. However, the location server will never send the update message to the gateway. If the implementation of multicast for auto-discovery is a problem in certain situations, pre-provisioned unicast-based discovery mechanisms (e.g., DNS lookup) can also be used. In addition, the keep-alive message may be sent from time-to-time to find the status and extend the time-to-live counter of the messages. It is expected that the location server will maintain a database to keep all the information. 8.2 Location Server to Location Server The alias addresses including telephone numbers and other information is received from a set of gateways by a location server within an ITAD. The information received from the gateways by a location server needs to be shared among other location servers located within the same ITAD. However, a location server also needs to know about other location servers within the ITAD. Similar to gateways, a location server may require to discover the other peer location servers. As described earlier, a location server will send the discovery message to other location servers using multicast. Unlike gateways, a location server can register to all other location servers. If there are only couple of location servers in an ITAD, these servers can also be pre- configured. The discovery and registration by the location servers will proceed as described in the case of the gateway. However, the appropriate mechanisms can be kept whether a discovery or registration message is sent by either a location server or by a gateway. The communications among the location servers will work as follows: Any information that is received from gateways by a location server will be sent to all other location servers by that location server. When a location server receives any information from the gateway, the same will be sent to all other location servers using the update message. The update message can be sent using either multicast or unicast as appropriate. Radhika R. Roy [Page 19] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 The registration message is used after the discovery and any information received from the gateways by a location server can also be sent during the registration process, if needed. However, registration message is used once and the update message is used thereafter. The keep-alive message is used to know the status and to update the time-to-live counter. The information exchanged among the location servers is synchronized as each one will be sending the update to all others. The updates can be sent in send/receive-only mode. In some cases, the send- receive mode may also be appropriate to increase the efficiency of communications in transferring a bulk of data. 8.3 Nature of Exchanged of Information A gateway will have a set of objects consisting of a range of telephone numbers, email IDs, URL IDs, and/or others which are reachable through it, capacity and other attributes, and an IP address of the gateway. This information will be sent to the location server by the gateway using the intra-ITAD protocol whose characteristics are described earlier. A location server will learn about all alias addresses and other attributes received from a set of gateways and, this information will be sent to all other location servers of the ITAD by the said location server. It may so happen that a location server may aggregate the information in such a way that it will always use the IP address of the gateway, not the IP address of the server itself. This is because all location servers will have the same information synchronized along with the gateway information. Should a call come to any location server, it can take the decision which gateway to send the call directly without sending the call to another location server. For example, if a couple of gateways advertise the same address ranges to a location server, the location server will decide which gateway should actually be reached for this particular address ranges and will send the information accordingly to all other location servers. All location servers will take the same decision to route a call to that particular gateway directly for those address ranges. In another situation, there may be a need for load sharing among the gateways for calls to a range of alias addresses. A location sever may then decide to subdivide the said range of addresses among the gateways based on available circuit capacity, port capacity, and/or Radhika R. Roy [Page 20] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 DSP resources which gateway needs to be contacted during a certain period of time for some particular kinds of calls based on certain policy. The location server will then send the update message accordingly to all other location servers updating this information. All information of all gateways within an ITAD will be synchronized among all location servers. All location servers will be able to know which gateways are already registered and, association of new gateways through registration to a location server will be made after discovery accordingly. In this way, all location servers will make sure that no gateway is registered with more than one location server. 8.4 Quality of Service In addition to capacity that may include available circuit capacity, port capacity and DSP resources, the quality-of-service (QoS) through a gateway can be expressed in terms of losses, delay, jitter, probability of blocking and/or other factors. However, these QoS attributes, if present, will only be considered for the gateway itself only. That is, the QoS on the _path_ between caller and the gateway is not considered. The QoS along the source-destination path requires the knowledge of the underlying network layer (e.g., IP network layer 3) topologies. This network layer QoS is handled by QOS routing protocols and is outside the scope of the intra-ITAD protocol because gateways and location servers are the application layer (i.e., layer 7) entities. However, the gateway capacity [2] is not dependent on the caller location or path characteristics. For this reason, a capacity metric of some form needs to be supported by the intra-ITAD protocol. This metric represents the static capacity of the gateway, not the dynamic available capacity which varies continuously during the gateways operation. Location Servers can use this metric as a means of load balancing of calls among gateways as explained earlier. It can also be used as an input to any other policy decision. 8.5 Cost Information Another useful attribute to propagate is a pricing metric [2]. This might represent the amount a particular gateway might charge for a call. The metric can be an index into a table that defines a pricing structure according to a pre-existing business arrangement, or it can contain a representation of the price itself. The intra-ITAD protocol itself does not define a pricing metric, but one can and should be defined as an extension. Using an extension for pricing means more than one such metric can be defined. Radhika R. Roy [Page 21] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 9. Alias Address Translations A gateway is willing to terminate calls towards some set of alias addresses including phone numbers. Again, a gateway can be a SIP- ISUP telephone gateway, a SIP-H.323 telephony, or other type of gateway. An administrator will decide what alias addresses the gateway is willing to call and policy decision will reside with a location server. In the case of the SIP-ISUP telephony gateway, telephone numbers (e.g., E.164) include which gateway needs to be contacted for a given destination address by the location server: _For 1 212 723 4587 send the call request to Gateway A_ _For 1 212 467 * send the call request to Gateway B_ _For 1 718 487 6753 send the call request to Gateway X_ _For 1 * send the call request to Gateway B_ _For private 41* send the call request to Gateway C_ _For 44 372 556*_ doesn't exist_ If it is a SIP-H.323 telephony gateway, the examples can be as follows: _For *@example.org send the call request to Gateway D_ _For *@foo.com send the call request to Gateway E_ _For 1 444 897 * send the call request to Gateway F_ The telephone numbers that is advertised by a gateway are expected to be in close geographic proximity to the gateway. For example, a gateway in New York might be willing to terminate calls to the 212 and 718 area codes. However, a gateway may also advertise the telephone numbers that do not represent the geographical proximity, rather represent services or virtual addresses. An example for such numbers can be freephone and local number portability (LNP). In the telephone network, these are actually mapped to routable telephone numbers, often based on complex formulae. A classic example is time-of-day-based translation. The administrator of an ITAD may decide whether the freephone or LNP numbers will be advertised by the gateway before making translation to a routable number because problems may arise if the routable numbers are not advertised. How a translation is out-of-scope of the intra-ITAD protocol. In some situation, the non-routable number advertisement depends on the time-of-the-day to obtain a particular routable number, the location server that administers the gateways may take the decision to update the information accordingly based on the time-of-the-day. Radhika R. Roy [Page 22] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 10. Security The intra-ITAD protocol needs to be secured because of the sensitivity of the information that is being sent. Like TRIP [4], encryption and end-to-end authentication are needed for the intra- ITAD protocol as well. 11. References [1] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. [2] Rosenburg, J. and Schulzrinne, H., _A Framework for Telephony Routing over IP,_ RFC 2871, IETF, June 2000. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [4] Rosenberg, J., H. Salama, H., and Squire, M., "Telephony routing over IP (TRIP)," Internet Draft, Internet Engineering Task Force, November 2000. Work in progress. [5] Cuervo, N., Greene, N., Huitema, C., Rayhan, A., Rosen, B., Segers, J., _MEGACO Protocol version 0.8,_ RFC 2885, Internet Engineering Task Force, August 2000. [6] Agrawal, H., Roy, R. R., Palawat, V., Johnston, A., Agboh, C., Wang, D., Singh, K., and Schulzrinne, H., "SIP-H.323 Interworking ", draft-agrawal-roy-palawat-sip-h323-interworking-reqs- 00.txt, IETF, April 2000. Work in progress. Acknowledgments TBD Author's Addresses Radhika R. Roy AT&T Room D3_3C09 200 S. Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732 420 1580 Fax: + 1 732 368 1302 Email: rrroy@att.com Full Copyright Statement 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 Radhika R. Roy [Page 23] Internet Draft Framework for Intra-ITAD Protocol January 7, 2002 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. Radhika R. Roy [Page 24]