rfc2871.txt

RFC 的详细文档！

RFC 2871                     TRIP Framework                    June 2000


9 Element Interactions

9.1 Gateways and Location Servers

   Gateways must somehow propagate information about their
   characteristics to an LS within the same ITAD. This LS may, in turn,
   further propagate this information outside of the ITAD by means of
   TRIP. This LS is called an originating LS for that gateway. When an
   LS nis not coresident with the gateway, the means by which the
   information gets propagated is not within the scope of TRIP.  The
   protocol used to accomplish this is generally called an intra-domain
   protocol.

   One way in which the information can be propagated is with the
   Service Location Protocol (SLP) [7]. The gateway can contain a
   Service Agent (SA), and the LS can act as a Directory Agent (DA). SLP
   defines procedures by which service information is automatically
   propagated to DA's from SA's. In this fashion, an LS can learn about
   gateways in the ITAD.

   An alternate mechanism for the intra-domain protocol is via the
   registration procedures of SIP or H.323. The registration procedures
   provide a means by which users inform a gatekeeper or SIP server
   about their address. Such a registration procedure could be extended
   to allow a gateway to effectively register as well.

   LDAP [8] might also be used for the intra-domain protocol.  A gateway
   can use LDAP to add an entry for itself into the database. If the LS
   also plays the role of the LDAP server, it will be able to learn
   about all those gateways in its ITAD.

   The intra-domain protocol which is used may be different from IT
   administrative domain to IT administrative domain, and is a matter of
   local configuration. There may also be more than one intra-domain
   protocol in a particular ITAD. An LS can also function without an
   intra-domain protocol. It may learn about gateways through static
   configuration, or may not know of any local gateways.

9.2 Location Server to Location Server

   The interaction between LS's is what is defined by TRIP.  LS's within
   the same ITAD use TRIP to synchronize information amongst themselves.
   LS's within different ITADs use TRIP to exchange gateway information
   according to policy. In the former case the LS's are referred to as
   internal peers, and in the latter case, external peers.






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


   LS's communicate with each other through persistent associations. An
   LS may be connected to one or more other LS's. LS's need not be
   physically adjacent or part of the same autonomous system. The
   association between a pair of LS's is normally set up
   administratively. Two LS's are configured to communicate with each
   other when their administrators have an agreement in place to
   exchange gateway information. While TRIP does not provide an
   autodiscovery procedure for peer LS's to discover each other, one
   could possibly be used. Such a procedure might be useful for finding
   a backup peer LS when a crash occurs. Alternatively, in an
   environment where the business relationships between peers become
   more standardized, peers might be allowed to discover each other
   through protocols like the Service Location Protocol (SLP) [9].
   Determination about whether autodiscovery should or should not be
   used is at the discretion of the administrator.

   The syntax and semantics of the messages exchanged over the
   association between LS's are dictated by TRIP.  The protocol does not
   dictate the nature of the agreements which must be in place. TRIP
   merely provides a transport means to exchange whatever gateway
   routing information is deemed appropriate by the administrators of
   the system. Details are provided in the TRIP protocol specification
   itself.

   The rules which govern which gateway information is generated,
   propagated, and accepted by a gateway is called a location server
   policy. TRIP does not dictate or mandate any specific policy.

9.2.1 Nature of Exchanged Information

   The information exchanged by the LS's is a set of routing objects.
   Each routing object minimally consists of a range of telephone
   numbers which are reachable, and an IP address or host name which is
   the application-layer "next hop" towards a gateway which can reach
   that range. Routing objects are learned from the intra-domain
   protocol, static configuration, or from LS's in remote ITAD's. An LS
   may aggregate these routing objects together (merging ranges of
   telephone numbers, and replacing the IP address with its own IP
   address, or with the IP address of a signaling server with which the
   LS is communicating) and then propagate them to another LS. The
   decision about which objects to aggregate and propagate is known as a
   route selection operation. The administrator has great latitude in
   selecting which objects to aggregate and propagate, so long as they
   are within the bounds of correct protocol operation (i.e., no loops
   are formed). The selection can be made based on information learned
   through TRIP, or through any out of band means.





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


   A routing object may have additional information which characterizes
   the service at the gateway. These attributes include things like
   protocols, features supported, and capacity. Greater numbers of
   attributes can provide useful information, however, they come at a
   cost. Aggregation becomes difficult with more and more information,
   impacting the scalability of the protocol.

   Aggregation plays a central role in TRIP. In order to facilitate
   scalability, routing objects can be combined into larger aggregates
   before being propagated. The mechanisms by which this is done are
   specified in TRIP. Aggregation of application layer routes to
   gateways is a non-trivial problem. There is a fundamental tradeoff
   between aggregatability and verbosity. The more information that is
   present in a TRIP routing object, the more difficult it is to
   aggregate.

   Consider a simple example of two gateways, A and B, capable of
   reaching some set of telephone numbers, X and Y, respectively. C is
   an LS for the ITAD in which A and B are resident. C learns of A and B
   through some other means. As it turns out, X and Y can be combined
   into a single address range, Z. C has several options. It can
   propagate just the advertisement for A, just the advertisement for B,
   propagate both, or combine them and propagate the aggregate
   advertisement. In this case C chooses the latter approach, and sends
   a single routing object to one of its peers, D, containing address
   range Z and its own address, since it is also a signaling server. D
   is also a signaling server.

   Some calling device, E, wishes to place a phone call to telephone
   number T, which happens to be in the address range X. E is configured
   to use D as its default H.323 gatekeeper. So, E sends a call setup
   message to D, containing destination address T. D determines that the
   address T is within the range Z. As D had received a routing object
   from C containing address range Z, it forwards the call setup message
   to C. C, in turn, sees that T is within range X, and so it forwards
   the call setup to A, which terminates the call signaling and
   initiates a call towards the telephone network.

