RFC2918 日本語訳
2918 Route Refresh Capability for BGP-4. E. Chen. September 2000. (Format: TXT=7354 bytes) (Status: PROPOSED STANDARD)
RFC一覧
英語原文
Network Working Group E. Chen Request for Comments: 2918 Redback Networks Category: Standards Track September 2000 Route Refresh Capability for BGP-4 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. この文書は、Internet community のための Internet standards track protocol を明細に記述し、改良のための討議と提案を要求する。このプロ トコルの標準化状態とステータスについては、"Internet Official Protocol Standards" (STD 1) の最新版を参照してもらいたい。このメモの 配布は、無制限である。 ----------------------------------------------------------------------- Copyright Notice 著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. ----------------------------------------------------------------------- Abstract 要約 This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. One possible application of this capability is to facilitate non-disruptive routing policy changes. この文書は、'Route Refresh Capbability (経路を新たに取り込む能力)' と呼ばれる新しい Border Gateway Protocol (BGP) 能力を定義する。この capability は、BGP スピーカ間で経路リフレッシュ要求の動的な交換を許 し、そしてそれぞれの Adj-RIB-Out から構成する後に続く再広告を許す。 この capability の可能性がある 1 つの応用は、混乱しないルーティング ポリシー変更を容易にすることである。 ----------------------------------------------------------------------- 1. Introduction 1. 序論 Currently there does not exist a mechanism in BGP-4 [BGP-4] to dynamically request a re-advertisement of the Adj-RIB-Out from a BGP peer. When the inbound routing policy for a peer changes, all prefixes from that peer must be somehow made available and then re- examined against the new policy. To accomplish this, a commonly used approach, known as 'soft-reconfiguration', is to store an unmodified copy of all routes from that peer at all times, even though routing policies do not change frequently (typically no more than a couple times a day). Additional memory and CPU are required to maintain these routes. 現在、BGP-4 [BGP-4] において、BGP ピアから Adj-RIB-Out の再広告を動 的に要求するメカニズムは存在しない。ピアに対する内向きルーティングポ リシーを変更した時、そのピアからのすべてのプレフィックスは何らかの方 法で利用可能にしなければならなく、その後、新しいポリシーに対して再調 査しなければならない。このことを達成するため、'soft-reconfiguration' として知られる、共通に使用される方法は、常にそのピアからの変更されて いない全経路のコピーを持っておくことである。これは、たとえルーティン グポリシーが頻繁に変更しなくてもである (典型的に、1 日にわずか 2, 3 回)。追加のメモリと CPU は、これら経路を維持するために必要とされる。 This document proposes an alternative solution that avoids the additional maintenance cost. More specifically, it defines a new BGP capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. この文書は、追加の維持コストを回避する代わりとなる解決法を提案する。 より明確に、この文書は、'Route Refresh Capability' と呼ばれる新しい BGP capability を定義する。この capability は、BGP スピーカ間で経路 リフレッシュ要求の動的交換を許し、そしてそれぞれの Adj-RIB-Out から なる後に続く再広告を許す。 ----------------------------------------------------------------------- 2. Route Refresh Capability 2. 経路リフレッシュ能力 To advertise the Route Refresh Capability to a peer, a BGP speaker uses BGP Capabilities Advertisement [BGP-CAP]. This capability is advertised using the Capability code 2 and Capability length 0. ピアへと Route Refresh Capability を広告するため、BGP スピーカは、 BGP Capabilities Advertisement [BGP-CAP] を使用する。この capability は、Capability code 2 と Capability length 0 を使用して広告される。 By advertising the Route Refresh Capability to a peer, a BGP speaker conveys to the peer that the speaker is capable of receiving and properly handling the ROUTE-REFRESH message (as defined in Section 3) from the peer. ピアへと Route Refresh Capability を広告することにより、BGP スピーカ は、そのピアからの (Section 5 で定義されるとして) ROUTE-REFRESH メッ セージを受信し、正確に扱う能力があるということを、そのピアへと運ぶ。 ----------------------------------------------------------------------- 3. Route-REFRESH Message 3. 経路リフレッシュメッセージ The ROUTE-REFRESH message is a new BGP message type defined as follows: ROUTE-REFRESH メッセージは、次のように定義された新しいメッセージタイ プである: Type: 5 - ROUTE-REFRESH Message Format: Oneencoded as は、次のようにエンコードされる。 0 7 15 23 31 +-------+-------+-------+-------+ | AFI | Res. | SAFI | +-------+-------+-------+-------+ The meaning, use and encoding of this field is the same as defined in [BGP-MP, sect. 7]. More specifically, この フィールドの意味、使用法とエンコーディングは [BGP-MP, sect. 8] で定義されたのと同じである。より正確に言う と、次の通りである AFI - Address Family Identifier (16 bit). アドレスファミリ識別子 (16 bit)。 Res. - Reserved (8 bit) field. Should be set to 0 by the sender and ignored by the receiver. 予約 (8 bit) フィールド。送信側により 0 に設定さ れるべきであり、受信側で無視されるべきである。 SAFI - Subsequent Address Family Identifier (8 bit). 後に続くアドレスファミリ識別子 (8 bit)。 ----------------------------------------------------------------------- 4. Operation 4. 運用 A BGP speaker that is willing to receive the ROUTE-REFRESH message from its peer should advertise the Route Refresh Capability to the peer using BGP Capabilities advertisement [BGP-CAP]. ピアからの ROUTE-REFRESH メッセージ受信に同意している BGP スピーカは BGP Capabilities 広告 [BGP-CAP] を使用して、ピアへと Route Refresh Capability を広告すべきである。 A BGP speaker may send a ROUTE-REFRESH message to its peer only if it has received the Route Refresh Capability from its peer. The carried in such a message should be one of the that the peer has advertised to the speaker at the session establishment time via capability advertisement. BGP スピーカは、そのピアから Route Refresh Capability を受信した場合 のみ、そのピアへ ROUTE-REFRESH メッセージを送信するかもしれない。そ のメッセージで運ばれる は、capability 広告によるセッショ ン確立時間での、ピアがスピーカへと広告される の 1 つであ るべきである。 If a BGP speaker receives from its peer a ROUTE-REFRESH message with the that the speaker didn't advertise to the peer at the session establishment time via capability advertisement, the speaker shall ignore such a message. Otherwise, the BGP speaker shall re- advertise to that peer the Adj-RIB-Out of the carried in the message, based on its outbound route filtering policy. もし BGP スピーカが次に述べる情報を持つ ROUTE-REFRESH メッセージをそ のピアから受信するなら、スピーカは、そのようなメッセージを無視すべき である。その情報とは、capability 広告によるセッション確立時間で、ス ピーカがピアへと広告しない である。もしそうでなければ、 BGP スピーカは、そのピアへと、その外向き経路フィルタリングポリシーに 基づいて、メッセージ中で運ばれる の Adj-RIB-Out を再広告 すべきである。 ----------------------------------------------------------------------- 5. Security Considerations 5. セキュリティに関する考察 This extension to BGP does not change the underlying security issues. この BGP への拡張は、潜在的なセキュリティ問題を変更しない。 ----------------------------------------------------------------------- 6. Acknowledgments 6. 謝辞 The concept of Route Refresh proposed is similar to the one used in IDRP. 提案される Route Refresh の概念は、IDRP で使用される概念と類似してい る。 The author would like to thank Yakov Rekhter, Ravi Chandra, Srihari Ramachandra and Bruce Cole for their review and comments. 著者は、査読とコメントをしてくれた Yakov Rekhter, Ravi Chandra, Srihari Ramachandra と Bruce Cole に感謝したい。 ----------------------------------------------------------------------- 7. References 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 8. 著者のアドレス Enke Chen Redback Networks Inc. 350 Holger Way San Jose, CA 95134 EMail: enke@redback.com ----------------------------------------------------------------------- 9. Full Copyright Statement 9. 著作権表示全文 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. RFC Editor の働きに対する資金援助は、Internet Society により現在提供 される。
一覧
スポンサーリンク