RFC3429 日本語訳

Network Working Group                                            H. Ohta
Request for Comments: 3429                                           NTT
Category: Informational                                    November 2002

コメントを求めるワーキンググループH.太田の要求をネットワークでつないでください: 3429年のNTTカテゴリ: 情報の2002年11月

                Assignment of the 'OAM Alert Label' for
           Multiprotocol Label Switching Architecture (MPLS)
              Operation and Maintenance (OAM) Functions

Multiprotocolラベル切り換え構造(MPLS)維持管理(OAM)機能のための'OAMの警告ラベル'の課題

Status of this Memo

この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 (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document describes the assignment of one of the reserved label
   values defined in RFC 3032 (MPLS label stack encoding) to the
   'Operation and Maintenance (OAM) Alert Label' that is used by user-
   plane Multiprotocol Label Switching Architecture (MPLS) OAM functions
   for identification of MPLS OAM packets.

このドキュメントはRFC3032(MPLSラベルスタックコード化)でMPLS OAMパケットの識別にユーザ飛行機Multiprotocol Label Switching Architecture(MPLS)OAM機能によって使用される'操作とMaintenance(OAM)の警告Label'と定義された予約されたラベル値の1つの課題について説明します。

1. Introduction

1. 序論

   This document describes the assignment of one of the reserved label
   values defined in RFC 3032 (MPLS label stack encoding [2]) to the
   'OAM Alert Label' that is used by user-plane MPLS OAM functions for
   identification of MPLS OAM packets as described in the ITU-T
   Recommendation Y.1711 [1] (on MPLS OAM functions).

このドキュメントはRFC3032で定義された予約されたラベル値の1つの課題について説明します。(MPLSは'OAM Alert Label'に[2])をコード化するMPLS OAMパケットの識別にITU-Tで説明されるようにユーザ飛行機MPLS OAM機能によって使用されるスタックをRecommendation Y.1711[1](MPLS OAM機能の)とラベルします。

2. OAM functions

2. OAM機能

   MPLS OAM (Operation and Maintenance) functions provide necessary
   tools for network operators to operate and maintain the networks.
   MPLS OAM functionality is required at the MPLS layer, and more
   specifically at each MPLS level, independent of OAM functionality
   provided by the lower layers (SONET/SDH, etc.).  The objectives of
   the OAM functions include the following:

MPLS OAM(操作とMaintenance)機能はネットワーク・オペレータがネットワークを運用して、維持する必要なツールを提供します。 MPLS OAMの機能性がMPLS層においてそれぞれのMPLSレベルで、より明確に必要です、下層(Sonet/SDHなど)で提供されたOAMの機能性の如何にかかわらず。 OAM機能の目的は以下を含んでいます:

   -  Defect and failure detection: Defect/failures affecting the
      transport of user information are detected by continuous or
      periodic checking.  As a result, maintenance event information or
      appropriate alarms will be produced.

- 欠陥と失敗検出: ユーザー情報の輸送に影響する欠陥/失敗が連続したか周期的な照合で検出されます。 その結果、維持イベント情報か適切なアラームが作り出されるでしょう。

Ohta                         Informational                      [Page 1]

RFC 3429           OAM Alert Label for OAM Functions       November 2002

太田情報[1ページ]のRFC3429OAMは2002年11月にOAM機能のためにラベルを警告します。

   -  Reporting the defect/failure information: Defect information is
      given to other management entities (e.g., Operation Support
      System) in order to provide the appropriate indications to the
      maintenance staff for maintaining the Quality of Service (QoS)
      level offered to customers.

- 欠陥/失敗情報を報告します: 顧客に提供されたService(QoS)レベルのQualityを維持するために適切な指摘を整備員に提供するために他の経営体(例えば、Operation Support System)に欠陥情報を与えます。

   -  Defect/failure localization: Determination by internal or external
      test systems of a failed entity is performed if defect information
      is insufficient.

- 欠陥/失敗ローカライズ: 欠陥情報が不十分であるなら、失敗した実体の内部の、または、外部のテスト・システムによる決断は実行されます。

   -  Performance monitoring: Performance (packet losses, transfer
      delay, bit errors, etc.) of the user information transport is
      measured in order to estimate the transport integrity.

- パフォーマンスモニター: ユーザー情報輸送のパフォーマンス(パケット損失(転送遅れ)は誤りなどに噛み付いた)は、輸送保全を見積もるために測定されます。

3. OAM Packet Identification

3. OAMパケット識別

   The user-plane MPLS OAM mechanisms as described in the ITU-T
   Recommendation Y.1711 [1] uses a special label called 'OAM Alert
   Label' to differentiate OAM packets from the normal user packets.
   One of the reserved label values defined in RFC 3032 (MPLS label
   stack encoding [2]) is assigned to 'OAM Alert Label'.  A value of 14
   is used for this purpose.

Recommendation Y.1711[1]が微分するのに'OAM Alert Label'と呼ばれる特別なラベルを使用するITU-T OAMパケットで正常なユーザパケットから説明されるユーザ飛行機MPLS OAMメカニズム。 予約されたラベル値のひとりはRFCで3032を定義しました。(MPLSラベルスタックコード化[2])は'OAM Alert Label'に割り当てられます。 14の値はこのために使用されます。

4. MPLS OAM work in ITU-T SG13

4. MPLS OAMはITU-T SG13で働いています。

   ITU-T Study Group 13, Question 3/13 is progressing work on user-plane
   MPLS OAM and has produced the following documents:

ITU-T Study Group13、Question3/13はユーザ飛行機MPLS OAMへの作業を進行していて、以下のドキュメントを製作しました:

   (1) Recommendation Y.1710 (Requirements for OAM functionality for
       MPLS networks) [3]

(1) 推薦Y.1710(MPLSネットワークのためのOAMの機能性のための要件)[3]

   (2) Corrigendum 1 to Recommendation Y.1710 [4]

(2) 推薦Y.1710への間違い1[4]

   (3) Recommendation Y.1711 (OAM mechanisms for MPLS networks) [1]

(3) 推薦Y.1711(MPLSネットワークのためのOAMメカニズム)[1]

   (4) Draft Recommendation Y.1720 (Protection switching for MPLS
       networks) [6] relies on OAM mechanisms in Y.1711, under last call
       as of Nov. 2002.

(4) 草稿Recommendation Y.1720(MPLSネットワークのために切り替わる保護)[6]はY.1711のOAMメカニズムを当てにします、2002年11月付けで最後の呼び出しで。

5. Considerations on penultimate hop popping (PHP)

5. 終わりから二番目のホップの飛び出しでの問題(PHP)

   In response to concerns raised during IETF meetings and in related
   discussions, this section provides an explanation on how MPLS OAM
   functions defined in ITU-T Recommendation Y.1711 [1] are applied to
   MPLS networks where PHP is in effect.

IETFミーティングと関連する議論で高められた関心に対応して、このセクションはITU-T Recommendation Y.1711[1]で定義されたMPLS OAM機能がどうPHPが有効であるMPLSネットワークに適用されるかに関する説明を提供します。

Ohta                         Informational                      [Page 2]

RFC 3429           OAM Alert Label for OAM Functions       November 2002

太田情報[2ページ]のRFC3429OAMは2002年11月にOAM機能のためにラベルを警告します。

5.1 Scope of ITU-T Recommendation Y.1711

5.1 ITU-T推薦Y.1711の範囲

   The scope of ITU-T Recommendation Y.1711 includes application to both
   non-PHP and PHP cases as quoted below [1].

ITU-T Recommendation Y.1711の範囲は[1]の下で引用されるように非PHPとPHPケースの両方にアプリケーションを含めます。

   "1 Scope
   This Recommendation provides mechanisms for user-plane OAM (Operation
   and Maintenance) functionality in MPLS networks according to the
   requirements and principles given in Recommendation Y.1710.  OAM
   functions specified in this Recommendation can be applied to both
   non-PHP and PHP cases unless otherwise stated.  The current version
   of this recommendation is designed primarily to support
   point-to-point and multipoint-to-point explicit routed LSPs
   (ER-LSPs)."

「1 Recommendation Y.1710で与えられた要件と原則に応じて、範囲This RecommendationはMPLSネットワークでユーザ飛行機OAM(操作とMaintenance)の機能性にメカニズムを提供します。」 別の方法で述べられない場合、このRecommendationで指定されたOAM機能は非PHPとPHPケースの両方に適用できます。 「この推薦の最新版は主としてポイントツーポイントと多点からポイントへの明白な発送されたLSPs(ER-LSPs)を支持するように設計されています。」

5.2 Applicability of MPLS OAM to PHP

5.2 PHPへのMPLS OAMの適用性

   There are two cases where PHP is used:

2つのケースがPHPが使用されているところにあります:

   Case 1: The ultimate node is an MPLS LSR, and implements both MPLS
   control-plane and data-plane, but is not able to perform 2 lookups at
   line rate.  So it asks the penultimate node to pop the top label
   (rather than swapping it), using the MPLS reserved label 3 (implicit
   null label) as per defined in RFC 3032 [2].

ケース1: 究極のノードは、MPLS LSRであり、MPLS制御飛行機とデータ飛行機の両方を実行しますが、ライン料率で2つのルックアップを実行できません。 それで、トップラベル(それを交換するよりむしろ)を飛び出させるように終わりから二番目のノードに頼みます、RFC3032[2]で定義にされるに従ってMPLSの予約されたラベル3(内在しているヌルラベル)を使用して。

   Case 2: The ultimate node has no MPLS label look up and processing
   capability and does not recognize labeled packets.  This node asks
   for PHP, using the MPLS reserved label 3 (implicit null label) as
   defined in RFC 3032 [2].

ケース2: 究極のノードは、どんなMPLSラベルも能力を見せて、処理しないのを持って、ラベルされたパケットを認めません。 RFC3032[2]で定義されるようにMPLSの予約されたラベル3(内在しているヌルラベル)を使用して、このノードはPHPを求めます。

   Currently, MPLS OAM functions defined in ITU-T Recommendation Y.1711
   [1] can only be applied to Case 1.  The next subsection describes the
   node behavior in Case 1.  Application for Case 2 needs further study.
   Also, application to carrier supporting carrier scenarios is for
   future study.

現在、ITU-T Recommendation Y.1711[1]で定義されたMPLS OAM機能はCase1に適用できるだけです。 次の小区分はCase1でノードの振舞いについて説明します。 Case2のアプリケーションはさらなる研究を必要とします。 また、今後の研究にはキャリヤーシナリオを支持しているキャリヤーへの利用があります。

5.3 Node behavior when OAM functions are activated

5.3 OAM機能が活性であることのノードの振舞い

   Where the ultimate LSR is an MPLS LSR and PHP is in effect, the
   penultimate LSR pops the top label and forwards the OAM packet (with
   the OAM label and the OAM payload intact) to the ultimate LSR [5].

究極のLSRがMPLS LSRであり、PHPが有効であるところでは、終わりから二番目のLSRは究極のLSR[5]にトップラベルを飛び出させて、OAMパケットを送ります(OAMラベルとOAMペイロードが完全な状態で)。

   -  If the ultimate LSR supports MPLS OAM, it understands that a
      received packet with an OAM label on top is an OAM packet, since
      the original top label has been removed by the penultimate LSR.
      It also knows the ingress LSR that originated the MPLS OAM packet
      from the TTSI (Trail Termination Source Identifier) value of the

- 究極のLSRがMPLS OAMを支持するなら、OAMラベルが先端にある容認されたパケットがOAMパケットであることは分かります、オリジナルのトップラベルが終わりから二番目のLSRによって取り除かれたので。 また、それはTTSI(道のTermination Source Identifier)値からMPLS OAMパケットを溯源したイングレスLSRを知っています。

Ohta                         Informational                      [Page 3]

RFC 3429           OAM Alert Label for OAM Functions       November 2002

太田情報[3ページ]のRFC3429OAMは2002年11月にOAM機能のためにラベルを警告します。

      received MPLS OAM packet.  TTSI is a unique identifier for ingress
      LSR that is contained in MPLS OAM packets (see ITU-T
      Recommendation Y.1711 [1]).

容認されたMPLS OAMパケット。 TTSIはMPLS OAMパケットに含まれているイングレスLSRに、ユニークな識別子です。(ITU-T Recommendation Y.1711[1])を見てください。

   -  If the ultimate LSR does not support MPLS OAM, the OAM packet is
      discarded as per section 3.18 of RFC 3031 [5].

- 究極のLSRがMPLS OAMを支持しないなら、OAMパケットはRFC3031[5]のセクション3.18に従って捨てられます。

6. IANA Considerations

6. IANA問題

   The IANA has reserved the use of the MPLS label value of 14 as the
   'OAM Alert Label'.  See section 3 for additional information.

IANAは'OAM Alert Label'として14のMPLSラベル価値の使用を控えました。 追加情報に関してセクション3を見てください。

7. Security Considerations

7. セキュリティ問題

   This document does not raise any security issues that are not already
   present in either the MPLS architecture or in the architecture of the
   network layer protocol contained within the encapsulation.

このドキュメントは少しのMPLS構造かカプセル化の中に含まれたネットワーク層プロトコルの構造で既に存在していない安全保障問題も提起しません。

   OAM functions could enhance the security of MPLS networks.  For
   example, Connectivity Verification (CV) function defined in ITU-T
   Recommendation Y.1711 [1] can detect mis-connections, and therefore
   can prevent customers' traffic being exposed to other customers.

OAM機能はMPLSネットワークのセキュリティを高めるかもしれません。 例えば、ITU-T Recommendation Y.1711[1]で定義されたConnectivity Verification(CV)機能は、付け違いを検出できて、したがって、顧客の交通が他の顧客に暴露されるのを防ぐことができます。

8. Acknowledgements

8. 承認

   The author wishes to thank Shahram Davari with PMC-Sierra, Neil
   Harrison with British Telecom, Monique Morrow, Thomas D. Nadeau, Hari
   Rakotoranto and Chip Sharp with Cisco Systems, Khalid Ahmad and David
   Allan with Nortel Networks, and Mina Azad with Azad-Mohtaj Consulting
   for their valuable contributions and discussions.

作者は彼らの有価約因と議論についてPMC-連峰があるShahram Davari、ブリティッシュ・テレコムをもっているニール・ハリソン、モニーク・モロー、トーマス・D.ナドー、シスコシステムズがあるハーリRakotorantoとChipシャープ、ノーテルNetworksをもっているハリド・アフマドとデヴィッド・アラン、およびAzad-Mohtaj ConsultingとミーナAzadに感謝したがっています。

9. Normative References

9. 引用規格

   [1] ITU-T Recommendation Y.1711, "OAM mechanism for MPLS networks",
       November 2002.

[1] ITU-T Recommendation Y.1711、「MPLSネットワークのためのOAMメカニズム」、2002年11月。

   [2] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinaccia, D.,
       Li, T. and A. Conta, "MPLS label stack encoding", RFC 3032,
       January 2001.

[2] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、Farinaccia、D.、李、T.、およびA.コンタ、「MPLSはスタックコード化をラベルします」、RFC3032、2001年1月。

   [3] ITU-T recommendation Y.1710, "Requirements for OAM functionality
       for MPLS networks" July 2001.

「MPLSネットワークのためのOAMの機能性のための要件」2001年7月の[3]ITU-T推薦Y.1710。

   [4] ITU-T Corrigendum 1 to Recommendation Y.1710, November 2002.

2002年11月の推薦Y.1710への[4]ITU-T間違い1。

   [5] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
       Switching Architecture", RFC 3031, January 2001.

[5] ローゼンとE.とViswanathanとA.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。

Ohta                         Informational                      [Page 4]

RFC 3429           OAM Alert Label for OAM Functions       November 2002

太田情報[4ページ]のRFC3429OAMは2002年11月にOAM機能のためにラベルを警告します。

10. Informative Reference

10. 有益な参照

   [6] ITU-T Draft Recommendation Y.1720, "Protection switching for MPLS
       networks", under last call as of November 2002.

[6] ITU-T Draft Recommendation Y.1720、最終における「MPLSネットワークのために切り替わる保護」を2002年11月現在、呼びます。

11. Author's Address

11. 作者のアドレス

   Hiroshi OHTA
   NTT
   3-9-11 Midori-Cho, Musashino-Shi
   Tokyo 180-8585 Japan

3 9-11テロのHiroshi太田NTT美土里町、武蔵野市日本東京180-8585

   Phone: +81 422 59 3617
   Fax:   +81 422 59 3787
   EMail: ohta.hiroshi@lab.ntt.co.jp

以下に電話をしてください。 +81 422 59 3617、Fax: +81 422 59 3787はメールされます: ohta.hiroshi@lab.ntt.co.jp

Ohta                         Informational                      [Page 5]

RFC 3429           OAM Alert Label for OAM Functions       November 2002

太田情報[5ページ]のRFC3429OAMは2002年11月にOAM機能のためにラベルを警告します。

12.  Full Copyright Statement

12. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

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

Ohta                         Informational                      [Page 6]

太田Informationalです。[6ページ]