RFC 7876 - UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7876
タイトル : RFC 7876 - MPLSネットワークのパケット損失および遅延測定のためのUDPリターンパス
翻訳編集 : 自動生成

[要約] このRFCは、MPLSネットワークにおいてパケット損失や遅延を測定する際、測定結果（リプライ）を特定のUDPポート宛に返送させるための「UDPリターンパス」機能を定義しています。一方向のパス特性を精密に測定するために、制御プレーン（LSP Ping等）を利用して戻り経路のポートを指定し、受信側での正確な統計収集と分析を可能にします。

Internet Engineering Task Force (IETF)                         S. Bryant
Request for Comments: 7876                                   Independent
Category: Standards Track                                   S. Sivabalan
ISSN: 2070-1721                                                  S. Soni
                                                           Cisco Systems
                                                               July 2016

UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks

MPLSネットワークのパケット損失および遅延測定のためのUDPリターンパス

Abstract

概要

RFC 6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path.

RFC 6374は、MPLSネットワーク（MPLS-PLDM）のパケット損失と遅延測定のプロトコルを定義しています。このドキュメントでは、UDP/IPリターンパスを介して帯域外MPLSパフォーマンス管理応答を送信および処理するときに使用される手順を指定します。

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 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc7876.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7876で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................3
   2. Requirements Language ...........................................3
   3. Solution Overview ...............................................3
      3.1. UDP Return Object ..........................................4
   4. Theory of Operation .............................................5
      4.1. Sending an MPLS-PLDM Query .................................5
      4.2. Receiving an MPLS-PLDM Query Request .......................5
      4.3. Sending an MPLS-PLDM Response ..............................6
      4.4. Receiving an MPLS-PLDM Response ............................7
   5. Congestion Considerations .......................................7
   6. Manageability Considerations ....................................8
   7. Security Considerations .........................................8
   8. IANA Considerations .............................................8
   9. References ......................................................9
      9.1. Normative References .......................................9
      9.2. Informative References .....................................9
   Acknowledgements ..................................................10
   Authors' Addresses ................................................10

1. Introduction

1. はじめに

This document describes how MPLS-PLDM [RFC6374] out-of-band Responses can be delivered to the querier using UDP/IP.

このドキュメントでは、UDP/IPを使用してMPLS-PLDM [RFC6374]帯域外応答をクエリアに配信する方法について説明します。

The use of UDP may be required to support data-path management such as passage through firewalls or to provide the necessary multiplexing needed in bistatic operation where the querier and the collector are not co-located and the collector is gathering the Response information for a number of responders. In a highly scaled system, some MPLS-PLDM sessions may be off-loaded to a specific node within the distributed system that comprises the Label Switching Router (LSR) as a whole. In such systems, the Response may arrive via any interface in the LSR and needs to be forwarded internally to the processor tasked with handling the particular MPLS-PLDM measurement. Currently, the MPLS-PLDM protocol does not have any mechanism to deliver the PLDM Response message to a particular node within a multi-CPU LSR.

ファイアウォールの通過などのデータパス管理をサポートするため、またはクエリアとコレクターが同じ場所に配置されておらず、コレクターがいくつかの応答情報を収集しているバイスタティック操作で必要な多重化を提供するために、UDPの使用が必要になる場合がありますレスポンダーの。高度にスケーリングされたシステムでは、一部のMPLS-PLDMセッションが、全体としてラベルスイッチングルーター（LSR）を構成する分散システム内の特定のノードにオフロードされる場合があります。そのようなシステムでは、応答はLSRの任意のインターフェースを介して到着する可能性があり、特定のMPLS-PLDM測定の処理を担当するプロセッサに内部的に転送する必要があります。現在、MPLS-PLDMプロトコルには、マルチCPU LSR内の特定のノードにPLDM応答メッセージを配信するメカニズムがありません。

The procedure described in this specification describes how the querier requests delivery of the MPLS-PLDM Response over IP to a dynamic UDP port. It makes no other changes to the protocol and thus does not affect the case where the Response is delivered over an MPLS Associated Channel [RFC5586].

この仕様で説明されている手順では、クエリアがMPLS-PLDM Response over IPの動的UDPポートへの配信をリクエストする方法について説明しています。プロトコルに他の変更を加えないため、応答がMPLS関連チャネル[RFC5586]経由で配信される場合には影響しません。

2. Requirements Language

2. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、[RFC2119] で説明されているように解釈されるものとします。

3. Solution Overview

