rfc2871.txt

RFC规范的翻译稿

者远程ITAD的LS来了解。LS可以将这些路由对象聚合到一起（合并电话码的范围，用自
己的或与LS通信的信令服务器的IP地址代替那些IP地址，）然后传播给另一个LS。决定
哪一个对象进行聚合和传播称为路由选择操作。管理员在决定对哪一个对象进行聚合和传播
上有很大的选择自由，只要他们在正确的协议操作范围内（无回路形成）。选择可以基于通
过TRIP了解到的信息，或者任何其他带外方式。
路由对象可以有表述网关服务特征的附加信息。这些属性包括协议、支持特征和容量等
等。属性越多可以提供有益的信息就越多，但是，它们也会带来开销。越来越多的信息会使
集合操作变得困难，严重影响协议的伸缩性。
聚合在TRIP中起核心的作用。为了提高伸缩性，路由对象在传播之前可以聚合为更大
的集合。TRIP中描述了这种机制。应用层的集合路由到网关并不是一个简单的问题。在聚
合和冗长之间存在着基本的权衡。TRIP路由对象中信息越多，聚合就越困难。
考虑一个两个网关的简单例子。网关A和B分别可以到达电话号码区X和Y，。C是A、
B所在ITAD中的一个LS。C通过一些方法了解A和B。当他工作时，X和Y被合并为一个单
一地址范围Z。C有几个选项。它可以散播A的信息，也可以散播B的信息，也可以同时散
播A和B，或者将他们合并然后再散播。在本例中，C选择后一种方式，发送一个路由对象
到一个对等体D，其中包含地址范围Z和它自己的地址，由于它也是一个信令服务器。D也
是一个信令服务器。
呼叫装置E希望拨一个电话号码T,该号码恰巧在地址范围X内。E被配置使用D作为他
的默认H.323关守。于是E发送一个呼叫建立信息给D，其中包含目的地址T。D判断出地
址T在Z内。由于D已经接受了一个来自于C的包含地址范围Z的路由对象，它将呼叫建立
消息转发给C。接着，C发现T在地址范围X内，于是它继续将消息发到A，A结束呼叫信令
并向电话网发起一个呼叫。
9.2.2 服务质量
当选择网关时，一个值得考虑的因素是服务质量（QoS），即呼叫通过这个网关所经历的
损失、延时和波动等。呼叫的质量取决于两个因素：呼叫者和网关之间路径上的服务质量和
网关本身的能力（衡量可依据电路门数、链路容量、DSP资源等等）。后者的确定需要复杂
的底层网络拓扑知识和呼叫者定位知识。这些因素由QoS路由协议控制，不属于TRIP的范
围。
但是，网关容量不靠呼叫者的位置或者路径特征。因此，TRIP支持一些形式的容量度
量。这种度量表述了网关的静态容量，而不是网关工作期间不断变化的动态可用容量。LS
可用该度量作为网关间对呼叫负载平衡的手段。它也可用作对任何其他策略判断的输入。
9.2.3 费用信息
对传播的另一个有用属性是费用度量。它可以表示为一个特定的网关对呼叫的收费。它
可以是一个到根据预先存在的商业协议而定义了价格结构的表的索引，或者它本身就表示了
费用。TRIP本身不定义价格度量，但可以且应该作为一个扩展定义。使用一个价格扩展意
味着可以定义更多的度量。
10．前端
作为TRIP的一个结果，LS建立了一个网关路由的数据库（即TRIB）。这些信息被ITAD
中各种实体所利用。这种将信息加工成可用的方法称为前端。通过这种明显的方式TRIP服
务被暴露在协议外。
10.1 前端客户
目前有以下几种实体（可能不止这几种）会使用前端来访问TRIB：
信令服务器：信令服务器接受信令消息（例如H.323或者SIP消息），这些消息用于初
始化IP电话呼叫。这些呼叫的目的地址可以是一个与GSTN终端相对应的电话号码。为了将
这些呼叫路由到一个合适的网关，信令服务器需要访问建在LS上的数据库。
端用户：端用户可以直接查询LS取得路由信息。此举允许他们提供需求的细节信息。
然后，他们可以联系通往被呼叫电话号码的下一跳信令服务器或者网关。
管理员：管理员需要访问TRIB来完成维护和管理功能。
当一个信号服务器联系LS路由电话号码时，它通常正在这么做，因为呼叫设备（代表
端用户）已经尝试要建立一个呼叫。结果，信令服务器作为端用户的代理高效地访问LS数
据库。呼叫设备和他们的代理人（信令服务器）之间通过信令协议通信。
这种代理方法的优点是使真实的LS交互对于呼叫设备隐藏起来。因此，不管呼叫是电
话号码还是IP地址都无所谓。如果是电话号码，则路由透明地发生。代理模式令一个优点
是方便了瘦客户端，因为它们没有接口或者处理能力直接查询局域服务器（例如：单独的
IP电话）。这种代理方法的优点同样也是它的缺点-真实的LS交互对于呼叫设备（即端用户）
隐藏起来了。在某些情况下，端用户需要知道呼叫如何被路由，包括花费、质量、管理员、
或者呼叫服务和协议。这些需求称为端用户策略。在代理方法中，用户能通过信令协议高效
地访问服务。信号协议不可能为端用户支持复杂的呼叫路由首选项的表述。（注意：SIP可
以为呼叫路由支持一些形式的呼叫者首选项。）因此，由端用户直接访问局域数据库可以提
供更丰富的呼叫路由服务。当端用户策略被提交到LS时（或者直接或者通过信令协议），LS
判断如何使用它。LS有它自己的策略来处理端用户首选项。
10.2 前端协议
有许多协议可用于前端访问LS数据库。TRIP不指定或限制对于前端访问的可能性。目
前并不清楚是否应该制定一个单一的前端访问标准。每个协议各有优缺点。有些适用于一些
场合，而另一些则适用于其它场合。
当前的前端协议有：
     Service Location Protocol (SLP): 服务定位协议，SLP设计为可以精确地满足这种
