RFC3474 日本語訳
3474 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically SwitchedOptical Network (ASON). Z. Lin, D. Pendarakis. March 2003. (Format: TXT=52551 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Z. Lin
Request for Comments: 3474 New York City Transit
Category: Informational D. Pendarakis
Tellium
March 2003
コメントを求めるワーキンググループZ.リンの要求をネットワークでつないでください: 3474年のニューヨーク市のトランジットカテゴリ: 2003年の情報のD.Pendarakis Tellium行進
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)
Generalized MultiProtocol Label Switching(GMPLS)リソース予約プロトコルのためのIANA課題のドキュメンテーション--Automatically Switched Optical NetworkのためのトラフィックEngineering(RSVP-TE)用法とExtensions(ASON)
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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).
プロトコル仕様のGeneralized MultiProtocol Label Switching(GMPLS)スイートは、異なったアプリケーションと同様に異なった技術のサポートを提供するために定義されました。 これらはOptical Transport Networks(OTNs)と同様にSynchronous Optical NETwork/同期デジタルハイアラーキ(Sonet/SDH)に基づく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スイートのシグナリング局面に集中します、明確にGMPLSがResource予約プロトコルを使用することで合図して--トラフィックEngineering(RSVP-TE)。 それは、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 Study Group15によって特定されて、伝えられた追加要件の解決に向かって適切な拡大を提案します。
Lin & Pendarakis Informational [Page 1] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[1ページ]のRFC3474GMPLS RSVP-Te用法と拡大
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
1. このドキュメントで中古のコンベンション…3 2. 序論…3 3. 優しい永久接続のために、サポートします。3 4. 呼び出しのために、サポートします。4 4.1 識別子に電話をしてください、そして、能力に電話をしてください…4 4.1 .1 識別子に電話をしてください…4 4.1 .2 能力に電話をしてください…7 4.2 現在のGMPLSをするものが提供されます…7 4.3 呼び出しと接続のために、サポートします。7 4.3 .1 処理は統治されます…8 4.3 経路メッセージへの.2変更…8 4.3 Resvメッセージへの.3変更…9 4.3 PathTearメッセージへの.4変更…9 4.3 PathErrメッセージへの.5変更…10 4.3 メッセージに通知する.6変更…10 5. 振舞いには、コントロールの間、飛行機の故障をサポートしてください…11 6. ラベルには、用法をサポートしてください…12 7. UNIと電子NNIシグナリングセッションのために、サポートします。13 8. 追加誤り事件…14 9. サポートする任意の拡大は呼び出しと接続の離別を終了します…15 9.1 能力に電話をしてください…;.................................15 9.2 要求と接続(RSVP-Te拡大)の離別を終了してください…16 9.2 経路への.1変更…16 9.2 Resvへの.2変更…17 9.2 PathTearへの.3変更…18 9.2 PathErrへの.4変更…18 9.2 通知する.5変更…18 10. セキュリティ問題…19 11. IANA問題…新しいメッセージの19 11.1課題…新しいオブジェクトとサブオブジェクトの19 11.2課題…新しいC-タイプの19 11.3課題…新しいエラーコード/値の20 11.4課題…20 12. 承認…20 13. 参照…21 13.1 標準の参照…21 13.2 有益な参照…22 14. 知的所有権…23 15. 貢献者問い合わせ先…24 16. 作者のアドレス…24 17. 完全な著作権宣言文…25
Lin & Pendarakis Informational [Page 2] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[2ページ]のRFC3474GMPLS RSVP-Te用法と拡大
1. Conventions used in this document
1. 本書では使用されるコンベンション
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
2. Introduction
2. 序論
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対応することのネットワーク[G7713.2]のためのGMPLSに拡大を含んでいます。 [ASON-RQTS]と同様に[GMPLS-ASON]にこれらの拡大の必要性について説明する要件を提供します。 これらは:
- 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]、および[RFC3476]によってGMPLS RSVP-TEプロトコルの基礎と定義されたメッセージとオブジェクトを使用します、追加拡大が本書では定義されている状態で。
3. Support for Soft Permanent Connection
3. 優しい永久接続のサポート
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)であるとサポートするために、GENERALIZED_UNIオブジェクトのための1つの新しいサブタイプが定義されます。 GENERALIZED_UNIオブジェクトは[RFC3476]と[OIF-UNI1]で定義されます。 この新しいサブタイプには、EGRESS_LABELとして同じ形式と構造があります(サブタイプは新しいサブオブジェクトのための提案された値です):
- SPC_LABEL (Type=4, Sub-type=2)
- SPC_ラベル(タイプ=4、サブタイプの=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.
切り換えられた接続イングレスノードにおける切り換えられたセグメントがある永久的なイングレスセグメントのラベル協会は、その結果、このドキュメントの範囲を超えてローカルの方針問題(すなわち、マネージメントシステムと切り換えられた接続イングレスノードの間の)であり、います。
Lin & Pendarakis Informational [Page 3] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[3ページ]のRFC3474GMPLS RSVP-Te用法と拡大
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サブオブジェクトの処理はEGRESS_LABELサブオブジェクト[OIF-UNI1]のものに続きます。 [RFC3471]と[RFC3473]で説明された明白なラベルコントロールがGMPLSがアプリケーションであるとサポートすることの文脈で指定が出口ラベルであるとサポートするためにメカニズムを提供するかもしれませんが、ASONモデルのSPCサービスサポートがこの拡張子が、切り換えられた接続と優しい永久接続の両方のためにモデルを並べるのを助けて、GENERALIZED_UNIオブジェクトのサービスレベルと多様性属性を使用するのにGENERALIZED_UNIオブジェクトを使用することに注意してください。
4. Support for Call
4. 呼び出しのサポート
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メッセージセットに取り入れられます。 この基本的な呼び出し能力は、呼び出しモデルを紹介するのを助けます。 しかしながら、追加拡大が、正準な呼び出しモデル(完全な呼び出し/接続分離)を完全にサポートするのに必要であるかもしれません。
4.1 Call Identifier and Call Capability
4.1 呼び出し識別子と呼び出し能力
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.
Call識別子オブジェクトとCall能力オブジェクトの両方が完全な呼び出し/接続分離に使用されますが、Call識別子オブジェクトは論理的な呼び出し/接続分離に使用されます。
4.1.1 Call Identifier
4.1.1 識別子に電話をしてください。
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オブジェクトは呼び出し識別子を運びます。 値はグローバルにユニークです(Class-numは新しいオブジェクトのための提案された値です):
CALL_ID (Class-num = 230)
_をIDと呼んでください。(クラス-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 |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ|クラスヌム(230)| C-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子に電話をしてください。| ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the following C-types are defined:
以下のC-タイプが定義されるところ:
- C-Type = 1 (operator specific): The call identifier contains an
operator specific identifier.
- C-タイプ=1(オペレータ特有の): 呼び出し識別子はオペレータの特定の識別子を含んでいます。
- C-Type = 2 (globally unique): The call identifier contains a
globally unique part plus an operator specific identifier.
- C-タイプ=2(グローバルにユニークな): 呼び出し識別子はグローバルにユニークな部分とオペレータの特定の識別子を含んでいます。
Lin & Pendarakis Informational [Page 4] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[4ページ]のRFC3474GMPLS RSVP-Te用法と拡大
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.
- 識別子に電話をしてください: ジェネリック[長さ*8-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がソースLSRアドレスとローカルの識別子で構成されるところ)と共にグローバルにユニークな固定ID(国名略号、キャリヤーコード、ユニークなアクセスポイントコードで構成される)を連結することです。
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>(<国名略号>プラス<キャリヤーコード>と<のユニークなアクセスポイントコード>で構成される)と<オペレータの特定のID>(<ソースLSRアドレス>と<のローカルの識別子>で構成される)を含んでいます。 オペレータの特定のユニークさを必要とするだけであるCALL_IDに<オペレータだけの特定のID>が必要です、<のグローバルなID>と<オペレータの特定のID>の両方がグローバルに特有になるのに必要であるCALL_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キャラクタのSegment(<国名略号>)と12キャラクタのNational Segment(<キャリヤーコード>と<のユニークなアクセスポイントコード>)から成るものとします。 ITU-T Recommendation T.50によると、これらのキャラクタはコード化されるものとします。 国際Segment(ある)分野は3キャラクタISO3166Geographic/政治上のCountry Codeを提供します。 国名略号は大文字しているアルファベット3キャラクタのISO3166Country Code(例えば、米国、FRA)に基づくものとします。
National Segment (NS):
The National Segment (NS) field consists of two sub-fields:
国家のセグメント(ナノ秒): National Segment(NS)分野は2つのサブ分野から成ります:
- the first subfield contains the ITU Carrier Code
- the second subfield contains a Unique Access Point Code.
- 最初の部分体はITU Carrier Codeを含んでいます--2番目の部分体はUnique Access Point Codeを含んでいます。
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 Carrier CodeはRecommendation M.1400とのITU-T Telecommunication Service Bureauin協会によって維持されたネットワーク・オペレータ/サービスプロバイダーに配属されたコードです。 このコード、左で正当な状態で1-6から成る、アルファベットである、または先導アルファベットで数値キャラクタ(バイト)はあとに続いています。 コードが6つ未満のキャラクタ(バイト)であるなら、それは、部分体をいっぱいにするために引きずっているNULLと共に水増しされます。
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.
Unique Access Point Codeは国名略号とITUキャリヤーコードが配属された組織のための問題です、ユニークさが保証されれば。 12キャラクタのためにNational Segmentを完成して、NULLを引きずって、このコードは1-6 キャラクタ(バイト)から成ります。 コードが6つ未満のキャラクタであるなら、それは、部分体をいっぱいにするために引きずっているNULLによって水増しされます。
Lin & Pendarakis Informational [Page 5] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[5ページ]のRFC3474GMPLS RSVP-Te用法と拡大
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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キャリヤーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITU carrie dode(cont)| ユニークなアクセスポイントコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユニークなアクセスポイントコード(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Call identifier field for C-Type = 1:
C-タイプ=1のためのCall識別子分野の形式:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ|クラスヌム(230)| C-タイプ(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| Resv| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースLSRアドレス| ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルの識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルの識別子(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lin & Pendarakis Informational [Page 6] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[6ページ]のRFC3474GMPLS RSVP-Te用法と拡大
The format of the Call identifier field for C-Type = 2:
C-タイプ=2のためのCall識別子分野の形式:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ|クラスヌム(230)| C-タイプ(2)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| (3バイト)です。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NS(12バイト)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースLSRアドレス| ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルの識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ローカルの識別子(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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アドレスに使用される形式のタイプを示すために定義されます。 Type分野には、以下の意味があります: Type=0x01に関しては、ソースLSRアドレスが4バイトFor Type=0x02である、ソースLSRアドレスが16バイトFor Type=0x03である、ソースLSRアドレスが20バイトForタイプ=0x04である、ソースLSRアドレスが6バイトのForタイプ=0x7fである、ソース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アドレスがオペレータ特有のアドレス空間から割り当てられるかもしれないので、これは保証されません。
Lin & Pendarakis Informational [Page 7] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[7ページ]のRFC3474GMPLS RSVP-Te用法と拡大
4.1.2 Call Capability
4.1.2 能力に電話をしてください。
The call capability feature is provided in Section 10. This is an optional capability. If supported, section 10 extensions must be followed.
呼び出し能力機能をセクション10に提供します。 これは任意の能力です。 サポートされるなら、セクション10拡大に続かなければなりません。
4.2 What Does Current GMPLS Provide
4.2 GMPLSが供給する電流をすること
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]で定義されたシグナル伝達機構は、自動接続が管理であるとサポートします。 しかしながら、それは呼び出しモデルをサポートする能力を提供しません。 呼び出しは情報の異なった部分集合がメッセージによって運ばれるのを必要とする専用接続として見なされるかもしれません。 この情報は呼び出し/接続協会を設立する目的のために呼び出しコントローラに狙います。
4.3 Support for Call and Connection
4.3 呼び出しと接続のサポート
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つ(さらに)の関連接続があるかもしれません。 Aゼロ接続呼び出しは一時的な状態、例えば、-以前造の回復イベントを壊しているaの間、定義されます。
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オブジェクトはPathメッセージによって運ばれます。 新しいCALL_IDオブジェクトはPath、Resv、PathTear、PathErr、およびNotifyメッセージによって運ばれます。 ResvConfメッセージは変更されていないままにされます。 CALL_IDオブジェクト(呼び出しに関連している他のオブジェクト、例えば、GENERALIZED_UNIに伴う)は呼び出しコントローラによって処理されます、これらのメッセージに含まれていた他のオブジェクトが[RFC3473]で説明されるように接続コントローラによって処理されますが。 CALL_ID(そして、関係する)オブジェクトの処理は本書では説明されます。
Note: unmodified RSVP message formats are not listed below.
以下に注意してください。 変更されていないRSVPメッセージ・フォーマットは以下に記載されていません。
4.3.1 Processing Rules
4.3.1 処理規則
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-タイプを設定して、オールゼロに識別子値と呼ばなければなりません。 - 新しい発呼要求のために、最初のネットワーク・ノードは適切なC-タイプと値をCALL_IDに設定します。 - 既存の要求(CALL_IDが非ゼロであるといけないので)のために、最初のネットワーク・ノードは呼び出しの存在について確かめます。
Lin & Pendarakis Informational [Page 8] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[8ページ]のRFC3474GMPLS RSVP-Te用法と拡大
- 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-ヌムが選ばれているので、GMPLSへの拡大をASONに支えないノードは変更されていなく(範囲11bbbbbbの値)オブジェクトを進めます。 - 要求を受け取る目的地ユーザ/クライアントはソースユーザとそれ自体の間の要求された呼び出しの参照としてCALL_ID値を使用します。 その後の動作は参照識別子としてCALL_IDに呼び出し用途に関連しました。
4.3.2 Modification to Path Message
4.3.2 経路メッセージへの変更
<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>
<経路メッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>[<の明白な_ルート>]<ラベル_要求>[<呼び出し_ID>][<保護>]を評価します[<ラベル_は>を…設定しました]。 [<セッション_属性>] [<は_要求>に通知します] [<アドミン_状態>] [<は_UNI>を一般化しました] [<方針_データ>] <送付者記述子>。
The format of the sender descriptor for unidirectional LSPs is not modified by this document.
単方向LSPsの間の送付者記述子の形式はこのドキュメントによって変更されません。
The format of the sender descriptor for bidirectional LSPs is not modified by this document.
双方向のLSPsのための送付者記述子の形式はこのドキュメントによって変更されません。
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.
GMPLSシグナリングに、GENERALIZED_UNIとCALL_IDオブジェクトが任意ですが、これらのオブジェクトがASON対応することのネットワークに義務的であるというメモ、すなわち、PathメッセージはGENERALIZED_UNIとCALL_IDオブジェクトの両方を含まなければなりません。
Lin & Pendarakis Informational [Page 9] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[9ページ]のRFC3474GMPLS RSVP-Te用法と拡大
4.3.3 Modification to Resv Message
4.3.3 Resvメッセージへの変更
<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>
<Resvメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>] <セッション><RSVP_ホップ><時間_は>[<呼び出し_ID>][<RESV_は>を確認する]<範囲>を評価します[<は_要求>に通知します][<アドミン_状態>][<方針_データ>…]。 <様式><流れ記述子リスト>。
<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.
GMPLSシグナリングに、CALL_IDオブジェクトが任意ですが、このオブジェクトがASON対応することのネットワークに義務的であるというメモ、すなわち、ResvメッセージはCALL_IDオブジェクトを含まなければなりません。
4.3.4 Modification to PathTear Message
4.3.4 PathTearメッセージへの変更
<PathTear Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
[ <CALL_ID> ]
[ <sender descriptor> ]
<PathTearメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>]<セッション><RSVP_ホップ>[<呼び出し_ID>][<送付者記述子>]
<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.
GMPLSシグナリングに、CALL_IDオブジェクトが任意ですが、このオブジェクトがASON対応することのネットワークに義務的であるというメモ、すなわち、PathTearメッセージはCALL_IDオブジェクトを含まなければなりません。
Lin & Pendarakis Informational [Page 10] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[10ページ]のRFC3474GMPLS RSVP-Te用法と拡大
4.3.5 Modification to PathErr Message
4.3.5 PathErrメッセージへの変更
<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>
<PathErrメッセージ>:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<メッセージ_ID>]<セッション>[<呼び出し_ID>]<誤り_仕様>[<の許容できる_ラベル_は>を設定します][<方針_データ>…] <送付者記述子>。
<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.
GMPLSシグナリングに、CALL_IDオブジェクトが任意ですが、このオブジェクトがASON対応することのネットワークに義務的であるというメモ、すなわち、PathErrメッセージはCALL_IDオブジェクトを含まなければなりません。
4.3.6 Modification to Notify Message
4.3.6 メッセージに通知する変更
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>
<はメッセージ>に通知します:、:= <の一般的なヘッダー>[<保全>][_<メッセージ_ID ACK>| _<メッセージ_IDナック>] [<MESSAGE_ID>] ><が>を記載するようにセッションに通知する<ERROR_SPEC
<notify session list> ::=
[ <notify session list> ]
<upstream notify session> |
<downstream notify session>
<はセッションリスト>に通知します:、:= [<はセッションリスト>に通知します] <上流はセッション>に通知します。| <川下はセッション>に通知します。
<upstream notify session> ::= <SESSION>
[ <CALL_ID> ]
[ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<上流はセッション>に通知します:、:= <セッション>[<呼び出し_ID>][<アドミン_状態>][<方針_データ>…] <送付者記述子>。
<downstream notify session> ::= <SESSION>
[ <CALL_ID> ]
[<POLICY_DATA>...]
<flow descriptor list descriptor>
<川下はセッション>に通知します:、:= <セッション>[<呼び出し_ID>][<方針_データ>…] <流れ記述子リスト記述子>。
Lin & Pendarakis Informational [Page 11] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[11ページ]のRFC3474GMPLS RSVP-Te用法と拡大
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.
GMPLSシグナリングに、CALL_IDオブジェクトが任意ですが、このオブジェクトがASON対応することのネットワークに義務的であるというメモ、すなわち、NotifyメッセージはCALL_IDオブジェクトを含まなければなりません。
5. Support For Behaviors during Control Plane Failures
5. コントロール飛行機の故障の間の振舞いのサポート
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.
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.
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]):
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]):
- 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
- 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
Lin & Pendarakis Informational [Page 12] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
Lin & Pendarakis Informational [Page 12] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
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.
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.
6. Support For Label Usage
6. Support For Label Usage
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.
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.
+-----+ +-----+ | | +---+ +---+ | | | A |---| B |---| C |---| Z | | | +---+ +---+ | | +-----+ +-----+
+-----+ +-----+ | | +---+ +---+ | | | 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.
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.
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
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
Lin & Pendarakis Informational [Page 13] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
Lin & Pendarakis Informational [Page 13] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
(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.
(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.
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:
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
- 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.
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.
7. Support for UNI and E-NNI Signaling Session
7. Support for UNI and E-NNI Signaling Session
[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] 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.
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
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.
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.
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
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
Lin & Pendarakis Informational [Page 14] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
Lin & Pendarakis Informational [Page 14] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
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.
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.
8. Additional Error Cases
8. Additional Error Cases
In the scope of ASON, the following additional error cases are defined:
In the scope of ASON, the following additional error cases are defined:
- 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).
- 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).
Lin & Pendarakis Informational [Page 15] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
Lin & Pendarakis Informational [Page 15] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
9. Optional Extensions for Supporting Complete Separation of Call and Connection
9. Optional Extensions for Supporting Complete Separation of Call and Connection
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.
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.
9.1 Call Capability
9.1 Call Capability
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.
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.
The CALL_OPS object is defined as follows (the Class-num is the suggested value for the new object):
The CALL_OPS object is defined as follows (the Class-num is the suggested value for the new object):
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
Two flags are currently defined for the "call ops flag": 0x01: call without connection 0x02: synchronizing a call (for restart mechanism)
9.2 Complete Separation of Call and Connection (RSVP-TE Extensions)
9.2 Complete Separation of Call and Connection (RSVP-TE Extensions)
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.
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.
Lin & Pendarakis Informational [Page 16] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
Lin & Pendarakis Informational [Page 16] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
9.2.1 Modification to Path
9.2.1 Modification to Path
<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>
<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:
The format of the sender descriptor for unidirectional LSPs is:
<sender descriptor> ::= <SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <RECORD_ROUTE> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> [ <RECORD_ROUTE> ]
The format of the sender descriptor for bidirectional LSPs is:
The format of the sender descriptor for bidirectional LSPs is:
<sender descriptor> ::= <SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <RECORD_ROUTE> ]
<UPSTREAM_LABEL>
<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:
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:
- 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.
- 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.
Lin & Pendarakis Informational [Page 17] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
Lin & Pendarakis Informational [Page 17] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
9.2.2 Modification to Resv
9.2.2 Modification to Resv
<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>
<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>
<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> ]
<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> ]
<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> ]
Lin & Pendarakis Informational [Page 18] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
Lin & Pendarakis Informational [Page 18] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
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:
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:
- 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.
- 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.
9.2.3 Modification to PathTear
9.2.3 Modification to PathTear
<PathTear Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<CALL_OPS>
<CALL_ID>
[ <sender descriptor> ]
<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)
<sender descriptor> ::= (see earlier definition in this section)
9.2.4 Modification to PathErr
9.2.4 Modification to PathErr
<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)
<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)
Lin & Pendarakis Informational [Page 19] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
Lin & Pendarakis Informational [Page 19] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
9.2.5 Modification to Notify
9.2.5 Modification to Notify
<Notify message> ::= <Common Header>
[<INTEGRITY>]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
<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>
<notify session list> ::= [ <notify session list> ] <upstream notify session> | <downstream notify session>
<upstream notify session> ::= <SESSION>
<CALL_ID>
[ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<upstream notify session> ::= <SESSION> <CALL_ID> [ <ADMIN_STATUS> ] [<POLICY_DATA>...] <sender descriptor>
<downstream notify session> ::= <SESSION>
<CALL_ID>
[<POLICY_DATA>...]
<flow descriptor list descriptor>
<downstream notify session> ::= <SESSION> <CALL_ID> [<POLICY_DATA>...] <flow descriptor list descriptor>
10. Security Considerations
10. Security Considerations
This document introduces no new security considerations.
This document introduces no new security considerations.
11. IANA Considerations
11. IANA 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].
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].
11.1 Assignment of New Messages
11.1 Assignment of New Messages
No new messages are defined to support the functions discussed in this document.
No new messages are defined to support the functions discussed in this document.
Lin & Pendarakis Informational [Page 20] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
Lin & Pendarakis Informational [Page 20] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
11.2 Assignment of New Objects and Sub-Objects
11.2 Assignment of New Objects and Sub-Objects
Two new objects are defined:
Two new objects are defined:
- 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); 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
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:
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:
- 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.
- 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.
One new sub-object is defined under the GENERALIZED_UNI object:
One new sub-object is defined under the GENERALIZED_UNI object:
- 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; 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.
11.3 Assignment of New C-Types
11.3 Assignment of New C-Types
Three new C-Types are defined for the SESSION object (Class-num = 1):
Three new C-Types are defined for the SESSION object (Class-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 SESSION object - C-Type = 15 (ASON): ENNI_IPv4 SESSION object - C-Type = 16 (ASON): ENNI_IPv6 SESSION object
11.4 Assignment of New Error Code/Values
11.4 Assignment of New Error Code/Values
No new error codes are required. The following new error values are defined. Error code 24 is defined in [RFC3209].
No new error codes are required. The following new error values are defined. Error code 24 is defined in [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): 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
Lin & Pendarakis Informational [Page 21] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
Lin & Pendarakis Informational [Page 21] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
12. Acknowledgements
12. Acknowledgements
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.
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.
13. References
13. References
13.1 Normative References
13.1 Normative References
[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, Architecture for the Automatically Switched Optical Network (ASON), November 2001.
[G7713] ITU-T Rec. G.7713/Y.1704, Distributed Call and
Connection Management (DCM), November 2001.
[G7713] ITU-T Rec. G.7713/Y.1704, Distributed Call and Connection Management (DCM), November 2001.
[G7713.2] DCM Signalling Mechanisms Using GMPLS RSVP-TE, ITU-T
G.7713.2, January 2003.
[G7713.2] DCM Signalling Mechanisms Using GMPLS RSVP-TE, ITU-T G.7713.2, January 2003.
[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 Signaling Specification, The Optical Internetworking Forum, http://www.oiforum.com/public/UNI_1.0_ia.html
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[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., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[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. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol
Label Switching (MPLS) - Signaling Functional
Description", RFC 3471, January 2003.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (MPLS) - Signaling Functional Description", RFC 3471, January 2003.
Lin & Pendarakis Informational [Page 22] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
Lin & Pendarakis Informational [Page 22] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
[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., Editor, "Generalized Multi-Protocol Label Switching (MPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3476] Rajagopalan, R., "Label Distribution Protocol (LDP)
and Resource ReserVation Protocol (RSVP) Extensions
for Optical UNI Signaling", RFC 3476, March 2003.
[RFC3476] Rajagopalan, R., "Label Distribution Protocol (LDP) and Resource ReserVation Protocol (RSVP) Extensions for Optical UNI Signaling", RFC 3476, March 2003.
[ITU-LIAISE] http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
[ITU-LIAISE] http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
13.2 Informative References
13.2 Informative References
[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, Requirements For Automatic Switched Transport Networks (ASTN), July 2001
[IPO-RQTS] Aboul-Magd, O., "Automatic Switched Optical Network
(ASON) Architecture and Its Related Protocols", Work
in Progress.
[IPO-RQTS] Aboul-Magd, O., "Automatic Switched Optical Network (ASON) Architecture and Its Related Protocols", Work in Progress.
[GMPLS-ASON] Lin, Z., "Requirements for Generalized MPLS (GMPLS)
Usage and Extensions For Automatically Switched
Optical Network (ASON)", Work in Progress.
Z.[GMPLS-ASON]リン、「一般化されたMPLS(GMPLS)用法のための要件と自動的に切り換えられた光学ネットワーク(ASON)のための拡大」は進行中で働いています。
[ASON-RQTS] Xue, Y., "Carrier Optical Services Requirements",
Work in Progress.
「キャリヤーの光学サービス要件」という[ASON-RQTS]シュー、Y.は進行中で働いています。
[GMPLS-SDHSONET] Mannie, E., "GMPLS Extensions for SONET and SDH
Control", Work in Progress.
[GMPLS-SDHSONET] マニー、E.、「SonetとSDHコントロールのためのGMPLS拡張子」が進行中で働いています。
14. Intellectual Property
14. 知的所有権
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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 RFC2028で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
Lin & Pendarakis Informational [Page 23] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[23ページ]のRFC3474GMPLS RSVP-Te用法と拡大
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専務に情報を記述してください。
15. Contributors Contact Information
15. 貢献者問い合わせ先
Sergio Belotti Alcatel Via Trento 30, I-20059 Vimercate, Italy EMail: sergio.belotti@netit.alcatel.it
トレント30を通したセルジオBelottiアルカテル、I-20059 Vimercate、イタリアはメールされます: sergio.belotti@netit.alcatel.it
Nic Larkin Data Connection 100 Church Street, Enfield Middlesex EN2 6BQ, UK EMail: npl@dataconnection.com
Nicラーキンデータ接続100チャーチストリート、エンフィールドミドルセックスEN2 6BQ、イギリスのメール: npl@dataconnection.com
Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium EMail: Dimitri.Papadimitriou@alcatel.be
ディミトリPapadimitriouアルカテルフランシスWellesplein1、B-2018アントウェルペン(ベルギー)はメールされます: Dimitri.Papadimitriou@alcatel.be
Yangguang Xu Lucent 1600 Osgood St, Room 21-2A41 North Andover, MA 01845-1043 EMail: xuyg@lucent.com
Yangguangのシューの透明な1600オズグッド通り、余地21-2A41ノースアンドーバー、MA01845-1043はメールされます: xuyg@lucent.com
16. Authors' Addresses
16. 作者のアドレス
Zhi-Wei Lin New York City Transit 2 Broadway, Room C3.25 New York, NY 10004
Zhi-ウェイ・リンのニューヨーク市のTransit2余地のC3.25ブロードウェイ(ニューヨーク)、ニューヨーク 10004
EMail: zhiwlin@nyct.com
メール: zhiwlin@nyct.com
Dimitrios Pendarakis Tellium 2 Crescent Place Oceanport, NJ 07757-0901
三日月形場所Oceanport、デーメートリオスPendarakis Tellium2ニュージャージー07757-0901
EMail: dpendarakis@tellium.com
メール: dpendarakis@tellium.com
Lin & Pendarakis Informational [Page 24] RFC 3474 GMPLS RSVP-TE Usage and Extensions for ASON March 2003
ASON行進2003年のリンとPendarakisの情報[24ページ]のRFC3474GMPLS RSVP-Te用法と拡大
17. Full Copyright Statement
17. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Lin & Pendarakis Informational [Page 25]
リンとPendarakis情報です。[25ページ]
一覧
スポンサーリンク
