[要約] 要約：RFC 5704は、協調しないプロトコル開発が問題を引き起こす可能性があることを指摘している。 目的：プロトコル開発者に、協調したアプローチを取ることの重要性を認識させる。
Network Working Group S. Bryant, Ed.
Request for Comments: 5704 M. Morrow, Ed.
Category: Informational For the IAB
November 2009
Uncoordinated Protocol Development Considered Harmful
調整されていないプロトコル開発は有害と見なされました
Abstract
概要
This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.
このドキュメントは、標準開発組織（SDO）間の相互関心のプロトコルに関する正式な調整と共同開発の欠如に起因する可能性のある問題を特定します。これらの問題のいくつかは、インターネットに大きな害を及ぼす可能性があります。このドキュメントは、堅牢な手順が必要であることが、将来これが発生するのを防ぐことを示唆しています。IABは、プロトコルの非協調的適応に起因するインターネットアーキテクチャの危険性を説明する最近の例として、トランスポートMPL（T-MPLS）などの多くのケーススタディを選択しました。
This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs.
この経験により、IETFとITU-Tの関係が大幅に改善されました。特に、これは「MPLS-TPの共同作業チーム」の設立によって達成されました。さらに、2つの組織のリーダーシップは、ITU-Tの推奨事項とIETF RFCの間の将来の紛争を回避するために、組織間の労働慣行を改善することに同意しました。
Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF.
これらのケーススタディでITU -T -IETF相互作用を使用しますが、ドキュメントの範囲は、IETFと重複するプロトコルの関心を持つすべてのSDOに拡張されます。
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 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 BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Protocol Design Rules ...........................................3
2.1. Protocol Safety ............................................3
2.2. Importance of Invariants ...................................4
2.3. Importance of Correct Identification .......................4
2.4. The Role of the Design Authority ...........................4
2.5. Ships in the Night .........................................5
3. Examples of Miscoordination .....................................6
3.1. T-MPLS as a Case Study .....................................6
3.2. PPP over SONET/SDH (Synchronous Optical Network /
Synchronous Digital Hierarchy ..............................6
4. Managing Information Flow .......................................7
4.1. Managing Information Flow within an SDO ....................7
4.2. Managing Information Flow between SDOs .....................7
5. MPLS-TP as Best Practice ........................................7
6. IETF Change Process .............................................8
7. Security Considerations .........................................8
8. Acknowledgments .................................................8
9. IAB Members at the Time of This Writing .........................8
10. Emerging Issues ................................................9
11. Conclusion .....................................................9
12. Informative References .........................................9
Appendix A. A Review of the T-MPLS Case ..........................12
A.1. Multiple Definitions of Label 14 ..........................12
A.2. Redefinition of TTL Semantics .............................13
A.3. Reservation of Additional Labels ..........................13
A.4. Redefinition of MPLS EXP Bits .............................14
A.5. The Consequences for the Network Operators ................14
A.6. The Consequences for the SDOs .............................15
The uncoordinated adaptation of a protocol, parameter, or code-point by a standards development organization (SDO), either through the allocation of a code-point without following the formal registration procedures or by unilaterally modifying the semantics of the protocol or intended use of the code-point itself, poses a risk of harm to the Internet [RFC4775].
正式な登録手順に従うことなく、またはプロトコルのセマンティクスを一方的に変更することによるコードポイントの割り当てを通じて、標準開発組織（SDO）によるプロトコル、パラメーター、またはコードポイントの非調整的な適応コードポイント自体は、インターネットに危害のリスクをもたらします[RFC4775]。
The purpose of this document is to describe the various problems that may occur without formal coordination and joint development on protocols of mutual interest between SDOs. Some of the problems that arise may cause significant harm to the Internet. In particular, the IAB considers it an essential principle of the protocol development process that only one SDO maintains design authority for a given protocol, with that SDO having ultimate authority over the allocation of protocol parameter code-points and over defining the intended semantics, interpretation, and actions associated with those code-points.
このドキュメントの目的は、SDO間の相互関心のプロトコルに関する正式な調整と共同開発なしに発生する可能性のあるさまざまな問題を説明することです。発生する問題のいくつかは、インターネットに大きな害を及ぼす可能性があります。特に、IABは、それをプロトコル開発プロセスの本質的な原則と考えています。SDOのみが特定のプロトコルの設計権を維持しているのは、そのSDOがプロトコルパラメーターコードポイントの割り当てと意図されたセマンティクスの定義、解釈について究極の権限を持っていることです。、およびそれらのコードポイントに関連するアクション。
There is currently a joint IETF - ITU-T development effort underway, known as the MPLS Transport Profile (MPLS-TP), which is progressing rapidly to extend MPLS in a way that is consistent with the MPLS architecture, and fully satisfies the requirements of the transport network provider [LS26]. By way of a case study, we will refer to the design and standardization process of the ITU-T protocol known as Transport MPLS (T-MPLS). Development of T-MPLS was abandoned [RFC5317] by ITU-T Study Group 15 due to inherent conflicts with the IETF MPLS design and, in particular, with the Internet architecture. These conflicts arose due to the lack of coordination with the IETF as the design authority for MPLS.
現在、MPLSトランスポートプロファイル（MPLS-TP）として知られるITU-T開発作業が進行中です。MPLSアーキテクチャと一致する方法でMPLSを拡張し、の要件を完全に満たすために急速に進行しています。輸送ネットワークプロバイダー[LS26]。ケーススタディとして、Transport MPLS（T-MPLS）として知られるITU-Tプロトコルの設計と標準化プロセスを参照します。T-MPLSの開発は、IETF MPLS設計、特にインターネットアーキテクチャとの固有の競合により、ITU-T研究グループ15によって放棄されました[RFC5317]。これらの紛争は、MPLSの設計権限としてのIETFとの調整がないために発生しました。
The goal of this document is to demonstrate the importance of a coordinated approach to successful collaboration between SDOs, and to explain a model for inter-SDO collaborative protocol development that is being used successfully by the ITU-T and IETF.
このドキュメントの目標は、SDO間のコラボレーションを成功させるための調整されたアプローチの重要性を実証し、ITU-TとIETFによって正常に使用されているSDO間共同プロトコル開発のモデルを説明することです。
This section describes a number of protocol design rules needed to ensure the safe operation of a network. Whilst these rules will be familiar to many protocol designers, the rules are restated here to ensure that assumptions are clear and consistent. Differing assumptions have been at the root of many miscoordinations and miscommunications between SDOs in the past.
このセクションでは、ネットワークの安全な動作を確保するために必要な多くのプロトコル設計ルールについて説明します。これらのルールは多くのプロトコル設計者に馴染みがありますが、ここでは、仮定が明確かつ一貫していることを確認するためにルールがここで修正されています。異なる仮定は、過去のSDO間の多くの誤解と誤解の根本にありました。
To understand the reasons why the IAB and IETF regard uncoordinated use of code-points and/or protocol modification as posing a risk of harm to the Internet, it is necessary to recap some important principles of protocol design in large-scale networks such as the Internet. Many end users and businesses have come to rely on the Internet as part of their critical infrastructure, thus large-scale networks, such as the Internet, represent significant economic value. Any outage in a large-scale network due to a protocol failure will therefore result in significant commercial and political damage.
IABとIETFがコードポイントおよび/またはプロトコルの変更の非調整された使用をインターネットに危害のリスクをもたらすと見なす理由を理解するには、大規模なネットワークのプロトコル設計の重要な原則を要約する必要があります。インターネット。多くのエンドユーザーや企業は、重要なインフラストラクチャの一部としてインターネットに依存するようになりました。したがって、インターネットなどの大規模なネットワークは、重要な経済的価値を表しています。したがって、プロトコルの障害による大規模なネットワークで停止すると、商業的および政治的損害が大きくなります。
When two incompatible protocols, or forms of the same protocol, are deployed without coordination, there is a serious risk that this may be catastrophic to the stability or security of the network.
2つの互換性のないプロトコル、または同じプロトコルのフォームが調整なしで展開される場合、これがネットワークの安定性またはセキュリティに壊滅的である可能性があるという深刻なリスクがあります。
Furthermore, the scale and distributed nature of the Internet is such that it may be difficult or impossible to rid the network of the long-term consequences of the protocol incompatibility. Therefore, the following issues are of critical importance.
さらに、インターネットの規模と分散の性質は、プロトコルの非互換性の長期的な結果をネットワークから取り除くことが困難または不可能である可能性があるためです。したがって、以下の問題は非常に重要です。
Invariants are core properties that are consistent across the network and do not change over extremely long time-scales. Protocol designers use such invariants as axioms in designing protocols. A protocol often places an absolute reliance on an invariant to resolve a design corner case. One example of an invariance in IP that was inherited in the design of MPLS is the invariant that a time to live (TTL) value is monotonically decreased and that a packet with TTL<=1 will not be forwarded. This is a safety mechanism to mitigate the damaging effects of packet-forwarding loops. Another example is the way that MPLS applies special semantics to the reserved label set (0..15) [RFC3032], and the notion that a Label Switched Router (LSR) is free to allocate labels with a value of 16 or greater for its own use.
不変剤は、ネットワーク全体で一貫しており、非常に長い時間スケールで変化しないコアプロパティです。プロトコル設計者は、プロトコルの設計において、公理などの不変剤を使用します。プロトコルは、多くの場合、デザインコーナーケースを解決するために不変に絶対に依存します。MPLSの設計に継承されたIPの不変性の1つの例は、生きる時間（TTL）値が単調に減少し、TTL <= 1のパケットが転送されないという不変です。これは、パケットに焦点を当てたループの損傷効果を軽減する安全メカニズムです。別の例は、MPLSが予約ラベルセット（0..15）[RFC3032]に特別なセマンティクスを適用する方法と、ラベルを切り替えたルーター（LSR）が16以上の値でラベルを自由に割り当てることができるという概念は、独自の使用。
A special type of invariant is the allocation of a code-point. A code-point may be used to identify a packet type or a component within a packet. Without these identifiers, a packet is an opaque sequence of bits. A packet parser operates by first identifying the code-point and then using the semantics associated with that code-point to interpret other components within the packet. Once a code-point is defined, the interpretation of associated data and the consequential actions become protocol invariants. Subsequent protocol development must adhere to those invariants. The semantics for an allocated code-point must never change. If a future enhancement requires different semantics, interpretation, or action, then a new code-point must be obtained.
特別なタイプの不変は、コードポイントの割り当てです。コードポイントを使用して、パケットタイプまたはパケット内のコンポーネントを識別できます。これらの識別子がなければ、パケットはビットの不透明なシーケンスです。パケットパーサーは、最初にコードポイントを識別し、次にそのコードポイントに関連付けられたセマンティクスを使用してパケット内の他のコンポーネントを解釈することにより動作します。コードポイントが定義されると、関連データの解釈と結果アクションがプロトコル不変剤になります。後続のプロトコル開発は、これらの不変剤に準拠する必要があります。割り当てられたコードポイントのセマンティクスは決して変更されない必要があります。将来の強化に異なるセマンティクス、解釈、またはアクションが必要な場合、新しいコードポイントを取得する必要があります。
A code-point such as an IEEE Ethertype is allocated to a design authority such as the IETF. It is this design authority that establishes how information identified by the code-point is to be interpreted to associate appropriate invariants. Modification and extension of a protocol requires great care. In particular, it is necessary to understand the exact nature of the invariants and the consequences of modification. Such understanding may not always be possible when protocols are modified by organizations that don't have the experience of the original designers or the design authority expert pool. Furthermore, since there can only safely be a single interpretation of the information identified by a code-point, there must be a unique authority responsible for authorizing and documenting the semantics of the information and consequential protocol actions.
IEEE EtherTypeなどのコードポイントは、IETFなどの設計機関に割り当てられます。コードポイントによって特定された情報が適切な不変剤を関連付けると解釈される方法を確立するのは、この設計権限です。プロトコルの変更と拡張には細心の注意が必要です。特に、不変剤の正確な性質と修正の結果を理解する必要があります。このような理解は、元のデザイナーや設計機関の専門家プールの経験を持たない組織によってプロトコルが変更されている場合、常に可能であるとは限りません。さらに、コードポイントによって特定された情報の1つの解釈しか安全に解釈できないため、情報と結果的なプロトコルアクションのセマンティクスを承認および文書化する責任のある独自の権限がなければなりません。
In the case of IP and MPLS technologies, the design authority is the IETF. The IETF has an internal process for evolving and maintaining the protocols for which it is the design authority. The IETF also has change processes in place [RFC4929] to work with other SDOs that require enhancements to its protocols and architectures. Similarly, the ITU-T has design authority for Recommendation E.164 [E.164] and allocates the relevant code-points, even though the IETF has design authority for the protocols ("ENUM") used to access E.164 numbers through the Internet DNS [RFC3245].
IPおよびMPLSテクノロジーの場合、設計機関はIETFです。IETFには、設計権限であるプロトコルを進化および維持するための内部プロセスがあります。IETFには、プロトコルとアーキテクチャを強化する必要がある他のSDOと連携するために、[RFC4929]の変更プロセスもあります。同様に、ITU-Tには推奨事項E.164 [E.164]の設計権があり、関連するコードポイントを割り当てます。インターネットDNS [RFC3245]。
It is a recommendation of this document that the IETF introduces additional change mechanisms to encompass all of the technical areas for which it has design authority.
このドキュメントの推奨事項は、IETFが設計権限を持っているすべての技術分野を含む追加の変更メカニズムを導入することです。
It may be tempting for a designer to assert that the protocol extensions it proposes are safe even though it breaks the invariants of the original protocol because these protocol variants will operate as ships in the night. That is, these protocol variants will never simultaneously exist in the same network domain and will never need to inter-work. This is a fundamentally unsound assumption for a number of reasons. First, it is infeasible to ensure that the two instances will never be interconnected under any circumstances. Second, even if the operators that deploy the protocols apply appropriate due diligence to ensure that the two instances do not conflict, it is infeasible to ensure that such conflicting protocols will not be interconnected under fault conditions.
これらのプロトコルバリアントは夜間に船として動作するため、元のプロトコルの不変性を破るにもかかわらず、提案するプロトコル拡張は安全であると主張するのは、設計者にとって魅力的かもしれません。つまり、これらのプロトコルバリアントは、同じネットワークドメインに同時に存在することはなく、インターワークする必要はありません。これは、いくつかの理由で根本的に不健全な仮定です。まず、2つのインスタンスがいかなる状況でも相互接続されないようにすることは不可能です。第二に、プロトコルを展開するオペレーターが適切なデューデリジェンスを適用して、2つのインスタンスが競合しないことを保証する場合、そのような矛盾するプロトコルが障害条件下で相互接続されないようにすることは不可能です。
This assumption of ships in the night is particularly hazardous when the instances of the protocol share the same identifying code-point. This is because a system is unable to determine which variant of the protocol it has received, and hence how to correctly interpret the associated information or to determine what protocol actions may be safely executed.
この夜の船のこの仮定は、プロトコルのインスタンスが同じ識別コードポイントを共有する場合、特に危険です。これは、システムが受信したプロトコルのバリアントを決定できないため、関連する情報を正しく解釈するか、どのプロトコルアクションを安全に実行できるかを決定する方法です。
There are a variety of examples where lack of inter-SDO coordination has led to the publication of flawed protocol designs. This section describes a number of case studies that illustrate coordination issues.
SDO間調整の欠如が欠陥のあるプロトコル設計の公開につながったさまざまな例があります。このセクションでは、調整の問題を示す多くのケーススタディについて説明します。
A recent example where another SDO created a protocol based on misunderstandings of IETF protocols is T-MPLS. T-MPLS was created in ITU-T in an attempt to design a packet-transport method for transport-oriented networks. This is an example of the success that IETF protocols have enjoyed, and ITU-T's interest and selection of MPLS is a compliment to the IETF work. Quite late in the ITU-T design and specification cycle, there were a number of liaison exchanges between the ITU-T and the IETF, where the IETF became increasingly concerned about incompatibility of IETF MPLS procedures and technologies with ITU-T T-MPLS [RFC5317]. Extensive discussions took place regarding interpretation, definition, and misunderstandings regarding aspects such as MPLS Label 14, MPLS swap operation, TTL semantics, reservation of additional labels, and EXP bits. If ITU-T had worked with IETF from the start in developing T-MPLS, these problems could have been avoided. A detailed analysis of the T-MPLS case is provided in Appendix A.
別のSDOがIETFプロトコルの誤解に基づいてプロトコルを作成した最近の例はT-mplsです。T-MPLSは、輸送指向のネットワーク用のパケット輸送メソッドを設計するために、ITU-Tで作成されました。これは、IETFプロトコルが享受した成功の例であり、ITU-TのMPLSの関心と選択は、IETF作業の賛辞です。ITU-Tの設計と仕様サイクルのかなり遅れて、ITU-TとIETFの間に多くのリエゾン交換があり、IETFはIETF MPLS手順とITU-T MPLSのテクノロジーの非互換性についてますます懸念していました[RFC5317]。MPLSラベル14、MPLSスワップ操作、TTLセマンティクス、追加のラベルの予約、EXPビットなどの側面に関する解釈、定義、および誤解に関する広範な議論が行われました。ITU-TがT-MPLSの開発で最初からIETFと連携していた場合、これらの問題は回避できた可能性があります。T-MPLSケースの詳細な分析は、付録Aに記載されています。
An example of where the IETF failed to coordinate with the ITU-T is [RFC1619], which defined PPP over SONET. In the text dealing with the SONET/SDH Synchronous Payload Envelope (SPE), the document erroneously stated that "no scrambling is needed during insertion into the SPE." It was later determined by SONET experts operating in the ITU-T and in ANSI that this error arose due to an incomplete understanding of the SONET scrambler. By not using a scrambler, the protocol was attempting to transport non-transparent data over SONET. This resulted in lost or misinterpreted data in the Packet over SONET (PoS) network. This impacted routing, signaling, and end-user data traffic. Details of this work are described in [PPPoSONET]. This problem would have been prevented if the IETF had worked with ITU-T and ANSI in initially developing [RFC1619] . The problem was resolved by working jointly with ITU-T and ANSI experts to publish [RFC2615], which mandated the use of scrambling.
IETFがITU-Tと調整できなかった場所の例は[RFC1619]であり、SONETよりもPPPを定義しました。SONET/SDH同期ペイロードエンベロープ（SPE）を扱うテキストでは、文書は「SPEへの挿入中にスクランブルは必要ない」と誤って述べました。その後、SONETの専門家とANSIで活動しているSONETの専門家によって決定されました。SONETScramblerの不完全な理解により、このエラーが発生したことです。スクランブラーを使用しないことで、プロトコルはSONETを介して非透明なデータを輸送しようとしました。これにより、SONET（POS）ネットワークを介したパケット内のデータが失われたり誤って解釈されたりしました。これは、ルーティング、シグナリング、およびエンドユーザーのデータトラフィックに影響を与えました。この作業の詳細は[ppposonet]で説明されています。IETFが最初に開発された[RFC1619]でIETFがITU-TとANSIと連携していた場合、この問題は防止されていました。この問題は、ITU-TとANSIの専門家と共同で作業して[RFC2615]を公開することで解決されました。
Note that [RFC1619] was developed four years before the IETF and ITU-T agreed on formal procedures for cooperation, as documented in [RFC2436] (which was later obsoleted by [RFC3356]).
[RFC2436]に記載されているように、[RFC1619]はIETFの4年前に開発され、ITU-Tは協力のための正式な手順に同意したことに注意してください（後に[RFC3356]によって廃止されました）。
This section recommends that intra- and inter-SDO information flows require careful management in order to prevent the accidental extension of protocols without complete coordination of the work with the relevant design authority.
このセクションでは、関連する設計機関との作業を完全に調整せずにプロトコルの偶発的な拡張を防ぐために、SDO内およびSDO間の情報フローが慎重な管理を必要とすることが推奨されます。
One cannot assume that an SDO is completely familiar with the internal structure, information exchange, or internal processes of another SDO. Hence, the initial contact point and the subgroup with which a long-term working relationship is formed has a duty to ensure that the work is fully notified and coordinated to all relevant parties within the SDO.
SDOが別のSDOの内部構造、情報交換、または内部プロセスに完全に精通しているとは想定できません。したがって、最初の接触点と長期的な仕事上の関係が形成されるサブグループは、作業がSDO内のすべての関連当事者に完全に通知され、調整されることを保証する義務があります。
A recommendation is that, as part of their document-approval process, SDOs should confirm that all protocol parameters, code-points, TLV identifiers, etc., have been authorized by the appropriate design authority (e.g., IANA, IETF, etc. in this case) and that SDO approval from the design authority has been obtained prior to publishing protocol extensions. This confirmation should be an integral part of the approval or consent process as verifying that the normative references are qualified.
推奨事項は、ドキュメント承認プロセスの一部として、SDOはすべてのプロトコルパラメーター、コードポイント、TLV識別子などが適切な設計機関（例えば、IANA、IETFなどによって許可されていることを確認する必要があることです。このケース）および設計機関からのSDOの承認は、プロトコル拡張を公開する前に取得されています。この確認は、規範的参照が適格であることを確認するために、承認または同意プロセスの不可欠な部分である必要があります。
In order to bridge the gap between the two organizations, the IETF and the ITU-T established a joint working team (JWT) to assess whether it was possible to enhance existing MPLS standards to provide a best-in-class solution for transport networks. The outcome of this investigation is reported in [RFC5317].
2つの組織間のギャップを埋めるために、IETFとITU-Tは共同作業チーム（JWT）を確立して、既存のMPLS標準を強化して輸送ネットワークにクラス最高のソリューションを提供できるかどうかを評価しました。この調査の結果は[RFC5317]で報告されています。
The JWT proposed a design that was acceptable to both SDOs. This has led to the creation of the MPLS-TP project. This is a joint project in which the ITU-T experts work with the IETF on protocol-development tasks, and IETF members work within the ITU-T to understand requirements and to assist in the creation of ITU-T recommendations that describe MPLS-TP in which the technical definition is provided through normative references to IETF RFCs.
JWTは、両方のSDOに受け入れられるデザインを提案しました。これにより、MPLS-TPプロジェクトが作成されました。これは、ITU-Tの専門家がProtocol-DevelopmentタスクでIETFと連携する共同プロジェクトであり、IETFメンバーはITU-T内で要件を理解し、MPLS-TPを説明するITU-Tの推奨事項の作成を支援するために働きます。IETF RFCSへの規範的参照を通じて技術的な定義が提供されます。
Although the JWT approach allowed the IETF and the ITU-T to agree on a method of resolving the T-MPLS problem, this approach had a significant resource cost. The JWT required considerable protocol-design expertise and IETF management time to agree on a suitable technical solution. A lightweight process, starting with close coordination during the requirements phase and continuing during the development phase, would likely reduce the resources needed to an acceptable level in the future.
JWTアプローチにより、IETFとITU-TはT-MPLS問題を解決する方法に同意することができましたが、このアプローチにはかなりのリソースコストがありました。JWTは、適切な技術的ソリューションに同意するために、かなりのプロトコル設計の専門知識とIETF管理時間を必要としました。要件段階での緊密な調整から始まり、開発段階で継続することから始まる軽量プロセスは、将来的に必要なリソースを許容可能なレベルに削減する可能性があります。
There is an MPLS-change-process [RFC4929] . However, the IETF has not yet defined a change process that is applicable to all of its work areas. The problems described in this document indicate that the IETF needs to develop a universal change process. The MPLS-change-process would seem to be a suitable starting point.
MPLSチェンジプロセス[RFC4929]があります。ただし、IETFは、すべての作業分野に適用できる変更プロセスをまだ定義していません。このドキュメントで説明されている問題は、IETFがユニバーサル変更プロセスを開発する必要があることを示しています。MPLSチェンジプロセスは、適切な出発点のようです。
The uncoordinated development of protocols poses a risk of harm to the Internet and must not be permitted. The enhancement or modification of a protocol can increase attack surfaces considerably and may therefore compromise the security or stability of the Internet. The IETF has a review process that combines cross-area review with specialist security review by experts familiar with the development and deployment context of the Internet protocol suite. In particular, because of the Internet infrastructure's reliance on the IP and MPLS protocol suites, this security review process must be exercised with considerable diligence. Failure to apply this review process exposes the Internet to increased risk along both security and stability vectors.
プロトコルの協調的な開発は、インターネットに危害のリスクをもたらし、許可されてはなりません。プロトコルの強化または変更により、攻撃表面が大幅に増加する可能性があるため、インターネットのセキュリティまたは安定性を損なう可能性があります。IETFには、インターネットプロトコルスイートの開発と展開のコンテキストに精通している専門家による、クロスエリアのレビューと専門のセキュリティレビューを組み合わせたレビュープロセスがあります。特に、インターネットインフラストラクチャがIPおよびMPLSプロトコルスイートに依存しているため、このセキュリティレビュープロセスはかなりの勤勉さで行使する必要があります。このレビュープロセスを適用しないと、インターネットがセキュリティベクトルと安定性ベクトルの両方に沿ってリスクを増加させます。
The authors wish to acknowledge Loa Andersson for his contribution to this work.
著者は、この仕事への貢献についてロア・アンダーソンに認めたいと考えています。
Marcelo Bagnulo Gonzalo Camarillo Stuart Cheshire Vijay Gill Russ Housley John Klensin Olaf Kolkman Gregory Lebovitz Andrew Malis Danny McPherson David Oran Jon Peterson Dave Thaler
マルセロ・バグヌロ・ゴンザロ・カマリロ・スチュアート・チェシャー・ギル・ラス・ヒューズリー・ジョン・クレンシン・オラフ・コルクマン・グレゴリー・レボビッツ・アンドリュー・マリス・ダニー・マクファーソン・デイビッド・オラン・ジョン・ピーターソン・デイブ・サラー
Although we have used T-MPLS as a case study, there are other ongoing ITU-T projects and core IETF specifications that could be the subject of either improved coordination or new conflicts, depending on whether or not the principles outlined in this document are adhered to by the IETF and ITU. Two current examples are [Y.2015] and [Q.Flowsig]. New areas with potential for cooperation or conflict are emerging from the work of ITU-T SG13 Question 7, "IPv6" -- for example: [Y.ipv6split] and [Y.ipv6migration].
TMPLSをケーススタディとして使用しましたが、このドキュメントで概説されている原則が順守されているかどうかに応じて、調整または新しい競合の対象となる可能性のある他の進行中のITU-TプロジェクトやコアIETF仕様があります。IETFとITUによる。現在の2つの例は、[Y.2015]と[Q.Flowsig]です。協力または紛争の可能性を秘めた新しい分野は、ITU-T SG13質問7、「IPv6」の仕事から生まれています。
Improved coordination, of course, is not limited to the relationship between IETF and ITU-T. This issue is present between a set of SDOs. The IETF - ITU-T relationship has simply been used because there is a recent example where a potential disaster was, through much hard work, not only prevented but turned into a net gain for all.
もちろん、調整の改善は、IETFとITU-Tの関係に限定されません。この問題は、SDOのセット間に存在します。IETF -ITU -T関係は、潜在的な災害が大変な仕事を通じて、防止されただけでなく、すべての人にとって純利益に変わった最近の例があるため、単に使用されています。
It is important that all SDOs developing standards that affect the operation of the Internet learn the lessons that arise from cases cited in this document. Uncoordinated parallel work between SDOs creates significant problems with potentially damaging operation impact to those that deploy and use the Internet. Both inter- and intra-SDO information flow needs to be well managed to ensure that all impacted parties are aware of work items. Finally, the IETF needs to develop a universal change process that encompasses all of its work areas.
インターネットの運用に影響を与えるすべてのSDOが開発されているすべてのSDOが、このドキュメントで引用されているケースから生じる教訓を学ぶことが重要です。SDO間の非調整された並列作業は、インターネットを展開して使用するものに操作の影響を損なう可能性があるという重大な問題を引き起こします。SDO間の情報フローとInterの両方の情報は、すべての影響を受けた当事者が作業項目を認識していることを保証するために適切に管理する必要があります。最後に、IETFは、すべての作業領域を含む普遍的な変更プロセスを開発する必要があります。
[E.164] ITU-T, "ITU Recommendation E.164: The international public telecommunication numbering plan", February 2005.
[E.164] ITU-T、「ITU勧告E.164：国際的な通信番号の番号付け計画」、2005年2月。
[LS26] ITU-T Study Group 15, "Cooperation Between IETF and ITU-T on the Development of MPLS-TP", Geneva, December 2008, <https://datatracker.ietf.org/ documents/LIAISON/file596.pdf>.
[LS26] ITU-T研究グループ15、「MPLS-TPの開発に関するIETFとITU-T間の協力」、ジュネーブ、2008年12月<https://datatracker.ietf.org/ documents/liaison/file596.pdf>。
[PPPoSONET] Manchester, J., et al., "PPP over SONET/SDH", Work in Progress, October 1997.
[PPPOSONET]マンチェスター、J.、他、「PPP Over Sonet/SDH」、Work in Progress、1997年10月。
[Q.Flowsig] ITU-T Study Group 11, Question 5, "Signalling protocols and procedures relating to flow state aware access QoS control in an NGN", Draft Recommendation.
[Q.Flowsig] ITU-T研究グループ11、質問5、「NGNのフロー状態認識アクセスQoSコントロールに関するシグナル伝達プロトコルと手順」、ドラフト推奨。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393] Malkin、G。、「IPオプションを使用したTraceroute」、RFC 1393、1993年1月。
[RFC1619] Simpson, W., "PPP over SONET/SDH", RFC 1619, May 1994.
[RFC1619]シンプソン、W。、「SONET/SDH上のPPP」、RFC 1619、1994年5月。
[RFC2436] Brett, R., Bradner, S., and G. Parsons, "Collaboration between ISOC/IETF and ITU-T", RFC 2436, October 1998.
[RFC2436] Brett、R.、Bradner、S。、およびG. Parsons、「ISOC/IETFとITU-Tのコラボレーション」、RFC 2436、1998年10月。
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[RFC2615] Malis、A。およびW. Simpson、「PPP Over Sonet/SDH」、RFC 2615、1999年6月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC3245] Klensin, J. and IAB, "The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)", RFC 3245, March 2002.
[RFC3245]クレンシン、J。およびIAB、「電話番号マッピングの履歴とコンテキスト（列挙）運用上の決定：情報文書がITU-T研究グループ2（SG2）に貢献した」、RFC 3245、2002年3月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines", RFC 3356, August 2002.
[RFC3356] Fishman、G。およびS. Bradner、「インターネットエンジニアリングタスクフォースおよび国際電気通信連合 - 電気通信標準化セクターコラボレーションガイドライン」、RFC 3356、2002年8月。
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002.
[RFC3429] OHTA、H。、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）操作およびメンテナンス（OAM）機能のための「OAMアラートラベル」の割り当て」、2002年11月、RFC 3429。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for Protocol Extensions and Variations", BCP 125, RFC 4775, December 2006.
[RFC4775] Bradner、S.、Carpenter、B。、およびT. Narten、「プロトコル拡張とバリエーションの手順」、BCP 125、RFC 4775、2006年12月。
[RFC4929] Andersson, L. and A. Farrel, "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007.
[RFC4929] Andersson、L。およびA. Farrel、「マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）プロトコルと手順の変更プロセス」、BCP 129、RFC 4929、2007年6月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129] Davie、B.、Briscoe、B。、およびJ. Tay、「MPLSの明示的な混雑マーキング」、RFC 5129、2008年1月。
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
[RFC5317] Bryant、S。およびL. Andersson、「輸送プロファイルのMPLSアーキテクチャに関する考慮事項に関する共同作業チーム（JWT）レポート」、RFC 5317、2009年2月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462] Andersson、L。and R. Asati、「マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ：「Exp」フィールド「トラフィッククラス」フィールドに改名されたフィールド、RFC 5462、2009年2月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Brungard、D.、Betts、M.、Sprecher、N。、およびS. Ueno、「MPLS輸送プロファイルの要件」、RFC 5654、2009年9月。
[Y.1711-2002] ITU-T Study Group 13, "ITU-T Recommendation Y.1711: OAM mechanism for MPLS networks", November 2002.
[Y.1711-2002] ITU-T研究グループ13、「ITU-T推奨Y.1711：MPLSネットワークのOAMメカニズム」、2002年11月。
[Y.1711-2004] ITU-T Study Group 13, "ITU-T Recommendation Y.1711: OAM mechanism for MPLS networks", February 2004.
[Y.1711-2004] ITU-T研究グループ13、「ITU-T推奨Y.1711：MPLSネットワークのOAMメカニズム」、2004年2月。
[Y.1711am1] ITU-T Study Group 13, "ITU-T Recommendation Y.1711 Amendment 1: New Function Type Codes", October 2005.
[Y.1711AM1] ITU-T研究グループ13、「ITU-Tの推奨Y.1711修正1：新しい機能タイプコード」、2005年10月。
[Y.1711cor1] ITU-T Study Group 13, "ITU-T Recommendation Y.1711 (2004) corrigendum 1", February 2005.
[Y.1711COR1] ITU-T研究グループ13、「ITU-T推奨Y.1711（2004）Corrigendum 1」、2005年2月。
[Y.2015] ITU-T Study Group 13, Question 5, "General Requirements for ID/Locator Separation in NGN".
[Y.2015] ITU-T研究グループ13、質問5、「NGNのID/ロケーター分離の一般的な要件」。
[Y.ipv6migration] ITU-T, "ITU draft Y.ipv6migration: Roadmap for IPv6 migration from NGN operators perspective", 2009.
[Y.IPv6Migration] ITU-T、「ITUドラフトY.IPv6移行：NGNオペレーターの視点からのIPv6移行のロードマップ」、2009年。
[Y.ipv6split] ITU-T, "ITU draft Y.ipv6split: Framework of ID/LOC separation in IPv6-based NGN", 2009.
[y.ipv6split] itu-t、 "ituドラフトy.ipv6split：IPv6ベースのNGNにおけるID/LOC分離のフレームワーク、2009。
T-MPLS was created in ITU-T in an attempt to design an MPLS-based packet-transport method for transport-oriented networks. This appendix describes the technical issues that the IETF identified with the T-MPLS documents and their consequences.
T-MPLSは、輸送指向のネットワーク向けにMPLSベースのパケット輸送メソッドを設計するために、ITU-Tで作成されました。この付録では、IETFがT-MPLS文書で特定した技術的な問題とその結果について説明しています。
To appreciate why the use of MPLS Reserved Label 14 by the T-MPLS protocol represented a safety concern to the Internet, it is important to understand the current standards that use MPLS Reserved Label 14.
T-MPLSプロトコルによるMPLS予約ラベル14の使用がインターネットの安全性の懸念を表す理由を理解するために、MPLS予約ラベル14を使用する現在の標準を理解することが重要です。
The governing standard on the use of MPLS Reserved Label 14 is [RFC3429], "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions".
MPLS予約ラベル14の使用に関する統治基準は[RFC3429]、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）操作およびメンテナンス（OAM）機能の「OAMアラートラベル」の割り当て」です。
Label 14 is assigned to a specific protocol, namely, ITU-T Recommendation [Y.1711-2002].
ラベル14は、特定のプロトコル、つまりITU-Tの推奨[Y.1711-2002]に割り当てられています。
ITU-T Recommendation [Y.1711-2002] has been superseded by newer versions, specifically: [Y.1711-2004], [Y.1711cor1], and [Y.1711am1].
ITU-Tの推奨[Y.1711-2002]は、具体的には[Y.1711-2004]、[Y.1711COR1]、および[Y.1711AM1]、新しいバージョンに取って代わられました。
All three documents are currently in force as ITU-T Recommendations.
3つのドキュメントはすべて、ITU-Tの推奨として現在有効です。
The problem is that the changes made to Y.1711 were never reflected in an update to RFC 3429, which only defines the protocol as specified by the now superseded 2002 Recommendation. So for example, MPLS equipment responding to an MPLS packet containing Label 14 would expect to see the 2002 version of the Y.1711 [Y.1711-2002] protocol and would not recognize any of the new function codes specified in Y.1711 Amendment 1. This problem arises because Y.1711 does not have a version field, and RFC 3429 offers no other method to disambiguate non-interoperable versions of Y.1711. Having a version number in the protocol permits an implementer to codify non-interoperability. Furthermore, the IETF as the authority over Label 14 semantics has the final say over maintaining the interoperability of the protocol employing that code-point, unless the IETF explicitly delegates such authority.
問題は、Y.1711に加えられた変更がRFC 3429の更新には決して反映されなかったことです。RFC3429は、現在置換されている2002年の推奨で指定されているプロトコルのみを定義しています。たとえば、ラベル14を含むMPLSパケットに応答するMPLS機器は、Y.1711 [Y.1711-2002]プロトコルの2002バージョンが表示され、Y.1711修正で指定された新しい関数コードのいずれも認識しないことが予想されます。1. Y.1711にはバージョンフィールドがないため、この問題は発生し、RFC 3429はY.1711の非透過性バージョンを明確にする他の方法を提供していません。プロトコルにバージョン番号を持つことで、実装者は非挿入性を成文化できます。さらに、IETFがそのような権限を明示的に委任しない限り、ラベル14セマンティクスの権限としてのIETFは、そのコードポイントを採用するプロトコルの相互運用性を維持することについて最終的な発言権を持っています。
With regard to T-MPLS, there was a lack of coordination between the ITU-T and the IETF over the redefinition of the semantics of MPLS Label 14, which resulted in protocol definitions that conflicted with the IETF MPLS architecture.
T-MPLに関しては、MPLSラベル14のセマンティクスの再定義に関するITU-TとIETFの間に調整が不足していたため、IETF MPLSアーキテクチャと矛盾するプロトコル定義が生じました。
The MPLS architecture [RFC3031], defines a swap operation as an atomic function that replaces the top label in an MPLS label stack with another label, which provides context for the next hop LSR. However, the ITU-T Recommendations that specified the new OAM functions defined by Label 14 redefined the label-swap operation as a POP, followed by a PUSH, thereby causing all LSRs to inspect the label stack for the presence of Label 14 at each hop. This proposed new behaviour conflicts with the IETF definition of a swap operation.
MPLSアーキテクチャ[RFC3031]は、MPLSラベルスタックのトップラベルを別のラベルに置き換える原子関数としてスワップ操作を定義します。これは、次のホップLSRのコンテキストを提供します。ただし、ラベル14で定義された新しいOAM関数を指定したITU-Tの推奨事項は、ラベルスワップ操作をポップとして再定義し、プッシュを続けるため、すべてのLSRが各ホップでラベル14の存在をラベルスタックの存在のために検査します。。これにより、提案された新しい動作は、スワップ操作のIETF定義と矛盾しています。
The behaviour proposed in these specifications would have had major consequences for deployed hardware designs. The outcome would have been that the equipments built according to the two different specifications would have been incompatible. It is important that the atomic procedure defined in [RFC3031] is kept unchanged.
これらの仕様で提案されている動作は、展開されたハードウェア設計に大きな結果をもたらしたでしょう。結果は、2つの異なる仕様に従って構築された機器が互換性がないということでした。[RFC3031]で定義されている原子手順を変更せずに保持することが重要です。
The standard method of delivering an OAM message to an entity on a Label Switched Path (LSP), such that the OAM message shares its fate with the data traffic, is to use TTL expiry. The IETF's Internet Protocol (IP) utilizes this mechanism for traceroute [RFC1393], as does MPLS ping [RFC4379].
OAMメッセージがデータトラフィックと運命を共有するように、ラベルスイッチ付きパス（LSP）のエンティティにOAMメッセージを配信する標準的な方法は、TTL有効期限を使用することです。IETFのインターネットプロトコル（IP）は、MPLS ping [RFC4379]と同様に、Traceroute [RFC1393]のこのメカニズムを利用しています。
At one stage, the T-MPLS designers considered a multi-level OAM design in which the OAM packet was steered to its target by a process in which some nodes increased the TTL as they forwarded the OAM packet to its next hop. TTL is a safety device in the IETF IP and MPLS architecture that prevents a packet from continuously looping under fault conditions. Thus, the proposed extension to support an enhanced OAM mechanism violated an MPLS design invariant specifically introduced to ensure safe operation of the Internet by preventing persistent forwarding loops.
ある段階で、T-MPLSデザイナーは、OAMパケットがTTLを増加させるプロセスにより、OAMパケットがOAMパケットを次のホップに転送するプロセスによってターゲットに導くマルチレベルのOAMデザインを検討しました。TTLは、IETF IPおよびMPLSアーキテクチャの安全装置であり、障害条件下でパケットが継続的にループするのを防ぎます。したがって、強化されたOAMメカニズムをサポートするための提案された拡張は、持続的な転送ループを防ぐことにより、インターネットの安全な動作を確保するために特異的に導入されたMPLS設計不変不変に違反しました。
The IETF MPLS protocol uses a small number of reserved labels [RFC3032] as a mechanism to provide additional context and to trigger some special processing operations in the forwarder. All other labels used for forwarding use semantics defined by the forwarding equivalence class (FEC). In an early implementation of T-MPLS, the designers determined that they needed some additional labels to alert the forwarder that the packet needed special processing. Thus, a conflict was thereby introduced between the behaviour of an IETF MPLS LSR and LSRs that operate according to the specification in the ITU-T Recommendation. Thus, some LSRs would attribute special semantics to Labels 16..31, whilst other LSRs would perform normal forwarding on them.
IETF MPLSプロトコルは、追加のコンテキストを提供し、フォワーダーでいくつかの特別な処理操作をトリガーするメカニズムとして、少数の予約ラベル[RFC3032]を使用します。転送に使用される他のすべてのラベルは、転送等価クラス（FEC）によって定義されたセマンティクスを使用します。T-MPLSの早期実装では、設計者は、パケットが特別な処理が必要であることを転送者に警告するために追加のラベルが必要であると判断しました。したがって、ITU-Tの推奨の仕様に従って動作するIETF MPLS LSRとLSRの動作の間に競合が導入されました。したがって、一部のLSRは特別なセマンティクスをラベル16..31に起因すると考えていますが、他のLSRはそれらに対して通常の転送を実行します。
The early MPLS documents defined the form of the MPLS label stack entry [RFC3032]. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".
初期のMPLS文書は、MPLSラベルスタックエントリ[RFC3032]の形式を定義しました。これには、「Expフィールド」と呼ばれる3ビットフィールドが含まれます。このフィールドの正確な使用は、これらのドキュメントによって定義されていませんでしたが、「実験用に予約される」ことを除いて。
Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today, a number of standards documents define its usage as a CoS field ([RFC3270], [RFC5129]), and hardware is deployed that assumes this exclusive usage.
EXPフィールドの使用は「サービスのクラス」（COS）フィールドとしてのものでしたが、このようなCOSフィールドの使用は十分に定義されているとは見なされなかったため、これらの初期の文書でCOSフィールドと名付けられていませんでした。今日、多くの標準文書がその使用法をCOSフィールド（[RFC3270]、[RFC5129]）として定義し、この排他的使用を想定するハードウェアが展開されています。
The T-MPLS designers, unaware of the historic reason for the "provisional" naming of this field, assumed that they were available for any experimental use and re-purposed them to indicate the maintenance-entity level (a hierarchical maintenance mechanism).
T-MPLSデザイナーは、この分野の「暫定的な」命名の歴史的な理由に気付いていないため、実験的な使用に利用できると想定し、メンテナンスエンティティレベル（階層的メンテナンスメカニズム）を示すためにそれらを再利用しました。
The intended use of the EXP field was subsequently carried in [RFC5462], which reinforces this use by formally changing the name to Traffic Class (TC).
その後、EXPフィールドの使用が意図されており、[RFC5462]で運ばれ、名前をトラフィッククラス（TC）に正式に変更することでこの使用を強化します。
Transport network operators need a way to realize the statistical gain inherent in packet networking while retaining the familiar operational structure of their SONET/SDH networks. T-MPLS was an attempt to provide that functionality. However, creating an incompatible variant of MPLS without tight coordination with IETF created a number of problems for network operators.
トランスポートネットワークオペレーターは、SONET/SDHネットワークの馴染みのある運用構造を保持しながら、パケットネットワーキングに固有の統計的ゲインを実現する方法が必要です。T-Mplsは、その機能を提供する試みでした。ただし、IETFとの緊密な調整なしにMPLの互換性のないバリアントを作成すると、ネットワーク演算子に多くの問題が生じました。
Firstly, those operators that deployed T-MPLS in production networks will need to address the risk and complexity of transitioning their network to MPLS-TP. Secondly, there has been a consequential delay of the necessary enhancements to MPLS to meet their needs [RFC5654] as the IETF and ITU-T executed a redevelopment of MPLS-based transport network protocols.
まず、生産ネットワークにT-MPLSを展開したオペレーターは、ネットワークをMPLS-TPに移行するリスクと複雑さに対処する必要があります。第二に、IETFとITU-TがMPLSベースのトランスポートネットワークプロトコルの再開発を実行したため、ニーズを満たすためにMPLSの必要な強化の結果的な遅延がありました[RFC5654]。
Fortunately, the two organizations are now working together to design the necessary enhancements
幸いなことに、2つの組織は現在、必要な機能強化を設計するために協力しています
The resulting technology, MPLS-TP, brings significant benefits to all. However, this has not been without cost. Had things continued, we are not sure what would have happened -- at the least, the larger MPLS community would have been denied the benefit of better OAM, and the transport community would have been denied the many benefits of an interoperable solution.
結果として得られるテクノロジーであるMPLS-TPは、すべての人に大きな利益をもたらします。ただし、これには費用がかかりません。物事が続いていたら、何が起こるかはわかりません。少なくとも、より大きなMPLSコミュニティはより良いOAMの利益を否定され、輸送コミュニティは相互運用可能な解決策の多くの利点を否定されていたでしょう。
The process of resolution required considerable resources and introduced a great deal of conflict between the IETF and the ITU-T, much of which was exposed to public scrutiny, to the detriment of both organizations. In particular, this conflict-resolution process consumed the very resources required to develop an optimal architecture for MPLS in transport networks.
解決のプロセスにはかなりのリソースが必要であり、IETFとITU-Tの間に多くの対立が導入されました。その多くは、両方の組織の損害にさらされていました。特に、この競合解像度プロセスは、輸送ネットワークのMPLの最適なアーキテクチャを開発するために必要なまさにリソースを消費しました。
Authors' Addresses
著者のアドレス
Stewart Bryant (editor)
スチュワート・ブライアント（編集者）
EMail: stbryant@cisco.com
Monique Morrow (editor)
モニーク・モロー（編集者）
EMail: mmorrow@cisco.com
Internet Architecture Board
インターネットアーキテクチャボード
EMail: iab@iab.org