RFC4167 日本語訳

4167 Graceful OSPF Restart Implementation Report. A. Lindem. October 2005. (Format: TXT=11780 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          A. Lindem
Request for Comments: 4167                            Cisco Systems, Inc
Category: Informational                                     October 2005

Lindemがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4167年のシスコシステムズ、Incカテゴリ: 情報の2005年10月

              Graceful OSPF Restart Implementation Report

優雅な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).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism
   whereby an OSPF router can stay on the forwarding path even as its
   OSPF software is restarted.  This document provides an implementation
   report for this extension to the base OSPF protocol.

RFC3623で指定される優雅なOSPF RestartはOSPFソフトウェアが再開されるとすぐに、OSPFルータが推進経路にいることができるメカニズムを提供します。 このドキュメントはこの拡大のための実装レポートをベースOSPFプロトコルに提供します。

Table of Contents

目次

   1. Overview ........................................................2
   2. Implementation Experience .......................................2
      2.1. Implementation Differences .................................2
   3. MIB Reference ...................................................3
   4. Authentication Mechanisms .......................................3
   5. List of Implementations .........................................3
   6. Test Scenarios ..................................................3
   7. Operational Experience ..........................................4
   8. Security Considerations .........................................4
   9. Normative References ............................................4
   10. Informative References .........................................4
   11. Acknowledgments ................................................5

1. 概要…2 2. 実装経験…2 2.1. 実装差…2 3. MIB参照…3 4. 認証メカニズム…3 5. 実装のリスト…3 6. シナリオをテストしてください…3 7. 操作上の経験…4 8. セキュリティ問題…4 9. 標準の参照…4 10. 有益な参照…4 11. 承認…5

Lindem                       Informational                      [Page 1]

RFC 4167      Graceful OSPF Restart Implementation Report   October 2005

OSPF再開実装レポート2005年10月に優雅なLindem情報[1ページ]のRFC4167

1.  Overview

1. 概要

   Today, many Internet routers implement a separation of control and
   forwarding functions.  Certain processors are dedicated to control
   and management tasks such as OSPF routing, while other processors
   perform the data forwarding tasks.  This separation creates the
   possibility of maintaining a router's data forwarding capability
   while the router's control software is restarted/reloaded.  For the
   OSPF protocol [OSPF], the protocol mechanisms necessary to accomplish
   this are described in Graceful OSPF Restart [GRACE].

今日、多くのインターネットルータがコントロールと推進機能の分離を実装します。 あるプロセッサはOSPFルーティングなどのコントロールと管理タスクに捧げられます、他のプロセッサはタスクを転送しながら、データを実行しますが。 この分離はルータの制御ソフトウェアが再開されるか、または再ロードされている間、能力を進めながらルータのデータを保守する可能性を作成します。 OSPFプロトコル[OSPF]において、これを達成するのに必要なプロトコルメカニズムはGraceful OSPF Restart[グレース]で説明されます。

   This document satisfies the RFC 1264 [CRITERIA] requirement for a
   report on implementation experience for Graceful OSPF Restart.
   Section 2 of this document contains the results of an implementation
   survey.  It also documents implementation differences between the
   vendors responding to the survey.  Section 3 contains a MIB
   reference.  Section 4 provide an authentication reference.  Section 5
   simply refers to the implementations listed in section 2.  Section 6
   includes a minimal set of test scenarios.  Finally, section 7
   includes a disclaimer with respect to operational experience.

このドキュメントはGraceful OSPF Restartのための実装経験に関するレポートのためのRFC1264[CRITERIA]要件を満たします。 このドキュメントのセクション2は実装調査の結果を含みます。 また、それは調査に応じるベンダーの実装差を記録します。 セクション3はMIB参照を含みます。 セクション4は認証参照を提供します。 セクション5は単にセクション2で記載された実装について言及します。 セクション6は1人の極小集合のテストシナリオを含めます。 最終的に、セクション7は運用経験に関して注意書きを含んでいます。

2.  Implementation Experience

