rfc2871.txt

RFC 的详细文档！


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.

   A gateway also has attributes which characterize the type of service
   it provides. This includes, but is not limited to, signaling
   protocols supported, telephony features provided, speech codecs
   understood, and encryption algorithms which are implemented. These
   attributes may be important in selecting a gateway. In the absence of
   baseline required features across all gateways (an admirable, but
   difficult goal), such a set of attributes is required in order to
   select a gateway with which communications can be established. End
   users which have specific requirements for the call (such as a user
   requesting a business class call, in which case certain call features
   may need to be supported) may wish to make use of such information as
   well.

   Some of these attributes are transported in TRIP to describe
   gateways, and others are not. This depends on whether the metric can
   be reasonably aggregated, and whether it is something which must be
   conveyed in TRIP before the call is set up (as opposed to negotiated
   or exchanged by the signaling protocols themselves). The philosophy
   of TRIP is to keep it simple, and to favor scalability above
   abundance of information. TRIP's attribute set is readily extensible.
   Flags provide information that allow unknown attributes to be
   reasonably processed by an LS.





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


8.3 End Users

   An end user is an entity (usually a human being) which wishes to
   complete a call through a gateway from an IP network to a terminal on
   a telephone network. An end user may be a user logged on at a PC with
   some Internet telephony software. The end user may also be connected
   to the IP network through an ingress telephone gateway, which the
   user accessed from telephone handset. This is the case for what is
   referred to as "phone to phone" service with the IP network used for
   interexchange transport.

   End users may, or may not be aware that there is a telephony routing
   service running when they complete a call towards the telephone
   network. In cases where they are aware, end users may have
   preferences for how a call is completed. These preferences might
   include call features which must be supported, quality metrics, owner
   or administrator, and cost preferences.

   TRIP does not dictate how these preferences are combined with those
   of the provider to yield the final gateway selection. Nor does TRIP
   support the transport of these preferences to the LS. This transport
   can be accomplished using the front end, or by some non-protocol
   means.

8.4 Location Server

   The Location Server (LS) is the main functional entity of TRIP.  It
   is a logical device which has access to a database of gateways,
   called the Telephony Routing Information Base (TRIB). This database
   of gateways is constructed by combining the set of locally available
   gateways and the set of remote gateways (learned through TRIP) based
   on policy. The LS also exports a set of gateways to its peer LS's in
   other ITAD's. The set of exported gateways is constructed from the set
   of local gateways and the set of remote gateways (learned through
   TRIP) based on policy. As such, policy plays a central role in the LS
   operation. This flow of information is shown in Figure 5.















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


                          |
                          |Intra-domain protocol
                         \ /
                        Local
                       Gateways


   TRIP-->  Gateways    POLICY     Gateways -->TRIP
                IN                     Out
                             |
                            \ /
                      Telephony Routing
                      Information Base

            Figure 5: Flow of Information in TRIP

   The TRIB built up in the LS allows it to make decisions about IP
   telephony call routing. When a signaling message arrives at a
   signaling server, destined for a telephone network address, the LS's
   database can provide information which is useful for determining a
   gateway or an additional signaling server to forward the signaling
   message to. For this reason, an LS may be coresident with a signaling
   server. When they are not coresident, some means of communication
   between the LS and the signaling server is needed. This communication
   is not specifically addressed by TRIP, although it is possible that
   TRIP might meet the needs of such a protocol.

   An ITAD must have at least one LS in order to participate in TRIP.
   An ITAD may have more than one LS, for purposes of load balancing,
   ease of management, or any other reason. In that case, communications
   between these LS's may need to take place in order to synchronize
   databases and share information learned from external peers. This is
   often referred to as the interior component of an inter-domain
   protocol. TRIP includes such a function.

   Figure 5 shows an LS learning about gateways within the ITAD by means
   of an intra-domain protocol. There need not be an intra-domain
   protocol. An LS may operate without knowledge of any locally run
   gateways. Or, it may know of locally run gateways, but through static
   configuration. An LS may also be co-resident with a gateway, in which
   case it would know about the gateway that it is co-resident with.










Rosenberg & Schulzrinne      Informational                     [Page 15]