[要約] 要約： RFC 6965は、MPLS-TP（MPLS Transport Profile）の適用性、使用事例、および設計に関する情報を提供しています。目的： このRFCの目的は、MPLS-TPの使用事例と設計に関するガイダンスを提供し、MPLSベースのネットワークでのトランスポートプロファイルの適用性を明確にすることです。
Internet Engineering Task Force (IETF) L. Fang, Ed.
Request for Comments: 6965 Cisco
Category: Informational N. Bitar
ISSN: 2070-1721 Verizon
R. Zhang
Alcatel-Lucent
M. Daikoku
KDDI
P. Pan
Infinera
August 2013
MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design
MPLSトランスポートプロファイル（MPLS-TP）の適用性：ユースケースと設計
Abstract
概要
This document describes the applicability of the MPLS Transport Profile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport.
このドキュメントでは、MPLSトランスポートプロファイル（MPLS-TP）の適用性について、ユースケーススタディとネットワーク設計の考慮事項について説明します。ユースケースには、メトロイーサネットアクセスと集約トランスポート、モバイルバックホール、およびパケット光トランスポートが含まれます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6965.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6965で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Background .................................................4
2. MPLS-TP Use Cases ...............................................6
2.1. Metro Access and Aggregation ...............................6
2.2. Packet Optical Transport ...................................7
2.3. Mobile Backhaul ............................................8
2.3.1. 2G and 3G Mobile Backhaul ...........................8
2.3.2. 4G/LTE Mobile Backhaul ..............................9
3. Network Design Considerations ..................................10
3.1. The Role of MPLS-TP .......................................10
3.2. Provisioning Mode .........................................10
3.3. Standards Compliance ......................................10
3.4. End-to-End MPLS OAM Consistency ...........................11
3.5. PW Design Considerations in MPLS-TP Networks ..............11
3.6. Proactive and On-Demand MPLS-TP OAM Tools .................12
3.7. MPLS-TP and IP/MPLS Interworking Considerations ...........12
4. Security Considerations ........................................13
5. Acknowledgements ...............................................13
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................14
7. Contributors ...................................................15
This document describes the applicability of the MPLS Transport Profile (MPLS-TP) with use case studies and network design considerations.
このドキュメントでは、MPLSトランスポートプロファイル（MPLS-TP）の適用性について、ユースケーススタディとネットワーク設計の考慮事項について説明します。
Term Definition
------ -------------------------------------------------------
2G 2nd generation of mobile telecommunications technology
3G 3rd generation of mobile telecommunications technology
4G 4th generation of mobile telecommunications technology
ADSL Asymmetric Digital Subscriber Line
AIS Alarm Indication Signal
ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection
BTS Base Transceiver Station
CC-V Continuity Check and Connectivity Verification
CDMA Code Division Multiple Access
E-LINE Ethernet line; provides point-to-point connectivity
E-LAN Ethernet LAN; provides multipoint connectivity
eNB Evolved Node B
EPC Evolved Packet Core
E-VLAN Ethernet Virtual Private LAN
EVDO Evolution-Data Optimized
G-ACh Generic Associated Channel
GAL G-ACh Label
GMPLS Generalized Multiprotocol Label Switching
GSM Global System for Mobile Communications
HSPA High Speed Packet Access
IPTV Internet Protocol television
L2VPN Layer 2 Virtual Private Network
L3VPN Layer 3 Virtual Private Network
LAN Local Access Network
LDI Link Down Indication
LDP Label Distribution Protocol
LSP Label Switched Path
LTE Long Term Evolution
MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point
MPLS Multiprotocol Label Switching
MPLS-TP MPLS Transport Profile
MS-PW Multi-Segment Pseudowire
NMS Network Management System
OAM Operations, Administration, and Maintenance
PE Provider-Edge device
PW Pseudowire
RAN Radio Access Network
RDI Remote Defect Indication
S-PE PW Switching Provider Edge
S1 LTE Standardized interface between eNB and EPC
SDH Synchronous Digital Hierarchy
SONET Synchronous Optical Network
SP Service Provider
SRLG Shared Risk Link Groups
SS-PW Single-Segment Pseudowire
TDM Time-Division Multiplexing
TFS Time and Frequency Synchronization
tLDP Targeted Label Distribution Protocol
UMTS Universal Mobile Telecommunications System
VPN Virtual Private Network
X2 LTE Standardized interface between eNBs for handover
Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet transport technologies. In addition to the increasing demand for bandwidth, packet transport technologies offer the following key advantages:
従来のトランスポート技術には、SONET / SDH、TDM、およびATMが含まれます。これらのトランスポートテクノロジーから新しいパケットトランスポートテクノロジーへの移行があります。帯域幅への需要の高まりに加えて、パケット転送テクノロジには次の主要な利点があります。
Bandwidth efficiency:
帯域幅効率：
Traditional TDM transport technologies support fixed bandwidth with no statistical multiplexing. The bandwidth is reserved in the transport network, regardless of whether or not it is used by the client. In contrast, packet technologies support statistical multiplexing. This is the most important motivation for the transition from traditional transport technologies to packet transport technologies. The proliferation of new distributed applications that communicate with servers over the network in a bursty fashion has been driving the adoption of packet transport techniques, since packet multiplexing of traffic from bursty sources provides more efficient use of bandwidth than traditional circuit-based TDM technologies.
従来のTDMトランスポートテクノロジーは、統計的多重化なしで固定帯域幅をサポートします。帯域幅は、クライアントが使用するかどうかに関係なく、トランスポートネットワークで予約されます。対照的に、パケット技術は統計的多重化をサポートしています。これは、従来のトランスポートテクノロジーからパケットトランスポートテクノロジーに移行するための最も重要な動機です。バースト性のある方法でネットワークを介してサーバーと通信する新しい分散アプリケーションの急増により、パケット転送技術の採用が促進されています。これは、バースト性のあるソースからのトラフィックのパケット多重化により、従来の回線ベースのTDMテクノロジーよりも効率的に帯域幅を使用できるためです。
Flexible data rate connections:
柔軟なデータレート接続：
The granularity of data rate connections of traditional transport technologies is limited to the rigid Plesiochronous Digital Hierarchy (PDH) hierarchy (e.g., DS1, DS3) or SONET hierarchy (e.g., OC3, OC12). Packet technologies support flexible data rate connections. The support of finer data rate granularity is particularly important for today's wireline and wireless services and applications.
従来のトランスポートテクノロジーのデータレート接続の細分性は、堅固なPlesiochronous Digital Hierarchy（PDH）階層（DS1、DS3など）またはSONET階層（OC3、OC12など）に制限されています。パケットテクノロジーは、柔軟なデータレート接続をサポートしています。より細かいデータレートの細分性のサポートは、今日の有線および無線のサービスとアプリケーションにとって特に重要です。
QoS support:
QoSサポート：
Traditional transport technologies (such as TDM) provide bandwidth guarantees, but they are unaware of the types of traffic they carry. They are not packet aware and do not provide packet-level services. Packet transport can provide the differentiated services capability needed to support oversubscription and to deal with traffic prioritization upon congestion: issues that arise only in packet networks.
従来のトランスポートテクノロジー（TDMなど）は帯域幅を保証しますが、伝送するトラフィックの種類を認識していません。それらはパケット対応ではなく、パケットレベルのサービスを提供しません。パケット転送は、オーバーサブスクリプションをサポートし、輻輳時のトラフィックの優先順位付けに対処するために必要な差別化されたサービス機能を提供できます。これは、パケットネットワークでのみ発生する問題です。
The root cause for transport moving to packet transport is the shift of applications from TDM to packet -- for example, Voice TDM to VoIP, Video to Video over IP, TDM access lines to Ethernet, and TDM VPNs to IP VPNs and Ethernet VPNs. In addition, network convergence and technology refreshes contribute to the demand for a common and flexible infrastructure that provides multiple services.
トランスポートがパケットトランスポートに移行する根本的な原因は、アプリケーションがTDMからパケットに移行することです。たとえば、音声TDMからVoIP、ビデオからビデオオーバーIP、TDMアクセスラインからイーサネット、TDM VPNからIP VPNおよびイーサネットVPNなどです。さらに、ネットワークコンバージェンスとテクノロジーの更新は、複数のサービスを提供する共通で柔軟なインフラストラクチャの需要に貢献します。
As part of the MPLS family, MPLS-TP complements existing IP/MPLS technologies; it closes the gaps in the traditional access and aggregation transport to enable end-to-end packet technology solutions in a cost efficient, reliable, and interoperable manner. After several years of industry debate on which packet technology to use, MPLS-TP has emerged as the next generation transport technology of choice for many Service Providers worldwide.
MPLS-TPは、MPLSファミリーの一部として、既存のIP / MPLSテクノロジーを補完します。従来のアクセスおよび集約トランスポートのギャップを埋め、エンドツーエンドのパケットテクノロジーソリューションをコスト効率の高い、信頼性の高い、相互運用可能な方法で実現します。 MPLS-TPは、使用するパケットテクノロジーについて数年にわたる業界での議論の末、世界中の多くのサービスプロバイダーが選択する次世代のトランスポートテクノロジーとして登場しました。
The Unified MPLS strategy -- using MPLS from core to aggregation and access (e.g., IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation and access) -- appears to be very attractive to many SPs. It streamlines the operation, reduces the overall complexity, and improves end-to-end convergence. It leverages the MPLS experience and enhances the ability to support revenue-generating services.
統合MPLS戦略-コアから集約およびアクセスまでMPLSを使用する（たとえば、コアのIP / MPLS、集約およびアクセスのIP / MPLSまたはMPLS-TP）-多くのSPにとって非常に魅力的です。運用を合理化し、全体的な複雑さを軽減し、エンドツーエンドの収束を改善します。 MPLSエクスペリエンスを活用して、収益を生み出すサービスをサポートする機能を強化します。
MPLS-TP is a subset of MPLS functions that meet the packet transport requirements defined in [RFC5654]. This subset includes: MPLS data forwarding, pseudowire encapsulation for circuit emulation, and dynamic control plane using GMPLS control for LSP and tLDP for pseudowire (PW). MPLS-TP also extends previous MPLS OAM functions, such as the BFD extension for proactive Connectivity Check and Connectivity Verification (CC-V) [RFC6428], Remote Defect Indication (RDI) [RFC6428], and LSP Ping Extension for on-demand CC-V [RFC6426]. New tools have been defined for alarm suppression with Alarm Indication Signal (AIS) [RFC6427] and switch-over triggering with Link Down Indication (LDI) [RFC6427]. Note that since the MPLS OAM feature extensions defined through the process of MPLS-TP development are part of the MPLS family, the applicability is general to MPLS and not limited to MPLS-TP.
MPLS-TPは、[RFC5654]で定義されているパケット転送要件を満たすMPLS機能のサブセットです。このサブセットには、MPLSデータ転送、回線エミュレーションの疑似配線カプセル化、およびLSPのGMPLS制御と疑似配線（PW）のtLDPを使用した動的制御プレーンが含まれます。 MPLS-TPは、プロアクティブな接続性チェックおよび接続性検証（CC-V）[RFC6428]のBFD拡張機能、リモート障害表示（RDI）[RFC6428]、オンデマンドCCのLSP Ping拡張機能など、以前のMPLS OAM機能も拡張します-V [RFC6426]。アラーム表示信号（AIS）によるアラーム抑制とリンクダウン表示（LDI）による切り替えトリガー[RFC6427]のための新しいツールが定義されました。 MPLS-TP開発のプロセスを通じて定義されたMPLS OAM機能拡張はMPLSファミリーの一部であるため、適用範囲はMPLSに一般的であり、MPLS-TPに限定されないことに注意してください。
The requirements of MPLS-TP are provided in the MPLS-TP requirements document [RFC5654], and the architectural framework is defined in the MPLS-TP framework document [RFC5921]. This document's intent is to provide the use case studies and design considerations from a practical point of view based on Service Providers' deployments plans as well as actual deployments.
MPLS-TPの要件はMPLS-TP要件ドキュメント[RFC5654]で提供されており、アーキテクチャフレームワークはMPLS-TPフレームワークドキュメント[RFC5921]で定義されています。このドキュメントの目的は、サービスプロバイダーの展開計画と実際の展開に基づいて、実用的な観点からユースケーススタディと設計に関する考慮事項を提供することです。
The most common use cases for MPLS-TP include Metro access and aggregation, mobile backhaul, and packet optical transport. MPLS-TP data-plane architecture, path protection mechanisms, and OAM functionality are used to support these deployment scenarios.
MPLS-TPの最も一般的な使用例には、メトロアクセスと集約、モバイルバックホール、およびパケット光トランスポートが含まれます。 MPLS-TPデータプレーンアーキテクチャ、UPSRメカニズム、およびOAM機能は、これらの展開シナリオをサポートするために使用されます。
The design considerations discussed in this document include the role of MPLS-TP in the network, provisioning options, standards compliance, end-to-end forwarding and OAM consistency, compatibility with existing IP/MPLS networks, and optimization vs. simplicity design trade-offs.
このドキュメントで説明する設計上の考慮事項には、ネットワークでのMPLS-TPの役割、プロビジョニングオプション、標準への準拠、エンドツーエンドの転送とOAMの一貫性、既存のIP / MPLSネットワークとの互換性、最適化とシンプルさの設計トレードが含まれます。オフ。
The use of MPLS-TP for Metro access and aggregation transport is the most common deployment scenario observed in the field.
メトロアクセスおよび集約トランスポートにMPLS-TPを使用することは、現場で観察される最も一般的な展開シナリオです。
Some operators are building green-field access and aggregation transport infrastructure, while others are upgrading or replacing their existing transport infrastructure with new packet technologies. The existing legacy access and aggregation networks are usually based on TDM or ATM technologies. Some operators are replacing these networks with MPLS-TP technologies, since legacy ATM/TDM aggregation and access are becoming inadequate to support the rapid business growth and too expensive to maintain. In addition, in many cases the legacy devices are facing End of Sale and End of Life issues. As operators must move forward with the next-generation packet technology, the adoption of MPLS-TP in access and aggregation becomes a natural choice. The statistical multiplexing in MPLS-TP helps to achieve higher efficiency compared with the time-division scheme in the legacy technologies. MPLS-TP OAM tools and protection mechanisms help to maintain high reliability of transport networks and achieve fast recovery.
一部の事業者はグリーンフィールドアクセスおよび集約トランスポートインフラストラクチャを構築していますが、他の事業者は既存のトランスポートインフラストラクチャを新しいパケットテクノロジーにアップグレードまたは交換しています。既存のレガシーアクセスおよび集約ネットワークは通常、TDMまたはATMテクノロジーに基づいています。従来のATM / TDM集約とアクセスは急速なビジネスの成長をサポートするには不十分であり、維持するにはコストがかかりすぎるため、一部の事業者はこれらのネットワークをMPLS-TPテクノロジーに置き換えています。さらに、多くの場合、レガシーデバイスは販売終了およびサポート終了の問題に直面しています。オペレーターは次世代のパケットテクノロジーを採用する必要があるため、アクセスと集約にMPLS-TPを採用するのは自然な選択です。 MPLS-TPの統計的多重化は、レガシー技術の時分割スキームと比較して、より高い効率を達成するのに役立ちます。 MPLS-TP OAMツールと保護メカニズムは、トランスポートネットワークの高い信頼性を維持し、高速リカバリを実現するのに役立ちます。
As most Service Providers' core networks are MPLS enabled, extending the MPLS technology to the aggregation and access transport networks with a Unified MPLS strategy is very attractive to many Service Providers. Unified MPLS strategy in this document means having end-to-end MPLS technologies through core, aggregation, and access. It reduces operating expenses by streamlining the operation and leveraging the operational experience already gained with MPLS technologies; it also improves network efficiency and reduces end-to-end convergence time.
ほとんどのサービスプロバイダーのコアネットワークはMPLS対応であるため、Unified MPLS戦略を使用してMPLSテクノロジーを集約およびアクセストランスポートネットワークに拡張することは、多くのサービスプロバイダーにとって非常に魅力的です。このドキュメントの統合MPLS戦略は、コア、アグリゲーション、およびアクセスを通じてエンドツーエンドのMPLSテクノロジーを持つことを意味します。運用を合理化し、MPLSテクノロジーですでに得られた運用経験を活用することにより、運用コストを削減します。また、ネットワークの効率が向上し、エンドツーエンドのコンバージェンス時間が短縮されます。
The requirements from the SPs for ATM/TDM aggregation replacement often include:
多くの場合、ATM / TDMアグリゲーション交換のためのSPからの要件には、
- maintaining the previous operational model, which means providing a similar user experience in NMS,
- 以前の運用モデルを維持します。つまり、NMSで同様のユーザーエクスペリエンスを提供します。
- supporting the existing access network (e.g., Ethernet, ADSL, ATM, TDM, etc.) and connections with the core networks, and
- 既存のアクセスネットワーク（イーサネット、ADSL、ATM、TDMなど）およびコアネットワークとの接続をサポートします。
- supporting the same operational capabilities and services (L3VPN, L2VPN, E-LINE/E-LAN/E-VLAN, Dedicated Line, etc.).
- 同じ操作機能とサービス（L3VPN、L2VPN、E-LINE / E-LAN / E-VLAN、専用線など）をサポートします。
MPLS-TP can meet these requirements and, in general, the requirements defined in [RFC5654] to support a smooth transition.
MPLS-TPは、これらの要件、および一般に、スムーズな移行をサポートするために[RFC5654]で定義された要件を満たすことができます。
Many SPs' transport networks consist of both packet and optical portions. The transport operators are typically sensitive to network deployment cost and operational simplicity. MPLS-TP supports both static provisioning through NMS and dynamic provisioning via the GMPLS control plane. As such, it is viewed as a natural fit in transport networks where the operators can utilize the MPLS-TP LSPs (including the ones statically provisioned) to manage user traffic as "circuits" in both packet and optical networks. Also, when the operators are ready, they can migrate the network to use the dynamic control plane for greater efficiency.
多くのSPのトランスポートネットワークは、パケット部分と光部分の両方で構成されています。トランスポートオペレーターは、通常、ネットワークの導入コストと運用のシンプルさに敏感です。 MPLS-TPは、NMSを介した静的プロビジョニングとGMPLSコントロールプレーンを介した動的プロビジョニングの両方をサポートしています。そのため、オペレーターがMPLS-TP LSP（静的にプロビジョニングされたものを含む）を利用して、ユーザートラフィックをパケットおよび光ネットワークの両方で「回線」として管理できるトランスポートネットワークに自然に適合していると見なされます。また、オペレータの準備が整ったら、ネットワークを移行して、ダイナミックコントロールプレーンを使用して効率を上げることができます。
Among other attributes, bandwidth management, protection/recovery, and OAM are critical in packet/optical transport networks. In the context of MPLS-TP, LSPs may be associated with bandwidth allocation policies. OAM is to be performed on each individual LSP. For some of the performance monitoring functions, the OAM mechanisms need to be able to transmit and process OAM packets at very high frequency. An overview of the MPLS-TP OAM toolset is found in [RFC6669].
他の属性の中で、帯域幅管理、保護/回復、およびOAMは、パケット/光トランスポートネットワークで重要です。 MPLS-TPのコンテキストでは、LSPは帯域幅割り当てポリシーに関連付けられている場合があります。 OAMは、個々のLSPごとに実行されます。一部のパフォーマンス監視機能では、OAMメカニズムが非常に高い頻度でOAMパケットを送信および処理できる必要があります。 MPLS-TP OAMツールセットの概要は[RFC6669]にあります。
Protection, as defined in [RFC6372], is another important element in transport networks. Typically, ring and linear protection can be readily applied in metro networks. However, as long-haul networks are sensitive to bandwidth cost and tend to have mesh-like topology, shared mesh protection is becoming increasingly important.
[RFC6372]で定義されている保護は、トランスポートネットワークにおけるもう1つの重要な要素です。通常、リングおよび線形保護は、メトロネットワークに簡単に適用できます。ただし、長距離ネットワークは帯域幅のコストに敏感であり、メッシュのようなトポロジを持つ傾向があるため、共有メッシュ保護の重要性が増しています。
In some cases, SPs plan to deploy MPLS-TP from their long-haul optical packet transport all the way to the aggregation and access in their networks.
場合によっては、SPはMPLS-TPを長距離光パケットトランスポートからアグリゲーションおよびネットワークでのアクセスに至るまで展開することを計画しています。
Wireless communication is one of the fastest growing areas in communication worldwide. In some regions, the tremendous mobile growth is fueled by the lack of existing landline and cable infrastructure. In other regions, the introduction of smart phones is quickly driving mobile data traffic to become the primary mobile bandwidth consumer (some SPs have already observed that more than 85% of total mobile traffic is data traffic). MPLS-TP is viewed as a suitable technology for mobile backhaul.
ワイヤレス通信は、世界中で最も急成長している通信分野の1つです。一部の地域では、既存の固定電話とケーブルインフラストラクチャの不足がモバイルの驚異的な成長を支えています。他の地域では、スマートフォンの導入により、モバイルデータトラフィックが急速に主要なモバイル帯域幅の消費者になっています（一部のSPは、モバイルトラフィック全体の85％以上がデータトラフィックであることをすでに確認しています）。 MPLS-TPは、モバイルバックホールに適したテクノロジーと見なされています。
MPLS-TP is commonly viewed as a very good fit for 2G/3G mobile backhaul. 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) mobile backhaul networks are still currently dominating the mobile infrastructure.
MPLS-TPは一般に、2G / 3Gモバイルバックホールに非常に適していると見なされています。 2G（GSM / CDMA）および3G（UMTS / HSPA / 1xEVDO）モバイルバックホールネットワークは、現在もモバイルインフラストラクチャを支配しています。
The connectivity for 2G/3G networks is point to point (P2P). The logical connections have a hub-and-spoke configuration. Networks are physically constructed using a star or ring topology. In the Radio Access Network (RAN), each mobile Base Transceiver Station (BTS/Node B) is communicating with a Base Station Controller (BSC) or Radio Network Controller (RNC). These connections are often statically set up.
2G / 3Gネットワークの接続はポイントツーポイント（P2P）です。論理接続には、ハブアンドスポーク構成があります。ネットワークは、スタートポロジまたはリングトポロジを使用して物理的に構築されます。無線アクセスネットワーク（RAN）では、各モバイルベーストランシーバーステーション（BTS /ノードB）は、基地局コントローラー（BSC）または無線ネットワークコントローラー（RNC）と通信しています。これらの接続は、静的に設定されることがよくあります。
Hierarchical or centralized architectures are often used for pre-aggregation and aggregation layers. Each aggregation network interconnects with multiple access networks. For example, a single aggregation ring could aggregate traffic for 10 access rings with a total of 100 base stations.
階層型アーキテクチャまたは集中型アーキテクチャは、事前集計レイヤーおよび集計レイヤーによく使用されます。各集約ネットワークは、複数のアクセスネットワークと相互接続します。たとえば、単一のアグリゲーションリングで、合計100個の基地局を持つ10個のアクセスリングのトラフィックを集約できます。
The technology used today is largely ATM based. Mobile providers are replacing the ATM RAN infrastructure with newer packet technologies. IP RAN networks with IP/MPLS technologies are deployed today by many SPs with great success. MPLS-TP is another suitable choice for Mobile RAN. The P2P connections from base station to Radio Controller can be set statically to mimic the operation of today's RAN environments; in-band OAM and deterministic path protection can support fast failure detection and switch-over to satisfy service level agreements (SLAs). Bidirectional LSPs may help to simplify the provisioning process. The deterministic nature of MPLS-TP LSP setup can also support packet-based synchronization to maintain predictable performance regarding packet delay and jitter. The traffic-engineered and co-routed bidirectional properties of an MPLS-TP LSP are of benefit in transporting packet-based Time and Frequency Synchronization (TFS) protocols, such as [TICTOC]. However, the choice between an external, physical-layer method or a packet-based TFS method is network dependent and thus is out of scope of this document.
現在使用されているテクノロジーは、主にATMベースです。モバイルプロバイダーは、ATM RANインフラストラクチャを新しいパケットテクノロジーに置き換えています。 IP / MPLSテクノロジーを備えたIP RANネットワークは、今日多くのSPによって導入され、大きな成功を収めています。 MPLS-TPは、モバイルRANに適した別の選択肢です。ベースステーションから無線コントローラーへのP2P接続は、静的に設定して、今日のRAN環境の動作を模倣できます。帯域内OAMと確定的パス保護は、サービスレベルアグリーメント（SLA）を満たすために、高速障害検出と切り替えをサポートできます。双方向LSPは、プロビジョニングプロセスを簡略化するのに役立ちます。 MPLS-TP LSPセットアップの決定論的な性質は、パケットベースの同期をサポートして、パケットの遅延とジッタに関する予測可能なパフォーマンスを維持することもできます。 MPLS-TP LSPのトラフィックエンジニアリングおよびコルートされた双方向プロパティは、[TICTOC]などのパケットベースの時間および周波数同期（TFS）プロトコルの転送に役立ちます。ただし、外部の物理層方式またはパケットベースのTFS方式のどちらを選択するかはネットワークに依存するため、このドキュメントの範囲外です。
One key difference between LTE and 2G/3G mobile networks is that the logical connection in LTE is a mesh, while in 2G/3G it is a P2P star. In LTE, each base station (eNB/BTS) communicates with multiple network controllers (e.g., Packet Data Network Gateway, Packet Data Network Serving Gateway, Access Service Network Gateway), and the radio elements communicate with one another for signal exchange and traffic offload to wireless or wireline infrastructures.
LTEと2G / 3Gモバイルネットワークの主な違いの1つは、LTEの論理接続はメッシュであるのに対し、2G / 3GではP2Pスターであることです。 LTEでは、各基地局（eNB / BTS）は複数のネットワークコントローラー（パケットデータネットワークゲートウェイ、パケットデータネットワークサービスゲートウェイ、アクセスサービスネットワークゲートウェイなど）と通信し、無線要素は信号交換とトラフィックオフロードのために互いに通信しますワイヤレスまたは有線インフラストラクチャに。
IP/MPLS has a great advantage in any-to-any connectivity environments. Thus, the use of mature IP or L3VPN technologies is particularly common in the design of an SP's LTE deployment plans.
IP / MPLSは、多対多の接続環境で大きな利点があります。したがって、SPのLTE展開計画の設計では、成熟したIPまたはL3VPNテクノロジの使用が特に一般的です。
The extended OAM functions defined in MPLS-TP, such as in-band OAM and path protection mechanisms, bring additional advantages to support SLAs. The dynamic control plane with GMPLS signaling is especially suited for the mesh environment, to support dynamic topology changes and network optimization.
インバンドOAMやパス保護メカニズムなど、MPLS-TPで定義された拡張OAM機能には、SLAをサポートするための追加の利点があります。 GMPLSシグナリングを備えた動的コントロールプレーンは、動的トポロジ変更とネットワーク最適化をサポートするために、メッシュ環境に特に適しています。
Some operators are using the same model as in 2G and 3G mobile backhaul, which uses IP/MPLS in the core and MPLS-TP with static provisioning (through NMS) in aggregation and access. The reasoning is as follows: currently, the X2 traffic load in LTE networks may be a very small percentage of the total traffic. For example, one large mobile operator observed that X2 traffic was less than one percent of the total S1 traffic. Therefore, optimizing the X2 traffic may not be the design objective in this case. The X2 traffic can be carried through the same static tunnels together with the S1 traffic in the aggregation and access networks and further forwarded across the IP/MPLS core. In addition, mesh protection may be more efficient with regard to bandwidth utilization, but linear protection and ring protection are often considered simpler by some operators from the point of view of operation maintenance and troubleshooting, and so are widely deployed. In general, using MPLS-TP with static provisioning for LTE backhaul is a viable option. The design objective of using this approach is to keep the operation simple and use a common model for mobile backhaul, especially during the transition period.
一部の事業者は、2Gおよび3Gモバイルバックホールと同じモデルを使用しています。このモデルでは、コアでIP / MPLSを使用し、集約およびアクセスで静的プロビジョニング（NMSを介して）を使用してMPLS-TPを使用します。その理由は次のとおりです。現在、LTEネットワークのX2トラフィック負荷は、総トラフィックのごくわずかな割合である可能性があります。たとえば、ある大手携帯電話会社は、X2トラフィックがS1トラフィック全体の1％未満であることを確認しました。したがって、X2トラフィックの最適化は、この場合の設計目標ではない可能性があります。 X2トラフィックは、集約およびアクセスネットワークのS1トラフィックと同じ静的トンネルを介して伝送され、さらにIP / MPLSコアを介して転送されます。さらに、メッシュ保護は帯域幅の利用に関してはより効率的ですが、線形保護とリング保護は多くの場合、運用の保守とトラブルシューティングの観点から一部のオペレーターによって単純であると考えられており、広く展開されています。一般に、LTEバックホールの静的プロビジョニングでMPLS-TPを使用することは、実行可能なオプションです。このアプローチを使用する設計の目的は、特に移行期間中は、操作をシンプルに保ち、モバイルバックホールの共通モデルを使用することです。
The TFS considerations stated in Section 2.3.1 apply to the 4G/LTE mobile backhaul case as well.
セクション2.3.1に記載されているTFSの考慮事項は、4G / LTEモバイルバックホールの場合にも適用されます。
The role of MPLS-TP is to provide a solution to help evolve traditional transport towards packet transport networks. It is designed to support the transport characteristics and behavior described in [RFC5654]. The primary use of MPLS-TP is largely to replace legacy transport technologies, such as SONET/SDH. MPLS-TP is not designed to replace the service support capabilities of IP/MPLS, such as L2VPN, L3VPN, IPTV, Mobile RAN, etc.
MPLS-TPの役割は、従来のトランスポートをパケットトランスポートネットワークへと進化させるソリューションを提供することです。 [RFC5654]で説明されているトランスポートの特性と動作をサポートするように設計されています。 MPLS-TPの主な用途は、主にSONET / SDHなどのレガシートランスポートテクノロジーを置き換えることです。 MPLS-TPは、L2VPN、L3VPN、IPTV、モバイルRANなどのIP / MPLSのサービスサポート機能を置き換えるようには設計されていません。
MPLS-TP supports two provisioning modes:
MPLS-TPは2つのプロビジョニングモードをサポートします。
- a mandatory static provisioning mode, which must be supported without dependency on dynamic routing or signaling; and
- 必須の静的プロビジョニングモード。動的ルーティングやシグナリングに依存せずにサポートする必要があります。そして
- an optional distributed dynamic control plane, which is used to enable dynamic service provisioning.
- オプションの分散動的コントロールプレーン。動的サービスプロビジョニングを有効にするために使用されます。
The decision on which mode to use is largely dependent on the operational feasibility and the stage of network transition. Operators who are accustomed to the transport-centric operational model (e.g., NMS configuration without control plane) typically prefer the static provisioning mode. This is the most common choice in current deployments. The dynamic provisioning mode can be more powerful, but it is more suited to operators who are familiar with the operation and maintenance of IP/MPLS technologies or are ready to step up through training and planned transition.
どちらのモードを使用するかの決定は、運用の実現可能性とネットワーク移行の段階に大きく依存します。トランスポート中心の運用モデル（コントロールプレーンのないNMS構成など）に慣れているオペレーターは、通常、静的プロビジョニングモードを好みます。これは、現在の展開で最も一般的な選択です。ダイナミックプロビジョニングモードはより強力ですが、IP / MPLSテクノロジーの運用とメンテナンスに精通しているオペレーター、またはトレーニングと計画された移行をステップアップする準備ができているオペレーターに適しています。
There may also be cases where operators choose to use the combination of both modes. This is appropriate when parts of the network are provisioned in a static fashion, and other parts are controlled by dynamic signaling. This combination may also be used to transition from static provisioning to dynamic control plane.
オペレーターが両方のモードの組み合わせを使用することを選択する場合もあります。これは、ネットワークの一部が静的にプロビジョニングされ、他の部分が動的シグナリングによって制御される場合に適しています。この組み合わせは、静的プロビジョニングから動的コントロールプレーンへの移行にも使用できます。
SPs generally recognize that standards compliance is important for lowering cost, accelerating product maturity, achieving multi-vendor interoperability, and meeting the expectations of their enterprise customers.
SPは一般に、コストの削減、製品の成熟度の加速、マルチベンダーの相互運用性の実現、企業顧客の期待を満たすために、標準への準拠が重要であることを認識しています。
MPLS-TP is a joint work between the IETF and ITU-T. In April 2008, the IETF and ITU-T jointly agreed to terminate T-MPLS and progress MPLS-TP as joint work [RFC5317]. The transport requirements are provided by the ITU-T; the protocols are developed in the IETF.
MPLS-TPは、IETFとITU-Tの共同作業です。 2008年4月、IETFとITU-Tは共同でT-MPLSを終了し、MPLS-TPを共同作業として進めることで合意しました[RFC5317]。トランスポート要件はITU-Tによって提供されます。プロトコルはIETFで開発されています。
End-to-end MPLS OAM consistency is highly desirable in order to enable Service Providers to deploy an end-to-end MPLS solution. As MPLS-TP adds OAM function to the MPLS toolkit, it cannot be expected that a full-function end-to-end LSP with MPLS-TP OAM can be achieved when the LSP traverses a legacy MPLS/IP core. Although it may be possible to select a subset of MPLS-TP OAM that can be gatewayed to the legacy MPLS/IP OAM, a better solution is achieved by tunneling the MPLS-TP LSP over the legacy MPLS/IP network. In that mode of operation, legacy OAM may be run on the tunnel in the core, and the tunnel endpoints may report issues in as much detail as possible to the MIPs in the MPLS-TP LSP. Note that over time it is expected that routers in the MPLS/IP core will be upgraded to fully support MPLS-TP features. Once this has occurred, it will be possible to run end-to-end MPLS-TP LSPs seamlessly across the core.
エンドツーエンドのMPLS OAMの一貫性は、サービスプロバイダーがエンドツーエンドのMPLSソリューションを展開できるようにするために非常に望ましいものです。 MPLS-TPはOLS機能をMPLSツールキットに追加するため、LSPがレガシーMPLS / IPコアを通過するときに、MPLS-TP OAMを使用した全機能のエンドツーエンドLSPを実現できるとは期待できません。レガシーMPLS / IP OAMにゲートウェイ処理できるMPLS-TP OAMのサブセットを選択することは可能ですが、レガシーMPLS / IPネットワークを介してMPLS-TP LSPをトンネリングすることにより、より良いソリューションが実現します。その動作モードでは、レガシーOAMがコアのトンネルで実行され、トンネルエンドポイントがMPLS-TP LSPのMIPにできるだけ詳細に問題を報告する場合があります。時間の経過とともに、MPLS / IPコアのルーターがMPLS-TP機能を完全にサポートするようにアップグレードされることが予想されることに注意してください。これが発生すると、エンドツーエンドのMPLS-TP LSPをコア全体でシームレスに実行できます。
In general, PWs in MPLS-TP work the same as in IP/MPLS networks. Both Single-Segment PW (SS-PW) and Multi-Segment PW (MS-PW) are supported. For dynamic control plane, Targeted LDP (tLDP) is used. In static provisioning mode, PW status is a new PW OAM feature for failure notification. In addition, both directions of a PW must be bound to the same transport bidirectional LSP.
一般に、MPLS-TPのPWは、IP / MPLSネットワークと同じように機能します。単一セグメントPW（SS-PW）と複数セグメントPW（MS-PW）の両方がサポートされています。ダイナミックコントロールプレーンの場合、Targeted LDP（tLDP）が使用されます。静的プロビジョニングモードでは、PWステータスは障害通知のための新しいPW OAM機能です。さらに、PWの両方向は、同じトランスポート双方向LSPにバインドする必要があります。
In the common network topology involving multi-tier rings, the design choice is between using SS-PW or MS-PW. This is not a discussion unique to MPLS-TP, as it applies to PW design in general. However, it is relevant here, since MPLS-TP is more sensitive to the operational complexities, as noted by operators. If MS-PW is used, Switching PE (S-PE) must be deployed to connect the rings. The advantage of this choice is that it provides domain isolation, which in turn facilitates troubleshooting and allows for faster PW failure recovery. On the other hand, the disadvantage of using S-PE is that it adds more complexity. Using SS-PW is simpler, since it does not require S-PEs, but it is less efficient because the paths across primary and secondary rings are longer. If operational simplicity is a higher priority, some SPs choose SS-PW.
多層リングを含む一般的なネットワークトポロジでは、設計の選択はSS-PWまたはMS-PWを使用することです。これは、一般的なPW設計に適用されるため、MPLS-TPに固有の説明ではありません。ただし、MPLS-TPは、オペレーターが指摘するように、操作の複雑さに対してより敏感であるため、ここでは重要です。 MS-PWを使用する場合は、リングを接続するためにスイッチングPE（S-PE）を展開する必要があります。この選択の利点は、ドメインの分離が提供されることです。これにより、トラブルシューティングが容易になり、より高速なPW障害回復が可能になります。一方、S-PEの欠点は、複雑さが増すことです。 SS-PWはS-PEを必要としないため、より簡単ですが、プライマリリングとセカンダリリング間のパスが長くなるため、効率が低下します。運用のシンプルさが優先される場合、一部のSPはSS-PWを選択します。
Another design trade-off is whether to use PW protection in addition to LSP protection or rely solely on LSP protection. When the MPLS-TP LSPs are protected, if the working LSP fails, the protecting LSP assures that the connectivity is maintained and the PW is not impacted. However, in the case of simultaneous failure of both the working and protecting LSPs, the attached PW would fail. By adding PW protection and attaching the protecting PW to a diverse LSP not in the same Shared Risk Link Group (SRLG), the PW is protected even when the primary PW fails. Clearly, using PW protection adds considerably more complexity and resource usage, and thus operators often may choose not to use it and consider protection against a single point of failure as sufficient.
もう1つの設計上のトレードオフは、LSP保護に加えてPW保護を使用するか、LSP保護のみに依存するかです。 MPLS-TP LSPが保護されている場合、現用LSPに障害が発生しても、保護LSPは接続が維持され、PWに影響が及ばないことを保証します。ただし、機能しているLSPと保護しているLSPの両方に同時に障害が発生した場合、接続されたPWは失敗します。 PW保護を追加し、同じ共有リスクリンクグループ（SRLG）にない多様なLSPに保護PWを接続することにより、プライマリPWに障害が発生した場合でもPWが保護されます。明らかに、PW保護を使用すると、複雑さとリソースの使用量が大幅に増えるため、オペレーターはそれを使用しないことを選択し、単一障害点に対する保護を十分に考慮します。
MPLS-TP provides both proactive and on-demand OAM tools. As a proactive OAM fault management tool, BFD Connectivity Check (CC) can be sent at regular intervals for Connectivity Check; three (or a configurable number) of missed CC messages can trigger the failure protection switch-over. BFD sessions are configured for both working and protecting LSPs.
MPLS-TPは、プロアクティブOAMツールとオンデマンドOAMツールの両方を提供します。プロアクティブなOAM障害管理ツールとして、BFD接続チェック（CC）を定期的に送信して接続チェックを行うことができます。 3つ（または構成可能な数）のCCメッセージが失われた場合、障害保護の切り替えがトリガーされます。 BFDセッションは、機能しているLSPと保護しているLSPの両方に対して設定されます。
A design decision is choosing the value of the BFD CC interval. The shorter the interval, the faster the detection time is, but also the higher the resource utilization is. The proper value depends on the application and the service needs, as well as the protection mechanism provided at the lower layer.
設計上の決定は、BFD CC間隔の値を選択することです。間隔が短いほど、検出時間は速くなりますが、リソース使用率も高くなります。適切な値は、アプリケーションとサービスのニーズ、および下位層で提供される保護メカニズムによって異なります。
As an on-demand OAM fault management mechanism (for example, when there is a fiber cut), a Link Down Indication (LDI) message [RFC6427] can be generated from the failure point and propagated to the Maintenance Entity Group End Points (MEPs) to trigger immediate switch-over from working to protecting path. An Alarm Indication Signal (AIS) can be propagated from the Maintenance Entity Group Intermediate Point (MIP) to the MEPs for alarm suppression.
オンデマンドOAM障害管理メカニズム（たとえば、ファイバーカットがある場合）として、リンクダウン表示（LDI）メッセージ[RFC6427]を障害ポイントから生成し、メンテナンスエンティティグループエンドポイント（MEP）に伝達できます。 ）現用パスから保護パスへの即時切り替えをトリガーします。アラーム表示信号（AIS）は、メンテナンスエンティティグループ中間ポイント（MIP）からMEPに伝播して、アラームを抑制できます。
In general, both proactive and on-demand OAM tools should be enabled to guarantee short switch-over times.
一般に、プロアクティブとオンデマンドの両方のOAMツールを有効にして、短い切り替え時間を保証する必要があります。
Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and IP/MPLS interworking is inevitable if not a reality. However, interworking discussion is out of the scope of this document; it is for further study.
IP / MPLSは主にほとんどのSPのネットワークに配備されているため、MPLS-TPとIP / MPLSのインターワーキングは、現実ではないとしても避けられません。ただし、インターワーキングの議論はこのドキュメントの範囲外です。今後の検討課題です。
Under the use case of Metro access and aggregation, in the scenario where some of the access equipment is placed in facilities not owned by the SP, the static provisioning mode of MPLS-TP is often preferred over the control-plane option because it eliminates the possibility of a control-plane attack, which may potentially impact the whole network. This scenario falls into the Security Reference Model 2 as described in [RFC6941].
メトロアクセスと集約のユースケースでは、アクセス機器の一部がSPが所有していない施設に配置されているシナリオでは、MPLS-TPの静的プロビジョニングモードが、コントロールプレーンオプションよりも優先されます。コントロールプレーン攻撃の可能性。ネットワーク全体に影響を与える可能性があります。このシナリオは、[RFC6941]で説明されているセキュリティ参照モデル2に該当します。
Similar location issues apply to the mobile use cases since equipment is often placed in remote and outdoor environment, which can increase the risk of unauthorized access to the equipment.
機器はリモートおよび屋外環境に配置されることが多く、機器への不正アクセスのリスクを高める可能性があるため、同様の場所の問題がモバイルの使用例にも当てはまります。
In general, NMS access can be a common point of attack in all MPLS-TP use cases, and attacks to GAL or G-ACh are unique security threats to MPLS-TP. The MPLS-TP security considerations are discussed in the MPLS-TP security framework [RFC6941]. General security considerations for MPLS and GMPLS networks are addressed in "Security Framework for MPLS and GMPLS Networks" [RFC5920].
一般に、NMSアクセスはすべてのMPLS-TPユースケースで共通の攻撃ポイントになる可能性があり、GALまたはG-AChへの攻撃は、MPLS-TPに固有のセキュリティ脅威です。 MPLS-TPセキュリティの考慮事項は、MPLS-TPセキュリティフレームワーク[RFC6941]で説明されています。 MPLSおよびGMPLSネットワークの一般的なセキュリティの考慮事項は、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」[RFC5920]で対処されています。
The authors wish to thank Adrian Farrel for his review as Routing Area Director and his continued support and guidance. Adrian's detailed comments and suggestions were of great help for improving the quality of this document. In addition, the authors would like to thank the following individuals: Loa Andersson for his continued support and guidance; Weiqiang Cheng for his helpful input on LTE mobile backhaul based on his knowledge and experience in real world deployment; Stewart Bryant for his text contribution on timing; Russ Housley for his improvement suggestions; Andrew Malis for his support and use case discussion; Pablo Frank, Lucy Yong, Huub van Helvoort, Tom Petch, Curtis Villamizar, and Paul Doolan for their comments and suggestions; and Joseph Yee and Miguel Garcia for their APPSDIR and Gen-ART reviews and comments, respectively.
著者はルーティングエリアディレクターとしての彼のレビューと彼の継続的なサポートとガイダンスを提供してくれたAdrian Farrelに感謝します。エイドリアンの詳細なコメントと提案は、このドキュメントの品質を向上させるのに非常に役立ちました。さらに、著者は次の個人に感謝したいと思います。ロア・アンダーソンは彼の継続的なサポートと指導に感謝します。 Weiqiang Chengは、実際の展開における知識と経験に基づいたLTEモバイルバックホールに関する有益な情報を提供してくれました。スチュワートブライアントは、タイミングに関するテキストを寄稿してくれました。 Russ Housley氏の改善提案。 Andrew Malis氏のサポートとユースケースディスカッション。パブロフランク、ルーシーヨン、フーブファンヘルボート、トムペッチ、カーティスビジャミザール、ポールドゥーランのコメントと提案。 APPSDIRとGen-ARTのレビューとコメントをそれぞれ提供してくれたJoseph YeeとMiguel Garcia。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、and S. Ueno、 "Requirements of an MPLS Transport Profile"、RFC 5654 、2009年9月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、and L. Berger、 "A Framework for MPLS in Transport Networks"、RFC 5921、 2010年7月。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6426]グレイ、E、バハドゥール、N、ブトロス、S、およびRアガーワル、「MPLSオンデマンド接続検証およびルートトレース」、RFC 6426、2011年11月。
[RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed., Boutros, S., and D. Ward, "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011.
[RFC6427] Swallow、G.、Ed。、Fulignoli、A.、Ed。、Vigoureux、M.、Ed。、Boutros、S.、and D. Ward、 "MPLS Fault Management Operations、Administration、and Maintenance（OAM） "、RFC 6427、2011年11月。
[RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed., "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011.
[RFC6428] Allan、D.、Ed。、Swallow Ed。、G。、およびJ. Drake Ed。、「MPLSトランスポートプロファイルのプロアクティブな接続検証、継続性チェック、およびリモート障害表示」、RFC 6428、2011年11月。
[RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009.
[RFC5317] Bryant、S.、Ed。、and L. Andersson、Ed。、 "Joint Working Team（JWT）Report on MPLS Architectural Considerations for a Transport Profile"、RFC 5317、2009年2月。
[RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011.
[RFC6372] Sprecher、N.、Ed。、and A. Farrel、Ed。、 "MPLS Transport Profile（MPLS-TP）Survivability Framework"、RFC 6372、September 2011。
[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks", RFC 6669, July 2012.
[RFC6669] Sprecher、N。およびL. Fang、「MPLSベースのトランスポートネットワークの運用、管理、および保守（OAM）ツールセットの概要」、RFC 6669、2012年7月。
[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.
[RFC6941] Fang、L.、Ed。、Niven-Jenkins、B.、Ed。、Mansfield、S.、Ed。、and R. Graveman、Ed。、 "MPLS Transport Profile（MPLS-TP）Security Framework"、 RFC 6941、2013年4月。
[TICTOC] Davari, S., Oren, A., Bhatia, M., Roberts, P., Montini, L., and L. Martini, "Transporting Timing messages over MPLS Networks", Work in Progress, June 2013.
[TICTOC] Davari、S.、Oren、A.、Bhatia、M.、Roberts、P.、Montini、L。、およびL. Martini、「Transporting Timing messages over MPLS Networks」、Work in Progress、2013年6月。
Kam Lee Yap XO Communications 13865 Sunrise Valley Drive Herndon, VA 20171 United States EMail: klyap@xo.com
カムリーヤップXOコミュニケーションズ13865サンライズバレードライブハーンドン、バージニア州20171米国Eメール：klyap@xo.com
Dan Frost Cisco Systems, Inc. United Kingdom EMail: danfrost@cisco.com
Dan Frost Cisco Systems、Inc.イギリスEメール：danfrost@cisco.com
Henry Yu TW Telecom 10475 Park Meadow Dr. Littleton, CO 80124 United States EMail: henry.yu@twtelecom.com
Henry Yu TW Telecom 10475 Park Meadow Dr. Littleton、CO 80124 United States Eメール：henry.yu@twtelecom.com
Jian Ping Zhang China Telecom, Shanghai Room 3402, 211 Shi Ji Da Dao Pu Dong District, Shanghai China EMail: zhangjp@shtel.com.cn
J Ian ping Zhang China telecom、Shanghai room 3402、211 shi J IDA DAO PU dong District、Shanghai China email：张建平@室tel.com。Talent
Lei Wang Lime Networks Strandveien 30, 1366 Lysaker Norway EMail: lei.wang@limenetworks.no
Lei Wang Lime Networks Strandveien 30、1366 Lysaker Norway EMail：lei.wang@limenetworks.no
Mach (Guoyi) Chen Huawei Technologies Co., Ltd. No. 3 Xinxi Road Shangdi Information Industry Base Hai-Dian District, Beijing 100085 China EMail: mach@huawei.com
Mach（Guoyi）Chen Huawei Technologies Co.、Ltd. No. 3 Xinxi Road Shangdi Information Industry Base Hai-Dian District、Beijing 100085 Chinaメール：mach@huawei.com
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel EMail: nurit.sprecher@nsn.com
ぬりｔ Ｓｐれちぇｒ のきあ しえめんｓ ねとぉｒｋｓ ３ はながｒ Ｓｔ。 ねゔぇ ね’えまん Ｂ ほｄ はしゃろん、 ４５２４１ いｓらえｌ えまいｌ： ぬりｔ。ｓｐれちぇｒ＠んｓん。こｍ
Authors' Addresses
著者のアドレス
Luyuan Fang (editor) Cisco Systems, Inc. 111 Wood Ave. South Iselin, NJ 08830 United States EMail: lufang@cisco.com
Luyuan Fang（編集者）Cisco Systems、Inc. 111 Wood Ave. South Iselin、NJ 08830 United States Eメール：lufang@cisco.com
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 United States EMail: nabil.bitar@verizon.com
Nabil Bitar Verizon 40 Sylvan Road Waltham、MA 02145 United Statesメール：nabil.bitar@verizon.com
Raymond Zhang Alcatel-Lucent 701 Middlefield Road Mountain View, CA 94043 United States EMail: raymond.zhang@alcatel-lucent.com
Raymond Zhang Alcatel-Lucent 701 Middlefield Road Mountain View、CA 94043アメリカ合衆国Eメール：raymond.zhang@alcatel-lucent.com
Masahiro Daikoku KDDI Corporation 3-11-11.Iidabashi, Chiyodaku, Tokyo Japan EMail: ms-daikoku@kddi.com
まさひろ だいこく Ｋっぢ こｒぽらちおん ３ー１１ー１１。いいだばし、 ちよだく、 ときょ じゃぱん えまいｌ： ｍｓーだいこく＠ｋっぢ。こｍ
Ping Pan Infinera United States EMail: ppan@infinera.com
Ping Pan Infineraアメリカ合衆国Eメール：ppan@infinera.com