Internet Engineering Task Force                          Radhika R. Roy
Internet Draft                                                     AT&T
draft-roy-iptel-intra-itad-fw-00.txt
January 7, 2002
Expires: July 7, 2002


           A Framework for Intra-ITAD Communications Protocol


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

   This document is an Internet-Draft and is NOT offered in accordance
   with Section 10 of RFC2026, and the author does not provide the IETF
   with any rights other than to publish as an Internet-Draft

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

                                 Abstract

   This document describes a framework for the intra-Internet Telephony
   Administrative Domain (Intra-ITAD) communications protocol. The
   intra-ITAD communications scenarios are analyzed. The requirements
   how the protocol will provide alias addresses resolution for routing
   a call to the appropriate gateway are described along with other
   attributes like capacity and QoS. The document describes specifics
   for communications between the gateways and servers as well as among
   the servers for discovery, registration, efficient selective updates
   of addresses, address aggregation, and reliability. The document
   also provides the framework how the intra-domain protocol will
   complement the inter-domain routing protocol, TRIP, in the broader
   context of Internet Telephony.



Radhika R. Roy                                               [Page 1]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002




                             Table of Contents


   1. Introduction      3
   2. Conventions used in this document 3
   3. Terminology       3
   4. Motivation for Intra-ITAD Communications Protocol 4
   5. Intra- and Inter-ITAD Communications Protocol Characteristics
        5
   5.1 Inter-ITAD Communications Protocol       5
   5.2 Intra-ITAD Communications Protocol       6
   6. Scenarios and Architectures for Intra-ITAD Communications 7
   6.1 ITAD Topology    10
   6.1.1 Star ITAD Topology     11
   6.1.2 Mesh and Star ITAD Topology    11
   6. Intra-ITAD Communications Protocol Requirements   14
   7. Functional Entities       15
   7.1 Internet Telephony Administrative Domain 15
   7.2 Gateway  16
   7.3 Location Server  17
   7.4 End Users        17
   8. Functional Entity Interactions    18
   8.1 Gateways and Location Servers    18
   8.2 Location Server to Location Server       19
   8.3 Nature of Exchanged of Information       20
   8.4 Quality of Service       21
   8.5 Cost Information 21
   9. Alias Address Translations        22
   10. Security 23
   11. References       23
   Acknowledgments      23
   Author's Addresses   23
   Full Copyright Statement     23
















   Radhika R. Roy                                             [Page 2]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


1. Introduction

   The framework of the intra-Internet Telephony Administrative Domain
   (Intra-ITAD) communications protocol is described in this document.
   The primary objective has been to specify requirements how the
   protocol will provide alias addresses resolution for routing a call
   to the appropriate gateway, not route processing, aggression, or
   propagation. In addition, the attributes like capacity and quality-
   of-service that are localized to the gateways, not between the
   source-destination path, are also addressed.

   The communications specifics like discovery, registration, efficient
   selective updates of addresses, address aggregation, and reliability
   are also described as a part of the requirements.

   The document also provides the framework how the intra-ITAD protocol
   will complement the inter-ITAD TRIP protocol [2] in the broader
   context of the Internet Telephony.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [3].

3. Terminology

   Gateway: A gateway can be a SIP-ISUP  telephony gateway, SIP-H.323
   telephony gateway, or other type of gateways. A SIP-ISUP  telephony
   gateway can be a device with some sort of circuit switched network
   (e.g., PSTN) connectivity and IP connectivity, capable of initiating
   and terminating IP telephony signaling protocols, and capable of
   initiating and terminating telephone network signaling protocols
   (e.g., ISUP). A SIP-H.323  telephony gateway can provide
   connectivity between the two IP networks, but uses SIP and H.323
   call control signaling protocol in two sides of the interworking
   gateway. All types of gateways will abstract the address families
   (e.g., E.164, email Ids, URL Ids, etc.), capacity, quality-of-
   service (QOS), grade-of-service (GOS), and/or other attributes in a
   common format that will form the basis for the intra-ITAD
   communications protocol.

   End User: The end user is usually (but not necessarily) a human
   being, and is the party who is the ultimate initiator or recipient
   of calls.

   Calling Device: The calling device is a physical entity which has IP
   connectivity. It is under the direction of an end user who wishes to
   place a call. The end user may or may not be directly controlling
   the calling device. If the calling device is a PC, the end user is

   Radhika R. Roy                                             [Page 3]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   directly controlling it. If, however, the calling device is a
   telephony gateway, the end user may be accessing it through a
   telephone.

   Location Server (LS): A logical entity with IP connectivity which
   has the knowledge of gateways that can be used to terminate calls
   towards the PSTN and/or the IP network. The LS is the main entity
   that participates in routing a call to a particular gateway. The LS
   is generally a point of contact for end users for completing calls
   to the telephony network. An LS may also be responsible for
   propagation of gateway information to other LS's. An LS may be
   coresident with an H.323 gatekeeper or SIP server, but this is not
   required.

   Internet Telephony Administrative Domain (ITAD): The set of
   resources (gateways and Location Servers) under the control of a
   single administrative authority. End users are customers of an ITAD.

   Provider: The administrator of an ITAD.

   Location Server Policy: The set of rules which dictate how a
   location server processes information it sends and receives via the
   intra-ITAD communications protocol. This includes rules for
   aggregating, propagating, generating, and accepting information.

   End User Policy: Preferences that an end user has about how a call
   towards the PSTN should be routed.