功能。SLP对于由属性集描述的定位服务器非常理想。这时服务器是一个网关，或者通向网
关的下一跳，而属性则是端用户策略。端用户是一个SLP UA，并且LS是一个SLP DA。服务查
询（Service Query）用于通过特定属性集寻找网关。
     Open Settlements Protocol (OSP): 开放结算协议，OSP [11]是一个客户/服务器协
议。它允许客户通过电话号码查询服务器，并得到下一跳的地址，以及用于呼叫的认证令牌。
此时，服务器可以是LS。响应OSP查询的路由表就是用TRIP建立起来的。
     Lightweight Directory Access Protocol (LDAP): 轻量目录访问协议，LDAP用于访
问分布式数据库。由于LS上有数据库，LDAP可以用来进行查询。
     Web Page: Web页面，LS也可以有Web前端。用户可以将查询输入form，响应中就返回
匹配的网关。这种访问机制更适合于人直接访问。不过信令服务器可不喜欢通过Web页面来
访问前端。
     TRIP: 前面讨论的协议都是关于查询响应类型。至于为什么LS访问必须是这种形式并
没有什么理由。通过完全数据库同步访问也是可以接受的，这样一来，访问LS的实体就有一
个完全的备份。虽然这种方法有明显的缺点，不过不妨碍具体实施。
11．号码翻译
TRIP模型有许多网关，每个网关都可以完成通往一些电话号码集的呼叫。通常，这些
电话号码集按照在地理上与网关相近来划分的。例如。一个纽约的网关可以完成区号为212
到718的呼叫。当然，实际上是管理员决定那些号码由那个网关完成。
但是，某些电话号码根本不是GSTN终端，而是服务或者虚拟地址。例如：免费电话和
LNP。在电话网络中，它们被真实的映射到可路由的电话号码，通常都要基于复杂的公式。
典型的例子是基于time-of-day的转换。
由于没有什么措施可以保护网关不受到这种号码的广告可达性的影响，因此不鼓励采用
这种用法。TRIP是一个路由协议，它传播的路由应该是可路由号码，不是最终转化为可路
由号码的名字。当TRIP用于传播到达这些号码的路由的时候，会产生很多问题：
?	通常，这些号码仅在局部有意义。从纽约呼叫一个免费电话可以终结于纽约某个公
司的办公室，从加利福尼亚呼叫的仅可以在加利福尼亚完成。如果这个免费电话在
纽约通过网关接入TRIP，它将被传播到加利福尼亚端用户使用的LS。如果使用了
这个路由，则呼叫可能无法按照用户的意愿进行。
?	呼叫信令路径可能远远达不到最佳。设想一个在纽约的网关广告一个映射到加利福
尼亚的电话的端口号码。该号码由TRIP传播，最终被加利福尼亚端用户使用的LS
了解。当一个用户拨这个号码时，呼叫由IP网络路由到纽约，找到符合的网关，
然后由GSTN路由返回加利福尼亚。这样做十分浪费资源。如果网关路由功能启用
之前端口号码已经被转换，就可以直接访问加利福尼亚的网关。
因此，在LS路由数据库访问之前完成这些特定号码的转换应该更高效。怎样完成这一
转换不属于TRIP的范围。它可以由呼叫设备在在呼叫之前完成，或者在访问LS数据库之前
由信令服务器完成。
12．安全考虑
安全是TRIP的重要组成部分。TRIP模型假设交换信息的对等LS之间相互信任的。这
些消息被用于传播确定呼叫路由的信息。如果信息是错误的，将导致一个错误的路由。这会
造成一种严重的拒绝服务攻击。这些信息也可以被传播到其他的ITAD，致使问题潜在的扩
散。结果，对等LS的相互认证是很关键的，而且，信息的完整性也要保证。
TRIP消息可以包含潜在的敏感信息。他们表示了一个ITAD的路由容量。这样的信息可
以被竞争对手利用来判断ITAD网络的拓扑和容量。因此，TRIP也支持消息加密。
由于路由对象可以在LS间传递，也需要某种形式的端到端认证。但是聚合会导致路由
对象改变，因此认证只能从接收LS的最后一个聚合点开始进行。
13．鸣谢
   感谢Randy Bush, Mark Foster, Dave Oran,Hussein Salama,和Matt Squire为本文提出的有
益见解。
14．参考资料
   [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.
   [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．作者地址
   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]
16．版权声明
   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.
致谢
   Funding for the RFC Editor function is currently provided by the
   Internet Society.




RFC 2871——A Framework for Telephony Routing over IP		     一个IP电话路由框架


1
RFC文档中文翻译计划