3. ソリューションの概要

This document specifies that, unless configured otherwise, if a UDP Return Object (URO) is present in an MPLS-PLDM Query, the responder SHOULD use the IP address and UDP port in the URO to reply back to the querier. The querier MAY include multiple UROs in an MPLS-PLDM Query indicating to the responder that an identical Response SHOULD be sent to each address-port pair. A responder MAY be designed or configured to only transmit a single Response, in which case the Response MUST be sent using the parameters specified in the first URO in the Query packet that it is able to use (see Section 4.3).

この文書は、別の設定がされていない限り、MPLS-PLDMクエリにUDP Return Object (URO) が存在する場合、応答側はUROのIPアドレスとUDPポートを使用して問い合わせ側に応答すべきである (SHOULD) と規定します。問い合わせ側は、MPLS-PLDMクエリに複数のUROを含めてもよく (MAY)、それは応答側に対して、各アドレスとポートの組に同一の応答を送信すべきである (SHOULD) ことを示します。応答側は単一の応答のみを送信するように設計または設定されていてもよく (MAY)、その場合、応答は、クエリパケット内で使用可能な最初のUROで指定されたパラメーターを使用して送信されなければなりません (MUST) (セクション4.3を参照)。

The procedures defined in this document may be applied to both unidirectional and bidirectional Label Switched Paths (LSPs). In this document, the term "bidirectional LSP" includes the co-routed bidirectional LSP defined in [RFC3945] and the associated bidirectional LSP that is constructed from a pair of unidirectional LSPs (one for each direction) that are associated with one another at the LSP's ingress/egress points [RFC5654]. The mechanisms defined in this document can apply to both IP/MPLS and to the MPLS Transport Profile (MPLS-TP) [RFC5654] [RFC5921].

このドキュメントで定義されている手順は、単方向と双方向の両方のラベルスイッチドパス（LSP）に適用できます。このドキュメントでは、「双方向LSP」という用語には、[RFC3945]で定義されている共ルーティング双方向LSPと、 LSPの入力/出力ポイント[RFC5654]。このドキュメントで定義されているメカニズムは、IP/MPLSとMPLSトランスポートプロファイル（MPLS-TP）[RFC5654] [RFC5921]の両方に適用できます。

3.1. UDP Return Object

3.1. UDPリターンオブジェクト

The format of the UDP Return Object (URO) is as follows:

UDP Return Object（URO）のフォーマットは次のとおりです。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | URO Type      | Length={6,18} |    UDP-Destination-Port       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                           Address                             ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Type and Length fields are each 8 bits long. The Length field indicates the size in bytes of the remainder of the object (i.e., it is the size of the address in bytes plus 2). When the address is IPv4, the Length field is thus 6; when the address is IPv6, the Length field is thus 18. The Length field therefore acts as both the TLV parsing parameter and the address family type indicator.

タイプおよび長さフィールドはそれぞれ8ビット長です。長さフィールドは、オブジェクトの残りのサイズをバイト単位で示します（つまり、バイト単位のアドレスのサイズ+ 2）。アドレスがIPv4の場合、Lengthフィールドは6になります。したがって、アドレスがIPv6の場合、Lengthフィールドは18になります。したがって、Lengthフィールドは、TLV解析パラメーターとアドレスファミリータイプインジケーターの両方として機能します。

The UDP Return Object Type (URO Type) has a value of 131.

UDP戻りオブジェクトタイプ（UROタイプ）の値は131です。

The UDP-Destination-Port is a UDP destination port as specified in [RFC768].

UDP-Destination-Portは、[RFC768]で指定されているUDP宛先ポートです。

The Address is either an IPv4 or an IPv6 address.

アドレスは、IPv4またはIPv6アドレスのいずれかです。

The URO MUST NOT appear in a Response and MUST be ignored if it is found to be present.

UROは応答に表示してはならず（MUST NOT）、存在することがわかった場合は無視しなければなりません (MUST)。

To prevent any ambiguity as to which address the responder needs to reply to, an MPLS-PLDM Query message containing a URO MUST NOT include an RFC 6374 Return Address TLV (TLV 1). Additionally, the method of constructing the return address from the Source Address TLV (TLV 130) described in Section 3.5.2 of [RFC6374] MUST NOT be used to construct a Response to a Query message that contains a URO.