4. Motivation for Intra-ITAD Communications Protocol

   An Internet Telephony Administrative Domain (ITAD) can be a
   collection of gateways (GW), location servers (LS), IP Telephony End
   users, IP Telephony Call Signaling servers and/or other functional
   entities administered by one administrative entity [2]. An ITAD can
   consist of one or more location server, zero or more gateways, and
   zero or more end users. This means that there is one authority
   responsible for dictating the policies and configuration of the GWs
   and LSs.

   A GW may provide the interface between the IP and PSTN Telephony
   network or an interface between the SIP- and ISUP-based telephony
   network or SIP- and H.323-based telephony network.

   As telephony gateways grow in terms of numbers and usage, managing
   their operation will become increasingly complex. There may need to
   be many LSs within an ITAD to manage those GWs. The GWs may relay
   the reachability of the address information to the LS while the LS
   will relay the address information among themselves. Each LS may
   have its own policy in associating GWs with it.


   Radhika R. Roy                                             [Page 4]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   It appears that a protocol is needed for communications between GWs
   and LSs, and among LSs.

   In intra-ITAD communications environment, the following functions
   need to be performed by the routing protocol:

   . First, a GW needs to discover who will be its location server for
     sending the reachability of the address information or it may so
     happen if a call comes to a LS and it does not know which GW to
     route a call, it may also need to discover GWs.

   . Second, once the discovery is done, a GW need to register all the
     address reachability information to the LS to which it has made
     association at the time of the discovery process.

   . Third, once a LS obtains the information for GWs, the said also
     needs to be shared among all other LSs within the ITAD. This
     information needs to be synchronized among all LSs.

   . Fourth, if there is any update in the prior registered address
     information, a GW needs to send an update to the LS selectively.
     The said information also needs to be updated among all other LSs
     by the location server that has received an update from the GW.

   . Fifth, syntax and semantics of the data which describe the address
     information of the telephony GW as well as signaling messages that
     are sent between the GWs and LSs, and among the LSs.

5. Intra- and Inter-ITAD Communications Protocol Characteristics

   The inter-domain framework document [2] has provided the basic
   outline what is required for a inter-ITAD protocol and, TRIP [4] has
   been designed to meet those requirements considering the routing of
   E.164/Decimel/Penta-Decimel numbers only. However, TRIP [2],
   designed for inter-domain communications, does not deal with the
   intra-ITAD communications.

5.1 Inter-ITAD Communications Protocol

   The primary characteristics of the inter-domain routing protocol,
   TRIP [4], fulfilling the requirements defined in the framework
   document [2] can be summarized as follows:

   . It propagates only the E.164/Decimel/Penta-Decimel addresses among
     the ITADs maintained by different providers.

   . The LSs maintain the peering relationship between the ITADs of
     different administrative domains.



   Radhika R. Roy                                             [Page 5]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   . The association between the LSs of different ITADs is pre-
     provisioned and, no auto-discovery mechanism exists.

   . How the route information is obtained from the telephony GWs or
     other LSs by a LS of a given ITAD is not defined.

   . It determines the IP address of a gateway capable of completing a
     call to a phone number given that a phone number which corresponds
     to a terminal on a circuit switched network.

   . It provides the exchange and synchronization of telephony gateway
     routing information between providers.

   . The stable routing loops for IP telephony signaling protocols are
     prevented.

   . The propagation of learned gateway routing information is provided
     to other providers in a timely and scalable fashion.

5.2 Intra-ITAD Communications Protocol

   The intended intra-ITAD communications protocol that needs to be
   designed should have the following characteristics:

   . Should maintain the relationship between GWs and LSs and among LSs
     within ITAD administered by a single provider and, GWs can be such
     as telephony GWs and SIP-H.323 GWs.

   . Need to auto-discover LSs by GWs and vice versa, GWs by LSs, and
     LSs by LSs.

   . Should make association between GWs and LSs as well as among LSs
     dynamically.

   . Should define the mechanism how the address information to be
     transferred between GWs and LSs as well as among LSs.

   . Should determine the IP address of a gateway capable of completing
     a call:

     .  To a E.164/Decimel/Penta-Decimel phone number given that a
        E.164/Decimel/Penta-Decimel phone number which corresponds to a
        terminal on a circuit switched network like PSTN.

     .  To an alias address like email ID, URL ID, etc. to a terminal
        that is residing in a packet-switched network like IP.

   . Should synchronize the address information (E.164/Decimel/Penta-
     Decimel numbers, email ID, URL ID, etc.) in all LSs of an ITAD
     administered by a single provider.

   Radhika R. Roy                                             [Page 6]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002



   . Should provide the address resolution (E.164/Decimel/Penta-Decimel
     numbers, email ID, URL ID, etc.) and not to perform any route
     processing, route path selection, or route path propagation.

   . Need to provide the update of the address information of the GWs
     among the LSs in a timely and scalable fashion.

   The above points explain the differences between the intra- and
   inter-ITAD communications protocol. It appears that the intra-ITAD
   communications protocol that needs to be developed will be
   complementing the already developed inter-ITAD protocol known as
   TRIP [4] for the E.164/Decimel/Penta-Decimel telephony route
   information.

