组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：张惠卿（zhang_vivian&nbsp;&nbsp;&nbsp;y00415@em.njupt.edu.cn&nbsp;）<br />
译文发布时间：2001-3-28<br />
版权：本翻译文档可以用于非商业用途自由转载，但必须保留本文档的翻译及组织信息。<br />
<br />
<br />
<br />
<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;B.&nbsp;Davie<br />
Request&nbsp;for&nbsp;Comments:&nbsp;3035&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J.&nbsp;Lawrence<br />
Category:&nbsp;Standards&nbsp;Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;K.&nbsp;McCloghrie<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;E.&nbsp;Rosen<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;G.&nbsp;Swallow<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Y.&nbsp;Rekhter<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Juniper&nbsp;Networks<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;P.&nbsp;Doolan<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Ennovate&nbsp;Networks,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;January&nbsp;2001<br />
<br />
<br />
<br />
用LDP和ATM的VC交换实现MPLS<br />
<br />
（RFC&nbsp;3035----MPLS&nbsp;using&nbsp;LDP&nbsp;and&nbsp;ATM&nbsp;VC&nbsp;Switching）<br />
<br />
本备忘录的状态<br />
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。请参考最新版的“Internet正式协议标准”&nbsp;(STD1)来获得本协议的标准化程度和状态。本备忘录的发布不受任何限制。<br />
版权声明<br />
Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(2001).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
<br />
<br />
摘要&nbsp;&nbsp;<br />
<br />
多协议标签交换(MPLS)体系讨论了一种将ATM交换机用作标签交换路由器的方式.&nbsp;ATM交换机执行网络层路由算法(如开放最短优先路由(OSPF),&nbsp;中间-中间层系统(IS-IS)等),&nbsp;并基于这些路由算法来转发数据.&nbsp;不需要特定的ATM路由或寻址.&nbsp;在这里,&nbsp;ATM交换机被称为ATM-标签交换路由器.&nbsp;&nbsp;这篇文档通过详细说明向ATM-LSR分配和从ATM-LSR得到的代表等效前传类(FECs)的标签的过程,&nbsp;&nbsp;扩充和阐明了[1]和[2]的相关部分.&nbsp;FECs&nbsp;是在逐跳方式的基础上,通过网络层路由算法来决定路由.&nbsp;这篇文档还详细说明了向ATM-LSR发送和从ATM-LSR中等到标签分组的MPLS封装,&nbsp;关于此方面的介绍参见相关文档[3].<br />
<br />
<br />
<br />
目录<br />
<br />
1.&nbsp;概述	2<br />
2.&nbsp;定义	2<br />
3.&nbsp;ATM交换的特征	3<br />
4.&nbsp;ATM标签交换控制组件	3<br />
5.&nbsp;混合交换(夜晚行船)	4<br />
6.&nbsp;使用VPI/VCI	4<br />
6.1&nbsp;直接连接	4<br />
6.2&nbsp;通过ATM&nbsp;VP的连接	5<br />
6.3&nbsp;通过ATM&nbsp;SVC的连接	5<br />
7.&nbsp;标签分配及维护过程	5<br />
7.1&nbsp;边缘LSR行为	5<br />
7.2&nbsp;传统ATM交换(非VC合并)	6<br />
7.3&nbsp;能实现VC合并的ATM交换	7<br />
8.&nbsp;封装	8<br />
9.&nbsp;TTL操作	8<br />
10.&nbsp;可选环路检测:&nbsp;分布路径矢量	9<br />
10.1&nbsp;何时发送下游路径矢量	9<br />
10.2&nbsp;何时发送上游路径矢量	10<br />
11.&nbsp;安全考虑	10<br />
12&nbsp;参考文献	10<br />
1.&nbsp;概述<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MPLS体系结构讨论了一种将ATM交换机用作标签交换路由器的的方式.&nbsp;ATM交换机运行网络层路由算法(如OSPF,&nbsp;IS-IS等),&nbsp;并基于这些路由算法转发数据.&nbsp;不需要特定的ATM路由或寻址.&nbsp;ATM交换机在此称为ATM-标签交换路由器(ATM-LSR).&nbsp;&nbsp;&nbsp;&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;这篇文档通过详细说明向ATM-LSR分配和从ATM-LSR得到代表等效前传类(FECs)的标签的过程,&nbsp;扩充及阐明了[1]和[2]的相关部分.&nbsp;FECs是由网络层路由算法基于逐跳方式来决定路由.&nbsp;这里所说的标签分配技术在[1]中被称为"下游按需".&nbsp;对不能进行VC合并的ATM-LSR必须使用标签分配技术(在第三部分中定义),&nbsp;对能进行VC合并的ATM-LSR可以随意选择.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;这篇文档对在下述情况下的标签分配技术没有规范定义.<br />
*&nbsp;在标签分配开始前,&nbsp;路由就被确定,&nbsp;而不是由逐跳机制标签分配过程中确定.<br />
*&nbsp;路由与任何时候由传统逐跳路由决定的路由不相同.<br />
*&nbsp;标签代表了包括了多播组的等效前传类.<br />
*&nbsp;标签分配路由器使用"VP合并"<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;文档关于ATM-LSR标签的进一步阐述,&nbsp;不必要在以上情况中应用.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;文档还详细说明了当发送或接收ATM-LSR的标签分组时使用的MPLS的封装,&nbsp;在这个方面,还有一个相关的[3]文档.&nbsp;这种封装规范还将用于多播或显式路由标签分组.<br />
<br />
2.&nbsp;定义<br />
LSR---标签交换路由器是实现标签交换控制和转发在[1]中描述的组件的设备<br />
LC-ATM---标签交换控制ATM接口是由标签交换控制组件控制的ATM接口.&nbsp;当接收一个穿越该接口的分组时,&nbsp;该分组就视为标签分组.&nbsp;由VCI字段或VPI及VCI联合字段的内容来决定分组的最高标签.&nbsp;任何两个通过LC-ATM接口连接的对等LPD(标识分发协议)将使用LDP协议来决定以上的情况的哪种适应于该接口.<br />
ATM-LSR---是一种有许多LC-ATM接口的LSR,&nbsp;&nbsp;用在VCI字段或VPI/VCI字段在携带的标签,&nbsp;在接口间转发信元,&nbsp;而不是在转发前将信元重组成帧.<br />
基于帧的LSR是一种在它的接口间转发完整帧的LSR.&nbsp;注意这样的LSR可能没有,&nbsp;或有一个,&nbsp;多个LC-ATM接口.<br />
有时一个单一的盒,&nbsp;对于特定的接口,&nbsp;实现ATM-LSR的功能,&nbsp;但在其它的场合,&nbsp;又可实现基于帧的LSR功能.&nbsp;如,&nbsp;有以太接口的ATM交换机,&nbsp;在它的LC-ATM接口中转发信元时可以实现ATM-LSR的功能,&nbsp;然而要在它的以太接口到其中一个LC-ATM接口间转发帧时,&nbsp;就实现基于帧的LSR功能.&nbsp;在这种情况下,&nbsp;可以在同一个盒子中实现两种功能.<br />
常用一个LC-ATM接口来连接两个ATM-LSRs,&nbsp;或连接一个ATM-LSR到基于帧的LSR上.&nbsp;在文档中没有考虑使用LC-ATM接口来连接两个基于帧的LRS.<br />
ATM-LSR域是一组ATM-LSR,&nbsp;ATM-LSR由LC-ATM接口相互连接.<br />
ATM-LSR域的边缘组是一组基于帧的LSR,&nbsp;它们通过LC-ATM接口在组的各个域中互连.&nbsp;基于帧的LSR,&nbsp;若是ATM-LSR域中边缘组的成员,&nbsp;则被称为边缘LSR.<br />
VC合并即交换机在几个输入VCI中接收信元并在单一的输出VCI中将信元输出,&nbsp;不会导致不同的AAL5&nbsp;层PDU信元交错.<br />
<br />
3.&nbsp;ATM交换的特征<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MPLS体系在LSR的实现方面有很大的灵活性,&nbsp;ATM-LSR拘泥于硬件(可能已经存在)的性能,&nbsp;还可能受ATM标准的信元格式约束.&nbsp;基于这些约束,&nbsp;ATM-LSR上需要一些特定的程序.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;下面是一些象LSR一样影响ATM交换机性能的主要特性:<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;---在信元头字段(VCI或VPI)中执行标签交换功能,&nbsp;这指示分组的大小和标签的替代.&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;---一般不支持多点到单点VC和多点到多点VC.&nbsp;即大多数交换机不支持上面定义的VC合&nbsp;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;并.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;---一般没有实现像在路由器中IP头中的TTL-消耗的功能.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;文档描述了在这些约束下在ATM交换机在应用标签交换的方法.<br />
<br />
4.&nbsp;ATM标签交换控制组件<br />
&nbsp;为支持标签交换,&nbsp;ATM交换机必须执行标签交换的控制组件功能.&nbsp;这主要包括标签分配,&nbsp;分布,&nbsp;维护过程.&nbsp;&nbsp;标签绑定信息由几个机制来传递,&nbsp;特别是标签分发协议(LDP).&nbsp;文档对LDP作了一些定义.<br />
&nbsp;&nbsp;文档只考虑了标签交换控制组件使用直接从网络层路由协议中得到信息的情况.&nbsp;即在这些协议中交换机是对等的.<br />
&nbsp;&nbsp;在某些情况下,&nbsp;LSR要使用其它一些协议(如,&nbsp;RSVP,&nbsp;PIM,&nbsp;BGP)来分发标签绑定信息.&nbsp;在这种情况下,&nbsp;ATM-LSR将需要参与到这些协议中.&nbsp;然而,&nbsp;文档没有明确考虑这些内容.<br />
&nbsp;&nbsp;在ATM交换机上支持&nbsp;标签交换不需要交换机支持由ITU及ATM论坛定义的ATM控制组件&nbsp;(如UNI,PNNI).&nbsp;ATM-LSR对OAM信元的响应是可选的.<br />
&nbsp;&nbsp;<br />
5.&nbsp;混合交换(夜晚行船)<br />
存在于ATM交换机上的标签交换控制组件,&nbsp;不排除对由ITU及ATM论坛在同一交换和同一接口上定义的ATM控制组件的支持.&nbsp;这两种控制组件,&nbsp;标签交换组件及ITU/ATM论坛定义的组件,&nbsp;是相互独立地操作.&nbsp;<br />
文档没有定义这种设计是如何操作的.&nbsp;然而,&nbsp;这两种控制组件之间只有一小部分信息是需要一致的,&nbsp;如每一种组件都有的VPI/VCI部分的空间大小.<br />
<br />
6.&nbsp;使用VPI/VCI&nbsp;<br />
实现标签交换的过程:联合前传等效类的标签,&nbsp;使用标签值来转发分组,&nbsp;包括决定任一需替代标签的值.&nbsp;细节问题请参见[1].&nbsp;在ATM-LSR中,&nbsp;标签信息由VPI/VCI字段携带,&nbsp;或当两个ATM-LSR通过ATM"虚通路"连接时,&nbsp;由VCI字段携带.&nbsp;<br />
标签分组必须使用空封装来传送,&nbsp;如RFC&nbsp;2684中的6.1部分所定义.<br />
另外,&nbsp;如果两个对等LDP通过LC-ATM接口连接,&nbsp;那么必须有一个能携带未标识IP分组的非MPLS连接.&nbsp;这个非MPLS连接是在两个对等LDP之间传送LDP分组,&nbsp;也可以(不一定需要)传送其它非标识分组(如OSPF包等).&nbsp;RFC&nbsp;2684[5]的LLC/SNAP封装必须用于非MPLS连接.<br />
可以用传送控制信息或非标识分组的附加VPI/VCI来配置LC-ATM接口.&nbsp;在这种情况下,&nbsp;VCI的值不能是0到32之间.&nbsp;0到32的值用于空封装,&nbsp;如RFC&nbsp;2684[5]中的6.1部分所定义,&nbsp;或是用于LLC/SNAP封装,&nbsp;如RFC&nbsp;2684[5]中的5.1部分所定义.<br />
<br />
6.1&nbsp;直接连接<br />
&nbsp;&nbsp;&nbsp;&nbsp;如果一个LSR经过LC-ATM接口传送的所有信元都将到达另外一个LSR,&nbsp;且在这两个LSR之间没有其它ATM交换机,&nbsp;我们就称这两个LSR在LC-ATM接口上是直接连接的.<br />
若两个LSR通过LC-ATM接口直接连接,&nbsp;它们将在接口上共同控制VPI/VCI的分配.&nbsp;它们也可以使用VPI/VCI字段对单一标签进行编码.<br />
在非MPLS连接中VPI/VCI的缺省值是VPI=0,&nbsp;VCI=32.&nbsp;也可以配置其它的值,&nbsp;只要双方都知道这个值就行了.<br />
VPI/VCI值中,&nbsp;如果它的VCI部分的值是在0到32之间(包含0,32),&nbsp;那么它就不能被视为是标签的编码.<br />
除了这些保留值以外,&nbsp;用于连接的两个方向中的VPI/VCI值都是独立的空间.<br />
VCI允许范围内的值通过LDP传送.<br />
<br />
6.2&nbsp;通过ATM&nbsp;VP的连接<br />
有时,&nbsp;认为两个LSR在LC-ATM接口上相邻(在一些LSP)的想法是很用的,&nbsp;即使它们俩的连接是通过ATM虚通路的ATM云团建立起来.&nbsp;这样,&nbsp;对MPLS来说,&nbsp;VPI字段是没有用的,&nbsp;标签必须完全在VCI字段内编码.<br />
这样,&nbsp;在LSR之间的非MPLS连接中,&nbsp;VCI缺省值是32.&nbsp;也可以配置其它的值,&nbsp;只要比方都知道配置的值就行了.&nbsp;VPI可以设置成利用虚通路所需要的任何值.<br />
VPI/VCI值中,&nbsp;如果它的VCI部分的值是在0到32之间(包含0,32),&nbsp;那么它就不能被视为是标签的编码.<br />
除了这些保留值以外,&nbsp;用于连接的两个方向中的VPI/VCI值都是独立的空间.<br />
VPI/VCI允许范围内的值通过LDP传送.&nbsp;在标签交换中,&nbsp;如果使用了多个VPI,&nbsp;则对每一个VPI,&nbsp;VCI允许的范围是不同的,&nbsp;每一个VCI范围通过LDP传送.<br />
<br />
6.3&nbsp;通过ATM&nbsp;SVC的连接<br />
&nbsp;&nbsp;&nbsp;&nbsp;有时,&nbsp;认为两个LSR在LC-ATM接口上相邻(在一些LSP)的想法是很用的,&nbsp;即使它们俩的连接是通过一组ATM交换虚电路的ATM云团建立起来.&nbsp;&nbsp;&nbsp;<br />
文档没有详细说明处理这个连接的过程.&nbsp;可以在[4]中找到这个处理过程.&nbsp;[4]中描述的过程允许分配VCID到每一个VC中,&nbsp;并详细说明了如何使用LDP在FEC中绑定VCID.&nbsp;接收分组中的最高标识符将由分组到达时的虚电路推断出(通过一对一映射).&nbsp;在非MPLS连接中不是缺省的VPI或VCI值.<br />
<br />
7.&nbsp;标签分配及维护过程<br />
&nbsp;&nbsp;&nbsp;&nbsp;文档讨论了ATM-LSR&nbsp;使用的"下游按需"标签分配.&nbsp;不支持VC合并的ATM-LSR必须使用这些标签分配过程,&nbsp;而支持VC合并的ATM-LSR也可以使用.&nbsp;而这两种情况下的处理过程有一些不同.&nbsp;下面我们将依次对这两种情况进行描述.&nbsp;我们首先描述ATM-LSR域的边缘组成员的行为,这些行为对域中有没有支持VC合并的LSR都是一样的.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
7.1&nbsp;边缘LSR行为<br />
考虑ATM-LSR域的边缘组的成员.&nbsp;假设,&nbsp;有一个路由计算结果,&nbsp;选择一个ATM-LSR作为一个特定FEC的下一跳,&nbsp;而且这下一跳可以通过LC-ATM接口到达.&nbsp;边缘LSR使用LDP为来自下一跳的FEC请求标签绑定.&nbsp;请求中的跳计数字段被置1(参见下一段).&nbsp;一旦边缘LSR收到标签绑定信息,&nbsp;它就使用MPLS转发过程以在指定FEC中传送分组,&nbsp;使用指定标签作为输出标签.&nbsp;(或如果使用[4]中的VCID技术,&nbsp;就用VPI/VCI来响应指定的VCID以作为输出标签).&nbsp;<br />
注意:&nbsp;如果边缘LSR的前一跳使用下游按需标签分配来为一指定FEC请求来自边缘LSR的标签,&nbsp;如果边缘LSR不将来自前一跳的LSP与其它LSP合并,&nbsp;如果来自前一跳的请求有h的跳计数值,&nbsp;那么边缘LSR发出的请求中跳计数值应该置1,&nbsp;而不是h+1.<br />
边缘LSR接收的绑定信息包含跳计数,&nbsp;跳计数表示一个分组使用该标签&nbsp;经过ATM-LSR域时需要的跳数.&nbsp;如果跳计数与绑定相联合,&nbsp;ATM-LSR就要在发送分组前用这个数调整数据分组的TTL值.&nbsp;在任何情况下,&nbsp;必须在传送前至少调整数据分组的TTL值一次.&nbsp;第10部分将详细讨论了这个过程(以IP分组为例).&nbsp;第9部分详细讨论了分组的封装过程.<br />
当ATM-LSR域的边缘组的成员从ATM-LSR中接收到标签绑定请求时,&nbsp;它分配一个标签,&nbsp;并将包含已分配标签的绑定返回(通过LDP)到最先发起请求的对等层.&nbsp;它将绑定中的跳计数置1.&nbsp;<br />
当路由计算引起边缘LSR改变指定FEC的下一跳时,&nbsp;原先的下一跳在ATM-LSR域中,&nbsp;边缘LSR将要通报(通过LDP)原先的下一跳,&nbsp;即与FEC关联的标签绑定,&nbsp;不再使用了.<br />
<br />
7.2&nbsp;传统ATM交换(非VC合并)<br />
ATM-LSR在LC-ATM接口上与另一个ATM-LSR的对等连接上,&nbsp;接收(通过LDP)某一FEC的标签绑定请求时,&nbsp;ATM-LSR做以下的行为:<br />
---分配标签,<br />
---为FEC请求(通过LDP)下一跳的标签绑定,<br />
---将包含已分配标签的绑定返回(通过LDP)到最先发起请求的对等层,<br />
为这个过程,&nbsp;我们定义了最大跳数值MAXHOP.&nbsp;缺省值为255,&nbsp;可以配置成其它值.<br />
ATM-LSR发送请求(发送至下一跳LSR)中的跳计数字段,&nbsp;要比从上游LSR中接收的请求中的跳计数值加1.&nbsp;如果此时跳计数值超过MAXHOP,&nbsp;请求将不能发送到下一跳,&nbsp;ATM-LSR必须通报邻近上游,&nbsp;请求被禁止.<br />
否则,&nbsp;一旦ATM-LSR接收来自下一跳的绑定,&nbsp;又将使用已用的标签.<br />
ATM-LSR可以在返回上游绑定前选择等待来自下游的请求响应.&nbsp;这是一种"受控控制"方式(如[1],[2]中所定义),&nbsp;特殊"入口初始受控控制".&nbsp;这样,&nbsp;只要ATM-LSR接收来自下游的跳数大小0且小于MAXHOP,&nbsp;在返回上游时,&nbsp;必须将跳数值加1,&nbsp;并在绑定中包含这个结果.&nbsp;然而,&nbsp;如果跳数超过MAXHOP,&nbsp;就不能给上游传递标签绑定.&nbsp;而是,&nbsp;必须通报对等上游LDP,&nbsp;所请求的标签绑定被禁止.&nbsp;如果从下游接收的跳数是0,&nbsp;则传递给上游的跳数也是0;&nbsp;这表明实际跳数是未知.<br />
ATM-LSR也可以选择返回上游绑定,&nbsp;不必等待来自下游的绑定("独立控制",&nbsp;如[1],[2]中所定义).&nbsp;这样,&nbsp;它绑定时指定跳数为0,&nbsp;表明真实跳数未知.&nbsp;跳数的正确值将在后面返回,&nbsp;如下所述.<br />
注意ATM-LSR,&nbsp;或ATM-LSR域边缘组的成员,&nbsp;可以从同一ATM-LSR中接收同一FEC的多个绑定请求.&nbsp;它必须为每一请求产生一个新的绑定(假定有足够的资源可以这么做),&nbsp;保留任一现存的绑定.&nbsp;为每一接收的请求,&nbsp;ATM-LSR还必须为FEC产生发送到下一跳的新的绑定请求.<br />
当路由计算引起ATM-LSR改变一个FEC的下一跳时,&nbsp;ATM-LSR必须通报(通过LDP)原先的下一跳,&nbsp;即与FEC关联的标签绑定,&nbsp;不再使用了.<br />
当LSR接收到声明指定的标签绑定不再使用的通告时,&nbsp;LSR将对与该绑定相关的标签进行解分配,&nbsp;然后去除该绑定.&nbsp;ATM-LSR在接收到这样的通告和去除绑定的情况下,&nbsp;必须通报FEC的下一跳,&nbsp;不再使用该标签绑定了.&nbsp;如果LSR不去除绑这一绑定,&nbsp;只有在下面情况下,&nbsp;它可以重新用此绑定,&nbsp;即它接收到同一FEC的请求,&nbsp;且跳数值与最先导致这一绑定产生的请求的跳数值相同.&nbsp;<br />
当路由改变时,&nbsp;标签绑定要从与先前路由不同处的路由点开始重新确立.&nbsp;该点的LSR上游不用改变(有一个例外,&nbsp;如下所述).<br />
不管LSR何时改变它特定FEC的下一跳,&nbsp;如果新的下一跳通过LC-ATM接口可达,&nbsp;那么对每一与该FEC相关的标签,&nbsp;及分布式上游,&nbsp;它都必须从下一跳中请求新的标签绑定.<br />
ATM-LSR从邻近下游接收到指定FEC的标签绑定时,&nbsp;由于使用独立控制方式,&nbsp;或由于来自下游的新绑定是路由改变的结果,&nbsp;它可能已经将与该FEC相关的标签绑定发送到邻近上游.&nbsp;这样,&nbsp;除非跳数值为0,&nbsp;ATM-LSR必须将新绑定的跳数值加1.&nbsp;如果新跳数值与原先发送到邻近上游的跳数值不同(包括邻近上游被赋于"未知"跳数值的情况),&nbsp;ATM-LSR必须向邻近上游通报这个改变.&nbsp;每一ATM-LSR必须依次将跳数值加1&nbsp;,&nbsp;并传送至上游直到到达入口边缘LSR.&nbsp;如果此间任何一点的跳数值等于MAXHOP,&nbsp;ATM-LSR就要从邻近上游中收回绑定.&nbsp;跳数值0必须不变的传送到上游.<br />
作为从另一个LSR(上游)接收标签绑定请求的结果,&nbsp;ATM-LSR对它的下一跳LSR发出标签绑定请求,&nbsp;当送往下一跳LSR的请求被禁止时,&nbsp;ATM-LSR应当删除对接收请求响应产生的绑定,&nbsp;并通报请求者(通过LDP).<br />
ATM-LSR接收的绑定请求中如果包含超过MAXHOP值的跳数值,&nbsp;它就不能建立绑定,&nbsp;必须向请求方返回一个错误值.<br />
当LSR丢失了与另一个LSR的LDP部分,&nbsp;将会采取下列行为.&nbsp;通过LDP这一连接得到的任何绑定信息都必须丢弃.&nbsp;作为从对等端接收标签绑定请求的结果而建立的任一标签绑定,&nbsp;LSR都将去除(解分配与这些绑定相关的标签).<br />
ATM-LSR从它的邻处响应绑定请求时,&nbsp;使用"水平分割"方法.&nbsp;就是说,&nbsp;如果ATM-LSR接收一个指定FEC的绑定请求,&nbsp;LSR根据ATM-LSR使该请求成为指定FEC的下一跳,&nbsp;ATM-LSR不为路由返回绑定.<br />
非合并ATM-LSR通常使用"保守标签方式"&nbsp;[1].<br />
<br />
7.3&nbsp;能实现VC合并的ATM交换<br />
为适应支持VC合并的ATM-LSR,&nbsp;需要作一些相关的小变化.&nbsp;支持VC合并的ATM-LSR的最主要的差别是对每一个FEC只需要一个输出标签,&nbsp;即使从邻近上游中接收了FEC的多个标签绑定请求.<br />
支持VC合并的ATM-LSR从某一FEC的上游LSR中接收了绑定请求时,&nbsp;对这个FEC,&nbsp;它还没有输出标签绑定(或对这个标签绑定有一个明显请求),&nbsp;ATM-LSR必须对它的下一跳发出绑定请求,&nbsp;就象不支持合并的ATM-LSR一样.&nbsp;然而,&nbsp;如果ATM-LSR已经有一个输出标签绑定,&nbsp;它就不需要发出一个下游绑定请求.&nbsp;相反,&nbsp;ATM-LSR会简单地分配一个输入标签,&nbsp;用一个绑定向上游请求端返回该标签.&nbsp;当对应这个标签的分组的最高标识被请求端接收时,&nbsp;最高标识值将被现有的对应于同一FEC的输出标签值替代.<br />
如果ATM-LSR对FEC没有输出标签绑定,&nbsp;但却有一个明显请求,&nbsp;它就不需要发送另外的请求了.<br />
发送上游标签绑定时,&nbsp;下游与相应绑定关联的跳数值必须加1,&nbsp;加1后的跳数值,即新绑定关联的跳数值必须传送到上游.&nbsp;然而,&nbsp;有两个例外:&nbsp;跳数值为0时必须将该值不变地传送到上游,&nbsp;跳数值已是MAXHOP,&nbsp;ATM-LSR不是传送上游绑定,&nbsp;而是传送一个错误信息到上游.<br />
注意,&nbsp;既然有不支持VC合并的上游交换,&nbsp;象传统的ATM-LSR和ATM-LSR域的边缘组成员一样,&nbsp;支持VC合并的ATM-LSR必须在每次从上游接收到请求时,&nbsp;发出新的绑定.&nbsp;然而,&nbsp;ATM-LSR只需要在它没有标签绑定合适路由时,发送相应下游绑定请求.<br />
支持VC合并的ATM-LSR的路由表发生变化时,&nbsp;会引起对它的FEC选择新的下一跳,&nbsp;它会随意地释放原先下一跳的路由绑定.&nbsp;支持VC合并的ATM-LSR对新的下一跳没有相应的绑定时,它会请求绑定.(可以选择执行保守及自由标签模式[1])<br />
如果获得了新绑定,&nbsp;其中包含的跳数与原先的旧绑定中的跳数不同,&nbsp;ATM-LSR必须将新的跳数值加1,&nbsp;并向所有的同一FEC标签绑定的邻近上游通报这个新值.&nbsp;与传统的ATM-LSR一样,&nbsp;能够将新值往回传送到ATM-LSR域的入口处.&nbsp;如果在此中任何一个点上跳数值超过了MAXHOP,那么这个路由的标签绑定,&nbsp;必须从所有邻近上游到该绑定先前提供处,&nbsp;一一被收回.&nbsp;这样,&nbsp;可以确保瞬时路由引起的环路被检测出并被破坏掉.<br />
<br />
8.&nbsp;封装<br />
这个部分描述的过程仅涉及ATM-LSR域的边缘LSR.&nbsp;ATM-LSR本身不对这种封装作任何修改.<br />
必须使用RFC&nbsp;2684&nbsp;[5]&nbsp;6.1部分中的空封装来传递标识分组.&nbsp;<br />
除了下面说明的特殊情况外,&nbsp;当标识分组在LC-ATM接口被传递时,&nbsp;VPI/VCI(或VCID)值被认为标签栈中的最高标签,&nbsp;分组必须包含"通用头"&nbsp;[3].<br />
如果分组的标签栈有n个条目,&nbsp;则它必须有n个条目的通用头.&nbsp;最高标签的实际值在VPI/VCI字段中编码.&nbsp;通用头的最高条目的标签值(仅是一个"占位符"条目)在传送时必须被置0,&nbsp;在接收时也必须被忽略.&nbsp;分组的输出TTL,&nbsp;及它的Cos信息,&nbsp;分别在通用头最高栈条目中的TTL和Cos字段中携带.<br />
注意,&nbsp;如果分组只有一个条目的标签栈,&nbsp;就需要一个单目通用头(4个字节),&nbsp;即使实际标签值在VPI/VCI字段中编码.&nbsp;这样才能保证分组都有一个通用头.&nbsp;否则,&nbsp;就不可能确定分组有没有通用头,&nbsp;也不可能确定它有没有额外标签栈条目.<br />
要消除这个额外开销的唯一方法是:<br />
---据先验知识分组仅有一个标签(如:&nbsp;可能网络仅支持一级标签)<br />
---对每个FEC使用两个VC,&nbsp;一个用于仅含一个标签的分组,&nbsp;另一个用于有多于一个标签的分组.<br />
第二种方法要求有一种信令方法,&nbsp;VC通过LDP仅传送含一个标签的分组,&nbsp;而不传送通用头.&nbsp;若支持VC合并,&nbsp;还必须注意不要把不使用VC的通用头合并VC到一个使用VC的通用头中,&nbsp;或反之.&nbsp;<br />
若上面两种方法都不允许使用,&nbsp;就可能没有其它更实用的方法了.&nbsp;注意,&nbsp;如果通用头不存在,&nbsp;输出TTL将在网络层头中的TTL字段中传送.<br />
<br />
9.&nbsp;TTL操作<br />
这个部分描述的过程仅涉及ATM-LSR域的边缘LSR.&nbsp;ATM-LSR本身不对TTL作任何修改.<br />
TTL调整过程的细节如下所述.&nbsp;如果分组作为未标识分组被边缘LSR中接收,&nbsp;"输入TTL"值来自IP报头(其它网络层协议的过程需要进一步的研究).&nbsp;如果分组作为标识分组被边缘LSR中被接收,&nbsp;就使用[3]中详细说明的封装,&nbsp;"输入TTL"值来自标签栈的最高条目.<br />
如果跳数值与传送分组时使用的标签绑定关联,&nbsp;"输出TTL"就设置为下面两个值中的较大者:&nbsp;0,&nbsp;输入TTL与跳数值的差值.&nbsp;如果跳数值不与传送分组时使用的标签绑定关联,&nbsp;"输出TTL"就设置为下面两个值中的较大者:&nbsp;0,&nbsp;比输入TTL小1的值.&nbsp;<br />
如果这使得输出TTL变成零,&nbsp;这个分组将不能视为使用指定标签的标签分组而传送.&nbsp;将对分组作如下两种方法之一的处理:<br />
---分组超时;&nbsp;将发送ICMP报文;<br />
---分组将作为未标识分组向前传送,&nbsp;TTL值为1,&nbsp;比输入TTL小;&nbsp;这样的传送需要在非MPLS连接上进行.&nbsp;<br />
当然,&nbsp;如果输入TTL为1,&nbsp;就只能是这两种情况中的第一种.<br />
如果分组作为标识分组传送,&nbsp;携带的输出TTL如第九部分中所指定.<br />
边缘LSR从LC-ATM接口中接收到标识分组时,&nbsp;能从一般封装的最高标签栈条目中得到输入TTL,&nbsp;或如果没有封装,&nbsp;就从IP报头中得到.&nbsp;<br />
如果分组的下一跳是ATM-LSR,&nbsp;输出TTL将使用本部分讲述的过程形成.&nbsp;否则输出TTL使用[3]中描述的过程形成.<br />
本部分的过程本来仅是用于单播分组.<br />
<br />
10.&nbsp;可选环路检测:&nbsp;分布路径矢量<br />
&nbsp;&nbsp;&nbsp;&nbsp;作为一个可配置选项,&nbsp;每一ATM-LSR必须实现下面的检测传送环路的过程.&nbsp;我们称之为LDPV过程(路径矢量的环路检测).&nbsp;LDPV不阻止传送环路的信息,&nbsp;但确保任一这样的环路被检测到.&nbsp;如果该选项没有被激活,&nbsp;将使用原先讨论的跳数机制检测环路.&nbsp;如果该选项被激活,&nbsp;环路检测将更为快速,&nbsp;但这是以高开销为代价的.<br />
<br />
10.1&nbsp;何时发送下游路径矢量<br />
假定LSR&nbsp;R&nbsp;为特定LSP向下一跳发送一个标签绑定请求.&nbsp;R不支持VC合并,&nbsp;R&nbsp;被配置成使用LDPV过程:<br />
---如果R为LSP发送请求,&nbsp;是因为R是一个入节点,&nbsp;或因为R已获得新的一跳,&nbsp;R将必须在请求中包括路径矢量对象,&nbsp;且路径矢量对象必须只包含R的自身地址.<br />
---如果R从上游LSR中接收了请求后而发送请求,&nbsp;那么:<br />
*&nbsp;如果接收的请求有路径矢量对象,&nbsp;R必须将自身地址加入到接收的路径矢量对象中,&nbsp;且必须将新路径矢量对象传送随标签绑定请求传送到它的下一跳;<br />
*&nbsp;如果接收的请求没有路径矢量对象,&nbsp;R必须在发送的请求中包含路径矢量对象,&nbsp;且该路径矢量对象只包含R的自身地址.<br />
支持VC合并的LSR不应该在它向下一跳发送的请求中包含路径矢量对象.<br />
如果LSR接收的标签绑定请求,&nbsp;它里面的路径矢量对象包含节点自身的地址,&nbsp;LSR则推断出该标签绑定请求已在环路中传播了一周.&nbsp;LSR此时所作的处理与出现跳数值超过MAXHOP情况时所作的处理一样.(参见8.2部分)<br />
这一过程检测出请求消息围绕非合并ATM-LSR序列循环的情况.<br />
<br />
10.2&nbsp;何时发送上游路径矢量<br />
如第八部分所述,&nbsp;存在如下情况:&nbsp;LSR&nbsp;R必须通过标签绑定响应信息,&nbsp;向它的邻近上游告知指定LSP的跳数值改变.&nbsp;如果以下条件都成立:<br />
---R&nbsp;被配置成使用LDPV过程,<br />
---R支持VC合并,<br />
---R不是LSP的出口<br />
---R不向它的邻处通告跳数值的减少<br />
那么R必须在响应信息中包含路径矢量对象.<br />
如果跳数值的改变是由于R的下一跳S告知跳数值改变的结果,&nbsp;且从S向R传送的消息包含了路径矢量对象,&nbsp;那么如果上述的条件成立,&nbsp;R必须在该对象中加入其自身地址,&nbsp;并将结果传送到上游.&nbsp;否则,&nbsp;如果上述条件不成立,&nbsp;R必须创建一个只包含自身地址的新对象.<br />
如果R&nbsp;被配置成使用LDPV过程,&nbsp;且R支持VC合并,&nbsp;那么它可以在任一向上游发送的标签绑定响应消息中包含路径矢量对象.&nbsp;特别地,&nbsp;当R&nbsp;收到从它的下一跳中发来的标签绑定响应时,&nbsp;如果该响应包含路径矢量,&nbsp;R可以(如果已配置成使用LDPV过程)向它的邻近上游发送响应,&nbsp;其中包括在接收路径矢量中将自身地址加入而形成的路径矢量对象.<br />
如果R不支持VC合并,&nbsp;它不能发送上游路径矢量对象.<br />
如果LSR从它的下一跳中接收了消息,&nbsp;其中的路径矢量对象包含LSR自身地址,&nbsp;那么LSR所作的处理与它在接收到的消息中跳数值等于MAXHOP情况下作的处理是一样的.<br />
配置成使用LDPV过程的LSR,&nbsp;一旦相应路径矢量对象已被传送,&nbsp;就不能存储路径矢量.<br />
注意,&nbsp;如果ATM-LSR域完全由非合并ATM-LSR组成,&nbsp;路径矢量就不需要被传送至上游,&nbsp;因为通过路径矢量下游传播的方法就可以检测到任一环路.<br />
除非跳数值增加,&nbsp;否则采用不发送路径矢量的方法时就要避免在没有环路的情况下发送.&nbsp;代价是在没有环路的某些情况下,&nbsp;花费在检测环路的时间会延长.<br />
<br />
11.&nbsp;安全考虑<br />
文档详细说明的封装和过程并没有涉及任何认证过程和/或对网络层分组的加密过程(如对IP数据报的IPSEC应用).&nbsp;<br />
文档中描述的MPLS标签过程不是不能变更的(或是偶然的,&nbsp;或是恶意的).这种变更将导致错误前传.<br />
文档中描述的过程,&nbsp;接收LSR不能鉴别传送LSR.<br />
在[2]在可以找到适用于标签分配机制的安全问题讨论.<br />
<br />
12&nbsp;参考文献<br />
<br />
&nbsp;&nbsp;&nbsp;[1]&nbsp;Rosen,&nbsp;E.,&nbsp;Viswanathan,&nbsp;A.&nbsp;and&nbsp;R.&nbsp;Callon&nbsp;"Multi-Protocol&nbsp;Label<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Switching&nbsp;Architecture",&nbsp;RFC&nbsp;3031,&nbsp;January&nbsp;2001.<br />
<br />
&nbsp;&nbsp;&nbsp;[2]&nbsp;Andersson&nbsp;L.,&nbsp;Doolan&nbsp;P.,&nbsp;Feldman&nbsp;N.,&nbsp;Fredette&nbsp;A.&nbsp;and&nbsp;R.&nbsp;Thomas,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"LDP&nbsp;Specification",&nbsp;RFC&nbsp;3036,&nbsp;January&nbsp;2001.<br />
<br />
&nbsp;&nbsp;&nbsp;[3]&nbsp;Rosen,&nbsp;E.,&nbsp;Rekhter,&nbsp;Y.,&nbsp;Tappan,&nbsp;D.,&nbsp;Farinacci,&nbsp;D.,&nbsp;Fedorkow,&nbsp;G.,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Li,&nbsp;T.&nbsp;and&nbsp;A.&nbsp;Conta,&nbsp;"MPLS&nbsp;Label&nbsp;Stack&nbsp;Encoding",&nbsp;RFC&nbsp;3032,<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;January&nbsp;2001.<br />
<br />
&nbsp;&nbsp;&nbsp;[4]&nbsp;Nagami,&nbsp;K.,&nbsp;Demizu&nbsp;N.,&nbsp;Esaki&nbsp;H.&nbsp;and&nbsp;P.&nbsp;Doolan,&nbsp;"VCID&nbsp;Notification<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;over&nbsp;ATM&nbsp;Link&nbsp;for&nbsp;LDP",&nbsp;RFC&nbsp;3038,&nbsp;January&nbsp;2001.<br />
<br />
&nbsp;&nbsp;&nbsp;[5]&nbsp;Grossman,&nbsp;D.,&nbsp;Heinanen,&nbsp;J.,&nbsp;"Multiprotocol&nbsp;Encapsulation&nbsp;over&nbsp;ATM<br />
Adaptation&nbsp;Layer&nbsp;5",&nbsp;RFC&nbsp;2684,&nbsp;September&nbsp;1999.<br />
<br />
<br />
13.&nbsp;Acknowledgments<br />
<br />
&nbsp;&nbsp;&nbsp;Significant&nbsp;contributions&nbsp;to&nbsp;this&nbsp;work&nbsp;have&nbsp;been&nbsp;made&nbsp;by&nbsp;Anthony<br />
&nbsp;&nbsp;&nbsp;Alles,&nbsp;Fred&nbsp;Baker,&nbsp;Dino&nbsp;Farinacci,&nbsp;Guy&nbsp;Fedorkow,&nbsp;Arthur&nbsp;Lin,&nbsp;Morgan<br />
&nbsp;&nbsp;&nbsp;Littlewood&nbsp;and&nbsp;Dan&nbsp;Tappan.&nbsp;&nbsp;We&nbsp;thank&nbsp;Alex&nbsp;Conta&nbsp;for&nbsp;his&nbsp;comments.<br />
<br />
14.&nbsp;Authors'&nbsp;Addresses<br />
<br />
&nbsp;&nbsp;&nbsp;Bruce&nbsp;Davie<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;250&nbsp;Apollo&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;Chelmsford,&nbsp;MA,&nbsp;01824<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;bsd@cisco.com<br />
<br />
&nbsp;&nbsp;&nbsp;Paul&nbsp;Doolan<br />
&nbsp;&nbsp;&nbsp;Ennovate&nbsp;Networks&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;60&nbsp;Codman&nbsp;Hill&nbsp;Rd<br />
&nbsp;&nbsp;&nbsp;Boxborough,&nbsp;MA&nbsp;01719<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;pdoolan@ennovatenetworks.com<br />
<br />
&nbsp;&nbsp;&nbsp;Jeremy&nbsp;Lawrence<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;99&nbsp;Walker&nbsp;St.<br />
&nbsp;&nbsp;&nbsp;North&nbsp;Sydney,&nbsp;NSW,&nbsp;Australia<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;jlawrenc@cisco.com<br />
<br />
&nbsp;&nbsp;&nbsp;Keith&nbsp;McCloghrie<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;170&nbsp;Tasman&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;San&nbsp;Jose,&nbsp;CA,&nbsp;95134<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;kzm@cisco.com<br />
<br />
&nbsp;&nbsp;&nbsp;Yakov&nbsp;Rekhter<br />
&nbsp;&nbsp;&nbsp;Juniper&nbsp;Networks<br />
&nbsp;&nbsp;&nbsp;1194&nbsp;N.&nbsp;Mathilda&nbsp;Avenue<br />
&nbsp;&nbsp;&nbsp;Sunnyvale,&nbsp;CA&nbsp;94089<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;yakov@juniper.net<br />
<br />
&nbsp;&nbsp;&nbsp;Eric&nbsp;Rosen<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;250&nbsp;Apollo&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;Chelmsford,&nbsp;MA,&nbsp;01824<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;erosen@cisco.com<br />
<br />
&nbsp;&nbsp;&nbsp;George&nbsp;Swallow<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;Systems,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;250&nbsp;Apollo&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;Chelmsford,&nbsp;MA,&nbsp;01824<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;swallow@cisco.com<br />
<br />
15.&nbsp;&nbsp;Full&nbsp;Copyright&nbsp;Statement<br />
<br />
&nbsp;&nbsp;&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(2001).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;and&nbsp;translations&nbsp;of&nbsp;it&nbsp;may&nbsp;be&nbsp;copied&nbsp;and&nbsp;furnished&nbsp;to<br />
&nbsp;&nbsp;&nbsp;others,&nbsp;and&nbsp;derivative&nbsp;works&nbsp;that&nbsp;comment&nbsp;on&nbsp;or&nbsp;otherwise&nbsp;explain&nbsp;it<br />
&nbsp;&nbsp;&nbsp;or&nbsp;assist&nbsp;in&nbsp;its&nbsp;implementation&nbsp;may&nbsp;be&nbsp;prepared,&nbsp;copied,&nbsp;published<br />
&nbsp;&nbsp;&nbsp;and&nbsp;distributed,&nbsp;in&nbsp;whole&nbsp;or&nbsp;in&nbsp;part,&nbsp;without&nbsp;restriction&nbsp;of&nbsp;any<br />
&nbsp;&nbsp;&nbsp;kind,&nbsp;provided&nbsp;that&nbsp;the&nbsp;above&nbsp;copyright&nbsp;notice&nbsp;and&nbsp;this&nbsp;paragraph&nbsp;are<br />
&nbsp;&nbsp;&nbsp;included&nbsp;on&nbsp;all&nbsp;such&nbsp;copies&nbsp;and&nbsp;derivative&nbsp;works.&nbsp;&nbsp;However,&nbsp;this<br />
&nbsp;&nbsp;&nbsp;document&nbsp;itself&nbsp;may&nbsp;not&nbsp;be&nbsp;modified&nbsp;in&nbsp;any&nbsp;way,&nbsp;such&nbsp;as&nbsp;by&nbsp;removing<br />
&nbsp;&nbsp;&nbsp;the&nbsp;copyright&nbsp;notice&nbsp;or&nbsp;references&nbsp;to&nbsp;the&nbsp;Internet&nbsp;Society&nbsp;or&nbsp;other<br />
&nbsp;&nbsp;&nbsp;Internet&nbsp;organizations,&nbsp;except&nbsp;as&nbsp;needed&nbsp;for&nbsp;the&nbsp;purpose&nbsp;of<br />
&nbsp;&nbsp;&nbsp;developing&nbsp;Internet&nbsp;standards&nbsp;in&nbsp;which&nbsp;case&nbsp;the&nbsp;procedures&nbsp;for<br />
&nbsp;&nbsp;&nbsp;copyrights&nbsp;defined&nbsp;in&nbsp;the&nbsp;Internet&nbsp;Standards&nbsp;process&nbsp;must&nbsp;be<br />
&nbsp;&nbsp;&nbsp;followed,&nbsp;or&nbsp;as&nbsp;required&nbsp;to&nbsp;translate&nbsp;it&nbsp;into&nbsp;languages&nbsp;other&nbsp;than<br />
&nbsp;&nbsp;&nbsp;English.<br />
<br />
&nbsp;&nbsp;&nbsp;The&nbsp;limited&nbsp;permissions&nbsp;granted&nbsp;above&nbsp;are&nbsp;perpetual&nbsp;and&nbsp;will&nbsp;not&nbsp;be<br />
&nbsp;&nbsp;&nbsp;revoked&nbsp;by&nbsp;the&nbsp;Internet&nbsp;Society&nbsp;or&nbsp;its&nbsp;successors&nbsp;or&nbsp;assigns.<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;document&nbsp;and&nbsp;the&nbsp;information&nbsp;contained&nbsp;herein&nbsp;is&nbsp;provided&nbsp;on&nbsp;an<br />
&nbsp;&nbsp;&nbsp;"AS&nbsp;IS"&nbsp;basis&nbsp;and&nbsp;THE&nbsp;INTERNET&nbsp;SOCIETY&nbsp;AND&nbsp;THE&nbsp;INTERNET&nbsp;ENGINEERING<br />
&nbsp;&nbsp;&nbsp;TASK&nbsp;FORCE&nbsp;DISCLAIMS&nbsp;ALL&nbsp;WARRANTIES,&nbsp;EXPRESS&nbsp;OR&nbsp;IMPLIED,&nbsp;INCLUDING<br />
&nbsp;&nbsp;&nbsp;BUT&nbsp;NOT&nbsp;LIMITED&nbsp;TO&nbsp;ANY&nbsp;WARRANTY&nbsp;THAT&nbsp;THE&nbsp;USE&nbsp;OF&nbsp;THE&nbsp;INFORMATION<br />
&nbsp;&nbsp;&nbsp;HEREIN&nbsp;WILL&nbsp;NOT&nbsp;INFRINGE&nbsp;ANY&nbsp;RIGHTS&nbsp;OR&nbsp;ANY&nbsp;IMPLIED&nbsp;WARRANTIES&nbsp;OF<br />
&nbsp;&nbsp;&nbsp;MERCHANTABILITY&nbsp;OR&nbsp;FITNESS&nbsp;FOR&nbsp;A&nbsp;PARTICULAR&nbsp;PURPOSE.<br />
<br />
Acknowledgement<br />
<br />
&nbsp;&nbsp;&nbsp;Funding&nbsp;for&nbsp;the&nbsp;RFC&nbsp;Editor&nbsp;function&nbsp;is&nbsp;currently&nbsp;provided&nbsp;by&nbsp;the<br />
&nbsp;&nbsp;&nbsp;Internet&nbsp;Society.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
&nbsp;&nbsp;<br />
<br />
&nbsp;<br />
&nbsp;<br />
RFC&nbsp;3035----MPLS&nbsp;using&nbsp;LDP&nbsp;and&nbsp;ATM&nbsp;VC&nbsp;Switching&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;用LDP和ATM的VC交换实现MPLS&nbsp;&nbsp;<br />
<br />
<br />
<br />
<br />
1<br />
RFC文档中文翻译计划<br />
<br />