RFC3212 日本語訳
3212 Constraint-Based LSP Setup using LDP. B. Jamoussi, Ed., L.Andersson, R. Callon, R. Dantu, L. Wu, P. Doolan, T. Worster, N.Feldman, A. Fredette, M. Girish, E. Gray, J. Heinanen, T. Kilty, A.Malis. January 2002. (Format: TXT=87591 bytes) (Updated by RFC3468) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループB.Jamoussi、ノーテルネットワークがコメントのために要求するエディタをネットワークでつないでください: 3212 L.アンデション、Utfors ABカテゴリ: 標準化過程R.Callon、R.Dantu、杜松ネットワークNetrake社のL.ウー、シスコシステムズP.Doolan、OTB Consulting社のT.オースター・N.フェルドマン、IBM社のA.Fredette、ANFコンサルティングM.Girish、AtogaシステムE.グレー、Sandburst J.Heinanen、歌は2002年1月にInc.T.Kilty、ニューブリッジネットワークスInc.A.Malis、活発なネットワークをネットワークでつなぎます。
Constraint-Based LSP Setup using LDP
自由民主党を使用する規制ベースのLSPセットアップ
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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).
このドキュメントは、自由民主党(ラベルDistributionプロトコル)を使用することでメカニズムとTLVs(タイプ/長さ/値)をCR-LSPs(規制ベースの発送されたLabel Switched Path)のサポートに指定します。
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.
この仕様はイングレスLSR(ラベルSwitching Router)によって開始されたCR-LSPの終わりから終わりへのセットアップメカニズムを提案します。 また、私たちは、自由民主党を使用することでリソースの予約のための手段を提供するためにメカニズムを指定します。
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように本書では解釈されることであるべきですか?
Jamoussi, et al. Standards Track [Page 1] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[1ページ]RFC3212の規制ベースのLSPセットアップ
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
1. 序論…3 2. 規制ベースのルート設定概観…4 2.1 厳しくてゆるい明白なルート…5 2.2 交通の特性…5 2.3先取り…5 2.4 ピンで止めることを発送してください…6 2.5リソースのクラス…6 3. ソリューション概観…6 3.1 メッセージとTLVsが必要でした…7 3.2 要求メッセージをラベルしてください…7 3.3 マッピングメッセージをラベルしてください…9 3.4通知メッセージ…3.5がリリースする10、アボートは通信します… 引き下がってください。そうすれば、…11 4. 仕様を議定書の中で述べてください…11 4.1 明白なルートTLV、(えー、-、TLV、)、…11 4.2 明白なルートホップTLV、(えー、-跳んでください、TLV)、…12 4.3 交通パラメタTLV…13 4.3 .1意味論…15 4.3 .1 .1頻度…15 4.3 .1 .2 レートに最大限にしてください…16 4.3 .1 .3はレートを遂行しました…16 4.3 .1 .4 過剰はサイズを押し破きました…16 4.3 .1 .5 レート象徴バケツを直立させてください…16 4.3 .1 .6はデータ信号速度象徴バケツを遂行しました…17 4.3 .1 .7 重みを加えます。18 4.3 .2の手順…18 4.3 .2 .1 要求メッセージをラベルしてください…18 4.3 .2 .2 マッピングメッセージをラベルしてください…18 4.3 .2 .3通知メッセージ…19 4.4 先取りTLV…19 4.5LSPID TLV…20 4.6 リソースのクラス(色)TLV…21 4.7 ER-ホップ意味論…22 4.7.1. えー、-跳んでください、1: IPv4接頭語…22 4.7.2. えー、-跳んでください、2: IPv6アドレス…23 4.7.3. えー、-跳んでください、3: 自律システム番号…24 4.7.4. えー、-跳んでください、4: LSPID…24 4.8. 明白なルートTLVの処理…26 4.8.1. 次のホップの選択…26 4.8.2. 明白なルートTLVにER-ホップスを加えます…27 4.9 ピンで止めるTLVを発送してください…28 4.10CR-LSP FEC要素…28 5. IANA問題…29 5.1 TLVは名前スペースをタイプします…29 5.2 FECは名前スペースをタイプします…30 5.3 ステータスコードスペース…30
Jamoussi, et al. Standards Track [Page 2] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[2ページ]RFC3212の規制ベースのLSPセットアップ
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
6. セキュリティ問題…31 7. 承認…31 8. 知的所有権の考慮…31 9. 参照…32 付録A: CR-LSP設立の例…33のA.1の厳しい明白なルートの例…33 A.2ノードグループと特定のノードの例…34 付録B.QoSは例を修理します…36 B.1は例を修理します…リアルタイムのアプリケーションを支持するCR-LSPを設立する36B.2…38 CR-LSPサポートを設立するB.3が神経の鈍いアプリケーション.38作者のアドレスを遅らせます…39 完全な著作権宣言文…42
1. Introduction
1. 序論
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].
ラベルDistributionプロトコル(自由民主党)は1つのMPLSドメインの中でラベルの分配のための[1]で定義されます。 一般に、MPLSと特に自由民主党を使用することで提供されるかもしれない中で最も重要なサービスの1つは発送されたネットワークの向こう側の交通の規制ベースのルーティングのサポートです。 規制ベースのルーティングはルーティング・プロトコルのために利用可能なことを超えて経路をセットアップするのに使用される情報を広げる機会を提供します。 例えば、LSPは明白なルート規制、QoS規制、および他の規制に基づくセットアップであるかもしれません。 規制ベースのルーティング(CR)は提案されたTraffic Engineering要件、[2]、および[3]に会うのに使用されるメカニズムです。 これらの必要条件は、規制ベースの発送されたラベルの切り換えられた経路(CR-LSPs)のサポートのために自由民主党を広げることによって、満たされるかもしれません。 CR-LSPsへの他の用途はMPLSベースのVPNs[4]を含んでいます。 [5]でCR-自由民主党の適用性に関する詳しい情報を見つけることができます。
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会合に、自由民主党が関連(推進)優先権のしるしへの支給でLSPsの明白なルーティングを支持するべきであるというコンセンサスがありました。 シカゴのミーティング(1998年8月)では、自由民主党における明白な経路セットアップのサポートが別々のドキュメントに動かされるという決定をしました。 このドキュメントはそのサポートを提供します、そして、それは働くドキュメントとしてオーランドのミーティング(1998年12月)で認められました。
Jamoussi, et al. Standards Track [Page 3] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[3ページ]RFC3212の規制ベースのLSPセットアップ
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.
この仕様はイングレスLSRによって開始された規制ベースの発送されたLSP(CR-LSP)の終わりから終わりへのセットアップメカニズムを提案します。 また、私たちは、自由民主党を使用することでリソースの予約のための手段を提供するためにメカニズムを指定します。
This document introduce TLVs and procedures that provide support for:
このドキュメントは以下のサポートを提供するTLVsと手順を導入します。
- Strict and Loose Explicit Routing
- Specification of Traffic Parameters
- Route Pinning
- CR-LSP Preemption though setup/holding priorities
- Handling Failures
- LSPID
- Resource Class
- 厳しい、そして、Loose Explicitルート設定--Traffic Parametersの仕様--Pinningを発送します--CR-LSP Preemption、もっとも、Failures--LSPID--リソースClassを扱って、/が優位に立つのをセットアップしてください。
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-自由民主党解決策を概説します。 セクション4はTLVsを定義します、そして、規制ベースの発送されたラベルをセットアップするのに用いられた手順は経路を切り換えました。 付録AはCR-LSP経路セットアップに関するいくつかの例を提供します。 付録BはService Definition Examplesを提供します。
2. Constraint-based Routing Overview
2. 規制ベースのルート設定概観
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]で定義されたTraffic Engineering要件を支持するメカニズムです。 明白なルート設定は規制が明白なルート(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ネットワークを通した経路です。 違いは規制ベースのルートが他の経路が唯一経路指定テーブルかマネージメントシステムからの情報に基づくセットアップである間評価基準に基づくネットワークの縁の1ポイントで計算されるということです、他のルーティング情報を含んでいて。 意志はこの機能性がLSPの上に送られた交通を支持するほうがよいために必要な特別な特性をLSPに与えるものとするということです。 CR-LSPsをセットアップする理由は人が、ある一定の帯域幅か他のService Classの特性をLSPに割り当てたがっているか、または人が、代替のルートがネットワークを通して肉体的に別々の経路を使用するのを確実にしたがっているということであるかもしれません。
Jamoussi, et al. Standards Track [Page 4] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[4ページ]RFC3212の規制ベースのLSPセットアップ
2.1 Strict and Loose Explicit Routes
2.1 厳しくてゆるい明白なルート
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.
明白なルートはノードのリストかノードのグループとして規制ベースのルートに沿ってLabel Request Messageに表されます。 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.
一連のER-ホップが規制ベースのルートにTLVを含んで、規制ベースのルートはコード化されます。 各ER-ホップは規制ベースのルートによるノードのグループを特定するかもしれません。 そして、規制ベースのルートはそれらが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.
議論を簡素化するために、私たちは、「抽象的なノード」にノードの各グループに電話をします。 したがって、また、私たちは、規制ベースのルートが抽象的なノードのすべてを含む経路であると言うことができます、指定された操作がその経路に沿って起こっていて。
2.2 Traffic Characteristics
2.2 交通の特性
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.
経路の交通の特性はTraffic Parameters TLVでピークレート、遂行されたレート、およびサービス粒状で説明されます。 ピークと遂行されたレートはCR-LDP MPLSドメインが経路の交通に取り入れるかもしれない遅れ変化で規制を指定するのにサービス粒状を使用できる間、経路の帯域幅規制について説明します。
2.3 Preemption
2.3 先取り
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-自由民主党はルートの各ホップの上の経路によって必要とされたリソースに合図します。 十分なリソースがあるルートを見つけることができないなら、既存の経路は、新しい経路にリソースを再割当てするために別ルートで送られるかもしれません。 これは経路先取りの過程です。 新しい経路が既存の経路を先取りできるなら、セットアップとプライオリティを保持するのは、存在が経路(優位に立って)と決定する新しい経路(セットアップ優先権)であると格付けするのに使用されます。
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
新しいCR-LSPのsetupPriorityと既存のCR-LSPのholdingPriority属性は、プライオリティを指定するのに使用されます。 経路であり、一度それがそうであると、より高い把持優先権急行に合図します。
Jamoussi, et al. Standards Track [Page 5] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[5ページ]RFC3212の規制ベースのLSPセットアップ
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.
確立していて、先取りされるという下側の機会を持つべきです。 おそらく、他の経路を先取りするようにリソースが入手できない経路が期待ですが、優先権が言い表すより高いセットアップに合図します。 突き当たることを決定する正確な規則はネットワーク方針の局面です。
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(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のsetupPriorityはそれ以来のholdingPriorityがLSPに突き当たって、次の「同等な」要求で突き当たられるかもしれないより高いはずがありません(数の上でさらに少ない)。
2.4 Route Pinning
2.4 ルートのピンで止めること
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」で指定されるそれらのセグメント。 CR-LSPは次の、より良いホップがLSPの緩く発送された部分に沿ったいくらかのLSRで利用可能になるときさえLSPによって使用された経路を変えるのが望ましくないならルートのピンで止めることを使用するセットアップであるかもしれません。
2.5 Resource Class
2.5 リソースのクラス
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がどのリソースのクラスから描くことができるかを示すのが必要です。
3. Solution Overview
3. ソリューション概観
CR-LSP over LDP Specification is designed with the following goals:
自由民主党Specificationの上の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]に基づいています。
Jamoussi, et al. Standards Track [Page 6] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[6ページ]RFC3212の規制ベースのLSPセットアップ
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-LSPsのサポートは指定されます。 さらなる研究(FFS)にはポイントツーマルチポイントのサポート(多点からポイント)が、あります。
Support for constraint-based routed LSPs in this specification depends on the following minimal LDP behaviors as specified in [1]:
この仕様による規制ベースの発送されたLSPsのサポートは[1]の指定されるとしての以下の最小量の自由民主党の振舞いによります:
- 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].
- 使用、Basic、そして/または、ExtendedディスカバリーMechanisms--命令されたコントロールで[1]で川下のオンデマンドのラベル広告モードで定義されたLabel Request Messageの使用。 - 命令されたコントロールで[1]で川下のオンデマンドのモードで定義されたLabel Mapping Messageの使用。 - [1]で定義されたNotification Messageの使用。 - [1]で定義されたWithdrawとRelease Messagesの使用。 - [1]で定義されたLoop Detection(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をセットアップするのに使用されるLabel Request Messageはセクション4で定義された1CR-TLVsを含んでいます。 例えば、Label Request Messageは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はLabel Request Messageの1CR-TLVsの存在から命令されたコントロールをそれとなく推論します。 これは、ダイナミックルーティングの結果、設立されたLSPsのための独立制御のためにまだLSRを構成できることを意味します。 しかしながら、Label Request MessageがCR- TLVsの1つ以上を含んでいるとき、そして、命令されたコントロールは、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-TLVsで指定された確立した経路の失敗のためのエラー通知を扱うために定義されます。 新しいステータスコードのすべてが、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.
プロトコルで言いなりになるために任意のTLVsを実行しなければなりません。 しかしながら、それらは設立されるか、または変更されるCR-LSPのある特性に合図するCR-自由民主党メッセージで任意に運ばれます。
Examples of CR-LSP establishment are given in Appendix A to illustrate how the mechanisms described in this document work.
CR-LSP設立に関する例は、メカニズムがどう本書では仕事について説明したかを例証するためにAppendix Aで出されます。
Jamoussi, et al. Standards Track [Page 7] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[7ページ]RFC3212の規制ベースのLSPセットアップ
3.1 Required Messages and TLVs
3.1 必要なメッセージとTLVs
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.
明らかに定義されなかったどんなMessages、TLVs、および手順も自由民主党Specification[1]で本書では定義されます。 読者は状態遷移に関する情報のドキュメントとして[7]を使用できます。(状態遷移はCR-自由民主党メッセージに関連します)。
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.
Status TLVの使用が[1]についてセクション3.4.6における指定されるとしてのNotificationメッセージに制限されないことに注意してください。 Notificationメッセージ以外のメッセージはOptional ParameterとしてStatus TLVを運ぶかもしれません。 Notification以外のメッセージがStatus TLVを運ぶとき、1にStatus TLVのU-ビットが、それを扱うために用意ができていないなら受信機が静かにTLVを捨てるはずであるのを示すように設定されるべきです。
3.2 Label Request Message
3.2 ラベル要求メッセージ
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):
定義されるとしてLabel Request Messageがいる、3.5、.8、以下の変更(CR-TLVsのどれかがLabel Request Messageに含まれている場合にだけ、必要である)がある[1]について:
- 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.
- Label Request Messageはただ一つのFEC-TLV要素を含まなければなりません。 CR-LSP FEC TLV要素SHOULD、使用されてください。 しかしながら、[1]で定義された他のFEC- TLVsはあるアプリケーションに代わりに使用されるかもしれません。
- The Optional Parameters TLV includes the definition of any of
the Constraint-based TLVs specified in Section 4.
- Optional Parameters TLVはセクション4で指定されたConstraintベースのTLVsのどれかの定義を含んでいます。
- The Procedures to handle the Label Request Message are
augmented by the procedures for processing of the CR-TLVs as
defined in Section 4.
- Label Request Messageを扱うProceduresはセクション4で定義されるようにCR-TLVsの処理のための手順で増大します。
Jamoussi, et al. Standards Track [Page 8] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[8ページ]RFC3212の規制ベースのLSPセットアップ
The encoding for the CR-LDP Label Request Message is as follows:
CR-自由民主党Label Request Messageのためのコード化は以下の通りです:
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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×0401)| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPID TLV(CR-自由民主党の、そして、義務的な)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-TLV(CR-自由民主党の、そして、任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 交通TLV(CR-自由民主党の、そして、任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV(CR-自由民主党の、そして、任意の)をピンで止めます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リソースClass TLV(CR-自由民主党の、そして、任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 先取りTLV(CR-自由民主党の、そして、任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3 Label Mapping Message
3.3 ラベルマッピングメッセージ
The Label Mapping Message is as defined in 3.5.7 of [1] with the following modifications:
Label Mapping Messageが以下の変更で[1]について3.5で.7を定義するようにあります:
- The Label Mapping Message MUST include a single Label-TLV.
- Label Mapping Messageは独身のLabel-TLVを含まなければなりません。
- The Label Mapping Message Procedures are limited to downstream
on demand ordered control mode.
- Label Mapping Message Proceduresは川下のオンデマンドの規則正しいコントロールモードに制限されます。
A Mapping message is transmitted by a downstream LSR to an upstream LSR under one of the following conditions:
Mappingメッセージは上流の以下の条件の1つ未満の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からマッピングを受け取りました。
Jamoussi, et al. Standards Track [Page 9] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[9ページ]RFC3212の規制ベースのLSPセットアップ
The encoding for the CR-LDP Label Mapping Message is as follows:
CR-自由民主党Label Mapping Messageのためのコード化は以下の通りです:
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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×0400)| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベルTLV| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル要求メッセージID TLV| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPID TLV(CR-自由民主党の、そして、任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 交通TLV(CR-自由民主党の、そして、任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.4 Notification Message
3.4 通知メッセージ
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.
Notification Messageがコード化がある[1]と[1]についてセクション3.4.6で定義された.1セクション3.5Status TLVで定義されるようにあります。 CR-LSPの設立はさまざまな理由で行き詰まるかもしれません。 そのようなすべての失敗が顧問状態であると考えられます、そして、それらはNotification Messageによって合図されます。
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.
通知Messagesは、合図される出来事を指定するためにStatus TLVsを運びます。 新しいステータスコードは、CR-LSPの設立とCR-TLVの処理に関連しているエラー通知に合図するためにセクション4.11で定義されます。 新しいステータスコードのすべてが、Fビットが設定されるのを必要とします。
The Notification Message MAY carry the LSPID TLV of the corresponding CR-LSP.
Notification Messageは対応する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.
各ホップにおいてこの仕様(または、[1]で)による手順がLabel Request Messageに対応してNotification Messageを発信させながら指定する何時でもときのLabel Requestを溯源するLSRに向かって通知Messagesを送らなければなりません。
Jamoussi, et al. Standards Track [Page 10] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[10ページ]RFC3212の規制ベースのLSPセットアップ
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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×0001)| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態(TLV)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 任意のパラメタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.5 Release , Withdraw, and Abort Messages
3.5がリリースする、引き下がってください、そして、メッセージを中止してください。
The Label Release , Label Withdraw, and Label Abort Request Messages are used as specified in [1]. These messages MAY also carry the LSPID TLV.
Label Release、Label Withdraw、およびLabel Abort Request Messagesは[1]で指定されるように使用されています。 また、これらのメッセージはLSPID TLVを運ぶかもしれません。
4. Protocol Specification
4. プロトコル仕様
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]で定義されたLabel Request MessageはLSPID TLVを運ばなければならなくて、このセクションで定義された任意のConstraintベースのルート設定TLVs(CR-TLVs)の1つ以上を運ぶかもしれません。 必要であるなら、後で新しいTLVsの定義で他の規制を支持できます。 この仕様では、以下のTLVsは定義されます:
- 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--先取りTLV(LSPID TLV)はTLVをピンで止めます--リソースクラスTLV--CR-LSP FEC TLVを発送します。
4.1 Explicit Route TLV (ER-TLV)
4.1 明白なルートTLV(えー、-、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で定義された1Explicit Route Hop TLVs(ER-ホップTLVs)で構成されます。
Jamoussi, et al. Standards Track [Page 11] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[11ページ]RFC3212の規制ベースの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 = 0x0800 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-Hop TLV 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-Hop TLV 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ............ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-Hop TLV n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| =0x0800をタイプしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | えー、-跳んでください、TLV1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | えー、-跳んでください、TLV2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ............ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ER-ホップTLV n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the ER-TLV
Type = 0x0800.
ER-TLV Type=0x0800の値を運んで、A14ビットの分野をタイプしてください。
Length
Specifies the length of the value field in bytes.
バイトで表現される値の分野の長さの長さのSpecifies。
ER-Hop TLVs
One or more ER-Hop TLVs defined in Section 4.2.
ER-ホップTLVs Oneかセクション4.2で定義されたより多くのER-ホップTLVs。
4.2 Explicit Route Hop TLV (ER-Hop TLV)
4.2 明白なルートホップTLV(えー、-跳んでください、TLV)
The contents of an ER-TLV are a series of variable length ER-Hop TLVs.
ER-TLVの内容は可変長ER-ホップTLVsのシリーズです。
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-ホップタイプを含むラベル要求メッセージを受け取るノードは、川下のLSRにラベル要求メッセージを進行してはいけなくて、「いいえルート」Notification Messageを返送しなければなりません。
Each ER-Hop TLV has the form:
それぞれのER-ホップ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 // | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| 内容//| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jamoussi, et al. Standards Track [Page 12] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[12ページ]RFC3212の規制ベースのLSPセットアップ
ER-Hop Type
A fourteen-bit field carrying the type of the ER-Hop contents.
Currently defined values are:
ER-ホップコンテンツのタイプを運ぶER-ホップのTypeのA14ビットの分野。 現在定義された値は以下の通りです。
Value Type
------ ------------------------
0x0801 IPv4 prefix
0x0802 IPv6 prefix
0x0803 Autonomous system number
0x0804 LSPID
値のタイプ------ ------------------------ 0×0801 IPv4接頭語0×0802IPv6接頭語0x0803AutonomousシステムNo.0x0804LSPID
Length
Specifies the length of the value field in bytes.
バイトで表現される値の分野の長さの長さのSpecifies。
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-ホップで噛み付いたLビットは1ビットの属性です。 Lビットが設定されるなら、属性の値は「ゆるいです」。 さもなければ、属性の値は「厳しいです」。 簡潔さのために、私たちは、ER-ホップ属性の値がゆるいならそれが「ゆるいER-ホップ」であると言います。 さもなければ、それは「厳しいER-ホップ」です。 さらに、私たちは、厳しいかゆるいER-ホップの抽象的な節がそれぞれ厳しいノードであるかゆるいノードであると言います。 ゆるくて厳しいノードはいつも彼らの先の抽象的なノードに比例して解釈されます。 厳しいノードとその先のノードの間の経路は厳しいノードとその先の抽象的なノードからのネットワーク・ノードだけを含まなければなりません。
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つであるノードか抽象的なノードを含むコンテンツA可変長フィールド。
4.3 Traffic Parameters TLV
4.3 交通パラメタTLV
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 Traffic Parametersについて説明します。 CR-LSPの必要な特性はTraffic Parameter値によって言い表されます。
A Traffic Parameters TLV, is used to signal the Traffic Parameter values. The Traffic Parameters are defined in the subsequent sections.
Traffic Parameters TLVはTraffic Parameter値に合図するのにおいて使用されています。 Traffic Parametersはその後のセクションで定義されます。
Jamoussi, et al. Standards Track [Page 13] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[13ページ]RFC3212の規制ベースのLSPセットアップ
The Traffic Parameters TLV contains a Flags field, a Frequency, a Weight, and the five Traffic Parameters PDR, PBS, CDR, CBS, EBS.
Traffic Parameters TLVはFlags分野、Frequency、Weight、および5Traffic Parameters 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| =0x0810をタイプしてください。| 長さ=24| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| 頻度| 予約されます。| 重さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ピークデータ信号速度(PDR)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ピーク放出量(PBS)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遂行されたデータ信号速度(CDR)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遂行された放出量(CBS)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 過剰放出量(EBS)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the Traffic
Parameters TLV Type = 0x0810.
Traffic Parameters TLV Type=0x0810の値を運んで、A14ビットの分野をタイプしてください。
Length
Specifies the length of the value field in bytes = 24.
価値の長さの長さのSpecifiesはバイトで=24をさばきます。
Flags
The Flags field is shown below:
Flags分野が以下に示される旗:
+--+--+--+--+--+--+--+--+
| Res |F6|F5|F4|F3|F2|F1|
+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+ | 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--重さに対応しています。
Jamoussi, et al. Standards Track [Page 14] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[14ページ]RFC3212の規制ベースのLSPセットアップ
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はTraffic Parameterに対応するNegotiable Flagです。 Negotiable Flag値ゼロはNotNegotiableを指示します、そして、値1はNegotiableを指示します。
Frequency
The Frequency field is coded as an 8 bit unsigned integer with
the following code points defined:
以下のコード・ポイントが定義されている状態で、Frequencyがさばく頻度は8の噛み付いている符号のない整数としてコード化されます:
0- Unspecified
1- Frequent
2- VeryFrequent
3-255 - Reserved
Reserved - Zero on transmission. Ignored on receipt.
0 1不特定の頻繁な2VeryFrequent3-255--予約されたReserved--トランスミッションのゼロ。 領収書の上で無視されます。
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.
重さのAn8はCR-LSPの重さを示す符号のない整数に噛み付きました。 有効な重さの値は、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.
交通Parameters Each Traffic Parameterは32ビットのIEEEただ一つの精度浮動小数点の番号としてコード化されます。 陽の無限の値はIEEEの単精度の浮動小数点の番号としてすべてのゼロのすべてのもの(255)の解説者、サイン、および仮数で表されます。 値のPDRとCDRが1秒あたりのユニットのバイトであります。 値のPBS、CBS、およびEBSがユニットのバイトであります。
The value of PDR MUST be greater than or equal to the value of
CDR in a correctly encoded Traffic Parameters TLV.
PDR MUSTの値はそう以上です。正しくコード化されたTraffic Parameters TLVのCDRの値。
4.3.1 Semantics
4.3.1 意味論
4.3.1.1 Frequency
4.3.1.1 頻度
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.
Frequencyは、どんな粒状にCR-LSPに割り当てられたCDRを利用可能にするかを指定します。 値のVeryFrequentは、CDRでは、最も短いパケット間より等しいか長いどんな時間間隔にわたっても測定されると有効なレートが少なくともCDRを平均するべきであることを意味します。値のFrequentは、CDRでは、少ない数の最も短いパケット回より等しいか長いどんな時間間隔にわたっても測定されると有効なレートが少なくともCDRを平均するべきであることを意味します。
The value Unspecified means that the CDR MAY be provided at any granularity.
値のUnspecifiedは、CDR MAYがどんな粒状でも提供されることを意味します。
Jamoussi, et al. Standards Track [Page 15] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[15ページ]RFC3212の規制ベースのLSPセットアップ
4.3.1.2 Peak Rate
4.3.1.2 ピークレート
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.
Peak Rateは最高率を定義します。どれがSHOULDを取引するかで、CR-LSPに送ります。 Peak Rateは資源配分の目的の役に立ちます。 MPLSドメインの中の資源配分がPeak Rate値によるなら、それはイングレスでMPLSドメインに実施されるべきです。
The Peak Rate is defined in terms of the two Traffic Parameters PDR and PBS, see section 4.3.1.5 below.
セクション4.3は、Peak Rateが2Traffic Parameters PDRとPBSに関して定義されるのを見ます。
4.3.1.3 Committed Rate
4.3.1.3 遂行されたレート
The Committed Rate defines the rate that the MPLS domain commits to be available to the CR-LSP.
Committed Rateは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.
Committed Rateは2Traffic Parameters CDRとCBSに関して定義されて、見ます。
4.3.1.4 Excess Burst Size
4.3.1.4 過剰はサイズを押し破きました。
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.
Excess Burst Sizeは交通調節の目的にMPLSドメインの縁で使用されるかもしれません。 EBS MAY、使用されて、範囲を交通が、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.
Excess Burst SizeはCommitted Rateと共に定義されて、セクション4.3を見ます。
4.3.1.5 Peak Rate Token Bucket
4.3.1.5 ピークレート象徴バケツ
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のPeak Rateは象徴レートPDRと最大の象徴バケツサイズPBSと共に象徴バケツ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秒あたり1PDR倍増加されます。 サイズ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は減少しません。
Jamoussi, et al. Standards Track [Page 16] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[16ページ]RFC3212の規制ベースのLSPセットアップ
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の実際の実現はモデル化される必要はありません。
4.3.1.6 Committed Data Rate Token Bucket
4.3.1.6 遂行されたデータ信号速度象徴バケツ
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に関して指定されます。範囲はオファードレートが遂行されたレートを超えている別の象徴バケツEに関して測定されるかもしれません。(また、バケツはレートCDRで作動します)。象徴バケツ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に)すなわち、いっぱいで、CBSと象徴カウントTc(0)=象徴がTe(0)=EBSを数えるということです。
Thereafter, the token counts Tc and Te are updated CDR times per second as follows:
その後、以下の秒にCDR回象徴カウントのTcとTeをアップデートします:
- 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はTeが、より少ない当時のEBSであるなら、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であるなら、パケットはCommitted Rateを超えていません、そして、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であるなら、パケットは、Committedレートを超えていますが、EBSを超えていません、そして、TeはBで0の最小値まで減少しますほかです。
- the packet is in excess of both the Committed Rate and the EBS
and neither Tc nor Te is decremented.
- パケットはCommitted Rateと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値が、到着パケットが決してCommitted RateかEBSのどちらか少しもを超えていないのを含意することに注意してください。 CBSかEBSのどちらかの上向きの無限の値は、それぞれの限界を超えることができないのを含意します。
The actual implementation of an LSR doesn't need to be modeled according to the above formal specification.
上記の形式仕様通りにLSRの実際の実現はモデル化される必要はありません。
Jamoussi, et al. Standards Track [Page 17] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[17ページ]RFC3212の規制ベースのLSPセットアップ
4.3.1.7 Weight
4.3.1.7 重さ
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ドメイン特有です。
4.3.2 Procedures
4.3.2 手順
4.3.2.1 Label Request Message
4.3.2.1 ラベル要求メッセージ
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の値以下である不当にコード化されたTraffic Parameters TLVを受けるなら、それはStatusコード「入手できない交通パラメタ」をそれが誤ったメッセージを受け取った上流のLSRに含むNotification Messageを送らなければなりません。
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.
Traffic ParameterがNegotiableとしてLabel Request Messageで対応するNegotiable Flagによって示されるなら、LSR MAYはTraffic Parameter値をより小さい値に取り替えます。
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).
WeightがNegotiableとしてLabel Request Messageで対応するNegotiable Flagによって示されるなら、LSRはWeight値を下側の値(最小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が可能なTraffic Parameter交渉の後にCR-LSP Traffic Parametersを支持できるなら、LSR MUSTは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が可能なTraffic Parameter交渉の後にCR-LSP Traffic Parametersを支持できないなら、LSR MUSTは「リソース入手できません、な」ステータスコードを含むNotification Messageを送ります。
4.3.2.2 Label Mapping Message
4.3.2.2 ラベルマッピングメッセージ
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の値以下である不当にコード化されたTraffic Parameters TLVを受けるなら、それはStatusコード「入手できない交通パラメタ」をそれが誤ったメッセージを受け取ったLSRに含むLabel Releaseメッセージを送らなければなりません。 さらに、LSPはステータスコード'ラベルRequest Aborted'と共にNotification Messageを上流へ送るはずです。
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 MUSTはLabel Mappingメッセージに(ことによると交渉されています)の交通ParametersとWeightを含んでいます。
The Traffic Parameters and the Weight in a Label Mapping message MUST be forwarded unchanged.
変わりがない状態でLabel MappingメッセージのTraffic ParametersとWeightを進めなければなりません。
Jamoussi, et al. Standards Track [Page 18] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[18ページ]RFC3212の規制ベースのLSPセットアップ
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.
Traffic Parametersが対応するLabel Request Messageでそれらと異なっているならLabel Mapping Messageを受けるとき、LSR SHOULDはそれがCR-LSPのために予約したリソースを調整します。
4.3.2.3 Notification Message
4.3.2.3 通知メッセージ
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のためにNotification Messageを受けて、それはSHOULDリリースです。それがCR-LSPのためにことによると控えたどんなリソース。 さらに、上流のLSRからのLabel Requestに関連しているDownstream LSRからNotification Messageを受けるとき、地方のLSR MUSTは、[1]で手順を用いることでNotificationメッセージを伝播します。 さらに、Fビットを設定しなければなりません。
4.4 Preemption TLV
4.4 先取りTLV
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).
Preemption TLVが任意のTLVであるので、LSPsは、明らかに合図された先取りなしでTLV SHOULDがデフォルトセットアップがあるLSPsとして扱われて、優位に立つのを(例えば、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はWithdraw Message上流とRelease Messageを川下に送ります。
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.
設立されて、(Label Mappingを取り戻すことのない傑出しているLabel Request)は先取りされます、先取りを開始するLSRということであることの途中にLSPがNotification Message上流とAbort Messageを川下に送るとき。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| =0x0820をタイプしてください。| 長さ=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SetPrio| HoldPrio| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the Preemption-TLV
Type = 0x0820.
Preemption-TLV Type=0x0820の値を運んで、A14ビットの分野をタイプしてください。
Length
Specifies the length of the value field in bytes = 4.
価値の長さの長さのSpecifiesはバイトで=4をさばきます。
Jamoussi, et al. Standards Track [Page 19] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[19ページ]RFC3212の規制ベースのLSPセットアップ
Reserved
Zero on transmission. Ignored on receipt.
トランスミッションでの予約されたZero。 領収書の上で無視されます。
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.
値ゼロの(0)のSetPrio A SetupPriorityは最も重要な経路に割り当てられた優先権です。 それは最優先と呼ばれます。 7(7)は最も重要でない経路への優先権です。 セットアップ優先度が高ければ高いほど、より多くの経路CR-自由民主党が、経路をセットアップするために突き当たることができます。 デフォルト値は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.
値ゼロの(0)のHoldPrio A HoldingPriorityは最も重要な経路に割り当てられた優先権です。 それは最優先と呼ばれます。 7(7)は最も重要でない経路への優先権です。 デフォルト値は4であるべきです。 把持優先度が高ければ高いほど、それはCR自由民主党が新しい経路に帯域幅をより再割当てしそうにはありません。
4.5 LSPID TLV
4.5 LSPID TLV
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はそのLSRにイングレスLSR Router ID(または、それ自身のIpv4アドレスのどれか)とLocallyのユニークな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修理と、ホップとしてER-TLVで既に確立したCR-LSPを使用する際に役に立ちます。
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で運ばれます。 この「動作インディケータ旗」は明らかにLSPがメッセージを受け取るLSRに既に存在しているなら取られるべきである行動を示します。
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です。
Jamoussi, et al. Standards Track [Page 20] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[20ページ]RFC3212の規制ベースの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 = 0x0821 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |ActFlg | Local CR-LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress LSR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| =0x0821をタイプしてください。| 長さ=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|ActFlg| 地方のCR-LSP ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | イングレスLSRルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the LSPID-TLV
Type = 0x0821.
LSPID-TLV Type=0x0821の値を運んで、A14ビットの分野をタイプしてください。
Length
Specifies the length of the value field in bytes = 4.
価値の長さの長さのSpecifiesはバイトで=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ビットの分野。 1セットのインディケータコード・ポイントは以下の通り提案されます:
0000: indicates initial LSP setup
0001: indicates modify LSP
0000: 初期のLSPが0001をセットアップするのを示します: LSPを変更するように示します。
Reserved
Zero on transmission. Ignored on receipt.
トランスミッションでの予約されたZero。 領収書の上で無視されます。
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 Local LSP IDはCR-LSPを溯源するIngress LSRの中で局所的にユニークなCR-LSPに関する識別子です。
Ingress LSR Router ID
An LSR may use any of its own IPv4 addresses in this field.
イングレスLSR Router ID An LSRはこの分野でそれ自身のIPv4アドレスのいずれも使用するかもしれません。
4.6 Resource Class (Color) TLV
4.6 リソースのクラス(色)TLV
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]で定義されるResource Classは、どのリンクがこのCR-LSPが許容できるかを指定するのに使用されます。 この情報は、ネットワークのトポロジーが剪定されるのを許容します。
Jamoussi, et al. Standards Track [Page 21] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[21ページ]RFC3212の規制ベースの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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| =0x0822をタイプしてください。| 長さ=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RsCls| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the ResCls-TLV
Type = 0x0822.
ResCls-TLV Type=0x0822の値を運んで、A14ビットの分野をタイプしてください。
Length
Specifies the length of the value field in bytes = 4.
価値の長さの長さのSpecifiesはバイトで=4をさばきます。
RsCls
The Resource Class bit mask indicating which of the 32
"administrative groups" or "colors" of links the CR-LSP can
traverse.
RsCls Resource ClassはCR-LSPが32「管理グループ」か「色」のリンクのどれを横断できるかを示すマスクに噛み付きました。
4.7 ER-Hop semantics
4.7 ER-ホップ意味論
4.7.1. ER-Hop 1: The IPv4 prefix
4.7.1. えー、-跳んでください、1: IPv4接頭語
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-ホップによって表された抽象的なノードはノードのセットです。(それは、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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| =0x0801をタイプしてください。| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| 予約されます。| PreLen| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address(4バイト)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the ER-Hop 1, IPv4
Address, Type = 0x0801
ER-ホップの値を運んで、A14ビットの分野をタイプしてください、1、IPv4 Address、Type=0×0801
Length
Specifies the length of the value field in bytes = 8.
価値の長さの長さのSpecifiesはバイトで=8をさばきます。
L Bit
Set to indicate Loose hop.
Cleared to indicate a strict hop.
Lは、Looseが跳ぶのを示すためにSetに噛み付きました。 厳しいホップを示すために、クリアされます。
Jamoussi, et al. Standards Track [Page 22] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[22ページ]RFC3212の規制ベースのLSPセットアップ
Reserved
Zero on transmission. Ignored on receipt.
トランスミッションでの予約されたZero。 領収書の上で無視されます。
PreLen
Prefix Length 1-32
PreLen接頭語の長さ1-32
IP Address
A four-byte field indicating the IP Address.
IP Addressを示すIPのAddressのA4バイトの分野。
4.7.2. ER-Hop 2: The IPv6 address
4.7.2. えー、-跳んでください、2: IPv6アドレス
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| 0x0802 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Reserved | PreLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| 0×0802| 長さ=20| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| 予約されます。| PreLen| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPV6アドレス(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the ER-Hop 2, IPv6
Address, Type = 0x0802
ER-ホップ2、IPv6 Address、Type=0×0802の値を運んで、A14ビットの分野をタイプしてください。
Length
Specifies the length of the value field in bytes = 20.
価値の長さの長さのSpecifiesはバイトで=20をさばきます。
L Bit
Set to indicate Loose hop.
Cleared to indicate a strict hop.
Lは、Looseが跳ぶのを示すためにSetに噛み付きました。 厳しいホップを示すために、クリアされます。
Reserved
Zero on transmission. Ignored on receipt.
トランスミッションでの予約されたZero。 領収書の上で無視されます。
PreLen
Prefix Length 1-128
PreLen接頭語の長さ1-128
IPv6 address
A 128-bit unicast host address.
IPv6はA128ビットのユニキャストホスト・アドレスを記述します。
Jamoussi, et al. Standards Track [Page 23] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[23ページ]RFC3212の規制ベースのLSPセットアップ
4.7.3. ER-Hop 3: The autonomous system number
4.7.3. えー、-跳んでください、3: 自律システム番号
The abstract node represented by this ER-Hop is the set of nodes belonging to the autonomous system.
このER-ホップによって表された抽象的なノードは自律システムに属すノードのセットです。
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 0×0803| 長さ=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| 予約されます。| 数として| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the ER-Hop 3, AS
Number, Type = 0x0803
ER-ホップ3、AS Number、Type=0×0803の値を運んで、A14ビットの分野をタイプしてください。
Length
Specifies the length of the value field in bytes = 4.
価値の長さの長さのSpecifiesはバイトで=4をさばきます。
L Bit
Set to indicate Loose hop.
Cleared to indicate a strict hop.
Lは、Looseが跳ぶのを示すためにSetに噛み付きました。 厳しいホップを示すために、クリアされます。
Reserved
Zero on transmission. Ignored on receipt.
トランスミッションでの予約されたZero。 領収書の上で無視されます。
AS Number
Autonomous System number
AS Number Autonomous System番号
4.7.4. ER-Hop 4: LSPID
4.7.4. えー、-跳んでください、4: LSPID
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-ホップは、既に確立したCR-LSPの中で新しいCR-LSPsを積み重ねると考慮します。 また、それは、既存の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
LSPID HopがLSRがER-TLVホップであるより最後のER-ホップであるなら、現在このLSPIDと共に存在するCR-LSPに入って来るLabel RequestのCR-LSPを継いでください。 例えば、これは局部的修繕に使用されるLabel Requestが緩く指定されたCR-LSPセグメントの後に次のER-ホップに到着するポイントで役に立ちます。 このシナリオにおけるLSPID Hopの使用はER-ホップスが州の情報の一部として緩く指定されたCR-LSPセグメントのどちらの(上流か川下)の終わりにもある各LSRに全体の残っているER-TLVをおく必要性を排除します。 これが事実のためである、それ
Jamoussi, et al. Standards Track [Page 24] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[24ページ]RFC3212の規制ベースのLSPセットアップ
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.
上流のLSRは、単に次のER-ホップと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 HopがER-TLVで最後のホップでないなら、LSRは、指定されたCR-LSPの出口であるLSRと共に確立された自由民主党のセッションを使用することでLSP-ID Hopを取り外して、Label Requestメッセージで残っているER-TLVを進めなければなりません。 そのLSRはCR-LSP Label Request Messageの処理を続けるでしょう。 結果はトンネルを堀られたか、積み重ねられた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セグメントにトンネルを堀って、ことによると既存のCR-LSPを使用して、自由民主党のセッションはトンネルエンドポイントの間の必要な[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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 0×0804| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| 予約されます。| 地方のLSPID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | イングレスLSRルータID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the ER-Hop 4, LSPID,
Type = 0x0804
ER-ホップ4、LSPID、Type=0×0804の値を運んで、A14ビットの分野をタイプしてください。
Length
Specifies the length of the value field in bytes = 8.
価値の長さの長さのSpecifiesはバイトで=8をさばきます。
L Bit
Set to indicate Loose hop.
Cleared to indicate a strict hop.
Lは、Looseが跳ぶのを示すためにSetに噛み付きました。 厳しいホップを示すために、クリアされます。
Reserved
Zero on transmission. Ignored on receipt.
トランスミッションでの予約されたZero。 領収書の上で無視されます。
Local LSPID
A 2 byte field indicating the LSPID which is unique with
reference to its Ingress LSR.
Ingress LSRに関してユニークなLSPIDを示す地方のLSPID A2バイト分野。
Ingress LSR Router ID
An LSR may use any of its own IPv4 addresses in this field.
イングレスLSR Router ID An LSRはこの分野でそれ自身のIPv4アドレスのいずれも使用するかもしれません。
Jamoussi, et al. Standards Track [Page 25] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[25ページ]RFC3212の規制ベースのLSPセットアップ
4.8. Processing of the Explicit Route TLV
4.8. 明白なルートTLVの処理
4.8.1. Selection of the next hop
4.8.1. 次のホップの選択
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を含むLabel Request Messageは次のホップをこの経路に決定しなければなりません。 この次のホップの選択は1セットの可能な代替手段から選択にかかわるかもしれません。 このセットから選定するためのメカニズムは、実現に依存していて、この仕様の範囲の外にあります。 特定の経路の品揃えがこの仕様の範囲の外にもありますが、各ノードが無輪の経路を決定するベストエフォート型試みをすると思われます。 そのような最善の努力がローカルの方針でくつがえされるかもしれないことに注意してください。
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. Label Request Messageを受けるノードは最初に、最初のER-ホップを評価しなければなりません。 Lビットが最初のER-ホップに設定されないで、またノードが最初のER-ホップによって説明された、抽象的なノードの一部でないなら、メッセージを間違って受け取って、aを返すべきである、「悪いイニシャル、えー、-跳んでください、誤り、」 状態。 Lビットが設定されて、ローカルのノードが最初のER-ホップによって説明された抽象的なノードの一部でないなら、ノードは経路に沿って最初のER-ホップによって説明された抽象的なノードにはある次のホップを選択します。 また、最初のER-ホップが全くなければ、メッセージも間違っています、そして、システムは上流へ送られたNotification Messageを使用することで「悪い明白なルート設定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. 第2ER-ホップが全くなければ、これは明白なルートの端を示します。 明白なルートTLVはLabel Request Messageから取り外されるべきです。 このノードはLSPの端であるかもしれません。 処理はセクション4.8.2を続行します。そこでは、新しい明白なルートTLVがLabel Request Messageに加えられるかもしれません。
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. また、ノードが第2ER-ホップによって説明された抽象的なノードの一部であるなら、ノードは、最初のER-ホップを削除して、ステップ2で処理し続けています、上です。 これが次の繰り返しの最初のER-ホップに第2ER-ホップを作りかえることに注意してください。
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. ノードは、第2ER-ホップによって説明された抽象的なノードに隣接してそれが位相的にそうかどうか決定します。 そうだとすれば、ノードは抽象的なノードの器官である次の特定のホップを選択します。 ノードは、次に、最初のER-ホップを削除して、セクション4.8.2で処理し続けています。
Jamoussi, et al. Standards Track [Page 26] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[26ページ]RFC3212の規制ベースのLSPセットアップ
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. 次に、ノードは経路に沿って第2ER-ホップの抽象的な節にはある最初のER-ホップの抽象的な節の中で次のホップを選択します。 何かそのような経路が存在していないなら、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. Ifの第2ER-ホップは厳しいER-ホップです、そして、次に、誤りがあります、そして、ノードは「悪い厳しいノード誤り」状態を返すはずです。
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、さもなければ、第2ER-ホップがゆるいER-ホップであるなら、ノードは経路に沿って次の抽象的なノードにはあるいくつかの次ホップを選択します。 経路が全く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-ホップを次のホップを含む抽象的なノードを指示するどんなER-ホップにも取り替えます。 これが、次のホップで明白なルートを受け取るとき、それを受け入れるくらい必要です。
7. Progress the Label Request Message to the next hop.
7. 次のホップにLabel Request Messageを進行してください。
4.8.2. Adding ER-Hops to the explicit route TLV
4.8.2. 明白なルートTLVにER-ホップスを加えます。
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.
明白なルートTLVがセクション4.8.1におけるアルゴリズムを実行する一部として取り外されるなら、ノードは新しい明白なルート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-ホップのための抽象的なノードの器官であるなら、一連のER-ホップが、最初のER-ホップの前に挿入されるか、または最初のER-ホップを取り替えるかもしれません。 このシリーズにおける各ER-ホップは現在の抽象的なノードの部分集合である抽象的なノードを指示しなければなりません。
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-ホップは最初のER-ホップがゆるいER-ホップであるなら、最初のER-ホップの前に挿入されるかもしれません。
Jamoussi, et al. Standards Track [Page 27] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[27ページ]RFC3212の規制ベースのLSPセットアップ
4.9 Route Pinning TLV
TLVをピンで止める4.9ルート
Section 2.4 describes the use of route pinning. The encoding of the Route Pinning TLV is as follows:
セクション2.4はルートのピンで止めることの使用について説明します。 Route Pinning 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| =0x0823をタイプしてください。| 長さ=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the Pinning-TLV
Type = 0x0823
Pinning-TLV Type=0x0823の値を運んで、A14ビットの分野をタイプしてください。
Length
Specifies the length of the value field in bytes = 4.
価値の長さの長さのSpecifiesはバイトで=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
1にPが噛み付いたPビットが、ルートのピンで止めることが要求されているのを示すように設定されます。 0にPビットが、ルートのピンで止めることが要求されていないのを示すように設定されます。
Reserved
Zero on transmission. Ignored on receipt.
トランスミッションでの予約されたZero。 領収書の上で無視されます。
4.10 CR-LSP FEC Element
4.10 CR-LSP FEC要素
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.
新しいFEC要素は、CR- LSPsを支持するためにこの仕様で紹介されます。 ElementタイプCR-LSP(0×04)のFECを含むFEC TLVはCR-LSP FEC TLVです。 CR-LSP FEC ElementはCR-LSPsのMessagesだけで使用されるべき不透明な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.
Label Request Messageにただ一つのFEC要素を含まなければなりません。 FEC Element SHOULD、CR-LSP FEC Elementになってください。 しかしながら、[1]で定義された他のFEC要素(=0×01、0×02、0x03をタイプする)の1つが、あるアプリケーションのためのCR-LSP FEC Elementの代わりにCR-自由民主党メッセージにあるかもしれません。 ElementタイプCR-LSP(0×04)のFECを含むFEC TLVはCR-LSP FEC TLVです。
FEC Element Type Value
Type name
FEC Element Type Value Type名
CR-LSP 0x04 No value; i.e., 0 value octets;
CR-LSP0x04いいえ価値。 すなわち、0は八重奏を評価します。
Jamoussi, et al. Standards Track [Page 28] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[28ページ]RFC3212の規制ベースのLSPセットアップ
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) | +-+-+-+-+-+-+-+-+
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| =0x0100をタイプしてください。| 長さ=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CR-LSP(4)| +-+-+-+-+-+-+-+-+
Type
A fourteen-bit field carrying the value of the FEC TLV
Type = 0x0100
FEC TLV Type=0x0100の値を運んで、A14ビットの分野をタイプしてください。
Length
Specifies the length of the value field in bytes = 1.
価値の長さの長さのSpecifiesはバイトで=1をさばきます。
CR-LSP FEC Element Type
CR-LSP FEC要素型
0x04
0×04
5. IANA Considerations
5. IANA問題
CR-LDP defines the following name spaces, which require management:
CR-自由民主党は以下の名前空間を定義します:(空間は管理を必要とします)。
- TLV types.
- FEC types.
- Status codes.
- TLVはタイプします。 - FECはタイプします。 - ステータスコード。
The following sections provide guidelines for managing these name spaces.
以下のセクションはこれらの名前空間を管理するためのガイドラインを提供します。
5.1 TLV Type Name Space
5.1 TLV型名スペース
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.
RFC3036[1]はスペースというLDP TLV名を定義します。 このドキュメントは範囲0x0800のCR-自由民主党に関連しているTLVsのためにそのTLVスペースからRFC3036の範囲をさらに分筆します--0x08FF。
Following the policies outlined in [IANA], TLV types in this range are allocated through an IETF Consensus action.
[IANA]に概説された方針に従って、IETF Consensus動作でこの範囲のTLVタイプを割り当てます。
Jamoussi, et al. Standards Track [Page 29] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[29ページ]RFC3212の規制ベースのLSPセットアップ
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
TLVはタイプします。-------------------------------------- ---------- 明白なルートTLV0x0800Ipv4が前に置く、えー、-跳んでください、TLV0x0801Ipv6が前に置く、えー、-跳んでください、TLV0x0802自律システム番号、えー、-跳んでください、TLV0x0803LSP-ID、えー、-跳んでください、TLV0x0823をピンで止めるTLV0x0810先取りTLV0x0820LSPID TLV0x0821リソースクラスTLV0x0822が発送するTLV0x0804交通パラメタ
5.2 FEC Type Name Space
5.2 FEC型名スペース
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]:
RFC3036はスペースというFEC Type名を定義します。 さらに、RFC3036には、割り当てられた値が0×00から0×03にあります。 FECタイプ0〜127はIETFコンセンサス動作で課題に手があいています。 この仕様は[IANA]に概説された方針を使用して、以下の追加課題をします:
FEC Element Type
-------------------------------------- ----------
CR-LSP FEC Element 0x04
FEC要素型-------------------------------------- ---------- CR-LSP FEC要素0x04
5.3 Status Code Space
5.3 ステータスコードスペース
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.
RFC3036はスペースというStatus Code名を定義します。 このドキュメントは範囲0x04000000のCR-自由民主党に関連しているTLVsのためにそのTLVスペースからRFC3036の範囲をさらに分筆します--0x040000FF。
Following the policies outlined in [IANA], TLV types in this range are allocated through an IETF Consensus action.
[IANA]に概説された方針に従って、IETF Consensus動作でこの範囲のTLVタイプを割り当てます。
Jamoussi, et al. Standards Track [Page 30] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[30ページ]RFC3212の規制ベースのLSPセットアップ
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
悪い明白なルート設定TLV誤り0x04000001の悪い厳しいノード誤り0x04000002の悪いゆるいノード誤り0x04000003の悪いイニシャル、えー、-跳んでください、0×04000005の誤り0x04000004のリソースの入手できない交通パラメタ入手できない0x04000006LSPが0×04000007を先取りした、変更、要求は0×04000008を支持しませんでした。
6. Security Considerations
6. セキュリティ問題
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-自由民主党は自由民主党のセッション接続の流れの中にだまされたTCPセグメントの導入から守るために[1]のセクション4.0で説明された同じセキュリティー対策を引き継ぎます。
7. Acknowledgments
7. 承認
The messages used to signal the CR-LSP setup are based on the work done by the LDP [1] design team.
CR-LSPセットアップに合図するのに使用されるメッセージは自由民主党[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.
オサマAboul-Magd、ピーター・Ashwood-スミス、ジョエル・アルペルン、Fiffi Hellstrand、ケネスSundell、およびパシ・バーナネン。
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.
また、作者はケン・ヘイワード、グレッグ・ライト、Geethaブラウン、ブライアン・ウィリアムズ、ポールBeaubien、マシューYuen、リーアム・ケーシー、Ankurアナンド、およびエードリアン・ファレルの慎重なレビューとコメントを承諾したがっています。
8. Intellectual Property Consideration
8. 知的所有権の考慮
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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
Jamoussi, et al. Standards Track [Page 31] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[31ページ]RFC3212の規制ベースのLSPセットアップ
9. References
9. 参照
[1] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B.
Thomas, "Label Distribution Protocol Specification", RFC 3036,
January 2001.
[1] アンデションとL.とDoolanとP.とフェルドマンとN.とFredetteとA.とB.トーマス、「ラベル分配プロトコル仕様」、RFC3036、2001年1月。
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[2] ローゼンとE.とViswanathanとA.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、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.、マルコムとJ.とAgogbuaとJ.とオデルとM.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(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] グリーソン、B.、リン、A.、Heinanen、アーミテージ、G.、およびA.Malis、「IPのための枠組みは仮想私設網を基礎づけました」、RFC2764、2000年2月。
[5] Ash, J., Girish, M., Gray, E., Jamoussi, B. and G. Wright,
"Applicability Statement for CR-LDP", RFC 3213, January 2002.
[5] 灰とJ.とGirishとM.とグレーとE.とJamoussiとB.とG.ライト、「CR-自由民主党のための適用性証明」、RFC3213、2002年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] Boscher, C., Cheval, P., Wu, L. and E. Gray, "LDP State Machine",
RFC 3215, January 2002.
[7]BoscherとC.とシェヴァルとP.とウーとL.とE.グレー、「自由民主党州のマシン」、RFC3215、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] 灰とJ.とリーとY.、Ashwood-スミスとP.とJamoussiとB.とFedykとD.とSkaleckiとD.とL.李、「CR-自由民主党を使用するLSP変更」RFC3214(2002年1月)。
Jamoussi, et al. Standards Track [Page 32] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[32ページ]RFC3212の規制ベースのLSPセットアップ
Appendix A: CR-LSP Establishment Examples
付録A: CR-LSP設立の例
A.1 Strict Explicit Route Example
A.1の厳しい明白なルートの例
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縁のLSRsと2コアLSRsは以下の通りでの4ノードネットワークです:
abc LSR1------LSR2------LSR3------LSR4
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で説明されるようにLabel Request Messageを発生させて、それを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:
3ER-ホップTLVs<a、bのベクトルに、c>はER-TLVを構成します。 タイプ0x0801(IPv4接頭語)にはこの例で使用されるERホップTLVsが32の接頭語の長さと共にあります。 したがって、それぞれのER-ホップTLVはノードのグループと対照的に特定のノードを特定します。 LSR2では、この.1通のセクション4.8ドキュメントあたりの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は抽象的なノードの一部が最初のホップ<による>について説明したということです。 したがって、第一歩はテストに合格します。 ステップ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-ホップ<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-ホップ<b>によって位相的に説明されることを決定します。 LSR2は抽象的なノードである次のホップ(LSR3)を選択します。 LSR2はER-TLVから最初のER-ホップ<a>を削除します。(ER-TLVは現在、<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-ホップ<b>によって説明された抽象的なノードの器官ではありません。
Finally, the first ER-Hop <b> is a strict hop.
最終的に、最初のER-ホップ<b>は厳しいホップです。
Jamoussi, et al. Standards Track [Page 33] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[33ページ]RFC3212の規制ベースのLSPセットアップ
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-ホップスの挿入をもたらしません。 次のホップの選択は既にしているのが、セクション4.8.1のステップ4であるということです、そして、ER-TLVの処理はLSR2に終了しています。 この場合、ER-TLV<bを含むLabel Request Messageであり、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>.
LSR3では、<b、c>、および出発している入って来るER-TLV=ER-TLVが<c>であるのを除いて、ER-TLVへの同様の処理は行われます。
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. 第2ER-ホップが全くなくて、これはCR- LSPの端を示します。 ER-TLVはLabel Request Messageから取り外されます。 処理はセクション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-ホップスの挿入をもたらしません。 これは、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の出口の端です、そして、上流のマッピングは要求されています)。 したがって、Label Mapping Messageを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からマッピングを受け取りました)。 したがって、Label Mapping Messageを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では、LSR3への同様の処理は行われます、そして、LSR1はLabel Mapping Messageに送り返されます。(LSR1は終わりから終わりへのCR-LSPセットアップを終了します)。
A.2 Node Groups and Specific Nodes Example
A.2ノードグループと特定のノードの例
A request at ingress LSR to setup a CR-LSP might originate from a management system or an application, the details are implementation specific.
CR-LSPをセットアップするというイングレスLSRでの要求はマネージメントシステムかアプリケーションから発するかもしれなくて、詳細は実現特有です。
Jamoussi, et al. Standards Track [Page 34] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[34ページ]RFC3212の規制ベースの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.
イングレスLSRは、明白なルートを計算して、Label Request Messageを作成するのにルーティングデータベースからのマネージメントシステムかアプリケーションで提供された情報とことによるとまた、情報を使用します。
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.
Label要求メッセージは他の必要事項と共に明らかに発送された経路を定義するER-TLVを運びます。 私たちの例では、ER-ホップTLVのホップのリストはノードのグループを代表する抽象的なノード、特定のノードを表す抽象的なノード、ノードのグループを代表する別の抽象的なノード、および特定の出口ポイントを表す抽象的なノードを含むべきです。
In--{Group 1}--{Specific A}--{Group 2}--{Specific Out: B}
The ER-TLV contains four ER-Hop TLVs:
--グループ1--特定のA--グループ2--特定のOut: Bでは、ER-TLVは4ER-ホップTLVsを含んでいます:
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-ホップTLV。
2. An ER-Hop TLV that indicates the specific node (Node A).
2. 特定のノード(ノードA)を示すER-ホップ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番目の抽象的なノードに、有効なLSRsのグループを指定するER-ホップTLV。
4. An ER-Hop TLV that indicates the specific egress point for the
CR-LSP (Node B).
4. CR-LSP(ノードB)のために特定の出口ポイントを示すER-ホップTLV。
All the ER-Hop TLVs are strictly routed nodes.
すべてのER-ホップTLVsは厳密に発送されたノードです。
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. イングレスノードはノードのグループが最初ERのホップTLVで示したメンバーであるノードにLabel Request Messageを送ります、特定のノード(A)のための正常なルーティングに従って。
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-ホップ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-ホップTLVsを完全に保って、最初のER-ホップTLV(グループ1)で示されたグループの一部である別のノードにLabel Request Messageを送ります、特定のノード(A)のための正常なルーティングに従って。
Jamoussi, et al. Standards Track [Page 35] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[35ページ]RFC3212の規制ベースのLSPセットアップ
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-ホップTLVで示されたグループの一部としてのそれ自体と、それが第2ER-ホップ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-ホップTLVsを取り外して、特定のノード(A)にLabel Request Messageを送ります。
6. The specific node (A) recognizes itself in the first ER-Hop
TLV. Removes the specific ER-Hop TLV.
6. 特定のノード(A)は最初のER-ホップTLVでそれ自体を認識します。 特定のER-ホップ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-ホップTLVで示されたグループ(グループ2)のメンバーであるノードにLabel Request Messageを送ります。
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-ホップTLVで特定の出口ノード(B)が次のホップの1つであることが換金されるのを示したので、メッセージを受け取るノードはそれ自体を特定します。
9. It sends a Label Request Message to the specific egress node
(B).
9. それは特定の出口ノード(B)にLabel Request Messageを送ります。
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のためにそれ自体が出口であると認めて、Label Mapping Messageを返して、それはLabel Request Messageと同じ経路を逆方向に横断するでしょう。
Appendix B. QoS Service Examples
付録B.QoSサービスの例
B.1 Service Examples
B.1サービスの例
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を導入しました、ノードで実行された資源予約規則と共に。
Jamoussi, et al. Standards Track [Page 36] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[36ページ]RFC3212の規制ベースのLSPセットアップ
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
DS S S=PDRはPBS0の頻繁な低下>PDRと等しいです。
TS S S S S 0 Unspecified drop>PDR,PBS
mark>CDR,CBS
S S S0不特定の低下>PDR、t S PBSは、>がCDR、CBSであるとマークします。
BE inf inf inf inf 0 Unspecified -
inf inf inf inf0Unspecifiedになってください、-
FRS S S CIR ~B_C ~B_E Unspecified drop>PDR,PBS
mark>CDR,CBS,EBS
FRS S S CIR~B_C~B_E不特定の低下>PDR、PBSマーク>CDR、CBS、EBS
ATM-CBR PCR CDVT =PCR =CDVT 0 VeryFrequent drop>PCR
気圧-CBR PCR CDVT =PCR =CDVT0VeryFrequentは>PCRを落とします。
ATM-VBR.3(rt) PCR CDVT SCR MBS 0 Frequent drop>PCR
mark>SCR,MBS
頻繁な.3(rt)気圧-VBR PCR CDVT SCR mb0の低下>PCRマーク>SCR、mb
ATM-VBR.3(nrt) PCR CDVT SCR MBS 0 Unspecified drop>PCR
mark>SCR,MBS
不特定の.3(nrt)気圧-VBR PCR CDVT SCR mb0の低下>PCRマーク>SCR、mb
ATM-UBR PCR CDVT - - 0 Unspecified drop>PCR
気圧-UBR PCR CDVT----0の不特定の低下>PCR
ATM-GFR.1 PCR CDVT MCR MBS 0 Unspecified drop>PCR
.1気圧-GFR PCR CDVT MCR mb0の不特定の低下>PCR
ATM-GFR.2 PCR CDVT MCR MBS 0 Unspecified drop>PCR
mark>MCR,MFS
不特定の.2気圧-GFR PCR CDVT MCR mb0の低下>PCRマーク>MCR、mf
int-serv-CL p m r b 0 Frequent drop>p
drop>r,b
int-serv-CL p m r b0Frequent低下>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にもかかわらず、データグラムには渡すという低い確率があるだろうより高いレートで送るかもしれません。
Jamoussi, et al. Standards Track [Page 37] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[37ページ]RFC3212の規制ベースのLSPセットアップ
The BE is the best effort service and it implies that there are no expected service guarantees from the network.
ベストエフォート型がサービスであり、ネットワークからのどんな期待しているサービス保証もないのを含意するということになってください。
B.2 Establishing CR-LSP Supporting Real-Time Applications
リアルタイムのアプリケーションを支持するCR-LSPを設立するB.2
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を設立する必要があります。 Delay敏感な(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サービスの輸送の特性は、Frequent頻度がサービスのリアルタイムの遅れ要件を反映するよう要求されているのを必要とします。
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を設立します。 各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.
新しいパラメタ値はLabel Mapping Messageでecho backです。 LSRsは、新しい交通パラメタ値に基づく彼らの資源予約を再調整する必要があるかもしれません。
B.3 Establishing CR-LSP Supporting Delay Insensitive Applications
遅れの神経の鈍いアプリケーションを支持するCR-LSPを設立するB.3
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のための値を割り当てます。 交通パラメタは交渉を受けることがあるなら、交渉旗が設定されます。 サービスが定義上遅れ神経が鈍いので、Unspecified頻度が、サービス頻度が問題でないことを示すように合図されます。
Jamoussi, et al. Standards Track [Page 38] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[38ページ]RFC3212の規制ベースのLSPセットアップ
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サービスのために、縁の規則は、CDRとCBSを超えているすべてのパケットのために先行値を捨てるように高く示すためにマークするのを含むかもしれません。 また、縁の規則は、どちらも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は入場が規則を制御して、交通パラメタを交渉する走行に予想されます。 新しいパラメタ値はLabel Mapping Messageでecho backです。 LSRsは、新しい交通パラメタ値に基づく彼らのリソースを再調整する必要があるかもしれません。
10. Author's Addresses
10. 作者のアドレス
Loa Andersson Utfors Bredband AB Rasundavagen 12 169 29 Solna Phone: +46 8 5270 50 38 EMail: loa.andersson@utfors.se
LoaアンデションUtfors Bredband AB Rasundavagen12 169 29ソールナ電話: +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
1194のNorthマチルダAvenue、サニーベル、カリフォルニア 94089が電話をするロスCallon杜松ネットワーク: 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
Dantu Netrake社3000の技術ドライブ、#100プラノテキサス、75024電話に激突してください: 1111年の214 291メール: 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
ポールDoolan渚にてコンサルティングCorp34工場池の円のミルフォードMA 01757は617 513 852メールに電話をします: pdoolan@acm.org
Jamoussi, et al. Standards Track [Page 39] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[39ページ]RFC3212の規制ベースのLSPセットアップ
Nancy Feldman IBM Research 30 Saw Mill River Road Hawthorne, NY 10532 Phone: 914-784-3254 EMail: Nkf@us.ibm.com
ナンシーフェルドマンIBM Research30は工場川のRoadホーソーンを見て、ニューヨーク 10532は以下に電話をします。 914-784-3254 メールしてください: Nkf@us.ibm.com
Andre Fredette ANF Consulting 62 Duck Pond Dr. Groton, MA 01450 EMail: afredette@charter.net
グロトン博士、アンドレFredette ANF Consulting62アヒルPond MA 01450はメールされます: afredette@charter.net
Eric Gray 600 Federal Drive Andover, MA 01810 Phone: (978) 689-1610 EMail: eric.gray@sandburst.com
アンドーバー、エリックGray600の連邦政府のDrive MA 01810は以下に電話をします。 (978) 689-1610 メールしてください: eric.gray@sandburst.com
Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland EMail: jh@song.fi
ユハHeinanen SongはInc.Hallituskatu16 33200タンペレ(フィンランド)メールをネットワークでつなぎます: jh@song.fi
Bilel Jamoussi Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA Phone: +1 978 288-4506 Mail: Jamoussi@nortelnetworks.com
技術公園Drive MA01821ビルリカ(米国)が電話をするBilel Jamoussiノーテルネットワーク600: +1 978 288-4506 以下を郵送してください。 Jamoussi@nortelnetworks.com
Timothy E. Kilty Island Consulting Phone: (978) 462 7091 EMail: tim-kilty@mediaone.net
ティモシーE.Kilty島のコンサルティング電話: (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
Parkwayサンノゼ、活発なネットワーク2730Orchardカリフォルニア 95134が電話をするアンドリューG.Malis: +1 7223年の408 383メール: Andy.Malis@vivacenetworks.com
Jamoussi, et al. Standards Track [Page 40] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[40ページ]RFC3212の規制ベースのLSPセットアップ
Muckai K Girish Atoga Systems 49026 Milmont Drive Fremont, CA 94538 EMail: muckai@atoga.com
Muckai K Girish Atogaシステム49026Milmont Driveフレモント、カリフォルニア 94538はメールされます: muckai@atoga.com
Tom Worster Phone: 617 247 2624 EMail: fsb@thefsb.org
トムオースターPhone: 2624年の617 247メール: fsb@thefsb.org
Liwen Wu Cisco Systems 250 Apollo Drive Chelmsford, MA. 01824 Phone: 978-244-3087 EMail: liwwu@cisco.com
Liwenウーシスコシステムズ250アポロDriveチェルムズフォード(MA)。 01824は以下に電話をします。 978-244-3087 メールしてください: liwwu@cisco.com
Jamoussi, et al. Standards Track [Page 41] RFC 3212 Constraint-Based LSP Setup using LDP January 2002
Jamoussi、他 2002年1月に自由民主党を使用する標準化過程[41ページ]RFC3212の規制ベースのLSPセットアップ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Jamoussi, et al. Standards Track [Page 42]
Jamoussi、他 標準化過程[42ページ]
一覧
スポンサーリンク