6. Scenarios and Architectures for Intra-ITAD Communications

   Figure 1 depicts that a simple configuration where a single SIP
   Server, with multiple SIP-ISUP  telephony or SIP-H.323  telephony
   GWs, resides in an IP network. However, a SIP-ISUP  telephony GW

   will have interfaces with both IP and PSTN network or a SIP-H.323
   telephony GW will have interfaces with both SIP- and H.323-based IP
   Telephony network.


    ------------------------------------------------------------------
    |                                        |                       |
    |                -------              ------                     |

    |                |SIP  | <----------> |GW 1|                     |
    |                |Serv.|              ------                     |
    |   IP           |/LS  |                 |         PSTN          |
    | NETWORK        |     |              ------     Network         |
    |(SIP-based      |     | <----------> |GW 2|   (ISUP-based       |
    |  Tel)          |     |              ------     Tel)            |
    |                |     |                 .                       |

    |                |     |                 .                       |
    |                |     |              ------                     |
    |                |     | <----------> |GW n|        IP           |
    |                |     |              ------      NETWORK        |
    |                |     |                 |       (H.323-based    |
    |                -------                 |         Tel)          |
    |                                        |                       |
    ------------------------------------------------------------------


            Figure 1: A Single SIP Server/LS with Multiple GWs


   Radhika R. Roy                                             [Page 7]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   In Figure 1, the key features can be described as follows:


   . The SIP-ISUP  telephony/SIP-H.323  telephony GWs and SIP
     Servers/LSs are deployed by the Internet Telephony Administrator
     in its own domain and, this can be designated as the Internet
     Telephony Administrative Domain (ITAD).

   . It is assumed that SIP Servers are co-located with the Location

     Server (LS).

   . The SIP Server and a given GW are, as if, one-hop away for
     communications and, GWs do not propagate route among themselves
     using the discovery/registration protocol.


   . A GW can have association for many more alias addresses over the
     PSTN/IP network that can be reached through it.

   . A GW can have its own policy to take decision how a specific
     destination point can be reachable or whether a call will be

     accepted for routing.

   . A GW can also take the decision whether or not it will
     register/communicate with a particular SIP Server/location server
     based on its policy.


   . A GW can have its many attributes like capacity, cost preferences,
     quality-of-service (QoS), grade-of-service (GoS), extensible
     parameters (e.g., ISUP variants - ITU-T, ANSI, ETSI), H.323
     versions, etc., and others in addition to the reachable
     destination addresses and policy.


   . A GW needs to discover a Server/LS (and vice versa, if needed),
     and, will be able to register/establish communications with the
     information that is reachable through it for the PSTN or IP
     network. If needed, the capabilities can also be checked during
     the discovery phase before registration.


   . A SIP Server/LS will also be able to discover its peer SIP
     Servers/LSs, and register with them for communications, if needed.
     Capability negotiations may also be done during the registration
     phase if it is not indicated at the time of discovery.



   Radhika R. Roy                                             [Page 8]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   . A GW (or Server) will be able to know during the registration
     process which alternate servers (or GWs) it will be able to

     communicate with in accordance to priority in case the primary
     server fails to enhance reliability. (Figure 1 does not show this
     situation, but Figure 2 can be used to depict more than one
     Server.)

   . A SIP Server/LS may also be capable to choose any GW independently

     if multiple GWs are available to route a call in accordance to its
     policy either based on cost-performance trade-offs or due to
     failure of the primary GW of its choice for enhancing reliability.

   Figure 2 provides a scenario where more than one Server/LS are
   available and, GWs will have the choice to choose any Server for
   registration in a given ITAD based on its policy. However, a GW
   should have the mechanism to discover how many Servers are available

   to register/communicate with in a given ITAD.































   Radhika R. Roy                                             [Page 9]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002



    ------------------------------------------------------------------
    |                                        |                       |

    |                -------              ------                     |
    |                |SIP  | <----------> |GW 1|                     |
    |                |Serv.|              ------                     |
    |    IP          |1/   |                 |                       |
    | NETWORK        |LS 1 |              ------       PSTN          |
    |(SIP-based      |     | <----------> |GW 2|      NETWORK        |
    |  Tel)          |     |              ------     (ISUP-based     |
    |                |     |                 .         Tel)          |

    |                |     |                 .                       |
    |                |     |              ------                     |
    |                |     | <----------> |GW n|                     |
    |                |     |              ------                     |
    |                |     |                 .                       |
    |                -------                 . . . . . . . . . . . . |
    |                                        .                       |

    |                                        .                       |
    |                -------              -------                    |
    |                |SIP  | <----------> |GW k1|                    |
    |                |Serv.|              -------                    |
    |   IP           |m/   |                 |                       |
    | NETWORK        |LS m |              -------      IP            |
    |(SIP-based      |     | <----------> |GW k2|     NETWORK        |
    |  Tel)          |     |              -------    (H.323-based    |

    |                |     |                 .         Tel)          |
    |                |     |                 .                       |
    |                |     |              -------                    |
    |                |     | <----------> |GW kj|                    |
    |                |     |              -------                    |
    |                |     |                 |                       |
    |                -------                 |                       |

    |                                        |                       |
    ------------------------------------------------------------------

           Figure 2: Multiple SIP Servers/LSs with Multiple GWs

