RFC1656 日本語訳

1656 BGP-4 Protocol Document Roadmap and Implementation Experience. P.Traina. July 1994. (Format: TXT=7705 bytes) (Obsoleted by RFC1773) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          P. Traina
Request for Comments: 1656                                 cisco Systems
Category: Informational                                        July 1994

Trainaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 1656年のコクチマスSystems Category: 情報の1994年7月

     BGP-4 Protocol Document Roadmap and Implementation Experience

BGP-4プロトコルドキュメント道路地図と実装経験

Status of this Memo

このMemoの状態

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

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

Introduction

序論

   Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System
   routing protocol.  It is built on experience gained with BGP as
   defined in RFC-1267 [2] and BGP usage in the connected Internet as
   described in RFC-1268 [3].

ボーダ・ゲイトウェイ・プロトコルv4(BGP-4)[1]は相互Autonomous Systemルーティング・プロトコルです。 それはBGPと共に接続インターネットでRFC-1267[2]とBGP用法で定義されるように行われた経験のときにRFC-1268[3]で説明されるように建てられます。

   The primary function of a BGP speaking system is to exchange network
   reachability information with other BGP systems.  This network
   reachability information includes information on the list of
   Autonomous Systems (ASs) that reachability information traverses.
   This information is sufficient to construct a graph of AS
   connectivity from which routing loops may be pruned and some policy
   decisions at the AS level may be enforced.

BGPがシステムを話すプライマリ機能は他のBGPシステムとネットワーク可到達性情報を交換することです。このネットワーク可到達性情報は可到達性情報が横断するAutonomous Systems(ASs)のリストの上の情報を含んでいます。 この情報は、ルーティング輪余計なものを取り除かれるかもしれなくて、ASレベルにおけるいくつかの政策決定が励行されるかもしれないASの接続性のグラフを作図するために十分です。

   BGP-4 provides a new set of mechanisms for supporting classless
   inter-domain routing.  These mechanisms include support for
   advertising an IP prefix and eliminates the concept of network
   "class" within BGP.  BGP-4 also introduces mechanisms which allow
   aggregation of routes, including aggregation of AS paths.  These
   changes provide support for the proposed supernetting scheme [4].

BGP-4は階級のない相互ドメインルーティングをサポートするのに新しいセットのメカニズムを提供します。 これらのメカニズムは、IP接頭語の広告を出すサポートを含んで、BGPの中でネットワーク「クラス」の概念を排除します。 また、BGP-4はAS経路の集合を含むルートの集合を許容するメカニズムを紹介します。 これらの変化は提案されたスーパーネッティング体系[4]のサポートを提供します。

   The management information base has been defined [5] and security
   considerations are discussed in the protocol definition document [1].

管理情報ベースはプロトコル定義ドキュメント[1]で定義された[5]とセキュリティ問題について議論するということです。

Applicability Statement for BGP-4

BGP-4のための適用性証明

   BGP-4 is explicitly designed for carrying reachability information
   between Autonomous Systems.  BGP-4 is not intended to replace
   interior gateway protocols such as OSPF [7] or RIP [6].

Autonomous Systems. BGP-4の間まで可到達性情報を運ぶとOSPF[7]かRIP[6]などの内部のゲートウェイプロトコルが置き換えられることを意図しないので、BGP-4は明らかに設計されています。

Implementations

実装

   Four vendors have developed independent implementations at the time
   of this memo:

4つのベンダーがこのメモ時点で、独立している実装を開発しました:

Traina                                                          [Page 1]

RFC 1656                  BGP-4 Implementation                 July 1994

Traina[1ページ]RFC1656BGP-4実装1994年7月

        ANS (gated)
        Europanet
        3COM
        cisco

ANS(外出を禁止される)Europanet 3COMコクチマス

   The complete interoperability matrix between all known
   implementations of various versions of BGP is available under
   separate cover [9].

BGPの様々なバージョンのすべての知られている実装の間の完全な相互運用性マトリクスは別便[9]で利用可能です。

Implementation Testing

実装テスト

   One implementation has been extensively tested in a network designed
   to mirror the complex connectivity present at many major Internet
   borders.  This network consists of multiple BGP-3 and BGP-4 speakers
   carrying full routing information injected from Alternet, EBone,
   Sprint, CERFnet, and cisco.  In many cases additional AS adjacencies
   are simulated via the use of IP over IP tunnels to increase the
   complexity of the routing topology.

