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
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.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks.
この文書は（MPLS）ネットワークをマルチプロトコルラベルスイッチングオーバー差別化サービス（差分-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.
このソリューションは、彼/彼女は最高の彼/彼女の特定の内のDiff-Servの、交通工学と保護の目標を一致させることができるようにラベルスイッチパス（LSP）へのDiff-Servの行動の集計（BAS）がマッピングされている方法を選択するために、MPLSネットワークの管理者にすることができます通信網。例えば、この溶液は、のBAの異なるセットが同じ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]において、ラベルスイッチパス（LSP）は、MPLSシグナリングプロトコルを使用して確立することができます。イングレスラベルスイッチルータ（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]のリンクを横断し、同じ差分-SERVの動作を必要とするすべてのIPパケットが動作集約（BA）を構成すると言われています。差分-SERVドメインの入口ノードにおいて、パケットが分類され、それらの行動の集合に対応する差分-SERVコードポイント（DSCP）の付きました。各トランジットノードでは、DSCPは、スケジューリング処理を決定し、いくつかのケースでは、パケットごとに確率をドロップ当たりホップの動作（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.
この文書では、差分-SERVの動作をサポートするための解決策は、その対応のPHB現在MPLSネットワーク上（[DIFF_EF]、[DIFF_AF]、[DIFF_HEADER]で）定義されている集約指定します。このソリューションはまた、将来的に定義されるのPHBの簡単な支援のための柔軟性を提供しています。
This solution relies on the combined use of two types of LSPs:
このソリューションは、LSPの2種類の併用に依存しています：
- 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にPHBを搬送するように、複数の順序付けられた集合体を輸送することができる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によって推測されるように、パケットの廃棄優先順位をMPLSシムヘッダのEXPフィールドに、または特定のカプセル化リンクレイヤで搬送されている間のみ排他的にパケットのラベル値から、単一の順序集合を輸送するLSP選択ドロップメカニズム（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]で述べたように、「サービス・プロバイダは、そのネットワーク内のサービスの差別化を可能にするために、同じノードの仕組みや構成を使用する必要があり、そのサービスの提供や交通工学のための適切な何らかの方法でノードのパラメータを設定するのは自由ですされていません目標」。したがって、この文書で定義されたソリューションは、そのドメイン内のサービスの差分-Servのクラスがルーティングされる方法の選択や交通エンジニアにサービスプロバイダの柔軟性を提供します（例えば、別々の独立した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にさまざまなレベルの保護を提供するかもしれないことに注意してください。ここで紹介するソリューションは、サービスプロバイダは、サービスの差分-ServのクラスはLSPの上にマッピングされている方法を選択することができますので、解決策はまた、サービスプロバイダにサービスの異なる差分-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.
また、この文書で指定された解決策は、ラベルスペースの節約を達成し、シグナルラベルセットアップ/ティアダウンの量を低減可能な場合のみ（FEC）[MPLS_ARCH]際に有用または必要所与の転送等価クラスの複数のLSPに頼ることによって。
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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_FR]、[MPLS_ATM]、[MPLS_ENCAPS]、[MPLS_ARCH]の用語に精通していると仮定されます。
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_EF]、[DIFF_AF]、[DIFF_HEADER]、[DIFF_ARCH]の用語に精通していると仮定されます。
AF Assured Forwarding
AF保証転送
BA Behavior Aggregate
BAの行動集計
CS Class Selector
CSクラスセレクタ
DF Default Forwarding
DFデフォルトフォワーディング
DSCP Differentiated Services Code Point
DSCP DiffServコードポイント
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に属する行動集合（S）に印加される1つ以上のPHB（S）のセット。例えば、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廃棄資格
SNMP Simple Network Management Protocol
SNMP簡易ネットワーク管理プロトコル
Finally, the following acronyms are defined in this specification:
最後に、以下の頭字語は、本明細書で定義されています。
E-LSP EXP-Inferred-PSC LSP
E-LSP EXP-推定される-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は、一の以上のOAをサポートするために使用することができます。このようなLSPは関係なく、どのように多くのOAこれらのBAスパンの、与えられたFECの8つのBAをサポートすることができます。そのようなLSPを用いて、MPLSシムヘッダのEXPフィールドは、パケットに適用されるPHBを決定するLSRによって使用されます。これは、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フィールド値に依存するため、我々は、「EXP-推論-PSCのLSP」（E-LSP）などの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のためにPHBのEXPフィールドからマッピング（すなわち、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).
別LSPは、単一の<FEC、OA>ペアのために確立することができます。ラベル設立後、LSRは、PSCは、ラベル付きパケットに適用されるラベル値のみから推測できるように、このようなLSPのでは、PSCは、明示的に、ラベルの確立時に通知されます。シムヘッダが使用される場合、標識されたパケットにLSRによって適用されるドロップ優先順位は、EXPフィールドを使用して標識されたパケットMPLSシムヘッダ内部に搬送されます。シムヘッダが（例えば、MPLSオーバーATM）を使用しない場合、ドロップ優先順位は、標識されたパケットに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.
PSCは、（例えば、関係なくEXPフィールド値の）他の情報なしラベルから完全に推測することができるので、我々は、「ラベル専用推定さ-PSCのLSP」（L-LSP）などの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のための、及び8、セクション7で識別されるメディア固有の制限が適用されない限り、以下に図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が存在してもよいです。しかし注文の制約を尊重するために、与えられたマイクロフローの全てのパケットは、おそらく所与の順序集合の複数のBAをまたがる、同じLSP上に輸送されなければなりません。逆に、各LSPは、所与のOAのすべての（アクティブ）のBAをサポートできなければなりません。
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.'
セクション `2.1 [MPLS_ARCH]状態。その「概要： `一部のルータは、パケットのネクストホップを選択することが、また、パケットの『優先度』や『サービスクラス』を決定していないだけで、パケットのネットワーク層ヘッダを分析します。そして、彼らは別のパケットに異なる廃棄しきい値またはスケジューリング規律を適用することができます。 MPLSは、precedenceまたはサービスのクラスは、完全に、または部分的にラベルから推測することができます（ただし、必須ではありません）。この場合、1は、ラベルは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を介して転送のBAのセットの組み合わせを表します。サポートされているすべてのBAは、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（S）プロビジョニングのDiff-Servのリソース（例えば、構成を介して、SNMPまたはポリシープロトコル）を介してシグナリングさLSPのアドミッション制御を実行するために設立時のLSRによって使用されてもよいです。そのようなシグナリング帯域幅要件は、関連するPSC（単数または複数）（例えば、PSCスケジューリングの重みを調整する）に関連付けられた差分-SERVリソースに調整を行うこと確立時のLSRによって使用されてもよいです。
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を差別化サービス、必要な転送処理（スケジューリングとドロップポリシー）をサポートするため、この文書で指定されているので、適切な差分-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に保証帯域幅にわたって）PSCに専用であるのDiff-Servのリソース上アドミッション制御を実行することができます。
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で、従って輸送のPSCsのセットにまとめて関連しています。したがって、アドミッション制御を実行するシグナリング帯域幅を使用するのLSR（例えば、リンクの総帯域幅を超える）のPSCsのセットによって共有されるグローバルリソース、上アドミッション制御を実行することができます。
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上で転送することができるので、差分-ServのLSRのラベルスワップの決定は明らかに転送されたパケットの行動の集計に依存します。転送されたパケットのIP DSフィールドはLSRに直接見えないかもしれないので、また、受信したパケットに適用されるPHBを決定し、送信されたパケットにPHBを符号化するための方法は、非MPLSは異なりますデフ-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:
このように、差分-SERVのLSRでラベル転送を説明するために、我々は4つの段階で構成さ振る舞いを切り替えるLSRのDiff-Servのラベルを、モデル：
- Incoming PHB Determination (A)
- 着信PHBの決意（A）
- Outgoing PHB Determination with Optional Traffic Conditioning(B)
- オプションのトラフィックコンディショニング（B）での発信PHBの決意
- 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.
明らかに、LSRはまた、送信PHBに対応する転送処理を適用しなければならないのDiff-Servのサービスの差別化を適用します。
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カプセル化層で符号化差分-Servの関連情報を指定する（例えば、EXPフィールド、ATM CLP、フレームリレーDE、802.1 User_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.
このモデルは、差分-ServのののLSRの機能動作を記述するためにここに提示され、実際の実装を制約しません。
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は、与えられた受信されたラベルスタックエントリを考慮着信PHBの決意を実行する方法に関する詳細を提供および/または受信LSPの種類に応じて、着信MPLSカプセル化に応じて着信MPLSカプセル化情報を受信しました。
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節では、サポートのDiff-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は、IPヘッダがサポートされている差分-SERVトンネリングモデルに応じて、着信PHBの決意のために考慮するときの詳細を提供します。 IPヘッダが使用されるような場合では、この段階では正確非MPLS IPのDiff-Servのルータのように動作し、着信PHBを決定するために、DSフィールドを使用します。
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のを特定の目的のために、我々は、単に、関連していたPHBに異なっていてもよく、PHBは、実際に（「発信PHB」と称する）LSRによって実施し、下流のLSRに搬送されることに注意してください前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】ラベルスワッピングは、各入力ラベルは、1つまたは複数NHLFEsにマッピングされる着信ラベルマップ（ILM）を使用して着信標識されたパケットでのLSRによって実行される方法を記載しています。 【MPLS_ARCH】また、ラベル面付けを使用して、着信非標識パケットでのLSRによって実行される方法を説明FECツーNHLFEs各着信FECは、1つまたは複数NHLFEsにマッピングされたマップ（FTN）。
A Diff-Serv Context for a label is comprised of:
ラベル用のDiff-Servのコンテキストがで構成されています。
- `LSP type (i.e., E-LSP or L-LSP)'
- `LSPタイプ（すなわち、E-LSPまたはL-LSP）」
- `supported PHBs'
- `のPHBをサポート
- `Encaps-->PHB mapping' for an incoming label
- `ENCAPS - 着信ラベル用> PHBのマッピング」
- `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.
本明細書は差分-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はまた、適切にパケット」を処分するために必要な他の情報を含むことができると述べています。これによれば、本明細書は差分-SERVコンテキストスワップ又は押し込まれる各発信ラベルNHLFEに格納されていることを定義します。
This Diff-Serv Context information is populated into the ILM and the FTN at label establishment time.
この差分-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で後述するPHBマッピング」、。
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'.
< - >ラベルは、E-LSP `EXPいるに対応する場合、< - > PHBマッピングが」明示LSPセットアップで合図された、`のPHBをサポート合図 `EXPののPHBのセットが取り込まれ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セットアップでシグナリングされるPSCを形成するの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.
> PHBマッピング」または `PHBのセット - - > ENCAPSマッピング人口はセクション3と4で以下に定義されている` ENCAPSの方法の詳細。
[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]は一つの要素よりも多く含まれているNHLFEsのセットに特定のラベルをマッピングした場合、パケットが転送される前に、一連の正確に一つの要素を選択する必要があります。セットから要素を選択するための手続きでありますこのドキュメントの範囲。例えば、もし有用である可能性がある複数のNHLFEを含むセットにILM [それぞれ、FTN]ラベルをマップ[それぞれ、FEC]を持つ超えて、複数のイコール上で負荷分散を行うことが望まれますコストパス。」
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.
これによれば、本明細書は、その着信ラベルを可能にする[それぞれFEC]は複数NHLFEs（例えば異なるNHLFEsがのPHBの異なるセットをサポート出力ラベルに対応する場合）に、差分-Servの目的のために、マッピングされてもよいです。ときにラベル[それぞれFEC]複数NHLFEsにマップ、のDiff-ServのLSRは、差分-Servのコンテキストには転送されたパケットの発信PHBをサポートしていることを示しNHLFEsのいずれかを選択しなければなりません。
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.
ラベル送信PHBをサポートする複数NHLFEsに【それぞれFEC】マップは、それらのうちのいずれかを選択するための手順は、この文書の範囲外である場合。複数の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シム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カプセル化情報に差分-SERV情報の符号化を実行する方法の詳細を提供します。
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は、サポートされている差分-SERVトンネリングモードに応じに差分-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のルータのように動作し、DSフィールドに発信PHBのDSCPをコードします。
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は、差分-SERV情報のエンコーディングがサポートされている差分-SERVトンネリングモードに応じて送信された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は、MPLSは、IPヘッダが含まれていないヘッダをカプセル化し、したがって、MPLSのLSPのが[DIFF_TUNNEL]に考慮されていないので、「IPトンネル」の形ではありません。しかし、「IPトンネル」のない形態が、MPLS LSPは「トンネル」の形態です。
From the Diff-Serv standpoint, LSPs share a number of common characteristics with IP Tunnels:
デフ-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:
しかし、差分-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トンネルで使用される最後から二番目のホップポップ（PHP）に類似した何の動作は、一般的にありません。また、LSPは、LSPの出口に見えないに関連付けられた「外側」のDiff-Servの情報でPHPをもたらします。この情報はLSP出口で意味のない状況では、これは明らかに全く問題ではありません。 LSP出口で、この情報は意味がある状況では、それは何らかの形で他の手段で搬送されなければなりません。
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トンネル上のDiff-Servのトンネリングのための2つの概念モデルは、MPLS上のDiff-Servのに適用できると便利であるが、それらのそれぞれの詳細な動作は、MPLS上多少異なっています。これらの2つのモデルがパイプモデルと統一モデルです。 MPLSを超える彼らの操作は、次のセクションで指定されています。代替トンネリングモデルの議論と定義この仕様の範囲外です。
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は）のDiff-Servの観点からLSP入力および出力の間の中間MPLSノードを隠すために使用されます。
In this model, tunneled packets must convey two meaningful pieces of Diff-Serv information:
このモデルでは、トンネルパケットは、差分-Servの情報の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のDiff-Servの情報」と呼ぶ）LSP出口を含むLSPスパンに沿った中間ノードに意味のある相違-SERV情報。このLSPのDiff-Servの情報は、LSP出口を越えては意味がありません：LSPスパンの中間ノードでのトラフィック調整がLSPのDiff-Servの情報に影響を与えるかどうかは、この更新のDiff-Servの情報は、LSP出口を超えて意味のあるとみなされているされていません無視。
- 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.
- （私たちは「トンネル化のDiff-Servの情報」と呼ぶ）LSP出口を超えた意味があるのDiff-Servの情報。この情報は、LSP出口にLSPイングレスによって搬送されます。この差分-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出口は（ポップする前に、IE）外部ヘッダで受信LSPのDiff-Servの情報を考慮し（*） "トンネリングのDiff-Servの情報" を表す "LSPのDiff-Servの情報"（M）を表しますその差分-Servの転送処理（すなわち、実際のPHB）を適用するために、私はLSPの入口ノードEがLSPの出口ノードを表し
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出口に伝達する必要があります。 「トンネリングのDiff-Servの情報」はまた、それがさらに下流に搬送することができるように、LSP出口に搬送する必要があります。
Since both require that Diff-Serv information be conveyed to the LSP Egress, the Pipe Model operates only without PHP.
両者が相違-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イングレスの着信インターフェイスとLSP出口の発信インターフェイスの下流雲の上流の雲は、差分-SERVサービスプロビジョニングポリシーおよびPHB定義の共通セットを使用して差分-SERVドメインであります1つ（または複数）のDiff-Servのドメイン（複数可）を使用する（S）のDiff-ServのサービスプロビジョニングポリシーおよびPHB定義の異なる組
- the outgoing interface of the LSP Egress is in the (last) Diff-Serv domain spanned by the LSP.
- LSP出口の発信インターフェイスは、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
一例として、サービスプロバイダは、MPLS VPNサービスを提供している場合を考えるのDiff-Servの分化を含む（MPLS VPNアーキテクチャの例について[MPLS_VPN]参照）。サイトのコレクションは、このようなMPLS VPNサービスを介して相互に接続されていることを言います。今、サイトのこのコレクションは、共通の管理の下で管理され、また、差分-Servのサービスの差別化を支援していると言います。もしVPNサイトの管理とサービス
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サービス上パイプモデルでのDiff-Servのの動作はVPNサイトのDiff-Servのポリシーが一貫して動作することを可能にする、（例えば、のPHBの同じ数をサポートしていない）まったく同じ差分-SERVポリシーを共有していません進入VPNサイトおよび出力VPNサイト全体にかつ透過的にサービスプロバイダのDiff-Servのドメインを超えます。物理的に中間ネットワークノードによって分離することができるにもかかわらず、これらのエンドポイントは、事実上連続することによって、単一のDiff-Servの領域に、そのエンドポイントでのDiff-Servのドメインを連結するようなLSPを表示するのに有用であり得ます。
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は、受信PHBの決意と次のようでのDiff-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に対して実行する場合、特に、LSRはポップ前に受信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が押されたラベルに対応する送信ラベルエントリのOUTGOING PHBに対応する差分-SERV情報を符号化します。
o encodes Diff-Serv Information corresponding to the INCOMING PHB in the encapsulated header (swapped label entry or IP header).
oは差分-SERV情報がカプセル化ヘッダ（スワップされたラベルエントリまたはIPヘッダ）にINCOMING PHBに対応するコード。
- 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は、差分-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のためのポップ動作を行う場合、LSRはポップ動作によって露出されたヘッダ内の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出口でのDiff-Servの転送処理が「トンネリングのDiff-Servの情報」（すなわち、カプセル化ヘッダで搬送のDiff-Servの情報）にではなく、「LSPのDiff-Servの情報」に基づいて適用される（すなわち、カプセル化ヘッダで搬送、差分-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）が "トンネリングのDiff-Servの情報" を表すIはLSP入口ノードEがLSPの出口ノードを表し、 "LSPのDiff-Servの情報"（M）を表します
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出口が「トンネリングのDiff-Servの情報」に基づいて転送処理を適用しているので、「LSPのDiff-Servの情報は、」LSP出口に最後から二番目のノードによって搬送される必要はありません。したがって、ショートパイプモデルも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）は最後から2番目LSRが（ポップする前に、IE）外部ヘッダで受信LSPのDiff-Servの情報を考慮し（*） "トンネリングのDiff-Servの情報" を表す "LSPのDiff-Servの情報"（M）を表しますその差分-Servの転送処理（すなわち、実際のPHB）を適用するためにI PはLSPの最後から二番目のノードEがLSPの出口ノードを表しLSPの入口ノードを表します
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イングレスの着信インターフェイスとLSP出口の発信インターフェイスの下流雲の上流の雲は、差分-SERVサービスプロビジョニングポリシーおよびPHB定義の共通セットを使用して差分-SERVドメインであります1つ（または複数）のDiff-Servのドメイン（複数可）を使用する（S）のDiff-ServのサービスプロビジョニングポリシーおよびPHB定義の異なる組
- the outgoing interface of the LSP Egress is in the same Diff-Serv domain as the cloud downstream of it.
- LSP出口の発信インターフェイスは、それの下流雲と同様の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出口の各発信インターフェイスはそれの下流雲と同じ差分-SERV領域であるため、それぞれの発信インタフェースは、潜在的に異なる差分-SERVドメインであってもよく、LSP出口はすべての対応を意識して設定する必要がありますデフ-Servのポリシー。この操作のオーバーヘッドは、それぞれの下流のDiff-Servの方針はLSPスパンで使用される共通のDiff-Servの政策よりも、各出力インターフェイス上でサービスの差別化を提供することに適しているいくつかの状況では正当化されます。サービスプロバイダは、MPLS VPNサービスを提供していますし、どこそのような状況の例があり、一部のVPNユーザーが独自のVPNのDiff-Servのポリシーが先VPNサイトへのLSP出口から専用リンク上でサービスの差別化を制御するために適用されることを要求する場合は、むしろ、サービスプロバイダーの差分-Servの政策よりも。
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の決意と差分-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に対して実行する場合、特に、LSRはポップAFTER着信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判別の差分-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.
- 最後から二番目LSRは、受信されたラベルスタックに外装ラベルエントリを考慮した着信PHBの決意を行います。ポップ操作を考慮LSPのために実行されるときに、他の言葉で、最後から二番目のLSRポップ前に受信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ショートパイプモードでの最後から二番目LSRの挙動は、（必ずしもPHPなし）パイプモードのLSP出口の動作と同一であることに留意されたいです。
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トンネルは、転送のために使用されるが、差分-SERVに有意な影響を有していなくてもよいです。このモデルでは、任意のパケットが有意義であり、常に（又はIPパケットがLSPの出口で、例えば非標識送信されるIP DSCPで）最も外側のラベルエントリに符号化される差分-SERV情報の正確に一つのピースが含まれています。どこか（例えば、より深いラベルエントリで）符号化された任意のDiff-Servの情報は、中間ノードまたはトンネル出口に重要ではないため、無視されます。 LSPスパン上の中間ノードにおけるトラフィックコンディショニングは「外側」のDiff-Servの情報に影響を与える場合、更新された差分-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）は、対応するヘッダで符号化された意味の差分-SERV情報を表します。 （x）は非意味の差分-SERV情報を表します。私は、LSP入口ノードEは、LSPの出口ノードを表し
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）は、対応するヘッダで符号化された意味の差分-SERV情報を表します。 （x）は非意味の差分-SERV情報を表します。 I PはLSPの最後から二番目のノードEがLSPの出口ノードを表し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のための統一モデルのDiff-Servの観点から、動作はMPLSを使用しなかった場合の動作と全く同じである、ようなものです。換言すれば、MPLSは、差分-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のドメインの間の物理的な境界でのドメイン間トラフィックコンディショニング協定よりも場所のメジャーと「外側」ヘッダのみに操作することなく差分-Servのドメインの境界にまたがることができます意味の差分-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の決意と次のようでのDiff-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に対して実行する場合、特に、LSRはポップ前に受信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は、差分-SERV情報が押されたラベルに対応する送信ラベルエントリに符号化します。カプセル化されたヘッダ（スワップされたラベルエントリまたはIPヘッダ）で符号化差分-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は、差分-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.
- 差分を行うために - 露出ヘッダ（> DSCPマッピング 'または `PHB）に対応するラベルの - 「> ENCAPSマッピングPHBのセット」PHPを使用した場合、最後から二番目LSRが認識する必要があります-Serv情報エンコーディング。このマッピングの認識を提供するための方法は、この仕様の範囲外です。一例として、「PHB - > DSCPマッピングは、」局所的に構成されてもよいです。露出されたヘッダに発信ラベルに使用されるPHBの」に設定される - > - 最後から二番目LSRは「> ENCAPSマッピングPHBのセット」と仮定する別の例として、いくつかの環境では、それが適切であるかもしれませんLSRは、PHPをやっていなかった場合はLSRによって使用されるENCAPSマッピング」。この仕様は、最後から二番目LSRは、ポップ操作（およびそれもポーズしたラベルを見ていないという事実にある）によって公開されたラベルエントリの上にラベルスワッピングを行わないことを前提としていることにも注意してください。その結果、制限は最後から二番目LSRによって行うことができるのDiff-Servの情報符号化に適用される場合があります。ポップにより露出ヘッダは、2つのL-LSPを各支持1つのPSCのラベル値を含むが、例えば、本明細書はDiff-ので、最後から二番目のLSRは、2つのPSCをサポートE-LSPに対応するラベルをポップ状況を許可しませんServの情報エンコーディングは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の行動が異なるだけであることに注意してください。このように、中間のLSRは関係なくパイプ、ショートパイプ又はユニフォームモデルで動作しているかどうか、まったく同じように動作し、LSPのためにスワップのみ動作を行います。差分-Servの実装は、複数のトンネリングモデルを支持するとともに、LSPイングレス最後から二番目のLSRまたはLSP出口として挙動のみのLSRは、特定のモデルで動作するように構成する必要があります。毎LSPに基づいて差分-SERVトンネリングモデルを関連付けるためのシグナリングは、この仕様の範囲内ではありません。
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 + 1のプッシュは、レベルNのためにプッシュを行うLSRに、後続の（または同じ）LSRに行われることを観察する（またはN LSPは、プッシュをやっイングレスLSRとポップをやっLSR（最後から二番目LSRまたはLSP出口）が同じトンネリングモデルで動作しなければならない与えられたレベルについてレベルNのポップをやっLSRに同じ）LSR（すなわち、パイプ、ショートパイプや制服）。しかし、異なるレベルでのLSPが異なるトンネリングモデルで動作することができるように、レベル間で一貫性のトンネリングモデルの必要はありません。
Hierarchical operations are illustrated below in the case of two levels of tunnels:
階層的な操作は、トンネルの二つのレベルの場合には以下に示します：
+--------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に従ってセクション2.6.2、2.6.2.1および2.6.3で指定されたようにレベルNの所与のLSPのために、LSRは、受信PHBの決意と差分-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個以下、のBAの同一の共通セットを輸送することができます。これらのE-LSPの各々は、実際のBAのこのフルセットまたはそれの任意のサブセットを輸送することができます。
For a given FEC, two given E-LSPs using a signaled `EXP<-->PHB mapping' can support the same or different sets of Ordered Aggregates.
順序付き集合体の同じ又は異なるセットをサポートすることができるPHBマッピング」 - <>与えられたFECのために、2シグナリング `EXPを使用してE-LSPを与えられました。
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.
このセクションでは、定義方法 `ENCAPS - >のDiff-ServのコンテキストのPHBマッピングが」着信PHBの決意を可能にするために、着信E-LSPのために取り込まれます。
The `Encaps-->PHB mapping' for an E-LSP is always of the form `EXP-->PHB mapping'.
`ENCAPS - > PHBのマッピング ' - > PHBのマッピングE-LSPのためには、常にフォーム` EXPのです'。
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.
< - > PHBマッピングラベルはないが `EXPはれるE-LSPに対応する場合「明示的にLSPセットアップで合図された、` EXP - > PHBマッピングが」事前設定 `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 `EXP-->PHB mapping' is populated as per the signaled `EXP<-->PHB mapping'.
ラベルは、E-LSPに対応する場合いる `EXP < - > PHBマッピングは「明示的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使用E-LSPをサポートするLSRのPHBのマッピングは、「< - > PHBのマッピングこの` EXPのローカル設定を可能にしなければなりません」。このマッピングは、明示的に、セットアップ時に合図をマッピングすることなく、この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またはEXPフィールドの適切な再マーキングによって張らMPLSのDiff-Servのドメイン全体のすべてのE-LSPのホップで一貫していなければならないのいずれかたびに異なる事前設定されたマッピングLSRによって実行されなければなりません入力および出力インターフェイス上で使用されています。
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のマッピング」デフォルトのPHBに、すべてのEXP値をマッピングします。
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決意定義します。セクション3.2で定義されるように> PHBマッピング」移入され - これは `ENCAPSのことを必要とします。
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.
- と考え、着信E-LSPラベルとILMに関連する差分-Servのコンテキストの - 「> PHBマッピング `ENCAPSを検索して、」> PHBのマッピング - ` EXPを決定します。
- determines the incoming PHB by looking up the EXP field of the considered label entry in the `EXP-->PHB mapping' table.
- > PHBマッピング」テーブル - `EXPで考慮ラベルエントリの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.
このセクションでは、 `PHBのセット方法を定義 - >は、差分-Servのコンテキストのマッピングはカプセル層内のDiff-Servの情報の符号化を可能にするために、発信E-LSPのためのラベルの設定に移入されENCAPS。
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.
その差分-Servのコンテキストの - 「> ENCAPSマッピング `PHBのセットの一部として> EXPマッピング - 発信E-LSPは常に` PHBを持っている必要があります。
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.
< - > PHBのマッピング「明示的にLSP設定で通知された、この `PHB - > EXPマッピング」ラベルはありませんが、` EXPがいるE-LSPに該当する場合は事前設定 `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'.
< - > PHBマッピング「明示的にLSPセットアップで合図された、 `PHB - > EXPマッピング」ラベルは` EXPはれるE-LSPに対応する場合ごとに移入されシグナリング `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インターフェイス上egressingされている場合は、1 `PHB - この送信LSPのために - > CLPマッピングは、」> ENCAPSマッピング` PHBのセットに追加されます。この `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の関数であり、デフォルトからこれらのPHBのための関連するマッピングエントリを使用することができる `PHB - >セクション3.4.2.1で定義されたCLPマッピング」。セクション3.4.2.1で定義されたもの以外のマッピングが使用されてもよいです。 CLPへのPHBからマッピングが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のセットいることに注意してください - > ENCAPSマッピング` 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ラベルがスイッチング制御されていないフレームリレーインターフェース上egressingされている場合、1 `PHB - > DEマッピングは` PHBのセットに追加される - > ENCAPSマッピングこの発信LSPのために、以下に取り込まれ仕方：
- 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の関数であり、デフォルトの `PHBからこれらのPHBに関連するマッピングエントリを使用することができる - > DEマッピング」セクション3.4.3.1で定義されています。セクション3.4.3.1で定義されたもの以外のマッピングが使用されてもよいです。 DEへのPHBからのマッピングは、フレームリレー上の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のセットいることに注意してください - > ENCAPSマッピング` PHBの両方含まれています - > EXPマッピング「と `PHB - > DEマッピング」を。
PHB DE Bit
PHB DEビット
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は、複数の802.1トラフィッククラスは、[IEEE_802.1]あたりとしてサポートされているLANインタフェースを介しegressingされている場合は、1 `PHB - について - > 802.1マッピングは」> ENCAPSマッピング` 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の関数であり、事前設定 `PHBからこれらのPHBに関連するマッピングエントリを使用する - セクション3.4.4.1で定義され> 802.1マッピング」。
Notice that the `Set of PHB-->Encaps mappings' then contains both a `PHB-->EXP mapping' and a `PHB-->802.1 mapping'.
>は、マッピングをENCAPS - `PHBのセットいることに注意してくださいを` 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.
この仕様を製造する時には、802.1トラフィッククラスにのPHBからの標準化されたマッピングはありません。 > 802.1マッピング」 - その結果、LANインタフェースを介して複数の802.1トラフィッククラスをサポートするLSRは `PHBのローカル設定を可能にしなければなりません。このマッピングは、LANインターフェイス上でLSRによって確立されたすべての発信のLSPに適用されます。
3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing E-LSP
3.5発信E-LSP上でカプセル化層へのDiff-Servの情報を符号化します
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で定義されている> ENCAPSマッピングが移入される - これは `PHBの設定する必要があります。
The LSR first determines the `Set of PHB-->Encaps mappings' of the Diff-Serv Context associated with the corresponding label in the NHLFE.
NHLFEで対応するラベルに関連付けられているのDiff-Servのコンテキストの> ENCAPSマッピング - LSRは最初 `PHBのセットを決定します。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->EXP mapping', then the LSR:
`PHBの設定されている場合 - > ENCAPSマッピングは形式のマッピングに` 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.
- > EXPマッピング」テーブル - この `PHBに「送信PHB」を検索して、対応するレベルのラベルエントリのEXPフィールドに書き込まれる値を決定します。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->CLP mapping', then the LSR:
`PHBの設定されている場合 - > ENCAPSマッピングは形式` 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.
- > CLPマッピング」テーブル - この `PHBの「発信PHB」を検索することにより、ATMカプセル化ヘッダのCLPフィールドに書き込まれる値を決定します。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->DE mapping', then the LSR:
`PHBの設定されている場合 - >は、マッピングをENCAPS形式のマッピングが含まれている` 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.
- > DEマッピング」テーブル - この `PHBの「発信PHB」を調べることによって、フレームリレーカプセル化ヘッダのDEフィールドに書き込まれる値を決定します。
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->802.1 mapping', then the LSR:
`PHBの設定されている場合 - > ENCAPSマッピングは形式` 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」を調べることによって、[IEEE_802.1] 802.1カプセル化ヘッダのタグ制御情報のUser_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は、一のLSRに一つのLSPにマージすることができます。 E-LSPはLSPは、以下の条件の下でのマージと互換性があります。
E-LSPs can only be merged into one LSP if they support the exact same set of BAs.
彼らはのBAの正確な同じセットをサポートしている場合E-LSPは、唯一の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使用してE-LSPのためにPHBのマッピング」を、上記マージ条件はのPHBの正確な同じセットがマージされたLSPでサポートされていることをラベル設定時に明示的なチェックを通しての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が事前設定された `EXP使用するためのPHBが確立時にシグナリングされないE-LSP上に支持されているので、PHBマッピング」、LSRは、上記のマージを適用するシグナリング情報に頼ることはできません。しかし、事前に設定 `EXP使用して、すべてのE-のLSP < - > PHBのマッピングは、」与えられたMPLSのDiff-Servのドメイン内の行動凝集体の同じセットをサポートする必要があります。このように、事前設定された `EXP使用E-LSPのマージ< - > PHBのマッピングを」所定の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.
差分-SERVコンテキストの> PHBマッピング」着信PHBの決意を可能にするために入ってくるL-LSPのラベル設定で移入さ - このセクションでは、 `ENCAPSの方法を定義します。
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が、その後 `ENCAPS、ATMでないもフレームリレーインターフェイス上で、この入ってくるL-LSPとL-LSPのingressesオーバーMPLSシムレイヤを終了した場合 - > PHBのマッピング」は、次のように読み込まれます。
- it is actually a `EXP-->PHB mapping'
- 「> PHBのマッピング - それは実際には `EXPです
- 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の関数であり、必須 `EXP / PSCからこの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:
着信ラベルL-LSP AF1 PSCをサポートに対応する場合、例えば、次に `ENCAPS - > 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.
LSRは、PPPインタフェースとLANインタフェース上にL-LSPを支持、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とATMやフレームリレーインターフェイス上のL-LSPのingresses、オーバーMPLSシムレイヤを終了した場合、 `ENCAPS - > 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.
- 「> PHBのマッピング - それは実際に `EXPする必要があります。 `ENCAPS移入の代替オプションの方法 - > PHBのマッピングは、」将来的に定義された（例えば、使用している場合があります『CLP / EXP - > PHBのマッピング』または『DE / EXP - > 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.
- 場合 `ENCAPS - > PHBマッピング「'EXPされる - > PHBマッピング」、この` EXP - > PHBマッピング」マッピングはL-LSP、上に担持されており、使用しなければならないPSCの関数です。セクション4.2.1.1で定義されている> PHBマッピング」 - 必須 `EXP / PSCから、この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ドメインのエッジLSRは入力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（すなわち、それはATM-LSRである）、この着信ラベルの上にMPLSシムレイヤを終端し、ATMカプセル化を使用しない場合は、 `ENCAPS - この入ってくるL-LSP用> PHBのマッピング」は、以下に移入されます仕方：
- it is actually a `CLP-->PHB mapping'
- 「> PHBのマッピング - それは実際には `CLPです
- 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の関数であり、デフォルトの `CLP / PSCからこのPSCは、関連するマッピングエントリを使用する必要が - > PHBのマッピング]セクション4.2.2.1で定義されています。
For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' should be populated with:
着信ラベルL-LSP AF1 PSCをサポートに対応する場合、例えば、次に `ENCAPS - > PHBマッピングは」移入されるべきです。
CLP Field PHB
CLPフィールドPHB
0 ----> AF11
1 ----> AF12
CLP Bit PSC PHB
CLPビット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（すなわち、それはFR-LSRである）、この着信ラベルの上にMPLSシムレイヤを終了し、フレームリレーカプセル化を使用しない場合は、 `ENCAPS - この入ってくるL-LSP用> PHBのマッピングは」に移入され次の方法：
- it is actually a `DE-->PHB mapping'
- 「> PHBのマッピング - それは実際には `DEです
- 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の関数であり、デフォルトの `DE / PSCからこのPSCは、関連するマッピングエントリを使用する必要が - > PHBのマッピング]セクション4.2.3.1で定義されています。
DE Bit PSC PHB
DEビット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.
このセクションでは、着信PHB判定を受信したラベルスタックにおいて考慮ラベルエントリはL-LSPに対応する場合に行われる方法を定義します。セクション4.2で定義されているよう> PHBマッピング」移入され - これは `ENCAPSのことを必要とします。
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マッピング」 - 着信PHBの決意の着信L-LSPに対応するラベルエントリを考慮した場合、LSRは最初 `ENCAPSを決定します。
If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping', then the LSR:
もし `ENCAPS - > 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'.
- > PHBのマッピング」 - と考えラベルエントリのEXPフィールドを見て、 `EXPを使用して、着信PHBを決定します。
If the `Encaps-->PHB mapping' is of the form `CLP-->PHB mapping', then the LSR:
> PHBのマッピング '形式 `CLPのである - - > PHBのマッピング'` ENCAPSがあれば、LSR：
- determines the incoming PHB by looking at the CLP field of the ATM Layer encapsulation and using the `CLP-->PHB mapping'.
- > PHBのマッピング」 - ATMレイヤのカプセル化のCLPフィールドを見て、 `CLPを使用して、着信PHBを決定します。
If the `Encaps-->PHB mapping' is of the form `DE-->PHB mapping', then the LSR:
> PHBのマッピング '形式 `DEである - - > PHBのマッピング'` ENCAPSがあれば、LSR：
- determines the incoming PHB by looking at the DE field of the Frame Relay encapsulation and by using the `DE-->PHB mapping'.
- > PHBのマッピング」 - フレームリレーカプセル化のDEフィールドを見て、と `DEを使用して、着信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.
デフ-Servのコンテキストの> ENCAPSマッピングのDiff-Servの情報の符号化を可能にするために、発信L-LSPのためのラベルの設定で読み込まれる - このセクションでは、 `PHBのセットが方法を定義します。
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シムレイヤを使用する場合、1 `PHB - この送信L-LSPのために - > EXPマッピングは、」> ENCAPSマッピング` PHBのセットに追加されます。この `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の関数であり、必須 `PHBからこのPSCに関連するマッピングエントリを使用しなければならない - > EXPマッピング」セクション4.4.1.1で定義されています。
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':
発信ラベルL-LSP AF1 PSCをサポートに対応する場合、例えば、次の `PHB - > EXPマッピングは` PHBのセットに追加される - > ENCAPSマッピング：
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-LSRであるか、またはそれはLC-ATMインターフェイスまたはラベルがスイッチング制御されていないATMインターフェイス上でパケットを送信フレームベースのLSRである）、次に、ATMインターフェイス上egressingされている場合1 `PHB - この送信L-LSPのために - > CLPマッピングは、」> ENCAPSマッピング` PHBのセットに追加されます。
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インタフェース上egressingされている場合、 `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インタフェース上egressingされている場合、 `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の関数であり、デフォルトの `PHBからこのPSCに関連するマッピングエントリを使用する必要が - セクション3.4.2.1で定義され> CLPマッピング」。
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のegressingを支持するフレームベースのLSR、 `PHBの集合である場合 - >マッピングをENCAPSを含む` PHBの両方 - > EXPマッピング」と `PHB- - > CLPマッピング」。 LSRは、L-LSPをサポートするATM-LSRであれば、 `PHBのセット - > ENCAPSマッピング - > CLPマッピングのみ` PHBが含まれています」。
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.
> DEマッピング」 - L-LSP（すなわち、それはLC-FRインターフェイスまたは制御ラベルスイッチングないフレームリレーインターフェース上でパケットを送信するLSRである）と、1つ `PHBフレームリレーインタフェース上egressingされている場合この送信L-LSP用> ENCAPSマッピング - `PHBのセットに追加されます。
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インタフェースを介しegressingされている場合、 `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インタフェース上egressingされている場合、 `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の関数であり、デフォルトの `PHBからこのPSCに関連するマッピングエントリを使用する必要が - セクション3.4.3.1で定義され> DEマッピング」。
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'.
>マッピングをENCAPS - LSRがある場合にエッジLSRは、LC-FRインタフェースを介して、次いで `PHBのセットL-LSPのegressingを支持することに注意してくださいを含む` PHBの両方を - > EXPマッピング」と `PHB - > DEマッピング」。 LSRは、FR-LSR L-LSPをサポートしている場合は、 `PHBのセット - > ENCAPSマッピングは - > DEマッピングのみ` PHBが含まれています」。
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.
LSPは、複数802.1トラフィッククラスがサポートされているLANインターフェースを介しegressingされている場合[IEEE_802.1]で定義されるように、そしてある `PHB - > 802.1マッピング」はセクション3.4.4に従って添加されます。
4.5 Encoding Diff-Serv Information into Encapsulation Layer on Outgoing L-LSP
4.5発信L-LSP上の封入層へのDiff-Servの情報を符号化します
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の情報を符号化する方法を定義します。セクション4.4で定義されている> ENCAPSマッピングが移入さ - これは `PHBの設定する必要があります。
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は、第 `PHBのセットを判定する - NHLFEに対応するラベルに関連付けられた差分-SERVコンテキストの> ENCAPSマッピングとその後のセクション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は、一のLSRに一つのLSPにマージすることができます。 L-LSPは、LSPは、以下の条件でマージと互換性があります。
L-LSPs can only be merged into one L-LSP if they support the same PSC.
彼らは同じPSCをサポートしている場合、L-LSPは、一つだけL-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.
DIFFSERVオブジェクト：一つの新しいRSVPオブジェクトは、このドキュメントで定義されています。このオブジェクトの詳細な説明は以下に提供されます。この新しいオブジェクトは、Pathメッセージに適用されます。この仕様は、[RSVP_MPLS_TE]に従って、従ってLSP_TUNNEL_IPv4に等しいC型とのセッションオブジェクトを含むとLABEL_REQUESTオブジェクトを含むでLSPトンネルを確立するために使用されるPathメッセージにDIFFSERVオブジェクトの使用を規定します。
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]で定義された制約も相違-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オブジェクトは、MPLS LSPに関係しない一般的なRSVPの実装はこのオブジェクトをサポートする必要はありません設定されるように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]で定義されたDiffServオブジェクトは、LSPトンネルをサポートするためのオプションです。 < - >事前構成済み `EXP使用してE-LSPをサポートするのDiff-Servの可能LSRこの仕様に準拠したPHBのマッピングは、」DIFFSERVオブジェクトをサポートするかもしれません。 < - >シグナリング `EXP使用E-LSPを支持差分-SERV可能なLSRこの仕様に準拠したPHBのマッピングは、」のDiffServオブジェクトをサポートしなければなりません。この仕様に準拠してL-LSPを支持差分-SERV可能なLSRはDIFFSERVオブジェクトをサポートしなければなりません。
The format of the Path message is as follows:
次のようにPathメッセージの形式は次のとおりです。
<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オブジェクトです。
class = 65, C_Type = 1
クラス= 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:
MAP：32ビット各マップエントリは、1つのEXPフィールド値と1つのPHBの間のマッピングを定義します。 MAPエントリの形式は次のとおりです。
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：このフィールドは 'EXPためのEXPフィールドの値が含まれて3ビット< - >このマップエントリで定義されたPHBのマッピングを」。
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： - このマップエントリで定義されたPHBのマッピング」<> 16ビットこのフィールドは `EXPのためのPHBのPHBIDが含まれています。 PHBIDは[PHBID]で指定されるように符号化されます。
class = 65, C_Type = 2
クラス= 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：PSCは、LSPによってサポートされるPHBスケジューリングクラスを示す16ビット。 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トンネルを確立するために、送信者はLSP_Tunnel_IPv4のセッション・タイプと[RSVP_MPLS_TE]の通りLABEL_REQUESTオブジェクトとPathメッセージを作成します。
To establish an E-LSP tunnel with RSVP, which uses the Preconfigured `EXP<-->PHB mapping', the sender creates a Path message:
< - >事前設定 `EXP使用RSVPとE-LSPトンネルを確立するためにPHBのマッピングを」、送信者は、Pathメッセージを作成します。
- 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使用RSVPとE-LSPトンネルを確立するためにPHBのマッピングを」、送信者は、代わりに、Pathメッセージを作成してもよいです。
- 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:
< - >シグナリング `EXP使用RSVPとE-LSPトンネルを確立するためにPHBのマッピングを」、送信者は、Pathメッセージを作成します。
- 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トンネルを確立するために、送信者は、Pathメッセージを作成します。
- 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）を収容するためのDiffServオブジェクトと、このL-LSP上に支持されています。
If a path message contains multiple DIFFSERV objects, only the first one is meaningful; subsequent DIFFSERV object(s) must be ignored and not forwarded.
Pathメッセージは、複数のDiffServオブジェクトが含まれている場合は、最初のものだけで意味があります。その後のDIFFSERVオブジェクト（s）は無視され、転送されませんする必要があります。
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.
< - > PHBマッピング」のDiffServオブジェクトはPathメッセージに存在しない場合、LSRは、事前設定 `EXPを使用してE-LSPのための要求として解釈すべきです。ただし、下位互換性のために、制御された負荷や保証サービスなど統合サービスなど[RSVP_MPLS_TE]で許可されたサービスオプションの他の非のDiff-Servの品質で、LSRは、構成「上書きオプション」をサポートするかもしれません。この「オーバーライドオプションが」構成されている場合、LSRはサービスのような非差分-SERV品質のLSPのための要求としてのDiff-ServのオブジェクトなしにPathメッセージを解釈します。
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.
< - > PHBマッピング」をマップエントリを含まないE-LSPのためのDiffServオブジェクトはPathメッセージに存在する場合、LSRは、事前設定 `EXPを使用してE-LSPのための要求としてこれを解釈しなければなりません。サービスの非差分-Servの品質とのLSPと同時に、PHBのマッピング」 - <>具体的には、これは「上書きオプション」とLSRを可能にする事前設定された `EXPと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'.
< - > PHBマッピング」E-LSP少なくとも1つのマップエントリを収容するためのDiffServオブジェクトはPathメッセージに存在する場合、LSRは、シグナリング `EXPと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オブジェクトはPathメッセージに存在する場合、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オブジェクトを含むPathメッセージに応答します。
- with the LABEL object
- LABELオブジェクトと
- 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:
差分-SERV用の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に関連付けられた差分-SERVコンテキストを更新し、
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
- このNHLFE（出力ラベル）のために必要なのDiff-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オブジェクトを認識し、それがLSP_Tunnel_IPv4のセッションタイプを持っていないのDiffServオブジェクトを含むがLABEL_REQUESTオブジェクトが含まれていないまたはパスメッセージを受信したLSRは、エラーコード 'と送信側に向けたPathErrを送信しますDiff- Servのエラー 'と `予期しない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.
LSRはDIFFSERVオブジェクトを認識するがマップエントリの特定の一つに符号化PHB、またはそれ以上をサポートしていないE-LSPのためのDiffServオブジェクトとPathメッセージを受信し、 `エラーコードを送信側に向かっのPathErrを送信しますデフ-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:
LSRはDIFFSERVオブジェクトを認識するが合図 `EXPと判断E-LSPのためのDiffServオブジェクトとPathメッセージを受信する< - > PHBマッピングが」無効である、`エラーコードを送信側に向かっのPathErrを送信Diff- Servのエラー「と無効 `EXPのエラー値< - > PHBのマッピング」。これらは、5.5節で以下に定義されています。 `EXP < - > PHBマッピングが」E-LSPのためのDiffServオブジェクト内シグナリングは場合無効です。
- the MAPnb field is not within the range 0 to 8 or
- MAPnbフィールドは0〜8、または範囲内にありません
- a given EXP value appears in more than one MAP entry, or
- 指定したEXP値は、複数のMAPエントリに表示され、または
- 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.
DIFFSERVオブジェクトを認識するが、PSCフィールドに符号化された特定のPSCをサポートしていないL-LSPのためのDiffServオブジェクトとPathメッセージを受信したLSRは、エラーコード `の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.
LSRはDIFFSERVオブジェクトを認識するが、それが必要あたり-LSPのDiff-Servのコンテキストがエラーコード「差分-SERVエラー」とエラー値「ごとでのPathErrを送信割り当てることができないのDiffServオブジェクトとPathメッセージを受信します-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は、そのフォーマットである0bbbbbbbはすなわち、未知のClass-numの[RSVP]で指定された手順に従って振る舞うしなければならない、それはエラーコード `不明なオブジェクトクラスでのPathErrを送信する必要があります送信者に向けました。
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を認識するが、未知のC型IE用[RSVP]で指定された手順に従って動作する必要があり、それはエラーコードでのPathErrを送信する必要があり、DIFFSERVオブジェクトC-タイプを認識しないLSR送信者に向けて `未知の物体のC-Type」と。
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).
両方の状況では、これは失敗するパスセットアップの原因となります。 fall-としてPHBのマッピング」 - <>送信者は、L-LSPを確立することができないと、おそらくDIFFSERVオブジェクト（例えば、事前設定された `EXPとE-LSPを使用しようとせずに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:
以下は、デフ-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.
帯域幅予約なしE-LSPまたはL-LSPを確立するために、[RSVP_MPLS_TE]で指定されるように、[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.
この仕様は唯一のDiff-ServのサービスのサポートのためにE-のLSPとL-LSPの使用を規定することに留意されたいです。かかわらずイントサーブサービス（負荷制御、ヌルサービス、保証サービス、...）のにかかわらず、予約が帯域予約の有無にかかわらずであるかどうかの、E-のLSPとL-LSPはデフ-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.
この目的は、MPLSネットワーク内の関連しないDSCP値、に関する情報を伝達するため、この明細書は、[DCLASS]で定義DCLASSオブジェクトとそれ自体に関係しないことにも留意されたいです。
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を）切り替えます。このセクションでは、MPLSネットワークで差別化サービスをサポートするLSPを確立するために、LDPに拡張子を指定します。
One new LDP TLV is defined in this document:
一つの新しいLDP TLVは、この文書で定義されています。
- the Diff-Serv TLV
- デフ-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使用E-LSPを支持差分-SERV可能なLSRこの仕様に準拠したPHBのマッピングは、」差分-SERV TLVをサポートするかもしれません。 < - >シグナリング `EXP使用E-LSPを支持差分-SERV可能なLSRこの仕様に準拠したPHBのマッピングは、」差分-SERV TLVをサポートしなければなりません。この仕様に準拠してL-LSPを支持差分-SERV可能なLSRは差分-SERV TLVをサポートしなければなりません。
The Diff-Serv TLV has the following formats:
デフ-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:
MAP：32ビット各マップエントリは、1つのEXPフィールド値と1つのPHBの間のマッピングを定義します。 MAPエントリの形式は次のとおりです。
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：このフィールドは 'EXPためのEXPフィールドの値が含まれて3ビット< - >このマップエントリで定義されたPHBのマッピングを」。
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： - このマップエントリで定義されたPHBのマッピング」<> 16ビットこのフィールドは `EXPのための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：PSCは、LSPによってサポートされるPHBスケジューリングクラスを示す16ビット。 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
予想外のDiff-ServのTLV 0 0x01000001サポートされていないPHB 0 0x01000002無効 `EXP < - > PHBマッピング」0 0x01000003サポートされていないPSC 0 0x01000004当たり-LSPコンテキストの割り当てに失敗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:
Label Mappingメッセージのフォーマットは、次のように任意に、拡張の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.
< - > PHBマッピング」、下流のDiff-ServのLSRは、差分-SERV TLV無しLabel Mappingメッセージを発行する事前設定された `EXPを使用することであるE-LSPのラベルを割り当てるとき。
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.
< - > PHBマッピング」、下流のDiff-ServのLSRが1つを含有するE-LSPのためのDiff-ServのTLVとLabel Mappingメッセージを発行合図 `EXPを使用することであるE-LSPのラベルを割り当てるときこのE-LSP上でサポートされる各EXP値のためのMAPエントリ。
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このL-LSP上に支持されるPHBスケジューリングクラス（PSC）を含有するためのDiff-ServのTLVとLabel Mappingメッセージを発行します。
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に関連付けられた差分-SERVコンテキストを更新し、
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
- このNHLFE（出力ラベル）のために必要なのDiff-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のLSR複数のDiff-ServのTLVを持つLabel Mappingメッセージを受信するには、最初一つとして意味考えます。 LSRは無視して、後続のDiff-ServのTLV（単数または複数）を転送してはなりません。
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'.
上流のDiff-ServのE-LSPのためのDiff-ServのTLVと、Label Mappingメッセージを受信し、MAPエントリの1つ以上にコードされる特定のPHBをサポートしていない、ラベル解放を送信することにより、マッピングを拒絶しなければならないLSRラベルTLVと `サポートされていないPHB」のステータスコードとステータス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:
上流のDiff-ServのLSR E-LSPのためのDiff-ServのTLVとLabel Mappingメッセージを受信し、シグナリング `EXPと判断< - > PHBマッピングが」無効であるが、ラベル解放メッセージを送信することにより、マッピングを拒絶しなければなりません< - > PHBのマッピング」無効な `EXPのステータスコードでラベルTLVとステータスTLVが含まれています。 `EXP < - > PHBのマッピングは、」E-LSPのためのDiffServオブジェクトに合図無効な場合：
- 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値は、複数のMAPエントリに表示され、または
- 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'.
上流のDiff-ServのLSRサポートされていないPSC値を含むL-LSPのためのDiff-ServのTLVとLabel Mappingメッセージを受信するには、ラベル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.
< - > PHBのマッピング」、上流のDiff-ServのLSRは、差分-SERV TLVなしラベル要求メッセージを送信する事前設定された `EXPを使用することであるE-LSPのラベルを要求するとき。
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.
< - > PHBのマッピング」、上流のDiff-ServのLSRが1つを含有するE-LSPのためのDiff-ServのTLVとラベル要求メッセージを送信するシグナリング `EXPを使用することであるE-LSPのラベルを要求する場合このE-LSP上でサポートされる各EXP値のためのMAPエントリ。
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このL-LSP上に支持されるPSCを含有するための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:
下流のDiff-ServのLSR E-LSPまたはL-LSPのためのラベル要求メッセージに応答して、Label Mappingメッセージを送信し、このLabel Mappingメッセージに差分-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に関連付けられた差分-SERVコンテキストを更新し、
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
- このNHLFE（出力ラベル）のために必要なのDiff-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のLSRのラベル要求メッセージに応答してのDiff-ServのTLVを含むラベルマッピングメッセージを受信するには、ラベルTLVとのステータスコードとステータスTLVを含んラベル解放メッセージを送信することにより、ラベルマッピングを拒否しなければなりません`予期しないのDiff-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のLSR複数のDiff-ServのTLVを用いてラベル要求メッセージを受信するには、最初一つとして意味考えます。 LSRは無視して、後続のDiff-ServのTLV（単数または複数）を転送してはなりません。
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'.
下流のDiff-ServのE-LSPのためのDiff-ServのTLVとラベル要求メッセージを受信し、1つ（または複数）にコードされる特定のPHBをサポートしていないLSR MAPエントリは、通知を送信することによって要求を拒否しなければなりません`サポートされていない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:
下流のDiff-ServのLSR E-LSPのためのDiff-ServのTLVとラベル要求メッセージを受信し、シグナリング `EXPと判断< - > PHBマッピングが」無効であるとしては、通知メッセージを送信することによって、要求を拒否しなければなりません< - > PHBのマッピング」無効な `EXPのステータスコードとステータスTLV。 `EXP < - > PHBのマッピングは、」E-LSPのためにDIFFSERV TLVで合図無効な場合：
- 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値は、複数のMAPエントリに表示され、または
- the PHBID encoding is invalid
- PHBIDエンコーディングが無効です
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'.
下流のDiff-ServのLSR L-LSPサポートされていないPSC値を収容するためのDiff-ServのTLVとラベル要求メッセージを受信するには、ステータスコードとステータス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のLSRラベル要求メッセージに差分-SERV TLVタイプを認識するが必要あたり-LSPコンテキスト情報を割り当てることができない、のステータスコードステータス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のLSRラベル要求メッセージでのDiff-ServのTLVタイプを認識し、要求されたPSCをサポートしていますが、他の理由（例えば、可能なラベルなし）のラベル要求を満たすことができないが、中に通知メッセージを送信する必要があります（ `ラベルなしリソース」ステータスコード付きなど、）既存の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.
ラベル要求メッセージやdiff-SERV TLVを含むラベルマッピングメッセージの受信時に、差分-SERV TLVタイプを認識しないLSRは、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の確立時にシグナリングすることができます。
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and Non-LC-FR Interfaces
PPP、LAN、非LC-ATMおよび非LC-FRインタフェースオーバーのDiff-Servのの7 MPLSサポート
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インターフェイス上のDiff-Servのの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.
これらのインターフェース上PHBマッピング」 - <>のDiff-Servの可能なLSRは、事前設定された `EXPを使用するE-LSPをサポートしなければなりません。
A Diff-Serv capable LSR MAY support E-LSPs which use signaled `EXP<-->PHB mapping' and L-LSPs over these interfaces.
これらのインターフェース上PHBマッピング」とL-LSPの< - >のDiff-Servの可能なLSRは `EXPを合図使用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）インターフェイスラベルスイッチング上のDiff-Servのの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.
ITU-Tで指定された「ATM転送機能」のか、ベンダー固有のATMトラフィッククラスの、ATMフォーラムで指定された「ATMサービスカテゴリ」の使用は、この仕様書の範囲外です。準拠した実装のための唯一の要件は、ATM LSRによってL-LSPを介して転送動作の集合によって経験される転送動作は、対応のDiff-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の廃棄優先順位値を符号化するための1ビットのみ（CLP）があるので、2つだけ異なるドロップ優先レベルは、ATMのLSRに支持されています。セクション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.
パケットの一部を廃棄避けるために、このような早期パケット廃棄（EPD）などのフレーム廃棄メカニズムは、（[ATMF_TM]参照）は、この文書に記載されているすべてのPHBのためにATM-LSRの中で有効にする必要があります。
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ドメインのエッジのLSRが[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）インターフェースラベルスイッチング上のDiff-Servのの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あたりのL-LSPの任意の数のことができます。 E-LSPは、LC-FRインターフェイス上でサポートされていません。
9.1 Use of Frame Relay Traffic parameters and Traffic Management mechanisms
9.1を使用するフレームリレートラフィックのパラメータおよびトラフィック管理メカニズム
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によって指定され、リレーフォーラムまたはベンダーの特定のフレームリレートラフィック管理メカニズムをフレームとして、フレームリレートラフィックパラメータの使用は、本明細書の範囲外です。準拠した実装のための唯一の要件は、フレームリレーLSRによってL-LSPを介して転送動作の集合によって経験される転送動作は、対応のDiff-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は、フレームリレーリンクに優先値をドロップ符号化するための1ビットのみ（DE）があるので、2つだけ異なるドロップ優先レベルは、フレームリレーのLSRに支持されています。セクション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.
この仕様は[MPLS_FR]の推奨FR-LSRドメインのエッジLSRには、「一般的なカプセル化」の方法を使用することを前提としています。 「一般的なカプセル化」なしの操作は、この仕様書の範囲外です。
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」は、「Diffservのエラー」にIANAによって割り当てられています。この文書では、このエラーコードに対してERROR_SPECオブジェクト内で使用される値フィールドの5を介して値1を定義します。このスペースの値の今後の配分は、まずを使用して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].
この文書では、セクションでのDiffserv関連のエラー条件のための6.2 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.
この文書では、差分-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.
この文書では、エリック・ローゼン、アンジェラ・チウとキャロルIturraldeとの議論の恩恵を受けています。それはまたのDiff-ServのとIPトンネルの相互作用に関するD.ブラックで行われた仕事から借りました。
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.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no MPLS Protection
A.1シナリオ1：8（またはそれ以下）のBA、トラフィックエンジニアリング、無MPLS保護
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の保護を使用して、彼/彼女のネットワークにMPLSシムヘッダーカプセル化を使用していない、単一E-LSPあたりを使用してMPLS上のDiff-Servのを実行するために選択することができ、トラフィックエンジニアリングを行っていない、MPLS上で8（または少ない）のBAを実行しているサービスプロバイダFECは、LDPを介して確立します。 < - > PHBのマッピング」さらに、サービスプロバイダは、事前に設定 `EXPを使用することを選んでもよいです。
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)
- 暗黙LSPがE-LSPであり、それことをことを示すLDPラベルリクエスト/ラベルマッピングメッセージ（すなわち、無差分-SERV TLV上記の仕様に応じてLDPを使用して、FECごとに単一のE-LSPのLSRの信号確立事前設定されたマッピングを使用しています）
A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no MPLS Protection
A.2シナリオ2：8つのBA、トラフィックエンジニアリングよりも、無MPLS保護
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つの以上のBAを実行しているサービスプロバイダは、MPLSの保護を使用して、彼/彼女のネットワークにMPLSシムカプセル化を使用していないトラフィックエンジニアリングを行っていないことは、各FECのために使用してMPLS上のDiff-Servのを実行することを選択することがあります。
- one E-LSP established via LDP and using the preconfigured mapping to support a set of 8 (or less) BAs, AND
- 1つのE-LSPは、LDPを介して確立され、8（またはそれ以下）のBAのセットをサポートするように事前設定されたマッピングを使用して、AND
- one L-LSP per <FEC,OA> established via LDP for support of the other BAs.
- 他のBAのサポートのためにLDPを介して確立<FEC、OA>ごとにL-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 for the BAs transported over the E-LSP
- サービスプロバイダは、各LSRで各PHBとE-LSPを介して転送するためのBA 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で構成し、各インターフェイスのために、各PSCのためのスケジューリング挙動はE-LSPとそれぞれ対応する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で構成し、すべてのインタフェースのために、各PSCのスケジューリング動作は、L-LSPを、それぞれ対応する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)
- 暗黙LSPであることを示すためにLDPラベルリクエスト/ラベルマッピングメッセージ（すなわち、無差分-SERV TLV上に指定されているE-LSPのセットのためのLSR FECごとに単一のE-LSPの信号確立はLDPを使用してのBAを搬送しましたE-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).
- LDPを使用して他のBAのためのLSR <FEC、OA>ごとにL-LSPの信号確立（L-LSPのPSCを示すために、LDPラベルリクエスト/ラベルマッピングメッセージに、すなわち、差分-SERV TLV）上に指定されるように。
A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering, Aggregate MPLS Protection
A.3シナリオ3：8（またはそれ以下）のBA、集約トラフィックエンジニアリング、集計MPLS保護
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.
（すなわち、共同ですべてのPSCにサービスを復元）集約MPLS保護を使用してMPLSシムヘッダーを使用して、MPLS上で8（または少ない）のBAを実行し、集約トラフィックエンジニアリング（すなわち、すべてのBAのための単一の共通の経路選択を行う）を実行するサービスプロバイダ彼/彼女のネットワーク内のカプセル化は、RSVP [RSVP_MPLS_TE]またはCR-LDP [CR-LDP_MPLS_TE]を介して確立され、事前設定されたマッピングを使用してFECあたり単一E-LSPを使用して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:
- 事前設定されたマッピングを使用するFECごとに単一のE-LSPのLSRの信号の確立：
* using the RSVP protocol as specified above (i.e., no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR
（すなわち、LABEL_REQUESTオブジェクトを含んだPATHメッセージでないのDiffServ RSVPオブジェクト）、または上指定されるよう* RSVPプロトコルを使用して
* using the CR-LDP protocol as specified above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages).
*（即ち、無差分-SERV TLV LDPラベルリクエスト/ラベルマッピングメッセージで）上に指定されているCR-LDPプロトコルを使用。
- 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.4 Scenario 4: per-OA Traffic Engineering/MPLS Protection
A.4シナリオ4：あたり-OAトラフィックエンジニアリング/ MPLS保護
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上のBAの任意の数を実行するごとOAトラヒックエンジニアリングを行う（すなわち、各OAに対して別々の経路選択を行う）と異なるの保護の潜在的に異なるレベルの保護を行うごとOA MPLS保護（すなわち、実行OAは）彼/彼女のネットワークに、RSVPまたはCR-LDPを介して確立<FEC、OA>ペアごとに1つのL-LSPを使用して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>:
- <FEC、OA>ごとにL-LSPのLSRの信号の確立：
* 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
L-LSPのPSCを知らせるために、上記指定された（すなわち、LABEL_REQUESTを含むPATHメッセージ内のDiffServ RSVPオブジェクト）、またはAS * 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).
L-LSPのPSCを通知するために、上記指定されたよう* CR-LDPプロトコルを使用して（即ち、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.5 Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/MPLS Protection
A.5シナリオ5：8（またはそれ以下）のBA、あたり-OAトラフィックエンジニアリング/ MPLS保護
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.
毎OAトラヒックエンジニアリングを行う（すなわち、各OAに対して別々の経路選択を行う）との保護の潜在的に異なるレベルの保護を行うごとOA MPLS保護（すなわち、実行、MPLS上8（またはより少ない）のBAを実行しているサービス・プロバイダ別のOA）は、彼/彼女のネットワークに、RSVPまたはCR-LDPを介して確立<FEC、OA>ペアごとに1つのE-LSPを使用してMPLS上のDiff-Servのを実行することを選択することができます。さらに、サービスプロバイダは、すべての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>:
- ごとに1つのE-LSPのLSRの信号の確立<FEC、OA>
* 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
上記指定されたとおり* LSPが事前設定されたマッピングを使用してE-LSPであることを知らせるためにRSVPプロトコルを使用して（すなわち、LABEL_REQUESTを含むPATHメッセージでないのDiffServ RSVPオブジェクト）、OR
* 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)
上記指定されたとおり* LSPが事前設定されたマッピングを使用してE-LSPであることを知らせるためにCR-LDPプロトコルを使用して（即ち、何らのDiff-ServのTLV LDPラベルリクエスト/ラベルマッピングメッセージ）ありません
- 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.
- 指定されたOAに属するパケットのみが、対応するFECのために確立されたE-LSPに転送されるように、サービスプロバイダは、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上搬送PSCに応じ保護の異なるレベルで）異なるE-LSPの上に活性化されます。
A.6 Scenario 6: no Traffic Engineering/MPLS Protection on 8 BAs, per-OA Traffic Engineering/MPLS Protection on other BAs.
A.6シナリオ6：他のBAにあたり、OAトラフィックエンジニアリング/ MPLS保護8つのBAにトラフィックエンジニアリング/ 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:
各OAは、他のBAに対応するMPLSを実行するための別の経路選択を行う他のBA（すなわち、上ごとOAトラヒックエンジニアリング/ MPLS保護を実行8（またはそれ以下）のBA上のトラフィックエンジニアリング/ MPLS保護を行わないサービスプロバイダー、これらの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
- 1つのE-LSP 8（またはそれ以下）のセットをサポートするために、LDPを介して確立された事前設定済みのマッピングの非トラヒックエンジニアリング/非保護のBAを使用して、AND
- one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP for support of the other BAs.
- 他のBAのサポートのためのRSVPまたはCR-LDPを介して確立<FEC、OA>ペアごとにL-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 for the BAs supported over the E-LSP
- サービスプロバイダーは、のBAは、E-LSPを介してサポートするために、すべてのLSRでそれぞれPHBと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で構成し、各インターフェイスのために、各PSCのためのスケジューリング挙動はE-LSPとそれぞれ対応する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で構成し、すべてのインタフェースのために、各PSCのスケジューリング動作は、L-LSPを、それぞれ対応する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)
- LDPを用いた非トラヒックエンジニアリングのBAのためのFECごとに単一のE-LSPのLSRの信号確立（LDPラベルリクエスト/ラベルマッピングメッセージに、すなわち、ノーのDiff-ServのTLV）上に指定され
- LSRs signal establishment of one L-LSP per <FEC,OA> for the other BAs:
- 他のBAのための<FEC、OA>ごとにL-LSPのLSRの信号の確立：
* 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
L-LSPのPSCを通知するために、上記指定された（すなわち、PATHメッセージ内のDiffServ RSVPオブジェクトLABEL_REQUESTオブジェクトを含む）、またはAS * 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).
L-LSPのPSCを通知するために、上記指定されたよう* CR-LDPプロトコルを使用して（即ち、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のPSCに応じ保護の異なるレベルで）異なるL-のLSPに活性化されます。
A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no MPLS Protection
A.7シナリオ7：8つのBA、トラフィックエンジニアリングよりも、無MPLS保護
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の保護を行って、彼/彼女のネットワークにMPLSシムヘッダーカプセル化を使用していない、トラフィックエンジニアリングを行っていない、MPLSの上に8つの以上のBAを実行しているサービスプロバイダは、を介して確立FECごとに2つのE-LSPを使用してMPLS上のDiff-Servのを実行するために選ぶことができます< - > PHBのマッピング」LDPおよび使用は、 `EXPを合図しました。
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.
- 上記の仕様に応じて、LDPを使用して、FECごとに2つのE-LSPのLSRの信号の確立（すなわち、差分-SERV TLVは、LDPラベルリクエスト/ラベルマッピングメッセージに明示的にLSPは、E-LSPとその `EXP <であることを示します - > PHBのマッピング '）。シグナリングマッピングは、各E-LSP上に搬送される8（以下）のBAのサブセットが表示され、どのようなEXPの値は、各E-LSP上の各BAにマッピングされます。
APPENDIX B. Example Bandwidth Reservation Scenarios
付録B.例帯域予約のシナリオ
B.1 Scenario 1: No Bandwidth Reservation
B.1シナリオ1：いいえ帯域予約
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を経由して、COPSを経由して、...）完全にオフラインプロビジョニングのDiff-Servのリソースを持っています
- have Shortest Path Routing used for all the Diff-Serv traffic.
- ルーティングは、すべてのDiff-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は、シグナリング帯域幅なしで確立されるであろう。
B.2 Scenario 2: Bandwidth Reservation for per-PSC Admission Control
B.2シナリオ2：あたり-PSCアドミッション制御のための帯域幅予約
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を経由して、COPSを経由して、...）完全にオフラインプロビジョニングのDiff-Servのリソースを持っています
- 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.
- 制約ベースのルーティングは、制約の1つは、関連するPSCに割り当てられた帯域幅の帯域幅の可用性、各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は、シグナリング帯域幅との間で確立されるであろう。帯域幅は、関連するPSCのための帯域幅の可用性の制約が満たされることを保証するためにすべてのホップでアドミッション制御を実行するためのLSRによって使用されるL-LSPの確立に合図しました。
B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and per-PSC Resource Adjustment
B.3シナリオ3：あたり-PSCアドミッション制御のための帯域予約・パー・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.
- 制約ベースのルーティングは、制約の1つは、関連するPSCに割り当てられた帯域幅の帯域幅の可用性、各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は、シグナリング帯域幅との間で確立されるであろう。帯域幅は、関連するPSCのための帯域幅の可用性の制約が満たされることを保証するために、関連するPSCに割り当てられたリソースを調整しようとするのLSRによって使用される（例えば、スケジューリング重量）、次いで、アドミッション制御を実行することになるL-LSPの確立時にシグナリング調整後。
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規格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.、エディタ、アンダーソン、L.、Callon、R.及び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.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ"、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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、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】デイビー、B.、Charny、A.、ベイカー、F.、ベネット、J.、ベンソン、K.、Boudec、J.、チウ、A.、コートニー、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]ブラック、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]ラマクリシュナン、K.、フロイド、S.及びD.ブラック、 "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規格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]アンデション、L.、Doolan、D.、フェルドマン、N.、Fredette、A.およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[MPLS_ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS_ARCH]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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】デイビー、B.、ローレンス、J.、McCloghrie、K.、ローゼン、E.、ツバメ、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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、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]コンタ、A.、Doolan、P.およびA. Malis、RFC 3034、2001年1月 "フレームリレーネットワークの仕様上のラベルスイッチングの使用"。
[MPLS_VPN] Rosen, E., "BGP/MPLS VPNs", Work in Progress.
【MPLS_VPN]ローゼン、E.、 "BGP / MPLS VPN" を、進行中で働いています。
[NULL] Bernet, Y., Smith, A. and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
[NULL] Bernet、Y.、スミス、A.およびB.デイビー、 "ヌルサービスタイプの仕様"、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]ブラック、D.、つば、S.、大工、B.およびF.ルFaucheur、 "パーホップ行動識別コード" 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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル（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.、バーガー、L.、ガン、D.、李、T.、スリニバサン、V.およびG.ツバメ、 "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
フランソワ・リーパーシスコシステムズコーポレート・ヴィレッジグリーンサイド - T3ビル400、アベニューRoumanille 06410ビオ・ソフィアアンティポリス、フランス
Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com
電話：+33 4 97 23 26 19 Eメール：flefauch@cisco.com
Liwen Wu Cisco Systems 3550 Cisco Way San Jose, CA 95134 USA
Liwen呉シスコシステムズ3550のCiscoウェイサンノゼ、CA 95134 USA
Phone: +1 (408) 853-4065 EMail: liwwu@cisco.com
電話：+1（408）853-4065 Eメール：liwwu@cisco.com
Bruce Davie Cisco Systems 250 Apollo Drive, Chelmsford, MA 01824 USA
ブルース・デイビーシスコシステムズ250アポロドライブ、チェルムスフォード、MA 01824 USA
Phone: +1 (978) 244-8000 EMail: bsd@cisco.com
電話：+1（978）244-8000 Eメール：bsd@cisco.com
Shahram Davari PMC-Sierra Inc. 411 Legget Drive Kanata, Ontario K2K 3C9 Canada
Shahram Davari PMC-Sierraの株式会社411 Leggetドライブカナタ、オンタリオK2K 3C9カナダ
Phone: +1 (613) 271-4018 EMail: davari@ieee.org
電話：+1（613）271-4018 Eメール：davari@ieee.org
Pasi Vaananen Nokia 3 Burlington Woods Drive, Suit 250 Burlington, MA 01803 USA
パシVaananenノキア3バーリントンウッズドライブ、スーツ250バーリントン、MA 01803 USA
Phone +1 (781) 993-4900 EMail: pasi.vaananen@nokia.com
電話+1（781）993-4900 Eメール：pasi.vaananen@nokia.com
Ram Krishnan Axiowave Networks 200 Nickerson Road Marlboro, MA 01752
ラムクリシュナンAxiowaveネットワーク200ニッカーソン道路マールボロ、MA 01752
EMail: ram@axiowave.com
メールアドレス：ram@axiowave.com
Pierrick Cheval Alcatel 5 rue Noel-Pons 92737 Nanterre Cedex France EMail: pierrick.cheval@space.alcatel.fr
Pierrick馬アルカテル5ノエル・ポンス・ストリート92737ナンテールCedexのフランス電子メール：pierrick.cheval@space.alcatel.fr
Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland
ユハわらソングネットワークス株式会社Hallituskatu 16 33200タンペレ、フィンランド
EMail: jh@song.fi
メールアドレス：jh@song.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。