[要約] RFC 5467は、GMPLSにおける非対称帯域幅の双方向ラベルスイッチドパス（LSPs）に関する要約です。このRFCの目的は、非対称な帯域幅を持つLSPsの設定と制御に関するガイドラインを提供することです。
Network Working Group L. Berger
Request for Comments: 5467 LabN
Category: Experimental A. Takacs
Ericsson
D. Caviglia
Ericsson
D. Fedyk
Nortel
J. Meuric
France Telecom
March 2009
GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
GMPLS非対称帯域幅双方向ラベルスイッチ付きパス（LSP）
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. The procedures described in this document are experimental.
このドキュメントは、GMPLS非対称帯域幅の双方向ラベルスイッチされたパス（LSP）のサポートの方法を定義します。提示されたアプローチは、任意のスイッチングテクノロジーに適用され、トラフィック関連パラメーターの輸送のための元のリソース予約プロトコル（RSVP）モデルに基づいています。このドキュメントで説明されている手順は実験的です。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Background .................................................3
1.2. Approach Overview ..........................................3
1.3. Conventions Used in This Document ..........................4
2. Generalized Asymmetric Bandwidth Bidirectional LSPs .............4
2.1. UPSTREAM_FLOWSPEC Object ...................................5
2.1.1. Procedures ..........................................5
2.2. UPSTREAM_TSPEC Object ......................................5
2.2.1. Procedures ..........................................5
2.3. UPSTREAM_ADSPEC Object .....................................6
2.3.1. Procedures ..........................................6
3. Packet Formats ..................................................6
4. Compatibility ...................................................7
5. IANA Considerations .............................................8
5.1. UPSTREAM_FLOWSPEC Object ...................................8
5.2. UPSTREAM_TSPEC Object ......................................8
5.3. UPSTREAM_ADSPEC Object .....................................8
6. Security Considerations .........................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
Appendix A. Alternate Approach Using ADSPEC Object.................11
A.1. Applicability .............................................11
A.2. Overview ..................................................11
A.3. Procedures ................................................12
A.4. Compatibility .............................................13
GMPLS [RFC3473] introduced explicit support for bidirectional Label Switched Paths (LSPs). The defined support matched the switching technologies covered by GMPLS, notably Time Division Multiplexing (TDM) and lambdas; specifically, it only supported bidirectional LSPs with symmetric bandwidth allocation. Symmetric bandwidth requirements are conveyed using the semantics objects defined in [RFC2205] and [RFC2210].
GMPLS [RFC3473]は、双方向ラベルスイッチドパス（LSP）の明示的なサポートを導入しました。定義されたサポートは、GMPLSで覆われたスイッチングテクノロジー、特に時分割多重化（TDM）とラムダスと一致しました。具体的には、対称帯域幅の割り当てで双方向LSPのみをサポートしました。対称帯域幅要件は、[RFC2205]および[RFC2210]で定義されたセマンティクスオブジェクトを使用して伝達されます。
Recent work ([GMPLS-PBBTE] and [MEF-TRAFFIC]) has looked at extending GMPLS to control Ethernet switching. In this context, there has been discussion of the support of bidirectional LSPs with asymmetric bandwidth. (That is, bidirectional LSPs that have different bandwidth reservations in each direction.) This discussion motivated the extensions defined in this document, which may be used with any switching technology to signal asymmetric bandwidth bidirectional LSPs. The procedures described in this document are experimental.
最近の研究（[GMPLS-PBBTE]および[MEF-Traffic]）は、GMPLSを拡張してイーサネットスイッチングを制御することを検討しました。これに関連して、非対称帯域幅を伴う双方向LSPの支持について議論されています。（つまり、各方向に帯域幅の予約が異なる双方向LSP。）この議論は、このドキュメントで定義されている拡張機能を動機付けました。このドキュメントで説明されている手順は実験的です。
Bandwidth parameters are transported within RSVP ([RFC2210], [RFC3209], and [RFC3473]) via several objects that are opaque to RSVP. While opaque to RSVP, these objects support a particular model for the communication of bandwidth information between an RSVP session sender (ingress) and receiver (egress). The original model of communication, defined in [RFC2205] and maintained in [RFC3209], used the SENDER_TSPEC and ADSPEC objects in Path messages and the FLOWSPEC object in Resv messages. The SENDER_TSPEC object was used to indicate a sender's data generation capabilities. The FLOWSPEC object was issued by the receiver and indicated the resources that should be allocated to the associated data traffic. The ADSPEC object was used to inform the receiver and intermediate hops of the actual resources allocated for the associated data traffic.
帯域幅パラメーターは、RSVP（[RFC2210]、[RFC3209]、および[RFC3473]）内でRSVPに不透明ないくつかのオブジェクトを介して輸送されます。RSVPに不透明になっている間、これらのオブジェクトは、RSVPセッション送信者（Ingress）と受信機（Egress）の間の帯域幅情報の通信のための特定のモデルをサポートしています。[RFC2205]で定義され、[RFC3209]で維持されている通信の元のモデルは、PATHメッセージにSender_TSPECおよびADSPECオブジェクトを使用し、RESVメッセージでFlowsPecオブジェクトを使用しました。Sender_TSPECオブジェクトを使用して、送信者のデータ生成機能を示しました。FlowsPecオブジェクトはレシーバーによって発行され、関連するデータトラフィックに割り当てる必要があるリソースを示しました。ADSPECオブジェクトを使用して、関連するデータトラフィックに割り当てられた実際のリソースの受信機と中間ホップに通知しました。
With the introduction of bidirectional LSPs in [RFC3473], the model of communication of bandwidth parameters was implicitly changed. In the context of [RFC3473] bidirectional LSPs, the SENDER_TSPEC object indicates the desired resources for both upstream and downstream directions. The FLOWSPEC object is simply confirmation of the allocated resources. The definition of the ADSPEC object is either unmodified and only has meaning for downstream traffic, or is implicitly or explicitly ([RFC4606] and [MEF-TRAFFIC]) irrelevant.
[RFC3473]に双方向LSPの導入により、帯域幅パラメーターの通信モデルが暗黙的に変更されました。[RFC3473]双方向LSPのコンテキストでは、sender_tspecオブジェクトは、上流方向と下流方向の両方の望ましいリソースを示します。FlowsPecオブジェクトは、割り当てられたリソースの単なる確認です。ADSPECオブジェクトの定義は、変更されておらず、下流のトラフィックに対してのみ意味があるか、暗黙的または明示的に（[RFC4606]および[MEFトラフィック]）無関係です。
The approach for supporting asymmetric bandwidth bidirectional LSPs defined in this document builds on the original RSVP model for the transport of traffic-related parameters and GMPLS's support for bidirectional LSPs. An alternative approach was considered and rejected in favor of the more generic approach presented below. For reference purposes only, the rejected approach is summarized in Appendix A.
このドキュメントで定義された非対称帯域幅の双方向LSPをサポートするためのアプローチは、交通関連のパラメーターの輸送と双方向LSPのサポートのための元のRSVPモデルに基づいています。代替アプローチが考慮され、以下に示すより一般的なアプローチを支持して拒否されました。参照目的のためにのみ、拒否されたアプローチは付録Aに要約されています。
The defined approach is generic and can be applied to any switching technology supported by GMPLS. With this approach, the existing SENDER_TSPEC, ADSPEC, and FLOWSPEC objects are complemented with the addition of new UPSTREAM_TSPEC, UPSTREAM_ADSPEC, and UPSTREAM_FLOWSPEC objects. The existing objects are used in the original fashion defined in [RFC2205] and [RFC2210], and refer only to traffic associated with the LSP flowing in the downstream direction. The new objects are used in exactly the same fashion as the old objects, but refer to the upstream traffic flow. Figure 1 shows the bandwidth-related objects used for asymmetric bandwidth bidirectional LSPs.
定義されたアプローチは一般的であり、GMPLSがサポートするスイッチングテクノロジーに適用できます。このアプローチにより、既存のsender_tspec、adspec、およびflowspecオブジェクトは、新しいupstream_tspec、upstream_adspec、およびupstream_flowspecオブジェクトの追加により補完されます。既存のオブジェクトは、[RFC2205]および[RFC2210]で定義された元のファッションで使用され、下流方向に流れるLSPに関連するトラフィックのみを参照しています。新しいオブジェクトは、古いオブジェクトとまったく同じ方法で使用されますが、上流のトラフィックフローを参照してください。図1は、非対称帯域幅の双方向LSPに使用される帯域幅関連オブジェクトを示しています。
|---| Path |---|
| I |------------------->| E |
| n | -SENDER_TSPEC | g |
| g | -ADSPEC | r |
| r | -UPSTREAM_FLOWSPEC | e |
| e | | s |
| s | Resv | s |
| s |<-------------------| |
| | -FLOWSPEC | |
| | -UPSTREAM_TSPEC | |
| | -UPSTREAM_ADSPEC | |
|---| |---|
Figure 1: Generic Asymmetric Bandwidth Bidirectional LSPs
図1：一般的な非対称帯域幅の双方向LSP
The extensions defined in this document are limited to Point-to-Point (P2P) LSPs. Support for Point-to-Multipoint (P2MP) bidirectional LSPs is not currently defined and, as such, not covered in this document.
このドキュメントで定義されている拡張機能は、ポイントツーポイント（P2P）LSPに限定されています。ポイントツーマルチポイント（P2MP）の双方向LSPのサポートは現在定義されておらず、このドキュメントではカバーされていません。
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]に記載されているように解釈される。
The setup of an asymmetric bandwidth bidirectional LSP is signaled using the bidirectional procedures defined in [RFC3473] together with the inclusion of the new UPSTREAM_FLOWSPEC, UPSTREAM_TSPEC, and UPSTREAM_ADSPEC objects.
非対称帯域幅の双方向LSPのセットアップは、[RFC3473]で定義された双方向手順を使用して、新しいupstream_flowspec、upstream_tspec、およびupstream_adspecオブジェクトを含めることとともに合図されます。
The new upstream objects carry the same information and are used in the same fashion as the existing downstream objects; they differ in that they relate to traffic flowing in the upstream direction while the existing objects relate to traffic flowing in the downstream direction. The new objects also differ in that they are used on messages in the opposite directions.
新しいアップストリームオブジェクトは同じ情報を持ち、既存のダウンストリームオブジェクトと同じ方法で使用されます。それらは、既存のオブジェクトが下流方向に流れるトラフィックに関連している間、上流の方向に流れるトラフィックに関係するという点で異なります。また、新しいオブジェクトは、反対方向のメッセージで使用されるという点でも異なります。
The format of an UPSTREAM_FLOWSPEC object is the same as a FLOWSPEC object. This includes the definition of class types and their formats. The class number of the UPSTREAM_FLOWSPEC object is 120 (of the form 0bbbbbbb).
upstream_flowspecオブジェクトの形式は、flowspecオブジェクトと同じです。これには、クラスタイプの定義とその形式が含まれます。upstream_flowspecオブジェクトのクラス番号は120（フォーム0bbbbbbbb）です。
The Path message of an asymmetric bandwidth bidirectional LSP MUST contain an UPSTREAM_FLOWSPEC object and MUST use the bidirectional LSP formats and procedures defined in [RFC3473]. The C-Type of the UPSTREAM_FLOWSPEC object MUST match the C-Type of the SENDER_TSPEC object used in the Path message. The contents of the UPSTREAM_FLOWSPEC object MUST be constructed using a format and procedures consistent with those used to construct the FLOWSPEC object that will be used for the LSP, e.g., [RFC2210] or [RFC4328].
非対称帯域幅の双方向LSPのパスメッセージには、[RFC3473]で定義されている双方向LSP形式と手順を使用する必要があります。upstream_flowspecオブジェクトのc型は、パスメッセージで使用されるsender_tspecオブジェクトのc型と一致する必要があります。upstream_flowspecオブジェクトの内容は、LSP（RFC2210]または[RFC4328]に使用されるFlowsPecオブジェクトを構築するために使用される形式と一致する形式と手順を使用して構築する必要があります。
Nodes processing a Path message containing an UPSTREAM_FLOWSPEC object MUST use the contents of the UPSTREAM_FLOWSPEC object in the upstream label and the resource allocation procedure defined in Section 3.1 of [RFC3473]. Consistent with [RFC3473], a node that is unable to allocate a label or internal resources based on the contents of the UPSTREAM_FLOWSPEC object MUST issue a PathErr message with a "Routing problem/MPLS label allocation failure" indication.
ノードupstream_flowspecオブジェクトを含むパスメッセージの処理アップストリームラベルのupstream_flowspecオブジェクトのコンテンツと[RFC3473]のセクション3.1で定義されているリソース割り当て手順を使用する必要があります。[RFC3473]と一致して、upstream_flowspecオブジェクトの内容に基づいてラベルまたは内部リソースを割り当てることができないノードは、「ルーティング問題/MPLSラベル割り当て障害」の表示を持つPatherRメッセージを発行する必要があります。
The format of an UPSTREAM_TSPEC object is the same as a SENDER_TSPEC object. This includes the definition of class types and their formats. The class number of the UPSTREAM_TSPEC object is 121 (of the form 0bbbbbbb).
upstream_tspecオブジェクトの形式は、sender_tspecオブジェクトと同じです。これには、クラスタイプの定義とその形式が含まれます。upstream_tspecオブジェクトのクラス番号は121（フォーム0bbbbbbbb）です。
The UPSTREAM_TSPEC object describes the traffic flow that originates at the egress. The UPSTREAM_TSPEC object MUST be included in any Resv message that corresponds to a Path message containing an UPSTREAM_FLOWSPEC object. The C-Type of the UPSTREAM_TSPEC object MUST match the C-Type of the corresponding UPSTREAM_FLOWSPEC object. The contents of the UPSTREAM_TSPEC object MUST be constructed using a format and procedures consistent with those used to construct the FLOWSPEC object that will be used for the LSP, e.g., [RFC2210] or [RFC4328]. The contents of the UPSTREAM_TSPEC object MAY differ from contents of the UPSTREAM_FLOWSPEC object based on application data transmission requirements.
upstream_tspecオブジェクトは、出口で発生するトラフィックフローを記述します。upstream_tspecオブジェクトは、upstream_flowspecオブジェクトを含むパスメッセージに対応する任意のRESVメッセージに含める必要があります。upstream_tspecオブジェクトのc型は、対応するupstream_flowspecオブジェクトのc型と一致する必要があります。upstream_tspecオブジェクトの内容は、LSPに使用されるFlowsPecオブジェクトを構築するために使用される形式と手順を使用して構築する必要があります[RFC2210]または[RFC4328]。upstream_tspecオブジェクトの内容は、アプリケーションデータ送信要件に基づいてupstream_flowspecオブジェクトの内容とは異なる場合があります。
When an UPSTREAM_TSPEC object is received by an ingress, the ingress MAY determine that the original reservation is insufficient to satisfy the traffic flow. In this case, the ingress MAY issue a Path message with an updated UPSTREAM_FLOWSPEC object to modify the resources requested for the upstream traffic flow. This modification might require the LSP to be re-routed, and in extreme cases might result in the LSP being torn down when sufficient resources are not available.
Upstream_TSPECオブジェクトが侵入によって受信されると、侵入は、元の予約がトラフィックの流れを満たすには不十分であると判断する場合があります。この場合、Ingressは更新されたupstream_flowspecオブジェクトを使用してパスメッセージを発行して、アップストリームトラフィックフローの要求されたリソースを変更する場合があります。この変更では、LSPを再ルーティングする必要があり、極端な場合には、十分なリソースが利用できない場合、LSPが取り壊される可能性があります。
The format of an UPSTREAM_ADSPEC object is the same as an ADSPEC object. This includes the definition of class types and their formats. The class number of the UPSTREAM_ADSPEC object is 122 (of the form 0bbbbbbb).
upstream_adspecオブジェクトの形式は、ADSPECオブジェクトと同じです。これには、クラスタイプの定義とその形式が含まれます。upstream_adspecオブジェクトのクラス番号は122（フォーム0bbbbbbbb）です。
The UPSTREAM_ADSPEC object MAY be included in any Resv message that corresponds to a Path message containing an UPSTREAM_FLOWSPEC object. The C-Type of the UPSTREAM_TSPEC object MUST be consistent with the C-Type of the corresponding UPSTREAM_FLOWSPEC object. The contents of the UPSTREAM_ADSPEC object MUST be constructed using a format and procedures consistent with those used to construct the ADSPEC object that will be used for the LSP, e.g., [RFC2210] or [MEF-TRAFFIC]. The UPSTREAM_ADSPEC object is processed using the same procedures as the ADSPEC object and, as such, MAY be updated or added at transit nodes.
upstream_adspecオブジェクトは、upstream_flowspecオブジェクトを含むパスメッセージに対応する任意のRESVメッセージに含めることができます。upstream_tspecオブジェクトのc型は、対応するupstream_flowspecオブジェクトのc型と一致する必要があります。upstream_adspecオブジェクトの内容は、LSPに使用されるADSPECオブジェクトを構築するために使用される形式と手順を使用して構築する必要があります[RFC2210]または[MEFトラフィック]。upstream_adSpecオブジェクトは、ADSPECオブジェクトと同じ手順を使用して処理され、そのため、トランジットノードで更新または追加される場合があります。
This section presents the RSVP message-related formats as modified by this section. This document modifies formats defined in [RFC2205], [RFC3209], and [RFC3473]. See [RSVP-BNF] for the syntax used by RSVP. Unmodified formats are not listed. Three new objects are defined in this section:
このセクションでは、このセクションで変更されたRSVPメッセージ関連形式を示します。このドキュメントは、[RFC2205]、[RFC3209]、および[RFC3473]で定義されている形式を変更します。RSVPで使用される構文については、[RSVP-BNF]を参照してください。変更されていない形式はリストされていません。このセクションでは、3つの新しいオブジェクトが定義されています。
Object name Applicable RSVP messages
--------------- ------------------------
UPSTREAM_FLOWSPEC Path, PathTear, PathErr, and Notify
(via sender descriptor)
UPSTREAM_TSPEC Resv, ResvConf, ResvTear, ResvErr, and
Notify (via flow descriptor list)
UPSTREAM_ADSPEC Resv, ResvConf, ResvTear, ResvErr, and
Notify (via flow descriptor list)
The format of the sender description for bidirectional asymmetric LSPs is:
双方向の非対称LSPの送信者説明の形式は次のとおりです。
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>
<UPSTREAM_FLOWSPEC>
The format of the flow descriptor list for bidirectional asymmetric LSPs is:
双方向の非対称LSPのフロー記述子リストの形式は次のとおりです。
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC>
<UPSTREAM_TSPEC> [ <UPSTREAM_ADSPEC> ]
<FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ]
[ <UPSTREAM_TSPEC>] [ <UPSTREAM_ADSPEC> ]
<FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
<SE flow descriptor> ::= <FLOWSPEC>
<UPSTREAM_TSPEC> [ <UPSTREAM_ADSPEC> ]
<SE filter spec list>
<SE filter spec list> is unmodified by this document.
<seフィルター仕様リスト>は、このドキュメントによって修正されていません。
This extension reuses and extends semantics and procedures defined in [RFC2205], [RFC3209], and [RFC3473] to support bidirectional LSPs with asymmetric bandwidth. To indicate the use of asymmetric bandwidth, three new objects are defined. Each of these objects is defined with class numbers in the form 0bbbbbbb. Per [RFC2205], nodes not supporting this extension will not recognize the new class numbers and should respond with an "Unknown Object Class" error. The error message will propagate to the ingress, which can then take action to avoid the path with the incompatible node or may simply terminate the session.
この拡張は、[RFC2205]、[RFC3209]、および[RFC3473]で定義されているセマンティクスと手順を再利用および拡張し、非対称帯域幅の双方向LSPをサポートします。非対称帯域幅の使用を示すために、3つの新しいオブジェクトが定義されています。これらの各オブジェクトは、フォーム0bbbbbbbbのクラス番号で定義されます。[RFC2205]ごとに、この拡張子をサポートしていないノードは、新しいクラス番号を認識せず、「不明なオブジェクトクラス」エラーで応答する必要があります。エラーメッセージはイングレスに伝播します。これにより、互換性のないノードを使用してパスを回避するためにアクションを実行したり、単にセッションを終了したりできます。
IANA has assigned new values for namespaces defined in this section and reviewed in this subsection.
IANAは、このセクションで定義され、このサブセクションでレビューされた名前空間に新しい値を割り当てました。
The IANA has made the assignments described below in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry.
IANAは、「クラス名、クラス番号、およびクラスのタイプ」セクション「RSVPパラメーター」レジストリで以下で説明する割り当てを作成しました。
A new class named UPSTREAM_FLOWSPEC has been created in the 0bbbbbbb range (120) with the following definition:
upstream_flowspecという名前の新しいクラスは、次の定義で0bbbbbbb範囲（120）で作成されています。
Class Types or C-types:
クラスタイプまたはCタイプ：
Same values as FLOWSPEC object (C-Num 9)
flowspecオブジェクトと同じ値（c-num 9）
A new class named UPSTREAM_TSPEC has been created in the 0bbbbbbb range (121) with the following definition:
upstream_tspecという名前の新しいクラスは、次の定義で0bbbbbbb範囲（121）で作成されました。
Class Types or C-types:
クラスタイプまたはCタイプ：
Same values as SENDER_TSPEC object (C-Num 12)
sender_tspecオブジェクトと同じ値（c-num 12）
A new class named UPSTREAM_ADSPEC has been created in the 0bbbbbbb range (122) with the following definition:
upstream_adspecという名前の新しいクラスは、次の定義で0bbbbbbb範囲（122）で作成されました。
Class Types or C-types:
クラスタイプまたはCタイプ：
Same values as ADSPEC object (C-Num 13)
AdSpecオブジェクトと同じ値（C-Num 13）
This document introduces new message objects for use in GMPLS signaling [RFC3473] -- specifically the UPSTREAM_TSPEC, UPSTREAM_ADSPEC, and UPSTREAM_FLOWSPEC objects. These objects parallel the exiting SENDER_TSPEC, ADSPEC, and FLOWSPEC objects but are used in the opposite direction. As such, any vulnerabilities that are due to the use of the old objects now apply to messages flowing in the reverse direction.
このドキュメントでは、GMPLSシグナル伝達[RFC3473]、特にUpstream_TSPEC、Upstream_AdSpec、およびUpstream_FlowsPecオブジェクトで使用する新しいメッセージオブジェクトを紹介します。これらのオブジェクトは、出口sender_tspec、adspec、およびflowspecオブジェクトに並行していますが、反対方向に使用されます。そのため、古いオブジェクトの使用による脆弱性は、逆方向に流れるメッセージに適用されます。
From a message standpoint, this document does not introduce any new signaling messages or change the relationship between LSRs that are adjacent in the control plane. As such, this document introduces no additional message- or neighbor-related security considerations.
メッセージの観点から、このドキュメントでは、新しいシグナリングメッセージを導入したり、コントロールプレーンに隣接しているLSR間の関係を変更したりしません。そのため、このドキュメントでは、追加のメッセージまたはネイバー関連のセキュリティ上の考慮事項を紹介しません。
See [RFC3473] for relevant security considerations, and [SEC-FRAMEWORK] for a more general discussion on RSVP-TE security discussions.
関連するセキュリティに関する考慮事項については[RFC3473]を参照し、RSVP-TEセキュリティディスカッションに関するより一般的な議論については[SECフレームワーク]を参照してください。
[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、9月1997年。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[GMPLS-PBBTE] Fedyk, D., et al "GMPLS Control of Ethernet", Work in Progress, July 2008.
[Gmpls-Pbbte] Fedyk、D.、et al "Gmpls Control of Ethernet"、Work in Progress、2008年7月。
[MEF-TRAFFIC] Papadimitriou, D., "MEF Ethernet Traffic Parameters," Work in Progress, October 2008.
[MEF-Traffic] Papadimitriou、D。、「MEF Ethernet Trafficパラメーター」、Work in Progress、2008年10月。
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC4606] Mannie、E。およびD. Papadimitriou、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）同期光学ネットワーク（SONET）および同期デジタル階層（SDH）コントロールの拡張機能」、RFC 4606、2006年8月。
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006.
[RFC4328] Papadimitriou、D.、ed。、「G.709光学輸送ネットワーク制御の一般化マルチプロトコルラベルスイッチング（GMPLS）シグナル伝達拡張」、2006年1月。
[RSVP-BNF] Farrel, A. "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", Work in Progress, November 2008.
[RSVP-BNF] Farrel、A。
[SEC-FRAMEWORK] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
[Sec-Framework] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2008年11月、Work in Progress。
A. Appendix A: Alternate Approach Using ADSPEC Object
A.付録A：ADSPECオブジェクトを使用した代替アプローチ
This section is included for historic purposes and its implementation is NOT RECOMMENDED.
このセクションは歴史的な目的で含まれており、その実装は推奨されません。
This section presents an alternate method for the support of asymmetric bandwidth bidirectional LSP establishment with a single RSVP-TE signaling session. This approach differs in applicability and generality from the approach presented in the main body of this document. In particular, this approach is technology-specific; it uses the ADSPEC object to carry traffic parameters for upstream data and requires the Metro Ethernet Forum (MEF) Ethernet Traffic Parameter, while the approach presented above is suitable for use with any technology.
このセクションでは、単一のRSVP-TEシグナル伝達セッションで非対称帯域幅の双方向LSP確立をサポートするための代替方法を紹介します。このアプローチは、このドキュメントの本体で提示されたアプローチとは、適用性と一般性が異なります。特に、このアプローチは技術固有です。ADSPECオブジェクトを使用してアップストリームデータにトラフィックパラメーターを運び、Metro Ethernet Forum（MEF）Ethernet Trafficパラメーターを必要としますが、上記のアプローチはあらゆるテクノロジーでの使用に適しています。
The generalized asymmetric bandwidth bidirectional LSP presented in the main body of this document has the benefit of being applicable to any switching technology, but requires support for three new types of object classes, i.e., the UPSTREAM_TSPEC, UPSTREAM_ADSPEC, and UPSTREAM_FLOWSPEC objects.
このドキュメントの本体に提示された一般化された非対称帯域幅の双方向LSPは、スイッチングテクノロジーに適用できるという利点がありますが、3つの新しいタイプのオブジェクトクラス、つまりupstream_tspec、upstream_adspec、およびupstream_flowspecオブジェクトをサポートする必要があります。
The solution presented in this section is based on the Ethernet-specific ADSPEC object, and is referred to as the "ADSPEC Object" approach. This approach limits applicability to cases where the [MEF-TRAFFIC] traffic parameters are appropriate, and to switching technologies that define no use for the ADSPEC object. While ultimately it is this limited scope that has resulted in this approach being relegated to an Appendix, the semantics of this approach are quite simple in that they only require the definition of a new ADSPEC object C-Type.
このセクションで示されているソリューションは、イーサネット固有のADSPECオブジェクトに基づいており、「ADSPECオブジェクト」アプローチと呼ばれます。このアプローチは、[MEFトラフィック]トラフィックパラメーターが適切である場合、およびADSPECオブジェクトの使用を定義するスイッチングテクノロジーに適用性を制限します。最終的には、このアプローチが付録に追いやられたのはこの限られた範囲ですが、このアプローチのセマンティクスは、新しいADSPECオブジェクトCタイプの定義のみを必要とするという点で非常に簡単です。
In summary, the "ADSPEC Object" approach presented in this section SHOULD NOT be implemented.
要約すると、このセクションに示されている「ADSPECオブジェクト」アプローチを実装すべきではありません。
The "ADSPEC Object" approach is specific to Ethernet and uses [MEF-TRAFFIC] traffic parameters. This approach is not generic and is aimed at providing asymmetric bandwidth bidirectional LSPs for just Ethernet transport. With this approach, the ADSPEC object carries the traffic parameters for the upstream data flow. SENDER_TSPEC object is used to indicate the traffic parameters for the downstream data flow. The FLOWSPEC object provides confirmation of the allocated downstream resources. Confirmation of the upstream resource allocation is a Resv message, as any resource allocation failure for the upstream direction will always result in a PathErr message. Figure 2 shows the bandwidth-related objects used in the first approach.
「ADSPECオブジェクト」アプローチはイーサネットに固有であり、[MEFトラフィック]トラフィックパラメーターを使用します。このアプローチは一般的ではなく、イーサネット輸送のみに非対称帯域幅の双方向LSPを提供することを目的としています。このアプローチを使用すると、ADSPECオブジェクトは、上流のデータフローのトラフィックパラメーターを搭載しています。sender_tspecオブジェクトは、下流のデータフローのトラフィックパラメーターを示すために使用されます。FlowsPecオブジェクトは、割り当てられたダウンストリームリソースの確認を提供します。上流のリソース割り当ての確認はRESVメッセージです。上流の方向のリソース割り当て障害は常にPatherrメッセージになります。図2は、最初のアプローチで使用されている帯域幅関連オブジェクトを示しています。
|---| Path |---|
| I |----------------->| E |
| n | -SENDER_TSPEC | g |
| g | -ADSPEC | r |
| r | | e |
| e | Resv | s |
| s |<-----------------| s |
| s | -FLOWSPEC | |
|---| |---|
Figure 2: Asymmetric Bandwidth Bidirectional LSPs Using ADSPEC Object
図2：ADSPECオブジェクトを使用した非対称帯域幅の双方向LSP
In the "ADSPEC Object" approach, the setup of an asymmetric bandwidth bidirectional LSP would be signaled using the bidirectional procedures defined in [RFC3473] together with the inclusion of a new ADSPEC object. The new ADSPEC object would be specific to Ethernet and could be called the Ethernet Upstream Traffic Parameter ADSPEC object. The Ethernet Upstream Traffic Parameter ADSPEC object would use the Class-Number 13 and C-Type UNASSIGNED (this approach should not be implemented). The format of the object would be the same as the Ethernet SENDER_TSPEC object defined in [MEF-TRAFFIC].
「ADSPECオブジェクト」アプローチでは、非対称帯域幅の双方向LSPのセットアップは、[RFC3473]で定義された双方向手順を使用して、新しいADSPECオブジェクトを含めることとともに合図されます。新しいADSPECオブジェクトはイーサネットに固有であり、イーサネット上流トラフィックパラメーターADSPECオブジェクトと呼ばれる可能性があります。イーサネットのアップストリームトラフィックパラメーターADSPECオブジェクトは、Class-Number 13およびCタイプの未割り当てを使用します（このアプローチは実装してはなりません）。オブジェクトの形式は、[MEF-Traffic]で定義されているイーサネットSender_TSPECオブジェクトと同じです。
This approach would not modify behavior of symmetric bandwidth LSPs. Per [MEF-TRAFFIC], such LSPs are signaled either without an ADSPEC or with an INTSERV ADSPEC.
このアプローチは、対称帯域幅LSPの動作を変更しません。[MEFトラフィック]ごとに、そのようなLSPは、ADSPECなしまたはIntServ ADSPECを使用してシグナル伝えられます。
The defined approach could be reused to support asymmetric bandwidth bidirectional LSPs for other types of switching technologies. All that would be needed would be to define the proper ADSPEC object.
定義されたアプローチは、他のタイプのスイッチング技術の非対称帯域幅の双方向LSPをサポートするために再利用できます。必要なのは、適切なADSPECオブジェクトを定義することです。
Using the approach presented in this section, the process of establishing an asymmetric bandwidth bidirectional LSP would follow the process of establishing a symmetric bandwidth bidirectional LSP, as defined in Section 3 of [RFC3473], with two modifications. These modifications would be followed when an incoming Path message is received containing an Upstream_Label object and the Ethernet Upstream Traffic Parameter ADSPEC object.
このセクションで提示されたアプローチを使用して、非対称帯域幅の双方向LSPを確立するプロセスは、[RFC3473]のセクション3で定義されているように、対称帯域幅の双方向LSPを確立するプロセスに従い、2つの修正が行われます。これらの変更は、上流の_LabelオブジェクトとイーサネットのアップストリームトラフィックパラメーターADSPECオブジェクトを含む着信パスメッセージを受信した場合に続きます。
The first modification to the symmetric bandwidth process would be that when allocating the upstream label, the bandwidth associated with the upstream label would be taken from the Ethernet Upstream Traffic Parameter ADSPEC object, see Section 3.1 of [RFC3473].
対称帯域幅プロセスの最初の変更は、アップストリームラベルを割り当てるときに、上流ラベルに関連付けられた帯域幅がイーサネット上流トラフィックパラメーターADSPECオブジェクトから取得されることです。[RFC3473]のセクション3.1を参照してください。
Consistent with [RFC3473], a node that is unable to allocate a label or internal resources based on the contents of the ADSPEC object, would issue a PathErr message with a "Routing problem/MPLS label allocation failure" indication.
[RFC3473]と一致して、ADSPECオブジェクトのコンテンツに基づいてラベルまたは内部リソースを割り当てることができないノードは、「ルーティング問題/MPLSラベル割り当て障害」の表示を伴うPatherrメッセージを発行します。
The second modification would be that the ADSPEC object would not be modified by transit nodes.
2番目の変更は、ADSPECオブジェクトがトランジットノードによって変更されないことです。
The approach presented in this section reuses semantics and procedures defined in [RFC3473]. To indicate the use of asymmetric bandwidth, a new ADSPEC object C-type would be defined. Per [RFC2205], nodes not supporting the approach should not recognize this new C-type and respond with an "Unknown object C-Type" error.
このセクションで示されているアプローチは、[RFC3473]で定義されているセマンティクスと手順を再利用します。非対称帯域幅の使用を示すために、新しいADSPECオブジェクトCタイプが定義されます。[RFC2205]によると、アプローチをサポートしていないノードは、この新しいCタイプを認識してはならず、「不明なオブジェクトCタイプ」エラーで応答してはなりません。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C.
Lou Berger Labn Consulting、L.L.C。
EMail: lberger@labn.net
Attila Takacs Ericsson 1. Laborc u. 1037 Budapest, Hungary
Attila Takacs Ericsson 1. Laborc u。1037ブダペスト、ハンガリー
Phone: +36-1-4377044
EMail: attila.takacs@ericsson.com
Diego Caviglia Ericsson Via A. Negrone 1/A Genova-Sestri Ponente, Italy
Diego Caviglia Ericsson A. Negrone 1/A Genova-Sestri Ponente、イタリア
Phone: +390106003738
EMail: diego.caviglia@ericsson.com
Don Fedyk Nortel Networks 600 Technology Park Drive Billerica, MA, USA 01821
Don Fedyk Nortel Networks 600 Technology Park Drive Billerica、MA、USA 01821
Phone: +1-978-288-3041
EMail: dwfedyk@nortel.com
Julien Meuric France Telecom Research & Development 2, avenue Pierre Marzin 22307 Lannion Cedex - France
Julien Meuric France Telecom Research＆Development 2、Avenue Pierre Marzin 22307 Lannion Cedex -France
Phone: +33 2 96 05 28 28
EMail: julien.meuric@orange-ftgroup.com