[要約] RFC 3212は、LDPを使用した制約ベースのLSPセットアップに関する仕様です。このRFCの目的は、LDPを使用して制約を考慮したLSPのセットアップを実現するための手法を提供することです。
Network Working Group B. Jamoussi, Editor, Nortel Networks
Request for Comments: 3212 L. Andersson, Utfors AB
Category: Standards Track R. Callon, Juniper Networks
R. Dantu, Netrake Corporation
L. Wu, Cisco Systems
P. Doolan, OTB Consulting Corp.
T. Worster
N. Feldman, IBM Corp.
A. Fredette, ANF Consulting
M. Girish, Atoga Systems
E. Gray, Sandburst
J. Heinanen, Song Networks, Inc.
T. Kilty, Newbridge Networks, Inc.
A. Malis, Vivace Networks
January 2002
Constraint-Based LSP Setup using LDP
LDPを使用した制約ベースのLSPセットアップ
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 Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol).
このドキュメントは、LDP（ラベル分布プロトコル）を使用してCR-LSP（制約ベースのルーティングラベルスイッチ付きパス）のサポートのために、メカニズムとTLV（タイプ/長さ/値）を指定します。
This specification proposes an end-to-end setup mechanism of a CR-LSP initiated by the ingress LSR (Label Switching Router). We also specify mechanisms to provide means for reservation of resources using LDP.
この仕様は、Ingress LSR（ラベルスイッチングルーター）によって開始されたCR-LSPのエンドツーエンドセットアップメカニズムを提案します。また、LDPを使用してリソースの予約手段を提供するメカニズムを指定します。
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 RFC 2119 [6].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [6]に記載されているように解釈される。
Table of Contents
目次
1. Introduction....................................................3
2. Constraint-based Routing Overview...............................4
2.1 Strict and Loose Explicit Routes...............................5
2.2 Traffic Characteristics........................................5
2.3 Preemption.....................................................5
2.4 Route Pinning..................................................6
2.5 Resource Class.................................................6
3. Solution Overview...............................................6
3.1 Required Messages and TLVs.....................................7
3.2 Label Request Message..........................................7
3.3 Label Mapping Message..........................................9
3.4 Notification Message..........................................10
3.5 Release , Withdraw, and Abort Messages........................11
4. Protocol Specification.........................................11
4.1 Explicit Route TLV (ER-TLV)...................................11
4.2 Explicit Route Hop TLV (ER-Hop TLV)...........................12
4.3 Traffic Parameters TLV........................................13
4.3.1 Semantics...................................................15
4.3.1.1 Frequency.................................................15
4.3.1.2 Peak Rate.................................................16
4.3.1.3 Committed Rate............................................16
4.3.1.4 Excess Burst Size.........................................16
4.3.1.5 Peak Rate Token Bucket....................................16
4.3.1.6 Committed Data Rate Token Bucket..........................17
4.3.1.7 Weight....................................................18
4.3.2 Procedures..................................................18
4.3.2.1 Label Request Message.....................................18
4.3.2.2 Label Mapping Message.....................................18
4.3.2.3 Notification Message......................................19
4.4 Preemption TLV................................................19
4.5 LSPID TLV.....................................................20
4.6 Resource Class (Color) TLV....................................21
4.7 ER-Hop semantics..............................................22
4.7.1. ER-Hop 1: The IPv4 prefix..................................22
4.7.2. ER-Hop 2: The IPv6 address.................................23
4.7.3. ER-Hop 3: The autonomous system number....................24
4.7.4. ER-Hop 4: LSPID............................................24
4.8. Processing of the Explicit Route TLV.........................26
4.8.1. Selection of the next hop..................................26
4.8.2. Adding ER-Hops to the explicit route TLV...................27
4.9 Route Pinning TLV.............................................28
4.10 CR-LSP FEC Element...........................................28
5. IANA Considerations............................................29
5.1 TLV Type Name Space...........................................29
5.2 FEC Type Name Space...........................................30
5.3 Status Code Space.............................................30
6. Security Considerations........................................31
7. Acknowledgments................................................31
8. Intellectual Property Consideration............................31
9. References.....................................................32
Appendix A: CR-LSP Establishment Examples.........................33
A.1 Strict Explicit Route Example.................................33
A.2 Node Groups and Specific Nodes Example........................34
Appendix B. QoS Service Examples..................................36
B.1 Service Examples..............................................36
B.2 Establishing CR-LSP Supporting Real-Time Applications.........38
B.3 Establishing CR-LSP Supporting Delay Insensitive Applications.38
Author's Addresses................................................39
Full Copyright Statement..........................................42
Label Distribution Protocol (LDP) is defined in [1] for distribution of labels inside one MPLS domain. One of the most important services that may be offered using MPLS in general and LDP in particular is support for constraint-based routing of traffic across the routed network. Constraint-based routing offers the opportunity to extend the information used to setup paths beyond what is available for the routing protocol. For instance, an LSP can be setup based on explicit route constraints, QoS constraints, and other constraints. Constraint-based routing (CR) is a mechanism used to meet Traffic Engineering requirements that have been proposed by, [2] and [3]. These requirements may be met by extending LDP for support of constraint-based routed label switched paths (CR-LSPs). Other uses for CR-LSPs include MPLS-based VPNs [4]. More information about the applicability of CR-LDP can be found in [5].
ラベル分布プロトコル（LDP）は、1つのMPLSドメイン内のラベルの分布について[1]で定義されています。一般的にMPLSを使用して提供される可能性のある最も重要なサービスの1つ、特にLDPは、ルーティングネットワーク全体のトラフィックの制約ベースのルーティングのサポートです。制約ベースのルーティングは、ルーティングプロトコルで利用可能なものを超えてパスをセットアップするために使用される情報を拡張する機会を提供します。たとえば、LSPは、明示的なルートの制約、QoS制約、およびその他の制約に基づいてセットアップできます。制約ベースのルーティング（CR）は、[2]および[3]によって提案されているトラフィックエンジニアリングの要件を満たすために使用されるメカニズムです。これらの要件は、制約ベースのルーティングラベルスイッチ付きパス（CR-LSP）のサポートのためにLDPを拡張することで満たすことができます。CR-LSPのその他の用途には、MPLSベースのVPN [4]が含まれます。CR-LDPの適用性に関する詳細については、[5]をご覧ください。
The need for constraint-based routing (CR) in MPLS has been explored elsewhere [2], and [3]. Explicit routing is a subset of the more general constraint-based routing function. At the MPLS WG meeting held during the Washington IETF (December 1997) there was consensus that LDP should support explicit routing of LSPs with provision for indication of associated (forwarding) priority. In the Chicago meeting (August 1998), a decision was made that support for explicit path setup in LDP will be moved to a separate document. This document provides that support and it has been accepted as a working document in the Orlando meeting (December 1998).
MPLSの制約ベースのルーティング（CR）の必要性は、他の場所で調査されています[2]、および[3]。明示的なルーティングは、より一般的な制約ベースのルーティング関数のサブセットです。ワシントンIETF（1997年12月）中に開催されたMPLS WG会議では、LDPが関連する（転送）優先度を示す規定を備えたLSPの明示的なルーティングをサポートする必要があるというコンセンサスがありました。シカゴ会議（1998年8月）では、LDPでの明示的なパスセットアップのサポートが別の文書に移動されるという決定が下されました。この文書は、そのサポートを規定しており、オーランド会議（1998年12月）で実用的な文書として受け入れられています。
This specification proposes an end-to-end setup mechanism of a constraint-based routed LSP (CR-LSP) initiated by the ingress LSR. We also specify mechanisms to provide means for reservation of resources using LDP.
この仕様は、Ingress LSRによって開始された制約ベースのルーティングLSP（CR-LSP）のエンドツーエンドセットアップメカニズムを提案します。また、LDPを使用してリソースの予約手段を提供するメカニズムを指定します。
This document introduce TLVs and procedures that provide support for:
このドキュメントでは、次のサポートを提供するTLVと手順を紹介します。
- Strict and Loose Explicit Routing - Specification of Traffic Parameters - Route Pinning - CR-LSP Preemption though setup/holding priorities - Handling Failures - LSPID - Resource Class
- 厳格でゆるい明示的なルーティング - トラフィックパラメーターの仕様 - ルートピン留め - セットアップ/保持優先順位 - 処理障害-LSPID-リソースクラス
Section 2 introduces the various constraints defined in this specification. Section 3 outlines the CR-LDP solution. Section 4 defines the TLVs and procedures used to setup constraint-based routed label switched paths. Appendix A provides several examples of CR-LSP path setup. Appendix B provides Service Definition Examples.
セクション2では、この仕様で定義されているさまざまな制約を紹介します。セクション3では、CR-LDPソリューションの概要を説明します。セクション4では、制約ベースのルーティングラベルスイッチ付きパスのセットアップに使用されるTLVと手順を定義します。付録Aでは、CR-LSPパスセットアップのいくつかの例を示します。付録Bには、サービスの定義の例が示されています。
Constraint-based routing is a mechanism that supports the Traffic Engineering requirements defined in [3]. Explicit Routing is a subset of the more general constraint-based routing where the constraint is the explicit route (ER). Other constraints are defined to provide a network operator with control over the path taken by an LSP. This section is an overview of the various constraints supported by this specification.
制約ベースのルーティングは、[3]で定義されているトラフィックエンジニアリング要件をサポートするメカニズムです。明示的なルーティングは、制約が明示的なルート（ER）である、より一般的な制約ベースのルーティングのサブセットです。その他の制約は、ネットワークオペレーターにLSPがとるパスを制御できるように定義されています。このセクションは、この仕様でサポートされているさまざまな制約の概要です。
Like any other LSP a CR-LSP is a path through an MPLS network. The difference is that while other paths are setup solely based on information in routing tables or from a management system, the constraint-based route is calculated at one point at the edge of network based on criteria, including but not limited to routing information. The intention is that this functionality shall give desired special characteristics to the LSP in order to better support the traffic sent over the LSP. The reason for setting up CR-LSPs might be that one wants to assign certain bandwidth or other Service Class characteristics to the LSP, or that one wants to make sure that alternative routes use physically separate paths through the network.
他のLSPと同様に、CR-LSPはMPLSネットワークを通るパスです。違いは、他のパスは、ルーティングテーブルまたは管理システムからの情報のみに基づいて設定されていますが、制約ベースのルートは、ルーティング情報を含むがこれらに限定されない基準に基づいてネットワークのエッジのあるポイントで計算されることです。意図は、この機能がLSPに送られたトラフィックをより適切にサポートするために、LSPに望ましい特別な特性を提供することです。CR-LSPをセットアップする理由は、特定の帯域幅またはその他のサービスクラスの特性をLSPに割り当てたい、または代替ルートがネットワークを通じて物理的に個別のパスを使用することを確認したいと考えている可能性があります。
An explicit route is represented in a Label Request Message as a list of nodes or groups of nodes along the constraint-based route. When the CR-LSP is established, all or a subset of the nodes in a group may be traversed by the LSP. Certain operations to be performed along the path can also be encoded in the constraint-based route.
明示的なルートは、制約ベースのルートに沿ったノードまたはノードのグループのリストとして、ラベル要求メッセージに表されます。CR-LSPが確立されると、グループ内のノードのすべてまたはサブセットがLSPによって横断される場合があります。パスに沿って実行される特定の操作は、制約ベースのルートでエンコードすることもできます。
The capability to specify, in addition to specified nodes, groups of nodes, of which a subset will be traversed by the CR-LSP, allows the system a significant amount of local flexibility in fulfilling a request for a constraint-based route. This allows the generator of the constraint-based route to have some degree of imperfect information about the details of the path.
指定されたノードに加えて、ノードのグループを指定する機能は、CR-LSPによってサブセットが通過するノードのグループにより、制約ベースのルートのリクエストを満たす際に、システムがかなりの量の速度を柔軟に導くことができます。これにより、制約ベースのルートのジェネレーターがパスの詳細に関するある程度の不完全な情報を持つことができます。
The constraint-based route is encoded as a series of ER-Hops contained in a constraint-based route TLV. Each ER-Hop may identify a group of nodes in the constraint-based route. A constraint-based route is then a path including all of the identified groups of nodes in the order in which they appear in the TLV.
制約ベースのルートは、制約ベースのルートTLVに含まれる一連のER-HOPSとしてエンコードされます。各ER-HOPは、制約ベースのルートでノードのグループを識別する場合があります。制約ベースのルートは、TLVに表示される順序で、識別されたノードのすべてのグループを含むパスです。
To simplify the discussion, we call each group of nodes an "abstract node". Thus, we can also say that a constraint-based route is a path including all of the abstract nodes, with the specified operations occurring along that path.
ディスカッションを簡素化するために、ノードの各グループを「抽象ノード」と呼びます。したがって、制約ベースのルートは、すべての抽象ノードを含むパスであり、指定された操作がそのパスに沿って発生していると言えます。
The traffic characteristics of a path are described in the Traffic Parameters TLV in terms of a peak rate, committed rate, and service granularity. The peak and committed rates describe the bandwidth constraints of a path while the service granularity can be used to specify a constraint on the delay variation that the CR-LDP MPLS domain may introduce to a path's traffic.
パスのトラフィック特性は、ピークレート、コミットレート、およびサービスの粒度に関して、トラフィックパラメーターTLVで説明されています。ピークとコミットされたレートは、パスの帯域幅の制約を説明しますが、サービスの粒度を使用して、CR-LDP MPLSドメインがパスのトラフィックに導入できる遅延変動の制約を指定できます。
CR-LDP signals the resources required by a path on each hop of the route. If a route with sufficient resources can not be found, existing paths may be rerouted to reallocate resources to the new path. This is the process of path preemption. Setup and holding priorities are used to rank existing paths (holding priority) and the new path (setup priority) to determine if the new path can preempt an existing path.
CR-LDPは、ルートの各ホップのパスで必要なリソースを信号します。十分なリソースを備えたルートが見つからない場合、リソースを新しいパスに再配分するために既存のパスを再ルーティングする場合があります。これがパスプリエンプションのプロセスです。セットアップと保持優先順位は、既存のパス（優先度を保持）と新しいパス（セットアップ優先度）をランク付けして、新しいパスが既存のパスを先取りできるかどうかを判断するために使用されます。
The setupPriority of a new CR-LSP and the holdingPriority attributes of the existing CR-LSP are used to specify priorities. Signaling a higher holding priority express that the path, once it has been established, should have a lower chance of being preempted. Signaling a higher setup priority expresses the expectation that, in the case that resource are unavailable, the path is more likely to preempt other paths. The exact rules determining bumping are an aspect of network policy.
新しいCR-LSPのセットアップリオリティと既存のCR-LSPの保持属性は、優先順位を指定するために使用されます。より高い保持優先度を示すことは、パスが確立されると、先制される可能性が低くなるはずであることを表明します。より高いセットアップの優先順位を示すことは、リソースが利用できない場合、パスが他のパスを先取りする可能性が高いという期待を表しています。バンピングを決定する正確なルールは、ネットワークポリシーの側面です。
The allocation of setup and holding priority values to paths is an aspect of network policy.
セットアップの割り当てとパスへの優先値を保持することは、ネットワークポリシーの側面です。
The setup and holding priority values range from zero (0) to seven (7). The value zero (0) is the priority assigned to the most important path. It is referred to as the highest priority. Seven (7) is the priority for the least important path. The use of default priority values is an aspect of network policy. The recommended default value is (4).
セットアップと保持優先度の値は、ゼロ（0）から7（7）の範囲です。値ゼロ（0）は、最も重要なパスに割り当てられた優先度です。これは最優先事項と呼ばれます。7つは、最も重要ではないパスの優先事項です。デフォルトの優先度値の使用は、ネットワークポリシーの側面です。推奨されるデフォルト値は（4）です。
The setupPriority of a CR-LSP should not be higher (numerically less) than its holdingPriority since it might bump an LSP and be bumped by the next "equivalent" request.
CR-LSPのセットアップリアリティは、LSPにぶつかり、次の「同等の」リクエストにぶつかる可能性があるため、その保持よりも高く（数値的に少ない）すべきではありません。
Route pinning is applicable to segments of an LSP that are loosely routed - i.e. those segments which are specified with a next hop with the "L" bit set or where the next hop is an abstract node. A CR-LSP may be setup using route pinning if it is undesirable to change the path used by an LSP even when a better next hop becomes available at some LSR along the loosely routed portion of the LSP.
ルートピン留めは、ゆるくルーティングされたLSPのセグメントに適用できます。つまり、「L」ビットセットを備えた次のホップで指定されているセグメント、または次のホップが抽象ノードである場所です。 LSPのゆるいルーティング部分に沿ってLSRでより良い次のホップが利用可能になった場合でも、LSPが使用するパスを変更することが望ましくない場合、ルートピン留めを使用してCR-LSPをセットアップできます。
The network operator may classify network resources in various ways. These classes are also known as "colors" or "administrative groups". When a CR-LSP is being established, it's necessary to indicate which resource classes the CR-LSP can draw from.
ネットワークオペレーターは、さまざまな方法でネットワークリソースを分類できます。これらのクラスは、「色」または「管理グループ」としても知られています。CR-LSPが確立されている場合、CR-LSPがどのリソースクラスから引き出すことができるかを示す必要があります。
CR-LSP over LDP Specification is designed with the following goals:
LDP仕様のCR-LSPは、次の目標で設計されています。
1. Meet the requirements outlined in [3] for performing traffic engineering and provide a solid foundation for performing more general constraint-based routing.
1. トラフィックエンジニアリングを実行するための[3]に概説されている要件を満たし、より一般的な制約ベースのルーティングを実行するための強固な基盤を提供します。
2. Build on already specified functionality that meets the requirements whenever possible. Hence, this specification is based on [1].
2. 可能な限り要件を満たす既に指定された機能に基づいて構築します。したがって、この仕様は[1]に基づいています。
3. Keep the solution simple.
3. ソリューションをシンプルに保ちます。
In this document, support for unidirectional point-to-point CR-LSPs is specified. Support for point-to-multipoint, multipoint-to-point, is for further study (FFS).
このドキュメントでは、単方向のポイントツーポイントCR-LSPのサポートが指定されています。ポイントツーマルチポイント、マルチポイントツーポイントのサポートは、さらなる研究（FFS）です。
Support for constraint-based routed LSPs in this specification depends on the following minimal LDP behaviors as specified in [1]:
この仕様における制約ベースのルーティングLSPのサポートは、[1]で指定されている次の最小LDP動作に依存します。
- Use of Basic and/or Extended Discovery Mechanisms. - Use of the Label Request Message defined in [1] in downstream on demand label advertisement mode with ordered control. - Use of the Label Mapping Message defined in [1] in downstream on demand mode with ordered control. - Use of the Notification Message defined in [1]. - Use of the Withdraw and Release Messages defined in [1]. - Use of the Loop Detection (in the case of loosely routed segments of a CR-LSP) mechanisms defined in [1].
- 基本および/または拡張された発見メカニズムの使用。 - 順序付けられたコントロールを備えたダウンストリームオンデマンドラベル広告モードで[1]で定義されたラベル要求メッセージの使用。 - 順序付けられたコントロールを備えたダウンストリームオンデマンドモードで[1]で定義されたラベルマッピングメッセージの使用。 - [1]で定義されている通知メッセージの使用。 - [1]で定義されている撤回およびリリースメッセージの使用。 - [1]で定義されているメカニズムのメカニズムの使用（1]で定義されているループ検出（CR-LSPの緩やかにルーティングされたセグメントの場合）の使用。
In addition, the following functionality is added to what's defined in [1]:
さらに、[1]で定義されているものに次の機能が追加されます。
- The Label Request Message used to setup a CR-LSP includes one or more CR-TLVs defined in Section 4. For instance, the Label Request Message may include the ER-TLV.
- CR-LSPのセットアップに使用されるラベル要求メッセージには、セクション4で定義された1つ以上のCR-TLVが含まれます。たとえば、ラベルリクエストメッセージにはER-TLVが含まれる場合があります。
- An LSR implicitly infers ordered control from the existence of one or more CR-TLVs in the Label Request Message. This means that the LSR can still be configured for independent control for LSPs established as a result of dynamic routing. However, when a Label Request Message includes one or more of the CR-TLVs, then ordered control is used to setup the CR-LSP. Note that this is also true for the loosely routed parts of a CR-LSP.
- LSRは、ラベルリクエストメッセージに1つ以上のCR-TLVの存在から制御を暗黙的に指定しました。これは、動的ルーティングの結果として確立されたLSPの独立制御用にLSRを構成できることを意味します。ただし、ラベルリクエストメッセージに1つ以上のCR-TLVが含まれている場合、CR-LSPをセットアップするために順序付けられたコントロールが使用されます。これは、cr-lspの緩くルーティングされた部分にも当てはまることに注意してください。
- New status codes are defined to handle error notification for failure of established paths specified in the CR-TLVs. All of the new status codes require that the F bit be set.
- 新しいステータスコードは、CR-TLVで指定された確立されたパスの障害のエラー通知を処理するために定義されます。すべての新しいステータスコードでは、fビットを設定する必要があります。
Optional TLVs MUST be implemented to be compliant with the protocol. However, they are optionally carried in the CR-LDP messages to signal certain characteristics of the CR-LSP being established or modified.
オプションのTLVは、プロトコルに準拠するために実装する必要があります。ただし、それらはオプションでCR-LDPメッセージに携帯されており、確立または変更されているCR-LSPの特定の特性を通知します。
Examples of CR-LSP establishment are given in Appendix A to illustrate how the mechanisms described in this document work.
CR-LSP確立の例を付録Aに示して、このドキュメントの作品で説明されているメカニズムを示しています。
Any Messages, TLVs, and procedures not defined explicitly in this document are defined in the LDP Specification [1]. The reader can use [7] as an informational document about the state transitions, which relate to CR-LDP messages.
このドキュメントで明示的に定義されていないメッセージ、TLV、および手順は、LDP仕様[1]で定義されています。読者は、[7]をCR-LDPメッセージに関連する状態遷移に関する情報文書として使用できます。
The following subsections are meant as a cross-reference to the [1] document and indication of additional functionality beyond what's defined in [1] where necessary.
以下のサブセクションは、[1]ドキュメントの相互参照と、必要に応じて[1]で定義されているものを超えて追加の機能を示すことを意味します。
Note that use of the Status TLV is not limited to Notification messages as specified in Section 3.4.6 of [1]. A message other than a Notification message may carry a Status TLV as an Optional Parameter. When a message other than a Notification carries a Status TLV the U-bit of the Status TLV should be set to 1 to indicate that the receiver should silently discard the TLV if unprepared to handle it.
ステータスTLVの使用は、[1]のセクション3.4.6で指定されている通知メッセージに限定されないことに注意してください。通知メッセージ以外のメッセージは、オプションのパラメーターとしてステータスTLVを運ぶ場合があります。通知以外のメッセージがステータスTLVを運ぶ場合、ステータスTLVのUビットを1に設定して、受信者が処理する準備ができていない場合はTLVを静かに廃棄する必要があることを示す必要があります。
The Label Request Message is as defined in 3.5.8 of [1] with the following modifications (required only if any of the CR-TLVs is included in the Label Request Message):
ラベル要求メッセージは、[1]の3.5.8で定義されているとおりです。次の変更（CR-TLVのいずれかがラベルリクエストメッセージに含まれている場合にのみ必要です）：
- The Label Request Message MUST include a single FEC-TLV element. The CR-LSP FEC TLV element SHOULD be used. However, the other FEC- TLVs defined in [1] MAY be used instead for certain applications.
- ラベル要求メッセージには、単一のFEC-TLV要素を含める必要があります。CR-LSP FEC TLV要素を使用する必要があります。ただし、[1]で定義されている他の分野は、代わりに特定のアプリケーションで使用できます。
- The Optional Parameters TLV includes the definition of any of the Constraint-based TLVs specified in Section 4.
- オプションのパラメーターTLVには、セクション4で指定された制約ベースのTLVの定義が含まれます。
- The Procedures to handle the Label Request Message are augmented by the procedures for processing of the CR-TLVs as defined in Section 4.
- ラベル要求メッセージを処理する手順は、セクション4で定義されているCR-TLVの処理手順によって補強されます。
The encoding for the CR-LDP Label Request Message is as follows:
CR-LDPラベル要求メッセージのエンコードは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSPID TLV (CR-LDP, mandatory) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pinning TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resource Class TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label Mapping Message is as defined in 3.5.7 of [1] with the following modifications:
ラベルマッピングメッセージは、[1]の3.5.7で定義されているとおりです。
- The Label Mapping Message MUST include a single Label-TLV.
- ラベルマッピングメッセージには、単一のラベルTLVを含める必要があります。
- The Label Mapping Message Procedures are limited to downstream on demand ordered control mode.
- ラベルマッピングメッセージの手順は、ダウンストリームオンデマンド順序制御モードに限定されています。
A Mapping message is transmitted by a downstream LSR to an upstream LSR under one of the following conditions:
マッピングメッセージは、次の条件のいずれかで下流のLSRによって上流のLSRに送信されます。
1. The LSR is the egress end of the CR-LSP and an upstream mapping has been requested.
1. LSRはCR-LSPの出口端であり、上流マッピングが要求されています。
2. The LSR received a mapping from its downstream next hop LSR for an CR-LSP for which an upstream request is still pending.
2. LSRは、上流のリクエストがまだ保留中であるCR-LSPの下流の次のホップLSRからマッピングを受け取りました。
The encoding for the CR-LDP Label Mapping Message is as follows:
CR-LDPラベルマッピングメッセージのエンコードは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSPID TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic TLV (CR-LDP, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Notification Message is as defined in Section 3.5.1 of [1] and the Status TLV encoding is as defined in Section 3.4.6 of [1]. Establishment of an CR-LSP may fail for a variety of reasons. All such failures are considered advisory conditions and they are signaled by the Notification Message.
通知メッセージは[1]のセクション3.5.1で定義されており、ステータスTLVエンコーディングは[1]のセクション3.4.6で定義されています。CR-LSPの確立は、さまざまな理由で失敗する可能性があります。そのような障害はすべてアドバイザリ条件と見なされ、通知メッセージによってシグナルがあります。
Notification Messages carry Status TLVs to specify events being signaled. New status codes are defined in Section 4.11 to signal error notifications associated with the establishment of a CR-LSP and the processing of the CR-TLV. All of the new status codes require that the F bit be set.
通知メッセージにはステータスTLVがあり、シグナルが行われているイベントを指定します。新しいステータスコードは、CR-LSPの確立とCR-TLVの処理に関連する信号エラー通知のセクション4.11で定義されています。すべての新しいステータスコードでは、fビットを設定する必要があります。
The Notification Message MAY carry the LSPID TLV of the corresponding CR-LSP.
通知メッセージには、対応するCR-LSPのLSPID TLVが搭載されている場合があります。
Notification Messages MUST be forwarded toward the LSR originating the Label Request at each hop and at any time that procedures in this specification - or in [1] - specify sending of a Notification Message in response to a Label Request Message.
通知メッセージは、各ホップでラベルリクエストを発信するLSRに向けて転送する必要があります。この仕様の手順 - または[1] - ラベルリクエストメッセージに応じて通知メッセージの送信を指定する必要があります。
The encoding of the notification message is as follows:
通知メッセージのエンコードは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label Release , Label Withdraw, and Label Abort Request Messages are used as specified in [1]. These messages MAY also carry the LSPID TLV.
ラベルのリリース、ラベルの撤回、およびラベル中止要求メッセージは、[1]で指定されているように使用されます。これらのメッセージは、LSPID TLVを搭載する場合があります。
The Label Request Message defined in [1] MUST carry the LSPID TLV and MAY carry one or more of the optional Constraint-based Routing TLVs (CR-TLVs) defined in this section. If needed, other constraints can be supported later through the definition of new TLVs. In this specification, the following TLVs are defined:
[1]で定義されているラベル要求メッセージは、LSPID TLVを運ぶ必要があり、このセクションで定義されているオプションの制約ベースのルーティングTLV（CR-TLV）の1つ以上を運ぶことができます。必要に応じて、新しいTLVの定義により、その他の制約を後でサポートできます。この仕様では、次のTLVが定義されています。
- Explicit Route TLV - Explicit Route Hop TLV - Traffic Parameters TLV - Preemption TLV - LSPID TLV - Route Pinning TLV - Resource Class TLV - CR-LSP FEC TLV
- 明示的なルートTLV-明示的なルートホップTLV-トラフィックパラメーターTLV -Preemption TLV -LSPID TLV -ROUTE PINING TLV -RESORANCE CLASS TLV -CR -LSP FEC TLV
The ER-TLV is an object that specifies the path to be taken by the LSP being established. It is composed of one or more Explicit Route Hop TLVs (ER-Hop TLVs) defined in Section 4.2.
ER-TLVは、確立されているLSPがとるパスを指定するオブジェクトです。セクション4.2で定義されている1つ以上の明示的なルートホップTLV（ER-HOP TLV）で構成されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0800 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ............ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ER-Hop TLV n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ER-TLV Type = 0x0800.
ER-TLV Type = 0x0800の値を運ぶ14ビットフィールドを入力します。
Length Specifies the length of the value field in bytes.
長さは、バイトフィールドの値フィールドの長さを指定します。
ER-Hop TLVs One or more ER-Hop TLVs defined in Section 4.2.
ER-HOP TLVSセクション4.2で定義された1つ以上のER-HOP TLV。
The contents of an ER-TLV are a series of variable length ER-Hop TLVs.
ER-TLVの内容は、一連の可変長いER-HOP TLVです。
A node receiving a label request message including an ER-Hop type that is not supported MUST not progress the label request message to the downstream LSR and MUST send back a "No Route" Notification Message.
サポートされていないER-HOPタイプを含むラベル要求メッセージを受信するノードは、ラベルリクエストメッセージをダウンストリームLSRに進めてはいけません。
Each ER-Hop TLV has the form:
各ER-HOP TLVには次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Content // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ER-Hop Type
A fourteen-bit field carrying the type of the ER-Hop contents.
Currently defined values are:
Value Type
------ ------------------------
0x0801 IPv4 prefix
0x0802 IPv6 prefix
0x0803 Autonomous system number
0x0804 LSPID
Length Specifies the length of the value field in bytes.
長さは、バイトフィールドの値フィールドの長さを指定します。
L bit The L bit in the ER-Hop is a one-bit attribute. If the L bit is set, then the value of the attribute is "loose." Otherwise, the value of the attribute is "strict." For brevity, we say that if the value of the ER-Hop attribute is loose then it is a "loose ER-Hop." Otherwise, it's a "strict ER-Hop." Further, we say that the abstract node of a strict or loose ER-Hop is a strict or a loose node, respectively. Loose and strict nodes are always interpreted relative to their prior abstract nodes. The path between a strict node and its prior node MUST include only network nodes from the strict node and its prior abstract node.
lビットER-HOPのLビットは1ビット属性です。Lビットが設定されている場合、属性の値は「緩んでいます」。それ以外の場合、属性の値は「厳格」です。簡潔にするために、ER-HOP属性の値が緩んでいる場合、それは「ゆるいERホップ」であると言います。そうでなければ、それは「厳格なer-hop」です。さらに、厳格またはゆるいERホップの抽象ノードは、それぞれ厳格または緩いノードであると言います。ゆるくて厳格なノードは、常に以前の抽象ノードに対して解釈されます。Strictノードとその前のノードの間のパスには、Strictノードとその以前の抽象ノードからのネットワークノードのみを含める必要があります。
The path between a loose node and its prior node MAY include other network nodes, which are not part of the strict node or its prior abstract node.
ルーズノードとその前ノードの間のパスには、厳密なノードまたはその前の抽象ノードの一部ではない他のネットワークノードが含まれる場合があります。
Contents A variable length field containing a node or abstract node which is one of the consecutive nodes that make up the explicitly routed LSP.
コンテンツ明示的にルーティングされたLSPを構成する連続したノードの1つであるノードまたは抽象ノードを含む可変長フィールド。
The following sections describe the CR-LSP Traffic Parameters. The required characteristics of a CR-LSP are expressed by the Traffic Parameter values.
次のセクションでは、CR-LSPトラフィックパラメーターについて説明します。CR-LSPの必要な特性は、トラフィックパラメーター値によって表されます。
A Traffic Parameters TLV, is used to signal the Traffic Parameter values. The Traffic Parameters are defined in the subsequent sections.
トラフィックパラメーターTLVを使用して、トラフィックパラメーター値を信号します。トラフィックパラメーターは、後続のセクションで定義されています。
The Traffic Parameters TLV contains a Flags field, a Frequency, a Weight, and the five Traffic Parameters PDR, PBS, CDR, CBS, EBS.
トラフィックパラメーターTLVには、フラグフィールド、周波数、重量、および5つのトラフィックパラメーターPDR、PBS、CDR、CBS、EBSが含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0810 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Frequency | Reserved | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate (PDR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Burst Size (PBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Data Rate (CDR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Committed Burst Size (CBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Burst Size (EBS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the Traffic Parameters TLV Type = 0x0810.
トラフィックパラメーターの値TLVタイプ= 0x0810を運ぶタイプA 14ビットフィールド。
Length Specifies the length of the value field in bytes = 24.
長さは、バイトフィールドの長さをバイト= 24で指定します。
Flags The Flags field is shown below:
フラグフラグフィールドを以下に示します。
+--+--+--+--+--+--+--+--+
| Res |F6|F5|F4|F3|F2|F1|
+--+--+--+--+--+--+--+--+
Res - These bits are reserved. Zero on transmission. Ignored on receipt. F1 - Corresponds to the PDR. F2 - Corresponds to the PBS. F3 - Corresponds to the CDR. F4 - Corresponds to the CBS. F5 - Corresponds to the EBS. F6 - Corresponds to the Weight.
res-これらのビットは予約されています。トランスミッションでゼロ。領収書は無視されます。F1- PDRに対応します。F2- PBSに対応します。F3- CDRに対応します。F4- CBSに対応します。F5- EBSに対応します。F6-重量に対応します。
Each flag Fi is a Negotiable Flag corresponding to a Traffic Parameter. The Negotiable Flag value zero denotes NotNegotiable and value one denotes Negotiable.
各フラグFIは、トラフィックパラメーターに対応する交渉可能なフラグです。交渉可能なフラグ値ゼロは、negotibleではなく、交渉可能な値を意味します。
Frequency The Frequency field is coded as an 8 bit unsigned integer with the following code points defined:
周波数フィールドは、次のコードポイントが定義された8ビットの符号なし整数としてコード化されます。
0- Unspecified 1- Frequent 2- VeryFrequent 3-255 - Reserved Reserved - Zero on transmission. Ignored on receipt.
0-不特定の1-頻繁な2-非常に頻繁な3-255-予約された予約済み - トランスミッションでゼロ。領収書は無視されます。
Weight An 8 bit unsigned integer indicating the weight of the CR-LSP. Valid weight values are from 1 to 255. The value 0 means that weight is not applicable for the CR-LSP.
重量は、cr-lspの重量を示す8ビットの符号なし整数です。有効な重量値は1から255です。値0は、重量がCR-LSPに適用できないことを意味します。
Traffic Parameters Each Traffic Parameter is encoded as a 32-bit IEEE single-precision floating-point number. A value of positive infinity is represented as an IEEE single-precision floating-point number with an exponent of all ones (255) and a sign and mantissa of all zeros. The values PDR and CDR are in units of bytes per second. The values PBS, CBS and EBS are in units of bytes.
トラフィックパラメータ各トラフィックパラメーターは、32ビットIEEEシングルプレシジョンフローティングポイント数としてエンコードされます。ポジティブインフィニティの値は、すべての指数（255）とすべてのゼロのサインとマンティッサを備えたIEEEシングルエシジョンフローティングポイント数として表されます。値PDRとCDRは、1秒あたりのバイト単位です。値PBS、CBS、およびEBはバイト単位にあります。
The value of PDR MUST be greater than or equal to the value of CDR in a correctly encoded Traffic Parameters TLV.
PDRの値は、正しくエンコードされたトラフィックパラメーターTLVでCDRの値以上でなければなりません。
The Frequency specifies at what granularity the CDR allocated to the CR-LSP is made available. The value VeryFrequent means that the available rate should average at least the CDR when measured over any time interval equal to or longer than the shortest packet time at the CDR. The value Frequent means that the available rate should average at least the CDR when measured over any time interval equal to or longer than a small number of shortest packet times at the CDR.
周波数は、CR-LSPに割り当てられたCDRが利用可能になった粒度で指定されています。値は非常に頻繁に、利用可能なレートが、CDRでの最短パケット時間以下の時間間隔で測定された場合、少なくともCDRの平均を平均する必要があることを意味します。頻繁な値は、利用可能なレートが、CDRでの少数の最短パケット時間以下の間隔で任意の時間間隔で測定された場合、少なくともCDRの平均を平均する必要があることを意味します。
The value Unspecified means that the CDR MAY be provided at any granularity.
不特定の値は、CDRがあらゆる粒度で提供される可能性があることを意味します。
The Peak Rate defines the maximum rate at which traffic SHOULD be sent to the CR-LSP. The Peak Rate is useful for the purpose of resource allocation. If resource allocation within the MPLS domain depends on the Peak Rate value then it should be enforced at the ingress to the MPLS domain.
ピークレートは、トラフィックをCR-LSPに送信する最大レートを定義します。ピークレートは、リソースの割り当てを目的として役立ちます。MPLSドメイン内のリソース割り当てがピークレート値に依存する場合、MPLSドメインへのイングレスで実施する必要があります。
The Peak Rate is defined in terms of the two Traffic Parameters PDR and PBS, see section 4.3.1.5 below.
ピークレートは、2つのトラフィックパラメーターPDRとPBSの観点から定義されています。以下のセクション4.3.1.5を参照してください。
The Committed Rate defines the rate that the MPLS domain commits to be available to the CR-LSP.
コミットされたレートは、MPLSドメインがCR-LSPが利用できるようにするレートを定義します。
The Committed Rate is defined in terms of the two Traffic Parameters CDR and CBS, see section 4.3.1.6 below.
コミットされたレートは、2つのトラフィックパラメーターCDRとCBSの観点から定義されています。以下のセクション4.3.1.6を参照してください。
The Excess Burst Size may be used at the edge of an MPLS domain for the purpose of traffic conditioning. The EBS MAY be used to measure the extent by which the traffic sent on a CR-LSP exceeds the committed rate.
過剰なバーストサイズは、トラフィックコンディショニングを目的として、MPLSドメインの端で使用できます。EBSは、CR-LSPに送信されるトラフィックがコミットレートを超える範囲を測定するために使用できます。
The possible traffic conditioning actions, such as passing, marking or dropping, are specific to the MPLS domain.
通過、マーキング、ドロップなどのトラフィックコンディショニングアクションの可能性は、MPLSドメインに固有です。
The Excess Burst Size is defined together with the Committed Rate, see section 4.3.1.6 below.
過剰バーストサイズは、コミットされたレートとともに定義されます。以下のセクション4.3.1.6を参照してください。
The Peak Rate of a CR-LSP is specified in terms of a token bucket P with token rate PDR and maximum token bucket size PBS.
CR-LSPのピークレートは、トークンレートPDRと最大トークンバケットサイズPBを備えたトークンバケットPの観点から指定されています。
The token bucket P is initially (at time 0) full, i.e., the token count Tp(0) = PBS. Thereafter, the token count Tp, if less than PBS, is incremented by one PDR times per second. When a packet of size B bytes arrives at time t, the following happens:
トークンバケットPは、最初は（時間0）、つまりトークンカウントTP（0）= PBSです。その後、PBS未満の場合、トークンカウントTPは、1秒あたり1回のPDR回数が増加します。サイズBバイトのパケットが時間tに到着すると、次のことが起こります。
- If Tp(t)-B >= 0, the packet is not in excess of the peak rate and Tp is decremented by B down to the minimum value of 0, else
- TP（T）-B> = 0の場合、パケットはピークレートを超えていないため、TPはBによって最小値0まで減少します。
- the packet is in excess of the peak rate and Tp is not decremented.
- パケットはピークレートを超えており、TPは減少していません。
Note that according to the above definition, a positive infinite value of either PDR or PBS implies that arriving packets are never in excess of the peak rate.
上記の定義によれば、PDRまたはPBSのいずれかの正の無限値は、到着パケットがピークレートを超えないことを意味することに注意してください。
The actual implementation of an LSR doesn't need to be modeled according to the above formal token bucket specification.
LSRの実際の実装は、上記の正式なトークンバケットの仕様に従ってモデル化する必要はありません。
The committed rate of a CR-LSP is specified in terms of a token bucket C with rate CDR. The extent by which the offered rate exceeds the committed rate MAY be measured in terms of another token bucket E, which also operates at rate CDR. The maximum size of the token bucket C is CBS and the maximum size of the token bucket E is EBS.
CR-LSPのコミットされたレートは、レートCDRのトークンバケットCの観点から指定されています。提供されたレートがコミットレートを超える範囲は、レートCDRでも動作する別のトークンバケットEの観点から測定できます。トークンバケットCの最大サイズはCBSで、トークンバケットEの最大サイズはEBSです。
The token buckets C and E are initially (at time 0) full, i.e., the token count Tc(0) = CBS and the token count Te(0) = EBS.
トークンバケットCとEは、最初は（時間0で）完全です。つまり、トークンカウントTC（0）= CBSおよびトークンカウントTE（0）= EBSです。
Thereafter, the token counts Tc and Te are updated CDR times per second as follows:
その後、トークンカウントTCとTEは、次のように1秒あたりのCDR時間を更新されます。
- If Tc is less than CBS, Tc is incremented by one, else - if Te is less then EBS, Te is incremented by one, else neither Tc nor Te is incremented.
- TCがCBSよりも少ない場合、TCは1つずつ増加します。TEがEBよりも少ない場合、TEが1つずつ増加し、TCもTEも増加しません。
When a packet of size B bytes arrives at time t, the following happens:
サイズBバイトのパケットが時間tに到着すると、次のことが起こります。
- If Tc(t)-B >= 0, the packet is not in excess of the Committed Rate and Tc is decremented by B down to the minimum value of 0, else
- TC（T）-B> = 0の場合、パケットはコミットレートを超えていないため、TCはBによって最小値0まで減少します。
- if Te(t)-B >= 0, the packet is in excess of the Committed rate but is not in excess of the EBS and Te is decremented by B down to the minimum value of 0, else
- te（t）-b> = 0の場合、パケットはコミットレートを超えていますが、EBSを超えていない場合、TEはBによって最小値0まで減少します。
- the packet is in excess of both the Committed Rate and the EBS and neither Tc nor Te is decremented.
- パケットはコミットレートとEBSの両方を超えており、TCもTEも減少していません。
Note that according to the above specification, a CDR value of positive infinity implies that arriving packets are never in excess of either the Committed Rate or EBS. A positive infinite value of either CBS or EBS implies that the respective limit cannot be exceeded.
上記の仕様によれば、ポジティブインフィニティのCDR値は、到着パケットがコミットレートまたはEBSを超えることは決してないことを意味します。CBSまたはEBSのいずれかの正の無限値は、それぞれの制限を超えることができないことを意味します。
The actual implementation of an LSR doesn't need to be modeled according to the above formal specification.
LSRの実際の実装は、上記の正式な仕様に従ってモデル化する必要はありません。
The weight determines the CR-LSP's relative share of the possible excess bandwidth above its committed rate. The definition of "relative share" is MPLS domain specific.
重量は、CR-LSPの可能性のある過剰帯域幅の相対的なシェアをそのコミットレートを超えて決定します。「相対シェア」の定義はMPLSドメイン固有です。
If an LSR receives an incorrectly encoded Traffic Parameters TLV in which the value of PDR is less than the value of CDR then it MUST send a Notification Message including the Status code "Traffic Parameters Unavailable" to the upstream LSR from which it received the erroneous message.
LSRがPDRの値がCDRの値よりも少ない誤ってエンコードされたトラフィックパラメーターTLVを受信した場合、誤ったメッセージを受信したアップストリームLSRに「トラフィックパラメーター」を含むステータスコード「トラフィックパラメーター」を含む通知メッセージを送信する必要があります。。
If a Traffic Parameter is indicated as Negotiable in the Label Request Message by the corresponding Negotiable Flag then an LSR MAY replace the Traffic Parameter value with a smaller value.
対応する交渉可能なフラグによるラベル要求メッセージで交渉可能であるとトラフィックパラメーターが示されている場合、LSRはトラフィックパラメーター値をより小さな値に置き換えることができます。
If the Weight is indicated as Negotiable in the Label Request Message by the corresponding Negotiable Flag then an LSR may replace the Weight value with a lower value (down to 0).
対応する交渉可能なフラグによるラベルリクエストメッセージで、ネゴシエルが認められていると示されている場合、LSRは重量値をより低い値（0まで）に置き換えることができます。
If, after possible Traffic Parameter negotiation, an LSR can support the CR-LSP Traffic Parameters then the LSR MUST reserve the corresponding resources for the CR-LSP.
可能なトラフィックパラメーター交渉の後、LSRがCR-LSPトラフィックパラメーターをサポートできる場合、LSRはCR-LSPの対応するリソースを予約する必要があります。
If, after possible Traffic Parameter negotiation, an LSR cannot support the CR-LSP Traffic Parameters then the LSR MUST send a Notification Message that contains the "Resource Unavailable" status code.
可能なトラフィックパラメーターの交渉の後、LSRがCR-LSPトラフィックパラメーターをサポートできない場合、LSRは「リソースが利用できない」ステータスコードを含む通知メッセージを送信する必要があります。
If an LSR receives an incorrectly encoded Traffic Parameters TLV in which the value of PDR is less than the value of CDR then it MUST send a Label Release message containing the Status code "Traffic Parameters Unavailable" to the LSR from which it received the erroneous message. In addition, the LSP should send a Notification Message upstream with the status code 'Label Request Aborted'.
LSRがPDRの値がCDRの値よりも少ない誤ってエンコードされたトラフィックパラメーターTLVを受信した場合、誤ったメッセージを受信したLSRにステータスコード「トラフィックパラメーター」を含むラベルリリースメッセージを送信する必要があります。。さらに、LSPは、ステータスコード「ラベルリクエストが中止された」とともに上流の通知メッセージを送信する必要があります。
If the negotiation flag was set in the label request message, the egress LSR MUST include the (possibly negotiated) Traffic Parameters and Weight in the Label Mapping message.
ネゴシエーションフラグがラベルリクエストメッセージに設定されている場合、出力LSRには、ラベルマッピングメッセージに（おそらく交渉された）トラフィックパラメーターと重量を含める必要があります。
The Traffic Parameters and the Weight in a Label Mapping message MUST be forwarded unchanged.
ラベルマッピングメッセージのトラフィックパラメーターと重量は、変更されずに転送する必要があります。
An LSR SHOULD adjust the resources that it reserved for a CR-LSP when it receives a Label Mapping Message if the Traffic Parameters differ from those in the corresponding Label Request Message.
LSRは、トラフィックパラメーターが対応するラベルリクエストメッセージのパラメーターと異なる場合、ラベルマッピングメッセージを受信するときにCR-LSPに予約したリソースを調整する必要があります。
If an LSR receives a Notification Message for a CR-LSP, it SHOULD release any resources that it possibly had reserved for the CR-LSP. In addition, on receiving a Notification Message from a Downstream LSR that is associated with a Label Request from an upstream LSR, the local LSR MUST propagate the Notification message using the procedures in [1]. Further the F bit MUST be set.
LSRがCR-LSPの通知メッセージを受信した場合、CR-LSPのために予約されていた可能性のあるリソースをリリースする必要があります。さらに、上流LSRからのラベル要求に関連付けられている下流LSRから通知メッセージを受信すると、ローカルLSRは[1]の手順を使用して通知メッセージを伝播する必要があります。さらに、Fビットを設定する必要があります。
The default value of the setup and holding priorities should be in the middle of the range (e.g., 4) so that this feature can be turned on gradually in an operational network by increasing or decreasing the priority starting at the middle of the range.
セットアップと保有優先順位のデフォルト値は、範囲の中央からの優先度を増やすか減少させることにより、この機能を運用ネットワークで徐々にオンにすることができるように、範囲の中央（例：4）にある必要があります。
Since the Preemption TLV is an optional TLV, LSPs that are setup without an explicitly signaled preemption TLV SHOULD be treated as LSPs with the default setup and holding priorities (e.g., 4).
プリエンプションTLVはオプションのTLVであるため、明示的にシグナルを使用せずにセットアップされるLSPは、デフォルトのセットアップおよび保持優先順位を持つLSPとして扱う必要があります（例：4）。
When an established LSP is preempted, the LSR that initiates the preemption sends a Withdraw Message upstream and a Release Message downstream.
確立されたLSPが先制されると、先制を開始するLSRは、上流の撤退メッセージと下流のリリースメッセージを送信します。
When an LSP in the process of being established (outstanding Label Request without getting a Label Mapping back) is preempted, the LSR that initiates the preemption, sends a Notification Message upstream and an Abort Message downstream.
確立されるプロセスのLSP（ラベルマッピングを取り戻すことなく未解決のラベル要求）が先制されると、先制を開始するLSRが上流に通知メッセージを送信し、下流メッセージを送信します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0820 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SetPrio | HoldPrio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the Preemption-TLV Type = 0x0820.
タイプA Preemption-TLV Type = 0x0820の値を運ぶ14ビットフィールド。
Length Specifies the length of the value field in bytes = 4.
長さは、バイトフィールドの長さをバイト= 4で指定します。
Reserved Zero on transmission. Ignored on receipt.
送信時に予約ゼロ。領収書は無視されます。
SetPrio A SetupPriority of value zero (0) is the priority assigned to the most important path. It is referred to as the highest priority. Seven (7) is the priority for the least important path. The higher the setup priority, the more paths CR-LDP can bump to set up the path. The default value should be 4.
SetPrio値ゼロ（0）のセットアップリオリティは、最も重要なパスに割り当てられた優先度です。これは最優先事項と呼ばれます。7つは、最も重要ではないパスの優先事項です。セットアップの優先度が高いほど、CR-LDPがぶつかってパスをセットアップできるパスが増えます。デフォルト値は4である必要があります。
HoldPrio A HoldingPriority of value zero (0) is the priority assigned to the most important path. It is referred to as the highest priority. Seven (7) is the priority for the least important path. The default value should be 4. The higher the holding priority, the less likely it is for CR-LDP to reallocate its bandwidth to a new path.
holdprio値ゼロ（0）の保持力は、最も重要なパスに割り当てられた優先度です。これは最優先事項と呼ばれます。7つは、最も重要ではないパスの優先事項です。デフォルト値は4でなければなりません。保持優先度が高いほど、CR-LDPが帯域幅を新しいパスに再配分する可能性が低くなります。
LSPID is a unique identifier of a CR-LSP within an MPLS network.
LSPIDは、MPLSネットワーク内のCR-LSPの一意の識別子です。
The LSPID is composed of the ingress LSR Router ID (or any of its own Ipv4 addresses) and a Locally unique CR-LSP ID to that LSR.
LSPIDは、Ingress LSRルーターID（または独自のIPv4アドレスのいずれか）と、そのLSRのローカルに一意のCR-LSP IDで構成されています。
The LSPID is useful in network management, in CR-LSP repair, and in using an already established CR-LSP as a hop in an ER-TLV.
LSPIDは、ネットワーク管理、CR-LSP修復、およびすでに確立されたCR-LSPをER-TLVのホップとして使用するのに役立ちます。
An "action indicator flag" is carried in the LSPID TLV. This "action indicator flag" indicates explicitly the action that should be taken if the LSP already exists on the LSR receiving the message.
「アクションインジケーターフラグ」は、LSPID TLVで運ばれます。この「アクションインジケーターフラグ」は、メッセージを受信するLSRにLSPが既に存在する場合に実行されるべきアクションを明示的に示しています。
After a CR-LSP is set up, its bandwidth reservation may need to be changed by the network operator, due to the new requirements for the traffic carried on that CR-LSP. The "action indicator flag" is used indicate the need to modify the bandwidth and possibly other parameters of an established CR-LSP without service interruption. This feature has application in dynamic network resources management where traffic of different priorities and service classes is involved.
CR-LSPがセットアップされた後、そのCR-LSPに掲載されたトラフィックの新しい要件により、ネットワークオペレーターが帯域幅の予約を変更する必要がある場合があります。「アクションインジケーターフラグ」が使用されることは、サービス中断なしで確立されたCR-LSPの帯域幅と、場合によっては他のパラメーターを変更する必要性を示しています。この機能には、さまざまな優先順位とサービスクラスのトラフィックが関係する動的ネットワークリソース管理にアプリケーションがあります。
The procedure for the code point "modify" is defined in [8]. The procedures for other flags are FFS.
コードポイント「変更」の手順は[8]で定義されています。他のフラグの手順はFFSです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0821 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ActFlg | Local CR-LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress LSR Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the LSPID-TLV Type = 0x0821.
LSPID-TLVタイプ= 0x0821の値を運ぶタイプA 14ビットフィールド。
Length Specifies the length of the value field in bytes = 4.
長さは、バイトフィールドの長さをバイト= 4で指定します。
ActFlg Action Indicator Flag: A 4-bit field that indicates explicitly the action that should be taken if the LSP already exists on the LSR receiving the message. A set of indicator code points is proposed as follows:
ACTFLGアクションインジケーターフラグ：LSPがLSRに既に存在している場合にメッセージを受信する場合に実行する必要があるアクションを明示的に示す4ビットフィールド。インジケーターコードポイントのセットは、次のように提案されています。
0000: indicates initial LSP setup 0001: indicates modify LSP
0000：初期LSPセットアップ0001を示します：LSPの変更を示します
Reserved Zero on transmission. Ignored on receipt.
送信時に予約ゼロ。領収書は無視されます。
Local CR-LSP ID The Local LSP ID is an identifier of the CR-LSP locally unique within the Ingress LSR originating the CR-LSP.
ローカルCR-LSP IDローカルLSP IDは、CR-LSPを発信する侵入LSR内で局所的にユニークなCR-LSPの識別子です。
Ingress LSR Router ID An LSR may use any of its own IPv4 addresses in this field.
Ingress LSRルーターID LSRは、このフィールドで独自のIPv4アドレスを使用する場合があります。
The Resource Class as defined in [3] is used to specify which links are acceptable by this CR-LSP. This information allows for the network's topology to be pruned.
[3]で定義されているリソースクラスは、このCR-LSPで許容できるリンクを指定するために使用されます。この情報により、ネットワークのトポロジを剪定できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0822 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RsCls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ResCls-TLV Type = 0x0822.
rescls-tlvタイプ= 0x0822の値を運ぶタイプA 14ビットフィールド。
Length Specifies the length of the value field in bytes = 4.
長さは、バイトフィールドの長さをバイト= 4で指定します。
RsCls The Resource Class bit mask indicating which of the 32 "administrative groups" or "colors" of links the CR-LSP can traverse.
RSCLSリソースクラスビットマスクは、CR-LSPがトラバースできるリンクの32の「管理グループ」または「色」のどれを示すものを示します。
The abstract node represented by this ER-Hop is the set of nodes, which have an IP address, which lies within this prefix. Note that a prefix length of 32 indicates a single IPv4 node.
このER-HOPで表される要約ノードは、このプレフィックス内にあるIPアドレスを持つノードのセットです。32のプレフィックス長は、単一のIPv4ノードを示していることに注意してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0801 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ER-Hop 1, IPv4 Address, Type = 0x0801
ER-HOP 1、IPv4アドレス、タイプ= 0x0801の値を運ぶタイプA 14ビットフィールド
Length Specifies the length of the value field in bytes = 8.
長さは、バイト= 8の値フィールドの長さを指定します。
L Bit Set to indicate Loose hop. Cleared to indicate a strict hop.
lルーズホップを示すように設定されています。厳格なホップを示すためにクリアされました。
Reserved Zero on transmission. Ignored on receipt.
送信時に予約ゼロ。領収書は無視されます。
PreLen Prefix Length 1-32
プレレンプレフィックス長1-32
IP Address A four-byte field indicating the IP Address.
IPアドレスIPアドレスを示す4バイトフィールド。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 0x0802 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ER-Hop 2, IPv6 Address, Type = 0x0802
ER-HOP 2、IPv6アドレスの値を運ぶタイプA 14ビットフィールド、タイプ= 0x0802
Length Specifies the length of the value field in bytes = 20.
長さは、バイトフィールドの長さをバイト= 20で指定します。
L Bit Set to indicate Loose hop. Cleared to indicate a strict hop.
lルーズホップを示すように設定されています。厳格なホップを示すためにクリアされました。
Reserved Zero on transmission. Ignored on receipt.
送信時に予約ゼロ。領収書は無視されます。
PreLen Prefix Length 1-128
プレレンプレフィックス長1-128
IPv6 address A 128-bit unicast host address.
IPv6アドレス128ビットユニキャストホストアドレス。
The abstract node represented by this ER-Hop is the set of nodes belonging to the autonomous system.
このER-HOPで表される抽象ノードは、自律システムに属するノードのセットです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 0x0803 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ER-Hop 3, AS Number, Type = 0x0803
ER-HOP 3の値を運ぶタイプA 14ビットフィールド、数字、タイプ= 0x0803
Length Specifies the length of the value field in bytes = 4.
長さは、バイトフィールドの長さをバイト= 4で指定します。
L Bit Set to indicate Loose hop. Cleared to indicate a strict hop.
lルーズホップを示すように設定されています。厳格なホップを示すためにクリアされました。
Reserved Zero on transmission. Ignored on receipt.
送信時に予約ゼロ。領収書は無視されます。
AS Number Autonomous System number
数として自律システム番号として
The LSPID is used to identify the tunnel ingress point as the next hop in the ER. This ER-Hop allows for stacking new CR-LSPs within an already established CR-LSP. It also allows for splicing the CR-LSP being established with an existing CR-LSP.
LSPIDは、ERの次のホップとしてトンネルイングレスポイントを識別するために使用されます。このER-HOPにより、すでに確立されたCR-LSP内に新しいCR-LSPを積み重ねることができます。また、既存のCR-LSPで確立されているCR-LSPをスプライシングすることもできます。
If an LSPID Hop is the last ER-Hop in an ER-TLV, than the LSR may splice the CR-LSP of the incoming Label Request to the CR-LSP that currently exists with this LSPID. This is useful, for example, at the point at which a Label Request used for local repair arrives at the next ER-Hop after the loosely specified CR-LSP segment. Use of the LSPID Hop in this scenario eliminates the need for ER-Hops to keep the entire remaining ER-TLV at each LSR that is at either (upstream or downstream) end of a loosely specified CR-LSP segment as part of its state information. This is due to the fact that the upstream LSR needs only to keep the next ER-Hop and the LSPID and the downstream LSR needs only to keep the LSPID in order for each end to be able to recognize that the same LSP is being identified.
LSPIDホップがER-TLVの最後のERホップである場合、LSRは、このLSPIDで現在存在するCR-LSPに、入っているラベル要求のCR-LSPをスプライスする可能性があります。これは、たとえば、ローカル修理に使用されたラベル要求が、緩やかに指定されたCR-LSPセグメントの後に次のER-HOPに到着する時点で有用です。このシナリオでのLSPIDホップの使用により、ER-HOPSが状態情報の一部として、緩やかに指定されたCR-LSPセグメントの（上流または下流）端にある各LSRに残りのER-TLV全体を維持する必要がなくなります。。これは、上流のLSRが次のER-HOPとLSPIDを維持するだけで、下流のLSRは、同じLSPが識別されていることを各端が認識できるためにLSPIDを維持するだけで必要です。
If the LSPID Hop is not the last hop in an ER-TLV, the LSR must remove the LSP-ID Hop and forward the remaining ER-TLV in a Label Request message using an LDP session established with the LSR that is the specified CR-LSP's egress. That LSR will continue processing of the CR-LSP Label Request Message. The result is a tunneled, or stacked, CR-LSP.
LSPIDホップがER-TLVの最後のホップではない場合、LSRはLSP-IDホップを削除し、指定されたCR-であるLSRで確立されたLDPセッションを使用してラベル要求メッセージに残りのER-TLVを転送する必要があります。LSPの出口。そのLSRは、CR-LSPラベル要求メッセージの処理を継続します。結果は、トンネル型、または積み重ねられたcr-lspです。
To support labels negotiated for tunneled CR-LSP segments, an LDP session is required [1] between tunnel end points - possibly using the existing CR-LSP. Use of the existence of the CR-LSP in lieu of a session, or other possible session-less approaches, is FFS.
トンネル付きのCR-LSPセグメントと交渉されたラベルをサポートするには、トンネルエンドポイント間のLDPセッション[1]が必要です。セッションの代わりにCR-LSPの存在の使用、または他の可能なセッションのないアプローチはFFSです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| 0x0804 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | Local LSPID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress LSR Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the ER-Hop 4, LSPID, Type = 0x0804
ER-HOP 4、LSPID、Type = 0x0804の値を運ぶタイプA 14ビットフィールド
Length Specifies the length of the value field in bytes = 8.
長さは、バイト= 8の値フィールドの長さを指定します。
L Bit Set to indicate Loose hop. Cleared to indicate a strict hop.
lルーズホップを示すように設定されています。厳格なホップを示すためにクリアされました。
Reserved Zero on transmission. Ignored on receipt.
送信時に予約ゼロ。領収書は無視されます。
Local LSPID A 2 byte field indicating the LSPID which is unique with reference to its Ingress LSR.
ローカルLSPID 2バイトフィールドは、その侵入LSRを参照して一意のLSPIDを示しています。
Ingress LSR Router ID An LSR may use any of its own IPv4 addresses in this field.
Ingress LSRルーターID LSRは、このフィールドで独自のIPv4アドレスを使用する場合があります。
A Label Request Message containing an explicit route TLV must determine the next hop for this path. Selection of this next hop may involve a selection from a set of possible alternatives. The mechanism for making a selection from this set is implementation dependent and is outside of the scope of this specification. Selection of particular paths is also outside of the scope of this specification, but it is assumed that each node will make a best effort attempt to determine a loop-free path. Note that such best efforts may be overridden by local policy.
明示的なルートTLVを含むラベル要求メッセージは、このパスの次のホップを決定する必要があります。この次のホップの選択には、可能な選択肢のセットからの選択が含まれる場合があります。このセットから選択を作成するメカニズムは実装依存であり、この仕様の範囲外です。特定のパスの選択は、この仕様の範囲外でもありますが、各ノードはループフリーのパスを決定するために最善の努力をすると想定されています。このような最善の努力は、現地のポリシーによって無効になる可能性があることに注意してください。
To determine the next hop for the path, a node performs the following steps:
パスの次のホップを決定するには、ノードが次の手順を実行します。
1. The node receiving the Label Request Message must first evaluate the first ER-Hop. If the L bit is not set in the first ER-Hop and if the node is not part of the abstract node described by the first ER-Hop, it has received the message in error, and should return a "Bad Initial ER-Hop Error" status. If the L bit is set and the local node is not part of the abstract node described by the first ER-Hop, the node selects a next hop that is along the path to the abstract node described by the first ER-Hop. If there is no first ER-Hop, the message is also in error and the system should return a "Bad Explicit Routing TLV Error" status using a Notification Message sent upstream.
1. ラベル要求メッセージを受信するノードは、最初に最初のER-HOPを評価する必要があります。Lビットが最初のER-HOPで設定されておらず、ノードが最初のER-HOPで説明されている抽象ノードの一部でない場合、メッセージを誤って受信し、「悪い初期ERホップを返す必要がありますエラー "ステータス。Lビットが設定されており、ローカルノードが最初のER-HOPで説明されている抽象ノードの一部ではない場合、ノードは、最初のERホップで記述された抽象ノードへのパスに沿って次のホップを選択します。最初のER-HOPがない場合、メッセージも誤っており、システムは上流に送信された通知メッセージを使用して「悪い明示的なルーティングTLVエラー」ステータスを返す必要があります。
2. If there is no second ER-Hop, this indicates the end of the explicit route. The explicit route TLV should be removed from the Label Request Message. This node may or may not be the end of the LSP. Processing continues with section 4.8.2, where a new explicit route TLV may be added to the Label Request Message.
2. 2番目のER-HOPがない場合、これは明示的なルートの終わりを示します。明示的なルートTLVは、ラベル要求メッセージから削除する必要があります。このノードは、LSPの終わりである場合とそうでない場合があります。セクション4.8.2で処理が続き、新しい明示的なルートTLVをラベルリクエストメッセージに追加できます。
3. If the node is also a part of the abstract node described by the second ER-Hop, then the node deletes the first ER-Hop and continues processing with step 2, above. Note that this makes the second ER-Hop into the first ER-Hop of the next iteration.
3. ノードが2番目のER-HOPで説明されている抽象ノードの一部である場合、ノードは最初のER-HOPを削除し、上記のステップ2で処理を続けます。これにより、次の反復の最初のERホップに2番目のERホップが作成されることに注意してください。
4. The node determines if it is topologically adjacent to the abstract node described by the second ER-Hop. If so, the node selects a particular next hop which is a member of the abstract node. The node then deletes the first ER-Hop and continues processing with section 4.8.2.
4. ノードは、2番目のER-HOPによって記述された抽象ノードに隣接するかどうかを決定します。その場合、ノードは抽象ノードのメンバーである特定の次のホップを選択します。次に、ノードは最初のER-HOPを削除し、セクション4.8.2で処理を継続します。
5. Next, the node selects a next hop within the abstract node of the first ER-Hop that is along the path to the abstract node of the second ER-Hop. If no such path exists then there are two cases:
5. 次に、ノードは、2番目のERホップの抽象ノードへのパスに沿っている最初のER-HOPの抽象ノード内の次のホップを選択します。そのようなパスが存在しない場合、2つのケースがあります。
5.a If the second ER-Hop is a strict ER-Hop, then there is an error and the node should return a "Bad Strict Node Error" status.
5.a 2番目のER-HOPが厳密なER-HOPである場合、エラーがあり、ノードは「悪い厳密なノードエラー」ステータスを返す必要があります。
5.b Otherwise, if the second ER-Hop is a loose ER-Hop, then the node selects any next hop that is along the path to the next abstract node. If no path exists within the MPLS domain, then there is an error, and the node should return a "Bad Loose Node Error" status.
5.Bそれ以外の場合、2番目のER-HOPが緩いER-HOPである場合、ノードは次の抽象ノードへのパスに沿っている次のホップを選択します。MPLSドメイン内にパスが存在しない場合、エラーが発生し、ノードは「バッドルーズノードエラー」ステータスを返す必要があります。
6. Finally, the node replaces the first ER-Hop with any ER-Hop that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted.
6. 最後に、ノードは最初のER-HOPを次のホップを含む抽象ノードを示す任意のER-HOPに置き換えます。これは、明示的なルートが次のホップで受信されると、受け入れられるように必要です。
7. Progress the Label Request Message to the next hop.
7. 次のホップにラベル要求メッセージを進めます。
After selecting a next hop, the node may alter the explicit route in the following ways.
次のホップを選択した後、ノードは次の方法で明示的なルートを変更する場合があります。
If, as part of executing the algorithm in section 4.8.1, the explicit route TLV is removed, the node may add a new explicit route TLV.
セクション4.8.1でアルゴリズムを実行することの一部として、明示的なルートTLVが削除された場合、ノードは新しい明示的なルートTLVを追加する場合があります。
Otherwise, if the node is a member of the abstract node for the first ER-Hop, then a series of ER-Hops may be inserted before the first ER-Hop or may replace the first ER-Hop. Each ER-Hop in this series must denote an abstract node that is a subset of the current abstract node.
それ以外の場合、ノードが最初のER-HOPの抽象ノードのメンバーである場合、最初のER-HOPの前に一連のER-HOPが挿入されるか、最初のERホップを置き換えることができます。このシリーズの各ER-HOPは、現在の抽象ノードのサブセットである抽象ノードを示す必要があります。
Alternately, if the first ER-Hop is a loose ER-Hop, an arbitrary series of ER-Hops may be inserted prior to the first ER-Hop.
あるいは、最初のER-HOPが緩いER-HOPである場合、最初のER-HOPの前に任意のER-HOPのシリーズが挿入される場合があります。
Section 2.4 describes the use of route pinning. The encoding of the Route Pinning TLV is as follows:
セクション2.4では、ルートピン留めの使用について説明します。TLVを固定するルートのエンコードは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0823 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the Pinning-TLV Type = 0x0823
ピンニング-tlvタイプの値を運ぶタイプA 14ビットフィールド= 0x0823
Length Specifies the length of the value field in bytes = 4.
長さは、バイトフィールドの長さをバイト= 4で指定します。
P Bit The P bit is set to 1 to indicate that route pinning is requested. The P bit is set to 0 to indicate that route pinning is not requested
pビットPビットは1に設定されており、ルートピン留めが要求されていることを示します。Pビットは0に設定されて、ルートピン留めが要求されていないことを示します
Reserved Zero on transmission. Ignored on receipt.
送信時に予約ゼロ。領収書は無視されます。
A new FEC element is introduced in this specification to support CR-LSPs. A FEC TLV containing a FEC of Element type CR-LSP (0x04) is a CR-LSP FEC TLV. The CR-LSP FEC Element is an opaque FEC to be used only in Messages of CR-LSPs.
CR-LSPをサポートするために、この仕様に新しいFEC要素が導入されています。要素タイプCr-LSP（0x04）のFECを含むFEC TLVは、CR-LSP FEC TLVです。CR-LSP FEC要素は、CR-LSPのメッセージでのみ使用される不透明なFECです。
A single FEC element MUST be included in the Label Request Message. The FEC Element SHOULD be the CR-LSP FEC Element. However, one of the other FEC elements (Type=0x01, 0x02, 0x03) defined in [1] MAY be in CR-LDP messages instead of the CR-LSP FEC Element for certain applications. A FEC TLV containing a FEC of Element type CR-LSP (0x04) is a CR-LSP FEC TLV.
ラベルリクエストメッセージに単一のFEC要素を含める必要があります。FEC要素は、CR-LSP FEC要素である必要があります。ただし、[1]で定義されている他のFEC要素の1つ（Type = 0x01、0x02、0x03）は、特定のアプリケーションのCR-LSP FEC要素の代わりにCR-LDPメッセージに含まれる場合があります。要素タイプCr-LSP（0x04）のFECを含むFEC TLVは、CR-LSP FEC TLVです。
FEC Element Type Value Type name
FEC要素タイプ値タイプ名
CR-LSP 0x04 No value; i.e., 0 value octets;
CR-LSP 0x04値なし;つまり、0値オクテット。
The CR-LSP FEC TLV encoding is as follows:
CR-LSP FEC TLVエンコードは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0100 | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CR-LSP (4) |
+-+-+-+-+-+-+-+-+
Type A fourteen-bit field carrying the value of the FEC TLV Type = 0x0100
fec tlvタイプの値を運ぶ14ビットフィールドとタイプ= 0x0100
Length Specifies the length of the value field in bytes = 1.
長さは、バイト= 1の値フィールドの長さを指定します。
CR-LSP FEC Element Type
CR-LSP FEC要素タイプ
0x04
0x04
CR-LDP defines the following name spaces, which require management:
CR-LDPは、管理が必要な次の名前スペースを定義します。
- TLV types. - FEC types. - Status codes.
- TLVタイプ。-FECタイプ。 - ステータスコード。
The following sections provide guidelines for managing these name spaces.
次のセクションでは、これらの名前スペースを管理するためのガイドラインを提供します。
RFC 3036 [1] defines the LDP TLV name space. This document further subdivides the range of RFC 3036 from that TLV space for TLVs associated with the CR-LDP in the range 0x0800 - 0x08FF.
RFC 3036 [1]は、LDP TLV名スペースを定義します。このドキュメントは、範囲0x0800-0x08ffのCR -LDPに関連付けられたTLVスペースからRFC 3036の範囲をさらに細分化します。
Following the policies outlined in [IANA], TLV types in this range are allocated through an IETF Consensus action.
[IANA]で概説されているポリシーに従って、この範囲のTLVタイプは、IETFコンセンサスアクションを通じて割り当てられます。
Initial values for this range are specified in the following table:
この範囲の初期値は、次の表に指定されています。
TLV Type
-------------------------------------- ----------
Explicit Route TLV 0x0800
Ipv4 Prefix ER-Hop TLV 0x0801
Ipv6 Prefix ER-Hop TLV 0x0802
Autonomous System Number ER-Hop TLV 0x0803
LSP-ID ER-Hop TLV 0x0804
Traffic Parameters TLV 0x0810
Preemption TLV 0x0820
LSPID TLV 0x0821
Resource Class TLV 0x0822
Route Pinning TLV 0x0823
RFC 3036 defines the FEC Type name space. Further, RFC 3036 has assigned values 0x00 through 0x03. FEC types 0 through 127 are available for assignment through IETF consensus action. This specification makes the following additional assignment, using the policies outlined in [IANA]:
RFC 3036は、FECタイプ名スペースを定義します。さらに、RFC 3036は値0x00から0x03を割り当てました。FECタイプ0〜127は、IETFコンセンサスアクションを通じて割り当てに利用できます。この仕様により、[IANA]で概説されているポリシーを使用して、次の追加の割り当てが行われます。
FEC Element Type
-------------------------------------- ----------
CR-LSP FEC Element 0x04
RFC 3036 defines the Status Code name space. This document further subdivides the range of RFC 3036 from that TLV space for TLVs associated with the CR-LDP in the range 0x04000000 - 0x040000FF.
RFC 3036は、ステータスコード名スペースを定義します。このドキュメントは、範囲0x04000000-0x040000ffのCR -LDPに関連付けられたTLVスペースからRFC 3036の範囲をさらに細分化します。
Following the policies outlined in [IANA], TLV types in this range are allocated through an IETF Consensus action.
[IANA]で概説されているポリシーに従って、この範囲のTLVタイプは、IETFコンセンサスアクションを通じて割り当てられます。
Initial values for this range are specified in the following table:
この範囲の初期値は、次の表に指定されています。
Status Code Type
-------------------------------------- ----------
Bad Explicit Routing TLV Error 0x04000001
Bad Strict Node Error 0x04000002
Bad Loose Node Error 0x04000003
Bad Initial ER-Hop Error 0x04000004
Resource Unavailable 0x04000005
Traffic Parameters Unavailable 0x04000006
LSP Preempted 0x04000007
Modify Request Not Supported 0x04000008
CR-LDP inherits the same security mechanism described in Section 4.0 of [1] to protect against the introduction of spoofed TCP segments into LDP session connection streams.
CR-LDPは、[1]のセクション4.0で説明されている同じセキュリティメカニズムを継承して、スプーフィングされたTCPセグメントのLDPセッション接続ストリームへの導入から保護します。
The messages used to signal the CR-LSP setup are based on the work done by the LDP [1] design team.
CR-LSPのセットアップを信号するために使用されるメッセージは、LDP [1]設計チームが行った作業に基づいています。
The list of authors provided with this document is a reduction of the original list. Currently listed authors wish to acknowledge that a substantial amount was also contributed to this work by:
このドキュメントを提供する著者のリストは、元のリストの削減です。現在リストされている著者は、この作業にもかなりの金額が貢献されたことを認めたいと考えています。
Osama Aboul-Magd, Peter Ashwood-Smith, Joel Halpern, Fiffi Hellstrand, Kenneth Sundell and Pasi Vaananen.
オサマ・アブール・マグド、ピーター・アシュウッド・スミス、ジョエル・ハルパーン、フィフィ・ヘルストランド、ケネス・スンデル、パシ・ヴァーナネン。
The authors would also like to acknowledge the careful review and comments of Ken Hayward, Greg Wright, Geetha Brown, Brian Williams, Paul Beaubien, Matthew Yuen, Liam Casey, Ankur Anand and Adrian Farrel.
著者はまた、ケン・ヘイワード、グレッグ・ライト、ゲーサ・ブラウン、ブライアン・ウィリアムズ、ポール・ボービエン、マシュー・ユン、リアム・ケーシー、アンクール・アナンド、エイドリアン・ファレルの慎重なレビューとコメントを認めたいと思います。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、請求権のオンラインリストを参照してください。
[1] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "Label Distribution Protocol Specification", RFC 3036, January 2001.
[1] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and B. Thomas、「ラベル分布プロトコル仕様」、RFC 3036、2001年1月。
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[2] Rosen、E.、Viswanathan、A。and R. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、2001年1月。
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[3] Awduche、D.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「MPLS上の交通工学要件」、RFC 2702、1999年9月。
[4] Gleeson, B., Lin, A., Heinanen, Armitage, G. and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000.
[4] Gleeson、B.、Lin、A.、Heinanen、Armitage、G。and A. Malis、「IPベースの仮想プライベートネットワークのフレームワーク」、RFC 2764、2000年2月。
[5] Ash, J., Girish, M., Gray, E., Jamoussi, B. and G. Wright, "Applicability Statement for CR-LDP", RFC 3213, January 2002.
[5] Ash、J.、Girish、M.、Gray、E.、Jamoussi、B。、およびG. Wright、「CR-LDPの適用声明」、RFC 3213、2002年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Boscher, C., Cheval, P., Wu, L. and E. Gray, "LDP State Machine", RFC 3215, January 2002.
[7] Boscher、C.、Cheval、P.、Wu、L。and E. Gray、「LDP State Machine」、RFC 3215、2002年1月。
[8] Ash, J., Lee, Y., Ashwood-Smith, P., Jamoussi, B., Fedyk, D., Skalecki, D. and L. Li, "LSP Modification Using CR-LDP", RFC 3214, January 2002.
[8] Ash、J.、Lee、Y.、Ashwood-Smith、P.、Jamoussi、B.、Fedyk、D.、Skalecki、D。and L. Li、「Cr-LDPを使用したLSP修正」、RFC 3214、2002年1月。
Appendix A: CR-LSP Establishment Examples
付録A：CR-LSP確立の例
This appendix provides an example for the setup of a strictly routed CR-LSP. In this example, a specific node represents each abstract node.
この付録は、厳密にルーティングされたCR-LSPのセットアップの例を示しています。この例では、特定のノードは各抽象ノードを表します。
The sample network used here is a four node network with two edge LSRs and two core LSRs as follows:
ここで使用されるサンプルネットワークは、次のように2つのエッジLSRと2つのコアLSRを備えた4つのノードネットワークです。
abc
LSR1------LSR2------LSR3------LSR4
LSR1 generates a Label Request Message as described in Section 3.1 of this document and sends it to LSR2. This message includes the CR-TLV.
LSR1は、このドキュメントのセクション3.1で説明されているように、ラベル要求メッセージを生成し、LSR2に送信します。このメッセージにはCR-TLVが含まれます。
A vector of three ER-Hop TLVs <a, b, c> composes the ER-TLV. The ER-Hop TLVs used in this example are of type 0x0801 (IPv4 prefix) with a prefix length of 32. Hence, each ER-Hop TLV identifies a specific node as opposed to a group of nodes. At LSR2, the following processing of the ER-TLV per Section 4.8.1 of this document takes place:
3つのER-HOP TLVS <A、B、C>のベクトルがER-TLVを構成します。この例で使用されているER-HOP TLVは、32のプレフィックス長を持つタイプ0x0801（IPv4プレフィックス）です。したがって、各ER-HOP TLVは、ノードのグループとは対照的に特定のノードを識別します。LSR2では、このドキュメントのセクション4.8.1ごとにER-TLVの次の処理が行われます。
1. The node LSR2 is part of the abstract node described by the first hop <a>. Therefore, the first step passes the test. Go to step 2.
1. ノードLSR2は、最初のホップ<a>で説明されている抽象ノードの一部です。したがって、最初のステップはテストに合格します。ステップ2に進みます。
2. There is a second ER-Hop, <b>. Go to step 3.
2. 2番目のERホップ<b>があります。ステップ3に進みます。
3. LSR2 is not part of the abstract node described by the second ER-Hop <b>. Go to Step 4.
3. LSR2は、2番目のER-HOP <b>で記述された抽象ノードの一部ではありません。ステップ4に進みます。
4. LSR2 determines that it is topologically adjacent to the abstract node described by the second ER-Hop <b>. LSR2 selects a next hop (LSR3) which is the abstract node. LSR2 deletes the first ER-Hop <a> from the ER-TLV, which now becomes <b, c>. Processing continues with Section 4.8.2.
4. LSR2は、2番目のER-HOP <b>で記述された抽象ノードに隣接するものであると判断します。LSR2は、抽象ノードである次のホップ（LSR3）を選択します。LSR2は、ER-TLVから最初のER-HOP <a>を削除します。これは<b、c>になります。セクション4.8.2で処理が続きます。
At LSR2, the following processing of Section 4.8.2 takes place: Executing algorithm 4.8.1 did not result in the removal of the ER-TLV.
LSR2では、セクション4.8.2の以下の処理が行われます。アルゴリズム4.8.1の実行では、ER-TLVの除去が得られませんでした。
Also, LSR2 is not a member of the abstract node described by the first ER-Hop <b>.
また、LSR2は、最初のER-HOP <b>で説明されている抽象ノードのメンバーではありません。
Finally, the first ER-Hop <b> is a strict hop.
最後に、最初のER-HOP <b>は厳格なホップです。
Therefore, processing section 4.8.2 does not result in the insertion of new ER-Hops. The selection of the next hop has been already done is step 4 of Section 4.8.1 and the processing of the ER-TLV is completed at LSR2. In this case, the Label Request Message including the ER-TLV <b, c> is progressed by LSR2 to LSR3.
したがって、セクション4.8.2の処理では、新しいER-HOPSが挿入されません。次のホップの選択はすでに行われています。セクション4.8.1のステップ4で、ER-TLVの処理はLSR2で完了しています。この場合、ER-TLV <B、C>を含むラベル要求メッセージは、LSR2からLSR3に進行します。
At LSR3, a similar processing to the ER-TLV takes place except that
the incoming ER-TLV = <b, c> and the outgoing ER-TLV is <c>.
At LSR4, the following processing of section 4.8.1 takes place:
LSR4では、セクション4.8.1の以下の処理が行われます。
1. The node LSR4 is part of the abstract node described by the first hop <c>. Therefore, the first step passes the test. Go to step 2.
1. ノードLSR4は、最初のホップ<C>で説明されている抽象ノードの一部です。したがって、最初のステップはテストに合格します。ステップ2に進みます。
2. There is no second ER-Hop, this indicates the end of the CR-LSP. The ER-TLV is removed from the Label Request Message. Processing continues with Section 4.8.2.
2. 2番目のER-HOPはありません。これは、CR-LSPの終わりを示しています。ER-TLVは、ラベルリクエストメッセージから削除されます。セクション4.8.2で処理が続きます。
At LSR4, the following processing of Section 4.8.2 takes place: Executing algorithm 4.8.1 resulted in the removal of the ER-TLV. LSR4 does not add a new ER-TLV.
LSR4では、セクション4.8.2の次の処理が行われます。アルゴリズム4.8.1の実行により、ER-TLVが除去されました。LSR4は新しいER-TLVを追加しません。
Therefore, processing section 4.8.2 does not result in the insertion of new ER-Hops. This indicates the end of the CR-LSP and the processing of the ER-TLV is completed at LSR4.
したがって、セクション4.8.2の処理では、新しいER-HOPSが挿入されません。これは、CR-LSPの終了とER-TLVの処理がLSR4で完了したことを示しています。
At LSR4, processing of Section 3.2 is invoked. The first condition is satisfied (LSR4 is the egress end of the CR-LSP and upstream mapping has been requested). Therefore, a Label Mapping Message is generated by LSR4 and sent to LSR3.
LSR4では、セクション3.2の処理が呼び出されます。最初の条件が満たされます（LSR4はCR-LSPの出力端であり、上流マッピングが要求されています）。したがって、ラベルマッピングメッセージはLSR4によって生成され、LSR3に送信されます。
At LSR3, the processing of Section 3.2 is invoked. The second condition is satisfied (LSR3 received a mapping from its downstream next hop LSR4 for a CR-LSP for which an upstream request is still pending). Therefore, a Label Mapping Message is generated by LSR3 and sent to LSR2.
LSR3では、セクション3.2の処理が呼び出されます。2番目の条件が満たされています（LSR3は、上流のリクエストがまだ保留中のCR-LSPの下流の次のホップLSR4からマッピングを受け取りました）。したがって、ラベルマッピングメッセージはLSR3によって生成され、LSR2に送信されます。
At LSR2, a similar processing to LSR 3 takes place and a Label Mapping Message is sent back to LSR1, which completes the end-to-end CR-LSP setup.
LSR2では、LSR 3と同様の処理が行われ、ラベルマッピングメッセージがLSR1に送信され、エンドツーエンドのCR-LSPセットアップが完了します。
A request at ingress LSR to setup a CR-LSP might originate from a management system or an application, the details are implementation specific.
Ingress LSRでのCR-LSPをセットアップするリクエストは、管理システムまたはアプリケーションから発生する可能性があり、詳細は実装固有です。
The ingress LSR uses information provided by the management system or the application and possibly also information from the routing database to calculate the explicit route and to create the Label Request Message.
Ingress LSRは、管理システムまたはアプリケーションによって提供される情報を使用し、場合によってはルーティングデータベースからの情報も使用して、明示的なルートを計算し、ラベル要求メッセージを作成します。
The Label request message carries together with other necessary information an ER-TLV defining the explicitly routed path. In our example the list of hops in the ER-Hop TLV is supposed to contain an abstract node representing a group of nodes, an abstract node representing a specific node, another abstract node representing a group of nodes, and an abstract node representing a specific egress point.
ラベルリクエストメッセージは、明示的にルーティングされたパスを定義するER-TLVを他の必要な情報と連携させます。この例では、ER-HOP TLVのホップのリストは、ノードのグループを表す抽象ノード、特定のノードを表す抽象ノード、ノードのグループを表す別の抽象ノード、および特定の抽象ノードを含むことになっています。出口点。
In--{Group 1}--{Specific A}--{Group 2}--{Specific Out: B} The ER-TLV contains four ER-Hop TLVs:
in-{グループ1} - {具体的なa} - {グループ2} - {eppecipy Out：b} ER-TLVには4つのER-HOP TLVが含まれています。
1. An ER-Hop TLV that specifies a group of LSR valid for the first abstract node representing a group of nodes (Group 1).
1. ノードのグループ（グループ1）を表す最初の抽象ノードに有効なLSRのグループを指定するER-HOP TLV。
2. An ER-Hop TLV that indicates the specific node (Node A).
2. 特定のノード（ノードA）を示すER-HOP TLV。
3. An ER-Hop TLV that specifies a group of LSRs valid for the second abstract node representing a group of nodes (Group 2).
3. ノードのグループ（グループ2）を表す2番目の抽象ノードに有効なLSRのグループを指定するER-HOP TLV。
4. An ER-Hop TLV that indicates the specific egress point for the CR-LSP (Node B).
4. CR-LSP（ノードB）の特定の出力ポイントを示すER-HOP TLV。
All the ER-Hop TLVs are strictly routed nodes.
すべてのER-HOP TLVは、厳密にルーティングされたノードです。
The setup procedure for this CR-LSP works as follows:
このCR-LSPのセットアップ手順は次のように機能します。
1. The ingress node sends the Label Request Message to a node that is a member the group of nodes indicated in the first ER-Hop TLV, following normal routing for the specific node (A).
1. Ingressノードは、特定のノード（a）の通常のルーティングに続いて、最初のER-HOP TLVに示されたノードのグループがメンバーであるノードにラベル要求メッセージを送信します。
2. The node that receives the message identifies itself as part of the group indicated in the first ER-Hop TLV, and that it is not the specific node (A) in the second. Further it realizes that the specific node (A) is not one of its next hops.
2. メッセージを受信するノードは、最初のER-HOP TLVに示されているグループの一部としてそれ自体を識別し、2番目のER-HOP TLVに示されており、2番目の特定のノード（a）ではありません。さらに、特定のノード（a）が次のホップの1つではないことを認識しています。
3. It keeps the ER-Hop TLVs intact and sends a Label Request Message to another node that is part of the group indicated in the first ER-Hop TLV (Group 1), following normal routing for the specific node (A).
3. ER-HOP TLVをそのままに保ち、特定のノード（A）の通常のルーティングに続いて、最初のER-HOP TLV（グループ1）に示されているグループの一部である別のノードにラベル要求メッセージを送信します。
4. The node that receives the message identifies itself as part of the group indicated in the first ER-Hop TLV, and that it is not the specific node (A) in the second ER-Hop TLV. Further it realizes that the specific node (A) is one of its next hops.
4. メッセージを受信するノードは、最初のER-HOP TLVに示されているグループの一部としてそれ自体を識別し、2番目のER-HOP TLVの特定のノード（a）ではないことです。さらに、特定のノード（a）が次のホップの1つであることがわかります。
5. It removes the first ER-Hop TLVs and sends a Label Request Message to the specific node (A).
5. 最初のER-HOP TLVを削除し、特定のノード（a）にラベルリクエストメッセージを送信します。
6. The specific node (A) recognizes itself in the first ER-Hop TLV. Removes the specific ER-Hop TLV.
6. 特定のノード（a）は、最初のER-HOP TLVでそれ自体を認識します。特定のER-HOP TLVを削除します。
7. It sends a Label Request Message to a node that is a member of the group (Group 2) indicated in the ER-Hop TLV.
7. ER-HOP TLVに示されているグループ（グループ2）のメンバーであるノードにラベル要求メッセージを送信します。
8. The node that receives the message identifies itself as part of the group indicated in the first ER-Hop TLV, further it realizes that the specific egress node (B) is one of its next hops.
8. メッセージを受信するノードは、最初のER-HOP TLVに示されているグループの一部としてそれ自体を識別します。さらに、特定の出力ノード（b）が次のホップの1つであることがわかります。
9. It sends a Label Request Message to the specific egress node (B).
9. 特定の出力ノード（b）にラベル要求メッセージを送信します。
10. The specific egress node (B) recognizes itself as the egress for the CR-LSP, it returns a Label Mapping Message, that will traverse the same path as the Label Request Message in the opposite direction.
10. 特定の出口ノード（b）は、それ自体がCR-LSPの出口として認識され、ラベルマッピングメッセージを返します。これは、ラベル要求メッセージと同じパスを反対方向に通過します。
Construction of an end-to-end service is the result of the rules enforced at the edge and the treatment that packets receive at the network nodes. The rules define the traffic conditioning actions that are implemented at the edge and they include policing with pass, mark, and drop capabilities. The edge rules are expected to be defined by the mutual agreements between the service providers and their customers and they will constitute an essential part of the SLA. Therefore edge rules are not included in the signaling protocol.
エンドツーエンドサービスの構築は、エッジで実施されたルールと、ネットワークノードでパケットが受ける処理の結果です。ルールは、エッジで実装されるトラフィックコンディショニングアクションを定義し、パス、マーク、ドロップ機能を備えたポリシングが含まれます。エッジルールは、サービスプロバイダーとその顧客との間の相互契約によって定義されることが期待されており、SLAの重要な部分を構成します。したがって、エッジルールはシグナリングプロトコルに含まれていません。
Packet treatment at a network node is usually referred to as the local behavior. Local behavior could be specified in many ways. One example for local behavior specification is the service frequency introduced in section 4.3.2.1, together with the resource reservation rules implemented at the nodes.
ネットワークノードでのパケット処理は、通常、ローカルの動作と呼ばれます。局所的な行動は、多くの方法で指定できます。ローカルの動作仕様の1つの例は、セクション4.3.2.1で導入されたサービス頻度と、ノードで実装されているリソース予約ルールです。
Edge rules and local behaviors can be viewed as the main building blocks for the end-to-end service construction. The following table illustrates the applicability of the building block approach for constructing different services including those defined for ATM.
エッジルールとローカルの動作は、エンドツーエンドサービス構造のメインビルディングブロックと見なすことができます。次の表は、ATM向けに定義されたものを含むさまざまなサービスを構築するためのビルディングブロックアプローチの適用性を示しています。
Service PDR PBS CDR CBS EBS Service Conditioning Examples Frequency Action
サービスPDR PBS CDR CBS EBSサービスコンディショニングの例頻度アクション
DS S S =PDR =PBS 0 Frequent drop>PDR
TS S S S S 0 Unspecified drop>PDR,PBS mark>CDR,CBS
TS S S S S S 0不特定のドロップ> PDR、PBS MARK> CDR、CBS
BE inf inf inf inf 0 Unspecified -
in inf inf inf inf 0不特定 -
FRS S S CIR ~B_C ~B_E Unspecified drop>PDR,PBS
mark>CDR,CBS,EBS
ATM-CBR PCR CDVT =PCR =CDVT 0 VeryFrequent drop>PCR
ATM-VBR.3(rt) PCR CDVT SCR MBS 0 Frequent drop>PCR mark>SCR,MBS
ATM-VBR.3（RT）PCR CDVT SCR MBS 0頻繁なドロップ> PCRマーク> SCR、MBS
ATM-VBR.3(nrt) PCR CDVT SCR MBS 0 Unspecified drop>PCR mark>SCR,MBS
ATM-VBR.3（NRT）PCR CDVT SCR MBS 0不特定のドロップ> PCRマーク> SCR、MBS
ATM-UBR PCR CDVT - - 0 Unspecified drop>PCR
ATM-GFR.1 PCR CDVT MCR MBS 0 Unspecified drop>PCR
ATM-GFR.1 PCR CDVT MCR MBS 0不特定のドロップ> PCR
ATM-GFR.2 PCR CDVT MCR MBS 0 Unspecified drop>PCR mark>MCR,MFS
ATM-GFR.2 PCR CDVT MCR MBS 0不特定のドロップ> PCRマーク> MCR、MFS
int-serv-CL p m r b 0 Frequent drop>p drop>r,b
int-serv-clp m r b 0頻繁なドロップ> pドロップ> r、b
S= User specified
s =ユーザー指定
In the above table, the DS refers to a delay sensitive service where the network commits to deliver with high probability user datagrams at a rate of PDR with minimum delay and delay requirements. Datagrams in excess of PDR will be discarded.
上記の表では、DSは、最小の遅延要件と遅延要件を備えたPDRのレートで高い確率ユーザーデータグラムを提供することをネットワークがコミットする遅延敏感なサービスを指します。PDRを超えるデータグラムは破棄されます。
The TS refers to a generic throughput sensitive service where the network commits to deliver with high probability user datagrams at a rate of at least CDR. The user may transmit at a rate higher than CDR but datagrams in excess of CDR would have a lower probability of being delivered.
TSは、少なくともCDRのレートで高い確率ユーザーデータグラムを提供することをネットワークが提供する一般的なスループットに敏感なサービスを指します。ユーザーはCDRよりも高い速度で送信できますが、CDRを超えるデータグラムは、配信される可能性が低くなります。
The BE is the best effort service and it implies that there are no expected service guarantees from the network.
BEは最良の努力サービスであり、ネットワークから予想されるサービス保証がないことを意味します。
In this scenario the customer needs to establish an LSP for supporting real-time applications such as voice and video. The Delay-sensitive (DS) service is requested in this case.
このシナリオでは、顧客は音声やビデオなどのリアルタイムアプリケーションをサポートするためのLSPを確立する必要があります。この場合、遅延感受性（DS）サービスが要求されます。
The first step is the specification of the traffic parameters in the signaling message. The two parameters of interest to the DS service are the PDR and the PBS and the user based on his requirements specifies their values. Since all the traffic parameters are included in the signaling message, appropriate values must be assigned to all of them. For DS service, the CDR and the CBS values are set equal to the PDR and the PBS respectively. An indication of whether the parameter values are subject to negotiation is flagged.
最初のステップは、信号メッセージ内のトラフィックパラメーターの指定です。DSサービスにとって関心のある2つのパラメーターは、PDRとPBSとその要件に基づくユーザーが、その値を指定します。すべてのトラフィックパラメーターは信号メッセージに含まれているため、適切な値をすべてに割り当てる必要があります。DSサービスの場合、CDRとCBS値はそれぞれPDRとPBSに等しく設定されます。パラメーター値がネゴシエーションの対象かどうかを示すことにフラグが付けられます。
The transport characteristics of the DS service require Frequent frequency to be requested to reflect the real-time delay requirements of the service.
DSサービスの輸送特性は、サービスのリアルタイム遅延要件を反映するために頻繁に頻繁に要求する必要があります。
In addition to the transport characteristics, both the network provider and the customer need to agree on the actions enforced at the edge. The specification of those actions is expected to be a part of the service level agreement (SLA) negotiation and is not included in the signaling protocol. For DS service, the edge action is to drop packets that exceed the PDR and the PBS specifications. The signaling message will be sent in the direction of the ER path and the LSP is established following the normal LDP procedures. Each LSR applies its admission control rules. If sufficient resources are not available and the parameter values are subject to negotiation, then the LSR could negotiate down the PDR, the PBS, or both.
輸送特性に加えて、ネットワークプロバイダーと顧客の両方が、エッジで実施されたアクションに同意する必要があります。これらのアクションの仕様は、サービスレベル契約（SLA）の交渉の一部であり、シグナリングプロトコルには含まれていません。DSサービスの場合、エッジアクションは、PDRおよびPBS仕様を超えるパケットをドロップすることです。信号メッセージはERパスの方向に送信され、LSPは通常のLDP手順に従って確立されます。各LSRは、入場管理ルールを適用します。十分なリソースが利用できず、パラメーター値が交渉の対象となる場合、LSRはPDR、PBS、またはその両方を交渉することができます。
The new parameter values are echoed back in the Label Mapping Message. LSRs might need to re-adjust their resource reservations based on the new traffic parameter values.
新しいパラメーター値は、ラベルマッピングメッセージに反映されます。LSRは、新しいトラフィックパラメーター値に基づいてリソースの予約を再調整する必要がある場合があります。
In this example we assume that a throughput sensitive (TS) service is requested. For resource allocation the user assigns values for PDR, PBS, CDR, and CBS. The negotiation flag is set if the traffic parameters are subject to negotiation. Since the service is delay insensitive by definition, the Unspecified frequency is signaled to indicate that the service frequency is not an issue.
この例では、スループットに敏感な（TS）サービスが要求されていると仮定します。リソース割り当ての場合、ユーザーはPDR、PBS、CDR、およびCBSの値を割り当てます。交通パラメーターが交渉の対象となる場合、ネゴシエーションフラグが設定されます。定義上、サービスは遅延しないため、不特定の頻度は、サービス頻度が問題ではないことを示すように信号を送られます。
Similar to the previous example, the edge actions are not subject for signaling and are specified in the service level agreement between the user and the network provider.
前の例と同様に、エッジアクションはシグナリングの対象ではなく、ユーザーとネットワークプロバイダーの間のサービスレベル契約で指定されています。
For TS service, the edge rules might include marking to indicate high discard precedence values for all packets that exceed CDR and the CBS. The edge rules will also include dropping of packets that conform to neither PDR nor PBS.
TSサービスの場合、EDGEルールには、CDRとCBSを超えるすべてのパケットの高い破棄の優先順位値を示すマークが含まれる場合があります。Edgeルールには、PDRもPBSもいないパケットのドロップも含まれます。
Each LSR of the LSP is expected to run its admission control rules and negotiate traffic parameters down if sufficient resources do not exist. The new parameter values are echoed back in the Label Mapping Message. LSRs might need to re-adjust their resources based on the new traffic parameter values.
LSPの各LSRは、十分なリソースが存在しない場合、入場管理ルールを実行し、トラフィックパラメーターを交渉することが期待されています。新しいパラメーター値は、ラベルマッピングメッセージに反映されます。LSRは、新しいトラフィックパラメーター値に基づいてリソースを再調整する必要がある場合があります。
Loa Andersson Utfors Bredband AB Rasundavagen 12 169 29 Solna Phone: +46 8 5270 50 38 EMail: loa.andersson@utfors.se
loa andersson utfors bredband ab rasundavagen 12 169 29 solna電話：46 8 5270 50 38メール：loa.andersson@utfors.se
Ross Callon Juniper Networks 1194 North Mathilda Avenue, Sunnyvale, CA 94089 Phone: 978-692-6724 EMail: rcallon@juniper.net
Ross Callon Juniper Networks 1194 North Mathilda Avenue、Sunnyvale、CA 94089電話：978-692-6724メール：rcallon@juniper.net
Ram Dantu Netrake Corporation 3000 Technology Drive, #100 Plano Texas, 75024 Phone: 214 291 1111 EMail: rdantu@netrake.com
Ram Dantu Netrake Corporation 3000テクノロジードライブ、＃100 Plano Texas、75024電話：214 291 1111メール：rdantu@netrake.com
Paul Doolan On The Beach Consulting Corp 34 Mill Pond Circle Milford MA 01757 Phone 617 513 852 EMail: pdoolan@acm.org Nancy Feldman IBM Research 30 Saw Mill River Road Hawthorne, NY 10532 Phone: 914-784-3254 EMail: Nkf@us.ibm.com
Paul Doolan on the Beach Consulting Corp 34 Mill Pond Circle Milford MA 01757電話617 513 852メール：pdoolan@acm.org Nancy Feldman IBM Research 30 Saw Mill River Road Hawthorne、NY 10532電話：914-784-3254電子メール.ibm.com
Andre Fredette ANF Consulting 62 Duck Pond Dr. Groton, MA 01450 EMail: afredette@charter.net
Andre Fredette ANF Consulting 62 Duck Pond Dr. Groton、MA 01450メール：afredette@charter.net
Eric Gray 600 Federal Drive Andover, MA 01810 Phone: (978) 689-1610 EMail: eric.gray@sandburst.com
Eric Grey 600 Federal Drive Andover、MA 01810電話：（978）689-1610メール：eric.gray@sandburst.com
Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland EMail: jh@song.fi
Juha Heinanen Song Networks、Inc。Hallituskatu 16 33200 Tampere、Finland Email：jh@song.fi
Bilel Jamoussi Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288-4506 Mail: Jamoussi@nortelnetworks.com
Bilel Jamoussi Nortel Networks 600 Technology Park Drive Drive Billerica、MA 01821 USA電話：1 978 288-4506メール：jamoussi@nortelnetworks.com
Timothy E. Kilty Island Consulting Phone: (978) 462 7091 EMail: tim-kilty@mediaone.net
Timothy E. Kilty Islandコンサルティング電話：（978）462 7091メール：tim-kilty@mediaone.net
Andrew G. Malis Vivace Networks 2730 Orchard Parkway San Jose, CA 95134 Phone: +1 408 383 7223 EMail: Andy.Malis@vivacenetworks.com Muckai K Girish Atoga Systems 49026 Milmont Drive Fremont, CA 94538 EMail: muckai@atoga.com
Andrew G. Malis Vivace Networks 2730 Orchard Parkway San Jose、CA 95134電話：1 408 383 7223電子メール：andy.malis@vivacenetworks.com Muckai K Girish Atoga Systems 49026 Milmont Drive Fremont、CA 94538メール
Tom Worster Phone: 617 247 2624 EMail: fsb@thefsb.org
Tom Worster Phone：617 247 2624メール：fsb@thefsb.org
Liwen Wu Cisco Systems 250 Apollo Drive Chelmsford, MA. 01824 Phone: 978-244-3087 EMail: liwwu@cisco.com
Liwen Wu Cisco Systems 250 Apollo Drive Chelmsford、MA。01824電話：978-244-3087メール：liwwu@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。