6.1 ITAD Topology

     A Internet Telephony Administrative Domain (ITAD) is expected to
     have at least one Location Server (LS). It is also expected that
     there will be gateways (GWs) that interconnect the SIP-based
     Telephony (e.g., SIP) network to the ISUP-based  Telephony


   Radhika R. Roy                                            [Page 10]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


     network. In another scenario, a SIP-based  Telephony network may
     be connected to the H.323-based  Telephony network via SIP-H.323
     telephony GWs [4].

6.1.1 Star ITAD Topology

     Figure 1 shows a simplified ITAD architecture where a single SS/LS
     is controlling all the GWs (e.g., SIP-ISUP  Telephony, SIP-H.323
     Telephony). In this star-type architecture the simple discovery
     and registration are sufficient to satisfy the requirements.

     In Figure 2, two SSs/LSs are controlling two sets of GWs in their
     own areas independently. The following situations may arise:

     .  Case 1: No communications exist between the SSs/LSs. That is,
        communications only exist between a SS/LS and the GWs.

     .  Case 2: Same as case 1, but each SS/LS supplies the address of
        the other SS/LS as a backup to the GWs at the time of their
        discovery or registration.

     .  Case 3: Communications exist between SSs/LSs and GWs as well as
        among SSs/LSs.

     For simple scenarios like Cases 1 and 2, the discovery and
     registration mechanisms are good enough to satisfy the
     requirements.

     However, additional messages are needed to cover the scenario like
     case 3 because discovery and registration mechanisms may not be
     efficient enough. Message updates, confirmations, keep-alive
     mechanisms, and error notifications are also needed. In other
     words, we need to build the intra-ITAD protocol to cover all cases
     efficiently.

6.1.2 Mesh and Star ITAD Topology

     An ITAD may consist of many GWs and LSs and, Figure 3 shows an
     ITAD architecture that uses the intra-ITAD Protocol. In Figure 3,
     an example is shown that the SIP Server is co-located with the LS.
     The SIP-based IP Telephony ITAD is being interconnected to the
     ISUP-based Telephony and H.323-based Telephony networks via SIP-
     ISUP  Telephony and SIP-H.323  Telephony GWs, respectively.

     The intra-ITAD protocol is used between the SIP servers
     (SSs)/Location Servers (LSs) and GWs as well as among the SSs/LSs.

     An important observation is that the logical connectivity between
     the SSs/LSs and the GWs is like star-type architecture and, there
     is no direct connectivity between the GWs. However, the logical

   Radhika R. Roy                                            [Page 11]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


     connectivity among the SSs/LSs can be star, mesh, or a combination
     of both.

     The implication is that the intra-ITAD (iITAD) protocol needs to
     have the in-built capacity to take care of the redundancy provided
     because the back-up GWs or SSs/LSs may not be co-located or may
     not have the same address.


      SIP-ISUP  Tel GWs                    SIP-ISUP     SIP-H.323
                                             Tel GWs     Tel GWs
        |          |                           |          |
        |  ...     |                           |   ...    |
     ---|----------|---------------------------|----------|--------
     |  O GW-11... O GW-1i                     O GW-21 . .O GW-2j |
     |  |          |                           |          |       |
     |  |  iITAD   |                           |  iITAD   |       |
     | --------------          iITAD          --------------      |
     | | SS/LS-1    |-------------------------|  SS/LS-2   |      |
     | |            |                         |            |      |
     | --------------                         --------------      |
     |       |                                       |            |
     |       |                                       |            |
     | iITAD |   (SIP-based) IP Telephony Network    | iITAD      |
     |       |                                       |            |
     |       |                                       |            |
     |       |                                       |            |
     | --------------          iITAD          --------------      |
     | | SS/LS-3    |-------------------------|  SS/LS-4   |      |
     | |            |                         |            |      |
     | --------------                         --------------      |
     |  |  iITAD   |                           |  iITAD   |       |
     |  |          |                           |          |       |
     |  O GW-31... O GW-3k                     O GW-41 . .O GW-4m |
     ---|----------|---------------------------|----------|--------
        |  ...     |                           |   ...    |
        |          |                           |          |
     SIP-ISUP  Tel GWs                      SIP-ISUP    SIP-H.323
                                             Tel GWs     Tel GWs


     Notes: iITAD = Intra-ITAD Communications Protocol
            SS = SIP Server (Proxy, Register, Re-direct)
            LS = Location Server

          Figure 3: ITAD Architecture using the Intra-IP Telephony
                Administrative Domain Communications Protocol

     Although Figure 3 shows a mesh-like architecture between the
     SSs/LSs, it can also be star architecture or a combination of both

   Radhika R. Roy                                            [Page 12]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


     star and mesh. However, SSs/LSs can communicate among themselves
     either directly or indirectly. The intra-ITAD protocol needs to be
     smart enough to exploit this situation of the logical connectivity
     among SSs/LSs.

     Finally, the connectivity among the GWs and the SSs/LSs are
     logical. The logical connection between GW-31 and SS/LS-3 shown in
     Figure 3 can be changed using the intra-ITAD communications
     protocol. That is, it will also be possible to have logical
     connectivity changed from GW-31 <-> SS/LS-3 to GW31 <-> SS/LS-4
     for example.

     The intra-ITAD protocol needs to be designed in such a way that
     will allow to auto-discover the GWs and SSs/LSs and registration
     should be made by the GWs to the SSs/LSs based on the association
     provided during the discovery process. In this way, the logical
     connectivity can also be changed dynamically.

     This simple example explains the fact that the intra-ITAD protocol
     needs to satisfy the two sets distinct requirements in the
     following areas for communications:

     .  Between GW and SS/LS - where GWs cannot communicate among
        themselves (other than via SSs/LSs).

     .  Among SSs/LSs - where SSs/LSs can communicate among themselves
        directly or indirectly.

     .  Information related to addresses and other attributes between
        the GW and the SS/LS: GW _ Send mode only and SS/LS _ Receive
        mode only. That is, a kind of one-way registration type
        information exchange will be OK.

     In addition, the intra-ITAD protocol also needs to satisfy other
     requirements as described later.

     The operation of the intra-ITAD protocol is independent of any
     particular IP Telephony signaling protocol (e.g., SIP) and can be
     used as the routing protocol for any of these protocols (e.g.,
     SIP).

     The SS/LS topology within a given ITAD is independent of the
     physical topology of the network. SSs/LSs communicate with the GWs
     in the application signaling layer (above layer 4) and the logical
     topology between the SSs/LSs and GWs will also be independent of
     the physical topology of the network whether the GWs are
     decomposed or not.




   Radhika R. Roy                                            [Page 13]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


