RFC1266 日本語訳

Network Working Group                                 Y. Rekhter, Editor
Request for Comments: 1266        T.J. Watson Research Center, IBM Corp.
                                                            October 1991

ワーキンググループY.Rekhter、コメントを求めるエディタ要求をネットワークでつないでください: 1266 T.J.ワトソン研究所、IBM社の1991年10月

                    Experience with the BGP Protocol

BGPプロトコルの経験

1. Status of this Memo.

1. このMemoの状態。

   This memo provides information for the Internet community.  It does
   not specify an Internet standard. Distribution of this memo is
   unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

2. Introduction.

2. 序論。

   The purpose of this memo is to document how the requirements for
   advancing a routing protocol to Draft Standard have been satisfied by
   Border Gateway Protocol (BGP). This report documents experience with
   BGP.  This is the second of two reports on the BGP protocol.  As
   required by the Internet Activities Board (IAB) and the Internet
   Engineering Steering Group (IESG), the first report will present a
   performance analysis of the BGP protocol.

このメモの目的はボーダ・ゲイトウェイ・プロトコル(BGP)によってルーティング・プロトコルをDraft Standardに唱えるための要件がどう満たされたかを記録することです。 このレポートはBGPの経験を記録します。 これはBGPプロトコルに関する2つのレポートの2番目です。 必要に応じて、BGPプロトコルの機能解析を提示するでしょうEngineering Steering Group(IESG)、インターネットActivities Board(IAB)とインターネットのそばの1番目が、報告する。

   The remaining sections of this memo document how BGP satisfies
   General Requirements specified in Section 3.0, as well as
   Requirements for Draft Standard specified in Section 5.0 of the
   "Internet Routing Protocol Standardization Criteria" document [1].

このメモの残っているセクションは「インターネットルーティング・プロトコル標準化評価基準」というドキュメント[1]のセクション5.0で指定されたDraft StandardのためにBGPがどうセクション3.0で指定されたRequirements司令官、およびRequirementsを満たすかを記録します。

   This report is based on the work of Dennis Ferguson (University of
   Toronto), Susan Hares (MERIT/NSFNET), and Jessica Yu (MERIT/NSFNET).
   Details of their work were presented at the Twentieth IETF meeting
   (March 11-15, 1991, St. Louis) and are available from the IETF
   Proceedings.

このレポートはデニスファーガソン(トロント大学)、スーザンHares(MERIT/NSFNET)、およびジェシカ・ユー(MERIT/NSFNET)の仕事に基づいています。 彼らの仕事の詳細は、Twentieth IETFミーティング(1991年3月11日〜15日、セントルイス)に提示されて、IETF Proceedingsから利用可能です。

   Please send comments to iwg@rice.edu.

コメントを iwg@rice.edu に送ってください。

3. Acknowledgements.

3. 承認。

   The BGP protocol has been developed by the IWG/BGP Working Group of
   the Internet Engineering Task Force. We would like to express our
   deepest thanks to Guy Almes (Rice University) who was the previous
   chairman of the IWG Working Group.  We also like to explicitly thank
   Bob Hinden (BBN) for the review of this document as well as his
   constructive and valuable comments.

BGPプロトコルはインターネット・エンジニアリング・タスク・フォースのIWG/BGP作業部会によって開発されました。 IWG作業部会の前の議長であったガイAlmes(ライス大学)のおかげで私たちの最も深さを言い表したいと思います。 また、私たちは、彼の建設的で貴重なコメントと同様にこのドキュメントのレビューについて明らかにボブHinden(BBN)に感謝するのが好きです。

BGP Working Group                                               [Page 1]

RFC 1266            Experience with the BGP Protocol        October 1991

BGP作業部会[1ページ]RFC1266は1991年10月にBGPと共にプロトコルを経験します。

4. Documentation.

4. ドキュメンテーション。

   BGP is an inter-autonomous system routing protocol designed for the
   TCP/IP internets.  Version 1 of the BGP protocol was published in RFC
   1105. Since then BGP Versions 2 and 3 have been developed. Version 2
   was documented in RFC 1163. Version 3 is documented in [3]. The
   changes between versions 1, 2 and 3 are explained in Appendix 3 of
   [3].  Most of the functionality that was present in the Version 1 is
   present in the Version 2 and 3.  Changes between Version 1 and
   Version 2 affect mostly the format of the BGP messages.  Changes
   between Version 2 and Version 3 are quite minor.

BGPはTCP/IPインターネットのために設計された相互自律システムルーティング・プロトコルです。 BGPプロトコルのバージョン1はRFC1105で発行されました。 それ以来、BGPバージョン2と3を開発してあります。 バージョン2はRFC1163に記録されました。 バージョン3は[3]に記録されます。 バージョン1、2、および3の間の変化は[3]のAppendix3で説明されます。 バージョン1で存在している機能性の大部分はバージョン2と3で存在しています。 バージョン1とバージョン2の間の変化はほとんどBGPメッセージの形式に影響します。 バージョン2とバージョン3の間の変化はかなり小さい方です。

   BGP Version 2 removed from the protocol the concept of "up", "down",
   and "horizontal" relations between autonomous systems that were
   present in the Version 1.  BGP Version 2 introduced the concept of
   path attributes.  In addition, BGP Version 2 clarified parts of the
   protocol that were "underspecified".  BGP Version 3 lifted some of
   the restrictions on the use of the NEXT_HOP path attribute, and added
   the BGP Identifier field to the BGP OPEN message. It also clarifies
   the procedure for distributing BGP routes between the BGP speakers
   within an autonomous system.  Possible applications of BGP in the
   Internet are documented in [2].