応答側がどのアドレスに応答する必要があるかについての曖昧さを防ぐために、UROを含むMPLS-PLDMクエリメッセージは、RFC 6374のReturn Address TLV (TLV 1) を含んではなりません (MUST NOT)。さらに、[RFC6374] のセクション3.5.2に記述されている、Source Address TLV (TLV 130) から応答先アドレスを構築する方法を、UROを含むクエリメッセージへの応答を構築するために使用してはなりません (MUST NOT)。

4. Theory of Operation

4. 動作理論

This document defines the UDP Return Object to enable the MPLS-PLDM querier to specify the return path for the MPLS-PLDM reply using UDP/ IP encapsulation.

このドキュメントでは、UDPリターンオブジェクトを定義して、MPLS-PLDMクエリアがUDP / IPカプセル化を使用してMPLS-PLDM応答のリターンパスを指定できるようにします。

When the MPLS-PLDM Response is requested out-of-band by setting the Control Code of the MPLS-PLDM Query to "Out-of-band Response Requested", and the URO is present, the responder SHOULD send the Response back to querier on the specified destination UDP port at the specified destination IP address contained in the URO.

MPLS-PLDM QueryのControl Codeを「Out-of-band Response Requested」に設定することでMPLS-PLDM Responseが帯域外で要求され、かつUROが存在する場合、応答者は、UROに含まれる指定された宛先IPアドレスの指定された宛先UDPポートに向けて、Responseを問い合わせ元に返送すべきです (SHOULD)。

If the URO is expected but is not present in a Query message and an MPLS-PLDM Response is requested out-of-band, the Query message MUST NOT be processed further, and if possible, an "Error - Invalid Message" ([RFC6374], Section 3.1) SHOULD be sent to the querier and the operator notified via the management system (see Section 4.2 for further details).

UROが予期されているがクエリメッセージに存在せず、MPLS-PLDM応答が帯域外で要求された場合、クエリメッセージはさらに処理してはならず（MUST NOT）、「エラー-無効なメッセージ」（[RFC6374 ]、セクション3.1）はクエリアに送信し、管理システム経由でオペレーターに通知すべきです (SHOULD)（詳細についてはセクション4.2を参照）。

4.1. Sending an MPLS-PLDM Query

4.1. MPLS-PLDMクエリの送信

When sending an MPLS-PLDM Query message, in addition to the rules and procedures defined in [RFC6374], the Control Code of the MPLS-PLDM Query MUST be set to "Out-of-band Response Requested", and a URO MUST be carried in the MPLS-PLDM Query message.

[RFC6374]で定義されたルールと手順に加えて、MPLS-PLDMクエリメッセージを送信する場合、MPLS-PLDMクエリの制御コードは「帯域外応答要求」に設定する必要があり、UROはMPLS-PLDMクエリメッセージで伝送されます。

If the querier uses the UDP port to de-multiplex the Response for a different measurement type, there MUST be a different UDP port for each measurement type (delay, loss, and delay-loss combined).

クエリアがUDPポートを使用して異なる測定タイプの応答を逆多重化する場合、測定タイプごとに異なるUDPポートが必要です（遅延、損失、および遅延損失の組み合わせ）。

An implementation MAY use multiple UDP ports for the same measurement type to direct the Response to the correct management process in the LSR.

実装は、LSRの正しい管理プロセスに応答を送るために、同じ測定タイプの複数のUDPポートを使用する場合があります (MAY)。

4.2. Receiving an MPLS-PLDM Query Request

4.2. MPLS-PLDMクエリ要求の受信

The processing of MPLS-PLDM Query messages as defined in [RFC6374] applies in this document. In addition, when an MPLS-PLDM Query message is received, with the Control Code of the MPLS-PLDM Query set to "Out-of-band Response Requested" with a URO present, then the responder SHOULD use that IP address and UDP port to send an MPLS-PLDM Response back to the querier.

[RFC6374]で定義されているMPLS-PLDM Queryメッセージの処理が、この文書でも適用されます。さらに、MPLS-PLDM QueryのControl Codeが「Out-of-band Response Requested」に設定され、UROが存在するMPLS-PLDM Queryメッセージを受信した場合、応答者は、そのIPアドレスとUDPポートを使用して、MPLS-PLDM Responseを問い合わせ元に返送すべきです (SHOULD)。

If an out-of-band Response is requested and the URO is missing, the Query SHOULD be dropped in the case of a unidirectional LSP. If the TLV is missing on a bidirectional LSP, the Control Code of the Response message SHOULD set to 0x1C indicating "Error - Invalid Message" ([RFC6374], Section 3.1), and the Response SHOULD be sent over the reverse LSP. The receipt of such a malformed request SHOULD be reported to the operator through the management system, with normal precautions taken in respect to the prevention of overload of the error-reporting system.