2. 実装経験

   Eleven vendors have implemented graceful OSPF and have completed the
   implementation survey.  These include Redback, Juniper, Motorola
   Computer Group (formerly Netplane Systems), Mahi Networks, Nexthop
   technologies, Force10 Networks, Procket, Alcatel, Laurel Networks,
   DCL (Data Connection Limited), and Ericsson.  All have implemented
   restart from the perspective of both a restarting and helper router.
   All but one vendor implemented both planned and unplanned restart.
   All implementations are original.  Seven successfully tested
   interoperability with Juniper.  Juniper successfully tested
   interoperability with Force10 Networks.  One vendor tested with John
   Moy's GNU Public License implementation [OSPFD].  Two vendors had not
   tested interoperability at the time of the survey.

11のベンダーが、優雅なOSPFを実装して、実装調査を終了しました。 これらはRedback、Juniper、モトローラコンピュータGroup(以前Netplane Systems)、マヒ川Networks、Nexthop技術、Force10 Networks、Procket、アルカテル、ローレルNetworks、DCL(データConnection株式会社)、およびエリクソンを含んでいます。 すべてが、両方の見解からの再開が再開とアシスタントルータであると実装しました。 計画されていて、かつ無計画な状態で実装された1つのベンダー以外のすべてが再開します。 すべての実装がオリジナルです。 7はJuniperと共に相互運用性を首尾よくテストしました。 杜松はForce10 Networksと共に相互運用性を首尾よくテストしました。 1つのベンダーがジョンMoyのGNU Public License実装[OSPFD]でテストされました。 2つのベンダーは調査時点で、相互運用性をテストしていませんでした。

2.1.  Implementation Differences

2.1. 実装差

   The first difference was whether strict LSA checking was implemented
   and, if so, whether it was configurable.  In the context of graceful
   OSPF restart, strict LSA checking indicates whether a changed LSA
   will result in the termination of graceful restart by a helping
   router.  Four vendors made it configurable (three defaulted it to
   enabled and one to disabled), another made it a compile option
   (shipping with strict LSA checking disabled), another didn't
   implement it at all, and five implemented strict LSA checking with no
   configuration option to disable it.

最初の違いは厳しいLSAの照合が実装されたかどうかと、そうだとすれば、それが構成可能であったかどうかということでした。 優雅なOSPFの文脈では、再開してください、と変えられたLSAが助けているルータで優雅な再開の終了をもたらすか否かに関係なく、厳しいLSAの照合は示します。 別のものはそれをaにしました。そして、4つのベンダーがそれを構成可能にした、(3がデフォルトとした、それ、可能にされる、身体障害者への1)、オプション(厳しいLSAが身体障害者をチェックしていて、出荷する)をコンパイルしてください、そして、別のものはそれを全く実装しないで、5はそれを無効にするために設定オプションなしでチェックする厳しいLSAを実装しました。

Lindem                       Informational                      [Page 2]

RFC 4167      Graceful OSPF Restart Implementation Report   October 2005

OSPF再開実装レポート2005年10月に優雅なLindem情報[2ページ]のRFC4167

   The second was whether a received grace LSA would be taken to apply
   only to the adjacency on which it was received or to all adjacencies
   with the restarting router.  This is a rather subtle difference since
   it only applies to helping and restarting routers with more than one
   full adjacency at the time of restart.  Eight vendors implemented the
   option of the received grace LSA only applying to the adjacency on
   which it was received.  Three vendors applied the grace LSA to all
   adjacencies with the grace LSA originator (i.e., the restarting
   router).

2番目は再開ルータでそれが受け取られた隣接番組、または、すべての隣接番組だけに適用するために容認された優雅LSAを取るだろうかどうかということでした。 それが再開時点で1つ以上の完全な隣接番組でルータを助けて、再開するのに適用されるだけであるので、これはかなり微妙な違いです。 8つのベンダーが容認された優雅LSAがそれが受け取られた隣接番組に適用するだけのオプションを実装しました。 3つのベンダーが優雅LSA創始者(すなわち、再開ルータ)と共に端麗LSAをすべての隣接番組に適用しました。

   The final difference was in whether additional extensions were
   implemented to accommodate other features such as protocol
   redistribution or interaction with MPLS VPNs [VPN].  Five vendors
   implemented extensions and six did not.  It should be noted that such
   extensions are beyond the scope of Graceful OSPF Restart [GRACE].

