RFC 7896 - Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7896
タイトル : RFC 7896 - パス計算要素通信プロトコル（PCEP）のインクルードルートオブジェクト（IRO）仕様の更新
翻訳編集 : 自動生成

[要約] RFC 7896は、PCEPのInclude Route Object（IRO）仕様の更新を提供しています。このRFCの目的は、PCEPメッセージ内のIROの使用を改善し、ネットワークパス計算の効率を向上させることです。

Internet Engineering Task Force (IETF)                          D. Dhody
Request for Comments: 7896                           Huawei Technologies
Updates: 5440                                                  June 2016
Category: Standards Track
ISSN: 2070-1721

Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)

パス計算要素通信プロトコル（PCEP）のインクルードルートオブジェクト（IRO）仕様の更新

Abstract

概要

The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. RFC 5440 defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO contains an ordered or unordered list of subobjects. During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability. It was also noted that there is a benefit in the handling of an attribute of the IRO's subobject, the L bit.

パス計算要素通信プロトコル（PCEP）は、パス計算クライアント（PCC）とPCEの間、または2つのPCE間の通信を可能にします。 RFC 5440は、ルートオブジェクトを含める（IRO）を定義して、計算されたパスを通過するネットワーク要素を指定します。この仕様では、IROにサブオブジェクトの順序付きリストまたは順序なしリストが含まれているかどうかは指定されていません。最近の議論の中で、相互運用性を確保するために標準的な表現を定義する必要があると判断されました。また、IROのサブオブジェクトの属性であるLビットを処理することには利点があることにも注意してください。

This document updates RFC 5440 regarding the IRO specification.

このドキュメントは、IRO仕様に関するRFC 5440を更新します。

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/rfc7896.

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

著作権表示

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に記載されているように保証なしで提供されます。

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標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Update in the IRO Specification . . . . . . . . . . . . . . .   3
     2.1.  Update to RFC 5440  . . . . . . . . . . . . . . . . . . .   3
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1. Introduction

1. はじめに

The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. [RFC5440] defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO is an ordered or unordered list of subobjects. In addition, it defines the L bit as having no meaning within an IRO.

パス計算要素通信プロトコル（PCEP）は、パス計算クライアント（PCC）とPCEの間、または2つのPCE間の通信を可能にします。 [RFC5440]は、ルートオブジェクトを含める（IRO）を定義して、計算されたパスを通過するネットワーク要素を指定します。仕様では、IROがサブオブジェクトの順序付きリストか順序なしリストかを指定していません。また、LビットはIRO内では意味がないものとして定義されています。

[RFC5441] describes the use of an IRO to indicate the sequence of domains to be traversed during inter-domain path computation.

[RFC5441]は、ドメイン間パスの計算中にトラバースされるドメインのシーケンスを示すためのIROの使用について説明しています。

During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability.

最近の議論の中で、相互運用性を確保するために標準的な表現を定義する必要があると判断されました。

This document updates the IRO specifications in Section 7.12 of [RFC5440].

このドキュメントは、[RFC5440]のセクション7.12のIRO仕様を更新します。

2. Update in the IRO Specification

2. IRO仕様の更新

Section 7.12 of [RFC5440] describes the IRO as an optional object used to specify a set of network elements to be traversed in the computed path. It states that the L bit in the subobject has no meaning within an IRO. It does not mention if the IRO contains an ordered or unordered list of subobjects.

[RFC5440]のセクション7.12では、計算されたパスを通過するネットワーク要素のセットを指定するために使用されるオプションのオブジェクトとしてIROについて説明しています。サブオブジェクトのLビットはIRO内では意味がないと述べています。 IROにサブオブジェクトの順序付きまたは順序なしのリストが含まれているかどうかについては触れられていません。

2.1. Update to RFC 5440

2.1. RFC 5440への更新

The IRO specification is updated to remove the last line in the Section 7.12 of [RFC5440], which states:

IRO仕様が更新され、[RFC5440]のセクション7.12の最後の行が削除されます。

"The L bit of such sub-object has no meaning within an IRO."

「そのようなサブオブジェクトのLビットは、IRO内では意味がありません。」

Further, Section 7.12 of [RFC5440] is updated to add the following two statements at the end of the first paragraph.

さらに、[RFC5440]のセクション7.12が更新され、最初の段落の終わりに次の2つのステートメントが追加されます。

- The content of an IRO is an ordered list of subobjects representing a series of abstract nodes (refer to Section 4.3.2 of [RFC3209]).

- IROのコンテンツは、一連の抽象ノードを表すサブオブジェクトの順序付きリストです（[RFC3209]のセクション4.3.2を参照）。

- The L bit of an IRO subobject is set based on the loose or strict hop property of the subobject; it is set if the subobject represents a loose hop. If the bit is not set, the subobject represents a strict hop. The interpretation of the L bit is as per Section 4.3.3.1 of [RFC3209].