BGPバージョン2はプロトコルから“up"、“down"、およびバージョン1で存在している自律システムの「水平な」関係の概念を取り除きました。 BGPバージョン2は経路属性の概念を紹介しました。 さらに、BGPバージョン2は"underspecifiedする"であったプロトコルの部分をはっきりさせました。 BGPバージョン3は、ネクスト_HOP経路属性の使用のときに制限のいくつかについて提案して、BGP Identifier分野をBGP OPENメッセージに追加しました。 また、それは自律システムの中のBGPスピーカーの間のBGPルートを分配するための手順をはっきりさせます。 インターネットのBGPの可能なアプリケーションは[2]に記録されます。

   The BGP protocol was developed by the IWG/BGP Working Group of the
   Internet Engineering Task Force. This Working Group has a mailing
   list, iwg@rice.edu, where discussions of protocol features and
   operation are held. The IWG/BGP Working Group meets regularly during
   the quarterly Internet Engineering Task Force conferences. Reports of
   these meetings are published in the IETF's Proceedings.

BGPプロトコルはインターネット・エンジニアリング・タスク・フォースのIWG/BGP作業部会によって開発されました。 この作業部会にはメーリングリスト、 iwg@rice.edu があります。そこでは、プロトコル機能と操作の議論が行われます。 IWG/BGP作業部会は四半期のインターネット・エンジニアリング・タスク・フォース会議の間、定期的に会合します。 これらのミーティングのレポートはIETFのProceedingsで発表されます。

5. MIB

5. MIB

   A BGP Management Information Base has been published [4].  The MIB
   was written by Steve Willis (swillis@wellfleet.com) and John Burruss
   (jburruss@wellfleet.com).

BGP Management Information基地は発行されました。[4]。 MIBはスティーブ・ウィリス( swillis@wellfleet.com )とジョンBurruss( jburruss@wellfleet.com )によって書かれました。

   Apart from a few system variables, the BGP MIB is broken into two
   tables: the BGP Peer Table and the BGP Received Path Attribute Table.
   The Peer Table reflects information about BGP peer connections, such
   as their state and current activity. The Received Path Attribute
   Table contains all attributes received from all peers before local
   routing policy has been applied. The actual attributes used in
   determining a route are a subset of the received attribute table.

いくつかのシステム変数は別として、2個のテーブルがBGP MIBに細かく分けられます: BGP同輩テーブルとBGPは経路属性テーブルを受けました。 Peer Tableは彼らの状態や現在の活動などのBGP同輩接続の情報を反映します。 Received Path Attribute Tableはローカルのルーティング方針が適用される前にすべての同輩から受け取られたすべての属性を含んでいます。 ルートを決定する際に使用される実際の属性は容認された属性テーブルの部分集合です。

   The BGP MIB is quite small. It contains total of 27 objects.

BGP MIBはかなり小さいです。 それは27個のオブジェクトの合計を含んでいます。

BGP Working Group                                               [Page 2]

RFC 1266            Experience with the BGP Protocol        October 1991

BGP作業部会[2ページ]RFC1266は1991年10月にBGPと共にプロトコルを経験します。

6. Security architecture.

6. セキュリティー体系。

   BGP provides flexible and extendible mechanism for authentication and
   security. The mechanism allows to support schemes with various degree
   of complexity. All BGP sessions are authenticated based on the BGP
   Identifier of a peer. In addition, all BGP sessions are authenticated
   based on the autonomous system number advertised by a peer. As part
   of the BGP authentication mechanism, the protocol allows to carry
   encrypted digital signature in every BGP message. All authentication
   failures result in sending the NOTIFICATION messages and immediate
   termination of the BGP connection.

BGPはフレキシブルで拡張可能なメカニズムを認証とセキュリティに提供します。 メカニズムは様々な度合いの複雑さがある体系をサポートに許容します。 すべてのBGPセッションが同輩のBGP Identifierに基づいて認証されます。 さらに、すべてのBGPセッションが同輩によって広告に掲載された自律システム番号に基づいて認証されます。 BGP認証機構の一部として、プロトコルで、あらゆるBGPメッセージにおける暗号化されたデジタル署名を運びます。 すべての認証失敗がBGP接続のNOTIFICATIONメッセージを送って、即座の終了をもたらします。

   Since BGP runs over TCP and IP, BGP's authentication scheme may be
   augmented by any authentication or security mechanism provided by
   either TCP or IP.

BGPがTCPとIPをひくので、BGPの認証体系はTCPかIPのどちらかによって提供されたどんな認証やセキュリティー対策によっても増大させられるかもしれません。