帯域外の応答が要求されているのにUROが欠けている場合、単方向LSPであればクエリは破棄されるべきです (SHOULD)。双方向LSPでTLVが欠けている場合、応答メッセージのControl Codeは「Error - Invalid Message」を示す0x1C ([RFC6374] のセクション3.1) に設定されるべきであり (SHOULD)、応答は逆方向のLSP上で送信されるべきです (SHOULD)。このような不正な形式の要求の受信は、エラー報告システムの過負荷を防ぐための通常の予防措置を講じたうえで、管理システムを通じてオペレーターに報告されるべきです (SHOULD)。

4.3. Sending an MPLS-PLDM Response

4.3. MPLS-PLDM応答の送信

As specified in [RFC6374], the MPLS-PLDM Response can be sent either over the reverse MPLS LSP for a bidirectional LSP or over an IP path. It MUST NOT be sent other than in Response to an MPLS-PLDM Query message.

[RFC6374]で指定されているように、MPLS-PLDM応答は、双方向LSPのリバースMPLS LSPまたはIPパスのいずれかで送信できます。 MPLS-PLDMクエリメッセージへの応答以外では送信してはなりません (MUST NOT)。

When the requested return path is an IP forwarding path and this method is in use, the destination IP address and UDP port are copied from the URO. The source IP address and the source UDP port of the Response packet are left to the discretion of the responder, subject to the normal management and security considerations. If the querier has included URO(s) for only one IP address family and a return path of that type is not available, then the Query message MUST be discarded, and the operator SHOULD be informed of the error through the management system using the normal rate-limited approach. If the responder is configured to only respond with a single Response, and a path using the IP address family in the first URO is not available, the responder MAY search the UROs for the first URO specifying a return address family for which it does have a path and use the parameters in that URO to respond. If the responder is designed or configured not to search for a URO that it can respond to, then the operator SHOULD be informed of the error through the management system using the normal rate-limited approach.

要求された応答経路がIP転送経路であり、この方法が使用されている場合、宛先IPアドレスとUDPポートはUROからコピーされます。応答パケットの送信元IPアドレスと送信元UDPポートは、通常の管理上およびセキュリティ上の考慮に従い、応答側の裁量に任されます。問い合わせ側が1つのIPアドレスファミリーについてのみUROを含めており、その種類の応答経路が利用できない場合、クエリメッセージは破棄されなければならず (MUST)、通常のレート制限された方法により、管理システムを通じてオペレーターにエラーが通知されるべきです (SHOULD)。応答側が単一の応答のみで応答するよう設定されており、最初のUROのIPアドレスファミリーを使用する経路が利用できない場合、応答側は、経路を持っている応答先アドレスファミリーを指定する最初のUROをUROの中から探し、そのUROのパラメーターを使用して応答してもよいです (MAY)。応答側が、応答できるUROを探さないように設計または設定されている場合、通常のレート制限された方法により、管理システムを通じてオペレーターにエラーが通知されるべきです (SHOULD)。

The packet format for the MPLS-PLDM Response after the UDP header is as specified in [RFC6374]. As shown in Figure 1, the Associated Channel Header (ACH) [RFC5586] is not included. The information provided by the ACH is not needed since the correct binding between the Query and Response messages is achieved through the UDP port and the session identifier contained in the RFC 6374 message.

UDPヘッダーの後のMPLS-PLDM応答のパケット形式は、[RFC6374]で指定されています。図1に示すように、関連チャネルヘッダー（ACH）[RFC5586]は含まれていません。クエリメッセージと応答メッセージ間の正しいバインディングは、UDPポートとRFC 6374メッセージに含まれるセッション識別子を介して行われるため、ACHによって提供される情報は必要ありません。

       +----------------------------------------------------------+
       |  IP Header                                               |
       .    Source Address = Responders IP Address                |
       .    Destination Address = URO.Address                     |
       .    Protocol = UDP                                        .
       .                                                          .
       +----------------------------------------------------------+
       | UDP Header                                               |
       .   Source Port = As chosen by Responder                   .
       .   Destination Port = URO.UDP-Destination-Port            .
       .                                                          .
       +----------------------------------------------------------+
       | Message as specified in RFC 6374                         |
       .                                                          .
       +----------------------------------------------------------+

