[要約] RFC 7394は、LSP-PingメカニズムのためのTime to Live TLVの定義に関するものです。このRFCの目的は、LSP-Pingメカニズムにおけるパケットの生存時間を制御するためのTLVの仕様を提供することです。
Internet Engineering Task Force (IETF) S. Boutros
Request for Comments: 7394 S. Sivabalan
Category: Standards Track G. Swallow
ISSN: 2070-1721 S. Saxena
Cisco Systems
V. Manral
Ionos Networks
S. Aldrin
Huawei Technologies, Inc.
November 2014
Definition of Time to Live TLV for LSP-Ping Mechanisms
LSP-Pingメカニズムの生存期間TLVの定義
Abstract
概要
LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment Pseudowire (MS-PW) and/or bidirectional co-routed Label Switched Path (LSP) from any node on the path of the MS-PW and/or bidirectional co-routed LSP. This document defines a TLV to address this shortcoming.
LSP-Pingは、MPLSネットワークで広く展開されている運用、管理、および保守（OAM）メカニズムです。ただし、現在の形式では、このメカニズムは、MSのパス上の任意のノードからのマルチセグメント疑似配線（MS-PW）のセグメントの接続性、および/または双方向の同じルートのラベルスイッチドパス（LSP）を検証するには不十分です。 -PWおよび/または双方向コルーテッドLSP。このドキュメントでは、この欠点に対処するTLVを定義しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc7394.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7394で入手できます。
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
2. Terminology .....................................................3
3. Time To Live TLV ................................................4
3.1. TTL TLV Format .............................................4
3.2. Usage ......................................................4
4. Operation .......................................................5
4.1. Traceroute Mode ............................................6
4.2. Error Scenario .............................................6
5. Security Considerations .........................................6
6. IANA Considerations .............................................7
7. References ......................................................7
7.1. Normative References .......................................7
Acknowledgements ...................................................7
Contributors .......................................................7
Authors' Addresses .................................................8
An MS-PW may span across multiple service provider networks. In order to allow Service Providers (SPs) to verify segments of such MS-PWs from any node on the path of the MS-PW, any node along the path of the MS-PW, should be able to originate an MPLS Echo Request packet to any other node along the path of the MS-PW and receive the corresponding MPLS Echo Reply. If the originator of the MPLS Echo Request is at the end of a MS-PW, the receiver of the request can send the reply back to the sender without knowing the hop-count distance of the originator. The reply will be intercepted by the originator regardless of the TTL value on the reply packet. But, if the originator is not at the end of the MS-PW, the receiver of the MPLS Echo Request may need to know how many hops away the originator of the MPLS Echo Request is so that it can set the TTL value on the MPLS header for the MPLS Echo Reply to be intercepted at the originator node.
MS-PWは、複数のサービスプロバイダーネットワークにまたがることがあります。サービスプロバイダー（SP）が、MS-PWのパス上のノードからそのようなMS-PWのセグメントを確認できるようにするために、MS-PWのパスに沿ったすべてのノードは、MPLSエコー要求パケットを発信できる必要があります。 MS-PWのパスに沿った他のノードに送信し、対応するMPLSエコー応答を受信します。 MPLSエコー要求の発信者がMS-PWの最後にある場合、要求の受信者は発信者のホップカウント距離を知らなくても送信者に返信を返すことができます。返信パケットのTTL値に関係なく、返信は発信者によって傍受されます。ただし、発信者がMS-PWの最後にない場合、MPLSエコー要求の受信者は、MPLSエコー要求の発信者がMPLSにTTL値を設定できるように何ホップ離れているかを知る必要がある場合があります。発信者ノードでインターセプトされるMPLSエコー応答のヘッダー。
In MPLS networks, for bidirectional co-routed LSPs, if it is desired to verify connectivity from any intermediate node Label Switching Router (LSR) on the LSP to the any other LSR on the LSP the receiver may need to know the TTL to send the MPLS Echo Reply with, so as the packet is intercepted by the originator node.
MPLSネットワークでは、双方向コルーテッドLSPの場合、LSP上の中間ノードのラベルスイッチングルータ（LSR）からLSP上の他のLSRへの接続を確認する必要がある場合、受信者はTTLを知って送信する必要があります。 MPLS Echo Reply with。これにより、パケットは発信者ノードによって傍受されます。
A new optional TTL TLV is defined in this document. This TLV will be added by the originator of the MPLS Echo Request to inform the receiver how many hops away the originator is on the path of the MS-PW or bidirectional LSP.
このドキュメントでは、新しいオプションのTTL TLVが定義されています。このTLVはMPLSエコー要求の発信者によって追加され、発信者がMS-PWまたは双方向LSPのパス上にあるホップ数をレシーバーに通知します。
This mechanism only works if the MPLS Echo Reply is sent down the co-routed LSP; hence, the scope of this TTL TLV is currently limited to MS-PW or bidirectional co-routed MPLS LSPs. The presence of the TLV implies the use of the return path of the co-routed LSP, if the return path is any other mechanism, then the TLV in the MPLS Echo Request MUST be ignored.
このメカニズムが機能するのは、MPLSエコー応答が同じルートのLSPに送信された場合のみです。したがって、このTTL TLVの範囲は現在、MS-PWまたは双方向のコルーテッドMPLS LSPに制限されています。 TLVの存在は、同じルートのLSPのリターンパスの使用を意味します。リターンパスが他のメカニズムである場合、MPLSエコー要求のTLVは無視する必要があります。
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]で説明されているように解釈されます。
LSR: Label Switching Router
LSR：ラベルスイッチングルーター
MPLS-TP: MPLS Transport Profile
MPLS-TP：MPLSトランスポートプロファイル
MS-PW: Multi-Segment Pseudowire
MS-PW：マルチセグメント疑似配線
PW: Pseudowire
説明：シュードビル
TLV: Type Length Value
TLV：タイプの長さの値
TTL: Time To Live
TTL：存続可能時間
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 = 32769 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Time To Live TLV Format
図1：存続時間TLV形式
The TTL TLV has the format shown in Figure 1.
TTL TLVのフォーマットは、図1に示されています。
Value
値
The value of the TTL as specified by this TLV
このTLVで指定されたTTLの値
Flags
旗
The Flags field is a bit vector with the following format:
Flagsフィールドは、次の形式のビットベクトルです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One flag is defined for now, the R flag. The rest of the flags are Reserved - MUST be zero (MBZ) when sending and ignored on receipt.
今のところ、Rフラグという1つのフラグが定義されています。残りのフラグは予約済みです-送信時にゼロ（MBZ）でなければならず、受信時に無視されます。
The R flag (Reply TTL) is set signify that the value is meant to be used as the TTL for the reply packet. Other bits may be defined later to enhance the scope of this TLV.
Rフラグ（応答TTL）が設定されていると、その値が応答パケットのTTLとして使用されることを意味します。他のビットは、このTLVの範囲を拡張するために後で定義される場合があります。
The TTL TLV MAY be included in the MPLS Echo Request by the originator of the request.
TTL TLVは、要求の発信者がMPLSエコー要求に含めることができます。
If the TTL TLV is present and the receiver does not understand TTL TLVs, it will simply ignore the TLV, as is the case for all optional TLVs. If the TTL TLV is not present or is not processed by the receiver, any determination of the TTL value used in the MPLS label on the LSP-Ping echo reply is beyond the scope of this document.
TTL TLVが存在し、レシーバーがTTL TLVを理解しない場合、すべてのオプションのTLVの場合と同様に、TLVは単に無視されます。 TTL TLVが存在しないか、レシーバーによって処理されない場合、LSP-Pingエコー応答のMPLSラベルで使用されるTTL値の決定は、このドキュメントの範囲外です。
If the TTL TLV is present and the receiver understands TTL TLVs, one of the following two conditions apply:
TTL TLVが存在し、レシーバーがTTL TLVを理解する場合、次の2つの条件のいずれかが適用されます。
o If the TTL TLV value field is zero, the LSP-Ping echo request packet SHOULD be dropped.
o TTL TLV値フィールドがゼロの場合、LSP-Pingエコー要求パケットをドロップする必要があります（SHOULD）。
o Otherwise, the receiver MUST use the TTL value specified in the TTL TLV when it creates the MPLS header of the MPLS Echo Reply. The TTL value in the TTL TLV takes precedence over any TTL value determined by other means, such as from the Switching Point TLV in the MS-PW. This precedence will aid the originator of the LSP-Ping echo request in analyzing the return path.
o それ以外の場合、レシーバーはMPLSエコー応答のMPLSヘッダーを作成するときに、TTL TLVで指定されたTTL値を使用する必要があります。 TTL TLVのTTL値は、MS-PWのスイッチングポイントTLVからなど、他の方法で決定されたTTL値よりも優先されます。この優先順位は、LSP-Pingエコー要求の発信者が戻りパスを分析するのに役立ちます。
In this section, we explain a use case for the TTL TLV with an MPLS MS-PW.
このセクションでは、MPLS MS-PWを使用したTTL TLVの使用例について説明します。
<------------------MS-PW --------------------->
A B C D E
o -------- o -------- o --------- o --------- o
---MPLS Echo Request--->
<--MPLS Echo Reply------
Figure 2: Use-Case with MS-PWs
図2：MS-PWを使用したユースケース
Let us assume an MS-PW going through LSRs A, B, C, D, and E. Furthermore, assume that an operator wants to perform a connectivity check between B and D, from B. Thus, an MPLS Echo Request with the TTL TLV is originated from B and sent towards D. The MPLS Echo Request packet contains the FEC of the PW Segment between C and D. The value field of the TTL TLV and the TTL field of the MPLS label are set to 2, the choice of the value 2 will be based on the operator input requesting the MPLS Echo Request or from the optional LDP switching point TLV. The MPLS Echo Request is intercepted at D because of TTL expiry. D detects the TTL TLV in the request and uses the TTL value (i.e., 2) specified in the TLV on the MPLS label of the MPLS Echo Reply. The MPLS Echo Reply will be intercepted by B because of TTL expiry.
LSR A、B、C、D、およびEを通過するMS-PWを想定します。さらに、オペレータがBからBとDの間の接続性チェックを実行したいとします。したがって、TTLを使用したMPLSエコー要求TLVはBから発信され、Dに向けて送信されます。MPLSエコー要求パケットには、CとDの間のPWセグメントのFECが含まれています。TTLTLVの値フィールドとMPLSラベルのTTLフィールドは2に設定されています。値2は、MPLSエコー要求を要求するオペレーター入力、またはオプションのLDPスイッチングポイントTLVからの値に基づいています。 TTLの期限切れのため、MPLSエコー要求はDでインターセプトされます。 DはリクエストでTTL TLVを検出し、MPLSエコー応答のMPLSラベルのTLVで指定されたTTL値（つまり、2）を使用します。 TTLの期限切れのため、MPLSエコー応答はBによってインターセプトされます。
The same operation will apply when we have a co-routed bidirectional LSP and we want to check connectivity from an intermediate LSR "B" to another LSR "D".
同一ルートの双方向LSPがあり、中間のLSR "B"から別のLSR "D"への接続を確認する場合も、同じ操作が適用されます。
In traceroute mode, the TTL value in the TLV is set to 1 for the first Echo Request, then to 2 for the next, and so on. This is similar to the TTL values used for the label set on the packet.
tracerouteモードでは、TLVのTTL値は最初のエコー要求に対して1に設定され、次のエコー要求に対して2に設定されます。これは、パケットに設定されたラベルに使用されるTTL値に似ています。
It is possible that the MPLS Echo Request packet was intercepted before the intended destination for reasons other than label TTL expiry. This could be due to network faults, misconfiguration, or other reasons. In such cases, if the return TTL is set to the value specified in the TTL TLV, then the echo response packet will continue beyond the originating node. This becomes a security issue.
ラベルTTLの有効期限以外の理由で、意図した宛先の前にMPLSエコー要求パケットが傍受された可能性があります。これは、ネットワーク障害、設定ミス、またはその他の理由が原因である可能性があります。このような場合、リターンTTLがTTL TLVで指定された値に設定されていると、エコー応答パケットは発信ノードを超えて継続します。これはセキュリティの問題になります。
To prevent this, the label TTL value used in the MPLS Echo Reply packet MUST be modified by deducting the incoming label TTL on the received packet from TTL TLV value. If the MPLS Echo Request packet is punted to the CPU before the incoming label TTL is deducted, then another 1 MUST be added. In other words:
これを防ぐには、MPLSエコー応答パケットで使用されるラベルTTL値を、TTL TLV値から受信パケットの着信ラベルTTLを差し引くことによって変更する必要があります。着信ラベルTTLが差し引かれる前にMPLSエコー要求パケットがCPUにパントされる場合、別の1を追加する必要があります。言い換えると：
Return TTL Value on the MPLS Echo Reply packet = (TTL TLV Value) -
(Incoming Label TTL) + 1
This document allows the setting of the TTL value in the MPLS Label of an MPLS Echo Reply, so that it can be intercepted by an intermediate device. This can cause a device to get a lot of LSP-Ping packets that get redirected to the CPU.
このドキュメントでは、MPLSエコー応答のMPLSラベルでTTL値を設定できるため、中間デバイスによって傍受される可能性があります。これにより、デバイスがCPUにリダイレクトされる多くのLSP-Pingパケットを取得する可能性があります。
However, the same is possible even without the changes mentioned in this document. A device should rate limit the LSP-Ping packets redirected to the CPU so that the CPU is not overwhelmed.
ただし、このドキュメントに記載されている変更がなくても、同じことが可能です。 CPUが過負荷にならないように、デバイスはCPUにリダイレクトされるLSP-Pingパケットをレート制限する必要があります。
The recommendation in the Security Considerations of [RFC4379] applies, to check the source address of the MPLS Echo Request; however, the source address can now be any node along the LSP path.
[RFC4379]のセキュリティに関する考慮事項の推奨事項が適用され、MPLSエコー要求の送信元アドレスをチェックします。ただし、送信元アドレスはLSPパス上の任意のノードにすることができます。
A faulty transit node changing the TTL TLV value could make the wrong node reply to the MPLS Echo Request, and/or the wrong node to receive the MPLS Echo Reply. An LSP trace may help identify the faulty transit node.
TTL TLV値を変更する障害のあるトランジットノードは、MPLSエコー要求に間違ったノードを応答させたり、MPLSエコー応答を受信するために間違ったノードを引き起こしたりする可能性があります。 LSPトレースは、障害のある中継ノードを識別するのに役立ちます。
IANA has assigned a TLV type value to the following TLV from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry in the "TLVs" subregistry.
IANAは、「TLVs」サブレジストリの「Multi-Protocol Label Switching（MPLS）Label Switched Paths（LSPs）Ping Parameters」レジストリから次のTLVにTLVタイプ値を割り当てました。
Time To Live TLV (see Section 3).
Time To Live TLV（セクション3を参照）。
IANA has allocated the value 32769.
IANAは値32769を割り当てました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月、<http://www.rfc-editor.org/info/rfc4379> 。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5085] Nadeau、T.、Ed。およびC. Pignataro、Ed。、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：A Control Channel for Pseudowires」、RFC 5085、2007年12月、<http：//www.rfc -editor.org/info/rfc5085>。
Acknowledgements
謝辞
The authors would like to thank Greg Mirsky for his comments.
著者は彼のコメントのためにグレッグ・ミルスキーに感謝したいと思います。
Contributors
貢献者
Michael Wildt Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 United States EMail: mwildt@cisco.com
Michael Wildt Cisco Systems、Inc. 1414 Massachusetts Avenue Boxborough、MA 01719 United States Eメール：mwildt@cisco.com
Authors' Addresses
著者のアドレス
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, CA 95134 United States EMail: sboutros@cisco.com
Sami Boutros Cisco Systems、Inc. 3750 Cisco Way San Jose、CA 95134米国Eメール：sboutros@cisco.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada EMail: msiva@cisco.com
Shiva Sivabalan Cisco Systems、Inc. ವೆ革新的なドライブカンタ、オンタリオ、Q1 A ೮カナダメール：masiva@scisco.com
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 United States EMail: swallow@cisco.com
George Swallow Cisco Systems、Inc. 300 Beaver Brook Road Boxborough、MA 01719 United States Eメール：swallow@cisco.com
Shaleen Saxena Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 United States EMail: ssaxena@cisco.com
Shaleen Saxena Cisco Systems、Inc. 1414 Massachusetts Avenue Boxborough、MA 01719 United States Eメール：ssaxena@cisco.com
Vishwas Manral Ionos Networks 4100 Moorpark Ave, Suite 122 San Jose, CA 95117 United States EMail: vishwas@ionosnetworks.com
Biswas Muralnios Networks 4100 Murvik Ave、Suithe 122 SunJosé、CA 95117 United Statesメール：Biswas@iononetwerks.com。
Sam Aldrin Huawei Technologies, Inc. 1188 Central Express Way, Santa Clara, CA 95051 United States EMail: aldrin.ietf@gmail.com
Sam Aldrin Huawei Technologies、Inc. 1188 Central Express Way、Santa Clara、CA 95051 United States Eメール：aldrin.ietf@gmail.com