7. Implementations.

7. 実装。

   There are multiple interoperable implementations of BGP currently
   available. This section gives a brief overview of the three
   completely independent implementations that are currently used in the
   operational Internet. They are:

BGPの現在利用可能な複数の共同利用できる実装があります。 このセクションは現在操作上のインターネットで使用される3つの完全に独立している実装の簡潔な概要を与えます。 それらは以下の通りです。

      - cisco. This implementation was wholly developed by cisco.
        It runs on the proprietary operating system used by the
        cisco routers. Consult Kirk Lougheed (lougheed@cisco.com)
        for more details.

- コクチマス。 この実装はコクチマスによって完全に開発されました。 それはコクチマスルータによって使用される独占オペレーティングシステムで動きます。 その他の詳細のために、カーク・ロッキード( lougheed@cisco.com )に相談してください。

      - "gated". This implementation was developed wholly by Jeff
        Honig (jch@risci.cit.cornell.edu) and Dennis Ferguson
        (dennis@CAnet.CA).  It runs on a variety of operating systems
        (4.3 BSD, AIX, etc...).  It is the only available public domain
        code for BGP. Consult Jeff Honig or Dennis Ferguson for more
        details.

- 「外出を禁止されます」。 この実装はジェフ・ホニッグ( jch@risci.cit.cornell.edu )とデニスファーガソン( dennis@CAnet.CA )によって完全に開発されました。 それはさまざまなオペレーティングシステム(4.3BSD、AIXなど)で動きます。 それはBGPのための唯一の利用可能な公共の場コードです。 その他の詳細のためにジェフ・ホニッグかデニスファーガソンに相談してください。

      - NSFNET. This implementation was developed wholly by Yakov
        Rekhter (yakov@watson.ibm.com). It runs on the T1 NSFNET
        Backbone and T3 NSFNET Backbone. Consult Yakov Rekhter for
        more details.

- NSFNET。 この実装はヤコフRekhter( yakov@watson.ibm.com )によって完全に開発されました。 それはT1 NSFNET BackboneとT3 NSFNET Backboneの上で作業します。 その他の詳細のためにヤコフRekhterに相談してください。

   To facilitate efficient BGP implementations, and avoid commonly made
   mistakes, the implementation experience with BGP in "gated" was
   documented as part of RFC 1164.  Implementors are strongly encouraged
   to follow the implementation suggestions outlined in that document.

効率的なBGP実装を容易にして、一般的に人工の誤りを避けるために、中にBGPがある状態で「外出を禁止された」実装経験はRFC1164の一部として記録されました。 作成者がそのドキュメントに概説された実装提案に続くよう強く奨励されます。

   Experience with implementing BGP showed that the protocol is
   relatively simple to implement. On the average BGP implementation
   takes about 1 man/month effort.

BGPを実装する経験は、プロトコルは実装するのが比較的簡単であることを示しました。 平均して、BGP実装はおよそ1つの男性/月の取り組みを取ります。

BGP Working Group                                               [Page 3]

RFC 1266            Experience with the BGP Protocol        October 1991

BGP作業部会[3ページ]RFC1266は1991年10月にBGPと共にプロトコルを経験します。

   Note that, as required by the IAB/IESG for Draft Standard status,
   there are multiple interoperable completely independent
   implementations, namely those from cisco, "gated", and IBM.

必要に応じて、Draft Standard状態へのIAB/IESGで、複数の共同利用できる完全に独立している実装があります、すなわち、コクチマスからのそれら、「外出を禁止され」てメモ、およびIBM。

8. Operational experience.

8. 運用経験。

   This section discusses operational experience with BGP.

このセクションはBGPの運用経験について論じます。

   BGP has been used in the production environment since 1989.  This use
   involves all three implementations listed above.  Production use of
   BGP includes utilization of all significant features of the protocol.
   The present production environment, where BGP is used as the inter-
   autonomous system routing protocol, is highly heterogeneous.  In
   terms of the link bandwidth it varies from 56 Kbits/sec to 45
   Mbits/sec. In terms of the actual routes that run BGP it ranges from
   a relatively slow performance PC/RT to a very high performance
   RS/6000, and includes both the special purpose routers (cisco) and
   the general purpose workstations running UNIX. In terms of the actual
   topologies it varies from a very sparse (spanning tree or a ring of
   CA*Net) to a quite dense (T1 or T3 NSFNET Backbones).

