RFC3270 日本語訳
3270 Multi-Protocol Label Switching (MPLS) Support of DifferentiatedServices. F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R.Krishnan, P. Cheval, J. Heinanen. May 2002. (Format: TXT=137960 bytes) (Updates RFC3032) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループF.Le Faucheur、コメントを求めるエディタ要求をネットワークでつないでください: 3270年のL.ウーカテゴリ: 標準化過程B.デイビーシスコシステムズS.Davari PMC-連峰株式会社P.バーナネンノキアR.クリシュナンAxiowaveは2002年5月にP.シェヴァルアルカテルJ.Heinanen歌のネットワークをネットワークでつなぎます。
Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services
微分されたサービスのマルチプロトコルラベルスイッチング(MPLS)サポート
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks.
このドキュメントはMulti-プロトコルの上のDifferentiated Services(デフ-Serv)Label Switching(MPLS)ネットワークのサポートのフレキシブルな解決策を定義します。
This solution allows the MPLS network administrator to select how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic Engineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs.
この解決策で、MPLSネットワーク管理者は、その人がその人の特定のネットワークの中でDiff-Serv、Traffic Engineering、および保護目的に最もよく合うことができるようにDiff-Serv Behavior Aggregates(BAs)がどのようにLabel Switched Paths(LSPs)に写像されるかを選択できます。 例えば、この解決策で、ネットワーク管理者は、BAsの異なったセットが同じLSPに写像されることになっているか、または別々のLSPsに写像されることになっているかを決めることができます。
Le Faucheur, et. al. Standards Track [Page 1] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1用語。 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 EXPがPSC LSPsを推論している(電子LSP).61.3推論されたPSC LSPsだけをラベルしている(L-LSP。) . . . . . . . . . . . . . 7 1.4 総合的な操作。 . . . . . . . . . . . . . . . . . . . . . . 7 1.5 ラベルとFECとの関係。 . . . . . . . . . . . . . . 8 電子LSPsとL-LSPs. . . . . . . . . . 8 2のための1.6帯域幅予約。 デフ-Serv LSRsのラベル推進モデルとトンネリングはデフ-Serv LSRsの.92.2の入って来るPHB決断のために.92.1ラベル推進モデルをモデル化します。 . . . . . . . . . . . . . . . . . .10 2.3 2.4が推進とラベルする任意の交通調節.11との外向的なPHB決断。 . . . . . . . . . . . . . . . . . . . . . . .11 2.5 カプセル化層. . . .13 2.6のデフ-Servトンネリングにデフ-Serv情報をコード化するのはMPLSの上でモデル化されます。 . . . . . . . . . . . . .13 3. 電子LSPsの詳細な操作。 . . . . . . . . . . . . . . . . .22 3.1 電子LSP定義。 . . . . . . . . . . . . . . . . . . . . . . .22 'Encapsに居住する3.2-->PHBマッピング、'入って来るE-LSP.3.3Incoming PHB Determination On Incoming E-LSPのために。 . . . . . . . . .23 3.4 出発しているE-LSP.3.5Encoding Diff-Servに関する'PHBをセットしてください-->Encapsマッピング'という情報にEncapsulation Layer On Outgoing E-LSPに居住します。 . . . . . . . . . . . . . . . . . . . . . . . .26 3.6 電子LSP合併. . . . . . . . . . . . . . . . . . . . . . . . .27 4。 L-LSPsの詳細な操作。 . . . . . . . . . . . . . . . . .28 4.1 L-LSP定義。 . . . . . . . . . . . . . . . . . . . . . . .28 'Encapsに居住する4.2-->PHBマッピング、'入って来るL-LSP. .28 4.3Incoming PHB Determination On Incoming L-LSPのために。 . . . . . . . . .30 4.4 出発しているL-LSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 4.5に関する'PHBをセットしてください-->Encapsマッピング'というEncoding Diff-Serv情報にOutgoing L-LSPの上のEncapsulation Layerに居住します。 . . . . . . . . . . . . . . . . . . . . . . . .33 4.6 L-LSP合併. . . . . . . . . . . . . . . . . . . . . . . . .34 5。 Diff-Serv Support. . . . . . . . . . . . . .34 5.1Diff-ServのためのRSVP ExtensionはRSVP Messages Formatを関係づけました。 . . . . . . . . . . . .34 5.2 DIFFSERV物. . . . . . . . . . . . . . . . . . . . . . . .35 5.3の取り扱いDIFFSERVは反対します。 . . . . . . . . . . . . . . . . . . .37 5.4 DIFFSERV物の非サポート。 . . . . . . . . . . . . . .40 5.5 誤りはデフ-Servのために.5.6Intservサービスタイプをコード化します。 . . . . . . . . . . . . . . . . . . . . .41 6. デフ-Servサポート. . . . . . . . . . . . . .41 6.1デフ-Serv TLV.6.2デフ-Serv状態のための自由民主党の拡大は値をコード化します。 . . . . . . . . . . . . . . . . .44 6.3 デフ-Servは自由民主党メッセージについて話しました。 . . . . . . . . . . . . . . . .44 6.4 デフ-Serv TLV.496.6のデフ-Serv TLV.6.5非取り扱い帯域幅情報. . . . . . . . . . . . . . . . . . . . .49の取り扱い
Le Faucheur, et. al. Standards Track [Page 2] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[2ページ]。
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
7. pppの上のデフ-ServのMPLSサポート、LAN、非LCの気圧、および非LC-FRインタフェース. . . . . . . . . . . . . . . . . . . . . .49 8。 ATM Traffic ClassesとTraffic Managementメカニズム.50 8.2LSR Implementation With LC-ATM Interfaces.9のLC-ATM Interfaces. . . . . . . .50 8.1Useの上のDiff-ServのMPLS Support。 LC-FRの上のデフ-ServのMPLSサポートは連結します。 . . . . . . . .51 9.1 Frame Relay TrafficパラメタとTraffic Managementメカニズム. . . . . . . . . . . . . . . . . . . . . . . . . . .51 9.2LSR Implementation With LC-FR Interfacesの使用。 . . . . . . . . . . .51 10. IANA問題. . . . . . . . . . . . . . . . . . . . . .52 11。 セキュリティ問題. . . . . . . . . . . . . . . . . . . .52 12。 承認. . . . . . . . . . . . . . . . . . . . . . . .52付録A.例の展開シナリオ。 . . . . . . . . . . . . .53 付録B.例の帯域幅予約シナリオ… .58の参照箇所。 . . . . . . . . . . . . . . . . . . . . . . . . . . . .60人の作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . .62 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . .64
1. Introduction
1. 序論
In an MPLS domain [MPLS_ARCH], when a stream of data traverses a common path, a Label Switched Path (LSP) can be established using MPLS signaling protocols. At the ingress Label Switch Router (LSR), each packet is assigned a label and is transmitted downstream. At each LSR along the LSP, the label is used to forward the packet to the next hop.
データのストリームが共通路を横断するとき、MPLSドメイン[MPLS_ARCH]に、MPLSシグナリングプロトコルを使用することでLabel Switched Path(LSP)を設立できます。 イングレスLabel Switch Router(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.
Differentiated Service(デフ-Serv)ドメイン[DIFF_ARCH]では、リンクを越えて、同じDiff-Servの振舞いを必要とするすべてのIPパケットがBehavior Aggregate(BA)を構成すると言われています。 Diff-Servドメインのイングレスノードでは、パケットは、それらのBehavior Aggregateに対応するDiff-Serv Code Point(DSCP)と共に分類されて、マークされます。 それぞれのトランジットノードでは、DSCPは、スケジューリング処理を決定するPer Hop Behavior(PHB)を選択して、いくつかの場合、各パケットのために確率を落とすのに使用されます。
This document specifies a solution for supporting the Diff-Serv Behavior Aggregates whose corresponding PHBs are currently defined (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network. This solution also offers flexibility for easy support of PHBs that may be defined in the future.
このドキュメントはMPLSネットワークの上で対応するPHBsが現在定義されるDiff-Serv Behavior Aggregates([DIFF_HEADER]、[DIFF_AF][DIFF_EF]の)を支持する解決策を指定します。 また、この解決策は将来定義されるかもしれないPHBsの簡単なサポートのために柔軟性を提供します。
This solution relies on the combined use of two types of LSPs:
この解決策はLSPsの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 Shim HeaderのEXP分野がパケットに適用されるためにLSRまでPHBを運ぶ(パケットのスケジューリング処理の情報とその低下先行の両方をカバーしていて)ための複数のOrdered Aggregatesを輸送できるLSPs。
Le Faucheur, et. al. Standards Track [Page 3] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[3ページ]。
- 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).
- 独身のOrdered Aggregateを輸送するだけであるLSPs、したがって、パケットの低下先行はMPLS Shim HeaderのEXP分野か要約のリンクレイヤ特定の選択している低下メカニズム(ATM、Frame Relay、802.1)で伝えられますが、パケットが処理の計画をしているのはLSRによって排他的にパケットのラベル値から推論されます。
As mentioned in [DIFF_HEADER], "Service providers are not required to use the same node mechanisms or configurations to enable service differentiation within their networks, and are free to configure the node parameters in whatever way that is appropriate for their service offerings and traffic engineering objectives". Thus, the solution defined in this document gives Service Providers flexibility in selecting how Diff-Serv classes of service are Routed or Traffic Engineered within their domain (e.g., separate classes of services supported via separate LSPs and Routed separately, all classes of service supported on the same LSP and Routed together).
[DIFF_HEADER]で言及されるように、「サービスプロバイダーは、それらのネットワークの中でサービス分化を可能にするのに同じノードメカニズムか構成を使用するのが必要でなく、自由にいかなるそれらのサービス提供と交通工学目的に、適切な方法でもノードパラメタを構成できます」。 したがって、サービスのDiff-Servのクラスがどのようにそれらのドメイン(例えば別々に、すべてのクラスのサービスが同じLSPとRoutedで一緒に支持した別々のLSPsとRoutedを通して支持された別々のクラスのサービス)の中のRoutedかそれともTraffic Engineeredであるかを選択する際に本書では定義された解決策は柔軟性をService Providersに与えます。
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保護」のような能力について言及します。 この仕様の範囲の外にそのような能力と関連メカニズムがありますが、私たちは、それらが異なったレベルの保護を異なったLSPsに提供するかもしれないことに注意します。 Service Providersがここに提示された解決策でサービスのDiff-ServのクラスがどうLSPsに写像されるかを選ぶことができるので、また、解決策は異なったDiff-Servのクラスのサービスに提供された保護のレベルの柔軟性をService Providersに与えます(ある他のサービスのクラスが保護されないLSPsによって支持されますが、保護されるLSPsは例えば数人のクラスのサービスを支持できます)。
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.
その上、本書では指定された解決策は、ラベル宇宙保護を実現して、役に立つか、または必要であるときに、与えられたForwarding Equivalent Class(FEC)[MPLS_ARCH]のために複数のLSPsに頼るだけによって可能であるところでラベルセットアップ/分解シグナリングのボリュームを減少させます。
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交通の両方のためのDifferentiated Servicesのサポートを許します。 このドキュメントはユニキャストのための操作について説明するだけです。 今後の研究にはマルチキャストサポートがあります。
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.
本書では説明された解決策は、同時にDiff-Servと共にMPLSの上でExplicit Congestion Notification[電子証券取引ネットワーク]を支持するためにEXPビットの合図されたか構成された使用を排除しません。 しかしながら、このドキュメントの範囲の外にMPLS環境で電子証券取引ネットワークを支持するためのテクニックがあります。
Le Faucheur, et. al. Standards Track [Page 4] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[4ページ]。
1.1 Terminology
1.1 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
The reader is assumed to be familiar with the terminology of [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM], [MPLS_FR], including the following:
以下を含んでいて、読者が[MPLS_ARCH]、[MPLS_ENCAPS]、[MPLS_ATM][MPLS_FR]の用語によく知られさせると思われます:
FEC Forwarding Equivalency Class
FEC推進同等クラス
FTN FEC-To-NHLFE Map
FTN FECからNHLFEへの地図
ILM Incoming Label Map
ILMの入って来るラベル地図
LC-ATM Label Switching Controlled-ATM (interface)
LC-気圧のラベルの切り換えの制御気圧(インタフェース)
LC-FR Label Switching Controlled-Frame Relay (interface)
LC-FRのラベルの切り換えの制御フレームリレー(インタフェース)
LSP Label Switched Path
LSPラベルは経路を切り換えました。
LSR Label Switch Router
LSRラベルスイッチルータ
MPLS Multi-Protocol Label Switching
MPLSマルチプロトコルラベルスイッチング
NHLFE Next Hop Label Forwarding Entry
次のNHLFEはラベル推進エントリーを飛び越します。
The reader is assumed to be familiar with the terminology of [DIFF_ARCH], [DIFF_HEADER], [DIFF_AF], [DIFF_EF], including the following:
以下を含んでいて、読者が[DIFF_ARCH]、[DIFF_HEADER]、[DIFF_AF][DIFF_EF]の用語によく知られさせると思われます:
AF Assured Forwarding
AF相対的優先転送
BA Behavior Aggregate
Ba振舞い集合
CS Class Selector
Csクラスセレクタ
DF Default Forwarding
DFデフォルト推進
DSCP Differentiated Services Code Point
DSCPはサービスコード・ポイントを微分しました。
EF Expedited Forwarding
EF完全優先転送
PHB Per Hop Behavior
ホップの振舞いあたりのPHB
Le Faucheur, et. al. Standards Track [Page 5] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[5ページ]。
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は集合を注文しました。 注文規制を共有するBehavior Aggregatesのセット。
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に属すBehavior Aggregate(s)に適用される1PHB(s)のセット。 例えば、AF1xはAF11、AF12、およびAF13 PHBsを包括する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
電子LSP EXPはPSC LSPを推論しました。
L-LSP Label-Only-Inferred-PSC LSP
L-LSP、ラベルはPSC LSPを推論しただけです。
1.2 EXP-Inferred-PSC LSPs (E-LSP)
1.2 EXPはPSC LSPsを推論しました。(電子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.
1OAsを支持するのに独身のLSPを使用できます。 そのようなLSPsはこれらのBAsがかかるいくつのOAsにかかわらず与えられたFECの最大8BAsを支持できるか。 そのようなLSPsと共に、MPLS Shim Headerの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.
私たちは「EXPはPSC LSPsを推論した」ので(E- LSP)、そのようなLSPsを参照します、このLSPで輸送されたパケットのPSCがそのパケットのためにEXP分野価値によるので。
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.
EXPからのマッピングは、与えられたそのようなもののためにPHB(すなわち、PSCと低下先行への)としてLSPをさばくか、ラベルセットアップで明らかに示唆されるか、またはあらかじめ設定されたマッピングを当てにします。
Detailed operations of E-LSPs are specified in section 3 below.
E-LSPsの詳細な操作は下のセクション3で指定されます。
Le Faucheur, et. al. Standards Track [Page 6] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[6ページ]。
1.3 Label-Only-Inferred-PSC LSPs (L-LSP)
1.3 ラベルはPSC LSPsを推論しただけです。(L-LSP)
A separate LSP can be established for a single <FEC, OA> pair. With such LSPs, the PSC is explicitly signaled at the time of label establishment, so that after label establishment, the LSR can infer exclusively from the label value the PSC to be applied to a labeled packet. When the Shim Header is used, the Drop Precedence to be applied by the LSR to the labeled packet, is conveyed inside the labeled packet MPLS Shim Header using the EXP field. When the Shim Header is not used (e.g., MPLS Over ATM), the Drop Precedence to be applied by the LSR to the labeled packet is conveyed inside the link layer header encapsulation using link layer specific drop precedence fields (e.g., ATM CLP).
独身の<FEC、OA>組のために別々のLSPを設立できます。 そのようなLSPsと共に、PSCはラベル設立時点で明らかに合図されます、LSRがラベル設立の後にラベルされたパケットに適用されるためにラベル値からPSCを排他的に推論できるように。 使用されるShim Header(LSRによってラベルされたパケットに適用されるべきDrop Precedence)がラベルされたパケットMPLS Shim Headerの中をEXP分野を使用することで運ばれるとき。 Shim Headerがいつでないかが(例えば、MPLS Over ATM)を使用して、LSRによってラベルされたパケットに適用されるべきDrop Precedenceは、リンクレイヤヘッダーカプセル化でリンクレイヤの特定の低下先行分野(例えば、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.
私たちは、ラベルから情報(例えば、EXP分野価値にかかわらず)なしでいかなる他のもPSCを完全に推論できるので、「ラベルはPSC LSPsを推論していただけです」のようなLSPs(L-LSP)について言及します。 L-LSPsの詳細な操作は下のセクション4で指定されます。
1.4 Overall Operations
1.4 総合的な操作
For a given FEC, and unless media specific restrictions apply as identified in the sections 7, 8 and 9 below, this specification allows any one of the following combinations within an MPLS Diff-Serv domain:
与えられたFEC、特定の制限が当てはまるメディアがセクションで7、8、および9未満を特定しなかったなら、この仕様はMPLS Diff-Servドメインの中に以下の組み合わせのどれかを許容します:
- zero or any number of E-LSPs, and
- そしてゼロかいろいろなE-LSPs。
- zero or any number of L-LSPs.
- ゼロかいろいろなL-LSPs。
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.
ネットワーク管理者は、許容組み合わせのセットからLSPsの実際の組み合わせを選択して、Behavior Aggregatesが実際にLSPsのこの組み合わせの上でどのように輸送されるかを選択します、Diff-Servサポート、Traffic Engineering、およびMPLS Protectionに関してその人の環境と目的を最もよく合わせるために。 この仕様の範囲の外にそのような組み合わせを選択する評価基準があります。
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を運ぶ1LSPがあるかもしれません、例えば、OAのロードバランシングの目的のために。 しかしながら、注文規制を尊敬するために、同じLSPの上で与えられたmicroflowのすべてのパケット(与えられたOrdered Aggregateの複数のことによるとわたっているBAs)を輸送しなければなりません。 逆に、各LSP MUST、与えられたOAのすべての(アクティブ)のBAsを支持できてください。
Examples of deployment scenarios are provided for information in APPENDIX A.
展開シナリオに関する例をAPPENDIX Aの情報に提供します。
Le Faucheur, et. al. Standards Track [Page 7] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[7ページ]。
1.5 Relationship between Label and FEC
1.5 ラベルとFECとの関係
[MPLS_ARCH] states in section `2.1. Overview' that: `Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service". They may then apply different discard thresholds or scheduling disciplines to different packets. MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label. In this case, one may say that the label represents the combination of a FEC and a precedence or class of service.'
[MPLS_ARCH] セクション'2.1'で、述べます。 '概観、': 'いくつかのルータが単にパケットの次のホップを選ぶのではなく、パケットの「先行」か「サービスのクラス」を決定もするためにパケットのネットワーク層ヘッダーを分析します'。 そして、彼らは敷居かスケジューリングが異なったパケットに訓練する異なった破棄を適用するかもしれません。 しかし、MPLSが許容する、(必要でない、)、ラベルから完全か部分的に推論されるべきサービスの先行かクラス。 'この場合、ラベルがサービスのFECの組み合わせと先行かクラスを表すと言うかもしれません'。
In line with this, we observe that:
これに沿って、私たちは、以下のことを観測します。
- With E-LSPs, the label represents the combination of a FEC and the
set of BAs transported over the E-LSP. Where all the supported
BAs are transported over an E-LSP, the label then represents the
complete FEC.
- E-LSPsと共に、ラベルはE-LSPの上で輸送されたFECの組み合わせとBAsのセットを表します。 そして、すべての支持されたBAsが輸送されるところでは、E-LSPの上では、ラベルが完全なFECを表します。
- With L-LSPs, the label represents the combination of a FEC and an
OA.
- L-LSPsと共に、ラベルはFECとOAの組み合わせを表します。
1.6 Bandwidth Reservation for E-LSPs and L-LSPs
1.6 電子LSPsとL-LSPsのための帯域幅予約
Regardless of which label binding protocol is used, E-LSPs and L-LSPs may be established with or without bandwidth reservation.
プロトコルを縛るどのラベルが使用されているかにかかわらず、E-LSPsとL-LSPsは帯域幅の予約のあるなしにかかわらず設立されるかもしれません。
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)のために食糧を供給された(構成、SNMPまたは例えば、方針プロトコルで)Diff-Servリソースの上で合図されたLSPの入場コントロールを実行する設立時にLSRsによって使用されるかもしれません。 また、そのような合図された帯域幅要件は関連PSC(s)に関連しているDiff-Servリソースに調整を実行する設立時にLSRsによって使用されるかもしれません(例えば、PSCスケジューリングの重さを調整してください)。
Note that establishing an E-LSP or L-LSP with bandwidth reservation does not mean that per-LSP scheduling is required. Since E-LSPs and L-LSPs are specified in this document for support of Differentiated Services, the required forwarding treatment (scheduling and drop policy) is defined by the appropriate Diff-Serv PHB. This forwarding treatment MUST be applied by the LSR at the granularity of the BA and MUST be compliant with the relevant PHB specification.
帯域幅の予約でE-LSPかL-LSPを設立するのが、1LSPあたりのスケジューリングが必要であることを意味しないことに注意してください。 E-LSPsとL-LSPsが本書ではDifferentiated Servicesのサポートに指定されるので、必要な推進処理(スケジューリングと低下方針)は適切なDiff-Serv PHBによって定義されます。 この推進処理は、BAの粒状におけるLSRが適用しなければならなくて、関連PHB仕様で対応するに違いありません。
Le Faucheur, et. al. Standards Track [Page 8] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[8ページ]。
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に関連しています。 したがって、入場コントロールを実行するのに合図された帯域幅を使用するLSRsはDiff-Servリソースの入場コントロールを実行するかもしれません。(リソースはPSC(例えば、スケジューリングの重さを通してPSCに保証された帯域幅の上の)に捧げられます)。
When bandwidth requirements are signaled at the establishment of an E-LSP, the signaled bandwidth is associated collectively with the whole LSP and therefore with the set of transported PSCs. Thus, LSRs which use the signaled bandwidth to perform admission control may perform admission control over global resources, which are shared by the set of PSCs (e.g., over the total bandwidth of the link).
帯域幅要件がE-LSPの設立のときに合図されるとき、合図された帯域幅は全体のLSPとしたがって、輸送されたPSCsのセットにまとめて関連しています。 したがって、入場コントロールを実行するのに合図された帯域幅を使用するLSRsはグローバル資源の入場コントロールを実行するかもしれません。(グローバル資源はPSCs(例えば、リンクの総帯域幅の上の)のセットによって共有されます)。
Examples of scenarios where bandwidth reservation is not used and scenarios where bandwidth reservation is used are provided for information in APPENDIX B.
帯域幅の予約が使用されていないシナリオと帯域幅の予約が使用されているシナリオに関する例をAPPENDIX Bの情報に提供します。
2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models
2. デフ-Serv LSRsのラベル推進モデルとトンネリングモデル
2.1 Label Forwarding Model for Diff-Serv LSRs
2.1 デフ-Serv LSRsのラベル推進モデル
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の異なったOrdered Aggregatesが異なったLSPsの上で輸送されるかもしれないので、Diff-Serv LSRのラベルスワッピング決定は明確に進められたパケットのBehavior Aggregateによります。 また、PHBが容認されたパケットに適用されて、伝えられたパケットにPHBをコード化することを決定する進められたパケットのIP DS分野が直接LSRに目に見えないかもしれない時から方法も非MPLS Diff-Serv Routerと異なっています。
Thus, in order to describe Label Forwarding by Diff-Serv LSRs, we model the LSR Diff-Serv label switching behavior, comprised of four stages:
したがって、Diff-Serv LSRsでLabel Forwardingについて説明するために、私たちは4つのステージから成るLSR Diff-Servラベル切り換えの振舞いをモデル化します:
- Incoming PHB Determination (A)
- 入って来るPHB決断(A)
- Outgoing PHB Determination with Optional Traffic Conditioning(B)
- 任意の交通調節との外向的なPHB決断(B)
- Label Forwarding (C)
- ラベル推進(C)
- Encoding of Diff-Serv information into Encapsulation Layer (EXP,
CLP, DE, User_Priority) (D)
- Encapsulation Layer(EXP、CLP、DE User_Priority)へのDiff-Serv情報のコード化(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.
また、明らかに、Diff-Servサービス分化を実施するために、LSR MUSTはOutgoing PHBに対応する推進処理を適用します。
Le Faucheur, et. al. Standards Track [Page 9] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[9ページ]。
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)
--Inc_ラベル(*)------------------------>I===私--Outg_ラベル(&)-->\I I\\---->I===I I C I\-->I===I--Encaps->I A I I===私--Outg_PHB>I===I I D I(&) -Encaps>I===私--、Inc_PHB、-、>I B I\/>I===I(*)I===I\--------+ \----推進-->処理(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 Encapsulation層の中でコード化されたDiff-Serv関連情報を指定します。(例えば、EXP分野、ATM CLP、Frame Relay DE802.1User_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.
MPLS出口ノード、出発しているパケットが伝えられるかもしれないようにLSRが振る舞うとき、(&)は非ラベルされました。
This model is presented here to describe the functional operations of Diff-Serv LSRs and does not constrain actual implementation.
このモデルは、Diff-Serv LSRsの機能操作について説明するためにここに提示されて、実際の実現を抑制しません。
2.2 Incoming PHB Determination
2.2 入って来るPHB決断
This stage determines which Behavior Aggregate the received packet belongs to.
このステージは、容認されたパケットがどのBehavior Aggregateに属すかを決定します。
2.2.1 Incoming PHB Determination Considering a Label Stack Entry
2.2.1 ラベルスタックがエントリーであると考える入って来るPHB決断
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はLSPがタイプする入来と入って来るMPLSカプセル化によるときどう与えられた容認されたラベルがスタックエントリーであると考える入って来るPHB Determination、そして/または、容認された入って来る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によるIncoming PHB Determinationのためにどのラベルスタックエントリーを考えたらよいかに関する詳細を明らかにします。
2.2.2 Incoming PHB Determination Considering IP Header
2.2.2 入って来るPHB決断考えているIPヘッダー
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
セクション2.6はIP Headerが入って来るPHB決断のために考えられることになっている時に関する詳細を明らかにします、支持されたDiff-Servトンネリングモデルに頼っていて。 IPヘッダーがあるそれらの場合で
Le Faucheur, et. al. Standards Track [Page 10] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[10ページ]。
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.
使用されていて、このステージがちょうど非MPLS IP Diff-Serv Routerのように作動して、入って来るPHBを決定するのにDS分野を使用するということになってください。
2.3 Outgoing PHB Determination With Optional Traffic Conditioning
2.3 任意の交通調節との外向的なPHB決断
The traffic conditioning stage is optional and may be used on an LSR to perform traffic conditioning including Behavior Aggregate demotion or promotion. It is outside the scope of this specification. For the purpose of specifying Diff-Serv over MPLS forwarding, we simply note that the PHB to be actually enforced and conveyed to downstream LSRs by an LSR (referred to as "outgoing PHB"), may be different to the PHB which had been associated with the packet by the previous LSR (referred to as "incoming PHB").
交通調節ステージは、任意であり、Behavior Aggregate格下げか販売促進を含んでいて、交通調節を実行するのにLSRで使用されるかもしれません。 この仕様の範囲の外にそれはあります。 MPLS推進の上でDiff-Servを指定する目的によって、私たちは単にそれに注意します。LSR(「出発しているPHB」と呼ばれる)によって実際に実施された、川下のLSRsまで運ばれるべきPHB、前のLSR(「入って来るPHB」と呼ばれる)でパケットに関連したPHBに異なるかもしれません。
When the traffic conditioning stage is not present, the "outgoing PHB" is simply identical to the "incoming PHB".
交通調節ステージが存在していないとき、「出発しているPHB」は単に「入って来るPHB」と同じです。
2.4 Label Forwarding
2.4 ラベル推進
[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に写像されるIncoming Label Map(ILM)を使用することでパケットとラベルされた入来にラベルスワッピングがLSRsによってどう実行されるかを説明します。 また、[MPLS_ARCH]はラベル賦課がLSRsによってそれぞれの入って来るFECが1か複数のNHLFEsに写像されるFECからNHLFEs Map(FTN)を使用することでどう実行されるかを入って来る非ラベルされたパケットに説明します。
A Diff-Serv Context for a label is comprised of:
ラベルのためのDiff-Serv Contextは以下から成ります。
- `LSP type (i.e., E-LSP or L-LSP)'
- 'LSPは(すなわち、E-LSPかL-LSP)をタイプします'
- `supported PHBs'
- '支持されたPHBs'
- `Encaps-->PHB mapping' for an incoming label
- 入来のためにラベルを'>PHBが写像して、Encapsします'。
- `Set of PHB-->Encaps mappings' for an outgoing label
- 出発しているラベルに関する'PHBをセットしてください-->Encapsマッピング'
The present specification defines that a Diff-Serv Context is stored in the ILM for each incoming label.
Diff-Serv Contextが格納される仕様が定義する各入来のための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が適切にパケットを処分するのに必要であるいかなる他の情報も含むかもしれないと述べる、' これに従って、現在の仕様は交換されるそれぞれの出発しているラベルのためにNHLFEに格納されるか、または押されたそのa Diff- Serv Contextを定義します。
This Diff-Serv Context information is populated into the ILM and the FTN at label establishment time.
このDiff-Serv Context情報はラベル設立時間にILMとFTNに居住されます。
Le Faucheur, et. al. Standards Track [Page 11] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[11ページ]。
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.
ラベルがどの以下でセクション3.2で議論する'EXP<-->PHBマッピングが'LSPセットアップで明らかに示唆されていて、'支持されたPHBs'にあらかじめ設定のPHBsのセットで居住されるということである'というEXP<-->PHBマッピング'でない.1のためにE-LSPに対応しているかなら。
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セットアップで明らかに示唆されていて、'支持されたPHBs'が合図のPHBsのセットで居住されるということである'というEXP<)>PHBマッピング'。
If the label corresponds to an L-LSP, the `supported PHBs' is populated with the set of PHBs forming the PSC that is signaled at LSP set-up.
ラベルがL-LSPに対応しているなら、PHBsのセットがLSPセットアップで示唆されるPSCを形成している状態で、'支持されたPHBs'は居住されます。
The details of how the `Encaps-->PHB mapping' or `Set of PHB-->Encaps mappings' are populated are defined below in sections 3 and 4.
'Encaps(''PHBのセットを写像する>PHB)>Encapsマッピング'がどう居住されるかに関する詳細は以下でセクション3と4で定義されます。
[MPLS_ARCH] also states that:
また、[MPLS_ARCH]は、以下のことと述べます。
"If the ILM [respectively, FTN] maps a particular label to a set of NHLFEs that contain more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the ILM [respectively, FTN] map a label [respectively, a FEC] to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths."
「ILM[それぞれFTN]が1つ以上の要素を含むNHLFEsの1セットに特定のラベルを写像するなら、パケットを進める前にちょうどセットの1つの要素を選ばなければなりません。」 セットから要素を選ぶための手順はこのドキュメントの範囲を超えています。 「例えば、複数の等しい費用経路にわたってロードバランシングをするのが必要であるなら、ILM[それぞれFTN]にラベル[それぞれFEC]を1NHLFEを含むセットに写像させるのは、役に立つかもしれません。」
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]が写像されるかもしれないのを許容します、Diff-Serv目的のために、複数のNHLFEsに(例えば、どこで、異なったNHLFEsはPHBsの異なったセットを支える出口ラベルに対応していますか)。 [それぞれFEC]が複数のNHLFEs、Diff-Serv LSRに写像するラベルが選ばなければならないとき、Diff-Serv Contextが進められたパケットのOutgoing PHBを支持するのを示すNHLFEsの1つを選んでください。
When a label [respectively FEC] maps to multiple NHLFEs which support the Outgoing PHB, the procedure for choosing one among those is outside the scope of this document. This situation may be encountered where it is desired to do load balancing of a Behavior Aggregate over multiple LSPs. In such situations, in order to respect ordering constraints, all packets of a given microflow MUST be transported over the same LSP.
このドキュメントの範囲の外で[それぞれFEC]がそれらの中の1つを選ぶためにOutgoing PHB、手順を支持する複数のNHLFEsに写像するラベルはいつですか? この状況は複数のLSPsの上にBehavior Aggregateのロードバランシングをするのが必要であるところで遭遇するかもしれません。 そのような状況で、注文規制を尊敬するために、同じLSPの上で与えられたmicroflowのすべてのパケットを輸送しなければなりません。
Le Faucheur, et. al. Standards Track [Page 12] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[12ページ]。
2.5 Encoding Diff-Serv Information Into Encapsulation Layer
2.5 デフ-Serv情報をカプセル化層の中にコード化すること。
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).
このステージは伝えられたパケット(例えば、MPLS Shim EXP、ATM CLP、Frame Relay DE802.1User_Priority)でDiff-Serv情報を伝える分野をコード化する方法を決定します。
2.5.1 Encoding Diff-Serv Information Into Transmitted Label Entry
2.5.1 デフ-Serv情報を伝えられたラベルエントリーにコード化すること。
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はどう与えられた伝えられたラベルスタックエントリー、そして/または、伝えられたMPLSカプセル化に対応する外向的なLSPタイプに頼る情報をコード化して、MPLSカプセル化によるDiff-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は、モードにトンネルを堀りながら支持されたDiff-ServによるのにDiff-Serv情報コード化を実行するためにどのラベルスタックエントリーに詳細を明らかにするか。
2.5.2 Encoding Diff-Serv Information Into Transmitted IP Header
2.5.2 デフ-Serv情報を伝えられたIPヘッダーにコード化すること。
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情報Encodingを実行するために、ちょうど非MPLS IP Diff- Serv Routerのように作動して、Outgoing PHBのDSCPをDS分野にコード化します。
Section 2.6 provides the details of when Diff-Serv Information Encoding is to be performed into transmitted IP header depending on the supported Diff-Serv tunneling mode.
セクション2.6は、モードにトンネルを堀りながら、Diff-Serv情報Encodingが支持されたDiff-Servを当てにする伝えられたIPヘッダーに実行されることになっている時に関する詳細を明らかにします。
2.6 Diff-Serv Tunneling Models over MPLS
2.6 MPLSの上でモデルにトンネルを堀るデフ-Serv
2.6.1 Diff-Serv Tunneling Models
2.6.1 デフ-Servトンネリングモデル
[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トンネルとのDifferentiated Servicesの相互作用を考えます。MPLSの要約のヘッダーがIPヘッダーを含んでいなくて、またその結果、MPLS LSPsが[DIFF_TUNNEL]で考えられないので、MPLS LSPsは「IPトンネル」のフォームではありません。 しかしながら、「IPトンネル」のフォームではありませんが、MPLS LSPsは「トンネル」のフォームです。
From the Diff-Serv standpoint, LSPs share a number of common characteristics with IP Tunnels:
Diff-Serv見地から、LSPsはIP Tunnelsと多くの共通する特徴を共有します:
- Intermediate nodes (i.e., Nodes somewhere along the LSP span) only
see and operate on the "outer" Diff-Serv information.
- 中間的ノード(すなわち、LSPの長さに沿ったどこかのNodes)は、「外側」のDiff-Serv情報を見るだけであり、作動させます。
- LSPs are unidirectional.
- LSPsは単方向です。
Le Faucheur, et. al. Standards Track [Page 13] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[13ページ]。
- The "outer" Diff-Serv information can be modified at any of the
intermediate nodes.
- 中間的ノードのいずれでも「外側」のDiff-Serv情報を変更できます。
However, from the Diff-Serv standpoint, LSPs also have a distinctive property compared to IP Tunnels:
しかしながら、Diff-Serv見地から、また、LSPsは特有の特性をIP Tunnelsと比較させます:
- 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 Tunnelsと共に使用されるPenultimate Hop Popping(PHP)への類似のどんな振舞いもありません。 その上、PHPはLSP出口に目に見えないLSPに関連している「外側」のDiff-Serv情報をもたらします。 この情報がLSP Egressで重要でない状況で、これは明らかに全く問題ではありません。 そして、この情報がLSP Egressで重要である状況で、どうにかある他の手段でそれを運ばなければなりません。
The two conceptual models for Diff-Serv tunneling over IP Tunnels defined in [DIFF_TUNNEL] are applicable and useful to Diff-Serv over MPLS but their respective detailed operations is somewhat different over MPLS. These two models are the Pipe Model and the Uniform Model. Their operations over MPLS are specified in the following sections. Discussion and definition of alternative tunneling models are outside the scope of this specification.
IP Tunnelsの上で[DIFF_TUNNEL]で定義されたDiff-Servトンネリングのための2人の概念モデルが、MPLSの上でDiff-Servに適切であって、役に立ちますが、彼らのそれぞれの詳細な操作はMPLSの上でいくらか異なっています。 これらの2つのモデルが、Pipe ModelとUniform Modelです。 MPLSの上の彼らの操作は以下のセクションで指定されます。 この仕様の範囲の外に代替のトンネリングモデルの議論と定義があります。
2.6.2 Pipe Model
2.6.2 パイプモデル
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.
Pipe Modelと共に、MPLSトンネル(通称LSPs)は、Diff-Serv見解から中間的MPLSノードをLSP IngressとEgressの間に隠すのに使用されます。
In this model, tunneled packets must convey two meaningful pieces of Diff-Serv information:
このモデルでは、トンネルを堀られたパケットは2つの重要なDiff-Serv情報を伝えなければなりません:
- the Diff-Serv information which is meaningful to intermediate
nodes along the LSP span including the LSP Egress (which we refer
to as the "LSP Diff-Serv Information"). This LSP Diff-Serv
Information is not meaningful beyond the LSP Egress: Whether
Traffic Conditioning at intermediate nodes on the LSP span affects
the LSP Diff-Serv information or not, this updated Diff-Serv
information is not considered meaningful beyond the LSP Egress and
is ignored.
- LSP Egress(私たちが「LSPデフ-Serv情報」を呼ぶ)を含んでいて、LSPの長さに沿って中間的ノードに重要なDiff-Serv情報。 このLSP Diff-Serv情報はLSP Egressを超えて重要ではありません: LSPの長さの上の中間的ノードのTraffic ConditioningがLSP Diff-Serv情報に影響するか否かに関係なく、このアップデートされたDiff-Serv情報は、LSP Egressを超えて重要であることは考えられないで、無視されます。
- the Diff-Serv information which is meaningful beyond the LSP
Egress (which we refer to as the "Tunneled Diff-Serv
Information"). This information is to be conveyed by the LSP
Ingress to the LSP Egress. This Diff-Serv information is not
meaningful to the intermediate nodes on the LSP span.
- LSP Egress(私たちが「トンネルを堀られたデフ-Serv情報」を呼ぶ)で重要なDiff-Serv情報。 この情報はLSP IngressによってLSP Egressまで運ばれることです。 このDiff-Serv情報はLSPの長さの上の中間的ノードに重要ではありません。
Le Faucheur, et. al. Standards Track [Page 14] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[14ページ]。
Operation of the Pipe Model without PHP is illustrated below:
PHPのないPipe Modelの操作は以下で例証されます:
========== LSP =============================>
========== LSP=============================>。
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E (M*)
---スワップしてください((M))…--スワップしてください--(M)--スワップしてください。---- /(外側のヘッダー)\(M)(M)/\>--(m) -押してください…(m).....................ポップス--(m)-->I(内側のヘッダー)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)は(m)がLSP Egressが、情報が私が表す処理(すなわち、実際のPHB)にLSPイングレスノードEを転送しながらDiff-Servを適用するために外側のヘッダー(すなわち、ポップスの前の)で受けたLSP Diff-ServがLSP出口ノードを表すと考えるという「トンネルを堀られたDiff-Serv情報」(*)を表すという「LSP Diff-Serv情報」を表します。
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デフ-Serv情報」が、LSP Egressまで運ばれる必要があるので、それはPipe Modelと共にそれに基づく推進処理を適用します。 また、「トンネルを堀られたDiff-Serv情報」は、さらに川下までそれを運ぶことができるようにLSP Egressまで運ばれる必要があります。
Since both require that Diff-Serv information be conveyed to the LSP Egress, the Pipe Model operates only without PHP.
両方が、Diff-Serv情報がLSP Egressに伝えられるのを必要とするので、Pipe ModelはPHPだけなしで作動します。
The Pipe Model is particularly appropriate for environments in which:
Pipe Modelは中の環境のために特にどれを当てるかことです:
- 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 Ingressの入って来るインタフェースの雲の上流とLSP Egressの外向的なインタフェースの雲の川下が方針に食糧を供給するDiff- Servサービスと一般的なPHB定義を利用するDiff-Servドメインにあります、LSPは(s) 方針に食糧を供給するDiff-Servサービスと異なったPHB定義を利用する1つ(さらに)のデフ-Servドメインにかかっていますが
- the outgoing interface of the LSP Egress is in the (last) Diff-
Serv domain spanned by the LSP.
- LSP Egressの外向的なインタフェースがLSPによってかかられた(最後)のデフ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
例と、Diff-Serv分化を含んでいて、サービスプロバイダーがMPLS VPNサービス(MPLS VPN構造の例に関して[MPLS_VPN]を見る)を提供しているケースを考えてください。 サイトの収集がそのようなMPLS VPNサービスでインタコネクトされると言ってください。 今度は、サイトのこの収集が一般的な管理の下で管理されて、また、Diff-Servサービス分化を支持していると言ってください。 VPNが管理とServiceを位置させるなら
Le Faucheur, et. al. Standards Track [Page 15] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[15ページ]。
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.
プロバイダーは全く同じDiff-Serv方針を共有していなくて(例えば、PHBsの同じ数を支持しないで)、次に、MPLS VPNサービスの上のPipe ModelでのDiff-Servの操作は、VPN Sites Diff-Serv方針がService Provider Diff-Servドメインの上で一貫してイングレスのVPN SiteとEgress VPN Siteに透明に作動するのを許容するでしょう。 それらの終点でそれらが中間ネットワークノードによって物理的に切り離されるかもしれませんが、これらの終点を実際には隣接にすることによってただ一つのDiff-Serv領域にDiff-ServドメインをリンクするようなLSPsを見るのは役に立つかもしれません。
The Pipe Model MUST be supported.
Pipe Modelを支持しなければなりません。
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の上のPipe Modelのサポートのために、LSRは以下の方法でIncoming PHB DeterminationとDiff-Serv情報Encodingを実行します:
- when receiving an unlabelled packet, the LSR performs Incoming PHB
Determination considering the received IP Header.
- 非ラベルされたパケットを受けるとき、容認されたIP Headerを考える場合、LSRはIncoming PHB Determinationを実行します。
- 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はIncoming PHB Determinationを実行します。 特に、飛び出し操作が考えられたLSPのために実行されることであることのLSRはIncoming PHB Determination BEFOREを実行します。ポップス。
- 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に対応するDiff-Serv情報をコード化します。
o encodes Diff-Serv Information corresponding to the INCOMING PHB
in the encapsulated header (swapped label entry or IP header).
o 要約のヘッダー(ラベルエントリーかIPヘッダーを交換する)でINCOMING PHBに対応するDiff-Serv情報をコード化します。
- when performing a swap-only operation for the considered LSP, the
LSR encodes Diff-Serv Information in the transmitted label entry
that contains the swapped label
- 考えられたLSPのためにスワッピングだけ操作を実行するとき、LSRは交換されたラベルを含む伝えられたラベルエントリーでDiff-Serv情報をコード化します。
- when 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情報のEncodingを実行しません(すなわち、LSRは「そのままで」露出しているヘッダーを置き去りにします)。
2.6.2.1 Short Pipe Model
2.6.2.1 背の低いパイプモデル
The Short Pipe Model is an optional variation of the Pipe Model described above. The only difference is that, with the Short Pipe
Short Pipe Modelは上で説明されたPipe Modelの任意の変化です。 唯一の違いがShort Pipeがあるそれです。
Le Faucheur, et. al. Standards Track [Page 16] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[16ページ]。
Model, the Diff-Serv forwarding treatment at the LSP Egress is applied based on the "Tunneled Diff-Serv Information" (i.e., Diff- Serv information conveyed in the encapsulated header) rather than on the "LSP Diff-Serv information" (i.e., Diff-Serv information conveyed in the encapsulating header).
モデル、LSP Egressで処理を進めるDiff-Servは「LSP Diff-Serv情報」(すなわち、要約のヘッダーで伝えられたDiff-Serv情報)でというよりむしろ「トンネルを堀られたデフ-Serv情報」(すなわち、要約のヘッダーで伝えられたDiff- Serv情報)に基づいて適用されます。
Operation of the Short Pipe Model without PHP is illustrated below:
PHPのないShort Pipe Modelの操作は以下で例証されます:
========== LSP =============================>
========== LSP=============================>。
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E
---スワップしてください((M))…--スワップしてください--(M)--スワップしてください。---- /(外側のヘッダー)\(M)(M)/\>--(m) -押してください…(m).....................ポップス--(m)-->I(内側のヘッダー)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)が表す、(m)がIがLSPイングレスノードEを表すという「トンネルを堀られたDiff-Serv情報」を表すという「LSP Diff-Serv情報」はLSP出口ノードを表します。
Since the LSP Egress applies its forwarding treatment based on the "Tunneled Diff-Serv Information", the "LSP Diff-Serv information" does not need to be conveyed by the penultimate node to the LSP Egress. Thus the Short Pipe Model can also operate with PHP.
LSP Egressが「トンネルを堀られたデフ-Serv情報」に基づく推進処理を適用するので、終わりから二番目のノードによって「LSP Diff-Serv情報」によってLSP Egressまで運ばれる必要はありません。 したがって、また、Short Pipe ModelはPHPと共に作動できます。
Operation of the Short Pipe Model with PHP is illustrated below:
PHPとのShort Pipe Modelの操作は以下で例証されます:
=========== LSP ============================>
=========== LSP============================>。
---Swap--(M)--...--Swap------
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).............Pop-(m)--E--(m)-->
I (inner header) P (M*)
---スワップしてください((M))…--スワッピング------ /(外側のヘッダー)\(M)(M)/\>--(m) -押してください…(m).............大衆的な(m)--E--(m)-->I(内側のヘッダー)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)は(m)がPenultimate LSRが私が表す処理(すなわち、実際のPHB)にイングレスノードPが表すLSPを送りながらDiff-Servを適用するために外側のヘッダー(すなわち、ポップスの前の)に受け取って、LSPの終わりから二番目のノードEがLSP出口ノードを表すというLSP Diff-Serv情報であると考える「トンネルを堀られたDiff-Serv情報」(*)を表すという「LSP Diff-Serv情報」を表します。
Le Faucheur, et. al. Standards Track [Page 17] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[17ページ]。
The Short Pipe Model is particularly appropriate for environments in which:
Short Pipe Modelは中の環境のために特にどれを当てるかことです:
- 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 Ingressの入って来るインタフェースの雲の上流とLSP Egressの外向的なインタフェースの雲の川下が方針に食糧を供給するDiff- Servサービスと一般的なPHB定義を利用するDiff-Servドメインにあります、LSPは(s) 方針に食糧を供給するDiff-Servサービスと異なったPHB定義を利用する1つ(さらに)のデフ-Servドメインにかかっていますが
- the outgoing interface of the LSP Egress is in the same Diff-Serv
domain as the cloud downstream of it.
- LSP Egressの外向的なインタフェースがそれの雲の川下と同じDiff-Servドメインにあります。
Since each outgoing interface of the LSP Egress is in the same Diff- Serv domain as the cloud downstream of it, each outgoing interface may potentially be in a different Diff-Serv domain, and the LSP Egress needs to be configured with awareness of every corresponding Diff-Serv policy. This operational overhead is justified in some situations where the respective downstream Diff-Serv policies are better suited to offering service differentiation over each egress interface than the common Diff-Serv policy used on the LSP span. An example of such a situation is where a Service Provider offers an MPLS VPN service and where some VPN users request that their own VPN Diff-Serv policy be applied to control service differentiation on the dedicated link from the LSP Egress to the destination VPN site, rather than the Service Provider's Diff-Serv policy.
LSP Egressのそれぞれの外向的なインタフェースがそれの雲の川下と同じDiff- Servドメインにあるので、それぞれの外向的なインタフェースが異なったDiff-Servドメインに潜在的にあるかもしれません、そして、LSP Egressはあらゆる対応するDiff-Serv方針の認識によって構成される必要があります。 この操作上のオーバーヘッドはそれぞれの川下のDiff-Serv方針がLSPの長さの上で使用される一般的なDiff-Serv方針よりそれぞれの出口のインタフェースにわたってサービス分化を提供するのに適しているほうがよいいくつかの状況で正当化されます。 そのような状況に関する例はService ProviderがMPLS VPNサービスをどこに提供するか、そして、何人かのVPNユーザが、どこでそれら自身のVPN Diff-Serv方針がLSP EgressからService ProviderのDiff-Serv方針よりむしろ目的地VPNサイトへの専用リンクの上にサービス分化を制御するために適用されるよう要求するかということです。
The Short Pipe Model MAY be supported.
Short Pipe Modelは支持されるかもしれません。
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の上のShort Pipe Modelのサポートのために、LSRは以下の例外があるPipe Modelのように同じ方法でIncoming PHB DeterminationとDiff-Serv情報Encodingを実行します:
- 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.
- ラベルされたパケットを受けるとき、ヘッダーが実際の推進をするのに使用される(ラベルエントリーかIPヘッダー)であると考える場合、LSRはIncoming PHB Determinationを実行します。 特に、飛び出し操作が考えられたLSPのために実行されることであることのLSRはIncoming PHB Determination AFTERを実行します。ポップス。
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の上のShort Pipe Modelのサポートのために、LSRは以下の例外があるPHPのように同じ方法でIncoming PHB DeterminationとDiff-Serv情報Encodingを実行します:
Le Faucheur, et. al. Standards Track [Page 18] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[18ページ]。
- 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.
- 容認されたラベルスタックで外側のラベルがエントリーであると考える場合、Penultimate LSRはIncoming PHB Determinationを実行します。 言い換えれば、飛び出し操作が考えられたLSPのために実行されることであることのPenultimate LSRはIncoming PHB Determination BEFOREを実行します。ポップス。
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とShort Pipe ModeのPenultimate LSRの動きがPipe Mode(必ずPHPのない)のLSP Egressの動きと同じであることに注意してください。
2.6.3 Uniform Model
2.6.3 一定のモデル
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.
Uniform Modelと共に、MPLSトンネル(通称LSPs)は終わりから端への経路の人工物としてDiff-Serv見地から見なされます。 MPLS Tunnelsは、推進目的に使用されますが、Diff-Servでどんな重要な影響も与えないかもしれません。 このモデルでは、どんなパケットもまさにどれが重要であり、外側でいつも最もコード化されるかがエントリー(または例えばIPパケットがLSPの出口で非ラベルされていた状態で伝えられるIP DSCPで)をラベルするというDiff-Serv情報の1つの断片を含んでいます。 他のどこか(例えば、より深いラベルエントリーで)でコード化されたどんなDiff-Serv情報も、中間的ノード、または、トンネル出口に意味が全くなくて、無視されます。 LSPの長さの上の中間的ノードのTraffic Conditioningが「外側」のDiff-Serv情報に影響するなら、アップデートされたDiff-Serv情報はLSPの出口で重要であると考えられたものです。
Operation of the Uniform Model without PHP is illustrated below:
PHPのないUniform Modelの操作は以下で例証されます:
========== LSP =============================>
========== LSP=============================>。
---Swap--(M)--...-Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(M)--Push...............(x).......................Pop--(M)->
I (inner header) E
---スワップしてください((M))…-スワップしてください--(M)--スワップしてください。---- /(外側のヘッダー)\(M)(M)/\>((M))は押されます…(x).......................ポップス--(M)->I(内側のヘッダー)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)は対応するヘッダーでコード化されたMeaningful Diff-Serv情報を表します。 (x) 非重要なDiff-Serv情報を表します。 私が表す、LSPイングレスノードEはLSP出口ノードを表します。
Le Faucheur, et. al. Standards Track [Page 19] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[19ページ]。
Operation of the Uniform Model with PHP is illustrated below:
PHPとのUniform Modelの操作は以下で例証されます:
========== LSP =========================>
========== LSP=========================>。
---Swap-(M)-...-Swap------
/ (outer header) \
(M) (M)
/ \
>--(M)--Push..............(x)............Pop-(M)--E--(M)->
I (inner header) P
---スワッピング(M)、-、…-スワッピング------ /(外側のヘッダー)\(M)(M)/\>((M))は押されます…(x)............大衆的な(M)--E--(M)->I(内側のヘッダー)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)は対応するヘッダーでコード化されたMeaningful Diff-Serv情報を表します。 (x) 非重要なDiff-Serv情報を表します。 私が表す、LSPイングレスノードPが終わりから二番目のノード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のためのUniform Modelがそのようなものであるので、MPLSが使用されなかったなら、操作はまさにDiff-Serv見解から操作と同じです。 言い換えれば、MPLSはDiff-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.
Uniform Modelの使用で、LSPsはDiff-Servドメインの間の物理的な境界の相互ドメインTraffic Conditioning Agreementと重要なDiff-Serv情報がいつも目に見えて修正できるので排他的な「外側」のヘッダーの上の操作よりいちばん遠いラベルエントリーにおける適所にある測定なしでいかなる他のもDiff-Servドメイン境界にかかることができます。
The Uniform Model MAY be supported.
Uniform Modelは支持されるかもしれません。
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の上のUniform Modelのサポートのために、LSRは以下の方法でIncoming PHB DeterminationとDiff-Serv情報Encodingを実行します:
- when receiving an unlabelled packet, the LSR performs Incoming PHB
Determination considering the received IP Header.
- 非ラベルされたパケットを受けるとき、容認されたIP Headerを考える場合、LSRはIncoming PHB Determinationを実行します。
- 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はIncoming PHB Determinationを実行します。 特に、飛び出し操作が考えられたLSPのために実行されることであることのLSRはIncoming PHB Determination BEFOREを実行します。ポップス。
Le Faucheur, et. al. Standards Track [Page 20] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[20ページ]。
- when performing a push operation for the considered LSP, the LSR
encodes Diff-Serv Information in the transmitted label entry
corresponding to the pushed label. The Diff-Serv Information
encoded in the encapsulated header (swapped label entry or IP
Header) is of no importance.
- 考えられたLSPのためにプッシュ操作を実行するとき、LSRは押されたラベルに対応する伝えられたラベルエントリーでDiff-Serv情報をコード化します。 要約のヘッダー(ラベルエントリーかIP Headerを交換する)でコード化されたDiff-Serv情報は全く重要ではありません。
- when performing a swap-only operation for the considered LSP, the
LSR encodes Diff-Serv Information in the transmitted label entry
that contains the swapped label.
- 考えられたLSPのためにスワッピングだけ操作を実行するとき、LSRは交換されたラベルを含む伝えられたラベルエントリーでDiff-Serv情報をコード化します。
- when PHP is used, the Penultimate LSR needs to be aware of the
"Set of PHB-->Encaps mappings" for the label corresponding to the
exposed header (or the `PHB-->DSCP mapping') in order to perform
Diff-Serv Information Encoding. Methods for providing this
mapping awareness are outside the scope of this specification. As
an example, the "PHB-->DSCP mapping" may be locally configured.
As another example, in some environments, it may be appropriate
for the Penultimate LSR to assume that the "Set of PHB-->Encaps
mappings" to be used for the outgoing label in the exposed header
is the "Set of PHB-->Encaps mappings" that would be used by the
LSR if the LSR was not doing PHP. Note also that this
specification assumes that the Penultimate LSR does not perform
label swapping over the label entry exposed by the pop operation
(and in fact that it does not even look at the exposed label).
Consequently, restrictions may apply to the Diff-Serv Information
Encoding that can be performed by the Penultimate LSR. For
example, this specification does not allow situations where the
Penultimate LSR pops a label corresponding to an E-LSP supporting
two PSCs, while the header exposed by the pop contains label
values for two L-LSPs each supporting one PSC, since the Diff-Serv
Information Encoding would require selecting one label or the
other.
- 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.
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.
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.
Le Faucheur, et. al. Standards Track [Page 21] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 21] RFC 3270 MPLS Support of Differentiated Services May 2002
2.6.4 Hierarchy
2.6.4 Hierarchy
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.
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.
Hierarchical operations are illustrated below in the case of two levels of tunnels:
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)
+--------Swap--...---+ / (outmost header) \ / \ Push(2).................(2)Pop / (outer header) \ / \ >>---Push(1)........................(1)Pop-->> (inner header)
(1) Tunneling Model 1 (2) Tunneling Model 2
(1) Tunneling Model 1 (2) Tunneling Model 2
Tunneling Model 2 may be the same as or may be different from Tunneling Model 1.
Tunneling Model 2 may be the same as or may be different from Tunneling Model 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.
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.
3. Detailed Operations of E-LSPs
3. Detailed Operations of E-LSPs
3.1 E-LSP Definition
3.1 E-LSP Definition
E-LSPs are defined in section 1.2.
E-LSPs are defined in section 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.
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.
Le Faucheur, et. al. Standards Track [Page 22] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 22] RFC 3270 MPLS Support of Differentiated Services May 2002
For a given FEC, two given E-LSPs using a signaled `EXP<-->PHB mapping' can support the same or different sets of Ordered Aggregates.
For a given FEC, two given E-LSPs using a signaled `EXP<-->PHB mapping' can support the same or different sets of Ordered Aggregates.
3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP
3.2 Populating the `Encaps-->PHB mapping' for an incoming 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.
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.
The `Encaps-->PHB mapping' for an E-LSP is always of the form `EXP-->PHB mapping'.
The `Encaps-->PHB mapping' for an E-LSP is always of the form `EXP-->PHB mapping'.
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.
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.
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'.
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'.
3.2.1 Preconfigured `EXP<-->PHB mapping'
3.2.1 Preconfigured `EXP<-->PHB mapping'
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.
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.
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.
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.
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.
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.
3.3 Incoming PHB Determination On Incoming E-LSP
3.3 Incoming PHB Determination On Incoming E-LSP
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.
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.
Le Faucheur, et. al. Standards Track [Page 23] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 23] RFC 3270 MPLS Support of Differentiated Services May 2002
When considering a label entry corresponding to an incoming E-LSP for Incoming PHB Determination, the LSR:
When considering a label entry corresponding to an incoming E-LSP for Incoming PHB Determination, the 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.
- 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.
- determines the incoming PHB by looking up the EXP field of the
considered label entry in the `EXP-->PHB mapping' table.
- determines the incoming PHB by looking up the EXP field of the considered label entry in the `EXP-->PHB mapping' table.
3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP
3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP
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.
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.
3.4.1 `PHB-->EXP mapping'
3.4.1 `PHB-->EXP mapping'
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.
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.
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.
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.
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'.
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'.
3.4.2 `PHB-->CLP mapping'
3.4.2 `PHB-->CLP mapping'
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:
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:
- 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.
- 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.
Le Faucheur, et. al. Standards Track [Page 24] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 24] RFC 3270 MPLS Support of Differentiated Services May 2002
For example if the outgoing label corresponds to an LSP supporting the AF1 PSC, then the `PHB-->CLP mapping' may be populated with:
For example if the outgoing label corresponds to an LSP supporting the AF1 PSC, then the `PHB-->CLP mapping' may be populated with:
PHB CLP Field
PHB CLP Field
AF11 ----> 0
AF12 ----> 1
AF13 ----> 1
EF ----> 0
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'.
Notice that in this case the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->CLP mapping'.
3.4.2.1 Default `PHB-->CLP mapping'
3.4.2.1 Default `PHB-->CLP mapping'
PHB CLP Bit
PHB CLP Bit
DF ----> 0
CSn ----> 0
AFn1 ----> 0
AFn2 ----> 1
AFn3 ----> 1
EF ----> 0
DF ----> 0 CSn ----> 0 AFn1 ----> 0 AFn2 ----> 1 AFn3 ----> 1 EF ----> 0
3.4.3 `PHB-->DE mapping'
3.4.3 `PHB-->DE mapping'
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:
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:
- 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.
- 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.
Notice that in this case the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'.
Notice that in this case the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'.
Le Faucheur, et. al. Standards Track [Page 25] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 25] RFC 3270 MPLS Support of Differentiated Services May 2002
3.4.3.1 `Default PHB-->DE mapping'
3.4.3.1 `Default PHB-->DE mapping'
PHB DE Bit
PHB DE Bit
DF ----> 0
CSn ----> 0
AFn1 ----> 0
AFn2 ----> 1
AFn3 ----> 1
EF ----> 0
DF ----> 0 CSn ----> 0 AFn1 ----> 0 AFn2 ----> 1 AFn3 ----> 1 EF ----> 0
3.4.4 `PHB-->802.1 mapping'
3.4.4 `PHB-->802.1 mapping'
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:
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:
- 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.
- 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.
Notice that the `Set of PHB-->Encaps mappings' then contains both a `PHB-->EXP mapping' and a `PHB-->802.1 mapping'.
Notice that the `Set of PHB-->Encaps mappings' then contains both a `PHB-->EXP mapping' and a `PHB-->802.1 mapping'.
3.4.4.1 Preconfigured `PHB-->802.1 Mapping'
3.4.4.1 Preconfigured `PHB-->802.1 Mapping'
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.
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.
3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing
E-LSP
3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing E-LSP
This section defines how to encode Diff-Serv information into the MPLS encapsulation Layer for a given transmitted label entry corresponding to an outgoing E-LSP. This requires that the `Set of PHB-->Encaps mappings' be populated as defined in section 3.4.
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.
The LSR first determines the `Set of PHB-->Encaps mappings' of the Diff-Serv Context associated with the corresponding label in the NHLFE.
The LSR first determines the `Set of PHB-->Encaps mappings' of the Diff-Serv Context associated with the corresponding label in the NHLFE.
Le Faucheur, et. al. Standards Track [Page 26] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 26] RFC 3270 MPLS Support of Differentiated Services May 2002
3.5.1 `PHB-->EXP mapping'
3.5.1 `PHB-->EXP mapping'
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->EXP mapping', then the LSR:
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->EXP mapping', then the 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.
- 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.
3.5.2 `PHB-->CLP mapping'
3.5.2 `PHB-->CLP mapping'
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->CLP mapping', then the LSR:
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->CLP mapping', then the 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.
- 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.
3.5.3 `PHB-->DE mapping'
3.5.3 `PHB-->DE mapping'
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->DE mapping', then the LSR:
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->DE mapping', then the 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.
- 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.
3.5.4 `PHB-->802.1 mapping'
3.5.4 `PHB-->802.1 mapping'
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->802.1 mapping', then the LSR:
If the `Set of PHB-->Encaps mappings' contains a mapping of the form `PHB-->802.1 mapping', then the 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.
- 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.
3.6 E-LSP Merging
3.6 E-LSP Merging
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:
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:
E-LSPs can only be merged into one LSP if they support the exact
same set of BAs.
E-LSPs can only be merged into one LSP if they support the exact same set of BAs.
Le Faucheur, et. al. Standards Track [Page 27] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 27] RFC 3270 MPLS Support of Differentiated Services May 2002
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.
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.
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.
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.
4. Detailed Operation of L-LSPs
4. Detailed Operation of L-LSPs
4.1 L-LSP Definition
4.1 L-LSP Definition
L-LSPs are defined in section 1.3.
L-LSPs are defined in section 1.3.
4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP
4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP
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.
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.
4.2.1 `EXP-->PHB mapping'
4.2.1 `EXP-->PHB mapping'
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:
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:
- it is actually a `EXP-->PHB mapping'
- it is actually a `EXP-->PHB mapping'
- 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.
- 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.
For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with:
For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' will be populated with:
EXP Field PHB
EXP Field PHB
001 ----> AF11
010 ----> AF12
011 ----> AF13
001 ----> AF11 010 ----> AF12 011 ----> AF13
Le Faucheur, et. al. Standards Track [Page 28] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 28] RFC 3270 MPLS Support of Differentiated Services May 2002
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.
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.
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:
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:
- 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.
- 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.
- 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.
- 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.
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.
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.
4.2.1.1 Mandatory `EXP/PSC --> PHB mapping'
4.2.1.1 Mandatory `EXP/PSC --> PHB mapping'
EXP Field PSC PHB
EXP Field PSC PHB
000 DF ----> DF
000 CSn ----> CSn
001 AFn ----> AFn1
010 AFn ----> AFn2
011 AFn ----> AFn3
000 EF ----> EF
000 DF ----> DF 000 CSn ----> CSn 001 AFn ----> AFn1 010 AFn ----> AFn2 011 AFn ----> AFn3 000 EF ----> EF
4.2.2 `CLP-->PHB mapping'
4.2.2 `CLP-->PHB mapping'
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:
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:
- it is actually a `CLP-->PHB mapping'
- it is actually a `CLP-->PHB mapping'
- 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.
- 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.
Le Faucheur, et. al. Standards Track [Page 29] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 29] RFC 3270 MPLS Support of Differentiated Services May 2002
For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' should be populated with:
For example if the incoming label corresponds to an L-LSP supporting the AF1 PSC, then the `Encaps-->PHB mapping' should be populated with:
CLP Field PHB
CLP Field PHB
0 ----> AF11
1 ----> AF12
0 ----> AF11 1 ----> AF12
4.2.2.1 Default `CLP/PSC --> PHB mapping'
4.2.2.1 Default `CLP/PSC --> PHB mapping'
CLP Bit PSC PHB
CLP Bit PSC PHB
0 DF ----> DF
0 CSn ----> CSn
0 AFn ----> AFn1
1 AFn ----> AFn2
0 EF ----> EF
0 DF ----> DF 0 CSn ----> CSn 0 AFn ----> AFn1 1 AFn ----> AFn2 0 EF ----> EF
4.2.3 `DE-->PHB mapping'
4.2.3 `DE-->PHB mapping'
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:
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:
- it is actually a `DE-->PHB mapping'
- it is actually a `DE-->PHB mapping'
- 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.
- 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.
4.2.3.1 Default `DE/PSC --> PHB mapping'
4.2.3.1 Default `DE/PSC --> PHB mapping'
DE Bit PSC PHB
DE Bit PSC PHB
0 DF ----> DF
0 CSn ----> CSn
0 AFn ----> AFn1
1 AFn ----> AFn2
0 EF ----> EF
0 DF ----> DF 0 CSn ----> CSn 0 AFn ----> AFn1 1 AFn ----> AFn2 0 EF ----> EF
4.3 Incoming PHB Determination On Incoming L-LSP
4.3 Incoming PHB Determination On Incoming L-LSP
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.
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.
Le Faucheur, et. al. Standards Track [Page 30] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 30] RFC 3270 MPLS Support of Differentiated Services May 2002
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.
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.
4.3.1 `EXP-->PHB mapping'
4.3.1 `EXP-->PHB mapping'
If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping', then the LSR:
If the `Encaps-->PHB mapping' is of the form `EXP-->PHB mapping', then the LSR:
- determines the incoming PHB by looking at the EXP field of the
considered label entry and using the `EXP-->PHB mapping'.
- determines the incoming PHB by looking at the EXP field of the considered label entry and using the `EXP-->PHB mapping'.
4.3.2 `CLP-->PHB mapping'
4.3.2 `CLP-->PHB mapping'
If the `Encaps-->PHB mapping' is of the form `CLP-->PHB mapping', then the LSR:
If the `Encaps-->PHB mapping' is of the form `CLP-->PHB mapping', then the LSR:
- determines the incoming PHB by looking at the CLP field of the
ATM Layer encapsulation and using the `CLP-->PHB mapping'.
- determines the incoming PHB by looking at the CLP field of the ATM Layer encapsulation and using the `CLP-->PHB mapping'.
4.3.3 `DE-->PHB mapping'
4.3.3 `DE-->PHB mapping'
If the `Encaps-->PHB mapping' is of the form `DE-->PHB mapping', then the LSR:
If the `Encaps-->PHB mapping' is of the form `DE-->PHB mapping', then the LSR:
- determines the incoming PHB by looking at the DE field of the
Frame Relay encapsulation and by using the `DE-->PHB mapping'.
- determines the incoming PHB by looking at the DE field of the Frame Relay encapsulation and by using the `DE-->PHB mapping'.
4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing L-LSP
4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing L-LSP
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.
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.
4.4.1 `PHB-->EXP mapping'
4.4.1 `PHB-->EXP mapping'
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:
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:
- 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.
- 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.
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':
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':
Le Faucheur, et. al. Standards Track [Page 31] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 31] RFC 3270 MPLS Support of Differentiated Services May 2002
PHB EXP Field
PHB EXP Field
AF11 ----> 001
AF12 ----> 010
AF13 ----> 011
AF11 ----> 001 AF12 ----> 010 AF13 ----> 011
4.4.1.1 Mandatory `PHB-->EXP mapping'
4.4.1.1 Mandatory `PHB-->EXP mapping'
PHB EXP Field
PHB EXP Field
DF ----> 000
CSn ----> 000
AFn1 ----> 001
AFn2 ----> 010
AFn3 ----> 011
EF ----> 000
DF ----> 000 CSn ----> 000 AFn1 ----> 001 AFn2 ----> 010 AFn3 ----> 011 EF ----> 000
4.4.2 `PHB-->CLP mapping'
4.4.2 `PHB-->CLP mapping'
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.
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.
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.
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.
If the L-LSP is egressing over an LC-ATM interface, the `PHB-->CLP mapping' is populated in the following way:
If the L-LSP is egressing over an LC-ATM interface, the `PHB-->CLP mapping' is populated in the following way:
- 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.
- 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.
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'.
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'.
Le Faucheur, et. al. Standards Track [Page 32] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 32] RFC 3270 MPLS Support of Differentiated Services May 2002
4.4.3 `PHB-->DE mapping'
4.4.3 `PHB-->DE mapping'
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.
'1PHB、>DEが写像されて、L-LSPであるなら、Frame Relayの上でegressingするのは、インタフェース(すなわち、それはLC-FRインタフェースにパケットを送るLSRであるかFrame Relayインタフェースでは、どれがラベルの切り換えでないかは制御された)です。'これに関する'PHBをセットしてください-->Encapsマッピング'という出発しているL-LSPに加えられます。
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.
>DEが写像されて、L-LSPであるなら、FRの上でegressingするのは、ラベルの切り換えが制御されました、'PHBということでないインタフェースです。'セクション3.4.3に従って、居住されます。
If the L-LSP is egressing over an LC-FR interface, the `PHB-->DE mapping' is populated in the following way:
>DEが写像されて、L-LSPがLC-FRインタフェース、'PHBの上でegressingしている、'以下の方法で居住されます:
- 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.
- 'セクション3.4.3で.1に定義されて、>DEが写像される場合、それは、このLSPでサポートされたPSCの機能であり、このPSCにDefault'PHBから関連マッピングエントリーを使用するべきです。
Notice that if the LSR is an Edge-LSR supporting an L-LSP egressing over a LC-FR interface, then the `Set of PHB-->Encaps mappings' contains both a `PHB-->EXP mapping' and a `PHB-->DE mapping'. If the LSR is a FR-LSR supporting an L-LSP, then the `Set of PHB-->Encaps mappings' only contains a `PHB-->DE mapping'.
LSRがPHBについてLC-FRインタフェースの上のL-LSP egressing、当時の'セットを支えるEdge-LSRであるならそれに注意してください--、>Encapsマッピング、'、両方を含んでいる、'PHB(''PHBを写像する>EXP)>DEマッピング'。 LSRがL-LSPを支持するFR-LSRであるなら、そして、'PHBをセットしてください-->DEが写像されて、>Encapsマッピングだけが'PHBを含んでいます'。
4.4.4 `PHB-->802.1 mapping'
4.4.4 'PHB-->802.1マッピング、'
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.
>802.1が写像されて、LSPであるなら、LANインタフェースの上で802.1Traffic Classesが支持されます、[IEEE_802.1]で定義されるように、そしてそれの倍数でegressingするのは、'1PHBです。'セクション3.4.4に従って、加えられます。
4.5 Encoding Diff-Serv Information into Encapsulation Layer on Outgoing
L-LSP
4.5 出発しているL-LSPでデフ-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カプセル化LayerにDiff-Serv情報をコード化する方法を定義します。 'PHBをセットしてください-->Encapsマッピング'。これがそれを必要とする、定義されるとして、セクション4.4では、居住されます。
The LSR first determines the `Set of PHB-->Encaps mappings' of the Diff-Serv Context associated with the corresponding label in the NHLFE and then performs corresponding encoding as specified in sections 3.5.1, 3.5.2, 3.5.3 and 3.5.4.
'PHBをセットしてください-->Encapsマッピング'。そして、LSRが最初に決定する、交際したDiff-Serv ContextではNHLFEとその時の対応するラベルがセクション3.5.1、3.5で.2を指定するので対応するコード化を実行する、3.5、.3、3.5 .4。
Le Faucheur, et. al. Standards Track [Page 33] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[33ページ]。
4.6 L-LSP Merging
4.6 L-LSP合併
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ドメインでは、1LSRの1LSPに2LSPsを合併できます。 L-LSPsは以下の条件でのLSP Mergingと互換性があります:
L-LSPs can only be merged into one L-LSP if they support the same
PSC.
彼らが同じPSCを支持するなら、1L-LSPにしかL-LSPsを合併できません。
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.
上記のマージ状態はLSRsによって励行されなければなりません、ラベルセットアップにおける明白な照合でそんなに同じPSCは合併しているLSPsで支持されます。
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-LSPsが合併するとき、マージポイントのPSC川下に利用可能な帯域幅が合併している交通の合計を運ぶために十分でなければならないことに注意してください。 これはEF交通の場合で特に重要です。 複数の方法(例えば食糧を供給することを通して、帯域幅シグナリングと明白な入場コントロールで)でこれを確実にすることができます。
5. RSVP Extension for Diff-Serv Support
5. デフ-ServサポートのためのRSVP拡張子
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ネットワークにLSPsを設立するために拡大をRSVPと定義します。 このセクションはRSVPに拡大を指定します、MPLSネットワークでDifferentiated Servicesを支持するLSPsを証明するために[RSVP_MPLS_TE]で定義されたものを超えて。
5.1 Diff-Serv related RSVP Messages Format
5.1 デフ-ServはRSVP Messages Formatを関係づけました。
One new RSVP Object is defined in this document: the DIFFSERV Object. Detailed description of this Object is provided below. This new Object is applicable to Path messages. This specification only defines the use of the DIFFSERV Object in Path messages used to establish LSP Tunnels in accordance with [RSVP_MPLS_TE] and thus containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 and containing a LABEL_REQUEST object.
1新しいRSVP Objectが本書では定義されます: DIFFSERVは反対します。 このObjectの詳述を以下に提供します。 この新しいObjectはPathメッセージに適切です。 この仕様は[RSVP_MPLS_TE]に従ってLSP Tunnelsを設立するのにおいて中古のPathメッセージと、その結果、LSP_TUNNEL_IPv4と等しいC-タイプがあるSession Objectを含んでいて、LABEL_REQUEST物を含むことにおけるDIFFSERV Objectの使用を定義するだけです。
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.
また、LSP Tunnelsの設立のサポートのためにRSVPを通して[RSVP_MPLS_TE]で定義された制限もDiff-Servを支持しているLSP Tunnelsの設立に適切です: 例えば、ユニキャストだけLSPsは支持されます、そして、さらなる研究にはMulticast LSPsがあります。
This new DIFFSERV object is optional with respect to RSVP so that general RSVP implementations not concerned with MPLS LSP set up do not have to support this object.
この新しいDIFFSERV物がRSVPに関して任意であるので、セットアップされるMPLS LSPに関しない一般的なRSVP実現はこの物を支える必要はありません。
Le Faucheur, et. al. Standards Track [Page 34] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[34ページ]。
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.
LSP Tunnelsのサポートに、DIFFSERV Objectは[RSVP_MPLS_TE]で定義されるように任意です。 あらかじめ設定された'EXP<を使用することでE-LSPsを支持するDiff-ServのできるLSR--'この仕様5月のサポートに従ってDIFFSERV Objectを写像する>PHB。 >PHBが写像して、aを使用することでE-LSPsを支持するDiff-ServのできるLSRは'EXP<に合図しました。'この仕様に従って、DIFFSERV Objectを支持しなければなりません。 この仕様に従ってL-LSPsを支持するDiff-ServのできるLSRはDIFFSERV Objectを支持しなければなりません。
5.1.1 Path Message Format
5.1.1 経路メッセージ・フォーマット
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> ]
<経路メッセージ>:、:= <一般的なヘッダー>[<保全>]<><RSVP_ホップ><時間_セッションは>[<の明白な_ルート>]<ラベル_要求>[<セッション_属性>][<DIFFSERV>][<方針_データ>…]を評価します。 [<送付者記述子>]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
<送付者記述子>:、:= _<送付者_テンプレート><送付者TSPEC>[<ADSPEC>][<記録_ルート>]
5.2 DIFFSERV Object
5.2 DIFFSERVは反対します。
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物です。
Le Faucheur, et. al. Standards Track [Page 35] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[35ページ]。
5.2.1. DIFFSERV object for an E-LSP:
5.2.1. DIFFSERVはE-LSPのために反対します:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| MAPnb| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 地図(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // ... // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 地図(MAPnb)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 28 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
予約される: Thisがさばく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: DIFFSERV ObjectにMAPエントリーの数を含んでいる4ビットのIndicates。 0〜8までどんな値にもこれを設定できます。
MAP : 32 bits
Each MAP entry defines the mapping between one EXP field value
and one PHB. The MAP entry has the following format:
以下を写像してください。 32ビットのEach MAPエントリーは1つのEXP分野価値と1PHBの間のマッピングを定義します。 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| EXP| PHBID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 13 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
予約される: Thisがさばく13ビットは予約されています。 それをトランスミッションのときにゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
EXP : 3 bits
This field contains the value of the EXP field for the
`EXP<-->PHB mapping' defined in this MAP entry.
EXP: Thisがさばく3ビットは'EXP<のためのEXP分野の値を含んでいます--'このMAPエントリーで定義されて、写像する>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: Thisがさばく16ビットは'EXP<のためのPHBのPHBIDを含んでいます--'このMAPエントリーで定義されて、写像する>PHB。 PHBIDは[PHBID]で指定されるようにコード化されます。
Le Faucheur, et. al. Standards Track [Page 36] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[36ページ]。
5.2.2 DIFFSERV object for an L-LSP:
5.2.2 DIFFSERVはL-LSPのために反対します:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| PSC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 16 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
予約される: Thisがさばく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: LSPによって支持されるように、16ビット、PSCはPHB Scheduling Classを示します。 PSCは[PHBID]で指定されるようにコード化されます。
5.3 Handling DIFFSERV Object
5.3 取り扱いDIFFSERVは反対します。
To establish an LSP tunnel with RSVP, the sender creates a Path message with a session type of LSP_Tunnel_IPv4 and with a LABEL_REQUEST object as per [RSVP_MPLS_TE].
RSVPと共にLSPトンネルを証明するために、送付者は[RSVP_MPLS_TE]に従ってLSP_Tunnel_IPv4のセッションタイプとLABEL_REQUEST物でPathメッセージを作成します。
To establish an E-LSP tunnel with RSVP, which uses the Preconfigured `EXP<-->PHB mapping', the sender creates a Path message:
'>PHBが写像して、Preconfigured'EXP<を使用するRSVPと共にE-LSPトンネルを証明するために、送付者は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:
'>PHBが写像して、Preconfigured'EXP<を使用するRSVPと共にE-LSPトンネルを証明するために、あるいはまた、送付者は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.
- MAPエントリーを全く含まないで、E-LSPのためにDIFFSERVと共に反対してください。
To establish an E-LSP tunnel with RSVP, which uses a signaled `EXP<-->PHB mapping', the sender creates a Path message:
'>PHBが写像して、合図された'EXP<を使用するRSVPと共にE-LSPトンネルを証明するために、送付者はPathメッセージを作成します:
- with a session type of LSP_Tunnel_IPv4,
- LSP_Tunnel_IPv4のセッションタイプで
Le Faucheur, et. al. Standards Track [Page 37] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[37ページ]。
- 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.
- それぞれのEXP値がこのE-LSPで支持されるために1つのMAPエントリーを含んで、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 Scheduling Class(PSC)を含むL-LSPのためにDIFFSERVと共に反対してください。
If a path message contains multiple DIFFSERV objects, only the first one is meaningful; subsequent DIFFSERV object(s) must be ignored and not forwarded.
経路メッセージが複数のDIFFSERV物を含んでいるなら、最初の方だけが重要です。 その後のDIFFSERV物を無視して、進めてはいけません。
Each LSR along the path records the DIFFSERV object, when present, in its path state block.
経路州のブロックに存在しているとき、経路に沿った各LSRはDIFFSERV物を記録します。
If a DIFFSERV object is not present in the Path message, the LSR SHOULD interpret this as a request for an E-LSP using the Preconfigured `EXP<-->PHB mapping'. However, for backward compatibility purposes, with other non-Diff-Serv Quality of Service options allowed by [RSVP_MPLS_TE] such as Integrated Services Controlled Load or Guaranteed Services, the LSR MAY support a configurable "override option". When this "override option" is configured, the LSR interprets a path message without a Diff-Serv object as a request for an LSP with such non-Diff-Serv Quality of Service.
>PHBが写像して、DIFFSERV物がPathメッセージに存在していないなら、LSR SHOULDがE-LSPを求める要求としてPreconfigured'EXP<を使用することでこれを解釈する、' しかしながら、後方の互換性目的のために、Serviceオプションの他の非デフのServ QualityがIntegrated Services Controlled LoadかGuaranteed Servicesとして[RSVP_MPLS_TE]そのようなものによって許容されている状態で、LSR MAYは構成可能な「オーバーライドオプション」を支持します。 この「オーバーライドオプション」が構成されるとき、LSRはServiceのそのような非デフのServ QualityとLSPを求める要求としてDiff-Serv物なしで経路メッセージを解釈します。
If a DIFFSERV object for an E-LSP containing no MAP entry is present in the Path message, the LSR MUST interpret this as a request for an E-LSP using the Preconfigured `EXP<-->PHB mapping'. In particular, this allows an LSR with the "override option" configured to support E-LSPs with Preconfigured `EXP<-->PHB mapping', simultaneously with LSPs with non-Diff-Serv Quality of Service.
>PHBが写像して、MAPエントリーを全く含まないE-LSPのためのDIFFSERV物がPathメッセージに存在しているなら、LSR MUSTがE-LSPを求める要求としてPreconfigured'EXP<を使用することでこれを解釈する、' >PHBが写像して、特に、これが「オーバーライドオプション」がPreconfigured'EXP<でE-LSPsを支持するために構成されていることのLSRを許容する、'、同時である、Serviceの非デフのServ QualityとLSPsと共に。
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が写像して、少なくともあるMAPエントリーを含むE-LSPのためのDIFFSERV物がPathメッセージに存在しているなら、LSR MUSTが合図された'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 MUSTはL-LSPを求める要求としてこれを解釈します。
Le Faucheur, et. al. Standards Track [Page 38] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[38ページ]。
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:
ラベル要求を受け入れて、ラベルを割り当てると仮定する場合、Diff-Serv LSRs(送付者、目的地、中間的ノード)は仮定しなければなりません:
- update the Diff-Serv Context associated with the established LSPs
in their ILM/FTN as specified in previous sections (incoming and
outgoing label),
- 前項(送受信のラベル)の指定されるとして彼らのILM/FTNの確立したLSPsに関連しているDiff-Serv Contextをアップデートしてください。
- 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物とそれを認識するLSRはDIFFSERV物を含みますが、LABEL_REQUEST物を含まないか、またはLSP_Tunnel_IPv4のセッションタイプがない経路メッセージを受け取って、エラーコード'デフ-Serv Error'と'予期していなかったDIFFSERVは反対する'誤り値をもっている送付者に向かってPathErrを送ります。 ものは以下でセクション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.
MAPエントリーのE-LSPのためにDIFFSERV物でPathメッセージを受け取るLSRはエラーコード'デフ-Serv Error'と'サポートされないPHB'の誤り値をもっている送付者に向かってPathErrを送ります。DIFFSERV物を認識しますが、LSPは1以上でコード化された特定の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がE-LSPのためにDIFFSERV物でPathメッセージを受け取って、どれが、DIFFSERV物を認識しますが、それを決定するか。合図された'EXP<('無効であり、エラーコード'デフ-Serv Errorをもっている送付者に向かってPathErrを送る'という>PHBマッピングとInvalid'EXP<の誤り値)>PHBマッピング'。 ものは以下でセクション5.5で定義されます。 'EXP<--'E-LSPが無効であるのでDIFFSERV Objectで合図されて、写像する>PHB、いつ:
- 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値が1つ以上のMAPエントリーに現れる。
- the PHBID encoding is invalid.
- PHBIDコード化は無効です。
Le Faucheur, et. al. Standards Track [Page 39] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[39ページ]。
An LSR receiving a Path message with the DIFFSERV object for L-LSP, which recognizes the DIFFSERV object but does not support the particular PSC encoded in the PSC field, sends a PathErr towards the sender with the error code `Diff-Serv Error' and an error value of `Unsupported PSC'. Those are defined below in section 5.5.
L-LSPのためにDIFFSERV物でPathメッセージを受け取るLSRはエラーコード'デフ-Serv Error'と'サポートされないPSC'の誤り値をもっている送付者に向かってPathErrを送ります。DIFFSERV物を認識しますが、L-LSPはPSC分野でコード化された特定の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物でPathメッセージを受け取って、どれが、DIFFSERV物にもかかわらず、それが1LSP Diff-Servあたりの必要な文脈を割り当てることができないと認めるかがエラーコード「デフ-Serv誤り」と誤り値の「1LSPあたりの文脈割り振りの失敗」があるPathErrを送ります。 ものは以下でセクション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]に従って(入場コントロールで拒絶された予約、例えば、ラベルを関連づけることができません、)。
5.4 Non-support of the DIFFSERV Object
5.4 DIFFSERV物の非サポート
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.
手順によると、Class-ヌムが反応させなければならないDIFFSERV物を認識しないLSRは、未知のClass-ヌムへの[RSVP]でだれの形式が0bbbbbbbであるかを指定しました、すなわち、それはエラーコード'未知の物のクラス'がある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物のClass-ヌムを認識しますが、DIFFSERV物のC-タイプを見分けないで、手順によると、振る舞わなければならないLSRは未知のC-タイプのための[RSVP]で指定しました、すなわち、それはエラーコード'未知の物のC-タイプ'で送付者に向かってPathErrを送らなければなりません。
In both situations, this causes the path set-up to fail. The sender should notify management that a L-LSP cannot be established and should possibly take action to retry LSP establishment without the DIFFSERV object (e.g., attempt to use E-LSPs with Preconfigured `EXP<-->PHB mapping' as a fall-back strategy).
両方の状況で、これは経路セットアップに失敗されます。 送付者は、L-LSPを設立できないように管理に通知するべきであり、DIFFSERV物なしでLSP設立を再試行するためにことによると行動を取るべきです。(例えば、Preconfigured'EXP<とE-LSPsを使用するのを試みてください--、>PHBマッピング、'、後退戦略)
5.5 Error Codes For Diff-Serv
5.5 デフ-Servのための誤りコード
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.
上で説明された手順で、'デフ-Serv Error'としてある誤りを報告しなければなりません。 'デフ-Serv Error'エラーコードの値は27です。
Le Faucheur, et. al. Standards Track [Page 40] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[40ページ]。
The following defines error values for the Diff-Serv Error:
以下はDiff-Serv Errorのために誤り値を定義します:
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物の2Unsupported PHB3Invalid'EXP<--'4Unsupported PSC5Per-LSP文脈割り振りの失敗を写像する>PHB
5.6 Intserv Service Type
5.6 Intservサービスタイプ
Both E-LSPs and L-LSPs can be established with or without bandwidth reservation.
帯域幅の予約のあるなしにかかわらずE-LSPsとL-LSPsの両方を設立できます。
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.
帯域幅の予約でE-LSPかL-LSPを証明するために[RSVP_MPLS_TE]で指定されるように、Int-ServのControlled Loadサービス(または、ことによるとGuaranteed Service)は使用されています、そして、帯域幅は経路(それぞれResv)メッセージのSENDER_TSPEC(それぞれFLOWSPEC)で合図されます。
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]で指定されたNull Serviceは使用されています。
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-LSPsとL-LSPsの使用法を定義することに注意してください。 サービス(制御Load、Null Service、Guaranteed Service)と予約が帯域幅の予約のあるなしにかかわらずあることにかかわらずIntservにかかわらず、E-LSPsとL-LSPsはDiff- Servサービスのサポートのためにここで定義されます。 この仕様の範囲の外にMPLS Diff-Serv背骨の上のInt-Servサービスのサポートがあります。
Note also that this specification does not concern itself with the DCLASS object defined in [DCLASS], since this object conveys information on DSCP values, which are not relevant inside the MPLS network.
また、DCLASS物が[DCLASS]で定義されている状態でこの仕様がタッチしないことに注意してください、この物がDSCP値(MPLSネットワークの中で関連していない)で情報を伝達するので。
6. LDP Extensions for Diff-Serv Support
6. デフ-Servサポートのための自由民主党の拡大
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構造はただ一つのラベル分配プロトコルを仮定しません。 [自由民主党]はLabel Distributionプロトコルを定義します、そして、ラベルの設立のための用法はMPLSネットワークで経路(LSPs)を切り換えました。 このセクションは、MPLSネットワークでDifferentiated Servicesを支持するLSPsを証明するために自由民主党に拡大を指定します。
Le Faucheur, et. al. Standards Track [Page 41] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[41ページ]。
One new LDP TLV is defined in this document:
1新しい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は自由民主党に関して任意です。 Preconfigured'EXP<を使用するE-LSPsを支持するDiff-ServのできるLSR--'この仕様5月のサポートに従ってDiff-Serv TLVを写像する>PHB。 E-LSPsを支持して、>PHBが写像して、どれが合図された'EXP<を使用するか。Diff-ServのできるLSR、'この仕様に従って、Diff-Serv TLVを支持しなければなりません。 この仕様に従ってL-LSPsを支持するDiff-ServのできるLSRはDiff-Serv TLVを支持しなければなりません。
6.1 Diff-Serv TLV
6.1 デフ-Serv TLV
The Diff-Serv TLV has the following formats:
Diff-Serv TLVには、以下の形式があります:
Diff-Serv TLV for an E-LSP:
電子LSPのためのデフ-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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
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| デフ-Serv(0×0901)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| 予約されます。| MAPnb| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 地図(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 地図(MAPnb)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T:1 bit
LSP Type. This is set to 0 for an E-LSP
T: 1ビットのLSP Type。 これはE-LSPのために0に設定されます。
Reserved : 27 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
予約される: Thisがさばく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: DIFFSERV ObjectにMAPエントリーの数を含んでいる4ビットのIndicates。 1〜8までどんな値にもこれを設定できます。
Le Faucheur, et. al. Standards Track [Page 42] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[42ページ]。
MAP : 32 bits
Each MAP entry defines the mapping between one EXP field value
and one PHB. The MAP entry has the following format:
以下を写像してください。 32ビットのEach MAPエントリーは1つのEXP分野価値と1PHBの間のマッピングを定義します。 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| EXP| PHBID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 13 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
予約される: Thisがさばく13ビットは予約されています。 それをトランスミッションのときにゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
EXP : 3 bits
This field contains the value of the EXP field for the
`EXP<-->PHB mapping' defined in this MAP entry.
EXP: Thisがさばく3ビットは'EXP<のためのEXP分野の値を含んでいます--'このMAPエントリーで定義されて、写像する>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: Thisがさばく16ビットは'EXP<のためのPHBのPHBIDを含んでいます--'このMAPエントリーで定義されて、写像する>PHB。 PHBIDは[PHBID]で指定されるようにコード化されます。
Diff-Serv TLV for an L-LSP:
L-LSPのためのデフ-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| =PSC(0×0901)をタイプしてください。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| 予約されます。| PSC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T:1 bit
LSP Type. This is set to 1 for an L-LSP
T: 1ビットのLSP Type。 これはL-LSPのために1に設定されます。
Reserved : 15 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
予約される: Thisがさばく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: LSPによって支持されるように、16ビット、PSCはPHB Scheduling Classを示します。 PSCは[PHBID]で指定されるようにコード化されます。
Le Faucheur, et. al. Standards Track [Page 43] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[43ページ]。
6.2 Diff-Serv Status Code Values
6.2 デフ-Serv状態コード値
The following values are defined for the Status Code field of the Status TLV:
以下の値はStatus TLVのStatus Code分野と定義されます:
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 TLV0 0×01000001Unsupported PHB0 0×01000002Invalid'EXP<--'0 0×01000003Unsupported PSC0 0×01000004Per-LSP文脈割り振りの失敗0 0×01000005を写像する>PHB
6.3 Diff-Serv Related LDP Messages
6.3 デフ-Servは自由民主党メッセージについて話しました。
6.3.1 Label Request Message
6.3.1 ラベル要求メッセージ
The format of the Label Request message is extended as follows, to optionally include the Diff-Serv TLV:
Label Requestメッセージの形式は任意に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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ラベル要求(0×0401)| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | デフ-Serv TLV(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Faucheur, et. al. Standards Track [Page 44] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 44] RFC 3270 MPLS Support of Differentiated Services May 2002
6.3.2 Label Mapping Message
6.3.2 Label Mapping Message
The format of the Label Mapping message is extended as follows, to optionally include the Diff-Serv TLV:
The format of the Label Mapping message is extended as follows, to optionally include the 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.3 Label Release Message
6.3.3 Label Release Message
The format of the Label Release message is extended as follows, to optionally include the Status TLV:
The format of the Label Release message is extended as follows, to optionally include the Status 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Faucheur, et. al. Standards Track [Page 45] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 45] RFC 3270 MPLS Support of Differentiated Services May 2002
6.3.4 Notification Message
6.3.4 Notification Message
The format of the Notification message is extended as follows, to optionally include the Diff-Serv TLV:
The format of the Notification message is extended as follows, to optionally include the 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.4 Handling of the Diff-Serv TLV
6.4 Handling of the Diff-Serv TLV
6.4.1 Handling of the Diff-Serv TLV in Downstream Unsolicited Mode
6.4.1 Handling of the Diff-Serv TLV in Downstream Unsolicited Mode
This section describes operations when the Downstream Unsolicited Mode is used.
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.
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.
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.
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.
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.
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.
Assuming the label set-up is successful, the downstream and upstream LSRs must:
Assuming the label set-up is successful, the downstream and upstream LSRs must:
- update the Diff-Serv Context associated with the established LSPs
in their ILM/FTN as specified in previous sections (incoming and
outgoing label),
- update the Diff-Serv Context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label),
Le Faucheur, et. al. Standards Track [Page 46] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 46] RFC 3270 MPLS Support of Differentiated Services May 2002
- install the required Diff-Serv forwarding treatment (scheduling
and dropping behavior) for this NHLFE (outgoing label).
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
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).
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).
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'.
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'.
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:
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:
- the MAPnb field is not within the range 1 to 8, or
- the MAPnb field is not within the range 1 to 8, or
- a given EXP value appears in more than one MAP entry, or
- a given EXP value appears in more than one MAP entry, or
- the PHBID encoding is invalid
- the PHBID encoding is invalid
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'.
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'.
6.4.2 Handling of the Diff-Serv TLV in Downstream on Demand Mode
6.4.2 Handling of the Diff-Serv TLV in Downstream on Demand Mode
This section describes operations when the Downstream on Demand Mode is used.
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.
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.
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.
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.
Le Faucheur, et. al. Standards Track [Page 47] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 47] RFC 3270 MPLS Support of Differentiated Services May 2002
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.
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.
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:
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:
- update the Diff-Serv Context associated with the established LSPs
in their ILM/FTN as specified in previous sections (incoming and
outgoing label),
- update the Diff-Serv Context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label),
- install the required Diff-Serv forwarding treatment (scheduling
and dropping behavior) for this NHLFE (outgoing label).
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
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'.
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'.
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).
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).
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'.
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'.
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:
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:
- the MAPnb field is not within the range 1 to 8, or
- the MAPnb field is not within the range 1 to 8, or
- a given EXP value appears in more than one MAP entry, or
- a given EXP value appears in more than one MAP entry, or
- the PHBID encoding is invalid
- the PHBID encoding is invalid
Le Faucheur, et. al. Standards Track [Page 48] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 48] RFC 3270 MPLS Support of Differentiated Services May 2002
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'.
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'.
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'.
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'.
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.
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.
6.5 Non-Handling of the Diff-Serv TLV
6.5 Non-Handling of the 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.
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.
6.6 Bandwidth Information
6.6 Bandwidth Information
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].
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].
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and Non-LC-FR Interfaces
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and Non-LC-FR Interfaces
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.
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.
On these interfaces, this specification allows any of the following LSP combinations per FEC:
On these interfaces, this specification allows any of the following LSP combinations per FEC:
Le Faucheur, et. al. Standards Track [Page 49] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 49] RFC 3270 MPLS Support of Differentiated Services May 2002
- Zero or any number of E-LSP, and
- Zero or any number of E-LSP, and
- Zero or any number of L-LSPs.
- Zero or any number of L-LSPs.
A Diff-Serv capable LSR MUST support E-LSPs which use preconfigured `EXP<-->PHB mapping' over these interfaces.
A Diff-Serv capable LSR MUST support E-LSPs which use preconfigured `EXP<-->PHB mapping' over these interfaces.
A Diff-Serv capable LSR MAY support E-LSPs which use signaled `EXP<-->PHB mapping' and L-LSPs over these interfaces.
A Diff-Serv capable LSR MAY support E-LSPs which use signaled `EXP<-->PHB mapping' and L-LSPs over these interfaces.
8. MPLS Support of Diff-Serv over LC-ATM Interfaces
8. MPLS Support of Diff-Serv over LC-ATM Interfaces
This section describes the specific operations required for MPLS support of Diff-Serv over label switching controlled ATM (LC-ATM) interfaces.
This section describes the specific operations required for MPLS support of Diff-Serv over label switching controlled ATM (LC-ATM) interfaces.
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.
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.
8.1 Use of ATM Traffic Classes and Traffic Management mechanisms
8.1 Use of ATM Traffic Classes and Traffic Management mechanisms
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.
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.
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.
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.
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.
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.
8.2 LSR Implementation With LC-ATM Interfaces
8.2 LSR Implementation With LC-ATM Interfaces
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.
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.
Le Faucheur, et. al. Standards Track [Page 50] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 50] RFC 3270 MPLS Support of Differentiated Services May 2002
9. MPLS Support of Diff-Serv over LC-FR Interfaces
9. MPLS Support of Diff-Serv over LC-FR Interfaces
This section describes the specific operations required for MPLS support of Diff-Serv over label switching controlled Frame Relay (LC-FR) interfaces.
This section describes the specific operations required for MPLS support of Diff-Serv over label switching controlled Frame Relay (LC-FR) interfaces.
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.
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.
9.1 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms
9.1 Use of Frame Relay Traffic parameters and Traffic Management mechanisms
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.
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.
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.
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.
9.2 LSR Implementation With LC-FR Interfaces
9.2 LSR Implementation With LC-FR Interfaces
A Diff-Serv capable LSR MUST support L-LSPs over LC-Frame Relay interfaces.
A Diff-Serv capable LSR MUST support L-LSPs over LC-Frame Relay interfaces.
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.
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.
Le Faucheur, et. al. Standards Track [Page 51] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 51] RFC 3270 MPLS Support of Differentiated Services May 2002
10. IANA Considerations
10. IANA Considerations
This document defines a number of objects with implications for IANA.
This document defines a number of objects with implications for 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.
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.
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].
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].
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].
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].
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].
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].
11. Security Considerations
11. Security Considerations
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.
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.
12. Acknowledgments
12. Acknowledgments
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.
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.
Le Faucheur, et. al. Standards Track [Page 52] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 52] RFC 3270 MPLS Support of Differentiated Services May 2002
APPENDIX A. Example Deployment Scenarios
APPENDIX A. Example Deployment Scenarios
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.
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.
A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no MPLS
Protection
A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no MPLS Protection
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'.
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'.
Operations can be summarized as follows:
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)
- 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)
- 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)
- 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)
- LSRs signal establishment of a single E-LSP per FEC using LDP in
accordance with the specification above (i.e., no Diff-Serv TLV in
LDP Label Request/Label Mapping messages to implicitly indicate
that the LSP is an E-LSP and that it uses the preconfigured
mapping)
- LSRs 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)
A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no MPLS
Protection
A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no MPLS Protection
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:
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:
- one E-LSP established via LDP and using the preconfigured mapping
to support a set of 8 (or less) BAs, AND
- one E-LSP established via LDP and using the preconfigured mapping to support a set of 8 (or less) BAs, AND
- one L-LSP per <FEC,OA> established via LDP for support of the
other BAs.
- one L-LSP per <FEC,OA> established via LDP for support of the other BAs.
Le Faucheur, et. al. Standards Track [Page 53] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 53] RFC 3270 MPLS Support of Differentiated Services May 2002
Operations can be summarized as follows:
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
- 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
- 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
- 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
- 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
- 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
- LSRs signal establishment of a single E-LSP per FEC for the set of
E-LSP transported BAs using LDP as specified above (i.e., no
Diff-Serv TLV in LDP Label Request/Label Mapping messages to
implicitly indicate that the LSP is an E-LSP and that it uses the
preconfigured mapping)
- LSRs signal establishment of a single E-LSP per FEC for the set of E-LSP transported BAs using LDP as specified above (i.e., no Diff-Serv TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP and that it uses the preconfigured mapping)
- LSRs signal establishment of one L-LSP per <FEC,OA> for the other
BAs using LDP as specified above (i.e., Diff-Serv TLV in LDP Label
Request/Label Mapping messages to indicate the L-LSP's PSC).
- LSRs 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).
A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering,
Aggregate MPLS Protection
A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering, Aggregate MPLS Protection
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.
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.
Operations can be summarized as follows:
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)
- 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)
- 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)
- 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)
- LSRs signal establishment of a single E-LSP per FEC which will use
the preconfigured mapping:
- LSRs signal establishment of a single E-LSP per FEC which will use the preconfigured mapping:
Le Faucheur, et. al. Standards Track [Page 54] RFC 3270 MPLS Support of Differentiated Services May 2002
Le Faucheur, et. al. Standards Track [Page 54] RFC 3270 MPLS Support of Differentiated Services May 2002
* using the RSVP protocol as specified above (i.e., no DIFFSERV
RSVP Object in the PATH message containing the LABEL_REQUEST
Object), OR
* using the RSVP protocol as specified above (i.e., no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR
* using the CR-LDP protocol as specified above (i.e., no Diff-
Serv TLV in LDP Label Request/Label Mapping messages).
* using the CR-LDP protocol as specified above (i.e., no Diff- Serv TLV in LDP Label Request/Label Mapping messages).
- protection is activated on all the E-LSPs in order to achieve MPLS
protection via mechanisms outside the scope of this document.
- protection is activated on all the E-LSPs in order to achieve MPLS protection via mechanisms outside the scope of this document.
A.4 Scenario 4: per-OA Traffic Engineering/MPLS Protection
A.4 Scenario 4: per-OA Traffic Engineering/MPLS Protection
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.
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.
Operations can be summarized as follows:
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)
- 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)
- LSRs signal establishment of one L-LSP per <FEC,OA>:
- LSRs signal establishment of one L-LSP per <FEC,OA>:
* 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
* 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
* 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).
* 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).
- 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-LSPsで活性化する、(潜在的に、各PSCのための異なったレベルの保護) このドキュメントの範囲の外のメカニズムで。
Le Faucheur, et. al. Standards Track [Page 55] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[55ページ]。
A.5 Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/MPLS
Protection
A.5シナリオ5: 1OA Traffic Engineering/MPLS Protectionあたり8(それほど)BAs
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 Traffic Engineering(すなわち、各OAのために別々の経路選択を実行する)を実行して、MPLSの上で8(それほど)BAsを走らせるService Providerとその人のネットワークで1OA MPLSあたりの保護(すなわち、異なったOAsのために潜在的に異なったレベルの保護で保護を実行する)を実行するのは、MPLSの上で<FECあたり1E-LSPを使用することでDiff-Servを走らせるのを選ぶかもしれません、とOA>組がRSVPかCR-自由民主党を通して確証しました。 その上、Service Providerは、すべてのE-LSPsに関するあらかじめ設定されたマッピングを使用するのを選ぶかもしれません。
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)
- Service ProviderはあらゆるLSRでEXP分野の各PHBと値の間の双方向のマッピングを構成します。(例えば、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)
- Service ProviderはあらゆるLSRにおいてあらゆるインタフェースと、各PSC(例えばAF1に割り当てられた帯域幅)のためのスケジューリングの振舞いと各PHBのための低下の振舞いように構成します。(AF11、AF12、AF13のためのeg低下プロフィール)
- LSRs signal establishment of one E-LSP per <FEC,OA>:
- LSRsは<FECあたり1E-LSP、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があらかじめ設定されたマッピング(すなわち、LABEL_REQUESTを含むPATHメッセージでDIFFSERV RSVP Objectがない)を使用するE-LSP、ORであると合図するのに上で指定されるとしてのRSVPプロトコルを使用します。
* using the CR-LDP protocol as specified above to signal that the
LSP is an E-LSP which uses the preconfigured mapping (i.e., no
Diff-Serv TLV in LDP Label Request/Label Mapping messages)
* LSPがあらかじめ設定されたマッピングを使用するE-LSPであると合図するのに上で指定されるとしてのCR-自由民主党プロトコルを使用します。(すなわち、自由民主党Label Request/ラベルMappingメッセージでDiff-Serv TLVがありません)
- the Service Provider configures, for each E-LSP, at the head-end
of that E-LSP, a filtering/forwarding criteria so that only the
packets belonging to a given OA are forwarded on the E-LSP
established for the corresponding FEC and corresponding OA.
- Service Providerは、そのE-LSP、フィルタリング/推進のギヤエンドの各E-LSP評価基準のために与えられたOAに属すパケットが唯一ように対応のために設立されたE-LSP FECと対応する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-LSPs(異なったレベルの保護がPSCによっていて、実際に各E-LSPの上で潜在的に輸送される)でこのドキュメントの範囲の外のメカニズムで活性化します。
Le Faucheur, et. al. Standards Track [Page 56] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[56ページ]。
A.6 Scenario 6: no Traffic Engineering/MPLS Protection on 8 BAs, per-OA
Traffic Engineering/MPLS Protection on other BAs.
A.6シナリオ6: 8BAsの上のTraffic Engineering/MPLS Protectionがない、他のBAsの上のOA Traffic Engineering/MPLS Protection。
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:
Service Providerが8(それほど)BAsにTraffic Engineering/MPLS Protectionを実行しない場合、他のBAs(すなわち、他のBAsに対応するそれぞれのOAのために別々の経路選択を実行して、それぞれのこれらのOAのために潜在的に異なった方針でMPLS Protectionを実行する)にOA Traffic Engineering/MPLS Protectionを実行して、その人のネットワークにMPLS Shimカプセル化を使用するのは、MPLSの上でDiff-Servを走らせるのを選ぶかもしれません、各FECに以下を使用して
- 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
- 8(それほど)非設計された非交通/保護されたBAsのセット、ANDを支持するために自由民主党を通して確立されたあらかじめ設定されたマッピングを使用する1E-LSP
- one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP for
support of the other BAs.
- 他のBAsのサポートのための<FECあたり1L-LSP、RSVPを通して設立されたOA>組またはCR-自由民主党。
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
- Service ProviderはE-LSPの上で支持されたBAsのためにあらゆるLSRでEXP分野の各PHBと値の間の双方向のマッピングを構成します。
- 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
- Service ProviderはあらゆるLSRにおいてあらゆるインタフェースと、E-LSPの上で支持された各PSCのためのスケジューリングの振舞いとそれぞれの対応するPHBのための滴下の振舞いように構成します。
- the Service Provider configures at every LSR, and for every
interface, the scheduling behavior for each PSC supported over the
L-LSPs and the dropping behavior for each corresponding PHB
- Service ProviderはあらゆるLSRにおいてあらゆるインタフェースと、L-LSPsの上で支持された各PSCのためのスケジューリングの振舞いとそれぞれの対応するPHBのための低下の振舞いように構成します。
- LSRs signal establishment of a single E-LSP per FEC for the non-
traffic engineered BAs using LDP as specified above (i.e., no
Diff-Serv TLV in LDP Label Request/Label Mapping messages)
- 非交通へのFECあたり1独身のE-LSPのLSRs信号設立は、上で指定されるとして自由民主党を使用することでBAsを設計しました。(すなわち、自由民主党Label Request/ラベルMappingメッセージでDiff-Serv TLVがありません)
- LSRs signal establishment of one L-LSP per <FEC,OA> for the other
BAs:
- LSRsは他のBAsのために<FECあたり1L-LSP、OA>の設立に合図します:
* 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(すなわち、LABEL_REQUEST Objectを含むPATHメッセージのDIFFSERV RSVP Object)、ORに合図するのに上で指定されるとして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(すなわち、自由民主党Label Request/ラベルMappingメッセージのDiff-Serv TLV)に合図するのに上で指定されるとしてCR-自由民主党プロトコルを使用します。
Le Faucheur, et. al. Standards Track [Page 57] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[57ページ]。
- protection is not activated on the E-LSPs.
- 保護はE-LSPsで起動されません。
- 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-LSPsで活性化する、(潜在的に、L-LSPのPSCによる異なったレベルの保護) このドキュメントの範囲の外のメカニズムで。
A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no MPLS
Protection
A.7シナリオ7: 8BAs、Traffic Engineeringがない、MPLS Protectionがありません。
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'.
>PHBが写像して、自由民主党と合図された'EXP<を使用することを通して1FECあたりのE-LSPsが確立した2を使用することでMPLS保護を実行して、その人のネットワークにMPLS Shim Headerカプセル化を使用して、MPLSの上でDiff- Servを走らせるのを選ぶかもしれないのではなく、Traffic工学を実行しないことでのMPLSの上で8BAsを走らせるA Service Provider
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)
- Service ProviderはあらゆるLSRにおいてあらゆるインタフェースと、各PSC(例えばAF1に割り当てられた帯域幅)のためのスケジューリングの振舞いと各PHBのための低下の振舞いように構成します。(例えば、AF11、AF12、AF13のための低下プロフィール)
- LSRs signal establishment of two E-LSPs per FEC using LDP in
accordance with the specification above (i.e., Diff-Serv TLV in
LDP Label Request/Label Mapping messages to explicitly indicate
that the LSP is an E-LSP and its `EXP<-->PHB mapping'). The
signaled mapping will indicate the subset of 8 (or less) BAs to be
transported on each E-LSP and what EXP values are mapped to each
BA on each E-LSP.
- LSRs信号(2E-LSPsの1上記の仕様通りに自由民主党を使用するFECあたりの設立に、(すなわち、自由民主党Label Request/ラベルMappingのDiff-Serv TLVはLSPがE-LSPであり、'EXPが<であることを明らかに示すために通信します-->PHBマッピング')) 合図されたマッピングは各E-LSPで輸送されるために8(それほど)BAsの部分集合を示すでしょう、そして、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,...)
- Diff-Servリソースにオフラインで完全に食糧を供給させてください。(例えば、COPSを通したSNMPを通したCommand線Interfaceを通して…)
- have Shortest Path Routing used for all the Diff-Serv traffic.
- すべてのDiff-Serv交通にShortest Pathルート設定を使用させてください。
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-LSPs、そして/または、L-LSPsは合図された帯域幅なしで設立されるでしょう。
Le Faucheur, et. al. Standards Track [Page 58] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[58ページ]。
B.2 Scenario 2: Bandwidth Reservation for per-PSC Admission Control
B.2シナリオ2: 1PSCあたりの入場コントロールのための帯域幅予約
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,...)
- Diff-Servリソースにオフラインで完全に食糧を供給させてください。(例えば、COPSを通したSNMPを通したCommand線Interfaceを通して…)
- use L-LSPs
- L-LSPsを使用してください。
- have Constraint Based Routing performed separately for each PSC,
where one of the constraints is availability of bandwidth from the
bandwidth allocated to the relevant PSC.
- 各PSCのために別々にConstraint Basedルート設定を実行させてください。(そこでは、規制の1つが関連PSCに割り当てられた帯域幅からの帯域幅の有用性です)。
In that case, L-LSPs would be established with signaled bandwidth. The bandwidth signaled at L-LSP establishment would be used by LSRs to perform admission control at every hop to ensure that the constraint on availability of bandwidth for the relevant PSC is met.
その場合、L-LSPsは合図された帯域幅で設立されるでしょう。 L-LSP設立で合図された帯域幅は、帯域幅の有用性における関連PSCの規制が迎えられるのを保証するためにあらゆるホップで入場コントロールを実行するのにLSRsによって使用されるでしょう。
B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and
per-PSC Resource Adjustment
B.3シナリオ3: 1PSCあたりの入場コントロールとPSCあたりの帯域幅予約リソース調整
Consider the case where a network administrator elects to:
ネットワーク管理者が選ぶケースを考えてください:
- use L-LSPs
- L-LSPsを使用してください。
- have Constraint Based Routing performed separately for each PSC,
where one of the constraints is availability of bandwidth from the
bandwidth allocated to the relevant PSC.
- 各PSCのために別々にConstraint Basedルート設定を実行させてください。(そこでは、規制の1つが関連PSCに割り当てられた帯域幅からの帯域幅の有用性です)。
- have Diff-Serv resources dynamically adjusted
- Diff-Servリソースはダイナミックに適応しましたか?
In that case, L-LSPs would be established with signaled bandwidth. The bandwidth signaled at L-LSP establishment would be used by LSRs to attempt to adjust the resources allocated to the relevant PSC (e.g., scheduling weight) and then perform admission control to ensure that the constraint on availability of bandwidth for the relevant PSC is met after the adjustment.
その場合、L-LSPsは合図された帯域幅で設立されるでしょう。 L-LSP設立で合図された帯域幅は、関連PSC(例えば、スケジューリングの重さ)に割り当てられたリソースを調整して、次に、帯域幅の有用性における関連PSCの規制が調整の後に迎えられるのを保証するために入場コントロールを実行するのを試みるのにLSRsによって使用されるでしょう。
Le Faucheur, et. al. Standards Track [Page 59] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[59ページ]。
References
参照
[ANSI/IEEE] ANSI/IEEE Std 802.1D, 1993 Edition, incorporating
IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992,
802.11c-1998, and P802.12e).
[ANSI/IEEE] ANSI/IEEE Std 802.1D、1993Editionが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.
「輸送管理仕様バージョン4.1インチと、1999年3月」の[ATMF_TM]気圧フォーラム。
[CR-LDP_MPLS_TE] Jamoussi, B., Editor, Andersson, L., Callon, R. and
R. Dantu, "Constraint-Based LSP Setup using LDP",
RFC 3212, January 2002.
[_MPLS_Te] CR-自由民主党JamoussiとB.とエディタとアンデションとL.とCallonとR.とR.Dantu、「自由民主党を使用する規制ベースのLSPセットアップ」、RFC3212、2002年1月。
[DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC
2996, November 2000.
[DCLASS]Bernet、Y.、「RSVP DCLASS物の形式」、RFC2996、2000年11月。
[DIFF_AF] Heinanen, J., Baker, F., Weiss, W. and J.
Wroclawski, "Assured Forwarding PHB Group", RFC
2597, June 1999.
[デフ_AF] HeinanenとJ.とベイカーとF.とウィスとW.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597、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.
[デフ_アーチ] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「微分されたサービスのための構造」、RFC2475、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.
[デフ_EF] デイビーとB.とシャルニーとA.とベイカーとF.とアメリカダイコンソウとJ.とベンソンとK.とBoudecとJ.とチウとA.とコートニーとW.とDavariとS.とFiroiuとV.とKalmanekとC.とRamakrishnamとK.と2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[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.
[デフ_ヘッダー]ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[DIFF_NEW] Grossman, D., "New Terminology and Clarifications
for Diffserv", RFC 3260, April 2002.
[デフ_新しい] グロースマンと、D.と、「Diffservのための新しい用語と明確化」、RFC3260、4月2002日
[DIFF_TUNNEL] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[デフ_トンネル]黒(D.)が「サービスとトンネルを微分した」、RFC2983、10月2000日
[ECN] Ramakrishnan, K., Floyd, S. and D. Black, "The
Addition of Explicit Congestion Notification (ECN)
to IP", RFC 3168, September 2001.
[電子証券取引ネットワーク]RamakrishnanとK.とフロイドとS.とD.黒、「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」、RFC3168、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Le Faucheur, et. al. Standards Track [Page 60] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[60ページ]。
[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/IEC15802-3: 1998ANSI/IEEE Std 802.1D、1998Edition、(ISO/IEC10038: 98の改正と「再-名称」。
[LDP] Andersson, L., Doolan, D., Feldman, N., Fredette, A.
and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
[自由民主党] アンデションとL.とDoolanとD.とフェルドマンとN.とFredetteとA.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
[MPLS_ARCH] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[MPLS_アーチ]ローゼン、E.、Viswanathan、A.、およびR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、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_気圧] デイビー、B.、ローレンス、J.、McCloghrie、K.、ローゼン、E.は飲み込まれます、Rekhter、Y.、およびP.Doolan、G.、「MPLSは自由民主党と気圧VCの切り換えを使用し」て、RFC3035、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はスタックコード化をラベルします」、RFC3032、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、「フレームリレーにおけるラベルの切り換えの使用は仕様をネットワークでつなぎます」、RFC3034、2001年1月。
[MPLS_VPN] Rosen, E., "BGP/MPLS VPNs", Work in Progress.
[MPLS_VPN] ローゼン、E.、「BGP/MPLS VPNs」が進行中で働いています。
[NULL] Bernet, Y., Smith, A. and B. Davie, "Specification
of the Null Service Type", RFC 2997, November 2000.
[ヌル] BernetとY.とスミスとA.とB.デイビー、「ヌルサービスタイプの仕様」、RFC2997、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.Le Faucheur、「ホップ振舞い識別コード」RFC3140、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の機能的な仕様」、RFC2205、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.とSrinivasan、V.とG.ツバメ、「LSP TunnelsのためのRSVPへの拡大」RFC3209(2001年12月)。
Le Faucheur, et. al. Standards Track [Page 61] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[61ページ]。
Authors' Addresses
作者のアドレス
Francois Le Faucheur Cisco Systems Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France
フランソアLe FaucheurシスコシステムズVillage d'EntrepriseグリーンSide--Batiment T3 400、アベニューdeルーマニーユ06410・Biot-ソフィア・Antipolisフランス
Phone: +33 4 97 23 26 19 EMail: flefauch@cisco.com
以下に電話をしてください。 +33 4 97 23 26 19はメールされます: flefauch@cisco.com
Liwen Wu Cisco Systems 3550 Cisco Way San Jose, CA 95134 USA
Liwenウーシスコシステムズ3550コクチマスWayサンノゼ(カリフォルニア)95134米国
Phone: +1 (408) 853-4065 EMail: liwwu@cisco.com
以下に電話をしてください。 +1 (408) 853-4065 メールしてください: liwwu@cisco.com
Bruce Davie Cisco Systems 250 Apollo Drive, Chelmsford, MA 01824 USA
ブルースデイビーシスコシステムズ250アポロDrive、チェルムズフォード、MA01824米国
Phone: +1 (978) 244-8000 EMail: bsd@cisco.com
以下に電話をしてください。 +1 (978) 244-8000 メールしてください: bsd@cisco.com
Shahram Davari PMC-Sierra Inc. 411 Legget Drive Kanata, Ontario K2K 3C9 Canada
Shahram Davari PMC-連峰株式会社411LeggetドライブKanata、オンタリオK2K 3C9カナダ
Phone: +1 (613) 271-4018 EMail: davari@ieee.org
以下に電話をしてください。 +1 (613) 271-4018 メールしてください: davari@ieee.org
Le Faucheur, et. al. Standards Track [Page 62] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[62ページ]。
Pasi Vaananen Nokia 3 Burlington Woods Drive, Suit 250 Burlington, MA 01803 USA
パシバーナネンノキア3のバーリントンウッズドライブ、スーツ250バーリントン、MA01803米国
Phone +1 (781) 993-4900 EMail: pasi.vaananen@nokia.com
+1 (781)993-4900メールに電話をしてください: pasi.vaananen@nokia.com
Ram Krishnan Axiowave Networks 200 Nickerson Road Marlboro, MA 01752
MA Nickerson道路マールボロ、牡羊座クリシュナンAxiowaveネットワーク200 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 Chevalアルカテル5はクリスマス橋92737ナンテールCedexフランスEMailを悔悟します: pierrick.cheval@space.alcatel.fr
Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland
ユハHeinanen SongはInc.Hallituskatu16 33200タンペレ(フィンランド)をネットワークでつなぎます。
EMail: jh@song.fi
メール: jh@song.fi
Le Faucheur, et. al. Standards Track [Page 63] RFC 3270 MPLS Support of Differentiated Services May 2002
et Le Faucheur、アル。 規格は2002年5月に微分されたサービスのRFC3270MPLSサポートを追跡します[63ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Le Faucheur, et. al. Standards Track [Page 64]
et Le Faucheur、アル。 標準化過程[64ページ]
一覧
スポンサーリンク
