RFC4974 日本語訳
4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Supportof Calls. D. Papadimitriou, A. Farrel. August 2007. (Format: TXT=72000 bytes) (Updates RFC3473) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Papadimitriou
Request for Comments: 4974 Alcatel
Updates: 3473 A. Farrel
Category: Standards Track Old Dog Consulting
August 2007
Papadimitriouがコメントのために要求するワーキンググループD.をネットワークでつないでください: 4974のアルカテルアップデート: 3473年のA.ファレルカテゴリ: 犬のコンサルティング2007年8月に古い標準化過程
Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions
in Support of Calls
呼び出しを支持して拡大を示す一般化されたMPLS(GMPLS)RSVP-Te
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls.
あるネットワークtopologiesでは、サービスのインスタンスをサポートするために終点と主要な乗り継ぎ地点との協会を維持するのは有利であるかもしれません。 そのような協会はCallsとして知られています。
A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs).
Callはユーザトラフィックを伝えるための実際の接続性を提供しませんが、その後のコネクションズが作られるかもしれない関係を築き上げるだけです。 Generalized MPLS(GMPLS)では、そのようなコネクションズはLabel Switched Paths(LSPs)として知られています。
This document specifies how GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation.
このドキュメントはGMPLS Resource予約プロトコル--Engineering(RSVP-TE)シグナリングを取引するのがCallsをサポートするためにどう使用されて、広げられるかもしれないかを指定します。 これらのメカニズムは完全で論理的なCall/接続分離を提供します。
The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching.
どんな環境(マルチ領域を含んでいる)、およびどんなタイプのインタフェースにも、本書では提案されたメカニズムは適切です: パケット、層-2、多重送信された時間分割、λ、またはファイバーの切り換え。
Papadimitriou & Farrel Standards Track [Page 1] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[1ページ]RFC4974GMPLS RSVP-Te
Table of Contents
目次
1. Introduction ....................................................3
1.1. Applicability to ASON ......................................4
2. Conventions Used in This document ...............................4
3. Requirements ....................................................4
3.1. Basic Call Function ........................................4
3.2. Call/Connection Separation .................................5
3.3. Call Segments ..............................................5
4. Concepts and Terms ..............................................5
4.1. What Is a Call? ............................................5
4.2. A Hierarchy of Calls, Connections, Tunnels, and LSPs .......6
4.3. Exchanging Access Link Capabilities ........................6
4.3.1. Network-Initiated Calls .............................7
4.3.2. User-Initiated Calls ................................7
4.3.3. Utilizing Call Setup ................................8
5. Protocol Extensions for Calls and Connections ...................8
5.1. Call Setup and Teardown ....................................8
5.2. Call Identification ........................................9
5.2.1. Long Form Call Identification .......................9
5.2.2. Short Form Call Identification ......................9
5.2.3. Short Form Call ID Encoding ........................10
5.3. LINK_CAPABILITY Object ....................................11
5.4. Revised Message Formats ...................................12
5.4.1. Notify Message .....................................12
5.5. ADMIN_STATUS Object .......................................13
6. Procedures in Support of Calls and Connections .................14
6.1. Call/Connection Setup Procedures ..........................14
6.2. Call Setup ................................................14
6.2.1. Accepting Call Setup ...............................16
6.2.2. Call Setup Failure and Rejection ...................16
6.3. Adding a Connections to a Call ............................17
6.3.1. Adding a Reverse Direction LSP to a Call ...........18
6.4. Call-Free Connection Setup ................................18
6.5. Call Collision ............................................18
6.6. Call/Connection Teardown ..................................19
6.6.1. Removal of a Connection from a Call ................20
6.6.2. Removal of the Last Connection from a Call .........20
6.6.3. Teardown of an "Empty" Call ........................20
6.6.4. Attempted Teardown of a Call with Existing
Connections ........................................20
6.6.5. Teardown of a Call from the Egress .................21
6.7. Control Plane Survivability ...............................21
7. Applicability of Call and Connection Procedures ................22
7.1. Network-Initiated Calls ...................................22
7.2. User-Initiated Calls ......................................23
7.3. External Call Managers ....................................23
7.3.1. Call Segments ......................................23
1. 序論…3 1.1. ASONへの適用性…4 2. ThisドキュメントのコンベンションUsed…4 3. 要件…4 3.1. 基本的な呼び出し機能…4 3.2. 呼び出し/接続分離…5 3.3. セグメントに電話をしてください…5 4. 概念と用語…5 4.1. 呼び出しは何ですか? ............................................5 4.2. 呼び出し、コネクションズ、Tunnels、およびLSPsの階層構造…6 4.3. アクセスを交換して、能力をリンクしてください…6 4.3.1. ネットワークによって開始された呼び出し…7 4.3.2. ユーザによって開始された呼び出し…7 4.3.3. 呼び出しを利用して、セットアップしてください…8 5. 呼び出しとコネクションズのための拡大について議定書の中で述べてください…8 5.1. セットアップと分解に電話をしてください…8 5.2. 識別に電話をしてください…9 5.2.1. 長い間、呼び出し識別を形成してください…9 5.2.2. 縮約形呼び出し識別…9 5.2.3. 縮約形呼び出しIDコード化…10 5.3. _能力オブジェクトをリンクしてください…11 5.4. メッセージ・フォーマットを改訂します…12 5.4.1. メッセージに通知してください…12 5.5. アドミン_状態オブジェクト…13 6. 呼び出しとコネクションズを支持した手順…14 6.1. 呼び出し/接続設定手順…14 6.2. セットアップに電話をしてください…14 6.2.1. 呼び出しを受け入れて、セットアップしてください…16 6.2.2. 失敗と拒絶にセットアップに電話をしてください…16 6.3. 呼び出しにコネクションズを加えます…17 6.3.1. 逆の方向LSPを呼び出しに加えます…18 6.4. 無呼び出しの接続設定…18 6.5. 衝突に電話をしてください…18 6.6. 呼び出し/接続分解…19 6.6.1. 呼び出しからの接続の解任…20 6.6.2. 呼び出しからの最後の接続の解任…20 6.6.3. 「空」の呼び出しの分解…20 6.6.4. 既存のコネクションズとの呼び出しの分解を試みます…20 6.6.5. 出口からの呼び出しの分解…21 6.7. 飛行機の生存性を制御してください…21 7. 呼び出しと接続手順の適用性…22 7.1. ネットワークによって開始された呼び出し…22 7.2. ユーザによって開始された呼び出し…23 7.3. 外部の呼び出しマネージャ…23 7.3.1. セグメントに電話をしてください…23
Papadimitriou & Farrel Standards Track [Page 2] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[2ページ]RFC4974GMPLS RSVP-Te
8. Non-Support of Call ID .........................................24
8.1. Non-Support by External Call Managers .....................24
8.2. Non-Support by Transit Node ...............................24
8.3. Non-Support by Egress Node ................................25
9. Security Considerations ........................................25
9.1. Call and Connection Security Considerations ...............25
10. IANA Considerations ...........................................26
10.1. RSVP Objects .............................................26
10.2. RSVP Error Codes and Error Values ........................27
10.3. RSVP ADMIN_STATUS Object Bits ............................27
11. Acknowledgements ..............................................27
12. References ....................................................28
12.1. Normative References .....................................28
12.2. Informative References ...................................29
8. Call IDの非サポート…24 8.1. 外部の呼び出しマネージャによる非サポート…24 8.2. トランジットノードによる非サポート…24 8.3. 出口ノードによる非サポート…25 9. セキュリティ問題…25 9.1. 呼び出しと接続セキュリティ問題…25 10. IANA問題…26 10.1. RSVPは反対します…26 10.2. RSVPエラーコードと誤り値…27 10.3. RSVPアドミン_状態オブジェクトビット…27 11. 承認…27 12. 参照…28 12.1. 標準の参照…28 12.2. 有益な参照…29
1. Introduction
1. 序論
This document defines protocol procedures and extensions to support Calls within Generalized MPLS (GMPLS).
このドキュメントは、Generalized MPLS(GMPLS)の中でCallsをサポートするためにプロトコル手順と拡大を定義します。
A Call is an association between endpoints and possibly between key transit points (such as network boundaries) in support of an instance of a service. The end-to-end association is termed a "Call", and the association between two transit points or between an endpoint and a transit point is termed a "Call Segment". An entity that processes a Call or Call Segment is called a "Call Manager".
Callは終点とサービスのインスタンスを支持したことによると主要な乗り継ぎ地点(ネットワーク限界などの)との協会です。 終わりから終わりへの協会は「呼び出し」と呼ばれます、そして、2乗り継ぎ地点か終点と乗り継ぎ地点との協会は「呼び出しセグメント」と呼ばれます。 CallかCall Segmentを処理する実体は「呼び出しマネージャ」と呼ばれます。
A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In GMPLS, such Connections are known as Label Switched Paths (LSPs). This document does not modify Connection setup procedures defined in [RFC3473], [RFC4208], and [STITCH]. Connections set up as part of a Call follow the rules defined in these documents.
Callはユーザトラフィックを伝えるための実際の接続性を提供しませんが、その後のコネクションズが作られるかもしれない関係を築き上げるだけです。 GMPLSでは、そのようなコネクションズはLabel Switched Paths(LSPs)として知られています。 このドキュメントは[RFC3473]、[RFC4208]、および[STITCH]で定義されたConnectionセットアップ手順を変更しません。 Callの一部としてセットアップされたコネクションズはこれらのドキュメントで定義された規則に従います。
A Call may be associated with zero, one, or more than one Connection, and a Connection may be associated with zero or one Call. Thus, full and logical Call/Connection separation is needed.
Callはゼロ、1、または1Connectionに関連しているかもしれません、そして、Connectionはゼロか1Callに関連しているかもしれません。 したがって、完全で論理的なCall/接続分離が必要です。
An example of the requirements for Calls can be found in the ITU-T's Automatically Switched Optical Network (ASON) architecture [G.8080] and specific requirements for support of Calls in this context can be found in [RFC4139]. Note, however, that while the mechanisms described in this document meet the requirements stated in [RFC4139], they have wider applicability.
ITU-TのAutomatically Switched Optical Network(ASON)アーキテクチャ[G.8080]でCallsのための要件に関する例を見つけることができます、そして、[RFC4139]でこのような関係においてはCallsのサポートのための決められた一定の要求を見つけることができます。 しかしながら、本書では説明されたメカニズムが[RFC4139]に述べられた必要条件を出迎えている間それらには、より広い適用性があることに注意してください。
Papadimitriou & Farrel Standards Track [Page 3] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[3ページ]RFC4974GMPLS RSVP-Te
The mechanisms defined in this document are equally applicable to any packet (PSC) interface, layer-2 interfaces (L2SC), TDM capable interfaces, LSC interfaces, or FSC interfaces. The mechanisms and protocol extensions are backward compatible, and can be used for Call management where only the Call Managers need to be aware of the protocol extensions.
本書では定義されたメカニズムは、層-2つの等しくどんなパケットにも適切な(PSC)インタフェース、インタフェース(L2SC)、TDMのできるインタフェース、LSCインタフェース、またはFSCインタフェースです。 メカニズムとプロトコル拡大が後方である、コンパチブル、Callマネージャだけがプロトコル拡大を意識している必要があるCall管理に使用できます。
1.1. Applicability to ASON
1.1. ASONへの適用性
[RFC4139] details the requirements on GMPLS signaling to satisfy the ASON architecture described in [G.8080]. The mechanisms described in this document meet the requirements for Calls as described in Sections 4.2 and 4.3 of [RFC4139] and the additional Call-related requirements in Sections 4.4, 4.7, 5, and 6 of [RFC4139].
[RFC4139]は[G.8080]で説明されたASONアーキテクチャを満たすと合図するGMPLSに関する要件を詳しく述べます。 本書では説明されたメカニズムはCallsのために[RFC4139]のセクション4.4、4.7、5、および6で[RFC4139]と追加Call関連の要件のセクション4.2と4.3で説明されるように条件を満たします。
[ASON-APPL] describes the applicability of GMPLS protocols to the ASON architecture.
[ASON-APPL]はGMPLSプロトコルの適用性についてASONアーキテクチャに説明します。
2. Conventions Used in This document
2. ThisのUsedが記録するコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
In addition, the reader is assumed to be familiar with the terminology used in [RFC3471], [RFC3473], [RFC3477], and [RFC3945].
さらに、読者が[RFC3471]、[RFC3473]、[RFC3477]、および[RFC3945]で使用される用語によく知られさせると思われます。
3. Requirements
3. 要件
3.1. Basic Call Function
3.1. 基本的な呼び出し機能
The Call concept is used to deliver the following capabilities:
Call概念は以下の能力を提供するのに使用されます:
- Verification and identification of the Call initiator (prior to
LSP setup).
- Call創始者(LSPセットアップの前の)の検証と識別。
- Support of virtual concatenation with diverse path component LSPs.
- さまざまの経路コンポーネントLSPsとの仮想の連結のサポート。
- Association of multiple LSPs with a single Call (note aspects
related to recovery are detailed in [RFC4426] and [GMPLS-E2E]).
- 独身のCall(回復に関連する注意局面は[RFC4426]と[2GMPLS EのE]で詳細である)と複数のLSPsの協会。
- Facilitation of control plane operations by allowing an
operational status change of the associated LSP.
- 関連LSPの操作上の状態変化を許容するのによるコントロール飛行機操作の簡易化。
Procedures and protocol extensions to support Call setup, and the association of Calls with Connections are described in Section 5 and onwards of this document.
コネクションズでCallがセットアップと、Callsの協会であるとサポートする手順とプロトコル拡大はこのドキュメントについてセクション5に前方へ説明されます。
Papadimitriou & Farrel Standards Track [Page 4] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[4ページ]RFC4974GMPLS RSVP-Te
3.2. Call/Connection Separation
3.2. 呼び出し/接続分離
Full and logical Call and Connection separation is required. That is:
完全で論理的なCallとConnection分離が必要です。 それは以下の通りです。
- It MUST be possible to establish a Connection without dependence
on a Call.
- Callへの依存なしで取引関係を築くのは可能であるに違いありません。
- It MUST be possible to establish a Call without any associated
Connections.
- 少しも関連コネクションズなしでCallを設立するのは可能であるに違いありません。
- It MUST be possible to associate more than one Connection with a
Call.
- 1ConnectionをCallに関連づけるのは可能であるに違いありません。
- Removal of the last Connection associated with a Call SHOULD NOT
result in the automatic removal of the Call except as a matter of
local policy at the ingress of the Call.
- ローカルの方針の問題を除いて、最後のConnectionの解任はCallの自動除去で結果ではなく、Call SHOULDとCallのイングレスで交際しました。
- Signaling of a Connection associated with a Call MUST NOT require
the distribution or retention of Call-related information (state)
within the network.
- Callに関連しているConnectionのシグナリングはネットワークの中でCall関連の情報(状態)の分配か保有を必要としてはいけません。
3.3. Call Segments
3.3. セグメントに電話をしてください。
Call Segment capabilities MUST be supported.
呼び出しSegment能力をサポートしなければなりません。
Procedures and (GMPLS) RSVP-TE signaling protocol extensions to support Call Segments are described in Section 7.3.1 of this document.
手順とCall Segmentsをサポートするためにプロトコル拡大を示す(GMPLS)RSVP-TEがこの.1通のセクション7.3ドキュメントで説明されます。
4. Concepts and Terms
4. 概念と用語
The concept of a Call and a Connection are also discussed in the ASON architecture [G.8080] and [RFC4139]. This section is not intended as a substitute for those documents, but is a brief summary of the key terms and concepts.
また、ASONアーキテクチャ[G.8080]と[RFC4139]でCallの概念とConnectionについて議論します。 このセクションは、それらのドキュメントの代用品として意図しませんが、主要な用語と概念の簡潔な概要です。
4.1. What Is a Call?
4.1. 呼び出しは何ですか?
A Call is an agreement between endpoints possibly in cooperation with the nodes that provide access to the network. Call setup may include capability exchange, policy, authorization, and security.
Callはことによるとネットワークへのアクセスを備えるノードと提携した終点の間の協定です。 呼び出しセットアップは能力交換、方針、承認、およびセキュリティを含むかもしれません。
A Call is used to facilitate and manage a set of Connections that provide end-to-end data services. While Connections require state to be maintained at nodes along the data path within the network, Calls do not involve the participation of transit nodes except to forward the Call management requests as transparent messages.
Callは、終わりから終わりに対するデータサービスを提供する1セットのコネクションズを容易にして、管理するのに使用されます。 コネクションズが、状態がネットワークの中でデータ経路に沿ってノードで維持されるのを必要としている間、経営者側が透明であるとして要求するCallにメッセージを転送する以外に、Callsはトランジットノードの参加にかかわりません。
Papadimitriou & Farrel Standards Track [Page 5] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[5ページ]RFC4974GMPLS RSVP-Te
A Call may be established and maintained independently of the Connections that it supports.
Callはそれがサポートするコネクションズの如何にかかわらず設立されて、維持されるかもしれません。
4.2. A Hierarchy of Calls, Connections, Tunnels, and LSPs
4.2. 呼び出し、コネクションズ、Tunnels、およびLSPsの階層構造
Clearly, there is a hierarchical relationship between Calls and Connections. One or more Connections may be associated with a Call. A Connection may not be part of more than one Call. A Connection may, however, exist without a Call.
明確に、Callsとコネクションズとの上下関係があります。 1つ以上のコネクションズがCallに関連しているかもしれません。 Connectionは1Callの一部でないかもしれません。 しかしながら、ConnectionはCallなしで存在するかもしれません。
In GMPLS RSVP-TE [RFC3473], a Connection is identified with a GMPLS TE Tunnel. Commonly, a Tunnel is identified with a single LSP, but it should be noted that for protection, load balancing, and many other functions, a Tunnel may be supported by multiple parallel LSPs. The following identification reproduces this hierarchy.
GMPLS RSVP-TE[RFC3473]では、ConnectionはGMPLS TE Tunnelと同一視されています。 一般的に、Tunnelは独身のLSPと同一視されていますが、保護、ロードバランシング、および他の多くの機能において、Tunnelが複数の平行なLSPsによってサポートされるかもしれないことに注意されるべきです。 以下の識別はこの階層構造を再生させます。
- Call IDs are unique within the context of the pair of addresses
that are the source and destination of the Call.
- 呼び出しIDはCallのソースと目的地であるアドレスの組の文脈の中でユニークです。
- Tunnel IDs are unique within the context of the Session (that is
the destination of the Tunnel). Applications may also find it
convenient to keep the Tunnel ID unique within the context of a
Call.
- トンネルIDはSessionの文脈の中でユニークです(それはTunnelの目的地です)。 また、アプリケーションは、Callの文脈の中でユニークにTunnel IDを保つのが便利であることがわかるかもしれません。
- LSP IDs are unique within the context of a Tunnel.
- LSP IDはTunnelの文脈の中でユニークです。
Note that the Call_ID value of zero is reserved and MUST NOT be used during LSP-independent Call establishment.
ゼロのCall_ID値が予約されていて、LSPから独立しているCall設立の間使用されてはいけないことに注意してください。
Throughout the remainder of this document, the terms LSP and Tunnel are used interchangeably with the term Connection. The case of a Tunnel that is supported by more than one LSP is covered implicitly.
このドキュメントの残り中では、用語のLSPとTunnelはConnectionという用語と共に互換性を持って使用されます。 1LSPによってサポートされるTunnelに関するケースはそれとなくカバーされています。
4.3. Exchanging Access Link Capabilities
4.3. アクセスリンク能力を交換します。
In an overlay model, it is useful for the ingress node of an LSP to know the link capabilities of the link between the network and the remote overlay network. In the language of [RFC4208], the ingress node can make use of information about the link between the egress core node (CN) and the remote edge node (EN). We call this link the egress network link. This information may allow the ingress node to tailor its LSP request to fit those capabilities and to better utilize network resources with regard to those capabilities.
オーバレイモデルでは、ネットワークとリモートオーバレイネットワークとのリンクのリンク能力を知るのはLSPのイングレスノードの役に立ちます。 [RFC4208]の言葉を借りて言えば、イングレスノードは出口コアノード(CN)とリモート縁のノード(EN)とのリンクの情報を利用できます。 私たちは、このリンクを出口のネットワークリンクと呼びます。 この情報で、イングレスノードは、それらの能力に合うというLSP要求を合わせて、それらの能力に関してネットワーク資源をよりよく利用するかもしれません。
For example, this might be used in transparent optical networks to supply information on lambda availability on egress network links, or, where the egress CN is capable of signal regeneration, it might provide a mechanism for negotiating signal quality attributes (such
例えば、これが出口のネットワークリンクに関するλの有用性の情報を提供するのに見え透いた光学ネットワークに使用されるかもしれないか、または出口CNは信号再生ができるところで信号を交渉するためのメカニズムに上質の属性を供給するかもしれない、(そのようなもの
Papadimitriou & Farrel Standards Track [Page 6] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[6ページ]RFC4974GMPLS RSVP-Te
as bit error rate). Similarly, in multi-domain routing environments, it could be used to provide end-to-end selection of component links (i.e., spatial attribute negotiation) where TE links have been bundled based on technology specific attributes.
ビット誤り率) 同様に、マルチドメインルーティング環境で、コンポーネントリンク(すなわち、空間属性交渉)の終わりから終わりへの品揃えをTEリンクが技術の特定の属性に基づいて添付されたところに提供するのにそれを使用できました。
In some circumstances, the Traffic Engineering Database (TED) may contain sufficient information for decisions to be made about which egress network link to use. In other circumstances, the TED might not contain this information and Call setup may provide a suitable mechanism to exchange information for this purpose. The Call- responder may use the Call parameters to select a subset of the available egress network links between the egress CN and the remote EN, and may report these links and their capabilities on the Call response so that the Call-initiator may select a suitable link.
いくつかの事情では、Traffic Engineering Database(TED)はどの出口のネットワークリンクを使用したらよいかに関して作られているという決定のための十分な情報を含むかもしれません。 他の事情では、TEDはこの情報を含まないかもしれません、そして、Callセットアップはこのために情報交換するために適当なメカニズムを提供するかもしれません。 Call応答者は、出口CNとリモートENとの利用可能な出口のネットワークリンクの部分集合を選択するのにCallパラメタを使用して、Call-創始者が適当なリンクを選択できるように、Call応答に関してこれらのリンクと彼らの能力を報告するかもしれません。
The sections that follow indicate the cases where the TED may be used, and those where Call parameter exchange may be appropriate.
従うセクションはTEDが使用されるかもしれないケース、およびCallパラメータ変換が適切であるかもしれないところのそれらを示します。
4.3.1. Network-Initiated Calls
4.3.1. ネットワークによって開始された呼び出し
Network-initiated Calls arise when the ingress (and correspondingly the egress) lie within the network and there may be no need to distribute additional link capability information over and above the information distributed by the TE and GMPLS extensions to the IGP. Further, it is possible that future extensions to these IGPs will allow the distribution of more detailed information including optical impairments.
そして、イングレスであるときに、ネットワークによって開始されたCallsが起こる、(出口) ネットワークとそこの偽りは対応する、情報と情報を超えた情報がTEで分配した追加リンク能力とGMPLS拡張子をIGPに分配する必要性でないかもしれません。 さらに、これらのIGPsへの今後の拡大が光の損傷を含むより詳細な情報の分配を許すのは、可能です。
4.3.2. User-Initiated Calls
4.3.2. ユーザによって開始された呼び出し
User-initiated Calls arise when the ingress (and correspondingly the egress) lie outside the network. Edge link information may not be visible within the core network, nor (and specifically) at other edge nodes. This may prevent an ingress from requesting suitable LSP characteristics to ensure successful LSP setup.
イングレスであるときに、ユーザによって開始されたCallsが起こる、(対応、出口) ネットワークの外に横たわってください。 縁のリンク情報は、コアネットワークの中で目に見えないで、他でノードを斜めに進ませるかもしれません(明確に)。 これは、イングレスが、うまくいっているLSPセットアップを確実にするよう適当なLSPの特性に要求するのを防ぐかもしれません。
Various solutions to this problem exist, including the definition of static TE links (that is, not advertised by a routing protocol) between the CNs and ENs. Nevertheless, special procedures may be necessary to advertise to the edge nodes outside of the network information about egress network links without also advertising the information specific to the contents of the network.
この問題への様々な解決は存在しています、CNsとENsの間に静的なTEリンクの定義を含んでいて(すなわち、ルーティング・プロトコルで、広告を出しません)。 それにもかかわらず、特別な手順が、出口のネットワークリンクに関するネットワーク情報の外にまた、ネットワークのコンテンツに特定の情報の広告を出さないで縁のノードに広告を出すのに必要であるかもしれません。
In the future, when the requirements on the information that needs to be supported are better understood, TE extensions to EGPs may be defined to provide this function, and new rules for leaking TE information between routing instances may be used.
未来に、EGPsへのTE拡張子はこの機能を提供するために定義されるかもしれません、そして、ルーティングインスタンスの間のTE情報を漏らすための新しい規則は使用されるかもしれません。(その時、サポートされる必要がある情報に関する要件は理解されているほうがよいです)。
Papadimitriou & Farrel Standards Track [Page 7] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[7ページ]RFC4974GMPLS RSVP-Te
4.3.3. Utilizing Call Setup
4.3.3. 呼び出しセットアップを利用します。
When IGP and EGP solutions are not available at the User-to-Network Interface (UNI), there is still a requirement to have the knowledge of the remote edge link capabilities at the local edge nodes.
IGPとEGPソリューションがUserからネットワークへのInterface(UNI)で利用可能でないときに、まだ、遠く離れた縁に関する知識にローカルの縁のノードで能力をリンクさせるという要件があります。
The Call setup procedure provides an opportunity to discover edge link capabilities of remote edge nodes before LSP setup is attempted.
Callセットアップ手順はLSPセットアップが試みられる前にリモート縁のノードの縁のリンク能力を発見する機会を提供します。
- The Call-responder can return information on one or more egress
network links. The Call-responder could return a full list of the
available links with information about the link capabilities, or
it could filter the list to return information about only those
links that might be appropriate to support the Connections needed
by the Call. To do this second option, the Call-responder must
determine such appropriate links from information carried in the
Call request including destination of the Call, and the level of
service (bandwidth, protection, etc.) required.
- Call-応答者は1個以上の出口のネットワークリンクの情報を返すことができます。 Call-応答者がリンク能力の情報との利用可能なリンクに関する完全リストを返すことができましたか、またはそれは、それらのCallによって必要とされたコネクションズをサポートするのが適切であるかもしれないリンクだけの情報を返すためにリストをフィルターにかけるかもしれません。 この2番目のオプションをするために、Call-応答者は、Callで運ばれた情報からのそのような適切なリンクが、Callの目的地、およびサービスのレベル(帯域幅、保護など)を含むのが必要であるよう要求すると決心しなければなりません。
- On receiving a Call response, the Call-initiator must determine
paths for the Connections (LSPs) that it will set up. The way
that it does this is out of scope for this document since it is an
implementation-specific, algorithmic process. However, it can
take as input the information about the available egress network
links as supplied in the Call response.
- Call応答を受けると、Call-創始者はそれがセットアップするコネクションズ(LSPs)のために経路を決定しなければなりません。 このドキュメントのための範囲の外にそれがこれをする方法が、それが実装特有の、そして、アルゴリズムのプロセスであるので、あります。 しかしながら、Call応答で供給するように利用可能な出口のネットワークリンクの情報を入力するとき、それは取ることができます。
The LINK_CAPABILITY object is defined to allow this information to be exchanged. The information that is included in this object is similar to that distributed by GMPLS-capable IGPs (see [RFC4202]).
LINK_CAPABILITYオブジェクトは、この情報が交換されるのを許容するために定義されます。 このオブジェクトに含まれている情報はGMPLSできるIGPsによって分配されたそれと同様です([RFC4202]を見てください)。
5. Protocol Extensions for Calls and Connections
5. 呼び出しとコネクションズのためのプロトコル拡大
This section describes the protocol extensions needed in support of Call identification and management of Calls and Connections. Procedures for the use of these protocol extensions are described in Section 6.
このセクションはCallsとコネクションズのCall識別と管理を支持して必要であるプロトコル拡大について説明します。 これらのプロトコル拡張子の使用のための手順はセクション6で説明されます。
5.1. Call Setup and Teardown
5.1. セットアップと分解に電話をしてください。
Calls are established independently of Connections through the use of the Notify message. The Notify message is a targeted message and does not need to follow the path of LSPs through the network.
呼び出しはNotifyメッセージの使用によるコネクションズの如何にかかわらず確立されます。 Notifyメッセージは、狙っているメッセージであり、ネットワークを通してLSPsの経路に続く必要はありません。
Simultaneous Call and Connection establishment (sometimes referred to as piggybacking) is not supported.
同時のCallとConnection設立(時々便乗と呼ばれる)はサポートされません。
Papadimitriou & Farrel Standards Track [Page 8] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[8ページ]RFC4974GMPLS RSVP-Te
5.2. Call Identification
5.2. 識別に電話をしてください。
As soon as the concept of a Call is introduced, it is necessary to support some means of identifying the Call. This becomes particularly important when Calls and Connections are separated and Connections must contain some reference to the Call.
Callの概念が紹介されるとすぐに、Callを特定するいくつかの手段をサポートするのが必要です。 Callsとコネクションズが切り離されて、コネクションズがCallの何らかの参照を含まなければならないと、これは特に重要になります。
A Call may be identified by a sequence of bytes that may have considerable (but not arbitrary) length. A Call ID of 40 bytes would not be unreasonable. It is not the place of this document to supply rules for encoding or parsing Call IDs, but it must provide a suitable means to communicate Call IDs within the protocol. The full Call identification is referred to as the long Call ID.
Callは相当で(任意でない)の長さを持っているかもしれないバイトの系列によって特定されるかもしれません。 40バイトのCall IDは無理でないでしょう。 このドキュメントがCall IDをコード化するか、または分析するための規則を供給する場所ではありませんが、それはプロトコルの中でCall IDを伝える適当な手段を提供しなければなりません。 完全なCall識別は長いCall IDと呼ばれます。
The Call_ID is only relevant at the sender and receiver nodes. Maintenance of this information in the signaling state is not mandated at any intermediate node. Thus, no change in [RFC3473] transit implementations is required and there are no backward compatibility issues. Forward compatibility is maintained by using the existing default values to indicate that no Call processing is required.
Call_IDは送付者と単に受信機ノードで関連しています。 シグナリング状態のこの情報のメインテナンスはどんな中間的ノードでも強制されません。 したがって、[RFC3473]トランジット実装における変化は全く必要ではありません、そして、どんな後方の互換性の問題もありません。 下位互換はいいえを示すのに既存のデフォルト値を使用することによって維持されて、Call処理が必要であるということです。
Further, the long Call ID is not required as part of the Connection (LSP) state even at the sender and receiver nodes so long as some form of correlation is available. This correlation is provided through the short Call ID.
さらに、何らかのフォームの相関関係が利用可能である限り、長いCall IDはConnection(LSP)状態の一部として送付者と受信機ノードでさえ必要ではありません。 短いCall IDを通してこの相関関係を提供します。
5.2.1. Long Form Call Identification
5.2.1. 長いフォーム呼び出し識別
The long Call ID is only required on the Notify message used to establish the Call. It is carried in the "Session Name" field of the SESSION_ATTRIBUTE object on the Notify message.
長いCall IDがCallを証明するのに使用されるNotifyメッセージで必要であるだけです。 それはNotifyメッセージで分野というSESSION_ATTRIBUTEオブジェクトの「セッション名」で運ばれます。
A unique value per Call is inserted in the "Session Name" field by the initiator of the Call. Subsequent core nodes MAY inspect this object and MUST forward this object transparently across network interfaces until reaching the egress node. Note that the structure of this field MAY be the object of further formatting depending on the naming convention(s). However, [RFC3209] defines the "Session Name" field as a Null padded display string, so any formatting conventions for the Call ID must be limited to this scope.
1Callあたり1つのユニークな値がCallの創始者によって分野という「セッション名」に挿入されます。 その後のコアノードは、このオブジェクトを点検するかもしれなくて、出口ノードに達するまで透過的にネットワーク・インターフェースの向こう側にこのオブジェクトを送らなければなりません。 この分野の構造が命名規則に依存するさらなる形式のオブジェクトであるかもしれないことに注意してください。 しかしながら、[RFC3209]が分野という「セッション名」をNullのそっと歩いているディスプレイストリングと定義するので、Call IDへのどんな形式コンベンションもこの範囲に制限しなければなりません。
5.2.2. Short Form Call Identification
5.2.2. 縮約形呼び出し識別
The Connections (LSPs) associated with a Call need to carry a reference to the Call - the short Call ID. A new field is added to the signaling protocol to identify an individual LSP with the Call to which it belongs.
コネクションズ(LSPs)はCallの参照を運ぶCallの必要性と交際しました--短いCall ID。 新しい分野は、それが属するCallと個々のLSPを同一視するためにシグナリングプロトコルに追加されます。
Papadimitriou & Farrel Standards Track [Page 9] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[9ページ]RFC4974GMPLS RSVP-Te
The new field is a 16-bit identifier (unique within the context of the address pairing provided by the Tunnel_End_Point_Address and the Sender_Address of the SENDER_TEMPLATE object) that MUST be exchanged on the Notify message during Call initialization and is used on all subsequent LSP messages that are associated with the Call. This identifier is known as the short Call ID and is encoded as described in Section 5.2.3. The Call ID MUST NOT be used as part of the processing to determine the session to which an RSVP signaling message applies. This does not generate any backward compatibility issue since the reserved field of the SESSION object defined in [RFC3209] MUST NOT be examined on receipt.
新しい分野はCall初期化の間、Notifyメッセージで交換しなければならなくて、すべてのCallに関連しているその後のLSPメッセージで使用される16ビットの識別子(Tunnel_End_Point_Addressによって提供されたアドレス組み合わせの文脈とSENDER_TEMPLATEオブジェクトのSender_Addressの中でユニークな)です。 この識別子は、短いCall IDとして知られていて、セクション5.2.3で説明されるようにコード化されます。 RSVPシグナリングメッセージが適用されるセッションを決定するのに処理の一部としてCall IDを使用してはいけません。 これは、領収書の上で[RFC3209]で定義されたSESSIONオブジェクトの予約された分野を調べてはいけないので、どんな後方の互換性問題も作りません。
In the unlikely case of short Call_ID exhaustion, local node policy decides upon specific actions to be taken, but might include the use of second Sender_Address. Local policy details are outside of the scope of this document.
短いCall_ID疲労困憊のありそうもない場合では、ローカルのノード方針は、特定の動作のときに取られると決めますが、第2Sender_Addressの使用を含むかもしれません。 ローカルの方針の詳細がこのドキュメントの範囲の外にあります。
5.2.3. Short Form Call ID Encoding
5.2.3. 縮約形呼び出しIDコード化
The short Call ID is carried in a 16-bit field in the SESSION object carried on the Notify message used during Call setup, and on all messages during LSP setup and management. The field used was previously reserved (MUST be set to zero on transmission and ignored on receipt). This ensures backward compatibility with nodes that do not utilize Calls.
短いCall IDはCallセットアップの間に使用されるNotifyメッセージの上と、そして、LSPセットアップと管理の間のすべてのメッセージの上で運ばれたSESSIONオブジェクトの16ビットの分野で運ばれます。 使用される分野は以前に、予約されました(トランスミッションのときにゼロに設定されて、領収書の上で無視しなければなりません)。 これはCallsを利用しないノードとの後方の互換性を確実にします。
The figure below shows the new version of the object.
以下の図はオブジェクトの新しいバージョンを示しています。
Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6)
クラス=セッション、クラスヌム=1、C-タイプ=7(IPv4)/8(IPv6)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv4/IPv6 Tunnel End Point Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call_ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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+++++++++++++++++++++++++++++++++~IPv4/IPv6トンネルエンドポイントアドレス~+++++++++++++++++++++++++++++++++| _をIDと呼んでください。| トンネルID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡張Tunnel ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209])
IPv4/IPv6はエンドポイントアドレスにトンネルを堀ります: 32ビット/128ビット([RFC3209]を見ます)
Call_ID: 16 bits
_をIDと呼んでください: 16ビット
A 16-bit identifier used in the SESSION object that remains
constant over the life of the Call. The Call_ID value MUST be set
to zero when there is no corresponding Call.
16ビットの識別子はCallの寿命の上でSESSIONオブジェクトでその残り定数を使用しました。 どんな対応するCallもないとき、Call_ID値をゼロに設定しなければなりません。
Papadimitriou & Farrel Standards Track [Page 10] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[10ページ]RFC4974GMPLS RSVP-Te
Tunnel ID: 16 bits (see [RFC3209])
IDにトンネルを堀ってください: 16ビット([RFC3209]を見ます)
Extended Tunnel ID: 32 bits/128 bits (see [RFC3209])
拡張Tunnel ID: 32ビット/128ビット([RFC3209]を見ます)
5.3. LINK_CAPABILITY Object
5.3. リンク_能力オブジェクト
The LINK_CAPABILITY object is introduced to support link capability exchange during Call setup and MAY be included in a Notify message used for Call setup. This optional object includes the link-local capabilities of a link joining the Call-initiating node (or Call- terminating node) to the network. The specific node is indicated by the source address of the Notify message.
LINK_CAPABILITYオブジェクトは、Callセットアップの間、リンク能力が交換であるとサポートするために導入されて、Callセットアップに使用されるNotifyメッセージに含まれるかもしれません。 この任意のオブジェクトはリンクがCallを開始しているノード(または、ノードを終えるCall)をネットワークに接合するリンク地方の能力を含んでいます。 特定のノードはNotifyメッセージのソースアドレスによって示されます。
The link reported can be a single link or can be a bundled link [RFC4201].
報告されたリンクは、単一のリンクであることができるか添付されたリンクであるかもしれません[RFC4201]。
The Class Number is selected so that the nodes that do not recognize this object drop it silently. That is, the top bit is set and the next bit is clear.
Class Numberが選択されるので、このオブジェクトを認識しないノードは静かにそれを下げます。 すなわち、トップビットは設定されます、そして、次のビットは明確です。
This object has the following format:
このオブジェクトには、以下の形式があります:
Class-Num = 133 (form 10bbbbbb), C_Type = 1
クラスヌム=133(フォーム10bbbbbb)、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //(Subobjects)//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the LINK_CAPABILITY object is defined as a series of variable-length data items called subobjects. The subobject format is defined in [RFC3209].
LINK_CAPABILITYオブジェクトのコンテンツは「副-オブジェクト」と呼ばれる一連の可変長のデータ項目と定義されます。 「副-オブジェクト」書式は[RFC3209]で定義されます。
The following subobjects are currently defined.
以下の「副-オブジェクト」は現在、定義されます。
- Type 1: the link local IPv4 address of a link or a numbered bundle
using the format defined in [RFC3209].
- タイプ1: 地方のIPv4が扱うリンクのリンクか[RFC3209]で定義された書式を使用する番号付のバンドル。
- Type 2: the link local IPv6 address of a link or a numbered bundle
using the format defined in [RFC3209].
- 2はタイプします: 地方のIPv6が扱うリンクのリンクか[RFC3209]で定義された書式を使用する番号付のバンドル。
- Type 4: the link local identifier of an unnumbered link or bundle
using the format defined in [RFC3477].
- 4はタイプします: [RFC3477]で定義された書式を使用する無数のリンクかバンドルのリンクのローカルの識別子。
Papadimitriou & Farrel Standards Track [Page 11] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[11ページ]RFC4974GMPLS RSVP-Te
- Type 64: the Maximum Reservable Bandwidth corresponding to this
link or bundle (see [RFC4201]).
- 64はタイプします: これに対応するMaximum Reservable Bandwidthはリンクするか、または荷物をまとめます([RFC4201]を見てください)。
- Type 65: the interface switching capability descriptor (see
[RFC4202]) corresponding to this link or bundle (see also
[RFC4201]).
- 65はタイプします: このリンクかバンドル(また[RFC4201]、見る)に対応するインタフェーススイッチング能力記述子([RFC4202]を見ます)。
Note: future revisions of this document may extend the above list.
以下に注意してください。 このドキュメントの今後の改正は上記のリストを広げるかもしれません。
A single instance of this object MAY be used to exchange capability information relating to more than one link or bundled link. In this case, the following ordering MUST be used:
このオブジェクトのただ一つのインスタンスは、1個以上のリンクに関連する能力情報を交換するのに使用されるか、またはリンクであると添付されるかもしれません。 この場合、以下の注文を使用しなければなりません:
- each link MUST be identified by an identifier subobject (Type 1,
2, or 4)
- 識別子「副-オブジェクト」は各リンクを特定しなければなりません。(タイプ1、2、または4)
- capability subobjects (Type 64 or 65, and future subobjects) MUST
be placed after the identifier subobject for the link or bundle to
which they refer.
- 彼らが参照するリンクかバンドルのための識別子「副-オブジェクト」の後に能力「副-オブジェクト」(タイプ64か65、および将来の「副-オブジェクト」)を置かなければなりません。
Multiple instances of the LINK_CAPABILITY object within the same Notify message are not supported by this specification. In the event that a Notify message contains multiple LINK_CAPABILITY objects, the receiver SHOULD process the first one as normal and SHOULD ignore subsequent instances of the object.
同じNotifyメッセージの中のLINK_CAPABILITYオブジェクトの複数のインスタンスはこの仕様でサポートされません。 Notifyメッセージが複数のLINK_CAPABILITYオブジェクトを含んでいる場合、標準とSHOULDがオブジェクトのその後のインスタンスを無視するとき、受信機SHOULDは最初のものを処理します。
5.4. Revised Message Formats
5.4. 改訂されたメッセージ・フォーマット
The Notify message is enhanced to support Call establishment and teardown of Calls. See Section 6 for a description of the procedures.
Notifyメッセージは、CallがCallsの設立と分解であるとサポートするために高められます。 手順の記述に関してセクション6を見てください。
5.4.1. Notify Message
5.4.1. メッセージに通知してください。
The Notify message is modified in support of Call establishment by the optional addition of the LINK_CAPABILITY object. Further, the SESSION_ATTRIBUTE object is added to the <notify session> sequence to carry the long Call ID. The presence of the SESSION_ATTRIBUTE object MAY be used to distinguish a Notify message used for Call management, but see Section 5.5 for another mechanism. The <notify session list> MAY be used to simultaneously set up multiple Calls.
NotifyメッセージはLINK_CAPABILITYオブジェクトの任意の追加によるCall設立を支持して変更されます。 さらに、加えられる_ATTRIBUTEが<に反対するSESSIONは、セッション>系列が長いCall IDを運ぶように通知します。 SESSION_ATTRIBUTEオブジェクトの存在はCall管理に使用されるNotifyメッセージを区別するのに使用されるかもしれませんが、別のメカニズムに関してセクション5.5を見てください。 <は、リスト>が使用されるかもしれないセッションが同時に複数のCallsをセットアップするように通知します。
Papadimitriou & Farrel Standards Track [Page 12] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[12ページ]RFC4974GMPLS RSVP-Te
The format of the Notify Message is as follows:
Notify Messageの形式は以下の通りです:
<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> ] <notify session>
<はセッションリスト>に通知します:、:= [<はセッションリスト>に通知します] <はセッション>に通知します。
<notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[ <POLICY_DATA>...]
[ <LINK_CAPABILITY> ]
[ <SESSION_ATTRIBUTE> ]
[ <sender descriptor> | <flow descriptor> ]
<はセッション>に通知します:、:= <セッション>[<アドミン_状態>][<方針_データ>…] [<リンク_能力>] [<セッション_属性>][<送付者記述子>| <流れ記述子>]
<sender descriptor> ::= see [RFC3473]
<送付者記述子>:、:= 見てください。[RFC3473]
<flow descriptor> ::= see [RFC3473]
<流れ記述子>:、:= 見てください。[RFC3473]
5.5. ADMIN_STATUS Object
5.5. アドミン_状態オブジェクト
Notify messages exchanged for Call control and management purposes carry a specific new bit (the Call Management or C bit) in the ADMIN_STATUS object.
Callコントロールと交換されたメッセージに通知してください。そうすれば、管理目的はADMIN_STATUSオブジェクトで特定の新しいビット(Call ManagementかCビット)を運びます。
[RFC3473] indicates that the format and contents of the ADMIN_STATUS object are as defined in [RFC3471]. The new "C" bit is added for Call control as shown below.
[RFC3473]は、[RFC3471]で定義されるようにADMIN_STATUSオブジェクトの形式とコンテンツがそうであることを示します。 新しい「C」ビットは呼び出しコントロールのために以下に示すように加えられます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |C|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| 予約されます。|C|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reflect (R): 1 bit - see [RFC3471]
Testing (T): 1 bit - see [RFC3471]
Administratively down (A): 1 bit - see [RFC3471]
Deletion in progress (D): 1 bit - see [RFC3471]
Call Management (C): 1 bit
(R)を反映してください: 1ビット--(T)をテストしながら、見てください[RFC3471]: 1ビット--行政上[RFC3471]を(A)に見てください: 1ビット--[RFC3471]削除の進行中の(D)を見てください: 1ビット--[RFC3471]が、Managementを(C)と呼ぶのを見てください: 1ビット
This bit is set when the message is being used to control
and manage a Call.
メッセージがCallを制御して、管理するのに使用されているとき、このビットは設定されます。
The procedures for the use of the C bit are described in Section 6.
Cビットの使用のための手順はセクション6で説明されます。
Papadimitriou & Farrel Standards Track [Page 13] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[13ページ]RFC4974GMPLS RSVP-Te
6. Procedures in Support of Calls and Connections
6. 呼び出しとコネクションズを支持した手順
6.1. Call/Connection Setup Procedures
6.1. 呼び出し/接続設定手順
This section describes the processing steps for Call and Connection setup.
このセクションはCallのための処理ステップとConnectionセットアップについて説明します。
There are three cases considered:
考えられた3つのケースがあります:
- A Call is set up without any associated Connection. It is assumed
that Connections will be added to the Call at a later time, but
this is neither a requirement nor a constraint.
- Callは少しも関連Connectionなしでセットアップされます。 コネクションズが後でCallに加えられると思われますが、これは、要件でなくてまた規制ではありません。
- A Connection may be added to an existing Call. This may happen if
the Call was set up without any associated Connections, or if
another Connection is added to a Call that already has one or more
associated Connections.
- Connectionは既存のCallに加えられるかもしれません。 Callが少しも関連コネクションズなしでセットアップされたか、または別のConnectionが既に1つを持っているCallか、より関連したコネクションズに加えられるなら、これは起こるかもしれません。
- A Connection may be established without any reference to a Call
(see Section 6.4). This encompasses the previous LSP setup
procedure.
- ConnectionはCallの少しも参照なしで設立されるかもしれません(セクション6.4を見てください)。 これは前のLSPセットアップ手順を包含します。
Note that a Call MUST NOT be imposed upon a Connection that is already established. To do so would require changing the short Call ID in the SESSION object of the existing LSPs and this would constitute a change in the Session Identifier. This is not allowed by existing protocol specifications.
既に設立されるConnectionにCallを課してはいけないことに注意してください。 そうするのは、既存のLSPsのSESSIONオブジェクトで短いCall IDを変えるのを必要とするでしょう、そして、これはSession Identifierにおける変化を構成するでしょう。 これは既存のプロトコル仕様で許容されていません。
Call and Connection teardown procedures are described later in Section 6.6.
呼び出しとConnection分解手順は後でセクション6.6で説明されます。
6.2. Call Setup
6.2. セットアップに電話をしてください。
A Call is set up before, and independent of, LSP (i.e., Connection) setup.
Callはセットアップの前とLSP(すなわち、Connection)セットアップセットアップされます。
Call setup MAY necessitate verification of the link status and link capability negotiation between the Call ingress node and the Call egress node. The procedure described below is applied only once for a Call and hence only once for the set of LSPs associated with a Call.
呼び出しセットアップは、CallイングレスノードとCall出口ノードの間でリンク状態の検証を必要として、能力交渉をリンクするかもしれません。 以下で説明された手順は、Callのために一度だけ適用されていてしたがって、LSPsのセットのための一度だけCallに関連しています。
The Notify message (see [RFC3473]) is used to signal the Call setup request and response. The new Call Management (C) bit in the ADMIN_STATUS object is used to indicate that this Notify is managing a Call. The Notify message is sent with source and destination IPv4/IPv6 addresses set to any of the routable ingress/egress node addresses respectively.
Notifyメッセージ([RFC3473]を見る)は、Callセットアップ要求と応答に合図するのに使用されます。 ADMIN_STATUSオブジェクトの新しいCall Management(C)ビットは、このNotifyがCallを管理しているのを示すのに使用されます。 ソースと共にNotifyメッセージを送ります、そして、送付先IPv4/IPv6アドレスはそれぞれ発送可能イングレス/出口ノードのいずれにもアドレスを設定します。
Papadimitriou & Farrel Standards Track [Page 14] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[14ページ]RFC4974GMPLS RSVP-Te
At least one session MUST be listed in the <notify session list> of
the Notify message. In order to allow for long identification of the
Call, the SESSION_ATTRIBUTE object is added as part of the <notify
session list>. Note that the ERROR_SPEC object is not relevant in
Call setup and MUST carry the Error Code zero ("Confirmation") to
indicate that there is no error.
<に記載しなければならない少なくとも1つのセッションがNotifyメッセージについてセッションリスト>に通知します。 Callの長い識別を考慮するために、加えられる_ATTRIBUTEが<の一部として反対するSESSIONはセッションリスト>に通知します。 ERROR_SPECオブジェクトがCallセットアップで関連していなくて、誤りが全くないのを示すために、Error Codeゼロ(「確認」)を運ばなければならないことに注意してください。
During Call setup, the ADMIN_STATUS object is sent with the following bits set. Bits not listed MUST be set to zero.
Callセットアップの間、以下のビットがセットした状態で、ADMIN_STATUSオブジェクトを送ります。 記載されなかったビットをゼロに設定しなければなりません。
R - to cause the egress to respond C - to indicate that the Notify message is managing a Call.
R--、出口がCを反応させることを引き起こしてください--Notifyメッセージがa Callを管理しているのを示すために。
The SESSION, SESSION_ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects included in the <notify session> of the Notify message are built as follows.
SESSION、SESSION_ATTRIBUTE、SENDER_TEMPLATE、<にオブジェクトを含んでいると以下の通り造られるようにNotifyメッセージのセッション>に通知されるSENDER_TSPEC。
- The SESSION object includes as Tunnel_End_Point_Address any of the
Call-terminating (egress) node's IPv4/IPv6 routable addresses.
The Call_ID is set to a non-zero value unique within the context
of the address pairing provided by the Tunnel_End_Point_Address
and the Sender_Address from the SENDER_TEMPLATE object (see
below). This value will be used as the short Call ID carried on
all messages for LSPs associated with this Call.
- SESSIONオブジェクトはTunnel_End_Point_AddressとしてノードのIPv4/IPv6 routableが扱うCall-終わり(出口)のいずれも含んでいます。 SENDER_TEMPLATEからのPoint_AddressとSender_AddressがTunnel_End_で反対するなら(以下を見てください)、Call_IDはアドレス組み合わせの文脈の中でユニークな非ゼロ値に設定されます。 短いCall IDがこのCallに関連しているLSPsへのすべてのメッセージで運ばれたので、この値は使用されるでしょう。
Note that the Call_ID value of zero is reserved and MUST NOT be
used since it will be present in SESSION objects of LSPs that are
not associated with Calls. The Tunnel_ID of the SESSION object is
not relevant for this procedure and SHOULD be set to zero. The
Extended_Tunnel_ID of the SESSION object is not relevant for this
procedure and MAY be set to zero or to an address of the ingress
node.
それがCallsに関連づけられないLSPsのSESSIONオブジェクトに存在するので、ゼロのCall_ID値が予約されていて、使用されてはいけないことに注意してください。 SESSIONオブジェクトのTunnel_IDはこの手順とSHOULDにおいて関連しているのが、ゼロへのセットであるということではありません。 SESSIONオブジェクトのExtended_Tunnel_IDは、この手順において関連していなくて、ゼロ、または、イングレスノードのアドレスに設定されるかもしれません。
- The SESSION_ATTRIBUTE object contains priority flags. Currently
no use of these flags is envisioned, however, future work may
identify value in assigning priorities to Calls; accordingly the
Priority fields MAY be set to non-zero values. None of the Flags
in the SESSION_ATTRIBUTE object is relevant to this process and
this field SHOULD be set to zero. The Session Name field is used
to carry the long Call Id as described in Section 5.
- SESSION_ATTRIBUTEオブジェクトは優先権旗を含んでいます。 しかしながら、現在の、これらの旗の無駄は思い描かれて、今後の活動はプライオリティをCallsに割り当てる際に値を特定するかもしれません。 それに従って、Priority分野は非ゼロ値に設定されるかもしれません。 SESSION_ATTRIBUTEオブジェクトのFlagsのいずれによるこのプロセスとこの分野SHOULDに関連しているのが、ゼロへのセットであるということではありません。 Session Name分野は、セクション5で説明されるように長いCall Idを運ぶのに使用されます。
- The SENDER_TEMPLATE object includes as Sender Address any of the
Call-initiating (ingress) node's IPv4/IPv6 routable addresses.
The LSP_ID is not relevant and SHOULD be set to zero.
- SENDER_TEMPLATEオブジェクトはSender AddressとしてノードのIPv4/IPv6 routableが扱うCallを開始している(イングレス)のいずれも含んでいます。 LSP_IDが関連していない、SHOULD、ゼロに設定されてください。
- The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC
objects MUST be ignored upon receipt and SHOULD be set to zero
when sent.
- 帯域幅値は_TSPECをSENDERに挿入しました、そして、領収書でFLOWSPECオブジェクトを無視しなければなりませんでした、そして、ゼロへのセットがいつであったかときに、SHOULDは発信しました。
Papadimitriou & Farrel Standards Track [Page 15] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[15ページ]RFC4974GMPLS RSVP-Te
Additionally, ingress/egress nodes that need to communicate their respective link local capabilities may include a LINK_CAPABILITY object in the Notify message.
さらに、それぞれのリンク地元の能力を伝える必要があるイングレス/出口ノードはNotifyメッセージにLINK_CAPABILITYオブジェクトを含むかもしれません。
The receiver of a Notify message may identify whether it is part of Call management or reporting an error by the presence or absence of the SESSION_ATTRIBUTE object in the <notify session list>. Full clarity, however, may be achieved by inspection of the new Call Management (C) bit in the ADMIN_STATUS object.
Notifyメッセージの受信機は、それが経営者側か<のSESSION_ATTRIBUTEオブジェクトの存在か不在で誤りを報告すると>を記載するようにセッションに通知されるCallの一部であるかどうか特定するかもしれません。 しかしながら、完全な明快はADMIN_STATUSオブジェクトでの新しいCall Management(C)ビットの点検で達成されるかもしれません。
Note that the POLICY_DATA object may be included in the <notify session list> and MAY be used to identify requestor credentials, account numbers, limits, quotas, etc. This object is opaque to RSVP, which simply passes it to policy control when required.
含まれるかもしれない_DATAが<で反対するPOLICYが要請者資格証明書、口座番号、限界、割当てなどを特定するのにセッションリスト>に通知して、使用されているかもしれないことに注意してください。 このオブジェクトはRSVPに不透明です。(単に、必要であると、RSVPは方針コントロールにそれを通過します)。
Message IDs MUST be used during Call setup.
Callセットアップの間、メッセージIDを使用しなければなりません。
6.2.1. Accepting Call Setup
6.2.1. 呼び出しセットアップを受け入れます。
A node that receives a Notify message carrying the ADMIN_STATUS object with the R and C bits set is being requested to set up a Call. The receiver MAY perform authorization and policy according to local requirements.
ビットが設定するRとCと共にADMIN_STATUSオブジェクトを運びながらNotifyメッセージを受け取るノードがCallをセットアップするよう要求されています。 地方の要件に従って、受信機は承認と方針を実行するかもしれません。
If the Call is acceptable, the receiver responds with a Notify message reflecting the information from the Call request with two exceptions.
Callが許容できるなら、NotifyメッセージがCall要求から2つの例外で情報を反映している状態で、受信機は応じます。
- The responder removes any LINK_CAPABLITY object that was received
and MAY insert a LINK_CAPABILITY object that describes its own
access link.
- 応答者は、受け取られたどんなLINK_CAPABLITYオブジェクトも取り除いて、それ自身のアクセスリンクについて説明するLINK_CAPABILITYオブジェクトを挿入するかもしれません。
- The ADMIN_STATUS object is sent with only the C bit set. All
other bits MUST be set to zero.
- Cビットだけがセットした状態で、ADMIN_STATUSオブジェクトを送ります。 他のすべてのビットをゼロに設定しなければなりません。
The responder MUST use the Message ID object to ensure reliable delivery of the response. If no Message ID Acknowledgement is received after the configured number of retries, the responder SHOULD continue to assume that the Call was successfully established. Call liveliness procedures are covered in Section 6.7.
応答者は、応答の信頼できる配信を確実にするのにMessage IDオブジェクトを使用しなければなりません。 再試行の構成された数の後にMessage ID Acknowledgementを全く受け取らないなら、応答者SHOULDは、Callが首尾よく設立されたと仮定し続けています。 呼び出し活気手順はセクション6.7でカバーされています。
6.2.2. Call Setup Failure and Rejection
6.2.2. 失敗と拒絶にセットアップに電話をしてください。
Call setup may fail or be rejected.
呼び出しセットアップは、失敗するか、または拒絶されるかもしれません。
If the Notify message can not be delivered, no Message ID acknowledgement will be received by the sender. In the event that the sender has retransmitted the Notify message a configurable number
Notifyメッセージを提供できないと、Message ID承認は全く送付者によって受けられないでしょう。 送付者がNotifyのメッセージのa構成可能な番号を再送した場合
Papadimitriou & Farrel Standards Track [Page 16] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[16ページ]RFC4974GMPLS RSVP-Te
of times without receiving a Message ID Acknowledgement (as described in [RFC2961]), the initiator SHOULD declare the Call failed and SHOULD send a Call teardown request (see Section 6.6).
Message ID Acknowledgement([RFC2961]で説明されるように)を受けることのない回では、創始者SHOULDは、Callに失敗されていると宣言します、そして、SHOULDはCall分解要求を送ります(セクション6.6を見てください)。
It is also possible that a Message ID Acknowledgement is received but no Call response Notify message is received. In this case, the initiator MAY re-send the Call setup request a configurable number of times (see Section 6.7) before declaring that the Call has failed. At this point, the initiator MUST send a Call teardown request (see Section 6.6).
また、Message ID Acknowledgementが受け取られているのも、可能ですが、どんなCall応答Notifyメッセージも受信されていません。 この場合、創始者はCallが失敗したと宣言する前に、Callセットアップ要求に構成可能な数の回を再送するかもしれません(セクション6.7を見ます)。 ここに、創始者はCall分解要求を送らなければなりません(セクション6.6を見てください)。
If the Notify message cannot be parsed or is in error, it MAY be
responded to with a Notify message carrying the error code 13
("Unknown object class") or 14 ("Unknown object C-Type") if
appropriate to the error detected.
Notifyメッセージが分析できませんし、間違ってもいるなら、検出された誤りに適切であるなら、それはエラーコード13(「未知のオブジェクトのクラス」)かNotifyメッセージが運ばれている14(「未知のオブジェクトC-タイプ」)に反応するかもしれません。
The Call setup MAY be rejected by the receiver because of security, authorization, or policy reasons. Suitable error codes already exist [RFC2205] and can be used in the ERROR_SPEC object included in the Notify message sent in response.
Callセットアップはセキュリティ、承認、または方針理由で受信機によって拒絶されるかもしれません。 適当なエラーコードは、既に存在していて[RFC2205]、応答で送られたNotifyメッセージにERROR_SPECオブジェクトを含む際に使用できます。
Error response Notify messages SHOULD also use the Message ID object to achieve reliable delivery. No action should be taken on the failure to receive a Message ID Acknowledgement after the configured number of retries.
また、誤り応答NotifyメッセージSHOULDは、信頼できる配信を達成するのにMessage IDオブジェクトを使用します。 再試行の構成された数の後にMessage ID Acknowledgementを受け取らないことで行動を全く取るべきではありません。
6.3. Adding a Connections to a Call
6.3. 呼び出しにコネクションズを加えます。
Once a Call has been established, LSPs can be added to the Call. Since the short Call ID is part of the SESSION object, any LSP that has the same Call ID value in the SESSION object belongs to the same Call, and the Notify message used to establish the Call carried the same Call ID in its SESSION object.
Callがいったん設立されると、CallにLSPsを加えることができます。 短いCall IDがSESSIONオブジェクトの一部であるので、SESSIONオブジェクトに同じCall ID価値を持っているどんなLSPも同じCallに属します、そして、Callを証明するのに使用されるNotifyメッセージはSESSIONオブジェクトで同じCall IDを運びました。
There will be no confusion between LSPs that are associated with a Call and those which are not, since the Call ID value MUST be equal to zero for LSPs that are not associated with a Call, and MUST NOT be equal to zero for a valid Call ID.
Callに関連しているLSPsとそうしないそれらの間には、混乱が全くないでしょう、Call ID価値がCallに関連づけられないLSPsのためにゼロに合わせるために等しくなければならなく、有効なCall IDにゼロに合わせるために等しいはずがないので。
LSPs for different Calls can be distinguished because the Call ID is unique within the context of the source address (in the SENDER_TEMPLATE object) and the destination address (in the SESSION object).
Call IDがソースアドレス(SENDER_TEMPLATEオブジェクトの)と送付先アドレス(SESSIONオブジェクトの)の文脈の中でユニークであるので、異なったCallsのためのLSPsを区別できます。
Ingress and egress nodes MAY group together LSPs associated with the same Call and process them as a group according to implementation requirements. Transit nodes need not be aware of the association of multiple LSPs with the same Call.
イングレスと出口ノードは、同じCallに関連しているLSPsを一緒に分類して、実装要件に従って、グループとして彼らを処理するかもしれません。 トランジットノードは同じCallと複数のLSPsの協会を意識している必要はありません。
Papadimitriou & Farrel Standards Track [Page 17] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[17ページ]RFC4974GMPLS RSVP-Te
The ingress node MAY choose to set the "Session Name" of an LSP to match the long Call ID of the associated Call.
イングレスノードは、LSPの「セッション名」に関連Callの長いCall IDを合わせるように設定するのを選ぶかもしれません。
The C bit of the ADMIN_STATUS object MUST NOT be set on LSP messages including on Notify messages that pertain to the LSP and MUST be ignored.
ADMIN_STATUSオブジェクトのCビットをNotifyにLSPに関係するメッセージを含むLSPメッセージに設定されてはいけなくて、無視しなければなりません。
6.3.1. Adding a Reverse Direction LSP to a Call
6.3.1. 逆の方向LSPを呼び出しに加えます。
Note that once a Call has been established, it is symmetric. That is, either end of the Call may add LSPs to the Call.
Callがいったん設立される後、それが左右対称であることに注意してください。 Callのすなわちどちらの端もCallにLSPsを加えるかもしれません。
Special care is needed when managing LSPs in the reverse direction since the addresses in the SESSION and SENDER_TEMPLATE are reversed. However, since the short Call ID is unique in the context of a given ingress-egress address pair, it may safely be used to associate the LSP with the Call.
SESSIONとSENDER_TEMPLATEのアドレスが逆にされるので反対の方向にLSPsを管理するとき、特別な注意が必要です。 しかしながら、短いCall IDが与えられたイングレス出口アドレス組の文脈でユニークであるので、それはLSPをCallに関連づけるのに安全に使用されるかもしれません。
Note that since Calls are defined here to be symmetrical, the issue of potential Call ID collision arises. This is discussed in Section 6.5.
Callsが対称であるためにここで定義されるので潜在的Call ID衝突の問題が起こることに注意してください。 セクション6.5でこれについて議論します。
6.4. Call-Free Connection Setup
6.4. 無呼び出しの接続設定
It continues to be possible to set up LSPs as per [RFC3473] without associating them with a Call. If the short Call ID in the SESSION object is set to zero, there is no associated Call and the Session Name field in the SESSION_ATTRIBUTE object MUST be interpreted simply as the name of the session (see [RFC3209]).
それは彼らをCallに関連づけることのない[RFC3473]に従ってLSPsをセットアップするのにおいてずっと可能です。 SESSIONオブジェクトの短いCall IDがゼロに設定されるなら、どんな関連Callもありません、そして、単にセッションの名前としてSESSION_ATTRIBUTEオブジェクトのSession Name分野を解釈しなければなりません([RFC3209]を見てください)。
The C bit of the ADMIN_STATUS object MUST NOT be set on messages for LSP control, including on Notify messages that pertain to LSPs, and MUST be ignored when received on such messages.
ADMIN_STATUSオブジェクトのCビットをNotifyにLSPsに関係するメッセージを含むLSPコントロールへのメッセージに設定してはいけなくて、そのようなメッセージに受け取ると、無視しなければなりません。
6.5. Call Collision
6.5. 衝突に電話をしてください。
Since Calls are symmetrical, it is possible that both ends of a Call will attempt to establish Calls with the same long Call IDs at the same time. This is only an issue if the source and destination address pairs match. This situation can be avoided by applying some rules to the contents of the long Call ID, but such mechanisms are outside the scope of this document.
Callsが対称であるので、Callの両端が、同時に同じ長いCall IDでCallsを設立するのを試みるのは、可能です。 ソースと目的地アドレス組が合っている場合にだけ、これは問題です。 長いCall IDのコンテンツにいくつかの規則を適用することによって、この状況を避けることができますが、このドキュメントの範囲の外にそのようなメカニズムがあります。
If a node that has sent a Call setup request and has not yet received a response itself receives a Call setup request with the same long Call ID and matching source/destination addresses, it SHOULD process as follows:
Callセットアップ要求を送って、まだ応答自体を受けていないノードが受信するなら、Callセットアップは同じ長いCallと共にIDを要求します、そして、マッチングは/送付先アドレスの出典を明示します、そして、それは以下のSHOULDプロセスです:
Papadimitriou & Farrel Standards Track [Page 18] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[18ページ]RFC4974GMPLS RSVP-Te
- If its source address is numerically greater than the remote
source address, it MUST discard the received message and continue
to wait for a response to its setup request.
- ソースアドレスがリモートソースアドレスより数の上で大きいなら、それは、受信されたメッセージを捨てて、セットアップ要求への応答を待ち続けなければなりません。
- If its source address is numerically smaller than the remote
source address, it MUST discard state associated with the Call
setup that it initiated, and MUST respond to the received Call
setup.
- ソースアドレスがリモートソースアドレスより数の上で小さいなら、それはそれが容認されたCallセットアップに着手して、反応させなければならないCallセットアップに関連している状態を捨てなければなりません。
If a node receives a Call setup request carrying an address pair and long Call ID that match an existing Call, the node MUST return an error message (Notify message) with the new Error Code "Call Management" and the new Error Value "Duplicate Call" in response to the new Call request, and MUST NOT make any changes to the existing Call.
ノードが既存のCallに合っているアドレス組と長いCall IDを運びながらCallセットアップ要求を受け取るなら、ノードが「管理に電話をしてください」という新しいError Codeがあるエラーメッセージ(メッセージに通知する)を返さなければならなくて、新しいCallに対応した新しいError Value「写し呼び出し」は、既存のCallへのどんな変更も要求して、行ってはいけません。
A further possibility for contention arises when short Call IDs are assigned by a pair of nodes for two distinct Calls that are set up simultaneously using different long Call IDs. In this event, a node receives a Call setup request carrying a short Call ID that matches one that it previously sent for the same address pair. The following processing MUST be followed:
短いCall IDが同時にセットアップされる2異なったCallsのための1組のノードによって異なった長いCall IDを使用することで割り当てられるとき、主張のためのさらなる可能性は起こります。 このイベントでは、ノードは、それが以前に同じアドレス組のために送ったものに合っている短いCall IDを運びながら、Callセットアップ要求を受け取ります。 以下の処理に続かなければなりません:
- If the receiver's source address is numerically greater than the
remote source address, the receiver returns an error (Notify
message) with the new Error Code "Call Management" and the new
Error Value "Call ID Contention".
- 受信機のソースアドレスがリモートソースアドレスより数の上で大きいなら、受信機は新しいError Code「呼び出し管理」で誤りを返します、そして、(メッセージに通知します)新しいError Valueは「IDを主張と呼びます」。
- If the receiver's source address is numerically less than the
remote source address, the receiver accepts and processes the Call
request. It will receive an error message sent as described
above, and at that point, it selects a new short Call ID and re-
sends the Call setup request.
- 受信機のソースアドレスが数の上でそうなら、受信機は、Call要求を受け入れて、リモートソースアドレスほど処理しません。 上で説明されるように送られたエラーメッセージを受け取って、それは、その時、新しい短いCall IDを選択して、Callセットアップ要求を再送ります。
6.6. Call/Connection Teardown
6.6. 呼び出し/接続分解
As with Call/Connection setup, there are several cases to consider.
Call/接続設定のように、考える数個のケースがあります。
- Removal of a Connection from a Call - Removal of the last Connection from a Call - Teardown of an "empty" Call
- CallからのConnectionの解任--Callからの最後のConnectionの解任--「空」のCallの分解
The case of tearing down an LSP that is not associated with a Call does not need to be examined as it follows exactly the procedures described in [RFC3473].
まさに[RFC3473]で説明された手順に従うので、Callに関連づけられないLSPを取りこわすケースは調べられる必要はありません。
Papadimitriou & Farrel Standards Track [Page 19] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[19ページ]RFC4974GMPLS RSVP-Te
6.6.1. Removal of a Connection from a Call
6.6.1. 呼び出しからの接続の解任
An LSP that is associated with a Call may be deleted using the standard procedures described in [RFC3473]. No special procedures are required.
Callに関連しているLSPは、[RFC3473]で説明された標準手続きを使用することで削除されるかもしれません。 どんな特別な手順も必要ではありません。
Note that it is not possible to remove an LSP from a Call without deleting the LSP. It is not valid to change the short Call ID from non-zero to zero since this involves a change to the SESSION object, which is not allowed.
CallからLSPを削除しないでLSPを取り外すのが可能でないことに注意してください。 これが許容されていないSESSIONオブジェクトへの変化にかかわるので、短いCall IDを非ゼロ〜ゼロに変えるのは有効ではありません。
6.6.2. Removal of the Last Connection from a Call
6.6.2. 呼び出しからの最後の接続の解任
When the last LSP associated with a Call is deleted, the question arises as to what happens to the Call. Since a Call may exist independently of Connections, it is not always acceptable to say that the removal of the last LSP from a Call removes the Call.
Callに関連している最後のLSPが削除されるとき、何がCallに起こるかに関して質問は起こります。 Callがコネクションズの如何にかかわらず存在するかもしれないので、Callからの最後のLSPの解任がCallを取り外すと言うのはいつも許容できるというわけではありません。
The removal of the last LSP does not remove the Call and the procedures described in the next Section MUST be used to delete the Call.
最後のLSPの解任はCallを取り外しません、そして、Callを削除するのに次のセクションで説明された手順を用いなければなりません。
6.6.3. Teardown of an "Empty" Call
6.6.3. 「空」の呼び出しの分解
When all LSPs have been removed from a Call, the Call may be torn down or left for use by future LSPs.
CallからすべてのLSPsを取り外したとき、将来のLSPsによる使用にCallを取りこわすか、または残すかもしれません。
Deletion of Calls is achieved by sending a Notify message just as for Call setup, but the ADMIN_STATUS object carries the R, D, and C bits on the teardown request and the D and C bits on the teardown response. Other bits MUST be set to zero.
Callsの削除は、まさしくCallセットアップ、しかし、_STATUSがRを運ぶのを反対させるADMIN、D、およびCビットのように分解応答の分解要求、D、およびCビットにNotifyメッセージを送ることによって、達成されます。 他のビットをゼロに設定しなければなりません。
When a Notify message is sent for deleting a Call and the initiator does not receive the corresponding reflected Notify message (or possibly even the Message ID Ack), the initiator MAY retry the deletion request using the same retry procedures as used during Call establishment. If no response is received after full retry, the node deleting the Call MAY declare the Call deleted, but under such circumstances the node SHOULD avoid re-using the long or short Call IDs for at least five times the Notify refresh period.
NotifyメッセージがCallを削除しながら注文されて、創始者が対応する反射したNotifyメッセージ(または、ことによるとMessage ID Ackさえ)を受け取らないとき、Call設立の間、同じくらい中古の同じ再試行手順を用いて、創始者は削除要求を再試行するかもしれません。 完全な再試行の後に応答を全く受けないなら、Callを削除するノードは、Callが削除されていると宣言するかもしれませんが、これではノードSHOULDはNotifyがリフレッシュする少なくとも5回に長いか短いCall IDを再使用する期間を避けます。
6.6.4. Attempted Teardown of a Call with Existing Connections
6.6.4. 既存のコネクションズとの呼び出しの試みられた分解
If a Notify request with the D bit of the ADMIN_STATUS object set is received for a Call for which LSPs still exist, the request MUST be rejected with the Error Code "Call Management" and Error Value "Connections Still Exist". The state of the Call MUST NOT be changed.
LSPsがまだ存在しているCallのためにADMIN_STATUSオブジェクトセットのDビットによるNotify要求を受け取るなら、要求はError Code「呼び出し管理」とError Valueと共に拒絶されて、「コネクションズはまだ存在している」ということであるに違いありません。 Callの州を変えてはいけません。
Papadimitriou & Farrel Standards Track [Page 20] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
拡大2007年8月に合図するPapadimitriouとファレル標準化過程[20ページ]RFC4974GMPLS RSVP-Te
6.6.5. Teardown of a Call from the Egress
6.6.5. 出口からの呼び出しの分解
Since Calls are symmetric, they may be torn down from the ingress or egress.
Callsが左右対称であるので、イングレスか出口から彼らを取りこわすかもしれません。
When the Call is "empty" (has no associated LSPs), it may be deleted by the egress sending a Notify message just as described above.
Callが「空である」ときに(どんな関連LSPsも持っていません)、それはちょうど上で説明されるようにNotifyメッセージを送る出口によって削除されるかもしれません。
Note that there is a possibility that both ends of a Call initiate Call deletion at the same time. In this case, the Notify message acting as teardown request MAY be interpreted by its recipient as a teardown response. But since the Notify messages acting as teardown requests carry the R bit in the ADMIN_STATUS object, they MUST be responded to anyway. If a teardown request Notify message is received for an unknown Call ID, it is, nevertheless, responded to in the affirmative.
Callの両端が同時にCall削除を開始する可能性があることに注意してください。 この場合、分解要求として機能するNotifyメッセージは分解応答として受取人によって解釈されるかもしれません。 しかし、分解要求がRを運ぶのでNotifyメッセージ芝居にADMIN_STATUSオブジェクトで噛み付いたので、とにかく彼らに応じなければなりません。 分解要求Notifyメッセージを未知のCall IDに受け取るなら、それにもかかわらず、肯定でそれに応じます。
6.7. Control Plane Survivability
6.7. コントロール飛行機の生存性
Delivery of Notify messages is secured using Message ID Acknowledgements as described in previous sections.
前項で説明されるようにMessage ID Acknowledgementsを使用することでNotifyメッセージの配送を保証します。
Notify messages provide end-to-end communication that does not rely on constant paths through the network. Notify messages are routed according to IGP routing information. No consideration is, therefore, required for network resilience (for example, make- before-break, protection, fast re-route), although end-to-end resilience is of interest for node restart and completely disjoint networks.
通知してください。メッセージはネットワークを通して一定の経路を当てにしないエンド・ツー・エンド通信を提供します。 メッセージに通知してください。IGPルーティング情報によると、発送されます。 したがって、考慮は全くネットワーク弾力に必要でない、(例えば、休みの、前で保護で、速く作る、コースを変更する、)、ネットワークを終わりから終わりへの弾力はノードに関しておもしろいのですが、再開して、完全、ばらばらにならせてください。
Periodic Notify messages SHOULD be sent by the initiator and terminator of the Call to keep the Call alive and to handle ingress or egress node restart. The time period for these retransmissions is a local matter, but it is RECOMMENDED that this period should be twice the shortest refresh period of any LSP associated with the Call. When there are no LSPs associated with a Call, an LSR is RECOMMENDED to use a refresh period of no less than one minute. The Notify messages are identical to those sent as if establishing the Call for the first time, except for the LINK_CAPABILITY object, which may have changed since the Call was first established, due to, e.g., the establishment of Connections, link failures, or the addition of new component links. The current link information is useful for the establishment of subsequent Connections. A node that receives a refresh Notify message carrying the R bit in the ADMIN_STATUS object MUST respond with a Notify response. A node that receives a refresh Notify message (response or request) MAY reset its timer - thus, in normal processing, Notify refreshes involve a single exchange once per time period.
Periodic Notify messages SHOULD be sent by the initiator and terminator of the Call to keep the Call alive and to handle ingress or egress node restart. The time period for these retransmissions is a local matter, but it is RECOMMENDED that this period should be twice the shortest refresh period of any LSP associated with the Call. When there are no LSPs associated with a Call, an LSR is RECOMMENDED to use a refresh period of no less than one minute. The Notify messages are identical to those sent as if establishing the Call for the first time, except for the LINK_CAPABILITY object, which may have changed since the Call was first established, due to, e.g., the establishment of Connections, link failures, or the addition of new component links. The current link information is useful for the establishment of subsequent Connections. A node that receives a refresh Notify message carrying the R bit in the ADMIN_STATUS object MUST respond with a Notify response. A node that receives a refresh Notify message (response or request) MAY reset its timer - thus, in normal processing, Notify refreshes involve a single exchange once per time period.
Papadimitriou & Farrel Standards Track [Page 21] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Papadimitriou & Farrel Standards Track [Page 21] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
A node (sender or receiver) that is unsure of the status of a Call MAY immediately send a Notify message as if establishing the Call for the first time.
A node (sender or receiver) that is unsure of the status of a Call MAY immediately send a Notify message as if establishing the Call for the first time.
Failure to receive a refresh Notify request has no specific meaning. A node that fails to receive a refresh Notify request MAY send its own refresh Notify request to establish the status of the Call. If a node receives no response to a refresh Notify request (including no Message ID Acknowledgement), a node MAY assume that the remote node is unreachable or unavailable. It is a local policy matter whether this causes the local node to teardown associated LSPs and delete the Call.
Failure to receive a refresh Notify request has no specific meaning. A node that fails to receive a refresh Notify request MAY send its own refresh Notify request to establish the status of the Call. If a node receives no response to a refresh Notify request (including no Message ID Acknowledgement), a node MAY assume that the remote node is unreachable or unavailable. It is a local policy matter whether this causes the local node to teardown associated LSPs and delete the Call.
In the event that an edge node restarts without preserved state, it MAY relearn LSP state from adjacent nodes and Call state from remote nodes. If a Path or Resv message is received with a non-zero Call ID but without the C bit in the ADMIN_STATUS, and for a Call ID that is not recognized, the receiver is RECOMMENDED to assume that the Call establishment is delayed and ignore the received message. If the Call setup never materializes, the failure by the restarting node to refresh state will cause the LSPs to be torn down. Optionally, the receiver of such an LSP message for an unknown Call ID may return an error (PathErr or ResvErr message) with the error code "Call Management" and Error Value "Unknown Call ID".
In the event that an edge node restarts without preserved state, it MAY relearn LSP state from adjacent nodes and Call state from remote nodes. If a Path or Resv message is received with a non-zero Call ID but without the C bit in the ADMIN_STATUS, and for a Call ID that is not recognized, the receiver is RECOMMENDED to assume that the Call establishment is delayed and ignore the received message. If the Call setup never materializes, the failure by the restarting node to refresh state will cause the LSPs to be torn down. Optionally, the receiver of such an LSP message for an unknown Call ID may return an error (PathErr or ResvErr message) with the error code "Call Management" and Error Value "Unknown Call ID".
7. Applicability of Call and Connection Procedures
7. Applicability of Call and Connection Procedures
This section considers the applicability of the different Call establishment procedures at the NNI and UNI reference points. This section is informative and is not intended to prescribe or prevent other options.
This section considers the applicability of the different Call establishment procedures at the NNI and UNI reference points. This section is informative and is not intended to prescribe or prevent other options.
7.1. Network-Initiated Calls
7.1. Network-Initiated Calls
Since the link properties and other traffic-engineering attributes are likely known through the IGP, the LINK_CAPABILITY object is not usually required.
Since the link properties and other traffic-engineering attributes are likely known through the IGP, the LINK_CAPABILITY object is not usually required.
In multi-domain networks, it is possible that access link properties and other traffic-engineering attributes are not known since the domains do not share this sort of information. In this case, the Call setup mechanism may include the LINK_CAPABILITY object.
In multi-domain networks, it is possible that access link properties and other traffic-engineering attributes are not known since the domains do not share this sort of information. In this case, the Call setup mechanism may include the LINK_CAPABILITY object.
Papadimitriou & Farrel Standards Track [Page 22] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Papadimitriou & Farrel Standards Track [Page 22] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
7.2. User-Initiated Calls
7.2. User-Initiated Calls
It is possible that the access link properties and other traffic- engineering attributes are not shared across the core network. In this case, the Call setup mechanism may include the LINK_CAPABILITY object.
It is possible that the access link properties and other traffic- engineering attributes are not shared across the core network. In this case, the Call setup mechanism may include the LINK_CAPABILITY object.
Further, the first node within the network may be responsible for managing the Call. In this case, the Notify message that is used to set up the Call is addressed by the user network edge node to the first node of the core network. Moreover, neither the long Call ID nor the short Call ID is supplied (the Session Name Length is set to zero and the Call ID value is set to zero). The Notify message is passed to the first core node, which is responsible for generating the long and short Call IDs before dispatching the message to the remote Call end point (which is known from the SESSION object).
Further, the first node within the network may be responsible for managing the Call. In this case, the Notify message that is used to set up the Call is addressed by the user network edge node to the first node of the core network. Moreover, neither the long Call ID nor the short Call ID is supplied (the Session Name Length is set to zero and the Call ID value is set to zero). The Notify message is passed to the first core node, which is responsible for generating the long and short Call IDs before dispatching the message to the remote Call end point (which is known from the SESSION object).
Further, when used in an overlay context, the first core node is allowed (see [RFC4208]) to replace the Session Name assigned by the ingress node and passed in the Path message. In the case of Call management, the first core node:
Further, when used in an overlay context, the first core node is allowed (see [RFC4208]) to replace the Session Name assigned by the ingress node and passed in the Path message. In the case of Call management, the first core node:
1) MAY insert a long Call ID in the Session Name of a Path
message.
1) MAY insert a long Call ID in the Session Name of a Path message.
2) MUST replace the Session Name with that originally issued by
the user edge node when it returns the Resv message to the
ingress node.
2) MUST replace the Session Name with that originally issued by the user edge node when it returns the Resv message to the ingress node.
7.3. External Call Managers
7.3. External Call Managers
Third party Call management agents may be used to apply policy and authorization at a point that is neither the initiator nor terminator of the Call. The previous example is a particular case of this, but the process and procedures are identical.
Third party Call management agents may be used to apply policy and authorization at a point that is neither the initiator nor terminator of the Call. The previous example is a particular case of this, but the process and procedures are identical.
7.3.1. Call Segments
7.3.1. Call Segments
Call Segments exist between a set of default and configured External Call Managers along a path between the ingress and egress nodes, and use the protocols described in this document.
Call Segments exist between a set of default and configured External Call Managers along a path between the ingress and egress nodes, and use the protocols described in this document.
The techniques that are used by a given service provider to identify which External Call Managers within its network should process a given Call are beyond the scope of this document.
The techniques that are used by a given service provider to identify which External Call Managers within its network should process a given Call are beyond the scope of this document.
An External Call Manager uses normal IP routing to route the Notify message to the next External Call Manager. Notify messages (requests
An External Call Manager uses normal IP routing to route the Notify message to the next External Call Manager. Notify messages (requests
Papadimitriou & Farrel Standards Track [Page 23] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Papadimitriou & Farrel Standards Track [Page 23] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
and responses) are therefore encapsulated in IP packets that identify the sending and receiving External Call Managers, but the addresses used to identify the Call (the Sender Address in the SENDER_TEMPLATE object and the Tunnel Endpoint Address in the SESSION object) continue to identify the endpoints of the Call.
and responses) are therefore encapsulated in IP packets that identify the sending and receiving External Call Managers, but the addresses used to identify the Call (the Sender Address in the SENDER_TEMPLATE object and the Tunnel Endpoint Address in the SESSION object) continue to identify the endpoints of the Call.
8. Non-Support of Call ID
8. Non-Support of Call ID
It is important that the procedures described above operate as seamlessly as possible with legacy nodes that do not support the extensions described.
It is important that the procedures described above operate as seamlessly as possible with legacy nodes that do not support the extensions described.
Clearly, there is no need to consider the case where the Call initiator does not support Call setup initiation.
Clearly, there is no need to consider the case where the Call initiator does not support Call setup initiation.
8.1. Non-Support by External Call Managers
8.1. Non-Support by External Call Managers
It is unlikely that a Call initiator will be configured to send Call establishment Notify requests to an external Call manager, including the first core node, if that node does not support Call setup.
It is unlikely that a Call initiator will be configured to send Call establishment Notify requests to an external Call manager, including the first core node, if that node does not support Call setup.
A node that receives an unexpected Call setup request will fall into one of the following categories.
A node that receives an unexpected Call setup request will fall into one of the following categories.
- Node does not support RSVP. The message will fail to be delivered
or responded to. No Message ID Acknowledgement will be sent. The
initiator will retry and then give up.
- Node does not support RSVP. The message will fail to be delivered or responded to. No Message ID Acknowledgement will be sent. The initiator will retry and then give up.
- Node supports RSVP or RSVP-TE but not GMPLS. The message will be
delivered but not understood. It will be discarded. No Message
ID Acknowledgement will be sent. The initiator will retry and
then give up.
- Node supports RSVP or RSVP-TE but not GMPLS. The message will be delivered but not understood. It will be discarded. No Message ID Acknowledgement will be sent. The initiator will retry and then give up.
- Node supports GMPLS but not Call management. The message will be
delivered, but parsing will fail because of the presence of the
SESSION_ATTRIBUTE object. A Message ID Acknowledgement may be
sent before the parse fails. When the parse fails, the Notify
message may be discarded in which case the initiator will retry
and then give up; alternatively, a parse error may be generated
and returned in a Notify message which will indicate to the
initiator that Call management is not supported.
- Node supports GMPLS but not Call management. The message will be delivered, but parsing will fail because of the presence of the SESSION_ATTRIBUTE object. A Message ID Acknowledgement may be sent before the parse fails. When the parse fails, the Notify message may be discarded in which case the initiator will retry and then give up; alternatively, a parse error may be generated and returned in a Notify message which will indicate to the initiator that Call management is not supported.
8.2. Non-Support by Transit Node
8.2. Non-Support by Transit Node
Transit nodes SHOULD NOT examine Notify messages that are not addressed to them. However, they will see short Call IDs in all messages for all LSPs associated with Calls.
Transit nodes SHOULD NOT examine Notify messages that are not addressed to them. However, they will see short Call IDs in all messages for all LSPs associated with Calls.
Papadimitriou & Farrel Standards Track [Page 24] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Papadimitriou & Farrel Standards Track [Page 24] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Previous specifications state that these fields SHOULD be ignored on receipt and MUST be transmitted as zero. This might be interpreted by some implementations as meaning that the fields should be zeroed before the objects are forwarded. If this happens, LSP setup will not be possible. If either of the fields is zeroed either on the Path or the Resv message, the Resv message will reach the initiator with the field set to zero - this is an indication to the initiator that some node in the network is preventing Call management. Use of Explicit Routes may help to mitigate this issue by avoiding such nodes. Ultimately, however, it may be necessary to upgrade the offending nodes to handle these protocol extensions.
Previous specifications state that these fields SHOULD be ignored on receipt and MUST be transmitted as zero. This might be interpreted by some implementations as meaning that the fields should be zeroed before the objects are forwarded. If this happens, LSP setup will not be possible. If either of the fields is zeroed either on the Path or the Resv message, the Resv message will reach the initiator with the field set to zero - this is an indication to the initiator that some node in the network is preventing Call management. Use of Explicit Routes may help to mitigate this issue by avoiding such nodes. Ultimately, however, it may be necessary to upgrade the offending nodes to handle these protocol extensions.
8.3. Non-Support by Egress Node
8.3. Non-Support by Egress Node
It is unlikely that an attempt will be made to set up a Call to a remote node that does not support Calls.
It is unlikely that an attempt will be made to set up a Call to a remote node that does not support Calls.
If the egress node does not support Call management through the Notify message, it will react (as described in Section 8.1) in the same way as an External Call Manager.
If the egress node does not support Call management through the Notify message, it will react (as described in Section 8.1) in the same way as an External Call Manager.
9. Security Considerations
9. Security Considerations
Please refer to each of the documents referenced in the following sections for a description of the security considerations applicable to the features that they provide.
Please refer to each of the documents referenced in the following sections for a description of the security considerations applicable to the features that they provide.
9.1. Call and Connection Security Considerations
9.1. Call and Connection Security Considerations
Call setup is vulnerable to attacks both of spoofing and denial of service. Since Call setup uses Notify messages, the process can be protected by the use of the INTEGRITY object to secure those messages as described in [RFC2205] and [RFC3473]. Deployments where security is a concern SHOULD use this mechanism.
Call setup is vulnerable to attacks both of spoofing and denial of service. Since Call setup uses Notify messages, the process can be protected by the use of the INTEGRITY object to secure those messages as described in [RFC2205] and [RFC3473]. Deployments where security is a concern SHOULD use this mechanism.
Implementations and deployments MAY additionally protect the Call setup exchange using end-to-end security mechanisms such as those provided by IPsec (see [RFC4302] and [RFC4303]), or using RSVP security [RFC2747].
Implementations and deployments MAY additionally protect the Call setup exchange using end-to-end security mechanisms such as those provided by IPsec (see [RFC4302] and [RFC4303]), or using RSVP security [RFC2747].
Note, additionally, that it would be desirable to use the process of independent Call establishment, where the Call is set up separately from the LSPs, to apply an extra level of authentication and policy for the end-to-end LSPs above that which is available with Call-less, hop-by-hop LSP setup. However doing so will require additional work to set up security associations between the peer and the call manager that meet the requirements of [RFC4107]. The mechanism described in this document is expected to meet this use case when combined with
Note, additionally, that it would be desirable to use the process of independent Call establishment, where the Call is set up separately from the LSPs, to apply an extra level of authentication and policy for the end-to-end LSPs above that which is available with Call-less, hop-by-hop LSP setup. However doing so will require additional work to set up security associations between the peer and the call manager that meet the requirements of [RFC4107]. The mechanism described in this document is expected to meet this use case when combined with
Papadimitriou & Farrel Standards Track [Page 25] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Papadimitriou & Farrel Standards Track [Page 25] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
this additional work. Application of this mechanism to the authentication and policy use case prior to standardization of a security solution is inappropriate and outside the current applicability of the mechanism.
this additional work. Application of this mechanism to the authentication and policy use case prior to standardization of a security solution is inappropriate and outside the current applicability of the mechanism.
The frequency of Call establishment is application dependent and hard to generalize. Key exchange for Call-related message exchanges is therefore something that should be configured or arranged dynamically in different deployments according to the advice in [RFC4107]. Note that the remote RSVP-TE signaling relationship between Call endpoints is no different from the signaling relationship between LSRs that establish an LSP. That is, the LSRs are not necessarily IP-adjacent in the control plane in either case. Thus, key exchange should be regarded as a remote procedure, not a single hop procedure. There are several procedures for automatic remote exchange of keys, and IKEv2 [RFC4306] is particularly suggested in [RFC3473].
The frequency of Call establishment is application dependent and hard to generalize. Key exchange for Call-related message exchanges is therefore something that should be configured or arranged dynamically in different deployments according to the advice in [RFC4107]. Note that the remote RSVP-TE signaling relationship between Call endpoints is no different from the signaling relationship between LSRs that establish an LSP. That is, the LSRs are not necessarily IP-adjacent in the control plane in either case. Thus, key exchange should be regarded as a remote procedure, not a single hop procedure. There are several procedures for automatic remote exchange of keys, and IKEv2 [RFC4306] is particularly suggested in [RFC3473].
10. IANA Considerations
10. IANA Considerations
10.1. RSVP Objects
10.1. RSVP Objects
A new RSVP object is introduced. IANA has made an assignment from the "RSVP Parameters" registry using the sub-registry "Class Names, Class Numbers, and Class Types".
A new RSVP object is introduced. IANA has made an assignment from the "RSVP Parameters" registry using the sub-registry "Class Names, Class Numbers, and Class Types".
o LINK_CAPABILITY object
o LINK_CAPABILITY object
Class-Num = 133 (form 10bbbbbb)
Class-Num = 133 (form 10bbbbbb)
The Class Number is selected so that nodes not recognizing this
object drop it silently. That is, the top bit is set and the next
bit is cleared.
The Class Number is selected so that nodes not recognizing this object drop it silently. That is, the top bit is set and the next bit is cleared.
C-Type = 1 (TE Link Capabilities)
C-Type = 1 (TE Link Capabilities)
The LINK_CAPABILITY object is only defined for inclusion on Notify
messages.
The LINK_CAPABILITY object is only defined for inclusion on Notify messages.
Refer to Section 5.3 of this document.
Refer to Section 5.3 of this document.
IANA maintains a list of subobjects that may be carried in this
object. This list is maintained in the registry entry for the
LINK_CAPABILITY object as is common practice for the subobjects of
other RSVP objects. For each subobject, IANA lists:
IANA maintains a list of subobjects that may be carried in this object. This list is maintained in the registry entry for the LINK_CAPABILITY object as is common practice for the subobjects of other RSVP objects. For each subobject, IANA lists:
- subobject type number
- subobject name
- reference indicating where subobject is defined.
- subobject type number - subobject name - reference indicating where subobject is defined.
Papadimitriou & Farrel Standards Track [Page 26] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Papadimitriou & Farrel Standards Track [Page 26] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
The initial list of subobjects is provided in Section 5.3 of this
document.
The initial list of subobjects is provided in Section 5.3 of this document.
10.2. RSVP Error Codes and Error Values
10.2. RSVP Error Codes and Error Values
A new RSVP Error Code and new Error Values are introduced. IANA has made assignments from the "RSVP Parameters" registry using the sub- registry "Error Codes and Globally-Defined Error Value Sub-Codes".
A new RSVP Error Code and new Error Values are introduced. IANA has made assignments from the "RSVP Parameters" registry using the sub- registry "Error Codes and Globally-Defined Error Value Sub-Codes".
o Error Codes:
- Call Management (value 32)
o Error Codes: - Call Management (value 32)
o Error Values:
- Call Management/Call ID Contention (value 1)
- Call Management/Connections Still Exist (value 2)
- Call Management/Unknown Call ID (value 3)
- Call Management/Duplicate Call (value 4)
o Error Values: - Call Management/Call ID Contention (value 1) - Call Management/Connections Still Exist (value 2) - Call Management/Unknown Call ID (value 3) - Call Management/Duplicate Call (value 4)
10.3. RSVP ADMIN_STATUS Object Bits
10.3. RSVP ADMIN_STATUS Object Bits
[GMPLS-E2E] requested that IANA manage the bits of the RSVP ADMIN_STATUS object. A new "Administrative Status Information Flags" sub-registry of the "GMPLS Signaling Parameters" registry was created.
[GMPLS-E2E] requested that IANA manage the bits of the RSVP ADMIN_STATUS object. A new "Administrative Status Information Flags" sub-registry of the "GMPLS Signaling Parameters" registry was created.
This document defines one new bit, the C bit, to be tracked in that sub-registry. Bit number 28 has been assigned. See Section 5.5 of this document.
This document defines one new bit, the C bit, to be tracked in that sub-registry. Bit number 28 has been assigned. See Section 5.5 of this document.
11. Acknowledgements
11. Acknowledgements
The authors would like to thank George Swallow, Yakov Rekhter, Lou Berger, Jerry Ash, and Kireeti Kompella for their very useful input to, and comments on, an earlier revision of this document.
The authors would like to thank George Swallow, Yakov Rekhter, Lou Berger, Jerry Ash, and Kireeti Kompella for their very useful input to, and comments on, an earlier revision of this document.
Thanks to Lyndon Ong and Ben Mack-Crane for lengthy discussions during and after working group last call, and to Deborah Brungard for a final, detailed review.
Thanks to Lyndon Ong and Ben Mack-Crane for lengthy discussions during and after working group last call, and to Deborah Brungard for a final, detailed review.
Thanks to Suresh Krishnan for the GenArt review, and to Magnus Nystrom for discussions about security.
Thanks to Suresh Krishnan for the GenArt review, and to Magnus Nystrom for discussions about security.
Useful comments were received during IESG review from Brian Carpenter, Lars Eggert, Ted Hardie, Sam Hartman, and Russ Housley.
Useful comments were received during IESG review from Brian Carpenter, Lars Eggert, Ted Hardie, Sam Hartman, and Russ Housley.
Papadimitriou & Farrel Standards Track [Page 27] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Papadimitriou & Farrel Standards Track [Page 27] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
12. References
12. References
12.1. Normative References
12.1. Normative References
[GMPLS-E2E] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007.
[GMPLS-E2E] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[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., Ed., Zhang, L., Berson, S., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205, September
1997.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[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] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
Papadimitriou & Farrel Standards Track [Page 28] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Papadimitriou & Farrel Standards Track [Page 28] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User- Network Interface (UNI): Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D.
Papadimitriou, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Recovery Functional Specification", RFC
4426, March 2006.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006.
12.2. Informative References
12.2. Informative References
[ASON-APPL] Drake, J., Papadimitriou, D., Farrel, A., Brungard, D.,
Ali, Z., Ayyangar, A., Ould-Brahim, H., and D. Fedyk,
"Generalized MPLS (GMPLS) RSVP-TE Signalling in support
of Automatically Switched Optical Network (ASON), Work in
Progress, July 2005.
[ASON-APPL] Drake, J., Papadimitriou, D., Farrel, A., Brungard, D., Ali, Z., Ayyangar, A., Ould-Brahim, H., and D. Fedyk, "Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON), Work in Progress, July 2005.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for
Cryptographic Key Management", BCP 107, RFC 4107, June
2005.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L.
Ong, "Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical
Network (ASON)", RFC 4139, July 2005.
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. Ong, "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 4139, July 2005.
[STITCH] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", Work in Progress, April 2007.
[STITCH] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", Work in Progress, April 2007.
Papadimitriou & Farrel Standards Track [Page 29] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Papadimitriou & Farrel Standards Track [Page 29] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
For information on the availability of the following document, please see http://www.itu.int.
For information on the availability of the following document, please see http://www.itu.int.
[G.8080] ITU-T, "Architecture for the Automatically Switched
Optical Network (ASON)," Recommendation G.8080/ Y.1304,
November 2001 (and Revision, January 2003).
[G.8080] ITU-T, "Architecture for the Automatically Switched Optical Network (ASON)," Recommendation G.8080/ Y.1304, November 2001 (and Revision, January 2003).
Authors' Addresses
Authors' Addresses
John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245 EMail: John.E.Drake2@boeing.com
John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245 EMail: John.E.Drake2@boeing.com
Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com
Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com
Zafar Ali (Cisco) 100 South Main St. #200 Ann Arbor, MI 48104, USA EMail: zali@cisco.com
Zafar Ali (Cisco) 100 South Main St. #200 Ann Arbor, MI 48104, USA EMail: zali@cisco.com
Arthi Ayyangar (Nuova Systems) 2600 San Tomas Expressway Santa Clara, CA 95051 EMail: arthi@nuovasystems.com
Arthi Ayyangar (Nuova Systems) 2600 San Tomas Expressway Santa Clara, CA 95051 EMail: arthi@nuovasystems.com
Don Fedyk (Nortel Networks) 600 Technology Park Drive Billerica, MA, 01821, USA EMail: dwfedyk@nortel.com
Don Fedyk (Nortel Networks) 600 Technology Park Drive Billerica, MA, 01821, USA EMail: dwfedyk@nortel.com
Contact Addresses
Contact Addresses
Dimitri Papadimitriou Alcatel-Lucent, Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel-Lucent, Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel-lucent.be
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
Papadimitriou & Farrel Standards Track [Page 30] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Papadimitriou & Farrel Standards Track [Page 30] RFC 4974 GMPLS RSVP-TE Signaling Extensions August 2007
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Papadimitriou & Farrel Standards Track [Page 31]
Papadimitriou & Farrel Standards Track [Page 31]
一覧
スポンサーリンク
