rfc2871.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   call a user with a terminal on the IP network, they need to dial a
   number identifying that terminal. This number could be an IP address.
   However, IP addresses are often ephemeral, assigned on demand by DHCP
   [4] or by dialup network access servers using PPP [5]. The number
   could be a hostname, obtained through some translation of groups of
   numbers to letters. However, this is cumbersome. It has been proposed
   instead to assign phone numbers to IP telephony terminals. A caller
   on the GSTN would then dial this number as they would any other. This
   number serves as an alternate name for the IP terminal, in much the
   same way its hostname serves as a name. A switch in the GSTN must
   then access the IP network, and obtain the mapping from this number
   to an IP address for the PC. Like the previous case, this problem is
   a name to address translation problem, and is best handled by a
   directory protocol. It is not addressed by TRIP.

   The first mapping function, however, is fundamentally an address to
   route translation problem. It is this problem which is considered by
   TRIP. As discussed in Section 3, this mapping depends on local
   factors such as policies and provider relationships. As a result, the
   database of available gateways is substantially different for each
   provider, and needs to be built up through specific inter-provider
   relationships. It is for this reason that a directory protocol is not
   appropriate for TRIP, whereas it is appropriate for the others.

5 Relationship with BGP

   TRIP can be classified as a close cousin of inter-domain IP routing
   protocols, such as BGP [6]. However, there are important differences
   between BGP and TRIP:

      o TRIP runs at the application layer, not the network layer,
        where BGP resides.

      o TRIP runs between servers which may be separated by many
        intermediate networks and IP service providers. BGP runs
        between routers that are usually adjacent.






Rosenberg & Schulzrinne      Informational                      [Page 7]

RFC 2871                     TRIP Framework                    June 2000


      o The information exchanged between TRIP peers describes routes
        to application layer devices, not IP routers, as is done with
        BGP.

      o TRIP assumes the existence of an underlying IP transport
        network. This means that servers which exchange TRIP routing
        information need not act as forwarders of signaling messages
        that are routed based on this information. This is not true in
        BGP, where the peers must also act as forwarding points (or
        name an adjacent forwarding hop) for IP packets.

      o The purpose of TRIP is not to establish global connectivity
        across all ITADs. It is perfectly reasonable for there to be
        many small islands of TRIP connectivity. Each island
        represents a closed set of administrative relationships.
        Furthermore, each island can still have complete connectivity
        to the entire GSTN. This is in sharp contrast to BGP, where
        the goal is complete connectivity across the Internet. If a
        set of AS's are isolated from some other set because of a BGP
        disconnect, no IP network connectivity exists between them.

      o Gateway routes are far more complex than IP routes (since they
        reside at the application, not the network layer), with many
        more parameters which may describe them.

      o BGP exchanges prefixes which represent a portion of the IP
        name space. TRIP exchanges phone number ranges, representing a
        portion of the GSTN numbering space. The organization and
        hierarchies in these two namespaces are different.

   These differences means that TRIP borrows many of the concepts from
   BGP, but that it is still a different protocol with its own specific
   set of functions.

6 Example Applications of TRIP

   TRIP is a general purpose tool for exchanging IP telephony routes
   between providers. TRIP does not, in any way, dictate the structure
   or nature of the relationships between those providers. As a result,
   TRIP has applications for a number of common cases for IP telephony.

6.1 Clearinghouses

   A clearinghouse is a provider that serves as an exchange point
   between a number of other providers, called the members of the
   clearinghouse. Each member signs on with the clearinghouse. As part
   of the agreement, the member makes their gateways available to the
   other members of the clearinghouse. In exchange, the members have



Rosenberg & Schulzrinne      Informational                      [Page 8]

RFC 2871                     TRIP Framework                    June 2000


   access to the gateways owned by the other members of the
   clearinghouse. When a gateway belonging to one member makes a call,
   the clearinghouse plays a key role in determining which member
   terminates the call.

   TRIP can be applied here as the tool for exchanging routes between
   the members and the clearinghouse. This is shown in Figure 1.

   There are 6 member companies, M1 through M6. Each uses TRIP to send
   and receive gateway routes with the clearinghouse provider.

6.2 Confederations

   We refer to a confederation as a group of providers which all agree
   to share gateways with each other in a full mesh, without using a
   central clearinghouse. Such a configuration is shown in Figure 2.
   TRIP would run between each pair of providers.

6.3 Gateway Wholesalers

          ------                                  ------
         |      |                                |      |
         | M1   |    TRIP                 TRIP   |  M2  |
         |      |\    |                    |    /|      |
          ------  \   |                    |   /  ------
                   \ \ /   -------------- \ / /
          ------    \----|              |----/    ------
         |      |        |              |        |      |
         | M3   |--------| Clearinghouse|--------|  M4  |
         |      |        |              |        |      |
          ------    /----|              |----\    ------
                   /      --------------      \
          ------  /                            \  ------
         |      |/                              \|      |
         | M5   |                                |  M6  |
         |      |                                |      |
          ------                                  ------


          Figure 1: TRIP in the Clearinghouse Application











Rosenberg & Schulzrinne      Informational                      [Page 9]

