[要約] RFC 7226は、MPLSネットワークにおける高度なマルチパスの要件についてのガイドラインです。その目的は、MPLSネットワークでの効率的なトラフィック分散と冗長性の向上を実現するための要件を定義することです。
Internet Engineering Task Force (IETF) C. Villamizar, Ed.
Request for Comments: 7226 OCCNC, LLC
Category: Informational D. McDysan, Ed.
ISSN: 2070-1721 Verizon
S. Ning
Tata Communications
A. Malis
Huawei
L. Yong
Huawei USA
May 2014
Requirements for Advanced Multipath in MPLS Networks
MPLSネットワークにおける高度なマルチパスの要件
Abstract
概要
This document provides a set of requirements for Advanced Multipath in MPLS networks.
このドキュメントでは、MPLSネットワークの高度なマルチパスの一連の要件について説明します。
Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques.
Advanced Multipathは、IPおよびMPLSネットワークで現在使用されているマルチパス技術を形式化したものであり、既存のマルチパス技術に対する一連の拡張機能です。
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/rfc7226.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7226で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6
3.1. Availability, Stability, and Transient Response . . . . . 6
3.2. Component Links Provided by Lower-Layer Networks . . . . 7
3.3. Component Links with Different Characteristics . . . . . 8
3.4. Considerations for Bidirectional Client LSP . . . . . . . 9
3.5. Multipath Load-Balancing Dynamics . . . . . . . . . . . . 10
4. General Requirements for Protocol Solutions . . . . . . . . . 12
5. Management Requirements . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
There is often a need to provide large aggregates of bandwidth that are best provided using parallel links between routers or carrying traffic over multiple MPLS Label Switched Paths (LSPs). In core networks, there is often no alternative since the aggregate capacities of core networks today far exceed the capacity of a single physical link or a single packet-processing element.
多くの場合、ルーター間の並列リンクを使用するか、複数のMPLSラベルスイッチドパス（LSP）を介してトラフィックを伝送することで提供される帯域幅の大きな集合体を提供する必要があります。コアネットワークでは、今日のコアネットワークの総容量が単一の物理リンクまたは単一のパケット処理要素の容量をはるかに超えるため、代替手段がないことがよくあります。
The presence of parallel links, with each link potentially comprised of multiple layers, has resulted in additional requirements. Certain services may benefit from being restricted to a subset of the component links or a specific component link, where component link characteristics, such as latency, differ. Certain services require that an LSP be treated as atomic and avoid reordering. Other services will continue to require only that reordering not occur within a flow as is current practice.
並列リンクが存在し、各リンクが複数のレイヤーで構成されている可能性があるため、追加の要件が発生しています。特定のサービスは、コンポーネントリンクのサブセットまたは特定のコンポーネントリンクに制限されることでメリットが得られる場合があります。特定のサービスでは、LSPをアトミックとして扱い、並べ替えを回避する必要があります。他のサービスは、現在の慣行のように、フロー内で並べ替えが発生しないことのみを引き続き必要とします。
Numerous forms of multipath exist today, including MPLS Link Bundling [RFC4201], Ethernet Link Aggregation [IEEE-802.1AX], and various forms of Equal Cost Multipath (ECMP) such as for OSPF ECMP, IS-IS ECMP, and BGP ECMP. Refer to the appendices in [USE-CASES] for a description of existing techniques and a set of references.
現在、MPLSリンクバンドリング[RFC4201]、イーサネットリンク集約[IEEE-802.1AX]、OSPF ECMP、IS-IS ECMP、BGP ECMPなどのさまざまな形式の等価コストマルチパス（ECMP）など、マルチパスの多くの形式が存在します。既存のテクニックの説明と一連のリファレンスについては、[USE-CASES]の付録を参照してください。
The purpose of this document is to clearly enumerate a set of requirements related to the protocols and mechanisms that provide MPLS-based Advanced Multipath. The intent is to first provide a set of functional requirements, in Section 3, that are as independent as possible of protocol specifications. A set of general protocol requirements are defined in Section 4. A set of network management requirements are defined in Section 5.
このドキュメントの目的は、MPLSベースの高度なマルチパスを提供するプロトコルとメカニズムに関連する一連の要件を明確に列挙することです。その意図は、セクション3で、プロトコル仕様から可能な限り独立した一連の機能要件を最初に提供することです。一般的なプロトコル要件のセットはセクション4で定義されています。ネットワーク管理要件のセットはセクション5で定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Any statement that requires the solution to support some new functionality through use of [RFC2119] keywords should be interpreted as follows. The implementation either MUST or SHOULD support the new functionality, depending on the use of either MUST or SHOULD in the requirements statement. The implementation SHOULD, in most or all cases, allow any new functionality to be individually enabled or disabled through configuration. A service provider or other deployment MAY enable or disable any feature in their network, subject to implementation limitations on sets of features that can be disabled.
[RFC2119]キーワードを使用していくつかの新しい機能をサポートするソリューションを必要とするステートメントは、次のように解釈する必要があります。要件ステートメントでのMUSTまたはSHOULDの使用に応じて、実装は新しい機能をサポートする必要があります。実装では、ほとんどの場合またはすべての場合で、構成を通じて新しい機能を個別に有効または無効にする必要があります。サービスプロバイダーまたは他の展開では、無効にできる一連の機能の実装制限に従って、ネットワーク内の機能を有効または無効にする場合があります。
Multipath The term "multipath" includes all techniques in which:
マルチパス「マルチパス」という用語には、以下のすべての手法が含まれます。
1. Traffic can take more than one path from one node to a destination.
1. トラフィックは、1つのノードから宛先への複数のパスを取ることができます。
2. Individual packets take one path only. Packets are not subdivided and reassembled at the receiving end.
2. 個々のパケットは1つのパスのみを使用します。パケットは分割されず、受信側で再構成されます。
3. Packets are not resequenced at the receiving end.
3. パケットは受信側で再シーケンスされません。
4. The paths may be:
4. パスは次のとおりです。
a. parallel links between two nodes,
a. 2つのノード間の並列リンク
b. specific paths across a network to a destination node, or
b. ネットワーク上の宛先ノードへの特定のパス、または
c. links or paths to an intermediate node used to reach a common destination.
c. 共通の宛先に到達するために使用される中間ノードへのリンクまたはパス。
The paths need not have equal capacity. The paths may or may not have equal cost in a routing protocol.
パスは同じ容量である必要はありません。パスは、ルーティングプロトコルで等しいコストを持つ場合と持たない場合があります。
Advanced Multipath Advanced Multipath is a formalization of multipath techniques that meets the requirements defined in this document. A key capability of Advanced Multipath is the support of non-homogeneous component links.
高度なマルチパス高度なマルチパスは、このドキュメントで定義されている要件を満たすマルチパス技術を形式化したものです。 Advanced Multipathの主要な機能は、不均一なコンポーネントリンクのサポートです。
Advanced Multipath Group (AMG) An AMG is a collection of component links where Advanced Multipath techniques are applied.
Advanced Multipath Group（AMG）AMGは、Advanced Multipathテクニックが適用されるコンポーネントリンクのコレクションです。
Composite Link The term "composite link" had been a registered trademark of Avici Systems, but it was abandoned in 2007. The term "composite link" is now defined by the ITU-T in [ITU-T.G.800]. The ITU-T definition includes multipath as defined here, plus inverse multiplexing, which is explicitly excluded from the definition of multipath.
複合リンク「複合リンク」という用語はAvici Systemsの登録商標でしたが、2007年に廃止されました。「複合リンク」という用語は、ITU-Tによって[ITU-T.G.800]で定義されています。 ITU-T定義には、ここで定義されているマルチパスと、マルチパスの定義から明示的に除外されている逆多重化が含まれています。
Inverse Multiplexing Inverse multiplexing is another method of sending traffic over multiple links. Inverse multiplexing either transmits whole packets and resequences the packets at the receiving end or subdivides packets and reassembles the packets at the receiving end. Inverse multiplexing requires that all packets be handled by a common egress packet processing element and is, therefore, not useful for very high-bandwidth applications.
逆多重化逆多重化は、複数のリンクを介してトラフィックを送信するもう1つの方法です。逆多重化は、パケット全体を送信して受信側でパケットの順序を変更するか、パケットを分割して受信側で再構成します。逆多重化では、すべてのパケットを共通の出力パケット処理要素で処理する必要があるため、非常に高帯域幅のアプリケーションには役立ちません。
Component Link The ITU-T definition of composite link in [ITU-T.G.800] and the IETF definition of link bundling in [RFC4201] both refer to an individual link in the composite link or link bundle as a component link. The term "component link" is applicable to all forms of multipath. The IEEE uses the term "member" rather than "component link" in Ethernet Link Aggregation [IEEE-802.1AX].
コンポーネントリンク[ITU-T.G.800]の複合リンクのITU-T定義と[RFC4201]のリンクバンドリングのIETF定義はどちらも、複合リンクまたはリンクバンドルの個々のリンクをコンポーネントリンクとして参照します。 「コンポーネントリンク」という用語は、すべての形式のマルチパスに適用できます。 IEEEは、イーサネットリンク集約[IEEE-802.1AX]で「コンポーネントリンク」ではなく「メンバー」という用語を使用しています。
Client Layer A client layer is the layer immediately above a server layer.
クライアント層クライアント層は、サーバー層のすぐ上の層です。
Server Layer A server layer is the layer immediately below a client layer.
サーバー層サーバー層は、クライアント層のすぐ下の層です。
Higher Layers Relative to a particular layer, a client layer and any layer above that is considered a higher layer. Upper layer is synonymous with higher layer.
上位層特定の層、クライアント層、およびそれより上の層と見なされるその上の任意の層に関連しています。上位層は上位層と同義です。
Lower Layers Relative to a particular layer, a server layer and any layer below that is considered a lower layer.
下位層特定の層、サーバー層、およびその下にあるすべての層に関連して、下位層と見なされます。
Client LSP A client LSP is an LSP that has been set up over one or more lower layers. In the context of this discussion, one type of client LSP is an LSP that has been set up over an AMG.
クライアントLSPクライアントLSPは、1つ以上の下位層に設定されたLSPです。この説明のコンテキストでは、クライアントLSPの1つのタイプは、AMGを介してセットアップされたLSPです。
Flow A sequence of packets that should be transferred in order on one component link of a multipath.
フローマルチパスの1つのコンポーネントリンクで順番に転送される一連のパケット。
Flow Identification The label stack and other information that uniquely identifies a flow. Other information in flow identification may include an IP header, pseudowire (PW) control word, Ethernet Media Access Control (MAC) address, etc. Note that a client LSP may contain one or more flows, or a client LSP may be equivalent to a flow. Flow identification is used to locally select a component link or a path through the network toward the destination.
フローの識別フローを一意に識別するラベルスタックおよびその他の情報。フロー識別のその他の情報には、IPヘッダー、疑似配線（PW）制御ワード、イーサネットメディアアクセス制御（MAC）アドレスなどが含まれます。クライアントLSPに1つ以上のフローが含まれる場合や、クライアントLSPがフロー。フロー識別は、コンポーネントリンクまたはネットワークを介して宛先に向かうパスをローカルに選択するために使用されます。
Load Balance Load split, load balance, or load distribution refers to subdividing traffic over a set of component links such that load is fairly evenly distributed over the set of component links and certain packet ordering requirements are met. Some existing techniques better achieve these objectives than others.
ロードバランスロードスプリット、ロードバランス、またはロードディストリビューションとは、コンポーネントリンクのセットにトラフィックを分割し、コンポーネントリンクのセットに負荷が均等に分散され、特定のパケット順序要件が満たされるようにすることです。一部の既存の技法は、他の技法よりもこれらの目的をよりよく達成します。
Performance Objective Numerical values for performance measures: principally availability, latency, and delay variation. Performance objectives may be related to Service Level Agreements (SLAs) as defined in [RFC2475] or may be strictly internal. Performance objectives may span links from edge to edge or from end to end. Performance objectives may span one provider or multiple providers.
パフォーマンス目標パフォーマンス測定の数値：主に可用性、遅延、遅延変動。パフォーマンス目標は、[RFC2475]で定義されているサービスレベルアグリーメント（SLA）に関連する場合と、厳密に内部的な場合があります。パフォーマンス目標は、リンクを端から端まで、または端から端まで広げることができます。パフォーマンス目標は、1つのプロバイダーまたは複数のプロバイダーに及ぶ場合があります。
A component link may be a point-to-point physical link (where a "physical link" includes one or more link layers, plus a physical layer) or a logical link that preserves ordering in the steady state. A component link may have transient out-of-order events, but such events must not exceed the network's performance objectives. For example, a component link may be comprised of any supportable combination of link layers over a physical layer or over logical sub-layers -- including those providing physical-layer emulation -- or over MPLS server-layer LSP.
コンポーネントリンクは、ポイントツーポイントの物理リンク（「物理リンク」には1つ以上のリンクレイヤーと物理レイヤーが含まれます）、または定常状態での順序を保持する論理リンクです。コンポーネントリンクには、一時的な順不同のイベントがある場合がありますが、そのようなイベントは、ネットワークのパフォーマンス目標を超えてはなりません。たとえば、コンポーネントリンクは、物理層または論理サブ層（物理層エミュレーションを提供するものを含む）またはMPLSサーバー層LSPを介したリンク層のサポート可能な組み合わせで構成できます。
The ingress and egress of a multipath may be midpoint LSRs with respect to a given client LSP. A midpoint LSR does not participate in the signaling of any clients of the client LSP. Therefore, in general, multipath endpoints cannot determine requirements of clients of a client LSP through participation in the signaling of the clients of the client LSP.
マルチパスの入力と出力は、特定のクライアントLSPに関するミッドポイントLSRである場合があります。ミッドポイントLSRは、クライアントLSPのクライアントのシグナリングには参加しません。したがって、一般に、マルチパスエンドポイントは、クライアントLSPのクライアントのシグナリングへの参加を通じて、クライアントLSPのクライアントの要件を決定できません。
This document makes no statement on whether Advanced Multipath is itself a layer or whether an instance of AMG is itself a layer. This is to avoid engaging in long and pointless discussions about what constitutes a proper layer.
このドキュメントでは、高度なマルチパス自体がレイヤーであるかどうか、またはAMGのインスタンス自体がレイヤーであるかどうかについては触れていません。これは、何が適切なレイヤーを構成するかについての長く無意味な議論に巻き込まれるのを避けるためです。
The term "Advanced Multipath" is intended to be used within the context described in this document and related documents, for example, [USE-CASES] and [FRAMEWORK]. Other Advanced Multipath techniques may arise in the future. If the capabilities defined in this document become commonplace, they would no longer be considered "advanced". Use of the term "advanced multipath" outside this document, if referring to the term as defined here, should indicate Advanced Multipath as defined by this document, citing the current document name. If using another definition of "advanced multipath", documents may optionally clarify that they are not using the term "advanced multipath" as defined by this document if clarification is deemed helpful.
「高度なマルチパス」という用語は、[USE-CASES]や[FRAMEWORK]など、このドキュメントおよび関連ドキュメントで説明されているコンテキスト内で使用されることを意図しています。他の高度なマルチパス技術が将来発生する可能性があります。このドキュメントで定義されている機能が一般的になると、それらは「高度」とは見なされなくなります。このドキュメントの外で「高度なマルチパス」という用語を使用する場合、ここで定義されている用語を指す場合、現在のドキュメント名を引用して、このドキュメントで定義されている高度なマルチパスを示す必要があります。 「高度なマルチパス」の別の定義を使用する場合、説明が役立つと思われる場合、ドキュメントはオプションで、このドキュメントで定義されている「高度なマルチパス」という用語を使用していないことを明確にする場合があります。
The functional requirements in this section are grouped in subsections, starting with the highest priority.
このセクションの機能要件は、優先順位の高いサブセクションにグループ化されています。
In addition to maintaining stability, limiting the period of unavailability in response to failures or transient events is extremely important.
安定性を維持することに加えて、障害や一時的なイベントに対応して利用できない期間を制限することは非常に重要です。
FR#1 The transient period between some service disrupting event and the convergence of the routing and/or signaling protocols MUST occur within a time frame specified by performance objective values.
FR＃1何らかのサービス中断イベントとルーティングおよび/またはシグナリングプロトコルの収束の間の一時的な期間は、パフォーマンス目標値で指定された時間枠内で発生する必要があります。
FR#2 An AMG MAY be announced in conjunction with detailed parameters about its component links, such as bandwidth and latency. The AMG SHALL behave as a single IGP adjacency.
FR＃2 AMGは、帯域幅や遅延など、コンポーネントリンクに関する詳細なパラメータと一緒に発表される場合があります。 AMGは単一のIGP隣接として動作する必要があります（SHALL）。
FR#3 The solution SHALL provide a means to summarize some routing advertisements regarding the characteristics of an AMG such that the updated protocol mechanisms maintain convergence times within the time frame needed to meet or not significantly exceed existing performance objectives for convergence on the same network or convergence on a network with a similar topology.
FR＃3ソリューションは、AMGの特性に関するルーティングアドバタイズを要約する手段を提供する必要があります。これにより、更新されたプロトコルメカニズムは、同じネットワーク上の既存のパフォーマンス目標を満たすか、または既存のパフォーマンス目標を大幅に超えないようにするために必要な時間内に収束時間を維持します。同様のトポロジを持つネットワークでの収束。
FR#4 The solution SHALL ensure that restoration operations happen within the time frame needed to meet existing performance objectives for restoration time on the same network or restoration time on a network with a similar topology.
FR＃4ソリューションは、同じネットワークでの復元時間または同様のトポロジを持つネットワークでの復元時間の既存のパフォーマンス目標を達成するために必要な時間枠内で復元操作が確実に行われるようにする必要があります。
FR#5 The solution shall provide a mechanism to select a set of paths for an LSP across a network in such a way that flows within the LSP are distributed across the set of paths, while meeting all of the other requirements stated above. The solution SHOULD work in a manner similar to existing multipath techniques, except as necessary to accommodate Advanced Multipath requirements.
FR＃5ソリューションは、LSP内のフローがパスのセット全体に分散されるように、ネットワーク全体でLSPのパスのセットを選択するメカニズムを提供すると同時に、上記の他のすべての要件を満たします。ソリューションは、高度なマルチパス要件に対応するために必要な場合を除いて、既存のマルチパス手法と同様に機能する必要があります。
FR#6 If extensions to existing protocols are specified and/or new protocols are defined, then the solution SHOULD provide a means for a network operator to migrate an existing deployment in a minimally disruptive manner.
FR＃6既存のプロトコルへの拡張が指定されているか、新しいプロトコルが定義されている場合、ソリューションは、ネットワークオペレーターが既存の展開を最小限の中断で移行する手段を提供する必要があります（SHOULD）。
FR#7 Any load-balancing solutions MUST NOT oscillate. Some change in path MAY occur. The solution MUST ensure that path stability and traffic reordering continue to meet performance objectives on the same network or on a network with a similar topology. Since oscillation may cause reordering, there MUST be means to control the frequency of changing the component link over which a flow is placed.
FR＃7負荷分散ソリューションは振動してはなりません。パスにいくつかの変更が発生する場合があります。ソリューションは、パスの安定性とトラフィックの並べ替えが、同じネットワーク上または同様のトポロジーを持つネットワーク上のパフォーマンス目標を継続して満たすことを保証する必要があります。振動は並べ替えを引き起こす可能性があるため、フローが配置されるコンポーネントリンクを変更する頻度を制御する手段がなければなりません。
FR#8 Management and diagnostic protocols MUST be able to operate over AMGs.
FR＃8管理および診断プロトコルは、AMG上で動作できる必要があります。
Existing scaling techniques used in MPLS networks apply to MPLS networks that support Advanced Multipath. Scalability and stability are covered in more detail in [FRAMEWORK].
MPLSネットワークで使用されている既存のスケーリング技法は、拡張マルチパスをサポートするMPLSネットワークに適用されます。スケーラビリティと安定性については、[フレームワーク]で詳しく説明しています。
A component link may be supported by a lower-layer network. For example, the lower layer may be a circuit-switched network or another MPLS network (e.g., MPLS Transport Profile (MPLS-TP)). The lower-layer network may change the latency (and/or other performance parameters) seen by the client layer. Currently, there is no protocol for the lower-layer network to inform the higher-layer network of a change in a performance parameter. Communication of the latency performance parameter is a very important requirement. Communication of other performance parameters (e.g., delay variation) is desirable.
コンポーネントリンクは、下位層ネットワークでサポートされている場合があります。たとえば、下位層は、回線交換ネットワークまたは別のMPLSネットワーク（たとえば、MPLSトランスポートプロファイル（MPLS-TP））とすることができます。下位層のネットワークは、クライアント層から見た待ち時間（および/または他のパフォーマンスパラメータ）を変更する可能性があります。現在、下位層のネットワークが上位層のネットワークにパフォーマンスパラメータの変更を通知するためのプロトコルはありません。レイテンシパフォーマンスパラメータの伝達は非常に重要な要件です。他の性能パラメータ（例えば、遅延変動）の通信が望ましい。
FR#9 The solution SHALL specify a protocol means to allow a server-layer network to communicate latency to the client-layer network.
FR＃9ソリューションは、サーバー層ネットワークがクライアント層ネットワークに遅延を通信できるようにするプロトコル手段を指定するものとします（SHALL）。
FR#10 The precision of latency reporting SHOULD be configurable. A reasonable default SHOULD be provided. Implementations SHOULD support precision of at least 10% of the one-way latencies for latency of 1 msec or more.
FR＃10レイテンシレポートの精度は設定可能である必要があります。妥当なデフォルトが提供されるべきです。実装は、1ミリ秒以上のレイテンシに対して、一方向レイテンシの少なくとも10％の精度をサポートする必要があります（SHOULD）。
The intent is to measure the predominant latency in uncongested service-provider networks, where geographic delay dominates and is on the order of milliseconds or more. The argument for including queuing delay is that it reflects the delay experienced by applications. The argument against including queuing delay is that if used in routing decisions, it can result in routing instability. This trade-off is discussed in detail in [FRAMEWORK].
その目的は、地理的な遅延が支配的であり、ミリ秒以上のオーダーである、輻輳していないサービスプロバイダーネットワークの主な遅延を測定することです。キューイング遅延を含めることの議論は、アプリケーションが経験する遅延を反映しているということです。キューイング遅延を含めることに対する反対論は、ルーティングの決定に使用すると、ルーティングが不安定になる可能性があるということです。このトレードオフについては、[フレームワーク]で詳しく説明しています。
As one means to provide high availability, network operators deploy a topology in the MPLS network using lower-layer networks that have a certain degree of diversity at the lower layer(s). Many techniques have been developed to balance the distribution of flows across component links that connect the same pair of nodes or ultimately lead to a common destination.
高可用性を提供する1つの手段として、ネットワークオペレーターは、下位層である程度の多様性を持つ下位層ネットワークを使用して、トポロジをMPLSネットワークに展開します。同じノードのペアを接続する、または最終的には共通の宛先につながるコンポーネントリンク間のフローの分散のバランスをとるために、多くの手法が開発されています。
FR#11 In the requirements that follow in this document, the word "indicate" is used where information may be provided by either the combination of link state IGP advertisement and MPLS LSP signaling or via management plane protocols. In later documents, providing framework and protocol definitions, both signaling and management plane mechanisms, MUST be defined.
FR＃11このドキュメントの以降の要件では、リンク状態のIGPアドバタイズメントとMPLS LSPシグナリングの組み合わせ、または管理プレーンプロトコルを介して情報が提供される場合に、「示す」という語が使用されます。後のドキュメントでは、シグナリングと管理プレーンの両方のメカニズムであるフレームワークとプロトコルの定義を提供することを定義する必要があります。
FR#12 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP will traverse a component link with the minimum-latency value. This will provide a means by which minimum latency performance objectives of flows within the client LSP can be supported.
FR＃12ソリューションは、クライアントレイヤがクライアントLSPが最小遅延値でコンポーネントリンクを通過するという要件を示す手段を提供するものとします（SHALL）。これは、クライアントLSP内のフローの最小遅延パフォーマンス目標をサポートできる手段を提供します。
FR#13 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP will traverse a component link with a maximum acceptable latency value as specified by protocol. This will provide a means by which bounded latency performance objectives of flows within the client LSP can be supported.
FR＃13ソリューションは、クライアントレイヤがクライアントLSPがプロトコルで指定された最大許容レイテンシ値でコンポーネントリンクを通過するという要件を示す手段を提供するものとします（SHALL）。これにより、クライアントLSP内のフローの制限されたレイテンシパフォーマンス目標をサポートできるようになります。
FR#14 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP will traverse a component link with a maximum acceptable delay variation value as specified by protocol.
FR＃14ソリューションは、クライアントレイヤがクライアントLSPがプロトコルで指定された最大許容遅延変動値でコンポーネントリンクを通過するという要件を示す手段を提供するものとします（SHALL）。
The above set of requirements applies to component links with different characteristics, regardless of whether those component links are provided by parallel physical links between nodes or by sets of paths across a network provided by a server-layer LSP.
上記の一連の要件は、コンポーネントリンクがノード間の並列物理リンクによって提供されるか、サーバー層LSPによって提供されるネットワーク全体のパスセットによって提供されるかに関係なく、異なる特性を持つコンポーネントリンクに適用されます。
Allowing multipath to contain component links with different characteristics can improve the overall load balance and can be accomplished while still accommodating the more strict requirements of a subset of client LSP.
マルチパスにさまざまな特性を持つコンポーネントリンクを含めることを許可すると、全体的なロードバランスが向上し、クライアントLSPのサブセットのより厳密な要件に対応しながら達成できます。
Some client LSPs MAY require a path bound to a specific set of component links. This case is most likely to occur in a bidirectional client LSP where time synchronization protocols such as the Precision Time Protocol (PTP) or the Network Time Protocol (NTP) are carried or in any other case where symmetric delay is highly desirable. There may be other uses of this capability.
一部のクライアントLSPでは、コンポーネントリンクの特定のセットにバインドされたパスが必要になる場合があります。このケースは、Precision Time Protocol（PTP）やNetwork Time Protocol（NTP）などの時間同期プロトコルが実行される双方向クライアントLSPで発生する可能性が最も高く、対称遅延が非常に望ましいその他のケースでも発生します。この機能は他にも使用される場合があります。
Other client LSPs may only require that the LSP serve the same set of nodes in both directions. This is necessary if protocols are carried that make use of the reverse direction of the LSP as a back channel in cases such Operations, Administration, and Maintenance (OAM) protocols using IPv4 Time to Live (TTL) or IPv4 Hop Limit to monitor or diagnose the underlying path. There may be other uses of this capability.
他のクライアントLSPは、LSPが双方向の同じノードのセットを提供することのみを必要とする場合があります。これは、監視または診断にIPv4存続時間（TTL）またはIPv4ホップ制限を使用する運用、管理、保守（OAM）プロトコルなどの場合に、LSPの逆方向をバックチャネルとして利用するプロトコルが実行される場合に必要です。基礎となるパス。この機能は他にも使用される場合があります。
FR#15 The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP be bound to a particular component link within an AMG. If this option is not exercised, then a client LSP that is carried over an AMG may be bound to any component link or set of component links matching all other signaled requirements, and different directions of a bidirectional client LSP can be bound to different component links.
FR＃15ソリューションは、クライアントLSPがAMG内の特定のコンポーネントリンクにバインドされるという要件をクライアントレイヤーが示す手段を提供するものとします（SHALL）。このオプションが実行されていない場合、AMGを介して伝送されるクライアントLSPは、他のすべての信号要件に一致するコンポーネントリンクまたはコンポーネントリンクのセットにバインドでき、双方向クライアントLSPの異なる方向を異なるコンポーネントリンクにバインドできます。 。
FR#16 The solution MUST support a means for the client layer to indicate a requirement that for a specific co-routed bidirectional client LSP, both directions of the co-routed bidirectional client LSP MUST be bound to the same set of nodes.
FR＃16ソリューションは、クライアントレイヤーが特定の同じルートの双方向クライアントLSPに対して、同じルートの双方向クライアントLSPの両方向が同じノードのセットにバインドされる必要があるという要件を示す手段をサポートする必要があります。
FR#17 A client LSP that is bound to a specific component link SHOULD NOT exceed the capacity of a single component link. This is inherent in the assumption that a network SHOULD NOT operate in a congested state if congestion is avoidable.
FR＃17特定のコンポーネントリンクにバインドされているクライアントLSPは、単一のコンポーネントリンクの容量を超えてはなりません。これは、輻輳が回避可能な場合、ネットワークが輻輳状態で動作してはならないという想定に固有です。
For some large bidirectional client LSPs, it may not be necessary (or possible due to the client LSP capacity) to bind the LSP to a common set of component links, but it may be necessary or desirable to constrain the path taken by the LSP to the same set of nodes in both directions. Without an entirely new and highly dynamic protocol, it is not feasible to constrain such a bidirectional client LSP from taking multiple paths and coordinating load balance on each side in order to keep both directions of flows within such an LSP on common paths.
一部の大規模な双方向クライアントLSPでは、LSPをコンポーネントリンクの共通セットにバインドする必要がない（またはクライアントのLSP容量が原因で可能である）かもしれませんが、LSPがたどるパスを双方向の同じノードセット。まったく新しい非常に動的なプロトコルがなければ、このような双方向クライアントLSPが複数のパスを取り、両側でロードバランスを調整して、共通パス上のこのようなLSP内のフローの両方向を維持することを制限することはできません。
Multipath load balancing attempts to keep traffic levels on all component links below congestion levels if possible and preferably well balanced. Load balancing is minimally disruptive (see the discussion below this section's list of requirements). The sensitivity to these minimal disruptions of traffic flows within a specific client LSP needs to be considered.
マルチパスロードバランシングは、可能であれば、すべてのコンポーネントリンクのトラフィックレベルを輻輳レベル以下に保ち、できればバランスをとろうとします。ロードバランシングは最小限の中断を伴います（このセクションの要件リストの下の説明を参照してください）。特定のクライアントLSP内のトラフィックフローのこれらの最小限の中断に対する感度を考慮する必要があります。
FR#18 The solution SHALL provide a means for the client layer to indicate a requirement that a specific client LSP MUST NOT be split across multiple component links.
FR＃18ソリューションは、特定のクライアントLSPが複数のコンポーネントリンクに分割されてはならないという要件をクライアント層が示す手段を提供するものとします（SHALL）。
FR#19 The solution SHALL provide a means local to a node that automatically distributes flows across the component links in the AMG such that performance objectives are met, as described in the prior requirements in Section 3.3.
FR＃19ソリューションは、セクション3.3の以前の要件で説明されているように、パフォーマンス目標が満たされるようにAMGのコンポーネントリンク全体にフローを自動的に分散するノードにローカルな手段を提供するものとします（SHALL）。
FR#20 The solution SHALL measure traffic flows or groups of traffic flows and dynamically select the component link on which to place this traffic in order to balance the load so that no component link in the AMG between a pair of nodes is overloaded.
FR＃20ソリューションは、トラフィックフローまたはトラフィックフローのグループを測定し、このトラフィックを配置するコンポーネントリンクを動的に選択して、ノードのペア間のAMGのコンポーネントリンクが過負荷にならないように負荷を分散します。
FR#21 When a traffic flow is moved from one component link to another in the same AMG between a set of nodes, it MUST be done so in a minimally disruptive manner.
FR＃21トラフィックフローがノードのセット間で同じAMG内の1つのコンポーネントリンクから別のコンポーネントリンクに移動されるとき、最小限の中断を伴う方法で行われる必要があります。
FR#22 Load balancing MAY be used during sustained low-traffic periods to reduce the number of active component links for the purpose of power reduction.
FR＃22負荷分散は、持続的な低トラフィック期間中に使用して、電力削減のためにアクティブなコンポーネントリンクの数を減らすことができます。
FR#23 The solution SHALL provide a means for the client layer to indicate a requirement that a specific client LSP contains traffic whose frequency of component link change due to load balancing needs to be bounded by a specific value. The solution MUST provide a means to bound the frequency of a component link change due to load balancing for subsets of traffic flow on AMGs.
FR＃23ソリューションは、特定のクライアントLSPに、ロードバランシングによるコンポーネントリンクの変更頻度が特定の値によって制限される必要があるトラフィックが含まれているという要件をクライアント層に示す手段を提供するものとします（SHALL）。ソリューションは、AMG上のトラフィックフローのサブセットのロードバランシングによるコンポーネントリンク変更の頻度を制限する手段を提供する必要があります。
FR#24 The solution SHALL provide a means to distribute traffic flows from a single client LSP across multiple component links to handle at least the case where the traffic carried in a client LSP exceeds that of any component link in the AMG.
FR＃24ソリューションは、少なくともクライアントLSPで伝送されるトラフィックがAMGのコンポーネントリンクのトラフィックを超える場合に対処するために、単一のクライアントLSPからのトラフィックフローを複数のコンポーネントリンクに分散する手段を提供する必要があります。
FR#25 The solution SHOULD support the use case where an AMG itself is a component link for a higher order AMG. For example, an AMG comprised of MPLS-TP bidirectional tunnels viewed as logical links could then be used as a component link in yet another AMG that connects MPLS routers.
FR＃25ソリューションは、AMG自体が高次AMGのコンポーネントリンクであるユースケースをサポートする必要があります（SHOULD）。たとえば、論理リンクとして表示されるMPLS-TP双方向トンネルで構成されるAMGは、MPLSルーターを接続するさらに別のAMGのコンポーネントリンクとして使用できます。
FR#26 If the total demand offered by traffic flows exceeds the capacity of the AMG, the solution SHOULD define a means to cause some client LSPs to move to an alternate set of paths that are not congested. These "preempted LSPs" may not be restored if there is no uncongested path in the network.
FR＃26トラフィックフローによって提供される総需要がAMGの容量を超える場合、ソリューションは、一部のクライアントLSPを、輻輳していない代替パスのセットに移動させる手段を定義する必要があります（SHOULD）。ネットワークに輻輳していないパスがない場合、これらの「プリエンプトされたLSP」は復元されない可能性があります。
A minimally disruptive change implies that as little disruption as is practical occurs. Such a change can be achieved with zero packet loss. A delay discontinuity may occur, which is considered to be a minimally disruptive event for most services if this type of event is sufficiently rare. A delay discontinuity is an example of a minimally disruptive behavior corresponding to current techniques.
最小限の破壊的な変更は、実際に発生する破壊が最小限であることを意味します。このような変更は、パケット損失なしで実現できます。遅延の不連続が発生する可能性があります。これは、このタイプのイベントが十分にまれである場合、ほとんどのサービスにとって最小限の中断イベントと見なされます。遅延の不連続性は、現在の技術に対応する最小限の破壊的な動作の例です。
A delay discontinuity is an isolated event that may greatly exceed the normal delay variation (jitter). A delay discontinuity has the following effect. When a flow is moved from a current link to a target link with lower latency, reordering can occur. When a flow is moved from a current link to a target link with a higher latency, a time gap can occur. Some flows (e.g., timing distribution and PW circuit emulation) are quite sensitive to these effects. A delay discontinuity can also cause a jitter buffer underrun or overrun, affecting user experience in real-time voice services (causing an audible click). These sensitivities may be specified in a performance objective.
遅延の不連続性は、通常の遅延変動（ジッター）を大幅に超える可能性がある孤立したイベントです。遅延の不連続性には次の影響があります。フローが現在のリンクから低遅延のターゲットリンクに移動されると、並べ替えが発生する可能性があります。フローが現在のリンクからレイテンシの高いターゲットリンクに移動されると、タイムギャップが発生する可能性があります。一部のフロー（タイミング分布やPW回路エミュレーションなど）は、これらの影響に非常に敏感です。遅延の不連続性により、ジッタバッファのアンダーランまたはオーバーランが発生し、リアルタイムの音声サービスのユーザーエクスペリエンスに影響を与える可能性があります（クリック音が発生します）。これらの感度は、パフォーマンス目標で指定できます。
As with any load-balancing change, a change initiated for the purpose of power reduction may be minimally disruptive. Typically, the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. When configuring a network for power reduction, the network operator should weigh the benefit of power reduction against the disadvantage of a minimal disruption.
負荷分散の変更と同様に、電力削減を目的として開始された変更は、最小限の中断を伴う場合があります。通常、中断は、遅延特性の変化と、トラフィックの並べ替えによる非常に短い期間の可能性に限定されます。電力削減のためにネットワークを構成する場合、ネットワークオペレーターは、電力削減の利点と最小限の中断の欠点を比較検討する必要があります。
This section defines requirements for protocol specifications used to meet the functional requirements specified in Section 3.
このセクションでは、セクション3で指定された機能要件を満たすために使用されるプロトコル仕様の要件を定義します。
GR#1 The solution SHOULD extend existing protocols wherever possible, developing a new protocol only where doing so adds a significant set of capabilities.
GR＃1ソリューションは、既存のプロトコルを可能な限り拡張し、重要な機能セットを追加する場合にのみ新しいプロトコルを開発する必要があります（SHOULD）。
GR#2 A solution SHOULD extend LDP capabilities to meet functional requirements. This MUST be accomplished without defining LDP Traffic Engineering (TE) methods as decided in [RFC3468].
GR＃2ソリューションは、機能要件を満たすようにLDP機能を拡張する必要があります（SHOULD）。これは、[RFC3468]で決定されているLDPトラフィックエンジニアリング（TE）メソッドを定義せずに実行する必要があります。
GR#3 Coexistence of LDP- and RSVP-TE-signaled LSPs MUST be supported on an AMG. Function requirements SHOULD, where possible, be accommodated in a manner that supports LDP-signaled LSP, RSVP-signaled LSP, and LSP setup using management plane mechanisms.
AMGでは、LDPとRSVP-TEでシグナリングされたLSPのGR＃3共存をサポートする必要があります。機能要件は、可能であれば、管理プレーンメカニズムを使用して、LDPシグナルLSP、RSVPシグナルLSP、およびLSPセットアップをサポートする方法で対応する必要があります（SHOULD）。
GR#4 When the nodes connected via an AMG are in the same routing domain, the solution MAY define extensions to the IGP.
GR＃4 AMGを介して接続されたノードが同じルーティングドメインにある場合、ソリューションはIGPへの拡張を定義できます（MAY）。
GR#5 When the nodes are connected via an AMG are in different MPLS network topologies, the solution SHALL NOT rely on extensions to the IGP.
GR＃5 AMGを介して接続されたノードが異なるMPLSネットワークトポロジにある場合、ソリューションはIGPの拡張に依存しないものとします（SHALL）。
GR#6 The solution SHOULD support AMG IGP advertisement that results in convergence time better than that of advertising the individual component links. The solution SHALL be designed so that it represents the range of capabilities of the individual component links such that functional requirements are met, and it also minimizes the frequency of advertisement updates that may cause IGP convergence to occur.
GR＃6ソリューションは、個々のコンポーネントリンクをアドバタイズするよりもコンバージェンス時間を短縮するAMG IGPアドバタイズをサポートする必要があります（SHOULD）。ソリューションは、機能要件が満たされるように個々のコンポーネントリンクの機能の範囲を表すように設計する必要があります。また、IGPコンバージェンスの発生を引き起こす可能性のあるアドバタイズメントの更新頻度を最小限に抑えます。
Examples of advertisement-update-triggering events to be considered include: client LSP establishment/release, changes in component-link characteristics (e.g., latency and up/down state), and/or bandwidth utilization.
考慮すべきアドバタイズメント更新トリガーイベントの例には、クライアントLSPの確立/解放、コンポーネントリンク特性の変化（例：レイテンシおよびアップ/ダウン状態）、および/または帯域幅の使用率が含まれます。
GR#7 When a worst-case failure scenario occurs, the number of RSVP-TE client LSPs to be resignaled will cause a period of unavailability as perceived by users. The resignaling time of the solution MUST support protocol mechanisms meeting existing provider performance objectives for the duration of unavailability without significantly relaxing those existing performance objectives for the same network or for networks with similar topology. For example, the processing load due to IGP readvertisement MUST NOT increase significantly, and the resignaling time of the solution MUST NOT increase significantly as compared with current methods.
GR＃7最悪のケースの障害シナリオが発生した場合、再シグナリングされるRSVP-TEクライアントLSPの数により、ユーザーが認識できない期間が使用不可になります。ソリューションの再シグナリング時間は、同じネットワークまたは同様のトポロジを持つネットワークの既存のパフォーマンス目標を大幅に緩和することなく、利用できない期間中、既存のプロバイダーのパフォーマンス目標を満たすプロトコルメカニズムをサポートする必要があります。たとえば、IGP readvertisementによる処理負荷は大幅に増加してはならず、ソリューションの再シグナリング時間は現在の方法と比較して大幅に増加してはなりません。
MR#1 The Management Plane MUST support polling of the status and configuration of an AMG and its individual component links and support notification of status change.
MR＃1管理プレーンは、AMGおよびその個々のコンポーネントリンクのステータスと構成のポーリングをサポートし、ステータス変更の通知をサポートする必要があります。
MR#2 The Management Plane MUST be able to activate or deactivate any component link in an AMG in order to facilitate operation maintenance tasks. The routers at each end of an AMG MUST redistribute traffic to move traffic from a deactivated link to other component links based on the traffic flow TE criteria.
MR＃2管理プレーンは、運用保守タスクを容易にするために、AMGのコンポーネントリンクをアクティブまたは非アクティブにできる必要があります。 AMGの両端にあるルーターは、トラフィックを再配布して、トラフィックフローのTE基準に基づいて、非アクティブなリンクから他のコンポーネントリンクにトラフィックを移動する必要があります。
MR#3 The Management Plane MUST be able to configure a client LSP over an AMG and be able to select a component link for the client LSP.
MR＃3管理プレーンは、AMGを介してクライアントLSPを構成でき、クライアントLSPのコンポーネントリンクを選択できる必要があります。
MR#4 The Management Plane MUST be able to trace which component link a client LSP is assigned to and monitor individual component link and AMG performance.
MR＃4管理プレーンは、クライアントLSPが割り当てられているコンポーネントリンクを追跡し、個々のコンポーネントリンクとAMGパフォーマンスを監視できる必要があります。
MR#5 The Management Plane MUST be able to verify connectivity over each individual component link within an AMG.
MR＃5管理プレーンは、AMG内の個々のコンポーネントリンクを介して接続を検証できる必要があります。
MR#6 Component link fault notification MUST be sent to the management plane.
MR＃6コンポーネントリンク障害通知を管理プレーンに送信する必要があります。
MR#7 AMG fault notification MUST be sent to the management plane and MUST be distributed via a link state message in the IGP.
MR＃7 AMG障害通知は管理プレーンに送信する必要があり、IGPのリンク状態メッセージを介して配信する必要があります。
MR#8 The Management Plane SHOULD provide the means for an operator to initiate an optimization process.
MR＃8管理プレーンは、オペレーターが最適化プロセスを開始するための手段を提供する必要があります（SHOULD）。
MR#9 An operator-initiated optimization MUST be performed in a minimally disruptive manner, as described in Section 3.5.
MR＃9セクション3.5で説明されているように、オペレーターが開始する最適化は、最小限の中断で実行する必要があります。
Frederic Jounay of France Telecom and Yuji Kamite of NTT Communications Corporation coauthored a version of this document.
France TelecomのFrederic JounayとNTT Communications Corporationの神手祐二がこのドキュメントのバージョンを共同執筆しました。
A rewrite of this document occurred after the IETF 77 meeting. Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG Chairs John Scuder and Alex Zinin, the current WG Chair Alia Atlas, and others provided valuable guidance prior to and at the IETF 77 RTGWG meeting.
この文書の書き換えは、IETF 77会議の後に行われました。ディミトリ・パパディミトリウ、ルー・バーガー、トニー・リー、元WG議長のジョン・スクーダー、アレックス・ジニン、現在のWG議長のアリア・アトラスなどが、IETF 77 RTGWG会議の前および会議で貴重なガイダンスを提供した。
Tony Li and John Drake have made numerous valuable comments on the RTGWG mailing list that are reflected in versions following the IETF 77 meeting.
Tony LiとJohn Drakeは、RTGWGメーリングリストに多数の貴重なコメントを投稿しており、IETF 77ミーティング後のバージョンに反映されています。
Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG mailing list after the IETF 82 meeting that identified a new requirement. Iftekhar Hussain made numerous valuable comments on the RTGWG mailing list that resulted in improvements to the document's clarity.
Iftekhar HussainとKireeti Kompellaは、新しい要件を特定したIETF 82会議後、RTGWGメーリングリストにコメントしました。 Iftekhar Hussainは、RTGWGメーリングリストに多数の貴重なコメントを投稿し、その結果、ドキュメントがより明確になりました。
In the interest of full disclosure of affiliation and in the interest of acknowledging sponsorship, past affiliations of authors are noted here. Much of the work done by Ning So and Andrew Malis occurred while they were at Verizon. Much of the work done by Curtis Villamizar occurred while he was at Infinera.
所属の完全な開示とスポンサーシップの承認のために、著者の過去の所属をここに示します。 Ning SoとAndrew Malisが行った作業の多くは、Verizonにいる間に行われました。 Curtis Villamizarによって行われた作業の多くは、彼がInfineraにいたときに行われました。
Tom Yu and Francis Dupont provided the SecDir and GenArt reviews, respectively. Both reviews provided useful comments. The current wording of the security section is based on suggested wording from Tom Yu. Lou Berger provided the RtgDir review, which resulted in the document being renamed and the substantial clarification of terminology and document wording, particularly in the Abstract, Introduction, and Definitions sections.
トム・ユーとフランシス・デュポンは、それぞれSecDirとGenArtのレビューを提供しました。どちらのレビューにも役立つコメントがありました。セキュリティセクションの現在の文言は、Tom Yuから提案された文言に基づいています。 Lou BergerはRtgDirのレビューを提供しました。その結果、ドキュメントの名前が変更され、特にアブストラクト、イントロダクション、および定義のセクションで用語とドキュメントの表現が大幅に明確になりました。
The security considerations for MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [RFC6941]. This document does not impact the security of MPLS, GMPLS, or MPLS-TP.
MPLS / GMPLSおよびMPLS-TPのセキュリティに関する考慮事項は、[RFC5920]および[RFC6941]で文書化されています。このドキュメントは、MPLS、GMPLS、またはMPLS-TPのセキュリティには影響しません。
The additional information that this document requires does not provide significant additional value to an attacker beyond the information already typically available from attacking a routing or signaling protocol. If the requirements of this document are met by extending an existing routing or signaling protocol, the security considerations of the protocol being extended apply. If the requirements of this document are met by specifying a new protocol, the security considerations of that new protocol should include an evaluation of what level of protection is required by the additional information specified in this document, such as data origin authentication.
このドキュメントが必要とする追加情報は、ルーティングまたはシグナリングプロトコルの攻撃からすでに通常入手可能な情報を超えて、攻撃者に重要な追加価値を提供しません。既存のルーティングまたはシグナリングプロトコルを拡張することでこのドキュメントの要件が満たされる場合、拡張されるプロトコルのセキュリティに関する考慮事項が適用されます。新しいプロトコルを指定することでこのドキュメントの要件が満たされている場合、その新しいプロトコルのセキュリティに関する考慮事項には、データ発信元認証など、このドキュメントで指定されている追加情報で必要な保護レベルの評価を含める必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[FRAMEWORK] Ning, S., McDysan, D., Osborne, E., Yong, L., and C. Villamizar, "Advanced Multipath Framework in MPLS", Work in Progress, July 2013.
[フレームワーク] Ning、S.、McDysan、D.、Osborne、E.、Yong、L。、およびC. Villamizar、「MPLSのAdvanced Multipath Framework」、Work in Progress、2013年7月。
[IEEE-802.1AX] IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", 2006, <http://standards.ieee.org/getieee802/ download/802.1AX-2008.pdf>.
[IEEE-802.1AX] IEEE Standards Association、「IEEE Std 802.1AX-2008 IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、2006、<http://standards.ieee.org/getieee802/ download / 802.1AX- 2008.pdf>。
[ITU-T.G.800] ITU-T, "Unified functional architecture of transport networks", ITU-T Recommendation G.800, February 2012, <http://www.itu.int/rec/T-REC-G/ recommendation.asp?parent=T-REC-G.800>.
[ITU-TG800] ITU-T、「統合されたトランスポートネットワークの機能アーキテクチャ」、ITU-T勧告G.800、2012年2月、<http://www.itu.int/rec/T-REC-G/勧告.asp？parent = T-REC-G.800>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「An Architecture for Differentiated Services」、RFC 2475、1998年12月。
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003.
[RFC3468] Andersson、L。およびG. Swallow、「MPLSシグナリングプロトコルに関するマルチプロトコルラベルスイッチング（MPLS）ワーキンググループの決定」、RFC 3468、2003年2月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y。、およびL. Berger、「MPLSトラフィックエンジニアリング（TE）におけるリンクバンドリング」、RFC 4201、2005年10月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. Graveman, "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.
[RFC6941] Fang、L.、Niven-Jenkins、B.、Mansfield、S。、およびR. Graveman、「MPLS Transport Profile（MPLS-TP）Security Framework」、RFC 6941、2013年4月。
[USE-CASES] Ning, S., Malis, A., McDysan, D., Yong, L., and C. Villamizar, "Advanced Multipath Use Cases and Design Considerations", Work in Progress, November 2013.
[使用例] Ning、S.、Malis、A.、McDysan、D.、Yong、L。、およびC. Villamizar、「Advanced Multipath Use Cases and Design Considerations」、Work in Progress、2013年11月。
Authors' Addresses
著者のアドレス
Curtis Villamizar (editor) OCCNC, LLC
Curtis Villamizar（編集者）OCCNC、LLC
EMail: curtis@occnc.com
Dave McDysan (editor) Verizon 22001 Loudoun County PKWY Ashburn, VA 20147 USA
Dave McDysan（編集者）Verizon 22001 Loudoun郡PKWY Ashburn、VA 20147米国
EMail: dave.mcdysan@verizon.com
So Ning Tata Communications
そ にんｇ たた こっむにかちおんｓ
EMail: ning.so@tatacommunications.com
Andrew G. Malis Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA
Andrew G. Malis Huawei Technologies 2330 Central Expressway Santa Clara、CA 95050 USA
EMail: agmalis@gmail.com
Lucy Yong Huawei USA 5340 Legacy Dr. Plano, TX 75025 USA
Lucy Yong hu Aは米国5340の遺産Dr. Plano、TX 75025米国
Phone: +1 469-277-5837
EMail: lucy.yong@huawei.com