Figure 1: Response Packet Format

図1：応答パケットの形式

If the return path is an IP path, only one-way delay or one-way loss measurement can be carried out. In this case, timestamps 3 and 4 MUST be zero as specified in [RFC6374].

リターンパスがIPパスの場合、一方向遅延または一方向損失の測定のみを実行できます。この場合、タイムスタンプ3と4は[RFC6374]で指定されているようにゼロでなければなりません (MUST)。

4.4. Receiving an MPLS-PLDM Response

4.4. MPLS-PLDM応答の受信

If the Response was received over UDP/IP and an out-of-band Response was expected, the Response message SHOULD be directed to the appropriate measurement process as determined by the destination UDP port and processed using the corresponding measurement type procedure specified in [RFC6374].

ResponseがUDP/IPを介して受信され、帯域外のResponseが期待されていた場合、Responseメッセージは、宛先UDPポートによって決まる適切な測定プロセスに振り向けられ、[RFC6374]で規定されている対応する測定タイプの手順を使用して処理されるべきです (SHOULD)。

If the Response was received over UDP/IP and an out-of-band Response was not requested, that Response SHOULD be dropped, and the event SHOULD be reported to the operator through the management system, with normal precautions taken in respect to the prevention of overload of the error-reporting system.

応答がUDP/IPを介して受信され、帯域外応答が要求されなかった場合、その応答はドロップされるべきであり (SHOULD)、その予防に関して通常の予防策を講じて、イベントは管理システムを通じてオペレーターに報告されるべきである（SHOULD）。エラー報告システムの過負荷の。

5. Congestion Considerations

5. 輻輳に関する考慮事項

This protocol MUST be run in accordance with the guidance provided in [RFC5405]. As advised in Section 3.1.2 of RFC 5405, operators that wish to run this protocol at rates in excess of one packet per three seconds need to ensure that the MPLS path being monitored and any IP path that may be used to carry the Response are provisioned such that there is a negligible chance of this protocol causing congestion. Additionally, if a significant number of Response packets are lost, the querier MUST reduce the sending rate to a point where there is a negligible chance that this protocol is contributing to network congestion. The operator should also take precautions that Response packets do not leak out of the network domain being used and cause congestion elsewhere. If a default IP address is configured by the equipment vendor, this MUST be an address known to contain the Response packet within the responder. A responder receiving a Query specifying this as a return address, and not being configured to expect such a return address, SHOULD notify the operator in a suitably rate-limited manner.

このプロトコルは[RFC5405]で提供されたガイダンスに従って実行されなければなりません (MUST)。 RFC 5405のセクション3.1.2で助言されているように、3秒あたり1パケットを超えるレートでこのプロトコルを実行することを望むオペレーターは、監視対象のMPLSパスと応答の伝送に使用できるIPパスがすべてこのプロトコルが輻輳を引き起こす可能性が無視できるようにプロビジョニングされています。さらに、かなりの数の応答パケットが失われた場合、クエリアは、このプロトコルがネットワークの輻輳の一因となる可能性が無視できる程度まで、送信速度を下げなければなりません (MUST)。オペレーターはまた、応答パケットが使用中のネットワークドメインから漏れて他の場所で輻輳を引き起こさないように予防策を講じる必要があります。デフォルトのIPアドレスが機器ベンダーによって構成されている場合、これはレスポンダ内に応答パケットを含むことがわかっているアドレスでなければなりません (MUST)。これを戻りアドレスとして指定するクエリを受信し、そのような戻りアドレスを期待するように設定されていないレスポンダは、適切にレート制限された方法でオペレータに通知すべきです (SHOULD)。

6. Manageability Considerations

6. 管理性に関する考慮事項

The manageability considerations described in Section 7 of [RFC6374] are applicable to this specification. Additional manageability considerations are noted within the elements of procedure in this document.

[RFC6374]のセクション7で説明されている管理性の考慮事項は、この仕様に適用されます。このドキュメントの手順の要素には、管理性に関するその他の考慮事項が記載されています。

Nothing in this document precludes the use of a configured UDP/IP return path in a deployment in which configuration is preferred to signaling. In these circumstances, the URO MAY be omitted from the MPLS-PLDM messages.

このドキュメントでは、シグナリングよりも構成が優先される展開で、構成されたUDP/IPリターンパスの使用を排除するものはありません。これらの状況では、UROはMPLS-PLDMメッセージから省略される場合があります (MAY)。

7. Security Considerations

