电脑技术学习

BGP-4(边界网关协议)的路由刷新功能

dn001

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.

摘要
本文定义了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 - 路由刷新
报文格式:一个二元组,编码如下:

0 7 15 23 31
+-------+-------+-------+-------+
AFI Res. SAFI
+-------+-------+-------+-------+

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

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

[BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC2842, 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.