RFC 6510 - Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6510
タイトル : RFC 6510 - リソース予約プロトコル（RSVP）ラベルスイッチパス（LSP）属性オブジェクトのメッセージ形式
翻訳編集 : 自動生成

[要約] RFC 6510は、ラベルスイッチパス（LSP）属性オブジェクトのためのResource Reservation Protocol（RSVP）メッセージフォーマットに関するものです。このRFCの目的は、LSP属性オブジェクトのメッセージフォーマットを定義し、RSVPプロトコルを使用してLSPの予約と制御を行うためのガイドラインを提供することです。

Internet Engineering Task Force (IETF)                         L. Berger
Request for Comments: 6510                                          LabN
Updates: 4875, 5420                                           G. Swallow
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                            February 2012

Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects

リソース予約プロトコル（RSVP）ラベルスイッチパス（LSP）属性オブジェクトのメッセージ形式

Abstract

概要

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP-specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420.

マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチ付きパス（LSP）リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）エクステンションは、LSP固有の属性のセットで信号を送信できます。これらの属性は、PATHメッセージとRESVメッセージの両方に携帯される場合があります。このドキュメントは、ルーティングバックスNAURフォームを使用してRSVPパスおよびRESVメッセージでLSP属性をどのように携帯するかを指定し、関連するRESVメッセージ形式を明確にします。このドキュメントは、RFC 4875およびRFC 5420を更新します。

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

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6510で取得できます。

著作権表示

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

このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントは必須です

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.

セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、簡素化されたBSDライセンスに記載されている保証なしで提供される簡略化されたBSDライセンステキストを含めます。

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. Path Messages ...................................................3
      2.1. Path Message Format ........................................3
   3. Resv Messages ...................................................4
      3.1. Resv Message Format -- Per LSP Operational Status ..........5
      3.2. Resv Message Format -- Per S2L Operational Status ..........6
           3.2.1. Compatibility .......................................6
   4. Security Considerations .........................................6
   5. Acknowledgments .................................................7
   6. References ......................................................7
      6.1. Normative References .......................................7
      6.2. Informative References .....................................7

1. Introduction

1. はじめに

Signaling in support of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Label Switched Paths (LSPs) is defined in [RFC3209] and [RFC3473]. [RFC4875] defines signaling support for point-to-multipoint (P2MP) Traffic Engineering (TE) LSPs.

マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）ポイントラベルスイッチングパス（LSP）をサポートするシグナル伝達は、[RFC3209]および[RFC3473]で定義されています。[RFC4875]は、ポイントツーマルチポイント（P2MP）トラフィックエンジニアリング（TE）LSPのシグナリングサポートを定義します。

Two LSP Attributes objects are defined in [RFC5420]. These objects may be used to provide additional information related to how an LSP should be set up when carried in a Path message and, when carried in a Resv message, how an LSP has been established. The definition of the objects includes a narrative description of related message formats (see Section 9 of [RFC5420]). This definition does not provide the related Routing Backus-Naur Form (BNF) [RFC5511] that is typically used to define how messages are to be constructed using RSVP objects. The current message format description has led to the open question of how the LSP Attributes objects are to be processed in Resv messages of P2MP LSPs (which are defined in [RFC4875]).

2つのLSP属性オブジェクトは[RFC5420]で定義されています。これらのオブジェクトは、パスメッセージに携帯するときにLSPをセットアップする方法、およびRESVメッセージに携帯する場合、LSPがどのように確立されているかに関連する追加情報を提供するために使用できます。オブジェクトの定義には、関連するメッセージ形式の物語の説明が含まれています（[RFC5420]のセクション9を参照）。この定義は、通常、RSVPオブジェクトを使用してメッセージの構築方法を定義するために使用される関連するルーティングバックナウルフォーム（BNF）[RFC5511]を提供しません。現在のメッセージ形式の説明により、LSP属性オブジェクトがP2MP LSPのRESVメッセージ（[RFC4875]で定義されている）でどのように処理されるかについての未解決の問題が発生しました。

