この文書はRFC4136の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                  P. Pillay-Esnault
Request for Comments: 4136                                 Cisco Systems
Category: Informational                                        July 2005


        OSPF Refresh and Flooding Reduction in Stable Topologies
              安定トポロジーでのOSPF更新と洪水の縮小

Status of This Memo
この文書の状態


   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.
   このメモはインターネット共同体に情報を提供します。これはインターネッ
   ト標準を指定しません。  このメモの配布は無制限です。

Copyright Notice
著作権表示

   Copyright (C) The Internet Society (2005).

Abstract
要約

   This document describes an extension to the OSPF protocol to reduce
   periodic flooding of Link State Advertisements (LSAs) in stable
   topologies.
   この文書は安定したトポロジーでリンク状態広告の周期的な洪水を減らすO
   SPFプロトコル拡張を記述します。

   Current OSPF behavior requires that all LSAs, except DoNotAge LSAs,
   to be refreshed every 30 minutes.  This document proposes to
   generalize the use of DoNotAge LSAs in order to reduce protocol
   traffic in stable topologies.
   現在のOSPFの行動は、DoNotAge LSA以外のLSAは30分毎に更新を必
   要とします。この文書は安定したトポロジーでプロトコルトラフィックを減
   らすためにDoNotAge LSAの使用を一般化することを提案します。
 
1.  Introduction
1.  導入

   The explosive growth of IP-based networks has placed focus on the
   scalability of Interior Gateway Protocols such as OSPF.  Networks
   using OSPF are growing every day and will continue to expand to
   accommodate the demand for connections to the Internet or intranets.
   IPベースのネットワークの爆発的な成長はOSPFのような内部ゲートウェ
   イプロトコルのスケーラビリティの問題を起こしました。OSPFを使うネッ
   トワークが毎日成長し、そしてインターネットあるいはイントラネットの接
   続に対する要求を受け入れるために拡張し続けるでしょう。

   Internet Service Providers and users that have large networks have
   noticed non-negligible protocol traffic, even when their network
   topologies were stable.
   インターネット・サービスプロバイダと大きいネットワークを持つユーザは、
   ネットワークトポロジーが安定している時でさえも、少なくはないプロトコ
   ルトラフィックに気付きました。

   OSPF requires every LSA to be refreshed every 1800 seconds or else
   they will expire when they reach 3600 seconds [1].
   OSPFはすべてのLSAに1800秒毎に更新を要求し、3600秒に達
   するとき期限切れになります[1]。

   This document proposes to overcome the LSA expiration by generalizing
   the use of DoNotAge LSAs.  This technique will facilitate OSPF
   scaling by reducing OSPF traffic overhead in stable topologies.
   DoNotAge LSAの使用を一般化することで、この文書はLSA期限を克服する
   ことを提案します。このテクニックは、安定したトポロジーで余計なOSP
   Fトラフィックを減らすことで、OSPFのスケール調整を容易にするでしょう。

2.  Changes in the Existing Implementation
2.  既存の実装の変更

   This enhancement relies on the implementation of the DoNotAge bit and
   the Indication-LSA.  The details of the implementation of the
   DoNotAge bit and the Indication-LSA are specified in "Extending OSPF
   to Support Demand Circuits" [2].
   この拡張はDoNotAgeビットとLSA表示の実装に依存します。DoNotAgeビッ
   トとLSA表示の実装の詳細は「需要回線を支援するためのOSPF拡張」
   で指定されます[2]。

   Flooding-reduction-capable routers will continue to send hellos to
   their neighbors and keep aging their self-originated LSAs in their
   database.  However, these routers will flood their self-originated
   LSAs with the DoNotAge bit set.  Thus, self-originated LSAs do not
   have to be re-flooded every 30 minutes and the re-flooding interval
   can be extended to the configured forced-flooding interval.  As in
   normal OSPF operation, any change in the contents of the LSA will
   cause a reoriginated LSA to be flooded with the DoNotAge bit set.
   This will reduce protocol traffic overhead while allowing changes to
   be flooded immediately.
   洪水縮小対応のルータはhellosを隣人に送り続けて、自己のデータベースで
   自己の生成したLSAを維持します。しかしながら、これらのルータは自己
   の生成したLSAをDoNotAgeビットを設定して送ります。それで、自己生成
   したLSAは30分毎に再送しなくてもよく、再送間隔は設定された強制送
   付間隔まで延長できます。通常のOSPFオペレーションのように、内容の
   変更されたLSAは再生成されたLSAを、DoNotAgeビットを設定して、送
   るでしょう。変更がすぐに配布されることを可能にしながら、これはプロト
   コルトラフィックのオーバーヘッドを減らすでしょう。

   Flooding-reduction-capable routers will flood received non-self-
   originated LSAs with the DoNotAge bit set on all normal or flooding-
   reduction-only interfaces within the LSA's flooding scope.  If an
   interface is configured as both flooding-reduction-capable and
   Demand-Circuit, then the flooding is done if and only if the contents
   of the LSA have changed.  This allows LSA flooding for unchanged LSAs
   to be periodically forced by the originating router.
   洪水縮小対応のルータは、LSA配布範囲内で、標準インターフェースや洪
   水縮小専用インターフェースで受信した、DoNotAgeビットを設定された、非
   自己生成LSAを送付するでしょう。もしインタフェースが洪水縮小対応と、
   需要回路の両方として設定されるなら、LSAの中身が変化した場合に限り、
   そしてこの場合には必ず、配布されます。これは変化していないLSAのL
   SA配布を、出発点のルータが周期的に強制することを可能にします。

