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は、トランスポートMPLS（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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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.
ITU-Tの開発努力MPLSアーキテクチャと一致するようにMPLSを拡張するために、急速に進んでいるMPLSトランスポートプロファイル（MPLS-TP）として知られている、進行中、および完全の要件を満たす - が関節IETFは、現在でありますトランスポート・ネットワーク・プロバイダ[LS26]。ケーススタディとして、私たちは交通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の間には多くのmiscoordinationsとミスコミュニケーションのルートになっています。
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における不変性の一例は、（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イーサタイプなどのコードポイントは、IETFのよう設計局に割り当てられています。これは、コード・ポイントで識別される情報は、適切な不変条件を関連付けるために解釈される方法を確立し、このデザインの権威です。プロトコルの変更や拡張は細心の注意が必要です。特に、不変量の正確な性質および変更の影響を理解することが必要です。プロトコルは、元の設計者の経験やデザインの権威の専門家のプールを持っていない組織が変更された場合、このような理解は常に可能ではないかもしれません。唯一の安全コード・ポイントで識別情報の単一の解釈ができるので、情報の意味や必然プロトコルアクションを許可し、文書化を担当するユニークな権限がなければなりません。
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は、IETFがを通じてE.164番号にアクセスするために使用されるプロトコル（「ENUM」）の設計権限を有しているにもかかわらず、関連するコードポイントを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プロトコルが享受してきたことを、成功の一例であり、MPLSのITU-Tの関心と選択は、IETFの仕事に褒め言葉です。かなり遅いITU-Tの設計及び仕様サイクルで、IETFは、ITU-T T-MPLSとIETF MPLS手順及び技術の非互換性についてますます心配になったITU-TとIETF、間連絡交換の数がありました[ RFC5317]。広範な議論は、このようなMPLSラベル14、MPLSスワップ操作、TTLのセマンティクス、追加のラベル、およびEXPビットの予約などの側面に関する解釈、定義、および誤解について行われました。 ITU-TがT-MPLSの開発に最初からIETFで働いていた場合は、これらの問題は回避されている可能性が。 T-MPLSケースの詳細な分析は、付録Aに設けられています。
3.2. PPP over SONET/SDH (Synchronous Optical Network / Synchronous Digital Hierarchy)
3.2. SONET / SDH（同期光ネットワーク/同期デジタル階層）上のPPP
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との調整に失敗した場合の一例は、SONET上にPPPを定義[RFC1619]です。 SONET / SDH同期ペイロード・エンベロープ（SPE）を扱うテキストで、ドキュメントが誤って「はスクランブルがSPEに挿入する時に必要とされない。」と述べそれは、後でこのエラーが原因SONETスクランブラの不完全な理解に生じたことITU-TおよびANSIで動作するSONETの専門家によって決定しました。スクランブラを使用しないことによって、プロトコルがSONET上に非透過データを転送しようとしました。これは、SONET（POS）ネットワークを介してパケット内の損失または誤って解釈データが得られました。これは、シグナリング、ルーティングに影響を与え、そしてエンドユーザのデータトラフィック。この作品の詳細は[PPPoSONET]で説明されています。 IETFは、最初に[RFC1619]を開発する際にITU-TおよびANSIで働いていた場合、この問題は回避されていたであろう。問題は、スクランブルの使用を義務付け[RFC2615]を、公開することITU-TおよびANSIの専門家との共同作業によって解決されました。
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]).
[RFC1619]は四年IETF前に開発され、（後で[RFC3356]によって廃止された）[RFC2436]に記載されているように、ITU-Tは、協力のための正式な手続きに合意していることに注意してください。
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の情報の流れは、関連する設計上の権限を持つ作品の完全な調整なしのプロトコルの不慮の拡張を防ぐために慎重な管理を必要とすることをお勧めします。
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は、トランスポートネットワークのためのクラス最高のソリューションを提供するために、既存のMPLS標準規格を向上させることが可能だったかどうかを評価するための共同作業チーム（JWT）を設立しました。この調査の結果は、[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の専門家は、プロトコル開発タスクにIETFと連携した共同プロジェクトであり、IETFのメンバーは、要件を理解し、MPLS-TPを記述するITU-T勧告の作成を支援するために、ITU-T内で作業しますここで技術的な定義は、IETFのRFCへの引用規格を介して提供されます。
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
マルセロBagnuloゴンサロ・カマリロスチュアートチェシャービジェイ・ギルラスHousleyジョン・クレンシンオラフKolkmanグレゴリーLebovitzアンドリューMalisダニー・マクファーソンデヴィッドオランジョン・ピーターソンデーブターラー
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].
我々はケーススタディとしてT-MPLSを使用してきたが、改良された配位又は新しい競合のいずれかの対象とすることができる他の進行中のITU-TプロジェクトおよびコアIETF仕様は、本書で概説した原理が接着されているか否かに応じて、ありますIETFおよびITUによると。二つの電流の例は、[Y.2015]であり、[Q.Flowsig]。協力や紛争のための可能性を秘めた新エリアはITU-T SG13質問7の仕事から浮上している、「IPv6の」 - 例：[Y.ipv6split]と[Y.ipv6migration]。
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の情報の流れは、影響を受けるすべての当事者が作業項目を認識していることを保証するために適切に管理する必要があります。最後に、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/文書/ LIAISON / file596.pdf >。
[PPPoSONET] Manchester, J., et al., "PPP over SONET/SDH", Work in Progress, October 1997.
【PPPoSONET]マンチェスター、進歩、1997年10月作業J.、ら、 "SONET / SDH上PPP"。
[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]マルキン、G.、 "tracerouteのIPオプションの使用"、RFC 1393、1993年1月。
[RFC1619] Simpson, W., "PPP over SONET/SDH", RFC 1619, May 1994.
[RFC1619]、RFC 1619、1994年5月シンプソン、W.、 "SONET / SDH上のPPP"。
[RFC2436] Brett, R., Bradner, S., and G. Parsons, "Collaboration between ISOC/IETF and ITU-T", RFC 2436, October 1998.
[RFC2436]ブレット、R.、ブラドナー、S.、およびG.パーソンズ、 "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.シンプソン、 "SONET / SDH上のPPP"、RFC 2615、1999年6月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、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] Klensin、J.およびIAB、 "電話番号マッピング（ENUM）操作上の決定の歴史と文脈：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]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（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]フィッシュマン、G.とS.ブラドナーの、「インターネットエンジニアリングタスクフォースおよび国際電気通信連合 - 電気通信標準化部門の連携ガイドライン」、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]太田、H.、RFC 3429、2002年11月 "のアーキテクチャをマルチプロトコル・ラベル・スイッチング（MPLS）動作及び保守（OAM）機能のための 'OAMの警告ラベル' の割り当て"。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for Protocol Extensions and Variations", BCP 125, RFC 4775, December 2006.
[RFC4775]ブラドナーの、S.、大工、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]アンデション、L.とA.ファレル、 "（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]デイビー、B.、ブリスコー、B.、およびJ.テイ、 "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]ブライアント、S.とL.アンダーソン、 "トランスポートプロファイルのための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]アンデション、L.および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]ニーヴン、ジェンキンス、B.、Brungard、D.、ベッツ、M.、Sprecher、N.、およびS.上野、 "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）正誤表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.ipv6migration：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年。
Appendix A. A Review of the T-MPLS Case
T-MPLSケースの付録A. Aレビュー
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の文書とその結果を用いて同定することを技術的な問題について説明します。
A.1. Multiple Definitions of Label 14
A.1。ラベル14の複数の定義
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].
[Y.1711cor1]、[Y.1711-2004]、および[Y.1711am1] ITU-T勧告は、[Y.1711-2002】具体的には、新しいバージョンに置き換えられました。
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に行われた変更のみ今置き換え2002勧告により指定されたプロトコルを定義するRFC 3429に更新に反映されなかったことです。だから、例えば、ラベル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-MPLSに関しては、IETF MPLSアーキテクチャと競合プロトコル定義の結果MPLSラベル14、の意味論の再定義を超えるITU-TとIETFの間の調整不足がありました。
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]は、次のホップLSRのためのコンテキストを提供する別のラベルとMPLSラベルスタック内のトップラベルを置き換える原子関数としてスワップ操作を定義します。しかし、ラベル14によって定義される新しいOAM機能を指定されたITU-T勧告は、それによって全てのLSRが各ホップにおけるラベル14の有無をラベルスタックを検査させ、PUSH続いPOPとしてラベル・スワップ操作を、再定義しました。これは、スワップ操作の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.
これらの仕様で提案されている動作が展開されているハードウェア設計のための主要な結果をもたらしただろう。結果は、二つの異なる仕様に従って構築された機器に互換性があったであろうということだったでしょう。 [RFC3031]で定義された原子の手順は変わらないことが重要です。
A.2. Redefinition of TTL Semantics
A.2。 TTLセマンティクスの再定義
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有効期限を使用することです。 MPLSピング[RFC4379]は同じようにIETFのインターネットプロトコル（IP）は、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パケットは、それらがその次のホップにOAMパケットを転送するように、いくつかのノードがTTLを増加するプロセスによってその標的に操舵されたマルチレベルOAMの設計を検討しました。 TTLは、連続的に故障状態の下でループからのパケットを阻止IETF IPとMPLSアーキテクチャの安全装置です。このように、強化されOAMメカニズムをサポートするために提案されている拡張子は、特に永続的な転送ループを防止することにより、インターネットの安全な動作を確保するために導入MPLS設計不変に違反し。
A.3. Reservation of Additional Labels
A.3。追加のラベルの予約
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の初期の実装では、設計者は、彼らが、パケットが特別な処理を必要とフォワーダに警告するためにいくつかの追加のラベルを必要とすることを決定しました。したがって、競合がそれによってIETF MPLS LSRとITU-T勧告における仕様に従って動作するのLSRの動作の間に導入しました。他のLSRは、それらの上に通常の転送を実行することになりながらこのように、いくつかのLSRは、ラベル16..31に特別な意味を属性だろう。
A.4. Redefinition of MPLS EXP Bits
A.4。 MPLS EXPビットの再定義
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フィールドの使用目的は、その後、正式にトラフィッククラス（TC）に名前を変更することで、この使用を強化[RFC5462]で実施しました。
A.5. The Consequences for the Network Operators
A.5。ネットワーク・オペレータのための帰結
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との緊密な連携せずにMPLSの互換性のないバリアントを作成するには、ネットワークオペレータのための多くの問題を作成しました。
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などのニーズ[RFC5654]を満たすために、MPLSに必要な拡張の結果として起こる遅延され及びITU-Tは、MPLSベースのトランスポートネットワークプロトコルの再開発を行いました。
Fortunately, the two organizations are now working together to design the necessary enhancements
幸いなことに、両組織は今、必要な拡張機能を設計するために一緒に働いています
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-TPは、すべてに大きなメリットをもたらします。しかし、これはコストがなかったわけではありません。物事は我々が起こっているだろうかわからない、続けていた - 少なくとも、大きな
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コミュニティは、より良いOAMの利益を拒否されていたであろう、と輸送コミュニティは、相互運用可能なソリューションの多くの利点を拒否されていたであろう。
A.6. The Consequences for the SDOs
A.6。 SDOのための帰結
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の間の紛争の多くを、導入しました。特に、この紛争解決プロセスは、トランスポートネットワークにMPLSのための最適なアーキテクチャを開発するために必要な非常にリソースを消費します。
Authors' Addresses
著者のアドレス
Stewart Bryant (editor)
スチュワートブライアント（編集者）
EMail: stbryant@cisco.com
メールアドレス：stbryant@cisco.com
Monique Morrow (editor)
モニークモロー（編集者）
EMail: mmorrow@cisco.com
メールアドレス：mmorrow@cisco.com
Internet Architecture Board
インターネットアーキテクチャ委員会
EMail: iab@iab.org
メールアドレス：iab@iab.org