This document provides the BNF for Path and Resv messages carrying the LSP Attributes object. The definition clarifies how the objects are to be carried for all LSP types. Both Path and Resv message BNF is provided for completeness.

このドキュメントは、LSP属性オブジェクトを運ぶPATHおよびRESVメッセージのBNFを提供します。定義は、すべてのLSPタイプに対してオブジェクトがどのように運ばれるかを明確にします。PATHとRESVメッセージBNFの両方が完全性のために提供されます。

This document presents the related RSVP message formats as modified by [RFC5420]. This document modifies formats defined in [RFC3209], [RFC3473], and [RFC4875]. See [RFC5511] for the syntax used by RSVP. Unmodified formats are not listed. An example of a case where the modified formats are applicable is described in [RFC6511].

このドキュメントでは、[RFC5420]によって変更された関連RSVPメッセージ形式を提示します。このドキュメントは、[RFC3209]、[RFC3473]、および[RFC4875]で定義されている形式を変更します。RSVPで使用される構文については、[RFC5511]を参照してください。変更されていない形式はリストされていません。修正された形式が適用可能な場合の例は、[RFC6511]で説明されています。

1.1. Conventions Used in This Document

1.1. このドキュメントで使用されている規則

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

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

2. Path Messages

2. パスメッセージ

This section updates [RFC4875]. Path message formatting is unmodified from the narrative description provided in Section 9 of [RFC5420]:

このセクションは[RFC4875]を更新します。パスメッセージのフォーマットは、[RFC5420]のセクション9に記載されている物語の説明から修正されていません。

      The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object
      MAY be carried in a Path message....

The order of objects in RSVP-TE messages is recommended, but implementations must be capable of receiving the objects in any meaningful order.

RSVP-TEメッセージのオブジェクトの順序が推奨されますが、実装は意味のある順序でオブジェクトを受信できる必要があります。

On a Path message, the LSP_ATTRIBUTES object and LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed immediately after the SESSION_ATTRIBUTE object if it is present, or otherwise immediately after the LABEL_REQUEST object.

パスメッセージでは、lsp_attributesオブジェクトとlsp_required_attributesオブジェクトは、存在する場合、またはlabel_requestオブジェクトの直後にsession_attributeオブジェクトの直後に配置することをお勧めします。

If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED to be placed first.

lsp_attributesオブジェクトとlsp_required_attributesオブジェクトの両方が存在する場合、lsp_required_attributesオブジェクトを最初に配置することをお勧めします。

LSRs MUST be prepared to receive these objects in any order in any position within a Path message. Subsequent instances of these objects within a Path message SHOULD be ignored and MUST be forwarded unchanged.

LSRは、パスメッセージ内の任意の位置でこれらのオブジェクトを任意の順序で受信する準備をする必要があります。パスメッセージ内のこれらのオブジェクトの後続のインスタンスは無視する必要があり、変更されずに転送する必要があります。

2.1. Path Message Format

2.1. パスメッセージ形式

This section presents the Path message format as modified by [RFC5420]. Unmodified formats are not listed.

