Internet Engineering Task Force Radhika R. Roy Internet Draft AT&T draft-roy-iptel-itrp-00.txt August 31, 2001 Expires: March 3, 2002 IP Telephony Routing Protocol (ITRP) 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 contribution describes an IP Telephony Routing Protocol (ITRP) for intra-ITAD communications. ITRP is a SINGLE protocol that is used between gateways and servers as well as among servers. It uses discovery, registration, update, keep-alive, confirmation, and error-notification messages. The connectionless (e.g., UDP) transport is used and, if needed, multicasting can be used instead of flooding. The connection-oriented (e.g., TCP) transport can also be utilized. ITRP's operation is independent of any signaling protocol and, can serve as a mechanism to provide the reachability information about alias addresses including telephone numbers. The proposed message formats in ITRP are similar to TRIP. Radhika R. Roy [Page 1] Internet Draft ITRP Protocol August 31, 2001 Discovery can be made considering all entities as peers (e.g., GWs, Servers), and options have been kept to check capabilities before the registration proceeds. Capability negotiations can be done during registration and, mechanisms are provided to find the alternate peers in order of priority for communications if the primary peer fails to enhance reliability. Updates can sent for the information selectively to increase the efficiency of communications. Information about circuit-capacity and other parameters can also be provided as appropriate. Table of Contents 1. Introduction 5 2. Conventions used in this document 5 3. Definitions 6 3.1 SIP User Agent 6 3.2 SIP Server 6 3.3 SIP Proxy Server 6 3.4 SIP Register Server 6 3.5 SIP Redirect Server 6 3.6 Location Server 6 3.7 SIP Phone 7 3.8 Media Gateway 7 3.9 Media Gateway Controller 7 3.10 Internet Protocol 7 3.11 Internet 7 3.12 IP Network 7 3.13 SIP-H.323 Interworking GW 7 4. Internet Telephony Administrative Domain Communications Environment 8 4.1 Telephony GW Characteristics 8 4.2 SIP-H.323 GW Characteristics 8 4.3 MEGACO GW (MGC/MG) Characteristics 9 4.4 SIP Server Characteristics 9 4.5 Interworking Configurations 10 4.5 ITAD Architecture 13 4.5.1 Star ITAD Topology 14 4.5.2 Mesh and Star ITAD Topology 14 5. Intra-ITAD Protocol Features 17 6. IP Telephony Routing Protocol (ITRP) Description 18 6.1 System Models 18 6.1.1 ITAD Configurations 20 6.1.2 Addressing Conventions 20 6.2 ITRP Operation 20 6.2.1 Peer Discovery 20 6.2.1.1 Capability Negotiation 21 6.2.1.2 Alternate Peers 21 Radhika R. Roy [Page 2] Internet Draft ITRP Protocol August 31, 2001 6.2.1.3 Timeout 22 6.2.1.4 Discovery using Non-Multicasting Method 22 6.2.2 Registration with Peers 22 6.2.2.1 Alternate Peers 23 6.2.2.2 Registration Time (RT) 23 6.2.2.3 Registration Time Extension (RTE) 23 6.2.2.4 Alternate GWs 24 6.2.2.5 Capacity Attributes 24 6.2.2.6 Registration Cancellation 24 6.2.2.7 Reachable Address Families 24 6.2.2.8 Capability Negotiation 25 6.2.3 Keep Alive Mechanisms 25 6.2.4 Message Update Mechanisms 25 6.2.5 Information Synchronization 25 6.2.6 Advertising Addresses in ITRP 26 6.2.7 Transport Protocol 26 7 ITRP Message Formats 26 7.1 Message Header Format 27 7.2 Request Messages 27 7.2.1 DISCOVER Message Format 27 7.2.2 REGISTER Message Format 30 7.2.3 Message-Update Message Format 33 7.2.4 Keep-Alive-Message Message Format 35 7.3 Response Message 36 7.3.1 CONFIRM Message Format 36 7.3.2 Request-Failure Message Format 37 8 ITRP Attributes 39 8.1 Address Format, Family and Application Protocol 39 8.1.1 E.164 Numbers 39 8.1.2 Decimal Routing Numbers 39 8.1.3 Penta-Decimal Routing Numbers 39 8.1.4 Email-Ids 40 8.1.5 SIP-URLs 40 8.1.6 H323-Ids 40 8.2 Address Aggression 40 8.3 Address Advertisement 40 9. ITRP Error Detection and Handling 41 9.1 Message Header Error Detection and Handling 41 9.2 DISCOVER Message Error Detection and Handling 41 9.3 REGISTER Message Error Detection and Handling 41 9.4 MESSAGE-UPDATE Message Error Detection and Handling 41 9.5 KEEP-ALIVE-MESSAGE Error Detection and Handling 41 9.5.1 Time-To-Live Expired Error Handling 41 9.6 RJECTION Message Error Detection and Handling 41 10 ITRP Version Negotiation 42 11 ITRP Capability Negotiation 42 12 MESSAGE-UPDATE Handling 42 13 ITRP Transport 42 14 IANA Considerations 42 14.1 ITRP Capabilities 42 Radhika R. Roy [Page 3] Internet Draft ITRP Protocol August 31, 2001 14.2 ITRP Attributes 42 14.3 Destination Address Families 42 14.4 ITRP Application Protocols 42 15. Issues with ITRP Protocol 42 16. Analysis of the ITRP Protocol in view of its Requirements 43 17. Policy 45 18. Security 45 19. Comparison of ITRP with other Intra-ITAD Protocol Proposals 45 19.1 TRIP-GW Proposal 45 19.2 GW-SLP Proposal 46 19.3 TRIP 48 12. Conclusion 49 13. References 50 Acknowledgments 51 Author's Addresses 51 Full Copyright Statement 51 Radhika R. Roy [Page 4] Internet Draft ITRP Protocol August 31, 2001 1. Introduction In IP-PSTN interworking environment, a SIP [2] call from the IP network may traverse to the PSTN network via a gateway (GW). In TRIP [3], a Location Server (LS) takes the routing decision and, a LS can be co-located with a call signaling server like SIP. A LS can also be called a Route Server (RS). For simplicity, a LS (or RS) is also referred as server in this contribution. Like TRIP, it is also assumed that a location server (or router server) is co-located with a call signaling server like SIP. However, a LS (or RS) will have the intelligence for routing. A GW [4, 5] may have many destination addresses that need binding to the address of the GW. A SIP Server/LS needs to know not only the address of the GW itself, but also all of the destination addresses that are reachable through the GW so when a SIP call arrives with a destination address that is reachable through a GW can be destined appropriately. At first, a telephony or SIP-H.323 GW connected to the IP network requires to discover [6] a SIP Server/LS which one will be its Server/LS server based on some independent policy decision for both although a Server/LS will have a centralized control. In another situation, if a SIP call arrives to a SIP Server/LS and if it does not know GWs, a SIP Server/LS will also be able to discover [6] GWs and destine the call accordingly based on resources availability and cost-performance trade-offs. Once the discovery [6] is performed, a telephony or SIP-H.323 GW connected to the IP network needs registration [7] with the SIP Server/LS a set of telephone numbers/prefixes or other aliases to its address that can be reachable for SIP calls. Again, the reachability of telephone and/or other alias addresses need to be communicated among the SIP Servers/LSs of the given ITAD. The important point is that the SIP Servers/LSs are learning about the reachability while GWs only advertise the reachability information. These two fundamental differences in communications make the proposed Intra-domain IP Telephony Routing Protocol (ITRP) unique to meet the requirements of the intra-Internet Telephony Administrative Domain (intra-ITAD) communications. 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 [8]. Radhika R. Roy [Page 5] Internet Draft ITRP Protocol August 31, 2001 3. Definitions 3.1 SIP User Agent A logical entity which can act as both SIP user agent (UA) client and SIP user agent server. An UA consists of two functional entities: User Agent Client (UAC) and User Agent Server (UAS). An UAC initiates the SIP request while an UAS contacts the user and returns a response on behalf of the user. 3.2 SIP Server A SIP server can be either SIP Proxy, Redirect, Location or Registrar server. 3.3 SIP Proxy Server A logical entity which acts as both server and a client. SIP messages will be processed and passed to other SIP entities. A SIP Server interprets, and, if necessary, rewrites a SIP message before forwarding it. 3.4 SIP Register Server A SIP registrar is a server that accepts REGISTER requests from SIP endpoints. A SIP registrar is typically co-located with a SIP Server or SIP redirect server and MAY make its information available through the location server. 3.5 SIP Redirect Server A logical entity which is primarily used for address translation and locating a SIP user. It may take the help of location server for locating a SIP user. SIP redirect server does not accept calls and does not initiate a SIP request on behalf of a calling SIP endpoint. SIP redirect server sends a response to a request for locating SIP user. 3.6 Location Server A location server (LS) in ITRP is to exchange information between the gateways (GWs) and itself and, with other LSs within a given Internet Telephony Administrative Domain (ITAD) where all resources (e.g., LSs, GWs, Servers) within an ITAD are under the control of a single administrative control. That is, the information exchanges occur only in the intra-ITAD environment. The information exchanged by a LS may include the reachability of telephone and other alias destinations, information about GWs towards those telephone or other aliases destinations residing in different networks outside the Radhika R. Roy [Page 6] Internet Draft ITRP Protocol August 31, 2001 given ITAD. A LS may be co-resident with a SIP server or others, but this is not required. 3.7 SIP Phone The term used to represent all end-user devices that originate SIP calls over the IP network. A SIP phone will act as the SIP UA. 3.8 Media Gateway A Media Gateway (MG) function provides the media mapping and/or transcoding functions between the PSTN/SCN and the IP/Internet. An MG might terminate PSTN/SCN facilities (trunks, loops), packetize the media stream and deliver packetized traffic to the IP/Internet packet network. It would perform these functions in the reverse order for media streams flowing from the IP/Internet packet network to the PSTN/SCN. For example, RFC 2885 (MEGACO protocol) describes the detail functionality of the MG. 3.9 Media Gateway Controller A Media Gateway Controller (MGC) is a signaling entity that controls a MG. Unlike MG, a MGC does not deal with media. For example, RFC 2885 (MEGACO protocol) describes the detail functionality of the MGC. 3.10 Internet Protocol The Internet Protocol (IP) that is considered can be IP version 4 and version 6. 3.11 Internet The public network that uses that uses the Internet Protocol (IP) is known as the Internet. 3.12 IP Network A network (can be owned by a carrier, ISP, public Internet, or otherwise) uses the IP protocol is known as the IP network. There can be one or many IP networks that carry the SIP signaling messages and media streams between the source-destination path. 3.13 SIP-H.323 Interworking GW A SIP-Interworking GW is a signaling GW that provides the translation between the signaling messages of SIP and H.323 and does not deal with media. This GW is also known as SIP-H.323 interwoking function (IWF) [4]. Radhika R. Roy [Page 7] Internet Draft ITRP Protocol August 31, 2001 4. Internet Telephony Administrative Domain Communications Environment The IP network may have gateways (GWs) for interworking with the PSTN or IP network. A SIP Server/LS may control one or several GWs to complete the SIP calls. However, an IP network may consist of SIP Servers/LSs, GWs, SIP Phones, and other SIP servers (Registers, Redirection Servers) and, these resources may be controlled by a given administrator and the system is termed as the Internet Telephony Administrative Domain (ITAD) [9]. 4.1 Telephony GW Characteristics A telephony GW provides the interface between the IP and PSTN network. Knowing the telephone numbers, a SIP Server/LS may send the SIP calls to the GWs as follows: Telephone number examples include which GW needs to be contacted for a given destination address by the SIP Server/LS: _For 1 333 723 4587 send the call request to Gateway A_ _For 1 333 467 * send the call request to Gateway B_ _For 1 333 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_ In addition to the telephone number, the GWs may have other attributes such as capacity (number of calls that can be handled, port numbers, number of circuits along with speed, etc.), cost, QoS, GoS, codecs, bridging capabilities, policy, and other features. A SIP Server/LS may need to know all those features and functions before taking a decision to forward a call to a GW. A telephony GW may be a monolithic GW that handles both signaling and media. However, a GW can also be a decomposed GW where the signaling and media are handled separately (e.g., MEGACO in Section 4.3). 4.2 SIP-H.323 GW Characteristics A SIP-H.323 GW or IWF is a signaling entity that provides interwoking of the call signaling functions between the SIP and H.323 network. This GW or IWF will be able to handle calls that will have both SIP and H.323 addresses and, SIP and H.323 addresses may contain both telephony numbers and alias addresses. In addition to the telephony addresses as shown in the case of the telephony GW (Section 4.1), the following can also be taken by this entity so that a SIP call can be routed to appropriate GWs: _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_ Radhika R. Roy [Page 8] Internet Draft ITRP Protocol August 31, 2001 Similar to the telephony GW, this GW may also have the attributes like capacity (number of calls that can be handled, port numbers), policy, and others. 4.3 MEGACO GW (MGC/MG) Characteristics The MEGACO protocol has the entity known as the media gateway controller (MGC) that controls the media gateway (MG). MG that controls the media resides between the SIP/IP and the PSTN network. However, a MGC may have the signaling interface between the PSTN and IP network. Like a telephony GW, a MGC/MG will have all the telephony addresses (Section 4.1). 4.4 SIP Server Characteristics A logical entity which acts as both server and a client and, it may be assumed that a SIP Server [3] is co-located with the Location Server [3] in a given ITAD because it is assumed that no separate protocol is used between the SIP Server and the LS. SIP messages will be processed and passed to other SIP entities by the SIP Server. A SIP Server interprets, and, if necessary, rewrites a SIP message before forwarding it. It is also assumed that a GW may have the SIP entity like UA (UAC, UAS) and, as such, the SIP Server will be able to communicate with the GW as well. Radhika R. Roy [Page 9] Internet Draft ITRP Protocol August 31, 2001 4.5 Interworking Configurations Figure 1 depicts that a simple configuration where a single SIP Server server, with multiple telephony or SIP-H.323 GWs, resides in an IP network. However, a telephony GW will have interfaces with both SIP and PSTN network or a SIP-H.323 GW will have interfaces with both SIP- and H.323-based IP Telephony network. ------------------------------------------------------------------ | | | | ------- ------ | | |SIP | <----------> |GW 1| | | |Serv.| ------ | | IP |/LS | | PSTN/ | | NETWORK | | ------ | |(SIP-based | | <----------> |GW 2| | | IP Tel) | | ------ | | | | . | | | | . | | | | ------ | | | | <----------> |GW n| IP | | | | ------ NETWORK | | | | | (H.323-based | | ------- | IP Tel) | | | | ------------------------------------------------------------------ Figure 1: A Single SIP Server/LS with Multiple GWs In Figure 1, the key features can be described as follows: . The telephony/SIP-H.323 GWs and SIP Servers/LSs are deployed by the Internet Telephony/SIP-H.323 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) [3]. . 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. Radhika R. Roy [Page 10] Internet Draft ITRP Protocol August 31, 2001 . 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. . 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. Radhika R. Roy [Page 11] Internet Draft ITRP Protocol August 31, 2001 Figure 2 provides a scenario where more than one Server/LS is 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 12] Internet Draft ITRP Protocol August 31, 2001 ------------------------------------------------------------------ | | | | ------- ------ | | |SIP | <----------> |GW 1| | | |Serv.| ------ | | IP |1/ | | PSTN/ | | NETWORK |LS 1 | ------ IP | |(SIP-based | | <----------> |GW 2| NETWORK | | IP Tel) | | ------ (H.323-based | | | | . IP Tel) | | | | . | | | | ------ | | | | <----------> |GW n| | | | | ------ | | | | | | | ------- | | | | | | | | | ------- ------- | | |SIP | <----------> |GW k1| | | |Serv.| ------- | | IP |m/ | | PSTN/ | | NETWORK |LS m | ------- IP | |(SIP-based | | <----------> |GW k2| NETWORK | | IP Tel) | | ------- (H.323-based | | | | . IP Tel) | | | | . | | | | ------- | | | | <----------> |GW kj| | | | | ------- | | | | | | | ------- | | | | | ------------------------------------------------------------------ Figure 2: Multiple SIP Servers/LSs with Multiple GWs 4.5 ITAD Architecture A Internet Telephony Administrative Domain (ITAD) is expected to have at least one Location Server (LS) [3]. It is also expected that there will be gateways (GWs) that interconnect the IP Telephony (e.g., SIP) network to the PSTN Telephony network. In Radhika R. Roy [Page 13] Internet Draft ITRP Protocol August 31, 2001 another scenario, a SIP-based IP Telephony network may be connected to the H.323-based IP Telephony network via SIP-H.323 GWs [4]. 4.5.1 Star ITAD Topology Figure 1 shows a simplified ITAD architecture where a single SS/LS is controlling all the GWs (e.g., PSTN Telephony, SIP-H.323). In this star-type architecture the simple discovery [6] and registration [7] 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 [6] and registration [7] mechanisms are good enough to satisfy the requirements. However, additional messages are needed to cover the scenario like case 3 because discovery [6] and registration [7] 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 ITRP protocol to cover all cases efficiently. 4.5.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 IP Telephony Routing Protocol (ITRP). 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 PSTN Telephony and H.323-based IP Telephony networks via PSTN Telephony and IP Telephony GWs (SIP-H.323 IWFs), respectively. The ITRP protocol is used between the IP Telephony 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 Radhika R. Roy [Page 14] Internet Draft ITRP Protocol August 31, 2001 is no direct connectivity between the GWs. However, the logical connectivity among the SSs/LSs can be star, mesh, or a combination of both. Radhika R. Roy [Page 15] Internet Draft ITRP Protocol August 31, 2001 The implication is that the ITRP 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. PSTN Tel. GWs PSTN Tel GWs SIP-H.323 GWs | | | | | ... | | ... | ---|----------|---------------------------|----------|-------- | O GW-11... O GW-1i O GW-21 . .O GW-2j | | | | | | | | | ITRP | | ITRP | | | -------------- ITRP -------------- | | | SS/LS-1 |-------------------------| SS/LS-2 | | | | | | | | | -------------- -------------- | | | | | | | | | | ITRP | (SIP-based) IP Telephony Network | ITRP | | | | | | | | | | | | | | -------------- ITRP -------------- | | | SS/LS-3 |-------------------------| SS/LS-4 | | | | | | | | | -------------- -------------- | | | ITRP | | ITRP | | | | | | | | | O GW-31... O GW-3k O GW-41 . .O GW-4m | ---|----------|---------------------------|----------|-------- | ... | | ... | | | | | PSTN Tel. GWs PSTN Tel GWs SIP-H.323 GWs Notes: ITRP = Intra-domain IP Telephony Routing Protocol SS = SIP Server (Proxy, Register, Re-direct) LS = Location Server (or Route Server) Figure 3: ITAD Architecture using the Intra-Domain IP Telephony Routing Protocol Although Figure 3 shows a mesh-like architecture between the SSs/LSs, it can also be star architecture or a combination of both star and mesh. However, SSs/LSs can communicate among themselves either directly or indirectly. The ITRP needs to be smart enough to exploit this situation of the logical connectivity among SSs/LSs. Radhika R. Roy [Page 16] Internet Draft ITRP Protocol August 31, 2001 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 IP Telephony routing 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. ITRP 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 ITRP 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. . Routing information 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, ITRP also needs to satisfy other requirements as described later. ITRP's operation 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 [5]. 5. Intra-ITAD Protocol Features 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. Radhika R. Roy [Page 17] Internet Draft ITRP Protocol August 31, 2001 . 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. . 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. 6. IP Telephony Routing Protocol (ITRP) Description 6.1 System Models The intra-ITAD topology is such that a set of GWs can communicate with its SIP Server/LS peer and, all SIP Servers/LSs can communicate among themselves. A GW can be a monolithic telephony GW, decomposed GW (MGC/MG), or SIP-H.323 GW. A call signaling server can be a SIP server. A SIP server can be a proxy, registrar, or re-direct server. A SIP server can be co-located with a Location Server (or Route Server). However, the location server (or route server) will have Radhika R. Roy [Page 18] Internet Draft ITRP Protocol August 31, 2001 the intelligence for routing. The proposed ITRP protocol is used between the GWs and Location Servers (LSs) [or Route Servers (RSs)] as well as among the Location Servers (LSs) [or Route Servers (RSs)]. The logical connectivity appears to be like this: A sets of GWs advertise their addresses to a SIP Server/LS, as if, there is a logical star connectivity. All SIP Servers/LSs can communicate using multicasting, as if, they are logically fully connected. Unlike TRIP [3], there is no need for the concept of complex and powerful route- aggression, route-creation and route path-selection in this simple intra-TRAD communications environment where address resolutions are the primary concern. The simplicity of the intra-ITAD communications environment helps to develop a simple protocol. The primary objective of the ITRP protocol is the discovery of peers (e.g., GWs, SIP Servers/LSs) that advertise a family of addresses including telephone numbers. These entities need capability negotiations through registration, confirmation, keep-alive messages not to expire the lifetime of messages, updates of the addresses, and rejection if errors occur. The discovery request and confirmation is done based on policy of each entity but the SIP Server/LS may have the centralized control, if needed. The capabilities of peers may also be included whether a particular peer will be associated for communications. Multicast is the most convenient way for the discovery process, but other methods may also be used. Registration is done after discovery of the peer(s). However, a GW may register with only one SIP Server/LS while a SIP Server/LS can register with all its SIP servers/LSs peers, if needed. This may be required for better management of the system as a matter of policy, but no limitation is provided by the protocol. The capability negotiation and advertisement of the addresses are done through the registration message. The updates of the addresses are done using the update request message. If an update is made by a GW to its SIP Sever/LS, the same is multicast by the server to all other SIP Server/LS peers. The confirmation message is sent confirming the request message. The reject response message is sent if any errors occur. The GW communicates with the SIP Server/LS in send-only mode. However, the communications between the SIP Servers/LSs can be send- only, receive-only or send-receive-only mode as appropriate, but a simple send-only mode may be enough in most of the cases. Radhika R. Roy [Page 19] Internet Draft ITRP Protocol August 31, 2001 In general, the connectionless (e.g., UDP) transport is used for communications. However, the connection-oriented (e.g., TCP) transport can also be used, if needed. The UDP is preferred because of easy multicasting capability and, no connection set-up time is needed. 6.1.1 ITAD Configurations Figures 1 through 3 show some configurations of ITADs. Each ITAD is administratively controlled by a single administrator. The connections shown among the SSs/LSs and GWs are logical because all SSs/LSs and GWs are application layer entities. Each application layer entity (e.g., GW, SS/LS) is connected to the IP network having a network address. One of the most important things is that all SSs/LSs of a given administrative domain, unlike inter-ITAD, can be logically connected for intra-ITAD communications. For example, if a SS/LS multicast any information to all other SSs/LSs, it is possible that information can be received by all of them because they are administratively under the control of the a single administrator. That is, the logical connectivity among the SSs/LSs of a given ITAD can be maintained. 6.1.2 Addressing Conventions The addressing convention provides the reachable addresses that can be resolved for routing a call. For example, a SIP call from the IP network needs to destined in the PSTN or IP network via the Telephony or SIP-H.323 GW, respectively. In the POTS network, the addressing schemes can be E.164 numbers, decimal routing numbers, or penta-decimal numbers. In H.323-based IP Telephony network, alias addresses can be E.164, email-ID, h323-id or others. The destination alias addresses with E.164 or others will be supported for resolution in routing a call. 6.2 ITRP Operation 6.2.1 Peer Discovery A discovery protocol [6] is needed to establish association among peers: GWs and SIP Servers/LSs or among SIP Servers/LSs through automatic method because it allows to change the association over time. The GW (or Server/LS) needs to know who is its Server/LS (or GW) and vice versa. A GW may multicast to discover a SIP Server/LS sending a _DISCOVER_ request message. This message can be sent to the Server's/LS's well- known Discovery multicast Address. One or more SIP Servers/LSs may respond with the _Confirm_ message based on the policy of each Radhika R. Roy [Page 20] Internet Draft ITRP Protocol August 31, 2001 Server. If a SIP Server does not want the GW to register/communicate to it based on its policy, it shall return the _Reject_ message. If more than one Server/LS responds, the GW may choose the Server/LS it wants to use based on its own policy. At this point, the GW knows which Server/LS to register/communicate with. The GW can now proceed with registration/communication with the SIP Server. It is recommended that a GW will register with only one SIP Server/LS while a SIP Server/LS can register with all its SIP Servers/LSs. The _DISCOVER_ message may be repeated periodically (i.e., at GW power-up after maintenance), so the Server/LS shall be able to handle multiple requests from the same GW. A well-known IP address and UDP port for multicast communications with the Servers/LSs by the GWs (or vice versa) can be defined (e.g., IP Address = 224.0.X.X; UDP port for multicast = XXXX; X = To be determined). In addition, a well-known UDP port for unicast communications between GWs and Servers can be defined (e.g., UDP port for unicast = XXXX; X = To be determined). More detail about the discovery process can be found in reference [6]. 6.2.1.1 Capability Negotiation The discovery [6] process has also the option to negotiate the capability of the peers, if they like to do so. Based on this, a SIP Server/LS may negotiate capability and the discovery _CONFIRM_ or _REJECT_ message can be sent to the peers accordingly. The capability sets can be whether they will support a particular address family (or families), application protocol(s), and/or send/receive/sendreceive mode. 6.2.1.2 Alternate Peers Alternate peers can also be associated using the discovery message. In order to enhance reliability in the system which uses a Server/LS, the Server/LS may indicate alternate Servers/LSs that may be used in the event of a primary Server/LS failure. The list of alternate Servers/LSs can be provided in the _Alternate-Server_ structure of the _Confirm_ and _Reject_ messages. Similarly, the alternate GW addresses can also be provided by the _Discover_ request message. When a SIP Server/LS discover other peers, they can also provide the list alternate peers to which it can communicate if the primary one fails. Radhika R. Roy [Page 21] Internet Draft ITRP Protocol August 31, 2001 6.2.1.3 Timeout If no Server responds within a timeout, a peer may retry after the timeout. For example, a GW (or SIP Server/LS) may retry the _DISCOVER_ message after the timeout. A GW (or SIP Server/LS) shall not send a _DISCOVER_ message within 5 seconds after sending a previous one. If no response is received, the GW (or SIP Server/LS) may use the manual discovery method. 6.2.1.4 Discovery using Non-Multicasting Method Discovery can also be done using the non-multicasting method. For example DNS method as discussed in [6] can also be used. These methods are non-dynamic where auto-discovery is not possible and, may not be so convenient to be used in intra-ITAD GW-Server communications environment. 6.2.2 Registration with Peers All peers can register with one another using the _REGISTER_ message [7]. A GW (or SIP Server/LS) shall send a _REGISTER_ request message to a SIP Server/LS. This message is sent to the Server's/LS's transport address. The GW (or SIP Server/LS) has the network address of the SIP Server/LS known from the discovery [6] process and uses the well-known port. The SIP Server/LS will respond with either _Confirm_ or _Reject_ message. The rejection of the registration message may include many reasons including security, policy, and others. A GW shall only register with a single SIP Server/LS, but a SIP Server/LS can register with all its SIP servers/LSs peers. However, in the confirmation message, a SIP Server/LS may send a list alternate SIP Servers/LSs in accordance to priority because a GW (or SIP server/LS) may need to communicate with the alternate Servers/LSs in accordance to priority should the primary Server/LS fail. Similarly, a GW may also provide the information about the alternate GWs where the SIP Server/LS can communicate should the primary GW fail. It will increase the reliability of the system. The _REGISTER_ message may be repeated periodically (i.e., at GW power-up after maintenance), so the Server/LS shall be able to handle multiple requests from the same GW. However, a SIP Server/LS may receive the registration message with different combinations of the alias and the transport address and, it will respond in those conditions as follows: . If a SIP Server/LS receives a _REGISTER_ request message having the same alias address and the same transport address as a previous _REGISTER_, it shall respond with the _CONFRIM_ message. Radhika R. Roy [Page 22] Internet Draft ITRP Protocol August 31, 2001 . If a SIP Server/LS receives a _REGISTER_ request message having the same alias address as a previous _REGISTER_ request message and a different transport address, it may confirm the request, if it conforms with the SIP Server's/LS's security policy. Otherwise, it should reject the registration indicating a duplicate registration. . If the SIP Server/LS receives a _REGISTER_ request message having the same transport address as a previous _REGISTER_ request message and a different alias address, it should replace the translation table entries. The SIP Server/LS may have a method to authenticate these changes before confirmation of the request. Similar is the case for the SIP Server/LS when it registers with its SIP Servers/LSs peers. 6.2.2.1 Alternate Peers Alternate peers can also be associated using the discovery [6] message. In order to enhance reliability in the system which uses a Server/LS, the Server/LS may indicate alternate Servers/LSs that may be used in the event of a primary Server/LS failure. The list of alternate Servers/LSs can be provided in the _Alternate-Server_ structure of the _CONFIRM_ and _REJECT_ messages. Similarly, the alternate GW addresses can also be provided by the _REGISTER_ request message. When a SIP Server/LS discovers other peers, they can also provide the list alternate peers to which it can communicate if the primary one fails. 6.2.2.2 Registration Time (RT) The registration of the GW with the SIP Server/LS may have a finite lifetime. A GW (or SIP Server/LS) may request a _Time-To-Live_ in the _REGISTER_ request message to the SIP Server/LS and, the SIP Server/LS may respond with a _CONFIRM_ response message containing the same registration time or a shorter registration time. After this time, the registration shall be expired. 6.2.2.3 Registration Time Extension (RTE) Prior to the expiration of the registration time, a GW (or SIP Server/LS) may send the _KEEP-ALIVE-MESSAGE_ requesting for extension of the registration time._ This shall reset the _Time-To- Live_ parameter in the SIP Server/LS, allowing the registration to be extended. After the expiration time, the GW (or SIP Server/LS) must re-register with the SIP Server/LS. If a GW (or SIP Server/LS) does not include the registration time value in _Time-To-Live_ field of its _CONFIRM_ message, the registered GW (or SIP Server/LS) shall consider that the SIP Radhika R. Roy [Page 23] Internet Draft ITRP Protocol August 31, 2001 Server/LS is not supporting the RTE mechanism and no indication for the RTE shall be provided in the subsequent messages indicating that the SIP Server/LS is not supporting the RTE mechanism. 6.2.2.4 Alternate GWs It has been explained earlier to deal with alternate peers. However, the SIP Server/LS shall ensure that each alias address translate into a single transport address. However, a GW may be able to indicate a backup, redundant, or alternate transport address using the _Alternate GW_ field. This will allow a GW to have a secondary network interface or a secondary GW as a backup. In any case, any ambiguous registration will be rejected by the SIP Server/LS. 6.2.2.5 Capacity Attributes A GW will be able to send all the attributes related to its capacity attributes related to circuit and other parameters for registration. For example, the parameters like number of calls [total, spare], number of ports [total, spare], number of circuits and speeds [total, spare], etc.), QOS, GoS, codecs, bridging capabilities, and others that a GW likes to send for registration. A SIP Server/LS will then be able to advertise these parameters. However, for initial specification, only the circuit and call capacity attributes may be considered. 6.2.2.6 Registration Cancellation A GW may cancel its registration by sending the _REGISTER_ message using the NULL value (or *) in the alias address field or address structure. The registration cancellation request can be confirmed or rejected using _CONFIRM_ or _REJECT_ message, respectively. In the case of rejection, the reject reason needs to be sent. 6.2.2.7 Reachable Address Families The family of addresses that is being supported is expressed in the capability code. If a given family is not supported, it needs to be known priori and peers can take a note of it and services need to be provided accordingly. The address family can also be coupled with the application family, if needed, but not mandatory. For example, reachable address for ITRP can be expressed as , indicating a set of E.164 (ISUP/PSTN) destinations for the SIP protocol. Radhika R. Roy [Page 24] Internet Draft ITRP Protocol August 31, 2001 The address types supported capability may contain multiple addresses of a given family and/or addresses of many families in the capability. 6.2.2.8 Capability Negotiation The registration process has also the option to negotiate the capability of the peers. In fact, this is the appropriate time for the capability negotiation if this is not done at the time of the discovery [6]. Based on this, a SIP Server/LS may negotiate capability and, the registration _CONFIRM_ or _REJECT_ message can be sent to peers accordingly. The capability sets can be whether they will support a particular address family (or families), application protocol(s), and/or send/receive/sendreceive mode. 6.2.3 Keep Alive Mechanisms The keep-alive-messages are used to extend the time-to-live parameter between the peers. Keep-alive-messages must not be sent more than once every 3 seconds. If needed, the keep-alive-message interval can be negotiated. 6.2.4 Message Update Mechanisms MESSAGE-UPDATE requests are used to update the addresses by a GW to the SIP Server/LS. In turn, a SIP Server/LS may multicast the same using the MESSAGE-UPDATE request to all its SIP Servers/LSs. If needed, the addresses can also be coupled with the application protocol. The MESSAGE-UPDATE request is sent by the GW or SIP Sever/LS only in send-only mode. If the GW receive any MESSAGE-UPDATE requests, it silently discards it. In receive-only mode, a SIP Server/LS peer simply listens to the MESSAGE-UPDATE request and processes it. No peering session is established between the SIP Servers/LSs either in send-only or receive-only mode. Peering sessions (e.g., among servers) may be established in send-receive-mode only. 6.2.5 Information Synchronization Unlike TRIP flooding with limited broadcast [3], ITRP uses multicast to send the updates over an arbitrary topology of the ITAD. Therefore, the scalability is provided for intra-ITAD communications. When an update is received from an internal peer, the addresses in the update are checked to determine if they are newer than the version that is already being used. Newer addresses may then be multicast to all other peers in the same ITAD. In this way, the synchronization of all information is maintained among all SSs/LSs peers. Radhika R. Roy [Page 25] Internet Draft ITRP Protocol August 31, 2001 6.2.6 Advertising Addresses in ITRP In ITRP, two attributes may be combined to define the destination: a. A set of destination addresses b. An application protocol (e.g., SIP, H.323) Unlike TRIP [3], the application protocol field is optional, unlike TRIP [3], not required. The destination addresses are advertised between a pair of SSs/LSs in _Message-Update_ requests. The other attributes like egress GWs are also described. If a SS/LS chooses to advertise the reachable addresses, it may add to or modify the attributes of the addresses before advertising it to a peer. Unlike TRIP [3] that uses route aggregation and path concept, ITRP provides a very simple mechanism through sending the _Message-Update_ by which an SS/LS can inform its peer within the ITAD that a previously advertise reachable address is no longer available for use. 6.2.7 Transport Protocol Messages in the ITRP protocol may be sent over an unreliable transport (e.g., UDP) or reliable transport (e.g., TCP) to a well- known address. The same well-known port can be used for both TCP and UDP (the well-known address need to be supplied by IANA). All entities shall listen on both UDP and TCP ports. However, it can be seen that many of the protocol messages can be better utilized by the UDP transport. For example, multicasting of the _DISCOVER_ or _Message-Update_ request can only be sent efficiently using UDP. Similarly, other messages can also be sent over UDP saving the call setup time. Using unreliable transport service, messages may be retransmitted. The default value of the retransmission time should be determined by an adaptive delay sensitive method. Exponential back-off shall be used for subsequent retransmissions. In the case of reliable transport service, multiple messages may be sent within the boundaries defined by the reliable transport protocol data unit (PDU) as long as whole messages are sent. 7 ITRP Message Formats This section is a draft one and will be refined further in the subsequent proposal. The ITRP messages can be sent either over the unreliable (e.g., UDP) or reliable transport (e.g., TCP) as explained earlier. The maximum message size can be XXXX (TBD). The smallest message that MAY be sent consisting of an ITRP header without a data portion, or 3 octets (same as TRIP [3]). Radhika R. Roy [Page 26] Internet Draft ITRP Protocol August 31, 2001 7.1 Message Header Format Each message has a fixed-size header. There may or may not be a data portion following the header depending on the message type as follows: . Message header (Length + Type) = 3 octets . Length = 2 octets . Type = 1 octet . Unsigned integer . No padding of extra data after the message Length: Total length of the message including the header; Unsigned integer; No padding of extra data after the message Type: The 1-octate unsigned integer indicates the type code of the message. The following type codes are defined. Message Type Code: 1 = DISCOVER 2 = REGISTER 3 = MESSAGE-UPDATE 4 = KEEP-ALIVE-MESSAGE 5 = CONFIRM 6 = REQUEST-FAILURE The _DISCOVER,_ _REGISTER,_ _KEEP-ALIVE-MESSAGE,_ and _MESSAGE- UPDATE_ messages request a specific action to be taken by another peer. The _CONFIRM_ and _REQUEST-FAILURE_ message are generated by a peer to reply to a request generated by another peer. 7.2 Request Messages 7.2.1 DISCOVER Message Format The _DISCOVER_ message is used by any peer to discover automatically which peer (or peers) to register with. The automatic method allows the peer-to-peer association (e.g., GW-SS/LS or SS/LS-SS/LS) over the time. Auto discovery allows for lower administrative overhead in configuring individual peers and additionally allows replacement of an existing peer without manually reconfiguring all of the affected peers. The minimum length of the _DISCOVER_ message is XXX (TBD) octets including the message header. Radhika R. Roy [Page 27] Internet Draft ITRP Protocol August 31, 2001 The _DISCOVER_ message contains the following fields: . Version . Sequence-Number . Reply-Address . Max-Forwards . ITRP entity identifier . Entity Type Code: . 0 = reserved . 1 = gateway . 2 = location server . X = TBD . ... . Reply transport address that initiates the request . Optional Parameter length . ... . (First) Optional Parameter . (Second) Optional Parameter . ... . Optional Identification Parameters . Identification code: . 0 = reserved . 1 = location server identifier (if known) from which the gateway would like to receive permission to register if the gateway initiates the request . 2 = gateway identifier (if known) from which the location server would like to receive permission to register if the location server initiates the request . 3 = (another) location server identifier (if known) from which the location server would like to receive permission to register if the location server initiates the request . X = TBD . ... . Optional Capability Parameter . Capability Code 0 = reserved . Capability Code 1 = Address Types Supported . Capability Code 2 = Send Receive Capability . Capability Code X = TBD . ... . Address Type Supported
. ... . Note: The destination address resolution is the primary objective of the intra-TAD protocol. For, ITRP . (Optional) Entity Type Code: . 0 = reserved . 1 = gateway . 2 = location server . X = TBD . ... . (Optional: Entity Identifier: A unique sequence number of the entity (e.g., gateway, location server) . ... . (Optional) Address Family Code: . 0 = reserved . 1 = E.164 numbers (as defined in TRIP [3]) . 2 = Decimal Routing Numbers (as defined in TRIP [3]) . 3 = Penta-Decimal Routing Numbers (as defined in TRIP [3]) . 4 = Email-IDs Radhika R. Roy [Page 29] Internet Draft ITRP Protocol August 31, 2001 . 5 = H323-IDs . 6 = SIP-URLs . 7 = Transport-IDs . X = TBD . ... . Transport address is an IPv4 address . ... . Priority order: An integer number . ... . ... . ... 7.2.2 REGISTER Message Format The _REGISTER_ message contains the following fields: . Version . Sequence-Number . Reply-Address . Max-Forwards . ITRP entity identifier . Type 0 = reserved . Type 1 = gateway if it initiates the request to register with the location server . Type 2 = location server if it initiates the request to register/associate with another location server . Type X = TBD . Reply transport address that initiates the request . Time-To-Live; the suggested lifetime in seconds for the registration. If not present, the infinite lifetime is assumed. (However, it is negotiated between the peering entities. Keep- Alive-Message needs to be sent prior expiration of this time.) . Optional Parameter length . (First) Optional Parameter . (Second) Optional Parameter . ... . Optional Parameter . ... . Optional Capability Parameter . Capability Code 0 = reserved . Capability Code 1 = Address Types Supported . Capability Code 2 = Send Receive Capability . Capability Code X = TBD . ... . Address Type Supported
. ... . Note: The destination address resolution is the primary objective of the intra-TAD protocol. For, ITRP . ... . (Note: If no alias address is there, it will cause to cancel all registrations. That is, if a _REGISTER_ message is sent with _NULL_ value [or *], it will cause to cancel all registrations.) . ... . Address Family Code: . 0 = reserved . 1 = E.164 numbers (as defined in TRIP [3]) . 2 = Decimal Routing Numbers (as defined in TRIP [3]) . 3 = Penta-Decimal Routing Numbers (as defined in TRIP [3]) . 4 = Email-IDs . 5 = H323-IDs . 6 = SIP-URLs Radhika R. Roy [Page 31] Internet Draft ITRP Protocol August 31, 2001 . 7 = Transport-IDs . X = TBD . ... . Optional Application Family Code: . 1 = SIP (as defined in TRIP [3]) . 2 = H.323-H.225.0-Q.931 (as defined in TRIP [3]) . 3 = H.323-H.225.0-RAS (as defined in TRIP [3]) . 4 = H.323-H.225.0-AnnexG (as defined in TRIP [3]) . 5 = ISUP/PSTN . X = TBD . ... . . ... . Optional Parameter Circuit capacity attribute registration . Attribute Flag Code: . 0 = Well-known Flag . 1 = Non-Transitive Flag (recommended for circuit capacity attribute) . X = TBD . Capacity Attribute Type Code: . 0 =reserved . 1 = Spare capacity for the E.164 number (Address Family Code 1) destinations . 2 = Spare capacity for Decimal Routing Number (Address Family Code 2) destinations . 3 = Spare capacity for Penta-Decimal Routing Number (Address Family Code 3) destinations . X = TBD . ... . Optional parameter of alternate peers for communications (a sequence of prioritized peer alternatives that will act as back-up of the initiator of the request) . (Optional) Entity Type Code: . 0 = reserved . 1 = gateway . 2 = location server . X = TBD . ... . (Optional: Entity Identifier: A unique sequence number of the entity (e.g., gateway, location server) . ... . (Optional) Address Family Code: . 0 = reserved . 1 = E.164 numbers (as defined in TRIP [3]) . 2 = Decimal Routing Numbers (as defined in TRIP [3]) . 3 = Penta-Decimal Routing Numbers (as defined in TRIP [3]) Radhika R. Roy [Page 32] Internet Draft ITRP Protocol August 31, 2001 . 4 = Email-IDs . 5 = H323-IDs . 6 = SIP-URLs . 7 = Transport-IDs . X = TBD . ... . Transport address is an IPv4 address . ... . Priority order: An integer number . ... . ... 7.2.3 Message-Update Message Format The _MESSAGE-UPDATE_ message contains the following fields: . Version . Sequence-Number . Reply-Address . Max-Forwards . ITRP entity identifier . Entity Type Code: . 0 = reserved . 1 = gateway if it initiates the request to update with the location server . 2 = location server if it initiates the request to update with another location server . X = TBD . ... . . Reply transport address that initiates the request . ... . (First) Address Attribute . (Second) Address Attribute . ... . Flag Code: . 0 = Well-known Flag . 1 = Transitive Flag . X = TBD . ... . Address Update Code: . 0 = reserved . 1 = Added (Addresses) . 2 = Deleted Addresses . 3 = Modified Address . ... Radhika R. Roy [Page 33] Internet Draft ITRP Protocol August 31, 2001 . Address Advertiser Code: . 0 = reserved . 1 = Gateway . X = TBD . ... . Address Advertiser Identifier: Unique identifier of the address advertiser (e.g., gateways, location servers) . ... . Sequence number: Unique sequence number of this particular update information element . ... . . Address Parameter
. Address Family Code: . 0 = reserved . 1 = E.164 numbers (as defined in TRIP [3]) . 2 = Decimal Routing Numbers (as defined in TRIP [3]) . 3 = Penta-Decimal Routing Numbers (as defined in TRIP [3]) . 4 = Email-IDs . 5 = H323-IDs . 6 = SIP-URLs . 7 = Transport-IDs . X = TBD . ... . (Optional) Application Family Code: . 1 = SIP (as defined in TRIP [3]) . 2 = H.323-H.225.0-Q.931 (as defined in TRIP [3]) . 3 = H.323-H.225.0-RAS (as defined in TRIP [3]) . 4 = H.323-H.225.0-AnnexG (as defined in TRIP [3]) . 5 = ISUP/PSTN . X = TBD . ... . . Optional Parameter Circuit capacity attribute registration < Flag, Circuit Update Code, Address Advertiser Code, Address Advertiser Identifier, Sequence Number, Attribute Flags, Capacity Attribute Type, Attribute Length, Capacity (variable)> . ... . ... . Attribute Flag Code: . 0 = Well-known Flag . 1 = Non-Transitive Flag (recommended for circuit capacity attribute) . X = TBD . ... . Circuit Update Code: . 0 = reserved . 1 = Added (Capacity) . 2 = Deleted (Capacity) Radhika R. Roy [Page 34] Internet Draft ITRP Protocol August 31, 2001 . 3 = Modified (Capacity) . ... . Address Advertiser Code: . 0 = reserved . 1 = Gateway . X = TBD . ... . ... . Address Advertiser Identifier: Unique identifier of the address advertiser (e.g., gateways, location servers) . ... . Capacity Attribute Type Code: . 0 =reserved . 1 = Spare capacity for the E.164 number (Address Family Code 1) destinations . 2 = Spare capacity for Decimal Routing Number (Address Family Code 2) destinations . 3 = Spare capacity for Penta-Decimal Routing Number (Address Family Code 3) destinations . X = TBD . ... . ... . ... 7.2.4 Keep-Alive-Message Message Format The _KEEP-ALIVE-MESSAGE_ message contains the following fields: . Version . Sequence-Number . Reply-Address . Max-Forwards . ITRP entity identifier . Entity Type Code: . 0 = reserved . 1 = gateway if it initiates the request to update the time-to- live parameter for registration/address/capacity with the location server . 2 = location server if it initiates the request to update the time-to-live parameter for registration/address/capacity with another location server . X = TBD . ... . . Reply transport address that initiates the request . Time-To-Live . Time-To-Live Code: . 0 = reserve . 1 = REGISTER . 2 = Address Radhika R. Roy [Page 35] Internet Draft ITRP Protocol August 31, 2001 . 3 = Capacity . X = TBD . ... . Optional parameters . ... Note: The frequency of the KEEP-ALIVE-MESSAGE must not be more than once in every 3 seconds. 7.3 Response Message 7.3.1 CONFIRM Message Format The _CONFIRM_ message contains the following fields: . Version . Sequence-Number (will use the sequence number of request message that is being confirmed) . Reply-Address . Max-Forwards . ITRP entity identifier . Entity Type Code: . 0 = reserved . 1 = gateway if it initiates the request to update the time-to- live parameter for registration/address/capacity with the location server . 2 = location server if it initiates the request to update the time-to-live parameter for registration/address/capacity with another location server . X = TBD . ... . . Reply transport address that initiates the request . Request message type that is being confirmed (Type, Length, Value (variable)> . Message Type Code: . 1 = DISCOVER . 2 = REGISTER . 3 = MESSAGE-UPDATE . 4 = KEEP-ALIVE-MESSAGE . ... . ... . Optional parameter of alternate peers for communications (a sequence of prioritized peer alternatives that will act as back-up of the initiator of the request. For example, a location server can provide a list of alternate servers to which a gateway needs to contact in case the primary location server fails) . (Optional) Entity Type Code: Radhika R. Roy [Page 36] Internet Draft ITRP Protocol August 31, 2001 . 0 = reserved . 1 = gateway . 2 = location server . X = TBD . ... . (Optional: Entity Identifier: A unique sequence number of the entity (e.g., gateway, location server) . ... . (Optional) Address Family Code: . 0 = reserved . 1 = E.164 numbers (as defined in TRIP [3]) . 2 = Decimal Routing Numbers (as defined in TRIP [3]) . 3 = Penta-Decimal Routing Numbers (as defined in TRIP [3]) . 4 = Email-IDs . 5 = H323-IDs . 6 = SIP-URLs . 7 = Transport-IDs . X = TBD . ... . Transport address is an IPv4 address . ... . Priority order: An integer number . ... . Optional Time-To-Live Parameter . Time-To-Live Code: . 0 = reserve . 1 = Registration . 2 = Address . 3 = Capacity . X = TBD . ... 7.3.2 Request-Failure Message Format The _REQUEST-FAILURE_ message contains the following fields: . Version . Sequence-Number (will use the sequence number of request message that is being rejected) . Reply-Address . Max-Forwards . ITRP entity identifier . Entity Type Code: . 0 = reserved . 1 = gateway if it initiates the request to update the time-to- live parameter for registration/address/capacity with the location server . 2 = location server if it initiates the request to update the time-to-live parameter for registration/address/capacity with another location server Radhika R. Roy [Page 37] Internet Draft ITRP Protocol August 31, 2001 . X = TBD . ... . . Reply transport address that initiates the request . Request message type that is being rejected (Type, Length, Value (variable)> . Message Type Code: . 1 = DISCOVER . 2 = REGISTER . 3 = MESSAGE-UPDATE . 4 = KEEP-ALIVE-MESSAGE . ... . Optional Error Parameter . Error Code: . 0 = reserved . 1 = Message header error . 2 = DISCOVER . 3 = REGISTRATION . 4 = MESSAGE-UPDATE . 5 = KEEP-ALIVE-MESSAGE . 6 = Time-To-Live Timer Expired . X = TBD . ... . Message Header Error Subcodes: . 0 = reserved . 1 = Bad Message Length . 2 = Bad Message Type . ... . DISCOVER Message Error Subcodes: . 0 = reserved . 1 = Unsupported Version Number . 2 = Unsupported Optional Parameters . 3 = Unsupported capability . 4 = Security Denial . 5 = Undefined Reason . . ... . REGISTER Message Error Subcodes: . 0 = reserved . 1 = Unsupported Version Number . 2 = Unsupported Optional Parameters . 3 = Unsupported capability . 4 = Capability Mismatch . 5 = Attribute Flag Error . 6 = Address Family Not Supported . 7 = Security Denial . 8 = Undefined Reason . ... . Message-Update Message Error Subcodes: Radhika R. Roy [Page 38] Internet Draft ITRP Protocol August 31, 2001 . 0 = reserved . 1 = Unsupported Version Number . 2 = Unsupported Optional Parameters . 3 = Attribute Flag Error . 4 = Security Denial . 5 = Undefined Reason . . ... . Keep-Alive-Message Error Subcodes: . 0 = reserved . 1 = Unsupported Version Number . 2 = Unsupported Optional Parameters . 3 = Security Denial . 4 = Undefined Reason . ... . ... . 8 ITRP Attributes 8.1 Address Format, Family and Application Protocol 8.1.1 E.164 Numbers The E.164 Numbers address family is dedicated to fully qualified E.164 numbers. A set of telephone numbers is specified by a E.164 prefix. E.164 prefixes are represented by a string of digits, each digit encoded by its ASCII character representation. 8.1.2 Decimal Routing Numbers The Decimal Routing Numbers address family is a super set of all E.164 numbers, national numbers, local numbers, and private numbers. It can also be used to represent the decimal routing numbers used in conjunction with Number Portability in some countries/regions. A set of telephone numbers is specified by a Decimal Routing Number prefix. Decimal Routing Number prefixes are represented by a string of digits, each digit encoded by its ASCII character representation. 8.1.3 Penta-Decimal Routing Numbers This address family is used to represent PentaDecimal Routing Numbers used in conjunction with Number Portability in some countries/regions. PentaDecimal Routing Number prefixes are represented by a string of digits, each digit encoded by its ASCII character representation. Radhika R. Roy [Page 39] Internet Draft ITRP Protocol August 31, 2001 8.1.4 Email-Ids RFC 822 defines email-IDs using IA5String of size ranging from 1 to 512 characters. 8.1.5 SIP-URLs RFC 2543 defines the addresses using the SIP URLs. 8.1.6 H323-Ids Rec. H.323v2 defines H.323-Ids using IA5String of size ranging from 1 to 256 characters. 8.2 Address Aggression A set of GWs will advertise the reachability of addresses through them to a SIP Server/LS. The SIP Server/LS will then send an update to all other peers (SIP Servers/LSs). It is expected that the individual GW will do the address aggregation as far as practicable before advertising it to the server. If the server aggregates the information further, it may also allow to scale the information even more. For example, if multiple GWs advertise the same reachable address set to a SIP server/LS, a sever may then independently decide how to aggregate this information to a GW for reachability for routing a call based on certain policy criteria (e.g., cost, circuit-capacity, QoS, GoS, etc.). The server may then send the aggregated information to all other servers. 8.3 Address Advertisement The addresses that may be advertised by GWs A, B, X, and C to the SIP Servers/LS-1 can be as follows: _1 333 723 4587 Gateway A_ _1 333 467 * Gateway B_ _1 333 487 6753 Gateway X_ _1 * Gateway B_ _private 41* Gateway C_ The address that may be advertised by GWs D, E, and F to the SIP Server/LS-2 as follows: _*@example.org Gateway D_ _*@foo.com Gateway E_ _1 444 897 * Gateway F_ Radhika R. Roy [Page 40] Internet Draft ITRP Protocol August 31, 2001 After communications between SIP Servers/LSs 1 and 2, both servers will have the same information and if any calls come that requires to select GWs, they can then direct the calls as follows: _For 1 333 723 4587 send the call request to Gateway A_ _For 1 333 467 * send the call request to Gateway B_ _For 1 333 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 *@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_ In this way, all SIP Servers/LSs can have their address information synchronized. The circuit capacity or application protocol information can also be included as a part of the address information, but has not been shown in the above example for simplicity. 9. ITRP Error Detection and Handling The detail of this section for dealing with error conditions will be described in detail in subsequent contributions. 9.1 Message Header Error Detection and Handling 9.2 DISCOVER Message Error Detection and Handling TBD 9.3 REGISTER Message Error Detection and Handling 9.4 MESSAGE-UPDATE Message Error Detection and Handling TBD 9.5 KEEP-ALIVE-MESSAGE Error Detection and Handling TBD 9.5.1 Time-To-Live Expired Error Handling TBD 9.6 RJECTION Message Error Detection and Handling TBD Radhika R. Roy [Page 41] Internet Draft ITRP Protocol August 31, 2001 10 ITRP Version Negotiation TBD 11 ITRP Capability Negotiation TBD 12 MESSAGE-UPDATE Handling TBD 13 ITRP Transport This proposal defines to use both connectionless (e.g., UDP) and connection-oriented (e.g., TCP) transport. It is proposed to reserve a TCP port (XXXX) from IANA to be used by both transport protocols. In addition, am multicast IPv4 (224.0.X.X) address is also be needed to be reserved from IANA. 14 IANA Considerations TBD 14.1 ITRP Capabilities TBD 14.2 ITRP Attributes TBD 14.3 Destination Address Families TBD 14.4 ITRP Application Protocols TBD 15. Issues with ITRP Protocol The issues that we need to resolve with the ITRP protocol can be summarized as follows: . Do we include email and other alias addresses in addition to telephone addresses (e.g., E.164)? Radhika R. Roy [Page 42] Internet Draft ITRP Protocol August 31, 2001 . Do we allow a GW to register/communicate with multiple SIP Servers/LSs without restricting to a single Server for better management? . Do we allow capacity negotiation both in discovery and registration process? . Is this appropriate to keep a provision for alternate GWs/Servers to be contacted in accordance to the priority to increase the reliability of the GW/Server in case the primary GW/Server fails? . Do we also include cost information along with circuit capacity? . Should we address security mechanism using authentication similar to GW-SLP [12] and/or mechanisms such as TLS, IPsec, etc. as proposed in TRIP [3]? 16. Analysis of the ITRP Protocol in view of its Requirements This section described how our proposed ITRP meets all requirements for intra-ITAD communications: 1. Single Protocol: A single protocol is used between the GWs and Servers as well as among the servers. Messages that are being used are _DISCOVERY,_ _REGISTER,_ _MESSAGE-UPDATE,_ _KEEP-ALIVE- MESSAGE,_ _CONFRIM,_ and _REJECT._ The use of a single protocol optimizes the protocol development for intra-ITAD communications. 2. Fast Call Setup Time: ITRP is independent of any call control signaling protocol. The discovery of GWs and Servers and, registration and updates of the addresses and relevant information can be done prior to the call setup. During the call setup, the server needs to retrieve the proper GW information from its database. So, the fast call setup time can be provided by ITRP. 3. Failure Detection: Expiration of registration time, re- registration, and keep-alive messages of ITRP are the mechanisms that are used to detect failures promptly. 4. Startup Detection: A GW or Server recovered from a failure can send the new registration message to notify its recovery in ITRP. 5. Reliability: ITRP provides in-built mechanisms in discovery and registration process to provide the list of alternate Servers and GWs so that communications can established to the alternate peer in accordance to the priority should the primary peer fail to enhance the reliability. 6. Capacity, Cost, QoS, and other Information: The capacity, cost, QoS, and relevant information can be carried out from the gateway Radhika R. Roy [Page 43] Internet Draft ITRP Protocol August 31, 2001 to the Server during registration and update messages in ITRP (although only circuit capacity has been shown as an example for now). 7. Security: In ITRP, the authentication mechanism described in GW- SLP [12] and/or IPSec, TLS, and other mechanisms described in TRIP [3] can be used. This can be worked out separately. 8. Convey Routing Information: Each Server will be able to know about the address information about telephone numbers, email address, and/or other alias addresses using the address family information field in registration and update messages of ITRP. The aggregated GW address information by a given server can also be sent among the other servers increasing scalability. This information can also be coupled with circuit-capacity, cost, and other features. 9. Timeliness: The information can be sent using the update message of ITRP in a timely manner. A wide range of interval can be supported from few seconds to hours. 10. Extensible Attributes: ITRP has flexibility to define new attributes adding new information elements. For example, the type of GWs (e.g., ISUP variant _ ITU-T/ANSI/ETSI, SIP-H.323, etc.) may also need to be defined to call a particular GW. 11. Efficient: The ITRP protocol uses efficient scheme to minimize traffic. For example, update messages are used to send the minimal information that is being changed relative to the earlier message. The messages can also be multicast where needed instead of flooding. The server can also aggregate the information received from the gateways before sending the updates using multicasting among the servers. Initially, the discovery message needs multicasting, however, registration is performed in unicast method. 12. Routing Server Control: In ITRP, each routing server collects information from the GWs and, if needed, the information from GWs can also be aggregated by the sever. So, each routing server makes its own routing decision based on its own policy. 13. Independent Policies: Using ITRP, each server can apply its own independent decision during discovery, registration, and routing a call to a particular GW based on its independent policy decision. The proposed ITRP that uses a single unified protocol meets all requirements for intra-ITAD communications environment. Radhika R. Roy [Page 44] Internet Draft ITRP Protocol August 31, 2001 17. Policy One of the requirements has been that each SIP Server/LS and each GW be allowed to apply its policy independently although the SIP Server/LS should have the control whether a GW can register with a SIP Server/LS or a call to be routed through a particular GW. The proposed ITRP protocol meets this requirement. However, as explained in discovery [6] and registration protocol [7], we have not specified a particular standard mechanism for policy either for the SIP Server/LS or for the GW. We believe that the standardization of policy may be addressed separately. 18. Security Like discovery [6] and registration [7] protocol, we have not proposed any particular security scheme for the ITRP protocol. We like to address the security mechanism in the context of the overall intra-domain protocol. However, we can use the similar authentication mechanism as proposed in GW-SLP [12]. Like TRIP [3], the IPsec, TLS, and other security mechanism can be used for the ITRP as well. 19. Comparison of ITRP with other Intra-ITAD Protocol Proposals 19.1 TRIP-GW Proposal TRIP-GW [10] has been proposed for intra-ITAD communications modifying the inter-ITAD TRIP [3] proposal. A brief overview is provided comparing both TRIP-GW [10] and ITRP proposal. . TRIP-GW [10] proposes to use the discovery mechanism as proposed by SLP [11], but TRIP-GW and SLP are two separate protocols and, it will complicate the entire process to use two separate protocols to achieve a given specific goal. As a result, two separate processes need to be maintained. ITRP uses only one unified protocol that for discovery, registration, update, keep- alive, confirm, and reject messages. . SLP [11] uses the client and server model, not peer-to-peer model. For intra-ITAD communications, the requirement is such that GWs can discover the SIP Server/LS, but the SIP Server/LS should also be allowed to discover the GWs, when needed. Furthermore, SIP Servers/LSs work as peers and they also need to discover should there be no association. So, the client-server model of the SLP [11] for discovery and address advertisement do not meet the requirement for intra-ITAD communications. ITRP uses peer-to-peer model for discovery along with capability negotiations, if needed. Radhika R. Roy [Page 45] Internet Draft ITRP Protocol August 31, 2001 . Like SLP [11], ITRP also uses the scalable multicasting for discovery for the specific. ITRP has been optimized to meet the requirements for advertisement a family of addresses, if needed, to be coupled with capacity, application protocol, and other features. . TRIP-GW [10] uses connection-oriented TCP transport protocol for communications and, flooding (or limited broadcast) is used to transfer information to all peers. In contrast, ITRP uses the efficient multicasting which the most optimized communications where the information needs to be shared among multiple peers. The proposed ITRP protocol also does not preclude the use of the connection-oriented TCP transport protocol, if one chooses to do so. . TRIP-GW [10] uses many features inherited from inter-ITAD TRIP [3] that are not needed for intra-ITAD communications. For example, the modeling of the ingress SIP Server/LS to be the TRIP-speaker for the intra-ITAD communications. This and other features of TRIP-GW [10] make it complex for intra-ITAD communications where a simple protocol like ITRP is more appropriate. Finally, it appears that the proposed ITRP protocol that uses a unified protocol is more suitable for intra-ITAD communications where a simpler protocol compared to that of the TRIP-GW [10] is needed to satisfy the requirements. 19.2 GW-SLP Proposal Recently, a GW-SLP [12] solution has been proposed to locate the route servers by GWs extending the SLP protocol. The discovery and registration mechanism are used between the GWs and the route servers. The GW acts as the SLP SA while the server acts as the SLP DA and, DAs are not shared among the servers. All GWs communicate with all route servers and, there is a many-to-many communication relationship between the GWs and route servers. (The Route Server of GW-SLP [12] may be thought as the Location Server of this contribution.) GWs discover the routes servers using multicasting and then the address information is pushed to the route servers by the GW using the registration message in a point-to-point communication fashion. This proposal has similarity with the ITRP of this contribution with respect to the discovery and registration, but the following differences are there as follows: . In GW-SLP [12], a many-to-many relationship between GWs and routing servers needs to exist for normal operation. This may pose problems in managing the large network where a routing server may Radhika R. Roy [Page 46] Internet Draft ITRP Protocol August 31, 2001 use multiple GWs and a GW may use multiple route servers. In ITRP, it can be restricted such that a set of GWs will be communicating with a single server and will not be allowed to communicate with other servers. (If needed, ITRP can also provide many-to-many relationships, but it is not recommended.) . GW-SLP [12] provides no mechanism for communications among the route servers, and all GWs need to communicate directly with all route servers if multiple servers are deployed. If multiple route servers are deployed using scopes to improve scalability, all GWs will not be able to communicate directly with all route servers. Therefore, it points to the fact that a new protocol needs to be developed for communications among the route servers. In ITRP, communications among the servers are also provided using the same protocol. . A route server may also need to aggregate the address information and may then need to distribute the same among all servers. So, there is a fundamental need for communications among the servers and, no protocol has been suggested in the GW-SLP [12] proposal. However, IPRT uses a single protocol for communications between GWs and Servers and among Servers including discovery and registration mechanisms as suggest in GW-SLP [12]. . Failure detection in GW-SLP [12] is done detecting expiration of registration time or through re-registration. However, no mechanism is in place which alternate GW needs to be reached if the primary GW fails. Moreover, no scheme is available to contact the alternate route server, if the primary route server fails. In ITRP, the information about the alternate GWs or route servers can be provided during the discovery and registration process and, the alternate GWs and route servers can be contacted in accordance to the order of priority if the primary one fails. . In GW-SLP [12], no new message is used for selectively updating the information that has been changed other than the registration itself. In ITRP, an update message has been created to inform just about the change that has been occurred. This scheme has the efficiency in communications especially for server-to-server communications. For example, if any information about a GW is changed, then the sever needs to update that particular information of given GW, not the entire data sets of all GWs. The above points clarify why ITRP is a better solution using a single protocol in the intra-ITAD communications environment. Radhika R. Roy [Page 47] Internet Draft ITRP Protocol August 31, 2001 19.3 TRIP TRIP [3] is not intended for the intra-ITAD communications as its only objective has been for the inter-ITAD communications. Proposal might be made to modify some of the features in TRIP for using in the intra-ITAD environment. However, TRIP has some inherent complexities that cannot be used for the intra-ITAD even some features are modified unless the fundamental architecture of the protocol is broken. The following paragraph describes why TRIP or its modification may not be suitable for intra-ITAD communications: . TRIP [3] does not have the discovery mechanism where multicast is the most convenient and efficient way to do so. The TRIP has been modeled to use the connection-oriented TCP protocol and, it is not easy to modify the protocol architecture to use the connectionless UDP transport protocol for multicasting. ITRP protocol proposed in this contribution has the simple message architecture that can be used for the efficient multicasting over the connectionless UDP transport. . TRIP's [3] messages are very useful for route aggregation and propagation of routes, but these requirements are not present for the intra-ITAD communications. In intra-ITAD communications, a GW needs to be directed for given destination address. There is no need for propagation of the routes and their aggregation as required in the inter-ITAD environment. So, the complex architecture of the TRIP messages are not needed. Rather a simpler mechanism as described in ITRP protocol is more suitable than the modified one of TRIP. . In intra-ITAD, all kinds of alias addresses are needed in addition to telephone numbers because there can different kinds of GWs. For example, a telephony GW may only deal with E.164 numbers while a SIP-H.323 GW may deal with E.164, emails, and others. TRIP [3] only deals with E.164 routings in inter-ITAD communications where pre-provisioned SIP Servers/LSs are assumed and, the routing aggregation and best selection process are the primary requirements. Finally, the proposed ITRP message architecture is inherently efficient compared to that of TRIP [3] even it is modified. Radhika R. Roy [Page 48] Internet Draft ITRP Protocol August 31, 2001 12. Conclusion We have proposed a single unified ITRP protocol that meets all requirements for the intra-ITAD communications. ITRP uses request (DISCOVER, REGISTER, MESSAGE-UPDATE and KEEP-ALIVE-MESSAGE) and response (CONFIRM and REJCT) messages. The proposed ITRP protocol is efficient and scalable considering the large-scale network in comparison with other existing intra-ITAD protocols (e.g., TRIP-GW [10], GW-SLP [12]). The semantics and syntax of ITRP have also been defined. However, the proposed message formats of ITRP are similar to those of TRIP [3]. The automatic discovery [6] process of ITRP meets the requirements of the intra-ITAD peer-to-peer communications what SLP [11] cannot meet. Like SLP [11], the discovery [6] process of ITRP is scalable. All peers can negotiate capabilities and policy during the discovery process should the registration need to proceed. It is shown that the registration [7] process of ITRP is most efficient way for registration (or open session) considering other alternatives such as GW-SLP [12], SIP's [2], or TRIP [3]. Both unreliable (e.g., UDP) reliable (e.g., TCP) transport can be used for ITRP. For security, we can also use the similar authentication mechanism as proposed in GW-SLP [12]. Like TRIP [3], the security of the ITRP protocol can also be addressed using IPsec, TLS, and others in the light of the overall security. The standardization of the policy protocol will be addressed separately. We have also discussed issues related to overall approach of the ITRP protocol and, some suggestions have been provided to address those issues. Radhika R. Roy [Page 49] Internet Draft ITRP Protocol August 31, 2001 13. References [1] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. [2] Handley, Schulzrinne, H., Schooler, J. Rosenberg, J., _SIP: Session Initiation Protocol,_ RFC 2543, Internet Engineering Task Force, March 1999. [3] Rosenberg, J., H. Salama, H., and Squire, M., "Telephony routing over IP (TRIP)," Internet Draft, Internet Engineering Task Force, November 2000. Work in progress. [4] 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. [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] Roy, R. R., _Gateway and Server Discovery Protocol,_ draft-roy- iptel-gw-server-discovery-00.txt, IETF, August 2001 - Work in progress. [7] Roy, R. R., _Gateway and Server Registration Protocol,_ draft- roy-iptel-gw-server-registration-00.txt, IETF, August 2001 - Work in progress. [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [9] Rosenberg, J. and Schulzrinne, H., _A Framework for Telephony Routing over IP,_ RFC 2871, IETF, June 2000. [10] Rosenberg, J., Salama, H., _Usage of TRIP in Gateways for Exporting Phone Routes,_ draft-rs-trip-gw-02.txt, IETF, July 2001 - Work in progress. [11] Guttman, E., Perkins, C., Veizades, J., and Day, M., "Service location protocol, version 2," Request for Comments 2608, Internet Engineering Task Force, June 1999. [12] Zhao, W. and Schulzrinne, H., _Locating Internet Telephony Gateways via SLP,_ draft-zhao-iptel-gwloc-slp-00.txt, IETF, August 2001 _ Work in progress. Radhika R. Roy [Page 50] Internet Draft ITRP Protocol August 31, 2001 Acknowledgments Author provides sincere thanks to Jerry Ash, Fred Burg, and Chuck Dvorak for their helpful comments and suggestions. Author's Addresses Radhika R. Roy AT&T Room D3_3C09 200 S. Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732 420 1580 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 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 51]