RFC 2871                     TRIP Framework                    June 2000


                       ------        ------
                      |      |------|      |
                      | M1   |      |  M2  |
                      |      |\    /|      |
                       ------  \  /  ------
                         |      \/     |
                         |      /\     |<-----TRIP
                       ------  /  \  ------
                      |      |/    \|      |
                      | M3   |      |  M4  |
                      |      |------|      |
                       ------        ------


                 Figure 2: TRIP for Confederations

   In this application, there are a number of large providers of
   telephony gateways. Each of these resells its gateway services to
   medium sized providers. These, in turn, resell to local providers who
   sell directly to consumers. This is effectively a pyramidal
   relationship, as shown in Figure 3.

                             ------
                            |      |
                            |  M1  |
                            |      |
                             ------
                           /       \ <------- TRIP
                      ------        ------
                     |      |      |      |
                     |  M2  |      |  M3  |
                     |      |      |      |
                      ------        ------
                     /      \      /      \
               ------        ------        ------
              |      |      |      |      |      |
              | M4   |      | M5   |      | M6   |
              |      |      |      |      |      |
               ------        ------        ------

                Figure 3: TRIP for Wholesalers

   Note that in this example, provider M5 resells gateways from both M2
   and M3.







Rosenberg & Schulzrinne      Informational                     [Page 10]

RFC 2871                     TRIP Framework                    June 2000


7 Architecture

   Figure 4 gives the overall architecture of TRIP.

           ITAD1                                ITAD2
      -----------------                ------------------
     |                  |             |                  |
     |  ----            |             |           ----   |
     | | GW |           |             |          | EU |  |
     |  ----  \  ----   |             |  ----  /  ----   |
     |          | LS | ---------------- | LS |           |
     |  ----     ----   |             /  ----  \  ----   |
     | | GW | /         |            /|          | EU |  |
     |  ----            |           / |           ----   |
     |                  |          /  |                  |
      ------------------          /    ------------------
                                 /
                                /
                     --------- /----------
                    |         |           |
                    |        ----         |
                    |       | LS |        |
                    |     /  ---- \       |
                    |  ----   ||   ----   |
                    | | GW |  ||  | EU |  |
                    |  ----   ||   ----   |
                    |  ----   ||   ----   |
                    | | GW | /  \ | EU |  |
                    |  ----        ----   |
                    |                     |
                     ---------------------
                              ITAD3

                  Figure 4: TRIP Architecture

   There are a number of Internet Telephony administrative domains
   (ITAD's), each of which has at least one Location Server (LS). The
   LS's, through an out-of-band means, called the intra-domain protocol,
   learn about the gateways in their domain. The intra-domain protocol
   is represented by the lines between the GW and LS elements in ITAD1
   in the Figure. The LS's have associations with other LS's, over which
   they exchange gateway information. These associations are established
   administratively, and are set up when the IT administrative domains
   have some kind of agreements in place regarding exchange of gateway
   information. In the figure, the LS in ITAD1 is connected to the LS in
   ITAD2, which is in turn connected to the LS in ITAD3. Through
   Telephony Routing over IP (TRIP), the LS in ITAD2 learns about the
   two gateways in ITAD1. This information is accessed by end users



Rosenberg & Schulzrinne      Informational                     [Page 11]

RFC 2871                     TRIP Framework                    June 2000


   (EUs) in ITAD2 through the front-end. The front-end is a non-TRIP
   protocol or mechanism by which the LS databases are accessed. In
   ITAD3, there are both EUs and gateways. The LS in ITAD3 learns about
   the gateways in ITAD1 through a potentially aggregated advertisement
   from the LS in ITAD2.

8 Elements

   The architecture in Figure 4 consists of a number of elements. These
   include the IT administrative domain, end user, gateway, and location
   server.

8.1 IT Administrative Domain

   An IT administrative domain consists of zero or more gateways, at
   least one Location Server, and zero or more end users. The gateways
   and LS's are those which are under the administrative control of a
   single authority. This means that there is one authority responsible
   for dictating the policies and configuration of the gateways and
   LS's.

   An IT administrative domain need not be the same as an autonomous
   system. While an AS represents a set of physically connected
   networks, an IT administrative domain may consist of elements on
   disparate networks, and even within disparate autonomous systems.

   The end users within an IT administrative domain are effectively the
   customers of that IT administrative domain. They are interested in
   completing calls towards the telephone network, and thus need access
   to gateways. An end user may be a customer of one IT administrative
   domain for one call, and then a customer of a different one for the
   next call.

   An IT administrative domain need not have any gateways. In this case,
   its LS learns about gateways in other domains, and makes these
   available to the end users within its domain. In this case, the IT
   administrative domain is effectively a virtual IP telephony gateway
   provider. This is because it provides gateway service, but may not
   actually own or administer any gateways.

   An IT administrative domain need not have any end users. In this
   case, it provides "wholesale" gateway service, making its gateways
   available to customers in other IT administrative domains.

   An IT administrative domain need not have gateways nor end users. In
   this case, the ITAD only has LS's. The ITAD acts as a reseller,
   learning about other gateways, and then aggregating and propagating
   this information to other ITAD's which do have customers.



Rosenberg & Schulzrinne      Informational                     [Page 12]

RFC 2871                     TRIP Framework                    June 2000


8.2 Gateway

   A gateway is a logical device which has both IP connectivity and
   connectivity to some other network, usually a public or private
   telephone network. 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.

   A gateway has a number of attributes which characterize the service
   it provides. Most fundamental among these are the range of phone
   numbers to which it is willing to provide service. This range may be
   broken into subranges, and associated with each, some cost metric or
   cost token. This token indicates some notion of cost or preference
   for completing calls for this part of the telephone number range.

   A gateway has attributes which characterize the volume of service
   which it can provide. These include the number of ports it has (i.e.,
   the number of simultaneous phone calls it can support), and the
   access link speed. These two together represent some notion of the
   capacity of the gateway. The metric is useful for allowing Location
   Servers to decide to route calls to gateways in proportion to the
   value of the metric, thus achieving a simple form of load balancing.