[要約] RFC 4420は、MPLS Label Switched Path（LSP）の確立における属性のエンコーディングに関するものであり、RSVP-TEを使用しています。このRFCの目的は、LSPの確立に必要な情報を効果的にエンコードするためのガイドラインを提供することです。
Network Working Group A. Farrel, Ed.
Request for Comments: 4420 Old Dog Consulting
Updates: 3209, 3473 D. Papadimitriou
Category: Standards Track Alcatel
J.-P. Vasseur
Cisco Systems, Inc.
A. Ayyangar
Juniper Networks
February 2006
Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチパス（LSP）の属性のエンコーディングリソース予約プロトコルトラフィックエンジニアリング（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) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
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）ラベルスイッチ付きパス（LSP）は、リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張機能を使用して確立できます。このプロトコルには、LSPのオプションと属性を示すために使用されるフラグフィールドを運ぶオブジェクト（Session_Attributeオブジェクト）が含まれます。そのフラグフィールドには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を簡単に拡張して新しい要件をサポートできるようにします。さらに、このドキュメントは、Hop-by-Hopベースで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およびGMPLS非PSC LSPに等しく適用できます。
Table of Contents
目次
1. Introduction and Problem Statement ..............................3
1.1. Applicability to Generalized MPLS ..........................4
1.2. A Rejected Alternate Solution ..............................4
2. Terminology .....................................................5
3. Attributes TLVs .................................................5
3.1. Attributes Flags TLV .......................................6
4. LSP_ATTRIBUTES Object ...........................................6
4.1. Format .....................................................7
4.2. Generic Processing Rules for Path Messages .................7
4.3. Generic Processing Rules for Resv Messages .................8
5. LSP_REQUIRED_ATTRIBUTES Object ..................................9
5.1. Format .....................................................9
5.2. Generic Processing Rules ...................................9
6. Inheritance Rules ..............................................10
7. Recording Attributes Per LSP ...................................11
7.1. Requirements ..............................................11
7.2. RRO Attributes Subobject ..................................11
7.3. Procedures ................................................12
7.3.1. Subobject Presence Rules ...........................12
7.3.2. Reporting Compliance with LSP Attributes ...........12
7.3.3. Reporting Per-Hop Attributes .......................13
7.3.4. Default Behavior ...................................13
8. Summary of Attribute Bit Allocation ............................13
9. Message Formats ................................................14
10. Guidance for Key Application Scenarios ........................14
10.1. Communicating to Egress LSRs .............................15
10.2. Communicating to Key Transit LSRs ........................15
10.3. Communicating to All LSRs ................................16
11. IANA Considerations ...........................................16
11.1. New RSVP C-Nums and C-Types ..............................16
11.2. New TLV Space ............................................17
11.3. Attributes Flags .........................................17
11.4. New Error Codes ..........................................18
11.5. New Record Route Subobject Identifier ....................18
12. Security Considerations .......................................18
13. Acknowledgements ..............................................19
14. Normative References ..........................................19
15. Informative References ........................................19
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）ラベルスイッチ付きパス（LSPS）[RFC3031]は、RSVP-TEシグナル伝達プロトコル[RFC3209]のパスメッセージを使用してセットアップできます。パスメッセージには、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オブジェクトのフラグフィールドには8ビットがあります。これらのビットのうち3つのみが[RFC3209]に割り当てられています。さらに2ビットが[RFC4090]に割り当てられており、高速な再ルート機能を使用して3ビットのみを使用できます。いくつかの最近の提案とインターネットドラフトは、他の3つのビットの使用に対する高い需要があることを実証しています。これらの提案のすべてではないにしても、一部の提案は、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:
TLV形式の使用により、新しいRSVP-TEメッセージオブジェクトは非常に柔軟です。
- 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, and 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を参照）。この機能はRSVP-TEに拡張され、特定のオブジェクトを理解している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が行動する必要がある属性を区別します。このドキュメントでは、2つのLSP属性オブジェクトが定義されています。[RFC2205]から継承されたC-Num定義ルールを使用して、1つ目はそれを認識しないLSRによって透過的に渡され、2番目のLSPセットアップ障害が発生します。LSRがそれを認識しない場合、適切なエラーコードを使用します。
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.
RSVP-TEシグナル伝達プロトコルは、[RFC3471]および[RFC3473]に記載されているように、一般化されたMPLS（GMPLS）のシグナル伝達プロトコルの基礎も形成します。このドキュメントで説明されている拡張機能は、MPLSおよびGMPLに等しく適用できます。
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タイプは、より大きなフラグフィールドを可能にし、当面の問題に対処することができます。
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型は、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]からの用語を使用しています。また、[RFC3471]および[RFC3473]で導入された一般化されたMPLS RSVP-TE用語も使用しています。
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]に記載されているように解釈される。
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内でエンコードされます。各オブジェクトに1つ以上の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
長さ
The length of the Value field in bytes. Thus, if no Value field is present the Length field contains the value zero. Each Value field must be zero padded at the end to take it up to a four byte boundary -- the padding is not included in the length so that a one byte value would be encoded in an eight byte TLV with Length field set to one.
バイトフィールドの値フィールドの長さ。したがって、値フィールドが存在しない場合、長さフィールドに値ゼロが含まれます。各値フィールドは、4バイトの境界まで取得するために端にゼロパッドで塗装する必要があります。パディングは長さに含まれていないため、長さフィールドが1に設定された8バイトTLVで1バイト値がエンコードされます。
Value
価値
The data for the TLV padded as described above.
上記のようにパッドで埋められたTLVのデータ。
This document defines only one TLV type value. Type 1 indicates the Attributes Flags TLV. Other TLV types may be defined in the future with type values assigned by IANA (see Section 11.2).
このドキュメントでは、1つのTLVタイプ値のみを定義します。タイプ1は、属性フラグTLVを示します。他のTLVタイプは、IANAによって割り当てられたタイプの値で将来定義される場合があります（セクション11.2を参照）。
The Attributes 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 or 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は、セクション4および5で定義されているLSP_ATTRIBUTESオブジェクトおよび/またはLSP_Required_attributesオブジェクトに存在する場合があります。TLVのビットは、どのオブジェクトがTLVを運ぶかに関係なく同じ属性を表します。個々のビットを定義するドキュメントは、ビットを1つのオブジェクトまたは他のオブジェクトまたはその両方に設定できるかどうかを指定する必要があります。単一のパスメッセージの両方のオブジェクトで同時に少し設定されることは予想されませんが、これはこのドキュメントでは除外されていません。
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 4 bytes, regardless of the number of bits carried and no padding is required.
属性フラグTLV値フィールドは、ビットゼロとして最も重要なビットから番号が付けられた32フラグの単位の配列です。したがって、このTLVの長さフィールドは、運ばれるビット数に関係なく、常に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 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オブジェクトが対応するパスメッセージに携帯されていない場合でも、RESVでLSPの動作状態を報告するために使用できます。オブジェクトは、オブジェクトをサポートするLSRによって追加または更新されます。オブジェクトを理解していない、または報告するものがないLSRは、オブジェクトを追加せず、生成するRESVメッセージに変更されていません。
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オブジェクトクラスは、フォーム11bbbbbbbの197です。このC-Num値（[RFC2205]、セクション3.10を参照）は、オブジェクトを認識しないLSRが透過的に渡されることを保証します。
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メッセージに配置できます。
LSP_ATTRIBUTES class = 197, C-Type = 1
lsp_attributes class = 197、c-type = 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.
属性TLVは、セクション3で説明されているようにエンコードされます。
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].
このオブジェクトをサポートしていないLSRは、[RFC2205]で定義されているルールで示されているように、変更されていないものに渡す必要があります。
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.
このオブジェクトをサポートするが、このオブジェクトに掲載されているTLVタイプコードを認識しないLSRは、下流に送信するパスメッセージに配置するLSP_ATTRIBUTESオブジェクトにTLVを変更しないように渡す必要があります。
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 Attributes Flags TLV, but does not recognize a bit set in the Attributes Flags TLV, MUST forward the TLV unchanged.
属性フラグTLVをサポートするが、属性フラグTLVに少し設定されていることを認識していないLSRは、TLVを変更せずに転送する必要があります。
An LSR that supports the Attributes 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で説明されているように、レコードルートオブジェクト（RRO）のLSP属性サブオブジェクトを使用して達成されます。
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は、少し設定して特定のステータスを報告する場合があります。このステータスが達成されていないと判断したネットワーク内のLSRは、RESVメッセージを転送する際にビットをクリアする可能性があります。
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.
オブジェクトをサポートしていない、またはTLVの特定のビットによって特徴付けられる関数をサポートしないLSRは、RESVを転送するときにビットをクリアしないことを観察します。したがって、RESVでこのオブジェクトの使用を定義することには注意が必要です。resv上のlsp_attributesオブジェクトの属性TLVでの個々のビットの使用は、ビットを定義するドキュメントで完全に定義する必要があります。
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オブジェクトクラスは、フォーム0bbbbbbbbの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の望ましい属性に関する追加情報を伝えるためにパスメッセージに配置できます。
LSP_REQUIRED_ATTRIBUTES class = 67, C-Type = 1
lsp_required_attributes class = 67、c-type = 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.
属性TLVは、セクション3で説明されているようにエンコードされます。
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は、Patherrを使用して、エラーコード「不明なオブジェクトクラス」を使用してC-Numに基づいてパスメッセージを拒否します。
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.
このオブジェクトに掲載されているTLVタイプコードを認識しないLSRは、エラーコード「不明な属性TLV」および不明なTLVタイプコードの値に設定されたエラー値を使用してPATHERRを使用してパスメッセージを拒否する必要があります。
An LSR that does not recognize a bit set in the Attributes 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 Attributes Flags.
属性フラグに少し設定されていないLSRは、属性フラグの未知のビットのビット番号に設定されたエラーコード「不明な属性ビット」およびエラー値を使用して、Patherrを使用してパスメッセージを拒否する必要があります。
An LSR that recognizes an attribute (however encoded), but that 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のLSP_ATTRIBUTESオブジェクトまたはレコードルートオブジェクトの属性サブオブジェクト（セクション7を参照）のいずれかを使用する必要があります。
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_RESQIERD_ATTRIBUTESオブジェクトを運ぶLSPの確立が可能になります。この場合、境界LSRがLSP_ATTRIBUTESおよびLSP_REQURED_ATTRIBUTES処理をサポートする場合、FA-LSPは、特にFA-LSPが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を確立するために使用されるパスメッセージの継承された属性TLVに単純にコピーされます。デフォルトでは（および展開を簡素化するために）、着信LSP属性TLVは継承可能と見なされません。FA-LSPの確立自体が1つ以上の属性を必要とする場合、no 'または'操作は継承された値のセットで実行されることに注意してください。
Documents that define individual bits for the LSP Attributes 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属性のどれが適用されているかを判断することが有用です。たとえば、オブジェクトをサポートしていないLSRが属性をサポートしたり、要求された関数を提供する必要がないように、LSP_ATTRIBUTESオブジェクトで属性が要求される場合があります。この場合、リクエストに基づいてどのLSRが行動したか、どのLSRがそれを無視したかを知ることは、Ingress 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サブオブジェクトのフラグフィールドに示されています。この分野には8つのビットしかありません。一部はすでに割り当てられており、新しいドキュメントの割り当てが増加する可能性が高いため、HOPごとの属性を報告する他の方法が必要です。
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 Attributes 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 Attributes 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属性のsubobjectのビットとの間には、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 4 and must be at least 8.
長さには、タイプと長さのフィールドを含む、バイト内のサブオブジェクトの全長が含まれます。この長さは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がオブジェクトの開始にサブオブジェクトを追加する「スタック」として管理されます。属性Subobjectは、ノードのIPアドレスまたはリンク識別子を押す直前にすぐにRecord_Routeオブジェクトに押し込まれます。したがって、ラベル記録が使用されている場合、属性はレコードレーベルSubobject（s）の後に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、またはNoumbered Interface ID subobjectもプッシュせずに、属性を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を識別するサブオブジェクトのペア間で複数の属性がSubobjectが見つかった場合、最初に見つかったもの（つまり、スタックの上部に最も近い）のみが、このドキュメントのコンテキスト内に意味があります。そのようなすべてのサブオブジェクトは、トランジットLSRによって変更されずに転送される必要があります
To report compliance with an attribute requested in the Attributes 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は属性Subobjectに対応するビット（セクション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 Attribute 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.
受信した属性Subobjectが特定の番号付きビットを含めるのに十分な長さでない場合、そのビットは存在し、ゼロに設定されているかのように扱わなければなりません。
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 Attributes 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 Attributes Flags TLV and the RRO Attributes subobject. For example, an attribute may be requested using the Attributes 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属性Subobjectの両方で少し使用されるとは限らないことに注意してください。たとえば、属性フラグTLVを使用して属性を要求することもできますが、ホップバイホップベースで属性の処理を報告する要件はありません。逆に、LSPの属性をホップバイホップベースで報告する要件があるかもしれませんが、対応する要求属性はありません。
In these cases, a single bit number is still assigned for both the Attributes Flags TLV and the RRO Attributes subobject even though the bit may be irrelevant in either the Attributes 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属性の両方に、属性フラグまたはRRO属性のいずれかのいずれかでビットが無関係である場合でも、属性フラグTLVとrRO属性の両方に単一のビット番号が割り当てられます。新しいビットの使用法を定義するドキュメントは、それが使用されている場所を述べ、ゼロのデフォルト設定を処理する必要があります。
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_attributesオブジェクトとlsp_required_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.
パスメッセージでは、lsp_attributesオブジェクトとlsp_required_attributesオブジェクトは、session_attributeオブジェクトが存在する場合、またはlabel_requestオブジェクトの直後に配置することをお勧めします。
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 those objects MUST be forwarded unchanged.
LSRは、パスメッセージ内の任意の位置でこれらのオブジェクトを任意の順序で受信する準備をする必要があります。パスメッセージ内のこれらのオブジェクトの後続のインスタンスは無視する必要があり、それらのオブジェクトは変更されずに転送する必要があります。
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オブジェクトのコンテキスト内で意味があります。オブジェクトの後続のインスタンスは無視する必要があり、変化しないで転送する必要があります。
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属性は、LSPの出口LSRのみ、特定のキートランジットポイント（ABRやASBRなど）、または沿ったすべての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 Egress LSRのみで作用する必要があるLSP属性を通信する場合、属性はLSP_ATTRIBUTESオブジェクトで通信する必要があります。C-Numのため、このオブジェクトは、それを理解していないトランジットLSRによって無視され（前に通過し、手つかずの）ことができます。これは、オブジェクトを理解していない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属性が必要なLSP_ATTRIBUTESオブジェクト内で設定されます。各属性はいくつかの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が必要な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 may omit the RRO Attributes subobject implying that it has not satisfied the request.
出口LSRが、出力LSRの必須であると認められた属性を理解しているが、リクエストを満たすことを望まない場合、パスメッセージを拒否します。出口LSRが属性を理解しているが、それがオプションであると考えられており、リクエストを満たすことを望んでいない場合、RRO属性Subobjectへの違反を報告します。出力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.
キートランジットLSR（ABRやASBRなど）の処理は、出力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.
すべてのLSRにLSP属性を強制するために、LSP_REQUIRED_ATTRIBUTESオブジェクトが使用されます。このオブジェクトのc-Numは、オブジェクトを認識しないLSRは、オブジェクトを含む受信したパスメッセージを拒否する必要があります。
An LSR that recognizes the LSP_REQUIRED_ATTRIBUTES object, but does not recognize an attribute, will reject the Path message.
lsp_required_attributesオブジェクトを認識しているが、属性を認識しないLSRは、パスメッセージを拒否します。
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属性Subobjectを使用して属性をサポートするかどうかを報告する必要がある場合があります。
Two new RSVP C-Nums are defined in this document and have been assigned by IANA.
このドキュメントでは2つの新しい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.
c-num（value 197）はフォーム11bbbbbbbであるため、オブジェクトを認識しないLSRは、オブジェクトを無視しますが、このメッセージから生じるすべてのメッセージで、未検証と変更されていない転送を行います。
One C-Type is defined for this object and has been assigned by IANA.
このオブジェクトに対して1つのCタイプが定義され、IANAによって割り当てられています。
o LSP Attributes TLVs
o LSP属性TLV
Recommended C-Type value 1.
推奨されるCタイプ値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.
c-num（値67）はフォーム0bbbbbbbbであるため、オブジェクトを認識しないLSRは、「不明なオブジェクトクラス」エラーでそれを運ぶメッセージを拒否します。
One C-Type is defined for this object and has been assigned by IANA.
このオブジェクトに対して1つのCタイプが定義され、IANAによって割り当てられています。
o LSP Required Attributes TLVs
o LSPには、tlvsが必要です
Recommended C-Type value 1.
推奨されるCタイプ値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.
上記の2つの新しいオブジェクトは、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 -Field値）-TLV名 - lsp_attributesオブジェクトで許可されるかどうか - lsp_required_attributesオブジェクトで許可されているかどうか。
This document defines one TLV type as follows:
このドキュメントは、次のように1つのTLVタイプを定義します。
- TLV Type = 1 - TLV Name = Attributes Flags TLV - allowed on LSP_ATTRIBUTES object - allowed on LSP_REQUIRED_ATTRIBUTES object.
- TLV TYPE = 1 -TLV名=属性フラグTLV- lsp_attributesオブジェクトで許可-LSP_REQUIRED_ATTRIBUTESオブジェクトで許可されます。
New TLV type values may be allocated only by an IETF Consensus action.
新しいTLVタイプの値は、IETFコンセンサスアクションによってのみ割り当てられる場合があります。
This document provides new attributes bit flags for use in other documents that specify new RSVP-TE attributes. These flags are present in the Attributes 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.
IANAは新しいレジストリを作成し、ゼロから始まり、少なくとも31まで継続する通常のIETF表記でそれらを番号付けする属性のスペースを管理します。
New bit numbers may be allocated only by an IETF Consensus action.
新しいビット番号は、IETFコンセンサスアクションによってのみ割り当てられる場合があります。
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
- ビット番号-RFCの定義 - ビットの名前 - パス上の属性フラグTLVに意味があるかどうか - resv上の属性フラグTLVに意味があるかどうか
- Whether there is meaning in the RRO Attributes Subobject.
- RRO属性SubObjectに意味があるかどうか。
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属性Subobjectが、1つまたは両方の場所で使用されているかどうかに関係なく、同じビット番号を使用することを意味することに注意してください。したがって、維持する必要があるビットのリストは1つだけです。（このドキュメントのコンテキストでは、属性フラグTLVまたはRRO属性SubObjectのいずれにも意味がないことは意味がありません。）
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パスメッセージに2つの新しいオブジェクトを追加し、多くの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ワーキンググループのソリューションから同様の問題へのインスピレーションを求めています。この作業の慎重なレビューとサポートをしてくれたRahul Aggarwalに感謝します。また、レイモンド・チャン、キリエト・コンペラ、フィリップ・マシューズ、ジム・ギブソン、アラン・クルバーグにも感謝します。頻繁に、役に立つオフラインでの議論をしてくれたJohn Drakeに感謝します。ルーティングディレクターレビューを提供してくれたマイクシャンドに感謝し、一般的なエリアレビューのためにジョエルハルパーンに感謝します。
[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月。
[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] Braden、R。（ed。）、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[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トンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3471] Berger, L. (Ed.), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。（ed。）、「一般化されたマルチプロトコルラベルスイッチング（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] Berger、L。（ed。）、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Swallow、G。、およびA. Atlas、「LSPトンネルのRSVP-TEへの高速拡張式」、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、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、RFC 4206、2005年10月。
Authors' Addresses
著者のアドレス
Adrian Farrel Old Dog Consulting
エイドリアンファレルオールドドッグコンサルティング
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Dimitri Papadimitriou Alcatel Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel Fr.Wellesplein 1、B-2018 Antwerpen、ベルギー
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Jean Philippe Vasseur Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 USA
Jean Philippe Vasseur Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA -01719 USA
EMail: jpv@cisco.com
Arthi Ayyangar Juniper Networks, Inc. 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA
Arthi Ayyangar Juniper Networks、Inc。1194 N.Mathilda Ave Sunnyvale、CA 94089 USA
EMail: arthi@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。