- IROサブオブジェクトのLビットは、サブオブジェクトのルーズまたはストリクトホッププロパティに基づいて設定されます。サブオブジェクトがルーズホップを表す場合に設定されます。ビットが設定されていない場合、サブオブジェクトは厳密なホップを表します。 Lビットの解釈は、[RFC3209]のセクション4.3.3.1のとおりです。

3. Operational Considerations

3. 運用上の考慮事項

Because of the lack of clarity in [RFC5440], it is possible to encounter implementations that always interpret the IRO subobjects as loose. When these implementations interwork with an implementation conforming to this document, the following impact might be seen:

[RFC5440]には明確さが欠けているため、常にIROサブオブジェクトをルーズとして解釈する実装に遭遇する可能性があります。これらの実装がこのドキュメントに準拠した実装と相互作用する場合、次の影響が見られる可能性があります。

o If a non-conforming (to this document) PCC sends an IRO to a conforming (to this document) PCE, then the PCE may unexpectedly fail to find a path (since the PCC may think of the IRO subobjects as loose hops, but the PCE interprets them as strict hops).

o （このドキュメントに対して）不適合のPCCがIROを（このドキュメントに対して）適合しているPCEに送信すると、PCEは予期せずパスを見つけられない可能性があります（PCCはIROサブオブジェクトをルーズホップと見なすため、 PCEはそれらを厳密なホップとして解釈します。

o If a conforming PCC sends an IRO containing strict hops to a non-conforming PCE, then the PCE may erroneously return a path that does not comply with the requested strict hops (since the PCE interprets them all as loose hops). The PCC may check the returned path and find the issue, or it may end up using an incorrect path.

o 適合PCCが厳密ホップを含むIROを非適合PCEに送信すると、PCEは要求された厳密ホップに準拠しないパスを誤って返す可能性があります（PCEがそれらをすべてルーズホップと解釈するため）。 PCCは、返されたパスをチェックして問題を見つけるか、誤ったパスを使用する可能性があります。

4. Security Considerations

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

This update in the IRO specification does not introduce any new security considerations, apart from those mentioned in [RFC5440]. Clarification in the supported IRO ordering or Loose hop bit handling will not have any negative security impact.

IRO仕様のこの更新では、[RFC5440]で言及されているものを除いて、新しいセキュリティ上の考慮事項は導入されていません。サポートされているIRO順序またはルーズホップビット処理の説明は、セキュリティに悪影響を及ぼしません。

It is worth noting that PCEP operates over TCP. An analysis of the security issues for routing protocols that use TCP (including PCEP) is provided in [RFC6952].

PCEPがTCP上で動作することは注目に値します。 TCP（PCEPを含む）を使用するルーティングプロトコルのセキュリティ問題の分析は、[RFC6952]で提供されています。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.

[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。

[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.

[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux、編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<http://www.rfc-editor.org/info/rfc5440>。

5.2. Informative References

5.2. 参考引用

[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, DOI 10.17487/RFC5441, April 2009, <http://www.rfc-editor.org/info/rfc5441>.

[RFC5441] Vasseur、JP。、Ed。、Zhang、R.、Bitar、N.、and JL。 Le Roux、「最短の制約付きドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、DOI 10.17487 / RFC5441、2009年4月、<http：//www.rfc- editor.org/info/rfc5441>。

[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.

[RFC6952] Jethanandani、M.、Patel、K。、およびL. Zheng、「ルーティングプロトコルのキーイングおよび認証（KARP）設計ガイドによるBGP、LDP、PCEP、およびMSDPの問題の分析」、RFC 6952、DOI 10.17487 / RFC6952、2013年5月、<http://www.rfc-editor.org/info/rfc6952>。

Acknowledgments

謝辞

A special thanks to the PCE chairs for guidance regarding this work.

この作業に関するガイダンスを提供してくれたPCE議長に特に感謝します。

Thanks to Francesco Fondelli for his suggestions in clarifying the L bit usage.

Lビットの使用法を明確にするための提案をしてくれたFrancesco Fondelliに感謝します。

Thanks to Adrian Farrel for his review and comments.

Adrian Farrelのレビューとコメントに感謝します。

Thanks to Jonathan Hardwick for shepherding the document and providing text in Section 3.

文書をシェファーディングし、セクション3でテキストを提供してくれたJonathan Hardwickに感謝します。

Thanks to Deborah Brungard for her comments and being the responsible AD.

彼女のコメントと責任あるADであるDeborah Brungardに感謝します。

Thanks to Peter Yee for the Gen-ART review.

Gen-ARTレビューをしてくれたPeter Yeeに感謝します。

Thanks to Alvaro Retana for comments during the IESG review.

IESGレビュー中のコメントについては、Alvaro Retanaに感謝します。

Author's Address

著者のアドレス

Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India

Dhruv Dhodai Huawei Technologies Divyashari Techno Park、Wheatfished Bangalore、Karnataka 2008インド

   Email: dhruv.ietf@gmail.com