rfc2871.txt

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

        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


   Some of the possible protocols for the front end are:

     Service Location Protocol (SLP): SLP has been designed to fit
        exactly this kind of function. SLP is ideal for locating servers
        described by a set of attributes. In this case, the server is a
        gateway (or next hop towards the gateway), and the attributes
        are the end user policy. The end user is an SLP UA, and the LS
        is an SLP DA. The Service Query is used to ask for a gateway
        with a particular set of attributes.

     Open Settlements Protocol (OSP): OSP [11] is a client server
        protocol. It allows the client to query a server with a phone
        number, and get back the address of a next hop, along with
        authorization tokens to use for the call. In this case, the
        server can be an LS. The routing table it uses to respond to OSP
        queries is the one built up using TRIP.

     Lightweight Directory Access Protocol (LDAP): LDAP is used for
        accessing distributed databases. Since the LS server contains a
        database, LDAP could be used to query it.

     Web Page: The LS could have a web front end. Users could enter
        queries into a form, and the matching gateways returned in the
        response. This access mechanism is more appropriate for human
        access, however. A signaling server would not likely access the
        front end through a web page.

     TRIP: The protocols discussed above are all of the query-response
        type. There is no reason why the LS access must be of this form.
        It is perfectly acceptable for the access to be through complete
        database synchronization, so that the entity accessing the LS
        database effectively has a full copy of it. If this approach
        were desired, TRIP itself is an appropriate mechanism. This
        approach has obvious drawbacks, but nothing precludes it from
        being done.

11 Number Translations

   The model for TRIP is that of many gateways, each of which is willing
   to terminate calls towards some set of phone numbers. Often, this set
   will be based on the set of telephone numbers which are 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. Of course, it is up to the administrator to decide on what
   phone numbers the gateway is willing to call.






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


   However, certain phone numbers don't represent GSTN terminals at all,
   but rather they represent services or virtual addresses. An example
   of such numbers are freephone and LNP numbers. 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.

   While nothing prevents a gateway from advertising reachability to
   these kinds of numbers, this usage is highly discouraged. Since TRIP
   is a routing protocol, the routes it propagates should be to routable
   numbers, not to names which are eventually translated to routable
   numbers. Numerous problems arise when TRIP is used to propagate
   routes to these numbers:

      o Often, these numbers have only local significance. Calls to a
        freephone number made from New York might terminate in a New
        York office of a company, while calls made from California
        will terminate in a California branch. If this freephone
        number is injected into TRIP by a gateway in New York, it
        could be propagated to other LS's with end users in
        California. If this route is used, calls may be not be routed
        as intended.

      o The call signaling paths might be very suboptimal. Consider a
        gateway in New York that advertises a ported number that maps
        to a phone in California. This number is propagated by TRIP,
        eventually being learned by an LS with end users in
        California. When one of them dials this number, the call is
        routed over the IP network towards New York, where it hits the
        gateway, and then is routed over the GSTN back to California.
        This is a waste of resources. Had the ported number been
        translated before the gateway routing function was invoked, a
        California gateway could have been accessed directly.

   As a result, it is more efficient to perform translations of these
   special numbers before the LS routing databases are accessed. How
   this translation is done is outside the scope of TRIP. It can be
   accomplished by the calling device before making the call, or by a
   signaling server before it accesses the LS database.

12 Security Considerations

   Security is an important component in TRIP. The TRIP model assumes a
   level of trust between peer LS's that exchange information. This
   information is used to propagate information which determines where
   calls will be routed. If this information were incorrect, it could
   cause complete misrouting of calls. This enables a significant denial
   of service attack. The information might also be propagated to other



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


   ITADs, causing the problem to potentially spread. As a result, mutual
   authentication of peer LS's is critical. Furthermore, message
   integrity is required.

   TRIP messages may contain potentially sensitive information. They
   represent the routing capabilities of an ITAD. Such information might
   be used by corporate competitors to determine the network topology
   and capacity of the ITAD. As a result, encryption of messages is also
   supported in TRIP.

   As routing objects can be passed via one LS to another, there is a
   need for some sort of end to end authentication as well. However,
   aggregation will cause the routing objects to be modified, and
   therefore authentication can only take place from the point of last
   aggregation to the receiving LS's.

13 Acknowledgments

   The authors would like to thank Randy Bush, Mark Foster, Dave Oran,
   Hussein Salama, and Matt Squire for their useful comments on this
   document.

14 Bibliography

   [1]  International Telecommunication Union, "Visual telephone systems
        and equipment for local area networks which provide a non-
        guaranteed quality of service," Recommendation H.323,
        Telecommunication Standardization Sector of ITU, Geneva,
        Switzerland, May 1996.

   [2]  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
        "SIP:  Session Initiation Protocol", RFC 2543, March 1999.

   [3]  Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett,
        "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705,
        October 1999.

   [4]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

   [5]  Simpson, W., "The Point-to-Point Protocol (PPP)," STD 51, RFC
        1661, July 1994.

   [6]  Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
        1771, March 1995.

   [7]  Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
        Location Protocol", RFC 2165, June 1997.



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


   [8]  Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access
        Protocol", RFC 1777, March 1995.

   [9]  Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
        Location Protocol, Version 2", RFC 2608, June 1999.

   [10] Schulzrinne H. and J. Rosenberg, "SIP caller preferences and
        callee capabilities", Work in progress.

   [11] European Telecommunications Standards Institute (ETSI),
        Telecommunications and Internet Protocol Harmonization Over
        Networks (TIPHON), "Inter-domain pricing, authorization, and
        usage exchange," Technical Specification 101 321 version 1.4.2,
        ETSI, 1998.

15 Authors' Addresses

   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936

   Email: [e-mail]


   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003

   Email: [e-mail]


















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


16.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

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

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

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

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Rosenberg & Schulzrinne      Informational                     [Page 25]