9.2.2 Quality of Service

   One of the factors which is useful to consider when selecting a
   gateway is "QoS" - will a call through this gateway suffer
   sufficiently low loss, delay, and jitter? The quality of a call
   depends on two components - the QoS on the path between the caller
   and gateway, and the capacity of the gateway itself (measured in
   terms of number of circuits available, link capacity, DSP resources,
   etc.). Determination of the latter requires intricate knowledge of




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


   underlying network topologies, and of where the caller is located.
   This is something handled by QoS routing protocols, and is outside
   the scope of TRIP.

   However, gateway capacity is not dependent on the caller location or
   path characteristics. For this reason, a capacity metric of some form
   is supported by TRIP. This metric represents the static capacity of
   the gateway, not the dynamic available capacity which varies
   continuously during the gateways operation. LS's can use this metric
   as a means of load balancing of calls among gateways. It can also be
   used as an input to any other policy decision.

9.2.3 Cost Information

   Another useful attribute to propagate is a pricing metric. 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. TRIP 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.

10 The Front End

   As a result of TRIP, the LS builds up a database (the TRIB) of
   gateway routes. This information is made available to various
   entities within the ITAD. The way in which this information is made
   available is called the front end. It is the visible means by which
   TRIP services are exposed outside of the protocol.

10.1 Front End Customers

   There are several entities which might use the front end to access
   the TRIB. These include, but are not limited to:

     Signaling Servers: Signaling servers receive signaling messages
        (such as H.323 or SIP messages) whose purpose is the initiation
        of IP telephony calls. The destination address of these calls
        may be a phone number corresponding to a terminal on the GSTN.
        In order to route these calls to an appropriate gateway, the
        signaling server will need access to the database built up in
        the LS.

     End Users: End users can directly query the LS to get routing
        information. This allows them to provide detailed information on
        their requirements. They can then go and contact the next hop
        signaling server or gateway towards that phone number.



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


     Administrators: Administrators may need to access the TRIB for
        maintenance and management functions.

   When a signaling server contacts the LS to route a phone number, it
   is usually doing so because a calling device (on behalf of an end
   user) has attempted to set up a call. As a result, signaling servers
   effectively act as proxies for end users when accessing the LS
   database. The communication between the calling devices and their
   proxies (the signaling servers) is through the signaling protocol.

   The advantage of this proxy approach is that the actual LS
   interaction is hidden from the calling device. Therefore, whether the
   call is to a phone number or IP address is irrelevant. The routing in
   the case of phone numbers takes place transparently. Proxy mode is
   also advantageous for thin clients (such as standalone IP telephones)
   which do not have the interfaces or processing power for a direct
   query of the LS.

   The disadvantage of the proxy approach is the same as its advantage -
   the LS interaction is hidden from the calling device (and thus the
   end user). In some cases, the end user may have requirements as to
   how they would like the call to be routed. These include preferences
   about cost, quality, administrator, or call services and protocols.
   These requirements are called the end user policy. In the proxy
   approach, the user effectively accesses the service through the
   signaling protocol. The signaling protocol is not likely to be able
   to support expression of complex call routing preferences from end
   users (note however, that SIP does support some forms of caller
   preferences for call routing [10]). Therefore, direct access from the
   end user to the LS can provide much richer call routing services.

   When the end user policy is presented to the LS (either directly or
   through the signaling protocol), it is at the discretion of the LS
   how to make use of it. The location server may have its own policies
   regarding how end user preferences are handled.

10.2 Front End Protocols

   There are numerous protocols that can be used in the front end to
   access the LS database. TRIP does not specify or restrict the
   possibilities for the front end. It is not clear that it is necessary
   or even desirable for there to be a single standard for the front
   end. The various protocols have their strengths and weaknesses. One
   may be the right solution in some cases, and another in different
   cases.






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