3.  Backward Compatibility
3. 後方互換性

   Routers supporting the demand circuit extensions [2] will be able to
   correctly process DoNotAge LSAs flooded by routers supporting the
   flooding reduction capability described herein.  These routers will
   also suppress flooding DoNotAge LSAs on interfaces configured as
   demand circuits.  However, they will also flood DoNotAge LSAs on
   interfaces that are not configured as demand circuits.
   需要回線拡張[2]をサポートするルータは正確にここに記述された洪水縮小能
   力をサポートしルータによって配布されたDoNotAge LSAを処理することが可
   能でしょう。これらのルータは需要回線と設定されたインタフェース上で同
   じく洪水DoNotAge LSAを抑制するでしょう。しかしながら、需要回線と設定
   されていないインタフェース上でDoNotAge LSAを送るでしょう。

   When there are routers in the OSPF routing domain, stub area, or NSSA
   area, that do not support the demand circuit extensions [2] then the
   use of these flooding reduction capabilities will be subject to the
   demand circuit interoperability constraints articulated in section
   2.5 of "Extending OSPF to Support Demand Circuits" [2].  This implies
   that detection of an LSA, with the DC bit clear, will result in the
   re-origination of self-originated DoNotAge LSAs with the DoNotAge
   clear and purging of non-self-originated DoNotAge LSAs.
   OSPFルーティングドメインやスタブエリアやNSSAエリアに需要回線拡張
   [2]をサポートしないルータがあるとき、これらの洪水縮小能力の使用は「需
   要回線サポートのためのOSPF拡張」[2]の2.5章で明瞭に表現された需
   要回線互換性制約の適用を受けるでしょう。これは、DCビットがクリアの
   状態のLSAの発見は、DoNotAgeがクリアの自己生成DoNotAge LSAの再生性
   を起こし、非自己生成DoNotAge LSAを消去します。

4.  Security Considerations
4.  セキュリティの考察

   This memo does not create any new security issues for the OSPF
   protocol.  Security considerations for the base OSPF protocol are
   covered in [1].
   このメモはOSPFプロトコルの新しいセキュリティ問題を引き起こしませ
   ん。元のOSPFプロトコルに対するセキュリティー考慮は[1]にあります。

5.  Acknowledgments
5.  謝辞

   The author would like to thank Jean-Michel Esnault, Barry Friedman,
   Thomas Kramer, Acee Lindem, Peter Psenak, Henk Smit, and Alex Zinin
   for their helpful comments on this work.
   著者はこの仕事に関する役立つコメントのためJean-Michel EsnaultとBarry
   FriedmanとThomas KramerとAcee LindemとPeter PsenakとHenk SmitとAlex
   Zininに感謝します。

6.  Normative References
6.  参照する参考文献


   [1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [2] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
       April 1995.


A.  Configurable Parameters
A.  構成パラメータ

   This memo defines new configuration parameters for the flooding
   reduction feature.  The feature must be enabled by configuration on a
   router and is, by default, off.
   このメモは洪水縮小特性の新しい設定パラメータを定義します。特性はルー
   タで設定可能でなければならず、デフォルトはオフです。

    flooding-reduction <all | list of interfaces> Indicates that the
       router has the flooding reduction feature enabled.  By default,
       this parameter applies to all interfaces running under the OSPF
       instance to which it applies.  The feature can be enabled on a
       subset of explicitly specified interfaces.
    flooding-reduction <all | list of interfaces> ルータが洪水縮小特性を
       使用可能にすることを明示します。デフォルトで、このパラメータは対
       象のOSPFインスタンス下のすべてのインタフェースに当てはまりま
       す。特性は明示的に指定されたインタフェースの部分集合でも使用可能
       です。

    flooding-interval <n minutes> Indicates the interval in minutes for
       the periodic flooding of self-originated LSAs.  By default, this
       value is 30 minutes as per [1].  The minimum value is also 30
       minutes.  A value of infinity will prevent re-flooding of self-
       originated LSAs that have not changed.
    flooding-interval <n minutes> 自己生成のLSAの周期的な配布間隔を示
       します。デフォルトで、この値は[1]に従って30分です。最小値は同じ
       く30分です。無限の値は変化しない自己生成LSAの再配布をを妨げ
       るでしょう。

Author's Address
著者のアドレス

   Padma Pillay-Esnault
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134

   EMail: ppe@cisco.com



Full Copyright Statement
著作権表示全文

   Copyright (C) The Internet Society (2005).
   著作権(C)インターネット学会(2005)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.
   この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして
   この中に明らかにされる以外は著者がすべての権利を維持します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.
   この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
   者が代表するか貢献者を後援する組織(もしあれば)とインターネット学会
   とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
   報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、全ての保証を拒否します。

Intellectual Property
知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.
   この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
   正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
   可能かの範囲について、IETFは何の立場もとりません;この様な権利を
   認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.
   IETF事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書
   の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
   試みの結果は、http://www.ietf.org/iprにあるIETFオンラインIPR
   貯蔵庫で得られます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.
   IETFは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
   バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
   めます。どうかietf-ipr@ietf.orgのIETFに情報を伝えてください。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

[]Japanese translation by Ishida So