1989年以来BGPは実稼動環境に使用されています。 この使用は上に記載されたすべての3つの実装にかかわります。 BGPの生産使用はプロトコルに関するすべての著しい特徴の利用を含んでいます。 現在の実稼動環境はBGPが相互自律システムルーティング・プロトコルとして使用されるところで非常に異種です。 56キロビット/秒から45メガビット/秒に変えるリンク帯域幅に関して BGPを実行する実際のルートで、それは、比較的遅い性能PC/RTから非常に高性能RS/6000まで及んで、専用ルータ(コクチマス)とUNIXを実行する汎用のワークステーションの両方を含んでいます。 実際のtopologiesに関して、それは非常にまばらな(カリフォルニア*ネットのスパニングツリーか響き)aから全く濃い状態で(T1かT3 NSFNET Backbones)異なります。

   At the time of this writing BGP is used as an inter-autonomous system
   routing protocol between the following autonomous systems: CA*Net, T1
   NSFNET Backbone, T3 NSFNET Backbone, T3 NSFNET Test Network, CICNET,
   MERIT, and PSC. Within CA*Net there are 10 border routers
   participating in BGP. Within T1 NSFNET Backbone there are 20 border
   routers participating in BGP. Within T3 NSFNET Backbone there are 15
   border routers participating in BGP. Within T3 NSFNET Test Network
   there are 7 border routers participating in BGP. Within CICNET there
   are 2 border routers participating in BGP. Within MERIT there is 1
   border router participating in BGP. Within PSC there is 1 router
   participating in BGP. All together there are 56 border routers
   spanning 7 autonomous systems that are running BGP.  Out of these, 49
   border routers that span 6 autonomous systems are part of the
   operational Internet.

この書くこと時点で、BGPは以下の自律システムの間の相互自律システムルーティング・プロトコルとして使用されます: カリフォルニア*ネット、T1 NSFNETバックボーン、T3 NSFNETバックボーン、T3 NSFNETテストネットワーク、CICNET、長所、およびPSC。 カリフォルニア*ネットの中に、BGPに参加する10の境界ルータがあります。 中では、そこのT1 NSFNET BackboneがBGPに参加する20の境界ルータです。 中では、そこのT3 NSFNET BackboneがBGPに参加する15の境界ルータです。 中では、そこのT3 NSFNET Test NetworkがBGPに参加する7つの境界ルータです。 中では、そこのCICNETがBGPに参加する2つの境界ルータです。 中では、そこのMERITがBGPに参加する1つの境界ルータです。 中では、そこのPSCがBGPに参加する1つのルータです。 一斉に、実行しているBGPである7つの自律システムにかかる56の境界ルータがあります。 これらから、6つの自律システムにかかる49の境界ルータが操作上のインターネットの一部です。

   BGP is used both for the exchange of routing information between a
   transit and a stub autonomous system, and for the exchange of routing
   information between multiple transit autonomous systems. It covers
   both the Backbones (CA*Net, T1 NSFNET Backbone, T3 NSFNET Backbone),
   and the Regional Networks (PSC, MERIT).

BGPはトランジットとスタッブ自律システムの間のルーティング情報の交換、および複数のトランジット自律システムの間のルーティング情報の交換に使用されます。それはBackbones(カリフォルニア*ネット、T1 NSFNET Backbone、T3 NSFNET Backbone)とRegional Networks(PSC、MERIT)の両方をカバーしています。

   Within CA*Net, T3 NSFNET Backbone, and T3 NSFNET Test Network BGP is
   used as the exclusive carrier of the exterior routing information
   both between the autonomous systems that correspond to the above
   networks, and with the autonomous system of each network. At the time
   of this writing within the T1 NSFNET Backbone BGP is used together
   with the NSFNET Backbone Interior Routing Protocol to carry the

中では、カリフォルニア*のネット、T3 NSFNET Backbone、およびT3 NSFNET Test Network BGPが外のルーティング情報の排他的なキャリヤーとして上のネットワークに対応する自律システムの間と、そして、それぞれのネットワークの自律システムで使用されます。 この書くこと時点で、中では、T1 NSFNET Backbone BGPが、運ぶのにNSFNET Backbone Interiorルート設定プロトコルと共に使用されます。

BGP Working Group                                               [Page 4]

RFC 1266            Experience with the BGP Protocol        October 1991

BGP作業部会[4ページ]RFC1266は1991年10月にBGPと共にプロトコルを経験します。

   exterior routing information. T1 NSFNET Backbone is in the process of
   moving toward carrying the exterior routing information exclusively
   by BGP.  The full set of exterior routes that is carried by BGP is
   well over 2,000 networks.

外のルーティング情報。 排他的にBGPで外のルーティング情報を運ぶことに向かって移行することの途中にT1 NSFNET Backboneがあります。 BGPによって運ばれる外のルートのフルセットははるかに2,000以上のネットワークです。

   Operational experience described above involved multi-vendor
   deployment (cisco, "gated", and NSFNET).

上で説明された運用経験はマルチベンダ展開(「外出を禁止された」コクチマスとNSFNET)にかかわりました。

   Specific details of the operational experience with BGP in the NSFNET
   were presented at the Twentieth IETF meeting (March 11-15, 1991, St.
   Louis) by Susan Hares (MERIT/NSFNET).  Specific details of the
   operational experience with BGP in the CA*Net were presented at the
   Twentieth IETF meeting (March 11-15, 1991, St. Louis) by Dennis
   Ferguson (University of Toronto).  Both of these presentations are
   available in the IETF Proceedings.