6. Intra-ITAD Communications Protocol Requirements

   The intra-domain ITAD communications protocol needs to have unique
   features. In brief, any protocol method or functional features
   should have the following:

   . Need to have a single protocol to optimize the protocol
     development because the intra-ITAD protocol has unique
     characteristics that need to be satisfied.

   . Should maintain the relationship between GWs and LSs and among LSs
     within ITAD administered by a single provider and, GWs can be such
     as SIP-ISUP  telephony GWs, SIP-H.323  telephony GWs, and others.

   . Need to auto-discover LSs by GWs and vice versa, GWs by LSs, and
     LSs by LSs.

   . Should make association between GWs and LSs as well as among LSs
     dynamically.

   . Should define the mechanism how the address information to be
     transferred between GWs and LSs as well as among LSs.

   . Should determine the IP address of a gateway capable of completing
     a call:

     .  To a phone number given that a phone number which corresponds
        to a terminal on a circuit switched network like PSTN.

     .  To an alias address like email ID, URL ID, etc. to a terminal
        that is residing in a packet-switched network like IP.

   . Should synchronize the address information (telephone numbers,
     email ID, URL ID, etc.) in all LSs of an ITAD administered by a
     single provider.

   . Should provide the address resolution (telephone numbers, email
     ID, URL ID, etc.) and not to perform any route processing, route
     path selection, or route path propagation.

   . Need to provide the update of the address information of the GWs
     among the LSs in a timely and scalable fashion.

   . Need to deal with telephone addresses in addition to other alias
     addresses that are reachable through the GWs and, these addresses
     may not reside in the SIP (or other IP Telephony) network.

   . Should have the fast call set-up time.



   Radhika R. Roy                                            [Page 14]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   . Should have the failure detection capability should a failure
     occurs either to a SIP Server/LS or to a GW.

   . Need to have the knowledge of the alternate GWs or Servers to
     contact in order of priority if the primary one fails.

   . Should have the automatic capability to restart communications
     with the SIP Server/LS or the GW should a failure occur.

   . Should have the knowledge of capacity (e.g., number of calls
     [total, spare], number of ports [total, spare], number of circuits
     and speeds [total, spare], etc.), QOS, GoS, codecs, bridging
     capabilities, and other features before forwarding the SIP calls.

   . Security (authentication, integrity, privacy).

   . Should convey the gateway selection preferences with probable
     trade-offs, if possible, between cost and performance.

   . Should be able to obtain the information (e.g., cost performance
     trade-offs along with routing preferences,) about both SIP
     Server/LS and the GW on time along with extensible attributes
     (e.g., ISUP variant _ ITU-T/ANSI/ETSI, codec support, etc.).

   . Need to be efficient without generating too many messages while
     satisfying the requirements.

   . Should need to have the control with SIP Server/LS how to select a
     GW and when to forward a call based on the centralized policy.

   . Should have the independent policy for each SIP Server and the GW
     residing within a given ITAD.

7. Functional Entities

   The topologies shown in Figures 1 through 3 consist of number of
   functional entities that reside in an ITAD. These entities include
   Internet Telephony Administrative Domain, gateways, location
   servers, and end users as described in the framework document [2].

