[要約] RFC 5317は、MPLSトランスポートプロファイルのためのMPLSアーキテクチャに関する共同作業チーム（JWT）の報告書です。このRFCの目的は、MPLSネットワークのトランスポートプロファイルに関連するアーキテクチャ上の考慮事項を提供することです。
Network Working Group S. Bryant, Ed.
Request for Comments: 5317 Cisco Systems
Category: Informational L. Andersson, Ed.
Acreo AB
February 2009
Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile
輸送プロファイルのMPLSアーキテクチャに関する考慮事項に関する共同作業チーム（JWT）レポート
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This RFC archives the report of the IETF - ITU-T Joint Working Team (JWT) on the application of MPLS to transport networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM (Operations, Administration, and Management), survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process. This RFC is available in ASCII (which contains a summary of the slides) and in PDF (which contains the summary and a copy of the slides).
このRFCは、MPLSの輸送ネットワークへの適用に関するIETF -ITU -Tジョイントワーキングチーム（JWT）のレポートをアーカイブします。JWTはオプション1を推奨しました：IETFとITU-Tは共同で協力してIETFに輸送要件を持ち込み、IETF MPLS転送、OAM（運用、管理、管理）、生存性、ネットワーク管理、コントロールプレーンプロトコルを拡張することに同意しますIETF標準プロセスを通じてこれらの要件を満たすため。このRFCは、ASCII（スライドの要約を含む）とPDF（スライドの要約とコピーが含まれています）で利用できます。
Table of Contents
目次
1. Introduction ....................................................3
2. Executive Summary ...............................................4
3. Introduction and Background Material ............................6
4. High-Level Architecture .........................................6
5. OAM and Forwarding ..............................................6
6. Control Plane ...................................................7
7. Survivability ...................................................7
8. Network Management ..............................................7
9. Summary .........................................................7
10. IANA Considerations ............................................8
11. Security Considerations ........................................8
12. The JWT Report .................................................8
13. Informative References .........................................9
For a number of years, the ITU-T has been designing a connection-oriented packet switched technology to be used in Transport Networks. A Transport Network can be considered to be the network that provides wide area connectivity upon which other services, such as IP or the phone network, run. The ITU-T chose to adapt the IETF's MPLS to this task, and introduced a protocol suite known as T-MPLS.
長年にわたり、ITU-Tは、輸送ネットワークで使用される接続指向のパケットスイッチテクノロジーを設計してきました。トランスポートネットワークは、IPや電話ネットワークなどの他のサービスが実行される幅広い領域接続を提供するネットワークと見なすことができます。ITU-Tは、IETFのMPLSをこのタスクに適応させることを選択し、T-MPLSとして知られるプロトコルスイートを導入しました。
Quite late in the ITU-T design and specification cycle, there were a number of liaison exchanges between the ITU-T and the IETF concerning this technology. These liaisons can be found on the IETF Liaison Statement web page [LIAISON]. In addition, the chairs of the MPLS, PWE3, BFD, and CCAMP working groups as well as the Routing and Internet Area Directors attended a number of ITU-T meetings. During this process, the IETF became increasingly concerned that the incompatibility of IETF MPLS and ITU-T T-MPLS would "represent a mutual danger to both the Internet and the Transport network". These concerns led the chairs of the IESG and IAB to take the step of sending a liaison to the ITU-T, stating that either T-MPLS should become fully compliant MPLS protocol, standardized under the IETF process (the so-called "Option 1"), or it should become a completely disjoint protocol with a new name and completely new set of code points (the so-called "Option 2") [Ethertypes].
ITU-Tの設計と仕様サイクルのかなり遅れて、この技術に関するITU-TとIETFの間に多くのリエゾン交換がありました。これらのリエゾンは、IETFリエゾンステートメントWebページ[liaison]に記載されています。さらに、MPLS、PWE3、BFD、およびCCAMPワーキンググループの椅子と、ルーティングおよびインターネットエリアのディレクターが多くのITU-Tミーティングに出席しました。このプロセス中、IETFは、IETF MPLSとITU-T-MPLの非互換性が「インターネットと輸送ネットワークの両方に対する相互の危険を表す」ことをますます懸念するようになりました。これらの懸念により、IESGとIABの椅子は、IETFプロセス（いわゆる」オプション1で標準化されたT-MPLSが完全に準拠したMPLSプロトコルになるはずであると述べて、IESGとIABの椅子をITU-Tに送信するための一歩を踏み出しました。"）、または、新しい名前と完全に新しいコードポイント（いわゆる「オプション2」）[ETHERTYPES]を備えた完全にばらばらのプロトコルになるはずです。
Option 1 and Option 2 were discussed at an ITU-T meeting of Question 12 Study Group 15 in Stuttgart [Stuttgart], where it was proposed that a Joint (ITU-T - IETF) Team should be formed to evaluate the issues, and make a recommendation to ITU-T management on the best way forward.
オプション1とオプション2は、Stuttgart [Stuttgart]の質問12研究グループ15のITU-T会議で議論されました。ここでは、問題を評価し、作成するためにジョイント（ITU-T-IETF）チームを形成する必要があることが提案されました。今後の最良の方法でのITU-T管理への推奨。
Following discussion between the management of the IETF and the ITU-T, a Joint Working Team (JWT) was established; this was supported by an IETF Design Team and an Ad Hoc Group on T-MPLS in the ITU-T [ahtmpls]. The first meeting of the Ad Hoc group occurred during the ITU-T Geneva Plenary in February 2008. As a result of the work of the JWT and the resulting agreement on a way forward, the fears that a set of next-generation network transport specifications developed by ITU-T could cause interoperability problems were allayed.
IETFとITU-Tの管理との間の議論に続いて、共同作業チーム（JWT）が確立されました。これは、IETF設計チームとITU-T [AHTMPLS]のT-MPLSのアドホックグループによってサポートされていました。Ad Hocグループの最初の会議は、2008年2月のITU-Tジュネーブ全体で発生しました。JWTの作業とその結果、次の世代のネットワーク輸送仕様のセットがあるという恐怖の結果としてITU-Tによって開発された可能性があるため、相互運用性の問題が緩和されました。
The JWT submitted their report to the ITU-T and IETF management in the form of a set of Power Point slides [MPLS-TP-22]. (See the PDF of this RFC.) The ITU-T have accepted the JWT recommendations, as documented in [MPLS-TP]. This RFC archives the JWT report in a format that is accessible to the IETF.
JWTは、パワーポイントスライドのセット[MPLS-TP-22]の形で、ITU-TおよびIETF管理にレポートを提出しました。（このRFCのPDFを参照してください。）ITU-Tは、[MPLS-TP]に記載されているように、JWTの推奨事項を受け入れました。このRFCは、JWTレポートをIETFにアクセスできる形式でアーカイブします。
This RFC is available in ASCII (which contains a summary of the slides) and in PDF (which contains the summary and a copy of the slides). In the case of a conflict between the summary and the slides, the slides take precedence. Since those slides were the basis of an important agreement between the IETF and the ITU-T, it should further be noted that in the event that the PDF version of the slides differs from those emailed to ITU-T and IETF management on 18 April 2008 by the co-chairs of the JWT, the emailed slides take precedence.
このRFCは、ASCII（スライドの要約を含む）とPDF（スライドの要約とコピーが含まれています）で利用できます。要約とスライドの間の競合の場合、スライドが優先されます。これらのスライドはIETFとITU-Tの間の重要な一致の基礎であるため、スライドのPDFバージョンが2008年4月18日にITU-TおよびIETF管理に電子メールで送信されたものと異なる場合にさらに注意する必要があります。JWTの共同議長によって、電子メールが済みたスライドが優先されます。
Slides 4 to 10 provide an executive summary of the JWT Report. The following is a summary of those slides:
スライド4〜10 JWTレポートのエグゼクティブサマリーを提供します。以下は、これらのスライドの要約です。
The JWT achieved consensus on the recommendation of Option 1: to jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM, survivability, network management, and control plane protocols to meet those requirements through the IETF Standards Process. The Joint Working Team believed that this would fulfill the mutual goals of improving the functionality of the transport networks and the Internet and guaranteeing complete interoperability and architectural soundness. This technology would be referred to as the Transport Profile for MPLS (MPLS-TP).
JWTは、オプション1の推奨に関するコンセンサスを達成しました。共同で協力してIETFに輸送要件を導入し、IETFの転送、生存性、ネットワーク管理、およびコントロールプレーンプロトコルを拡張して、IETF標準プロセスを通じてそれらの要件を満たすこと。共同作業チームは、これが輸送ネットワークとインターネットの機能を改善し、完全な相互運用性と建築の健全性を保証するという相互の目標を達成すると信じていました。この技術は、MPLS（MPLS-TP）の輸送プロファイルと呼ばれます。
The JWT recommended that future work should focus on:
JWTは、将来の作業に焦点を当てることを推奨しました。
In the IETF:
IETFで：
Definition of the MPLS "Transport Profile" (MPLS-TP).
MPLS「輸送プロファイル」（MPLS-TP）の定義。
In the ITU-T:
ITU-Tで：
Integration of MPLS-TP into the transport network,
MPLS-TPのトランスポートネットワークへの統合、
Alignment of the current T-MPLS ITU-T Recommendations with MPLS-TP and,
MPLS-TPとの現在のT-MPLS ITU-Tの推奨事項のアラインメントおよび
Termination of the work on current T-MPLS.
現在のT-mplsでの作業の終了。
The technical feasibility analysis concluded there were no "show stopper" issues in the recommendation of Option 1 and that the IETF MPLS and Pseudowire architecture could be extended to support transport functional requirements. Therefore, the team believed that there was no need for the analysis of any other option.
技術的な実現可能性分析では、オプション1の推奨には「ショーストッパー」の問題はなく、IETF MPLSおよび擬似ワイヤアーキテクチャを輸送機能要件をサポートするために拡張できると結論付けました。したがって、チームは、他のオプションの分析は必要ないと考えていました。
The JWT proposed that the MPLS Interoperability Design Team (MEAD Team), JWT, and Ad Hoc T-MPLS groups continue as described in SG15 TD515/PLEN [JWTcreation] with the following roles:
JWTは、MPLS Interoperability Design Team（Mead Team）、JWT、およびAd Hoc T-MPLSグループが、SG15 TD515/PLEN [JWTCreation]で説明されているように、次の役割で[JWTCreation]を継続することを提案しました。
Facilitate the rapid exchange of information between the IETF and ITU-T,
IETFとITU-Tの間の情報の迅速な交換を促進します。
Ensure that the work is progressing with a consistent set of priorities,
一貫した優先順位で作業が進行していることを確認し、
Identify gaps/inconsistencies in the solutions under development,
開発中のソリューションのギャップ/矛盾を特定する、
Propose solutions for consideration by the appropriate WG/ Question,
適切なwg/ questionによって検討するためのソリューションを提案します、
Provide guidance when work on a topic is stalled or a technical decision must be mediated.
トピックの作業が失速した場合、または技術的な決定を媒介する必要がある場合、ガイダンスを提供します。
None of these groups would have the authority to create or modify IETF RFCs or ITU-T Recommendations. Any such work would be progressed via the normal process of the respective standards body. Direct participation in the work by experts from the IETF and ITU-T would be required.
これらのグループはいずれも、IETF RFCまたはITU-Tの推奨事項を作成または変更する権限を持つことはありません。そのような作業は、それぞれの標準本体の通常のプロセスを介して進められます。IETFおよびITU-Tの専門家による作業への直接参加が必要です。
The JWT recommended that the normative definition of the MPLS-TP that supports the ITU-T transport network requirements be captured in IETF RFCs. It proposed that the ITU-T should:
JWTは、ITU-Tトランスポートネットワークの要件をサポートするMPLS-TPの規範的定義をIETF RFCSでキャプチャすることを推奨しました。ITU-Tは次のとおりであることを提案しました。
Develop ITU-T Recommendations to allow MPLS-TP to be integrated with current transport equipment and networks, including in agreement with the IETF, the definition of any ITU-T-specific functionality within the MPLS-TP architecture via the MPLS change process [RFC4929],
ITU-Tの推奨事項を開発して、MPLS変更プロセスを介してMPLS-TPアーキテクチャ内のITU-T固有の機能の定義を含む、MPLS-TPを現在の輸送機器およびネットワークと統合できるようにします[RFC4929を介してMPLS-TPアーキテクチャの定義]、、
Revise existing ITU-T Recommendations to align with MPLS-TP,
既存のITU-Tの推奨事項を修正して、MPLS-TPに合わせて、
ITU-T Recommendations will make normative references to the appropriate RFCs.
ITU-Tの推奨事項は、適切なRFCに規範的な参照を作成します。
The executive summary contains a number of detailed JWT recommendations to both IETF and ITU-T management together with proposed document structure and timetable.
エグゼクティブサマリーには、提案されたドキュメント構造と時刻表とともに、IETFとITU-Tの両方の管理に対する詳細なJWT推奨事項が多数含まれています。
These JWT recommendations were accepted by ITU-T management [MPLS-TP1].
これらのJWTの推奨事項は、ITU-T管理[MPLS-TP1]によって受け入れられました。
Slides 11 to 22 provide introductory and background material.
スライド11〜22は、入門および背景素材を提供します。
The starting point of the analysis was to attempt to satisfy Option 1 by showing the high-level architecture, any show stoppers, and the design points that would need to be addressed after the decision had been made to work together. Option 1 was stated as preferred by the IETF and because Option 1 was shown to be feasible, Option 2 was not explored.
分析の出発点は、高レベルのアーキテクチャ、ショーストッパー、および協力することを決定した後に対処する必要がある設計ポイントを表示することにより、オプション1を満たすことでした。オプション1は、IETFが好むと述べられており、オプション1が実行可能であることが示されているため、オプション2は調査されませんでした。
The work was segmented into five groups looking at: Forwarding, OAM, Protection, Control Plane, and Network Management. The outcome of each review was reported in the following sections and is summarized below.
この作業は、転送、OAM、保護、制御プレーン、ネットワーク管理の5つのグループに分割されました。各レビューの結果は次のセクションで報告され、以下に要約されています。
There follows a detailed description of the overall requirements and architectural assumptions that would be used in the remainder of the work.
残りの作業で使用される全体的な要件とアーキテクチャの仮定の詳細な説明が続きます。
Slides 23 to 28 provide a high-level architectural view of the proposed design.
スライド23〜28は、提案されたデザインの高レベルのアーキテクチャビューを提供します。
The spectrum of services that the MPLS-TP needs to address and the wider MPLS context is described, together with the provisioning issues. Some basic terminology needed in order to understand the MPLS-TP is defined and some context examples are provided.
MPLS-TPが対処する必要があるサービスのスペクトルと、プロビジョニングの問題とともに、より広いMPLSコンテキストについて説明します。MPLS-TPを理解するために必要ないくつかの基本的な用語が定義され、いくつかのコンテキストの例が提供されます。
Slides 29 to 32 describe the OAM requirements and talk about segment recovery and node identification.
スライド29〜32は、OAMの要件を説明し、セグメントの回復とノードの識別について説明します。
Slides 33 to 38 introduce OAM hierarchy and describe Label Switched Path (LSP) monitoring, the Maintenance End Point (MEP) and Maintenance Intermediate Point (MIP) relationship and the LSP and pseudowire (PW) monitoring relationship.
スライド33〜38 OAM階層を導入し、ラベルスイッチ付きパス（LSP）監視、メンテナンスエンドポイント（MEP）およびメンテナンス中間点（MIP）関係、LSPおよび擬似ワイヤ（PW）の監視関係を説明します。
Sides 39 to 46 introduce the Associated Channel Header (ACH) and its generalization to carry the OAM over LSPs through the use of the "Label for You" (LFU).
側面39〜46は、関連するチャネルヘッダー（ACH）とその一般化を導入し、「LABEL FOR YOU」（LFU）を使用してOAMをLSPSに運びます。
Slides 47 to 48 provide a description of how the forwarding and the ACH OAM mechanism work in detail. A significant number of scenarios are described to work through the operation on a case-by-case basis. These slides introduce a new textual notation to simplify the description of complex MPLS stacks.
スライド47〜48は、転送とACH OAMメカニズムがどのように機能するかについての説明を提供します。かなりの数のシナリオが、ケースバイケースで操作を通じて機能するように説明されています。これらのスライドは、複雑なMPLSスタックの説明を簡素化するための新しいテキスト表記を導入します。
Note that the MPLS forwarding, as specified by IETF RFCs, requires no changes to support MPLS-TP.
IETF RFCSで指定されているMPLS転送には、MPLS-TPをサポートするための変更は必要ないことに注意してください。
Sides 79 to 83 discuss various aspects of the control plane design.
サイド79〜83は、コントロールプレーンの設計のさまざまな側面について説明します。
Control plane sub-team stated that existing IETF protocols can be used to provide required functions for transport network operation and for data-communications-network/switched-circuit-network operation. IETF GMPLS protocols have already applied to Automatic Switched Optical Network (ASON) architecture, and the JWT considered that any protocol extensions needed will be easy to make. The slides provide a number of scenarios to demonstrate this conclusion.
Control Planeのサブチームは、既存のIETFプロトコルを使用して、輸送ネットワーク操作およびデータコミュニケーションネットワーク/スイッチサーキットネットワーク操作に必要な機能を提供できると述べました。IETF GMPLSプロトコルはすでに自動スイッチネットワーク（ASON）アーキテクチャに適用されており、JWTは必要なプロトコル拡張機能は簡単にできると考えました。スライドは、この結論を示すために多くのシナリオを提供します。
The survivability considerations are provided in slides 95 to 104.
生存可能性の考慮事項は、スライド95〜104で提供されます。
The survivability sub-team did not find any issues that prevented the creation of an MPLS-TP, and therefore recommended that Option 1 be selected. Three potential solutions were identified. Each solution has different attributes and advantages, and it was thought that further work in the design phase should eliminate one or more of these options and/or provide an applicability statement.
Survivability Sub-Teamは、MPLS-TPの作成を妨げる問題は見つかりませんでした。したがって、オプション1を選択することを推奨しました。3つの潜在的なソリューションが特定されました。各ソリューションには異なる属性と利点があり、設計フェーズでのさらなる作業は、これらのオプションの1つ以上を排除するか、適用性ステートメントを提供するはずだと考えられていました。
After some clarifications and discussion, there follow in the slide set a number of linear and ring protection scenarios with examples of how they might be addressed.
いくつかの明確化と議論の後、スライドには、それらがどのように対処されるかを示す例を備えた多くの線形保護シナリオをセットします。
Slide 106 states the conclusion of the Network Management sub-team : that it found no issues that prevent the creation of an MPLS-TP and hence Option 1 can be selected.
Slide 106は、ネットワーク管理サブチームの結論を述べています。MPLS-TPの作成を妨げるため、オプション1を選択できる問題は見つかりませんでした。
Slide 113 provides a summary of the JWT report.
Slide 113は、JWTレポートの要約を提供します。
The JWT found no show stoppers and unanimously agreed that they had identified a viable solution. They therefore recommend Option 1. They stated that in their view, 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. From probing various ITU-T Study Groups and IETF Working Groups it appears that MPLS reserved label 14 has had wide enough implementation and deployment that the solution may have to use a different reserved label (e.g., Label 13). The JWT recommended that extensions to Label 14 should cease.
JWTはショーのストッパーを見つけられず、すべてのことが実行可能な解決策を特定したことに全会一致で同意しました。したがって、彼らはオプション1を推奨します。彼らは、彼らの見解では、既存のMPLSアーキテクチャを輸送プロファイルの要件を満たすために拡張できること、およびアーキテクチャがLSP、PWS、およびPWS、およびPWSの単一のOAMテクノロジーを許可することは技術的に実行可能であると述べました。深くネストされたネットワーク。さまざまなITU-T研究グループとIETFワーキンググループを調査することから、MPLS予約ラベル14には、ソリューションが異なる予約ラベルを使用する必要がある可能性があるため、十分な幅広い実装と展開があるように見えます（例：ラベル13）。JWTは、ラベル14の拡張機能が停止することを推奨しました。
The JWT further recommended that this architecture appeared to subsume Y.1711, since the requirements can be met by the mechanism proposed in their report.
JWTはさらに、このアーキテクチャは、レポートで提案されているメカニズムによって要件を満たすことができるため、Y.1711を包含するように見えることを推奨しました。
There are no IANA considerations that arise from this document.
このドキュメントから生じるIANAの考慮事項はありません。
Any IANA allocations needed to implement the JWT recommendation will be requested in the Standards-Track RFCs that define the MPLS-TP protocol.
JWTの推奨事項を実装するために必要なIANAの割り当ては、MPLS-TPプロトコルを定義する標準トラックRFCで要求されます。
The only security consideration that arises as a result of this document is the need to ensure that this is a faithful representation of the JWT report.
このドキュメントの結果として生じる唯一のセキュリティの考慮事項は、これがJWTレポートの忠実な表現であることを保証する必要性です。
The protocol work that arises from this agreement will have technical security requirements that will be identified in the RFCs that define MPLS-TP.
本契約から生じるプロトコル作業には、MPLS-TPを定義するRFCで特定される技術的セキュリティ要件があります。
In the PDF of this RFC, there follows the JWT report as a set of slides.
このRFCのPDFでは、JWTレポートがスライドのセットとして続きます。
[Ethertypes] IESG and IAB, "T-MPLS use of the MPLS Ethertypes", 2006, <https://datatracker.ietf.org/documents/LIAISON/ file470.txt>.
[EtherTypes] IESGおよびIAB、「MPLS ETHERTYPESの使用」、2006、<https://datatracker.ietf.org/documents/liaison/ file470.txt>。
[JWTcreation] Chairman, ITU-T SG 15, "Proposal to establish an Ad Hoc group on T-MPLS", 2008, <http://www.itu.int/md/ T05-SG15-080211-TD-PLEN-0515/en>.
[JWTCreation]会長、ITU-T SG 15、「T-Mplsに関するアドホックグループを確立する提案」、2008年、<http://www.itu.int/md/ t05-sg15-080211-td-plen--0515/en>。
[LIAISON] Liaison statements to and from the IETF can be found at: <https://datatracker.ietf.org/liaison/>.
[liaison] IETFとの連絡ステートメントは、<https://datatracker.ietf.org/liaison/>にあります。
[MPLS-TP] "IETF and ITU-T cooperation on extensions to MPLS for transport network functionality", May 2008, <https://datatracker.ietf.org/liaison/446/>.
[MPLS-TP]「輸送ネットワーク機能のMPLSへの拡張に関するIETFおよびITU-T協力」、2008年5月、<https://datatracker.ietf.org/liaison/446/>。
[MPLS-TP-22] IETF - ITU-T Joint Working Team, "MPLS Architectural Considerations for a Transport Profile", April 2008, <http://www.ietf.org/MPLS-TP_overview-22.pdf>.
[MPLS-TP-22] IETF-ITU-Tジョイントワーキングチーム、2008年4月<http://www.ietf.org/mpls-tp_overview-22.pdf>。
[MPLS-TP1] "IETF and ITU-T cooperation on extensions to MPLS for transport network functionality", ITU-T SG15, May 2008, <https://datatracker.ietf.org/documents/ LIAISON/file553.pdf>.
[MPLS-TP1]「輸送ネットワーク機能のMPLSへの拡張に関するIETFおよびITU-T協力」、ITU-T SG15、2008年5月、<https://datatracker.ietf.org/documents/ liaison/file553.pdf>。
[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月。
[Stuttgart] IETF - IESG and IAB Chairs, "Report of interim meeting of Q.12 on T-MPLS", Stuttgart, Germany, Annex 4, 12-14 September 2007, 2008, <http://ties.itu.int/u//tsg15/ sg15/xchange/wp3/200709_joint_q12_q14_stuttgart/ T-MPLS/wdt03_rapporteur_report-final.doc>. This document is available on request from the ITU-T.
[Stuttgart] IETF-IESGおよびIABチェア、「T-MplsでのQ.12の暫定会議の報告」、ドイツ、Stuttgart、Annex 4、12-14、2008年9月12-14日、<http://ties.itu.int/U // TSG15/SG15/XCHANGE/WP3/200709_JOINT_Q12_Q14_STUTTGART/T-MPLS/WDT03_RAPPORTEUR_REPORT-FINAL.DOC>。このドキュメントは、ITU-Tからのリクエストに応じて利用できます。
[ahtmpls] "Ad Hoc group on T-MPLS", 2008, <http://www.itu.int/ ITU-T/studygroups/com15/ahtmpls.html>.
[ahtmpls]「t-mplsのアドホックグループ」、2008、<http://www.itu.int/ itu-t/sudygroups/com15/ahtmpls.html>。
Editors' Addresses
編集者のアドレス
Stewart Bryant (editor) Cisco Systems 250, Longwater, Green Park, Reading RG2 6GB UK
スチュワートブライアント（編集者）シスコシステム250、ロングウォーター、グリーンパーク、レディングRG2 6GB UK
EMail: stbryant@cisco.com
Loa Andersson (editor) Acreo AB Isafjordsgatan 22 Kista, Sweden
Loa Andersson（編集者）Acreo ab isafjordsgatan 22キスタ、スウェーデン
EMail: loa@pi.nu