NSFNETのBGPの運用経験の特定の詳細はTwentieth IETFミーティング(1991年3月11日〜15日、セントルイス)にスーザンHares(MERIT/NSFNET)によって提示されました。 カリフォルニア*ネットにおけるBGPの運用経験の特定の詳細はTwentieth IETFミーティング(1991年3月11日〜15日、セントルイス)にデニスファーガソン(トロント大学)によって提示されました。 これらのプレゼンテーションの両方がIETF Proceedingsで利用可能です。

   Operational experience with BGP exercised all basic features of the
   protocol, including the authentication and routing loop suppression.

BGPの運用経験は認証とルーティング輪の抑圧を含むプロトコルに関するすべての基本的特徴を運動させました。

   Bandwidth consumed by BGP has been measured at the interconnection
   points between CA*Net and T1 NSFNET Backbone. The results of these
   measurements were presented by Dennis Ferguson during the last IETF,
   and are available from the IETF Proceedings. These results showed
   clear superiority of BGP as compared with EGP in the area of
   bandwidth consumed by the protocol. Observations on the CA*Net by
   Dennis Ferguson, and on the T1 NSFNET Backbone by Susan Hares
   confirmed clear superiority of BGP as compared with EGP in the area
   of CPU requirements.

BGPによって消費された帯域幅はカリフォルニア*のネットとT1 NSFNET Backboneの間のインタコネクトポイントで測定されました。 これらの測定値の結果は、最後のIETFの間、デニスファーガソンによって提示されて、IETF Proceedingsから利用可能です。 これらの結果はプロトコルによって消費された帯域幅の領域のEGPと比べてBGPの明確な優越を示しました。 カリフォルニア*における観測はCPU要件の領域のEGPと比べてBGPを優越から取り除きますデニスファーガソンの近くと、そして、スーザンHaresによるT1 NSFNET Backboneの上のネットが、確認した。

9. Using TCP as a transport for BGP.

9. BGPに輸送としてTCPを使用します。

9.1. Introduction.

9.1. 序論。

   On multiple occasions some members of IETF expressed concern about
   using TCP as a transport protocol for BGP. In this section we examine
   the use of TCP for BGP in terms of:

複数の時に、IETFの何人かのメンバーがBGPにトランスポート・プロトコルとしてTCPを使用することに関して懸念を示しました。 このセクションで、私たちは以下に関してTCPのBGPの使用を調べます。

      - real versus perceived problems
      - offer potential solutions to real problems
      - perspective on the convergence problem
      - conclusions

- 知覚された問題--潜在的ソリューションを実際の問題に提供します--集合問題の見解--結論に対して本当です。

   BGP is based on the incremental updates. This is done intentionally
   to conserve the CPU and bandwidth requirements. Extensive operational
   experience with BGP in the Internet showed that indeed the use of the
   incremental updates allows significant saving both in terms of the
   CPU utilization and bandwidth consumption.  However, to operate
   correctly the incremental updates must be exchanged over a reliable

BGPはアップデート増加に基づいています。 CPUと帯域幅要件を保存するために故意にこれをします。 インターネットのBGPの大規模な運用経験は、本当に、アップデート増加の使用がCPU使用率と帯域幅消費による重要な節約を許すのを示しました。 しかしながら、正しくアップデート増加を操作するのを信頼できるaの上と交換しなければなりません。

BGP Working Group                                               [Page 5]

RFC 1266            Experience with the BGP Protocol        October 1991

BGP作業部会[5ページ]RFC1266は1991年10月にBGPと共にプロトコルを経験します。

   transport.  BGP uses TCP as such transport. It had been suggested
   that another transport protocol would be more suitable for BGP.

輸送。 BGPはそのような輸送としてTCPを使用します。 別のトランスポート・プロトコルがBGPにより適当であると示唆されました。

9.2. Examination of Problems - Real and "perceived".

9.2. 問題の試験--本当で「知覚されています」。

   Extensive operational experience with BGP in the Internet showed that
   the only real problem that was attributed to BGP in general, and the
   use of TCP as the transport for BGP in particular, was its slow
   convergence in presence of congestion.  This problem was experienced
   in CA*Net. As we mentioned before, CA*Net is composed of 10 routers
   that form a ring. The routers are connected by 56 Kbits/sec links.
   All links are heavily utilized and are often congested.  Experience
   with BGP in CA*Net showed that unless special measures are taken, the
   protocol may exhibit slow convergence when BGP information is passed
   over the slow speed (56 Kbits/sec) congested links. This is because a
   large percentage of packets carrying BGP information are being
   dropped due to congestion.  Therefore, there are three inter-related
   problems: congestion, packet drops, and the resulting slow
   convergence of routing under congestion and packet drops.

