[要約] RFC 3270は、異なるサービスのマルチプロトコルラベルスイッチング（MPLS）のサポートに関する規格です。このRFCの目的は、MPLSを使用して異なるサービス品質を提供するためのガイドラインを提供することです。
Network Working Group F. Le Faucheur, Editor
Request for Comments: 3270 L. Wu
Category: Standards Track B. Davie
Cisco Systems
S. Davari
PMC-Sierra Inc.
P. Vaananen
Nokia
R. Krishnan
Axiowave Networks
P. Cheval
Alcatel
J. Heinanen
Song Networks
May 2002
Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
マルチプロトコルラベルスイッチング（MPLS）差別化されたサービスのサポート
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks.
このドキュメントでは、マルチプロトコルラベルスイッチング（MPLS）ネットワークを介した差別化されたサービス（DIFF-Serv）のサポートのための柔軟なソリューションを定義しています。
This solution allows the MPLS network administrator to select how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic Engineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs.
このソリューションにより、MPLSネットワーク管理者は、Diff-Servの動作集合体（BAS）がラベルスイッチ付きパス（LSP）にマッピングされる方法を選択できるため、特定の範囲内、トラフィックエンジニアリング、保護目標に最適に対応できます。通信網。たとえば、このソリューションにより、ネットワーク管理者は、異なるBASのセットを同じLSPにマッピングするか、個別のLSPにマッピングするかどうかを決定できます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 EXP-Inferred-PSC LSPs (E-LSP) . . . . . . . . . . . . . . . . . 6
1.3 Label-Only-Inferred-PSC LSPs (L-LSP). . . . . . . . . . . . . . 7
1.4 Overall Operations. . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Relationship between Label and FEC. . . . . . . . . . . . . . . 8
1.6 Bandwidth Reservation for E-LSPs and L-LSPs . . . . . . . . . . 8
2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models . 9
2.1 Label Forwarding Model for Diff-Serv LSRs . . . . . . . . . . . 9
2.2 Incoming PHB Determination. . . . . . . . . . . . . . . . . . .10
2.3 Outgoing PHB Determination With Optional Traffic Conditioning .11
2.4 Label Forwarding. . . . . . . . . . . . . . . . . . . . . . . .11
2.5 Encoding Diff-Serv Information Into Encapsulation Layer . . . .13
2.6 Diff-Serv Tunneling Models over MPLS. . . . . . . . . . . . . .13
3. Detailed Operations of E-LSPs. . . . . . . . . . . . . . . . . .22
3.1 E-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .22
3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP . .23
3.3 Incoming PHB Determination On Incoming E-LSP. . . . . . . . . .23
3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
E-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
3.5 Encoding Diff-Serv information into Encapsulation Layer On
Outgoing E-LSP. . . . . . . . . . . . . . . . . . . . . . . . .26
3.6 E-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .27
4. Detailed Operation of L-LSPs. . . . . . . . . . . . . . . . . .28
4.1 L-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .28
4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP . .28
4.3 Incoming PHB Determination On Incoming L-LSP. . . . . . . . . .30
4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
L-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
4.5 Encoding Diff-Serv Information into Encapsulation Layer on
Outgoing L-LSP. . . . . . . . . . . . . . . . . . . . . . . . .33
4.6 L-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .34
5. RSVP Extension for Diff-Serv Support . . . . . . . . . . . . . .34
5.1 Diff-Serv related RSVP Messages Format. . . . . . . . . . . . .34
5.2 DIFFSERV Object . . . . . . . . . . . . . . . . . . . . . . . .35
5.3 Handling DIFFSERV Object. . . . . . . . . . . . . . . . . . . .37
5.4 Non-support of the DIFFSERV Object. . . . . . . . . . . . . . .40
5.5 Error Codes For Diff-Serv . . . . . . . . . . . . . . . . . . .40
5.6 Intserv Service Type. . . . . . . . . . . . . . . . . . . . . .41
6. LDP Extensions for Diff-Serv Support . . . . . . . . . . . . . .41
6.1 Diff-Serv TLV . . . . . . . . . . . . . . . . . . . . . . . . .42
6.2 Diff-Serv Status Code Values. . . . . . . . . . . . . . . . . .44
6.3 Diff-Serv Related LDP Messages. . . . . . . . . . . . . . . . .44
6.4 Handling of the Diff-Serv TLV . . . . . . . . . . . . . . . . .46
6.5 Non-Handling of the Diff-Serv TLV . . . . . . . . . . . . . . .49
6.6 Bandwidth Information . . . . . . . . . . . . . . . . . . . . .49
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and
Non-LC-FR Interfaces . . . . . . . . . . . . . . . . . . . . . .49
8. MPLS Support of Diff-Serv over LC-ATM Interfaces . . . . . . . .50
8.1 Use of ATM Traffic Classes and Traffic Management mechanisms. .50
8.2 LSR Implementation With LC-ATM Interfaces . . . . . . . . . . .50
9. MPLS Support of Diff-Serv over LC-FR Interfaces. . . . . . . . .51
9.1 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . .51
9.2 LSR Implementation With LC-FR Interfaces. . . . . . . . . . . .51
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .52
11. Security Considerations . . . . . . . . . . . . . . . . . . . .52
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .52
APPENDIX A. Example Deployment Scenarios. . . . . . . . . . . . . .53
APPENDIX B. Example Bandwidth Reservation Scenarios . . . . . . . .58
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .62
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .64
In an MPLS domain [MPLS_ARCH], when a stream of data traverses a common path, a Label Switched Path (LSP) can be established using MPLS signaling protocols. At the ingress Label Switch Router (LSR), each packet is assigned a label and is transmitted downstream. At each LSR along the LSP, the label is used to forward the packet to the next hop.
MPLSドメイン[MPLS_ARCH]では、データのストリームが共通パスを通過すると、MPLSシグナル伝達プロトコルを使用してラベルスイッチングパス（LSP）を確立できます。Ingressラベルスイッチルーター（LSR）では、各パケットにラベルが割り当てられ、下流に送信されます。LSPに沿った各LSRで、ラベルはパケットを次のホップに転送するために使用されます。
In a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] all the IP packets crossing a link and requiring the same Diff-Serv behavior are said to constitute a Behavior Aggregate (BA). At the ingress node of the Diff-Serv domain, the packets are classified and marked with a Diff-Serv Code Point (DSCP) which corresponds to their Behavior Aggregate. At each transit node, the DSCP is used to select the Per Hop Behavior (PHB) that determines the scheduling treatment and, in some cases, drop probability for each packet.
差別化されたサービス（diff-serv）ドメイン[diff_arch]リンクを横切り、同じdif-servの動作を必要とするすべてのIPパケットは、動作集合体（ba）を構成すると言われています。Diff-Servドメインのイングレスノードでは、パケットが分類され、動作の集合体に対応するDiff-Servコードポイント（DSCP）でマークされています。各トランジットノードでは、DSCPを使用して、スケジューリング処理を決定するPERホップ動作（PHB）を選択し、場合によっては各パケットの確率を低下させます。
This document specifies a solution for supporting the Diff-Serv Behavior Aggregates whose corresponding PHBs are currently defined (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network. This solution also offers flexibility for easy support of PHBs that may be defined in the future.
このドキュメントは、MPLSネットワーク上で（[diff_header]、[diff_af]、[diff_ef]、[diff_af]、[diff_ef]）現在定義されているdiff-servの動作集合体をサポートするためのソリューションを指定します。また、このソリューションは、将来定義される可能性のあるPHBを簡単にサポートするための柔軟性を提供します。
This solution relies on the combined use of two types of LSPs:
このソリューションは、2種類のLSPの使用に依存しています。
- LSPs which can transport multiple Ordered Aggregates, so that the EXP field of the MPLS Shim Header conveys to the LSR the PHB to be applied to the packet (covering both information about the packet's scheduling treatment and its drop precedence).
- MPLSシムヘッダーのEXPフィールドがLSRにパケットに適用されるように、MPLSシムヘッダーのEXPフィールドがLSRに伝えられるようにするLSP（パケットのスケジューリング処理に関する両方の情報とその低い優先順位をカバーします）。
- LSPs which only transport a single Ordered Aggregate, so that the packet's scheduling treatment is inferred by the LSR exclusively from the packet's label value while the packet's drop precedence is conveyed in the EXP field of the MPLS Shim Header or in the encapsulating link layer specific selective drop mechanism (ATM, Frame Relay, 802.1).
- パケットのスケジューリング処理は、パケットのラベル値からのみLSRによって推測されるように、単一の順序付けされた集計のみを輸送するLSPSが、パケットのドロップの優先順位がMPLSシムヘッダーのEXPフィールドまたはカプセル化リンクレイヤー固有の選択的選択的選択的に伝えられますドロップメカニズム（ATM、フレームリレー、802.1）。
As mentioned in [DIFF_HEADER], "Service providers are not required to use the same node mechanisms or configurations to enable service differentiation within their networks, and are free to configure the node parameters in whatever way that is appropriate for their service offerings and traffic engineering objectives". Thus, the solution defined in this document gives Service Providers flexibility in selecting how Diff-Serv classes of service are Routed or Traffic Engineered within their domain (e.g., separate classes of services supported via separate LSPs and Routed separately, all classes of service supported on the same LSP and Routed together).
[diff_header]で述べたように、「サービスプロバイダーは、ネットワーク内のサービス差別化を有効にするために同じノードメカニズムまたは構成を使用する必要はありません。目的」。したがって、このドキュメントで定義されているソリューションにより、サービスプロバイダーは、Diff-Serv Classe of Serviceのルーティングまたはトラフィックエンジニアリングの柔軟性を提供します（たとえば、個別のLSPを介してサポートされ、別々にルーティングされるサービスの個別のクラス、すべてのクラスのサービスがサポートされています。同じLSPと一緒にルーティング）。
Because MPLS is path-oriented it can potentially provide faster and more predictable protection and restoration capabilities in the face of topology changes than conventional hop by hop routed IP systems. In this document we refer to such capabilities as "MPLS protection". Although such capabilities and associated mechanisms are outside the scope of this specification, we note that they may offer different levels of protection to different LSPs. Since the solution presented here allow Service Providers to choose how Diff-Serv classes of services are mapped onto LSPs, the solution also gives Service Providers flexibility in the level of protection provided to different Diff-Serv classes of service (e.g., some classes of service can be supported by LSPs which are protected while some other classes of service are supported by LSPs which are not protected).
MPLSはパス指向であるため、ホップルーティングされたIPシステムによる従来のホップよりも、トポロジの変化に面して、より速く、より予測可能な保護と回復機能を潜在的に提供できます。このドキュメントでは、そのような機能を「MPLS保護」と呼びます。このような機能と関連するメカニズムは、この仕様の範囲外ですが、異なるLSPに異なるレベルの保護を提供する可能性があることに注意してください。ここで提示されたソリューションにより、サービスプロバイダーはDiffServクラスのサービスのマッピングをLSPにマッピングする方法を選択できるため、ソリューションは、さまざまなDiff-Servクラスのサービス（たとえば、一部のクラスのサービスに提供される保護レベルでサービスプロバイダーが柔軟性を与えます。保護されているLSPによってサポートできますが、他のクラスのサービスは保護されていないLSPによってサポートされています）。
Furthermore, the solution specified in this document achieves label space conservation and reduces the volume of label set-up/tear-down signaling where possible by only resorting to multiple LSPs for a given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when useful or required.
さらに、このドキュメントで指定されたソリューションは、ラベル空間保存を実現し、可能な限りラベルセットアップ/引き裂きシグナリングの量を減らします。。
This specification allows support of Differentiated Services for both IPv4 and IPv6 traffic transported over an MPLS network. This document only describes operations for unicast. Multicast support is for future study.
この仕様により、MPLSネットワークを介して輸送されるIPv4とIPv6トラフィックの両方の差別化されたサービスのサポートが可能になります。このドキュメントは、ユニキャストの操作のみを説明しています。マルチキャストサポートは、将来の研究のためのものです。
The solution described in this document does not preclude the signaled or configured use of the EXP bits to support Explicit Congestion Notification [ECN] simultaneously with Diff-Serv over MPLS. However, techniques for supporting ECN in an MPLS environment are outside the scope of this document.
このドキュメントで説明されているソリューションは、MPLS上のDiff-Servと同時に明示的なうっ血通知[ECN]をサポートするために、EXPビットの信号または構成された使用を排除するものではありません。ただし、MPLS環境でECNをサポートする手法は、このドキュメントの範囲外です。
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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119に記載されているとおりに解釈されます。
The reader is assumed to be familiar with the terminology of [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM], [MPLS_FR], including the following:
読者は、[mpls_arch]、[mpls_encaps]、[mpls_atm]、[mpls_fr]の用語に精通していると想定されています。
FEC Forwarding Equivalency Class
FEC転送等価クラス
FTN FEC-To-NHLFE Map
ftn fec-to-nhlfeマップ
ILM Incoming Label Map
ILM着信ラベルマップ
LC-ATM Label Switching Controlled-ATM (interface)
LC-ATMラベルスイッチング制御ATM（インターフェイス）
LC-FR Label Switching Controlled-Frame Relay (interface)
LC-FRラベルスイッチング制御フレームリレー（インターフェイス）
LSP Label Switched Path
LSPラベルの切り替えパス
LSR Label Switch Router
LSRラベルスイッチルーター
MPLS Multi-Protocol Label Switching
MPLSマルチプロトコルラベルスイッチング
NHLFE Next Hop Label Forwarding Entry
NHLFE次のホップラベル転送エントリ
The reader is assumed to be familiar with the terminology of [DIFF_ARCH], [DIFF_HEADER], [DIFF_AF], [DIFF_EF], including the following:
読者は、[diff_arch]、[diff_header]、[diff_af]、[diff_ef]の用語に精通していると想定されています。
AF Assured Forwarding
AF ASSURED FOWROWNING
BA Behavior Aggregate
BAの動作集合体
CS Class Selector
CSクラスセレクター
DF Default Forwarding
DFデフォルト転送
DSCP Differentiated Services Code Point
DSCP差別化されたサービスコードポイント
EF Expedited Forwarding
EF迅速な転送
PHB Per Hop Behavior
ホップあたりのPHB動作
The reader is assumed to be familiar with the terminology of [DIFF_NEW], including the following:
読者は、[diff_new]の用語に精通していると想定されています。
OA Ordered Aggregate. The set of Behavior Aggregates which share an ordering constraint.
OA注文集合体。順序付けの制約を共有する動作のセットは集約します。
PSC PHB Scheduling Class. The set of one or more PHB(s) that are applied to the Behavior Aggregate(s) belonging to a given OA. For example, AF1x is a PSC comprising the AF11, AF12 and AF13 PHBs. EF is an example of PSC comprising a single PHB, the EF PHB.
PSC PHBスケジューリングクラス。特定のOAに属する動作集約に適用される1つ以上のPHBのセット。たとえば、AF1Xは、AF11、AF12、およびAF13 PHBを含むPSCです。EFは、単一のPHBであるEF PHBを含むPSCの例です。
The following acronyms are also used:
次の頭字語も使用されます。
CLP Cell Loss Priority
CLP細胞損失の優先順位
DE Discard Eligibility
De Dosdardの適格性
SNMP Simple Network Management Protocol
SNMPシンプルなネットワーク管理プロトコル
Finally, the following acronyms are defined in this specification:
最後に、次の頭字語がこの仕様で定義されています。
E-LSP EXP-Inferred-PSC LSP
e-lsp expinferred-psc lsp
L-LSP Label-Only-Inferred-PSC LSP
l-lspラベルのみを受信したpsc lsp
A single LSP can be used to support one or more OAs. Such LSPs can support up to eight BAs of a given FEC, regardless of how many OAs these BAs span. With such LSPs, the EXP field of the MPLS Shim Header is used by the LSR to determine the PHB to be applied to the packet. This includes both the PSC and the drop preference.
単一のLSPを使用して、1つ以上のOASをサポートできます。このようなLSPは、これらのBASスパンの数に関係なく、特定のFECの最大8つのBASをサポートできます。このようなLSPを使用すると、MPLSシムヘッダーのEXPフィールドがLSRによって使用され、パケットに適用されるPHBを決定します。これには、PSCとドロップ選好の両方が含まれます。
We refer to such LSPs as "EXP-inferred-PSC LSPs" (E-LSP), since the PSC of a packet transported on this LSP depends on the EXP field value for that packet.
このLSPで輸送されたパケットのPSCは、そのパケットのEXPフィールド値に依存するため、このようなLSPは「Exp Inferred-PSC LSPS」（E-LSP）と呼びます。
The mapping from the EXP field to the PHB (i.e., to PSC and drop precedence) for a given such LSP, is either explicitly signaled at label set-up or relies on a pre-configured mapping.
特定のLSPのEXPフィールドからPHBへのマッピング（つまり、PSCおよびドロップの優先順位）は、ラベルセットアップで明示的に信号を送るか、事前に構成されたマッピングに依存しています。
Detailed operations of E-LSPs are specified in section 3 below.
E-LSPの詳細な操作は、以下のセクション3に指定されています。
A separate LSP can be established for a single <FEC, OA> pair. With such LSPs, the PSC is explicitly signaled at the time of label establishment, so that after label establishment, the LSR can infer exclusively from the label value the PSC to be applied to a labeled packet. When the Shim Header is used, the Drop Precedence to be applied by the LSR to the labeled packet, is conveyed inside the labeled packet MPLS Shim Header using the EXP field. When the Shim Header is not used (e.g., MPLS Over ATM), the Drop Precedence to be applied by the LSR to the labeled packet is conveyed inside the link layer header encapsulation using link layer specific drop precedence fields (e.g., ATM CLP).
単一の<FEC、OA>ペアに対して別のLSPを確立できます。このようなLSPを使用すると、PSCはラベル確立時に明示的に信号を送られているため、ラベル設立後、LSRはラベル値からPSCをラベルパケットに適用するPSCのみを推測できます。シムヘッダーを使用すると、LSRによってラベル付きパケットに適用されるドロップの優先順位が、EXPフィールドを使用してラベル付きパケットMPLSシムヘッダー内で伝達されます。Shimヘッダーを使用していない場合（ATMを超えるMPL）、LSRによってラベル付きパケットに適用されるドロップの優先順位は、リンクレイヤー固有のドロップ優先フィールド（ATM CLPなど）を使用してリンクレイヤーヘッダーカプセル化内で伝達されます。
We refer to such LSPs as "Label-Only-Inferred-PSC LSPs" (L-LSP) since the PSC can be fully inferred from the label without any other information (e.g., regardless of the EXP field value). Detailed operations of L-LSPs are specified in section 4 below.
このようなLSPは、PSCを他の情報なしでラベルから完全に推測できるため（例：EXPフィールド値に関係なく）、「ラベルのみの有名なPSC LSP」（L-LSP）と呼びます。L-LSPの詳細な操作は、以下のセクション4に指定されています。
For a given FEC, and unless media specific restrictions apply as identified in the sections 7, 8 and 9 below, this specification allows any one of the following combinations within an MPLS Diff-Serv domain:
特定のFECの場合、および以下のセクション7、8、9で特定されているようにメディア固有の制限が適用されない限り、この仕様により、MPLS DIFF-SERVドメイン内の以下の組み合わせのいずれかが許可されます。
- zero or any number of E-LSPs, and
- ゼロまたは任意の数のE-LSP、および
- zero or any number of L-LSPs.
- ゼロまたは任意の数のL-LSP。
The network administrator selects the actual combination of LSPs from the set of allowed combinations and selects how the Behavior Aggregates are actually transported over this combination of LSPs, in order to best match his/her environment and objectives in terms of Diff-Serv support, Traffic Engineering and MPLS Protection. Criteria for selecting such a combination are outside the scope of this specification.
ネットワーク管理者は、許可された組み合わせのセットからLSPの実際の組み合わせを選択し、Diff-Servのサポート、トラフィックの観点から環境と目的に最適に一致するために、このLSPのこの組み合わせで動作集合体が実際に輸送される方法を選択します。エンジニアリングおよびMPLS保護。このような組み合わせを選択するための基準は、この仕様の範囲外です。
For a given FEC, there may be more than one LSP carrying the same OA, for example for purposes of load balancing of the OA; However in order to respect ordering constraints, all packets of a given microflow, possibly spanning multiple BAs of a given Ordered Aggregate, MUST be transported over the same LSP. Conversely, each LSP MUST be capable of supporting all the (active) BAs of a given OA.
特定のFECの場合、たとえばOAの負荷分散のために、同じOAを運ぶ複数のLSPがある場合があります。ただし、順序付けの制約を尊重するためには、特定の順序付けされた骨材の複数のBASにまたがる可能性のあるマイクロフローのすべてのパケットを同じLSPで輸送する必要があります。逆に、各LSPは、特定のOAのすべての（アクティブな）BASをサポートできる必要があります。
Examples of deployment scenarios are provided for information in APPENDIX A.
展開シナリオの例は、付録Aの情報について提供されています。
[MPLS_ARCH] states in section `2.1. Overview' that: `Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service". They may then apply different discard thresholds or scheduling disciplines to different packets. MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label. In this case, one may say that the label represents the combination of a FEC and a precedence or class of service.'
[MPLS_ARCH]セクション `2.1に記載されています。概要 'That：その後、異なる廃棄のしきい値またはスケジューリング分野を異なるパケットに適用する場合があります。MPLSを使用すると、優先順位またはサービスのクラスをラベルから完全または部分的に推測することができます（必要ありません）。この場合、ラベルはFECと優先順位またはサービスの組み合わせを表していると言うかもしれません。
In line with this, we observe that:
これに沿って、私たちはそれを観察します：
- With E-LSPs, the label represents the combination of a FEC and the set of BAs transported over the E-LSP. Where all the supported BAs are transported over an E-LSP, the label then represents the complete FEC.
- E-LSPを使用すると、ラベルはFECとE-LSPで輸送されるBASのセットの組み合わせを表します。サポートされているすべてのBASがE-LSPで輸送される場合、ラベルは完全なFECを表します。
- With L-LSPs, the label represents the combination of a FEC and an OA.
- L-LSPでは、ラベルはFECとOAの組み合わせを表します。
Regardless of which label binding protocol is used, E-LSPs and L-LSPs may be established with or without bandwidth reservation.
どのラベル結合プロトコルを使用するかに関係なく、帯域幅の予約の有無にかかわらず、E-LSPとL-LSPは確立される場合があります。
Establishing an E-LSP or L-LSP with bandwidth reservation means that bandwidth requirements for the LSP are signaled at LSP establishment time. Such signaled bandwidth requirements may be used by LSRs at establishment time to perform admission control of the signaled LSP over the Diff-Serv resources provisioned (e.g., via configuration, SNMP or policy protocols) for the relevant PSC(s). Such signaled bandwidth requirements may also be used by LSRs at establishment time to perform adjustment to the Diff-Serv resources associated with the relevant PSC(s) (e.g., adjust PSC scheduling weight).
帯域幅の予約を備えたE-LSPまたはL-LSPを確立することは、LSPの帯域幅要件がLSPの確立時にシグナルにされることを意味します。このようなシグナル付き帯域幅要件は、関連するPSCのために提供されたDIF-Servリソース（たとえば、構成、SNMP、またはポリシープロトコルを介して）でシグナル付きLSPの入場制御を実行するために、確立時にLSRによって使用される場合があります。このようなシグナル付き帯域幅要件は、LSRが設立時間にも使用して、関連するPSC（S）に関連付けられたDIF-Servリソースの調整を実行することもできます（たとえば、PSCスケジューリング重量を調整します）。
Note that establishing an E-LSP or L-LSP with bandwidth reservation does not mean that per-LSP scheduling is required. Since E-LSPs and L-LSPs are specified in this document for support of Differentiated Services, the required forwarding treatment (scheduling and drop policy) is defined by the appropriate Diff-Serv PHB. This forwarding treatment MUST be applied by the LSR at the granularity of the BA and MUST be compliant with the relevant PHB specification.
帯域幅の予約でE-LSPまたはL-LSPを確立しても、LSPごとのスケジューリングが必要であることを意味しないことに注意してください。このドキュメントでは、差別化されたサービスをサポートするためにE-LSPとL-LSPが指定されているため、必要な転送処理（スケジューリングおよびドロップポリシー）は、適切なDIF-Serv PHBによって定義されます。この転送処理は、BAの粒度でLSRによって適用されなければならず、関連するPHB仕様に準拠している必要があります。
When bandwidth requirements are signaled at the establishment of an L-LSP, the signaled bandwidth is obviously associated with the L-LSP's PSC. Thus, LSRs which use the signaled bandwidth to perform admission control may perform admission control over Diff-Serv resources, which are dedicated to the PSC (e.g., over the bandwidth guaranteed to the PSC through its scheduling weight).
L-LSPの確立時に帯域幅要件が信号を受ける場合、信号帯域幅は明らかにL-LSPのPSCに関連付けられています。したがって、信号帯域幅を使用して入学制御を実行するLSRは、PSC専用のDIF-Servリソース（たとえば、スケジューリング重量を通じてPSCに保証されている帯域幅を介して）を介して入学制御を実行できます。
When bandwidth requirements are signaled at the establishment of an E-LSP, the signaled bandwidth is associated collectively with the whole LSP and therefore with the set of transported PSCs. Thus, LSRs which use the signaled bandwidth to perform admission control may perform admission control over global resources, which are shared by the set of PSCs (e.g., over the total bandwidth of the link).
E-LSPの確立時に帯域幅要件が信号を送られると、信号帯域幅はLSP全体と輸送されたPSCのセットに集合的に関連付けられています。したがって、信号帯域幅を使用して入学制御を実行するLSRは、PSCのセット（例：リンクの総帯域幅で）で共有されるグローバルリソースに対して入場制御を実行できます。
Examples of scenarios where bandwidth reservation is not used and scenarios where bandwidth reservation is used are provided for information in APPENDIX B.
帯域幅の予約が使用されていないシナリオの例と、付録Bに情報に帯域幅予約が使用されるシナリオが使用されています。
Since different Ordered Aggregates of a given FEC may be transported over different LSPs, the label swapping decision of a Diff-Serv LSR clearly depends on the forwarded packet's Behavior Aggregate. Also, since the IP DS field of a forwarded packet may not be directly visible to an LSR, the way to determine the PHB to be applied to a received packet and to encode the PHB into a transmitted packet, is different than a non-MPLS Diff-Serv Router.
特定のFECの異なる秩序化された凝集体は異なるLSPで輸送される可能性があるため、Diff-Serv LSRのラベル交換決定は、転送されたパケットの動作の集合体に明確に依存します。また、転送されたパケットのIP DSフィールドがLSRに直接表示されない可能性があるため、受信したパケットに適用されるPHBを決定し、PHBを送信されたパケットにエンコードする方法は、非MPLSとは異なります。Diff-Servルーター。
Thus, in order to describe Label Forwarding by Diff-Serv LSRs, we model the LSR Diff-Serv label switching behavior, comprised of four stages:
したがって、diff-serv LSRによるラベル転送を記述するために、4つの段階で構成されるLSR diff-servラベルスイッチング動作をモデル化します。
- Incoming PHB Determination (A)
- 着信PHB決定（a）
- Outgoing PHB Determination with Optional Traffic Conditioning(B)
- オプションのトラフィックコンディショニングによる発信PHB決定（b）
- Label Forwarding (C)
- ラベル転送（c）
- Encoding of Diff-Serv information into Encapsulation Layer (EXP, CLP, DE, User_Priority) (D)
- diff-serv情報のカプセル化レイヤーへのエンコーディング（Exp、clp、de、user_priority）（d）
Each stage is described in more detail in the following sections.
各段階については、次のセクションで詳しく説明します。
Obviously, to enforce the Diff-Serv service differentiation the LSR MUST also apply the forwarding treatment corresponding to the Outgoing PHB.
明らかに、DIF-Servサービスの差別化を実施するには、LSRも発信PHBに対応する転送処理を適用する必要があります。
This model is illustrated below:
このモデルを以下に示します。
--Inc_label(s)(*)------------------------>I===I--Outg_label(s)(&)-->
\ I I \
\---->I===I I C I \-->I===I--Encaps->
I A I I===I--Outg_PHB->I===I I D I (&)
-Encaps->I===I--Inc_PHB->I B I \ /->I===I
(*) I===I \--------+
\----Forwarding-->
Treatment
(PHB)
"Encaps" designates the Diff-Serv related information encoded in the MPLS Encapsulation layer (e.g., EXP field, ATM CLP, Frame Relay DE, 802.1 User_Priority)
「Encaps」は、MPLSカプセル化レイヤーにエンコードされたDIF-Serv関連情報を指定します（例：Expフィールド、ATM CLP、フレームリレーDE、802.1ユーザー_Priority）
(*) when the LSR behaves as an MPLS ingress node, the incoming packet may be received unlabelled.
（*）LSRがMPLS侵入ノードとして動作する場合、着信パケットは無効にされている可能性があります。
(&) when the LSR behaves as an MPLS egress node, the outgoing packet may be transmitted unlabelled.
（＆）LSRがMPLS出力ノードとして動作する場合、発信パケットは無効にされている場合があります。
This model is presented here to describe the functional operations of Diff-Serv LSRs and does not constrain actual implementation.
このモデルは、diff-serv LSRSの機能操作を記述するためにここに示されており、実際の実装を制約しません。
This stage determines which Behavior Aggregate the received packet belongs to.
この段階では、受信したパケットが属する動作を決定します。
Sections 3.3 and 4.3 provide the details on how to perform incoming PHB Determination considering a given received label stack entry and/or received incoming MPLS encapsulation information depending on the incoming LSP type and depending on the incoming MPLS encapsulation.
セクション3.3および4.3は、特定の受信したラベルスタックエントリおよび/または受信した受信したMPLSカプセル化情報を、着信LSPタイプに応じて、受信したMPLSカプセル化に応じて、受信したPHB決定を実行する方法の詳細を提供します。
Section 2.6 provides the details of which label stack entry to consider for the Incoming PHB Determination depending on the supported Diff-Serv tunneling mode.
セクション2.6では、サポートされているDIF-Servトンネルモードに応じて、着信PHB決定を考慮するラベルスタックエントリの詳細を示します。
Section 2.6 provides the details of when the IP Header is to be considered for incoming PHB determination, depending on the supported Diff-Serv tunneling model. In those cases where the IP header is to be used, this stage operates exactly as with a non-MPLS IP Diff-Serv Router and uses the DS field to determine the incoming PHB.
セクション2.6では、サポートされているDIF-Servトンネリングモデルに応じて、IPヘッダーが着信PHB決定のために考慮される時期の詳細を説明します。IPヘッダーを使用する場合、この段階は非MPLS IP DIFF-SERVルーターと同様に正確に動作し、DSフィールドを使用して着信PHBを決定します。
The traffic conditioning stage is optional and may be used on an LSR to perform traffic conditioning including Behavior Aggregate demotion or promotion. It is outside the scope of this specification. For the purpose of specifying Diff-Serv over MPLS forwarding, we simply note that the PHB to be actually enforced and conveyed to downstream LSRs by an LSR (referred to as "outgoing PHB"), may be different to the PHB which had been associated with the packet by the previous LSR (referred to as "incoming PHB").
トラフィックコンディショニング段階はオプションであり、LSRで使用されて、動作の集約的降格や昇進などのトラフィックコンディショニングを実行できます。この仕様の範囲外です。MPLS転送よりもdiff-servを指定する目的で、LSR（「発信PHB」と呼ばれる）によって実際に施行され、下流のLSRに伝達されるPHBは、関連付けられていたPHBとは異なる場合があることに注意してください。以前のLSR（「着信PHB」と呼ばれる）によるパケットを使用してください。
When the traffic conditioning stage is not present, the "outgoing PHB" is simply identical to the "incoming PHB".
トラフィックコンディショニング段階が存在しない場合、「発信PHB」は単に「着信PHB」と同じです。
[MPLS_ARCH] describes how label swapping is performed by LSRs on incoming labeled packets using an Incoming Label Map (ILM), where each incoming label is mapped to one or multiple NHLFEs. [MPLS_ARCH] also describes how label imposition is performed by LSRs on incoming unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each incoming FEC is mapped to one or multiple NHLFEs.
[MPLS_ARCH]は、着信ラベルマップ（ILM）を使用して、着信ラベル付きパケットでLSRによってラベルスワッピングが実行される方法について説明します。ここでは、各着信ラベルが1つまたは複数のNHLFEにマッピングされます。[MPLS_ARCH]は、FEC-to-NHLFESマップ（FTN）を使用して、着信の非標識パケットでLSRによってラベルの賦課がどのように実行されるかについても説明しています。そこでは、各着信FECが1つまたは複数のNHLFEにマッピングされます。
A Diff-Serv Context for a label is comprised of:
ラベルの差別的なコンテキストは、次のことです。
- `LSP type (i.e., E-LSP or L-LSP)'
- `LSPタイプ（つまり、e-lspまたはl-lsp）」
- `supported PHBs'
- 「サポートされているPHB」
- `Encaps-->PHB mapping' for an incoming label
- `cankaps-> phb mapping 'for incomingラベル
- `Set of PHB-->Encaps mappings' for an outgoing label
- 「PHBのセット - >発信ラベルのEncapsマッピング」
The present specification defines that a Diff-Serv Context is stored in the ILM for each incoming label.
現在の仕様では、diff-servコンテキストが各着信ラベルのILMに保存されていることを定義しています。
[MPLS_ARCH] states that the `NHLFE may also contain any other information needed in order to properly dispose of the packet'. In accordance with this, the present specification defines that a Diff-Serv Context is stored in the NHLFE for each outgoing label that is swapped or pushed.
[MPLS_ARCH]は、「NHLFEには、パケットを適切に処分するために必要な他の情報も含まれている可能性がある」と述べています。これに従って、現在の仕様では、交換またはプッシュされる発信ラベルごとに、diff-servコンテキストがNHLFEに保存されていることを定義しています。
This Diff-Serv Context information is populated into the ILM and the FTN at label establishment time.
このdiff-servコンテキスト情報は、ラベル確立時にILMとFTNに入力されます。
If the label corresponds to an E-LSP for which no `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the `supported PHBs' is populated with the set of PHBs of the preconfigured `EXP<-->PHB mapping', which is discussed below in section 3.2.1.
ラベルがe-lspに対応している場合、「exp <> phbマッピング」がLSPセットアップで明示的に信号を送られていない場合、「サポートされたPHB」には、事前に設定された「exp < - >PHBマッピング '。これは、セクション3.2.1で以下で説明します。
If the label corresponds to an E-LSP for which an `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the `supported PHBs' is populated with the set of PHBs of the signaled `EXP<-->PHB mapping'.
ラベルが「exp < - > phbマッピング」がLSPセットアップで明示的に信号が表示されているe-lspに対応する場合、「サポートされているphb」には、「exp <->PHBマッピング '。
If the label corresponds to an L-LSP, the `supported PHBs' is populated with the set of PHBs forming the PSC that is signaled at LSP set-up.
ラベルがL-LSPに対応する場合、「サポートされているPHB」には、LSPセットアップでシグナルが形成されるPHBのセットが入力されます。
The details of how the `Encaps-->PHB mapping' or `Set of PHB-->Encaps mappings' are populated are defined below in sections 3 and 4.
`cankpaps-> phbマッピング」または「phbのセット - > cankapsマッピング」の詳細は、セクション3および4の以下に定義されています。
[MPLS_ARCH] also states that:
[mpls_arch]も次のように述べています。
"If the ILM [respectively, FTN] maps a particular label to a set of NHLFEs that contain more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the ILM [respectively, FTN] map a label [respectively, a FEC] to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths."
「それぞれILM [FTN]が特定のラベルを複数の要素を含むNHLFEのセットにマッピングする場合、パケットが転送される前に、セットの正確な1つの要素を選択する必要があります。セットから要素を選択する手順は次のとおりです。このドキュメントの範囲を超えて。ILM[それぞれFTN]を使用すると、それぞれラベルをマップします[FEC]を複数のNHLFEを含むセットにマッピングすることが有用です。コストパス。」
In accordance with this, the present specification allows that an incoming label [respectively FEC] may be mapped, for Diff-Serv purposes, to multiple NHLFEs (for instance where different NHLFEs correspond to egress labels supporting different sets of PHBs). When a label [respectively FEC] maps to multiple NHLFEs, the Diff-Serv LSR MUST choose one of the NHLFEs whose Diff-Serv Context indicates that it supports the Outgoing PHB of the forwarded packet.
これに従って、現在の仕様では、diff-serv-servの目的のために、それぞれ受信ラベルが複数のNHLFにマッピングされることができます（たとえば、異なるNHLFがPHBの異なるセットをサポートする出力ラベルに対応する場合）。[それぞれFEC]を複数のNHLFEにマッピングする場合、DIFSERV-SERV LSRは、転送パケットの発信PHBをサポートすることを示すDIF-Servコンテキストが示すNHLFEのいずれかを選択する必要があります。
When a label [respectively FEC] maps to multiple NHLFEs which support the Outgoing PHB, the procedure for choosing one among those is outside the scope of this document. This situation may be encountered where it is desired to do load balancing of a Behavior Aggregate over multiple LSPs. In such situations, in order to respect ordering constraints, all packets of a given microflow MUST be transported over the same LSP.
[それぞれFEC]が発信PHBをサポートする複数のNHLFEにマッピングする場合、それらの中から1つを選択する手順は、このドキュメントの範囲外です。この状況には、複数のLSPを介して動作の負荷分散を行うことが望まれる場合に遭遇する可能性があります。このような状況では、順序付けの制約を尊重するために、特定のマイクロフローのすべてのパケットを同じLSPで輸送する必要があります。
This stage determines how to encode the fields which convey Diff-Serv information in the transmitted packet (e.g., MPLS Shim EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority).
この段階では、送信されたパケットにdiff-serv情報を伝えるフィールドをエンコードする方法を決定します（例：mpls shim exp、atm clp、フレームリレーDE、802.1 user_priority）。
Sections 3.5 and 4.5 provide the details on how to perform Diff-Serv information encoding into a given transmitted label stack entry and/or transmitted MPLS encapsulation information depending on the corresponding outgoing LSP type and depending on the MPLS encapsulation.
セクション3.5および4.5は、対応する発信LSPタイプに応じて、MPLSカプセル化に応じて、特定の送信されたラベルスタックエントリおよび/または送信されたMPLSカプセル化情報にエンコードする差別情報情報を実行する方法の詳細を提供します。
Section 2.6 provides the details in which label stack entry to perform Diff-Serv information encoding into depending on the supported Diff-Serv tunneling mode.
セクション2.6では、サポートされているDIFF-Servトンネルモードに応じて、Diff-Serv情報を実行するラベルスタックエントリを実行する詳細を示します。
To perform Diff-Serv Information Encoding into the transmitted packet IP header, this stage operates exactly as with a non-MPLS IP Diff-Serv Router and encodes the DSCP of the Outgoing PHB into the DS field.
送信されたパケットIPヘッダーにエンコードするDiff-Serv情報を実行するために、この段階は非MPLS IP DIFF-Servルーターと同様に正確に動作し、発信PHBのDSCPをDSフィールドにエンコードします。
Section 2.6 provides the details of when Diff-Serv Information Encoding is to be performed into transmitted IP header depending on the supported Diff-Serv tunneling mode.
セクション2.6では、サポートされているDIFF-Servトンネルモードに応じて、DIFSERV情報エンコードが送信されたIPヘッダーに実行される時期の詳細を説明します。
[DIFF_TUNNEL] considers the interaction of Differentiated Services with IP tunnels of various forms. MPLS LSPs are not a form of "IP tunnels" since the MPLS encapsulating header does not contain an IP header and thus MPLS LSPs are not considered in [DIFF_TUNNEL]. However, although not a form of "IP tunnel", MPLS LSPs are a form of "tunnel".
[diff_tunnel]は、さまざまな形態のIPトンネルとの差別化されたサービスとの相互作用を考慮します。MPLS LSPは「IPトンネル」の形式ではありません。MPLSカプセル化ヘッダーにはIPヘッダーが含まれていないため、MPLS LSPは[diff_tunnel]では考慮されていません。ただし、「IPトンネル」の形式ではありませんが、MPLS LSPは「トンネル」の形式です。
From the Diff-Serv standpoint, LSPs share a number of common characteristics with IP Tunnels:
Diff-Servの観点から、LSPはIPトンネルと多くの共通の特性を共有しています。
- Intermediate nodes (i.e., Nodes somewhere along the LSP span) only see and operate on the "outer" Diff-Serv information.
- 中間ノード（つまり、LSPスパンのどこかにノード）は、「外側の」diff-serv情報を参照して動作させます。
- LSPs are unidirectional.
- LSPは単方向です。
- The "outer" Diff-Serv information can be modified at any of the intermediate nodes.
- 「外側の」diff-serv情報は、中間ノードのいずれかで変更できます。
However, from the Diff-Serv standpoint, LSPs also have a distinctive property compared to IP Tunnels:
ただし、Diff-Servの観点からは、LSPにはIPトンネルと比較して特徴的な特性もあります。
- There is generally no behavior analogous to Penultimate Hop Popping (PHP) used with IP Tunnels. Furthermore, PHP results in the "outer" Diff-Serv information associated with the LSP not being visible to the LSP egress. In situations where this information is not meaningful at the LSP Egress, this is obviously not an issue at all. In situations where this information is meaningful at the LSP Egress, then it must somehow be carried in some other means.
- 一般に、IPトンネルで使用される最後から2番目のホップポップ（PHP）に類似した動作はありません。さらに、PHPは、LSPに関連する「外側」Diff-Serv情報をLSP Egressに表示していません。LSP Egressでこの情報が意味がない状況では、これは明らかにまったく問題ではありません。この情報がLSP Egressで意味のある状況では、何らかの形で他の手段で運ばれなければなりません。
The two conceptual models for Diff-Serv tunneling over IP Tunnels defined in [DIFF_TUNNEL] are applicable and useful to Diff-Serv over MPLS but their respective detailed operations is somewhat different over MPLS. These two models are the Pipe Model and the Uniform Model. Their operations over MPLS are specified in the following sections. Discussion and definition of alternative tunneling models are outside the scope of this specification.
[diff_tunnel]で定義されているIPトンネル上のdif-servトンネルの2つの概念モデルは、MPLSよりもdiff-servに適用可能で有用ですが、それぞれの詳細操作はMPLSで多少異なります。これらの2つのモデルは、パイプモデルと均一モデルです。MPLを介した操作は、次のセクションで指定されています。代替トンネルモデルのディスカッションと定義は、この仕様の範囲外です。
With the Pipe Model, MPLS tunnels (aka LSPs) are used to hide the intermediate MPLS nodes between LSP Ingress and Egress from the Diff-Serv perspective.
パイプモデルを使用すると、MPLSトンネル（別名LSP）を使用して、LSPの侵入と脱出の間の中間MPLSノードを非公開の観点から非表示にします。
In this model, tunneled packets must convey two meaningful pieces of Diff-Serv information:
このモデルでは、トンネルパケットが2つの意味のある違い情報を伝える必要があります。
- the Diff-Serv information which is meaningful to intermediate nodes along the LSP span including the LSP Egress (which we refer to as the "LSP Diff-Serv Information"). This LSP Diff-Serv Information is not meaningful beyond the LSP Egress: Whether Traffic Conditioning at intermediate nodes on the LSP span affects the LSP Diff-Serv information or not, this updated Diff-Serv information is not considered meaningful beyond the LSP Egress and is ignored.
- LSP Egress（「LSP Diff-Serv情報」と呼ばれるLSPスパンに沿った中間ノードにとって意味のあるDiff-Serv情報。このLSP Diff-Serv情報は、LSPの出口を超えて意味がありません。LSPスパンの中間ノードでのトラフィックコンディショニングがLSP Diff-Serv情報に影響するかどうかにかかわらず、この更新されたDiff-Serv情報はLSP Egressを超えて意味があるとは見なされず、無視した。
- the Diff-Serv information which is meaningful beyond the LSP Egress (which we refer to as the "Tunneled Diff-Serv Information"). This information is to be conveyed by the LSP Ingress to the LSP Egress. This Diff-Serv information is not meaningful to the intermediate nodes on the LSP span.
- LSPの出口を超えて意味のあるdif-serv情報（「トンネル違いのdiff-serv情報」と呼ばれます）。この情報は、LSPの侵入によってLSP出力に伝えられます。このdiff-serv情報は、LSPスパンの中間ノードにとって意味がありません。
Operation of the Pipe Model without PHP is illustrated below:
PHPのないパイプモデルの動作を以下に示します。
========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E (M*)
(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" (*) The LSP Egress considers the LSP Diff-Serv information received in the outer header (i.e., before the pop) in order to apply its Diff-Serv forwarding treatment (i.e., actual PHB) I represents the LSP ingress node E represents the LSP egress node
（m）は「LSP Diff-Serv情報」を表します（M）は、「トンネル付きDiff-Serv情報」（*）を表します。そのdiff-serv方向転送処理（すなわち、実際のphb）を適用するために、iはLSP侵入ノードeを表すLSP Egressノードを表します
With the Pipe Model, the "LSP Diff-Serv Information" needs to be conveyed to the LSP Egress so that it applies its forwarding treatment based on it. The "Tunneled Diff-Serv information" also needs to be conveyed to the LSP Egress so it can be conveyed further downstream.
パイプモデルを使用すると、「LSP Diff-Serv情報」をLSP Egressに伝える必要があり、それに基づいて転送処理を適用する必要があります。「トンネル付きのdif-serv情報」もLSP出力に伝える必要があるため、さらに下流に伝えることができます。
Since both require that Diff-Serv information be conveyed to the LSP Egress, the Pipe Model operates only without PHP.
どちらもdiff-servの情報をLSP出力に伝える必要があるため、パイプモデルはPHPなしでのみ動作します。
The Pipe Model is particularly appropriate for environments in which:
パイプモデルは、次の環境に特に適しています。
- the cloud upstream of the incoming interface of the LSP Ingress and the cloud downstream of the outgoing interface of the LSP Egress are in Diff-Serv domains which use a common set of Diff-Serv service provisioning policies and PHB definitions, while the LSP spans one (or more) Diff-Serv domain(s) which use(s) a different set of Diff-Serv service provisioning policies and PHB definitions
- LSP侵入の着信インターフェイスの上流のクラウドと、LSPエグレスの発信インターフェイスの下流のクラウドは、diff-servサービスプロビジョニングポリシーとPHB定義の共通セットを使用しますが、LSPは1つにわたるDiff-Servドメインにあります。（またはそれ以上）Diff-Serv Service ProvisioningポリシーとPHB定義の異なるセットを使用するDIFF-SERVドメイン
- the outgoing interface of the LSP Egress is in the (last) Diff-Serv domain spanned by the LSP.
- LSP Egressの発信インターフェイスは、LSPによって範囲された（最後の）Diff-Servドメインにあります。
As an example, consider the case where a service provider is offering an MPLS VPN service (see [MPLS_VPN] for an example of MPLS VPN architecture) including Diff-Serv differentiation. Say that a collection of sites is interconnected via such an MPLS VPN service. Now say that this collection of sites is managed under a common administration and is also supporting Diff-Serv service differentiation. If the VPN site administration and the Service Provider are not sharing the exact same Diff-Serv policy (for instance not supporting the same number of PHBs), then operation of Diff-Serv in the Pipe Model over the MPLS VPN service would allow the VPN Sites Diff-Serv policy to operate consistently throughout the ingress VPN Site and Egress VPN Site and transparently over the Service Provider Diff-Serv domain. It may be useful to view such LSPs as linking the Diff-Serv domains at their endpoints into a single Diff-Serv region by making these endpoints virtually contiguous even though they may be physically separated by intermediate network nodes.
例として、サービスプロバイダーがMPLS VPNサービスを提供している場合を検討してください（MPLS VPNアーキテクチャの例については[mpls_vpn]を参照）、Diff-Servの差別化を含みます。サイトのコレクションは、このようなMPLS VPNサービスを介して相互接続されていると言います。ここで、このサイトのコレクションは共通の管理の下で管理されており、Dif-Servのサービス差別化もサポートしていると言ってください。VPNサイト管理とサービスプロバイダーがまったく同じDifF-Servポリシー（たとえば、同じ数のPHBをサポートしていない）を共有していない場合、MPLS VPNサービス上のパイプモデルでのDIFF-SERVの操作により、VPNが許可されます。サイトは、VPNサイトおよび出力VPNサイト全体で一貫して動作し、サービスプロバイダーDIFF-SERVドメインで透過的に動作するようになります。このようなLSPは、中間ネットワークノードで物理的に分離されている場合でも、これらのエンドポイントを実質的に隣接することにより、エンドポイントのDIFSERVドメインを単一のDiff-Serv領域にリンクするものとして見ると便利かもしれません。
The Pipe Model MUST be supported.
パイプモデルをサポートする必要があります。
For support of the Pipe Model over a given LSP without PHP, an LSR performs the Incoming PHB Determination and the Diff-Serv information Encoding in the following manner:
PHPなしの特定のLSPでのパイプモデルをサポートするために、LSRは次の方法でエンコードするdiff-serv情報を着信するPHB決定を実行します。
- when receiving an unlabelled packet, the LSR performs Incoming PHB Determination considering the received IP Header.
- 無効なパケットを受信するとき、LSRは受信したIPヘッダーを考慮して着信PHB決定を実行します。
- when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination BEFORE the pop.
- ラベル付きパケットを受信すると、LSRは受信したラベルスタックの外側ラベルエントリを考慮して、着信PHB決定を実行します。特に、考慮されたLSPに対してPOP操作を実行する場合、LSRはPOPの前に着信PHB決定を実行します。
- when performing a push operation for the considered LSP, the LSR:
- 考慮されたLSPのプッシュ操作を実行するとき、LSR：
o encodes Diff-Serv Information corresponding to the OUTGOING PHB in the transmitted label entry corresponding to the pushed label.
o プッシュラベルに対応する送信されたラベルエントリの発信PHBに対応するDiff-Serv情報をエンコードします。
o encodes Diff-Serv Information corresponding to the INCOMING PHB in the encapsulated header (swapped label entry or IP header).
o カプセル化されたヘッダーの着信PHBに対応するDIF-Serv情報をエンコードします（スワップラベルエントリまたはIPヘッダー）。
- when performing a swap-only operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry that contains the swapped label
- 考慮されたLSPのスワップのみの操作を実行するとき、LSRは、交換されたラベルを含む送信されたラベルエントリのDiff-Serv情報をエンコードします
- when performing a pop operation for the considered LSP, the LSR does not perform Encoding of Diff-Serv Information into the header exposed by the pop operation (i.e., the LSR leaves the exposed header "as is").
- 考慮されたLSPのPOP操作を実行する場合、LSRはPOP操作によって露出したヘッダーへのdiff-serv情報のエンコードを実行しません（つまり、LSRは露出したヘッダーを「現状のまま」します）。
The Short Pipe Model is an optional variation of the Pipe Model described above. The only difference is that, with the Short Pipe Model, the Diff-Serv forwarding treatment at the LSP Egress is applied based on the "Tunneled Diff-Serv Information" (i.e., Diff-Serv information conveyed in the encapsulated header) rather than on the "LSP Diff-Serv information" (i.e., Diff-Serv information conveyed in the encapsulating header).
短いパイプモデルは、上記のパイプモデルのオプションのバリエーションです。唯一の違いは、短いパイプモデルでは、LSP EgressでのDiff-Serv Forwarding Treatmentが「トンネル付きDiff-Serv情報」（つまり、カプセル化されたヘッダーで伝えられるDiff-Serv情報）に基づいて適用されることです。「LSP Diff-Serv情報」（つまり、カプセル化ヘッダーで伝えられるDiff-Serv情報）。
Operation of the Short Pipe Model without PHP is illustrated below:
PHPのない短いパイプモデルの動作を以下に示します。
========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E
(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" I represents the LSP ingress node E represents the LSP egress node
（m）は「LSP Diff-Serv情報」を表します（M）は「トンネル付きDiff-Serv情報」を表します。IはLSP Ingressノードeを表します。
Since the LSP Egress applies its forwarding treatment based on the "Tunneled Diff-Serv Information", the "LSP Diff-Serv information" does not need to be conveyed by the penultimate node to the LSP Egress. Thus the Short Pipe Model can also operate with PHP.
LSP Egressは「トンネル型差別情報」に基づいて転送処理を適用するため、「LSP Diff-Serv情報」は、LSP Egressに最後から2番目のノードによって伝える必要はありません。したがって、短いパイプモデルはPHPで動作することもあります。
Operation of the Short Pipe Model with PHP is illustrated below:
PHPを使用した短いパイプモデルの動作を以下に示します。
=========== LSP ============================>
---Swap--(M)--...--Swap------
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).............Pop-(m)--E--(m)-->
I (inner header) P (M*)
(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" (*) The Penultimate LSR considers the LSP Diff-Serv information received in the outer header (i.e., before the pop) in order to apply its Diff-Serv forwarding treatment (i.e., actual PHB) I represents the LSP ingress node P represents the LSP penultimate node E represents the LSP egress node
（m）は「LSP Diff-Serv情報」を表します（M）は、「トンネル付きDiff-Serv情報」（*）を表します（*）、最後から2番目のLSRが、外側のヘッダー（つまり、POPの前）で受け取ったLSP Diff-Serv情報を考慮します。そのdiff-serv転送処理（すなわち、実際のphb）を適用するために、iはLSPイングレスノードPを表すLSPの最後から2番目のノードEを表します。
The Short Pipe Model is particularly appropriate for environments in which:
短いパイプモデルは、次の環境に特に適しています。
- the cloud upstream of the incoming interface of the LSP Ingress and the cloud downstream of the outgoing interface of the LSP Egress are in Diff-Serv domains which use a common set of Diff-Serv service provisioning policies and PHB definitions, while the LSP spans one (or more) Diff-Serv domain(s) which use(s) a different set of Diff-Serv service provisioning policies and PHB definitions
- LSP侵入の着信インターフェイスの上流のクラウドと、LSPエグレスの発信インターフェイスの下流のクラウドは、diff-servサービスプロビジョニングポリシーとPHB定義の共通セットを使用しますが、LSPは1つにわたるDiff-Servドメインにあります。（またはそれ以上）Diff-Serv Service ProvisioningポリシーとPHB定義の異なるセットを使用するDIFF-SERVドメイン
- the outgoing interface of the LSP Egress is in the same Diff-Serv domain as the cloud downstream of it.
- LSP Egressの発信インターフェイスは、その下流のクラウドと同じDiff-Servドメインにあります。
Since each outgoing interface of the LSP Egress is in the same Diff-Serv domain as the cloud downstream of it, each outgoing interface may potentially be in a different Diff-Serv domain, and the LSP Egress needs to be configured with awareness of every corresponding Diff-Serv policy. This operational overhead is justified in some situations where the respective downstream Diff-Serv policies are better suited to offering service differentiation over each egress interface than the common Diff-Serv policy used on the LSP span. An example of such a situation is where a Service Provider offers an MPLS VPN service and where some VPN users request that their own VPN Diff-Serv policy be applied to control service differentiation on the dedicated link from the LSP Egress to the destination VPN site, rather than the Service Provider's Diff-Serv policy.
LSP Egressの各発信インターフェイスは、その下流のクラウドと同じDiff-Servドメインにあるため、各発信インターフェイスは潜在的に異なるDiff-Servドメインにある可能性があり、LSP Egressを対応するすべての意識を持って構成する必要があります。Diff-Servポリシー。この運用上のオーバーヘッドは、LSPスパンで使用される一般的なDIF-Servポリシーよりも、それぞれの下流のDiff-Servポリシーが各出口インターフェイスにわたってサービスの差別化を提供するのに適している状況で正当化されます。このような状況の例は、サービスプロバイダーがMPLS VPNサービスを提供し、一部のVPNユーザーが独自のVPN Diff-Servポリシーを適用して、LSP Egressから宛先VPNサイトへの専用リンクのサービス差別化を制御するよう要求する場所です。サービスプロバイダーの差別的なポリシーではなく。
The Short Pipe Model MAY be supported.
短いパイプモデルがサポートされる場合があります。
For support of the Short Pipe Model over a given LSP without PHP, an LSR performs the Incoming PHB Determination and the Diff-Serv information Encoding in the same manner as with the Pipe Model with the following exception:
PHPなしの特定のLSPでの短いパイプモデルをサポートするために、LSRは、次の例外を除いて、パイプモデルと同じ方法でエンコードする、着信PHB決定とdif-serv情報を実行します。
- when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the header (label entry or IP header) which is used to do the actual forwarding. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination AFTER the pop.
- ラベル付きパケットを受信すると、LSRは、実際の転送を行うために使用されるヘッダー（ラベルエントリまたはIPヘッダー）を考慮して、着信PHB決定を実行します。特に、考慮されたLSPに対してPOP操作を実行する場合、LSRはPOP後に着信PHB決定を実行します。
For support of the Short Pipe Model over a given LSP with PHP, an LSR performs Incoming PHB Determination and Diff-Serv information Encoding in the same manner as without PHP with the following exceptions:
PHPを備えた特定のLSPでの短いパイプモデルのサポートのために、LSRは、次の例外を除き、PHPなしでエンコードする受信PHB決定とdiff-serv情報を実行します。
- the Penultimate LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In other words, when a pop operation is to be performed for the considered LSP, the Penultimate LSR performs Incoming PHB Determination BEFORE the pop.
- 最後から2番目のLSRは、受信したラベルスタックの外側のラベルエントリを考慮して、着信PHB決定を実行します。言い換えれば、考慮されたLSPに対してPOP操作を実行する場合、最後から2番目のLSRは、POPの前に着信PHB決定を実行します。
Note that the behavior of the Penultimate LSR in the Short Pipe Mode with PHP, is identical to the behavior of the LSP Egress in the Pipe Mode (necessarily without PHP).
PHPを使用した短いパイプモードでの最後から2番目のLSRの動作は、パイプモードでのLSP出力の動作と同一であることに注意してください（必然的にPHPなし）。
With the Uniform Model, MPLS tunnels (aka LSPs) are viewed as artifacts of the end-to-end path from the Diff-Serv standpoint. MPLS Tunnels may be used for forwarding purposes but have no significant impact on Diff-Serv. In this model, any packet contains exactly one piece of Diff-Serv information which is meaningful and is always encoded in the outer most label entry (or in the IP DSCP where the IP packet is transmitted unlabelled for instance at the egress of the LSP). Any Diff-Serv information encoded somewhere else (e.g., in deeper label entries) is of no significance to intermediate nodes or to the tunnel egress and is ignored. If Traffic Conditioning at intermediate nodes on the LSP span affects the "outer" Diff-Serv information, the updated Diff-Serv information is the one considered meaningful at the egress of the LSP.
均一なモデルでは、MPLSトンネル（別名LSP）は、Diff-Servの観点からエンドツーエンドパスのアーティファクトと見なされます。MPLSトンネルは転送目的に使用できますが、diff-servに大きな影響はありません。このモデルでは、任意のパケットには、意味があり、常に最も多くのラベルエントリ（またはLSPの出口でIPパケットが非標識されているIP DSCPで常にエンコードされているdif-serv情報の1つが1つ含まれています。。どこかでエンコードされた差別的な情報（例えば、より深いラベルエントリ）は、中間ノードまたはトンネルの出口にとって重要ではなく、無視されます。LSPスパンの中間ノードでのトラフィックコンディショニングが「外側の」diff-serv情報に影響する場合、更新されたdiff-serv情報は、LSPの出口で意味があると見なされるものです。
Operation of the Uniform Model without PHP is illustrated below:
PHPのない統一モデルの操作を以下に示します。
========== LSP =============================>
---Swap--(M)--...-Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(M)--Push...............(x).......................Pop--(M)->
I (inner header) E
(M) represents the Meaningful Diff-Serv information encoded in the corresponding header. (x) represents non-meaningful Diff-Serv information. I represents the LSP ingress node E represents the LSP egress node
（m）は、対応するヘッダーにエンコードされた意味のあるdif-serv情報を表します。（x）は、意味のないdif-serv情報を表します。私はLSPイングレスノードeを表しますeはLSP Egressノードを表します
Operation of the Uniform Model with PHP is illustrated below:
PHPを使用した統一モデルの操作を以下に示します。
========== LSP =========================>
---Swap-(M)-...-Swap------
/ (outer header) \
(M) (M)
/ \
>--(M)--Push..............(x)............Pop-(M)--E--(M)->
I (inner header) P
(M) represents the Meaningful Diff-Serv information encoded in the corresponding header. (x) represents non-meaningful Diff-Serv information. I represents the LSP ingress node P represents the LSP penultimate node E represents the LSP egress node
（m）は、対応するヘッダーにエンコードされた意味のあるdif-serv情報を表します。（x）は、意味のないdif-serv情報を表します。私はLSPイングレスノードPを表し、LSPペラルテーションノードeはLSP出力ノードを表します
The Uniform Model for Diff-Serv over MPLS is such that, from the Diff-Serv perspective, operations are exactly identical to the operations if MPLS was not used. In other words, MPLS is entirely transparent to the Diff-Serv operations.
MPLS上のdiff-servの均一なモデルは、MPLSが使用されない場合、diff-servの観点から、操作が操作とまったく同じであるようなものです。言い換えれば、MPLSはDif-Serv操作に対して完全に透明です。
Use of the Uniform Model allows LSPs to span Diff-Serv domain boundaries without any other measure in place than an inter-domain Traffic Conditioning Agreement at the physical boundary between the Diff-Serv domains and operating exclusively on the "outer" header, since the meaningful Diff-Serv information is always visible and modifiable in the outmost label entry.
均一なモデルを使用すると、LSPは、Diff-Servドメイン間の物理的境界でのドメイン間トラフィックコンディショニング契約以外の測定値なしで、Diff-Servドメイン境界を範囲内に及ぼすことができます。意味のあるdiff-serv情報は、最大のラベルエントリで常に表示され、変更可能です。
The Uniform Model MAY be supported.
均一なモデルがサポートされる場合があります。
For support of the Uniform Model over a given LSP, an LSR performs Incoming PHB Determination and Diff-Serv information Encoding in the following manner:
特定のLSPで均一なモデルをサポートするために、LSRは、次の方法でエンコードする入っているPHB決定とdif-serv情報を実行します。
- when receiving an unlabelled packet, the LSR performs Incoming PHB Determination considering the received IP Header.
- 無効なパケットを受信するとき、LSRは受信したIPヘッダーを考慮して着信PHB決定を実行します。
- when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination BEFORE the pop.
- ラベル付きパケットを受信すると、LSRは受信したラベルスタックの外側ラベルエントリを考慮して、着信PHB決定を実行します。特に、考慮されたLSPに対してPOP操作を実行する場合、LSRはPOPの前に着信PHB決定を実行します。
- when performing a push operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry corresponding to the pushed label. The Diff-Serv Information encoded in the encapsulated header (swapped label entry or IP Header) is of no importance.
- 考慮されたLSPのプッシュ操作を実行するとき、LSRは、プッシュラベルに対応する送信されたラベルエントリにDiff-Serv情報をエンコードします。カプセル化されたヘッダー（交換されたラベルエントリまたはIPヘッダー）にエンコードされたDiff-Serv情報は重要ではありません。
- when performing a swap-only operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry that contains the swapped label.
- 考慮されたLSPのスワップのみの操作を実行するとき、LSRは、交換されたラベルを含む送信されたラベルエントリのDiff-Serv情報をエンコードします。
- when PHP is used, the Penultimate LSR needs to be aware of the "Set of PHB-->Encaps mappings" for the label corresponding to the exposed header (or the `PHB-->DSCP mapping') in order to perform Diff-Serv Information Encoding. Methods for providing this mapping awareness are outside the scope of this specification. As an example, the "PHB-->DSCP mapping" may be locally configured. As another example, in some environments, it may be appropriate for the Penultimate LSR to assume that the "Set of PHB-->Encaps mappings" to be used for the outgoing label in the exposed header is the "Set of PHB-->Encaps mappings" that would be used by the LSR if the LSR was not doing PHP. Note also that this specification assumes that the Penultimate LSR does not perform label swapping over the label entry exposed by the pop operation (and in fact that it does not even look at the exposed label). Consequently, restrictions may apply to the Diff-Serv Information Encoding that can be performed by the Penultimate LSR. For example, this specification does not allow situations where the Penultimate LSR pops a label corresponding to an E-LSP supporting two PSCs, while the header exposed by the pop contains label values for two L-LSPs each supporting one PSC, since the Diff-Serv Information Encoding would require selecting one label or the other.
- PHPを使用する場合、最後から2番目のLSRは、dif-を実行するために、露出したヘッダー（または `phb-> dscpマッピング '）に対応するラベルの「phb-> capsマッピングのセット」を認識する必要があります。情報エンコーディングを提供します。このマッピング認識を提供する方法は、この仕様の範囲外です。例として、「PHB - > DSCPマッピング」をローカルで構成することができます。別の例として、いくつかの環境では、最後から2番目のLSRが「PHB - > cankapsマッピングのセット」が、露出したヘッダーの発信ラベルに使用される「マッピングのマッピングのセット」が「PHBのセット - >LSRがPHPを実行していない場合、LSRが使用するEncaps Mappings "。また、この仕様では、最後から2番目のLSRがポップ操作によって露出したラベルエントリ上のラベルスワッピングを実行しないことを前提としています（実際、露出したラベルを見ないことさえありません）。その結果、最後から2番目のLSRが実行できるDiff-Serv情報エンコードに制限が適用される場合があります。たとえば、この仕様では、2つのPSCをサポートするE-LSPに対応するラベルを最後から2番目のPSCに対応するラベルをポップする状況は許可されていませんが、POPによって露出したヘッダーには、Diff-が1つのPSCをサポートする2つのL-LSPのラベル値が含まれています。サービスエンコードでは、1つのラベルを選択する必要があります。
Note that LSR behaviors for the Pipe, the Short Pipe and the Uniform Model only differ when doing a push or a pop. Thus, Intermediate LSRs which perform swap only operations for an LSP, behave in exactly the same way, regardless of whether they are behaving in the Pipe, Short Pipe or the Uniform model. With a Diff-Serv implementation supporting multiple Tunneling Models, only LSRs behaving as LSP Ingress, Penultimate LSR or LSP Egress need to be configured to operate in a particular Model. Signaling to associate a Diff-Serv tunneling model on a per-LSP basis is not within the scope of this specification.
パイプ、ショートパイプ、均一モデルのLSRの動作は、プッシュまたはポップを行う場合にのみ異なることに注意してください。したがって、LSPの操作のみをスワップする中間LSRは、パイプ、ショートパイプ、または均一モデルで動作しているかどうかに関係なく、まったく同じように動作します。複数のトンネリングモデルをサポートするDiff-Serv実装では、LSP侵入として動作するLSRのみが、特定のモデルで動作するように構成する必要があります。diff-servトンネルモデルをlspごとに関連付けるためのシグナリングは、この仕様の範囲内ではありません。
Through the label stack mechanism, MPLS allows LSP tunneling to nest to any depth. We observe that with such nesting, the push of level N+1 takes place on a subsequent (or the same) LSR to the LSR doing the push for level N, while the pop of level N+1 takes place on a previous (or the same) LSR to the LSR doing the pop of level N. For a given level N LSP, the Ingress LSR doing the push and the LSR doing the pop (Penultimate LSR or LSP Egress) must operate in the same Tunneling Model (i.e., Pipe, Short Pipe or Uniform). However, there is no requirement for consistent tunneling models across levels so that LSPs at different levels may be operating in different Tunneling Models.
ラベルスタックメカニズムを介して、MPLSを使用すると、LSPトンネリングが任意の深さに巣を作ることができます。このようなネストにより、レベルn 1のプッシュは、レベルnをプッシュするLSRに後続（または同じ）LSRで行われ、レベルn 1のポップは以前（または同じ）が発生することを観察します。）LSRへのLSRレベルNのPOPを実行します。特定のレベルN LSPについて、PUSHを行うIngress LSRはPOP（最後から2番目のLSRまたはLSP Egress）を行うLSRが同じトンネリングモデル（すなわち、パイプ、パイプ、パイプで動作する必要があります。短いパイプまたはユニフォーム）。ただし、レベル全体で一貫したトンネリングモデルの要件はありません。そのため、異なるレベルのLSPが異なるトンネルモデルで動作している可能性があります。
Hierarchical operations are illustrated below in the case of two levels of tunnels:
階層操作は、2つのレベルのトンネルの場合に以下に示されています。
+--------Swap--...---+
/ (outmost header) \
/ \
Push(2).................(2)Pop
/ (outer header) \
/ \
>>---Push(1)........................(1)Pop-->>
(inner header)
(1) Tunneling Model 1 (2) Tunneling Model 2
(1) トンネルモデル1（2）トンネリングモデル2
Tunneling Model 2 may be the same as or may be different from Tunneling Model 1.
トンネルモデル2は、トンネルモデル1と同じであるか、異なる場合があります。
For a given LSP of level N, the LSR must perform the Incoming PHB Determination and the Diff-Serv information Encoding as specified in section 2.6.2, 2.6.2.1 and 2.6.3 according to the Tunneling Model of this level N LSP and independently of the Tunneling Model of other level LSPs.
レベルnの特定のLSPについて、LSRは、このレベルN LSPのトンネルモデルに従って、セクション2.6.2、2.6.2.1、および2.6.3で指定されているように、着信PHB決定とDIF-Serv情報エンコードを実行する必要があり、独立して実行する必要があります。他のレベルLSPのトンネルモデルの。
E-LSPs are defined in section 1.2.
E-LSPはセクション1.2で定義されています。
Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the pre-configured mapping are capable of transporting the same common set of 8, or fewer, BAs. Each of those E-LSPs may actually transport this full set of BAs or any arbitrary subset of it.
特定のMPLS DIFF-SERVドメイン内で、事前に構成されたマッピングに依存するすべてのE-LSPは、8または少ないBASの同じ一般的なセットを輸送することができます。これらのe-LSPのそれぞれは、実際にこのBASの完全なセットまたはその任意のサブセットを輸送する場合があります。
For a given FEC, two given E-LSPs using a signaled `EXP<-->PHB mapping' can support the same or different sets of Ordered Aggregates.
与えられたFECの場合、2つの指定されたe-LSPは、シグナル付き「Exp < - > phbマッピング」を使用して、同じまたは異なる順序付けされた集合体をサポートできます。
This section defines how the `Encaps-->PHB mapping' of the Diff-Serv Context is populated for an incoming E-LSP in order to allow Incoming PHB determination.
このセクションでは、diff-servコンテキストの「> phbマッピング」が、着信PHBの決定を可能にするために、着信E-lspのためにどのように入力されるかを定義します。
The `Encaps-->PHB mapping' for an E-LSP is always of the form `EXP-->PHB mapping'.
e-lspの「cankaps-> phbマッピング」は、常に「exp-> phbマッピング」という形式です。
If the label corresponds to an E-LSP for which no `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the `EXP-->PHB mapping' is populated based on the Preconfigured `EXP<-->PHB mapping' which is discussed below in section 3.2.1.
ラベルがe-lspに対応している場合、「exp <> phbマッピング」がLSPセットアップで明示的に信号を送られていない場合、「exp-> phbマッピング」は、事前に設定された `exp < - >に基づいて入力されます。PHBマッピング ''セクション3.2.1で以下で説明します。
If the label corresponds to an E-LSP for which an `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the `EXP-->PHB mapping' is populated as per the signaled `EXP<-->PHB mapping'.
ラベルが「exp <> phbマッピング」がLSPセットアップで明示的に信号を送られているe-lspに対応する場合、「exp-> phbマッピング」が信号された「exp < - >PHBマッピング '。
LSRs supporting E-LSPs which use the preconfigured `EXP<-->PHB mapping' must allow local configuration of this `EXP<-->PHB mapping'. This mapping applies to all the E-LSPs established on this LSR without a mapping explicitly signaled at set-up time.
事前に設定された `exp < - > phbマッピング 'を使用するe-LSPをサポートするLSRSは、この「exp < - > phbマッピング」のローカル構成を可能にする必要があります。このマッピングは、セットアップ時に明示的にマッピングを行うことなく、このLSRに確立されたすべてのE-LSPに適用されます。
The preconfigured `EXP<-->PHB mapping' must either be consistent at every E-LSP hop throughout the MPLS Diff-Serv domain spanned by the LSP or appropriate remarking of the EXP field must be performed by the LSR whenever a different preconfigured mapping is used on the ingress and egress interfaces.
事前に設定された「EXP < - > PHBマッピング」は、LSPによって範囲されたMPLS DIFF-SERVドメイン全体のすべてのE-LSPホップで一貫性がある必要があります。入り口と出口のインターフェイスで使用されます。
In case, the preconfigured `EXP<-->PHB mapping' has not actually been configured by the Network Administrator, the LSR should use a default preconfigured `EXP<-->PHB mapping' which maps all EXP values to the Default PHB.
場合には、事前に設定された「Exp < - > PHBマッピング」が実際にネットワーク管理者によって構成されていない場合、LSRはすべてのEXP値をデフォルトのPHBにマッピングするデフォルトの事前に構成された「EXP < - > PHBマッピング」を使用する必要があります。
This section defines how Incoming PHB Determination is carried out when the considered label entry in the received label stack corresponds to an E-LSP. This requires that the `Encaps-->PHB mapping' is populated as defined in section 3.2.
このセクションでは、受信したラベルスタックの考慮されたラベルエントリがE-LSPに対応する場合、受信PHB決定がどのように実行されるかを定義します。これには、「cankaps - > phbマッピング」がセクション3.2で定義されているように入力される必要があります。
When considering a label entry corresponding to an incoming E-LSP for Incoming PHB Determination, the LSR:
着信PHB決定のために着信E-LSPに対応するラベルエントリを検討する場合、LSR：
- determines the `EXP-->PHB mapping' by looking up the `Encaps-->PHB mapping' of the Diff-Serv Context associated in the ILM with the considered incoming E-LSP label.
- ILMに関連付けられたDIFF-Servコンテキストの「cancaps-> phbマッピング」を検索して、考慮されたE-LSPラベルと「> PHBマッピング」を調べることにより、「exp-> phbマッピング」を決定します。
- determines the incoming PHB by looking up the EXP field of the considered label entry in the `EXP-->PHB mapping' table.
- 「EXP-> PHBマッピング」テーブルにある考慮されたラベルエントリのEXPフィールドを調べることにより、着信PHBを決定します。
This section defines how the `Set of PHB-->Encaps mappings' of the Diff-Serv Context is populated at label setup for an outgoing E-LSP in order to allow Encoding of Diff-Serv information in the Encapsulation Layer.
このセクションでは、diff-servコンテキストの「phb - > cankapsマッピングのセット」が、カプセル化レイヤーのdiff-serv情報のエンコードを可能にするために、発信e-lspのラベルセットアップにどのように入力されるかを定義します。
An outgoing E-LSP must always have a `PHB-->EXP mapping' as part of the `Set of PHB-->Encaps mappings' of its Diff-Serv Context.
発信e-LSPには、dif-servコンテキストの「phb - > cankapsマッピング」の一部として、常に「phb - > expマッピング」が必要です。
If the label corresponds to an E-LSP for which no `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, this `PHB-->EXP mapping' is populated based on the Preconfigured `EXP<-->PHB mapping' which is discussed above in section 3.2.1.
ラベルがe-lspに対応している場合、「exp <> phbマッピング」がLSPセットアップで明示的に信号を送られていない場合、この「phb - > expマッピング」は、事前に設定された `exp <->に基づいて入力されます。上記のセクション3.2.1で説明したPHBマッピング '。
If the label corresponds to an E-LSP for which an `EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the `PHB-->EXP mapping' is populated as per the signaled `EXP<-->PHB mapping'.
ラベルが「exp <> phbマッピング」がLSPセットアップで明示的に信号を送られているe-lspに対応する場合、「phb - > expマッピング」が信号された「exp < - >PHBマッピング '。
If the LSP is egressing over an ATM interface which is not label switching controlled, then one `PHB-->CLP mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing LSP. This `PHB-->CLP mapping' is populated in the following way:
LSPがラベルスイッチング制御ではないATMインターフェイスを脱出している場合、1つの「PHB - > CLPマッピング」が、この発信LSPの「PHB-> clpマッピング」セットに追加されます。この「phb - > clpマッピング」は、次の方法で入力されます。
- it is a function of the PHBs supported on this LSP, and may use the relevant mapping entries for these PHBs from the Default `PHB-->CLP mapping' defined in section 3.4.2.1. Mappings other than the one defined in section 3.4.2.1 may be used. In particular, if a mapping from PHBs to CLP is standardized in the future for operations of Diff-Serv over ATM, such a standardized mapping may then be used.
- これは、このLSPでサポートされているPHBの関数であり、セクション3.4.2.1で定義されたデフォルトの「PHB - > CLPマッピング」からこれらのPHBの関連マッピングエントリを使用する場合があります。セクション3.4.2.1で定義されているもの以外のマッピングを使用できます。特に、PHBからCLPへのマッピングが将来、ATMを介したDiff-Servの運用のために標準化されている場合、そのような標準化されたマッピングを使用する場合があります。
For example if the outgoing label corresponds to an LSP supporting the AF1 PSC, then the `PHB-->CLP mapping' may be populated with:
たとえば、発信ラベルがAF1 PSCをサポートするLSPに対応している場合、「PHB - > CLPマッピング」に次のように入力される場合があります。
PHB CLP Field
PHB CLPフィールド
AF11 ----> 0
AF12 ----> 1
AF13 ----> 1
EF ----> 0
Notice that in this case the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'.
この場合、「PHBのセット - > cankapsマッピング」には、「phb - > expマッピング」と「phb-> clpマッピング」の両方が含まれていることに注意してください。
PHB CLP Bit
PHB CLPビット
DF ----> 0
CSn ----> 0
AFn1 ----> 0
AFn2 ----> 1
AFn3 ----> 1
EF ----> 0
If the LSP is egressing over a Frame Relay interface which is not label switching controlled, one `PHB-->DE mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing LSP and is populated in the following way:
ラベルスイッチング制御ではないフレームリレーインターフェイスにLSPが脱出している場合、1つの「PHB-> deマッピング」がこの発信LSPの「PHBのセット」に追加され、次のように追加されます。方法：
- it is a function of the PHBs supported on this LSP, and may use the relevant mapping entries for these PHBs from the Default `PHB-->DE mapping' defined in section 3.4.3.1. Mappings other than the one defined in section 3.4.3.1 may be used. In particular, if a mapping from PHBs to DE is standardized in the future for operations of Diff-Serv over Frame Relay, such a standardized mapping may then be used.
- これは、このLSPでサポートされているPHBの関数であり、セクション3.4.3.1で定義されているデフォルトの「PHB - > deマッピング」からこれらのPHBの関連マッピングエントリを使用する場合があります。セクション3.4.3.1で定義されているもの以外のマッピングを使用できます。特に、PHBからDEへのマッピングが将来、Diff-Servオーバーフレームリレーの操作のために標準化されている場合、そのような標準化されたマッピングを使用する場合があります。
Notice that in this case the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'.
この場合、「PHBのセット - > cankapsマッピング」には、「phb - > expマッピング」と「phb-> deマッピング」の両方が含まれていることに注意してください。
PHB DE Bit
phb de bit
DF ----> 0
CSn ----> 0
AFn1 ----> 0
AFn2 ----> 1
AFn3 ----> 1
EF ----> 0
If the LSP is egressing over a LAN interface on which multiple 802.1 Traffic Classes are supported as per [IEEE_802.1], then one `PHB-->802.1 mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing LSP. This `PHB-->802.1 mapping' is populated in the following way:
LSPが[IEEE_802.1]に従って複数の802.1トラフィッククラスがサポートされているLANインターフェイスに脱出している場合、1つの「PHB - > 802.1マッピング」が「PHBのセット」に追加されます。この発信LSP。この「PHB - > 802.1マッピング」は、次のように入力されています。
- it is a function of the PHBs supported on this LSP, and uses the relevant mapping entries for these PHBs from the Preconfigured `PHB-->802.1 mapping' defined in section 3.4.4.1.
- これは、このLSPでサポートされているPHBの関数であり、セクション3.4.4.1で定義されている事前に構成された「PHB - > 802.1マッピング」からこれらのPHBの関連マッピングエントリを使用します。
Notice that the `Set of PHB-->Encaps mappings' then contains both a `PHB-->EXP mapping' and a `PHB-->802.1 mapping'.
「PHBのセット - > cankapsマッピング」には、「phb - > expマッピング」と「phb-> 802.1マッピング」の両方が含まれていることに注意してください。
At the time of producing this specification, there are no standardized mapping from PHBs to 802.1 Traffic Classes. Consequently, an LSR supporting multiple 802.1 Traffic Classes over LAN interfaces must allow local configuration of a `PHB-->802.1 mapping'. This mapping applies to all the outgoing LSPs established by the LSR on such LAN interfaces.
この仕様の作成時には、PHBから802.1トラフィッククラスへの標準化されたマッピングはありません。その結果、LANインターフェイス上の複数の802.1トラフィッククラスをサポートするLSRは、「PHB - > 802.1マッピング」のローカル構成を可能にする必要があります。このマッピングは、このようなLANインターフェイス上のLSRによって確立されたすべての発信LSPに適用されます。
This section defines how to encode Diff-Serv information into the MPLS encapsulation Layer for a given transmitted label entry corresponding to an outgoing E-LSP. This requires that the `Set of PHB-->Encaps mappings' be populated as defined in section 3.4.
このセクションでは、発信E-LSPに対応する特定の送信されたラベルエントリのMPLSカプセル化レイヤーにdiff-serv情報をエンコードする方法を定義します。これには、セクション3.4で定義されているように、「PHB - > cankApsマッピングのセット」を入力する必要があります。
The LSR first determines the `Set of PHB-->Encaps mappings' of the Diff-Serv Context associated with the corresponding label in the NHLFE.
LSRは、最初に、NHLFEの対応するラベルに関連付けられたDIF-ServコンテキストのPHB - > capsマッピングのセット」を決定します。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->EXP mapping', then the LSR:
「PHBのセット - > cankapsマッピング」に「phb-> expマッピング」という形式のマッピングが含まれている場合、LSR：
- determines the value to be written in the EXP field of the corresponding level label entry by looking up the "outgoing PHB" in this `PHB-->EXP mapping' table.
- この「PHB - > expマッピング」テーブルの「発信PHB」を調べることにより、対応するレベルラベルエントリのEXPフィールドに記述する値を決定します。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->CLP mapping', then the LSR:
「PHBのセット - > cankapsマッピング」に「phb-> clpマッピング」という形式のマッピングが含まれている場合、LSR：
- determines the value to be written in the CLP field of the ATM encapsulation header, by looking up the "outgoing PHB" in this `PHB-->CLP mapping' table.
- この「PHB - > CLPマッピング」テーブルの「発信PHB」を調べることにより、ATMカプセル化ヘッダーのCLPフィールドに記述される値を決定します。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->DE mapping', then the LSR:
「PHBのセット - > cankapsマッピング」に「phb-> deマッピング」という形式のマッピングが含まれている場合、LSR：
- determines the value to be written in the DE field of the Frame Relay encapsulation header, by looking up the "outgoing PHB" in this `PHB-->DE mapping' table.
- この「PHB - > deマッピング」テーブルの「発信PHB」を調べることにより、フレームリレーカプセル化ヘッダーのDEフィールドに記述される値を決定します。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->802.1 mapping', then the LSR:
「PHBのセット - > cankapsマッピング」に、「phb-> 802.1マッピング」という形式のマッピングが含まれている場合、LSR：
- determines the value to be written in the User_Priority field of the Tag Control Information of the 802.1 encapsulation header [IEEE_802.1], by looking up the "outgoing PHB" in this 'PHB-- >802.1 mapping' table.
- この「PHB - > 802.1マッピング」テーブルの「発信PHB」を調べることにより、802.1カプセル化ヘッダー[IEEE_802.1]のタグ制御情報のユーザー_Priorityフィールドに記述される値を決定します。
In an MPLS domain, two or more LSPs can be merged into one LSP at one LSR. E-LSPs are compatible with LSP Merging under the following condition:
MPLSドメインでは、2つ以上のLSPを1つのLSRで1つのLSPにマージできます。E-LSPは、次の条件下でLSPの合併と互換性があります。
E-LSPs can only be merged into one LSP if they support the exact same set of BAs.
E-LSPは、まったく同じBASセットをサポートする場合にのみ1つのLSPにマージできます。
For E-LSPs using a signaled `EXP<-->PHB mapping', the above merge condition MUST be enforced by LSRs through explicit checking at label setup that the exact same set of PHBs is supported on the merged LSPs.
シグナル付き「Exp < - > PHBマッピング」を使用したe-LSPの場合、上記のマージ条件は、ラベルセットアップでの明示的なチェックを通じて、マージされたLSPでまったく同じPHBセットがサポートされていることを明示的にチェックすることにより、LSRによって強制する必要があります。
For E-LSPs using the preconfigured `EXP<-->PHB mapping', since the PHBs supported over an E-LSP is not signaled at establishment time, an LSR can not rely on signaling information to enforce the above merge. However all E-LSPs using the preconfigured `EXP<-->PHB mapping' are required to support the same set of Behavior Aggregates within a given MPLS Diff-Serv domain. Thus, merging of E-LSPs using the preconfigured `EXP<-->PHB mapping' is allowed within a given MPLS Diff-Serv domain.
E-LSPでサポートされているPHBは確立時にシグナルが行われないため、事前に設定された「Exp < - > PHBマッピング」を使用したE-LSPの場合、LSRは上記のマージを強制するためにシグナル情報に依存することはできません。ただし、特定のMPLS DIFF-SERVドメイン内で同じ一連の動作集合体をサポートするには、事前に設定された「Exp < - > PHBマッピング」を使用するすべてのE-LSPが必要です。したがって、事前に構成された「Exp < - > PHBマッピング」を使用したE-LSPのマージは、特定のMPLS DIFF-SERVドメイン内で許可されます。
L-LSPs are defined in section 1.3.
L-LSPはセクション1.3で定義されています。
This section defines how the `Encaps-->PHB mapping' of the Diff-Serv Context is populated at label setup for an incoming L-LSP in order to allow Incoming PHB determination.
このセクションでは、diff-servコンテキストの「> phbマッピング」が、着信PHBの決定を可能にするために、着信L-lspのラベルセットアップでどのように入力されるかを定義します。
If the LSR terminates the MPLS Shim Layer over this incoming L-LSP and the L-LSP ingresses on an interface which is not ATM nor Frame Relay, then the `Encaps-->PHB mapping' is populated in the following way:
LSRがMPLSシム層をこの着信L-LSPの上に終了し、L-LSPがATMでもフレームリレーでもないインターフェイスに侵入した場合、「cankaps-> phbマッピング」が次のように入力されます。
- it is actually a `EXP-->PHB mapping'
- それは実際には「exp-> phbマッピング」です
- this mapping is a function of the PSC which is carried on this LSP, and must use the relevant mapping entries for this PSC from the Mandatory `EXP/PSC-->PHB mapping' defined in Section 4.2.1.1.
- このマッピングは、このLSPに掲載されているPSCの関数であり、このPSCの関連するマッピングエントリを必須の「EXP/PSC-> PHBマッピング」からセクション4.2.1.1で定義する必要があります。
For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with:
たとえば、着信ラベルがAF1 PSCをサポートするL-LSPに対応している場合、「cankaps-> phbマッピング」に次のように入力されます。
EXP Field PHB
ExpフィールドPhb
001 ----> AF11
010 ----> AF12
011 ----> AF13
An LSR, supporting L-LSPs over PPP interfaces and LAN interfaces, is an example of an LSR terminating the Shim layer over ingress interfaces which are not ATM nor Frame Relay.
PPPインターフェイスとLANインターフェイスでL-LSPをサポートするLSRは、ATMでもフレームリレーでもない侵入インターフェイス上のシム層を終了するLSRの例です。
If the LSR terminates the MPLS Shim Layer over this incoming L-LSP and the L-LSP ingresses on an ATM or Frame Relay interface, then the `Encaps-->PHB mapping' is populated in the following way:
LSRがこの入っているL-LSPの上にMPLSシム層を終了し、L-LSPがATMまたはフレームリレーインターフェイスに侵入すると、「cankaps-> phbマッピング」は次のように入力されます。
- it should actually be a `EXP-->PHB mapping'. Alternative optional ways of populating the `Encaps-->PHB mapping' might be defined in the future (e.g., using a 'CLP/EXP--> PHB mapping' or a 'DE/EXP-->PHB mapping') but are outside the scope of this document.
- 実際には「exp-> phbマッピング」である必要があります。「clp/exp-> phbマッピング」または「de/exp-> phbマッピング」を使用する「clp/exp-> phbマッピング」を使用する「clbマッピング」を「> phbマッピング」に入力する代替オプションの方法は定義される可能性がありますが、このドキュメントの範囲外。
- when the `Encaps-->PHB mapping' is an `EXP-->PHB mapping', this `EXP-->PHB mapping' mapping is a function of the PSC which is carried on the L-LSP, and must use the relevant mapping entries for this PSC from the Mandatory `EXP/PSC-->PHB mapping' defined in Section 4.2.1.1.
- `cankaps-> phbマッピング 'が「exp-> phbマッピング」である場合、この「exp-> phbマッピング」マッピングは、l-lspに携帯されているpscの関数であり、セクション4.2.1.1で定義されている必須の「EXP/PSC-> PHBマッピング」からのこのPSCの関連マッピングエントリ。
An Edge-LSR of an ATM-MPLS domain or of a FR-MPLS domain is an example of an LSR terminating the shim layer over an ingress ATM/FR interface.
ATM-MPLSドメインまたはFR-MPLSドメインのEdge-LSRは、Ingress ATM/FRインターフェイスの上でシム層を終了するLSRの例です。
EXP Field PSC PHB
ExpフィールドPSC PHB
000 DF ----> DF
000 CSn ----> CSn
001 AFn ----> AFn1
010 AFn ----> AFn2
011 AFn ----> AFn3
000 EF ----> EF
If the LSR does not terminate an MPLS Shim Layer over this incoming label and uses ATM encapsulation (i.e., it is an ATM-LSR), then the `Encaps-->PHB mapping' for this incoming L-LSP is populated in the following way:
LSRがこの着信ラベルの上にMPLSシム層を終了せず、ATMカプセル化（つまり、ATM-LSR）を使用している場合、この着信L-LSPの「cankaps-> phbマッピング」が次のように入力されます。方法：
- it is actually a `CLP-->PHB mapping'
- それは実際には「clp-> phbマッピング」です
- the mapping is a function of the PSC, which is carried on this LSP, and should use the relevant mapping entries for this PSC from the Default `CLP/PSC-->PHB mapping' defined in Section 4.2.2.1.
- マッピングは、このLSPに掲載されているPSCの関数であり、セクション4.2.2.1で定義されているデフォルトの「CLP/PSC-> PHBマッピング」からこのPSCの関連マッピングエントリを使用する必要があります。
For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' should be populated with:
たとえば、着信ラベルがAF1 PSCをサポートするL-LSPに対応している場合、「cankaps-> phbマッピング」に次のように入力する必要があります。
CLP Field PHB
CLPフィールドPHB
0 ----> AF11
1 ----> AF12
CLP Bit PSC PHB
CLP BIT PSC PHB
0 DF ----> DF
0 CSn ----> CSn
0 AFn ----> AFn1
1 AFn ----> AFn2
0 EF ----> EF
If the LSR does not terminate an MPLS Shim Layer over this incoming label and uses Frame Relay encapsulation (i.e., it is a FR-LSR), then the `Encaps-->PHB mapping' for this incoming L-LSP is populated in the following way:
LSRがこの着信ラベルの上にMPLSシム層を終了せず、フレームリレーカプセル化（つまり、FR-LSR）を使用している場合、この着信l-lspの「cankaps-> phbマッピング」は、次のように：
- it is actually a `DE-->PHB mapping'
- それは実際には「de-> phbマッピング」です
- the mapping is a function of the PSC which is carried on this LSP, and should use the relevant mapping entries for this PSC from the Default `DE/PSC-->PHB mapping' defined in Section 4.2.3.1.
- マッピングは、このLSPに掲載されているPSCの関数であり、セクション4.2.3.1で定義されているデフォルトの「DE/PSC-> PHBマッピング」からこのPSCの関連マッピングエントリを使用する必要があります。
DE Bit PSC PHB
de bit psc phb
0 DF ----> DF
0 CSn ----> CSn
0 AFn ----> AFn1
1 AFn ----> AFn2
0 EF ----> EF
This section defines how Incoming PHB determination is carried out when the considered label entry in the received label stack corresponds to an L-LSP. This requires that the `Encaps-->PHB mapping' is populated as defined in section 4.2.
このセクションでは、受信したラベルスタックの考慮されたラベルエントリがL-LSPに対応する場合、受信PHB決定がどのように実行されるかを定義します。これには、「cankaps - > phbマッピング」がセクション4.2で定義されているように入力される必要があります。
When considering a label entry corresponding to an incoming L-LSP for Incoming PHB Determination, the LSR first determines the `Encaps-->PHB mapping' associated with the corresponding label.
着信PHB決定のための着信L-LSPに対応するラベルエントリを検討する場合、LSRは最初に、対応するラベルに関連付けられた「cankaps-> phbマッピング」を決定します。
If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping', then the LSR:
「cankaps-> phbマッピング」が「exp-> phbマッピング」の形式である場合、LSR：
- determines the incoming PHB by looking at the EXP field of the considered label entry and using the `EXP-->PHB mapping'.
- 考慮されたラベルエントリのEXPフィールドを調べ、「EXP-> PHBマッピング」を使用して、着信PHBを決定します。
If the `Encaps-->PHB mapping' is of the form `CLP-->PHB mapping', then the LSR:
`cankaps-> phbマッピング」が「clp-> phbマッピング」の形式である場合、LSR：
- determines the incoming PHB by looking at the CLP field of the ATM Layer encapsulation and using the `CLP-->PHB mapping'.
- ATM層のカプセル化のCLPフィールドを調べ、「CLP-> PHBマッピング」を使用して、着信PHBを決定します。
If the `Encaps-->PHB mapping' is of the form `DE-->PHB mapping', then the LSR:
「cankaps-> phbマッピング」が「de-> phbマッピング」の形式である場合、LSR：
- determines the incoming PHB by looking at the DE field of the Frame Relay encapsulation and by using the `DE-->PHB mapping'.
- フレームリレーカプセル化のDEフィールドを調べ、「DE-> PHBマッピング」を使用して、着信PHBを決定します。
This section defines how the `Set of PHB-->Encaps mappings' of the Diff-Serv Context is populated at label setup for an outgoing L-LSP in order to allow Encoding of Diff-Serv Information.
このセクションでは、diff-servコンテキストの「phb - > cankapsマッピングのセット」が、diff-serv情報のエンコードを可能にするために、発信l-lspのラベルセットアップにどのように存在するかを定義します。
If the LSR uses an MPLS Shim Layer over this outgoing L-LSP, then one `PHB-->EXP mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing L-LSP. This `PHB-->EXP mapping' is populated in the following way:
LSRがこの発信l-LSPにMPLSシム層を使用する場合、この発信l-lspの「phb - > expマッピング」が「phb - > cankapsマッピング」に追加されます。この「phb - > expマッピング」は、次の方法で入力されます。
- it is a function of the PSC supported on this LSP, and must use the mapping entries relevant for this PSC from the Mandatory `PHB-->EXP mapping' defined in section 4.4.1.1.
- これは、このLSPでサポートされているPSCの関数であり、セクション4.4.1.1で定義されている必須の「> expマッピング」からこのPSCに関連するマッピングエントリを使用する必要があります。
For example, if the outgoing label corresponds to an L-LSP supporting the AF1 PSC, then the following `PHB-->EXP mapping' is added into the `Set of PHB-->Encaps mappings':
たとえば、発信ラベルがAF1 PSCをサポートするL-LSPに対応している場合、次の「PHB - > Expマッピング」が「PHBのセット - > capsマッピング」に追加されます。
PHB EXP Field
PHB Expフィールド
AF11 ----> 001
AF12 ----> 010
AF13 ----> 011
PHB EXP Field
PHB Expフィールド
DF ----> 000
CSn ----> 000
AFn1 ----> 001
AFn2 ----> 010
AFn3 ----> 011
EF ----> 000
If the L-LSP is egressing on an ATM interface (i.e., it is an ATM-LSR or it is a frame-based LSR sending packets on an LC-ATM interface or on an ATM interface which is not label switching controlled), then one `PHB-->CLP mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing L-LSP.
L-LSPがATMインターフェイスで脱出している場合（つまり、ATM-LSRであるか、LC-ATMインターフェイスまたはラベルスイッチング制御ではないATMインターフェイスでパケットを送信するフレームベースのLSRである場合）この発信l-lspの「phb - > clpマッピング」が「phbのセット - > cankapsマッピング」に追加されます。
If the L-LSP is egressing over an ATM interface which is not label-controlled, the `PHB-->CLP mapping' is populated as per section 3.4.2.
l-lspがラベル制御されていないATMインターフェイスに脱出している場合、「phb - > clpマッピング」がセクション3.4.2に従って入力されます。
If the L-LSP is egressing over an LC-ATM interface, the `PHB-->CLP mapping' is populated in the following way:
L-LSPがLC-ATMインターフェイスで脱出している場合、「PHB - > CLPマッピング」が次の方法で入力されます。
- it is a function of the PSC supported on this LSP, and should use the relevant mapping entries for this PSC from the Default `PHB-->CLP mapping' defined in section 3.4.2.1.
- これは、このLSPでサポートされているPSCの関数であり、セクション3.4.2.1で定義されたデフォルトの「PHB - > CLPマッピング」からこのPSCの関連マッピングエントリを使用する必要があります。
Notice that if the LSR is a frame-based LSR supporting an L-LSP egressing over an ATM interface, then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'. If the LSR is an ATM-LSR supporting an L-LSP, then the `Set of PHB-->Encaps mappings' only contains a `PHB-->CLP mapping'.
LSRがATMインターフェイス上で脱出するL-LSPをサポートするフレームベースのLSRである場合、PHBのセット - > cankApsマッピング 'には、「phb - > expマッピング」と `phb-の両方が含まれていることに注意してください。 - > CLPマッピング '。LSRがL-LSPをサポートするATM-LSRである場合、「PHBのセット - > cankapsマッピング」には「PHB - > CLPマッピング」のみが含まれます。
If the L-LSP is egressing over a Frame Relay interface (i.e., it is an LSR sending packets on an LC-FR interface or on a Frame Relay interface which is not label switching controlled), one `PHB-->DE mapping' is added to the `Set of PHB-->Encaps mappings' for this outgoing L-LSP.
L-LSPがフレームリレーインターフェイスにびらんを脱出している場合（つまり、LC-FRインターフェイスまたはラベルスイッチング制御ではないフレームリレーインターフェイスでPacketを送信するLSRです）、1つの「PHB - > DeMapping」この発信l-lspの「phbのセット - > cankapsマッピング」に追加されます。
If the L-LSP is egressing over a FR interface which is not label switching controlled, the `PHB-->DE mapping' is populated as per section 3.4.3.
l-lspがラベルスイッチング制御ではないFRインターフェイスに脱出している場合、「phb - > deマッピング」がセクション3.4.3に従って入力されます。
If the L-LSP is egressing over an LC-FR interface, the `PHB-->DE mapping' is populated in the following way:
L-LSPがLC-FRインターフェイスで脱出している場合、「PHB - > deマッピング」が次の方法で入力されます。
- it is a function of the PSC supported on this LSP, and should use the relevant mapping entries for this PSC from the Default `PHB-->DE mapping' defined in section 3.4.3.1.
- これは、このLSPでサポートされているPSCの関数であり、セクション3.4.3.1で定義されているデフォルトの「PHB - > deマッピング」からこのPSCの関連マッピングエントリを使用する必要があります。
Notice that if the LSR is an Edge-LSR supporting an L-LSP egressing over a LC-FR interface, then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. If the LSR is a FR-LSR supporting an L-LSP, then the `Set of PHB-->Encaps mappings' only contains a `PHB-->DE mapping'.
LSRがLC-FRインターフェイス上で脱出するL-LSPをサポートするEDGE-LSRである場合、「PHB - > cankapsマッピングのセット」には「phb - > expマッピング」とphbの両方が含まれています。 - > de Mapping '。LSRがL-LSPをサポートするFR-LSRである場合、「PHBのセット - > cankapsマッピング」には「phb - > deマッピング」のみが含まれます。
If the LSP is egressing over a LAN interface on which multiple 802.1 Traffic Classes are supported, as defined in [IEEE_802.1], then one `PHB-->802.1 mapping' is added as per section 3.4.4.
[IEEE_802.1]で定義されているように、複数の802.1トラフィッククラスがサポートされているLANインターフェイスにLSPが脱出している場合、セクション3.4.4に従って1つの「PHB - > 802.1マッピング」が追加されます。
This section defines how to encode Diff-Serv information into the MPLS encapsulation Layer for a transmitted label entry corresponding to an outgoing L-LSP. This requires that the `Set of PHB-->Encaps mappings' is populated as defined in section 4.4.
このセクションでは、発信L-LSPに対応する送信されたラベルエントリのMPLSカプセル化レイヤーにdiff-serv情報をエンコードする方法を定義します。これには、「PHBのセット - > cankapsマッピング」がセクション4.4で定義されているように入力される必要があります。
The LSR first determines the `Set of PHB-->Encaps mappings' of the Diff-Serv Context associated with the corresponding label in the NHLFE and then performs corresponding encoding as specified in sections 3.5.1, 3.5.2, 3.5.3 and 3.5.4.
LSRは最初に、NHLFEの対応するラベルに関連付けられたDIF-Servコンテキストの「PHB - > cankApsマッピングのセット」を決定し、セクション3.5.1、3.5.2、3.5.3、およびセクションで指定されているように対応するエンコードを実行します。3.5.4。
In an MPLS domain, two or more LSPs can be merged into one LSP at one LSR. L-LSPs are compatible with LSP Merging under the following condition:
MPLSドメインでは、2つ以上のLSPを1つのLSRで1つのLSPにマージできます。L-LSPは、次の条件下でLSPの合併と互換性があります。
L-LSPs can only be merged into one L-LSP if they support the same PSC.
L-LSPは、同じPSCをサポートしている場合にのみ1つのLSPにマージできます。
The above merge condition MUST be enforced by LSRs, through explicit checking at label setup, that the same PSC is supported on the merged LSPs.
上記のマージ条件は、ラベルセットアップでの明示的なチェックを通じて、同じPSCがマージされたLSPでサポートされていることをLSRによって強制する必要があります。
Note that when L-LSPs merge, the bandwidth that is available for the PSC downstream of the merge point must be sufficient to carry the sum of the merged traffic. This is particularly important in the case of EF traffic. This can be ensured in multiple ways (for instance via provisioning, or via bandwidth signaling and explicit admission control).
L-LSPがマージする場合、マージポイントの下流のPSCが使用できる帯域幅は、マージされたトラフィックの合計を運ぶのに十分でなければならないことに注意してください。これは、EFトラフィックの場合に特に重要です。これは、複数の方法で確保できます（たとえば、プロビジョニングを介して、または帯域幅のシグナル伝達と明示的な加入制御を介して）。
The MPLS architecture does not assume a single label distribution protocol. [RSVP_MPLS_TE] defines the extension to RSVP for establishing LSPs in MPLS networks. This section specifies the extensions to RSVP, beyond those defined in [RSVP_MPLS_TE], to establish LSPs supporting Differentiated Services in MPLS networks.
MPLSアーキテクチャは、単一のラベル分布プロトコルを想定していません。[RSVP_MPLS_TE] MPLSネットワークでLSPを確立するためのRSVPへの拡張機能を定義します。このセクションでは、MPLSネットワークで差別化されたサービスをサポートするLSPを確立するために、[rsvp_mpls_te]で定義されているものを超えたRSVPへの拡張機能を指定します。
One new RSVP Object is defined in this document: the DIFFSERV Object. Detailed description of this Object is provided below. This new Object is applicable to Path messages. This specification only defines the use of the DIFFSERV Object in Path messages used to establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 and containing a LABEL_REQUEST object.
このドキュメントでは、1つの新しいRSVPオブジェクトが定義されています：diffservオブジェクト。このオブジェクトの詳細な説明を以下に示します。この新しいオブジェクトは、パスメッセージに適用できます。この仕様は、[rsvp_mpls_te]に従ってLSPトンネルを確立するために使用されるパスメッセージでのdiffservオブジェクトの使用のみを定義します。したがって、lsp_tunnel_ipv4に等しいCタイプのセッションオブジェクトを含み、label_requestオブジェクトを含みます。
Restrictions defined in [RSVP_MPLS_TE] for support of the establishment of LSP Tunnels via RSVP are also applicable to the establishment of LSP Tunnels supporting Diff-Serv: for instance, only unicast LSPs are supported and Multicast LSPs are for further study.
RSVPを介したLSPトンネルの確立をサポートするために[rsvp_mpls_te]で定義されている制限は、Diff-servをサポートするLSPトンネルの確立にも適用できます。たとえば、ユニキャストLSPのみがサポートされ、マルチリカストLSPはさらなる研究に適しています。
This new DIFFSERV object is optional with respect to RSVP so that general RSVP implementations not concerned with MPLS LSP set up do not have to support this object.
この新しいDiffServオブジェクトは、RSVPに関してオプションであるため、MPLS LSPのセットアップに関係のない一般的なRSVP実装は、このオブジェクトをサポートする必要がありません。
The DIFFSERV Object is optional for support of LSP Tunnels as defined in [RSVP_MPLS_TE]. A Diff-Serv capable LSR supporting E-LSPs using the preconfigured `EXP<-->PHB mapping' in compliance with this specification MAY support the DIFFSERV Object. A Diff-Serv capable LSR supporting E-LSPs using a signaled `EXP<-->PHB mapping' in compliance with this specification MUST support the DIFFSERV Object. A Diff-Serv capable LSR supporting L-LSPs in compliance with this specification MUST support the DIFFSERV Object.
[rsvp_mpls_te]で定義されているLSPトンネルのサポートのために、diffservオブジェクトはオプションです。この仕様に準拠して、事前に構成された「Exp < - > PHBマッピング」を使用してE-LSPをサポートするDiff-Serv対応LSRは、DiffServオブジェクトをサポートする場合があります。この仕様に準拠して信号された「Exp < - > PHBマッピング」を使用してE-LSPをサポートするDIF-Serv対応LSRは、DiffServオブジェクトをサポートする必要があります。この仕様に準拠したL-LSPをサポートするDiff-Serv対応LSRは、DiffServオブジェクトをサポートする必要があります。
The format of the Path message is as follows:
パスメッセージの形式は次のとおりです。
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
The DIFFSERV object formats are shown below. Currently there are two possible C_Types. Type 1 is a DIFFSERV object for an E-LSP. Type 2 is a DIFFSERV object for an L-LSP.
diffservオブジェクト形式を以下に示します。現在、2つの可能なC_TYPESがあります。タイプ1は、e-lspのdiffservオブジェクトです。タイプ2は、L-LSPのdiffservオブジェクトです。
5.2.1. DIFFSERV object for an E-LSP:
5.2.1. e-lspのdiffservオブジェクト：
class = 65, C_Type = 1
class = 65、c_type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 28 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
予約済み：28ビットこのフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
MAPnb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 0 to 8.
MAPNB：4ビットは、DiffServオブジェクトに含まれるマップエントリの数を示します。これは、0から8までの任意の値に設定できます。
MAP : 32 bits Each MAP entry defines the mapping between one EXP field value and one PHB. The MAP entry has the following format:
マップ：32ビット各マップエントリは、1つのExpフィールド値と1つのPHBの間のマッピングを定義します。マップエントリには次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | EXP | PHBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 13 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
予約済み：13ビットこのフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
EXP : 3 bits This field contains the value of the EXP field for the `EXP<-->PHB mapping' defined in this MAP entry.
EXP：3ビットこのフィールドには、このマップエントリで定義されている「EXP <> PHBマッピング」のEXPフィールドの値が含まれています。
PHBID : 16 bits This field contains the PHBID of the PHB for the `EXP<-->PHB mapping' defined in this MAP entry. The PHBID is encoded as specified in [PHBID].
PHBID：16ビットこのフィールドには、このマップエントリで定義されている「Exp <> PHBマッピング」のPHBのPHBIDが含まれています。pHBIDは、[phbid]で指定されているようにエンコードされます。
5.2.2 DIFFSERV object for an L-LSP:
5.2.2 l-lspのdiffservオブジェクト：
class = 65, C_Type = 2
class = 65、c_type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 16 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
予約済み：16ビットこのフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
PSC : 16 bits The PSC indicates a PHB Scheduling Class to be supported by the LSP. The PSC is encoded as specified in [PHBID].
PSC：16ビットPSCは、PHBスケジューリングクラスがLSPによってサポートされることを示しています。PSCは[phbid]で指定されているようにエンコードされます。
To establish an LSP tunnel with RSVP, the sender creates a Path message with a session type of LSP_Tunnel_IPv4 and with a LABEL_REQUEST object as per [RSVP_MPLS_TE].
RSVPでLSPトンネルを確立するために、送信者は[rsvp_mpls_te]に従って、lsp_tunnel_ipv4のセッションタイプとlabel_requestオブジェクトを使用してパスメッセージを作成します。
To establish an E-LSP tunnel with RSVP, which uses the Preconfigured `EXP<-->PHB mapping', the sender creates a Path message:
rsvpを使用してe-lspトンネルを確立するには、事前に構成された「exp < - > phbマッピング」を使用するために、送信者はパスメッセージを作成します。
- with a session type of LSP_Tunnel_IPv4,
- lsp_tunnel_ipv4のセッションタイプで、
- with the LABEL_REQUEST object, and
- label_requestオブジェクトと
- without the DIFFSERV object.
- diffservオブジェクトなし。
To establish an E-LSP tunnel with RSVP, which uses the Preconfigured `EXP<-->PHB mapping', the sender MAY alternatively create a Path message:
事前に構成された「exp < - > phbマッピング」を使用するRSVPでe-lspトンネルを確立するには、送信者は代わりにパスメッセージを作成する場合があります。
- with a session type of LSP_Tunnel_IPv4,
- lsp_tunnel_ipv4のセッションタイプで、
- with the LABEL_REQUEST object, and
- label_requestオブジェクトと
- with the DIFFSERV object for an E-LSP containing no MAP entries.
- マップエントリなしを含むE-LSPのdiffservオブジェクトを使用します。
To establish an E-LSP tunnel with RSVP, which uses a signaled `EXP<-->PHB mapping', the sender creates a Path message:
rsvpを使用してe-lspトンネルを確立するために、「exp < - > phbマッピング」という信号された「phbマッピング」を使用すると、送信者はパスメッセージを作成します。
- with a session type of LSP_Tunnel_IPv4,
- lsp_tunnel_ipv4のセッションタイプで、
- with the LABEL_REQUEST object,
- label_requestオブジェクトを使用して、
- with the DIFFSERV object for an E-LSP containing one MAP entry for each EXP value to be supported on this E-LSP.
- このe-lspでサポートされる各exp値の1つのマップエントリを含むe-lspのdiffservオブジェクト。
To establish with RSVP an L-LSP tunnel, the sender creates a Path message:
RSVPでL-LSPトンネルを確立するには、送信者がパスメッセージを作成します。
- with a session type of LSP_Tunnel_IPv4,
- lsp_tunnel_ipv4のセッションタイプで、
- with the LABEL_REQUEST object,
- label_requestオブジェクトを使用して、
- with the DIFFSERV object for an L-LSP containing the PHB Scheduling Class (PSC) supported on this L-LSP.
- このL-LSPでサポートされているPHBスケジューリングクラス（PSC）を含むL-LSPのdiffservオブジェクト。
If a path message contains multiple DIFFSERV objects, only the first one is meaningful; subsequent DIFFSERV object(s) must be ignored and not forwarded.
パスメッセージに複数のdiffservオブジェクトが含まれている場合、最初のオブジェクトのみが意味があります。後続のdiffservオブジェクトは無視し、転送されない必要があります。
Each LSR along the path records the DIFFSERV object, when present, in its path state block.
パスに沿った各LSRは、存在する場合、そのパス状態ブロックにdiffservオブジェクトを記録します。
If a DIFFSERV object is not present in the Path message, the LSR SHOULD interpret this as a request for an E-LSP using the Preconfigured `EXP<-->PHB mapping'. However, for backward compatibility purposes, with other non-Diff-Serv Quality of Service options allowed by [RSVP_MPLS_TE] such as Integrated Services Controlled Load or Guaranteed Services, the LSR MAY support a configurable "override option". When this "override option" is configured, the LSR interprets a path message without a Diff-Serv object as a request for an LSP with such non-Diff-Serv Quality of Service.
DiffServオブジェクトがパスメッセージに存在しない場合、LSRは、これを事前に構成された「Exp < - > PHBマッピング」を使用してE-LSPの要求として解釈する必要があります。ただし、統合されたサービス制御負荷や保証サービスなど、[RSVP_MPLS_TE]で許可されている他の非ディフサービス品質オプションにより、後方互換性の目的で、LSRは構成可能な「オーバーライドオプション」をサポートする場合があります。この「オーバーライドオプション」が構成されている場合、LSRは、このような非ディフセルブサービス品質のLSPのリクエストとして、Diff-Servオブジェクトなしでパスメッセージを解釈します。
If a DIFFSERV object for an E-LSP containing no MAP entry is present in the Path message, the LSR MUST interpret this as a request for an E-LSP using the Preconfigured `EXP<-->PHB mapping'. In particular, this allows an LSR with the "override option" configured to support E-LSPs with Preconfigured `EXP<-->PHB mapping', simultaneously with LSPs with non-Diff-Serv Quality of Service.
パスメッセージにマップエントリを含むE-LSPのdiffservオブジェクトがパスメッセージに存在する場合、LSRはこれを事前に構成された「exp < - > phbマッピング」を使用してe-lspの要求として解釈する必要があります。特に、これにより、「オーバーライドオプション」を備えたLSRが、非ディフサービスの品質を備えたLSPと同時に、事前に構成された「exp <-> phbマッピング」を使用してe-LSPをサポートするように構成されます。
If a DIFFSERV object for an E-LSP containing at least one MAP entry is present in the Path message, the LSR MUST interpret this as a request for an E-LSP with signaled `EXP<-->PHB mapping'.
少なくとも1つのマップエントリを含むe-LSPのdiffservオブジェクトがパスメッセージに存在する場合、LSRはこれを「exp < - > phbマッピング」と信号付きのe-lspの要求として解釈する必要があります。
If a DIFFSERV object for an L-LSP is present in the Path message, the LSR MUST interpret this as a request for an L-LSP.
l-lspのdiffservオブジェクトがパスメッセージに存在する場合、LSRはこれをl-lspの要求として解釈する必要があります。
The destination LSR of an E-LSP or L-LSP responds to the Path message containing the LABEL_REQUEST object by sending a Resv message:
e-lspまたはl-lspの宛先LSRは、RESVメッセージを送信して、label_requestオブジェクトを含むパスメッセージに応答します。
- with the LABEL object
- ラベルオブジェクトで
- without a DIFFSERV object.
- diffservオブジェクトなし。
Assuming the label request is accepted and a label is allocated, the Diff-Serv LSRs (sender, destination, intermediate nodes) must:
ラベルリクエストが受け入れられ、ラベルが割り当てられていると仮定すると、diff-serv lsrs（送信者、宛先、中間ノード）は次のことが必要です。
- update the Diff-Serv Context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label),
- 以前のセクション（着信および発信ラベル）で指定されているように、ILM/FTNの確立されたLSPに関連付けられたdif-servコンテキストを更新します。
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
- このNHLFE（発信ラベル）に必要なDIF-Serv転送処理（スケジューリングとドロップの動作）をインストールします。
An LSR that recognizes the DIFFSERV object and that receives a path message which contains the DIFFSERV object but which does not contain a LABEL_REQUEST object or which does not have a session type of LSP_Tunnel_IPv4, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unexpected DIFFSERV object'. Those are defined below in section 5.5.
diffservオブジェクトを認識し、diffservオブジェクトを含むがlabel_requestオブジェクトが含まれていないか、セッションタイプのlsp_tunnel_ipv4を持たないパスメッセージを受信するLSRは、エラーコードで送信者に向かって送信者に送信されます。サーブエラー 'および「予期しないdiffservオブジェクト」のエラー値。これらは、セクション5.5で以下に定義されています。
An LSR receiving a Path message with the DIFFSERV object for E-LSP, which recognizes the DIFFSERV object but does not support the particular PHB encoded in one, or more, of the MAP entries, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unsupported PHB'. Those are defined below in section 5.5.
diffservオブジェクトのdiffservオブジェクトを使用してパスメッセージを受信するLSRは、diffservオブジェクトを認識しますが、マップエントリの1つまたは複数のエンコードされた特定のPHBをサポートしていないため、エラーコードを使用して送信者にpatherrを送信します。diff-servエラー 'および「サポートされていないphb」のエラー値。これらは、セクション5.5で以下に定義されています。
An LSR receiving a Path message with the DIFFSERV object for E-LSP, which recognizes the DIFFSERV object but determines that the signaled `EXP<-->PHB mapping' is invalid, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of Invalid `EXP<-->PHB mapping'. Those are defined below in section 5.5. `The EXP<-->PHB mapping' signaled in the DIFFSERV Object for an E-LSP is invalid when:
diffservオブジェクトを認識しますが、信号された「exp <> phbマッピング」が無効であると判断したe-lspのdiffservオブジェクトを使用してパスメッセージを受信するLSRは、エラーコードを使用して送信者に送信者に送信されます。サーブエラー 'および無効な `exp < - > phbマッピング」のエラー値。これらは、セクション5.5で以下に定義されています。`exp < - > phbマッピング 'e-lspのdiffservオブジェクトで信号を送信した場合：
- the MAPnb field is not within the range 0 to 8 or
- mapnbフィールドは0〜8または8または
- a given EXP value appears in more than one MAP entry, or
- 特定のEXP値は、複数のマップエントリに表示されます。
- the PHBID encoding is invalid.
- pHBIDエンコーディングは無効です。
An LSR receiving a Path message with the DIFFSERV object for L-LSP, which recognizes the DIFFSERV object but does not support the particular PSC encoded in the PSC field, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unsupported PSC'. Those are defined below in section 5.5.
L-LSPのdiffservオブジェクトを使用してパスメッセージを受信するLSRは、diffservオブジェクトを認識しますが、PSCフィールドでエンコードされた特定のPSCをサポートしていないため、エラーコード「diff-servエラー」とエラーコードを持つ送信者にpatherrを送信します。「サポートされていないPSC」のエラー値。これらは、セクション5.5で以下に定義されています。
An LSR receiving a Path message with the DIFFSERV object, which recognizes the DIFFSERV object but that is unable to allocate the required per-LSP Diff-Serv context sends a PathErr with the error code "Diff-Serv Error" and the error value "Per-LSP context allocation failure". Those are defined below in section 5.5.
diffservオブジェクトを使用してパスメッセージを受信するLSRは、diffservオブジェクトを認識しますが、必要なlspごとのdiff-servコンテキストを割り当てることができないため、エラーコード「diff-servエラー」とエラー値を掲載してpatherrを送信します。-LSPコンテキスト割り当て障害」。これらは、セクション5.5で以下に定義されています。
A Diff-Serv LSR MUST handle the situations where the label request can not be accepted for reasons other than those already discussed in this section, in accordance with [RSVP_MPLS_TE] (e.g., reservation rejected by admission control, a label can not be associated).
diff-serv LSRは、[rsvp_mpls_te]に従って、このセクションで既に説明した理由以外の理由でラベル要求を受け入れない状況を処理する必要があります（たとえば、入場管理によって拒否された予約は、ラベルを関連付けることはできません）。
An LSR that does not recognize the DIFFSERV object Class-Num MUST behave in accordance with the procedures specified in [RSVP] for an unknown Class-Num whose format is 0bbbbbbb i.e., it must send a PathErr with the error code `Unknown object class' toward the sender.
diffservオブジェクトクラス-Numを認識しないLSRは、[RSVP]で指定された手順に従って動作しなければなりません。送信者に向かって。
An LSR that recognize the DIFFSERV object Class-Num but does not recognize the DIFFSERV object C-Type, must behave in accordance with the procedures specified in [RSVP] for an unknown C-type i.e., it must send a PathErr with the error code `Unknown object C-Type' toward the sender.
DiffServオブジェクトクラスNumを認識しているが、DiffServオブジェクトCタイプを認識しないLSRは、未知のCタイプについて[RSVP]で指定された手順に従って動作する必要があります。送信者に対する「不明なオブジェクトCタイプ」。
In both situations, this causes the path set-up to fail. The sender should notify management that a L-LSP cannot be established and should possibly take action to retry LSP establishment without the DIFFSERV object (e.g., attempt to use E-LSPs with Preconfigured `EXP<-->PHB mapping' as a fall-back strategy).
両方の状況で、これによりパスのセットアップが失敗します。送信者は、l-lspを確立できないことを管理者に通知する必要があり、diffservオブジェクトなしでLSPの確立を再試行するための行動を起こす必要があります（たとえば、fall- fall-としての事前に設定された「exp < - > phbマッピング」を使用してe-LSPを使用しようとする必要があります。バック戦略）。
In the procedures described above, certain errors must be reported as a `Diff-Serv Error'. The value of the `Diff-Serv Error' error code is 27.
上記の手順では、特定のエラーを「Diff-Servエラー」として報告する必要があります。「diff-servエラー」エラーコードの値は27です。
The following defines error values for the Diff-Serv Error:
以下は、dif-servエラーのエラー値を定義します。
Value Error
値エラー
1 Unexpected DIFFSERV object 2 Unsupported PHB 3 Invalid `EXP<-->PHB mapping' 4 Unsupported PSC 5 Per-LSP context allocation failure
1予期しないdiffservオブジェクト2サポートされていないphb 3無効な `exp < - > phbマッピング '4サポートされていないPSC 5-lspコンテキスト割り当て障害
Both E-LSPs and L-LSPs can be established with or without bandwidth reservation.
E-LSPとL-LSPの両方は、帯域幅の予約の有無にかかわらず確立できます。
As specified in [RSVP_MPLS_TE], to establish an E-LSP or an L-LSP with bandwidth reservation, Int-Serv's Controlled Load service (or possibly Guaranteed Service) is used and the bandwidth is signaled in the SENDER_TSPEC (respectively FLOWSPEC) of the path (respectively Resv) message.
[rsvp_mpls_te]で指定されているように、帯域幅予約のあるe-lspまたはl-lspを確立するために、int-servの制御された負荷サービス（またはおそらく保証されたサービス）が使用され、帯域幅はそれぞれsender_tspec（それぞれFlowsPec）で通知されます。パス（それぞれRESV）メッセージ。
As specified in [RSVP_MPLS_TE],to establish an E-LSP or an L-LSP without bandwidth reservation, the Null Service specified in [NULL] is used.
[rsvp_mpls_te]で指定されているように、帯域幅の予約なしでe-lspまたはl-lspを確立するために、[null]で指定されたヌルサービスを使用します。
Note that this specification defines usage of E-LSPs and L-LSPs for support of the Diff-Serv service only. Regardless of the Intserv service (Controlled Load, Null Service, Guaranteed Service,...) and regardless of whether the reservation is with or without bandwidth reservation, E-LSPs and L-LSPs are defined here for support of Diff-Serv services. Support of Int-Serv services over an MPLS Diff-Serv backbone is outside the scope of this specification.
この仕様では、dif-servサービスのみをサポートするためのe-LSPとL-LSPの使用法を定義することに注意してください。INTSERVサービス（制御荷重、ヌルサービス、保証サービスなど）に関係なく、および予約が帯域幅の予約の有無にかかわらず、e-LSPとL-LSPがDiff-Servサービスのサポートのためにここで定義されています。MPLS Diff-Servバックボーンを介したINT-Servサービスのサポートは、この仕様の範囲外です。
Note also that this specification does not concern itself with the DCLASS object defined in [DCLASS], since this object conveys information on DSCP values, which are not relevant inside the MPLS network.
また、この仕様は[dclass]で定義されたDCLASSオブジェクトには関係していないことに注意してください。このオブジェクトは、MPLSネットワーク内では関連しないDSCP値に関する情報を伝えているためです。
The MPLS architecture does not assume a single label distribution protocol. [LDP] defines the Label Distribution Protocol and its usage for establishment of label switched paths (LSPs) in MPLS networks. This section specifies the extensions to LDP to establish LSPs supporting Differentiated Services in MPLS networks.
MPLSアーキテクチャは、単一のラベル分布プロトコルを想定していません。[LDP]は、MPLSネットワークにラベルスイッチパス（LSP）を確立するためのラベル分布プロトコルとその使用法を定義します。このセクションでは、LDPへの拡張を指定して、MPLSネットワークで差別化されたサービスをサポートするLSPを確立します。
One new LDP TLV is defined in this document:
このドキュメントでは、1つの新しいLDP TLVが定義されています。
- the Diff-Serv TLV
- diff-serv tlv
Detailed description of this TLV is provided below.
このTLVの詳細な説明を以下に示します。
The new Diff-Serv TLV is optional with respect to LDP. A Diff-Serv capable LSR supporting E-LSPs which uses the Preconfigured `EXP<-- >PHB mapping' in compliance with this specification MAY support the Diff-Serv TLV. A Diff-Serv capable LSR supporting E-LSPs which uses the signaled `EXP<-->PHB mapping' in compliance with this specification MUST support the Diff-Serv TLV. A Diff-Serv capable LSR supporting L-LSPs in compliance with this specification MUST support the Diff-Serv TLV.
新しいdiff-serv TLVは、LDPに関してオプションです。この仕様に準拠して事前に構成された「exp < - > phbマッピング」を使用するe-LSPをサポートするdif-serv有能LSRは、diff-serv tlvをサポートする場合があります。この仕様に準拠して「exp < - > phbマッピング」を使用するe-LSPをサポートするdiff-serv対応LSRは、diff-serv tlvをサポートする必要があります。この仕様に準拠してL-LSPをサポートするDIFSERV有能LSRは、DIF-Serv TLVをサポートする必要があります。
The Diff-Serv TLV has the following formats:
Diff-Serv TLVには次の形式があります。
Diff-Serv TLV for an E-LSP:
e-lspのdiff-serv 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Diff-Serv (0x0901) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T:1 bit LSP Type. This is set to 0 for an E-LSP
T：1ビットLSPタイプ。これは、e-lspで0に設定されています
Reserved : 27 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
予約済み：27ビットこのフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
MAPnb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 1 to 8.
MAPNB：4ビットは、DiffServオブジェクトに含まれるマップエントリの数を示します。これは、1〜8の任意の値に設定できます。
MAP : 32 bits Each MAP entry defines the mapping between one EXP field value and one PHB. The MAP entry has the following format:
マップ：32ビット各マップエントリは、1つのExpフィールド値と1つのPHBの間のマッピングを定義します。マップエントリには次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | EXP | PHBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 13 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
予約済み：13ビットこのフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
EXP : 3 bits This field contains the value of the EXP field for the `EXP<-->PHB mapping' defined in this MAP entry.
EXP：3ビットこのフィールドには、このマップエントリで定義されている「EXP <> PHBマッピング」のEXPフィールドの値が含まれています。
PHBID : 16 bits This field contains the PHBID of the PHB for the `EXP<-->PHB mapping' defined in this MAP entry. The PHBID is encoded as specified in [PHBID].
PHBID：16ビットこのフィールドには、このマップエントリで定義されている「Exp <> PHBマッピング」のPHBのPHBIDが含まれています。pHBIDは、[phbid]で指定されているようにエンコードされます。
Diff-Serv TLV for an L-LSP:
l-lspのdiff-serv 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = PSC (0x0901) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T:1 bit LSP Type. This is set to 1 for an L-LSP
T：1ビットLSPタイプ。これは、L-LSPの場合に1に設定されています
Reserved : 15 bits This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
予約済み：15ビットこのフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
PSC : 16 bits The PSC indicates a PHB Scheduling Class to be supported by the LSP. The PSC is encoded as specified in [PHBID].
PSC：16ビットPSCは、PHBスケジューリングクラスがLSPによってサポートされることを示しています。PSCは[phbid]で指定されているようにエンコードされます。
The following values are defined for the Status Code field of the Status TLV:
次の値は、ステータスTLVのステータスコードフィールドに対して定義されています。
Status Code E Status Data
ステータスコードEステータスデータ
Unexpected Diff-Serv TLV 0 0x01000001
Unsupported PHB 0 0x01000002
Invalid `EXP<-->PHB mapping' 0 0x01000003
Unsupported PSC 0 0x01000004
Per-LSP context allocation failure 0 0x01000005
The format of the Label Request message is extended as follows, to optionally include the Diff-Serv TLV:
ラベルリクエストメッセージの形式は、次のように拡張され、オプションでdiff-serv 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| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Label Mapping message is extended as follows, to optionally include the Diff-Serv TLV:
ラベルマッピングメッセージの形式は、次のように拡張され、オプションでdiff-serv 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| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Label Release message is extended as follows, to optionally include the Status TLV:
ラベルリリースメッセージの形式は、次のように拡張され、オプションでステータス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| Label Release (0x0403) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Notification message is extended as follows, to optionally include the Diff-Serv TLV:
通知メッセージの形式は、次のように拡張され、オプションでdiff-serv 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| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section describes operations when the Downstream Unsolicited Mode is used.
このセクションでは、下流の未承諾モードが使用される場合の操作について説明します。
When allocating a label for an E-LSP which is to use the preconfigured `EXP<-->PHB mapping', a downstream Diff-Serv LSR issues a Label Mapping message without the Diff-Serv TLV.
事前に構成された「exp < - > phbマッピング」を使用するe-lspにラベルを割り当てると、下流のdiff-serv lsrは、diff-serv tlvなしでラベルマッピングメッセージを発行します。
When allocating a label for an E-LSP which is to use a signaled `EXP<-->PHB mapping', a downstream Diff-Serv LSR issues a Label Mapping message with the Diff-Serv TLV for an E-LSP which contains one MAP entry for each EXP value to be supported on this E-LSP.
信号された「exp <> phbマッピング」を使用するe-lspにラベルを割り当てる場合、下流のdiff-serv lsrは、1つを含むe-lspのdiff-serv tlvのラベルマッピングメッセージを発行しますこのe-lspでサポートされる各exp値のマップエントリ。
When allocating a label for an L-LSP, a downstream Diff-Serv LSR issues a Label Mapping message with the Diff-Serv TLV for an L-LSP which contains the PHB Scheduling Class (PSC) to be supported on this L-LSP.
L-LSPにラベルを割り当てるとき、下流のDIFF-Serv LSRは、このL-LSPでサポートされるPHBスケジューリングクラス（PSC）を含むL-LSPのDIFF-Serv TLVを使用してラベルマッピングメッセージを発行します。
Assuming the label set-up is successful, the downstream and upstream LSRs must:
ラベルのセットアップが成功したと仮定すると、下流と上流のLSRが必要です。
- update the Diff-Serv Context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label),
- 以前のセクション（着信および発信ラベル）で指定されているように、ILM/FTNの確立されたLSPに関連付けられたdif-servコンテキストを更新します。
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
- このNHLFE（発信ラベル）に必要なDIF-Serv転送処理（スケジューリングとドロップの動作）をインストールします。
An upstream Diff-Serv LSR receiving a Label Mapping message with multiple Diff-Serv TLVs only considers the first one as meaningful. The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).
複数のDiff-Serv TLVを使用したラベルマッピングメッセージを受信する上流のDiff-Serv LSRは、最初のものを意味のあるものとみなすだけです。LSRは、その後のdif-serv tlv（s）を無視し、転送する必要があります。
An upstream Diff-Serv LSR which receives a Label Mapping message, with the Diff-Serv TLV for an E-LSP and does not support the particular PHB encoded in one or more of the MAP entries, must reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unsupported PHB'.
e-lsp用のdiff-serv tlvを備えたラベルマッピングメッセージを受信する上流のdiff-serv LSRは、1つ以上のマップエントリでエンコードされた特定のPHBをサポートしていないため、ラベルリリースを送信してマッピングを拒否する必要があります。「サポートされていないPHB」のステータスコードを備えたラベルTLVとステータスTLVを含むメッセージ。
An upstream Diff-Serv LSR receiving a Label Mapping message with the Diff-Serv TLV for an E-LSP and determining that the signaled `EXP<-->PHB mapping' is invalid, must reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of Invalid `EXP<-->PHB mapping'. The `EXP<-->PHB mapping' signaled in the DIFFSERV Object for an E-LSP is invalid when:
e-lspのdiff-serv tlvを使用してラベルマッピングメッセージを受信し、信号された「exp < - > phbマッピング」が無効であると判断する上流のdiff-serv LSRは、ラベルリリースメッセージを送信してマッピングを拒否する必要があります。無効な「exp <-> phbマッピング」のステータスコードを備えたラベルTLVとステータスTLVが含まれます。e-lspのdiffservオブジェクトで信号を送信した `exp < - > phbマッピング 'は、次の場合に無効です。
- the MAPnb field is not within the range 1 to 8, or
- mapnbフィールドは1〜8の範囲内ではありません。
- a given EXP value appears in more than one MAP entry, or
- 特定のEXP値は、複数のマップエントリに表示されます。
- the PHBID encoding is invalid
- pHBIDエンコーディングは無効です
An upstream Diff-Serv LSR receiving a Label Mapping message with the Diff-Serv TLV for an L-LSP containing a PSC value which is not supported, must reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unsupported PSC'.
サポートされていないPSC値を含むL-LSPのDiff-Serv TLVを使用してラベルマッピングメッセージを受信する上流のDIFF-SERV LSRは、ラベルTLVとステータスTLVを含むラベルリリースメッセージを送信してマッピングを拒否する必要があります「サポートされていないPSC」のステータスコードを使用します。
This section describes operations when the Downstream on Demand Mode is used.
このセクションでは、ダウンストリームオンデマンドモードが使用される場合の操作について説明します。
When requesting a label for an E-LSP which is to use the preconfigured `EXP<-->PHB mapping', an upstream Diff-Serv LSR sends a Label Request message without the Diff-Serv TLV.
事前に設定された「Exp < - > PHBマッピング」を使用するE-LSPのラベルを要求すると、上流のDIFSV-Serv LSRは、DIFF-Serv TLVなしでラベル要求メッセージを送信します。
When requesting a label for an E-LSP which is to use a signaled `EXP<-->PHB mapping', an upstream Diff-Serv LSR sends a Label Request message with the Diff-Serv TLV for an E-LSP which contains one MAP entry for each EXP value to be supported on this E-LSP.
信号された「Exp <> phbマッピング」を使用するe-lspのラベルを要求する場合、上流のdiff-serv lsrは、1つを含むe-lspのdiff-serv tlvを使用してラベル要求メッセージを送信しますこのe-lspでサポートされる各exp値のマップエントリ。
When requesting a label for an L-LSP, an upstream Diff-Serv LSR sends a Label Request message with the Diff-Serv TLV for an L-LSP which contains the PSC to be supported on this L-LSP.
L-LSPのラベルを要求すると、上流のDIFF-Serv LSRは、このL-LSPでサポートされるPSCを含むL-LSPのDiff-Serv TLVを使用してラベル要求メッセージを送信します。
A downstream Diff-Serv LSR sending a Label Mapping message in response to a Label Request message for an E-LSP or an L-LSP must not include a Diff-Serv TLV in this Label Mapping message. Assuming the label set-up is successful, the downstream and upstream LSRs must:
e-lspまたはl-lspのラベル要求メッセージに応じてラベルマッピングメッセージを送信する下流のdiff-serv LSRは、このラベルマッピングメッセージにdiff-serv tlvを含めてはなりません。ラベルのセットアップが成功したと仮定すると、下流と上流のLSRが必要です。
- update the Diff-Serv Context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label),
- 以前のセクション（着信および発信ラベル）で指定されているように、ILM/FTNの確立されたLSPに関連付けられたdif-servコンテキストを更新します。
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
- このNHLFE（発信ラベル）に必要なDIF-Serv転送処理（スケジューリングとドロップの動作）をインストールします。
An upstream Diff-Serv LSR receiving a Label Mapping message containing a Diff-Serv TLV in response to its Label Request message, must reject the label mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unexpected Diff-Serv TLV'.
ラベルリクエストメッセージに応じてDiff-Serv TLVを含むラベルマッピングメッセージを受信する上流のDIFF-SERV LSRは、ラベルTLVとステータスTLVを含むラベルリリースメッセージを送信して、ラベルマッピングを拒否する必要があります。「予期しないdif-serv tlv」。
A downstream Diff-Serv LSR receiving a Label Request message with multiple Diff-Serv TLVs only considers the first one as meaningful. The LSR must ignore and not forward the subsequent Diff-Serv TLV(s).
複数のDIFF-Serv TLVを使用したラベル要求メッセージを受信する下流のDIFF-Serv LSRは、最初のものを意味のあるものとみなすだけです。LSRは、その後のdif-serv tlv（s）を無視し、転送する必要があります。
A downstream Diff-Serv LSR which receives a Label Request message with the Diff-Serv TLV for an E-LSP and does not support the particular PHB encoded in one (or more) of the MAP entries, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of `Unsupported PHB'.
e-lspのdiff-serv tlvを使用したラベル要求メッセージを受信し、マップエントリの1つ（またはそれ以上）でエンコードされた特定のPHBをサポートしない下流のdiff-serv LSRは、通知を送信してリクエストを拒否する必要があります。「サポートされていないPHB」のステータスコードを持つステータスTLVを含むメッセージ。
A downstream Diff-Serv LSR receiving a Label Request message with the Diff-Serv TLV for an E-LSP and determining that the signaled `EXP<-->PHB mapping' is invalid, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of Invalid `EXP<-->PHB mapping'. The `EXP<-->PHB mapping' signaled in the DIFFSERV TLV for an E-LSP is invalid when:
e-lspのdiff-serv tlvを使用してラベル要求メッセージを受信し、信号された「exp < - > phbマッピング」が無効であると判断する下流のdiff-serv lsrは、「exp < - > phbマッピング」のステータスコードを持つステータスTLV。e-lspのdiffserv tlvで信号を送信した `exp < - > phbマッピング 'は、次の場合に無効です。
- the MAPnb field is not within the range 1 to 8, or
- mapnbフィールドは1〜8の範囲内ではありません。
- a given EXP value appears in more than one MAP entry, or
- 特定のEXP値は、複数のマップエントリに表示されます。
- the PHBID encoding is invalid A downstream Diff-Serv LSR receiving a Label Request message with the Diff-Serv TLV for an L-LSP containing a PSC value which is not supported, must reject the request by sending a Notification message which includes the Status TLV with a Status Code of `Unsupported PSC'.
- pHBIDエンコードは、サポートされていないPSC値を含むL-LSPのdiff-serv request tlvを使用してラベル要求メッセージを受信する下流のdiff-serv-serv lsrが無効です。ステータスTLVを含む通知メッセージを送信してリクエストを拒否する必要があります「サポートされていないPSC」のステータスコードを使用します。
A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in a Label Request message but is unable to allocate the required per-LSP context information, must reject the request sending a Notification message which includes the Status TLV with a Status Code of `Per-LSP context allocation failure'.
ラベルリクエストメッセージのDIFF-Serv TLVタイプを認識しているが、必要なLSPごとのコンテキスト情報を割り当てることができないダウンストリームDIFSERV-Serv LSRは、ステータスコードを含むステータスTLVを含む通知メッセージの送信リクエストを拒否する必要があります「LSPごとのコンテキスト割り当て障害」。
A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in a Label Request message and supports the requested PSC but is not able to satisfy the label request for other reasons (e.g., no label available), must send a Notification message in accordance with existing LDP procedures [LDP] (e.g., with a `No Label Resource' Status Code). This Notification message must include the requested Diff-Serv TLV.
ラベルリクエストメッセージのDIFF-Serv TLVタイプを認識し、要求されたPSCをサポートするが、他の理由でラベルリクエストを満たすことができない（ラベルがない）ダウンストリームDIFF-Serv LSRは、通知メッセージを送信する必要があります。既存のLDP手順[LDP]（たとえば、「ラベルなしリソース」ステータスコードを使用）に従って。この通知メッセージには、要求されたdiff-serv TLVを含める必要があります。
An LSR that does not recognize the Diff-Serv TLV Type, on receipt of a Label Request message or a Label Mapping message containing the Diff-Serv TLV, must behave in accordance with the procedures specified in [LDP] for an unknown TLV whose U Bit and F Bit are set to 0 i.e., it must ignore the message, return a Notification message with `Unknown TLV' Status.
LABERリクエストメッセージまたはdiff-serv tlvを含むラベルマッピングメッセージを受信した場合に、diff-serv tlvタイプを認識しないLSRは、uがuを持つ未知のTLVの[LDP]で指定された手順に従って動作する必要があります。ビットとfビットは0に設定されています。つまり、メッセージを無視し、「不明なTLV」ステータスの通知メッセージを返す必要があります。
Bandwidth information may also be signaled at the establishment time of E-LSP and L-LSP, for instance for the purpose of Traffic Engineering, using the Traffic Parameters TLV as described in [MPLS CR LDP].
帯域幅情報は、[MPLS CR LDP]で説明されているように、トラフィックパラメーターTLVを使用して、トラフィックエンジニアリングの目的など、E-LSPおよびL-LSPの確立時にも通知される場合があります。
The general operations for MPLS support of Diff-Serv, including label forwarding and LSP setup operations are specified in the previous sections. This section describes the specific operations required for MPLS support of Diff-Serv over PPP interfaces, LAN interfaces, ATM Interfaces which are not label controlled and Frame Relay interfaces which are not label controlled.
ラベル転送やLSPセットアップ操作を含むDIFF-SERVのMPLSサポートの一般的な操作は、前のセクションで指定されています。このセクションでは、PPPインターフェイス、LANインターフェイス、ラベル制御のないATMインターフェイス、およびラベル制御のないフレームリレーインターフェイスを介したDIFFSERVのMPLSサポートに必要な特定の操作について説明します。
On these interfaces, this specification allows any of the following LSP combinations per FEC:
これらのインターフェイスでは、この仕様により、FECごとに次のLSPの組み合わせが可能になります。
- Zero or any number of E-LSP, and
- ゼロまたは任意の数のe-lsp、および
- Zero or any number of L-LSPs.
- ゼロまたは任意の数のL-LSP。
A Diff-Serv capable LSR MUST support E-LSPs which use preconfigured `EXP<-->PHB mapping' over these interfaces.
Diff-Servの有能なLSRは、これらのインターフェイスでPRECONSFIGURED「EXP < - > PHBマッピング」を使用するE-LSPをサポートする必要があります。
A Diff-Serv capable LSR MAY support E-LSPs which use signaled `EXP<-->PHB mapping' and L-LSPs over these interfaces.
Diff-Serv対応LSRは、これらのインターフェイスで「Exp <> PHBマッピング」とL-LSPを使用するE-LSPをサポートする場合があります。
This section describes the specific operations required for MPLS support of Diff-Serv over label switching controlled ATM (LC-ATM) interfaces.
このセクションでは、ラベルスイッチング制御ATM（LC-ATM）インターフェイスを超えるDIFFSERVのMPLSサポートに必要な特定の操作について説明します。
This document allows any number of L-LSPs per FEC within an MPLS ATM Diff-Serv domain. E-LSPs are not supported over LC-ATM interfaces.
このドキュメントにより、MPLS ATM DIFF-SERVドメイン内のFECあたりのL-LSPの数が任意になります。E-LSPはLC-ATMインターフェイスでサポートされていません。
The use of the "ATM service categories" specified by the ATM Forum, of the "ATM Transfer Capabilities" specified by the ITU-T or of vendor specific ATM traffic classes is outside of the scope of this specification. The only requirement for compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be compliant with the corresponding Diff-Serv PHB specifications.
ATMフォーラムで指定された「ATMサービスカテゴリ」の使用、ITU-Tまたはベンダー固有のATMトラフィッククラスで指定された「ATM転送機能」の使用は、この仕様の範囲外です。準拠の実装の唯一の要件は、ATM LSRによってL-LSPを介して転送された動作によって経験される転送動作が、対応するDIF-Serv PHB仕様に準拠している必要があることです。
Since there is only one bit (CLP) for encoding the PHB drop precedence value over ATM links, only two different drop precedence levels are supported in ATM LSRs. Sections 4.2.2 and 4.4.2 define how the three drop precedence levels of the AFn Ordered Aggregates are mapped to these two ATM drop precedence levels. This mapping is in accordance with the requirements specified in [DIFF_AF] for the case when only two drop precedence levels are supported.
ATMリンクでPHBドロップの優先順位値をエンコードするためのビット（CLP）が1つしかないため、ATM LSRでサポートされている2つの異なるドロップ優先レベルのみがサポートされています。セクション4.2.2および4.4.2は、AFN順序付けされた集約の3つのドロップ優先レベルが、これら2つのATMドロップの優先度レベルにマッピングされる方法を定義します。このマッピングは、2つのドロップ優先度レベルのみがサポートされている場合の[diff_af]で指定された要件に準拠しています。
To avoid discarding parts of the packets, frame discard mechanisms, such as Early Packet Discard (EPD) (see [ATMF_TM]) SHOULD be enabled in the ATM-LSRs for all PHBs described in this document.
パケットの一部の破棄を避けるために、このドキュメントに記載されているすべてのPHBのATM-LSRで、初期パケット廃棄（EPD）（[ATMF_TM]を参照）などのフレーム廃棄メカニズムをフレーム廃棄メカニズムが有効にする必要があります。
A Diff-Serv capable LSR MUST support L-LSPs over LC-ATM interfaces. This specification assumes that Edge-LSRs of the ATM-LSR domain use the "shim header" encapsulation method defined in [MPLS_ATM]. Operations without the "shim header" encapsulation are outside the scope of this specification.
diff-serv対応LSRは、LC-ATMインターフェイスを介したL-LSPをサポートする必要があります。この仕様では、ATM-LSRドメインのEDGE-LSRSが[MPLS_ATM]で定義された「シムヘッダー」カプセル化メソッドを使用することを前提としています。「シムヘッダー」カプセル化のない操作は、この仕様の範囲外です。
This section describes the specific operations required for MPLS support of Diff-Serv over label switching controlled Frame Relay (LC-FR) interfaces.
このセクションでは、ラベルスイッチング制御フレームリレー（LC-FR）インターフェイスを超えるDIFFSERVのMPLSサポートに必要な特定の操作について説明します。
This document allows any number of L-LSPs per FEC within an MPLS Frame Relay Diff-Serv domain. E-LSPs are not supported over LC-FR interfaces.
このドキュメントにより、MPLSフレームリレーDIFF-SERVドメイン内のFECあたりの任意の数のLSPが許可されます。E-LSPはLC-FRインターフェイスでサポートされていません。
The use of the Frame Relay traffic parameters as specified by ITU-T and Frame Relay-Forum or of vendor specific Frame Relay traffic management mechanisms is outside of the scope of this specification. The only requirement for compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the Frame Relay LSR MUST be compliant with the corresponding Diff-Serv PHB specifications.
ITU-Tおよびフレームリレーフォーラムで指定されているフレームリレートラフィックパラメーターまたはベンダー固有のフレームリレートラフィック管理メカニズムの使用は、この仕様の範囲外です。準拠の実装の唯一の要件は、Frame Relay LSRによってL-LSPを介して転送される動作によって経験される転送動作が、対応するDIF-Serv PHB仕様に準拠している必要があることです。
Since there is only one bit (DE) for encoding the PHB drop precedence value over Frame Relay links, only two different drop precedence levels are supported in Frame Relay LSRs. Sections 4.2.3 and 4.4.3 define how the three drop precedence levels of the AFn Ordered Aggregates are mapped to these two Frame Relay drop precedence levels. This mapping is in accordance with the requirements specified in [DIFF_AF] for the case when only two drop precedence levels are supported.
フレームリレーリンク上のPHBドロップの優先順位値をエンコードするためのビット（DE）は1つしかないため、フレームリレーLSRでサポートされている2つの異なるドロップ優先レベルのみがサポートされています。セクション4.2.3および4.4.3は、AFN順序付けされた集約の3つのドロップ優先度レベルが、これら2つのフレームリレードロップの優先度レベルにマッピングされる方法を定義します。このマッピングは、2つのドロップ優先度レベルのみがサポートされている場合の[diff_af]で指定された要件に準拠しています。
A Diff-Serv capable LSR MUST support L-LSPs over LC-Frame Relay interfaces.
diff-serv対応LSRは、LCフレームリレーインターフェイスよりもL-LSPをサポートする必要があります。
This specification assumes that Edge-LSRs of the FR-LSR domain use the "generic encapsulation" method as recommended in [MPLS_FR]. Operations without the "generic encapsulation" are outside the scope of this specification.
この仕様は、FR-LSRドメインのEDGE-LSRが[MPLS_FR]で推奨されるように「汎用カプセル化」メソッドを使用することを前提としています。「汎用カプセル化」のない操作は、この仕様の範囲外です。
This document defines a number of objects with implications for IANA.
このドキュメントでは、IANAに影響を与える多くのオブジェクトを定義しています。
This document defines in section 5.2 a new RSVP object, the DIFFSERV object. This object required a number from the space defined in [RSVP] for those objects which, if not understood, cause the entire RSVP message to be rejected with an error code of "Unknown Object Class". Such objects are identified by a zero in the most significant bit of the class number. Within that space, this object required a number from the "IETF Consensus" space. "65" has been allocated by IANA for the DIFFSERV object.
このドキュメントでは、セクション5.2で、新しいRSVPオブジェクトであるDiffServオブジェクトを定義しています。このオブジェクトには、[RSVP]で定義されたスペースからの数値が必要でした。これらのオブジェクトでは、理解されていない場合、RSVPメッセージ全体が「不明なオブジェクトクラス」のエラーコードで拒否されます。このようなオブジェクトは、クラス番号の最も重要なビットでゼロで識別されます。そのスペース内で、このオブジェクトには「IETFコンセンサス」スペースからの数字が必要でした。「65」は、diffservオブジェクトにianaによって割り当てられています。
This document defines in section 5.5 a new RSVP error code, "Diffserv Error". Error code "27" has been assigned by IANA to the "Diffserv Error". This document defines values 1 through 5 of the value field to be used within the ERROR_SPEC object for this error code. Future allocations of values in this space should be handled by IANA using the First Come First Served policy defined in [IANA].
このドキュメントでは、セクション5.5で、新しいRSVPエラーコード「DiffServエラー」を定義しています。エラーコード「27」は、IANAによって「diffservエラー」に割り当てられています。このドキュメントでは、このエラーコードのERROR_SPECオブジェクト内で使用される値フィールドの値1〜5を定義します。このスペースの将来の値の割り当ては、[IANA]で定義された最初の提供ポリシーを使用してIANAが処理する必要があります。
This document defines in section 6.1 a new LDP TLV, the Diffserv TLV. The number for this TLV has been assigned by working group consensus according to the policies defined in [LDP].
このドキュメントでは、セクション6.1で新しいLDP TLV、DiffServ TLVを定義しています。このTLVの番号は、[LDP]で定義されているポリシーに従って、ワーキンググループのコンセンサスによって割り当てられています。
This document defines in section 6.2 five new LDP Status Code values for Diffserv-related error conditions. The values for the Status Code have been assigned by working group consensus according to the policies defined in [LDP].
このドキュメントは、セクション6.2で定義されています。DiffServ関連エラー条件の5つの新しいLDPステータスコード値。ステータスコードの値は、[LDP]で定義されているポリシーに従って、ワーキンググループのコンセンサスによって割り当てられています。
This document does not introduce any new security issues beyond those inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms proposed for those technologies.
このドキュメントでは、Diff-Serv、MPLS、およびRSVPに固有のものを超えた新しいセキュリティ問題を導入しておらず、これらのテクノロジーに提案されているのと同じメカニズムを使用する場合があります。
This document has benefited from discussions with Eric Rosen, Angela Chiu and Carol Iturralde. It has also borrowed from the work done by D. Black regarding Diff-Serv and IP Tunnels interaction.
この文書は、エリック・ローゼン、アンジェラ・チウ、キャロル・イトゥルラルドとの議論の恩恵を受けています。また、D.BlackがDiff-ServトンネルとIPトンネルの相互作用に関して行った作業から借りました。
APPENDIX A. Example Deployment Scenarios
付録A.展開シナリオの例
This section does not provide additional specification and is only here to provide examples of how this flexible approach for Diff-Serv support over MPLS may be deployed. Pros and cons of various deployment options for particular environments are beyond the scope of this document.
このセクションでは、追加の仕様を提供するものではなく、MPLSを介したDiff-Servサポートのこの柔軟なアプローチをどのように展開するかの例を提供するためにのみここにあります。特定の環境のさまざまな展開オプションの長所と短所は、このドキュメントの範囲を超えています。
A Service Provider running 8 (or fewer) BAs over MPLS, not performing Traffic engineering, not using MPLS protection and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff-Serv over MPLS using a single E-LSP per FEC established via LDP. Furthermore the Service Provider may elect to use the preconfigured `EXP<-->PHB mapping'.
MPLSで8（または少ない）BASを実行しているサービスプロバイダー、トラフィックエンジニアリングを実行せず、MPLS保護を使用せず、MPLSシムヘッダーカプセル化を使用してネットワークで使用することは、単一のE-LSPを使用してDiff-serv over MPLSを実行することを選択できます。LDPを介して確立されたFEC。さらに、サービスプロバイダーは、事前に設定された「exp < - > phbマッピング」を使用することを選択できます。
Operations can be summarized as follows:
操作は次のように要約できます。
- the Service Provider configures at every LSR, the bi-directional mapping between each PHB and a value of the EXP field (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
- サービスプロバイダーは、すべてのLSRで構成され、各PHB間の双方向マッピング、およびEXPフィールドの値（例：000 <-> AF11、001 <-> AF12、010 <-> AF13）
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13)
- サービスプロバイダーはすべてのLSRで構成され、すべてのインターフェイスについて、各PSCのスケジューリング動作（たとえば、AF1に割り当てられた帯域幅）と各PHBのドロップ挙動（たとえば、AF11、AF12、AF13のドロッププロファイル）
- LSRs signal establishment of a single E-LSP per FEC using LDP in accordance with the specification above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP and that it uses the preconfigured mapping)
- LSRSは、上記の仕様に従ってLDPを使用してFECあたりの単一E-LSPのシグナル確立（つまり、LDPラベルリクエスト/ラベルマッピングメッセージには、LSPがE-LSPであり、使用していることを暗黙的に示すために、LDPラベルマッピングメッセージにはありません。事前に設定されたマッピング）
A Service Provider running more than 8 BAs over MPLS, not performing Traffic Engineering, not using MPLS protection and using MPLS Shim encapsulation in his/her network may elect to run Diff-Serv over MPLS using for each FEC:
MPLSで8 basを実行しているサービスプロバイダーは、MPLS保護を使用せず、MPLS保護を使用せず、MPLSシムカプセル化を使用して、各FECを使用してMPLSを使用してDIFFSERVを実行することを選択する場合があります。
- one E-LSP established via LDP and using the preconfigured mapping to support a set of 8 (or less) BAs, AND
- LDPを介して確立され、事前に設定されたマッピングを使用して8（以下）のBASのセットをサポートする1つのE-LSP、および
- one L-LSP per <FEC,OA> established via LDP for support of the other BAs.
- 他のBASのサポートのためにLDPを介して確立された1つのL-LSP <FEC、OA>。
Operations can be summarized as follows:
操作は次のように要約できます。
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field for the BAs transported over the E-LSP
- サービスプロバイダーは、すべてのLSRで、各PHB間の双方向マッピングと、e-lspで輸送されるBASのEXPフィールドの値を構成します
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the E-LSP and the dropping behavior for each corresponding PHB
- サービスプロバイダーはすべてのLSRで構成され、すべてのインターフェイスについて、e-LSPでサポートされる各PSCのスケジューリング動作と、対応する各PHBのドロップ動作を構成します
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the L-LSPs and the dropping behavior for each corresponding PHB
- サービスプロバイダーはすべてのLSRで構成され、すべてのインターフェイスについて、L-LSPでサポートされる各PSCのスケジューリング動作と、対応する各PHBのドロップ挙動が
- LSRs signal establishment of a single E-LSP per FEC for the set of E-LSP transported BAs using LDP as specified above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP and that it uses the preconfigured mapping)
- LSRSは、上記で指定されたLDPを使用してE-LSP輸送BASのセットのFECあたりの単一E-LSPの確立を信号します（つまり、LDPラベルリクエスト/ラベルマッピングメッセージにDIFF-SERV TLVはありません。-LSPおよびそれは、事前に設定されたマッピングを使用すること）
- LSRs signal establishment of one L-LSP per <FEC,OA> for the other BAs using LDP as specified above (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping messages to indicate the L-LSP's PSC).
- LSRSは、上記で指定されたLDPを使用して他のBASを使用した1つのL-LSP、OA>の1つのl-LSPの確立を信号します（つまり、LDPラベルリクエスト/ラベルマッピングメッセージでL-LSPのPSCを示すLABELマッピングメッセージ）。
A Service Provider running 8 (or fewer) BAs over MPLS, performing aggregate Traffic Engineering (i.e., performing a single common path selection for all BAs), using aggregate MPLS protection (i.e., restoring service to all PSCs jointly) and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff-Serv over MPLS using a single E-LSP per FEC established via RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE] and using the preconfigured mapping.
MPLSで8（または少ない）BASを実行しているサービスプロバイダー、集約トラフィックエンジニアリング（つまり、すべてのBASの単一の共通パス選択を実行する）、集約MPLS保護を使用して（つまり、すべてのPSCへのサービスの復元）、MPLSシムヘッダーの使用彼/彼女のネットワークでのカプセル化は、RSVP [RSVP_MPLS_TE]またはCR-LDP [CR-LDP_MPLS_TE]を介して確立されたFECごとに単一のE-LSPを使用して、MPLSを使用してMPLSを介してDiff-Servを実行し、事前に設定されたマッピングを使用することを選択する場合があります。
Operations can be summarized as follows:
操作は次のように要約できます。
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
- サービスプロバイダーは、すべてのLSRで、各PHBとEXPフィールドの値の間の双方向マッピングを構成します（例：000 <-> AF11、001 <-> AF12、010 <-> AF13）
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13)
- サービスプロバイダーはすべてのLSRで構成され、すべてのインターフェイスについて、各PSCのスケジューリング動作（たとえば、AF1に割り当てられた帯域幅）と各PHBのドロップ挙動（AF11、AF12、AF13のドロッププロファイル）
- LSRs signal establishment of a single E-LSP per FEC which will use the preconfigured mapping:
- LSRSは、事前に構成されたマッピングを使用するFECごとに単一のe-LSPの確立を信号します。
* using the RSVP protocol as specified above (i.e., no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR
* 上記で指定されているRSVPプロトコルを使用します（つまり、label_requestオブジェクトを含むパスメッセージにdiffserv rsvpオブジェクトはありません）、または
* using the CR-LDP protocol as specified above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages).
* 上記で指定されているCR-LDPプロトコルを使用します（つまり、LDPラベルリクエスト/ラベルマッピングメッセージにDIFF-SERV TLVはありません）。
- protection is activated on all the E-LSPs in order to achieve MPLS protection via mechanisms outside the scope of this document.
- このドキュメントの範囲外のメカニズムを介してMPLS保護を実現するために、すべてのE-LSPで保護が活性化されます。
A Service Provider running any number of BAs over MPLS, performing per-OA Traffic Engineering (i.e., performing a separate path selection for each OA) and performing per-OA MPLS protection (i.e., performing protection with potentially different levels of protection for the different OAs) in his/her network, may elect to run Diff-Serv over MPLS using one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP.
MPLSを介して任意の数のBASを実行し、OAごとのトラフィックエンジニアリングを実行し（つまり、各OAの個別のパス選択を実行します）、OAごとのMPLS保護を実行するサービスプロバイダー（つまり、異なるレベルの保護を潜在的に異なるレベルの保護で保護を実行します。OAS）彼/彼女のネットワークでは、RSVPまたはCR-LDPを介して確立された1つのl-LSP、OA>ペアを使用して、MPLSを介してDiff-Servを実行することを選択できます。
Operations can be summarized as follows:
操作は次のように要約できます。
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13)
- サービスプロバイダーはすべてのLSRで構成され、すべてのインターフェイスについて、各PSCのスケジューリング動作（たとえば、AF1に割り当てられた帯域幅）と各PHBのドロップ挙動（たとえば、AF11、AF12、AF13のドロッププロファイル）
- LSRs signal establishment of one L-LSP per <FEC,OA>:
- lsrs信号<fec、oa>あたり1つのl-lspの確立：
* using the RSVP as specified above to signal the L-LSP's PSC (i.e., DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR
* 上記のRSVPを使用して、L-LSPのPSC（つまり、label_requestを含むパスメッセージのdiffserv rsvpオブジェクト）、または
* using the CR-LDP protocol as specified above to signal the L-LSP PSC (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping messages).
* 上記のCR-LDPプロトコルを使用して、L-LSP PSC（つまり、LDPラベルリクエスト/ラベルマッピングメッセージのdiff-serv tlv）を通知します。
- the appropriate level of protection is activated on the different L-LSPs (potentially with a different level of protection for each PSC) via mechanisms outside the scope of this document.
- 適切なレベルの保護は、このドキュメントの範囲外のメカニズムを介して、異なるL-LSP（潜在的には各PSCに対して異なるレベルの保護を伴う可能性がある）でアクティブになります。
A Service Provider running 8 (or fewer) BAs over MPLS, performing per-OA Traffic Engineering (i.e., performing a separate path selection for each OA) and performing per-OA MPLS protection (i.e., performing protection with potentially different levels of protection for the different OAs) in his/her network, may elect to run Diff-Serv over MPLS using one E-LSP per <FEC,OA> pair established via RSVP or CR-LDP. Furthermore, the Service Provider may elect to use the preconfigured mapping on all the E-LSPs.
MPLSで8（または少ない）BASを実行し、OAごとのトラフィックエンジニアリングを実行し（つまり、各OAに対して個別のパス選択を実行する）、OAごとのMPLS保護を実行するサービスプロバイダー（つまり、潜在的に異なるレベルの保護で保護を実行します。異なるOAS）は、彼/彼女のネットワークで、RSVPまたはCR-LDPを介して確立された1つのE-LSP、OA>ペアを使用して、MPLSを介してDIFSERVを実行することを選択できます。さらに、サービスプロバイダーは、すべてのE-LSPで事前に設定されたマッピングを使用することを選択できます。
Operations can be summarized as follows:
操作は次のように要約できます。
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field (e.g., 000<-->AF11, 001<-->AF12, 010<-->AF13)
- サービスプロバイダーは、すべてのLSRで、各PHBとEXPフィールドの値の間の双方向マッピングを構成します（例：000 <-> AF11、001 <-> AF12、010 <-> AF13）
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13)
- サービスプロバイダーはすべてのLSRで構成され、すべてのインターフェイスについて、各PSCのスケジューリング動作（たとえば、AF1に割り当てられた帯域幅）と各PHBのドロップ挙動（AF11、AF12、AF13のドロッププロファイル）
- LSRs signal establishment of one E-LSP per <FEC,OA>:
- lsrs信号<fec、oa>あたり1つのe-lspの確立：
* using the RSVP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured mapping (i.e., no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR
* 上記のRSVPプロトコルを使用して、LSPが事前に構成されたマッピングを使用するE-LSPであることを示すために（つまり、label_requestを含むパスメッセージにdiffserv rsvpオブジェクトはありません）、または
* using the CR-LDP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured mapping (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages)
* 上記のCR-LDPプロトコルを使用して、LSPが事前に構成されたマッピングを使用するE-LSPであることを示すために（つまり、LDPラベルリクエスト/ラベルマッピングメッセージにDiff-Serv TLVはありません）。
- the Service Provider configures, for each E-LSP, at the head-end of that E-LSP, a filtering/forwarding criteria so that only the packets belonging to a given OA are forwarded on the E-LSP established for the corresponding FEC and corresponding OA.
- サービスプロバイダーは、各e-LSPに対して、そのe-lspのヘッドエンドで、フィルタリング/転送基準を構成します。対応するOA。
- the appropriate level of protection is activated on the different E-LSPs (potentially with a different level of protection depending on the PSC actually transported over each E-LSP) via mechanisms outside the scope of this document.
- 適切なレベルの保護は、このドキュメントの範囲外のメカニズムを介して、異なるE-LSP（実際に各E-LSPで実際に輸送されるPSCに応じて異なるレベルの保護を伴う可能性がある）で活性化されます。
A.6 Scenario 6: no Traffic Engineering/MPLS Protection on 8 BAs, per-OA Traffic Engineering/MPLS Protection on other BAs.
A.6シナリオ6：トラフィックエンジニアリング/MPLS保護なし8 BAS、他のBASのOAごとのトラフィックエンジニアリング/MPLS保護。
A Service Provider not performing Traffic Engineering/MPLS Protection on 8 (or fewer) BAs, performing per-OA Traffic Engineering/MPLS Protection on the other BAs (i.e., performing a separate path selection for each OA corresponding to the other BAs and performing MPLS Protection with a potentially different policy for each of these OA) and using the MPLS Shim encapsulation in his/her network may elect to run Diff-Serv over MPLS, using for each FEC:
8（または少ない）BASでトラフィックエンジニアリング/MPLS保護を実行しないサービスプロバイダーは、他のBASでOAごとのトラフィックエンジニアリング/MPLS保護を実行します（つまり、他のBASに対応し、MPLSを実行する各OAに対して個別のパス選択を実行しますこれらのOAのそれぞれに対して潜在的に異なるポリシーを持つ保護）および彼/彼女のネットワークでMPLSシムカプセル化を使用すると、各FECを使用して、MPLSを介してDiff-Servを実行することを選択できます。
- one E-LSP using the preconfigured mapping established via LDP to support the set of 8 (or fewer) non-traffic-engineered/non-protected BAs, AND
- LDPを介して確立された事前設定されたマッピングを使用して1つのE-LSPは、8（または少ない）非交通機関/非保護されていないBASのセットをサポートします。
- one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP for support of the other BAs.
- 他のBASのサポートのために、RSVPまたはCR-LDPを介して確立された1つのL-LSP、OA>ペア。
Operations can be summarized as follows:
操作は次のように要約できます。
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field for the BAs supported over the E-LSP
- サービスプロバイダーは、すべてのLSRで、各PHB間の双方向マッピングと、E-LSPでサポートされるBASのEXPフィールドの値を構成します
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the E-LSP and the dropping behavior for each corresponding PHB
- サービスプロバイダーはすべてのLSRで構成され、すべてのインターフェイスについて、e-LSPでサポートされる各PSCのスケジューリング動作と、対応する各PHBのドロップ動作を構成します
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC supported over the L-LSPs and the dropping behavior for each corresponding PHB
- サービスプロバイダーはすべてのLSRで構成され、すべてのインターフェイスについて、L-LSPでサポートされる各PSCのスケジューリング動作と、対応する各PHBのドロップ挙動が
- LSRs signal establishment of a single E-LSP per FEC for the non-traffic engineered BAs using LDP as specified above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages)
- LSRSは、上記で指定されたLDPを使用して、非トラフィックエンジニアリングBASのFECあたりの単一のe-LSPの確立を確立します（つまり、LDPラベルリクエスト/ラベルマッピングメッセージにDIFF-Serv TLVはありません）
- LSRs signal establishment of one L-LSP per <FEC,OA> for the other BAs:
- LSRSは、他のBASの1つのl-LSP、OA>の1つのl-lspの確立を信号します。
* using the RSVP protocol as specified above to signal the L-LSP PSC (i.e., DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR
* 上記のRSVPプロトコルを使用して、L-LSP PSC（つまり、label_requestオブジェクトを含むパスメッセージのdiffserv rsvpオブジェクト）、または
* using the CR-LDP protocol as specified above to signal the L-LSP PSC (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping messages).
* 上記のCR-LDPプロトコルを使用して、L-LSP PSC（つまり、LDPラベルリクエスト/ラベルマッピングメッセージのdiff-serv tlv）を通知します。
- protection is not activated on the E-LSPs.
- E-LSPで保護は活性化されません。
- the appropriate level of protection is activated on the different L-LSPs (potentially with a different level of protection depending on the L-LSP's PSC) via mechanisms outside the scope of this document.
- 適切なレベルの保護は、このドキュメントの範囲外のメカニズムを介して、異なるL-LSP（L-LSPのPSCに応じて異なるレベルの保護を伴う可能性がある）で活性化されます。
A Service Provider running more than 8 BAs over MPLS, not performing Traffic engineering, not performing MPLS protection and using MPLS Shim Header encapsulation in his/her network, may elect to run Diff-Serv over MPLS using two E-LSPs per FEC established via LDP and using signaled `EXP<-->PHB mapping'.
MPLSで8 basを実行するサービスプロバイダーは、交通工学を実行せず、MPLS保護を実行せず、MPLSシムヘッダーカプセル化を使用して自分のネットワークでカプセル化することを選択できます。LDPおよびシグナル付き「exp < - > phbマッピング」を使用します。
Operations can be summarized as follows:
操作は次のように要約できます。
- the Service Provider configures at every LSR, and for every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13)
- サービスプロバイダーはすべてのLSRで構成され、すべてのインターフェイスについて、各PSCのスケジューリング動作（たとえば、AF1に割り当てられた帯域幅）と各PHBのドロップ挙動（たとえば、AF11、AF12、AF13のドロッププロファイル）
- LSRs signal establishment of two E-LSPs per FEC using LDP in accordance with the specification above (i.e., Diff-Serv TLV in LDP Label Request/Label Mapping messages to explicitly indicate that the LSP is an E-LSP and its `EXP<-->PHB mapping'). The signaled mapping will indicate the subset of 8 (or less) BAs to be transported on each E-LSP and what EXP values are mapped to each BA on each E-LSP.
- LSRSは、上記の仕様に従ってLDPを使用したFECあたり2つのE-LSPの確立を信号します（つまり、LDPラベルリクエスト/ラベルマッピングメッセージのDIFF-SERV TLVは、LSPがE-LSPであり、その `exp < - であることを明示的に示します。 - > phbマッピング '）。信号マッピングは、各e-LSPで輸送される8（またはそれ以下の）BASのサブセットと、各e-LSPの各BAにマッピングされるEXP値を示します。
APPENDIX B. Example Bandwidth Reservation Scenarios
付録B.例の帯域幅予約シナリオ
Consider the case where a network administrator elects to:
ネットワーク管理者が次のように選択する場合を検討してください。
- have Diff-Serv resources entirely provisioned off-line (e.g., via Command Line Interface, via SNMP, via COPS,...)
- オフラインで完全にプロビジョニングされた差別的なリソースを持っています（例：コマンドラインインターフェイスを介して、SNMPを介して、警官を介して...）
- have Shortest Path Routing used for all the Diff-Serv traffic.
- すべてのdif-servトラフィックに使用される最短パスルーティングがあります。
This is the closest model to provisioned Diff-Serv over non-MPLS IP. In that case, E-LSPs and/or L-LSPs would be established without signaled bandwidth.
これは、非MPLS IPよりもプロビジョニングされたDIFF-Servに最も近いモデルです。その場合、E-LSPおよび/またはL-LSPは、信号帯域幅なしで確立されます。
Consider the case where a network administrator elects to:
ネットワーク管理者が次のように選択する場合を検討してください。
- have Diff-Serv resources entirely provisioned off-line (e.g., via Command Line Interface, via SNMP, via COPS,...)
- オフラインで完全にプロビジョニングされた差別的なリソースを持っています（例：コマンドラインインターフェイスを介して、SNMPを介して、警官を介して...）
- use L-LSPs
- L-LSPを使用します
- have Constraint Based Routing performed separately for each PSC, where one of the constraints is availability of bandwidth from the bandwidth allocated to the relevant PSC.
- 制約ベースのルーティングは、各PSCに対して個別に実行されます。ここでは、制約の1つは、関連するPSCに割り当てられた帯域幅から帯域幅の可用性です。
In that case, L-LSPs would be established with signaled bandwidth. The bandwidth signaled at L-LSP establishment would be used by LSRs to perform admission control at every hop to ensure that the constraint on availability of bandwidth for the relevant PSC is met.
その場合、L-LSPは信号帯域幅で確立されます。L-LSP施設で合図された帯域幅は、LSRSによって使用され、すべてのホップで入学制御を実行して、関連するPSCの帯域幅の可用性に対する制約が満たされるようにします。
Consider the case where a network administrator elects to:
ネットワーク管理者が次のように選択する場合を検討してください。
- use L-LSPs
- L-LSPを使用します
- have Constraint Based Routing performed separately for each PSC, where one of the constraints is availability of bandwidth from the bandwidth allocated to the relevant PSC.
- 制約ベースのルーティングは、各PSCに対して個別に実行されます。ここでは、制約の1つは、関連するPSCに割り当てられた帯域幅から帯域幅の可用性です。
- have Diff-Serv resources dynamically adjusted
- Diff-Servリソースを動的に調整します
In that case, L-LSPs would be established with signaled bandwidth. The bandwidth signaled at L-LSP establishment would be used by LSRs to attempt to adjust the resources allocated to the relevant PSC (e.g., scheduling weight) and then perform admission control to ensure that the constraint on availability of bandwidth for the relevant PSC is met after the adjustment.
その場合、L-LSPは信号帯域幅で確立されます。L-LSP施設で合図された帯域幅は、LSRSによって使用され、関連するPSCに割り当てられたリソースを調整しようとします（例：スケジューリング重量）。調整後。
References
参考文献
[ANSI/IEEE] ANSI/IEEE Std 802.1D, 1993 Edition, incorporating IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, and P802.12e).
[ANSI/IEEE] ANSI/IEEE STD 802.1d、1993エディション、IEEEサプリメントP802.1p、802.1J-1996、802.6k-1992、802.11c-1998、およびP802.12Eを組み込み。
[ATMF_TM] ATM Forum, "Traffic Management Specification Version 4.1", March 1999.
[ATMF_TM] ATMフォーラム、「トラフィック管理仕様バージョン4.1」、1999年3月。
[CR-LDP_MPLS_TE] Jamoussi, B., Editor, Andersson, L., Callon, R. and R. Dantu, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[cr-ldp_mpls_te] Jamoussi、B.、Editor、Andersson、L.、Callon、R。and R. Dantu、「LDPを使用した制約ベースのLSPセットアップ」、RFC 3212、2002年1月。
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
[DClass] Bernet、Y。、「RSVP DClassオブジェクトの形式」、RFC 2996、2000年11月。
[DIFF_AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[diff_af] Heinanen、J.、Baker、F.、Weiss、W。and J. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[DIFF_ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[Diff_arch] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスのアーキテクチャ」、RFC 2475、1998年12月。
[DIFF_EF] Davie, B., Charny, A., Baker, F., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[Diff_ef] Davie、B.、Charny、A.、Baker、F.、Bennet、J.、Benson、K.、Boudec、J.、Chiu、A.、Courtney、W.、Davari、S.、Firoiu、V.、Kalmanek、C.、Ramakrishnam、K。、およびD. Stiliadis、「迅速な転送PHB（ホップあたりの行動）」、RFC 3246、2002年3月。
[DIFF_HEADER] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[diff_header]ニコルズ、K。、ブレイク、S。、ベイカー、F。、およびD.ブラック、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[DIFF_NEW] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[diff_new]グロスマン、D。、「diffservの新しい用語と説明」、RFC 3260、2002年4月。
[DIFF_TUNNEL] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[diff_tunnel] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[ECN] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[ECN] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision and redesignation of ISO/IEC 10038:98.
[IEEE_802.1] ISO/IEC 15802-3：1998 ANSI/IEEE STD 802.1d、1998エディション（ISO/IEC 10038：98の改訂と再指定。
[LDP] Andersson, L., Doolan, D., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[LDP] Andersson、L.、Doolan、D.、Feldman、N.、Fredette、A。and B. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[MPLS_ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS_ARCH] Rosen、E.、Viswanathan、A。およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、2001年1月。
[MPLS_ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[MPLS_ATM] Davie、B.、Lawrence、J.、McCloghrie、K.、Rosen、E.、Swallow、G.、Rekhter、Y.、P。Doolan、「LDPおよびATM VCスイッチングを使用したMPLS」、RFC 3035、2001年1月。
[MPLS_ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS_ENCAPS] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。およびA. Conta、「MPLS Label Stack Encoding」、RFC 3032、2001年1月。
[MPLS_FR] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[MPLS_FR] Conta、A.、Doolan、P。およびA. Malis、「フレームリレーネットワーク仕様のラベルスイッチングの使用」、RFC 3034、2001年1月。
[MPLS_VPN] Rosen, E., "BGP/MPLS VPNs", Work in Progress.
[MPLS_VPN] Rosen、E。、「BGP/MPLS VPNS」、進行中の作業。
[NULL] Bernet, Y., Smith, A. and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
[Null] Bernet、Y.、Smith、A。and B. Davie、「Nullサービスタイプの仕様」、RFC 2997、2000年11月。
[PHBID] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes" RFC 3140, June 2001.
[Phbid] Black、D.、Brim、S.、Carpenter、B。and F. Le Faucheur、「Per Hopの動作識別コード」RFC 3140、2001年6月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RSVP_MPLS_TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP_MPLS_TE] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。およびG. Swallow、「LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
Authors' Addresses
著者のアドレス
Francois Le Faucheur Cisco Systems Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France
Francois le Faucheur Cisco Systems Village D'Entreprise Green Side -Batiment T3 400、Avenue de Roumanille 06410 Biot -Sophia Antipolis France
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Liwen Wu Cisco Systems 3550 Cisco Way San Jose, CA 95134 USA
Liwen Wu Cisco Systems 3550 Cisco Way San Jose、CA 95134 USA
Phone: +1 (408) 853-4065
EMail: liwwu@cisco.com
Bruce Davie Cisco Systems 250 Apollo Drive, Chelmsford, MA 01824 USA
ブルースデイビーシスコシステム250アポロドライブ、チェルムスフォード、マサチューセッツ州01824 USA
Phone: +1 (978) 244-8000
EMail: bsd@cisco.com
Shahram Davari PMC-Sierra Inc. 411 Legget Drive Kanata, Ontario K2K 3C9 Canada
Shahram Davari PMC-Sierra Inc. 411 Legget Drive Kanata、オンタリオK2K 3C9カナダ
Phone: +1 (613) 271-4018 EMail: davari@ieee.org Pasi Vaananen Nokia 3 Burlington Woods Drive, Suit 250 Burlington, MA 01803 USA
電話：1（613）271-4018メール：davari@ieee.org pasi vaananen nokia 3バーリントンウッズドライブ、スーツ250バーリントン、マサチューセッツ州01803 USA
Phone +1 (781) 993-4900 EMail: pasi.vaananen@nokia.com
電話1（781）993-4900メール：pasi.vaananen@nokia.com
Ram Krishnan Axiowave Networks 200 Nickerson Road Marlboro, MA 01752
Ram Krishnan Axiowave Networks 200 Nickerson Road Marlboro、MA 01752
EMail: ram@axiowave.com
Pierrick Cheval Alcatel 5 rue Noel-Pons 92737 Nanterre Cedex France EMail: pierrick.cheval@space.alcatel.fr
Pierrick Cheval Alcatel 5 Rue Noel-Pons 92737 Nanterre Cedex Franceメール：Pierrick.cheval@space.alcatel.fr
Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland
Juha Heinanen Song Networks、Inc。Hallituskatu 16 33200タンペレ、フィンランド
EMail: jh@song.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。