[要約] RFC 3429は、MPLSの運用および保守（OAM）機能のための「OAM Alert Label」の割り当てに関するものです。このRFCの目的は、MPLSネットワークでのOAM機能の効果的な運用をサポートするために、OAM Alert Labelの使用方法と割り当て手順を定義することです。
Network Working Group H. Ohta
Request for Comments: 3429 NTT
Category: Informational November 2002
Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions
マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）の運用と保守（OAM）機能のための「OAMアラートラベル」の割り当て
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 (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
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.
このドキュメントでは、RFC 3032（MPLSラベルスタックエンコーディング）で定義されている予約済みラベル値の1つを、ユーザープレーンのマルチプロトコルラベルスイッチングアーキテクチャ（MPLS）OAM機能で使用される「運用と保守（OAM）アラートラベル」に割り当てます。 MPLS OAMパケットの識別用。
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).
このドキュメントでは、RFC 3032（MPLSラベルスタックエンコーディング[2]）で定義されている予約済みラベル値の1つを、説明されているようにMPLS OAMパケットの識別のためにユーザープレーンMPLS OAM機能で使用される「OAMアラートラベル」に割り当てます。 ITU-T勧告Y.1711 [1]（MPLS 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（運用および保守）機能は、ネットワーク事業者がネットワークを運用および保守するために必要なツールを提供します。 MPLS OAM機能は、下位層（SONET / SDHなど）が提供するOAM機能とは関係なく、MPLS層、より具体的には各MPLSレベルで必要です。 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.
- 欠陥と障害の検出：ユーザー情報の転送に影響を与える欠陥/障害は、継続的または定期的なチェックによって検出されます。その結果、メンテナンスイベント情報または適切なアラームが生成されます。
- 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.
- 欠陥/故障情報の報告：顧客に提供されるサービス品質（QoS）レベルを維持するために保守スタッフに適切な指示を提供するために、欠陥情報が他の管理エンティティ（たとえば、操作サポートシステム）に提供されます。
- 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.
- パフォーマンス監視：トランスポートの完全性を推定するために、ユーザー情報トランスポートのパフォーマンス（パケット損失、転送遅延、ビットエラーなど）が測定されます。
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.
ITU-T勧告Y.1711 [1]で説明されているユーザープレーンMPLS OAMメカニズムは、「OAMアラートラベル」と呼ばれる特別なラベルを使用して、OAMパケットを通常のユーザーパケットと区別します。 RFC 3032（MPLSラベルスタックエンコーディング[2]）で定義されている予約済みラベル値の1つが「OAMアラートラベル」に割り当てられています。この目的で、値14が使用されます。
ITU-T Study Group 13, Question 3/13 is progressing work on user-plane MPLS OAM and has produced the following documents:
ITU-T研究グループ13、質問3/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）ドラフト勧告Y.1720（MPLSネットワークの保護切り替え）[6]は、2002年11月の最終コールで、Y.1711のOAMメカニズムに依存しています。
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勧告Y.1711 [1]で定義されたMPLS OAM機能が、PHPが有効なMPLSネットワークにどのように適用されるかについて説明します。
The scope of ITU-T Recommendation Y.1711 includes application to both non-PHP and PHP cases as quoted below [1].
ITU-T勧告Y.1711の範囲には、以下に引用されているように、非PHPとPHPの両方のケースへの適用が含まれています[1]。
"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範囲この推奨事項は、推奨事項Y.1710に記載されている要件と原則に従って、MPLSネットワークのユーザープレーンOAM（操作と保守）機能のメカニズムを提供します。この推奨事項で指定されているOAM関数は、非PHPとPHPの両方に適用できますこの勧告の現在のバージョンは、主にポイントツーポイントおよびマルチポイントツーポイントの明示的にルーティングされるLSP（ER-LSP）をサポートするように設計されています。
There are two cases where PHP is used:
PHPが使用されるケースは2つあります。
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つのルックアップを実行できません。したがって、RFC 3032 [2]で定義されているように、MPLS予約ラベル3（暗黙のnullラベル）を使用して、最後から2番目のノードに（スワップするのではなく）トップラベルをポップするように要求します。
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ラベルルックアップと処理機能がなく、ラベル付きパケットを認識しません。このノードは、RFC 3032 [2]で定義されているMPLS予約済みラベル3（暗黙のnullラベル）を使用して、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勧告Y.1711 [1]で定義されているMPLS OAM機能は、ケース1にのみ適用できます。次のサブセクションでは、ケース1のノードの動作について説明します。ケース2のアプリケーションには、さらに検討が必要です。また、キャリアシナリオをサポートするキャリアへの適用は、今後の検討課題です。
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が有効である場合、最後から2番目のLSRはトップラベルをポップし、OAMパケットを（OAMラベルとOAMペイロードをそのままに）究極のLSRに転送します[5]。
- 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 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]).
-最上位のLSRがMPLS OAMをサポートしている場合、元の最上位ラベルが最後から2番目のLSRによって削除されているため、最上位にOAMラベルが付いた受信パケットはOAMパケットであると認識されます。また、受信したMPLS OAMパケットのTTSI（Trail Termination Source Identifier）値からMPLS OAMパケットを発信した入力LSRも認識します。 TTSIは、MPLS OAMパケットに含まれる入力LSRの一意の識別子です（ITU-T勧告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パケットはRFC 3031 [5]のセクション3.18に従って破棄されます。
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は、14のMPLSラベル値の使用を「OAMアラートラベル」として予約しています。詳細については、セクション3を参照してください。
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勧告Y.1711 [1]で定義されている接続検証（CV）機能は、誤接続を検出できるため、顧客のトラフィックが他の顧客にさらされるのを防ぐことができます。
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-SierraのShahram Davari、British TelecomのNeil Harrison、Monique Morrow、Thomas D. Nadeau、Cisco SystemsのHari RakotorantoおよびChip Sharp、Nortel NetworksのKhalid AhmadとDavid Allan、Azad-のMina Azadに感謝します。 Mohtajコンサルティングの貴重な貢献と議論。
[1] ITU-T Recommendation Y.1711, "OAM mechanism for MPLS networks", November 2002.
[1] ITU-T勧告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。、フェドルコウ、G。、レクター、Y。、ファリナッチャ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月。
[3] ITU-T recommendation Y.1710, "Requirements for OAM functionality for MPLS networks" July 2001.
[3] ITU-T勧告Y.1710、「MPLSネットワークのOAM機能の要件」2001年7月。
[4] ITU-T Corrigendum 1 to Recommendation Y.1710, November 2002.
[4] ITU-T勧告Y.1710改訂1、2002年11月。
[5] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[5] ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[6] ITU-T Draft Recommendation Y.1720, "Protection switching for MPLS networks", under last call as of November 2002.
[6] ITU-Tドラフト推奨事項Y.1720、「MPLSネットワークの保護スイッチング」、2002年11月現在の最終コール。
Hiroshi OHTA NTT 3-9-11 Midori-Cho, Musashino-Shi Tokyo 180-8585 Japan
ひろし おＨた んっｔ ３ー９ー１１ みどりーちょ、 むさしのーし ときょ １８０ー８５８５ じゃぱん
Phone: +81 422 59 3617
Fax: +81 422 59 3787
EMail: ohta.hiroshi@lab.ntt.co.jp
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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機能への資金提供は、現在Internet Societyから提供されています。