インターネットのBGPの大規模な運用経験は、一般に、BGPの結果と考えられた、唯一の実際の問題、および特に輸送としてのTCPのBGPの使用が混雑の存在で遅い集合であることを示しました。 この問題はカリフォルニア*ネットで経験されました。 私たちが以前言及したように、カリフォルニア*ネットは輪になる10のルータで構成されます。 ルータは56個のキロビット/秒のリンクによって接続されます。 すべてのリンクが、大いに利用されて、しばしば充血します。 カリフォルニア*ネットにおけるBGPの経験は、情報が遅い速度(56キロビット/秒)の上通過されるBGPがリンクを充血させたとき、特別な対策が実施されない場合、プロトコルが遅い集合を示すかもしれないのを示しました。 これはBGP情報を運ぶ大きい百分率のパケットが混雑のため下げられているからです。 したがって、3つの相互関連する問題があります: 混雑、パケット滴、および結果になるのは混雑とパケット滴の下でルーティングの集合を遅くします。

   Observe, that any transport protocol used by BGP would have
   difficulty preventing packets from being dropped under congestion,
   since it has no direct control over the routers that drop the
   packets, and the congestion has nothing to do with the BGP traffic.
   Therefore, since BGP is not the cause of congestion, and cannot
   directly influence dropping at the routers, replacing TCP (as the BGP
   transport) with another transport protocol would have no effect on
   packets being dropped due to congestion. We think that once a network
   is congested, packets will be dropped (regardless of whether these
   packets carry BGP or any other information), unless special measures
   outside of BGP in general, and the transport protocol used by BGP in
   particular, are taken.

パケットが混雑で下げられるのを防ぐのにいずれもBGPによって使用されたプロトコルを輸送するのが苦労するのを観測してください、それにはパケットを下げるルータの上の直轄が全くなくて、混雑がBGPトラフィックと関係ないので。 したがって、BGPが混雑の原因でなく、直接ルータの低下に影響を及ぼすことができないので、TCP(BGP輸送としての)を別のトランスポート・プロトコルに取り替えるのは混雑のため下げられながら、パケットの上で効き目がないでしょう。 私たちは、ネットワークがいったん混雑するようになるとパケットが下げられる(これらのパケットがBGPかいかなる他の情報も運ぶかどうかにかかわらず)と思います、一般に、BGPにおける外の特別な程度、および特にBGPによって使用されたトランスポート・プロトコルが取られない場合。

   If packets carrying routing information are lost, any distributed
   routing protocol will exhibit slow convergence.  If quick convergence
   is viewed as important for a routing within a network, special
   measures to minimize the loss of packets that carry routing
   information must be taken.  The next section suggests some possible
   methods.

ルーティング情報を運ぶパケットが無くなると、どんな分配されたルーティング・プロトコルも遅い集合を示すでしょう。 迅速な集合がルーティングにネットワークの中で重要であるとして見なされるなら、ルーティング情報を運ぶパケットの損失を最小にする特別な対策は実施されなければなりません。 次のセクションはいくつかの可能なメソッドを示します。

9.3. Solutions to the problem.

9.3. 問題の解決。

   Two possible measures could be taken to reduce the drop of BGP
   packets which slows convergence of routing:

ルーティングの集合を遅くするBGPパケットの滴を減少させるために2つの可能な対策を実施されることができました:

      1) alleviate the congestion

1) 混雑を軽減してください。

      2) reduce the percentage of BGP packets that are dropped due

2) 当然の状態で下げられるBGPパケットの割合を低下させてください。

BGP Working Group                                               [Page 6]

RFC 1266            Experience with the BGP Protocol        October 1991

BGP作業部会[6ページ]RFC1266は1991年10月にBGPと共にプロトコルを経験します。

         to congestion by marking BGP packets and setting policies to
         routers to try not to drop BGP packets

BGPパケットを下げないようにするルータにBGPパケットをマークして、方針を設定するのによる混雑に

   Alleviating the network congestion is a subject outside the control
   of BGP, and will not be discussed in this paper.

ネットワークの混雑を軽減するのと、BGPのコントロールの外における対象であり、この紙で議論しないでしょう。

   Operational experience with BGP in CA*Net shows that reducing the
   percentage of BGP packets dropped due to congestion by marking them,
   and setting policies to routers to try not to drop BGP packets
   completely solves the problem of slow convergence in presence of
   congestion.

カリフォルニア*ネットにおけるBGPの運用経験は、BGPパケットの割合が混雑のためBGPパケットを下げないようにするためにそれらをマークして、ルータに方針を設定することによって下げた減少が混雑の存在における遅い集合の問題を完全に解決するのを示します。

   The BGP packets can be marked (explicitly or implicitly) by the
   following three methods:

以下の3つのメソッドでBGPパケットをマークできます(明らかかそれとなく):

      a) by means of IP precedence (Internetwork Control)

a) IP先行による(インターネットワークコントロール)

      b) by using a well-known TCP port number

よく知られるTCPポートナンバーを使用するのによるb)

      c) by identifying packets by just source or destination IP
         address.

まさしくソースか送付先IPアドレスでパケットを特定するのによるc)。

   Appendix 4 of the BGP protocol specification, RFC 1163, recommends
   the use of IP precedence (Internetwork Control) because the
   precedence provides a well-defined mechanism to mark BGP packets.
   The method of a well-known TCP port number to identify packets is
   similar to the one that was used by Dave Mills in the NSFNET Phase I.
   Dave Mills identified Telnet traffic by a well known TCP port number,
   and gave it priority over the rest of the traffic.  CA*Net identified
   BGP traffic based on it's source and destination IP address.  Packets
   receive a priority if either the source or the destination IP address
   belongs to CA*Net.

