Network Working Group D. Papadimitriou
Request for Comments: 4974 Alcatel
Updates: 3473 A. Farrel
Category: Standards Track Old Dog Consulting
August 2007
Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions
in Support of Calls
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
特定のネットワークトポロジでは、サービスのインスタンスをサポートするために、エンドポイントと鍵通過点の間の関連付けを維持することが有利であり得ます。このような団体はコールとして知られています。
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).
コールは、ユーザトラフィックを送信するための実際の接続を提供するが、唯一の後続の接続を行うことができるそれによって関係を構築しません。ラベルスイッチパス（LSP）として一般化MPLS（GMPLS）にこのような接続は、知られています。
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.
トラフィックエンジニアリング（RSVP-TE）シグナリングを使用してコールをサポートするように拡張することができる - このドキュメントは、GMPLS、リソース予約プロトコルがどのように指定します。これらのメカニズムは完全かつ論理的なコール/接続の分離を提供します。
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、時分割多重、ラムダ、又は繊維切替。
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
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
This document defines protocol procedures and extensions to support Calls within Generalized MPLS (GMPLS).
この文書では、一般化MPLS（GMPLS）内のコールをサポートするためのプロトコル手順と拡張を定義します。
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".
コールがエンドポイント間、おそらくサービスのインスタンスをサポートする（例えば、ネットワーク境界のような）キー通過点との間の関連付けです。エンドツーエンドの関連付けは、「コール」と呼ばれ、2つの通過点間またはエンドポイントおよび中継ポイントとの間の関連付けは、「コールセグメント」と呼ばれます。通話や通話セグメントを処理するエンティティは、「コールマネージャ」と呼ばれています。
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.
コールは、ユーザトラフィックを送信するための実際の接続を提供するが、唯一の後続の接続を行うことができるそれによって関係を構築しません。 GMPLSでは、そのような接続は、ラベルスイッチパス（LSP）として知られています。この文書では、[RFC3473]で定義された接続のセットアップ手順、[RFC4208]、および[STITCH]を変更しません。コールの一部として設定接続は、これらの文書で定義されたルールに従ってください。
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.
コールは、ゼロ、1つ、または複数の接続に関連付けることができる、との接続は、ゼロまたは1つのコールに関連付けられてもよいです。このように、完全かつ論理的なコール/接続の分離が必要とされています。
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.
コールのための要件の一例は、[RFC4139]に見出すことができるITU-Tの自動交換光ネットワーク（ASON）アーキテクチャ[G.8080]この文脈中の通話をサポートするための特定の要件に見出すことができます。この文書で説明するメカニズムは[RFC4139]に記載されている要件を満たしながら、彼らはより広い適用性を持っていること、しかし、注意してください。
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.
この文書で定義されたメカニズムは、TDM対応インターフェイス、LSCインターフェース、またはFSCインターフェイス任意のパケット（PSC）インターフェイス、レイヤ2インターフェイス（L2SC）に等しく適用可能です。メカニズムとプロトコルの拡張機能は、下位互換性があり、そしてコールマネージャは、プロトコル拡張を認識する必要がある唯一のコールの管理に使用することができます。
[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シグナリングに関する要件を詳述します。 [RFC4139]とセクション4.4で追加コール関連の要件、4.7、5、及び[RFC4139]の6のセクション4.2および4.3に記載されるように本書で説明されたメカニズムは、通話のための要件を満たします。
[ASON-APPL] describes the applicability of GMPLS protocols to the ASON architecture.
[ASON-APPL] ASONアーキテクチャにGMPLSプロトコルの適用を記載します。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
In addition, the reader is assumed to be familiar with the terminology used in [RFC3471], [RFC3473], [RFC3477], and [RFC3945].
また、読者は[RFC3471]で使用される用語、[RFC3473]、[RFC3477]及び[RFC3945]に精通しているものとします。
The Call concept is used to deliver the following capabilities:
コールの概念は、以下の機能を提供するために使用されます。
- Verification and identification of the Call initiator (prior to LSP setup).
- 検証と通話開始の識別（前LSPセットアップに）。
- Support of virtual concatenation with diverse path component LSPs.
- 多様な経路成分のLSPとバーチャルコンカチネーションのサポート。
- Association of multiple LSPs with a single Call (note aspects related to recovery are detailed in [RFC4426] and [GMPLS-E2E]).
- 1回の呼び出しで複数のLSP協会（リカバリに関連する音符の側面は、[RFC4426]と[GMPLS-E2E]に詳述されています）。
- 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.
コールのセットアップ、および接続でコールの関連付けをサポートするための手順およびプロトコルの拡張は、第5節では以降、このドキュメントの記述されています。
Full and logical Call and Connection separation is required. That is:
完全かつ論理的なコールと接続分離が必要です。あれは：
- It MUST be possible to establish a Connection without dependence on a Call.
- コールに依存せず接続を確立することが可能でなければなりません。
- It MUST be possible to establish a Call without any associated Connections.
- 関連する接続せずにコールを確立することが可能でなければなりません。
- It MUST be possible to associate more than one Connection with a 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.
- コールに関連付けられている最後の接続の除去は、コールの入口でローカルポリシーの問題として除き、コールの自動削除になってはなりません。
- Signaling of a Connection associated with a Call MUST NOT require the distribution or retention of Call-related information (state) within the network.
- コールに関連付けられた接続のシグナリングは、ネットワーク内のコール関連情報の配信または保持（状態）を必要としてはなりません。
Call Segment capabilities MUST be supported.
コールセグメント機能をサポートしなければなりません。
Procedures and (GMPLS) RSVP-TE signaling protocol extensions to support Call Segments are described in Section 7.3.1 of this document.
手順呼セグメントをサポートする（GMPLS）RSVP-TEシグナリングプロトコルの拡張は、このドキュメントのセクション7.3.1に記載されています。
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]で議論されています。ここでは、これらの文書の代替として意図したものではなく、重要な用語と概念の概要ですされていません。
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.
コールは、おそらくネットワークへのアクセスを提供するノードと協力して、エンドポイント間の合意です。コールセットアップは、能力交換、ポリシー、認証、およびセキュリティを含むことができます。
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.
呼び出しは、エンドツーエンドのデータサービスを提供する接続のセットを容易にし、管理するために使用されます。接続は、ネットワーク内のデータ・パスに沿ったノードで維持される状態を必要としますが、コールは透明メッセージとしてコール管理要求を転送する以外にトランジットノードの参加を伴いません。
A Call may be established and maintained independently of the Connections that it supports.
コールが確立され、それがサポートする接続の独立して維持することができます。
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.
明らかに、コールと接続間の階層関係があります。一つ以上の接続は、コールに関連付けられてもよいです。接続は、複数のコールの一部ではないかもしれません。接続は、しかし、コールせずに存在してもよいです。
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]では、接続はGMPLS TEトンネルに識別されます。一般に、トンネルが単一のLSPで識別され、保護、ロードバランシング、および他の多くの機能のために、トンネルは、複数の並列のLSPによって支持されてもよいことに留意すべきです。以下の識別は、この階層構造を再現します。
- Call IDs are unique within the context of the pair of addresses that are the source and destination of the Call.
- コールIDは、コールの発信元と宛先あるアドレスのペアの文脈の中でユニークです。
- 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はセッションのコンテキスト（すなわち、トンネルの宛先である）内でユニークです。また、アプリケーションは、それが便利な呼び出しのコンテキスト内で固有のトンネルIDを維持するために見つけることがあります。
- LSP IDs are unique within the context of a Tunnel.
- LSP IDは、トンネルのコンテキスト内で一意です。
Note that the Call_ID value of zero is reserved and MUST NOT be used during LSP-independent Call establishment.
ゼロのCALL_ID値が予約されており、LSP非依存呼設定中に使用してはならないことに注意してください。
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とトンネルは、用語接続と互換的に使用されます。複数のLSPによってサポートされているトンネルの場合は、暗黙的に覆われています。
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 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.
例えば、これは出口のネットワークリンク上のラムダの可用性に関する情報を提供するために透明な光ネットワークに使用されるかもしれない、または、出口CNは信号再生が可能である場合、このようなビットエラーレート等の信号品質属性（交渉するためのメカニズムを提供するかもしれません）。同様に、マルチドメインルーティング環境では、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.
いくつかの状況では、トラフィックエンジニアリングデータベース（TED）は、出口のネットワークリンクを使用するかについて行われる意思決定のための十分な情報が含まれていてもよいです。他の状況では、TEDは、この情報が含まれており、この目的のために情報を交換するための適切な機構を提供することができる設定を呼び出していない可能性があります。コールレスポンダは、出口CNとリモートENとの間で利用可能な出口のネットワークリンクのサブセットを選択するために、コール・パラメータを使用することができ、およびコールの開始剤は、適切なを選択することができるように、コールの応答にこれらのリンクとその機能を報告することがありますリンク。
The sections that follow indicate the cases where the TED may be used, and those where Call parameter exchange may be appropriate.
以下のセクションは、TEDを使用することができる場合、呼パラメータ交換が適切であるかもしれないあるものを示しています。
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.
ネットワーク内の入口（およびそれに対応出口）嘘とオーバーとIGPにTEとGMPLS拡張で配信される情報の上に追加のリンク能力情報を配布する必要はないかもしれないと、ネットワークが開始したコールが発生します。さらに、これらのIGPへの将来の拡張には、光障害を含む、より詳細な情報の配信を許可することも可能です。
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.
イングレス（およびそれに対応出口）がネットワーク外にあるとき、ユーザーが開始コールが発生します。エッジリンク情報は、他のエッジノードでも（具体的に）コアネットワーク内で見えないかもしれません。これが成功した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とのENの間（すなわち、ルーティングプロトコルによってアドバタイズされない、である）静的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.
サポートされる必要がある情報に関する要件がより良く理解される将来において、のEGPへTE拡張は、この機能を提供するために定義されてもよい、およびルーティングインスタンス間のTE情報を漏洩するための新しいルールを使用することができます。
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ソリューションはユーザ対ネットワークインタフェース（UNI）で利用可能でない場合、ローカルエッジノードのリモートエッジリンク機能の知識を持っている必要が依然として存在します。
The Call setup procedure provides an opportunity to discover edge link capabilities of remote edge nodes before LSP setup is attempted.
呼設定手順は、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.
- コール応答者は、一つ以上の出口のネットワークリンク上の情報を返すことができます。コール応答は、リンク機能に関する情報で使用可能なリンクの完全なリストを返すことができ、またはそれはコールで必要な接続をサポートするために適切であるかもしれないもののみリンクに関する情報を返すためにリストをフィルタリングできます。この2番目のオプションを実行するには、通話応答者は、このような適切なコールの宛先を含むコール要求に運ばれた情報からのリンク、およびサービス（帯域幅、保護、など）のレベルを決定しなければならない必要。
- 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.
- コール応答を受信すると、通話開始剤は、それが設定されます接続（のLSP）のパスを決定しなければなりません。それは実装固有の、アルゴリズム的プロセスであるため、それがこれを行う方法はこの文書の範囲外です。しかし、それは、入力としてコール応答で供給されるよう可能な出口のネットワークリンクについての情報を取ることができます。
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オブジェクトは、この情報が交換できるように定義されています。このオブジェクトに含まれている情報は、（[RFC4202]を参照）GMPLS対応のIGPによって分配と同様です。
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.
このセクションでは、コールと接続コールの識別と管理のサポートに必要なプロトコルの拡張機能について説明します。これらのプロトコルの拡張機能を使用するための手順は、第6節で説明されています。
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.
通話は通知メッセージを使用して独立して接続を確立しています。通知メッセージは、ターゲットメッセージであり、ネットワークを介して、LSPのパスに従う必要はありません。
Simultaneous Call and Connection establishment (sometimes referred to as piggybacking) is not supported.
同時通話や接続の確立は（時々、ピギーバックと呼ばれる）はサポートされていません。
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.
すぐに通話の概念が導入されると、コールを特定のいくつかの手段をサポートするために必要です。コールとの接続が分離され、接続がコールにいくつかの参照を含んでいなければならないとき、これは特に重要になります。
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.
コールはかなり（しかし任意ではない）の長さを有することができるバイトのシーケンスによって同定することができます。 40バイトのコールIDは不合理ではないでしょう。これは、エンコーディングや解析コールIDのルールを供給するために、このドキュメントの場所ではありませんが、それは、プロトコル内のコールIDを通信するための適切な手段を提供しなければなりません。完全なコール識別は長いコール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]トランジット実装における変更は不要であるとNO下位互換性の問題は存在しません。上位互換性には、コール処理が必要とされないことを示すために、既存のデフォルト値を使用することによって維持されています。
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.
さらに、長いコールIDがあれば、相関のいくつかのフォームが利用可能であるとしても送信側と受信側ノードでの接続（LSP）状態の一部として必要とされません。この相関は短いコールIDを介して提供されます。
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.
長いコールIDだけコールを確立するために使用される通知メッセージに必要とされます。これは、通知メッセージに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.
コールごとに固有の値は、コールの発信により「セッション名」フィールドに挿入されています。その後のコアノードは、このオブジェクトを検査することができると出口ノードに到達するまでのネットワークインタフェースを横切って透過的にこのオブジェクトを転送する必要があります。このフィールドの構造は、命名規則（単数または複数）に応じてさらにフォーマットのオブジェクトでもよいことに留意されたいです。ただし、[RFC3209]はヌルパディングされた表示文字列として「セッション名」フィールドを定義し、そのコールIDのいずれかの表記規則は、この範囲に限定されなければなりません。
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.
ショートコールID - コールに関連付けられた接続（LSPは）コールへの参照を運ぶために必要。新しいフィールドは、それが属するを呼び出して個々のLSPを識別するためのシグナリングプロトコルに追加されます。
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.
新しいフィールドは、コールの初期化中に通知メッセージで交換しなければならなくて、それ以降のすべてのLSPのメッセージで使用され（Tunnel_End_Point_AddressとSENDER_TEMPLATEオブジェクトのSENDER_ADDRESSによって提供されるアドレスのペアリングのコンテキスト内で一意）16ビットの識別子でありますコールに関連付けられています。この識別子は、ショートコールIDとして知られており、セクション5.2.3に記載したように符号化されます。通話IDは、RSVPシグナリングメッセージが適用されるセッションを決定する処理の一部として使用してはなりません。 [RFC3209]で定義されたセッションオブジェクトの予約フィールドは、受信時に検査されてはならないので、これは任意の下位互換性の問題を発生しません。
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枯渇の可能性は低い場合には、ローカル・ノードのポリシーがとるべき具体的な行動により決定したが、2番目のSENDER_ADDRESSの使用が含まれる場合があります。ローカルポリシーの詳細は、この文書の範囲外です。
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.
ショートコールIDは、LSP設定及び管理の間、呼セットアップ中に使用される通知メッセージに担持されたセッション・オブジェクトに、すべてのメッセージに16ビットのフィールドで運ばれます。使用されるフィールドは、以前に予約された（送信にゼロに設定され、領収書の上で無視しなければなりません）。これは、通話を利用しないノードとの下位互換性を保証します。
The figure below shows the new version of the object.
下の図は、オブジェクトの新しいバージョンを示しています。
Class = SESSION, Class-Num = 1, C-Type = 7(IPv4)/8(IPv6)
クラス= SESSION、クラスのNum = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4/IPv6 Tunnel End Point Address: 32 bits/128 bits (see [RFC3209])
IPv4 / IPv6のトンネルエンドポイントアドレス：32ビット/ 128ビット（[RFC3209]を参照）
Call_ID: 16 bits
CALL_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.
コールの期間にわたって一定のままSESSIONオブジェクトで使用される16ビットの識別子。該当するコールがないときCALL_ID値をゼロに設定しなければなりません。
Tunnel ID: 16 bits (see [RFC3209])
トンネルID：16ビット（[RFC3209]を参照）
Extended Tunnel ID: 32 bits/128 bits (see [RFC3209])
拡張トンネルID：32ビット/ 128ビット（[RFC3209]を参照）
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オブジェクトは、コールセットアップ中にリンク能力交換をサポートするために導入され、コールセットアップに使用通知メッセージに含まれるかもしれません。このオプションの目的は、ネットワークに（または電話、終端ノード）コール開始ノードを結ぶリンクのリンクローカル機能を含みます。特定のノードは、通知メッセージの送信元アドレスで示されています。
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.
このオブジェクトを認識しないノードは静かにそれをドロップするようにクラス番号が選択されています。これは、最上位ビットがセットされ、次のビットがクリアされているされています。
This object has the following format:
このオブジェクトの形式は次のとおりです。
Class-Num = 133 (form 10bbbbbb), C_Type = 1
クラス民= 133（フォーム10bbbbbb）、C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (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]で定義されたフォーマットを使用して、無数のリンクまたはバンドルのリンクローカル識別子。
- Type 64: the Maximum Reservable Bandwidth corresponding to this link or bundle (see [RFC4201]).
- タイプ64：最大予約可能帯域幅が、このリンクまたはバンドルに対応する（[RFC4201]を参照）。
- Type 65: the interface switching capability descriptor (see [RFC4202]) corresponding to this link or bundle (see also [RFC4201]).
- タイプ65：インタフェーススイッチング能力記述（[RFC4202]を参照）、このリンクまたはバンドルに対応する（また、[RFC4201]を参照）。
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:
このオブジェクトの単一のインスタンスは、複数のリンクまたはバンドルされたリンクに関連する能力情報を交換するために使用されるかもしれません。この場合、以下の順序を使用しなければなりません。
- 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.
同じ通知メッセージ内LINK_CAPABILITYオブジェクトの複数のインスタンスは、この仕様によりサポートされていません。通知メッセージは、複数LINK_CAPABILITYオブジェクトが含まれていた場合に、受信機は、通常のように最初のものを処理すると、オブジェクトの後続のインスタンスを無視すべきです。
The Notify message is enhanced to support Call establishment and teardown of Calls. See Section 6 for a description of the procedures.
通知メッセージは、コールのコールの確立とティアダウンをサポートするように拡張されます。手順の説明については、第6章を参照してください。
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.
通知メッセージはLINK_CAPABILITYオブジェクトの任意の添加によって呼確立をサポートするために修正されます。さらに、SESSION_ATTRIBUTEオブジェクトが長いコールIDを運ぶ配列<セッションを通知>に追加されます。 SESSION_ATTRIBUTEオブジェクトの存在は、コールの管理に使用される通知メッセージを区別するために使用されるが、別のメカニズムについては、セクション5.5を参照してくださいかもしれません。 <セッションリストを通知>同時に複数のコールを設定するために使用されるかもしれません。
The format of the Notify Message is as follows:
次のように通知メッセージの形式は次のとおりです。
<Notify message> ::= <Common Header> [ <INTEGRITY> ]
[[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
<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]
<flow descriptor> ::= see [RFC3473]
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.
通知メッセージはADMIN_STATUSオブジェクト内の特定の新しいビット（通話管理または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]はADMIN_STATUSオブジェクトの形式と内容は、[RFC3471]で定義されるようにすることを示しています。以下に示すように、新たな「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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビット - 参照[RFC3471]試験（T）：1ビット - [RFC3471]管理上のダウン（A）を参照してください：1ビット - 進行中の[RFC3471]の削除（D）を参照してください：1ビット - 参照[RFC3471 ]コールマネージメント（C）：1ビット
This bit is set when the message is being used to control and manage a Call.
メッセージがコールを制御および管理するために使用されている場合、このビットがセットされています。
The procedures for the use of the C bit are described in Section 6.
Cビットを使用するための手順は、セクション6に記載されています。
This section describes the processing steps for Call and Connection setup.
このセクションでは、コールと接続設定のための処理手順を説明します。
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.
- コールは、関連するすべての接続なしに設定されています。接続は後でコールに追加されることを想定するが、これは必要条件でも制約でもありませんさ。
- 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.
- 接続は、既存の通話に加えてもよいです。コールは、関連するすべての接続なしに設定された場合、または別の接続がすでに一つ以上の関連するコネクションを持っているコールに追加された場合に発生します。
- A Connection may be established without any reference to a Call (see Section 6.4). This encompasses the previous LSP setup procedure.
- 接続をコールへの参照なしで確立することができる（セクション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.
コールがすでに確立された接続に課されてはならないことに注意してください。そうするためには、既存のLSPのSessionオブジェクトに短いコールIDを変更することが必要となると、これはセッション識別子の変更を構成するであろう。これは、既存のプロトコル仕様によって許可されていません。
Call and Connection teardown procedures are described later in Section 6.6.
電話して接続ティアダウン手順は6.6節で後述されています。
A Call is set up before, and independent of, LSP (i.e., Connection) setup.
コール前に設定、及び、LSP（すなわち、接続）の設定とは無関係です。
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.
コールセットアップは、コール入口ノードとコール出口ノード間のリンクステータスとリンク能力交渉の検証を必要とするかもしれません。以下の手順は、コールに関連するLSPのセットに対して、したがって、一度だけ呼び出しのために一度だけ印加されます。
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.
通知メッセージは、（[RFC3473]を参照）呼設定要求と応答を通知するために使用されます。 ADMIN_STATUSオブジェクトの新しいコールマネージメント（C）ビットは、このコールを管理して通知することを示すために使用されます。通知メッセージは、それぞれのルーティング可能な入口/出口ノードのアドレスのいずれかに設定し、送信元と宛先のIPv4 / IPv6アドレスを用いて送信されます。
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.
少なくとも一つのセッションは通知メッセージの<通知セッションリスト>に列挙されなければなりません。コールの長い同定を可能にするために、SESSION_ATTRIBUTEオブジェクトは<通知セッションリスト>の一部として追加されます。 ERROR_SPECオブジェクトは、コールセットアップ中関係ありませんし、エラーがないことを示すためにエラーコードゼロ（「確認」）を運ばなければなりませんので注意してください。
During Call setup, the ADMIN_STATUS object is sent with the following bits set. Bits not listed MUST be set to zero.
コールセットアップ中、ADMIN_STATUSオブジェクトが設定され、次のビットを用いて送信されます。記載されていないビットはゼロに設定しなければなりません。
R - to cause the egress to respond C - to indicate that the Notify message is managing a Call.
R - 通知メッセージは、通話を管理していることを示すために - Cを応答する出力を発生させます。
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は、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のルーティング可能なアドレスのいずれかを含みます。 CALL_IDはTunnel_End_Point_AddressとSENDER_TEMPLATEオブジェクトからSENDER_ADDRESS（下記参照）によって提供されるアドレスのペアリングのコンテキスト内で固有非ゼロ値に設定されています。この値は、このコールに関連付けられたLSPのためにすべてのメッセージに担持短いコールIDとして使用されます。
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.
ゼロのCALL_ID値が予約され、それがコールに関連付けられていないLSPのセッション・オブジェクト内に存在することになるので、使用してはならないことに注意してください。 SESSIONオブジェクトのTunnel_IDは、この手順に関係なく、ゼロに設定されるべきです。 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オブジェクトは、優先フラグが含まれています。現在、これらのフラグのない使用が想定されていない、しかし、将来の仕事は、通話に優先順位を割り当てることで値を識別することができます。それに応じて優先順位フィールドがゼロ以外の値に設定することができます。 SESSION_ATTRIBUTEオブジェクト内のフラグのいずれもが、このプロセスに関連していないと、このフィールドはゼロに設定する必要があります。セッション名フィールドは、セクション5で説明したように長いコール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オブジェクトは、送信者アドレスとしてコール開始（入力）ノードのIPv4 / IPv6のルーティング可能なアドレスのいずれかを含みます。 LSP_IDは関係ありませんし、ゼロに設定する必要があります。
- The bandwidth value inserted in the SENDER_TSPEC and FLOWSPEC objects MUST be ignored upon receipt and SHOULD be set to zero when sent.
- SENDER_TSPECおよびFLOWSPECオブジェクトに挿入された帯域幅の値は、受信時に無視されなければならないと送信されるときにゼロに設定されるべきです。
Additionally, ingress/egress nodes that need to communicate their respective link local capabilities may include a LINK_CAPABILITY object in the Notify message.
また、それぞれのリンクローカル機能を通信する必要が入口/出口ノードは、通知メッセージ内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.
通知メッセージの受信側は、呼管理の一部又は<通知するセッションリスト>でSESSION_ATTRIBUTEオブジェクトの存在または不在によってエラーを報告しているかどうかを識別することができます。完全な透明性は、しかし、ADMIN_STATUSオブジェクトの新しいコールマネージメント（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.
POLICY_DATAオブジェクトがこのオブジェクトは必要なときに簡単にポリシー制御に渡され、RSVPに対して不透明な等、<セッションのリストを通知>とリクエスタ資格情報、口座番号、制限、クォータを同定することができるに含まれてもよいことに留意されたいです。
Message IDs MUST be used during Call setup.
メッセージIDは、コールのセットアップ時に使用しなければなりません。
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オブジェクトを搬送する通知メッセージを受信したノードは、呼を設定するように要求されています。受信機は、地域の要件に応じて、認可やポリシーを実行してもよいです。
If the Call is acceptable, the receiver responds with a Notify message reflecting the information from the Call request with two exceptions.
コールが受け入れ可能である場合、受信機は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.
- ADMIN_STATUSオブジェクトのみCのビットセットで送信されます。他のすべてのビットはゼロに設定しなければなりません。
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.
応答は、応答の信頼性の高い配信を確保するために、メッセージIDのオブジェクトを使用しなければなりません。ノーメッセージID謝辞が再試行の設定された番号の後に受信された場合、応答者は、コールが正常に確立されたと仮定し続けるべきです。コール活気手順は6.7節で説明されています。
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 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).
通知メッセージを配信することができない場合は、メッセージIDの確認は、送信者が受信しません。送信者がメッセージID確認応答を（[RFC2961]に記載されているように）受けることなく通知メッセージを何度設定可能な数を再送信していた場合には、開始剤は（セクション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).
ID確認応答が受信されたメッセージが、無通話応答メッセージが受信された通知することも可能です。この場合、イニシエータは、コールが失敗したことを宣言する前に、呼設定要求を何回（6.7節を参照）の設定可能数を再送信してもよい（MAY）。この時点で、イニシエータは、コールのティアダウン要求（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.
通知メッセージを解析または誤りであることができない場合に検出されたエラーに適切な場合は、エラーコード13（「未知のオブジェクトクラス」）または14（「未知のオブジェクトのC型」）を担持するNotifyメッセージによって応答されるかもしれません。
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.
コール・セットアップがあるため、セキュリティ、認証、またはポリシー上の理由の受信機によって拒絶されるかもしれません。適切なエラー・コードがすでに[RFC2205]を存在に応答して送信される通知メッセージに含ま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.
エラー応答通知メッセージも信頼性の高い配信を実現するために、メッセージIDのオブジェクトを使用すべきです。アクションは、再試行の設定された番号の後にメッセージIDの確認を受信するために失敗した場合にとられるべきではありません。
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.
コールが確立された後、LSPはコールに追加することができます。ショートコールIDは、セッションオブジェクトの一部であるため、セッションオブジェクトに同一のコールID値を有する任意のLSPは、同じコールに属し、呼を確立するために使用される通知メッセージは、セッションオブジェクトに同一のコール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.
そこコールID値は、コールに関連付けられていないのLSPのためにゼロに等しくなければならないので、コールに関連付けられたLSPとないものとの間には混乱がないでしょう、そして、有効なコールのためにゼロに等しくしているはずがありません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).
通話IDは、（SENDER_TEMPLATEオブジェクト内の）ソースアドレスおよび（SESSIONオブジェクト内）宛先アドレスのコンテキスト内で一意であるため、異なるコールのLSPは区別することができます。
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.
入口および出口は共に同一の呼に関連するLSPをMAY基をノードと実装要件に応じて、それらをグループとして処理します。トランジットノードは、同じ呼び出しで複数のLSPの関連性を意識する必要はありません。
The ingress node MAY choose to set the "Session Name" of an LSP to match the long Call ID of the associated Call.
入口ノードは、関連するコールの長いコールIDと一致するようにLSPの「セッション名」を設定することを選択するかもしれません。
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ビットはLSPに関連し、無視されなければならない通知メッセージに含め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.
コールが確立されると、それが対称であることに注意してください。つまり、どちらかのコールの終わりには、コールにLSPを追加することができます。
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のアドレスが逆になっているので、逆方向にLSPを管理する場合には、特別な注意が必要とされています。ショートコールIDが与えられ、入口、出口アドレス対のコンテキスト内で一意であるので、安全にコールでLSPを関連付けるために使用されてもよいです。
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.
コールは対称的に、ここで定義されているので、潜在的なコールIDの衝突の問題が発生することに注意してください。これは、6.5節で説明されています。
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]).
これは、コールに関連付けることなく、[RFC3473]に従ってLSPを設定することは可能であり続けています。 SESSIONオブジェクト内ショートコールIDがゼロに設定されている場合、セッションの名前として単に解釈されなければならないSESSION_ATTRIBUTEオブジェクトには関連する呼およびセッション名フィールドが存在しない（参照[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ビットのLSPに関連するメッセージを通知に含め、LSP制御のためのメッセージで設定してはいけません、そのようなメッセージで受信されたときに無視しなければなりません。
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.
通話は対称であるので、コールの両端が同時に同じ長いコールIDを持つコールを確立しようとする可能性があります。送信元と宛先アドレスのペアが一致する場合、これが唯一の問題です。この状況は長くコール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:
呼設定要求を送信し、まだ応答自体を受信していないノードが同じ長コールIDとソース/宛先アドレスが一致する呼設定要求を受信した場合、次のように処理しなければなりません。
- 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.
- その送信元アドレスは、リモート送信元アドレスよりも数値的に小さい場合、それは開始され、受信したコールのセットアップに反応しなければなりませんコールセットアップに関連した状態を捨てなければなりません。
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.
ノードが既存のコールと一致するアドレスのペアと長いコールIDを持つ呼設定要求を受信した場合、ノードは新しいエラーコード「通話管理」および新しいエラー値「重複コールして（メッセージを通知）エラーメッセージを返さなければなりません「新しいコール要求に応答して、既存のコールに変更を加えてはなりません。
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:
ショートコールIDが異なる長いコールIDを使用して同時に設定されている2つの別個のコールのためのノードのペアで割り当てられている場合、競合のための更なる可能性が生じます。このイベントでは、ノードは、それが以前に同じアドレスペアのために送られたものと一致する短いコールIDを持つ呼設定要求を受信します。以下の処理に従う必要があります。
- 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".
- 受信者の送信元アドレスは、リモートの送信元アドレスよりも数値的に大きい場合、受信機は、新しいエラーコード「通話管理」および新しいエラー値「コール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.
- 受信者の送信元アドレスは、リモートの送信元アドレスよりも数値的に小さい場合、受信側は受け入れ、通話要求を処理します。これは、前述のように送られたエラーメッセージが表示され、その時点で、それは新しいショートコールIDを選択し、呼設定要求を再送信します。
As with Call/Connection setup, there are several cases to consider.
コール/接続設定と同じように、考慮すべきいくつかのケースがあります。
- Removal of a Connection from a Call - Removal of the last Connection from a Call - Teardown of an "empty" 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]に記載の手順を以下のようにコールに関連付けられていないLSPを切断する場合を検討する必要はありません。
An LSP that is associated with a Call may be deleted using the standard procedures described in [RFC3473]. No special procedures are required.
コールに関連付けられている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.
LSPを削除せずに通話からLSPを削除することはできないことに注意してください。これが許可されていないセッションオブジェクトへの変更を必要とするので、ゼロにゼロ以外からの短いコールIDを変更することが有効ではありません。
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.
コールに関連付けられている最後のLSPが削除されると、質問がコールに何が起こるかのように生じます。コールは、接続の独立して存在する可能性があるので、コールから最後のLSPの除去がコールを削除すると言うことは常に受け入れられません。
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の除去は、呼び出しを削除しないと、次のセクションで説明する手順は、コールを削除するために使用しなければなりません。
When all LSPs have been removed from a Call, the Call may be torn down or left for use by future LSPs.
すべてのLSPをコールから削除された場合は、コールが切断または将来のLSPが使用するために残しておいてもよいです。
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.
コールの削除は、単に呼設定用として通知メッセージを送信することによって達成されるが、ADMIN_STATUSオブジェクトはティアダウン要求とティアダウンの応答D及びCビットについてR、D、およびCビットを運びます。他のビットはゼロに設定しなければなりません。
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.
通知メッセージは、コールを削除するために送られると、イニシエータは、対応を受信しない場合、メッセージ（またはおそらくはメッセージID Ack）を通知反射、イニシエータは、呼確立時に使用されるのと同じ再試行手順を使用して削除要求を再試行することができます。応答が完全な再試行の後に受信されない場合、コールを削除するノードは、コールが削除宣言してもよいが、そのような状況下でノードには、少なくとも5回通知リフレッシュ期間の長いか短いコールIDを再使用しないでください。
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.
ADMIN_STATUSオブジェクトセットのDビットとの通知リクエストはLSPのがまだ存在しているコールのために受信された場合、要求は「接続がまだ存在する」エラーコード「通話管理」とエラー値を拒絶しなければなりません。コールの状態を変更してはいけません。
Since Calls are symmetric, they may be torn down from the ingress or egress.
通話は対称なので、入力または出力から解体することができます。
When the Call is "empty" (has no associated LSPs), it may be deleted by the egress sending a Notify message just as described above.
コール（無関連LSPを有していない）「空」である場合、それは上記のように単に通知メッセージを送信する出口によって削除されてもよいです。
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.
コールの両端が同時に通話削除を開始する可能性があることに注意してください。この場合、ティアダウン要求として作用する通知メッセージがティアダウン応答としてその受信者によって解釈されてもよいです。ティアダウン要求として動作する通知メッセージがADMIN_STATUSオブジェクト内のRビットを運ぶので、しかし、彼らはとにかくに対応しなければなりません。ティアダウン要求メッセージを通知するが、未知のコールIDのために受信された場合、それは、それにもかかわらず、肯定的で応答されます。
Delivery of Notify messages is secured using Message ID Acknowledgements as described in previous sections.
通知メッセージの配信は、前のセクションで説明したように、メッセージID謝辞を使用して固定されます。
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.
定期的な通知メッセージは、生きているコールを維持し、入力または出力ノードの再起動を処理するためにコールのイニシエータとターミネーターで送ってください。これらの再送信のための時間は、ローカルの問題であるが、この期間は二回コールに関連付けられたすべてのLSPの最短リフレッシュ周期することをお勧めします。コールに関連付けられたLSPが存在しない場合は、LSRは1分よりも劣らずのリフレッシュ周期を使用することをお勧めします。通知メッセージが送信されたものと同一であるコールが最初に確立されて以来により、例えば、接続の確立、リンク障害、またはに、変更された可能性LINK_CAPABILITYオブジェクトを除いて初めてコールを確立するかのように新しいコンポーネントリンクの追加。現在のリンク情報は、後続の接続の確立のために有用です。リフレッシュADMIN_STATUSオブジェクト内のRビットを搬送する通知メッセージを受信したノードは、通知応答で応答しなければなりません。リフレッシュメッセージ（応答または要求）通知受信ノードは、そのタイマーをリセットすることができる - このように、通常の処理では、リフレッシュを一旦時間当たりの単一の交換を伴う通知します。
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.
リフレッシュ要求を通知受信に失敗すると、具体的な意味を持ちません。要求を通知リフレッシュを受信に失敗したノードは、コールの状態を確立するための要求を通知し、自身のリフレッシュを送信することができます。ノードが（ないメッセージID確認応答を含まない）リフレッシュ通知要求に対する応答を受信しない場合、ノードは、リモートノードが到達不能又は使用不能であると仮定することができます。これは、関連するLSPをティアダウンし、コールを削除するには、ローカル・ノードを引き起こすかどうかローカルポリシーの問題です。
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".
エッジノードは、保存状態なしで再起動した場合には、隣接ノードからのLSPの状態を再学習かもしれなくて、遠隔ノードからの状態を呼び出します。パスまたはResvメッセージが非ゼロのコールIDが、ADMIN_STATUSのCビットせず、そして認識されないコールID用と受信された場合、受信機は、呼確立が遅れていると仮定し、受信を無視するように推奨されていますメッセージ。コールセットアップが具体化しません場合は、状態をリフレッシュするために再起動ノードが障害がLSPのが取り壊されることになります。必要に応じて、未知のコールIDのためのそのようなLSPメッセージの受信機は、エラーコード「通話管理」とエラー値「不明コールID」とエラー（のPathErr又はResvErrメッセージ）を返すことができます。
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.
このセクションでは、NNIとUNI基準点で異なる呼確立手順の適用可能性を考慮する。このセクションは参考情報であり、他のオプションを処方予防するものではありません。
Since the link properties and other traffic-engineering attributes are likely known through the IGP, the LINK_CAPABILITY object is not usually required.
リンクプロパティおよびその他のトラフィックエンジニアリング属性がありそうIGPを通じて知られているので、LINK_CAPABILITYオブジェクトは、通常は必要ありません。
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.
マルチドメインネットワークでは、ドメインは、この種の情報を共有していないので、アクセスリンクのプロパティおよびその他のトラフィックエンジニアリング属性が知られていない可能性があります。この場合、呼設定メカニズムはLINK_CAPABILITYオブジェクトを含むことができます。
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.
アクセスリンクのプロパティおよびその他のトラフィックエンジニアリング属性はコアネットワーク上で共有されていない可能性があります。この場合、呼設定メカニズムはLINK_CAPABILITYオブジェクトを含むことができます。
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).
さらに、ネットワーク内の最初のノードは、通話を管理するための責任があるかもしれません。この場合には、呼を設定するために使用される通知メッセージは、コアネットワークの最初のノードへのユーザ・ネットワーク・エッジ・ノードによって対処されます。また、長いコールIDも短いコールIDのいずれも供給される（セッション名の長さがゼロに設定され、コールID値はゼロに設定されています）。通知メッセージは、（SESSIONオブジェクトから知られている）リモート通話エンドポイントにメッセージをディスパッチする前に、長い及び短いコールIDを生成する責任がある第一のコア・ノードに渡されます。
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:
オーバーレイの文脈で使用される場合、さらに、第一のコアノードは、Pathメッセージに入口ノードによって割り当てられ、渡されたセッション名を交換する（[RFC4208]を参照）が許可されています。コール管理の場合には、第一のコアノード。
1) MAY insert a long Call ID in the Session Name of a Path message.
1）Pathメッセージのセッション名に長いコールIDを挿入することができます。
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）それが入口ノードにResvメッセージを返す場合、本来ユーザエッジノードによって発行されたものとセッション名を交換しなければなりません。
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.
サードパーティのコール管理エージェントは、コールの発信も終端でもない時点で、ポリシーと許可を適用するために使用することができます。前の例では、この特定の場合であるが、プロセスおよび手順は同一です。
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.
与えられたコールを処理する必要があり、そのネットワーク内のどの外部コール・マネージャーを識別するために、与えられたサービスプロバイダによって使用されている技術は、このドキュメントの範囲を超えています。
An External Call Manager uses normal IP routing to route the Notify message to the next External Call Manager. Notify messages (requests 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.
外部コールマネージャは、次の外部コールマネージャにメッセージを通知ルーティングするために、通常のIPルーティングを使用しています。メッセージ（要求と応答）を通知するため、送信側と受信側の外部コールマネージャが、コール（SENDER_TEMPLATEオブジェクト内の送信者アドレスやSessionオブジェクトにトンネルエンドポイントアドレス）を識別するために使用されるアドレスを識別し、IPパケットにカプセル化され続けますコールのエンドポイントを識別します。
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.
明らかに、通話の開始剤は、コールセットアップの開始をサポートしていない場合を考える必要はありません。
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.
予想外の呼設定要求を受信したノードは、次のいずれかのカテゴリに分類されます。
- 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.
- ノードは、RSVPをサポートしていません。メッセージが配信されるかに対応するために失敗します。いいえ、メッセージID確認は送信されません。イニシエータは、再試行して、あきらめます。
- 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.
- ノードは、RSVPまたはRSVP-TEではなく、GMPLSをサポートしています。メッセージは配信が、理解されていないことだろう。それは破棄されます。いいえ、メッセージID確認は送信されません。イニシエータは、再試行して、あきらめます。
- 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.
- ノードは、GMPLSをサポートしていますが、管理を呼び出しません。メッセージが配信されるが、解析が理由SESSION_ATTRIBUTEオブジェクトの存在失敗します。解析が失敗する前に、メッセージID謝辞を送ることができます。解析が失敗した場合、通知メッセージは、イニシエータが再試行した後あきらめれる場合に廃棄することができます。代替的に、解析エラーが生成され、管理がサポートされていない電話イニシエータに知らせるであろう通知メッセージで返されてもよいです。
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.
トランジットノードは、それらに対処されていないNotifyメッセージを調べるべきではありません。しかし、彼らは、コールに関連付けられているすべてのLSPのすべてのメッセージに短いコールIDが表示されます。
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.
前の仕様は、これらのフィールドは、領収書の上で無視されるべきであり、ゼロとして送らなければならないと述べています。これは、オブジェクトが転送される前にフィールドがゼロにする必要があることを意味するものとしていくつかの実装によって解釈される可能性があります。この問題が発生した場合、LSPの設定はできません。フィールドのいずれかがパスまたはResvメッセージのいずれかがゼロにされる場合、Resvメッセージは、ゼロに設定フィールドとイニシエータに到達する - これは、ネットワーク内のいくつかのノードは、呼管理を妨げていることをイニシエータに示すものです。明示的なルートの使用は、このようなノードを避けることによって、この問題を軽減するのを助けることができます。最終的に、しかし、これらのプロトコル拡張を処理するために、問題のあるノードをアップグレードする必要があるかもしれません。
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.
出口ノードは、通知メッセージを介してコール管理をサポートしていない場合は、外部コールマネージャと同じように（8.1節で説明したように）反応します。
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.
それらが提供する機能に適用されるセキュリティ上の考慮事項の説明については、次のセクションで参照文書のそれぞれを参照してください。
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.
コールセットアップは、なりすましやサービス拒否の両方の攻撃に対して脆弱です。呼設定メッセージを通知用いているので、処理は[RFC2205]及び[RFC3473]に記載されているようにそれらのメッセージを保護するためにINTEGRITYオブジェクトを使用することによって保護することができます。セキュリティが懸念される展開は、このメカニズムを使用すべきです。
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].
実装と展開さらに（[RFC4302]及び[RFC4303]を参照）は、IPSecで提供されるようなエンドツーエンドのセキュリティ・メカニズムを使用して、またはRSVPのセキュリティを使用して呼設定交換を保護することができる[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 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.
その上のエンドツーエンドのLSPの認証およびポリシーの余分なレベルを適用するために、呼がLSPを別に設定されている独立した呼確立のプロセスを使用することが望ましいであろうこと、さらに、注コールレス、ホップバイホップLSP設定で利用可能。しかし、[RFC4107]の要件を満たすピアとコールマネージャ間のセキュリティアソシエーションを設定するには、追加の作業が必要になりますそう。本書で説明されたメカニズムは、この追加の作業と組み合わされた場合、このユースケースを満たすことが期待されます。前セキュリティソリューションの標準化、認証およびポリシーのユースケースにこのメカニズムの適用は不適切と機構の現在の適用外です。
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].
呼確立の頻度はアプリケーションに依存し、一般化することは困難です。コール関連のメッセージ交換のための鍵交換は、[RFC4107]でアドバイスに従って、したがって、異なる展開で構成されるか、または動的に配置する必要があるものです。コールのエンドポイント間のリモートRSVP-TEシグナリング関係はLSPを確立するのLSR間のシグナリング関係と変わらないことに留意されたいです。すなわち、のLSRは、必ずしもいずれの場合も、制御プレーンにおいてIP-隣接していない、です。したがって、鍵交換は、リモート・プロシージャではなく、単一ホップ手順とみなされるべきです。そこキーの自動遠隔交換のためのいくつかの手順があり、のIKEv2 [RFC4306]は特に[RFC3473]で提案されています。
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".
新しいRSVPオブジェクトが導入されます。 IANAは、サブレジストリ「クラス名、クラス番号、およびクラスの型」を使用して「RSVPパラメータ」をレジストリから割り当てを行いました。
o LINK_CAPABILITY object
O LINK_CAPABILITYオブジェクト
Class-Num = 133 (form 10bbbbbb)
クラス民= 133（フォーム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.
ノードは、このオブジェクトは黙ってそれをドロップ認識しないように、クラス番号が選択されています。これは、最上位ビットがセットされ、次のビットがクリアされます。
C-Type = 1 (TE Link Capabilities)
Cタイプ= 1（TEリンク機能）
The LINK_CAPABILITY object is only defined for inclusion on Notify messages.
LINK_CAPABILITYオブジェクトのみを通知するメッセージの包含のために定義されています。
Refer to Section 5.3 of this document.
このドキュメントのセクション5.3を参照してください。
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は、このオブジェクトで実行することができるサブオブジェクトのリストを保持します。その他のRSVPオブジェクトのサブオブジェクトのための一般的な方法があるとしてこのリストはLINK_CAPABILITYオブジェクトのレジストリエントリに維持されています。各サブオブジェクトのために、IANAが一覧表示されます：
- subobject type number - subobject name - reference indicating where subobject is defined.
- サブオブジェクトタイプ番号 - サブオブジェクト名 - 参照サブオブジェクトが定義されている場所を示します。
The initial list of subobjects is provided in Section 5.3 of this document.
サブオブジェクトの初期リストは、このドキュメントのセクション5.3で提供されています。
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".
新しいRSVPエラーコードと新しいエラー値が導入されています。 IANAは、サブレジストリ「エラーコードとグローバル定義のエラー値サブコード」を使用して「RSVPパラメータ」をレジストリから割り当てを行いました。
o Error Codes: - Call Management (value 32)
Oエラーコード： - コールマネージメント（値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： - 管理/コールIDの競合を呼び出します（値は1） - 管理/接続はまだ（値は2）が存在コール - 管理/不明コールIDを呼び出します（値3） - 管理/重複コールを呼び出します（値4）
[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]はIANAは、RSVPのADMIN_STATUSオブジェクトのビットを管理することを要求されました。 「GMPLSシグナリングパラメータ」レジストリの「管理ステータス情報フラグ」新しいサブレジストリが作成されました。
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.
この文書は、そのサブレジストリで追跡される1つの新しいビット、Cビットを、定義します。ビット番号28が割り当てられています。このドキュメントのセクション5.5を参照してください。
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.
作者は、このドキュメントの以前のリビジョンをする彼らの非常に便利な入力のためのジョージくん、ヤコフ・レックター、ルー・バーガー、ジェリー・アッシュ、およびKireeti Kompellaに感謝したい、とのコメントです。
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.
中に最終的な、詳細な検討のための最後の呼び出し、およびデボラBrungardにグループを加工後の長い議論のためのリンドン・オングとベン・マック・クレーンに感謝します。
Thanks to Suresh Krishnan for the GenArt review, and to Magnus Nystrom for discussions about security.
セキュリティについての議論のためのGenArtレビューのためのSureshクリシュナンのおかげで、とマグナスNystromへ。
Useful comments were received during IESG review from Brian Carpenter, Lars Eggert, Ted Hardie, Sam Hartman, and Russ Housley.
有益なコメントはブライアン・カーペンター、ラースEggertの、テッドハーディー、サム・ハートマン、とラスHousleyからIESGレビュー中に受信されました。
[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]ラング、J.、エド。、Rekhter、Y.、エド。、およびD. Papadimitriou、エド。、「RSVP-TE拡張機能は、エンドツーエンド一般化マルチプロトコルラベルのサポートにスイッチング（GMPLS ）リカバリ」、RFC 4872、2007年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K.とY. Rekhter、 "資源予約プロトコルでアンナンバードリンクシグナリング - トラフィックエンジニアリング（RSVP-TE）"、RFC 3477、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ"、RFC 3945、2004年10月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（TE）"、RFC 4201、2005年10月。
[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.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング（GMPLS）のサポートで"、RFC 4202、2005年10月。
[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]ツバメ、G.、ドレイク、J.、石松、H.、およびY. Rekhter、「一般化マルチプロトコルラベルスイッチング（GMPLS）ユーザネットワークインタフェース（UNI）：リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）オーバレイモデルのサポート」、RFC 4208、2005年10月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[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]ラング、J.、エド。、Rajagopalan、B.、エド。、およびD. Papadimitriou、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）回復機能仕様"、RFC 4426、2006年3月。
[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]ドレイク、J.、Papadimitriou、D.、ファレル、A.、Brungard、D.、アリ、Z.、Ayyangar、A.、ウルド-Brahimの、H.、およびD. Fedyk、「一般化MPLS （GMPLS）RSVP-TEシグナリングの自動交換光ネットワーク（ASON）、進歩、2005年7月の作業の支援インチ
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin氏、S.とR. Housley氏、 "暗号鍵管理のためのガイドライン"、BCP 107、RFC 4107、2005年6月。
[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.、ドレイク、J.、灰、J.、ファレル、A.、およびL.オング、 "自動交換光ネットワーク（ASON）のための一般化MPLS（GMPLS）使用をシグナリングおよび拡張のための要件"、 RFC 4139、2005年7月。
[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。、およびA.ファレルは、進捗状況、2007年4月に仕事を "ラベルは、一般マルチプロトコルラベルは、トラフィックエンジニアリング（GMPLS TE）を切り替えるとステッチスイッチパス"。
For information on the availability of the following document, please see http://www.itu.int.
次の文書の入手については、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、 "自動的に交換光ネットワーク（ASON）のためのアーキテクチャ、" 勧告G.8080 / Y.1304、2001年11月（および改訂、2003年1月）。
Authors' Addresses
著者のアドレス
John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo, CA 90245 EMail: John.E.Drake2@boeing.com
ジョン・ドレイクボーイング衛星システム2300東インペリアルハイウェイエルセグンドー、CA 90245 Eメール：John.E.Drake2@boeing.com
Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com
デボラBrungard（AT＆T）Rmを。 D1-3C22 - 200 S.ローレルアベニュー。ミドルタウン、NJ 07748、USA Eメール：dbrungard@att.com
Zafar Ali (Cisco) 100 South Main St. #200 Ann Arbor, MI 48104, USA EMail: zali@cisco.com
Zafarアリ（シスコ）100南メインストリート＃200アナーバー、MI 48104、USA電子メール：zali@cisco.com
Arthi Ayyangar (Nuova Systems) 2600 San Tomas Expressway Santa Clara, CA 95051 EMail: arthi@nuovasystems.com
Arthi Ayyangar（ヌオーヴァシステムズ）2600サントーマス高速道路サンタクララ、CA 95051 Eメール：arthi@nuovasystems.com
Don Fedyk (Nortel Networks) 600 Technology Park Drive Billerica, MA, 01821, USA EMail: dwfedyk@nortel.com
ドン・ルブラン（ノーテルネットワーク）600テクノロジーパークドライブビルリカ、MA、01821、USA Eメール：dwfedyk@nortel.com
Contact Addresses
連絡先アドレス
Dimitri Papadimitriou Alcatel-Lucent, Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouアルカテル・Lykent、神父.. Vellesplein 1 B-2018アントワープ、Velgiomボイス：X2 + 3 240から8491 Eメール：δημήτρη.παπαδημητρίου@αλκατελ-λυκεντ.βε
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティング電話：+44（0）1978 860944 Eメール：adrian@olddog.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。