7. セキュリティに関する考慮事項

The MPLS-PLDM system is not intended to be deployed on the public Internet. It is intended for deployment in well-managed private and service provider networks. The security considerations described in Section 8 of [RFC6374] are applicable to this specification, and particular attention should be paid to the last two paragraphs. Cryptographic measures may be enhanced by the correct configuration of access-control lists and firewalls.

MPLS-PLDMシステムは、公共のインターネット上での展開を想定していません。これは、適切に管理されたプライベートネットワークおよびサービスプロバイダーネットワークでの展開を目的としています。 [RFC6374]のセクション8に記載されているセキュリティの考慮事項はこの仕様に適用され、最後の2つの段落には特に注意を払う必要があります。暗号対策は、アクセス制御リストとファイアウォールの正しい構成によって強化される場合があります。

To prevent the use of this protocol as a reflection attack vector, the operator should ensure that the IP address in the URO addresses a system that is expecting to act as a receiver of PLDM Responses.

このプロトコルがリフレクション攻撃ベクトルとして使用されないようにするには、オペレーターは、UROのIPアドレスがPLDM応答の受信者として機能することを期待しているシステムをアドレス指定していることを確認する必要があります。

There is no additional exposure of information to pervasive monitoring systems observing LSPs that are being monitored.

監視されているLSPを監視する広範な監視システムに情報がさらに公開されることはありません。

8. IANA Considerations

8. IANAに関する考慮事項

IANA has assigned a new optional TLV type from the "MPLS Loss/Delay Measurement TLV Object" registry contained within the "Generic Associated Channel (G-ACh) Parameters" registry set:

IANAは、「Generic Associated Channel（G-ACh）Parameters」レジストリセットに含まれる「MPLS Loss/Delay Measurement TLV Object」レジストリから新しいオプションのTLVタイプを割り当てました。

      Code         Description        Reference
       131         UDP Return         [RFC7876]

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.

[RFC768] Postel, J.、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487/RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner, S.、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。

[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <http://www.rfc-editor.org/info/rfc3945>.

[RFC3945] Mannie, E., Ed.、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、RFC 3945、DOI 10.17487/RFC3945、2004年10月、<http://www.rfc-editor.org/info/rfc3945>。

[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.

[RFC5405] Eggert, L. and G. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、DOI 10.17487/RFC5405、2008年11月、<http://www.rfc-editor.org/info/rfc5405>。

[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <http://www.rfc-editor.org/info/rfc5586>.

[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel"、RFC 5586、DOI 10.17487/RFC5586、June 2009、<http://www.rfc-editor.org/info/rfc5586>。

[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, <http://www.rfc-editor.org/info/rfc5654>.

[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile"、RFC 5654 、DOI 10.17487/RFC5654、2009年9月、<http://www.rfc-editor.org/info/rfc5654>。

[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <http://www.rfc-editor.org/info/rfc6374>.

[RFC6374] Frost, D. and S. Bryant、「MPLSネットワークのパケット損失と遅延測定」、RFC 6374、DOI 10.17487/RFC6374、2011年9月、<http://www.rfc-editor.org/info/rfc6374>。

9.2. Informative References

9.2. 参考引用

[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, <http://www.rfc-editor.org/info/rfc5921>.

[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks"、RFC 5921、 DOI 10.17487/RFC5921、2010年7月、<http://www.rfc-editor.org/info/rfc5921>。

Acknowledgements

謝辞

We acknowledge the contributions of Joseph Chin and Rakesh Gandhi, both with Cisco Systems. We thank Loa Andersson, Eric Osborne, Mustapha Aissaoui, Jeffrey Zhang, and Ross Callon for their review comments.

シスコシステムズの両方で、Joseph ChinとRakesh Gandhiの貢献を認めます。 Loa Andersson、Eric Osborne、Mustapha Aissaoui、Jeffrey Zhang、Ross Callonのレビューコメントに感謝します。

We thank all who have reviewed this text and provided feedback.

このテキストを確認してフィードバックを提供してくださったすべての方に感謝いたします。

Authors' Addresses

著者のアドレス

Stewart Bryant Independent

スチュワートブライアントインディペンデント

   Email: stewart.bryant@gmail.com

Siva Sivabalan Cisco Systems

Shiva Sivabalan Cisco Systems

   Email: msiva@cisco.com

Sagar Soni Cisco Systems

さがｒそにしｓこＳｙｓてｍｓ

   Email: sagsoni@cisco.com