先行がBGPパケットをマークするために明確なメカニズムを提供するので、BGPプロトコル仕様の付録4(RFC1163)はIP先行(インターネットワークControl)の使用を推薦します。 よく知られるTCPポートナンバーがパケットを特定するメソッドはNSFNET Phase I.のデーヴ・ミルズによって使用されたものと同様です。デーヴ・ミルズは、よく知られているTCPポートナンバーに従ってTelnetトラフィックを特定して、トラフィックの残りの上でそれを優先させました。 カリフォルニア*ネットはそれに基づいているBGPトラフィックのソースと送付先IPアドレスを特定しました。 ソースか送付先IPアドレスのどちらかがカリフォルニア*ネットに属すなら、パケットは優先を受けます。

   If packets that carry the routing information are being dropped
   (because of congestion), one also may ask about how does a particular
   routing protocol react to such an event.  In the case of BGP the
   packets are retransmitted using the TCP retransmission mechanism. It
   seems plausible that being more aggressive in terms of the
   retransmission should have positive effect on the convergence.  This
   can be done completely within TCP by adjusting the TCP retransmission
   timers. However, we would like to point out that the change in the
   retransmission strategy should not be viewed as a cure for the
   problem, since the root of the problem lies in the way how packets
   that carry the BGP information are handled within a congested
   network, and not in how frequently the lost packets are
   retransmitted.

下げられます(混雑による)、もどのようにに関して尋ねるかもしれないかということであることが運ぶルーティング情報を運ぶパケットであるなら、特定のルーティング・プロトコルはそのようなイベントに反応します。 BGPの場合では、パケットは、TCP retransmissionメカニズムを使用することで再送されます。 「再-トランスミッション」で、より攻撃的であるのが集合に明白な効果を持っているべきであるのはもっともらしく思えます。 TCPの完全中でTCP再送信タイマーを調整することによって、これができます。 しかしながら、「再-トランスミッション」戦略における変化が問題の療法として見なされるべきでないと指摘したいと思います、問題の本質がBGP情報を運ぶパケットが無くなっているパケットがどれくらい頻繁に再送されるかで扱われるのではなく、混雑しているネットワークの中で扱われる方法であるので。

   It should also be pointed out that the local system can control the

また、ローカルシステムが制御されることができると指摘されるべきです。

BGP Working Group                                               [Page 7]

RFC 1266            Experience with the BGP Protocol        October 1991

BGP作業部会[7ページ]RFC1266は1991年10月にBGPと共にプロトコルを経験します。

   amount of data to be retransmitted (in case of a congestion or
   losses) by adjusting the TCP Window size. That allows to control the
   amount of potentially obsolete data that has to be retransmitted.

TCP Windowサイズを調整することによって再送されるべき(混雑か損失の場合に)データ量。 それは再送されなければならない潜在的に時代遅れのデータの量をコントロールに許容します。

9.4. Perspective on the Convergence Problem.

9.4. 集合問題の見解。

   To put the convergence problem in a proper perspective, we'd like to
   point out that much of the Internet now uses EGP at AS borders,
   ensuring that routing changes cannot be guaranteed to propagate
   between ASes in less than a few minutes. It would take huge amount of
   congestion to slow BGP to this pace. Additionally, the problems of
   EGP in the face of packet loss are well known and far exceed any
   imaginable problem BGP/TCP might ever suffer.  Therefore, the worst
   case behavior of BGP is about the same as the steady case behavior of
   EGP.

適切な見解に集合問題を入れるために、インターネットの大部分が現在AS境界でEGPを使用すると指摘したいと思います、数分以下でASesの間で伝播するためにルーティング変化を保証できないのを確実にして。 BGPをこのペースまで遅くするのに混雑の膨大な量を要するでしょう。 さらに、パケット損失に直面してEGPの問題は井戸がBGP/TCPが受けるどんな想像可能な問題も知っていて、遠くに、超えているということです。 したがって、BGPの最悪の場合動きはEGPの安定したケース動きとほぼ同じくらいです。

   Within an AS the speed of convergence of the AS's IGP in the face of
   congestion is of far greater concern than the propagation speed of
   BGP, and indeed avoiding loss of packets carrying IGP, and a more
   aggressive transport is similarly of much greater importance for an
   IGP than for BGP.

混雑に直面してASのIGPの集合の速度のASの中では、IGPのためのBGPよりすばらしい重要性は同様にBGPと、本当に、IGPを運ぶパケットの損失、および、より攻撃的な輸送を避ける伝播速度よりはるかにすごい関心の多くのものです。

   The issue of BGP convergence is of exaggerated importance to CA*Net
   since CA*Net carries no information about external routes in its IGP.
   CA*Net uses BGP to transfer external routes for use in computing
   internal routes through the CA*Net network.  The reason CA*Net does
   this has nothing to do with BGP. Under more ordinary circumstances an
   IGP carries external routing information for use in computing
   internal routes. CA*Net shows that BGP can work under extreme stress.
   However, it's results should not be taken as the norm since most
   networks will use BGP in a different (and less stressful)
   configuration, where information about external routes will be
   carried by an IGP.