7.1 Internet Telephony Administrative Domain

   The characteristics of an Internet Telephony Administrative Domain
   for the intra-ITAD communications protocol can be summarized as
   follows:

   . Will have at least one gateway and at least one location server,
     and zero or more users for using the intra-ITAD protocol.



   Radhika R. Roy                                            [Page 15]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   . Will be under a single administrative control with one authority
     responsible dictating the policies and configurations of the
     gateways and location servers.


   . Will allow end users in an ITAD to access the gateways to complete
     the calls.

7.2 Gateway

   A gateway is a logical device that will connect the two networks of
   different call control protocols. The one side of the connectivity
   of the gateway will be the IP network while the other side can be
   either a telephone network or an IP Network. A gateway is considered
   a generic term where it can be a monolithic or decomposed. A
   monolithic gateway (e.g., SIP-ISUP  telephony GW, SIP-H.323
   telephony GW) deals with both media and signaling in the same
   entity. A decomposed gateway like MEGACO [5] that can provide SIP-
   ISUP interworking or SIP-H.323 IWF [6] that handles SIP-H.323
   interworking [6] deals with media and signaling in two different
   entities.

   For development of the intra-ITAD protocol, it is the signaling part
   of the gateway that is considered. However, in a generic sense, the
   function of the gateway is to translate the media and signaling
   protocols from one network technology to the other, achieving a
   transparent connection for the users of the system.

   It may be noted that all types of GWs (e.g., SIP-ISUP Telephony GW,
   SIP-H.323 Telephony GW) will abstract the address family (e.g.,
   E.164/Decimel/Penta-Decimel), capacity, QOS, GOS, and other
   attributes in a common format that will form the basis for the
   intra-ITAD communications protocol.

   The important attributes of the gateway can be summarized as
   follows:

   . Range and sub-range of phone numbers, email IDs, URL IDs, and/or
     others that a gateway wants to provide services.

   . Preferences (cost or other factors) associated with each range or
     sub-range of phone numbers, email IDs, URL IDs, and/or others.

   . Indicator of capacity or volume of service (e.g., number of
     simultaneous calls handled/port capacity, access link speed,
     etc.).

   . Type of services that a gateway provides (e.g., signaling protocol
     supported, telephony features provided, speech codecs understood,
     encryption algorithms implemented, etc.).

   Radhika R. Roy                                            [Page 16]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002



   . Type of call services to be provided (e.g., business call with
     minimal amount of probability of blocking at any time, ordinary
     call that can be blocked if needed, etc.).

   In intra-ITAD communications environment, these attributes can be
   used to select a gateway. However, care will be taken not to make
   the protocol too complex in choosing the attributes while making it
   scalable. The another aspect should be to have all attributes that
   TRIP [4] support to complement each other.

7.3 Location Server

   A location server (LS) will have the access to the database of the
   address information that is collected from the gateways. A gateway
   can be co-located or remotely located to the location server in an
   ITAD. If the gateway is remotely located, the intra-ITAD protocol
   that is to be developed needs to be used between the gateways and
   the location server.

   A given location server will be controlling a set of gateways and
   may not have the information of all gateways in an ITAD. There may
   be more that one location server in an ITAD and, each location
   server may be controlling a set of gateways within the sphere of its
   own control. So, the location servers also need to communicate among
   themselves to transfer information once it is obtained from the
   gateways to synchronize their databases.

   TRIP [4] assumes that there will some sort of communications among
   the locations servers of a given ITAD to have their databases
   synchronized. Therefore, the intra-ITAD protocol that is to be
   developed will complement the inter-ITAD TRIP [4] protocol.

7.4 End Users

   An end user logged into an IP network may wish to call another user
   who is located in a network that needs to traverse through a
   gateway. A gateway can be a telephony gateway or a SIP-H.323 gateway
   although an end user may not be aware that the call is passing
   through a gateway.

   In some situations, an user may be aware that the call will be
   passing through a gateway (e.g., SIP-ISUP  telephony gateway, SIP-
   H.323  telephony GW) and may have preferences how the call should be
   completed. The preferences can be expressed in call features that
   should be supported, QoS metrics for each media, owner or
   administrator, cost preferences, security criteria, and others.

   The intra-ITAD protocol may also need to deal with end users'
   preferences indirectly although the protocol itself will nor dictate

   Radhika R. Roy                                            [Page 17]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   how these preferences will be used in selecting a gateway. The
   selection of a gateway based on preferences needs to be done by some
   other means, not to be addressed by the intra-ITAD protocol.

8. Functional Entity Interactions

   Figures 1 through 3 provide some configurations for the gateways and
   location servers in an ITAD. A more detail about the interaction
   among those functional entities is described here.