1つの実装が多くの主要なインターネット境界の現在の複雑な接続性を反映するように設計されたネットワークで手広くテストされました。 このネットワークはAlternet、EBone、スプリント、CERFnet、およびコクチマスから注入された完全なルーティング情報を運ぶ複数のBGP-3とBGP-4スピーカーから成ります。 多くの場合、追加AS隣接番組は、ルーティングトポロジーの複雑さを増強するためにIPトンネルの上でIPの使用でシミュレートされます。

   The primary feature of BGP-4 is the ability to carry network
   reachability information without regard to classfull routing.  In
   addition to canonical routing information,  CIDR prefixes (both
   supernets and subnets) are being injected from IGP information and
   aggregated using the methods described in BGP-4.  AS set aggregation
   and policy decisions based upon AS sets have been tested.

BGP-4のプライマリ特徴は関係なしでネットワーク可到達性情報をclassfullルーティングまで運ぶ能力です。 正準なルーティング情報に加えて、CIDR接頭語(「スーパー-ネット」とサブネットの両方)は、BGP-4で説明されたメソッドを使用することでIGP情報から注入されて、集められています。 ASは集合を設定します、そして、ASセットに基づく政策決定はテストされました。

   Secondary extensions incorporated as part of version 4 of this
   protocol include enhancements to use of the INTER_AS_METRIC (now
   called MULTI_EXIT_DISC), the addition of a LOCAL_PREF parameter to
   influence route selection within an AS,  and a specified method of
   damping route fluctuations.  All of these features have been tested
   in at least one implementation.

このプロトコルのバージョン4の一部としての法人組織のセカンダリ拡大は、ASの中のルート選択、およびルート変動をじめじめとする指定されたメソッドに影響を及ぼすためにINTER_AS_METRIC(現在、MULTI_をEXIT_DISCと呼ぶ)の使用、LOCAL_PREFパラメタの追加に増進を含んでいます。 これらの特徴のすべてが少なくとも1つの実装でテストされました。

Observations

観測

   All implementations, are able to carry and exchange network
   reachability information.

すべての実装が、ネットワーク可到達性情報を運んで、交換できます。

   Not all implementations are capable of generating aggregate
   information based upon the existence of more specific routes.

すべての実装がどんなより特定のルートの存在に基づく集合情報を生成することができるというわけではありません。

   No implementation supports automatic deaggregation (enumeration of
   all networks in an aggregate block for backwards compatibility with
   routing protocols that do not carry mask information (e.g. BGP-3)).
   However, most implementations do allow for staticly configured
   controlled deaggregation for minimal backwards compatibility with
   non-CIDR capable routers.

どんな実装も自動「反-集合」をサポートしません(すべての列挙は後方にように集合ブロックでマスク情報(例えば、BGP-3)を運ばないルーティング・プロトコルとの互換性をネットワークでつなぎます)。 しかしながら、ほとんどの実装が非CIDRのできるルータとの最小量の遅れている互換性に関して静的な構成された制御「反-集合」を考慮します。

Traina                                                          [Page 2]

RFC 1656                  BGP-4 Implementation                 July 1994

Traina[2ページ]RFC1656BGP-4実装1994年7月

   At least one implementation capable of running earlier versions of
   BGP deliberately does not automaticly negotiate to earlier versions.
   Connections to BGP-4 peers must be explicitly configured as such.

故意にBGPの以前のバージョンを実行できる少なくとも1つの実装が自動に以前のバージョンと交渉されません。 明らかにそういうものとしてBGP-4同輩へのコネクションズを構成しなければなりません。

Conclusions

結論

   The ability to carry and inject natural networks and CIDR supernets
   is the immediate requirement for BGP-4.  The ability to carry subnet
   information (useful when reassigning parts of class A networks to
   organizations with different routing policies) is of secondary
   concern.

自然なネットワークとCIDR supernetsを運んで、注入する能力はBGP-4のための即座の要件です。 サブネット情報(役に立つ異なったルーティング方針でクラスAネットワークの部分を組織に再選任すると)を運ぶ能力はあまり重要でない関心事のものです。

   The ability to conditionally aggregate routing information may be
   worked around by injecting static or IGP network information into
   BGP, or aggregation may be performed by an upstream router that is
   capable.

