[要約] RFC 4974は、GMPLS RSVP-TEシグナリング拡張をサポートするためのものであり、要約すると以下のようになります。1. GMPLS RSVP-TEシグナリングの拡張機能を提供する。 2. 通話をサポートするためのGMPLSネットワークの機能を拡張する。 3. GMPLSネットワークでの通話の設定と制御を向上させる。
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
一般化された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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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).
通話は、ユーザートラフィックを送信するための実際の接続性を提供するものではなく、後続の接続を行うことができる関係のみを構築します。一般化されたMPL（GMPL）では、このような接続は、ラベルスイッチ付きパス（LSP）として知られています。
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リソース予約プロトコル - トラフィックエンジニアリング（RSVP -TE）シグナル伝達を使用して拡張して呼び出しをサポートする方法を指定します。これらのメカニズムは、完全かつ論理的な呼び出し/接続分離を提供します。
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).
このドキュメントでは、一般化されたMPL（GMPL）内の呼び出しをサポートするプロトコル手順と拡張機能を定義します。
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]、および[ステッチ]で定義されている接続セットアップ手順を変更しません。コールの一部として設定された接続は、これらのドキュメントで定義されているルールに従います。
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.
呼び出しの要件の例は、ITU-Tの自動化された光ネットワーク（ASON）アーキテクチャ[G.8080]に記載されており、このコンテキストでのコールのサポートのための特定の要件は[RFC4139]にあります。ただし、このドキュメントで説明されているメカニズムは[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.
このドキュメントで定義されているメカニズムは、任意のパケット（PSC）インターフェイス、レイヤー2インターフェイス（L2SC）、TDM対応インターフェイス、LSCインターフェイス、またはFSCインターフェイスに等しく適用できます。メカニズムとプロトコル拡張は逆方向に互換性があり、コールマネージャーのみがプロトコル拡張を認識する必要があるコール管理に使用できます。
[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.2および4.3で説明されている通話の要件と、[RFC4139]のセクション4.4、4.7、5、および6の追加のコール関連要件を満たしています。
[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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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]).
- 複数の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.
明らかに、呼び出しと接続の間には階層的な関係があります。1つ以上の接続が呼び出しに関連付けられている場合があります。接続は複数の呼び出しの一部ではない場合があります。ただし、接続は電話なしで存在する場合があります。
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.
-
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）の間のリンクに関する情報を利用できます。このリンクと呼び、Egress Networkリンクを呼び出します。この情報により、Ingressノードは、それらの機能に適合し、それらの機能に関してネットワークリソースをよりよく利用するように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.
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データベース（TED）には、使用するネットワークリンクがどの出力するかについて決定が行われるのに十分な情報が含まれている場合があります。他の状況では、TEDにはこの情報が含まれておらず、コールセットアップがこの目的のために情報を交換するための適切なメカニズムを提供する場合があります。コールレスポンダーは、呼び出しパラメーターを使用して、Egress CNとリモートENの間の使用可能なEugressネットワークリンクのサブセットを選択し、コールイニシエーターが適切なものを選択できるように、コール応答にこれらのリンクとその機能を報告することができますリンク。
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.
ネットワークが開始する呼び出しは、イングレス（およびそれに応じて出口）がネットワーク内にある場合に発生し、TEおよびGMPLS拡張機能によってIGPに配布された情報の上に追加のリンク機能情報を配布する必要がない場合があります。さらに、これらのIGPSの将来の拡張により、光学障害を含むより詳細な情報の分布が可能になる可能性があります。
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とENSの間の静的リンク（つまり、ルーティングプロトコルによって宣伝されていない）の定義を含む、この問題のさまざまなソリューションが存在します。それにもかかわらず、ネットワークのコンテンツに固有の情報を宣伝することなく、出力ネットワークリンクに関するネットワークの外側のエッジノードに宣伝するために特別な手順が必要になる場合があります。
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への拡張機能がこの機能を提供するために定義される場合があり、ルーティングインスタンス間で情報を漏らすための新しいルールを使用することができます。
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.
- コールレスポンダーは、1つ以上の出力ネットワークリンクに関する情報を返すことができます。コールレスポンダーは、リンク機能に関する情報を含む利用可能なリンクの完全なリストを返すことができます。または、リストをフィルタリングして、コールが必要とする接続をサポートするのに適しているリンクのみに関する情報を返すことができます。この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オブジェクトは、この情報を交換できるように定義されています。このオブジェクトに含まれる情報は、GMPLS対応IGPSによって分布したものと類似しています（[RFC4202]を参照）。
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.
通話は、Notifyメッセージを使用して接続とは独立して確立されます。Notifyメッセージはターゲットメッセージであり、ネットワークを介して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]トランジットの実装は必要ありません。また、後方互換性の問題はありません。既存のデフォルト値を使用して、通話処理が不要であることを示すことにより、フォワード互換性が維持されます。
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.
さらに、何らかの形の相関関係が利用できる限り、送信者と受信機のノードでも、接続（LSP）状態の一部として長いコールIDは必要ありません。この相関は、短いコール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は、通話の確立に使用される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.
コールのイニシエーターにより、コールごとの一意の値が「セッション名」フィールドに挿入されます。後続のコアノードは、このオブジェクトを検査し、このオブジェクトを出力ノードに到達するまでネットワークインターフェイスを透過的に転送する必要があります。このフィールドの構造は、命名規則に応じてさらにフォーマットするオブジェクトである可能性があることに注意してください。ただし、[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.
通話に関連付けられた接続（LSP）は、コールへの参照を伝える必要があります - 短いコールID。新しいフィールドがシグナリングプロトコルに追加され、個々の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.
新しいフィールドは、16ビット識別子（tunnel_end_point_addressとsender_templateオブジェクトのsender_addressによって提供されるアドレスペアリングのコンテキスト内で一意）で、通話初期化中に通知メッセージで交換する必要があり、その後のすべてのLSPメッセージで使用される必要があります。コールに関連付けられています。この識別子は、短いコール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 Exhorionのありそうもないケースでは、ローカルノードポリシーは、特定のアクションを実行することを決定しますが、Second 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は、コールのセットアップ中に使用されたNotifyメッセージとLSPのセットアップと管理中にすべてのメッセージに掲載されたセッションオブジェクトの16ビットフィールドに掲載されます。使用されたフィールドは以前に予約されていました（送信時にゼロに設定し、受領時に無視する必要があります）。これにより、通話を使用しないノードとの後方互換性が保証されます。
The figure below shows the new version of the object.
以下の図は、オブジェクトの新しいバージョンを示しています。
Class = SESSION, Class-Num = 1, C-Type = 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.
セッションオブジェクトで使用される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オブジェクトは、コールセットアップ中にリンク機能交換をサポートするために導入され、コールセットアップに使用される通知メッセージに含まれる場合があります。このオプションのオブジェクトには、ネットワークへのコールイネーティングノード（または呼び出し終了ノード）を結合するリンクのリンクローカル機能が含まれます。特定のノードは、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.
このオブジェクトを認識しないノードが静かにドロップするように、クラス番号が選択されます。つまり、トップビットが設定されており、次のビットは明確です。
This object has the following format:
このオブジェクトには次の形式があります。
Class-Num = 133 (form 10bbbbbb), C_Type = 1
class-num = 133（フォーム10bbbbbbb）、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オブジェクトの内容は、subobjectsと呼ばれる一連の可変長データ項目として定義されます。サブオブジェクト形式は[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：[RFC3209]で定義された形式を使用して、リンクまたは番号付きバンドルのリンクローカルIPv4アドレス。
- Type 2: the link local IPv6 address of a link or a numbered bundle using the format defined in [RFC3209].
- タイプ2：[RFC3209]で定義された形式を使用して、リンクまたは番号付きバンドルのリンクローカルIPv6アドレス。
- 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.
Notifyメッセージは、コールの確立と呼び出しの分裂をサポートするために強化されています。手順の説明については、セクション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.
Notifyメッセージは、link_capabilityオブジェクトのオプションの追加により、コール確立をサポートするために変更されます。さらに、session_attributeオブジェクトが<colotify session>シーケンスに追加され、長いコールIDが掲載されます。session_attributeオブジェクトの存在は、コール管理に使用される通知メッセージを区別するために使用できますが、別のメカニズムについてはセクション5.5を参照してください。<通知セッションリスト>を使用して、複数の呼び出しを同時に設定できます。
The format of the Notify Message is as follows:
Notifyメッセージの形式は次のとおりです。
<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
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.
- 既存の呼び出しに接続が追加される場合があります。これは、関連する接続なしでコールが設定された場合、またはすでに1つ以上の関連する接続があるコールに別の接続が追加された場合に発生する可能性があります。
- 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のセッションオブジェクトで短いコール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.
コールのセットアップでは、コールイングレスノードとコールエグレスノードの間のリンクステータスとリンク機能の交渉の検証が必要になる場合があります。以下で説明する手順は、コールに対して1回のみ適用されるため、コールに関連付けられたLSPのセットに対しては1回のみ適用されます。
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]を参照）を使用して、コールセットアップリクエストと応答を通知します。Admin_Statusオブジェクトの新しいコール管理（c）ビットは、このNotifyが通話を管理していることを示すために使用されます。Notifyメッセージは、Routable Ingress/Egressノードアドレスのいずれかに設定されたソースおよび宛先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.
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に応答するように - notifyメッセージが呼び出しの管理を示していることを示します。
The SESSION, SESSION_ATTRIBUTE, SENDER_TEMPLATE, SENDER_TSPEC objects included in the <notify session> of the Notify message are built as follows.
セッション、session_attribute、sender_template、sender_tspecオブジェクトは、notifyメッセージの<notifyセッション>に含まれています。
- 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.
- セッションオブジェクトには、tunnel_end_point_addressが含まれます。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.
- 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オブジェクトには、送信者アドレスとして、node（ingress）ノードの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.
さらに、それぞれのリンクローカル機能を通信する必要があるイングレス/出力ノードには、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メッセージの受信者は、<Notify Session List>に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オブジェクトは<Notify Session List>に含まれ、要求者の資格情報、アカウント番号、制限、割り当てなどを識別するために使用できることに注意してください。このオブジェクトは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つの例外を除いて、コールリクエストからの情報を反映したNotifyメッセージで応答します。
- The responder removes any LINK_CAPABLITY object that was received and MAY insert a LINK_CAPABILITY object that describes its own access link.
- Responderは、受信された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).
Notifyメッセージを配信できない場合、送信者がメッセージ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を参照）を再送信する場合があります。この時点で、イニシエーターはコールダウンダウンリクエストを送信する必要があります（セクション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（「不明なオブジェクトクラス」）または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.
セキュリティ、承認、またはポリシーの理由により、コールセットアップはレシーバーによって拒否される場合があります。適切なエラーコードはすでに存在しており[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.
エラー応答通知メッセージもメッセージ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.
コールに関連するLSPとそうでないLSPの間に混乱はありません。コールID値は、コールに関連付けられていない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オブジェクト）と宛先アドレス（セッションオブジェクト内）のコンテキスト内で一意であるため、異なる呼び出しの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.
Ingressおよび出力ノードは、同じ呼び出しに関連付けられたLSPをグループ化し、実装要件に応じてグループとしてそれらを処理する場合があります。トランジットノードは、複数のLSPと同じ呼び出しとの関連に注意する必要はありません。
The ingress node MAY choose to set the "Session Name" of an LSP to match the long Call ID of the associated Call.
Ingressノードは、関連する呼び出しの長いコール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.
セッションのアドレスと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をセットアップすることは、呼び出しに関連付けずに可能になり続けています。セッションオブジェクトの短い呼び出しIDがゼロに設定されている場合、関連する呼び出しはなく、セッション_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を使用して同時にセットアップされる2つの異なる呼び出しに対して、短いコールIDが一対のノードによって割り当てられると、競合のさらなる可能性が生じます。この場合、ノードは、以前に同じアドレスペアに送信されたものと一致する短いコール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 contention」でエラー（通知メッセージ）を返します。
- 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.
通話の削除は、コールのセットアップと同様にNotifyメッセージを送信することで達成されますが、Admin_Statusオブジェクトは、断downリクエストにR、D、およびCビットと、Teledown応答に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）を受信しない場合、イニシエーターは、コール設定中に使用されるのと同じ再試行手順を使用して削除要求を再試行する場合があります。完全な再試行後に応答がない場合、コールを削除するノードはコールを削除する可能性がありますが、そのような状況では、ノードはNotify Refresh期間の少なくとも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.
LSPSがまだ存在する呼び出しに対して、admin_statusオブジェクトセットのdビットを使用した通知要求が受信された場合、リクエストはエラーコード「コール管理」とエラー値「接続」を拒否する必要があります。呼び出しの状態を変更してはなりません。
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.
コールの両端が同時にコール削除を開始する可能性があることに注意してください。この場合、分解要求として機能する通知メッセージは、受信者が分解反応として解釈することができます。ただし、Teardownリクエストとして機能する通知メッセージは、Admin_StatusオブジェクトにRビットを伝えているため、とにかく応答する必要があります。不明な呼び出しIDに対してTeardown Requestの通知メッセージが受信された場合、それでも肯定的に応答しました。
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の2倍の最短の更新期間であることをお勧めします。通話に関連するLSPがない場合、LSRは1分以上の更新期間を使用することをお勧めします。Notifyメッセージは、接続の確立、リンク障害、または、コールが最初に確立されてから変更されてから変更されたLink_Capabilityオブジェクトを除いて、初めてコールを確立するかのように送信されたメッセージと同一です。新しいコンポーネントリンクの追加。現在のリンク情報は、後続の接続の確立に役立ちます。admin_StatusオブジェクトにRビットを掲載した更新通知メッセージを受信するノードは、Notify応答で応答する必要があります。更新された通知メッセージ（応答または要求）を受信するノードは、タイマーをリセットする場合があります。したがって、通常の処理では、リフレッシュには期間ごとに1回の交換が含まれます。
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.
通話のステータスが不明なノード（送信者または受信機）は、最初に電話を確立するかのようにすぐにNotifyメッセージを送信する場合があります。
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.
更新notifyリクエストの受信の失敗には、具体的な意味はありません。更新されたNOTIFYリクエストを受信できないノードは、コールのステータスを確立するために独自の更新notifyリクエストを送信する場合があります。ノードが更新通知要求（メッセージ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状態を再学習し、リモートノードから状態を呼び出すことができます。ゼロ以外の呼び出しIDでパスまたはRESVメッセージが受信され、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.
Linkプロパティとその他のトラフィックエンジニアリング属性は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値はゼロに設定されます）。Notifyメッセージは、リモートコールエンドポイント（セッションオブジェクトから既知）にメッセージをディスパッチする前に、長いコールIDと短いコール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:
さらに、オーバーレイのコンテキストで使用すると、最初のコアノードが許可されます（[RFC4208]を参照）。イングレスノードによって割り当てられ、パスメッセージに渡されるセッション名を置き換えます。コール管理の場合、最初のコアノード：
1) MAY insert a long Call ID in the Session Name of a Path message.
1) パスメッセージのセッション名にロングコール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メッセージをIngressノードに返すときに、ユーザーEdgeノードによって最初に発行されたセッション名にセッション名を置き換える必要があります。
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ルーティングを使用して、通知メッセージを次の外部コールマネージャーにルーティングします。したがって、メッセージ（リクエストと応答）の通知は、送信および受信外部コールマネージャーを識別するIPパケットにカプセル化されますが、通話を識別するために使用されるアドレス（Sender_Templateオブジェクトの送信者アドレスとセッションオブジェクトのトンネルエンドポイントアドレス）の継続呼び出しのエンドポイントを識別します。
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.
トランジットノードは、対処されていないメッセージを調べてはなりません。ただし、呼び出しに関連付けられているすべての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.
出力ノードがNotifyメッセージを介してコール管理をサポートしていない場合、外部コールマネージャーと同じ方法で（セクション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]で説明されているように、これらのメッセージを保護するためにプロセスを保護できます。セキュリティが懸念される展開では、このメカニズムを使用する必要があります。
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].
実装と展開は、IPSEC（[RFC4302]および[RFC4303]を参照）、または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)
class-num = 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-type = 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.
このドキュメントでは、そのサブレジストリで追跡される新しいビット、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.
著者は、ジョージ・スワロー、ヤコフ・レクター、ルー・ベルガー、ジェリー・アッシュ、キリエティ・コンペラに、この文書の以前の改訂に非常に有用な入力とコメントについて感謝したいと思います。
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.
ワーキンググループの最後のコール中と後の長い議論をしてくれたLyndon OngとBen Mack-Craneに感謝します。
Thanks to Suresh Krishnan for the GenArt review, and to Magnus Nystrom for discussions about security.
Genart ReviewのSuresh Krishnanに感謝し、セキュリティについての議論をしてくれたMagnus Nystromに感謝します。
Useful comments were received during IESG review from Brian Carpenter, Lars Eggert, Ted Hardie, Sam Hartman, and Russ Housley.
Brian Carpenter、Lars Eggert、Ted Hardie、Sam Hartman、Russ 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] Lang、J.、ed。、Rekhter、Y.、ed。、およびD. Papadimitriou、ed。、「rsvp-te拡張機能エンドツーエンドの一般化マルチプロトコルラベルスイッチング（GMPLS））Recovery "、RFC 4872、2007年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、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] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F。、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（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] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（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] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（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. Berger、「MPLS Traffic Engineering（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.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（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] Swallow、G.、Drake、J.、Ishimatsu、H。、およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）ユーザーネットワークインターフェイス（UNI）：リソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）オーバーレイモデルのサポート」、RFC 4208、2005年10月。
[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。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、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] Lang、J.、Ed。、Rajagopalan、B.、ed。、およびD. Papadimitriou、ed。、「一般化されたマルチプロトコルラベルスイッチング（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] Drake、J.、Papadimitriou、D.、Farrel、A.、Brungard、D.、Ali、Z.、Ayyangar、A.、Oould-Brahim、H。、およびD. Fedyk、「一般化されたMpls」（GMPLS）自動的に切り替えられた光ネットワーク（ASON）をサポートするRSVP-TEシグナル伝達、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.、Drake、J.、Ash、J.、Farrel、A。、およびL. Ong、「一般化されたMPLS（GMPLS）シグナリングの使用の要件と自動切り替え光ネットワーク（ASON）の拡張機能」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. Farrel、「一般化されたマルチプロトコルラベル交通工学（GMPLS TE）を使用したラベルスイッチパスステッチ」、2007年4月、進行中の作業。
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
John Drake Boeing Satellite Systems 2300 East Imperial Highway El Segundo、CA 90245メール：John.E.Drake2@boeing.com
Deborah Brungard (AT&T) Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA EMail: dbrungard@att.com
デボラ・ブランガード（AT＆T）RM。D1-3C22-200 S.ローレルアベニューミドルタウン、ニュージャージー州07748、米国メール：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メール：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メール：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メール：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
Dimitri Papadimitriou Alcatel-Lucent、Fr。Wellesplein 1、B-2018 Antwerpen、ベルギー電話：32 3 240-8491メール：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電話：44（0）1978 860944メール：adrian@olddog.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（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.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。