[要約] RFC 6425は、LSP Pingの拡張であり、ポイントツーマルチポイントMPLSにおけるデータプレーンの障害を検出するための方法を提供します。このRFCの目的は、ネットワークの信頼性を向上させ、障害の早期検出と回復を可能にすることです。
Internet Engineering Task Force (IETF) S. Saxena, Ed.
Request for Comments: 6425 G. Swallow
Updates: 4379 Z. Ali
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 A. Farrel
Juniper Networks
S. Yasukawa
NTT Corporation
T. Nadeau
CA Technologies
November 2011
Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping
ポイントツーマルチポイントMPLSでのデータプレーン障害の検出-LSP Pingへの拡張
Abstract
概要
Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs.
最近の提案により、マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチ付きパス（LSP）の範囲が拡張され、ポイントツーマルチポイント（P2MP）LSPを包含しています。
The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping".
ポイントツーポイント（P2P）MPLS LSPでのデータ平面障害を検出するために使用できるシンプルで効率的なメカニズムの要件が認識されており、一般的に言及される障害検出と分離の技術の開発につながりました。lsp ping "。
The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment.
このドキュメントの範囲は、P2MP MPLS LSPの障害検出と分離です。このドキュメントは、LSP pingのメカニズムのいずれにおいても置き換えられませんが、MPLS P2MP LSPへの適用性を明確にし、LSP pingの技術とメカニズムをMPLS P2MP環境に拡張します。
This document updates RFC 4379.
このドキュメントは、RFC 4379を更新します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc6425.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6425で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Design Considerations ......................................4
1.2. Terminology ................................................4
2. Notes on Motivation .............................................5
2.1. Basic Motivations for LSP Ping .............................5
2.2. Motivations for LSP Ping for P2MP LSPs .....................6
3. Packet Format ...................................................7
3.1. Identifying the LSP Under Test .............................8
3.1.1. Identifying a P2MP MPLS TE LSP ......................8
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV .............8
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV .............9
3.1.2. Identifying a Multicast LDP LSP .....................9
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs ..........10
3.1.2.2. Applicability to
Multipoint-to-Multipoint LSPs .............11
3.2. Limiting the Scope of Responses ...........................11
3.2.1. Egress Address P2MP Responder Sub-TLVs .............12
3.2.2. Node Address P2MP Responder Sub-TLVs ...............13
3.3. Preventing Congestion of Echo Replies .....................14
3.4. Respond Only If TTL Expired Flag ..........................14
3.5. Downstream Detailed Mapping TLV ...........................15
4. Operation of LSP Ping for a P2MP LSP ...........................15
4.1. Initiating LSR Operations .................................16
4.1.1. Limiting Responses to Echo Requests ................16
4.1.2. Jittered Responses to Echo Requests ................16
4.2. Responding LSR Operations .................................17
4.2.1. Echo Reply Reporting ...............................18
4.2.1.1. Responses from Transit and Branch Nodes ...19
4.2.1.2. Responses from Egress Nodes ...............19
4.2.1.3. Responses from Bud Nodes ..................19
4.3. Special Considerations for Traceroute .....................21
4.3.1. End of Processing for Traceroutes ..................21
4.3.2. Multiple Responses from Bud and Egress Nodes .......22
4.3.3. Non-Response to Traceroute Echo Requests ...........22
4.3.4. Use of Downstream Detailed Mapping TLV in
Echo Requests ......................................23
4.3.5. Cross-Over Node Processing .........................23
5. Non-Compliant Routers ..........................................24
6. OAM and Management Considerations ..............................24
7. IANA Considerations ............................................25
7.1. New Sub-TLV Types .........................................25
7.2. New TLVs ..................................................25
7.3. New Global Flags Registry .................................26
8. Security Considerations ........................................26
9. Acknowledgements ...............................................26
10. References ....................................................27
10.1. Normative References .....................................27
10.2. Informative References ...................................27
Simple and efficient mechanisms that can be used to detect data-plane failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSP) are described in [RFC4379]. The techniques involve information carried in MPLS "echo request" and "echo reply" messages, and mechanisms for transporting them. The echo request and reply messages provide sufficient information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, and thereby localize faults. The use of reliable channels for echo reply messages as described in [RFC4379] enables more robust fault isolation. This collection of mechanisms is commonly referred to as "LSP ping".
ポイントツーポイント（P2P）マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチ付きパス（LSP）のデータ平面障害を検出するために使用できるシンプルで効率的なメカニズムは、[RFC4379]に記載されています。この手法には、MPLS「エコーリクエスト」と「エコー応答」メッセージ、およびそれらを輸送するメカニズムに含まれる情報が含まれます。エコーリクエストと応答メッセージは、データプレーンの正しい動作を確認するのに十分な情報と、コントロールプレーンに対するデータプレーンを検証するメカニズムを提供し、それにより障害を局在させます。[RFC4379]に記載されているように、エコー応答メッセージに信頼できるチャネルを使用すると、より堅牢な障害分離が可能になります。このメカニズムのコレクションは、一般に「LSP ping」と呼ばれます。
The requirements for point-to-multipoint (P2MP) MPLS traffic engineered (TE) LSPs are stated in [RFC4461]. [RFC4875] specifies a signaling solution for establishing P2MP MPLS TE LSPs.
ポイントツーマルチポイント（P2MP）MPLSトラフィックエンジニアリング（TE）LSPの要件は、[RFC4461]に記載されています。[RFC4875]は、P2MP MPLS TE LSPを確立するためのシグナル伝達ソリューションを指定します。
The requirements for P2MP extensions to the Label Distribution Protocol (LDP) are stated in [RFC6348]. [RFC6388] specifies extensions to LDP for P2MP MPLS.
ラベル分布プロトコル（LDP）へのP2MP拡張の要件は、[RFC6348]に記載されています。[RFC6388]は、P2MP MPLSのLDPへの拡張機能を指定します。
P2MP MPLS LSPs are at least as vulnerable to data-plane faults or to discrepancies between the control and data planes as their P2P counterparts. Therefore, mechanisms are needed to detect such data plane faults in P2MP MPLS LSPs as described in [RFC4687].
P2MP MPLS LSPは、少なくともデータプレーン障害や、P2Pの対応物と同じように、コントロールプレーンとデータプレーンの間の不一致に対して脆弱です。したがって、[RFC4687]に記載されているように、P2MP MPLS LSPのそのようなデータプレーン障害を検出するためにメカニズムが必要です。
This document extends the techniques described in [RFC4379] such that they may be applied to P2MP MPLS LSPs. This document stresses the reuse of existing LSP ping mechanisms used for P2P LSPs, and applies them to P2MP MPLS LSPs in order to simplify implementation and network operation.
このドキュメントは、[RFC4379]で説明されている手法を拡張して、P2MP MPLS LSPに適用できるようにします。このドキュメントは、P2P LSPに使用される既存のLSP PINGメカニズムの再利用を強調し、実装とネットワークの動作を簡素化するためにP2MP MPLS LSPに適用します。
An important consideration for designing LSP ping for P2MP MPLS LSPs is that every attempt is made to use or extend existing mechanisms rather than invent new mechanisms.
P2MP MPLS LSPのLSP Pingを設計するための重要な考慮事項は、新しいメカニズムを発明するのではなく、既存のメカニズムを使用または拡張するためにあらゆる試みがなされることです。
As for P2P LSPs, a critical requirement is that the echo request messages follow the same data path that normal MPLS packets traverse. However, as can be seen, this notion needs to be extended for P2MP MPLS LSPs, as in this case an MPLS packet is replicated so that it arrives at each egress (or leaf) of the P2MP tree.
P2P LSPSに関しては、重要な要件は、ECHO要求メッセージが通常のMPLSパケットをトラバースするのと同じデータパスに従うことです。ただし、見られるように、この概念はP2MP MPLS LSPの場合は拡張する必要があります。この場合、MPLSパケットが複製され、P2MPツリーの各出口（または葉）に到達するように。
MPLS echo requests are meant primarily to validate the data plane, and they can then be used to validate data-plane state against the control plane. They may also be used to bootstrap other Operations, Administration, and Maintenance (OAM) procedures such as [RFC5884]. As pointed out in [RFC4379], mechanisms to check the liveness, function, and consistency of the control plane are valuable, but such mechanisms are not a feature of LSP ping and are not covered in this document.
MPLSエコーリクエストは、主にデータプレーンを検証することを目的としており、その後、制御プレーンに対するデータプレーン状態を検証するために使用できます。また、[RFC5884]などの他の操作、管理、およびメンテナンス（OAM）手順をブートストラップするためにも使用できます。[RFC4379]で指摘されているように、コントロールプレーンの活性、機能、一貫性をチェックするメカニズムは価値がありますが、そのようなメカニズムはLSP pingの特徴ではなく、このドキュメントではカバーされていません。
As is described in [RFC4379], to avoid potential denial-of-service attacks, it is RECOMMENDED to regulate the LSP ping traffic passed to the control plane. A rate limiter should be applied to the incoming LSP ping traffic.
[RFC4379]で説明されているように、潜在的なサービス拒否攻撃を回避するために、コントロールプレーンに渡されたLSP pingトラフィックを調整することをお勧めします。レートリミッターは、着信LSP pingトラフィックに適用する必要があります。
The terminology used in this document for P2MP MPLS can be found in [RFC4461]. The terminology for MPLS OAM can be found in [RFC4379]. In particular, the notation <RSC> refers to the Return Subcode as defined in Section 3.1. of [RFC4379].
このドキュメントでP2MP MPLSのために使用される用語は、[RFC4461]に記載されています。MPLS OAMの用語は[RFC4379]に記載されています。特に、表記<rsc>は、セクション3.1で定義されているリターンサブコードを指します。[RFC4379]。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The motivations listed in [RFC4379] are reproduced here for completeness.
[RFC4379]にリストされている動機は、完全性のためにここで再現されています。
When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. There is a need to provide a tool that enables users to detect such traffic "black holes" or misrouting within a reasonable period of time. A mechanism to isolate faults is also required.
LSPがユーザートラフィックの配信に失敗した場合、MPLSコントロールプレーンによって障害を常に検出することはできません。ユーザーがそのようなトラフィックの「ブラックホール」を検出したり、合理的な期間内に誤ったりすることができるツールを提供する必要があります。断層を分離するメカニズムも必要です。
[RFC4379] describes a mechanism that accomplishes these goals. This mechanism is modeled after the ping/traceroute paradigm: ping (ICMP echo request [RFC792]) is used for connectivity checks, and traceroute is used for hop-by-hop fault localization as well as path tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode for testing MPLS LSPs.
[RFC4379]は、これらの目標を達成するメカニズムを説明しています。このメカニズムは、ping/tracerouteパラダイムの後にモデル化されます：ping（icmp echo request [rfc792]）は接続チェックに使用され、tracerouteはホップバイホップ障害の局在化とパストレースに使用されます。[RFC4379]は、MPLS LSPをテストするために「Pingモード」と「Traceroute」モードを指定します。
The basic idea as expressed in [RFC4379] is to test that the packets that belong to a particular Forwarding Equivalence Class (FEC) actually end their MPLS path on an LSR that is an egress for that FEC. [RFC4379] achieves this test by sending a packet (called an "MPLS echo request") along the same data path as other packets belonging to this FEC. An MPLS echo request also carries information about the FEC whose MPLS path is being verified. This echo request is forwarded just like any other packet belonging to that FEC. In "ping" mode (basic connectivity check), the packet should reach the end of the path, at which point it is sent to the control plane of the egress LSR, which then verifies that it is indeed an egress for the FEC. In "traceroute" mode (fault isolation), the packet is sent to the control plane of each transit LSR, which performs various checks that it is indeed a transit LSR for this path; this LSR also returns further information that helps to check the control plane against the data plane, i.e., that forwarding matches what the routing protocols determined as the path.
[RFC4379]で表現されている基本的なアイデアは、特定の転送等価クラス（FEC）に属するパケットが、そのFECの出口であるLSRでMPLSパスを実際に終了することをテストすることです。 [RFC4379]このFECに属する他のパケットと同じデータパスに沿って、パケット（「MPLSエコーリクエスト」と呼ばれる）を送信することにより、このテストを実現します。 MPLSエコー要求には、MPLSパスが検証されているFECに関する情報も伝えられます。このエコー要求は、そのFECに属する他のパケットと同じように転送されます。 「Ping」モード（基本的な接続性チェック）では、パケットはパスの終わりに到達する必要があります。その時点で、Egress LSRの制御面に送信されます。これは、FECの出力であることを確認します。 「Traceroute」モード（障害分離）では、パケットが各トランジットLSRの制御プレーンに送信されます。このLSRは、データプレーンに対してコントロールプレーンを確認するのに役立つさらなる情報、つまり、転送がルーティングプロトコルがパスとして決定したものと一致することを返します。
One way these tools can be used is to periodically ping a FEC to ensure connectivity. If the ping fails, one can then initiate a traceroute to determine where the fault lies. One can also
これらのツールを使用できる1つの方法は、接続性を確保するためにFECを定期的にpingすることです。pingが失敗した場合、障害がどこにあるかを判断するためにトレーサーを開始できます。できることもあります
periodically traceroute FECs to verify that forwarding matches the control plane; however, this places a greater burden on transit LSRs and should be used with caution.
FECSを定期的にトレーサーして、転送がコントロールプレーンと一致することを確認します。ただし、これにより輸送LSRに大きな負担がかかり、注意して使用する必要があります。
As stated in [RFC4687], MPLS has been extended to encompass P2MP LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and diagnose control- and data-plane defects is critical. For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects is important because such defects may affect the fundamentals of an MPLS network, but also because they may impact service-level-specification commitments for customers of their network.
[RFC4687]に記載されているように、MPLSはP2MP LSPを含むように拡張されています。P2P MPLS LSPSと同様に、コントロールおよびデータプレーンの欠陥を検出、処理、診断するための要件が重要です。P2MP MPLS LSPに基づいてサービスを展開するオペレーターの場合、そのような欠陥がMPLSネットワークの基礎に影響を与える可能性があるため、これらの欠陥を処理する方法の検出と仕様は重要ですが、それが彼らの顧客のサービスレベルの仕様コミットメントに影響を与える可能性があるため通信網。
P2MP LDP [RFC6388] uses LDP to establish multicast LSPs. These LSPs distribute data from a single source to one or more destinations across the network according to the next hops indicated by the routing protocols. Each LSP is identified by an MPLS multicast FEC.
P2MP LDP [RFC6388]はLDPを使用してマルチキャストLSPを確立します。これらのLSPは、ルーティングプロトコルで示される次のホップに従って、単一のソースからネットワーク上の1つ以上の宛先にデータを配布します。各LSPは、MPLSマルチキャストFECによって識別されます。
P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a single ingress and multiple egresses. The tunnels, built on P2MP LSPs, are explicitly routed through the network. There is no concept or applicability of a FEC in the context of a P2MP MPLS TE LSP.
P2MP MPLS TE LSP [RFC4875]は、単一の侵入と複数の出口を持つMPLSトンネルと見なされる場合があります。P2MP LSP上に構築されたトンネルは、ネットワークを通して明示的にルーティングされます。P2MP MPLS TE LSPのコンテキストでは、FECの概念や適用性はありません。
MPLS packets inserted at the ingress of a P2MP LSP are delivered equally (barring faults) to all egresses. In consequence, the basic idea of LSP ping for P2MP MPLS LSPs may be expressed as an intention to test that packets that enter (at the ingress) a particular P2MP LSP actually end their MPLS path on the LSRs that are the (intended) egresses for that LSP. The idea may be extended to check selectively that such packets reach specific egresses.
P2MP LSPの侵入に挿入されたMPLSパケットは、すべての出力に均等に（障害を除いて）供給されます。その結果、P2MP MPLS LSPのLSP Pingの基本的な考え方は、特定のP2MP LSPが実際に（意図された）出口であるLSRのMPLSパスを実際に終了するパケットをテストする意図として表現される場合があります。そのlsp。アイデアは、そのようなパケットが特定の出口に到達することを選択的にチェックするために拡張される場合があります。
The technique in this document makes this test by sending an LSP ping echo request message along the same data path as the MPLS packets. An echo request also carries the identification of the P2MP MPLS LSP (multicast LSP or P2MP TE LSP) that it is testing. The echo request is forwarded just as any other packet using that LSP, and so is replicated at branch points of the LSP and should be delivered to all egresses.
このドキュメントの手法は、MPLSパケットと同じデータパスに沿ってLSP Pingエコー要求メッセージを送信することにより、このテストを行います。ECHO要求には、テストしているP2MP MPLS LSP（マルチキャストLSPまたはP2MP TE LSP）の識別も伝えられます。エコー要求は、そのLSPを使用して他のパケットと同様に転送されるため、LSPの分岐点で複製され、すべての出口に配信される必要があります。
In "ping" mode (basic connectivity check), the echo request should reach the end of the path, at which point it is sent to the control plane of the egress LSRs, which verify that they are indeed an egress (leaf) of the P2MP LSP. An echo reply message is sent by an egress to the ingress to confirm the successful receipt (or announce the erroneous arrival) of the echo request.
「Ping」モード（基本的な接続チェック）では、エコー要求はパスの終わりに到達する必要があります。P2MP LSP。エコーの返信メッセージは、出口によって侵入に送信され、エコーリクエストの成功した領収書（または誤った到着を発表）を確認します。
In "traceroute" mode (fault isolation), the echo request is sent to the control plane at each transit LSR, and the control plane checks that it is indeed a transit LSR for this P2MP MPLS LSP. The transit LSR returns information about the outgoing paths. This information can be used by ingress LSRs to build topology or by downstream LSRs to do extra label verification.
「Traceroute」モード（障害分離）では、エコー要求が各トランジットLSRのコントロールプレーンに送信され、コントロールプレーンはこのP2MP MPLS LSPのトランジットLSRであることを確認します。Transit LSRは、発信パスに関する情報を返します。この情報は、Ingress LSRSによってトポロジーを構築するために、または下流のLSRによって使用して、追加のラベル検証を行うことができます。
P2MP MPLS LSPs may have many egresses, and it is not necessarily the intention of the initiator of the ping or traceroute operation to collect information about the connectivity or path to all egresses. Indeed, in the event of pinging all egresses of a large P2MP MPLS LSP, it might be expected that a large number of echo replies would arrive at the ingress independently but at approximately the same time. Under some circumstances this might cause congestion at or around the ingress LSR. The procedures described in this document provide two mechanisms to control echo replies.
P2MP MPLS LSPには多くの出力がある可能性があり、必ずしもすべての出力への接続またはパスに関する情報を収集するPingまたはTraceroute操作のイニシエーターの意図ではありません。実際、大きなP2MP MPLS LSPのすべての出口をpingする場合、多数のエコー応答が独立して侵入に到着すると予想されるかもしれませんが、ほぼ同時に。状況によっては、これは侵入LSRまたはその周辺で輻輳を引き起こす可能性があります。このドキュメントで説明されている手順は、エコー応答を制御するための2つのメカニズムを提供します。
The first procedure allows the responders to randomly delay (or jitter) their replies so that the chances of swamping the ingress are reduced. The second procedure allows the initiator to limit the scope of an LSP ping echo request (ping or traceroute mode) to one specific intended egress.
最初の手順により、レスポンダーは回答をランダムに遅らせる（またはジッター）することで、侵入を圧倒する可能性が低下するようにします。2番目の手順により、イニシエーターは、LSP Ping Echo要求（PingまたはTracerouteモード）の範囲を特定の意図された出力に制限できます。
LSP ping can be used to periodically ping a P2MP MPLS LSP to ensure connectivity to any or all of the egresses. If the ping fails, the operator or an automated process can then initiate a traceroute to determine where the fault is located within the network. A traceroute may also be used periodically to verify that data-plane forwarding matches the control-plane state; however, this places an increased burden on transit LSRs and should be used infrequently and with caution.
LSP Pingを使用して、P2MP MPLS LSPを定期的にpingして、任意のいずれかまたはすべてへの接続を確保することができます。pingが失敗した場合、オペレーターまたは自動化されたプロセスは、トレーサーを開始して、ネットワーク内の障害がどこにあるかを判断できます。Tracerouteは、データプレーン転送がコントロールプレーン状態と一致することを確認するために定期的に使用することもできます。ただし、これにより、輸送LSRの負担が増加し、慎重に使用する必要があります。
The basic structure of the LSP ping packet remains the same as described in [RFC4379]. Some new TLVs and sub-TLVs are required to support the new functionality. They are described in the following sections.
LSP pingパケットの基本構造は、[RFC4379]で説明されているものと同じままです。新しい機能をサポートするには、いくつかの新しいTLVとサブTLVが必要です。これらについては、次のセクションで説明します。
[RFC4379] defines how an MPLS TE LSP under test may be identified in an echo request. A Target FEC Stack TLV is used to carry either an RSVP IPv4 Session or an RSVP IPv6 Session sub-TLV.
[RFC4379]は、テスト中のMPLS TE LSPがエコー要求でどのように識別されるかを定義します。ターゲットFECスタックTLVは、RSVP IPv4セッションまたはRSVP IPv6セッションSub-TLVのいずれかを運ぶために使用されます。
In order to identify the P2MP MPLS TE LSP under test, the echo request message MUST carry a Target FEC Stack TLV, and this MUST carry exactly one of two new sub-TLVs: either an RSVP P2MP IPv4 Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs carry fields from the RSVP-TE P2MP SESSION and SENDER_TEMPLATE objects [RFC4875] and so provide sufficient information to uniquely identify the LSP.
テスト中のP2MP MPLS TE LSPを識別するために、エコー要求メッセージはターゲットFECスタックTLVを運ぶ必要があります。IPv6セッションSUB-TLV。これらのサブTLVは、RSVP-TE P2MPセッションとsender_templateオブジェクト[RFC4875]からフィールドを搭載しているため、LSPを一意に識別するのに十分な情報を提供します。
The new sub-TLVs are assigned Sub-Type identifiers as follows, and are described in the following sections.
新しいサブTLVには、次のようにサブタイプの識別子が割り当てられ、次のセクションで説明されています。
Sub-Type # Length Value Field
---------- ------ -----------
17 20 RSVP P2MP IPv4 Session
18 56 RSVP P2MP IPv6 Session
The format of the RSVP P2MP IPv4 Session sub-TLV value field is specified in the following figure. The value fields are taken from the definitions of the P2MP IPv4 LSP SESSION Object and the P2MP IPv4 SENDER_TEMPLATE Object in Sections 19.1.1 and 19.2.1 of [RFC4875]. Note that the Sub-Group ID of the SENDER_TEMPLATE is not required.
RSVP P2MP IPv4セッションサブTLV値フィールドの形式は、次の図に指定されています。値フィールドは、[RFC4875]のセクション19.1.1および19.2.1のP2MP IPv4 LSPセッションオブジェクトとP2MP IPv4 Sender_Templateオブジェクトの定義から取得されます。sender_templateのサブグループIDは必要ないことに注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the RSVP P2MP IPv6 Session sub-TLV value field is specified in the following figure. The value fields are taken from the definitions of the P2MP IPv6 LSP SESSION Object and the P2MP IPv6 SENDER_TEMPLATE Object in Sections 19.1.2 and 19.2.2 of [RFC4875]. Note that the Sub-Group ID of the SENDER_TEMPLATE is not required.
RSVP P2MP IPv6セッションサブTLV値フィールドの形式は、次の図に指定されています。値フィールドは、[RFC4875]のセクション19.1.2および19.2.2のP2MP IPv6 LSPセッションオブジェクトとP2MP IPv6 Sender_Templateオブジェクトの定義から取得されます。sender_templateのサブグループIDは必要ないことに注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Extended Tunnel ID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Tunnel Sender Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[RFC4379] defines how a P2P LDP LSP under test may be identified in an echo request. A Target FEC Stack TLV is used to carry one or more sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the LSP.
[RFC4379]は、テスト中のP2P LDP LSPがエコー要求でどのように識別されるかを定義します。ターゲットFECスタックTLVは、LSPを識別する1つ以上のサブTLV（たとえば、IPv4プレフィックスFEC Sub-TLV）を運ぶために使用されます。
In order to identify a multicast LDP LSP under test, the echo request message MUST carry a Target FEC Stack TLV, and this MUST carry exactly one of two new sub-TLVs: either a Multicast P2MP LDP FEC Stack sub-TLV or a Multicast MP2MP LDP FEC Stack sub-TLV. These sub-TLVs use fields from the multicast LDP messages [RFC6388] and so provide sufficient information to uniquely identify the LSP.
テスト中のマルチキャストLDP LSPを識別するために、エコーリクエストメッセージはターゲットFECスタックTLVを運ぶ必要があります。これは、マルチキャストP2MP LDP LDP FECスタックSub-TLVまたはマルチキャストMP2MPの2つの新しいサブTLVのいずれかを正確に運ぶ必要があります。LDP FECスタックSub-TLV。これらのサブTLVは、マルチキャストLDPメッセージ[RFC6388]からフィールドを使用しているため、LSPを一意に識別するのに十分な情報を提供します。
The new sub-TLVs are assigned sub-type identifiers as follows and are described in the following section.
新しいサブTLVには、次のようにサブタイプの識別子が割り当てられ、次のセクションで説明されています。
Sub-Type # Length Value Field
---------- ------ -----------
19 Variable Multicast P2MP LDP FEC Stack
20 Variable Multicast MP2MP LDP FEC Stack
Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as specified in the following figure.
マルチキャストP2MPとMP2MP LDP FECスタックの両方は、次の図に指定されているように同じ形式を持っています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address Length| Root LSR Addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Root LSR Address (Cont.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family
住所ファミリー
Two-octet quantity containing a value from ADDRESS FAMILY NUMBERS in [IANA-AF] that encodes the address family for the Root LSR Address.
ルートLSRアドレスのアドレスファミリをエンコードする[IANA-AF]のアドレスファミリ番号からの値を含む2オクテット数量。
Address Length
アドレス長
Length of the Root LSR Address in octets.
オクテットのルートLSRアドレスの長さ。
Root LSR Address
ルートLSRアドレス
Address of the LSR at the root of the P2MP LSP encoded according to the Address Family field.
住所ファミリーフィールドに従ってエンコードされたP2MP LSPのルートにあるLSRのアドレス。
Opaque Length
不透明な長さ
The length of the opaque value, in octets. Depending on the length of the Root LSR Address, this field may not be aligned to a word boundary.
オクテット内の不透明な値の長さ。ルートLSRアドレスの長さに応じて、このフィールドは単語境界に整合していない場合があります。
Opaque Value
不透明な値
An opaque value element that uniquely identifies the P2MP LSP in the context of the Root LSR.
ルートLSRのコンテキストでP2MP LSPを一意に識別する不透明な値要素。
If the Address Family is IPv4, the Address Length MUST be 4. If the Address Family is IPv6, the Address Length MUST be 16. No other Address Family values are defined at present.
アドレスファミリがIPv4の場合、アドレスの長さは4でなければなりません。アドレスファミリがIPv6の場合、アドレスの長さは16でなければなりません。
The mechanisms defined in this document can be extended to include Multipoint-to-Multipoint (MP2MP) Multicast LSPs. In an MP2MP LSP tree, any leaf node can be treated like a head node of a P2MP tree. In other words, for MPLS OAM purposes, the MP2MP tree can be treated like a collection of P2MP trees, with each MP2MP leaf node acting like a P2MP head-end node. When a leaf node is acting like a P2MP head-end node, the remaining leaf nodes act like egress or bud nodes.
このドキュメントで定義されているメカニズムは、Multipoint-to-MultiPoint（MP2MP）マルチキャストLSPを含むように拡張できます。MP2MP LSPツリーでは、葉のノードはP2MPツリーのヘッドノードのように扱うことができます。言い換えれば、MPLS OAMの目的で、MP2MPツリーはP2MPツリーのコレクションのように扱うことができ、各MP2MPリーフノードはP2MPヘッドエンドノードのように機能します。リーフノードがP2MPヘッドエンドノードのように動作している場合、残りのリーフノードは出口または芽ノードのように機能します。
A new TLV is defined for inclusion in the echo request message.
新しいTLVは、Echo要求メッセージに含めるために定義されています。
The P2MP Responder Identifier TLV is assigned the TLV type value 11 and is encoded as follows.
P2MPレスポンダー識別子TLVには、TLVタイプ値11が割り当てられ、次のようにエンコードされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 11 (P2MP Responder ID)| Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-TLVs:
サブTLV：
Zero, one, or more sub-TLVs as defined below.
以下に定義するように、ゼロ、1つ、またはそれ以上のサブTLV。
If no sub-TLVs are present, the TLV MUST be processed as if it were absent. If more than one sub-TLV is present, the first TLV MUST be processed as described in this document, and subsequent sub-TLVs SHOULD be ignored. Interpretation of additional sub-TLVs may be defined in future documents.
サブTLVが存在しない場合、TLVは存在しないかのように処理する必要があります。複数のサブTLVが存在する場合、このドキュメントで説明されているように最初のTLVを処理する必要があり、その後のサブTLVは無視する必要があります。追加のサブTLVの解釈は、将来のドキュメントで定義される場合があります。
The P2MP Responder Identifier TLV only has meaning on an echo request message. If present on an echo reply message, it MUST be ignored.
P2MPレスポンダー識別子TLVは、エコー要求メッセージにのみ意味があります。エコー返信メッセージに存在する場合は、無視する必要があります。
Four sub-TLVs are defined for inclusion in the P2MP Responder Identifier TLV carried on the echo request message. These are:
4つのサブTLVが、ECHO要求メッセージに掲載されたP2MPレスポンダー識別子TLVに含めるために定義されています。これらは：
Sub-Type # Length Value Field
---------- ------ -----------
1 4 IPv4 Egress Address P2MP Responder
2 16 IPv6 Egress Address P2MP Responder
3 4 IPv4 Node Address P2MP Responder
4 16 IPv6 Node Address P2MP Responder
The content of these sub-TLVs are defined in the following sections. Also defined is the intended behavior of the responding node upon receiving any of these sub-TLVs.
これらのサブTLVの内容は、次のセクションで定義されています。また、これらのサブTLVのいずれかを受信すると、応答ノードの意図された動作も定義されています。
The encoding of the IPv4 Egress Address P2MP Responder sub-TLV is as follows:
IPv4 EgressアドレスP2MP Responder Sub-TLVのエンコードは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 1 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding of the IPv6 Egress Address P2MP Responder sub-TLV is as follows:
IPv6 EgressアドレスP2MP Responder Sub-TLVのエンコードは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 128-bit IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A node that receives an echo request with this sub-TLV present MUST respond if the node lies on the path to the address in the sub-TLV and MUST NOT respond if it does not lie on the path to the address in the sub-TLV. For this to be possible, the address in the sub-TLV must be known to the nodes that lie upstream in the LSP. This can be the case if RSVP-TE is used to signal the P2MP LSP, in which case this address will be the address used in the Destination Address
このSub-TLVプレゼントでエコー要求を受信するノードは、ノードがサブTLVのアドレスへのパスにある場合、応答する必要があり、サブTLVのアドレスへのパスにある場合は応答しないでください。これを可能にするためには、Sub-TLVのアドレスは、LSPの上流にあるノードに対して知られている必要があります。これは、RSVP-TEがP2MP LSPを信号するために使用される場合に当てはまります。この場合、このアドレスは宛先アドレスで使用されるアドレスになります
field of the S2L_SUB_LSP object, when corresponding egress or bud node is signaled. Thus, the IPv4 or IPv6 Egress Address P2MP Responder sub-TLV MAY be used in an echo request carrying RSVP P2MP Session sub-TLV.
対応する出力またはバッドノードが信号が表示される場合、S2L_SUB_LSPオブジェクトのフィールド。したがって、IPv4またはIPv6 EgressアドレスP2MP Responder Sub-TLVは、RSVP P2MPセッションSub-TLVを運ぶエコー要求で使用できます。
However, in Multicast LDP, there is no way for upstream LSRs to know the identity of the downstream leaf nodes. Hence, these TLVs cannot be used to perform traceroute to a single node when Multicast LDP FEC is used, and the IPv4 or IPv6 Egress Address P2MP Responder sub-TLV SHOULD NOT be used with an echo request carrying a Multicast LDP FEC Stack sub-TLV. If a node receives these TLVs in an echo request carrying Multicast LDP, then it will not respond since it is unaware of whether it lies on the path to the address in the sub-TLV.
ただし、マルチキャストLDPでは、上流のLSRが下流の葉のノードのアイデンティティを知る方法はありません。したがって、これらのTLVは、マルチキャストLDP FECを使用している場合、単一ノードへのTracerouteを実行するために使用できず、IPv4またはIPv6 EgressアドレスP2MPレスポンダーSub-TLVを使用して、マルチキャストLDP FEC STACK SUB-TLVを運ぶECOリクエストで使用しないでください。ノードがマルチキャストLDPを運ぶエコー要求でこれらのTLVを受信した場合、サブTLVのアドレスへのパスにあるかどうかを知らないため、応答しません。
The encoding of the IPv4 Node Address P2MP Responder sub-TLV is as follows:
IPv4ノードアドレスP2MPレスポンダーSub-TLVのエンコードは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 3 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding of the IPv6 Node Address P2MP Responder sub-TLV is as follows:
IPv6ノードアドレスP2MPレスポンダーSub-TLVのエンコードは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 4 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 128-bit IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 or IPv6 Node Address P2MP Responder sub-TLVs MAY be used in an echo request carrying either RSVP P2MP Session or Multicast LDP FEC Stack sub-TLVs.
IPv4またはIPv6ノードアドレスP2MPレスポンダーサブTLVは、RSVP P2MPセッションまたはマルチキャストLDP FECスタックSub-TLVのいずれかを運ぶエコー要求で使用できます。
A node that receives an echo request with one of these sub-TLVs present MUST respond if the address in the sub-TLV matches any address that is local to the node and MUST NOT respond if the address
これらのサブTLVのいずれかを使用してエコー要求を受信するノードは、サブTLVのアドレスがノードにローカルであるアドレスと一致し、アドレスが応答しないでください。
in the sub-TLV does not match any address that is local to the node. The address in the sub-TLV may be of any physical interface or may be the router ID of the node itself.
Sub-TLVでは、ノードにローカルのアドレスと一致しません。Sub-TLVのアドレスは、物理的なインターフェイスのものである場合がある場合や、ノード自体のルーターIDである場合があります。
The address in this sub-TLV SHOULD be of any transit, branch, bud, or egress node for that P2MP LSP. The address of a node that is not on the P2MP LSP MAY be used as a check for that no reply is received.
このSub-TLVのアドレスは、そのP2MP LSPの任意のトランジット、ブランチ、バッド、または出力ノードのものでなければなりません。P2MP LSPにないノードのアドレスは、返信がないため、チェックとして使用できます。
A new TLV is defined for inclusion in the Echo request message.
新しいTLVは、Echo要求メッセージに含めるために定義されています。
The Echo Jitter TLV is assigned the TLV type value 12 and is encoded as follows.
Echo Jitter TLVにはTLVタイプ値12が割り当てられ、次のようにエンコードされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 (Jitter TLV) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jitter Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jitter Time:
ジッター時間：
This field specifies the upper bound of the jitter period that should be applied by a responding node to determine how long to wait before sending an echo reply. A responding node MUST wait a random amount of time between zero milliseconds and the value specified in this field.
このフィールドは、応答ノードによって適用されるジッター期間の上限を指定して、エコー応答を送信する前に待機する時間を決定します。応答するノードは、ゼロミリ秒とこのフィールドで指定された値の間でランダムな時間を待つ必要があります。
Jitter time is specified in milliseconds.
ジッター時間はミリ秒単位で指定されています。
The Echo Jitter TLV only has meaning on an echo request message. If present on an echo reply message, it MUST be ignored.
エコージッターTLVには、エコーリクエストメッセージにのみ意味があります。エコー返信メッセージに存在する場合は、無視する必要があります。
A new flag is being introduced in the Global Flags field defined in [RFC4379]. The new format of the Global Flags field is:
[RFC4379]で定義されているグローバルフラグフィールドに新しいフラグが導入されています。グローバルフラグフィールドの新しい形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |T|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The V flag is described in [RFC4379].
Vフラグは[RFC4379]で説明されています。
The T (Respond Only If TTL Expired) flag MUST be set only in the echo request packet by the sender. This flag MUST NOT be set in the echo reply packet. If this flag is set in an echo reply packet, then it MUST be ignored.
T（TTLの有効期限が切れた場合にのみ応答）フラグは、送信者がEcho要求パケットでのみ設定する必要があります。このフラグは、Echo Replyパケットに設定してはなりません。このフラグがエコー応答パケットに設定されている場合、無視する必要があります。
If the T flag is set to 0, then the receiving node MUST process the incoming echo request.
Tフラグが0に設定されている場合、受信ノードは着信エコー要求を処理する必要があります。
If the T flag is set to 1 and the TTL of the incoming MPLS label is equal to 1, then the receiving node MUST process the incoming echo request.
Tフラグが1に設定され、着信MPLSラベルのTTLが1に等しい場合、受信ノードは着信エコー要求を処理する必要があります。
If the T flag is set to 1 and the TTL of the incoming MPLS label is more than 1, then the receiving node MUST drop the incoming echo request and MUST NOT send any echo reply to the sender.
Tフラグが1に設定され、着信MPLSラベルのTTLが1以上の場合、受信ノードは着信エコー要求をドロップする必要があり、送信者にエコー返信を送信してはなりません。
If the T flag is set to 1 and there are no incoming MPLS labels in the echo request packet, then a bud node with PHP configured MAY choose to not respond to this echo request. All other nodes MUST ignore this bit and respond as per regular processing.
Tフラグが1に設定されており、Echo Request Packetに受信MPLSラベルがない場合、設定されたPHPを備えたBUDノードがこのエコーリクエストに応答しないことを選択できます。他のすべてのノードは、このビットを無視し、通常の処理に従って応答する必要があります。
The Downstream Detailed Mapping TLV is described in [RFC6424]. A transit, branch or bud node can use the Downstream Detailed Mapping TLV to return multiple Return Codes for different downstream paths. This functionality can not be achieved via the Downstream Mapping TLV. As per Section 3.4 of [RFC6424], the Downstream Mapping TLV as described in [RFC4379] is being deprecated.
下流の詳細なマッピングTLVは[RFC6424]で説明されています。トランジット、ブランチ、またはバッドノードは、ダウンストリーム詳細マッピングTLVを使用して、異なるダウンストリームパスの複数のリターンコードを返すことができます。この機能は、ダウンストリームマッピングTLVを介して実現できません。[RFC6424]のセクション3.4によると、[RFC4379]で説明されている下流マッピングTLVは非推奨です。
Therefore, for P2MP, a node MUST support the Downstream Detailed Mapping TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP traceroute functionality and MUST NOT be included in an Echo Request message. When responding to an RSVP IPv4/IPv6 P2MP Session FEC type or a Multicast P2MP/MP2MP LDP FEC type, a node MUST ignore any Downstream Mapping TLV it receives in the echo request and MUST continue processing as if the Downstream Mapping TLV is not present.
したがって、P2MPの場合、ノードは下流の詳細マッピングTLVをサポートする必要があります。ダウンストリームマッピングTLV [RFC4379]は、P2MP Traceroute機能には適しておらず、Echo要求メッセージに含めてはなりません。RSVP IPv4/IPv6 P2MPセッションFECタイプまたはマルチキャストP2MP/MP2MP LDP FECタイプに応答する場合、ノードはECHOリクエストで受信する下流マッピングTLVを無視する必要があり、下流マッピングTLVが現在存在しないかのように処理を続ける必要があります。
The details of the Return Codes to be used in the Downstream Detailed Mapping TLV are provided in Section 4.
ダウンストリーム詳細マッピングTLVで使用されるリターンコードの詳細は、セクション4に記載されています。
This section describes how LSP ping is applied to P2MP MPLS LSPs. As mentioned previously, an important design consideration has been to extend the existing LSP ping mechanism in [RFC4379] rather than invent new mechanisms.
このセクションでは、LSP PingがP2MP MPLS LSPに適用される方法について説明します。前述のように、重要な設計上の考慮事項は、新しいメカニズムを発明するのではなく、[RFC4379]の既存のLSP Pingメカニズムを拡張することでした。
As specified in [RFC4379], MPLS LSPs can be tested via a "ping" mode or a "traceroute" mode. The ping mode is also known as "connectivity verification" and traceroute mode is also known as "fault isolation". Further details can be obtained from [RFC4379].
[RFC4379]で指定されているように、MPLS LSPは「Ping」モードまたは「Traceroute」モードでテストできます。Pingモードは「接続検証」とも呼ばれ、Tracerouteモードは「障害分離」とも呼ばれます。詳細については、[RFC4379]から入手できます。
This section specifies processing of echo requests for both ping and traceroute mode at various nodes (ingress, transit, etc.) of the P2MP LSP.
このセクションでは、P2MP LSPのさまざまなノード（イングレス、トランジットなど）でのPingおよびTracerouteモードの両方のEcho要求の処理を指定します。
The LSR initiating the echo request will follow the procedures in [RFC4379]. The echo request will contain a Target FEC Stack TLV. To identify the P2MP LSP under test, this TLV will contain one of the new sub-TLVs defined in Section 3.1. Additionally, there may be other optional TLVs present.
ECHO要求を開始するLSRは、[RFC4379]の手順に従います。エコー要求には、ターゲットFECスタックTLVが含まれます。テスト中のP2MP LSPを識別するために、このTLVにはセクション3.1で定義された新しいサブTLVの1つが含まれます。さらに、他のオプションのTLVが存在する場合があります。
As described in Section 2.2, it may be desirable to restrict the operation of P2MP ping or traceroute to a single egress. Since echo requests are forwarded through the data plane without interception by the control plane, there is no facility to limit the propagation of echo requests, and they will automatically be forwarded to all reachable egresses.
セクション2.2で説明されているように、P2MP PingまたはTracerouteの動作を単一の出口に制限することが望ましい場合があります。エコー要求は、制御プレーンによる傍受なしにデータプレーンを介して転送されるため、エコーリクエストの伝播を制限する施設はありません。これらは自動的にすべての到達可能な出口に転送されます。
However, a single egress may be identified by the inclusion of a P2MP Responder Identifier TLV. The details of this TLV and its sub-TLVs are in Section 3.2. There are two main types of sub-TLVs in the P2MP Responder Identifier TLV: Node Address sub-TLV and Egress Address sub-TLV.
ただし、P2MPレスポンダー識別子TLVを含めることにより、単一の出口を識別できます。このTLVとそのサブTLVの詳細は、セクション3.2にあります。P2MPレスポンダー識別子TLVには2つの主要なタイプのサブTLVがあります：ノードアドレスSub-TLVとEugressアドレスSub-TLV。
These sub-TLVs limit the replies either to the specified LSR only or to any LSR on the path to the specified LSR. The former capability is generally useful for ping mode, while the latter is more suited to traceroute mode. An initiating LSR may indicate that it wishes all egresses to respond to an echo request by omitting the P2MP Responder Identifier TLV.
これらのサブTLVは、指定されたLSRのみまたは指定されたLSRへのパス上のLSRへの応答を制限します。以前の機能は一般にPingモードに役立ちますが、後者はTracerouteモードにより適しています。LSRを開始すると、P2MPレスポンダー識別子TLVを省略して、すべての出力がエコー要求に応答することを望んでいることを示している可能性があります。
The initiating LSR MAY request that the responding LSRs introduce a random delay (or jitter) before sending the reply. The randomness of the delay allows the replies from multiple egresses to be spread over a time period. Thus, this technique is particularly relevant when the entire P2MP LSP is being pinged or traced since it helps prevent the initiating (or nearby) LSRs from being swamped by replies, or from discarding replies due to rate limits that have been applied.
開始LSRは、応答するLSRが返信を送信する前にランダムな遅延（またはジッター）を導入するよう要求する場合があります。遅延のランダム性により、複数の出力からの応答が期間にわたって広がることができます。したがって、この手法は、P2MP LSP全体が回答（または近くの）が応答によって圧倒されるのを防ぐのに役立つため、または適用された速度制限による返信を廃棄するのに役立つため、特に関連します。
It is desirable for the initiating LSR to be able to control the bounds of the jitter. If the tree size is small, only a small amount of jitter is required, but if the tree is large, greater jitter is needed.
LSRがジッターの境界を制御できるようにすることが望ましいです。ツリーのサイズが小さい場合、少量のジッターだけが必要ですが、ツリーが大きい場合は、より大きなジッターが必要です。
The initiating LSR can supply the desired value of the jitter in the Echo Jitter TLV as defined in Section 3.3. If this TLV is present, the responding LSR MUST delay sending a reply for a random amount of time between zero milliseconds and the value indicated in the TLV. If the TLV is absent, the responding egress SHOULD NOT introduce any additional delay in responding to the echo request, but MAY delay according to local policy.
開始LSRは、セクション3.3で定義されているように、エコージッターTLVにジッターの望ましい値を提供できます。このTLVが存在する場合、応答するLSRは、ゼロミリ秒とTLVに示されている値の間でランダムな時間の返信の送信を遅らせる必要があります。TLVが存在しない場合、応答する出力は、エコー要求への応答に追加の遅延を導入する必要はありませんが、ローカルポリシーに従って遅延する可能性があります。
LSP ping MUST NOT be used to attempt to measure the round-trip time for data delivery. This is because the P2MP LSPs are unidirectional, and the echo reply is often sent back through the control plane. The timestamp fields in the echo request and echo reply packets MAY be used to deduce some information about delivery times, for example the variance in delivery times.
LSP Pingを使用して、データ配信のために往復時間を測定しようとしないでください。これは、P2MP LSPが単方向であり、エコー応答がコントロールプレーンを通して返信されることが多いためです。エコーリクエストとエコー応答パケットのタイムスタンプフィールドは、配信時間、たとえば配信時間の分散に関する情報を推定するために使用できます。
The use of echo jittering does not change the processes for gaining information, but note that the responding node MUST set the value in the Timestamp Received fields before applying any delay.
エコージッタリングの使用は、情報を取得するためのプロセスを変更するものではありませんが、応答するノードは、遅延を適用する前に、受信したフィールドに値を設定する必要があることに注意してください。
Echo reply jittering SHOULD be used for P2MP LSPs, although it MAY be omitted for simple P2MP LSPs or when the Node Address P2MP Responder sub-TLVs are used. If the Echo Jitter TLV is present in an echo request for any other type of LSPs, the responding egress MAY apply the jitter behavior as described here.
Echo Reply JitteringはP2MP LSPに使用する必要がありますが、単純なP2MP LSPでは省略される場合があります。エコージッターTLVが他のタイプのLSPのエコー要求に存在する場合、応答する出力は、ここで説明するジッター動作を適用する場合があります。
Usually the echo request packet will reach the egress and bud nodes. In case of TTL Expiry, i.e., traceroute mode, the echo request packet may stop at branch or transit nodes. In both scenarios, the echo request will be passed on to the control plane for reply processing.
通常、エコーリクエストパケットは出口ノードとバッドノードに到達します。TTLの有効期限、つまりTracerouteモードの場合、Echo Requestパケットはブランチまたはトランジットノードで停止する場合があります。両方のシナリオで、エコーリクエストは、返信処理のためにコントロールプレーンに渡されます。
The operations at the receiving node are an extension to the existing processing as specified in [RFC4379]. As described in that document, a responding LSR SHOULD rate-limit the receipt of echo request messages. After rate-limiting, the responding LSR must verify the general sanity of the packet. If the packet is malformed or certain TLVs are not understood, the [RFC4379] procedures must be followed for echo reply. Similarly, the Reply Mode field determines if the reply is required or not (and the mechanism to send it back).
受信ノードでの操作は、[RFC4379]で指定されている既存の処理の拡張です。そのドキュメントで説明されているように、応答するLSRはエコー要求メッセージの受信をレートに制限する必要があります。レート制限後、応答するLSRはパケットの一般的な正気を検証する必要があります。パケットが奇形であるか、特定のTLVが理解されていない場合、エコー応答のために[RFC4379]手順に従う必要があります。同様に、返信モードフィールドは、応答が必要かどうかを判断します（およびそれを送り返すメカニズム）。
For P2MP LSP ping and traceroute, i.e., if the echo request is carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding LSR MUST determine whether it is part of the P2MP LSP in question by checking with the control plane.
P2MP LSP PingおよびTracerouteの場合、つまり、エコーリクエストがRSVP P2MP FECまたはマルチキャストLDP FECを担当している場合、対応するLSRは、コントロールプレーンでチェックすることにより、問題のP2MP LSPの一部であるかどうかを判断する必要があります。
- If the node is not part of the P2MP LSP, it MUST respond according to [RFC4379] processing rules.
- ノードがP2MP LSPの一部でない場合、[RFC4379]処理ルールに従って応答する必要があります。
- If the node is part of the P2MP LSP, the node must check whether or not the echo request is directed to it.
- ノードがP2MP LSPの一部である場合、ノードはエコー要求がそれに向けられているかどうかを確認する必要があります。
- If a P2MP Responder Identifier TLV is present, then the node must follow the procedures defined in Section 3.2 to determine whether or not it should respond to the request. The presence of a P2MP Responder Identifier TLV or a Downstream Detailed Mapping TLV might affect the Return Code. This is discussed in more detail later.
- P2MPレスポンダー識別子TLVが存在する場合、ノードはセクション3.2で定義された手順に従って、リクエストに応答するかどうかを判断する必要があります。P2MPレスポンダー識別子TLVまたは下流の詳細なマッピングTLVの存在は、リターンコードに影響を与える可能性があります。これについては、後で詳しく説明します。
- If the P2MP Responder Identifier TLV is not present (or, in the error case, is present, but does not contain any sub-TLVs), then the node MUST respond according to [RFC4379] processing rules.
- P2MPレスポンダー識別子TLVが存在しない場合（または、エラーの場合は存在しますが、サブTLVが含まれていません）、ノードは[RFC4379]処理ルールに従って応答する必要があります。
Echo reply messages carry Return Codes and Subcodes to indicate the result of the LSP ping (when the ping mode is being used) as described in [RFC4379].
エコー応答メッセージは、[RFC4379]で説明されているように、LSP ping（Pingモードが使用されている場合）の結果を示すために、戻りコードとサブコードを伝達します。
When the responding node reports that it is an egress, it is clear that the echo reply applies only to that reporting node. Similarly, when a node reports that it does not form part of the LSP described by the FEC, then it is clear that the echo reply applies only to that reporting node. However, an echo reply message that reports an error from a transit node may apply to multiple egress nodes (i.e., leaves) downstream of the reporting node. In the case of the ping mode of operation, it is not possible to correlate the reporting node to the affected egresses unless the topology of the P2MP tree is already known, and it may be necessary to use the traceroute mode of operation to further diagnose the LSP.
応答するノードが出口であると報告すると、エコーの応答がそのレポートノードにのみ適用されることは明らかです。同様に、ノードがFECで記述されたLSPの一部を形成しないと報告すると、エコー応答がそのレポートノードにのみ適用されることは明らかです。ただし、トランジットノードからのエラーを報告するエコー応答メッセージは、レポートノードの下流の複数の出力ノード（つまり、葉）に適用される場合があります。ping動作モードの場合、P2MPツリーのトポロジーが既にわかっていない限り、報告ノードを影響を受ける出力に相関させることはできません。LSP。
Note that a transit node may discover an error, but it may also determine that while it does lie on the path of the LSP under test, it does not lie on the path to the specific egress being tested. In this case, the node SHOULD NOT generate an echo reply unless there is a specific error condition that needs to be communicated.
トランジットノードはエラーを発見する可能性がありますが、テスト中のLSPの経路にあるが、テスト対象の特定の出口へのパスにはないことも判断する可能性があることに注意してください。この場合、通信する必要がある特定のエラー条件がない限り、ノードはエコー応答を生成してはなりません。
The following sections describe the expected values of Return Codes for various nodes in a P2MP LSP. It is assumed that the sanity and other checks have been performed and an echo reply is being sent back. As mentioned in Section 4.2, the Return Code might change based on the presence of a Responder Identifier TLV or Downstream Detailed Mapping TLV.
次のセクションでは、P2MP LSPのさまざまなノードのリターンコードの期待値について説明します。正気やその他のチェックが実行されており、エコーの返信が返されていると想定されています。セクション4.2で述べたように、返品コードは、レスポンダー識別子TLVまたは下流の詳細マッピングTLVの存在に基づいて変更される可能性があります。
The presence of a Responder Identifier TLV does not influence the choice of the Return Code. For a success response, the Return Code MAY be set to value 8 ('Label switched at stack-depth <RSC>'). The notation <RSC> refers to the Return Subcode as defined in Section 3.1. of [RFC4379]. For error conditions, use appropriate values defined in [RFC4379].
レスポンダー識別子TLVの存在は、返品コードの選択に影響しません。成功応答の場合、リターンコードを値8に設定できます（ 'ラベルがStack-Depth <RSC>'で切り替えられました）。表記<rsc>は、セクション3.1で定義されているリターンサブコードを指します。[RFC4379]。エラー条件の場合は、[RFC4379]で定義されている適切な値を使用します。
The presence of a Downstream Detailed Mapping TLV will influence the choice of Return Code. As per [RFC6424], the Return Code in the echo reply header MAY be set to 'See DDM TLV for Return Code and Return Subcode' as defined in [RFC6424]. The Return Code for each Downstream Detailed Mapping TLV will depend on the downstream path as described in [RFC6424].
下流の詳細なマッピングTLVの存在は、リターンコードの選択に影響します。[RFC6424]によると、[RFC6424]で定義されているように、Echo Reply Headerの返品コードは、「RETURN CODEのDDM TLVを表示し、サブコードを返す」に設定できます。[RFC6424]に記載されているように、下流の詳細マッピングTLVのリターンコードは、下流のパスに依存します。
There will be a Downstream Detailed Mapping TLV for each downstream path being reported in the echo reply. Hence, for transit nodes, there will be only one such TLV, and for branch nodes, there will be more than one. If there is an Egress Address Responder sub-TLV, then the branch node will include only one Downstream Detailed Mapping TLV corresponding to the downstream path required to reach the address specified in the Egress Address sub-TLV.
エコー応答で報告されている各下流パスの詳細なマッピングTLVがあります。したがって、トランジットノードの場合、そのようなTLVは1つだけで、ブランチノードには複数のものがあります。EgressアドレスResponder Sub-TLVがある場合、Branch Nodeには、EgressアドレスSub-TLVで指定されたアドレスに到達するために必要な下流パスに対応する1つの下流の詳細マッピングTLVのみが含まれます。
The presence of a Responder Identifier TLV does not influence the choice of the Return Code. For a success response, the Return Code MAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>'). For error conditions, use appropriate values defined in [RFC4379].
レスポンダー識別子TLVの存在は、返品コードの選択に影響しません。成功応答の場合、リターンコードを値3に設定できます（ 'Replyのルーターは、Stack-Depth <RSC>'のFECの出口です）。エラー条件の場合は、[RFC4379]で定義されている適切な値を使用します。
The presence of the Downstream Detailed Mapping TLV does not influence the choice of Return Code. Egress nodes do not put in any Downstream Detailed Mapping TLV in the echo reply [RFC6424].
ダウンストリーム詳細マッピングTLVの存在は、返品コードの選択に影響しません。出力ノードは、エコー応答[RFC6424]に下流の詳細なマッピングTLVを入れません。
The case of bud nodes is more complex than other types of nodes. The node might behave as either an egress node or a transit node, or a combination of an egress and branch node. This behavior is
バッドノードの場合は、他のタイプのノードよりも複雑です。ノードは、出口ノードまたはトランジットノード、または出口ノードと分岐ノードの組み合わせのいずれかとして動作する場合があります。この動作はです
determined by the presence of any Responder Identifier TLV and the type of sub-TLV in it. Similarly, the Downstream Detailed Mapping TLV can influence the Return Code values.
レスポンダー識別子TLVの存在とその中のサブTLVのタイプによって決定されます。同様に、下流の詳細なマッピングTLVは、返品コード値に影響を与える可能性があります。
To determine the behavior of the bud node, use the following rules. The intent of these rules is to figure out if the echo request is meant for all nodes, or just this node, or for another node reachable through this node or for a different section of the tree. In the first case, the node will behave like a combination of egress and branch node; in the second case, the node will behave like pure egress node; in the third case, the node will behave like a transit node; and in the last case, no reply will be sent back.
芽ノードの動作を決定するには、次のルールを使用します。これらのルールの意図は、エコー要求がすべてのノード、またはこのノードのみ、またはこのノードを介して到達可能な別のノードに対して、またはツリーの別のセクションに対して対象であるかどうかを把握することです。最初のケースでは、ノードは出口と分岐ノードの組み合わせのように動作します。2番目のケースでは、ノードは純粋な出口ノードのように動作します。3番目のケースでは、ノードはトランジットノードのように動作します。そして最後のケースでは、返信は返送されません。
Node behavior rules:
ノードの動作ルール：
- If the Responder Identifier TLV is not present, then the node will behave as a combination of egress and branch node.
- Responder Identifier TLVが存在しない場合、ノードは出力と分岐ノードの組み合わせとして動作します。
- If the Responder Identifier TLV containing a Node Address sub-TLV is present, and:
- ノードアドレスSub-TLVを含むレスポンダー識別子TLVが存在する場合、
- If the address specified in the sub-TLV matches to an address in the node, then the node will behave like a combination of egress and branch node.
- Sub-TLVで指定されたアドレスがノードのアドレスに一致する場合、ノードは出口ノードと分岐ノードの組み合わせのように動作します。
- If the address specified in the sub-TLV does not match any address in the node, then no reply will be sent.
- Sub-TLVで指定されたアドレスがノードのアドレスと一致しない場合、返信は送信されません。
- If the Responder Identifier TLV containing an Egress Address sub-TLV is present, and:
- 出力アドレスサブTLVを含むレスポンダー識別子TLVが存在する場合、
- If the address specified in the sub-TLV matches to an address in the node, then the node will behave like an egress node only.
- Sub-TLVで指定されたアドレスがノードのアドレスに一致する場合、ノードは出口ノードのみのように動作します。
- If the node lies on the path to the address specified in the sub-TLV, then the node will behave like a transit node.
- ノードがサブTLVで指定されたアドレスへのパスにある場合、ノードはトランジットノードのように動作します。
- If the node does not lie on the path to the address specified in the sub-TLV, then no reply will be sent.
- ノードがSub-TLVで指定されたアドレスへのパスにある場合、返信は送信されません。
Once the node behavior has been determined, the possible values for Return Codes are as follows:
ノードの動作が決定されると、リターンコードの可能な値は次のとおりです。
- If the node is behaving as an egress node only, then for a success response, the Return Code MAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>'). For error conditions, use appropriate values defined
- ノードが出口ノードのみとして動作している場合、成功応答のために、戻りコードを値3に設定できます（ 'Replyのルーターは、Stack-Depth <RSC>'のFECの出口です）。エラー条件の場合は、定義された適切な値を使用します
in [RFC4379]. The echo reply MUST NOT contain any Downstream Detailed Mapping TLV, even if one is present in the echo request.
[RFC4379]。エコー応答には、エコーリクエストに存在する場合でも、下流の詳細なマッピングTLVが含まれてはなりません。
- If the node is behaving as a transit node, and:
- ノードがトランジットノードとして動作している場合、
- If a Downstream Detailed Mapping TLV is not present, then for a success response, the Return Code MAY be set to value 8 ('Label switched at stack-depth <RSC>'). For error conditions, use appropriate values defined in [RFC4379].
- 下流の詳細なマッピングTLVが存在しない場合、成功応答のために、戻りコードを値8に設定できます（ 'ラベルがStack-Depth <RSC>'で切り替えられます）。エラー条件の場合は、[RFC4379]で定義されている適切な値を使用します。
- If a Downstream Detailed Mapping TLV is present, then the Return Code MAY be set to 'See DDM TLV for Return Code and Return Subcode' as defined in [RFC6424]. The Return Code for the Downstream Detailed Mapping TLV will depend on the downstream path as described in [RFC6424]. There will be only one Downstream Detailed Mapping corresponding to the downstream path to the address specified in the Egress Address sub-TLV.
- 下流の詳細なマッピングTLVが存在する場合、[RFC6424]で定義されているように、戻りコードを「返信コードにDDM TLVを表示し、サブコードを返す」ように設定することができます。[RFC6424]に記載されているように、下流の詳細マッピングTLVのリターンコードはダウンストリームパスに依存します。出力アドレスSub-TLVで指定されたアドレスへの下流パスに対応する下流の詳細マッピングは1つだけです。
- If the node is behaving as a combination of egress and branch node, and:
- ノードが出口と分岐ノードの組み合わせとして動作している場合、
- If a Downstream Detailed Mapping TLV is not present, then for a success response, the Return Code MAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>'). For error conditions, use appropriate values defined in [RFC4379].
- 下流の詳細なマッピングTLVが存在しない場合、成功応答の場合、返品コードを値3に設定できます（ 'Replyのルーターは、Stack-Depth <RSC>'のFECの出力です）。エラー条件の場合は、[RFC4379]で定義されている適切な値を使用します。
- If a Downstream Detailed Mapping TLV is present, then for a success response, the Return Code MAY be set to value 3 ('Replying router is an egress for the FEC at stack-depth <RSC>'). For error conditions, use appropriate values defined in [RFC4379]. The Return Code for the each Downstream Detailed Mapping TLV will depend on the downstream path as described in [RFC6424]. There will be a Downstream Detailed Mapping for each downstream path from the node.
- 下流の詳細なマッピングTLVが存在する場合、成功応答のために、戻りコードを値3に設定できます（ 'Replyのルーターは、Stack-Depth <RSC>'のFECの出口です）。エラー条件の場合は、[RFC4379]で定義されている適切な値を使用します。[RFC6424]に記載されているように、各下流の詳細マッピングTLVの返品コードは、下流パスに依存します。ノードから下流パスごとに下流の詳細マッピングがあります。
As specified in [RFC4379], the traceroute mode operates by sending a series of echo requests with sequentially increasing TTL values. For regular P2P targets, this processing stops when a valid reply is received from the intended egress or when some errored return code is received.
[RFC4379]で指定されているように、Tracerouteモードは、TTL値が順次増加する一連のエコー要求を送信することにより動作します。通常のP2Pターゲットの場合、この処理は、意図した出力から有効な返信が受信されたとき、またはエラーされた返品コードを受信したときに停止します。
For P2MP targets, there may not be an easy way to figure out the end of the traceroute processing, as there are multiple egress nodes. Receiving a valid reply from an egress will not signal the end of processing.
P2MPターゲットの場合、複数の出力ノードがあるため、Traceroute処理の終了を把握する簡単な方法はない場合があります。出口から有効な返信を受信しても、処理の終了を示すものではありません。
For P2MP TE LSP, the initiating LSR has a priori knowledge about the number of egress nodes and their addresses. Hence, it is possible to continue processing until a valid reply has been received from each end point, provided that the replies can be matched correctly to the egress nodes.
P2MP TE LSPの場合、開始LSRには、出力ノードの数とそのアドレスに関する先験的な知識があります。したがって、返信が出口ノードに正しく一致する場合、各エンドポイントから有効な返信が受信されるまで処理を継続することができます。
However, for Multicast LDP LSP, the initiating LSR might not always know about all of the egress nodes. Hence, there might not be a definitive way to estimate the end of processing for traceroute.
ただし、マルチキャストLDP LSPの場合、開始LSRはすべての出力ノードについて常に知っているとは限りません。したがって、Tracerouteの処理の終了を推定する決定的な方法はないかもしれません。
Therefore, it is RECOMMENDED that traceroute operations provide for a configurable upper limit on TTL values. Hence, the user can choose the depth to which the tree will be probed.
したがって、Traceroute操作は、TTL値に設定可能な上限を提供することをお勧めします。したがって、ユーザーはツリーがプローブされる深さを選択できます。
The P2MP traceroute may continue even after it has received a valid reply from a bud or egress node, as there may be more nodes at deeper levels. Hence, for subsequent TTL values, a bud or egress node that has previously replied would continue to get new echo requests. Since each echo request is handled independently from previous requests, these bud and egress nodes will keep on responding to the traceroute echo requests. This can cause an extra processing burden for the initiating LSR and these bud or egress LSRs.
P2MP Tracerouteは、より深いレベルでより多くのノードがある可能性があるため、芽または出力ノードから有効な返信を受け取った後も続く場合があります。したがって、その後のTTL値の場合、以前に返信した芽または出力ノードは、新しいエコー要求を引き続き取得し続けます。各エコー要求は以前のリクエストとは独立して処理されるため、これらの芽と出口ノードは、Traceroute Echoリクエストに応答し続けます。これにより、LSRとこれらの芽または出力LSRの開始に追加の処理負担が発生する可能性があります。
To prevent a bud or egress node from sending multiple replies in the same traceroute operation, a new "Respond Only If TTL Expired" flag is being introduced. This flag is described in Section 3.4.
芽または出力ノードが同じTraceroute操作で複数の応答を送信するのを防ぐために、新しい「TTLの有効期限が切れた場合にのみ応答」フラグが導入されています。このフラグは、セクション3.4で説明されています。
It is RECOMMENDED that this flag be used for P2MP traceroute mode only. By using this flag, extraneous replies from bud and egress nodes can be reduced. If PHP is being used in the P2MP tree, then bud and egress nodes will not get any labels with the echo request packet. Hence, this mechanism will not be effective for PHP scenarios.
このフラグは、P2MP Tracerouteモードのみに使用することをお勧めします。このフラグを使用することにより、芽と出口ノードからの外部応答を減らすことができます。P2MPツリーでPHPが使用されている場合、BUDとEugressノードはEcho Requestパケットを使用してラベルを取得しません。したがって、このメカニズムはPHPシナリオに効果的ではありません。
There are multiple reasons for which an ingress node may not receive a reply to its echo request. For example, the transit node has failed or the transit node does not support LSP ping.
Ingressノードがエコーリクエストへの返信を受け取らない場合は複数の理由があります。たとえば、トランジットノードが故障しているか、トランジットノードがLSP pingをサポートしていません。
When no reply to an echo request is received by the ingress, then (as per [RFC4379]) the subsequent echo request with a larger TTL SHOULD be sent in order to trace further toward the egress, although the ingress MAY halt the procedure at this point. The time that an ingress waits before sending the subsequent echo request is an implementation choice.
エコーリクエストへの返信がイングレスによって受信されない場合、（[RFC4379]に従って）退出に向かってさらにトレースするために、より大きなTTLを使用した後続のエコー要求を送信する必要がありますが、イングレスはこれで手順を停止する可能性があります。点。後続のエコー要求を送信する前に侵入が待機する時間は、実装の選択です。
As described in Section 4.6 of [RFC4379], an initiating LSR, during traceroute, SHOULD copy the Downstream Mapping(s) into its next echo request(s). However, for P2MP LSPs, the initiating LSR will receive multiple sets of Downstream Detailed Mapping TLVs from different nodes. It is not practical to copy all of them into the next echo request. Hence, this behavior is being modified for P2MP LSPs. If the echo request is destined for more than one node, then the Downstream IP Address field of the Downstream Detailed Mapping TLV MUST be set to the ALLROUTERS multicast address, and the Address Type field MUST be set to either IPv4 Unnumbered or IPv6 Unnumbered depending on the Target FEC Stack TLV.
[RFC4379]のセクション4.6で説明されているように、Traceroute中の開始LSRは、ダウンストリームマッピングを次のエコー要求にコピーする必要があります。ただし、P2MP LSPの場合、開始LSRは異なるノードから複数のダウンストリーム詳細マッピングTLVを受け取ります。それらすべてを次のエコーリクエストにコピーすることは実用的ではありません。したがって、この動作はP2MP LSPに対して変更されています。エコー要求が複数のノードを使用している場合、下流の詳細マッピングTLVのダウンストリームIPアドレスフィールドをAllRoutersマルチキャストアドレスに設定する必要があり、アドレスタイプフィールドは、IPv4のいずれかに設定する必要があります。ターゲットFECスタックTLV。
If an Egress Address Responder sub-TLV is being used, then the traceroute is limited to only one egress. Therefore this traceroute is effectively behaving like a P2P traceroute. In this scenario, as per Section 4.2, the echo replies from intermediate nodes will contain only one Downstream Detailed Mapping TLV corresponding to the downstream path required to reach the address specified in the Egress Address sub-TLV. For this case, the echo request packet MAY reuse a received Downstream Detailed Mapping TLV. This will allow interface validation to be performed as per [RFC4379].
出力アドレスResponder Sub-TLVが使用されている場合、Tracerouteは1つの出力のみに制限されます。したがって、このTracerouteは、P2P Tracerouteのように効果的に動作しています。このシナリオでは、セクション4.2によると、中間ノードからのエコー応答には、EgressアドレスSub-TLVで指定されたアドレスに到達するために必要な下流パスに対応する1つの下流の詳細なマッピングTLVのみが含まれます。この場合、Echo Request Packetは、受信したダウンストリーム詳細マッピングTLVを再利用する場合があります。これにより、[RFC4379]に従ってインターフェイス検証を実行できます。
A cross-over node will require slightly different processing for traceroute mode. The following definition of cross-over is taken from [RFC4875].
クロスオーバーノードでは、Tracerouteモードにはわずかに異なる処理が必要です。次のクロスオーバーの定義は[RFC4875]から取得されます。
The term "cross-over" refers to the case of an ingress or transit node that creates a branch of a P2MP LSP, a cross-over branch, that intersects the P2MP LSP at another node farther down the tree. It is unlike re-merge in that, at the intersecting node, the cross-over branch has a different outgoing interface as well as a different incoming interface.
「クロスオーバー」という用語は、ツリーのさらに下の別のノードでP2MP LSPと交差するP2MP LSPのブランチを作成する侵入またはトランジットノードの場合を指します。それは、交差するノードでは、クロスオーバーブランチに異なる発信インターフェイスと異なる着信インターフェイスがあるという点とは異なります。
During traceroute, a cross-over node will receive the echo requests via each of its input interfaces. Therefore, the Downstream Detailed Mapping TLV in the echo reply MUST carry information only about the outgoing interface corresponding to the input interface.
Traceroute中、クロスオーバーノードは、各入力インターフェイスを介してエコーリクエストを受信します。したがって、エコー応答のダウンストリーム詳細マッピングTLVは、入力インターフェイスに対応する発信インターフェイスに関する情報のみを伝える必要があります。
If this restriction is applied, the cross-over node will not duplicate the outgoing interface information in each of the echo request it receives via the different input interfaces. This will reflect the actual packet replication in the data plane.
この制限が適用されている場合、クロスオーバーノードは、異なる入力インターフェイスを介して受信する各エコー要求の発信インターフェイス情報を複製しません。これは、データプレーンの実際のパケットレプリケーションを反映します。
If a node for a P2MP LSP does not support MPLS LSP ping, then no reply will be sent, causing an incorrect result on the initiating LSR. There is no protection for this situation, and operators may wish to ensure that all nodes for P2MP LSPs are all equally capable of supporting this function.
P2MP LSPのノードがMPLS LSP pingをサポートしていない場合、返信は送信されず、開始LSRに誤った結果が発生します。この状況には保護がありません。オペレーターは、P2MP LSPのすべてのノードがすべてこの機能をサポートできることを確認したい場合があります。
If the non-compliant node is an egress, then the traceroute mode can be used to verify the LSP nearly all the way to the egress, leaving the final hop to be verified manually.
非準拠ノードが出口である場合、Tracerouteモードを使用してLSPを出口までほぼ完全に検証し、最終ホップを手動で検証することができます。
If the non-compliant node is a branch or transit node, then it should not impact ping mode. However the node will not respond during traceroute mode.
非準拠ノードがブランチまたはトランジットノードである場合、Pingモードに影響を与えないはずです。ただし、ノードはTracerouteモードでは応答しません。
The procedures in this document provide OAM functions for P2MP MPLS LSPs and may be used to enable bootstrapping of other OAM procedures.
このドキュメントの手順は、P2MP MPLS LSPのOAM関数を提供し、他のOAM手順のブートストラップを有効にするために使用できます。
In order to be fully operational, several considerations apply.
完全に動作するためには、いくつかの考慮事項が適用されます。
- Scaling concerns dictate that only cautious use of LSP ping should be made. In particular, sending an LSP ping to all egresses of a P2MP MPLS LSP could result in congestion at or near the ingress when the replies arrive.
- スケーリングの懸念は、LSP pingの慎重な使用のみを行う必要があると指示します。特に、P2MP MPLS LSPのすべての出口にLSP pingを送信すると、応答が到着したときに入り口またはその近くに輻輳が発生する可能性があります。
Further, incautious use of timers to generate LSP ping echo requests either in ping mode or especially in traceroute may lead to significant degradation of network performance.
さらに、Pingモードまたは特にトレーサーでのLSP Pingエコー要求を生成するためのタイマーの矛盾した使用は、ネットワークパフォーマンスの大幅な分解につながる可能性があります。
- Management interfaces should allow an operator full control over the operation of LSP ping. In particular, such interfaces should provide the ability to limit the scope of an LSP ping echo request for a P2MP MPLS LSP to a single egress.
- 管理インターフェイスでは、オペレーターがLSP pingの動作を完全に制御できるようにする必要があります。特に、このようなインターフェイスは、P2MP MPLS LSPのLSP Pingエコー要求の範囲を単一の出口に制限する機能を提供する必要があります。
Such interfaces should also provide the ability to disable all active LSP ping operations, to provide a quick escape if the network becomes congested.
このようなインターフェイスは、ネットワークが混雑した場合に迅速な脱出を提供するために、すべてのアクティブなLSP Ping操作を無効にする機能も提供する必要があります。
- A MIB module is required for the control and management of LSP ping operations, and to enable the reported information to be inspected.
- LSP Ping操作の制御と管理、および報告された情報を検査できるようにするには、MIBモジュールが必要です。
There is no reason to believe this should not be a simple extension of the LSP ping MIB module used for P2P LSPs.
これがP2P LSPに使用されるLSP Ping MIBモジュールの単純な拡張であるべきではないと信じる理由はありません。
Four new sub-TLV types are defined for inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV type 1).
LSP Ping [RFC4379]ターゲットFECスタックTLV（TLVタイプ1）に4つの新しいサブTLVタイプが定義されています。
IANA has assigned sub-type values to the following sub-TLVs under TLV type 1 (Target FEC Stack) from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry.
IANAは、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチパス（LSP）PINGパラメーター」から「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチパラメーター」から、TLVタイプ1（ターゲットFECスタック）の下で、次のサブTLVにサブタイプの値を割り当てました。「サブレジストリ。
17 RSVP P2MP IPv4 Session (Section 3.1.1) 18 RSVP P2MP IPv6 Session (Section 3.1.1) 19 Multicast P2MP LDP FEC Stack (Section 3.1.2) 20 Multicast MP2MP LDP FEC Stack (Section 3.1.2)
17 RSVP P2MP IPv4セッション（セクション3.1.1）18 RSVP P2MP IPv6セッション（セクション3.1.1）19マルチキャストP2MP LDP FECスタック（セクション3.1.2）20マルチキャストMP2MP LDP FECスタック（セクション3.1.2）
Two new LSP ping TLV types are defined for inclusion in LSP ping messages.
LSP Pingメッセージに含めるために、2つの新しいLSP Ping TLVタイプが定義されています。
IANA has assigned a new value from the "Multi-Protocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry as follows using a Standards Action value.
IANAは、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）ラベルスイッチパス（LSP）PINGパラメーター」から新しい値を割り当てました。レジストリ、「TLV、およびサブTLV」サブレジストリは、標準のアクション値を使用して次のように登録します。
11 P2MP Responder Identifier TLV (see Section 3.2) is a mandatory TLV.
11 P2MPレスポンダー識別子TLV（セクション3.2を参照）は必須のTLVです。
Four sub-TLVs are defined. - Sub-Type 1: IPv4 Egress Address P2MP Responder - Sub-Type 2: IPv6 Egress Address P2MP Responder - Sub-Type 3: IPv4 Node Address P2MP Responder - Sub-Type 4: IPv6 Node Address P2MP Responder
4つのサブTLVが定義されています。 - サブタイプ1：IPv4出力アドレスP2MPレスポンダー - サブタイプ2：IPv6出力アドレスP2MPレスポンダー - サブタイプ3：IPv4ノードアドレスP2MPレスポンダー - サブタイプ4：IPv6ノードアドレスP2MPレスポンダーダーダー
12 Echo Jitter TLV (see Section 3.3) is a mandatory TLV.
12エコージッターTLV（セクション3.3を参照）は必須のTLVです。
IANA has created a new sub-registry of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. The sub-registry is called the "Global Flags" registry.
IANAは、「マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチ付きパス（LSP）Pingパラメーター」レジストリの新しいサブレジストリを作成しました。サブレジストリは「グローバルフラグ」レジストリと呼ばれます。
This registry tracks the assignment of 16 flags in the Global Flags field of the MPLS LSP ping echo request message. The flags are numbered from 0 (most significant bit, transmitted first) to 15.
このレジストリは、MPLS LSP Ping Echo要求メッセージのグローバルフラグフィールドに16のフラグの割り当てを追跡します。フラグには、0（最も重要なビット、最初に送信）から15に番号が付けられます。
New entries are assigned by Standards Action.
新しいエントリは、標準アクションによって割り当てられます。
Initial entries in the registry are as follows:
レジストリの初期エントリは次のとおりです。
Bit number | Name | Reference
------------+----------------------------+--------------
15 | V Flag | [RFC4379]
14 | T Flag | [RFC6425]
13-0 | Unassigned |
This document does not introduce security concerns over and above those described in [RFC4379]. Note that because of the scalability implications of many egresses to P2MP MPLS LSPs, there is a stronger concern about regulating the LSP ping traffic passed to the control plane by the use of a rate limiter applied to the LSP ping well-known UDP port. This rate limiting might lead to false indications of LSP failure.
このドキュメントでは、[RFC4379]に記載されているもの以上のセキュリティ上の懸念は導入されていません。P2MP MPLS LSPに対する多くの出力のスケーラビリティへの影響のため、LSP Pingのよく知られているUDPポートに適用されるレートリミッターを使用することにより、コントロールプレーンに渡されたLSP pingトラフィックを調節することについて、より強い懸念があることに注意してください。このレートの制限は、LSP障害の誤った兆候につながる可能性があります。
The authors would like to acknowledge the authors of [RFC4379] for their work, which is substantially re-used in this document. Also, thanks to the members of the MBONED working group for their review of this material, to Daniel King and Mustapha Aissaoui for their reviews, and to Yakov Rekhter for useful discussions.
著者は、この文書で実質的に再利用されている作業のために、[RFC4379]の著者を認めたいと考えています。また、この資料のレビューをしてくれたMbonedワーキンググループのメンバー、ダニエルキングとムスタファアイッサウイのレビュー、および有用な議論のためにヤコフレクターに感謝します。
The authors would like to thank Bill Fenner, Vanson Lim, Danny Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar, Sam Aldrin, and IJsbrand Wijnands for their comments and suggestions.
著者は、ビル・フェナー、ヴァンソン・リム、ダニー・プレーリー、レスシャド・ラーマン、ベン・ニーヴェン・ジェンキンス、ハンヌ・グレドラー、ニティン・バハドゥール、ティツヤ・ムラカミ、マイケル・フア、マイケル・ワイルド、ディパ・タッカル、サム・アルドリン、イジスブランド・ウィジナンドのコメントに感謝したいと思います。と提案。
[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月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing LSP-Ping over MPLS Tunnels", RFC 6424, November 2011.
[RFC6424] Bahadur、N.、Kompella、K。、およびG. Swallow、「MPLSトンネル上でLSP-Pingを実行するためのメカニズム」、RFC 6424、2011年11月。
[IANA-AF] IANA Assigned Port Numbers, <http://www.iana.org/assignments/address-family-numbers>.
[IANA-AF] IANAはポート番号を割り当てました、<http://www.iana.org/assignments/address-family-numbers>。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461] Yasukawa、S.、ed。、「ポイントツーマルチポイントトラフィックエンジニアリングMPLSラベルスイッチドパス（LSP）のシグナリング要件」、RFC 4461、2006年4月。
[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006.
[RFC4687] Yasukawa、S.、Farrel、A.、King、D。、およびT. Nadeau、「ポイントツーマルチポイントMPLSネットワークの運用および管理（OAM）要件」、RFC 4687、2006年9月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（LSP） "、RFC 4875、2007年5月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、2010年6月。
[RFC6348] Le Roux, JL., Ed., and T. Morin, Ed., "Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol", RFC 6348, September 2011.
[RFC6348] Le Roux、Jl。、ed。、およびT. Morin、ed。、「ラベル分布プロトコルへのポイントツーマルチポイント拡張の要件」、RFC 6348、2011年9月。
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.
[RFC6388] Wijnands、IJ。、ed。、Misei、I.、ed。、Kompella、K。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチされたパスのラベル分布プロトコル拡張」、RFC 6388、2011年11月。
Authors' Addresses
著者のアドレス
Shaleen Saxena Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 EMail: ssaxena@cisco.com
Shaleen Saxena Cisco Systems、Inc。1414 Massachusetts Ave Boxborough、MA 01719メール：ssaxena@cisco.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 EMail: swallow@cisco.com
George Swallow Cisco Systems、Inc。1414 Massachusetts Ave Boxborough、MA 01719メール：swallow@cisco.com
Zafar Ali Cisco Systems Inc. 2000 Innovation Drive Kanata, ON, K2K 3E8, Canada. Phone: 613-889-6158 EMail: zali@cisco.com
Zafar Ali Cisco Systems Inc. 2000 Innovation Drive Kanata、ON、K2K 3E8、カナダ。電話：613-889-6158メール：zali@cisco.com
Adrian Farrel Juniper Networks EMail: adrian@olddog.co.uk
Adrian Farrel Juniper Networksメール：adrian@olddog.co.uk
Seisho Yasukawa NTT Corporation 3-9-11, Midori-Cho Musashino-Shi Tokyo 180-8585 Japan Phone: +81 422 59 2684 EMail: yasukawa.seisho@lab.ntt.co.jp
Seisho Yasukawa NTT Corporation 3-9-11、Midori-Cho Musashino-Shi Tokyo 180-8585日本電話：81 422 59 2684電子メール：Yasukawa.seisho@lab.ntt.co.jp
Thomas D. Nadeau CA Technologies, Inc. 273 Corporate Drive Portsmouth, NH 03801
Thomas D. Nadeau Ca Technologies、Inc。273 Corporate Drive Portsmouth、NH 03801
EMail: thomas.nadeau@ca.com