最終的な違いが追加拡大がMPLS VPNs[VPN]とのプロトコル再分配か相互作用などの他の特徴を収容するために実装されたかどうかにありました。 拡大と6であると実装された5つのベンダーはそうしませんでした。 そのような拡大がGraceful OSPF Restart[グレース]の範囲を超えていることに注意されるべきです。

3.  MIB Reference

3. MIB参照

   MIB objects for the Graceful OSPF Restart have been added to the OSPF
   Version 2 Management Information Base [OSPFMIB].  Additions include:

Graceful OSPF RestartのためのMIBオブジェクトはOSPFバージョン2Management Information基地[OSPFMIB]に加えられます。 追加は:

   -  Objects ospfRestartSupport, ospfRestartInterval, ospfRestartAge,
      ospfRestartExitReason, and ospfRestartStrictLsaChecking to
      ospfGeneralGroup.

- ospfGeneralGroupへのオブジェクトのospfRestartSupport、ospfRestartInterval、ospfRestartAge、ospfRestartExitReason、およびospfRestartStrictLsaChecking。

   -  Objects ospfNbrRestartHelperStatus, ospfNbrRestartHelperAge, and
      ospfNbrRestartHelperExitReason to ospfNbrEntry.

- ospfNbrEntryへのオブジェクトospfNbrRestartHelperStatus、ospfNbrRestartHelperAge、およびospfNbrRestartHelperExitReason。

   -  Objects ospfVirtNbrRestartHelperStatus,
      ospfVirtNbrRestartHelperAge, and
      ospfVirtNbrRestartHelperExitReason to ospfVirtNbrEntry.

- ospfVirtNbrEntryへのオブジェクトospfVirtNbrRestartHelperStatus、ospfVirtNbrRestartHelperAge、およびospfVirtNbrRestartHelperExitReason。

4.  Authentication Mechanisms

4. 認証機構

   The authentication mechanisms are the same as those implemented by
   the base OSPF protocol [OSPF].

認証機構はものが、ベースのそばでOSPFがプロトコル[OSPF]であると実装したのと同じです。

5.  List of Implementations

5. 実装のリスト

   Refer to section 2.

セクション2を参照してください。

6.  Test Scenarios

6. テストシナリオ

   A router implementing graceful restart should test, at a minimum, the
   following scenarios as both a restarting and helping router.  For all
   scenarios, monitoring data plane traffic may be used to ensure that
   the restart is non-disruptive:

優雅な再開を実装するルータは再開していて助けているルータとして最小限で以下のシナリオをテストするべきです。 すべてのシナリオにおいて、モニターしているデータ空輸は再開が確実に非破壊的になるようにするのに使用されるかもしれません:

Lindem                       Informational                      [Page 3]

RFC 4167      Graceful OSPF Restart Implementation Report   October 2005

OSPF再開実装レポート2005年10月に優雅なLindem情報[3ページ]のRFC4167

   1. Operation over a broadcast network.

1. 放送網の上の操作。

   2. Operation over a P2P network.

2. P2Pネットワークの上の操作。

   3. Operation over a virtual link.

3. 仮想のリンクの上の操作。

   4. Operation using OSPF MD5 authentication.

4. OSPF MD5認証を使用する操作。

   5. Early graceful restart termination when an LSA inconsistency is
      detected.

5. LSA矛盾であるときに、早めの優雅な再開終了は検出されます。

   6. Early graceful restart termination when a flooded LSA changes (if
      implemented).

6. 水につかっているLSAであるときに、早めの優雅な再開終了は変化します(実装されるなら)。

7.  Operational Experience

7. 運用経験

   Since OSPF graceful restart is configurable, it is difficult to gage
   operational experience at this juncture.  However, multiple service
   providers have tested and evaluated it.

OSPFの優雅な再開が構成可能であるので、この際運用経験を抵当に入れるのは難しいです。 しかしながら、複数のサービスプロバイダーが、それをテストして、評価しました。

8.  Security Considerations

8. セキュリティ問題

   This document does not discuss implementation and interoperability
   aspects of the security mechanisms in great detail, as no new
   security mechanisms are introduced with Graceful OSPF Restart.
   Security considerations for the OSPF protocol are included in RFC
   2328 [OSPF].  Security considerations for Graceful OSPF Restart are
   included in [GRACE].

