[要約] RFC 3474は、GMPLSリソース予約プロトコル（RSVP-TE）の使用と拡張のためのIANA割り当てのドキュメントです。このRFCの目的は、ASONにおける自動切り替え光ネットワークのためのRSVP-TEの使用方法と拡張機能を提供することです。
Network Working Group Z. Lin
Request for Comments: 3474 New York City Transit
Category: Informational D. Pendarakis
Tellium
March 2003
Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)
一般化されたマルチプロトコルラベルスイッチング（GMPLS）リソース予約プロトコル - トラフィックエンジニアリング（RSVP -TE）の使用および自動スイッチ型光ネットワーク（ASON）の拡張機能のIANA割り当てのドキュメント
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs).
一般化されたマルチプロトコルラベルスイッチング（GMPLS）のプロトコル仕様スイートは、さまざまなテクノロジーとさまざまなアプリケーションのサポートを提供するために定義されています。これらには、同期光学ネットワーク/同期デジタル階層（SONET/SDH）と光輸送ネットワーク（OTNS）に基づいてTDM接続を要求するためのサポートが含まれます。
This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network.
このドキュメントは、プロトコルのGMPLSスイート、特にリソース予約プロトコル - トラフィックエンジニアリング（RSVP -TE）を使用したGMPLSシグナル伝達のシグナリングの側面に集中しています。ASONネットワークの機能をサポートするために、これらのシグナリングプロトコルに追加の拡張機能を提案しています。
This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort.
このドキュメントは、ITUのASON標準化の取り組みをサポートするために、ITU-T研究グループ15によって特定および伝達された追加要件の解決に向けた適切な拡張を提案しています。
Table of Contents
目次
1. Conventions used in this document...............................3
2. Introduction....................................................3
3. Support for Soft Permanent Connection...........................3
4. Support for Call................................................4
4.1 Call Identifier and Call Capability........................4
4.1.1 Call Identifier.....................................4
4.1.2 Call Capability.....................................7
4.2 What Does Current GMPLS Provide............................7
4.3 Support for Call and Connection............................7
4.3.1 Processing Rules....................................8
4.3.2 Modification to Path Message........................8
4.3.3 Modification to Resv Message........................9
4.3.4 Modification to PathTear Message....................9
4.3.5 Modification to PathErr Message....................10
4.3.6 Modification to Notify Message.....................10
5. Support For Behaviors during Control Plane Failures...........11
6. Support For Label Usage.......................................12
7. Support for UNI and E-NNI Signaling Session...................13
8. Additional Error Cases........................................14
9. Optional Extensions for Supporting
Complete Separation of Call and Connection....................15
9.1 Call Capability.........;.................................15
9.2 Complete Separation of Call and
Connection (RSVP-TE Extensions)...........................16
9.2.1 Modification to Path...............................16
9.2.2 Modification to Resv...............................17
9.2.3 Modification to PathTear...........................18
9.2.4 Modification to PathErr............................18
9.2.5 Modification to Notify.............................18
10. Security Considerations.......................................19
11. IANA Considerations...........................................19
11.1 Assignment of New Messages...............................19
11.2 Assignment of New Objects and Sub-Objects................19
11.3 Assignment of New C-Types................................20
11.4 Assignment of New Error Code/Values......................20
12. Acknowledgements..............................................20
13. References....................................................21
13.1 Normative References.....................................21
13.2 Informative References...................................22
14. Intellectual Property.........................................23
15. Contributors Contact Information..............................24
16. Authors' Addresses............................................24
17. Full Copyright Statement......................................25
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 BCP 14, RFC 2119 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
This document contains the extensions to GMPLS for ASON-compliant networks [G7713.2]. The requirements describing the need for these extensions are provided in [GMPLS-ASON] as well as [ASON-RQTS]. These include:
このドキュメントには、ASON準拠ネットワークのGMPLへの拡張が含まれています[G7713.2]。これらの拡張機能の必要性を説明する要件は、[GMPLS-ASON]および[ASON-RQTS]で提供されます。これらには以下が含まれます：
- Support for call and connection separation - Support for soft permanent connection - Support for extended restart capabilities - Additional error codes/values to support these extensions
- 通話と接続の分離のサポート - ソフトパーマネント接続のサポート - 拡張再起動機能のサポート - これらの拡張機能をサポートする追加のエラーコード/値
This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using RSVP-TE. It introduces extensions to GMPLS RSVP-TE to support the capabilities as specified in the above referenced documents. Specifically, this document uses the messages and objects defined by [RFC2205], [RFC2961], [RFC3209], [RFC3471], [RFC3473], [OIF-UNI1] and [RFC3476] as the basis for the GMPLS RSVP-TE protocol, with additional extensions defined in this document.
このドキュメントは、プロトコルのGMPLSスイート、特にRSVP-TEを使用したGMPLSシグナリングのシグナル伝達の側面に集中しています。上記の参照ドキュメントで指定されているように、GMPLS RSVP-TEに拡張機能を導入します。具体的には、このドキュメントでは、[RFC2205]、[RFC2961]、[RFC3209]、[RFC3471]、[RFC3473]、[OIF-UNI1]、[OIF-UNI1]、[RFC3476]によってGMPLS RSVP-TEプロトコルの基礎としての基礎として定義されたメッセージとオブジェクトを使用します。、このドキュメントで追加の拡張機能が定義されています。
In the scope of ASON, to support soft permanent connection (SPC) for RSVP-TE, one new sub-type for the GENERALIZED_UNI object is defined. The GENERALIZED_UNI object is defined in [RFC3476] and [OIF-UNI1]. This new sub-type has the same format and structure as the EGRESS_LABEL (the sub-type is the suggested value for the new sub-object):
ASONの範囲では、RSVP-TEのソフトパーマネント接続（SPC）をサポートするために、一般化された_UNIオブジェクトの1つの新しいサブタイプが定義されています。Generalized_Uniオブジェクトは[RFC3476]および[OIF-UNI1]で定義されています。この新しいサブタイプは、Egress_labelと同じ形式と構造を持っています（サブタイプは、新しいサブオブジェクトの推奨値です）：
- SPC_LABEL (Type=4, Sub-type=2)
- spc_label（type = 4、sub-type = 2）
The label association of the permanent ingress segment with the switched segment at the switched connection ingress node is a local policy matter (i.e., between the management system and the switched connection ingress node) and is thus beyond the scope of this document.
Switched Connection Ingressノードの永久侵入セグメントとスイッチセグメントのラベル関連は、ローカルポリシーの問題（つまり、管理システムとスイッチ付き接続イングレスノードの間）であるため、このドキュメントの範囲を超えています。
The processing of the SPC_LABEL sub-object follows that of the EGRESS_LABEL sub-object [OIF-UNI1]. Note that although the explicit label control described in [RFC3471] and [RFC3473] may provide a mechanism to support specifying the egress label in the context of supporting the GMPLS application, the SPC services support for the ASON model uses the GENERALIZED_UNI object for this extension to help align the model for both switched connection and soft permanent connection, as well as to use the service level and diversity attributes of the GENERALIZED_UNI object.
SPC_LABELサブオブジェクトの処理は、gesress_label sub-object [oif-uni1]の処理に従います。[RFC3471]および[RFC3473]で説明されている明示的なラベル制御は、GMPLSアプリケーションをサポートするというコンテキストで出口ラベルの指定をサポートするメカニズムを提供する可能性があるが、ASONモデルのSPCサービスサポートは、この拡張機能の一般化_UNIオブジェクトを使用するSwitched Connectionとソフトパーマネント接続の両方にモデルを整列させ、Generalized_uniオブジェクトのサービスレベルと多様性属性を使用するのに役立ちます。
To support basic call capability (logical call/connection separation), a call identifier is introduced to the RSVP-TE message sets. This basic call capability helps introduce the call model; however, additional extensions may be needed to fully support the canonical call model (complete call/connection separation).
基本的なコール機能（論理呼び出し/接続分離）をサポートするために、RSVP-TEメッセージセットにコール識別子が導入されます。この基本的なコール機能は、コールモデルを導入するのに役立ちます。ただし、標準コールモデル（完全なコール/接続分離）を完全にサポートするには、追加の拡張機能が必要になる場合があります。
A Call identifier object is used in logical call/connection separation while both the Call identifier object and a Call capability object are used in complete call/connection separation.
コール識別子オブジェクトは論理呼び出し/接続分離で使用され、コール識別子オブジェクトとコール機能オブジェクトの両方が完全なコール/接続分離で使用されます。
To identify a call, a new object is defined for RSVP-TE. The CALL_ID object carries the call identifier. The value is globally unique (the Class-num is the suggested value for the new object):
呼び出しを識別するために、RSVP-TE用に新しいオブジェクトが定義されています。call_idオブジェクトには、コール識別子が搭載されています。値はグローバルに一意です（クラス-Numは、新しいオブジェクトの推奨値です）：
CALL_ID (Class-num = 230)
call_id（class-num = 230）
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call identifier |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the following C-types are defined:
次のCタイプが定義されている場合：
- C-Type = 1 (operator specific): The call identifier contains an operator specific identifier.
- C-Type = 1（演算子固有）：コール識別子には、オペレーター固有の識別子が含まれています。
- C-Type = 2 (globally unique): The call identifier contains a globally unique part plus an operator specific identifier.
- C-Type = 2（グローバルに一意）：コール識別子には、グローバルに一意のパーツとオペレーター固有の識別子が含まれています。
The following structures are defined for the call identifier:
次の構造は、コール識別子に対して定義されています。
- Call identifier: generic [Length*8-32]-bit identifier. The number of bits for a call identifier must be multiples of 32 bits, with a minimum size of 32 bits.
- 呼び出し識別子：generic [length*8-32] - ビット識別子。コール識別子のビット数は、32ビットの32ビットの倍数でなければなりません。最小サイズは32ビットです。
The structure for the globally unique call identifier (to guarantee global uniqueness) is to concatenate a globally unique fixed ID (composed of country code, carrier code, unique access point code) with an operator specific ID (where the operator specific ID is composed of a source LSR address and a local identifier).
グローバルに一意のコール識別子の構造（グローバルな一意性を保証するため）は、オペレーター固有のID（オペレーター固有のIDが構成されている場合、グローバルに一意の固定ID（カントリーコード、キャリアコード、一意のアクセスポイントコードで構成される）を連結することです。ソースLSRアドレスとローカル識別子）。
Therefore, a generic CALL_ID with global uniqueness includes <global ID> (composed of <country code> plus <carrier code> plus <unique access point code>) and <operator specific ID> (composed of <source LSR address> plus <local identifier>). For a CALL_ID that only requires operator specific uniqueness, only the <operator specific ID> is needed, while for a CALL_ID that is required to be globally unique, both <global ID> and <operator specific ID> are needed.
したがって、グローバルユニークネスを備えた汎用Call_idには、<グローバルID>（<Country Code> Plus <Carrier Code> Plus <Unique Access Point Code>で構成）および<オペレーター固有のID>（<ソースLSRアドレス> Plus <localで構成されています識別子>）。演算子固有の一意のみを必要とするcall_idの場合、グローバルに一意である必要があるcall_idの場合、<グローバルID>と<オペレーター固有のID>の両方が必要です。
The <global ID> shall consist of a three-character International Segment (the <country code>) and a twelve-character National Segment (the <carrier code> plus <unique access point code>). These characters shall be coded according to ITU-T Recommendation T.50. The International Segment (IS) field provides a 3 character ISO 3166 Geographic/Political Country Code. The country code shall be based on the three-character uppercase alphabetic ISO 3166 Country Code (e.g., USA, FRA).
<グローバルID>は、3文字の国際セグメント（<カントリーコード>）と12文字の全国セグメント（<キャリアコード>プラス<一意のアクセスポイントコード>）で構成されます。これらの文字は、ITU-Tの推奨T.50に従ってコーディングされます。国際セグメント（IS）フィールドは、3文字のISO 3166地理/政治国コードを提供します。国コードは、3文字の大文字のアルファベットISO 3166国コード（米国、FRAなど）に基づいています。
National Segment (NS): The National Segment (NS) field consists of two sub-fields:
National Segment（NS）：National Segment（NS）フィールドは、2つのサブフィールドで構成されています。
- the first subfield contains the ITU Carrier Code - the second subfield contains a Unique Access Point Code.
- 最初のサブフィールドには、ITUキャリアコードが含まれています。2番目のサブフィールドには、一意のアクセスポイントコードが含まれています。
The ITU Carrier Code is a code assigned to a network operator/service provider, maintained by the ITU-T Telecommunication Service Bureauin association with Recommendation M.1400. This code consists of 1-6 left-justified alphabetic, or leading alphabetic followed by numeric, characters (bytes). If the code is less than 6 characters (bytes), it is padded with a trailing NULL to fill the subfield.
ITUキャリアコードは、ITU-T Telecommunication Service Bureauin Associationが推奨M.1400と維持するネットワークオペレーター/サービスプロバイダーに割り当てられたコードです。このコードは、1〜6個の左正当化されたアルファベット語、または先頭のアルファベット語で構成され、それに続く数値文字（バイト）が続きます。コードが6文字未満（バイト）の場合、サブフィールドを埋めるために末尾のヌルがパッドで塗られています。
The Unique Access Point Code is a matter for the organization to which the country code and ITU carrier code have been assigned, provided that uniqueness is guaranteed. This code consists of 1-6 characters (bytes), trailing NULL, completing the 12-character National Segment. If the code is less than 6 characters, it is padded by a trailing NULL to fill the subfield.
一意のアクセスポイントコードは、一意性が保証されていれば、国コードとITUキャリアコードが割り当てられている組織の問題です。このコードは、1〜6文字（バイト）で構成され、nullを走り、12文字の全国セグメントを完成させます。コードが6文字未満の場合、サブフィールドを埋めるために後続のnullによってパディングされます。
Format of the National Segment
全国セグメントの形式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU carrier code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU carrie dode (cont) | Unique access point code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique access point code (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Call identifier field for C-Type = 1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Resv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source LSR address |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Call identifier field for C-Type = 2:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | IS (3 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NS (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source LSR address |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In both cases, a "Type" field is defined to indicate the type of format used for the source LSR address. The Type field has the following meaning: For Type=0x01, the source LSR address is 4 bytes For Type=0x02, the source LSR address is 16 bytes For Type=0x03, the source LSR address is 20 bytes For type=0x04, the source LSR address is 6 bytes For type=0x7f, the source LSR address has the length defined by the vendor
どちらの場合も、ソースLSRアドレスに使用される形式のタイプを示す「タイプ」フィールドが定義されています。タイプフィールドには次の意味があります。タイプ= 0x01の場合、ソースLSRアドレスはタイプ= 0x02の4バイトです。ソースLSRアドレスはタイプ= 0x03の16バイトです。ソースLSRアドレスはタイプ= 0x04の20バイトです。ソースLSRアドレスはタイプ= 0x7Fの6バイトです。ソースLSRアドレスの長さはベンダーによって定義されています
Source LSR address: An address of the LSR controlled by the source network.
ソースLSRアドレス：ソースネットワークによって制御されるLSRのアドレス。
Local identifier: A 64-bit identifier that remains constant over the life of the call.
ローカル識別子：コールの寿命にわたって一定のままである64ビット識別子。
Note that if the source LSR address is assigned from an address space that is globally unique, then the operator-specific CALL_ID may also be used to represent a globally unique CALL_ID. However, this is not guaranteed since the source LSR address may be assigned from an operator-specific address space.
ソースLSRアドレスがグローバルに一意のアドレススペースから割り当てられている場合、オペレーター固有のCALL_IDを使用してグローバルに一意のCALL_IDを表すこともできます。ただし、ソースLSRアドレスはオペレーター固有のアドレススペースから割り当てられる可能性があるため、これは保証されません。
The call capability feature is provided in Section 10. This is an optional capability. If supported, section 10 extensions must be followed.
コール機能機能はセクション10で提供されています。これはオプションの機能です。サポートされている場合は、セクション10拡張機能に従う必要があります。
The signaling mechanism defined in [RFC2961], [RFC3209] and [RFC3471] supports automatic connection management; however it does not provide capability to support the call model. A call may be viewed as a special purpose connection that requires a different subset of information to be carried by the messages. This information is targeted to the call controller for the purpose of setting up a call/connection association.
[RFC2961]、[RFC3209]、および[RFC3471]で定義されたシグナル伝達メカニズムは、自動接続管理をサポートしています。ただし、コールモデルをサポートする機能は提供されません。呼び出しは、メッセージによって異なるサブセットを掲載する必要がある特別な目的接続と見なされる場合があります。この情報は、コール/接続関連を設定する目的で、コールコントローラーを対象としています。
Within the context of this document, every call (during steady state) may have one (or more) associated connections. A zero connection call is defined as a transient state, e.g., during a break-before-make restoration event.
このドキュメントのコンテキスト内では、すべての呼び出し（定常状態）には、1つ（またはそれ以上）の関連する接続があります。ゼロ接続コールは、たとえば、壊れた後の修復イベント中に、過渡状態として定義されます。
In the scope of ASON, to support a logical call/connection separation, a new call identifier is needed as described above. The new GENERALIZED_UNI object is carried by the Path message. The new CALL_ID object is carried by the Path, Resv, PathTear, PathErr, and Notify messages. The ResvConf message is left unmodified. The CALL_ID object (along with other objects associated with a call, e.g., GENERALIZED_UNI) is processed by the call controller, while other objects included in these messages are processed by the connection controller as described in [RFC3473]. Processing of the CALL_ID (and related) object is described in this document.
ASONの範囲では、論理呼び出し/接続分離をサポートするには、上記のように新しいコール識別子が必要です。新しいgeneralized_uniオブジェクトは、パスメッセージによって運ばれます。新しいcall_idオブジェクトは、パス、RESV、PATHTEAR、PATHERR、および通知メッセージによって運ばれます。RESVCONFメッセージは変更されていません。call_idオブジェクト（コールに関連付けられている他のオブジェクト、たとえば、一般化された_uniなど）はコールコントローラーによって処理されますが、これらのメッセージに含まれる他のオブジェクトは、[rfc3473]で説明されているように接続コントローラーによって処理されます。CALL_ID（および関連）オブジェクトの処理については、このドキュメントで説明されています。
Note: unmodified RSVP message formats are not listed below.
注：変更されていないRSVPメッセージ形式は以下にリストされていません。
The following processing rules are applicable for call capability:
次の処理ルールは、通話機能に適用されます。
- For initial calls, the source user MUST set the CALL_ID's C-Type and call identifier value to all-zeros. - For a new call request, the first network node sets the appropriate C-type and value for the CALL_ID. - For an existing call (in case CALL_ID is non-zero) the first network node verifies existence of the call.
- 最初の呼び出しの場合、ソースユーザーはcall_idのcタイプを設定し、識別子値をすべてゼロに呼び出す必要があります。 - 新しいコールリクエストの場合、最初のネットワークノードは、call_idの適切なCタイプと値を設定します。 - 既存の呼び出しの場合（CALL_IDがゼロではない場合）、最初のネットワークノードは呼び出しの存在を検証します。
- The CALL_ID object on all messages MUST be sent from the ingress call controller to egress call controller by all other (intermediate) controllers without alteration. Indeed, the Class-Num is chosen such that a node which does not support ASON extensions to GMPLS forwards the object unmodified (value in the range 11bbbbbb). - The destination user/client receiving the request uses the CALL_ID value as a reference to the requested call between the source user and itself. Subsequent actions related to the call uses the CALL_ID as the reference identifier.
- すべてのメッセージのcall_idオブジェクトは、イングレスコールコントローラーから送信する必要があります。実際、Class-Numは、GMPLSへのAson拡張機能をサポートしないノードがオブジェクトを変更していない（範囲11BBBBBB）に選択するように選択されます。 - リクエストを受信する宛先ユーザー/クライアントは、ソースユーザーとそれ自体の間の要求された呼び出しへの参照としてcall_id値を使用します。コールに関連する後続のアクションは、call_idを参照識別子として使用します。
<Path Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <CALL_ID> ]
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <GENERALIZED_UNI> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the sender descriptor for unidirectional LSPs is not modified by this document.
単方向LSPの送信者記述子の形式は、このドキュメントによって変更されません。
The format of the sender descriptor for bidirectional LSPs is not modified by this document.
双方向LSPの送信者記述子の形式は、このドキュメントによって変更されません。
Note that although the GENERALIZED_UNI and CALL_ID objects are optional for GMPLS signaling, these objects are mandatory for ASON-compliant networks, i.e., the Path message MUST include both GENERALIZED_UNI and CALL_ID objects.
Generalized_uniおよびcall_idオブジェクトはGMPLSシグナリングにはオプションですが、これらのオブジェクトはASON準拠ネットワークに必須であることに注意してください。
<Resv Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
[ <CALL_ID> ]
[ <RESV_CONFIRM> ]
<SCOPE>
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE>
<flow descriptor list>
<flow descriptor list> is not modified by this document.
<フロー記述子リスト>は、このドキュメントで変更されていません。
Note that although the CALL_ID object is optional for GMPLS signaling, this object is mandatory for ASON-compliant networks, i.e., the Resv message MUST include the CALL_ID object.
call_idオブジェクトはGMPLSシグナリングのオプションですが、このオブジェクトはASON準拠のネットワークに必須であることに注意してください。つまり、RESVメッセージにはcall_idオブジェクトを含める必要があります。
<PathTear Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
[ <CALL_ID> ]
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition)
Note that although the CALL_ID object is optional for GMPLS signaling, this object is mandatory for ASON-compliant networks, i.e., the PathTear message MUST include the CALL_ID object.
call_idオブジェクトはGMPLSシグナリングのオプションですが、このオブジェクトはASON準拠ネットワークに必須であることに注意してください。つまり、PathTearメッセージにはcall_idオブジェクトを含める必要があります。
<PathErr Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
[ <CALL_ID> ]
<ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= (see earlier definition)
Note that although the CALL_ID object is optional for GMPLS signaling, this object is mandatory for ASON-compliant networks, i.e., the PathErr message MUST include the CALL_ID object.
call_idオブジェクトはGMPLSシグナリングのオプションですが、このオブジェクトはASON準拠のネットワークに必須であることに注意してください。つまり、patherRメッセージにはcall_idオブジェクトを含める必要があります。
Note that this message may include sessions belonging to several calls.
このメッセージには、いくつかのコールに属するセッションが含まれる場合があることに注意してください。
<Notify message> ::= <Common Header>
[<INTEGRITY>]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
<notify session list> ::=
[ <notify session list> ]
<upstream notify session> |
<downstream notify session>
<upstream notify session> ::= <SESSION>
[ <CALL_ID> ]
[ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<downstream notify session> ::= <SESSION>
[ <CALL_ID> ]
[<POLICY_DATA>...]
<flow descriptor list descriptor>
Note that although the CALL_ID object is optional for GMPLS signaling, this object is mandatory for ASON-compliant networks, i.e., the Notify message MUST include the CALL_ID object.
call_idオブジェクトはGMPLSシグナリングのオプションですが、このオブジェクトはASON準拠のネットワークに必須であることに注意してください。つまり、Notifyメッセージにはcall_idオブジェクトを含める必要があります。
Various types of control plane failures may occur within the network. These failures may impact the control plane as well as the data plane (e.g., in a SDH/SONET network if the control plane transport uses the DCC and a fiber cut occurs, then both the control plane signaling channel and the transport plane connection fails). As described in [RFC3473], current GMPLS restart mechanisms allows support to handle all of these different scenarios, and thus no additional extensions are required.
ネットワーク内でさまざまなタイプのコントロールプレーンの障害が発生する可能性があります。これらの障害は、コントロールプレーンとデータプレーンに影響を与える可能性があります（たとえば、コントロールプレーンの輸送がDCCを使用し、ファイバーカットが発生する場合、SDH/SONETネットワークで、コントロールプレーンシグナリングチャネルと輸送プレーンの接続の両方が失敗します）。[RFC3473]で説明されているように、現在のGMPLの再起動メカニズムにより、サポートがこれらのさまざまなシナリオのすべてを処理できるため、追加の拡張機能は必要ありません。
In the scope of the ASON model, several procedures may take place in order to support the following control plane behaviors (as per [G7713] and [IPO-RQTS]):
ASONモデルの範囲では、次のコントロールプレーンの動作をサポートするためにいくつかの手順が行われる可能性があります（[G7713]および[IPO-RQTS]）：
- A control plane node SHOULD provide capability for persistent storage of call and connection state information. This capability allows each control plane node to recover the states of calls/connections after recovery from a signaling controller entity failure/reboot (or loss of local FSM state). Note that although the restart mechanism allows neighbor control plane nodes to automatically recover (and thus infer) the states of calls/connections, this mechanism can also be used for verification of neighbor states, while the persistent storage provides the local recovery of lost state. In this case, per [RFC3473], if during the Hello synchronization the restarting node determines that a neighbor does not support state recovery (i.e., local state recovery only), and the restarting node maintains its state on a per neighbor basis, the restarting node should immediately consider the Recovery as completed. - A control plane node detecting a failure of all control channels between a pair of nodes SHOULD request an external controller (e.g., the management system) for further instructions. The default behavior is to enter into self-refresh mode (i.e., preservation) for the local call/connection states. As an example, possible external instructions may be to remain in self-refresh mode, or to release local states for certain connections. Specific details are beyond the scope of this document. - A control plane node detecting that one (or more) connections cannot be re-synchronized with its neighbor (e.g., due to different states for the call/connection) SHOULD request an external controller (e.g., the management system) for further instructions on how to handle the non-synchronized connection. As an example, possible instructions may be to maintain the current local connection states. Specifics of the interactions between the control plane and management plane are beyond the scope of this document. - A control plane node (after recovering from node failure) may lose information on forwarding adjacencies. In this case the control plane node SHOULD request an external controller (e.g., the management system) for information to recover the forwarding adjacency information. Specifics of the interactions between the control plane and management plane are beyond the scope of this document.
- コントロールプレーンノードは、通話および接続状態情報の永続的なストレージの機能を提供する必要があります。この機能により、各コントロールプレーンノードは、シグナリングコントローラーエンティティの障害/再起動（またはローカルFSM状態の損失）から回復した後、コール/接続の状態を回復できます。再起動メカニズムにより、隣接するコントロールプレーンノードは呼び出し/接続の状態を自動的に回復する（および推測する）ことができますが、このメカニズムは近隣状態の検証にも使用できますが、永続的なストレージは失われた状態の局所回復を提供します。この場合、[RFC3473]ごとに、Hello同期中に再起動ノードが状態の回復（つまり、現地の状態回復のみ）をサポートしていないと判断し、再起動ノードが近隣ベースで状態を維持すると判断します。ノードは、回復が完了したとすぐに考慮する必要があります。 - ノードのペア間のすべての制御チャネルの障害を検出するコントロールプレーンノードでは、さらなる指示について外部コントローラー（管理システムなど）を要求する必要があります。デフォルトの動作は、ローカルコール/接続状態のセルフリフレッシュモード（つまり、保存）に入ることです。例として、可能な外部指示は、自己再版画モードを維持するか、特定の接続のために地元の状態を解放することです。特定の詳細は、このドキュメントの範囲を超えています。-1つの（またはそれ以上）接続を検出するコントロールプレーンノードは、近隣と再同期することはできません（たとえば、コール/接続の状態が異なるため）、さらに指示のために外部コントローラー（管理システム）に要求する必要があります。非同期接続を処理する方法。例として、可能な指示は、現在のローカル接続状態を維持することです。コントロールプレーンと管理プレーン間の相互作用の詳細は、このドキュメントの範囲を超えています。 - コントロールプレーンノード（ノード障害から回復した後）は、隣接する転送に関する情報を失う可能性があります。この場合、コントロールプレーンノードは、フォワーディング隣接情報を回復するための情報について、外部コントローラー（管理システムなど）を要求する必要があります。コントロールプレーンと管理プレーン間の相互作用の詳細は、このドキュメントの範囲を超えています。
Labels are defined in GMPLS to provide information on the resources used for a particular connection. The labels may range from specifying a particular timeslot, or a particular wavelength, to a particular port/fiber. In the context of the automatic switched optical network, the value of a label may not be consistently the same across a link. For example, the figure below illustrates the case where two GMPLS/ASON-enabled nodes (A and Z) are interconnected across two non-GMPLS/ASON-enabled nodes (B and C; i.e., nodes B and C do not support the ASON capability), where these nodes are all SDH/SONET nodes providing, e.g., a VC-4 service.
ラベルはGMPLSで定義されており、特定の接続に使用されるリソースに関する情報を提供します。ラベルは、特定のタイムスロットまたは特定の波長の指定から特定のポート/ファイバーまで及びます。自動スイッチされた光ネットワークのコンテキストでは、ラベルの値は、リンク間で一貫して同じではない場合があります。たとえば、次の図は、2つのGMPLS/ASON対応ノード（AとZ）が2つの非GMPLS/ASON対応ノード（BおよびC;つまり、ノードBおよびCがASONをサポートしない場合を示しています。機能）、これらのノードはすべてSDH/SONETノードであり、たとえばVC-4サービスを提供します。
+-----+ +-----+
| | +---+ +---+ | |
| A |---| B |---| C |---| Z |
| | +---+ +---+ | |
+-----+ +-----+
Labels have an associated structure imposed on them for local use based on [GMPLS-SDHSONET] and [GMPLS-OTN]. Once the local label is transmitted across an interface to its neighboring control plane node, the structure of the local label may not be significant to the neighbor node since the association between the local and the remote label may not necessarily be the same. This issue does not present a problem in a simple point-to-point connection between two control plane-enabled nodes where the timeslots are mapped 1:1 across the interface. However, in the scope of the ASON, once a non-GMPLS capable sub-network is introduced between these nodes (as in the above figure, where the sub-network provides re-arrangement capability for the timeslots) label scoping may become an issue.
ラベルには、[GMPLS-SDHSONET]および[GMPLS-OTN]に基づいて、ローカル使用のためにそれらに課される関連構造があります。ローカルラベルがインターフェイスを介して隣接するコントロールプレーンノードに送信されると、ローカルラベルとリモートラベルの関連性が必ずしも同じではないため、ローカルラベルの構造は隣接ノードにとって重要ではない場合があります。この問題は、タイムスロットがインターフェイス全体で1：1でマッピングされる2つの制御プレーン対応ノード間の単純なポイントツーポイント接続で問題を提示しません。ただし、ASONの範囲では、これらのノード（上記の図のように、サブネットワークがタイムスロットの再配置機能を提供する）の間に非GMPLS対応のサブネットワークが導入されると、ラベルスコーピングは問題になる可能性があります。
In this context, there is an implicit assumption that the data plane connections between the GMPLS capable edges already exist prior to any connection request. For instance node A's outgoing VC-4's timeslot #1 (with SUKLM label=[1,0,0,0,0]) as defined in [GMPLS-SONETSDH]) may be mapped onto node B's outgoing VC-4's timeslot #6 (label=[6,0,0,0,0]) may be mapped onto node C's outgoing VC-4's timeslot #4 (label=[4,0,0,0,0]). Thus by the time node Z receives the request from node A with label=[1,0,0,0,0], the node Z's local label and the timeslot no longer corresponds to the received label and timeslot information.
これに関連して、接続要求の前にGMPLS対応エッジ間のデータプレーン接続がすでに存在するという暗黙の仮定があります。たとえば、[gmpls-sonetsdh]で定義されているように、ノードAの発信VC-4のタイムスロット＃1（suklm label = [1,0,0,0,0]）は、Node Bの発信VC-4のタイムスロット＃6にマッピングされる場合があります。（ラベル= [6,0,0,0,0]）は、ノードCの発信VC-4のタイムスロット＃4（label = [4,0,0,0,0]）にマッピングできます。したがって、ノードZがラベル= [1,0,0,0,0]を使用してノードAからリクエストを受信するまでに、ノードZのローカルラベルとタイムスロットは、受信したラベルとタイムスロット情報に対応しなくなります。
As such to support the general case, the scope of the label value is considered local to a control plane node. A label association function can be used by the control plane node to map the received (remote) label into a locally significant label. The information necessary to allow mapping from a received label value to a locally significant label value may be derived in several ways:
そのため、一般的なケースをサポートするため、ラベル値の範囲はコントロールプレーンノードにローカルと見なされます。ラベルアソシエーション関数をコントロールプレーンノードで使用して、受信した（リモート）ラベルを局所的に重要なラベルにマッピングできます。受信したラベル値から局所的に重要なラベル値へのマッピングを許可するために必要な情報は、いくつかの方法で導き出される場合があります。
- Via manual provisioning of the label association - Via discovery of the label association
- ラベル協会の手動プロビジョニングを介して - ラベル協会の発見による
Either method may be used. In the case of dynamic association, this implies that the discovery mechanism operates at the timeslot/label level before the connection request is processed at the ingress node. Note that in the simple case where two nodes are directly connected, no association may be necessary. In such instances, the label association function provides a one-to-one mapping of the received local label values.
どちらの方法も使用できます。動的関連の場合、これは、接続要求がイングレスノードで処理される前に、発見メカニズムがタイムスロット/ラベルレベルで動作することを意味します。2つのノードが直接接続されている単純な場合、関連性は必要ない場合があることに注意してください。そのような場合、ラベルアソシエーション関数は、受信したローカルラベル値の1対1のマッピングを提供します。
[RFC3476] defines a UNI IPv4 SESSION object used to support the UNI signaling when IPv4 addressing is used. This document introduces three new extensions. These extensions specify support for the IPv4 and IPv6 E-NNI session and IPv6 UNI session. These C-Types are introduced to allow for easier identification of messages as regular GMPLS messages, UNI messages, or E-NNI messages. This is particularly useful if a single interface is used to support multiple service requests.
[RFC3476]は、IPv4アドレス指定を使用するときにUNIシグナル伝達をサポートするために使用されるUNI IPv4セッションオブジェクトを定義します。このドキュメントでは、3つの新しい拡張機能を紹介します。これらの拡張機能は、IPv4およびIPv6 E-NNIセッションおよびIPv6 UNIセッションのサポートを指定します。これらのCタイプは、通常のGMPLSメッセージ、UNIメッセージ、またはe-NNIメッセージとしてメッセージを簡単に識別できるように導入されています。これは、単一のインターフェイスを使用して複数のサービス要求をサポートする場合に特に便利です。
Extensions to SESSION object (Class-num = 1):
- C-Type = 12: UNI_IPv6 SESSION object
- C-TYPE = 15: ENNI_IPv4 SESSION object
- C-Type = 16: ENNI_IPv6 SESSION object
The format of the SESSION object with C-Type = 15 is the same as that for the SESSION object with C-Type = 7. The format of the SESSION object with C-Type = 12 and 16 is the same as that for the SESSION object with C-Type = 8.
Cタイプ= 15のセッションオブジェクトの形式は、Cタイプ= 7のセッションオブジェクトの形式と同じです。Cタイプ= 12および16のセッションオブジェクトの形式は、セッションの形式と同じです。Cタイプ= 8のオブジェクト。
The destination address field contains the address of the downstream controller processing the message. For the case of the E-NNI signaling interface (where eNNI-U represents the upstream controller and eNNI-D represents the downstream controller) the destination address contains the address of eNNI-D. [OIF-UNI1] and [RFC3476] describes the content of the address for UNI_IPv4 SESSION object, which is also applicable for UNI_IPv6 SESSION object.
宛先アドレスフィールドには、メッセージを処理する下流コントローラーのアドレスが含まれています。ENNIシグナル伝達インターフェイスの場合（ENNI-Uは上流コントローラーを表し、ENNI-Dはダウンストリームコントローラーを表します）、宛先アドレスにはENNI-Dのアドレスが含まれています。[oif-uni1]および[rfc3476]は、uni_ipv6セッションオブジェクトにも適用できるuni_ipv4セッションオブジェクトのアドレスの内容を説明しています。
In the scope of ASON, the following additional error cases are defined:
ASONの範囲では、次の追加エラーケースが定義されています。
- Policy control failure: unauthorized source; this error is generated when the receiving node determines that a source user/client initiated request for service is unauthorized based on verification of the request (e.g., not part of a contracted service). This is defined in [RFC3476]. - Policy control failure: unauthorized destination; this error is generated when the receiving node determines that a destination user/client is unauthorized to be connected with a source user/client. This is defined in [RFC3476]. - Routing problem: diversity not available; this error is generated when a receiving node determines that the requested diversity cannot be provided (e.g., due to resource constraints). This is defined in [RFC3476]. - Routing problem: service level not available; this error is generated when a receiving node determines that the requested service level cannot be provided (e.g., due to resource constraints). This is defined in [RFC3476]. - Routing problem: invalid/unknown connection ID; this error is generated when a receiving node determines that the connection ID generated by the upstream node is not valid/unknown (e.g., does not meet the uniqueness property). Connection ID is defined in [OIF-UNI1]. - Routing problem: no route available toward source; this error is generated when a receiving node determines that there is no available route towards the source node (e.g., due to unavailability of resources). - Routing problem: unacceptable interface ID; this error is generated when a receiving node determines that the interface ID specified by the upstream node is unacceptable (e.g., due to resource contention). - Routing problem: invalid/unknown call ID; this error is generated when a receiving node determines that the call ID generated by the source user/client is invalid/unknown (e.g., does not meet the uniqueness property). - Routing problem: invalid SPC interface ID/label; this error is generated when a receiving node determines that the SPC interface ID (or label, or both interface ID and label) specified by the upstream node is unacceptable (e.g., due to resource contention).
- ポリシー管理の失敗：不正なソース。このエラーは、受信ノードがソースユーザー/クライアントのサービスのリクエストがリクエストの検証に基づいて不正であると判断したときに生成されます（たとえば、契約サービスの一部ではありません）。これは[RFC3476]で定義されています。 - ポリシー管理の失敗：不正な目的地。このエラーは、受信ノードが宛先ユーザー/クライアントがソースユーザー/クライアントに接続することを許可されていないと判断したときに生成されます。これは[RFC3476]で定義されています。 - ルーティングの問題：多様性は利用できません。このエラーは、受信ノードが要求された多様性を提供できないと判断したときに生成されます（たとえば、リソースの制約のため）。これは[RFC3476]で定義されています。 - ルーティングの問題：サービスレベルは利用できません。このエラーは、受信ノードが要求されたサービスレベルを提供できないと判断したときに生成されます（たとえば、リソースの制約のため）。これは[RFC3476]で定義されています。 - ルーティングの問題：無効/不明な接続ID。このエラーは、受信ノードがアップストリームノードによって生成された接続IDが有効/不明でないことを決定したときに生成されます（たとえば、一意性プロパティを満たしていません）。接続IDは[oif-uni1]で定義されています。 - ルーティングの問題：ソースに向かって利用できるルートはありません。このエラーは、受信ノードがソースノードに向かって利用可能なルートがないことを決定すると生成されます（たとえば、リソースが利用できないため）。 - ルーティングの問題：容認できないインターフェイスID。このエラーは、受信ノードがアップストリームノードで指定されたインターフェイスIDが受け入れられないことを決定したときに生成されます（たとえば、リソースの競合のため）。 - ルーティングの問題：無効/不明な呼び出しID。このエラーは、受信ノードがソースユーザー/クライアントによって生成された呼び出しIDが無効/不明であると判断したときに生成されます（例えば、一意性プロパティを満たしていません）。 - ルーティングの問題：無効なSPCインターフェイスID/ラベル。このエラーは、受信ノードがアップストリームノードで指定されたSPCインターフェイスID（またはラベル、または両方のインターフェイスIDとラベル）が受け入れられないことを決定するときに生成されます（例えば、リソースの競合のため）。
This section describes the optional and non-normative capability to support complete separation of call and connection. To support complete separation of call and connection, a call capability object is introduced. The capability described in this Appendix is meant to be an optional capability within the scope of the ASON specification. An implementation of the extensions defined in this document include support for complete separation of call and connection, defined in this section.
このセクションでは、コールと接続の完全な分離をサポートするオプションおよび非規範的な機能について説明します。コールと接続の完全な分離をサポートするために、コール機能オブジェクトが導入されます。この付録で説明されている機能は、ASON仕様の範囲内でオプションの機能であることを意図しています。このドキュメントで定義されている拡張機能の実装には、このセクションで定義されているコールと接続の完全な分離のサポートが含まれます。
A call capability is used to specify the capabilities supported for a call. For RSVP-TE a new CALL_OPS object is defined to be carried by the Path, Resv, PathTear, PathErr, and Notify messages. The CALL_OPS object also serves to differentiate the messages to indicate a "call-only" call. In the case for logical separation of call and connection, the CALL_OPS object is not needed.
通話機能を使用して、コールにサポートされている機能を指定します。RSVP-TEの場合、新しいcall_opsオブジェクトは、パス、resv、pathtear、patherrによって運ばれ、メッセージに通知するように定義されます。Call_opsオブジェクトは、「コールのみの」コールを示すためにメッセージを区別するのにも役立ちます。コールと接続の論理的な分離の場合、call_opsオブジェクトは必要ありません。
The CALL_OPS object is defined as follows (the Class-num is the suggested value for the new object):
call_opsオブジェクトは次のように定義されます（クラス-Numは、新しいオブジェクトの推奨値です）：
CALL_OPS (Class-num = 228, C-type = 1)
call_ops（class-num = 228、c-type = 1）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (228)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Call ops flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Two flags are currently defined for the "call ops flag": 0x01: call without connection 0x02: synchronizing a call (for restart mechanism)
現在、2つのフラグが「コールOPSフラグ」で定義されています：0x01：接続なしでコール0x02：呼び出しの同期（再起動メカニズムの場合）
A complete separation of call and connection implies that a call (during steady state) may have zero (or more) associated connections. A zero connection call is a steady state, e.g., simply setting up the user end-point relationship prior to connection setup. The following modified messages are used to set up a call. Set up of a connection uses the messages defined in Section 5 above.
コールと接続の完全な分離は、（定常状態の間）コールがゼロ（またはそれ以上）の関連する接続を持っている可能性があることを意味します。ゼロ接続コールは、たとえば、接続セットアップの前にユーザーエンドポイント関係を設定するだけで定常状態です。次の変更されたメッセージを使用して、呼び出しを設定します。接続のセットアップは、上記のセクション5で定義されているメッセージを使用します。
<Path Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
<CALL_OPS>
<CALL_ID>
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
<GENERALIZED_UNI>
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the sender descriptor for unidirectional LSPs is:
単方向LSPの送信者記述子の形式は次のとおりです。
<sender descriptor> ::= <SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <RECORD_ROUTE> ]
The format of the sender descriptor for bidirectional LSPs is:
双方向LSPの送信者記述子の形式は次のとおりです。
<sender descriptor> ::= <SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <RECORD_ROUTE> ]
<UPSTREAM_LABEL>
Note that LABEL_REQUEST, SENDER_TSPEC and UPSTREAM_LABEL are not required for a call; however these are mandatory objects. As such, for backwards compatibility purposes, processing of these objects for a call follows the following rules:
label_request、sender_tspec、およびupstream_labelは呼び出しに必要ではないことに注意してください。ただし、これらは必須のオブジェクトです。そのため、後方互換性のために、呼び出しのこれらのオブジェクトを処理すると、次のルールに従います。
- These objects are ignored upon receipt; however, a valid-formatted object (e.g., by using the received valid object in the transmitted message) must be included in the generated message.
- これらのオブジェクトは受領時に無視されます。ただし、有効なフォーマットされたオブジェクト（たとえば、送信されたメッセージで受信した有効なオブジェクトを使用することにより）を生成されたメッセージに含める必要があります。
<Resv Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
<CALL_OPS>
<CALL_ID>
[ <RESV_CONFIRM> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE>
<flow descriptor list>
<flow descriptor list> ::=
<FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::=
<FLOWSPEC>
<FILTER_SPEC>
[ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::=
[ <FLOWSPEC> ]
<FILTER_SPEC>
[ <RECORD_ROUTE> ]
<SE flow descriptor> ::=
<FLOWSPEC>
<SE filter spec list>
<SE filter spec list> ::=
<SE filter spec>
| <SE filter spec list>
<SE filter spec>
<SE filter spec> ::=
<FILTER_SPEC>
[ <RECORD_ROUTE> ]
Note that FILTER_SPEC and LABEL are not required for a call; however these are mandatory objects. As such, for backwards compatibility purposes, processing of these objects for a call follows the following rules:
filter_specとラベルは呼び出しに必要ではないことに注意してください。ただし、これらは必須のオブジェクトです。そのため、後方互換性のために、呼び出しのこれらのオブジェクトを処理すると、次のルールに従います。
- These objects are ignored upon receipt; however, a valid-formatted object (e.g., by using the received valid object in the transmitted message) must be included in the generated message.
- これらのオブジェクトは受領時に無視されます。ただし、有効なフォーマットされたオブジェクト（たとえば、送信されたメッセージで受信した有効なオブジェクトを使用することにより）を生成されたメッセージに含める必要があります。
<PathTear Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<CALL_OPS>
<CALL_ID>
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition in this section)
<PathErr Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<CALL_OPS>
<CALL_ID>
<ERROR_SPEC>
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= (see earlier definition in this section)
<Notify message> ::= <Common Header>
[<INTEGRITY>]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
<notify session list> ::=
[ <notify session list> ]
<upstream notify session> |
<downstream notify session>
<upstream notify session> ::= <SESSION>
<CALL_ID>
[ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<downstream notify session> ::= <SESSION>
<CALL_ID>
[<POLICY_DATA>...]
<flow descriptor list descriptor>
This document introduces no new security considerations.
このドキュメントでは、新しいセキュリティ上の考慮事項は紹介されていません。
There are multiple fields and values defined within this document. IANA administers the assignment of these class numbers in the FCFS space as shown in [see: http://www.iana.org/assignments/rsvp-parameters].
このドキュメント内には、複数のフィールドと値が定義されています。IANAは、[http://www.iana.org/assignments/rsvp-parameters]に示すように、FCFSスペースでのこれらのクラス番号の割り当てを管理します。
No new messages are defined to support the functions discussed in this document.
このドキュメントで説明されている機能をサポートする新しいメッセージは定義されていません。
Two new objects are defined:
2つの新しいオブジェクトが定義されています。
- CALL_ID (ASON); this object should be assigned an object identifier of the form 11bbbbbb. A suggested value is 230. Two C-types are defined for this object - C-Type = 1: Operator specific - C-Type = 2: Globally unique
- call_id（ason）;このオブジェクトには、フォーム11bbbbbbbのオブジェクト識別子を割り当てる必要があります。提案された値は230です。このオブジェクトに対して2つのCタイプが定義されています-Cタイプ= 1：演算子固有-Cタイプ= 2：グローバルに一意
For the Type field, there is no range restriction, and the entire range 0x00 to 0xff is open for assignment, with 0x00 to 0x7f assignment based on FCFS and 0x80 to 0xff assignment reserved for Private Use. The assignments are defined in this document:
タイプフィールドの場合、範囲制限はありません。すべての範囲0x00〜0xffが割り当てに開かれており、FCFSに基づいて0x00〜0x7Fの割り当てと、プライベート使用のために予約されている0x80から0xff割り当てがあります。割り当てはこのドキュメントで定義されています。
- Type = 0x01: Source LSR address is 4-bytes - Type = 0x02: Source LSR address is 16-bytes - Type = 0x03: Source LSR address is 20-bytes - Type = 0x04: Source LSR address is 6-bytes - Type = 0x7f: the source LSR address has the length defined by the vendor - CALL_OPS (ASON); this object should be assigned an object identifier of the form 11bbbbbb. The value is 228. One C-type is defined for this object; the value is 1.
- タイプ= 0x01：ソースLSRアドレスは4バイトです - タイプ= 0x02：ソースLSRアドレスは16バイトです - タイプ= 0x03：ソースLSRアドレスは20バイトです-Type = 0x04：ソースLSRアドレスは6バイトです-Type = = Source0x7F：ソースLSRアドレスには、ベンダー-Call_ops（ASON）によって定義された長さがあります。このオブジェクトには、フォーム11bbbbbbbのオブジェクト識別子を割り当てる必要があります。値は228です。このオブジェクトに対して1つのCタイプが定義されています。値は1です。
One new sub-object is defined under the GENERALIZED_UNI object:
1つの新しいサブオブジェクトは、generalized_uniオブジェクトの下で定義されています。
- SPC_LABEL; this sub-object is part of the GENERALIZED_UNI object, as a sub-type of the EGRESS_LABEL sub-object (which is Type=4). The value is sub-type=2.
- spc_label;このサブオブジェクトは、generalized_uniオブジェクトの一部であり、egress_label sub-object（Type = 4）のサブタイプです。値はサブタイプ= 2です。
Three new C-Types are defined for the SESSION object (Class-num = 1):
セッションオブジェクトに対して3つの新しいCタイプが定義されています（クラス-Num = 1）：
- C-Type = 12 (ASON): UNI_IPv6 SESSION object - C-Type = 15 (ASON): ENNI_IPv4 SESSION object - C-Type = 16 (ASON): ENNI_IPv6 SESSION object
- c-type = 12（ason）：uni_ipv6セッションオブジェクト-c-type = 15（ason）：enni_ipv4セッションオブジェクト-c-type = 16（ason）：enni_ipv6セッションオブジェクト
No new error codes are required. The following new error values are defined. Error code 24 is defined in [RFC3209].
新しいエラーコードは必要ありません。次の新しいエラー値が定義されています。エラーコード24は[RFC3209]で定義されています。
24/103 (ASON): No route available toward source 24/104 (ASON): Unacceptable interface ID 24/105 (ASON): Invalid/unknown call ID 24/106 (ASON): Invalid SPC interface ID/label
24/103（ASON）：ソースに向けて利用できるルート24/104（ASON）：容認できないインターフェイスID 24/105（ASON）：無効/不明コールID 24/106（ASON）：無効なSPCインターフェイスID/ラベル
The authors would like to thank Osama Aboul-Magd, Jerry Ash, Sergio Belotti, Greg Bernstein, Adrian Farrel, Nic Larkin, Lyndon Ong, Dimitri Papadimitriou, Bala Rajagopalan, and Yangguang Xu for their comments and contributions to the document.
著者は、オサマ・アブール・マグド、ジェリー・アッシュ、セルジオ・ベロッティ、グレッグ・バーンスタイン、エイドリアン・ファレル、ニック・ラーキン、リンドン・オング、ディミトリ・パパディミトリウ、バラ・ラジャゴパラン、ヤンガン・XUに感謝します。
[G8080] ITU-T Rec. G.8080/Y.1304, Architecture for the Automatically Switched Optical Network (ASON), November 2001.
[g8080] itu-t rec。G.8080/Y.1304、2001年11月、自動化された光ネットワーク（ASON）のアーキテクチャ。
[G7713] ITU-T Rec. G.7713/Y.1704, Distributed Call and Connection Management (DCM), November 2001.
[g7713] itu-t rec。G.7713/Y.1704、分散コールおよび接続管理（DCM）、2001年11月。
[G7713.2] DCM Signalling Mechanisms Using GMPLS RSVP-TE, ITU-T G.7713.2, January 2003.
[G7713.2] GMPLS RSVP-TE、ITU-T G.7713.2、2003年1月を使用したDCMシグナル伝達メカニズム。
[OIF-UNI1] UNI 1.0 Signaling Specification, The Optical Internetworking Forum, http://www.oiforum.com/public/UNI_1.0_ia.html
[OIF-UNI1] UNI 1.0シグナル伝達仕様、光学インターネットワークフォーラム、http：//www.oiforum.com/uni_1.0_ia.html
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Editor, Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Editor、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource Reservation Protocol（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961] Berger、L.、Gan、D.、Pwallow、G.、Pan、P.、Tommasi、F。and S. Molendini、「RSVPリフレッシュオーバーヘッド削減拡張」、RFC 2961、2001年4月。
[RFC3209] Awaduche, 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] Awaduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (MPLS) - Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、編集者、「一般化されたマルチプロトコルラベルスイッチング（MPLS） - シグナリング機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (MPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、編集者、「一般化されたマルチプロトコルラベルスイッチング（MPLS）シグナル伝達 - リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3476] Rajagopalan, R., "Label Distribution Protocol (LDP) and Resource ReserVation Protocol (RSVP) Extensions for Optical UNI Signaling", RFC 3476, March 2003.
[RFC3476] Rajagopalan、R。、「ラベル分布プロトコル（LDP）および光学UNIシグナル伝達用のリソース予約プロトコル（RSVP）拡張」、RFC 3476、2003年3月。
[ITU-LIAISE] http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
[itu-liaise] http://www.ietf.org/iesg/liaison/itu-oif.html
[G807] ITU-T Rec. G.807/Y.1301, Requirements For Automatic Switched Transport Networks (ASTN), July 2001
[G807] itu-t rec。G.807/Y.1301、自動切り替え輸送ネットワーク（ASTN）の要件、2001年7月
[IPO-RQTS] Aboul-Magd, O., "Automatic Switched Optical Network (ASON) Architecture and Its Related Protocols", Work in Progress.
[IPO-RQTS] Aboul-Magd、O。、「自動スイッチされた光ネットワーク（ASON）アーキテクチャとその関連プロトコル」、進行中の作業。
[GMPLS-ASON] Lin, Z., "Requirements for Generalized MPLS (GMPLS) Usage and Extensions For Automatically Switched Optical Network (ASON)", Work in Progress.
[GMPLS-ASON] Lin、Z。、「自動化された光ネットワーク（ASON）の一般化されたMPLS（GMPLS）使用法と拡張機能の要件」、進行中の作業。
[ASON-RQTS] Xue, Y., "Carrier Optical Services Requirements", Work in Progress.
[Ason-Rqts] Xue、Y。、「キャリア光学サービス要件」、進行中の作業。
[GMPLS-SDHSONET] Mannie, E., "GMPLS Extensions for SONET and SDH Control", Work in Progress.
[Gmpls-Sdhsonet] Mannie、E。、「SONETおよびSDHコントロールのGMPLS拡張機能」、進行中の作業。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in RFC 2028. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、RFC 2028に記載されています。この仕様の実施者またはユーザーによるそのような独自の権利を使用するための一般的なライセンスまたは許可を取得するために行われたのは、IETF事務局から取得できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実践するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待します。情報をIETFエグゼクティブディレクターに宛ててください。
Sergio Belotti Alcatel Via Trento 30, I-20059 Vimercate, Italy EMail: sergio.belotti@netit.alcatel.it
TRENTO 30、I-20059 Vimercate、Italy Email：sergio.belotti@netit.alcatel.it経由のセルジオベロッティアルカテル
Nic Larkin Data Connection 100 Church Street, Enfield Middlesex EN2 6BQ, UK EMail: npl@dataconnection.com
Nic Larkin Data Connection 100 Church Street、Enfield Middlesex EN2 6BQ、英国メール：npl@dataconnection.com
Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium EMail: Dimitri.Papadimitriou@alcatel.be
Dimitri Papadimitriou Alcatel Francis Wellesplein 1、B-2018 Antwerpen、ベルギーメール：dimitri.papadimitriou@alcatel.be
Yangguang Xu Lucent 1600 Osgood St, Room 21-2A41 North Andover, MA 01845-1043 EMail: xuyg@lucent.com
Yangguang Xu Lucent 1600 Osgood St、Room 21-2A41 North Andover、MA 01845-1043メール：xuyg@lucent.com
Zhi-Wei Lin New York City Transit 2 Broadway, Room C3.25 New York, NY 10004
Zhi-Wei Lin New York City Transit 2 Broadway、Room C3.25 New York、NY 10004
EMail: zhiwlin@nyct.com
Dimitrios Pendarakis Tellium 2 Crescent Place Oceanport, NJ 07757-0901
Dimitrios Pendarakis Tellium 2 Crescent Place Oceanport、NJ 07757-0901
EMail: dpendarakis@tellium.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。