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
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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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アーカイブIETFのレポート - ネットワークを輸送するためのMPLSの適用に関する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 T-MPLSの非互換性「は、インターネットおよびトランスポートネットワークの両方に相互危険を表す」ということがますます心配になりました。これらの懸念は、いずれかのT-MPLSはIETFプロセスの下で標準化され完全に準拠MPLSプロトコル、（いわゆる「オプション1になるべきであると述べ、ITU-Tへのリエゾンを送信するステップを取るためにIESGとIABの椅子を主導しました「）、またはそれは新しい名前で完全に互いに素プロトコルとコードポイントの全く新しいセット（いわゆるなるべき 『オプション2』）[さらにEthertype]。
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は、それがジョイント（ITU-T - IETF）が提案されたシュトゥット[ガルト]で質問12研究グループ15のITU-Tの会議で議論されたチームの問題を評価するために形成されるべきである、とします前方の最良の方法で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）が設立されました。これは、[ahtmpls] ITU-TでT-MPLSにIETF設計チームとアドホックグループによってサポートされていました。アドホックグループは、JWTの仕事と今後の方向への結果の合意の結果、2008年2月にITU-Tジュネーブ本会議中に発生したの最初の会議、次世代ネットワークトランスポート仕様のセット懸念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経営への報告書を提出しました。 [MPLS-TP]に記載されているように（このRFCのPDFを参照。）ITU-Tは、JWTの勧告を受け入れました。このRFCはIETFにアクセス可能な形式でJWTレポートをアーカイブします。
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転送、OAM、生存、ネットワーク管理、及び制御プレーンプロトコルを拡張することに同意します。合同ワーキングチームは、これは、トランスポート・ネットワークの機能とインターネットを改善し、完全な相互運用性と建築の健全性を保証する相互の目標を達成すると信じていました。この技術は、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はSG15 TD515 / PLENに記載されているようにMPLS相互運用設計チーム（MEADチーム）、JWT、およびアドホックT-MPLS基は、以下のロールと[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 /質問による検討のためのソリューションを提案し、
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 RFCで捕獲することをお勧めします。これは、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],
MPLS-TPはIETF、MPLS変更処理を介してMPLS-TPアーキテクチャ内の任意のITU-T特有の機能の定義と一致して含む、現在の輸送機器とネットワークと統合することを可能にするITU-T勧告を開発する[RFC4929 ]、
Revise existing ITU-T Recommendations to align with MPLS-TP,
MPLS-TPに合わせて、既存のITU-T勧告を修正し、
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推奨は[MPLS-TP1] ITU-Tの管理により受け付けました。
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を満たすために試みることで、意思決定が一緒に動作するようになされた後に対処する必要がデザインポイント。 IETFによって好ましいものとしてオプション1に述べたとオプション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.
28のスライド23は、提案された設計の高レベルアーキテクチャのビューを提供します。
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）と「あなたのためのラベル」（LFU）を使用してLSPを超えるOAMを搬送するための一般化を紹介します。
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.
48スライド47がどのように転送と詳細ACH OAM機構の作業の説明を提供します。シナリオのかなりの数は、ケースバイケースで動作を介して動作するように記載されています。これらのスライドは、複雑なMPLSスタックの説明を簡単にするために、新しいテキストの表記法を紹介します。
Note that the MPLS forwarding, as specified by IETF RFCs, requires no changes to support MPLS-TP.
MPLS転送は、IETFのRFCによって指定されるように、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.
制御プレーンサブチームは、既存のIETFプロトコルがトランスポートネットワーク動作用とデータ通信ネットワークに必要な機能を提供するために使用することができることを述べ/切り換え回路網の動作を制御します。 IETF GMPLSプロトコルは、すでに自動に適用した交換光ネットワーク（ASON）アーキテクチャ、およびJWTは、必要に応じて任意のプロトコルの拡張が作るのは簡単だろうと考えました。スライドは、この結論を実証するシナリオの数を提供しています。
The survivability considerations are provided in slides 95 to 104.
生存の考慮事項は、スライド104から95に設けられています。
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.
サバイバビリティサブチームは、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.
106個の状態ネットワーク管理サブチームの結論をスライド：それはMPLS-TPの創出、ひいてはオプション1を選択することができるのを防ぐ何の問題を発見していないこと。
Slide 113 provides a summary of the JWT report.
スライド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のための単一のOAM技術のためのPWを許可すること、および述べてお勧めします深くネストされたネットワーク。様々なITU-Tの研究グループとIETFのワーキンググループをプロービングから、それはそれは予約ラベル14は、溶液が異なる予約されたラベルを使用する必要があり十分な広さの実装と展開してきたMPLS表示されます（例えば、ラベル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>.
[イーサタイプ] IESGとIAB、 "MPLSイーサタイプのT-MPLSの使用"、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、2008年、<http://www.itu.int/md/ T05-SG15-080211-TD-PLEN- "T-MPLSに関するアドホックグループを確立するための提案" 0515 / EN>。
[LIAISON] Liaison statements to and from the IETF can be found at: <https://datatracker.ietf.org/liaison/>.
<https://datatracker.ietf.org/liaison/>：[LIAISON]連絡文へとIETFからはで見つけることができます。
[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] "IETFとトランスポートネットワーク機能のためのMPLSの拡張機能の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合同ワーキングチーム、 "トランスポートプロファイルのためのMPLSアーキテクチャの考慮事項"、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>.
、ITU-T SG15、2008年5月、<https://datatracker.ietf.org/documents/ LIAISON / file553.pdf> [MPLS-TP1] "トランスポート・ネットワーク機能のためのMPLSの拡張機能のIETFとITU-Tの協力"。
[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月。
[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.
[シュトゥットガルト] IETF - IESGとIAB議長、 "T-MPLS上Q.12の暫定会議の報告書"、シュトゥットガルト、ドイツ、附属書4、12-14 2007年9月、2008年、<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 / studygroups / COM1···COM15 / ahtmpls.html>。
Editors' Addresses
エディタのアドレス
Stewart Bryant (editor) Cisco Systems 250, Longwater, Green Park, Reading RG2 6GB UK
スチュワートブライアント（エディタ）シスコシステムズ250、Longwater、グリーンパーク、読書RG2 6ギガバイト英国
EMail: stbryant@cisco.com
メールアドレス：stbryant@cisco.com
Loa Andersson (editor) Acreo AB Isafjordsgatan 22 Kista, Sweden
ロア・アンダーソン（エディタ）Acreo AB Isafjordsgatan 22キスタ、スウェーデン
EMail: loa@pi.nu
メールアドレス：loa@pi.nu