RFC4420 日本語訳
4420 Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVationProtocol-Traffic Engineering (RSVP-TE). A. Farrel, Ed., D.Papadimitriou, J.-P. Vasseur, A. Ayyangar. February 2006. (Format: TXT=47235 bytes) (Updates RFC3209, RFC3473) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループのA.ファレル、エドをネットワークでつないでください。コメントのために以下を要求してください。 4420の古い犬のコンサルティングアップデート: 3209、3473D.Papadimitriouカテゴリ: 規格はアルカテルJ.-Pを追跡します。 A.Ayyangar杜松が2006年2月にネットワークでつなぐVasseurシスコシステムズInc.
Encoding of Attributes for Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) Establishment Using
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
(MPLS)がラベルするMultiprotocolラベルの切り換えのための属性のコード化は、資源予約プロトコル交通工学を使用することで経路(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
Multiprotocol Label Switching(MPLS)ラベルSwitched Paths(LSPs)は、Resource予約プロトコルTraffic Engineering(RSVP-TE)拡張子を使用することで設立されるかもしれません。 このプロトコルはLSPのオプションと属性を示すのに使用されるFlags野原を運ぶオブジェクト(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.
本書では定義されたオブジェクトメカニズムは等しくGeneralized MPLS(GMPLS)パケットSwitch Capable(PSC)LSPsと、そして、GMPLS非PSC LSPsに適切です。
Farrel, et al. Standards Track [Page 1] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[1ページ]RFC4420属性
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
1. 序論と問題声明…3 1.1. 一般化されたMPLSへの適用性…4 1.2. 拒絶された代替策…4 2. 用語…5 3. 属性TLVs…5 3.1. 属性はTLVに旗を揚げさせます…6 4. LSP_属性オブジェクト…6 4.1. 形式…7 4.2. ジェネリック処理は経路メッセージのために統治されます…7 4.3. ジェネリック処理はResvメッセージのために統治されます…8 5. LSP_は_属性オブジェクトを必要としました…9 5.1. 形式…9 5.2. ジェネリック処理は統治されます…9 6. 継承は統治されます…10 7. 1LSPあたりの属性を記録します…11 7.1. 要件…11 7.2. RRO属性Subobject…11 7.3. 手順…12 7.3.1. Subobject存在は統治します…12 7.3.2. LSP属性へのコンプライアンスを報告します…12 7.3.3. 1ホップあたりの属性を報告します…13 7.3.4. デフォルトの振舞い…13 8. 属性の概要は配分に噛み付きました…13 9. メッセージ形式…14 10. 主要なアプリケーションシナリオのための指導…14 10.1. 出口LSRsに、交信します…15 10.2. 主要なトランジットLSRsに、交信します…15 10.3. すべてのLSRsに、交信します…16 11. IANA問題…16 11.1. 新しいRSVP C-NumsとC-タイプ…16 11.2. 新しいTLVスペース…17 11.3. 属性旗…17 11.4. 新しいエラーコード…18 11.5. 新しい記録的なルートSubobject識別子…18 12. セキュリティ問題…18 13. 承認…19 14. 標準の参照…19 15. 有益な参照…19
Farrel, et al. Standards Track [Page 2] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[2ページ]RFC4420属性
1. Introduction and Problem Statement
1. 序論と問題声明
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.
トラフィックで設計されたMultiprotocol Label Switching(MPLS)ラベルSwitched Paths(LSPs)[RFC3031]はRSVP-TEシグナリングプロトコルに関するPathメッセージを使用するのに用意ができるかもしれません[RFC3209]。 PathメッセージはSESSION_ATTRIBUTEオブジェクトを含んでいます。(それは、LSPの希望のオプションと属性を示すのに使用されるFlags野原を運びます)。
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]で割り当てられます。 3ビットだけを利用可能な状態でおいて、より遠い2ビットは速い再コースを変更している機能性のために[RFC4090]で割り当てられます。 いくつかの最近の提案とインターネットDraftsは、他の3ビットの使用の高需要があるのを示しました。 それらの提案のいくつか(すべてでなくても)が前方に減少かほぼ将来開発されるかもしれない新しいオプションと属性に合図することにおけるFlags分野と結果の苦労の減少で結果になるRFCsに仮装して出演しそうです。
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メッセージのためのさらなる属性ビットのシグナリングを許容する新しいオブジェクトを定義します。 新しいオブジェクトはTLVsから組み立てられます、そして、新しい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 AttributesがLSPにおいて明確に見られることに注意してください。 同じソースと目的地(すなわち、同じセッション中の)の間には、同じTunnel IDがある状態で、別々のLSPsはそれらに異なってけしかけられるかもしれません。
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の経路に沿ったすべてのLabel Switched Routers(LSRs)によっていくつかのオプションと属性が影響される必要はないことに注意されます。 特に、これらのオプションと属性は経路のイングレスLSRや出口LSRなどの主要なLSRsだけに適用されるかもしれません。 また、AreaかAutonomous System Border Routersなどの特別なトランジットLSRs(ABRsかASBRs)はこのカテゴリになるかもしれません。 これは、新しいオプションと属性が透過的に合図されて、それらに影響する必要があるそれらのポイントで調べられるだけであるべきであることを意味します。
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の経路に沿ったすべてのトランジットLSRsで動作を必要とするかもしれません。 それらの1つによる必要な属性がトランジットLSRsであるとサポートすることができないことは、LSRがLSPの設立を拒否するのを必要とするかもしれません。
Farrel, et al. Standards Track [Page 3] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[3ページ]RFC4420属性
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.
これらの問題は後方の互換性の文脈で特に重要です。 一般に、レガシーネットワークの向こう側に新種業務で活躍する必要はないそれらのLSRsはアップグレードさせないで新しい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.
既にRFCsを先在させることにおける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に達して、特定のオブジェクトを理解しているそれらのLSRsだけがそれを調べるのを保証する早道を提供します。
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の経路に沿った主要なLSRsで必要であるだけである属性、およびLSPに沿ったあらゆるLSRが影響しなければならないものを見分けます。 2個のLSP Attributesオブジェクトが本書では定義されます: C-ヌム定義規則を使用するのは[RFC2205]から世襲されました、そして、1番目は透過的にそれを認識しないLSRsによって通過されます、そして、LSRがそれを認識しないなら、秒は適切なError CodeとのPathErrメッセージの世代と共にセットアップ失敗をLSPに引き起こします。
1.1. Applicability to Generalized MPLS
1.1. 一般化されたMPLSへの適用性
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シグナリングプロトコルはGeneralized MPLS(GMPLS)のために[RFC3471]と[RFC3473]で説明されるようにシグナリングプロトコルの基礎を形成します。 本書では説明された拡大は等しくMPLSとGMPLSに適切です。
1.2. A Rejected Alternate Solution
1.2. 拒絶された代替策
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-タイプは、より大きい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-タイプは1か7人のC-タイプに会うと予想する配布している実装と互換性があった状態で遅れていません。 それらのLSRsが属性に影響する必要はないならどんなソリューションも透過的にレガシーLSRsの向こう側に新しい属性を運ぶことができるのは、重要です。
Farrel, et al. Standards Track [Page 4] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[4ページ]RFC4420属性
- Support for arbitrary attributes parameters through TLVs would have
meant a significant change of substance to the existing object.
- TLVsを通した任意の属性パラメタのサポートは既存のオブジェクトへの物質の著しい変化を意味したでしょう。
2. Terminology
2. 用語
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-TEプロトコル仕様[RFC3209]から用語を使用します。プロトコル仕様はRSVP仕様[RFC2205]から世襲されます。 また、それは[RFC3471]と[RFC3473]で紹介されたGeneralized 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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Attributes TLVs
3. 属性TLVs
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.
本書では定義された新しいオブジェクトによって運ばれた属性はTLVsの中でコード化されます。 1TLVsが各オブジェクトに存在しているかもしれません。 注文規則は全くTLVsのためにありません、そして、TLVsが受け取られているオーダーに解釈を全く置くべきではありません。
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
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.
バイトで表現されるValue分野の長さ。 したがって、どんなValue分野も存在していないなら、Length分野は値ゼロを含んでいます。 それぞれのValue分野は4バイト境界まで分かる終わりにそっと歩いているゼロであるに違いありません--詰め物は、1バイトの値が8バイトのTLVでLength分野セットで1つにコード化されるように、長さに含まれていません。
Farrel, et al. Standards Track [Page 5] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[5ページ]RFC4420属性
Value
値
The data for the TLV padded as described above.
TLVのためのデータは上で説明されるようにそっと歩きました。
3.1. Attributes Flags TLV
3.1. 属性旗の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はAttributes Flags TLVを示します。 タイプ値がIANAによって割り当てられている状態で、他のTLVタイプは将来、定義されるかもしれません(セクション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.
Attributes Flags TLVはセクション4と5で定義されたLSP_ATTRIBUTESオブジェクト、そして/または、LSP_REQUIRED_ATTRIBUTESオブジェクトに存在しているかもしれません。 TLVのビットはのにかかわらずオブジェクトが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 4 bytes, regardless of the number of bits carried and no padding is required.
Attribute Flags TLV Value分野はビットゼロとして最も重要なビットから付番された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 MUSTを含みませんでした。ゼロに設定されると思われてください。 それがLSP_ATTRIBUTESかLSP_REQUIRED_ATTRIBUTESオブジェクトに含まれていないか、またはそれらのオブジェクトが自分たちで欠けているのでTLVが欠けるなら、まるでビットが存在していて、ゼロにセットするかのようにすべての処理を実行しなければなりません。 すなわち、TLVが故意に短縮されるか、またはTLVが含まれていないので存在していない割り当てられたビットは、まるでそれらが存在しているかのように扱わなければならなくて、ゼロに設定されます。
No bits are defined in this document. The assignment of bits is managed by IANA (see Section 11.3).
ビットは全く本書では定義されません。 ビットの課題はIANAによって管理されます(セクション11.3を見てください)。
4. LSP_ATTRIBUTES Object
4. LSP_属性オブジェクト
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を支持して必要である属性に合図するか、またはすべてのトランジットLSRsによって影響されるのにその情報が必要でないLSPの自然か使用を示すのに使用されます。 明確に、LSRがオブジェクトを支えないなら、それは非審査されていて変わりがない状態でそれを進めます。 これはこの新しいオブジェクトを支えないレガシーネットワークの向こう側に属性の交換を容易にします。
Farrel, et al. Standards Track [Page 6] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[6ページ]RFC4420属性
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オブジェクトでFlags分野を広げていて、TLVsを通して、より複雑なオブジェクトの将来の包含を考慮します。
Note that some function may require an LSR to inspect both the SESSION_ATTRIBUTE object and the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object.
何らかの機能が、LSRがSESSION_ATTRIBUTEオブジェクトとLSP_ATTRIBUTESかLSP_REQUIRED_ATTRIBUTESオブジェクトの両方を点検するのを必要とするかもしれないことに注意してください。
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オブジェクトも対応するPathメッセージで運ばれなかったときさえ、Resvに関してLSPの操作上の状態を報告するのに使用されるかもしれません。 オブジェクトは、オブジェクトを支えるLSRsによって加えられるか、またはアップデートされます。 オブジェクトを理解もしていませんし、何も報告すること持ってもいないLSRsがそれらが生成する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オブジェクトのクラスは197フォーム11bbbbbbです。 このC-ヌム値([RFC2205]、セクション3.10を見る)は、オブジェクトを認識しないLSRsが透過的にそれを伝えるのを確実にします。
One C-Type is defined, C-Type = 1 for LSP Attributes.
1つのC-タイプが定義されて、C-タイプはLSP Attributesのための=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の必要な属性に関する追加情報を伝えるPathメッセージと、そして、操作上の状態を報告するResvメッセージに置かれるかもしれません。
4.1. Format
4.1. 形式
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //属性TLVs//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attributes TLVs are encoded as described in Section 3.
Attributes TLVsはセクション3で説明されるようにコード化されます。
4.2. Generic Processing Rules for Path Messages
4.2. 経路メッセージのためのジェネリック処理規則
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が、C-ヌムと[RFC2205]で定義された規則で示されるように非変更されて、それを伝えるのに必要です。
Farrel, et al. Standards Track [Page 7] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[7ページ]RFC4420属性
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はそれが川下に発信するというPathメッセージに置く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.
Attributes Flags TLVをサポートしますが、Attributes Flags 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.
Attributes Flags TLVをサポートして、少し、それが設定されると認めますが、示された属性をサポートしないLSRはビットを定義するドキュメントで指定されるように行動しなければなりません。
4.3. Generic Processing Rules for Resv Messages
4.3. Resvメッセージのためのジェネリック処理規則
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で説明されるようにRecord Routeオブジェクト(RRO)のLSP Attributes subobjectを使用することで獲得されます。
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.
Attributes TLVのビットは、全体のLSPのために操作上の状態を報告するのに使用されるかもしれません。 例えば、出口LSRは、少しセットすることによって、特定の状態を報告するかもしれません。 彼らがResvメッセージを転送するとき、ネットワークの中のこの状態が獲得されていないことを決定するLSRsはビットをきれいにするかもしれません。
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を進めるとき、オブジェクトを支えないか、またはAttributes TLVの特定のビットによって特徴付けられた機能をサポートしないLSRsがビットをきれいにしないのを観測してください。 したがって、Resvでこのオブジェクトの使用法を定義しながら、注意を中に入れなければなりません。 ビットを定義するドキュメントでResvの上のLSP_ATTRIBUTESオブジェクトのAttributes TLVの個々のビットの使用法を完全に定義しなければなりません。
Additional TLVs may also be defined to be carried in this object on a Resv.
また、追加TLVsは、Resvでこのオブジェクトで運ばれるために定義されるかもしれません。
An LSR that does not support this object will pass it on unaltered because of the C-Num.
このオブジェクトを支えないLSRはC-ヌムのために非変更されていた状態でそれを伝えるでしょう。
Farrel, et al. Standards Track [Page 8] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[8ページ]RFC4420属性
5. LSP_REQUIRED_ATTRIBUTES Object
5. LSP_は_属性オブジェクトを必要としました。
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 MUSTは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オブジェクトでFlags分野を広げていて、TLVsを通して、より複雑なオブジェクトの将来の包含を考慮します。 それは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オブジェクトのクラスは67フォーム0bbbbbbbです。 このC-ヌム値は、オブジェクトを認識しないLSRsが事実上、彼らが要求された属性をサポートしないと言うLSPセットアップを拒絶するのを確実にします。 これは、このオブジェクトSHOULDが何らかのトランジットLSRsで支持を要するのですべてのトランジットLSRsで試験を必要とする属性に使用されるだけであることを意味します。 終わりの終わりの、そして、選択している属性がどう合図されるかためにセクション4を見てください。
One C-Type is defined, C-Type = 1 for LSP Required Attributes.
1つのC-タイプが定義されて、C-タイプはLSP Required Attributesのための=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メッセージに置かれるかもしれません。
5.1. Format
5.1. 形式
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //属性TLVs//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attributes TLVs are encoded as described in Section 3.
Attributes TLVsはセクション3で説明されるようにコード化されます。
5.2. Generic Processing Rules
5.2. ジェネリック処理規則
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は、Error Code「未知のオブジェクトのクラス」を使用することでC-ヌムに基づくPathメッセージを拒絶するのにPathErrを使用するでしょう。
Farrel, et al. Standards Track [Page 9] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[9ページ]RFC4420属性
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.
Error Code「未知の属性TLV」があるPathErrを使用して、このオブジェクトで運ばれたTLVタイプコードを認識しないLSRはPathメッセージを拒絶しなければなりません、そして、未知のTLVの値に用意ができているError Valueはコードをタイプします。
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.
Error Code「未知の属性ビット」があるPathErrを使用して、Attributes Flags TLVに少しセットするように認めないLSRはPathメッセージを拒絶しなければなりません、そして、Error ValueはAttributes Flagsの未知のビットの噛み付いている数にセットしました。
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オブジェクトかRecord Routeオブジェクト(セクション7を見る)のAttributes subobjectのどちらかを使用しなければなりません。
6. Inheritance Rules
6. 継承規則
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の設立を許容するためにセットアップされるLSP_ATTRIBUTES、そして/または、LSP_REQUIRED_ATTRIBUTESオブジェクトを運ぶ推進隣接番組。 この場合、LSR境界が、LSP_ATTRIBUTESとLSP_REQUIREDが_ATTRIBUTES処理であるとサポートすると、ローカルの方針のFA-LSP MAYはAttributes TLVsの部分集合を引き継ぎます、特定でFA-LSPが引き金となっているLSPと同じスイッチング能力のクラスのものと。
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メッセージの引き継いでいるAttributes TLVsと共に単にコピーされます。 デフォルトで(展開を簡素化するために)、入って来るLSP Attributes TLVsのいずれも相続可能であるとみなされません。 FA-LSP設立自体が1Attributes TLVsを必要とするとき、'OR'操作が引き継いでいる値で実行されることに注意してください。
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 Attributes Flags TLVのために個々のビットを定義するドキュメントは、これらのビットが引き継がれるかもしれないかどうか(この継承が起こるように会われるべき状態を含んでいます)指定しなければなりません。 同じくらいはセクション3で指定された規則に従って、定義されるいかなる他のTLVにも申し込みます。
Farrel, et al. Standards Track [Page 10] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[10ページ]RFC4420属性
7. Recording Attributes Per LSP
7. 1LSPあたりの属性を記録します。
7.1. Requirements
7.1. 要件
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属性のどれがLSPの経路に沿ったどのLSRsに適用されたかを決定するのは役に立ちます。 例えば、属性がLSP_ATTRIBUTESオブジェクトで要求されているかもしれないので、オブジェクトを支えないLSRsは属性をサポートするか、または要求された機能を提供する必要はありません。 この場合、どのLSRsが要求に影響したか、そして、どれがそれを無視したかを知るのはイングレス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 subobjectsのFlags分野で示されます。 この分野で有効な8ビットしかなくて、或るものが既に割り当てられて、新しいドキュメントには配分の増加がおそらくもあるので、1ホップあたりの属性を報告するある他のメソッドの必要があります。
7.2. RRO Attributes Subobject
7.2. RRO属性Subobject
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 Attributes SubobjectはRECORD_ROUTEオブジェクトで運ばれるかもしれません。 「副-オブジェクト」はRRO subobjectの標準書式を使用します。
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.
長さはAttributes Flags TLVのように可変です。 内容はAttribute Flags 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.
Attributes Flags TLVとRRO Attributes Subobjectのビットの間には、1〜1つの通信があります。 しばらくが2つの場所の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attribute Flags //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
0x05
0×05
Farrel, et al. Standards Track [Page 11] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[11ページ]RFC4420属性
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.
LengthはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 この長さは、4の倍数でなければならなく、少なくとも8であるに違いありません。
Attribute Flags
属性旗
The attribute flags recorded for the specific hop.
属性旗は特定のホップのために記録しました。
7.3. Procedures
7.3. 手順
7.3.1. Subobject Presence Rules
7.3.1. Subobject存在規則
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](_ROUTEが各LSRがオブジェクトの始まりに「副-オブジェクト」を加えていて「スタック」として管理されるのを反対させるRECORD)から明確であるときに ノードのIPアドレスかリンク識別子を押すすぐ前に、Attributes subobjectはRECORD_ROUTEオブジェクトに押されます。 その結果、録音はラベルであるなら使用されています、Attributes subobject SHOULD。Record Label 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、またはUnnumbered Interface ID「副-オブジェクト」を押さないで、ノードはRECORD_ROUTEオブジェクトにAttributes subobjectを押してはいけません。
This means that an Attributes subobject is bound to the LSR identified by the subobject found in the RRO immediately before the Attributes subobject.
これは、Attributes subobjectが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がPath(または、Resv)メッセージをうまくはめ込むことができないくらい大きいことを引き起こすなら、処理が.3セクション4.4[RFC3209]で説明されるようにあるに違いありません。
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
1Attributes subobjectがLSRsを特定する1組の「副-オブジェクト」の間で見つけられるなら、最初のものだけで、SHALLがこのドキュメントの文脈の中にどんな意味も持っているのがわかりました(すなわち、スタックの先端に最も近い)。 トランジットLSRsは変更されていなくそのようなすべての「副-オブジェクト」を進めなければなりません。
7.3.2. Reporting Compliance with LSP Attributes
7.3.2. LSP属性へのコンプライアンスを報告します。
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.
Attributes Flags TLVで要求されている属性へのコンプライアンスを報告するために、LSR MAYはAttributes subobjectに対応するビット(セクション8を見る)を設定しました。 不承諾、LSR MAYを報告するには、Attributes subobjectで対応するビットをきれいにしてください。
Farrel, et al. Standards Track [Page 12] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[12ページ]RFC4420属性
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.
どんなビットの使用法も定義するドキュメントでコンプライアンスを報告するという要件を指定しなければなりません。 これはホップごとの承認が必要であるかどうかに関する声明に減少するでしょう。
7.3.3. Reporting Per-Hop Attributes
7.3.3. 1ホップあたりの属性を報告します。
To report a per-hop attribute, an LSR sets the appropriate bit in the Attributes subobject.
1ホップあたり1つの属性を報告するために、LSRは適切なビットをAttributes subobjectにはめ込みます。
The requirement to report a per-hop attribute MUST be specified in the document that defines the usage of the bit.
ビットの使用法を定義するドキュメントで1ホップあたり1つの属性を報告するという要件を指定しなければなりません。
7.3.4. Default Behavior
7.3.4. デフォルトの振舞い
By default, all bits in an Attributes subobject SHOULD be set to zero.
Attributes subobject SHOULDにゼロにデフォルトで、そして、すべてのビット設定されてください。
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.
aが受信されたなら、Attribute 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 subobjectがLSPのホップのために存在していないなら、ゼロに設定されるとすべてのビットを思わなければなりません。
8. Summary of Attribute Bit Allocation
8. 属性ビット配分の概要
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.
このドキュメントはフラグビットがさばく1LSPあたりの属性の2つの用途を定義します。 Attributes Flags TLVとRRO Attributes subobjectでの噛み付いている付番は同じです。 すなわち、同じ属性は両方の場所で同じビットによって示されます。 これは、ビットの単一の登録だけが維持されることを意味します。
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.
しかしながら、それがAttributes Flags TLVとRRO Attributes subobjectの両方で少し使用されるのが、いつもケースであるというわけではないことに注意してください。 例えば、属性はAttributes Flags 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 FlagsかRROのどちらかで無関係であるかもしれませんが、1つの噛み付いている数がAttributes Flags TLVとRRO Attributes subobjectの両方のためにまだ割り当てられています。
Farrel, et al. Standards Track [Page 13] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[13ページ]RFC4420属性
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.
属性「副-オブジェクト」。 新しいビットの使用法を定義するドキュメントは、それがどの場所で使用されているかを述べなければならなくて、ゼロの既定の設定を扱わなければなりません。
9. Message Formats
9. メッセージ・フォーマット
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オブジェクトはPathメッセージで運ばれるかもしれません。 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メッセージでは、それが現在である、またはLABEL_REQUESTオブジェクト直後そうでないなら、LSP_ATTRIBUTESオブジェクトとLSP_REQUIRED_ATTRIBUTESオブジェクトはSESSION_ATTRIBUTEオブジェクト直後置かれるべきRECOMMENDEDです。
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オブジェクトは最初に置かれるべきRECOMMENDEDです。
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.
Pathメッセージの中のあらゆる見解に順不同なこれらのオブジェクトを受け取るようにLSRsを準備しなければなりません。 SHOULDを無視されて、変わりがない状態で進めなければならないというものが、反対する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オブジェクト直後置かれるのは、RECOMMENDEDです。
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.
前の注意を条件としたResvメッセージの中のあらゆる見解に順不同なこのオブジェクトを受け取るようにLSRsを準備しなければなりません。 LSP_ATTRIBUTESオブジェクトの1つのインスタンスだけがFILTER_SPECオブジェクトの文脈の中で重要です。 オブジェクトSHOULDのその後のインスタンスを無視して、変わりがない状態で進めなければなりません。
10. Guidance for Key Application Scenarios
10. 主要なアプリケーションシナリオのための指導
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.
このドキュメントのIntroduction部で説明されるように、多分要求されたLSP属性は、LSPの出口だけLSR、ある一定の主要な乗り継ぎ地点(ABRsやASBRsなどの)、またはLSPに沿ったすべてのLSRsによって影響される必要があります。 このセクションは簡潔にそれぞれのこれらのシナリオがどう満たされるかを説明します。 このセクションは、情報であり、どんな新しい手順も定義しません。
Farrel, et al. Standards Track [Page 14] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[14ページ]RFC4420属性
10.1. Communicating to Egress LSRs
10.1. 出口LSRsに、交信します。
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出口LSRが影響しなければならないLSP属性を伝えるとき、属性はLSP_ATTRIBUTESオブジェクトで伝えられるべきです。 C-ヌムのために、このオブジェクトが無視されるかもしれない、(前方へ通過される、触れなさ、)、それを理解していないトランジットLSRsで。 これは、Pathメッセージがオブジェクトを理解していないLSRsによって拒絶されないことを意味します。 このように、要求された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 Attributes subobjectを使用しなければなりません。
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に義務的であるとして容認された属性を理解していますが、要望に応じたがっていなくて、それはPathメッセージを拒絶するでしょう。 出口であるなら、LSRは属性を理解しています、それが任意であると信じていて、要望に応じることを願っていないのを除いてそれはRRO Attributes subobjectで不承諾を報告するでしょう。 出口LSRが容認された属性を理解していないなら、それは、RRO Attributes subobjectで明らかに不承諾を報告するか、または要望に応じていないのを含意するRRO Attributes subobjectを省略するかもしれません。
10.2. Communicating to Key Transit LSRs
10.2. 主要なトランジットLSRsに、交信します。
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.
主要なトランジットLSRs(ABRsやASBRsなどの)のための処理はちょうど出口LSRのように続きます。 唯一の違いはRFCが述べる定義とのLSP属性の属性がそうしなければならない定義がこれらのトランジットLSRsによって影響されるということです。
Farrel, et al. Standards Track [Page 15] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[15ページ]RFC4420属性
10.3. Communicating to All LSRs
10.3. すべてのLSRsに、交信します。
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.
すべてのLSRsにLSP属性を調べさせるように、LSP_REQUIRED_ATTRIBUTESオブジェクトは使用されています。 このオブジェクトのC-ヌムがそのようなものであるので、オブジェクトを認識しないどんな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.
定義しているRFCとの属性の定義に従って、属性を認識しますが、属性をサポートしたがっていないLSRは反応します。 これは、LSRが属性を無視して、変わりがない状態でそれを進めるのを許容するか、またはLSPセットアップに失敗するようにそれを必要とするかもしれません。 それがRRO Attributes subobjectを使用することで属性をサポートするか否かに関係なく、LSRはさらに、報告しなければならないかもしれません。
11. IANA Considerations
11. IANA問題
11.1. New RSVP C-Nums and C-Types
11.1. 新しいRSVP C-NumsとC-タイプ
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-ヌム(値197)はオブジェクトを認識しないLSRsがオブジェクトを無視するためのフォーム11bbbbbbのものですが、このメッセージから生じながら、すべてのメッセージで非審査されて変更されていないそれを進めてください。
One C-Type is defined for this object and has been assigned by
IANA.
1つのC-タイプが、このオブジェクトのために定義されて、IANAによって選任されました。
o LSP Attributes TLVs
o LSP属性TLVs
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-ヌム(値67)は、オブジェクトを認識しないLSRsが「未知のオブジェクトのクラス」誤りでそれを運ぶメッセージを拒絶するためのフォーム0bbbbbbbのものです。
One C-Type is defined for this object and has been assigned by
IANA.
1つのC-タイプが、このオブジェクトのために定義されて、IANAによって選任されました。
Farrel, et al. Standards Track [Page 16] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[16ページ]RFC4420属性
o LSP Required Attributes TLVs
o LSPは属性TLVsを必要としました。
Recommended C-Type value 1.
お勧めのC-タイプは1を評価します。
11.2. New TLV Space
11.2. 新しいTLVスペース
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個の新しいオブジェクトがTLVsから組み立てられます。 各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.
- LSP_ATTRIBUTESに許容されているか否かに関係なく、LSP_REQUIRED_ATTRIBUTESオブジェクトの上に許容されているか否かに関係なく、TLV Type(T-分野値)(TLV Name)は反対します。
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 NameはLSP_REQUIRED_ATTRIBUTESオブジェクトの上に許容された属性Flags TLV(LSP_ATTRIBUTESオブジェクトの上に許容されている)と等しいです。
New TLV type values may be allocated only by an IETF Consensus action.
単にIETF Consensus動作で新しいTLVタイプ値を割り当てるかもしれません。
11.3. Attributes Flags
11.3. 属性旗
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属性を指定する他のドキュメントにおける使用のために旗を揚げさせる新しい属性を提供します。 これらの旗は前項で参照をつけられるAttributes Flags 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 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
- そこであるか否かに関係なく、RFCを定義するという数が命名する意味がPathの上のAttribute Flags TLVにあるか否かに関係なく、ビットのビットはResvの上のAttribute Flags TLVでの意味です。
Farrel, et al. Standards Track [Page 17] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[17ページ]RFC4420属性
- Whether there is meaning in the RRO Attributes Subobject.
- 意味がRRO Attributes 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.)
これが、Attribute Flags TLVとRRO Attributes Subobjectのすべてのビットがそれらが1か両方で使用されるかどうかにかかわらず数が置く同じビットを使用することを意味することに注意してください。 ビットの1つのリストだけが、維持されるのに必要です。 (しばらくこのドキュメントの文脈では、Attribute Flags TLVかRRO Attributes Subobjectのどちらかに意味でないのを持っているのは無意味でしょう。)
11.4. New Error Codes
11.4. 新しいエラーコード
This document defines the following new Error Codes and Error Values. Numeric values have been assigned by IANA.
このドキュメントは以下の新しいError CodesとError Valuesを定義します。 数値はIANAによって割り当てられました。
Error Code Error Value 29 "Unknown Attributes TLV" Identifies the unknown TLV type code. 30 "Unknown Attributes Bit" Identifies the unknown Attribute Bit.
誤りCode Error Value29「未知の属性TLV」Identifiesの未知のTLVはコードをタイプします。 30 「未知の属性ビット」Identifiesの未知のAttribute Bit。
11.5. New Record Route Subobject Identifier
11.5. 新しい記録的なルートSubobject識別子
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 Attributes subobjectは5のType値によって特定されます。
12. Security Considerations
12. セキュリティ問題
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シグナリングに使用されるように2個の新しいオブジェクトをRSVP Pathメッセージに追加します、そして、RECORD_ROUTEオブジェクトへの新しい「副-オブジェクト」は多くのRSVPメッセージで運ばれました。 それは少しの新しいダイレクト安全保障問題も紹介しません、そして、読者は[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の状態と個々のLSRsの能力の情報を明らかにするかもしれません。 また、他のRRO subobjectsに適用されるのと同じ戦略はここに適用されます。 しかしながら、トランジットLSRsでLSP状態のギヤエンドに通知して、トランジットLSRsの存在かアイデンティティを隠すとき、緊張があることに注意してください。
Farrel, et al. Standards Track [Page 18] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[18ページ]RFC4420属性
13. Acknowledgements
13. 承認
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は働いています。 また、彼らの入力をレイモンド・チャン、Kireeti Kompella、フィリップ・マシューズ、ジム・ギブソン、およびアランKullbergをありがとうございます。 そうとして、しばしば、役に立つオフライン議論のためにジョン・ドレイクをありがとうございます。 ルート設定Directorateレビューを提供するためのマイク・シャンドと、そして、一般Areaレビューのためのジョエル・アルペルンへの感謝--両方がいくらかの「非-明瞭さ」で回復しました。
14. Normative References
14. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.
R.編(チャン)の[RFC2205]ブレーデン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、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.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3471] Berger, L. (Ed.), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3471]バーガー、L.編、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、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)拡大」、RFC3473、2003年1月。
15. Informative References
15. 有益な参照
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換えアーキテクチャ」、RFC3031、2001年1月。
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[RFC4090]のなべ、P.、ツバメ、G.、およびA.Atlas(「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ってください」、RFC4090)は2005がそうするかもしれません。
[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)を階層構造とラベルします」、RFC4206、2005年10月。
Farrel, et al. Standards Track [Page 19] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[19ページ]RFC4420属性
Authors' Addresses
作者のアドレス
Adrian Farrel Old Dog Consulting
エードリアンのファレルの古い犬のコンサルティング
Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
以下に電話をしてください。 +44 (0) 1978 860944はメールされます: adrian@olddog.co.uk
Dimitri Papadimitriou Alcatel Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルフラン。 Wellesplein1、B-2018アントウェルペン(ベルギー)
Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
以下に電話をしてください。 +32 3 240-8491 メールしてください: dimitri.papadimitriou@alcatel.be
Jean Philippe Vasseur Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 USA
マサチューセッツ通りBoxborough、ジーンフィリップVasseurシスコシステムズInc.1414MA--01719米国
EMail: jpv@cisco.com
メール: jpv@cisco.com
Arthi Ayyangar Juniper Networks, Inc. 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA
Arthi Ayyangar杜松はInc.1194N.マチルダ・Aveカリフォルニア94089サニーベル(米国)をネットワークでつなぎます。
EMail: arthi@juniper.net
メール: arthi@juniper.net
Farrel, et al. Standards Track [Page 20] RFC 4420 Attributes for MPLS LSPs Using RSVP-TE February 2006
ファレル、他 2006年2月にRSVP-Teを使用するMPLS LSPsのための標準化過程[20ページ]RFC4420属性
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Farrel, et al. Standards Track [Page 21]
ファレル、他 標準化過程[21ページ]
一覧
スポンサーリンク