8.1 Gateways and Location Servers

   A gateway can be a SIP-ISUP (PSTN) telephony gateway, SIP-H.323
   telephony gateway, or other kind of gateway. First of all, gateways
   need to propagate information to the location servers in an ITAD. To
   do so, a gateway needs to discover who will be its location server.
   In an ITAD there can be more than one location server. A location
   server will control a set of gateways because a many-to-many
   relationship among the gateways and servers will create problems in
   managing a large network. Each location server may have its own
   policy for registering a gateway for advertising the reachable
   addresses.

   In the initial stage, a gateway may need to multicast a message in
   order to discover a location server. If the discovery message is
   multicast, many location servers may send confirming the request
   back in a unicast fashion to the gateway depending on the policy and
   other service criteria. The confirmation message may contain the
   list of alternate location servers in accordance to priority if the
   primary one fails. If the criteria are such that a location server
   will not allow registration of a particular gateway, it should send
   the reject message.

   If a gateway receives the reply more than one location server, it
   will only choose one location server and, will proceed to register
   with the location server. During registration, the gateway will send
   the registration message containing all the alias addresses
   including telephone numbers with range and sub-ranges along with
   capacity, list of alternate gateways in accordance to priority if
   the primary one fails and other information. In response, the
   location server will confirm the registration of the gateway. If any
   problems, the location server will reject the registration and will
   send the reason why the registration has been rejected.

   It may so happen that a location server may not have any information
   related to the gateway while a call has arrived. In this situation,
   a location server may also send the discover message to discover the
   gateway. In response, the gateway will send the registration message
   to the location server based on its policy if it is not already


   Radhika R. Roy                                            [Page 18]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   registered with the location server. Then the process will follow as
   described above.

   Once the registration process in completed, there may be some
   changes in the information registered with the location server. If
   it is so, the gateway will send the update message containing only
   the information that does not match with the original registration.
   This information may be of the category of each item: Add, Delete,
   or Change. However, the location server will never send the update
   message to the gateway.

   If the implementation of multicast for auto-discovery is a problem
   in certain situations, pre-provisioned unicast-based discovery
   mechanisms (e.g., DNS lookup) can also be used.

   In addition, the keep-alive message may be sent from time-to-time to
   find the status and extend the time-to-live counter of the messages.
   It is expected that the location server will maintain a database to
   keep all the information.

8.2 Location Server to Location Server

   The alias addresses including telephone numbers and other
   information is received from a set of gateways by a location server
   within an ITAD. The information received from the gateways by a
   location server needs to be shared among other location servers
   located within the same ITAD.

   However, a location server also needs to know about other location
   servers within the ITAD. Similar to gateways, a location server may
   require to discover the other peer location servers. As described
   earlier, a location server will send the discovery message to other
   location servers using multicast. Unlike gateways, a location server
   can register to all other location servers. If there are only couple
   of location servers in an ITAD, these servers can also be pre-
   configured.

   The discovery and registration by the location servers will proceed
   as described in the case of the gateway. However, the appropriate
   mechanisms can be kept whether a discovery or registration message
   is sent by either a location server or by a gateway.

   The communications among the location servers will work as follows:
   Any information that is received from gateways by a location server
   will be sent to all other location servers by that location server.
   When a location server receives any information from the gateway,
   the same will be sent to all other location servers using the update
   message. The update message can be sent using either multicast or
   unicast as appropriate.


   Radhika R. Roy                                            [Page 19]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   The registration message is used after the discovery and any
   information received from the gateways by a location server can also
   be sent during the registration process, if needed. However,
   registration message is used once and the update message is used
   thereafter.

   The keep-alive message is used to know the status and to update the
   time-to-live counter.

   The information exchanged among the location servers is synchronized
   as each one will be sending the update to all others. The updates
   can be sent in send/receive-only mode. In some cases, the send-
   receive mode may also be appropriate to increase the efficiency of
   communications in transferring a bulk of data.

8.3 Nature of Exchanged of Information

   A gateway will have a set of objects consisting of a range of
   telephone numbers, email IDs, URL IDs, and/or others which are
   reachable through it, capacity and other attributes, and an IP
   address of the gateway. This information will be sent to the
   location server by the gateway using the intra-ITAD protocol whose
   characteristics are described earlier.

   A location server will learn about all alias addresses and other
   attributes received from a set of gateways and, this information
   will be sent to all other location servers of the ITAD by the said
   location server.

   It may so happen that a location server may aggregate the
   information in such a way that it will always use the IP address of
   the gateway, not the IP address of the server itself. This is
   because all location servers will have the same information
   synchronized along with the gateway information. Should a call come
   to any location server, it can take the decision which gateway to
   send the call directly without sending the call to another location
   server.

   For example, if a couple of gateways advertise the same address
   ranges to a location server, the location server will decide which
   gateway should actually be reached for this particular address
   ranges and will send the information accordingly to all other
   location servers. All location servers will take the same decision
   to route a call to that particular gateway directly for those
   address ranges.

   In another situation, there may be a need for load sharing among the
   gateways for calls to a range of alias addresses. A location sever
   may then decide to subdivide the said range of addresses among the
   gateways based on available circuit capacity, port capacity, and/or

   Radhika R. Roy                                            [Page 20]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   DSP resources which gateway needs to be contacted during a certain
   period of time for some particular kinds of calls based on certain
   policy. The location server will then send the update message
   accordingly to all other location servers updating this information.

   All information of all gateways within an ITAD will be synchronized
   among all location servers. All location servers will be able to
   know which gateways are already registered and, association of new
   gateways through registration to a location server will be made
   after discovery accordingly. In this way, all location servers will
   make sure that no gateway is registered with more than one location
   server.

