RFC2918 BGP-4（边界网关协议）的路由刷新功能

组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者：刘伟娜（superwinner，starfield@xanet.edu.cn） 译文发布时间：2001-4-26 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须 保留本文档的翻译及版权信息。

Network Working Group                                            E. Chen Request for Comments: 2918                              Redback Networks Category: Standards Track                                 September 2000

BGP-4（边界网关协议）的路由刷新功能 (RFC 2918 Route Refresh Capability for BGP-4)

Status of this Memo

   This document specifies an Internet standards track protocol for the    Internet community, and requests discussion and suggestions for    improvements.  Please refer to the current edition of the "Internet    Official Protocol Standards" (STD 1) for the standardization state    and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

目录

摘要 2

1. 介绍 2 2. 路由刷新功能 2 3. 路由更新报文 2 4. 操作 3 6. 说明 3 7. 参考文献 3 8. Author's Address 4 9.  Full Copyright Statement 4

摘要 本文定义了BGP（边界网关协议）的新功能――“路由刷新功能“。它允许路由刷新请求在BGP扬声器和相应的广告资源信息输出模块的后继重新广告(re-advertisment)之间进行动态交换。该功能的一种应用是使无拆分的路由策略的更改更加容易。

1. 介绍 目前在BGP（边界网关协议）－4【BGP－4】中还没有提供从BGP同位体中动态申请广告资源信息输出模块的重新广告的机制。当已有的一个同位体的路由策略发生改变时，不知何故，必须访问该同位体的所有前缀，然后再重新检测新的路由策略。要完成这样的功能，通常使用的是一种称为“软件重置”的策略――也就是说要一直保存着该同位体的所有路由的备份，即使是路由策略并不经常更改（通常情况下，一天也不会更改一两次）。这样的处理方法还需要额外的存储器和CPU（中央处理器）来处理这些路由。 本文提供了另外一种解决方案，这种方案可以避免额外处理的开销。更明确的讲，这种方法定义了一种新的BGP（边界网关协议）功能，称作“路由刷新功能”。该功能允许在BGP扬声器和它们各自的广告资源信息输出块的后继广播之间进行动态的路由交换。 2. 路由刷新功能 为了将路由刷新权限广告给它的同位体，BGP（边界网关协议）的扬声器要使用BGP（边界网关协议）的权限广告功能【BGP-CAP】。该权限使用权限代码为2、权限长度为0的广告功能进行广告。 通过将路由刷新权限广告给它的同位体，BGP（边界网关协议）的扬声器给它的同位体传递该扬声器已经能够接收并且恰当的处理来自于同位体的路由刷新报文（报文的格式定义在本文的第3部分）了。 3. 路由更新报文 路由刷新报文是一种新的BGP（边界网关协议）报文，该类报文的定义如下： 类型   5 － 路由刷新 报文格式：一个<AFI，SAFI>二元组，编码如下：                                     0       7      15      23      31                   +-------+-------+-------+-------+                   |      AFI      | Res.  | SAFI  |                   +-------+-------+-------+-------+

这个<AFI，SAFI>二元组的意义和编码方式与【BGP-MP, sect. 7】中定义的相同。详细描述如下： AFI  ―― 地址组标识符（16位） Res.  ―― 保留区域（8位）。方送方应当把它置为0，接收方应当忽略该域的信息。 SAFI  ―― 后继的地址组标识符（8位）。 4. 操作 BGP（边界网关协议）扬声器是用来从它的同位体接收路由更新(ROUTE-REFRESH)报文的。它应当能够使用BGP（边界网关协议）的权限广告【BGP－CAP】功能将路由更新权限通知它的同位体。     BGP（边界网关协议）扬声器只有收到来自它的同位体的路由更新权限才有可能发送路由更新（ROUTE-REFRESH）报文。该报文中携带的<AFI，SAFI>应当是会话建立是它的同位体通过权限广告功能通知扬声器的。     如果BGP（边界网关协议）扬声器从它的同位体那里收到了一个带有<AFI,SAFI>的报文，但是，该报文并不是会话建立是通过权限广告功能发送过来的；那么，BGP（边界网关协议）扬声器就会忽略该报文。否则，BGP(边界网关协议)将会根据它的输出路由过虑策略将带有<AFI,SAFI>的Adj-RIB-Out报文重新广播给它的同位体。

 5. 安全因素 对BGP（边界网关协议）的扩展并没有改变BGP（边界网关协议）的安全因素。 6. 说明 路由刷新概念的提出类似于用于IDRP（域间路由协议）中的相应概念。 作者要特别感谢Yakov Rekhter,、Ravi Chandra、 Srihari Ramachandra 以及 Bruce Cole，他们为本文提供了很好的建议和意见。

7. 参考文献 [BGP-4]   Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.

[BGP-MP]  Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000.

8. Author's Address

   Enke Chen    Redback Networks Inc.    350 Holger Way    San Jose, CA 95134

   EMail: enke@redback.com

9.  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.