[要約] 要約：RFC 6670は、MPLS Transport Profile（MPLS-TP）の運用、管理、および保守（OAM）のための単一のソリューションを選択する理由について説明しています。目的：このRFCの目的は、MPLS-TPネットワークでのOAMの効果的な実装を支援し、複数のソリューションを選択する際の利点と課題を明確にすることです。
Internet Engineering Task Force (IETF) N. Sprecher
Request for Comments: 6670 Nokia Siemens Networks
Category: Informational KY. Hong
ISSN: 2070-1721 Cisco Systems
July 2012
The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)
MPLSトランスポートプロファイル（MPLS-TP）の運用、管理、および保守（OAM）の単一のソリューションを選択する理由
Abstract
概要
The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work on MPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.
MPLSトランスポートプロファイル（MPLS-TP）は、トランスポートネットワークの展開で使用するMPLSテクノロジのプロファイルです。 MPLS-TPの作業により、MPLSテクノロジーが拡張され、あらゆるMPLS展開で使用できる追加のアーキテクチャ要素と機能が追加されました。 MPLS-TPは、拡張MPLSツールセットから選択された機能と機能のセットであり、パケット転送ネットワークのオペレーターのニーズと要件を満たすために一貫した方法で適用されます。
During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment.
プロファイルの開発プロセス中に、使用可能なツールが要件を確実に満たすように、MPLSツールセットへの追加が行われました。これらの追加はMPLS-TPによって動機付けられましたが、より広いMPLSツールセットの一部を形成しているため、これらのいずれもMPLS展開で使用できます。
One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization.
1つの主要な追加セットにより、運用、管理、および保守（OAM）のサポートが強化されます。これにより、トランスポートネットワークで必要なレベルまでの障害管理とパフォーマンス監視が可能になります。 MPLS-TP OAMの要件に対処するために多くのソリューションとプロトコル拡張が提案されており、このドキュメントでは、標準化のために単一の一貫したソリューションセットを選択する理由を説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6670.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6670で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Background .................................................5
1.2. The Development of a Parallel MPLS-TP OAM Solution .........7
2. Terminology .....................................................8
2.1. Acronyms ...................................................8
3. Motivations for a Single OAM Solution in MPLS-TP ................9
3.1. MPLS-TP Is an MPLS Technology ..............................9
3.2. MPLS-TP Is a Convergence Technology ........................9
3.3. There Is an End-to-End Requirement for OAM ................10
3.4. The Complexity Sausage ....................................10
3.5. Interworking Is Expensive and Has Deployment Issues .......11
3.6. Selection of a Single OAM Solution When There Is a
Choice ....................................................13
3.7. Migration Issues ..........................................14
4. Potential Models for Coexistence ...............................15
4.1. Protocol Incompatibility ..................................15
4.2. Inevitable Coexistence ....................................16
4.3. Models for Coexistence ....................................16
4.3.1. The Integrated Model ...............................17
4.3.2. The Island Model ...................................18
5. The Argument for Two Solutions .................................20
5.1. Progress of the IETF Solution .............................20
5.2. Commonality with Ethernet OAM .............................21
5.3. Different Application Scenarios ...........................21
5.4. Interaction between Solutions .............................22
5.5. Letting the Market Decide .................................23
6. Security Considerations ........................................24
7. Acknowledgments ................................................24
8. References .....................................................24
8.1. Normative References ......................................24
8.2. Informative References ....................................25
Appendix A. Examples of Interworking Issues in the Internet .......27
A.1. IS-IS/OSPF .................................................27
A.2. Time Division Multiplexing Pseudowires .....................28
A.3. Codecs .....................................................28
A.4. MPLS Signaling Protocols ...................................29
A.5. IPv4 and IPv6 ..............................................29
Appendix B. Other Examples of Interworking Issues .................30
B.1. SONET and SDH ..............................................30
B.2. IEEE 802.16d and IEEE 802.16e ..............................32
B.3. CDMA and GSM ...............................................32
The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. Note that "transport" in this document is used in the context of transport networks as discussed in Section 1.3 of [RFC5654] and in [RFC5921]. The work on MPLS-TP has extended the MPLS toolset with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.
MPLSトランスポートプロファイル（MPLS-TP）は、トランスポートネットワークの展開で使用するためのMPLSテクノロジのプロファイルです。このドキュメントの「トランスポート」は、[RFC5654]のセクション1.3と[RFC5921]で説明されているトランスポートネットワークのコンテキストで使用されることに注意してください。 MPLS-TPの作業により、MPLSツールセットが拡張され、あらゆるMPLS展開で使用できる追加のアーキテクチャ要素と機能が追加されました。 MPLS-TPは、拡張MPLSツールセットから選択された機能と機能のセットであり、パケット転送ネットワークのオペレーターのニーズと要件を満たすために一貫した方法で適用されます。
Operations, Administration, and Maintenance (OAM) plays a significant role in carrier networks, providing methods for fault management and performance monitoring in both the transport and service layers, and enabling these layers to support services with guaranteed and strict Service Level Agreements (SLAs) while reducing their operational costs.
運用、管理、保守（OAM）はキャリアネットワークで重要な役割を果たし、トランスポート層とサービス層の両方で障害管理とパフォーマンス監視を行う方法を提供し、これらの層が保証された厳密なサービスレベルアグリーメント（SLA）でサービスをサポートできるようにします。運用コストを削減しながら。
OAM provides a comprehensive set of capabilities that operate in the data plane. Network-oriented mechanisms are used to monitor the network's infrastructure in order to enhance the network's general behavior and level of performance. Service-oriented mechanisms are used to monitor the services offered to end customers. Such mechanisms enable rapid response to a failure event and facilitate the verification of some SLA parameters. Fault management mechanisms are used for fault detection and localization as well as for diagnostics and notification. Performance management mechanisms enable monitoring of the quality of service with regard to key SLA criteria (e.g., jitter, latency, and packet loss).
OAMは、データプレーンで動作する包括的な機能セットを提供します。ネットワーク指向のメカニズムは、ネットワークの一般的な動作とパフォーマンスのレベルを向上させるために、ネットワークのインフラストラクチャを監視するために使用されます。サービス指向のメカニズムは、エンドカスタマーに提供されるサービスを監視するために使用されます。このようなメカニズムにより、障害イベントへの迅速な対応が可能になり、一部のSLAパラメーターの検証が容易になります。障害管理メカニズムは、障害の検出と位置特定、および診断と通知に使用されます。パフォーマンス管理メカニズムにより、主要なSLA基準（ジッター、遅延、パケット損失など）に関するサービス品質の監視が可能になります。
During the process of development of MPLS-TP, additions to the MPLS toolset have been made to ensure that the tools available meet the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset, such that any of them could be used in any MPLS deployment.
MPLS-TPの開発プロセス中に、MPLSツールセットへの追加が行われ、使用可能なツールが要件を確実に満たすようになりました。これらの追加はMPLS-TPによって動機付けられましたが、より広いMPLSツールセットの一部を形成しているため、これらはMPLS展開で使用できます。
One major set of additions provides enhanced support for OAM. Many solutions and protocol extensions have been proposed to address these OAM requirements. This document sets out the reasons for selecting a single, coherent set of OAM solutions for standardization.
1つの主要な追加セットにより、OAMのサポートが強化されます。これらのOAM要件に対処するために、多くのソリューションとプロトコル拡張が提案されています。このドキュメントでは、標準化のために単一の一貫したOAMソリューションを選択する理由を説明します。
The content of this document should be read in the context of [RFC1958]. In particular, Section 3.2 of [RFC1958] says:
このドキュメントの内容は、[RFC1958]のコンテキストで読む必要があります。特に、[RFC1958]のセクション3.2は次のように述べています。
If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements.
同じことを行う方法がいくつかある場合は、いずれかを選択します。以前の設計がインターネットのコンテキストなどで同じ問題を正常に解決した場合は、技術的な理由がない限り同じソリューションを選択してください。もちろん、この引数を使用して改善を拒否することなく、同じプロトコル機能の重複は可能な限り避けてください。
The ITU-T and the IETF jointly commissioned a Joint Working Team (JWT) to examine the feasibility of a collaborative solution to support OAM requirements for MPLS transport networks known as the MPLS Transport Profile (MPLS-TP). The JWT reported that it is possible to extend the MPLS technology to fully satisfy the requirements [RFC5317]. The investigation by the JWT laid the foundations for the work to extend MPLS, but a thorough technical analysis was subsequently carried out within the IETF with strong input from the ITU-T to ensure that the MPLS-TP OAM requirements provided by the ITU-T and the IETF would be met.
ITU-TとIETFは、共同作業チーム（JWT）に共同で委託して、MPLSトランスポートプロファイル（MPLS-TP）と呼ばれるMPLSトランスポートネットワークのOAM要件をサポートする協調ソリューションの実現可能性を調査しました。 JWTは、MPLSテクノロジーを拡張して要件を完全に満たすことが可能であることを報告しました[RFC5317]。 JWTによる調査は、MPLSを拡張する作業の基礎を築きましたが、その後、ITU-Tからの強力な入力により、IETF内で徹底的な技術分析が行われ、ITU-Tによって提供されるMPLS-TP OAM要件がそしてIETFは満たされるでしょう。
The report of the JWT [RFC5317] as accepted by the ITU-T was documented in [TD7] and was communicated to the IETF in a liaison statement [LS26]. In particular, the ITU-T stated that any extensions to MPLS technology will be progressed via the IETF standards process using the procedures defined in [RFC4929].
ITU-Tによって承認されたJWT [RFC5317]のレポートは[TD7]に文書化され、連絡声明[LS26]でIETFに通知されました。特に、ITU-Tは、MPLSテクノロジーへの拡張は、[RFC4929]で定義された手順を使用したIETF標準プロセスを介して進められると述べました。
[RFC5317] includes the analysis that "it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network". This provided a starting point for the work on MPLS-TP.
[RFC5317]には、「既存のMPLSアーキテクチャをトランスポートプロファイルの要件を満たすように拡張でき、LSP、PW、および深くネストされたネットワーク用の単一のOAMテクノロジーが可能であることが技術的に実現可能である」という分析が含まれています。 。これは、MPLS-TPの作業の開始点となりました。
[RFC5654] in general, and [RFC5860] in particular, define a set of requirements for OAM functionality in MPLS-TP that are applicable to MPLS-TP Label Switched Paths (LSPs), Pseudowires (PWs), and MPLS-TP links. These documents are the results of a joint effort by the ITU-T and the IETF to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to enable the deployment of a packet transport network that supports the capabilities and functionalities of a transport network as defined by the ITU-T. The OAM requirements are derived from those specified by the ITU-T in [Y.Sup4].
[RFC5654]全般、特に[RFC5860]は、MPLS-TPラベルスイッチドパス（LSP）、疑似配線（PW）、およびMPLS-TPリンクに適用可能なMPLS-TPのOAM機能の要件のセットを定義します。これらのドキュメントは、IETF MPLSおよび疑似配線エミュレーションエッジツーエッジ（PWE3）アーキテクチャ内にMPLSトランスポートプロファイルを含めて、サポートするパケットトランスポートネットワークの導入を可能にするためのITU-TとIETFによる共同作業の結果です。 ITU-Tで定義されているトランスポートネットワークの機能と機能。 OAM要件は、ITU-Tが[Y.Sup4]で指定したものから派生しています。
An analysis of the technical options for OAM solutions was carried out by a design team (the MEAD team) consisting of experts from both the ITU-T and the IETF. The team reached an agreement on the principles of the design and the direction for the development of an MPLS-TP OAM toolset. A report was subsequently submitted to the IETF MPLS working group at the Stockholm IETF meeting in July 2009 [DesignReport]. The guidelines drawn up by the design team have played an important role in the creation of a coherent MPLS-TP OAM solution.
OAMソリューションの技術オプションの分析は、ITU-TとIETFの両方の専門家で構成される設計チーム（MEADチーム）が実施しました。チームは、設計の原則とMPLS-TP OAMツールセットの開発の方向性について合意に達しました。その後、2009年7月のストックホルムIETF会議[DesignReport]で、IETF MPLSワーキンググループにレポートが提出されました。設計チームが作成したガイドラインは、首尾一貫したMPLS-TP OAMソリューションの作成に重要な役割を果たしてきました。
The MPLS working group has modularized the function of MPLS-TP OAM, allowing for separate and prioritized development of solutions. This has given rise to a number of documents each describing a different part of the solution toolset. At the time of this writing, the most important of these documents have completed development within the MPLS working group and are advancing through the IETF process toward publication as RFCs. These documents cover the following OAM features:
MPLSワーキンググループは、MPLS-TP OAMの機能をモジュール化し、個別の優先順位付けされたソリューションの開発を可能にしました。これにより、それぞれがソリューションツールセットの異なる部分を説明する多数のドキュメントが生まれました。この記事の執筆時点で、これらのドキュメントの最も重要なものは、MPLSワーキンググループ内での開発を完了しており、RFCとしての公開に向けてIETFプロセスを進めています。これらのドキュメントでは、次のOAM機能について説明しています。
o Continuity Check
o 導通チェック
o Connection Verification
o 接続検証
o On-Demand Connection Verification
o オンデマンド接続検証
o Route Tracing
o ルートトレース
o Remote Defect Indication
o リモート欠陥表示
o Packet Loss Measurement
o パケットロス測定
o Packet Delay Measurement
o パケット遅延測定
o Lock Instruction
o ロック命令
o Loopback Testing
o ループバックテスト
o Fault Management
o 障害管理
The standardization process within the IETF allows for the continued analysis of whether the OAM solutions under development meet the documented requirements, and facilitates the addition of new requirements if any are discovered. It is not the purpose of this document to analyze the correctness of the selection of specific OAM solutions. This document is intended to explain why it would be unwise to standardize multiple solutions for MPLS-TP OAM, and to show how the existence of multiple solutions would complicate MPLS-TP development and deployment, making networks more expensive to build, less stable, and more costly to operate.
IETF内の標準化プロセスにより、開発中のOAMソリューションが文書化された要件を満たしているかどうかの継続的な分析が可能になり、新しい要件が発見された場合にそれを簡単に追加できます。特定のOAMソリューションの選択の正しさを分析することは、このドキュメントの目的ではありません。このドキュメントは、MPLS-TP OAMの複数のソリューションを標準化することが賢明でない理由を説明し、複数のソリューションの存在がMPLS-TPの開発と展開を複雑にし、ネットワークの構築コストを高め、安定性を低下させることを示すことを目的としています。運用コストが高くなります。
It has been suggested that a second (i.e., different) OAM solution should also be developed and documented in an ITU-T Recommendation. Various arguments have been presented for this duplication of effort, including the following:
2番目の（つまり、異なる）OAMソリューションも開発し、ITU-T勧告に文書化する必要があることが示唆されています。この取り組みの重複については、次のようなさまざまな議論がなされています。
o Similarity to OAM encodings and mechanisms used in Ethernet.
o イーサネットで使用されるOAMエンコーディングとメカニズムとの類似性。
o The existence of two distinct MPLS-TP deployment environments: Packet Switched Networks (PSNs) and Packet Transport Networks (PTNs).
o パケット交換ネットワーク（PSN）とパケット転送ネットワーク（PTN）の2つの異なるMPLS-TP展開環境の存在。
o The need for similar operational experience in MPLS-TP networks and in pre-existing transport networks (especially Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) networks).
o MPLS-TPネットワークおよび既存のトランスポートネットワーク（特に、同期光ネットワーク/同期デジタル階層（SONET / SDH）ネットワーク）における同様の運用経験の必要性。
The first of these was discussed within the IETF's MPLS working group where precedence was given to adherence to the JWT's recommendation to select a solution that reused as far as possible pre-existing MPLS tools. Additionally, it was decided that consistency with encodings and mechanisms used in MPLS was of greater importance.
これらの最初のものはIETFのMPLSワーキンググループ内で議論され、可能な限り既存のMPLSツールを再利用するソリューションを選択するというJWTの推奨を優先することが優先されました。さらに、MPLSで使用されるエンコーディングとメカニズムとの一貫性がより重要であると判断されました。
The second argument has not been examined in great detail because substantive evidence of the existence of two deployment environments has not been documented or presented. Indeed, one of the key differences cited between the two allegedly distinct environments is the choice of MPLS-TP OAM solution, which makes a circular argument.
2つの展開環境が存在することの実質的な証拠は文書化も提示もされていないため、2番目の議論は詳細には検討されていません。確かに、2つの異なる環境とされる2つの環境の主な違いの1つは、MPLS-TP OAMソリューションの選択です。
The third argument contains a very important point: network operators want to achieve a smooth migration from legacy technologies such as SONET/SDH to their new packet transport networks. This transition can be eased if the new networks offer similar OAM features and can be managed using tools with similar look and feel. The requirements specifications [RFC5654] and [RFC5860] capture the essential issues that must be resolved to allow the same look and feel to be achieved. Since the OAM solutions developed within the IETF meet the documented requirements, Network Management Systems (NMSs) can easily be built to give the same type of control of MPLS-TP networks as is seen in other transport networks. Indeed, it should be understood that the construction of an NMS is not dependent on the protocols and packet formats within the OAM but on the high-level features and functions offered by the OAM.
3番目の議論には非常に重要なポイントが含まれています。ネットワークオペレーターは、SONET / SDHなどのレガシーテクノロジーから新しいパケットトランスポートネットワークへのスムーズな移行を実現したいと考えています。新しいネットワークが同様のOAM機能を提供し、同様のルックアンドフィールのツールを使用して管理できる場合、この移行は容易になります。要件仕様[RFC5654]および[RFC5860]は、同じルックアンドフィールを実現するために解決する必要のある重要な問題をキャプチャします。 IETF内で開発されたOAMソリューションは文書化された要件を満たすため、ネットワーク管理システム（NMS）を簡単に構築して、他のトランスポートネットワークで見られるのと同じタイプのMPLS-TPネットワークの制御を提供できます。実際、NMSの構築は、OAM内のプロトコルやパケット形式ではなく、OAMが提供する高レベルの機能に依存していることを理解しておく必要があります。
This document does not debate the technical merits of any specific solution. That discussion, and the documentation of MPLS-TP OAM specifications, was delegated by the IETF and ITU-T to the MPLS working group and can be conducted using the normal consensus-driven IETF process. [OAM-OVERVIEW] presents an overview of the OAM mechanisms that have already been defined and that are currently being defined by the IETF, as well as a comparison with other OAM mechanisms that were defined by the IEEE and ITU-T.
このドキュメントでは、特定のソリューションの技術的なメリットについては説明していません。その議論とMPLS-TP OAM仕様のドキュメントは、IETFとITU-TによってMPLSワーキンググループに委任され、通常のコンセンサス主導のIETFプロセスを使用して実施できます。 [OAM-OVERVIEW]は、すでに定義され、現在IETFによって定義されているOAMメカニズムの概要と、IEEEおよびITU-Tによって定義された他のOAMメカニズムとの比較を示しています。
This document focuses on an examination of the consequences of the existence of two MPLS-TP OAM solutions.
このドキュメントでは、2つのMPLS-TP OAMソリューションが存在することによる影響の調査に焦点を当てています。
This document uses the following acronyms:
このドキュメントでは、次の頭字語を使用しています。
ANSI American National Standards Institute CESoPSN Circuit Emulation Service over Packet Switched Network ETSI European Telecommunications Standards Institute FPGA Field-Programmable Gate Array GFP Generic Framing Procedure IEEE Institute of Electrical and Electronics Engineers ITU-T International Telecommunication Union - Telecommunication Standardization Sector JWT Joint Working Team LSP Label Switched Path MPLS-TP MPLS Transport Profile NMS Network Management System OAM Operations, Administration, and Maintenance PDH Plesiochronous Digital Hierarchy PSN Packet Switched Network PTN Packet Transport Network PW Pseudowire PWE3 Pseudowire Emulation Edge-to-Edge SAToP Structure-Agnostic Time Division Multiplexing over Packet SDH Synchronous Digital Hierarchy SLA Service Level Agreement SONET Synchronous Optical Network TDM Time Division Multiplexing TDMoIP Time Division Multiplexing over IP
ANSI American National Standards Institute CESoPSN Circuit Emulation Service over Packet Switched Network ETSI European Telecommunications Standards Institute FPGA Field-Programmable Gate Array GFP Generic Framing Procedure IEEE Institute of Electrical and Electronics Engineers ITU-T International Telecommunication Union-Telecommunication Standardization Sector JWT Joint Working Team LSPラベルスイッチドパスMPLS-TP MPLSトランスポートプロファイルNMSネットワーク管理システムOAM運用、管理、および保守PDH Plesiochronous Digital Hierarchy PSNパケットスイッチドネットワークPTNパケットトランスポートネットワークPW疑似配線PWE3疑似配線エミュレーションエッジ間SAToP構造に依存しない時分割多重化パケットSDH同期デジタル階層SLAサービスレベルアグリーメントSONET同期光ネットワークTDM時分割多重TDMoIP時分割多重IP
This section presents a discussion of the implications of the development and deployment of more than one MPLS OAM protocol. The summary is that it can be seen that there are strong technical, operational, and economic reasons to avoid the development and deployment of anything other than a single MPLS OAM protocol.
このセクションでは、複数のMPLS OAMプロトコルの開発と展開の影響について説明します。要約すると、単一のMPLS OAMプロトコル以外のものの開発と展開を回避するための技術的、運用上、経済上の強力な理由があることがわかります。
MPLS-TP is an MPLS technology. It is designed to apply MPLS to a new application. The original proposers of the concept assumed that the transport variant of MPLS would always exist in a disjoint network, and indeed their first attempt at the technology (Transport MPLS (T-MPLS)) had a number of significant incompatibilities with MPLS that were irreconcilable. When it was established that coexistence in the same layer network could and would occur, T-MPLS development was stopped and the development of MPLS-TP was begun. In MPLS-TP, MPLS was extended to satisfy the transport network requirements in a way that was compatible both with MPLS as has already been deployed, and with MPLS as the IETF envisioned it would develop in the future.
MPLS-TPはMPLSテクノロジーです。 MPLSを新しいアプリケーションに適用するように設計されています。コンセプトの最初の提案者は、MPLSのトランスポートバリアントは常にばらばらのネットワークに存在すると想定し、実際、テクノロジー（トランスポートMPLS（T-MPLS））での最初の試みには、MPLSとの互換性のない多くの重大な非互換性がありました。同層ネットワークでの共存が可能であり、発生することが判明した時点で、T-MPLSの開発は中止され、MPLS-TPの開発が開始されました。 MPLS-TPでは、MPLSは拡張され、トランスポートネットワークの要件を満たします。これは、すでに展開されているMPLSと、将来開発されると予測されるIETFのMPLSの両方と互換性があります。
Given this intention for compatibility, it follows that the MPLS-TP OAM protocols should be designed according to the design philosophies that were applied for the existing deployed MPLS OAM and that have led to the current widespread adoption of MPLS. Key elements here are scalability and hardware independence, i.e., that the trade-off between scaling to large numbers of monitored objects and the performance of the monitoring system should be a matter for vendors and operators to resolve, and that the trade-off should be a soft transition rather than an abrupt one. Furthermore, there should be no requirement to execute any component (other than packet forwarding) in hardware to achieve usable performance.
この互換性の意図を踏まえると、MPLS-TP OAMプロトコルは、既存の展開済みMPLS OAMに適用され、現在広く普及しているMPLSの採用につながった設計哲学に従って設計する必要があります。ここで重要な要素は、スケーラビリティとハードウェアの独立性です。つまり、多数の監視対象オブジェクトへのスケーリングと監視システムのパフォーマンスとの間のトレードオフは、ベンダーとオペレーターが解決する問題であり、トレードオフは突然の遷移ではなく、ソフトな遷移。さらに、使用可能なパフォーマンスを実現するために、ハードウェアで（パケット転送以外の）コンポーネントを実行する必要はありません。
It is possible to argue that using MPLS for transport is only a stepping stone in the middle of a longer transition. Quite clearly, all communication applications are being moved to operate over the Internet protocol stack of TCP/IP/MPLS, and the various layers that have existed in communications networks are gradually being collapsed into the minimum necessary set of layers. Thus, for example, we no longer run IP over X.25 over High-Level Data Link Control (HDLC) over multi-layered Time Division Multiplexing (TDM) networks.
トランスポートにMPLSを使用することは、より長い移行の真っ只中の足がかりにすぎないと主張することは可能です。明らかに、すべての通信アプリケーションはTCP / IP / MPLSのインターネットプロトコルスタック上で動作するように移行されており、通信ネットワークに存在していたさまざまなレイヤーは、必要最小限のレイヤーセットに徐々に縮小されています。したがって、たとえば、多層の時分割多重化（TDM）ネットワークでは、高レベルデータリンク制御（HDLC）を介してIP over X.25を実行しなくなりました。
Increasingly, the entire point of transport networks is to support the transmission of TCP/IP/MPLS. Using MPLS to construct a transport network may be a relatively short-term stepping stone toward running IP and MPLS directly over fiber optics. MPLS has been deployed in operational networks for approximately a decade, and the existing MPLS OAM techniques have seen wide deployment. Service providers are not going to stop using the MPLS-based OAM techniques that they have been using for years, and no one has proposed that they would. Thus, the question is not which OAM to use for transport networks; the question is whether service providers want to use two different sets of OAM tools in the future converged network. If we arrive at a destination where TCP/IP/MPLS runs directly over fiber, the operators will use MPLS OAM tools to make this work.
ますます、トランスポートネットワークの全体のポイントは、TCP / IP / MPLSの伝送をサポートすることです。 MPLSを使用してトランスポートネットワークを構築することは、IPとMPLSを光ファイバーで直接実行するための比較的短期間の足がかりになる場合があります。 MPLSは約10年間運用ネットワークに展開されており、既存のMPLS OAM技術は広く展開されています。サービスプロバイダーは、長年使用してきたMPLSベースのOAM技術の使用をやめようとはしていません。したがって、問題はトランスポートネットワークにどのOAMを使用するかではありません。問題は、サービスプロバイダーが2つの異なるOAMツールセットを将来の統合ネットワークで使用することを望んでいるかどうかです。 TCP / IP / MPLSがファイバー上で直接実行される宛先に到着した場合、オペレーターはMPLS OAMツールを使用してこれを機能させます。
The purpose of OAM is usually to execute a function that operates end to end on the monitored object (such as an LSP or PW). Since LSPs and PWs provide edge-to-edge connectivity and can cross network operator boundaries, the OAM must similarly operate across network operator boundaries. This is particularly the case with the continuity check and connection verification functions that are needed to test the end-to-end connectivity of LSPs and PWs. It is, therefore, necessary that any two pieces of equipment that could ever be a part of an end-to-end communications path have a common OAM. This necessity is emphasized in the case of equipment executing an edge function, since with a global technology such as MPLS it could be interconnected with edge equipment deployed by any other operator in any part of the global network.
OAMの目的は通常、監視対象オブジェクト（LSPやPWなど）をエンドツーエンドで操作する機能を実行することです。 LSPとPWはエッジ間接続を提供し、ネットワークオペレーターの境界を越えることができるため、OAMはネットワークオペレーターの境界を越えて同様に動作する必要があります。これは特に、LSPとPWのエンドツーエンドの接続をテストするために必要な連続性チェックと接続検証機能の場合に当てはまります。したがって、エンドツーエンドの通信パスの一部となる可能性のある2つの機器には、共通のOAMが必要です。エッジ機能を実行する機器の場合、この必要性が強調されます。これは、MPLSなどのグローバルテクノロジーを使用すると、グローバルネットワークの任意の部分で他のオペレーターが展開したエッジ機器と相互接続できるためです。
This leads to the conclusion that it is desirable for any network-layer protocol in all equipment to be able to execute or to interwork with a canonical form of the OAM. As discussed in Section 4, interworking between protocols adds significant complexity; thus, a single default OAM is strongly preferred.
これは、すべての機器の任意のネットワーク層プロトコルが、OAMの標準形式を実行または相互運用できることが望ましいという結論につながります。セクション4で説明したように、プロトコル間のインターワーキングはかなり複雑になります。したがって、単一のデフォルトOAMが強く推奨されます。
A frequent driver for the replacement of an established technology is a perception that the new technology is simpler and thus of greater economic benefit to the user. In an isolated system, this may be the case; however, as is usually the case with communications technologies, simplification in one element of the system introduces an increase (possibly a non-linear one) in complexity elsewhere.
確立されたテクノロジーを置き換えるための頻繁なドライバーは、新しいテクノロジーが単純であり、ユーザーにとって経済的利益が大きいという認識です。孤立したシステムでは、これが当てはまる場合があります。ただし、通信技術の場合は通常そうであるように、システムの1つの要素を単純化すると、他の場所で複雑さが増します（おそらく非線形要素になります）。
This creates the "squashed sausage" effect, where reduction in complexity at one place leads to significant increase in complexity at a remote location. When we drive complexity out of hardware by placing complexity in the control plane, there is frequently an economic benefit, as illustrated by MPLS itself.
これにより、「押しつぶされたソーセージ」の効果が生まれます。1か所での複雑さの軽減により、遠隔地での複雑さが大幅に増加します。コントロールプレーンに複雑さを配置することでハードウェアの複雑さを排除すると、MPLS自体が示すように、多くの場合、経済的メリットがあります。
Some motivation for the second OAM solution is the simplicity of operation at a single node in conjunction with other transport OAM mechanisms. However, when we drive OAM complexity out of one network element at the cost of increased complexity at a peer network element, we lose out economically and, more importantly, we lose out in terms of the reliability of this important network functionality. Due to the need to ensure compatibility of an interworking function between the two MPLS-TP OAM solutions (in order to achieve end-to-end OAM), we create a situation where neither of two disjoint protocol developments is able to make technical advances. Such a restriction is unacceptable within the context of the Internet.
2番目のOAMソリューションのいくつかの動機は、他のトランスポートOAMメカニズムと組み合わせた単一ノードでの操作の単純さです。ただし、ピアネットワーク要素での複雑さの増大を犠牲にして、1つのネットワーク要素からOAMの複雑さを排除すると、経済的に失われ、さらに重要なことに、この重要なネットワーク機能の信頼性の点で失われます。 2つのMPLS-TP OAMソリューション間のインターワーキング機能の互換性を確保する必要があるため（エンドツーエンドのOAMを実現するため）、2つの独立したプロトコル開発のどちらも技術的な進歩を遂げることができない状況を作り出します。このような制限は、インターネットのコンテキスト内では受け入れられません。
The issue of OAM interworking can easily be illustrated by considering an analogy with people speaking different languages. Interworking is achieved through the use of an interpreter. The interpreter introduces cost, slows down the rate of information exchange, and may require transition through an intermediate language. There is considerable risk of translation errors and semantic ambiguities. These considerations also apply to computer protocols, particularly given the ultra-pedantic nature of such systems. In all cases, the availability of a single working language dramatically simplifies the system, reduces cost, and speeds reliable communication.
OAMインターワーキングの問題は、さまざまな言語を話す人々との類似性を検討することで簡単に説明できます。インターワーキングは、インタープリターを使用して実現されます。通訳者はコストがかかり、情報交換の速度が遅くなり、中間言語を介した移行が必要になる場合があります。翻訳エラーと意味のあいまいさにはかなりのリスクがあります。これらの考慮事項は、特にこのようなシステムの非常に画期的な性質を考えると、コンピュータプロトコルにも適用されます。いずれの場合も、単一の動作言語を使用できるため、システムが大幅に簡素化され、コストが削減され、信頼性の高い通信が高速化されます。
If two MPLS OAM protocols were to be deployed, we would have to consider three possible scenarios:
2つのMPLS OAMプロトコルを導入する場合、考えられる3つのシナリオを考慮する必要があります。
1. Isolation of the network into two incompatible and unconnected islands.
1. 2つの互換性のない、接続されていないアイランドへのネットワークの分離。
2. Universal use of both OAM protocols.
2. 両方のOAMプロトコルの普遍的な使用。
3. Placement of interworking (translation) functions or gateways.
3. インターワーキング（変換）関数またはゲートウェイの配置。
We have many existence proofs that isolation is not a viable approach, and the reader is referred to the early T-MPLS discussions for examples. In summary, the purpose of the Internet is to achieve an integrated universal connectivity. Partition of the Internet into incompatible and unconnected islands is neither desirable nor acceptable.
分離は実行可能なアプローチではないという多くの存在証明があり、読者は例として初期のT-MPLSの議論を参照されています。要約すると、インターネットの目的は、統合されたユニバーサル接続を実現することです。インターネットを互換性のない、接続されていないアイランドに分割することは、望ましいことでも、許容できることでもありません。
Universal deployment of both OAM protocols requires the sum of the costs associated with each protocol. This manifests as implementation time, development costs, memory requirements, hardware components, and management systems. It introduces additional testing requirements to ensure there are no conflicts (processing state, fault detection, code path, etc.) when both protocols are run on a common platform. It also requires code and the processes to deal with the negotiation of which protocol to use and to deal with conflict resolution (which may be remote and multi-party) when an inconsistent choice is made. In short, this option results in more than double the cost, increases the complexity of the resulting system, risks the stability of the deployed network, and makes the networks more expensive and more complicated to operate.
両方のOAMプロトコルのユニバーサルな展開には、各プロトコルに関連するコストの合計が必要です。これは、実装時間、開発コスト、メモリ要件、ハードウェアコンポーネント、および管理システムとして現れます。両方のプロトコルが共通のプラットフォームで実行されている場合に、競合（処理状態、障害検出、コードパスなど）がないことを確認するための追加のテスト要件が導入されています。また、一貫性のない選択が行われた場合、使用するプロトコルのネゴシエーションを処理し、競合解決（リモートおよびマルチパーティの場合がある）を処理するためのコードとプロセスも必要です。つまり、このオプションでは、コストが2倍以上になり、結果のシステムの複雑さが増し、展開されたネットワークの安定性にリスクが生じ、ネットワークの運用がより高価で複雑になります。
The third possibility is the use of some form of interworking function. This is not a simple solution and inevitably leads to cost and complexity in implementation, deployment, and operation. Where there is a chain of communication (end-to-end messages passed through a series of transit nodes), a choice must be made about where to apply the translation and interworking.
3番目の可能性は、何らかの形のインターワーキング関数の使用です。これは単純なソリューションではなく、必然的に実装、展開、および運用のコストと複雑さにつながります。一連の通信（一連の中継ノードを通過するエンドツーエンドのメッセージ）がある場合は、変換とインターワーキングを適用する場所を選択する必要があります。
o In a layered architecture, interworking can be achieved through tunneling with the translation points at the end-points of the tunnels. In simple network diagrams, this can look very appealing, and only one end-node is required to be able to perform the translation function (effectively speaking both OAM languages). But in the more complex reality of the Internet, nearly every network node performs the function of an end-node, and so the result is that nearly every node must be implemented with the capability to handle both OAM protocols and to translate between them. This turns out to be even more complex than the universal deployment of both protocols discussed above.
o 階層化アーキテクチャでは、トンネルのエンドポイントにある変換ポイントをトンネリングすることで、インターワーキングを実現できます。単純なネットワークダイアグラムでは、これは非常に魅力的に見える可能性があり、翻訳機能（効果的に両方のOAM言語を実行する）を実行するために必要なエンドノードは1つだけです。しかし、インターネットのより複雑な現実では、ほぼすべてのネットワークノードがエンドノードの機能を実行するため、ほぼすべてのノードに、両方のOAMプロトコルを処理し、それらの間で変換する機能を実装する必要があります。これは、上で説明した両方のプロトコルの一般的な展開よりもさらに複雑であることがわかります。
o In a flat architecture, interworking is performed at a "gateway" between islands implementing different protocols. Gateways are substantially complex entities that usually have to maintain end-to-end state within the network (something that is against one of the fundamental design principles of the Internet) and must bridge the differences in state machines, message formats, and information elements in the two protocols. The complexity of gateways makes them expensive, fragile, and unstable; hard to update when new revisions of protocols are released; and difficult to manage.
o フラットアーキテクチャでは、異なるプロトコルを実装するアイランド間の「ゲートウェイ」でインターワーキングが実行されます。ゲートウェイは非常に複雑なエンティティであり、通常はネットワーク内でエンドツーエンドの状態（インターネットの基本的な設計原則の1つに反するもの）を維持する必要があり、状態マシン、メッセージ形式、および情報要素の違いを埋める必要があります。 2つのプロトコル。ゲートウェイは複雑であるため、高価で壊れやすく、不安定です。プロトコルの新しいリビジョンがリリースされたときに更新するのが難しい。管理が難しい。
To deploy an interworking function, it is necessary to determine whether the OAM protocol on the arriving segment of the OAM is identical to the OAM protocol on the departing segment. Where the protocols are not the same, it is necessary to determine which party will perform the translation. It is then necessary to route the LSP or PW through a translation point that has sufficient translation capacity and sufficient data bandwidth, as well as adequate path diversity. When an upgraded OAM function is required, the problem changes from a two-party negotiation to an n-party negotiation with commercial and deployment issues added to the mix.
インターワーキング機能を展開するには、OAMの到着セグメントのOAMプロトコルが、出発セグメントのOAMプロトコルと同一であるかどうかを判別する必要があります。プロトコルが同じでない場合は、どちらの当事者が変換を実行するかを決定する必要があります。次に、十分な変換容量と十分なデータ帯域幅、および適切なパスダイバーシティを持つ変換ポイントを介してLSPまたはPWをルーティングする必要があります。アップグレードされたOAM機能が必要な場合、問題は2パーティのネゴシエーションからnパーティのネゴシエーションに変わり、商用および展開の問題が追加されます。
Note that when an end-to-end LSP or PW is deployed, it may transit many networks, and the OAM might require repeated translation back and forth between the OAM protocols. The consequent loss of information and potential for error is similar to the children's game of "telephone".
エンドツーエンドのLSPまたはPWが展開されると、多くのネットワークを通過し、OAMはOAMプロトコル間で繰り返し変換を繰り返す必要があることに注意してください。結果として生じる情報の損失とエラーの可能性は、「電話」の子供のゲームに似ています。
When there is a choice of protocols for deployment or operation, a network operator must make a choice. Choice can be a good thing when it provides for selection between different features and functions, but it is a burden when the protocols offer essentially the same functions but are incompatible.
展開または運用のためのプロトコルの選択がある場合、ネットワークオペレーターは選択を行う必要があります。選択は、異なる機能や機能を選択できる場合には良いことですが、プロトコルが本質的に同じ機能を提供するが互換性がない場合は負担になります。
In this case, the elements of the choice include the following:
この場合、選択の要素には次のものが含まれます。
o Which protocol will continue to be developed by its Standards Development Organization (SDO)?
o 標準開発機構（SDO）が引き続き開発するプロトコルはどれですか？
o Which protocol is most stable in implementations?
o 実装で最も安定しているプロトコルはどれですか？
o How does a network operator test and evaluate the two protocols?
o ネットワークオペレーターは2つのプロトコルをどのようにテストおよび評価しますか
o Which vendors support and will continue to support which protocol?
o どのベンダーがどのプロトコルをサポートし、今後もサポートしますか？
o What equipment from different vendors is compatible?
o 異なるベンダーのどの機器が互換性がありますか？
o Which management tools support which protocols?
o どの管理ツールがどのプロトコルをサポートしていますか？
o What protocols are supported by peer operators, and what interworking function is needed?
o ピアオペレーターがサポートするプロトコルと、必要なインターワーキング機能
o Which protocols are engineers experienced with and trained in?
o エンジニアはどのプロトコルを経験し、訓練を受けていますか？
o What are the consequences of a wrong choice?
o 間違った選択の結果は何ですか？
o Will it be possible to migrate from one protocol to another in the future?
o 将来、あるプロトコルから別のプロトコルに移行することは可能ですか？
o How is integration with other functions already present in the network accomplished?
o ネットワークにすでに存在する他の機能との統合はどのようにして達成されますか？
o How does a network operator future-proof against the inclusion of new functions in the network?
o ネットワークオペレーターは、ネットワークに新しい機能が含まれることをどのように将来にわたって保証しますか？
At the very least, the evaluation of these questions constitutes a cost and introduces delay for the operator. The consequence of a wrong choice could be very expensive, and it is likely that any comparative testing will more than double the lab-test costs prior to deployment.
少なくとも、これらの質問の評価はコストとなり、オペレーターに遅延をもたらします。間違った選択の結果は非常に費用がかかる可能性があり、比較テストは展開前のラボテストのコストの2倍以上になる可能性があります。
From a vendor's perspective, the choice is even harder. A vendor does not want to risk not offering a product for which there is considerable demand, so both protocols may need to be developed, leading to more than doubled development costs. Indeed, code complexity and defect rates have often been shown to increase more than linearly with code size, and (as noted in Section 3.5) the need to test for coexistence and interaction between the protocols adds to the cost and complexity.
ベンダーの観点からは、選択はさらに困難です。ベンダーは、かなりの需要がある製品を提供しないリスクを冒したくないので、両方のプロトコルを開発する必要があり、開発コストが2倍以上になる可能性があります。実際、コードの複雑さと欠陥率は、コードサイズの増加に伴って直線的に増加することが多く、（セクション3.5で説明したように）プロトコル間の共存と相互作用をテストする必要があるため、コストと複雑さが増します。
It should be noted that, in the long run, it is the end-users who pay the price for the additional development costs and any network instability that arises.
長期的には、追加の開発コストと発生するネットワークの不安定性の代償を払うのはエンドユーザーです。
Deployment of a technology that is subsequently replaced or obsoleted often leads to the need to migrate from one technology to another. Such a situation might arise if an operator deploys one of the two OAM protocol solutions and discovers that he needs to migrate to the other one. A specific case would be when two operators merge their networks but are using different OAM solutions.
後に置き換えられるか廃止されたテクノロジを展開すると、多くの場合、あるテクノロジから別のテクノロジに移行する必要が生じます。このような状況は、オペレーターが2つのOAMプロトコルソリューションの1つを展開し、もう1つに移行する必要があることを発見した場合に発生する可能性があります。特定のケースは、2つの事業者がネットワークをマージするが、異なるOAMソリューションを使用している場合です。
When the migration is between versions of a protocol, it may be that the new version is defined to support the old version. If the implementation is in software (including FPGAs), upgrades can be managed centrally. However, neither of these would be the case with MPLS-TP OAM mechanisms, and hardware components would need to be upgraded in the field using expensive call-out services.
プロトコルのバージョン間で移行する場合、古いバージョンをサポートするように新しいバージョンが定義されている可能性があります。実装がソフトウェア（FPGAを含む）で行われている場合は、アップグレードを集中管理できます。ただし、MPLS-TP OAMメカニズムではこれらのいずれも当てはまりません。ハードウェアコンポーネントは、高価なコールアウトサービスを使用して現場でアップグレードする必要があります。
Hardware upgrades are likely to affect service, even with sophisticated devices with redundant hardware components. Furthermore, since it would be impractical to upgrade every device in the network at the same time, there is a need for either a significantly large maintenance period across the whole network or for a rolling plan that involves upgrading nodes one at a time with new hardware that has dual capabilities. Such hardware is, of course, more expensive and more complex to configure than hardware dedicated to just one OAM protocol.
ハードウェアのアップグレードは、冗長なハードウェアコンポーネントを備えた高度なデバイスであっても、サービスに影響を与える可能性があります。さらに、ネットワーク内のすべてのデバイスを同時にアップグレードすることは非現実的であるため、ネットワーク全体で非常に長いメンテナンス期間、または新しいハードウェアを使用してノードを一度に1つずつアップグレードするローリングプランが必要です。これには2つの機能があります。もちろん、そのようなハードウェアは、1つのOAMプロトコル専用のハードウェアよりも構成が複雑で高価です。
Additionally, the transition phase of migration leads to dual-mode networks as described in Section 4.3. Such networks are not desirable because of their cost and complexity.
さらに、移行の移行フェーズでは、セクション4.3で説明するように、デュアルモードネットワークが導入されます。そのようなネットワークは、そのコストと複雑さのために望ましくありません。
In short, the potential for future migration will need to be part of the deployment planning exercise when there are two OAM protocols to choose between. This issue will put pressure on making the "right" choice when performing the selection described in Section 3.6.
つまり、2つのOAMプロトコルから選択する場合、将来の移行の可能性を展開計画の練習の一部にする必要があります。この問題は、セクション3.6で説明されている選択を実行するときに「正しい」選択を行うことを迫られます。
This section expands upon the discussion in Section 3 by examining three questions:
このセクションでは、3つの質問を検討することにより、セクション3での議論をさらに詳しく説明します。
o What does it mean for two protocols to be incompatible?
o 2つのプロトコルに互換性がないとはどういう意味ですか？
o Why can't we assume that the two solutions will never coexist in the same network?
o 2つのソリューションが同じネットワークで共存しないと仮定できないのはなぜですか？
o What models could we support for coexistence?
o 共存をサポートできるモデルは何ですか？
Protocol incompatibility comes in a range of grades of seriousness. At the most extreme, the operation of one protocol will prevent the safe and normal operation of the other protocol. This was the case with the original T-MPLS, where MPLS labels that could be used for data in a native MPLS system were assigned special meaning in T-MPLS such that data packets would be intercepted and mistaken for OAM packets.
プロトコルの非互換性には、さまざまな深刻度があります。最も極端な場合、1つのプロトコルの操作は、他のプロトコルの安全で通常の操作を妨げます。これは、元のT-MPLSの場合でした。ネイティブMPLSシステムのデータに使用できるMPLSラベルには、T-MPLSで特別な意味が割り当てられ、データパケットが傍受され、OAMパケットと間違えられました。
A lesser incompatibility arises where the packets of one protocol are recognized as "unknown" or "not valid" by implementations of the other protocol. In this case, the rules of one protocol require that the packets of the other protocol be discarded and may result in the LSP or PW being torn down.
1つのプロトコルのパケットが、他のプロトコルの実装によって「不明」または「無効」として認識される場合は、互換性が低くなります。この場合、1つのプロトコルのルールでは、他のプロトコルのパケットを破棄する必要があり、LSPまたはPWが破棄される可能性があります。
The least serious level of incompatibility is where the packets of one protocol are recognized as "unknown" by implementations of the other protocol, but where the rules of one protocol allow the packets of the other protocol to be ignored; in this case, such packets are either silently discarded or forwarded untouched.
最も深刻ではないレベルの非互換性は、1つのプロトコルのパケットが他のプロトコルの実装によって「不明」として認識されるが、1つのプロトコルのルールで他のプロトコルのパケットを無視できる場合です。この場合、そのようなパケットは通知なしで破棄されるか、そのまま転送されます。
These are issues with all of these grades of incompatibility; these issues range from disruption or corruption of user data, through connection failure, to the inability to provide end-to-end OAM function without careful planning and translation functions.
これらは、これらすべてのグレードの非互換性に関する問題です。これらの問題の範囲は、ユーザーデータの中断または破損から接続障害まで、綿密な計画と変換機能なしにエンドツーエンドのOAM機能を提供できないことです。
Networks expand and merge. For example, one service provider may acquire another and wish to merge the operation of the two networks. This makes partitioning networks by protocol deployment a significant issue for future-proofing commercial interactions. Although a network operator may wish to present difficulties in order to disincentivize hostile takeover (a poison pill), most operators are interested in future options to grow their networks.
ネットワークは拡大し、融合します。たとえば、あるサービスプロバイダーが別のサービスプロバイダーを取得し、2つのネットワークの動作をマージしたいとします。これにより、プロトコル展開によるネットワークのパーティション分割は、将来を見据えた商業的相互作用にとって重要な問題になります。ネットワークオペレーターは、敵対的乗っ取り（ポイズンピル）を阻害するために困難を提示したいと思うかもしれませんが、ほとんどのオペレーターは、ネットワークを拡大するための将来のオプションに関心があります。
As described in Section 3.2, MPLS is a convergence technology. That means that there is a tendency for an ever-increasing number of services to be supported by MPLS and for MPLS to be deployed in an increasing number of environments. It would be an unwise operator who deployed a high-function convergence technology in such a way that the network could never be expanded to offer new services or to integrate with other networks or technologies.
セクション3.2で説明したように、MPLSはコンバージェンステクノロジーです。つまり、MPLSでサポートされるサービスの数が増え、MPLSがより多くの環境に展開される傾向があります。新しいサービスを提供したり、他のネットワークやテクノロジーと統合したりするためにネットワークを拡張することができないような方法で高機能コンバージェンステクノロジーを展開したのは賢明なオペレーターでしょう。
As described in Section 3.3, there is a requirement for end-to-end OAM. That means that where LSPs and PWs span multiple networks, there is a need for OAM to span multiple networks.
セクション3.3で説明したように、エンドツーエンドのOAMが必要です。つまり、LSPとPWが複数のネットワークにまたがる場合、OAMが複数のネットワークにまたがる必要があります。
All of this means that, if two different OAM protocol technologies are deployed, there will inevitably come a time when some form of coexistence is required, no matter how carefully the separation is initially planned.
つまり、2つの異なるOAMプロトコルテクノロジが展開されている場合、最初にどのように慎重に分離を計画したとしても、何らかの形の共存が必要になることがあります。
Two models for coexistence can be considered:
共存の2つのモデルを検討できます。
1. An integrated model based on the "ships-in-the-night" approach. In this model, there is no protocol translation or mapping. This model can be decomposed as follows:
1. 「夜間発送」アプローチに基づく統合モデル。このモデルでは、プロトコルの変換やマッピングはありません。このモデルは次のように分解できます。
* A non-integrated mixed network, where some nodes support just one protocol, some support just the other, and no node supports both protocols.
* 統合されていない混合ネットワーク。一部のノードは1つのプロトコルのみをサポートし、一部は他のプロトコルのみをサポートし、ノードは両方のプロトコルをサポートしません。
* Partial integration, where some nodes support just one protocol, some support just the other, and some support both protocols.
* 一部のノードが1つのプロトコルのみをサポートする場合、一部のノードが他のプロトコルのみをサポートする場合、一部のノードが両方のプロトコルをサポートする場合の部分的な統合。
* Fully integrated dual mode, where all nodes support both protocols.
* すべてのノードが両方のプロトコルをサポートする完全に統合されたデュアルモード。
2. An "island" model, where groups of similar nodes are deployed together. In this model, there may be translation or mapping, but it is not always required. This model can be further decomposed as follows:
2. 類似のノードのグループが一緒にデプロイされる「アイランド」モデル。このモデルでは、変換またはマッピングが存在する場合がありますが、常に必要なわけではありません。このモデルは、次のようにさらに分解できます。
* "Islands in a sea", where connectivity between islands of the same type is achieved across a sea of a different type.
* 「海の島」。同じタイプの島の間の接続は、異なるタイプの海を越えて達成されます。
* "Border crossings", where connectivity between different islands is achieved at the borders between them.
* 「国境通過」、異なる島の間の接続はそれらの間の境界で達成されます。
The integrated model assumes that nodes of different capabilities coexist within a single network. Dual-mode nodes supporting both OAM solutions may coexist in the same network. Interworking is not required in this model, and no nodes are capable of performing translation or gateway function (see Section 4.3.2 for operational modes including translation and gateways).
統合モデルは、異なる機能のノードが単一のネットワーク内で共存することを前提としています。両方のOAMソリューションをサポートするデュアルモードノードは、同じネットワーク内で共存できます。このモデルではインターワーキングは不要であり、変換またはゲートウェイ機能を実行できるノードはありません（変換やゲートウェイを含む操作モードについては、セクション4.3.2を参照してください）。
In this model, protocol messages pass as "ships in the night" unaware of each other and without perturbing each other.
このモデルでは、プロトコルメッセージは、互いに気付かずに、互いに気づかない「夜の船」として渡されます。
As noted above, there are several sub-models.
上記のように、いくつかのサブモデルがあります。
In a mixed network with no integration, some nodes support one protocol and other nodes support the other protocol. There are no nodes that have dual capabilities.
統合されていない混合ネットワークでは、一部のノードが1つのプロトコルをサポートし、他のノードが他のプロトコルをサポートします。デュアル機能を持つノードはありません。
All nodes on the path of an LSP or PW that are required to play an active part in OAM must support the same OAM protocol. Nodes that do not support the OAM protocol will silently ignore (and possibly discard) OAM packets from the other protocol and cannot form part of the OAM function for the LSP or PW.
OAMでアクティブな役割を果たすために必要なLSPまたはPWのパス上のすべてのノードは、同じOAMプロトコルをサポートする必要があります。 OAMプロトコルをサポートしないノードは、他のプロトコルからのOAMパケットを静かに無視し（場合によっては破棄し）、LSPまたはPWのOAM機能の一部を形成することはできません。
In order to provision an end-to-end connection that benefits from the full OAM functionality, the planning and path-computation tool must know the capabilities of each network node and must select a path that includes only nodes with the same OAM protocol capability. This can result in considerably suboptimal paths and may lead to the network being partitioned. In the most obvious case, connectivity can only be achieved between end-points with the same OAM capability. This leads to considerable operational complexity and expense, as well as the inability to provide a fully flexible mesh of services.
完全なOAM機能の恩恵を受けるエンドツーエンド接続をプロビジョニングするには、計画およびパス計算ツールが各ネットワークノードの機能を認識し、同じOAMプロトコル機能を持つノードのみを含むパスを選択する必要があります。これにより、パスが大幅に最適化されず、ネットワークが分割される可能性があります。最も明白なケースでは、接続は同じOAM機能を持つエンドポイント間でのみ実現できます。これにより、運用がかなり複雑になり、費用がかかるだけでなく、完全に柔軟なサービスのメッシュを提供できなくなります。
In the event of dynamic network changes (such as fast reroute) or if misconnectivity occurs, nodes of mismatched OAM capabilities may become interconnected. This will disrupt traffic delivery because end-to-end continuity checks may be disrupted, and it may be hard or impossible to diagnose the problem because connectivity verification and route trace functions will not work properly.
動的なネットワーク変更（高速リルートなど）が発生した場合、または誤接続が発生した場合、OAM機能が一致しないノードが相互接続される可能性があります。これにより、エンドツーエンドの連続性チェックが中断される可能性があるため、トラフィックの配信が中断されます。また、接続検証とルートトレース機能が適切に機能しないため、問題を診断することが困難または不可能になる場合があります。
In a partially integrated network, the network described in Section 4.3.1.1 is enhanced by the addition of a number of nodes with dual capabilities. These nodes do not possess gateway or translation capabilities (this is covered in Section 4.3.2), but each such node can act as a transit point or end-node for an LSP or PW that uses either OAM protocol.
部分的に統合されたネットワークでは、セクション4.3.1.1で説明されているネットワークは、デュアル機能を持つ多数のノードを追加することによって拡張されます。これらのノードはゲートウェイまたは変換機能（セクション4.3.2で説明）を備えていませんが、そのような各ノードは、OAMプロトコルを使用するLSPまたはPWのトランジットポイントまたはエンドノードとして機能できます。
Complexity of network operation is not eased, but there is greater connectivity potential in the network.
ネットワーク操作の複雑さは緩和されませんが、ネットワークの接続可能性は大きくなります。
Dual mode is a development of partial integration (Section 4.3.1.2) such that all nodes in the network are capable of both OAM protocols. As in that section, these nodes do not possess gateway or translation capabilities (this is covered in Section 4.3.2), but each such node can act as a transit point or end-node for an LSP or PW that uses either OAM protocol. Thus, every LSP or PW in the network can be configured to use either of the OAM protocols.
デュアルモードは、ネットワーク内のすべてのノードが両方のOAMプロトコルに対応できるようにするための部分統合（セクション4.3.1.2）の開発です。そのセクションと同様に、これらのノードにはゲートウェイまたは変換機能はありませんが（これについてはセクション4.3.2で説明します）、そのような各ノードは、OAMプロトコルを使用するLSPまたはPWの中継ポイントまたはエンドノードとして機能できます。したがって、ネットワーク内のすべてのLSPまたはPWは、いずれかのOAMプロトコルを使用するように構成できます。
However, it seems unlikely that an operator would choose which OAM protocol to use on a per-LSP or per-PW basis. That would lead to additional complexity in the management system and potential confusion if additional diagnostic analytics need to be performed. This mode increases the complexity of implementation, deployment, and operation without adding to the function within the network (since both OAM solutions provide the same level of function), so this mode would not be selected for deployment except, perhaps, during migration of the network from one OAM protocol to the other.
ただし、オペレータがLSPごとまたはPWごとに使用するOAMプロトコルを選択することはほとんどありません。これにより、管理システムがさらに複雑になり、追加の診断分析を実行する必要がある場合に混乱が生じる可能性があります。このモードでは、ネットワーク内の機能に追加することなく、実装、展開、および操作の複雑さが増します（両方のOAMソリューションが同じレベルの機能を提供するため）。このモードは、おそらく移行中以外は、展開用に選択されません。 1つのOAMプロトコルから別のOAMプロトコルへのネットワーク。
In the island model, regions or clusters of nodes with the same OAM capabilities are grouped together. Tools to interconnect the technologies are deployed based on layered networking or on interworking between the protocols. These lead to the two sub-models described in the sections that follow.
アイランドモデルでは、同じOAM機能を持つノードのリージョンまたはクラスターがグループ化されます。テクノロジーを相互接続するツールは、レイヤードネットワーキングまたはプロトコル間の相互作用に基づいて展開されます。これらは、次のセクションで説明する2つのサブモデルにつながります。
One way to view clusters of nodes supporting one OAM protocol is as an island in a sea of nodes supporting the other protocol. In this view, tunnels are used to carry LSPs or PWs using one OAM type across the sea and into another island of a compatible OAM type. The tunnel in this case is an LSP utilizing the OAM protocol supported by the nodes in the sea. Theoretically, an island can be as small as one node, and the strait between two islands can be as narrow as just one node.
1つのOAMプロトコルをサポートするノードのクラスターを表示する1つの方法は、他のプロトコルをサポートするノードの海の島として表示することです。このビューでは、1つのOAMタイプを使用してLSPまたはPWを海を越え、互換性のあるOAMタイプの別のアイランドに運ぶためにトンネルが使用されます。この場合のトンネルは、海のノードでサポートされているOAMプロトコルを利用したLSPです。理論的には、島は1つのノードと同じくらい小さくすることができ、2つの島の間の海峡は1つのノードと同じくらい狭くすることができます。
Layering in this way is an elegant solution to operating two protocols simultaneously and is, of course, used to support different technologies (such as MPLS over optical). However, in such layering deployments, there is no simple integration of OAM between the layers, and the OAM in the upper layer must regard the tunnel as a single hop with no visibility into the OAM of the lower layer. Diagnostics within the upper layer are complicated by this "hiding" of the nodes along the path of the tunnel in the lower layer.
このように階層化することは、2つのプロトコルを同時に操作するための洗練されたソリューションであり、もちろん、さまざまなテクノロジー（MPLS over Opticalなど）をサポートするために使用されます。ただし、このようなレイヤ展開では、レイヤ間のOAMの単純な統合はなく、上位レイヤのOAMはトンネルを下位レイヤのOAMへの可視性のない単一のホップと見なす必要があります。上位層内の診断は、下位層のトンネルのパスに沿ったノードの「非表示」によって複雑になります。
In the scenarios described so far, both ends of each connection have been placed in islands of compatible OAM types. It is possible to achieve connectivity between a node in an island and a node in the sea if the end-point in the sea has dual capabilities (i.e., can be viewed as a single-node island).
これまでに説明したシナリオでは、各接続の両端が互換性のあるOAMタイプのアイランドに配置されています。海のエンドポイントにデュアル機能がある場合（つまり、単一ノードのアイランドと見なすことができる場合）、アイランド内のノードと海内のノード間の接続を実現することができます。
A number of islands may lie along the path between end-points, necessitating the use of more than one tunnel. To further complicate matters, the islands may lie in an inland sea so that it is necessary to nest tunnels.
エンドポイント間のパスに沿っていくつかのアイランドが存在する場合があり、複数のトンネルを使用する必要があります。さらに複雑なことに、島は内海にあり、トンネルをネストする必要があります。
Regardless of the scenario, operating such tunnels/layers adds to the management complexity and expense. Furthermore, it should be noted that in an MPLS network there is often a call for any-to-any connectivity. That is, any node in the network may need to establish an LSP or a PW to any other node in the network. As previously noted, the end-points of any LSP or PW must support the same OAM type in the islands-in-a-sea model, so this tends to imply that all, or nearly all, nodes will end up needing to support both OAM protocols.
シナリオに関係なく、このようなトンネル/レイヤーを運用すると、管理の複雑さと費用が増加します。さらに、MPLSネットワークでは、多くの場合、any-to-any接続の呼び出しが存在することに注意してください。つまり、ネットワーク内の任意のノードが、ネットワーク内の他のノードへのLSPまたはPWを確立する必要がある場合があります。前述のように、LSPまたはPWのエンドポイントは、海の島モデルで同じOAMタイプをサポートする必要があるため、これは、すべてまたはほぼすべてのノードが両方をサポートする必要があることを意味する傾向がありますOAMプロトコル。
The use of tunnels can also degrade network services unless carefully coordinated. For example, a service in the upper layer may be provisioned with protection so that a working and backup path is constructed using diverse paths to make them robust against a single failure. However, the paths of the tunnels (in the lower layer) are not visible to the path computation in the upper layer, with the risk that the upper layer working and protection paths share a single point of failure in the lower layer. Traffic engineering techniques have been developed to resolve this type of issue, but they add significant complexity to a system that would be a simple flat network if only one OAM technology was used.
トンネルを使用すると、注意深く調整しない限り、ネットワークサービスが低下する可能性もあります。たとえば、上位層のサービスに保護をプロビジョニングして、さまざまなパスを使用して現用パスとバックアップパスを構築し、単一の障害に対して堅牢にすることができます。ただし、（下位層の）トンネルのパスは、上位層のパス計算からは見えないため、上位層の現用パスと保護パスが下位層の単一障害点を共有するリスクがあります。トラフィックエンジニアリング技術はこの種の問題を解決するために開発されましたが、OAMテクノロジーを1つだけ使用した場合、単純なフラットネットワークであるシステムにかなりの複雑さを追加します。
Instead of connecting islands with tunnels across the sea, islands of different types can be connected directly so that the LSP or PW transits the series of islands without tunneling. In this case, protocol translation is performed each time the LSP/PW crosses a border between islands that use a different OAM protocol.
島を海を横切るトンネルで接続する代わりに、LSPまたはPWがトンネリングなしで一連の島を通過するように、異なるタイプの島を直接接続できます。この場合、プロトコル変換は、LSP / PWが異なるOAMプロトコルを使用するアイランド間の境界を越えるたびに実行されます。
In principle, this makes for a straightforward end-to-end connection. However, protocol translation presents a number of issues, as described in Section 3. The complexity is that in planning the end-to-end connection, gateways with protocol translation capabilities must be selected to lie on the path.
原則として、これは単純なエンドツーエンド接続になります。ただし、セクション3で説明するように、プロトコル変換には多くの問題があります。複雑なのは、エンドツーエンド接続を計画するときに、プロトコル変換機能を持つゲートウェイをパス上に配置するように選択する必要があることです。
The decision to define and develop an alternative MPLS-TP OAM solution was based on several assertions:
代替のMPLS-TP OAMソリューションを定義および開発する決定は、いくつかの主張に基づいていました。
o The IETF solution is taking too long to standardize.
o IETFソリューションの標準化には時間がかかりすぎています。
o Commonality with Ethernet solutions is beneficial.
o イーサネットソリューションとの共通性は有益です。
o There are two different application scenarios.
o 2つの異なるアプリケーションシナリオがあります。
o There is no risk of interaction between the solutions.
o ソリューション間の相互作用のリスクはありません。
o The market should be allowed to decide between competing solutions.
o 市場は、競合するソリューション間の決定を許可されるべきです。
The following sections look briefly at each of these claims.
次のセクションでは、これらの各主張について簡単に説明します。
The MPLS-TP OAM work carried out within the IETF is the product of joint work within the IETF and ITU-T communities. That is, all interested parties share the responsibility for progressing this work as quickly as possible. Since the work is contribution-driven, there is no reason to assume that consensus on the technical content of the work could be reached any more quickly.
IETF内で実行されるMPLS-TP OAM作業は、IETFおよびITU-Tコミュニティ内の共同作業の成果物です。つまり、すべての利害関係者がこの作業をできるだけ早く進める責任を共有します。作業は寄稿主導型であるため、作業の技術的な内容についてコンセンサスにすぐに到達できると想定する理由はありません。
Opening discussions on a second solution seems certain to increase the workload and will only slow down the speed at which consensus is reached.
2番目のソリューションについての議論を開始することは、ワークロードを確実に増加させるようであり、コンセンサスに達する速度を遅くするだけです。
The core work on MPLS-TP OAM within the IETF was completed, and the specifications were published as RFCs. For more information, see [ISOCAnnounce].
IETF内のMPLS-TP OAMに関するコア作業が完了し、仕様はRFCとして公開されました。詳細については、[ISOCAnnounce]を参照してください。
Ethernet can be used to build packet transport networks, and so there is an argument that Ethernet and MPLS-TP networks will be operated as peers. Examining the issues of end-to-end connections across mixed networks, many of the same issues as those discussed in Section 4 arise. If a peer networking gateway model (see Section 4.3.2.2) is applied, there is a strong argument for making the OAM technologies as similar as possible.
イーサネットはパケット転送ネットワークの構築に使用できるため、イーサネットとMPLS-TPネットワークがピアとして動作するという議論があります。混合ネットワークにわたるエンドツーエンド接続の問題を調べると、セクション4で説明したものと同じ問題の多くが発生します。ピアネットワーキングゲートウェイモデル（セクション4.3.2.2を参照）が適用されている場合、OAMテクノロジをできるだけ類似させることについて強い議論があります。
While this might be a valid discussion point when selecting the single OAM solution for MPLS-TP, it is countered by the need to achieve OAM consistency between MPLS and MPLS-TP networks. One might make the counter-argument that if there is a strong need to make MPLS-TP as similar as possible to Ethernet, it would be better to go the full distance and simply deploy Ethernet.
これは、MPLS-TPの単一のOAMソリューションを選択する際の有効な議論のポイントになるかもしれませんが、MPLSとMPLS-TPネットワーク間でOAMの一貫性を実現する必要があるため、これに対抗します。 MPLS-TPをイーサネットにできるだけ類似させる必要性が強い場合は、完全な距離に移動し、イーサネットを展開する方がよいという反論をするかもしれません。
Furthermore, the approach of a second MPLS-TP OAM protocol does not resolve anything. Since MPLS-TP is not Ethernet, a gateway will still be needed. This would constitute a second MPLS-TP OAM, so additional gateways or interworking functions will be needed because coexistence is inevitable, as described in the rest of this document.
さらに、2番目のMPLS-TP OAMプロトコルのアプローチは何も解決しません。 MPLS-TPはイーサネットではないため、引き続きゲートウェイが必要になります。これは2番目のMPLS-TP OAMを構成します。このドキュメントの残りの部分で説明するように、共存は避けられないため、追加のゲートウェイまたはインターワーキング機能が必要になります。
Additionally, it may be claimed that implementation can be simplified if the OAM solution developed for MPLS-TP is similar to Ethernet OAM. This would apply both in the hardware/software implementing the OAM, and at the server-to-client interface where OAM-induced fault status is reported. The questions here are very much implementation dependent, as the necessary function is contained within individual nodes. The counter-argument is that implementation simplicity can also be achieved by making MPLS-TP OAM similar to MPLS OAM, especially since the client technology may well be IP/MPLS and since MPLS is an end-to-end technology.
さらに、MPLS-TP用に開発されたOAMソリューションがイーサネットOAMに類似している場合は、実装を簡略化できると主張できます。これは、OAMを実装するハードウェア/ソフトウェアと、OAMに起因する障害ステータスが報告されるサーバー/クライアントインターフェイスの両方に適用されます。ここでの質問は、必要な機能が個々のノードに含まれているため、実装に大きく依存します。特にクライアントテクノロジーがIP / MPLSであり、MPLSがエンドツーエンドテクノロジーであるため、MPLS-TP OAMをMPLS OAMと同様にすることで実装の簡素化も実現できるという反論があります。
It has been suggested that two different applications of MPLS-TP exist: Packet Switched Networks (PSNs) and Packet Transport Networks (PTNs). These applications have not been documented in the IETF, and most of the support for this idea has been documented by the ITU-T [TD522].
MPLS-TPには2つの異なるアプリケーションが存在することが示唆されています。パケット交換ネットワーク（PSN）とパケット転送ネットワーク（PTN）です。これらのアプリケーションはIETFで文書化されておらず、このアイデアのサポートのほとんどはITU-T [TD522]によって文書化されています。
One of the stated differences between these applications lies in the OAM tools that are required to support the distinct operational scenarios. The OAM used in a PSN should be similar to that used in an MPLS network (and so should be the MPLS-TP OAM defined in the IETF), while the OAM used in a PTN should provide the same operational experience as that found in SONET/SDH and Optical Transport Networks (OTNs).
これらのアプリケーション間の前述の違いの1つは、個別の運用シナリオをサポートするために必要なOAMツールにあります。 PSNで使用されるOAMは、MPLSネットワークで使用されるOAM（IETFで定義されたMPLS-TP OAMである必要があります）と同様である必要がありますが、PTNで使用されるOAMは、SONETと同じ運用エクスペリエンスを提供する必要があります。 / SDHおよび光伝送ネットワーク（OTN）。
The basic MPLS-TP OAM requirements in [RFC5654] make this point as follows:
[RFC5654]の基本的なMPLS-TP OAM要件は、この点を次のようにしています。
Furthermore, for carriers it is important that operation of such packet transport networks should preserve the look-and-feel to which carriers have become accustomed in deploying their optical transport networks, while providing common, multi-layer operations, resiliency, control, and multi-technology management.
さらに、通信事業者にとって、このようなパケット転送ネットワークの運用は、一般的な多層運用、復元力、制御、およびマルチを提供しながら、光通信ネットワークの展開に慣れてきているルックアンドフィールを維持する必要があります。 -テクノロジー管理。
Thus, the look and feel of the OAM has been a concern in the design of MPLS-TP from the start, and the solutions that have been defined in the IETF were designed to comply with the requirements and to provide operational behavior, functionality, and processes similar to those available in existing transport networks. In particular, the toolset supports the same controls and indications as those present in other transport networks, and the same management information model can be used to support the MPLS-TP OAM tools (in areas where the technology type is irrelevant).
したがって、OAMのルックアンドフィールは当初からMPLS-TPの設計において懸念事項であり、IETFで定義されているソリューションは、要件に準拠し、運用上の動作、機能、および既存のトランスポートネットワークで利用可能なプロセスと同様のプロセス。特に、ツールセットは他のトランスポートネットワークに存在するものと同じコントロールとインジケーションをサポートし、同じ管理情報モデルを使用してMPLS-TP OAMツールをサポートできます（テクノロジータイプが無関係な領域で）。
It is important to note that the operational look and feel does not determine the way in which OAM function is achieved. There are multiple ways of achieving the required functionality while still providing the same operational experience and supporting the same management information model. Thus, the OAM protocol solution does not dictate the look and feel, and the demand for a particular operational experience does not necessitate the development of a second OAM protocol.
操作のルックアンドフィールは、OAM機能の実現方法を決定するものではないことに注意することが重要です。同じ運用エクスペリエンスを提供し、同じ管理情報モデルをサポートしながら、必要な機能を実現する方法は複数あります。したがって、OAMプロトコルソリューションはルックアンドフィールを指示せず、特定の運用経験に対する要求は、2番目のOAMプロトコルの開発を必要としません。
Section 3 of this document discusses how network convergence occurs and indicates that where two MPLS-TP solutions exist, they are in fact very likely to appear either in the same network or at gateways between networks in order to provide end-to-end OAM functionality.
このドキュメントのセクション3では、ネットワークコンバージェンスがどのように発生するかについて説明し、2つのMPLS-TPソリューションが存在する場合、エンドツーエンドのOAM機能を提供するために、同じネットワークまたはネットワーク間のゲートウェイに実際に現れる可能性が高いことを示しています。
Indeed, since nodes offering either solution are likely to both be branded as "MPLS-TP", and since network interoperation (as described in Section 4) demands the existence of some nodes that are either dual-mode or act as protocol translators/gateways, there is considerable likelihood of the two OAM solutions interacting through design or through accident. When a node is capable of supporting both OAM protocols, it must be configured to support the correct protocol for each interface and LSP/PW. When a device has interfaces that offer different MPLS-TP OAM functions, the risk of misconfiguration is significant. When a device is intended to support end-to-end connections, it may need to translate, map, or tunnel to accommodate both protocols.
実際、いずれかのソリューションを提供するノードは両方とも「MPLS-TP」としてブランド化されている可能性があり、ネットワークの相互運用（セクション4で説明）は、デュアルモードまたはプロトコルトランスレータ/ゲートウェイとして機能するノードの存在を要求するため、2つのOAMソリューションが設計または事故によって相互作用する可能性がかなりあります。ノードが両方のOAMプロトコルをサポートできる場合、各インターフェイスとLSP / PWの正しいプロトコルをサポートするようにノードを構成する必要があります。デバイスに異なるMPLS-TP OAM機能を提供するインターフェイスがある場合、設定ミスのリスクが大きくなります。デバイスがエンドツーエンド接続をサポートすることを目的としている場合、両方のプロトコルに対応するために、変換、マッピング、またはトンネリングが必要になる場合があります。
Thus, the very existence of two OAM protocols within the common MPLS-TP family makes copresence and integration most likely.
したがって、一般的なMPLS-TPファミリ内に2つのOAMプロトコルが存在することで、共存と統合が可能になります。
When two technologies compete, it is common to let the market decide which one will survive. Sometimes the resolution is quite fast, and one technology dominates the other before there is widespread deployment. Sometimes it takes considerable time before one technology overcomes the other, perhaps because one technology has become entrenched before the emergence of the other, as in the case of MPLS replacing ATM. In more cases, however, the market does not select in favor of one technology or the other -- as in many of the cases described in Sections 4 and 5 of this document, sometimes both technologies continue to live in the network.
2つのテクノロジーが競合する場合、どちらが生き残るかを市場に決定させるのが一般的です。場合によっては解決が非常に速く、広範囲に展開する前に、1つのテクノロジーが他のテクノロジーよりも優先されます。 ATMに代わるMPLSの場合のように、1つのテクノロジーが他のテクノロジーの出現前に定着したためか、1つのテクノロジーが他のテクノロジーを克服するまでにかなりの時間がかかることがあります。ただし、多くの場合、市場はどちらか一方のテクノロジーを優先して選択しません。このドキュメントのセクション4と5で説明されている多くのケースのように、両方のテクノロジーがネットワークに存在し続ける場合があります。
Letting the market decide is not a cheap option. Even when the resolution is rapid, equipment vendors and early adopters pay the price of both technologies. When it takes longer to determine which technology is correct, there will be a period of coexistence followed by the need to transition equipment from the losing solution to the winning one. In the cases where no choice is made, the network is permanently complicated by the existence of the competing technologies.
市場に決定させることは、安価な選択肢ではありません。解決が迅速な場合でも、機器ベンダーとアーリーアダプターは両方のテクノロジーの価格を支払います。どのテクノロジーが正しいかを判断するのに時間がかかる場合は、共存の期間があり、その後、敗者のソリューションから勝者のソリューションに機器を移行する必要があります。選択の余地がない場合、ネットワークは競合するテクノロジーの存在によって永続的に複雑になります。
In fact, the only time when allowing the market to decide can be easily supported is when the competing technologies do not overlap. In those cases -- for example, different applications in the user space -- the core network is not perturbed by the decision-making process, and transition from one technology to the other is relatively painless. This is not the case for MPLS-TP OAM; coexistence while the market determines the correct approach would be expensive, while the necessary transition after the decision has been made would be difficult and costly.
実際、市場が簡単にサポートできるのは、競合するテクノロジーが重複しない場合だけです。このような場合（たとえば、ユーザー空間でのさまざまなアプリケーション）、コアネットワークは意思決定プロセスの影響を受けず、あるテクノロジから別のテクノロジへの移行は比較的簡単です。これはMPLS-TP OAMには当てはまりません。市場が正しいアプローチを決定する間の共存は費用がかかりますが、決定が行われた後の必要な移行は困難で費用がかかります。
This informational document does not introduce any security issues.
この情報ドキュメントでは、セキュリティの問題は紹介されていません。
However, it should be noted that the existence of two OAM protocols raises a number of security concerns:
ただし、2つのOAMプロトコルが存在すると、多くのセキュリティ上の問題が発生することに注意してください。
o Each OAM protocol must be secured. This leads to the existence of two security solutions that each need configuration and management. The increased complexity of operating security mechanisms tends to reduce the likelihood of them being used in the field and so increases the vulnerability of the network. Similarly, the existence of two security mechanisms raises the risk of misconfiguration.
o 各OAMプロトコルを保護する必要があります。これにより、それぞれに構成と管理が必要な2つのセキュリティソリューションが存在します。運用セキュリティメカニズムの複雑さが増すと、現場で使用される可能性が低くなる傾向があり、ネットワークの脆弱性が高まります。同様に、2つのセキュリティメカニズムが存在すると、設定ミスのリスクが生じます。
o One OAM protocol may be used as a vector to attack the other. Inserting an OAM message of the other OAM protocol onto a link may cause the service to be disrupted and, because some nodes may support both OAM protocols, it may be possible to cause the disruption at a remote point in the network.
o 一方のOAMプロトコルは、もう一方を攻撃するベクトルとして使用される可能性があります。他のOAMプロトコルのOAMメッセージをリンクに挿入すると、サービスが中断する可能性があります。また、一部のノードが両方のOAMプロトコルをサポートしている場合があるため、ネットワークのリモートポイントで中断が発生する可能性があります。
o Securing a network protocol is not a trivial matter for protocol designers. Duplicating design effort is unlikely to result in a stronger solution and runs the risk of diluting the effort and creating two less-secure solutions.
o ネットワークプロトコルのセキュリティ保護は、プロトコル設計者にとって簡単なことではありません。設計作業を複製しても、より強力なソリューションが得られる可能性は低く、作業を希釈して2つの安全性の低いソリューションを作成するリスクがあります。
Thanks to Brian Carpenter, Tom Petch, Rolf Winter, Alexander Vainshtein, Ross Callon, Malcolm Betts, and Martin Vigoureux for their review and useful comments.
レビューと有益なコメントを提供してくれたBrian Carpenter、Tom Petch、Rolf Winter、Alexander Vainshtein、Ross Callon、Malcolm Betts、Martin Vigoureuxに感謝します。
Thanks to Huub van Helvoort for supplying text and history about SONET/SDH.
SONET / SDHに関するテキストと履歴を提供してくれたHuub van Helvoortに感謝します。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、and S. Ueno、 "Requirements of an MPLS Transport Profile"、RFC 5654 、2009年9月。
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860] Vigoureux、M.、Ed。、Ward、D.、Ed。、and M. Betts、Ed。、 "Requirements for Operations、Administration、and Maintenance（OAM）in MPLS Transport Networks"、RFC 5860、May 2010 。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]カーペンター、B。、編、「インターネットのアーキテクチャ原則」、RFC 1958、1996年6月。
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.
[RFC4553] Vainshtein、A.、Ed。、およびYJ。スタイン編、「構造にとらわれない時分割多重（TDM）over Packet（SAToP）」、RFC 4553、2006年6月。
[RFC4929] Andersson, L., Ed., and A. Farrel, Ed., "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007.
[RFC4929] Andersson、L.、Ed。、and A. Farrel、Ed。、 "Change Process for Multiprotocol Label Switching（MPLS）and Generalized MPLS（GMPLS）Protocols and Procedures"、BCP 129、RFC 4929、June 2007。
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, December 2007.
[RFC5086] Vainshtein、A.、Ed。、Sasson、I.、Metz、E.、Frost、T.、and P. Pate、 "Structure-Aware Time Division Multiplexed（TDM）Circuit Emulation Service over Packet Switched Network（CESoPSN ） "、RFC 5086、2007年12月。
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, December 2007.
[RFC5087] Stein、Y（J）。、Shashoua、R.、Insler、R.、and M. Anavi、 "Time Division Multiplexing over IP（TDMoIP）"、RFC 5087、December 2007。
[RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
[RFC5317] Bryant、S.、Ed。およびL. Andersson、Ed。、 "Joint Working Team（JWT）Report on MPLS Architectural Considerations for a Transport Profile"、RFC 5317、2009年2月。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、and L. Berger、 "A Framework for MPLS in Transport Networks"、RFC 5921、 2010年7月。
[OAM-OVERVIEW] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", Work in Progress, March 2012.
[OAM-OVERVIEW]ミズラヒ、T。、スプレッチャー、N。、ベラガンバ、E。、およびY.ウェインガルテン、「運用、管理、および保守（OAM）メカニズムの概要」、進行中の作業、2012年3月。
[Y.Sup4] "Supplement on transport requirements for T-MPLS OAM and considerations for the application of IETF MPLS technology", ITU-T Y.1300-series Supplement 4, January 2008.
[Y.Sup4]「T-MPLS OAMのトランスポート要件に関する補足とIETF MPLSテクノロジーの適用に関する考慮事項」、ITU-T Y.1300シリーズ補足4、2008年1月。
[G.707] "Network node interface for the synchronous digital hierarchy (SDH)", ITU-T Recommendation G.707, January 2007.
[G.707]「同期デジタル階層（SDH）のネットワークノードインターフェイス」、ITU-T勧告G.707、2007年1月。
[TD7] "IETF and ITU-T cooperation on extensions to MPLS for transport network functionality", ITU-T TD7 (WP3/SG15), December 2008.
[TD7]「トランスポートネットワーク機能のためのMPLSの拡張に関するIETFとITU-Tの連携」、ITU-T TD7（WP3 / SG15）、2008年12月。
[TD522] "Clarification of the PTN/solution X environment", ITU-T TD522 (WP3/SG15), February 2011.
[TD522]「PTN /ソリューションX環境の明確化」、ITU-T TD522（WP3 / SG15）、2011年2月。
[LS26] "Cooperation Between IETF and ITU-T on the Development of MPLS-TP", ITU-T COM 15-LS26-E, December 2008, <http://datatracker.ietf.org/documents/LIAISON/ file596.pdf>.
[LS26]「MPLS-TPの開発に関するIETFとITU-Tの協力」、ITU-T COM 15-LS26-E、2008年12月、<http://datatracker.ietf.org/documents/LIAISON/ file596。 pdf>。
[DesignReport] "MPLS-TP OAM Analysis", Proc. IETF 75, Stockholm, Sweden, July 2009, <http://www.ietf.org/proceedings/75/slides/ mpls-17/mpls-17_files/frame.htm>.
[DesignReport]「MPLS-TP OAM Analysis」、Proc。 IETF 75、ストックホルム、スウェーデン、2009年7月、<http://www.ietf.org/proceedings/75/slides/ mpls-17 / mpls-17_files / frame.htm>。
[ISOCAnnounce] "Milestone Achieved in Internet Carrier Network Standards - Multiprotocol Label Switching Transport Profile (MPLS-TP) Specifications Published", Internet Society, December 2011, <http://www.isoc.org/standards/mpls.shtml>.
[ISOCAnnounce]「インターネットキャリアネットワーク標準で達成されたマイルストーン-マルチプロトコルラベルスイッチングトランスポートプロファイル（MPLS-TP）仕様の公開」、Internet Society、2011年12月、<http://www.isoc.org/standards/mpls.shtml>。
It is, of course, right to observe that there are a number of instances of multiple protocols serving the same purpose that have arisen within the Internet. It is valuable to examine these examples to understand what issues they have caused and how they have been mitigated.
もちろん、インターネット内で発生した、同じ目的を果たす複数のプロトコルのインスタンスが多数あることを観察することは正しいことです。これらの例を調べて、どのような問題が発生し、どのように軽減されたかを理解することは重要です。
IS-IS and OSPF are two competing link-state IGP routing protocols that derive from the same root technology and that, for political and personality reasons, were never reconciled prior to wide-scale deployment. It is an accident of history that one of these protocols did not gain overwhelming deployment and so force the other into retirement.
IS-ISとOSPFは、同じルートテクノロジーから派生した2つの競合するリンクステートIGPルーティングプロトコルであり、政治的および人格上の理由から、大規模な展開の前に調整されたことはありません。これらのプロトコルの1つが圧倒的な展開を実現できなかったため、もう1つのプロトコルを強制的に廃止したのは、歴史の偶然です。
The existence of these two widely deployed and highly functional competing IGPs doubles the cost of link-state IGP maintenance and deployment in the Internet. This is a situation that will almost certainly continue for the lifetime of the Internet. Although the Internet is clearly successful and operates well, the existence of these two IGPs forces router vendors to implement both protocols (doubling the protocol cost of all routers even when an operator only wants to deploy one of the protocols), forcing the operator to make an active choice between IGPs during deployment and requiring a gateway function between the islands of protocol use.
これらの2つの広く展開され、機能性の高い競合IGPが存在すると、リンクステートIGPのメンテナンスとインターネットでの展開のコストが2倍になります。これは、ほぼ確実にインターネットの存続期間中続く状況です。インターネットは明らかに成功し、うまく機能していますが、これら2つのIGPの存在により、ルーターベンダーは両方のプロトコルを実装する必要があり（オペレーターがプロトコルの1つのみを展開したい場合でも、すべてのルーターのプロトコルコストが2倍になります）、オペレーターは展開中のIGP間のアクティブな選択であり、プロトコル使用のアイランド間のゲートウェイ機能を必要とします。
A mitigating factor in this specific case is that, owing to the way networks are partitioned for administrative and scaling reasons, there already existed a gateway routing protocol called BGP that propagates a summarized form of the IGP reachability information throughout the Internet. BGP means that there is actually no requirement for IS-IS and OSPF to interwork directly: that is, there is no need for a translation function between OSPF and IS-IS, and the two IGPs can continue to exist without impacting the function of the Internet. Thus, unlike the situation with MPLS OAM, the choice of IGP protocol is truly a local decision; however, there is a cost to BGP implementations that must support interactions with both OSPF and IS-IS.
この特定の場合の問題を緩和する要素は、管理上およびスケーリング上の理由でネットワークが分割される方法のために、IGP到達可能性情報の要約された形式をインターネット全体に伝搬するBGPと呼ばれるゲートウェイルーティングプロトコルがすでに存在していたことです。 BGPは、実際にIS-ISとOSPFが直接相互作用する必要がないことを意味します。つまり、OSPFとIS-ISの間の変換機能は必要なく、2つのIGPは、機能に影響を与えずに存在し続けることができます。インターネット。したがって、MPLS OAMの状況とは異なり、IGPプロトコルの選択は本当にローカルな決定です。ただし、OSPFとIS-ISの両方との相互作用をサポートする必要があるBGP実装にはコストがかかります。
The IETF's PWE3 working group has published the specification of three different TDM PW types. This happened after considerable effort to reach a compromise failed to reduce the set of options.
IETFのPWE3ワーキンググループは、3つの異なるTDM PWタイプの仕様を公開しています。これは、妥協案に到達するためのかなりの努力がオプションのセットを減らすことに失敗した後に起こりました。
o SAToP is a relatively simple design. It is a Proposed Standard RFC [RFC4553] and is the mandatory-to-implement, default mode of operation.
o SAToPは比較的シンプルなデザインです。これはProposed Standard RFC [RFC4553]であり、実装が必須のデフォルトの動作モードです。
o CESoPSN [RFC5086] and TDMoIP [RFC5087] are more complex approaches with different degrees of bandwidth efficiency optimized for different applications. They are both published as Informational RFCs.
o CESoPSN [RFC5086]とTDMoIP [RFC5087]は、さまざまなアプリケーション向けに最適化されたさまざまな程度の帯域幅効率を持つ、より複雑なアプローチです。どちらも情報RFCとして公開されています。
In this case, all implementations must include the default mode of operation (SAToP). This means that end-to-end operation is guaranteed: an operator can select equipment from any vendor in the knowledge that he will be able to build and operate an end-to-end TDM PW service.
この場合、すべての実装にデフォルトの操作モード（SAToP）を含める必要があります。つまり、エンドツーエンドの運用が保証されます。オペレーターは、エンドツーエンドのTDM PWサービスを構築および運用できるという知識のもとに、任意のベンダーから機器を選択できます。
If an operator wishes to deploy a TDM PW optimized for a specific application, he may select equipment from a vendor offering CESoPSN or TDMoIP in addition to SAToP. Provided that all of his equipment and his management system can handle the optimized approach, he can run this in his network, but he has to carry the cost of selecting, purchasing, configuring, and operating the extended mode of operation.
オペレーターが特定のアプリケーション用に最適化されたTDM PWを展開したい場合は、SAToPに加えてCESoPSNまたはTDMoIPを提供するベンダーから機器を選択できます。すべての機器と管理システムが最適化されたアプローチを処理できる場合、これをネットワークで実行できますが、拡張操作モードの選択、購入、構成、および操作のコストを負担する必要があります。
This situation is far from ideal, and it is possible that long-distance, multi-operator optimized TDM PWs cannot be achieved. However, the existence of a default mode implemented in all devices helps to reduce pain for the operator and ensures that simpler end-to-end operation is always available. Additionally, the growth of other protocols is acting to diminish the use of long-distance TDM circuits, making this a self-limiting problem.
この状況は理想とはほど遠く、長距離のマルチオペレーター最適化TDM PWを実現できない可能性があります。ただし、すべてのデバイスに実装されているデフォルトモードの存在は、オペレーターの負担を軽減するのに役立ち、シンプルなエンドツーエンドの操作を常に利用できるようにします。さらに、他のプロトコルの成長により、長距離TDM回路の使用が減り、これが自己制限的な問題になっています。
The n-squared codec interworking problem was brought to the attention of the IETF by the ITU-T when the IETF started its work on a royalty-free codec suitable for use in the Internet. Every time a new codec is deployed, translation between it and all other deployed codecs must be available within the network; each participating node must be able to handle the new codec. Translation between codecs is expensive and can lead to reduced quality.
n二乗コーデックインターワーキング問題は、IETFがインターネットでの使用に適した使用料無料のコーデックの開発に着手したときに、ITU-TによってIETFの注意を引きました。新しいコーデックが展開されるたびに、それと他のすべての展開されたコーデックとの間の変換がネットワーク内で利用可能である必要があります。参加する各ノードは、新しいコーデックを処理できる必要があります。コーデック間の変換は高価であり、品質の低下につながる可能性があります。
This problem seriously constrains the addition of new codecs to the available set, and new codecs are only designed and released when there is a well-established need (such as a major difference in functionality).
この問題は、利用可能なセットへの新しいコーデックの追加に深刻な制約を課し、新しいコーデックは、十分に確立されたニーズ（機能の大きな違いなど）がある場合にのみ設計およびリリースされます。
The application layer of the Internet is, however, predicated on a business model that allows for the use of shared, free, and open-source software; this model requires the existence of a royalty-free codec. This, together with the specific characteristics of transmission over lossy packet networks, comprised requirements equivalent to a major difference in functionality and led to work in the IETF to specify a new codec.
ただし、インターネットのアプリケーション層は、共有された無料のオープンソースソフトウェアの使用を可能にするビジネスモデルに基づいています。このモデルでは、ロイヤルティフリーのコーデックが必要です。これは、損失の多いパケットネットワークを介した伝送の特定の特性とともに、機能の大きな違いに相当する要件を含み、IETFで新しいコーデックを指定する作業につながりました。
The complexity, economic, and quality costs associated with interworking with this new codec will need to be factored into the deployment model. This, in turn, may adversely affect its adoption and the viability of its use in the Internet.
この新しいコーデックとの相互作用に関連する複雑さ、経済性、および品質のコストは、展開モデルに織り込む必要があります。これは、その採用とインターネットでの使用の実行可能性に悪影響を与える可能性があります。
There are three MPLS signaling control protocols used for distributing labels to set up LSPs and PWs in MPLS networks: LDP, RSVP - Traffic Engineering (RSVP-TE), and GMPLS.
MPLSネットワークでLSPとPWを設定するためにラベルを配布するために使用される3つのMPLSシグナリング制御プロトコル：LDP、RSVP-トラフィックエンジニアリング（RSVP-TE）、およびGMPLS。
The application domain for each of these protocols is different, and unlike the OAM situation, there is limited requirement for interworking between the protocols. For example, although one provider may use LDP to set up LSPs while its peer uses RSVP-TE, connectivity between the two providers usually takes place at the IP layer.
これらの各プロトコルのアプリケーションドメインは異なり、OAMの状況とは異なり、プロトコル間の相互作用の要件は限られています。たとえば、1つのプロバイダーがLDPを使用してLSPをセットアップする一方で、ピアがRSVP-TEを使用している場合でも、通常、2つのプロバイダー間の接続はIPレイヤーで行われます。
It should be noted that the IETF initially worked on another signaling protocol called Constraint-based Routed LDP (CR-LDP) with variants applicable to MPLS and GMPLS. The development of this protocol was allowed to progress in parallel with RSVP-TE. However, once it was possible to determine that the solution preferred by the community of vendors and operators was RSVP-TE, the IETF terminated all further work on CR-LDP. No translation function or gateway point interfacing RSVP-TE to CR-LDP was ever proposed.
IETFは当初、MPLSおよびGMPLSに適用可能なバリアントを備えた制約ベースのルーテッドLDP（CR-LDP）と呼ばれる別のシグナリングプロトコルに取り組んだことに注意してください。このプロトコルの開発は、RSVP-TEと並行して進めることができました。ただし、ベンダーおよびオペレーターのコミュニティーが好むソリューションがRSVP-TEであると判断できると、IETFはCR-LDPに関するすべての作業を終了しました。 RSVP-TEからCR-LDPへのインターフェイスとなる変換機能またはゲートウェイポイントはこれまで提案されていません。
If there were ever an example of why protocol interworking is to be avoided if at all possible, it is the transition from IPv4 to IPv6.
プロトコルインターワーキングが可能な限り回避される理由の例があった場合、それはIPv4からIPv6への移行です。
The reasons for introducing IPv6 into the Internet are well known and don't need discussion here. IPv6 was not introduced as a competitor to IPv4 but rather as a planned replacement. The need for the transition to IPv6 arose from the expansion of the network size beyond the wildest dreams of the creators of the Internet and from the consequent depletion of the IPv4 address space.
IPv6をインターネットに導入する理由はよく知られているため、ここで説明する必要はありません。 IPv6は、IPv4の競合製品としてではなく、計画的な代替製品として導入されました。 IPv6への移行の必要性は、インターネットの作成者が思い描いていた夢を超えたネットワークサイズの拡大と、その結果として生じるIPv4アドレス空間の枯渇から生じました。
This transition has proved to be the hardest problem that the IETF has ever addressed. The invention and standardization of IPv6 were straightforward by comparison, but it has been exceptionally difficult to migrate networks from one established protocol to a new protocol.
この移行は、IETFがこれまでに対処した最も困難な問題であることが証明されています。比較すると、IPv6の発明と標準化は単純明快でしたが、1つの確立されたプロトコルから新しいプロトコルにネットワークを移行することは非常に困難でした。
The early assumption that by the time the IPv4 address space was exhausted IPv6 would be universally deployed failed to materialize due to (understandable) short-term economic constraints. Early migration would have been simpler and less costly than the current plans. The Internet is now faced with the considerable complexity of implementing and deploying interworking functions.
IPv4アドレス空間が使い果たされるまでにIPv6が普遍的に配備されるという初期の仮定は、（理解できる）短期的な経済的制約のために実現できませんでした。初期の移行は、現在の計画よりも単純で、コストも低くなっていました。インターネットは現在、インターワーキング機能の実装と展開のかなりの複雑さに直面しています。
If anything can be learned from the IPv4/IPv6 experience, it is that every effort should be applied to avoid the need to migrate or jointly operate two protocols within one network. Adding to the mix, a number of issues caused by OAM interworking of MPLS, one of the Internet's core protocols, would be most unwelcome and would complicate matters still further.
IPv4 / IPv6の経験から何かを学ぶことができれば、1つのネットワーク内で2つのプロトコルを移行または共同で運用する必要性を回避するためにあらゆる努力が払われるべきです。加えて、インターネットのコアプロトコルの1つであるMPLSのOAMインターワーキングによって引き起こされる多くの問題は、最も歓迎されず、問題をさらに複雑にします。
SONET and SDH were defined as competing standards that basically provided the same functionality (simultaneous transport of multiple circuits of differing origin within a single framing protocol). SONET was developed first by ANSI, based on the 24-channel PDH hierarchy existing in North America and Japan. The basic rate is based on DS3. Some time later, ETSI developed SDH based on the 30-channel PDH deployed in Europe. The basic rate is based on E4 (3x DS3). The key difference between PDH and SDH is that the "S" stands for "synchronous" and the "P" for "plesiochronous". Thus, the difference between the technologies is timing related.
SONETとSDHは、基本的に同じ機能を提供する競合する標準として定義されました（単一のフレーミングプロトコル内で異なる発信元の複数の回線を同時に転送）。 SONETは、北米と日本に存在する24チャネルPDH階層に基づいて、ANSIによって最初に開発されました。基本レートはDS3に基づいています。しばらくして、ETSIはヨーロッパに展開された30チャネルPDHに基づいてSDHを開発しました。基本レートはE4（3x DS3）に基づいています。 PDHとSDHの主な違いは、「S」が「同期」を表し、「P」が「プレシオクロナス」を表すことです。したがって、テクノロジー間の違いはタイミングに関連しています。
SONET was adopted in the U.S., Canada, and Japan, and SDH in the rest of the world.
SONETは米国、カナダ、日本で採用され、SDHはその他の国で採用されました。
Until 1988, the standards were unpublished and under development.
1988年まで、標準は非公開で開発中でした。
o The SONET standard ANSI T1.105-1988 was published in 1988.
o SONET標準ANSI T1.105-1988は1988年に公開されました。
o The SDH standard ETSI EN 300 417 was first published in 1992.
o SDH標準ETSI EN 300 417は、1992年に最初に公開されました。
o The compromise SDH/SONET standard ITU-T G.707 was published in 1988 (see below for the nature of this compromise).
o 妥協SDH / SONET標準ITU-T G.707は1988年に公開されました（この妥協の性質については以下を参照してください）。
Some implementers were confused by this situation. Equipment manufacturers initially needed to select the market segment they intended to address. The cost of chipsets for a limited market increased, and only a limited number of equipment manufacturers were available for selection in each market.
一部の実装者はこの状況で混乱しました。機器メーカーは当初、対象とする市場セグメントを選択する必要がありました。限られた市場向けのチップセットのコストは増加し、限られた数の機器メーカーのみが各市場で選択できました。
Obviously, most equipment vendors wanted to sell their equipment in both regions. Hence, today most chips support both SONET and SDH, and the selection is a matter of provisioning. The impact of the additional function to support both markets has had a mixed impact on cost. It has enabled a higher volume of production, which reduced cost, but it has required increased development and complexity, which increased cost.
明らかに、ほとんどの機器ベンダーは両方の地域で機器を販売したいと考えていました。したがって、今日のほとんどのチップはSONETとSDHの両方をサポートしており、選択はプロビジョニングの問題です。両方の市場をサポートする追加機能の影響は、コストにさまざまな影響を及ぼしました。大量生産が可能になり、コストが削減されましたが、開発と複雑さが増し、コストが増加しました。
Because the regions of applicability of SONET and SDH are well known, service providers do not need to consider the merits of the two standards and their long-term role in the industry when examining their investment options.
SONETとSDHの適用範囲はよく知られているので、サービスプロバイダーは、2つの規格のメリットと、業界での長期的な役割を検討して投資オプションを検討する必要はありません。
To be able to deploy SONET and SDH worldwide, the regional SDO experts came together in the ITU-T to define a frame structure and a frame rate that would allow interconnection of SONET and SDH. A compromise was agreed upon and approved in an ITU-T meeting in Seoul in 1988.
SONETとSDHを世界中に展開できるようにするため、地域のSDOエキスパートがITU-Tに集まり、SONETとSDHの相互接続を可能にするフレーム構造とフレームレートを定義しました。 1988年にソウルで開催されたITU-T会議で妥協案が合意され、承認されました。
The SDH standard supports both the North American and Japanese 24-channel/T1/T3 hierarchy and the European 30-channel/E1/E4-based hierarchy within a single multiplexing structure. SDH has options for payloads at VC-4 (150 Mb/s) and above. SDH allows T1/T3 services to be delivered in Europe and E1 services to be delivered in North America using a common infrastructure.
SDH規格は、北米と日本の24チャネル/ T1 / T3階層とヨーロッパの30チャネル/ E1 / E4ベースの階層を単一の多重化構造内でサポートします。 SDHには、VC-4（150 Mb / s）以上のペイロードのオプションがあります。 SDHでは、共通のインフラストラクチャを使用して、T1 / T3サービスをヨーロッパで、E1サービスを北米で配信できます。
Deployment of an E1-only standard in North America would have required the conversion of all of the 24-channel/T1 deployed equipment and services into the 30-channel/E1 format. Similarly, deployment of a T1-only standard in Europe would have required the conversion of all of the 30-channel/E1 equipment and services into the 24-channel/T1 format. Clearly, given the existing network deployments (in 1988), this was not a practical proposition and was the principal reason why a compromise was reached.
北米でE1のみの標準を展開するには、24チャネル/ T1で展開されたすべての機器とサービスを30チャネル/ E1形式に変換する必要がありました。同様に、ヨーロッパでT1のみの標準を導入するには、30チャネル/ E1の機器とサービスをすべて24チャネル/ T1形式に変換する必要がありました。明らかに、既存のネットワーク展開（1988年）を考えると、これは実用的な提案ではなく、妥協点に達した主な理由でした。
The result of the compromise is documented in ITU-T Recommendation G.707 [G.707], which includes the frame definition and frame rates and also documents how SONET and SDH can interconnect.
妥協の結果は、ITU-T勧告G.707 [G.707]に文書化されています。これには、フレーム定義とフレームレートが含まれ、SONETとSDHの相互接続方法も文書化されています。
An extensive interworking function had to be implemented in order to provide global connectivity (e.g., throughout the U.S. and Europe), and this resulted in an increase in operational overhead. The interworking function has to be performed before the SDH-based segment is reached. The reason for placing the interworking function on the SONET side was that in a previous agreement on interconnection the functionality was placed on the European side.
グローバルな接続性を提供するために（たとえば、米国とヨーロッパ全体で）広範なインターワーキング機能を実装する必要があり、これにより運用上のオーバーヘッドが増加しました。インターワーキング機能は、SDHベースのセグメントに到達する前に実行する必要があります。インターワーキング機能をSONET側に配置した理由は、相互接続に関する以前の合意では、機能がヨーロッパ側に配置されていたためです。
IEEE 802.16d and IEEE 802.16e were two different, incompatible iterations of the Worldwide Interoperability for Microwave Access (WiMAX) standards. In addition to the issues described for SONET/ SDH, developers who implemented IEEE 802.16d found that they could not reuse their equipment design when developing the IEEE 802.16e variant. This increased the cost of development and lengthened the time to market.
IEEE 802.16dとIEEE 802.16eは、Microwave Access（WiMAX）規格のWorldwide Interoperabilityの互換性のない2つの異なるバージョンです。 SONET / SDHについて説明した問題に加えて、IEEE 802.16dを実装した開発者は、IEEE 802.16eバリアントの開発時に機器設計を再利用できないことに気付きました。これにより、開発コストが増加し、市場投入までの時間が長くなりました。
Code Division Multiple Access (CDMA) and the Global System for Mobile Communications (GSM) are two competing technologies for mobile connectivity.
コード分割多重アクセス（CDMA）とグローバルシステムモバイルコミュニケーション（GSM）は、モバイル接続のための2つの競合するテクノロジーです。
In addition to all the undesirable effects described above, the existence of these two technologies adversely affected customers who used roaming when overseas. Sometimes, customers were obliged to obtain an additional device from their service providers in order to roam when traveling abroad (for example, when traveling from Europe to the U.S.).
上記のすべての望ましくない影響に加えて、これら2つのテクノロジーの存在は、海外でローミングを使用する顧客に悪影響を及ぼしました。場合によっては、海外旅行中（たとえば、ヨーロッパから米国への旅行中）にローミングするために、顧客がサービスプロバイダーから追加のデバイスを取得する必要がありました。
Authors' Addresses
著者のアドレス
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 Israel
ぬりｔ Ｓｐれちぇｒ のきあ しえめんｓ ねとぉｒｋｓ ３ はながｒ Ｓｔ。 ねゔぇ ね’えまん Ｂ ほｄ はしゃろん ４５２４１ いｓらえｌ
EMail: nurit.sprecher@nsn.com
Kyung-Yeop Hong Cisco Systems 300 Beaver Brook Road Boxborough, Massachusetts 01719 USA
Kyung-Yeop Hong Cisco Systems 300 Beaver Brook Road Boxborough、Massachusetts 01719 USA
EMail: hongk@cisco.com