Network Working Group A. Farrel, Ed.
Request for Comments: 5420 Old Dog Consulting
Obsoletes: 4420 D. Papadimitriou
Updates: 3209, 3473 Alcatel
Category: Standards Track JP. Vasseur
Cisco Systems, Inc.
A. Ayyangar
Juniper Networks
February 2009
Encoding of Attributes for MPLS LSP Establishment Using
Resource Reservation Protocol Traffic Engineering (RSVP-TE)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.
マルチプロトコルラベルは（MPLS）ラベルは、リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）の拡張機能を使用して確立することができるスイッチパス（LSP）切り替えを行います。このプロトコルは、オプションとLSPの属性を示すために使用されるフラグフィールドを運ぶオブジェクト（SESSION_ATTRIBUTEオブジェクト）を含みます。 Flagsフィールドは、8つのオプションを可能に8ビットを、持っていることを設定します。 RSVP-TEを拡張する多くのドキュメントの最近の提案は、以前に未使用のビットのそれぞれの用途を示唆しています。
This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.
この文書は、さらに、属性ビットと、任意の属性パラメータのキャリッジのシグナリングは、新しい要件をサポートするRSVP-TEは、容易に拡張することを可能にするRSVP-TEメッセージのための新しいオブジェクトを定義します。また、この文書では、ホップバイホップ毎にLSPに適用される属性を記録する方法を定義します。
The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs.
この文書で定義されたオブジェクトのメカニズムは、一般MPLS（GMPLS）パケットができる（PSC）LSPを切り替えて非PSC LSPをGMPLSするためにも同様に適用可能です。
This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures.
この文書では、唯一の変化はなType-Length-変数（TLV）のデータ構造のエンコーディングであるRFC 4420として発行され、この作品の前のバージョンを置き換え、廃止します。
Table of Contents
目次
1. Introduction and Problem Statement ..............................4
1.1. Applicability to Generalized MPLS ..........................5
1.2. A Rejected Alternate Solution ..............................5
2. Terminology .....................................................6
3. Attributes TLVs .................................................6
3.1. Attribute Flags TLV ........................................7
4. LSP_ATTRIBUTES Object ...........................................8
4.1. Format .....................................................9
4.2. Generic Processing Rules for Path Messages .................9
4.3. Generic Processing Rules for Resv Messages .................9
5. LSP_REQUIRED_ATTRIBUTES Object .................................10
5.1. Format ....................................................11
5.2. Generic Processing Rules ..................................11
6. Inheritance Rules ..............................................11
7. Recording Attributes Per LSP ...................................12
7.1. Requirements ..............................................12
7.2. RRO Attributes Subobject ..................................12
7.3. Procedures ................................................13
7.3.1. Subobject Presence Rules ...........................13
7.3.2. Reporting Compliance with LSP Attributes ...........14
7.3.3. Reporting Per-Hop Attributes .......................14
7.3.4. Default Behavior ...................................14
8. Summary of Attribute Bit Allocation ............................14
9. Message Formats ................................................15
10. Guidance for Key Application Scenarios ........................16
10.1. Communicating to Egress LSRs .............................16
10.2. Communicating to Key Transit LSRs ........................17
10.3. Communicating to All LSRs ................................17
11. IANA Considerations ...........................................17
11.1. New RSVP C-Nums and C-Types ..............................17
11.2. New TLV Space ............................................18
11.3. Attribute Flags ..........................................19
11.4. New Error Codes ..........................................19
11.5. New Record Route Subobject Identifier ....................19
12. Security Considerations .......................................20
13. Acknowledgements ..............................................20
14. Changes from RFC 4420 to RFC 5420 .............................20
15. Normative References ..........................................21
16. Informative References ........................................21
This document replaces and obsoletes the previous version of this work, published as RFC 4420 [RFC4420]. The only change is in the encoding of the Type-Length-Variable (TLV) data structures presented in Section 3. See Section 14 for a summary of changes.
この文書は、RFC 4420 [RFC4420]として発行され、この作品の前のバージョンを置き換え、廃止します。唯一の変更は、変更点の概要については、第3節を参照してください14で提示さなType-Length-変数（TLV）のデータ構造のエンコーディングです。
Traffic-Engineered Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) [RFC3031] may be set up using the Path message of the RSVP-TE signaling protocol [RFC3209]. The Path message includes the SESSION_ATTRIBUTE object, which carries a Flags field used to indicate desired options and attributes of the LSP.
トラフィックエンジニアマルチは、ラベルスイッチング（MPLS）ラベルスイッチパス（LSPは）[RFC3031]はRSVP-TEシグナリングプロトコル[RFC3209]のPathメッセージを使用して設定することができます。 Pathメッセージは、所望のオプションとLSPの属性を示すために使用されるフラグフィールドを運ぶSESSION_ATTRIBUTEオブジェクトを含みます。
The Flags field in the SESSION_ATTRIBUTE object has eight bits. Just three of those bits are assigned in [RFC3209]. A further two bits are assigned in [RFC4090] for fast re-reroute functionality, leaving only three bits available. Several recent proposals and Internet Drafts have demonstrated that there is a high demand for the use of the other three bits. Some, if not all, of those proposals are likely to go forward as RFCs, resulting in depletion or near depletion of the Flags field and a consequent difficulty in signaling new options and attributes that may be developed in the future.
SESSION_ATTRIBUTEオブジェクト内のFlagsフィールドは8ビットです。ちょうどこれらのビットの3つが[RFC3209]に割り当てられています。さらに2つのビットは、利用可能な3ビットのみを残して、高速再リルート機能のために[RFC4090]に割り当てられています。最近のいくつかの提案やインターネットドラフトは、他の3ビットを使用するための高い需要があることが実証されています。これらの提案のいくつかは、すべてではない場合は、枯渇またはFlagsフィールドの近くに枯渇し、将来的に開発することができる新しいオプションと属性のシグナリングの必然的困難になる、RFCとして前進する可能性があります。
This document defines a new object for RSVP-TE messages that allows the signaling of further attributes bits. The new object is constructed from TLVs, and a new TLV is defined to carry a variable number of attributes bits.
この文書は、さらに、属性ビットのシグナリングを可能にするRSVP-TEメッセージのための新しいオブジェクトを定義します。新しいオブジェクトがのTLVから構成され、そして新たなTLVは、属性ビットの可変数を運ぶために定義されています。
The new RSVP-TE message object is quite flexible, due to the use of the TLV format and allows:
新しいRSVP-TEメッセージオブジェクトは、TLV形式の使用による、非常にフレキシブルであり、できます。
- future specification of bit flags - additional options and attribute parameters carried in TLV format
- ビットフラグの将来の仕様 - TLV形式で運ば追加のオプションや属性パラメータ
Note that the LSP Attributes defined in this document are specifically scoped to an LSP. They may be set differently on separate LSPs with the same Tunnel ID between the same source and destination (that is, within the same session).
LSPは、特にLSPにスコープされ、この文書で定義された属性ことに留意されたいです。それらは、同じ送信元と宛先の間で同一のトンネルIDを持つ別のLSP（すなわち、同じセッション内である）上で異なるように設定してもよいです。
It is noted that some options and attributes do not need to be acted on by all Label Switched Routers (LSRs) along the path of the LSP. In particular, these options and attributes may apply only to key LSRs on the path, such as the ingress LSR and egress LSR. Special transit LSRs, such as Area or Autonomous System Border Routers (ABRs or ASBRs), may also fall into this category. This means that the new options and attributes should be signaled transparently, and only examined at those points that need to act on them.
いくつかのオプションと属性はLSPの経路に沿ったルータ（LSRのを）スイッチ、すべてのラベルが作用する必要はないことに留意されます。具体的には、これらのオプションと属性は、このような入口LSRと出口LSRとしてパス上のキーのLSRに適用される場合があります。このような領域または自律システム境界ルータ（のABRまたはASBRは）、などの特別なトランジットのLSRは、また、このカテゴリーに入ることがあります。これは、新しいオプションと属性が透過的合図、およびそれらのみに基づいて行動する必要があり、これらのポイントで検証されなければならないことを意味しています。
On the other hand, other options and attributes may require action at all transit LSRs along the path of the LSP. Inability to support the required attributes by one of those transit LSRs may require the LSR to refuse the establishment of the LSP.
一方、他のオプションと属性はLSPのパスに沿ってすべてのトランジットのLSRでのアクションが必要な場合があります。これらのトランジットのLSRのいずれかによって必要な属性をサポートできないことは、LSPの確立を拒否するLSRが必要な場合があります。
These considerations are particularly important in the context of backward compatibility. In general, it should be possible to provide new MPLS services across a legacy network without upgrading those LSRs that do not need to participate actively in the new services. Moreover, some features just require action on specific intermediate hops, not on every visited LSR.
これらの考慮事項は、下位互換性の文脈で特に重要です。一般的には、新しいサービスに積極的に参加する必要はありませんそれらのLSRをアップグレードせずに、レガシーネットワークを介して新しいMPLSサービスを提供することが可能でなければなりません。また、一部の機能だけでなく、すべての訪問LSR上で、特定の中間ホップでのアクションを必要としています。
Note that options already specified for the SESSION_ATTRIBUTE object in preexisting RFCs are not migrated to the new mechanisms described in this document.
すでに既存のRFCの中SESSION_ATTRIBUTEオブジェクトに指定されたオプションは、この文書で説明する新しいメカニズムに移行されませんので注意してください。
RSVP includes a way for unrecognized objects to be transparently forwarded by transit nodes without them refusing the incoming protocol messages and without the objects being stripped from the outgoing protocol message (see [RFC2205], Section 3.10). This capability extends to RSVP-TE and provides a good way to ensure that only those LSRs that understand a particular object examine it.
RSVPは、（[RFC2205]、セクション3.10を参照）を透過的にそれらは、着信プロトコルメッセージを拒否し、オブジェクトが送信プロトコルメッセージから剥離されることなくことなくトランジットノードによって転送される認識されないオブジェクトの方法を含みます。この機能は、-TEをRSVPに拡張し、特定のオブジェクトを理解のみのLSRがそれを調べることを確保するための良い方法を提供します。
This document distinguishes between options and attributes that are only required at key LSRs along the path of the LSP, and those that must be acted on by every LSR along the LSP. Two LSP Attributes objects are defined in this document; using the C-Num definition rules inherited from [RFC2205], the first is passed transparently by LSRs that do not recognize it, and the second causes LSP setup failure with the generation of a PathErr message with an appropriate Error Code if an LSR does not recognize it.
この文書では、オプションのみLSPの経路に沿って、キーのLSRに必要な属性、およびLSPに沿ったすべてのLSRによって作用しなければならないものを区別しています。二つのLSPは、オブジェクトが、この文書で定義されている属性。 [RFC2205]から継承されたC-numが定義ルールを使用して、最初はそれを認識しないのLSRによって透過的に渡され、LSRがない場合は、2番目は、適切なエラーコードでのPathErrメッセージの生成とLSPセットアップの失敗を引き起こしましたそれを認識しています。
The RSVP-TE signaling protocol also forms the basis of a signaling protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and [RFC3473]. The extensions described in this document are equally applicable to MPLS and GMPLS.
[RFC3471]及び[RFC3473]に記載されているようにRSVP-TEシグナリングプロトコルは、一般MPLS用のシグナリングプロトコル（GMPLS）の基礎を形成します。この文書で説明する機能拡張は、MPLSとGMPLSにも同様に適用可能です。
A rejected alternate solution was to define a new C-Type for the existing SESSION_ATTRIBUTE object. This new C-Type could allow a larger Flags field and address the immediate problem.
拒否された代替的な解決策は、既存のSESSION_ATTRIBUTEオブジェクトの新しいC-タイプを定義することでした。この新しいC-Typeが大きなFlagsフィールドを許可し、当面の問題に取り組むことができました。
This solution was rejected because:
このソリューションは、ために拒否されました：
- A new C-Type is not backward compatible with deployed implementations that expect to see a C-Type of 1 or 7. It is important that any solution be capable of carrying new attributes transparently across legacy LSRs if those LSRs are not required to act on the attributes.
- 新しいC-TypeがそれらのLSRが行動するために必要とされていない場合、すべてのソリューションは、従来のLSRの間で透過的に新しい属性を運ぶことができることが重要である1または7のC-種類を見ることを期待展開実装との下位互換性はありません属性に関する。
- Support for arbitrary attributes parameters through TLVs would have meant a significant change of substance to the existing object.
- TLVを通じ任意の属性パラメータのサポートは、既存のオブジェクトへの物質の有意な変化を意味しているだろう。
This document uses terminology from the MPLS architecture document [RFC3031] and from the RSVP-TE protocol specification [RFC3209], which inherits from the RSVP specification [RFC2205]. It also makes use of the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and [RFC3473].
この文書では、MPLSアーキテクチャ文書[RFC3031]から、およびRSVP仕様[RFC2205]を継承RSVP-TEプロトコル仕様[RFC3209]から用語を使用します。また、一般化MPLS RSVP-TEの[RFC3471]で導入された用語と[RFC3473]を使用しています。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Attributes carried by the new objects defined in this document are encoded within TLVs. One or more TLVs may be present in each object. There are no ordering rules for TLVs, and no interpretation should be placed on the order in which TLVs are received.
この文書で定義された新しいオブジェクトによって運ばれる属性は、TLVの内にコードされています。一の以上のTLVは、各オブジェクトに存在してもよいです。そこのTLVのための順序付け規則はありませんし、何の解釈はのTLVが受信された順序に置かれるべきではありません。
Each TLV is encoded as follows.
次のように各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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
The identifier of the TLV.
TLVの識別子。
Length
長さ
Indicates the total length of the TLV in octets. That is, the combined length of the Type, Length, and Value fields, i.e., four plus the length of the Value field in octets.
オクテットでTLVの合計の長さを示します。すなわち、タイプ、長さ、および値フィールドの合計の長さ、すなわち、4プラスオクテットで値フィールドの長さ。
The entire TLV MUST be padded with between zero and three trailing zeros to make it four-octet aligned. The Length field does not count any padding.
全体TLVは、4オクテット整列するためにゼロから3末尾のゼロでパディングされなければなりません。 Lengthフィールドは、任意のパディングをカウントされません。
Value
値
The data carried in the TLV.
TLVで搬送されたデータ。
This document defines only one TLV type value. Type 1 indicates the Attribute Flags TLV. Other TLV types may be defined in the future with type values assigned by IANA (see Section 11.2).
この文書では、唯一のTLVタイプの値を定義します。タイプ1は、属性フラグTLVを示しています。他のTLVタイプはIANAによって割り当てられたタイプの値と、将来的に定義されてもよい（第11.2節を参照）。
The Attribute Flags TLV may be present in an LSP_ATTRIBUTES object and/or an LSP_REQUIRED_ATTRIBUTES object, defined in Sections 4 and 5. The bits in the TLV represent the same attributes regardless of which object carries the TLV. Documents that define individual bits MUST specify whether the bit may be set in one object, the other, or both. It is not expected that a bit will be set in both objects on a single Path message at the same time, but this is not ruled out by this document.
属性フラグは、TLVはLSP_ATTRIBUTES物中に存在し得る、および/またはセクション4および5 TLVのビットで定義されたLSP_REQUIRED_ATTRIBUTESオブジェクトは、関係なくTLVを担持するオブジェクトの同じ属性を表します。個々のビットを定義する文書がビットが1つのオブジェクト、その他、またはその両方に設定することができるかどうかを指定しなければなりません。ビットが同時に一つのPathメッセージの両方のオブジェクトに設定されることが期待されていないが、これは、この文書によって除外されていません。
The Attribute Flags TLV Value field is an array of units of 32 flags numbered from the most significant bit as bit zero. The Length field for this TLV is therefore always a multiple of four bytes, regardless of the number of bits carried, and no padding is required.
属性フラグTLV値フィールドは、ビットゼロとして、最上位ビットから数えて32のフラグの単位の配列です。このTLVのためのLengthフィールドは関係なく行われるビット数の、従って、常に4バイトの倍数であり、パディングが必要とされません。
Unassigned bits are considered as reserved and MUST be set to zero on transmission by the originator of the object. Bits not contained in the TLV MUST be assumed to be set to zero. If the TLV is absent either because it is not contained in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object, or because those objects are themselves absent, all processing MUST be performed as though the bits were present and set to zero. That is to say, assigned bits that are not present either because the TLV is deliberately foreshortened or because the TLV is not included MUST be treated as though they are present and are set to zero.
未割り当てのビットは予約済みとみなされ、オブジェクトの発信者によって送信にゼロに設定しなければなりません。 TLVに含まれていないビットはゼロに設定されているものとしなければなりません。 TLVは存在しないのいずれかでそれがLSP_ATTRIBUTES又はLSP_REQUIRED_ATTRIBUTESに含まれていないため、オブジェクト、またはそれらのオブジェクトが存在しないそれ自体であるためビットが存在し、ゼロに設定されたかのように、全ての処理を実行しなければならない場合。それは、彼らが存在し、ゼロに設定されているかのように、TLVが意図的に短縮されるため、またはTLVが含まれていないためのいずれかで存在していない割り当てられたビットが処理されなければならないと言うことです。
No bits are defined in this document. The assignment of bits is managed by IANA (see Section 11.3).
何ビットは、この文書で定義されていません。ビットの割り当てはIANAによって管理されている（11.3節を参照してください）。
The LSP_ATTRIBUTES object is used to signal attributes required in support of an LSP, or to indicate the nature or use of an LSP where that information is not required to be acted on by all transit LSRs. Specifically, if an LSR does not support the object, it forwards it unexamined and unchanged. This facilitates the exchange of attributes across legacy networks that do not support this new object.
LSP_ATTRIBUTESオブジェクトはLSPをサポートするために必要な属性を知らせるために、またはその情報が全て通過のLSRによって作用する必要がないLSPの性質または使用を示すために使用されます。 LSRがオブジェクトをサポートしていない場合は具体的に、それは未そしてそのまま転送します。これは、この新しいオブジェクトをサポートしていないレガシーネットワークにまたがる属性の交換を容易にします。
This object effectively extends the Flags field in the SESSION_ATTRIBUTE object and allows for the future inclusion of more complex objects through TLVs.
この目的は、効果的SESSION_ATTRIBUTEオブジェクト内のフラグフィールドを拡張しTLVを介して、より複雑なオブジェクトの将来の包含を可能にします。
Note that some function may require an LSR to inspect both the SESSION_ATTRIBUTE object and the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object.
いくつかの関数がSESSION_ATTRIBUTEオブジェクトとLSP_ATTRIBUTES又はLSP_REQUIRED_ATTRIBUTESオブジェクトの両方を検査するLSRを必要とし得ることに留意されたいです。
The LSP_ATTRIBUTES object may also be used to report LSP operational state on a Resv message even when no LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object was carried on the corresponding Path message. The object is added or updated by LSRs that support the object. LSRs that do not understand the object or have nothing to report do not add the object and forward it unchanged on Resv messages that they generate.
LSP_ATTRIBUTESオブジェクトは、全くLSP_ATTRIBUTES又はLSP_REQUIRED_ATTRIBUTESオブジェクトは、対応するPathメッセージに担持されなかった場合でも、ResvメッセージにLSP動作状態を報告するために使用されてもよいです。オブジェクトは、オブジェクトをサポートするのLSRによって追加または更新されます。オブジェクトを理解したり、オブジェクトを追加し、それらが発生したResvメッセージに変わらずにそれを転送しません報告することは何もありませんしませんのLSR。
The LSP_ATTRIBUTES object class is 197 of the form 11bbbbbb. This C-Num value (see [RFC2205], Section 3.10) ensures that LSRs that do not recognize the object pass it on transparently.
LSP_ATTRIBUTESオブジェクトクラスは、フォーム11bbbbbbの197です。このC-民値は、オブジェクトを認識しないのLSRが透過それを渡すことを保証する（[RFC2205]は、セクション3.10を参照します）。
One C-Type is defined, C-Type = 1 for LSP Attributes.
1つのC型が定義され、LSPのためのC型= 1属性。
This object is optional and may be placed on Path messages to convey additional information about the desired attributes of the LSP, and on Resv messages to report operational state.
このオブジェクトは、任意であり、LSPの必要な属性について、および動作状態を報告するRESVメッセージに関する追加情報を伝えるためにPathメッセージ上に配置することができます。
LSP_ATTRIBUTES class = 197, C-Type = 1
LSP_ATTRIBUTESクラス= 197、C-タイプ= 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attributes TLVs are encoded as described in Section 3.
セクション3に記載されているように属性のTLVは、符号化されています。
An LSR that does not support this object is required to pass it on unaltered, as indicated by the C-Num and the rules defined in [RFC2205].
C-numと[RFC2205]で定義された規則によって示されるようにこのオブジェクトをサポートしていないLSRは、不変でそれを通過する必要があります。
An LSR that does support this object but does not recognize a TLV type code carried in this object MUST pass the TLV on unaltered in the LSP_ATTRIBUTES object that it places in the Path message that it sends downstream.
このオブジェクトをサポートしていますが、LSP_ATTRIBUTESで変更されていない上でTLVを渡す必要があり、このオブジェクトで運ばTLVタイプコードを認識しないLSRは、それが下流に送信Pathメッセージに置き、そのオブジェクト。
An LSR that does support this object and recognizes a TLV but does not support the attribute defined by the TLV MUST act as specified in the document that defines the TLV.
このオブジェクトをサポートし、TLVを認識するが、TLVによって定義された属性をサポートしていないLSRはTLVを定義する文書で指定された行動しなければならないと。
An LSR that supports the Attribute Flags TLV but does not recognize a bit set in the Attribute Flags TLV MUST forward the TLV unchanged.
属性フラグTLVは変わらないTLVを転送しなければならないに設定されたビットを属性フラグのTLVをサポートしていますが、認識しないLSR。
An LSR that supports the Attribute Flags TLV and recognizes a bit that is set but does not support the indicated attribute MUST act as specified in the document that defines the bit.
属性フラグのTLVをサポートし、設定されているが、ビットを定義する文書で指定され、示された属性が行動しなければならないサポートされていないビットを認識しLSR。
An LSR that wishes to report operational status of an LSP may include this object in a Resv message, or update the object that is already carried in a Resv message.
LSPの動作状態を報告することを希望するLSRは、Resvメッセージ中でこのオブジェクトを含む、または既にResvメッセージで運ばれるオブジェクトを更新してもよいです。
Note that this usage reports the state of the entire LSP and not the state of the LSP at an individual LSR. This latter function is achieved using the LSP Attributes subobject of the Record Route object (RRO) as described in Section 7.
この用法は、個々のLSRで全体のLSPとLSPのない状態の状態を報告することに注意してください。この後者の機能は、第7節に記載されるようにLSPは、レコードルートオブジェクト（RRO）のサブオブジェクトの属性を使用して達成されます。
The bits in the Attributes TLV may be used to report operational status for the whole LSP. For example, an egress LSR may report a particular status by setting a bit. LSRs within the network that determine that this status has not been achieved may clear the bit as they forward the Resv message.
属性TLVのビットは全LSPの動作ステータスを報告するために使用されてもよいです。例えば、出口LSRは、ビットを設定することにより、特定のステータスを報告することができます。それらはResvメッセージを転送するように、この状態が達成されていないと判断ネットワーク内のLSRは、ビットをクリアすることができます。
Observe that LSRs that do not support the object or do not support the function characterized by a particular bit in the Attributes TLV will not clear the bit when forwarding the Resv. Thus, care must be taken in defining the usage of this object on a Resv. The usage of an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object on a Resv must be fully defined in the document that defines the bit.
観察そのオブジェクトをサポートしていないか、のResvを転送するときTLVビットをクリアしないであろう属性に特定のビットによって特徴付けられる機能をサポートしないのLSR。このように、注意がのResvでこのオブジェクトの使用方法を定義する際に注意する必要があります。 TLVのResvにLSP_ATTRIBUTESオブジェクトの属性の個々のビットの使用は、完全にビットを定義する文書で定義されなければなりません。
Additional TLVs may also be defined to be carried in this object on a Resv.
追加のTLVものResvに、このオブジェクトで運ばれるように定義することができます。
An LSR that does not support this object will pass it on unaltered because of the C-Num.
このオブジェクトをサポートしていないLSRがあるためC-のNumの変更せずにそれを渡します。
The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes required in support of an LSP, or to indicate the nature or use of an LSP where that information MUST be inspected at each transit LSR. Specifically, each transit LSR MUST examine the attributes in the LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object without acting on its contents.
LSP_REQUIRED_ATTRIBUTESオブジェクトはLSPをサポートするために必要な属性を知らせるために、またはその情報を各中継LSRで検査しなければならないLSPの性質または使用を示すために使用されます。具体的には、各中継LSRはLSP_REQUIRED_ATTRIBUTESオブジェクトの属性を調べる必要があり、その内容に作用せずにオブジェクトを転送してはなりません。
This object effectively extends the Flags field in the SESSION_ATTRIBUTE object and allows for the future inclusion of more complex objects through TLVs. It complements the LSP_ATTRIBUTES object.
この目的は、効果的SESSION_ATTRIBUTEオブジェクト内のフラグフィールドを拡張しTLVを介して、より複雑なオブジェクトの将来の包含を可能にします。それはLSP_ATTRIBUTESオブジェクトを補完します。
The LSP_REQUIRED_ATTRIBUTES object class is 67 of the form 0bbbbbbb. This C-Num value ensures that LSRs that do not recognize the object reject the LSP setup, effectively saying that they do not support the attributes requested. This means that this object SHOULD only be used for attributes that require support at some transit LSRs and so require examination at all transit LSRs. See Section 4 for how end-to-end and selective attributes are signaled.
LSP_REQUIRED_ATTRIBUTESオブジェクトクラスは、フォーム0bbbbbbbは67です。このC-のNum値は、オブジェクトを認識しないのLSRが効果的に、彼らが要求された属性をサポートしていないことを言って、LSPの設定を拒否することを保証します。これは、このオブジェクトは一部だけトランジットのLSRでサポートが必要なので、すべてのトランジットのLSRでの検査が必要な属性に使用されることを意味します。エンドツーエンドと選択属性合図する方法については、セクション4を参照してください。
One C-Type is defined, C-Type = 1 for LSP Required Attributes.
1つのC型が定義され、LSP必須用Cタイプ= 1属性。
This object is optional and may be placed on Path messages to convey additional information about the desired attributes of the LSP.
このオブジェクトはオプションであり、LSPの所望の属性に関する追加情報を伝えるためにPathメッセージ上に配置することができます。
LSP_REQUIRED_ATTRIBUTES class = 67, C-Type = 1
LSP_REQUIRED_ATTRIBUTESクラス= 67、C-タイプ= 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attributes TLVs are encoded as described in Section 3.
セクション3に記載されているように属性のTLVは、符号化されています。
An LSR that does not support this object will use a PathErr to reject the Path message based on the C-Num using the Error Code "Unknown Object Class".
このオブジェクトをサポートしていないLSRは、エラーコード「不明なオブジェクトクラス」を使用してC-のNumに基づいてPathメッセージを拒否するのPathErrを使用します。
An LSR that does not recognize a TLV type code carried in this object MUST reject the Path message using a PathErr with Error Code "Unknown Attributes TLV" and Error Value set to the value of the unknown TLV type code.
エラーコードとのPathErrを使用してPathメッセージを拒絶しなければなりません。このオブジェクトで運ばTLVタイプコードを認識しないLSRは、未知のTLVタイプコードの値に設定し、エラー値「不明TLV属性」。
An LSR that does not recognize a bit set in the Attribute Flags TLV MUST reject the Path message using a PathErr with Error Code "Unknown Attributes Bit" and Error Value set to the bit number of the unknown bit in the Attribute Flags.
TLVは、エラーコード「未知の属性ビット」と属性フラグ中の未知のビットのビット数に設定エラー値とのPathErrを使用してPathメッセージを拒絶しなければなりません属性フラグに設定されたビットを認識しませんLSR。
An LSR that recognizes an attribute (however encoded) but does not support that attribute MUST act according to the behavior specified in the document that defines that specific attribute.
属性を認識する（ただしエンコード）が、その属性をサポートしていないLSRは、その特定の属性を定義する文書で指定された動作に応じて行動しなければなりません。
Note that this object is not used on a Resv. In order to report the status of an LSP, either the LSP_ATTRIBUTES object on a Resv or the Attributes subobject in the Record Route object (see Section 7) must be used.
このオブジェクトはのResvに使用されていないことに注意してください。 LSPの状態を報告するために、のResvまたはレコードルートオブジェクトの属性のサブオブジェクト（セクション7参照）にLSP_ATTRIBUTESオブジェクトのいずれかを使用しなければなりません。
In certain circumstances, when reaching an LSP region boundary, a forwarding adjacency LSP (FA-LSP; see [RFC4206]) is initially set up to allow the establishment of the LSP carrying the LSP_ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES objects. In this case, when the boundary LSR supports LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES processing, the FA-LSP MAY, upon local policy, inherit a subset of the Attributes TLVs, in particular when the FA-LSP belongs to the same switching capability class as the triggering LSP.
LSP領域境界に到達したとき、特定の状況では、転送隣接LSP（FA-LSP; [RFC4206]を参照）を最初LSP_ATTRIBUTES及び/又はLSP_REQUIRED_ATTRIBUTESオブジェクトを運ぶLSPの確立を許可するように設定されています。 FA-LSPトリガLSPと同じスイッチング能力クラスに属している場合この場合、境界LSRはLSP_ATTRIBUTESとLSP_REQUIRED_ATTRIBUTES処理をサポートする場合、FA-LSP MAYは、ローカルポリシーに、特に、属性のTLVのサブセットを継承します。
When these conditions are met, the LSP_ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited Attributes TLVs in the Path message used to establish the FA-LSP. By default (and in order to simplify deployment), none of the incoming LSP Attributes TLVs are considered as inheritable. Note that when the FA-LSP establishment itself requires one or more Attributes TLVs, an 'OR' operation is performed with the inherited set of values.
これらの条件が満たされた場合、LSP_ATTRIBUTES及び/又はLSP_REQUIRED_ATTRIBUTESオブジェクトが単にFA-LSPを確立するために使用されるPathメッセージ内のTLV属性継承とコピーされます。デフォルトで（および展開を簡単にするために）、受信LSPのいずれものTLV属性ない継承と考えられます。 FA-LSPの確立自体が1つを必要以上のTLV属性場合、「OR」演算は、値の継承されたセットを用いて行われることに留意されたいです。
Documents that define individual bits for the LSP Attribute Flags TLV MUST specify whether or not these bits MAY be inherited (including the condition to be met in order for this inheritance to occur). The same applies for any other TLV that will be defined following the rules specified in Section 3.
LSPのための個々のビットを定義する文書がフラグTLVは、これらのビットは（この継承が発生するために満たすべき条件を含む）継承されるかもしれませんかどうかを指定しなければならない属性。同じことが、第3節で指定された規則に従って定義される任意の他のTLVに適用されます。
In some circumstances, it is useful to determine which of the requested LSP attributes have been applied at which LSRs along the path of the LSP. For example, an attribute may be requested in the LSP_ATTRIBUTES object such that LSRs that do not support the object are not required to support the attribute or provide the requested function. In this case, it may be useful to the ingress LSR to know which LSRs acted on the request and which ignored it.
いくつかの状況では、LSPの経路に沿っているのLSRに適用されている要求されたLSP属性のどれかを決定するのに有用です。例えば、属性はLSP_ATTRIBUTESに要求することができるオブジェクトをサポートしていないのLSRが属性をサポートするか、要求された機能を提供するために必要とされないようにオブジェクト。この場合、それはのLSRは、リクエストに応じて行動しているが、それを無視しているかを知るために、入口LSRに有用である可能性があります。
Additionally, there may be other qualities that need to be reported on a hop-by-hop basis. These are currently indicated in the Flags field of RRO subobjects. Since there are only eight bits available in this field, and since some are already assigned and there is also likely to be an increase in allocations in new documents, there is a need for some other method to report per-hop attributes.
また、ホップバイホップベースで報告する必要がある他の資質があるかもしれません。これらは、現在、RROのサブオブジェクトのFlagsフィールドに示されています。この分野で利用可能な唯一の8ビットがある、といくつかはすでに割り当てられているので、また新しい文書に配分が増加する可能性がありますので、他のいくつかの方法がホップごとの属性を報告するための必要性があります。
The RRO Attributes subobject may be carried in the RECORD_ROUTE object if it is present. The subobject uses the standard format of an RRO subobject.
RROは、それが存在する場合、サブオブジェクトはRECORD_ROUTEオブジェクトで実施することができる属性。サブオブジェクトは、RROのサブオブジェクトの標準フォーマットを使用しています。
The length is variable, as for the Attribute Flags TLV. The content is the same as the Attribute Flags TLV -- that is, it is a series of bit flags.
長さは、属性フラグTLV用として、変数です。コンテンツは、属性フラグTLVと同じである - つまり、それはビットフラグのシリーズです。
There is a one-to-one correspondence between bits in the Attribute Flags TLV and the RRO Attributes subobject. If a bit is only required in one of the two places, it is reserved in the other place. See the procedures sections, below, for more information.
TLVとRROは、サブオブジェクトの属性属性フラグのビットの間に1対1で対応しています。ビットは2つのだけの場所のいずれかで必要とされている場合は、それを他の場所に予約されています。詳細については、下記の手順のセクションを参照してください。
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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attribute Flags //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
0x05
0x05の
Length
長さ
The Length contains the total length of the subobject in bytes, including the Type and Length fields. This length must be a multiple of four and must be at least eight.
長さは、タイプと長さフィールドを含むバイト単位のサブオブジェクトの全長を含んでいます。この長さは4の倍数でなければならないし、少なくとも8でなければなりません。
Attribute Flags
フラグ属性
The attribute flags recorded for the specific hop.
属性フラグは、特定のホップのために記録します。
As will be clear from [RFC3209], the RECORD_ROUTE object is managed as a "stack", with each LSR adding subobjects to the start of the object. The Attributes subobject is pushed onto the RECORD_ROUTE object immediately prior to pushing the node's IP address or link identifier. Thus, if label recording is being used, the Attributes subobject SHOULD be pushed onto the RECORD_ROUTE object after the Record Label subobject(s).
[RFC3209]から明らかなように、RECORD_ROUTEオブジェクトは、各LSRは、オブジェクトの先頭にサブオブジェクトを追加すると、「スタック」として管理されます。属性のサブオブジェクトは、直前のノードのIPアドレスまたはリンク識別子を押すとRECORD_ROUTEオブジェクトにプッシュされます。ラベル記録が使用されている場合このように、属性、サブオブジェクトは、レコードレーベルのサブオブジェクト（複数可）の後にRECORD_ROUTEオブジェクトにプッシュされるべきです。
A node MUST NOT push an Attributes subobject onto the RECORD_ROUTE object without also pushing an IPv4, IPv6, or Unnumbered Interface ID subobject.
ノードはまたのIPv4、IPv6の、またはアンナンバードインターフェイスIDサブオブジェクトを押すことなく、RECORD_ROUTEオブジェクト上にサブオブジェクト属性をプッシュしてはいけません。
This means that an Attributes subobject is bound to the LSR identified by the subobject found in the RRO immediately before the Attributes subobject.
これは、属性のサブオブジェクトがすぐに属性のサブオブジェクトの前にRROで見つかったサブオブジェクトによって識別されるLSRにバインドされていることを意味します。
If the new subobject causes the RRO to be too big to fit in a Path (or Resv) message, the processing MUST be as described in Section 4.4.3 of [RFC3209].
新しいサブオブジェクトは、RROがパス（またはのResv）メッセージに収まるには大きすぎるようになる場合、[RFC3209]のセクション4.4.3で説明したように、処理がなければなりません。
If more than one Attributes subobject is found between a pair of subobjects that identify LSRs, only the first one found (that is, the nearest to the top of the stack) SHALL have any meaning within the context of this document. All such subobjects MUST be forwarded unmodified by transit LSRs.
一つはサブオブジェクト属性のLSRを識別サブオブジェクトの対の間に発見されたよりも多くの場合、唯一見つかった最初の一つ（即ち、スタックの最上位に最も近い）は、本明細書の文脈内の任意の意味を有します。そのようなすべてのサブオブジェクトは、トランジットのLSRによってそのまま転送する必要があります。
To report compliance with an attribute requested in the Attribute Flags TLV, an LSR MAY set the corresponding bit (see Section 8) in the Attributes subobject. To report non-compliance, an LSR MAY clear the corresponding bit in the Attributes subobject.
属性フラグTLVに要求された属性の遵守を報告するには、LSRは、属性のサブオブジェクトに（セクション8を参照）、対応するビットを設定することができます。不遵守を報告するには、LSRは、属性のサブオブジェクトに対応するビットをクリアすることができます。
The requirement to report compliance MUST be specified in the document that defines the usage of any bit. This will reduce to a statement of whether hop-by-hop acknowledgement is required.
コンプライアンスを報告する要件は、任意のビットの使用を定義文書に指定されなければなりません。これは、ホップバイホップの承認が必要とされているかどうかのステートメントに削減されます。
To report a per-hop attribute, an LSR sets the appropriate bit in the Attributes subobject.
ホップごとの属性を報告するには、LSRは、属性のサブオブジェクトに適切なビットを設定します。
The requirement to report a per-hop attribute MUST be specified in the document that defines the usage of the bit.
ホップごとの属性を報告するための要件は、ビットの使用方法を定義する文書で指定する必要があります。
By default, all bits in an Attributes subobject SHOULD be set to zero.
デフォルトでは、属性のサブオブジェクトのすべてのビットはゼロに設定する必要があります。
If a received Attributes subobject is not long enough to include a specific numbered bit, that bit MUST be treated as though present and as if set to zero.
受信した属性のサブオブジェクトは、特定の番号のビットを含むのに十分長くない場合は、そのビットが存在し、ゼロに設定されているかのようかのように扱われなければなりません。
If the RRO subobject is not present for a hop in the LSP, all bits MUST be assumed to be set to zero.
RROサブオブジェクトはLSPでホップのために存在しない場合、すべてのビットがゼロに設定されているものとしなければなりません。
This document defines two uses of per-LSP attribute flag bit fields. The bit numbering in the Attribute Flags TLV and the RRO Attributes subobject is identical. That is, the same attribute is indicated by the same bit in both places. This means that only a single registry of bits is maintained.
この文書では、フラグビットフィールド属性ごと-LSPの2つの使用を規定します。 TLVとRROは、サブオブジェクトが同一である属性の属性フラグのビット番号。これは、同じ属性は、両方の場所で同じビットによって示されています。これは、ビットの単一のレジストリが維持されることを意味します。
The consequence is a degree of clarity in implementation and registration.
その結果は、実装および登録で明瞭度です。
Note, however, that it is not always the case that a bit will be used in both the Attribute Flags TLV and the RRO Attributes subobject. For example, an attribute may be requested using the Attribute Flags TLV, but there is no requirement to report the handling of the attribute on a hop-by-hop basis. Conversely, there may be a requirement to report the attributes of an LSP on a hop-by-hop basis, but there is no corresponding request attribute.
それは少しはTLVとRROは、サブオブジェクトの属性の両方の属性フラグに使用されることを必ずしもそうではないこと、しかし、注意してください。例えば、属性は、属性フラグにTLVを使用して要求することができるが、ホップ単位での属性の取り扱いを報告する必要はありません。逆に、ホップバイホップに基づいてLSPの属性を報告する必要があるかもしれないが、該当する要求属性が存在しません。
In these cases, a single bit number is still assigned for both the Attribute Flags TLV and the RRO Attributes subobject, even though the bit may be irrelevant in either the Attribute Flags or the RRO Attributes subobject. The document that defines the usage of the new bit MUST state in which places it is used and MUST handle a default setting of zero.
これらのケースでは、単一のビット数は依然としてビットは属性フラグまたはRROのいずれかに無関係であっても、TLVとRROは、サブオブジェクトの属性の属性フラグの両方に割り当てられているサブオブジェクト属性。それを配置する新しいビットMUST状態の使用を定義する文書が使用され、ゼロのデフォルト設定を処理する必要があります。
The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY be carried in a Path message. The LSP_ATTRIBUTES object MAY be carried in a Resv message.
LSPは、オブジェクト属性およびLSP REQUIREDオブジェクトはPathメッセージで運ばれるかもしれATTRIBUTES。 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 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.
Pathメッセージに、LSP_ATTRIBUTES、オブジェクトとそれが存在する、またはそうでなければ直ちにLABEL_REQUESTオブジェクト後の場合LSP_REQUIRED_ATTRIBUTESオブジェクトは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は、Pathメッセージ内の任意の位置に任意の順序でこれらのオブジェクトを受信する準備をしなければなりません。 Pathメッセージ内のこれらのオブジェクトの後続のインスタンスは無視され、そのまま転送する必要があります。
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オブジェクトがすぐにLABELオブジェクトの後に配置することを推奨します。
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オブジェクトのインスタンスは1つだけFILTER_SPECオブジェクトのコンテキスト内で有意義です。オブジェクトの後続のインスタンスは無視され、そのまま転送する必要があります。
As described in the Introduction section of this document, it may be that requested LSP attributes need to be acted on by only the egress LSR of the LSP, by certain key transit points (such as ABRs and ASBRs), or by all LSRs along the LSP. This section briefly describes how each of these scenarios is met. This section is informational and does not define any new procedures.
この文書の導入部に記載されているように、それはそれがLSP属性は、（例えば、のABRとのASBR）又は沿って全てのLSRによって特定のキー通過点によって、LSPの唯一出口LSRによって作用する必要が要求されてもよいですLSP。このセクションでは、簡単にこれらのシナリオのそれぞれが満たされている方法について説明します。このセクションでは、情報提供であり、いかなる新しい手順を定義していません。
When communicating LSP attributes that must be acted on only by the LSP egress LSR, the attributes should be communicated in the LSP_ATTRIBUTES object. Because of its C-Num, this object may be ignored (passed onwards, untouched) by transit LSRs that do not understand it. This means that the Path message will not be rejected by LSRs that do not understand the object. In this way, the requested LSP attributes are guaranteed to reach the egress LSR.
通信LSPは、それがLSPの出口LSRだけに作用しなければならない属性の場合、属性はLSP_ATTRIBUTESオブジェクトで伝達されなければなりません。そのC-のNumの、このオブジェクトは無視されることがありますので、それを理解していないトランジットのLSRによって（そのまま、以降渡されます）。これは、Pathメッセージがオブジェクトを理解していないのLSRによって拒絶されないことを意味します。このように、要求されたLSP属性は、出口LSRに到達することが保証されています。
Attributes are set within the LSP_ATTRIBUTES object according to which LSP attributes are required. Each attribute is defined in some RFC and is accompanied by a statement of what the expected behavior is. This behavior will include whether the attribute must be acted on by any LSR that recognizes it, or specifically by the egress LSR. Thus, any attribute that must be acted on only by an egress LSR will be defined in this way -- any transit LSR seeing this attribute either will understand the semantics of the attribute and ignore it (forwarding it, unchanged) or will not understand the attribute and ignore it (forwarding it, unchanged) according to the rules of the LSP_ATTRIBUTES object.
属性はLSP_ATTRIBUTES内に設定されているLSP属性が要求されるに係る物体。各属性には、いくつかのRFCで定義されていると予想される動作が何であるかの声明を伴っています。この動作は、属性は出力LSRによってそれを特異的に認識し、または任意のLSRによって作用する必要があるかどうかが含まれます。したがって、出口LSRによってのみに作用しなければならない任意の属性は、このように定義されます - 任意のトランジットLSRは、この属性を見てどちらかの属性の意味を理解し、それを無視します（それを転送し、変わらず）、または理解できないだろうLSP_ATTRIBUTESオブジェクトの規則に従って属性と（それを転送不変）それを無視します。
The remaining issue is how the ingress LSR can know whether the egress LSR has acted correctly on the required LSP attribute. Another part of the definition of the attribute (in the defining RFC) is whether reporting is required. If reporting is required, the egress LSR is required to use the RRO Attributes subobject to report whether it has acted on the received attribute.
残りの問題は、イングレスLSRが出口LSRが必要なLSP属性に正しく行動しているかどうかを知ることができる方法です。 （定義RFCで）属性の定義の別の部分は、報告が必要とされているかどうかです。報告が必要な場合は、出力LSRはRROは、それが受信した属性に作用しているかどうかを報告するサブオブジェクト属性を使用するために必要とされます。
If an egress LSR understands a received attribute as mandatory for an egress LSR but does not wish to satisfy the request, it will reject the Path message. If an egress LSR understands the attribute but believes it to be optional and does not wish to satisfy the request, it will report its non-compliance in the RRO Attributes subobject. If the egress LSR does not understand the received attribute, it may report non-compliance in the RRO Attributes subobject explicitly, or it may omit the RRO Attributes subobject, implying that it has not satisfied the request.
出口LSRが出口LSRのために必須として受信した属性を理解しますが、要求を満たすために希望しない場合は、Pathメッセージを拒否します。出口LSRが属性を理解しますが、それはオプションであることを信じているし、要求を満たすために希望しない場合は、RROでその非コンプライアンスはサブオブジェクトの属性を報告します。出口LSRは、受信した属性を理解していない場合は、RRO非コンプライアンスがサブオブジェクトを明示的属性、またはそれはRROは、それが要求を満たしていないことを意味、サブオブジェクト属性省略することが報告されることがあります。
Processing for key transit LSRs (such as ABRs and ASBRs) follows exactly as for egress LSR. The only difference is that the definition of the LSP attribute in the defining RFC will state that the attribute must be acted on by these transit LSRs.
（などのABRおよびASBRはなど）のキートランジットLSRのための処理が正確に出力LSR用として、次の。唯一の違いは、定義するRFCでのLSP属性の定義は、属性がこれらのトランジットのLSRによって作用しなければならないことを述べるということです。
In order to force all LSRs to examine the LSP attributes, the LSP_REQUIRED_ATTRIBUTES object is used. The C-Num of this object is such that any LSR that does not recognize the object must reject a received Path message containing the object.
LSP属性を調べるために、すべてのLSRを強制するために、LSP_REQUIRED_ATTRIBUTESオブジェクトが使用されます。このオブジェクトのC-numがオブジェクトを認識しない任意のLSRは、オブジェクトを含む受信したPathメッセージを拒絶しなければならないようなものです。
An LSR that recognizes the LSP_REQUIRED_ATTRIBUTES object but does not recognize an attribute will reject the Path message.
LSP_REQUIRED_ATTRIBUTESオブジェクトを認識するが属性を認識しないLSRはPathメッセージを拒否します。
An LSR that recognizes an attribute but does not wish to support the attribute reacts according to the definition of the attribute in the defining RFC. This may allow the LSR to ignore the attribute and forward it unchanged, or may require it to fail the LSP setup. The LSR may additionally be required to report whether it supports the attribute using the RRO Attributes subobject.
属性を認識しますが、属性をサポートしたくないLSRが定義するRFC内の属性の定義に従って反応します。これはLSRが属性を無視して、そのままそれを転送することを可能にする、またはLSPのセットアップに失敗することが必要な場合があります。 LSRは、さらにそれがRROは、サブオブジェクトの属性使用して属性をサポートしているかどうかを報告するために必要とすることができます。
The IANA allocations made for RFC 4420 [RFC4420] now apply to this document and are listed here for completeness.
RFC 4420 [RFC4420]のために作られたIANAの割り当ては現在、このドキュメントに適用され、完全を期すためにここに記載されています。
IANA has updated the registry entries created for RFC 4420 to reference this document, which is now the normative reference for those entries. This document makes no further requests for IANA action.
IANAは現在、これらのエントリの引用規格であるこのドキュメントを、参照するためにRFC 4420のために作成されたレジストリエントリを更新しました。このドキュメントは、IANAのアクションのための更なる要求を行うものではありません。
Two new RSVP C-Nums are defined in this document and have been assigned by IANA.
二つの新しいRSVPのC-NUMSは、この文書で定義され、IANAによって割り当てられました。
o LSP_ATTRIBUTES object
O LSP_ATTRIBUTESオブジェクト
The C-Num (value 197) is of the form 11bbbbbb so that LSRs that do not recognize the object will ignore the object but forward it, unexamined and unmodified, in all messages resulting from this message.
オブジェクトを認識しないのLSRがオブジェクトを無視するが、このメッセージから得られたすべてのメッセージに、未および未修飾、それを転送するようにC-民（値197）は、フォーム11bbbbbbです。
One C-Type is defined for this object and has been assigned by IANA.
一つのC-typeこのオブジェクトのために定義され、IANAによって割り当てられています。
o LSP Attributes TLVs
O LSPは、TLVを属性
C-Type value 1.
C-Type値1。
o LSP_REQUIRED_ATTRIBUTES object
O LSP_REQUIRED_ATTRIBUTESオブジェクト
The C-Num (value 67) is of the form 0bbbbbbb so that LSRs that do not recognize the object will reject the message that carries it with an "Unknown Object Class" error.
オブジェクトを認識しないのLSRsは「未知のオブジェクトクラス」エラーでそれを運ぶメッセージを拒否するようにC-民（値67）がフォーム0bbbbbbbはです。
One C-Type is defined for this object and has been assigned by IANA.
一つのC-typeこのオブジェクトのために定義され、IANAによって割り当てられています。
o LSP Required Attributes TLVs
O LSP必須のTLV属性
C-Type value 1.
C-Type値1。
The two new objects referenced above are constructed from TLVs. Each TLV includes a 16-bit type identifier (the T-field). The same T-field values are applicable to both objects.
上記参照二つの新しいオブジェクトがのTLVから構成されています。各TLVは、16ビットのタイプ識別子（T-フィールド）を含みます。同じTフィールドの値は、両方のオブジェクトに適用可能です。
The IANA has created a new registry and will manage TLV type identifiers as follows:
IANAは、新しいレジストリを作成して、次のようにTLVタイプ識別子を管理します。
- TLV Type (T-field value) - TLV Name - Whether allowed on LSP_ATTRIBUTES object - Whether allowed on LSP_REQUIRED_ATTRIBUTES object
- TLVタイプ（T-フィールド値） - TLV名 - LSP_ATTRIBUTESオブジェクトに対して許可するかどうか - LSP_REQUIRED_ATTRIBUTESオブジェクトに対して許可するかどうか
This document defines one TLV type as follows:
次のようにこの文書では、1羽のTLVタイプを定義します。
- TLV Type = 1 - TLV Name = Attribute Flags TLV - allowed on LSP_ATTRIBUTES object - allowed on LSP_REQUIRED_ATTRIBUTES object
- TLVタイプ= 1 - TLV名=属性フラグTLV - LSP_ATTRIBUTESオブジェクト上で許可 - LSP_REQUIRED_ATTRIBUTESオブジェクト上で許可
New TLV type values may be allocated only by an IETF Consensus action.
新しいTLVタイプの値はIETF Consensus動作によって割り当てることができます。
This document provides new attributes bit flags for use in other documents that specify new RSVP-TE attributes. These flags are present in the Attribute Flags TLV referenced in the previous section.
この文書は、新しいRSVP-TEの属性を指定して他のドキュメントで使用するための新しい属性ビットフラグを提供します。これらのフラグは、前のセクションで参照属性フラグのTLVに存在しています。
The IANA has created a new registry and will manage the space of attributes bit flags, numbering them in the usual IETF notation: starting at zero and continuing at least through 31.
ゼロから始まり、少なくとも31まで継続：IANAは、通常のIETF記法でそれらの番号、フラグビット新しいレジストリを作成したと属性のスペースを管理します。
New bit numbers may be allocated only by an IETF Consensus action.
新しいビット数はIETF Consensus動作によって割り当てることができます。
Each bit should be tracked with the following qualities:
各ビットは以下の品質を追跡する必要があります。
- Bit number - Defining RFC - Name of bit - Whether there is meaning in the Attribute Flags TLV on a Path - Whether there is meaning in the Attribute Flags TLV on a Resv - Whether there is meaning in the RRO Attributes subobject
- ビット数 - パス上の属性フラグTLVに意味があるかどうか - - ビットの名前 - RFCの定義RROであっ意味されることはサブオブジェクトの属性かどうか - 属性フラグのResv上のTLVに意味があるかどうか
Note that this means that all bits in the Attribute Flags TLV and the RRO Attributes subobject use the same bit number, regardless of whether they are used in one or both places. Thus, only one list of bits is required to be maintained. (It would be meaningless in the context of this document for a bit to have no meaning in either the Attribute Flags TLV or the RRO Attributes subobject.)
この属性フラグTLVとRROのすべてのビットに関係なく、1つのまたは両方の場所で使用されているかどうかの、同一のビット数を使用するサブオブジェクト属性のことを意味することに留意されたいです。したがって、ビットの一方のみのリストを維持する必要があります。 （TLVまたはRROは、サブオブジェクトの属性属性フラグのいずれかに意味を持たないためにビットのは、この文書の文脈では意味がありません。）
This document defines the following new Error Codes and Error Values. Numeric values have been assigned by IANA.
このドキュメントは、次の新しいエラーコードとエラー値を定義します。数値は、IANAによって割り当てられています。
Error Code Error Value 29 "Unknown Attributes TLV" Identifies the unknown TLV type code. 30 "Unknown Attributes Bit" Identifies the unknown Attribute Bit.
エラーコードエラー値29は「不明TLV属性」不明なTLVタイプコードを識別します。 30「不明な属性ビットは、」未知の属性ビットを識別します。
A new subobject is defined for inclusion in the RECORD_ROUTE object.
新しいサブオブジェクトはRECORD_ROUTEオブジェクトに含めるために定義されています。
The RRO Attributes subobject is identified by a Type value of 5.
RROは、5種類の値によって識別されるサブオブジェクト属性。
This document adds two new objects to the RSVP Path message as used in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE object carried on many RSVP messages. It does not introduce any new direct security issues, and the reader is referred to the security considerations expressed in [RFC2205], [RFC3209], and [RFC3473].
この文書では、MPLSおよびGMPLSシグナリングに使用されるようにRSVP Pathメッセージに二つの新しいオブジェクトを追加し、多くのRSVPメッセージで運ばRECORD_ROUTEオブジェクトに新しいサブオブジェクト。これは、任意の新しいダイレクトセキュリティ問題を導入しないと、読者は[RFC2205]、[RFC3209]、および[RFC3473]で表されたセキュリティ上の考慮事項と呼ばれます。
It is of passing note that any signaling request that indicates the functional preferences or attributes of an MPLS LSP may provide anyone with unauthorized access to the contents of the message with information about the LSP that an administrator may wish to keep secret. Although this document adds new objects for signaling desired LSP attributes, it does not contribute to this issue, which can only be satisfactorily handled by encrypting the content of the signaling message.
これは、機能的な好みやMPLS LSPの属性を示す任意のシグナリング要求は、管理者が秘密にしておきたいことがLSPに関する情報を持つメッセージの内容に不正にアクセスして、誰を提供することができることをメモして渡すのです。このドキュメントは、所望のLSP属性のシグナリングのための新しいオブジェクトを追加しますが、それだけで十分シグナリングメッセージの内容を暗号化することによって処理することができ、この問題に寄与しません。
Similarly, the addition of attribute-recording information to the RRO may reveal information about the status of the LSP and the capabilities of individual LSRs that operators wish to keep secret. The same strategy that applies to other RRO subobjects also applies here. Note, however, that there is a tension between notifying the head end of the LSP status at transit LSRs, and hiding the existence or identity of the transit LSRs.
同様に、RROの属性情報記録の追加は、LSPの状況と事業者が秘密を保持したい個々のLSRの機能に関する情報を公開してもよいです。他のRROのサブオブジェクトに適用される同じ戦略もここに適用されます。トランジットのLSRにおいてLSPステータスのヘッドエンドに通知し、トランジットのLSRの存在またはアイデンティティを隠すの間に緊張があること、しかし、注意してください。
Credit to the OSPF Working Group for inspiration from their solution to a similar problem. Thanks to Rahul Aggarwal for his careful review and support of this work. Thanks also to Raymond Zhang, Kireeti Kompella, Philip Matthews, Jim Gibson, and Alan Kullberg for their input. As so often, thanks to John Drake for useful offline discussions. Thanks to Mike Shand for providing the Routing Directorate review and to Joel Halpern for the General Area review -- both picked up on some unclarities.
同様の問題への解決策からのインスピレーションのためのOSPF作業部会の功績によるものです。この作品の彼の慎重な検討と支援のためのラウール・アガーウォールに感謝します。また、彼らの入力のためのレイモンド・チャン、Kireeti Kompella、フィリップ・マシューズ、ジム・ギブソン、とアランKullbergに感謝します。ように、多くの場合、便利なオフラインでの議論のためのジョン・ドレイクのおかげ。一般的なエリアの見直しのためのルーティング総局のレビューを提供するためのジョエル・ハルパーンにマイクシャンドのおかげで - 両方のいくつかのunclaritiesに拾いました。
Thanks to the OIF for noticing the discrepancy in RFC 4420 that is fixed in this document. Alfred Hoenes noted several typographical errors.
このドキュメントで固定されているRFC 4420で矛盾に気付いためのOIFに感謝します。アルフレッドHoenesは、いくつかのタイプミスを指摘しました。
This document obsoletes RFC 4420 [RFC4420]. The only change is in Section 3. Section 3 describes the semantic of the Length field of the Attributes TLV.
この文書は、RFC 4420 [RFC4420]を廃止します。唯一の変化は第3節第3節である属性TLVの長さフィールドの意味を説明しています。
Prior to the change, the Length field indicated the length of the Value field only. After the change, as described in Section 3, the Length field indicates the length of the whole TLV. This change means that this document is consistent with the subobject format defined in [RFC3209] and the TLV format defined in [RFC3471].
変更する前に、Lengthフィールドは、値フィールドの長さを示します。第3節で説明したように変更後、Lengthフィールドは、全体のTLVの長さを示します。この変更は、この文書は[RFC3209]で定義されたサブオブジェクトのフォーマットと[RFC3471]で定義されたTLVのフォーマットと一致していることを意味します。
In addition, the RFC Editor made many editorial changes to improve the text and readability. These changes can be observed by comparing the text of this document with that of [RFC4420].
また、RFC Editorは、テキストや読みやすさを改善するために多くの編集上の変更を行いました。これらの変更は、[RFC4420]のもので、この文書のテキストを比較することによって観察することができます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、RFC 4090、2005年5月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K.とY. Rekhterは、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
[RFC4420]ファレル、A.編、Papadimitriou、D.、Vasseur、J.-P.、およびA. Ayyangar、「マルチプロトコルラベルスイッチングのための属性のエンコーディング（MPLS）リソース予約を使用したラベルスイッチパス（LSP）の確立をプロトコル - トラフィックエンジニアリング（RSVP-TE）」、RFC 4420、2006年2月。
Authors' Addresses
著者のアドレス
Adrian Farrel Old Dog Consulting
エードリアンファレル古い犬のコンサルティング
Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
電話：+44（0）1978 860944 Eメール：adrian@olddog.co.uk
Dimitri Papadimitriou Alcatel Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルブロック。 B-2018アントワープ、Velgiom Vellesplein 1
Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
電話：+32 3 240-8491 Eメール：dimitri.papadimitriou@alcatel.be
Jean Philippe Vasseur Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 USA
ジャン・フィリップVasseurシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA - 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
Arthi Ayyangar Juniper Networks, Inc. 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA
Arthyアイアンガージュニパーネットワークス本。 1194 Nkmthildaアベニューサニーベール、それらの94089
EMail: arthi@juniper.net
メールアドレス：arthi@juniper.net