Internet Engineering Task Force Radhika R. Roy Internet Draft AT&T draft-roy-iptel-gw-server-discovery-00.txt August 31, 2001 Expires: March 3, 2002 Gateway and Server Discovery 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 contribution describes a discovery protocol that can be used between gateways (GWs) and severs as well as among servers in intra- ITAD communications environment. The entities work in peer-to-peer mode to discover each other. A peer can find which peer(s) to register with based on policy. Each peer can also decide whether capabilities should also be taken into consideration during the discovery process before they proceed for registration. The discovery protocol will be a part for building a single unified intra-ITAD protocol described in a following contribution. The message formats of the intra-ITAD protocol including the discovery message are similar to TRIP. Radhika R. Roy [Page 1] Internet Draft Discovery Protocol August 31, 2001 We have also explained how all requirements are met by our proposed discovery protocol what other protocols like DNS, SLP, LDAP, and others cannot satisfy. Table of Contents 1. Introduction 3 2. Conventions used in this document 3 3. Discovery Protocol Description 4 3.1 SIP Server/LS Discovery by the GW 4 3.1.1 Alternate Peers 4 3.1.2 Timeout 5 3.1.3 Capability Negotiation 5 3.2 GW Discovery by the SIP Server/LS 5 3.3 SIP Server/LS Discovery by another SIP Server/LS 5 3.4 SIP Server/LS and GW Discovery Message Flows 6 3.5 Behavior of SIP Server/LS and GW for Discovery Messages 6 3.6 Discovery Message Operation and Decision Tree 7 3.7 ITAD Topology and Discovery Mechanism 9 3.7.1 Rules about Scope 10 3.7.2 Intra-Domain ITAD Topology Information 11 3.8 Discovery Protocol Semantics 11 3.8.1 Common Message Elements 13 3.8.2 Transport Protocol for Discovery Protocol 13 3.9 Discovery Protocol Syntax 13 4. Issues with the Discovery Protocol 14 5. Analysis of the Discovery Protocol in view of its Requirements 14 6. Policy 15 7. Security 15 8. Discovery of GWs and SIP Servers using Other Methods 15 8.1 DNS 16 8.2 SLP 16 8.3 LDAP 17 8.4 H.323 17 9. Conclusion 18 10. References 19 Acknowledgments 19 Author's Addresses 19 Full Copyright Statement 20 Radhika R. Roy [Page 2] Internet Draft Discovery 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). A telephony or SIP-H.323 GW connected to the IP network needs to bind with the location server (LS) [3] a set of telephone numbers/prefixes or aliases to its address that can be reachable for SIP calls. Similarly, a SIP server also requires to find telephony or H.323 GWs to route SIP calls with PSTNN or H.323 destinations. 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. The proposed discovery protocol will be used between GWs and Servers as well as among the Servers. In addition to the reachable destination of telephone numbers (E.164) or H.323 addresses, a GW needs to express its capacity, cost, quality-of-service (QoS), grade-of-Service (GoS), and other attributes whether it can handle a call with its available resources in accordance to its policy. A SIP Server/LS will also have its policy whether a SIP call can be handled by a particular GW. This discovery of the SIP Server/LS or the telephony GW can be done manually or automatically. Manual discovery relies on methods outside the scope of this contribution to determine which SIP Server/LS a telephony, SIP-H.323 GW [4], or the soft-switches like media gateway controller (MGC) [5] is associated with or to determine which GW can be used by the Server/LS to route SIP calls. The GW is configured with the address of the associated Server/LS. For example, it may be entered at the GW configuration, or it may be entered into an initialization file. In this way, the GW may know a priori which Server/LS it is associated with. The GW can then register/communicate with that Server/LS. Similar is the case with the Server/LS where a Server/LS can be configured with respective telephony or SIP-H.323 GWs to route SIP calls. The automatic method allows the GW-Server/LS association to change over time. The GW may not know who its Server/LS is, or may need to identify another Server/LS due to a failure. Similarly, a Server/LS can also discover whether a given GW is available for handling a SIP call or may need to find another GW due to failures. This may be done through auto discovery. The auto discovery is the most convenient way to replace an existing Server/LS or GW without manually reconfiguring all of the affected GWs or Servers/LSs. 2. Conventions used in this document Radhika R. Roy [Page 3] Internet Draft Discovery Protocol August 31, 2001 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 [6]. 3. Discovery Protocol Description A discovery protocol is needed to establish association among peers: Between 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. 3.1 SIP Server/LS Discovery by the GW 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 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 for better management of the system 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). 3.1.1 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 _REJETC_ 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 Radhika R. Roy [Page 4] Internet Draft Discovery Protocol August 31, 2001 also provide the list alternate peers to which it can register if the primary one fails. 3.1.2 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. 3.1.3 Capability Negotiation The discovery 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/send-receive mode. 3.2 GW Discovery by the SIP Server/LS Like GW, a SIP Server/LS may also multicast to discover the GWs sending a _DISCOVER_ message. The discovery message will have an indication that the discovery message is being sent to the GWs. This message can be sent to GW's well-known Discovery multicast Address. After receiving the _DISCOVER_ message, a GW knows about the existence of the SIP Server/LS in the ITAD. At this, a GW MAY send the registration/binding message to register/bind with the Server if it is already not registered and, the Server/LS comes to know about the registration/binding of the new GW. This process is recommended because of the fact that the registration needs to be under the control of the Server. It may be noted that all Servers can also communicate among themselves and, will be able to know which GWs already registered with which Servers. As a result, A Server can decide whether a GW has been registered with other Server or not. In this way, the registration with a given GW by all servers can be coordinated. 3.3 SIP Server/LS Discovery by another SIP Server/LS Radhika R. Roy [Page 5] Internet Draft Discovery Protocol August 31, 2001 A SIP Server/LS may also need to discover other SIP Servers/LSs for communications. Like before, a SIP Server/LS may multicast to discover the SIP Servers/LSs sending a request to all servers. The discovery message will have an indication that the discovery message is being sent to the servers. The response will be sent before registration proceeds. The communications will proceed as described in the case of a GW discovers Servers. 3.4 SIP Server/LS and GW Discovery Message Flows A simple high-level message flows is shown in Figure 1. In this scenario, a GW sends the DISCOVER message using the multicast. One or more Servers/LSs send the response using either CONFIRM or REJECT message. GW SIP Server/LS | DISCOVER | |----------------------->| | CONFRIM or REJECT | |<-----------------------| | | Figure 1: Auto SIP Server/LS Discovery by the GW Figure 2 depicts the high-level message flows where the SIP Server/LS initiates the GW discovery for eventual selection of the GW for routing a call assuming the fact that the SIP Server/LS does not have the registration/association with the GWs. SIP Server/LS GW | DISCOVER | |------------------------------------->| | (Register) | |<-------------------------------------| | (Registration Confirm/Reject) | |------------------------------------->| Figure 2: Auto GW Discovery by the SIP Server/LS 3.5 Behavior of SIP Server/LS and GW for Discovery Messages It is recommended that a GW needs to register/bind with a SIP Server/LS in an ITAD. As a result, every GW is required to implement the DISCOVER message for auto discovery of the SIP Server/LS. The DISCOVER request may be multicast in a well-known IP address and UDP Radhika R. Roy [Page 6] Internet Draft Discovery Protocol August 31, 2001 port number. The request SHOULD be scoped to ensure that it is not forwarded beyond the boundaries of the administrative scope. This MAY be done with either Time-To-Live (TTL) or administrative scope [7], depending on what is implemented in the network. A SIP Server/LS receiving the multicast DISCOVER request from the GW, it SHALL send the _CONFIRM_ or _REJECT_ response. Once the SIP Server/LS is discovered, a GW proceeds for the next step such as registration/binding with the Server/LS for eventual communications between the two. It may so happen that a SIP Server/LS may not have the information about the GWs while a call has arrived. In this situation, a SIP Server/LS MAY send the DISCOVER message to discover the GWs using multicast. Receiving the DISCOVER message, a GW knows about a SIP Server/LS and MAY decide to send the registration/binding message to the SIP Server/LS using unicast if it is not registered/associated already. It is recommended that the protocol design will be good enough to have the information about the GWs by the SIP Servers/LSs before placing a call using discovery, registration and update messages (will be described in other contributions) and, the Servers/LS may not need to discover GWs while the calls arrive. Should the Server/LS need to discover the GWs at the time of the call setup, it will increase the call setup time. 3.6 Discovery Message Operation and Decision Tree Ideally, the GW needs no configuration to begin its operation similar to the operation described in SLP (RFC 2608). The GW (or SIP Server/LS) has two basic modes of operation as shown in Figure 3. The first mode is used in the case when the GW already knows the address of a SIP Server/LS and, we assume that a well-known port (UDP Port = X to be specified by IANA) will be used. In this case, the GW transmits its request (DISCOVER) to it via unicast. Likewise, the SIP Server/LS will unicast its reply to the GW. If no reply is received in a reasonable amount of time (say, 5 seconds), a GW simply reissues its request until a reply is received. To prevent GWs from bombarding _live_ SIP Servers/LSs forever, the SIP Server/LS will either return a confirmation or a reject response with reason codes. In this way, the GW will know why the request cannot be answered by the SIP Server/LS. The second mode is when the GW has not yet discovered the existence of a SIP Server/LS. This case also corresponds to the situation in which there is no SIP Server/LS on this network. In this situation, Radhika R. Roy [Page 7] Internet Draft Discovery Protocol August 31, 2001 the second discovery mechanism is used. The GW will multicast the request (DISCOVER) in the well-known multicast address and port number (e.g., IP Address = 224.0.Y.Y, UDP Port = ZZZZ; Y, Z = To be assigned by IANA). If the policy of the SIP Server/LS permits, then the SIP Server/LS will hear this request and make an appropriate response (CONFIRM or REJECT). ------------------------------- | Need SIP Server/LS Discovery| | by the GW | ------------------------------- | | | | V V -----------------_ -------------------- | SIP Server/LS | | No SIP Server/LS | | Address known | | Address known | ----------------- -------------------- | | | | V V ----------------------_ --------------------------- | Ask SIP Server/LS | | Use general multicast | | directly (DISCOVER)| | address (DISCOVER) in | | via Unicast in the | | the well-known port | | well-known port | | (IP address = 224.0.Y.Y | | (UDP port = XXXX) | | UDP Port = ZZZZ) | ---------------------- --------------------------- Note: X, Y, Z -> To be assigned by IANA Figure 3: A GW's SIP Server/LS Discovery Decision Tree Similarly, a SIP Server/LS can also use the decision tree like Figure 3 to discover GWs or SIP Servers/LSs and, this has not been shown for simplicity. Again, GWs (or SIP Server/LS) will use the unicast request/response transaction (DISCOVER/CONFIRM/REJECT) in their communications with the SIP Servers/LSs (or GWs). In these transactions, the communications can be made either reliable (e.g., TCP) or unreliable (e.g., UDP) transport. Whether using TCP or UDP, a well-known port number (port = XXXX) assigned by IANA will be used. GWs (or SIP Server/LS) communicating with SIP Servers/LSs (or GWs) via unicast may use either reliable (e.g., TCP) or unreliable (e.g., UDP) transport, but only use UDP over multicast. Radhika R. Roy [Page 8] Internet Draft Discovery Protocol August 31, 2001 The registration/binding between the GW and SIP Servers/LSs are not forever, but include a lifetime. Once that lifetime expires, the SIP Server/LS will disassociate with this particular GW unless the binding/registration is refreshed. A keep-alive [3] like mechanism will be helpful to refresh the binding/registration. It is possible that a GW may need to be taken out for maintenance, or otherwise become unavailable before the expiration of the lifetime of the binding. GWs that know their services are being disabled are expected to withdraw their service binding/registrations, by notifying the SIP Server/LS of their earlier than-expected unavailability. Every GW must also keep track of the its binding/registration so that it can refresh its binding/registration before they expire, thus ensuring continuos service reachability. 3.7 ITAD Topology and Discovery Mechanism An ITAD topology is expected to have at least a single SIP Server/LS or multiple SIP Servers/LSs. In the case of a single SIP Server/LS, the network configuration is straight forward. A single SIP Server/LS is likely to become an increasingly critical single point of failure eventually. A desire to have SIP Servers/LSs to back each other (e.g., alternate Servers as explained earlier) up or to serve different regions of very large networks characterizes the next level. However, a network (e.g., intranet) needs not be truly large before it may become convenient to use multiple SIP Servers/LSs. Radhika R. Roy [Page 9] Internet Draft Discovery Protocol August 31, 2001 3.7.1 Rules about Scope Several rules about the scopes that must be followed and Figure 4 provides a diagram. ------------------------------------------------------------------- | O GW-u1 O GW-u2 O GW-u3 . . . . . O GW-ui | | | | | | O Unscoped SIP Server-u1/LS-u1 | | | | ------------------ ------------------ ------------------ | | | Scope 1 | | Scope 2 | | Scope 3 | | | | | | | | | | | | O SIP Server-11| | O SIP Server-21| | O SIP Server-31| | | | /LS11 | | /LS-21 | | /LS-31 | | | | | | | | | | | | O GW-11 | | O GW-21 | . . | O GW-31 | | | | O GW-12 | | O GW-22 | | O GW-32 | | | | . | | . | | . | | | | . | | . | | . | | | | O GW-1j | | O GW-2k | | O GW-3m | | | | | | | | | | | ----------------- | O SIP Server-22| ------------------ | | | /LS-22 | | | | | | | ------------------ | | | | O Unscoped SIP Server/LS-u2/LS-u2 | | | ------------------------------------------------------------------- Figure 4: ITAD Reference Diagram for Scopes . GWs scoped discovery/registrations/bindings must register/bind with all SIP Servers/LSs within the scope's radius. Even if GWs are configured to register with SIP Servers/LSs having some scope (perhaps even a set of scopes), they also register with unscoped SIP Servers/LSs. . Unscoped dicoveries/registrations/bindings may only register/bind with unscoped SIP Servers/LSs. . SIP Servers/LSs and GWs may only communicate if they are within the same scope. GWs must be configured to know what their scope is. GWs may also communicate with unscoped SIP Servers/LSs despite being configured to use a specific scope. This may be useful since any unscoped SIP Servers/LSs will know about all registrations/bindings (scoped and unscoped). Radhika R. Roy [Page 10] Internet Draft Discovery Protocol August 31, 2001 . A unscoped SIP Server/LS may itself be overwhelmed since all GWs can communicate with unscoped SIP Server/LS. Therefore, if a GW has been configured with a scope, it should only use SIP Servers/LSs within that scope. Otherwise, the unscoped SIP Servers/LSs could become overloaded, presenting a scaling problem. A SIP Server/LS within a GW's scope should always be preferred over an unscoped SIP Server/LS. If scoped SIP Servers/LSs are used, they will not accept unscoped requests/registrations/bindings. GWs should use a scope in their requests if possible and should use a SIP Server/LS with their scope in preference to an unscoped SIP Server/LS. . For administrative reason, it may be better to configure GWs to register/bind only with some list of SIP Servers/LSs based on certain policy decision after discovery of Servers/LSs, if possible. Although the above rules have been stated when GWs want to make discovery/registrations/bindings with the SIP Server/LS, the similar rules are also applicable in some situations when the SIP Server/LS sends requests/queries to the GWs. 3.7.2 Intra-Domain ITAD Topology Information It has been described how each SIP Server/LS will have the information about the reachability of the GWs known to them. However, these SIP Servers/LSs also need to communicate among themselves to exchange the information about the GWs to have the global information within a given ITAD. It is seen that TRIP [3] has the mechanism to communicate the information among the SIP Servers/LSs using flooding mechanism for intra-domain communications. However, a multicasting mechanism seems to be more efficient than flooding intra-ITAD communications. 3.8 Discovery Protocol Semantics The _DISCOVER_ request message needs to have the following information: . Protocol Identifier: The protocol that is being used for the discovery message. For example, DISCOVER messages can be a part of the intra-ITAD protocol. . Transport Address: The transport address that the GW or SIP Server/LS uses for registration/binding/status messages. Radhika R. Roy [Page 11] Internet Draft Discovery Protocol August 31, 2001 . Entity Type: The entity that is sending the discovery message for registration/binding/query. For example, it can be GW (POTS/PSTN/ISDN, SIP-H.323, MEGACO/H.248), SIP Server/LS, etc. . Server/LS Identifier: The Server/LS identity from which the GW would like to receive permission to register/bind/query/communicate. A provision should also be kept to indicate that the GW is interested to register/bind/query/communicate with any prosy/LS, if needed. . Entity Alias: A list of alias addresses, by which other entities (e.g., SIP Servers/LSs) may identify this entity. . Alternate Entities: A sequence of prioritized GW alternatives for transport address, entity type, or entity alias. . Security Parameters: Authentication mechanisms, encryption algorithms, integrity mechanisms, token, etc. may be specified, if needed. The _CONFIRM_ message can have the following parameters: . Protocol Identifier: The protocol that is being used for the discovery confirmation (CONFIRM) message. For example, CONFIRM messages can be a part of the Intra-ITAD protocol. . Transport Address: The transport address that SIP Server/LS uses for registration/binding/status messages. . Server/LS Identifier: The Server/LS identity that is sending the CONFIRM message. . Alternate Server/LS: A sequence of prioritized alternatives for the _Server/LS-Identifier_ and _Transport Address._ The GW should use these alternatives in the future, should a request to the Prosy/LS not respond or return a reject without redirect. . Security Parameters: Authentication mechanisms, encryption algorithms, integrity mechanisms, token, etc. may be specified, if needed. The _REJECT_ message can have the following: . Protocol Identifier: The protocol that is being used for the discovery (REJECT) message. For example, REJECT messages can be a part of the Intra-ITAD protocol. . Server/LS Identifier: The Server/LS identity that is sending the REJECT message. Radhika R. Roy [Page 12] Internet Draft Discovery Protocol August 31, 2001 . Reject Reason: Codes why the CONFIRM message was rejected by this Server/LS. . Authentication required, unauthorized, temporary unavailable, resource unavailable, entity excluded/not allowed, undefined reason, etc. . Alternate Server/LS Information: This field provides the information about alternative Servers/LSs. If this information is supplied, a GW should retransmit the request to one of the alternate Servers/LSs listed. If an alternate Server/LS rejects the request, the GW should accept the rejection. If an alternate Server/LS does not respond, the GW may send the request to another alternate in the list. . Security Parameters: Authentication mechanisms, encryption algorithms, integrity mechanisms, token, etc. may be specified, if needed. Above all, the general parameters like sequence number of the messages and others will also need to be there. These aspects of the protocol semantics can be decided once we decide the overall goal of the protocol development. 3.8.1 Common Message Elements The above analysis shows that the common message elements for all messages can be as follows: . Message Sequence Number . Protocol Identifier . Transport Address . Entity Type . Entity Alias 3.8.2 Transport Protocol for Discovery Protocol It is shown that multicast is needed for auto-discovery of the SIP Server/LS by the GW or vice versa. A SIP Server/LS can also discover other SIP Servers/LSs. So, UDP seems to be the most appropriate transport protocol in multicasting environment for discovery. 3.9 Discovery Protocol Syntax Radhika R. Roy [Page 13] Internet Draft Discovery Protocol August 31, 2001 The messages that are used by GWs and SIP Servers/LSs for discovery are DISCOVER, CONFIRM, and REJECT. Again, any updates are made by any GWs, the same also need to be propagated to all SIP Servers/LSs. The most important thing is that, unlike TRIP [3], none of these messages require route selection and aggregation. Like TRIP [3], a _KeepAlive-Message_ may also be needed for both GW- Server/LS and Server/LS-Server-LS communications to detect failures. The detail of the DISCOVER, CONFIRM, and REJECT messages have been described. Similarly, a new message _REGISTER_ message may be defined for binding of the GW with the Server/LS with all its information like reachable addresses (e.g., E.164, alias, email), capacity, QoS, GoS, and other attributes. Like TRIP [3], a MESSAGE-UPDATE request also needs to be defined for the intra-ITAD protocol. Finally, the syntax of the Intra-ITAD protocol can also be written in accordance to TRIP [3] protocol. The proposed message formats of the discovery message can be seen in another contribution [8] as a part of the a single unified intra-ITAD protocol. 4. Issues with the Discovery Protocol The issues that we need to resolve with the discovery protocol can be summarized as follows: . Do we include email and other alias addresses in addition to telephone addresses (E.164)? . Is 5 seconds timeout OK? Should we define an elaborate mechanism for timeout? . Is it appropriate to keep the alternate GWs to be contacted in accordance to the priority to increase the reliability of the GW in case the primary GW fails? . Should we rely on alternative mechanisms such as TLS, IPsec, etc. instead of considering for individual messages? 5. Analysis of the Discovery Protocol in view of its Requirements Radhika R. Roy [Page 14] Internet Draft Discovery Protocol August 31, 2001 The proposed discovery protocol that uses three messages DISCOVER, CONFIRM, and REJECT as a part of the overall intra-ITAD (or domain) protocol to discover the SIP Servers/LSs (or GWs). This protocol messages are not tied to the call control messages and, allow to proceed to calls fast as SIP Servers/LSs do not need to discover the GWs and their present available characteristics (e.g., capacity, codecs, ISUP variants, etc.) before the calls arrive. The features like reliability, security, timeliness, efficient, Server control, and independent policy control for both the GW and the SIP Server/LS are also the inherent property of the said discovery protocol. More importantly, how a scalable ITAD network can be built using the administrative multicasting scope for discovering the SIP Servers/LSs and GWs are also described. The proposed protocol allows either GWs discover SIP Servers/LSs or SIP Servers/LSs discover GWs using the peer-to-peer model without restricting the roles for any entities. Therefore, the proposed discovery protocol meets all the requirements that have been envisioned. 6. Policy One of the requirements has been that each SIP Server/LS and GW be allowed to apply its policy independently although the SIP Server/LS should have the control whether a call to be routed through a particular GW. The proposed discovery protocol meets this requirement. However, 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. 7. Security We have not proposed any particular security scheme for the discovery protocol. We like to address the security mechanism in the context of the overall intra-domain protocol. 8. Discovery of GWs and SIP Servers using Other Methods GWs and SIP Servers/LSs may also be discovered using Domain Name System (DNS), Service Location Protocol (SLP), Lightweight Directory Access Protocol (LDAP), and others. Each scheme has its own pros and cons and, may not be suitable to meet all requirements for Radhika R. Roy [Page 15] Internet Draft Discovery Protocol August 31, 2001 communications among GWs and SIP Servers/LSs. Because of this, the use of those methods (as it is or through extensions) for discovery is not addressed in this contribution. 8.1 DNS A uniform resource locator (URL) can be used for a SIP Server/LS or GW. For example, we assume that the Intra-ITAD protocol is used between them, a URL for the SIP Server/LS or GW could be given by: itrip://ServerlsID@domainname:portnumber itrip://gwID@domainname:portnumber A well-known port number can be defined by IANA that can be used as default if no port number is given. However, the SRV resource or text record query can be used to find the transport address and ServerlsID/gwID for the Intra-ITAD protocol given the domain name of a SIP Server/LS or a GW. This method uses the unicast method for discovery, but auto- discovery is not possible as we have described in our proposed discovery protocol. 8.2 SLP Service Location Protocol (SLP), FRC 2608, is a good mechanism for auto-discovery, but it works in a client server fashion. It assumes that there are many clients and each client may look a specific service while the server is able to provide advertise many services. In client server mode, it requires that GWs need to act as the service agent (SA) while the SIP Server/LS needs to act as the directory agent (DA) and, this role may be difficult to reverse once the system is configured. In the intra-ITAD scenarios, there is only one kind of service that needs to be advertised. GWs may discover SIP Servers/LSs, but SIP Servers/LSs may also need to discover GWs should the need arise. In addition, SIP Servers/LSs also may also need to discover one another. It mandates that the auto-discovery needs work in peer-to- peer mode. Our proposed discovery protocol meets the requirements where both GW and SIP Server/LS can work in peer-to-peer mode and, discover each other as needed. The Servers can also discover one another as appropriate. The capability negotiations can also be done using the proposed protocol. The list of alternate peers can also be auto- Radhika R. Roy [Page 16] Internet Draft Discovery Protocol August 31, 2001 provisioned to enhance reliability in our protocol and, it has also the scaling property like that of the SLP. 8.3 LDAP Lightweight Directory Access Protocol (LDAP), RFC 1777, can be used to add an entry for an entity into the database and the information about the GWs and SIP Servers/LSs can be learnt through use of this protocol. However, this protocol is not suitable for auto-discovery to meet the requirements. 8.4 H.323 H.323 [9] also has a method for discovery as a part of H.225.0 RAS signaling messages. The discovery of the gatekeepers can only be done for the endpoints, but not vice versa. The discovery mechanism is also not used among the gatekeepers. There are similarities between H.323 discovery and our proposed protocol. In our case, all entities (GW and Server) are considered are peers and can initiate discovery as needed. A GW can discover Servers, a Sever can also discover GWs, or a Server can also discover peer Servers as appropriate. The peers can also negotiate capabilities among themselves before registration proceeds. Many semantics are also not the same based on our intra-ITAD requirements. Finally, our syntaxes are also different. Radhika R. Roy [Page 17] Internet Draft Discovery Protocol August 31, 2001 9. Conclusion We have proposed a discovery protocol that is scalable considering the large-scale network. It is also shown that this protocol meets the requirements that have been proposed. The semantics of the protocol have also been defined. We have also explained how the proposed discovery protocol described in this contribution meets all requirements what DNS, SLP, H.323, and LDAP cannot meet. It is shown that the auto-discovery process described in this contribution is the most dynamic way to discover the SIP Server/LS by the GW or vice versa considering all other alternatives like DNS, LDAP, and others. The protocol also allows to discover SIP Servers/LSs by another SIP Server/LS. For multicasting environment, UDP is the most efficient transport protocol that needs to be used for the discovery protocol. However, we believe that the syntax of the protocol be defined using the TRIP {3] protocol. We have proposed that a complete set of intra-ITAD protocol can be defined using _DISCOVER, CONFIRM, REJECT, REGISTER, MESSAGE-UPDATE, and KEEP-ALIVE-MESSAGE._ This combine set of protocol can be termed as Intra-ITAD protocol as described in another contribution [8]. The security of the discovery protocol will be addressed in the light of the overall security of the Intra-ITAD protocol. The standardization of the policy protocol will be addressed separately. There are some issues related to the security and the overall approach of the Intra-ITAD protocol. We have provided some suggestions how these issues can be addressed. Radhika R. Roy [Page 18] Internet Draft Discovery Protocol August 31, 2001 10. 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [7] Mayer, D., _Administratively scoped IP multicast,_ RFC 2365, IETF, July 1998. [8] Roy, R. R, _IP Telephony Routing Protocol (IPRT),_ Internet Draft, draft-roy-iptel-itrp-00.txt, IETF, August, 2001 _ Work in Progress. [9] "Packet based multimedia communication systems", Recommendation H.323v2, ITU-T, Geneva, Switzerland, February 1998. 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 Radhika R. Roy [Page 19] Internet Draft Discovery Protocol August 31, 2001 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 20]