カリフォルニア*ネットがIGPの外部経路の情報を全く運ばないので、BGP集合の問題は大袈裟にカリフォルニア*ネットに重要です。 カリフォルニア*ネットは、カリフォルニア*ネットネットワークを通して内部のルートを計算することにおける使用のための外部経路を移すのにBGPを使用します。 カリフォルニア*ネットがこれをする理由はBGPと関係ありません。 より普通の状況で、IGPは内部のルートを計算することにおける使用のための外部のルーティング情報を運びます。 カリフォルニア*ネットは、BGPが過度のストレスの下で働くことができるのを示します。 しかしながら、ほとんどのネットワークが異なって(それほどストレスが多くない)の構成の外部経路の情報がIGPによって運ばれるBGPを使用するので標準として結果をみなすべきでないということです。

9.5. Conclusion.

9.5. 結論。

   The extensive operational experience with BGP showed that the only
   problem attributed to BGP was the slow convergence problem in
   presence of congestion.  We demonstrated that this problem has
   nothing to do with BGP in general, or with TCP as the BGP transport
   in particular, but is directly related to the way how packets that
   carry routing information are handled within a congested network. The
   document suggests possible ways of solving the problem.  We would
   like to point out that the issue of convergence in presence of
   congested network is important to all distributed routing protocol,
   and not just to BGP.  Therefore, we recommend that every routing
   protocol (whether it is intra-autonomous system or inter-autonomous
   system) should clearly specify how its behavior is affected by the

BGPの大規模な運用経験は、BGPの結果と考えられた唯一の問題が混雑の存在の遅い集合問題であることを示しました。 私たちは、この問題がBGP輸送として一般に、またはTCPとBGPと特に関係ないのですが、直接ルーティング情報を運ぶパケットが混雑しているネットワークの中で扱われる方法に関連するのを示しました。 ドキュメントは問題を解決する可能な方法を示します。 混雑しているネットワークの存在における集合の問題がBGPだけではなく、すべての分配されたルーティング・プロトコルに重要であると指摘したいと思います。 したがって、私たちは、あらゆるルーティング・プロトコル(それがイントラ自律システムか相互自律システムであることにかかわらず)が明確に影響を受けた状態で振舞いがどうあるかを指定するべきであることを勧めます。

BGP Working Group                                               [Page 8]

RFC 1266            Experience with the BGP Protocol        October 1991

BGP作業部会[8ページ]RFC1266は1991年10月にBGPと共にプロトコルを経験します。

   congestion in the networks, and what are the possible mechanisms to
   avoid the negative effect of congestion (if any).

ネットワークにおける混雑と何が(もしあれば)の混雑のマイナスの効果を避ける可能なメカニズムですか?

10. Bibliography.

10. 図書目録。

   [1] Hinden, B., "Internet Routing Protocol Standardization Criteria",
       RFC 1264, BBN, October 1991.

[1]Hinden、B.、「インターネットルーティング・プロトコル標準化評価基準」、RFC1264、BBN、1991年10月。

   [2] Rekhter, Y., and P. Gross, "Application of the Border Gateway
       Protocol in the Internet", RFC 1268, T.J. Watson Research Center,
       IBM Corp., ANS, October 1991.

Rekhter、Y.、およびP.が利益を上げる[2]、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」、RFC1268、T.J.ワトソン研究所、IBM社、ANS(1991年10月)。

   [3] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-
       3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM
       Corp., October 1991.

[3] ロッキード、K.、およびY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル3(BGP3)」、RFC1267、コクチマスSystems、T.J.ワトソン研究所、IBM社(1991年10月)。

   [4] Willis, S., and J. Burruss, "Definitions of Managed Objects for
       the Border Gateway Protocol (Version 3)", RFC 1269, Wellfleet
       Communications Inc., October 1991.

[4] ウィリス、S.、およびJ.Burruss、「境界ゲートウェイへの管理オブジェクトの定義は(バージョン3)について議定書の中で述べます」、RFC1269、WellfleetコミュニケーションInc.、1991年10月。

Security Considerations

セキュリティ問題

   Security issues are discussed in section 6.

セクション6で安全保障問題について議論します。

Author's Address

作者のアドレス

   Yakov Rekhter
   T.J. Watson Research Center IBM Corporation
   P.O. Box 218
   Yorktown Heights, NY 10598

ニューヨーク ヤコフRekhter T.J.ワトソン研究所IBM社の私書箱218ヨークタウンの高さ、10598

   Phone:  (914) 945-3896
   EMail: yakov@watson.ibm.com

以下に電話をしてください。 (914) 945-3896 メールしてください: yakov@watson.ibm.com

   IETF BGP WG mailing list: iwg@rice.edu
   To be added: iwg-request@rice.edu

IETF BGP WGメーリングリスト: 加えられるべき iwg@rice.edu : iwg-request@rice.edu

BGP Working Group                                               [Page 9]

BGP作業部会[9ページ]