条件付きに情報が静電気かIGPネットワーク情報をBGP、または集合に注ぐことによって扱われるかもしれないルーティングに集める能力はできる上流のルータによって実行されるかもしれません。

   Deaggregation is dangerous.  It leads to information loss and unless
   tightly controlled by a manual mechanism,  will create a routing
   information explosion.

Deaggregationは危険です。 それは情報の損失を出します、そして、手動のメカニズムによってしっかり制御されないと、ルーティング情力化を引き起こすでしょう。

   Automatic version negotiation is dangerous due to the state-less
   nature.  Given packet losses or spontaneous restarts,  it is possible
   for two BGP peers capable of BGP-4 to negotiate a BGP-3 or BGP-2
   connection,  which is incapable of carrying super/subnet reachability
   information and AS set information.

自動バージョン交渉は状態がない自然のために危険です。 パケット損失か自然発生的な再開を考えて、BGP-4ができる2人のBGP同輩がBGP-3かBGP-2接続を交渉するのは、可能です。(接続は最高の/サブネット可到達性情報とAS情報集合を運ぶことができません)。

Acknowledgments

承認

   The author would like to acknowledge Yakov Rekhter (IBM) and Tony Li
   (cisco) for their advice, encouragement and insightful comments.

作者は彼らのアドバイス、奨励、および洞察に満ちたコメントのためにヤコフRekhter(IBM)とトニー・李(コクチマス)を承認したがっています。

References

参照

   [1] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4), RFC
       1654, cisco Systems, T.J. Watson Research Center, IBM Corp., July
       1994.

[1]Rekhter、Y.、およびT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)、RFC1654、コクチマスSystems、T.J.ワトソン研究所、IBM社、1994年7月。」

   [2] 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.

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

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

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

Traina                                                          [Page 3]

RFC 1656                  BGP-4 Implementation                 July 1994

Traina[3ページ]RFC1656BGP-4実装1994年7月

   [4] Fuller V., Li. T, Yu J., and K. Varadhan, "Supernetting: an
       Address Assignment and Aggregation Strategy", Work in Progress.
       [Note: This is an expired draft, and is also referred to in
       BGP4.6.]

[4] フラーV.、李。 T、ユーJ.、およびK.Varadhan、「スーパーネッティング:」 「アドレス課題と集合戦略」は進行中で働いています。 [注意: これは、満期の草稿であり、また、BGP4.6で言及されます。]

   [5] Willis S., Burruss J., and J. Chu, "Definitions of Managed
       Objects for the Border Gateway Protocol (Version 4) using SMIv2",
       RFC 1657, Wellfleet Communications Inc., IBM Corp., July 1994.

[5] ウィリスS.、Burruss J.、およびJ.チュウ、「SMIv2"を使用して、境界ゲートウェイへの管理オブジェクトの定義は(バージョン4)について議定書の中で述べます、RFC1657、WellfleetコミュニケーションInc.、IBM社、1994年7月。」

   [6] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
       University, June 1988.

[6] ヘドリック、C.、「ルーティング情報プロトコル」、RFC1058、ラトガース大学、1988年6月。

   [7] Moy J., "Open Shortest Path First Routing Protocol (Version 2)",
       RFC 1583, Proteon, March 1994.

[7]Moy J.、「開いている最短パス優先ルーティングプロトコル(バージョン2)」、RFC1583、Proteon、1994年3月。

   [8] Varadhan, K., Hares S., and Y. Rekhter, "BGP4/IDRP for IP---OSPF
       Interaction", Work in Progress, September 1993.

[8]Varadhan、K.、野兎S.、およびY.Rekhter、「IPのためのBGP4/IDRP」---「OSPF相互作用」、処理中の作業、1993年9月。

   [9] Li, T., and P. Traina, "BGP Interoperabilty Matrix", Work in
       Progress, November 1993.

[9] 李、T.、およびP.Traina、「BGP Interoperabiltyマトリクス」が進歩、1993年11月に働いています。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's  Address

作者のアドレス

   Paul Traina
   cisco Systems, Inc.
   1525 O'Brien Drive
   Menlo Park, CA 94025

ポールTrainaコクチマスSystems Inc.1525オブライエン・Driveメンローパーク、カリフォルニア 94025

   EMail: pst@cisco.com

メール: pst@cisco.com

Traina                                                          [Page 4]

Traina[4ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

NOT演算子 否定

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る