8.4 Quality of Service

   In addition to capacity that may include available circuit capacity,
   port capacity and DSP resources, the quality-of-service (QoS)
   through a gateway can be expressed in terms of losses, delay,
   jitter, probability of blocking and/or other factors. However, these
   QoS attributes, if present, will only be considered for the gateway
   itself only. That is, the QoS on the _path_ between caller and the
   gateway is not considered. The QoS along the source-destination path
   requires the knowledge of the underlying network layer (e.g., IP
   network layer 3) topologies. This network layer QoS is handled by
   QOS routing protocols and is outside the scope of the intra-ITAD
   protocol because gateways and location servers are the application
   layer (i.e., layer 7) entities.

   However, the gateway capacity [2] is not dependent on the caller
   location or path characteristics. For this reason, a capacity metric
   of some form needs to be supported by the intra-ITAD protocol. This
   metric represents the static capacity of the gateway, not the
   dynamic available capacity which varies continuously during the
   gateways operation. Location Servers can use this metric as a means
   of load balancing of calls among gateways as explained earlier. It
   can also be used as an input to any other policy decision.

8.5 Cost Information

   Another useful attribute to propagate is a pricing metric [2]. This
   might represent the amount a particular gateway might charge for a
   call. The metric can be an index into a table that defines a pricing
   structure according to a pre-existing business arrangement, or it
   can contain a representation of the price itself. The intra-ITAD
   protocol itself does not define a pricing metric, but one can and
   should be defined as an extension. Using an extension for pricing
   means more than one such metric can be defined.




   Radhika R. Roy                                            [Page 21]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


9. Alias Address Translations

   A gateway is willing to terminate calls towards some set of alias
   addresses including phone numbers. Again, a gateway can be a SIP-
   ISUP  telephone gateway, a SIP-H.323  telephony, or other type of
   gateway. An administrator will decide what alias addresses the
   gateway is willing to call and policy decision will reside with a
   location server.

   In the case of the SIP-ISUP  telephony gateway, telephone numbers
   (e.g., E.164) include which gateway needs to be contacted for a
   given destination address by the location server:

   _For 1 212 723 4587  send the call request to Gateway A_
   _For 1 212 467 *     send the call request to Gateway B_
   _For 1 718 487 6753  send the call request to Gateway X_
   _For 1 *             send the call request to Gateway B_
   _For private 41*     send the call request to Gateway C_
   _For 44 372 556*_    doesn't exist_

   If it is a SIP-H.323  telephony gateway, the examples can be as
   follows:

   _For *@example.org   send the call request to Gateway D_
   _For *@foo.com       send the call request to Gateway E_
   _For 1 444 897 *     send the call request to Gateway F_

   The telephone numbers that is advertised by a gateway are expected
   to be in close geographic proximity to the gateway. For example, a
   gateway in New York might be willing to terminate calls to the 212
   and 718 area codes.

   However, a gateway may also advertise the telephone numbers that do
   not represent the geographical proximity, rather represent services
   or virtual addresses. An example for such numbers can be freephone
   and local number portability (LNP). In the telephone network, these
   are actually mapped to routable telephone numbers, often based on
   complex formulae. A classic example is time-of-day-based
   translation.

   The administrator of an ITAD may decide whether the freephone or LNP
   numbers will be advertised by the gateway before making translation
   to a routable number because problems may arise if the routable
   numbers are not advertised. How a translation is out-of-scope of the
   intra-ITAD protocol.

   In some situation, the non-routable number advertisement depends on
   the time-of-the-day to obtain a particular routable number, the
   location server that administers the gateways may take the decision
   to update the information accordingly based on the time-of-the-day.

   Radhika R. Roy                                            [Page 22]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002




10. Security

   The intra-ITAD protocol needs to be secured because of the
   sensitivity of the information that is being sent. Like TRIP [4],
   encryption and end-to-end authentication are needed for the intra-
   ITAD protocol as well.

11. References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3,"
   BCP 9, RFC 2026, October 1996.
   [2] Rosenburg, J. and Schulzrinne, H., _A Framework for Telephony
   Routing over IP,_ RFC 2871, IETF, June 2000.
   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
   Levels," BCP 14, RFC 2119, March 1997.
   [4] Rosenberg, J., H. Salama, H., and Squire, M., "Telephony routing
   over IP (TRIP)," Internet Draft, Internet Engineering Task Force,
   November 2000.  Work in progress.
   [5] Cuervo, N., Greene, N., Huitema, C., Rayhan, A., Rosen, B.,
   Segers, J., _MEGACO Protocol version 0.8,_ RFC 2885, Internet
   Engineering Task Force, August 2000.
   [6] Agrawal, H., Roy, R. R., Palawat, V., Johnston, A., Agboh, C.,
   Wang, D., Singh, K., and Schulzrinne, H., "SIP-H.323 Interworking ",
   draft-agrawal-roy-palawat-sip-h323-interworking-reqs-
   00.txt, IETF, April 2000. Work in progress.


Acknowledgments

   TBD

Author's Addresses

   Radhika R. Roy
   AT&T
   Room D3_3C09
   200 S. Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: +1 732 420 1580
   Fax: + 1 732 368 1302
   Email: rrroy@att.com

Full Copyright Statement

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published


   Radhika R. Roy                                            [Page 23]
Internet Draft     Framework for Intra-ITAD Protocol    January 7, 2002


   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.































   Radhika R. Roy                                            [Page 24]