このセクションでは、[RFC5420]によって変更されたパスメッセージ形式を示します。変更されていない形式はリストされていません。

   <Path Message> ::=     <Common Header> [ <INTEGRITY> ]
                          [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
                          [ <MESSAGE_ID> ]
                          <SESSION> <RSVP_HOP>

                          <TIME_VALUES>
                          [ <EXPLICIT_ROUTE> ]
                          <LABEL_REQUEST>
                          [ <PROTECTION> ]
                          [ <LABEL_SET> ... ]
                          [ <SESSION_ATTRIBUTE> ]
                          [ <LSP_REQUIRED_ATTRIBUTES> ... ]
                          [ <LSP_ATTRIBUTES> ... ]
                          [ <NOTIFY_REQUEST> ]
                          [ <ADMIN_STATUS> ]
                          [ <POLICY_DATA> ... ]
                          <sender descriptor>
                          [<S2L sub-LSP descriptor list>]

Note that PathErr and PathTear messages are not impacted by the introduction of the LSP Attributes objects.

PatherrおよびPathtearメッセージは、LSP属性オブジェクトの導入によって影響を受けないことに注意してください。

3. Resv Messages

3. RESVメッセージ

This section updates [RFC4875] and [RFC5420]. Section 9 of [RFC5420] contains the following text regarding Resv messages:

このセクションは[RFC4875]および[RFC5420]を更新します。[RFC5420]のセクション9には、RESVメッセージに関する次のテキストが含まれています。

The LSP_ATTRIBUTES object MAY be carried in a Resv message.

LSP_ATTRIBUTESオブジェクトは、RESVメッセージに携帯することができます。

The order of objects in RSVP-TE messages is recommended, but implementations must be capable of receiving the objects in any meaningful order.

RSVP-TEメッセージのオブジェクトの順序が推奨されますが、実装は意味のある順序でオブジェクトを受信できる必要があります。

...

On a Resv message, the LSP_ATTRIBUTES object is placed in the flow descriptor and is associated with the FILTER_SPEC object that precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be placed immediately after the LABEL object.

RESVメッセージでは、lsp_attributesオブジェクトはフロー記述子に配置され、その先行するfilter_specオブジェクトに関連付けられています。lsp_attributesオブジェクトは、ラベルオブジェクトの直後に配置することをお勧めします。

LSRs MUST be prepared to receive this object in any order in any position within a Resv message, subject to the previous note. Only one instance of the LSP_ATTRIBUTES object is meaningful within the context of a FILTER_SPEC object. Subsequent instances of the object SHOULD be ignored and MUST be forwarded unchanged.

LSRは、以前のメモに従って、RESVメッセージ内の任意の位置でこのオブジェクトを任意の順序で受信する準備をする必要があります。LSP_ATTRIBUTESオブジェクトのインスタンスは、Filter_Specオブジェクトのコンテキスト内で意味があります。オブジェクトの後続のインスタンスは無視する必要があり、変化しないように転送する必要があります。

This means that LSP attributes may be present per sender (LSP) and allows for the LSP Attributes object to be modified using make-before-break (see [RFC3209]). This definition is sufficient for point-to-point ([RFC3209] and [RFC3473]) LSPs and the special case where all point-to-multipoint source-to-leaf (S2L) sub-LSPs ([RFC4875]) report the same operational status (as used in [RFC5420]). However, this definition does not allow for different

これは、LSP属性が送信者（LSP）ごとに存在する可能性があり、LSP属性オブジェクトをMake-Be-Breakを使用して変更できることを意味します（[RFC3209]を参照）。この定義は、ポイントツーポイント（[RFC3209]および[RFC3473]）LSPSおよびすべてのポイントツーマルチポイントソース（S2L）サブLSP（[RFC4875]）が同じことを報告する特別なケースに十分です。運用ステータス（[RFC5420]で使用される）。ただし、この定義では異なることはできません

egress Label Switching Routers (LSRs) to report different operational statuses. In order to allow such reporting, this document adds the following definition:

出力ラベルスイッチングルーター（LSR）は、さまざまな動作ステータスを報告します。このようなレポートを許可するために、このドキュメントは次の定義を追加します。

An LSR that wishes to report the operational status of a (point-to-multipoint) S2L sub-LSP may include the LSP Attributes object in a Resv message or update the object that is already carried in a Resv message. LSP Attributes objects representing S2L sub-LSP status MUST follow a S2L_SUB_LSP object. Only the first instance of the LSP Attributes object is meaningful within the context of a S2L_SUB_LSP object. Subsequent instances of the object SHOULD be ignored and MUST be forwarded unchanged.

（Point-to-MultiPoint）S2L Sub-LSPの動作ステータスを報告したいLSRには、resvメッセージにLSP属性オブジェクトを含めるか、resvメッセージに既に運ばれているオブジェクトを更新することができます。S2LサブLSPステータスを表すLSP属性オブジェクトは、S2L_SUB_LSPオブジェクトに従う必要があります。LSP属性オブジェクトの最初のインスタンスのみが、S2L_SUB_LSPオブジェクトのコンテキスト内で意味があります。オブジェクトの後続のインスタンスは無視する必要があり、変化しないように転送する必要があります。

When an LSP Attributes object is present before the first S2L_SUB_LSP object, the LSP Attributes object represents the operational status of all S2L sub-LSPs identified in the message. Subsequent instances of the object (e.g., in the filter spec or the S2L sub-LSP flow descriptor) SHOULD be ignored and MUST be forwarded unchanged. When a branch node is combining Resv state from multiple receivers into a single Resv message and an LSP Attributes object is present before the first S2L_SUB_LSP object in a received Resv message, the received LSP Attributes object SHOULD be moved to follow the first received S2L_SUB_LSP object and then SHOULD be duplicated for, and placed after, each subsequent S2L_SUB_LSP object.

LSP属性オブジェクトが最初のS2L_SUB_LSPオブジェクトの前に存在する場合、LSP属性オブジェクトは、メッセージで識別されるすべてのS2LサブLSPの動作ステータスを表します。オブジェクトの後続のインスタンス（たとえば、フィルター仕様またはS2LサブLSPフロー記述子）は無視する必要があり、変更されていません。Branchノードが複数の受信機からRESV状態を単一のRESVメッセージに組み合わせている場合、受信したRESVメッセージの最初のS2L_SUB_LSPオブジェクトの前にLSP属性オブジェクトが存在する場合、受信したLSP属性オブジェクトは、最初の受信したS2L_SUB_LSPオブジェクトに従って移動する必要があります。次に、後続の各S2L_SUB_LSPオブジェクトのために複製し、その後配置する必要があります。

3.1. Resv Message Format -- Per LSP Operational Status

3.1. RESVメッセージフォーマット-LSPの動作ステータスごと

This section presents the Resv message format for LSPs as modified by [RFC5420] and can be used to report operational status per LSP. Unmodified formats are not listed. The following is based on [RFC4875].

このセクションでは、[RFC5420]によって変更されたLSPのRESVメッセージ形式を示し、LSPごとの動作ステータスを報告するために使用できます。変更されていない形式はリストされていません。以下は[RFC4875]に基づいています。

   <FF flow descriptor list> ::= <FF flow descriptor>
                                 [ <FF flow descriptor list> ]

   <FF flow descriptor>      ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                                 [ <LSP_ATTRIBUTES> ... ]
                                 [ <RECORD_ROUTE> ]
                                 [ <S2L sub-LSP flow descriptor list> ]

   <SE flow descriptor>      ::= <FLOWSPEC> <SE filter spec list>

   <SE filter spec list>     ::= <SE filter spec>
                                 [ <SE filter spec list> ]

   <SE filter spec>          ::= <FILTER_SPEC> <LABEL>
                                 [ <LSP_ATTRIBUTES> ... ]
                                 [ <RECORD_ROUTE> ]
                                 [ <S2L sub-LSP flow descriptor list> ]

3.2. Resv Message Format -- Per S2L Operational Status

3.2. RESVメッセージフォーマット-S2L運用ステータスごと

This section presents the Resv message format for LSPs as modified by this document and [RFC5420], and can be used to report operational status per S2L sub-LSP. Unmodified formats are not listed. The following is based on [RFC4875].

このセクションでは、このドキュメントと[RFC5420]によって変更されたLSPのRESVメッセージ形式を示し、S2LサブLSPごとの動作ステータスを報告するために使用できます。変更されていない形式はリストされていません。以下は[RFC4875]に基づいています。

   <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                            [ <RECORD_ROUTE> ]
                            [ <S2L sub-LSP flow descriptor list> ]

   <SE filter spec>     ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
                            [ <S2L sub-LSP flow descriptor list> ]

   <S2L sub-LSP flow descriptor list> ::=
                               <S2L sub-LSP flow descriptor>
                               [ <S2L sub-LSP flow descriptor list> ]

   <S2L sub-LSP flow descriptor>      ::= <S2L_SUB_LSP>
                               [ <LSP_ATTRIBUTES> ... ]
                               [ <P2MP_SECONDARY_RECORD_ROUTE> ]

3.2.1. Compatibility

3.2.1. 互換性

A node that supports [RFC4875] and [RFC5420], but not this document, will interpret the first LSP Attributes object present in a received message, which is formatted as described in this document, as representing LSP operational status rather than S2L sub-LSP status. It is unclear if this is a significant issue as the LSP Attributes object is currently considered to be an unsuitable mechanism for reporting operational status of P2MP LSPs, for example, see Section 2.1 of [RFC6511]. The intent of this document is to correct this limitation; it is expected that networks that wish to make use of such operational reporting will deploy this extension.

[RFC4875]および[RFC5420]をサポートするノードは、このドキュメントではなく、このドキュメントに記載されているようにフォーマットされた受信メッセージに存在する最初のLSP属性オブジェクトを解釈します。状態。LSP属性オブジェクトは現在、P2MP LSPの運用状態を報告するのに適さないメカニズムであると考えられているため、これが重要な問題であるかどうかは不明です。たとえば、[RFC6511]のセクション2.1を参照してください。このドキュメントの意図は、この制限を修正することです。このような運用レポートを利用したいネットワークがこの拡張機能を展開することが期待されています。

4. Security Considerations

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

This document clarifies usage of objects defined in [RFC5420]. No new information is conveyed; therefore, no additional security considerations are included here. For a general discussion on MPLS-and GMPLS-related security issues, see the MPLS/GMPLS security framework [RFC5920].

このドキュメントでは、[RFC5420]で定義されているオブジェクトの使用法が明確になります。新しい情報は伝えられません。したがって、ここには追加のセキュリティ上の考慮事項は含まれていません。MPLSおよびGMPLS関連のセキュリティ問題に関する一般的な議論については、MPLS/GMPLSセキュリティフレームワーク[RFC5920]を参照してください。

5. Acknowledgments

5. 謝辞

The authors would like to acknowledge the contributions of Adrian Farrel.

著者は、エイドリアン・ファレルの貢献を認めたいと考えています。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[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月。

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。

[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。

[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月。

[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.

[RFC5420] Farrel、A.、ed。、ed。、Papadimitriou、D.、Vasseur、Jp。、およびA. Ayyangarps、「リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）を使用したMPLS LSP確立の属性のエンコード」、RFC 5420、2009年2月。

[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.

[RFC5511] Farrel、A。、「ルーティングバックスノーフォーム（RBNF）：さまざまなルーティングプロトコル仕様でエンコードルールを形成するために使用される構文」、RFC 5511、2009年4月。

6.2. Informative References

6.2. 参考引用

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.

[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。

[RFC6511] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths", RFC 6511, February 2012.

[RFC6511] Ali、Z.、Swallow、G。、およびR. Aggarwal、「RSVP-TEラベルの切り替えパスの非ペニルなホップポップ動作とバンド外マッピング」、RFC 6511、2012年2月。

Authors' Addresses

著者のアドレス

Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net

Lou Berger Labn Consulting、L.L.C。電話：1-301-468-9228メール：lberger@labn.net

George Swallow Cisco Systems, Inc. EMail: swallow@cisco.com

George Swallow Cisco Systems、Inc。メール：swallow@cisco.com