このドキュメントは丹念にセキュリティー対策の実装と相互運用性局面について議論しません、どんな新しいセキュリティー対策もGraceful OSPF Restartと共に紹介されないとき。 OSPFプロトコルのためのセキュリティ問題はRFC2328[OSPF]に含まれています。 Graceful OSPF Restartのためのセキュリティ問題は[グレース]に含まれています。

9.  Normative References

9. 引用規格

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

[OSPF]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。

   [GRACE]     Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful
               OSPF Restart", RFC 3623, November 2003.

[優雅] MoyとJ.とPillay-Esnault、P.とA.Lindem、「優雅なOSPFは再開する」RFC3623、2003年11月。

   [CRITERIA]  Hinden, R., "Internet Engineering Task Force Internet
               Routing Protocol Standardization Criteria", RFC 1264,
               October 1991.

[評価基準]Hinden、R.、「インターネット・エンジニアリング・タスク・フォースインターネットルーティング・プロトコル標準化評価基準」、RFC1264、1991年10月。

10.  Informative References

10. 有益な参照

   [VPN]       Rosen, E. and Y Rekhter, "BGP/MPLS IP VPNs", Work in
               Progress, September 2003.

[VPN] 「BGP/MPLS IP VPNs」というローゼン、E.、およびY Rekhterは進歩、2003年9月に働いています。

   [OSPFD]     Moy, J., "OSPF Complete Implementation", Addison-Wesley,
               1991, ISBN 0-201-30966-1

[OSPFD] Moy、J.、「OSPFの完全な実装」、アディソン-ウエスリー、1991、ISBN0-201-30966-1

Lindem                       Informational                      [Page 4]

RFC 4167      Graceful OSPF Restart Implementation Report   October 2005

OSPF再開実装レポート2005年10月に優雅なLindem情報[4ページ]のRFC4167

   [OSPFMIB]   Joyal, D., et al, "OSPF Version 2 Management Information
               Base", Work in Progress, December 2003.

[OSPFMIB] Joyal、D.、他、「OSPFバージョン2管理情報ベース」、Progress、2003年12月のWork。

11.  Acknowledgments

11. 承認

   The author wishes to acknowledge the individuals/vendors who have
   completed the implementation survey.

作者は実装調査を終了した個人/ベンダーを承認したがっています。

      - Anand Oswal (Redback Networks)
      - Padma Pillay-Esnault (Juniper Networks)
      - Vishwas Manral (Motorola Computer Group, formerly Netplane
        System).
      - Sriganesh Kini (Mahi Networks)
      - Jason Chen (Force10 Networks)
      - Daniel Gryniewicz (NextHop Technologies)
      - Hasmit Grover (Procket Networks)
      - Pramoda Nallur (Alcatel)
      - Ardas Cilingiroglu (Laurel Networks)
      - Philip Crocker (Data Connection Limited)
      - Le-Vinh Hoang (Ericsson)

- アナンドOswal(20ドル紙幣Networks)--Padma Pillay-Esnault(杜松Networks)--Vishwas Manral(モトローラコンピュータGroup、以前Netplane System)。 - Sriganesh Kini(マヒ川ネットワーク)--ジェイソン・チェン(Force10ネットワーク)--ダニエルGryniewicz(NextHop技術)--Hasmitグローヴァー(Procketネットワーク)--Pramoda Nallur(アルカテル)--Ardas Cilingiroglu(ローレルネットワーク)--フィリップ・クロッカー(接続が制限したデータ)--Le-ビンホアン(エリクソン)

Author's Address

作者のアドレス

   Acee Lindem
   Cisco Systems, Inc
   7025 Kit Creek Road
   Research Triangle Park, NC  27709
   USA

Acee Lindemシスコシステムズ、Inc7025キットクリークRoadリサーチトライアングル公園、NC27709米国

   EMail: acee@cisco.com

メール: acee@cisco.com

Lindem                       Informational                      [Page 5]

RFC 4167      Graceful OSPF Restart Implementation Report   October 2005

OSPF再開実装レポート2005年10月に優雅なLindem情報[5ページ]のRFC4167

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金は現在、インターネット協会によって提供されます。

Lindem                       Informational                      [Page 6]

Lindem情報です。[6ページ]

一覧

 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 

スポンサーリンク

screen.colorDepth

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

上に戻る