[要約] RFC 8100は、Diffserv-Interconnectionクラスと実践に関するガイドラインです。その目的は、異なるネットワーク間でのDiffservトラフィックの相互接続を効果的に管理するための指針を提供することです。
Internet Engineering Task Force (IETF) R. Geib, Ed.
Request for Comments: 8100 Deutsche Telekom
Category: Informational D. Black
ISSN: 2070-1721 Dell EMC
March 2017
Diffserv-Interconnection Classes and Practice
Diffserv相互接続クラスと実践
Abstract
概要
This document defines a limited common set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operate Multiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS.
このドキュメントでは、個別に管理および運用されている2つのネットワークの（内部）接続に適用される、Diffservのホップ単位の動作（PHB）とDiffservコードポイント（DSCP）の限定された共通セットを定義し、このアプローチでネットワークの構成と運用を簡素化する方法について説明します。多くのネットワークプロバイダーは、さまざまなDiffserv Per-Hop Behaviorsでマークされたトラフィックにトリートメントアグリゲートを使用してマルチプロトコルラベルスイッチング（MPLS）を操作し、他のネットワークとの相互接続にMPLSを使用しています。このドキュメントは、MPLSを使用し、ショートパイプモデルを適用するプロバイダー間のネットワーク相互接続のためのDiffservの操作を簡略化する可能性がある単純な相互接続アプローチを提供します。ショートパイプモデルトンネルを使用するMPLSネットワークオペレーターの要件に動機付けられていますが、このドキュメントは、MPLSと非MPLSの両方の他のネットワークにも適用できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8100.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8100で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability Statement . . . . . . . . . . . . . . . . . 5
1.3. Document Organization . . . . . . . . . . . . . . . . . . 5
2. MPLS and Short Pipe Model Tunnels . . . . . . . . . . . . . . 6
3. Relationship to RFC 5127 . . . . . . . . . . . . . . . . . . 7
3.1. Background of RFC 5127 . . . . . . . . . . . . . . . . . 7
3.2. Differences from RFC 5127 . . . . . . . . . . . . . . . . 7
4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 8
4.1. Diffserv-Intercon Example . . . . . . . . . . . . . . . . 11
4.2. End-to-End PHB and DSCP Transparency . . . . . . . . . . 13
4.3. Treatment of Network Control Traffic at Carrier
Interconnection Interfaces . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. The MPLS Short Pipe Model and IP Traffic . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Diffserv has been deployed in many networks; it provides differentiated traffic forwarding based on the Diffserv Codepoint (DSCP) field, which is part of the IP header [RFC2474]. This document defines a set of common Diffserv classes (Per-Hop Behaviors (PHBs)) and codepoints for use at interconnection points to which and from which locally used classes and codepoints should be mapped.
Diffservは多くのネットワークに配備されています。 IPヘッダー[RFC2474]の一部であるDiffserv Codepoint（DSCP）フィールドに基づいて差別化されたトラフィック転送を提供します。このドキュメントでは、ローカルで使用されるクラスとコードポイントをマッピングする相互接続ポイントで使用するための共通のDiffservクラス（ホップごとの動作（PHB））とコードポイントのセットを定義します。
As described by Section 2.3.4.2 of [RFC2475], the re-marking of packets at domain boundaries is a Diffserv feature. If traffic marked with unknown or unexpected DSCPs is received, [RFC2474] recommends forwarding that traffic with default (best-effort) treatment without changing the DSCP markings to better support incremental Diffserv deployment in existing networks as well as with routers that do not support Diffserv or are not configured to support it. Many networks do not follow this recommendation and instead re-mark unknown or unexpected DSCPs to zero upon receipt for default (best-effort) forwarding in accordance with the guidance in [RFC2475] to ensure that appropriate DSCPs are used within a Diffserv domain. This document is based on the latter approach and defines additional DSCPs that are known and expected at network interconnection interfaces in order to reduce the amount of traffic whose DSCPs are re-marked to zero.
[RFC2475]のセクション2.3.4.2で説明されているように、ドメイン境界でのパケットの再マーキングはDiffserv機能です。不明または予期しないDSCPでマークされたトラフィックを受信した場合、[RFC2474]は、DSCPマーキングを変更せずにデフォルト（ベストエフォート）の処理でそのトラフィックを転送し、既存のネットワークでの差分Diffserv配備とDiffservをサポートしていないルーターをより適切にサポートすることを推奨しますまたはそれをサポートするように構成されていません。多くのネットワークはこの推奨事項に従っておらず、[RFC2475]のガイダンスに従ってデフォルト（ベストエフォート）転送の受信時に不明または予期しないDSCPをゼロに再マークし、Diffservドメイン内で適切なDSCPが使用されるようにします。このドキュメントは後者のアプローチに基づいており、DSCPがゼロに再マーキングされるトラフィックの量を削減するために、ネットワーク相互接続インターフェースで既知であり予想される追加のDSCPを定義します。
This document is motivated by requirements for IP network interconnection with Diffserv support among providers that operate Multiprotocol Label Switching (MPLS) in their backbones, but it is also applicable to other technologies. The operational simplifications and methods in this document help align IP Diffserv functionality with MPLS limitations resulting from the widely deployed Short Pipe Model for MPLS tunnel operation [RFC3270]. Further, limiting Diffserv to a small number of Treatment Aggregates can enable network traffic to leave a network with the DSCP value with which it was received, even if a different DSCP is used within the network, thus providing an opportunity to extend consistent Diffserv treatment across network boundaries.
このドキュメントは、バックボーンでマルチプロトコルラベルスイッチング（MPLS）を運用するプロバイダー間のDiffservサポートとIPネットワーク相互接続の要件に基づいていますが、他のテクノロジーにも適用できます。このドキュメントの操作の簡素化と方法は、IP Diffserv機能をMPLSトンネル操作用に広く展開されているショートパイプモデル[RFC3270]に起因するMPLSの制限に合わせるのに役立ちます。さらに、Diffservを少数の処理集約に制限することで、ネットワーク内で別のDSCPが使用されている場合でも、ネットワークトラフィックがそれを受信したDSCP値でネットワークを離れることができるため、一貫したDiffserv処理を拡張できます。ネットワーク境界。
In isolation, use of a defined set of interconnection PHBs and DSCPs may appear to be additional effort for a network operator. The primary offsetting benefit is that mapping from or to the interconnection PHBs and DSCPs is specified once for all of the interconnections to other networks that can use this approach. Absent this approach, the PHBs and DSCPs have to be negotiated and configured independently for each network interconnection, which has poor administrative and operational scaling properties. Further, consistent end-to-end Diffserv treatment is more likely to result when an interconnection codepoint scheme is used because traffic is re-marked to the same DSCPs at all network interconnections.
独立して、定義された相互接続PHBとDSCPのセットの使用は、ネットワークオペレーターにとって追加の作業のように見える場合があります。主な相殺の利点は、相互接続PHBおよびDSCPとの間のマッピングが、このアプローチを使用できる他のネットワークへのすべての相互接続に対して一度指定されることです。このアプローチがない場合、PHBとDSCPは、ネットワークの相互接続ごとに個別にネゴシエートおよび構成する必要があり、管理および運用のスケーリングプロパティが不十分です。さらに、すべてのネットワーク相互接続でトラフィックが同じDSCPに再マーキングされるため、相互接続コードポイントスキームを使用すると、一貫したエンドツーエンドのDiffserv処理が発生する可能性が高くなります。
The interconnection approach described in this document (referred to as "Diffserv-Intercon") uses a set of PHBs (mapped to four corresponding MPLS Treatment Aggregates) along with a set of interconnection DSCPs allowing straightforward rewriting to domain-internal DSCPs and defined DSCP markings for traffic forwarded to interconnected domains. The solution described here can be used in other contexts benefiting from a defined Diffserv interconnection interface.
このドキュメントで説明されている相互接続アプローチ（ "Diffserv-Intercon"と呼ばれます）は、PHBのセット（4つの対応するMPLS処理集約にマップされます）と相互接続DSCPのセットを使用して、ドメイン内部のDSCPと定義されたDSCPマーキングへの簡単な書き換えを可能にします相互接続されたドメインに転送されるトラフィック用。ここで説明するソリューションは、定義されたDiffserv相互接続インターフェースの恩恵を受ける他のコンテキストで使用できます。
The basic idea is that traffic sent with a Diffserv-Intercon PHB and DSCP is restored to that PHB and DSCP at each network interconnection, even though a different PHB and DSCP may be used within each network involved. The key requirement is that the network ingress interconnect DSCP be restored at the network egress, and a key observation is that this is only feasible in general for a small number of DSCPs. Traffic sent with other DSCPs can be re-marked to an interconnect DSCP or dealt with via an additional agreement(s) among the operators of the interconnected networks; use of the MPLS Short Pipe Model favors re-marking unexpected DSCPs to zero in the absence of an additional agreement(s), as explained further in this document.
基本的な考え方は、Diffserv-Intercon PHBおよびDSCPで送信されたトラフィックは、関係する各ネットワーク内で異なるPHBおよびDSCPが使用される場合でも、各ネットワーク相互接続でそのPHBおよびDSCPに復元されるということです。重要な要件は、ネットワーク入力相互接続DSCPがネットワーク出力で復元されることであり、重要な観察は、これは一般的に少数のDSCPに対してのみ実行可能であることです。他のDSCPで送信されたトラフィックは、相互接続DSCPに再マーキングするか、相互接続されたネットワークのオペレーター間の追加の合意を介して処理できます。このドキュメントでさらに説明されているように、MPLSショートパイプモデルを使用すると、追加の合意がない場合、予期しないDSCPをゼロに再マーキングすることができます。
In addition to the common interconnecting PHBs and DSCPs, interconnecting operators need to further agree on the tunneling technology used for interconnection (e.g., MPLS, if used) and control or mitigate the impacts of tunneling on reliability and MTU.
相互接続する一般的なPHBとDSCPに加えて、相互接続するオペレーターは、相互接続に使用されるトンネリング技術（MPLSなど）についてさらに合意し、信頼性とMTUへのトンネリングの影響を制御または軽減する必要があります。
In addition to the activities that triggered this work, there are additional RFCs and Internet-Drafts that may benefit from an interconnection PHB and DSCP scheme. [RFC5160] suggests Meta-QoS-Classes to help enable deployment of standardized end-to-end QoS classes. The Diffserv-Intercon class and codepoint scheme is intended to complement that work (e.g., by enabling a defined set of interconnection DSCPs and PHBs).
この作業をトリガーしたアクティビティに加えて、相互接続PHBおよびDSCPスキームの恩恵を受ける可能性がある追加のRFCおよびインターネットドラフトがあります。 [RFC5160]はMeta-QoS-Classesを提案し、標準化されたエンドツーエンドのQoSクラスの配備を可能にします。 Diffserv-Interconクラスとコードポイントスキームは、（たとえば、定義された相互接続DSCPとPHBのセットを有効にすることによって）その機能を補完することを目的としています。
Border Gateway Protocol (BGP) support for signaling Class of Service at interconnection interfaces [BGP-INTERCONNECTION] [SLA-EXCHANGE] is complementary to Diffserv-Intercon. These two BGP documents focus on exchanging Service Level Agreement (SLA) and traffic conditioning parameters and assume that common PHBs identified by the signaled DSCPs have been established (e.g., via use of the Diffserv-Intercon DSCPs) prior to BGP signaling of PHB id codes.
相互接続インターフェースでのサービスクラスのシグナリングに対するボーダーゲートウェイプロトコル（BGP）サポート[BGP-INTERCONNECTION] [SLA-EXCHANGE]は、Diffserv-Interconを補完するものです。これら2つのBGPドキュメントは、サービスレベルアグリーメント（SLA）とトラフィックコンディショニングパラメーターの交換に焦点を当てており、PHB IDコードのBGPシグナリングの前に、シグナリングされたDSCPによって識別される共通のPHBが確立されていることを前提としています（たとえば、Diffserv-Intercon DSCPを使用して）。 。
This document is applicable to the use of Differentiated Services for interconnection traffic between networks and is particularly suited to interconnection of MPLS-based networks that use MPLS Short Pipe Model tunnels. This document is also applicable to other network technologies, but it is not intended for use within an individual network, where the approach specified in [RFC5127] is among the possible alternatives; see Section 3 for further discussion.
このドキュメントは、ネットワーク間のトラフィックを相互接続するための差別化サービスの使用に適用され、MPLSショートパイプモデルトンネルを使用するMPLSベースのネットワークの相互接続に特に適しています。このドキュメントは他のネットワークテクノロジーにも適用できますが、[RFC5127]で指定されているアプローチが可能な代替策の1つである個々のネットワーク内での使用は意図されていません。詳細については、セクション3を参照してください。
The Diffserv-Intercon approach described in this document simplifies IP-based interconnection to domains operating the MPLS Short Pipe Model for IP traffic, both terminating within the domain and transiting onward to another domain. Transiting traffic is received and sent with the same PHB and DSCP. Terminating traffic maintains the PHB with which it was received; however, the DSCP may change.
このドキュメントで説明されているDiffserv-Interconアプローチは、ドメイン内で終端し、別のドメインに転送するIPトラフィックのMPLSショートパイプモデルを操作するドメインへのIPベースの相互接続を簡素化します。通過トラフィックは、同じPHBとDSCPで送受信されます。トラフィックを終了すると、受信したPHBが維持されます。ただし、DSCPは変更される場合があります。
Diffserv-Intercon is also applicable to Pipe Model tunneling [RFC2983] [RFC3270], but it is not applicable to Uniform Model tunneling [RFC2983] [RFC3270].
Diffserv-Interconは、パイプモデルトンネリング[RFC2983] [RFC3270]にも適用できますが、均一モデルトンネリング[RFC2983] [RFC3270]には適用できません。
The Diffserv-Intercon approach defines a set of four PHBs for support at interconnections (or network boundaries in general). Corresponding DSCPs for use at an interconnection interface are also defined. Diffserv-Intercon allows for a simple mapping of PHBs and DSCPs to MPLS Treatment Aggregates. It is extensible by IETF standardization, and this allows additional PHBs and DSCPs to be specified for the Diffserv-Intercon scheme. Coding space for private interconnection agreements or provider internal services is available, as only a single digit number of standard DSCPs are applied by the Diffserv-Intercon approach.
Diffserv-Interconアプローチは、相互接続（またはネットワーク境界一般）でサポートするための4つのPHBのセットを定義します。相互接続インターフェースで使用するための対応するDSCPも定義されています。 Diffserv-Interconを使用すると、PHBとDSCPをMPLS処理集約に簡単にマッピングできます。これはIETF標準化によって拡張可能であり、これにより、Diffserv-Interconスキームに追加のPHBおよびDSCPを指定できます。 Diffserv-Interconアプローチでは1桁の標準DSCPのみが適用されるため、プライベート相互接続契約またはプロバイダーの内部サービス用のコーディングスペースを利用できます。
This document is organized as follows: Section 2 reviews the MPLS Short Pipe Model for Diffserv Tunnels [RFC3270], because effective support for that model is a crucial goal of Diffserv-Intercon. Section 3 provides background on the approach described in RFC 5127 to Traffic Class (TC) aggregation within a Diffserv network domain and contrasts it with the Diffserv-Intercon approach. Section 4 introduces Diffserv-Intercon Treatment Aggregates, along with the PHBs and DSCPs that they use, and explains how other PHBs (and associated DSCPs) may be mapped to these Treatment Aggregates. Section 4 also discusses treatment of IP traffic, MPLS VPN Diffserv considerations, and the handling of high-priority network management traffic. Appendix A describes how the MPLS Short Pipe Model (Penultimate Hop Popping (PHP)) impacts DSCP marking for IP interconnections.
このドキュメントは次のように構成されています。セクション2は、DiffservトンネルのMPLS短パイプモデル[RFC3270]をレビューしています。これは、そのモデルの効果的なサポートがDiffserv-Interconの重要な目標であるためです。セクション3では、RFC 5127で説明されている、Diffservネットワークドメイン内のトラフィッククラス（TC）集約へのアプローチの背景を説明し、Diffserv-Interconアプローチと比較します。セクション4では、Diffserv-Intercon処理集約と、それらが使用するPHBおよびDSCPを紹介し、他のPHB（および関連するDSCP）がこれらの処理集約にどのようにマッピングされるかを説明します。セクション4では、IPトラフィックの処理、MPLS VPN Diffservの考慮事項、および優先度の高いネットワーク管理トラフィックの処理についても説明します。付録Aでは、MPLSショートパイプモデル（Penultimate Hop Popping（PHP））がIP相互接続のDSCPマーキングにどのように影響するかについて説明します。
This section provides a summary of the implications of MPLS Short Pipe Model tunnels and, in particular, their use of PHP (see RFC 3270) on the Diffserv tunnel framework described in RFC 2983. The Pipe and Uniform Models for Differentiated Services and Tunnels are defined in [RFC2983]. RFC 3270 adds the Short Pipe Model to reflect the impact of MPLS PHP, primarily for MPLS-based IP tunnels and VPNs. The Short Pipe Model and PHP have subsequently become popular with network providers that operate MPLS networks and are now widely used to transport unencapsulated IP traffic. This has important implications for Diffserv functionality in MPLS networks.
このセクションでは、MPLSショートパイプモデルトンネルの影響、特に、RFC 2983で説明されているDiffservトンネルフレームワークでのPHP（RFC 3270を参照）の使用の概要を説明します。差別化されたサービスとトンネルのパイプモデルと均一モデルが定義されています[RFC2983]。 RFC 3270には、主にMPLSベースのIPトンネルとVPN向けのMPLS PHPの影響を反映するショートパイプモデルが追加されています。その後、ショートパイプモデルとPHPは、MPLSネットワークを運用するネットワークプロバイダーに普及し、現在、カプセル化されていないIPトラフィックの転送に広く使用されています。これは、MPLSネットワークのDiffserv機能に重要な影響を及ぼします。
Per RFC 2474, the recommendation to forward traffic with unrecognized DSCPs with default (best-effort) service without rewriting the DSCP has not been widely deployed in practice. Network operation and management are simplified when there is a 1-1 match between the DSCP marked on the packet and the forwarding treatment (PHB) applied by network nodes. When this is done, CS0 (the all-zero DSCP) is the only DSCP used for default forwarding of best-effort traffic, and a common practice is to re-mark to CS0 any traffic received with unrecognized or unsupported DSCPs at network edges.
RFC 2474によると、DSCPを書き換えずにデフォルト（ベストエフォート）サービスで認識されないDSCPを含むトラフィックを転送する推奨は、実際には広く導入されていません。パケットにマークされたDSCPとネットワークノードによって適用された転送処理（PHB）の間に1-1の一致がある場合、ネットワークの操作と管理が簡略化されます。これが行われると、CS0（すべてゼロのDSCP）が、ベストエフォートトラフィックのデフォルトの転送に使用される唯一のDSCPとなります。一般的な方法は、ネットワークエッジで認識されない、またはサポートされていないDSCPで受信されたトラフィックをCS0に再マークすることです。
MPLS networks are more subtle in this regard, as it is possible to encode the provider's DSCP in the MPLS TC field and allow that to differ from the PHB indicated by the DSCP in the MPLS-encapsulated IP packet. If the MPLS label with the provider's TC field is present at all hops within the provider network, this approach would allow an unrecognized DSCP to be carried edge-to-edge over an MPLS network, because the effective DSCP used by the provider's MPLS network would be encoded in the MPLS label TC field (and also carried edge-to-edge). Unfortunately, this is only true for Pipe Model tunnels.
MPLS TCフィールドでプロバイダーのDSCPをエンコードし、MPLSカプセル化IPパケットのDSCPで示されるPHBと異なるようにすることができるため、MPLSネットワークはこの点でより巧妙です。プロバイダーのTCフィールドを含むMPLSラベルがプロバイダーネットワーク内のすべてのホップに存在する場合、プロバイダーのMPLSネットワークで使用される有効なDSCPが原因で、このアプローチにより、認識されないDSCPがMPLSネットワークを介してエッジツーエッジで伝送されます。 MPLSラベルTCフィールドにエンコードされます（また、エッジツーエッジで伝送されます）。残念ながら、これはパイプモデルトンネルにのみ当てはまります。
Short Pipe Model tunnels and PHP behave differently because PHP removes and discards the MPLS provider label carrying the provider's TC field before the traffic exits the provider's network. That discard occurs one hop upstream of the MPLS tunnel endpoint (which is usually at the network edge), resulting in no provider TC information being available at the tunnel egress. To ensure consistent handling of traffic at the tunnel egress, the DSCP field in the MPLS-encapsulated IP header has to contain a DSCP that is valid for the provider's network, so that the IP header cannot be used to carry a different DSCP edge-to-edge. See Appendix A for a more detailed discussion.
トラフィックがプロバイダーのネットワークを出る前に、PHPがプロバイダーのTCフィールドを運ぶMPLSプロバイダーラベルを削除して破棄するため、ショートパイプモデルトンネルとPHPの動作は異なります。その破棄は、MPLSトンネルエンドポイント（通常はネットワークエッジにあります）の1ホップ上流で発生し、その結果、プロバイダーのTC情報がトンネルの出口で利用できなくなります。トンネル出口でのトラフィックの一貫した処理を確保するには、MPLSカプセル化IPヘッダーのDSCPフィールドにプロバイダーのネットワークで有効なDSCPを含める必要があります。これにより、IPヘッダーを使用して別のDSCPエッジから-縁。詳細については、付録Aを参照してください。
This document draws heavily upon the approach to aggregation of Diffserv TCs for use within a network as described in RFC 5127, but there are important differences caused by characteristics of network interconnects that differ from links within a network.
このドキュメントでは、RFC 5127で説明されている、ネットワーク内で使用するDiffserv TCの集約へのアプローチに重点を置いていますが、ネットワーク内のリンクとは異なるネットワーク相互接続の特性によって生じる重要な違いがあります。
Many providers operate MPLS-based backbones that employ backbone traffic engineering to ensure that if a major link, switch, or router fails, the result will be a routed network that continues to function. Based on that foundation, [RFC5127] introduced the concept of Diffserv Treatment Aggregates, which enable traffic marked with multiple DSCPs to be forwarded in a single MPLS TC based on robust provider backbone traffic engineering. This enables differentiated forwarding behaviors within a domain in a fashion that does not consume a large number of MPLS TCs.
多くのプロバイダーは、バックボーントラフィックエンジニアリングを採用したMPLSベースのバックボーンを運用して、主要なリンク、スイッチ、またはルーターに障害が発生しても、ルーティングされたネットワークが機能し続けるようにします。その基盤に基づいて、[RFC5127]はDiffserv処理集約の概念を導入しました。これにより、堅牢なプロバイダーバックボーントラフィックエンジニアリングに基づいて、複数のDSCPでマークされたトラフィックを単一のMPLS TCで転送できます。これにより、多数のMPLS TCを消費しない方法で、ドメイン内の差別化された転送動作が可能になります。
RFC 5127 provides an example aggregation of Diffserv service classes into four Treatment Aggregates. A small number of aggregates are used because:
RFC 5127は、Diffservサービスクラスを4つの処理集約に集約する例を提供しています。次の理由により、少数のアグリゲートが使用されます。
o The available coding space for carrying TC information (e.g., Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in size and is intended for more than just Diffserv purposes (see, e.g., [RFC5129]).
o MPLS（およびイーサネット）でTC情報（Diffserv PHBなど）を伝送するために利用可能なコーディングスペースは、サイズが3ビットのみであり、Diffservの目的（たとえば、[RFC5129]を参照）以外の目的でも使用できます。
o The common interconnection DSCPs ought not to use all 8 possible values. This leaves space for future standards, private bilateral agreements, and local use PHBs and DSCPs.
o 一般的な相互接続DSCPは、8つの値すべてを使用するべきではありません。これにより、将来の標準、私的な二国間協定、およびローカルで使用するPHBとDSCPのためのスペースが残されます。
o Migrations from one DSCP scheme to a different one is another possible application of otherwise unused DSCPs.
o あるDSCPスキームから別のDSCPスキームへの移行は、他の方法では使用されていないDSCPの別の可能なアプリケーションです。
Like RFC 5127, this document also uses four Treatment Aggregates, but it differs from RFC 5127 in some important ways:
RFC 5127と同様に、このドキュメントも4つの処理集約を使用しますが、いくつかの重要な点でRFC 5127とは異なります。
o It follows RFC 2475 in allowing the DSCPs used within a network to differ from those used to exchange traffic with other networks (at network edges), but it provides support to restore ingress DSCP values if one of the recommended interconnect DSCPs in this document is used. This results in DSCP re-marking at both network ingress and network egress, and this document assumes that such re-marking at network edges is possible for all interface types.
o ネットワーク内で使用されるDSCPが他のネットワークと（ネットワークエッジで）トラフィックを交換するために使用されるDSCPと異なることを許可するRFC 2475に従いますが、このドキュメントで推奨される相互接続DSCPの1つが使用される場合、入力DSCP値を復元するためのサポートを提供します。これにより、ネットワークの入口と出口の両方でDSCPの再マーキングが行われます。このドキュメントでは、ネットワークエッジでのそのような再マーキングがすべてのインターフェイスタイプで可能であると想定しています。
o Diffserv-Intercon suggests limiting the number of interconnection PHBs per Treatment Aggregate to the minimum required. As further discussed below, the number of PHBs per Treatment Aggregate is no more than two. When two PHBs are specified for a Diffserv-Intercon Treatment Aggregate, the expectation is that the provider network supports DSCPs for both PHBs but uses a single MPLS TC for the Treatment Aggregate that contains the two PHBs.
o Diffserv-Interconは、処理集約ごとの相互接続PHBの数を必要最小限に制限することを提案しています。以下でさらに説明するように、処理集合体あたりのPHBの数は2つ以下です。 Diffserv-Intercon処理集約に2つのPHBが指定されている場合、プロバイダーネットワークは両方のPHBのDSCPをサポートしますが、2つのPHBを含む処理集約に単一のMPLS TCを使用することが期待されます。
o Diffserv-Intercon suggests mapping other PHBs and DSCPs into the interconnection Treatment Aggregates as further discussed below.
o Diffserv-Interconは、以下でさらに説明するように、他のPHBおよびDSCPを相互接続処理集約にマッピングすることを推奨しています。
o Diffserv-Intercon treats network control (NC) traffic as a special case. Within a provider's network, the CS6 DSCP is used for local network control traffic (routing protocols and Operations, Administration, and Maintenance (OAM) traffic that is essential to network operation administration, control, and management) that may be destined for any node within the network. In contrast, network control traffic exchanged between networks (e.g., BGP) usually terminates at or close to a network edge and is not forwarded through the network because it is not part of internal routing or OAM for the receiving network. In addition, such traffic is unlikely to be covered by standard interconnection agreements; rather, it is more likely to be specifically configured (e.g., most networks impose restrictions on use of BGP with other networks for obvious reasons). See Section 4.2 for further discussion.
o Diffserv-Interconは、ネットワーク制御（NC）トラフィックを特殊なケースとして扱います。プロバイダーのネットワーク内で、CS6 DSCPはローカルネットワーク制御トラフィック（ルーティングプロトコルとネットワーク運用管理、制御、および管理に不可欠な運用、管理、保守（OAM）トラフィック）に使用され、ネットワーク。対照的に、ネットワーク（BGPなど）間で交換されるネットワーク制御トラフィックは、通常、ネットワークエッジまたはその近くで終端し、受信ネットワークの内部ルーティングまたはOAMの一部ではないため、ネットワークを介して転送されません。さらに、そのようなトラフィックが標準の相互接続契約でカバーされることはほとんどありません。むしろ、具体的に構成されている可能性が高くなります（たとえば、ほとんどのネットワークは、明らかな理由で他のネットワークでのBGPの使用に制限を課しています）。詳細については、セクション4.2を参照してください。
o Because RFC 5127 used a Treatment Aggregate for network control traffic, Diffserv-Intercon can instead define a fourth Treatment Aggregate for use at network interconnections instead of the Network Control Treatment Aggregate in RFC 5127. Network control traffic may still be exchanged across network interconnections as further discussed in Section 4.2. Diffserv-Intercon uses this fourth Treatment Aggregate for Voice over IP (VoIP) traffic, where network-provided service differentiation is crucial, as even minor glitches are immediately apparent to the humans involved in the conversation.
o RFC 5127はネットワーク制御トラフィックに処理集約を使用したため、Diffserv-Interconは、RFC 5127のネットワーク制御処理集約の代わりに、ネットワーク相互接続で使用する4番目の処理集約を代わりに定義できます。セクション4.2で説明します。 Diffserv-Interconは、この4番目のトリートメントアグリゲートをVoice over IP（VoIP）トラフィックに使用します。会話に関与する人間にはわずかな不具合でもすぐに明らかになるため、ネットワークが提供するサービスの差別化が重要です。
At an interconnection, the networks involved need to agree on the PHBs used for interconnection and the specific DSCP for each PHB. This document defines a set of four interconnection Treatment Aggregates with well-defined DSCPs to be aggregated by them. A sending party re-marks DSCPs from internal usage to the interconnection codepoints. The receiving party re-marks DSCPs to their internal usage. The interconnect SLA defines the set of DSCPs and PHBs supported across the two interconnected domains and the treatment of PHBs and DSCPs that are not recognized by the receiving domain.
相互接続では、関係するネットワークは、相互接続に使用されるPHBと各PHBの特定のDSCPについて合意する必要があります。このドキュメントでは、4つの相互接続処理集約のセットを定義し、それらによって集約されるDSCPを明確に定義しています。送信側は、内部使用から相互接続コードポイントへのDSCPを再マーキングします。受信側は、DSCPを内部使用に再マーキングします。相互接続SLAは、2つの相互接続されたドメイン間でサポートされる一連のDSCPとPHBを定義し、受信ドメインで認識されないPHBとDSCPの扱いを定義します。
Similar approaches that use a small number of Treatment Aggregates (including recognition of the importance of VoIP traffic) have been taken in related standards and recommendations from outside the IETF, e.g., Y.1566 [Y.1566], Global System for Mobile Communications Association (GSMA) IR.34 [IR.34], and MEF23.1 [MEF23.1].
少数のトリートメントアグリゲート（VoIPトラフィックの重要性の認識を含む）を使用する同様のアプローチが、IETFの外部から関連する標準や推奨事項で採用されています（例：Y.1566 [Y.1566]、Global System for Mobile Communications Association） （GSMA）IR.34 [IR.34]、およびMEF23.1 [MEF23.1]。
The list of the four Diffserv-Intercon Treatment Aggregates follows, highlighting differences from RFC 5127 and suggesting mappings for all RFC 4594 TCs to Diffserv-Intercon Treatment Aggregates:
次に、4つのDiffserv-Intercon処理集約のリストを示し、RFC 5127との違いを強調し、すべてのRFC 4594 TCのDiffserv-Intercon処理集約へのマッピングを提案します。
Telephony Service Treatment Aggregate: PHB Expedited Forwarding (EF), DSCP 101 110 and PHB VOICE-ADMIT, DSCP 101 100 (see [RFC3246], [RFC4594], and [RFC5865]). This Treatment Aggregate corresponds to the Real-Time Treatment Aggregate definition regarding the queuing (both delay and jitter should be minimized) per RFC 5127, but this aggregate is restricted to transport Telephony service class traffic in the sense of [RFC4594].
テレフォニーサービス処理集約：PHB Expedited Forwarding（EF）、DSCP 101 110およびPHB VOICE-ADMIT、DSCP 101 100（[RFC3246]、[RFC4594]、および[RFC5865]を参照）。この処理集約は、RFC 5127によるキューイング（遅延とジッターの両方を最小限にする必要がある）に関するリアルタイム処理集約の定義に対応していますが、この集約は、[RFC4594]の意味でのテレフォニーサービスクラストラフィックのトランスポートに制限されています。
Bulk Real-Time Treatment Aggregate: This Treatment Aggregate is designed to transport PHB AF41, DSCP 100 010 (the other AF4 PHB group PHBs and DSCPs may be used for future extension of the set of DSCPs carried by this Treatment Aggregate). This Treatment Aggregate is intended to provide Diffserv-Intercon network interconnection of a subset of the Real-Time Treatment Aggregate defined in RFC 5127, specifically the portions that consume significant bandwidth. This traffic is expected to consist of the following classes defined in RFC 4594: Broadcast Video, Real-Time Interactive, and Multimedia Conferencing. This Treatment Aggregate should be configured with a rate-based queue (consistent with the recommendation for the transported TCs in RFC 4594). By comparison to RFC 5127, the number of DSCPs has been reduced to one (initially). The AF42 and AF43 PHBs could be added if there is a need for three-color marked Multimedia Conferencing traffic.
バルクリアルタイム処理集約：この処理集約は、PHB AF41、DSCP 100 010を転送するように設計されています（他のAF4 PHBグループのPHBとDSCPは、この処理集約によって運ばれる一連のDSCPの将来の拡張に使用される可能性があります）。この処理集約は、RFC 5127で定義されているリアルタイム処理集約のサブセット、具体的にはかなりの帯域幅を消費する部分のDiffserv-Interconネットワーク相互接続を提供することを目的としています。このトラフィックは、RFC 4594で定義されている次のクラスで構成されると予想されます。ブロードキャストビデオ、リアルタイムインタラクティブ、およびマルチメディア会議。この処理集約は、レートベースのキューを使用して構成する必要があります（RFC 4594のトランスポートされたTCの推奨事項に準拠）。 RFC 5127と比較すると、DSCPの数は（最初は）1つに減っています。 3色のマルチメディア会議トラフィックが必要な場合は、AF42およびAF43 PHBを追加できます。
Assured Elastic Treatment Aggregate: This Treatment Aggregate consists of PHBs AF31 and AF32 (i.e., DSCPs 011 010 and 011 100). By comparison to RFC 5127, the number of DSCPs has been reduced to two. This document suggests to transport signaling marked by AF31 (e.g., as recommended by GSMA IR.34 [IR.34]). AF33 is reserved for the extension of PHBs to be aggregated by this Treatment Aggregate. For Diffserv-Intercon network interconnection, the following service classes (per RFC 4594) should be mapped to the Assured Elastic Treatment Aggregate: the Signaling service class (being marked for lowest loss probability), the Multimedia Streaming service class, the Low-Latency Data service class, and the High-Throughput Data service class.
保証された弾性治療骨材：この治療骨材は、PHB AF31およびAF32（つまり、DSCP 011 010および011 100）で構成されます。 RFC 5127と比較すると、DSCPの数は2つに減っています。このドキュメントは、AF31でマークされたシグナリングを転送することを提案しています（たとえば、GSMA IR.34 [IR.34]で推奨されています）。 AF33は、この処理集約によって集約されるPHBの拡張用に予約されています。 Diffserv-Interconネットワーク相互接続の場合、次のサービスクラス（RFC 4594に準拠）を保証されたElastic Treatment Aggregateにマップする必要があります：シグナリングサービスクラス（損失確率が最も低くなるようにマークされている）、マルチメディアストリーミングサービスクラス、低遅延データサービスクラス、および高スループットデータサービスクラス。
Default / Elastic Treatment Aggregate: Transports the Default PHB, CS0 with DSCP 000 000. An example in RFC 5127 refers to this Treatment Aggregate as "Elastic Treatment Aggregate". An important difference from RFC 5127 is that any traffic with unrecognized or unsupported DSCPs may be re-marked to this DSCP. For Diffserv-Intercon network interconnection, the Standard service class and Low-Priority Data service class defined in RFC 4594 should be mapped to this Treatment Aggregate. This document does not specify an interconnection class for Low-Priority Data (also defined RFC 4594). This traffic may be forwarded with a Lower Effort PHB in one domain (e.g., the PHB proposed by Informational [RFC3662]), but the methods specified in this document re-mark this traffic with DSCP CS0 at a Diffserv-Intercon network interconnection. This has the effect that Low-Priority Data is treated the same as data sent using the Standard service class. (Note: In a network that implements RFC 2474, Low-Priority traffic marked as CS1 would otherwise receive better treatment than Standard traffic using the default PHB.)
デフォルト/エラスティックトリートメントアグリゲート：デフォルトPHB、CS0をDSCP 000 000で転送します。RFC5127の例では、このトリートメントアグリゲートを「エラスティックトリートメントアグリゲート」と呼んでいます。 RFC 5127との重要な違いは、認識されない、またはサポートされていないDSCPを持つトラフィックは、このDSCPに再マーキングされる可能性があることです。 Diffserv-Interconネットワーク相互接続の場合、RFC 4594で定義されている標準サービスクラスと低優先度データサービスクラスをこの処理集約にマップする必要があります。このドキュメントでは、低優先度データ（RFC 4594も定義）の相互接続クラスを指定していません。このトラフィックは、1つのドメイン内のローワーエフォートPHB（たとえば、Informational [RFC3662]によって提案されたPHB）で転送される可能性がありますが、このドキュメントで指定されている方法は、Diffserv-Interconネットワーク相互接続でDSCP CS0を使用してこのトラフィックを再マーキングします。これには、低優先度データが標準サービスクラスを使用して送信されたデータと同じように扱われるという効果があります。 （注：RFC 2474を実装するネットワークでは、CS1としてマークされた低優先度トラフィックは、デフォルトのPHBを使用する標準トラフィックよりも適切に処理されます。）
RFC 2475 states that ingress nodes must condition all inbound traffic to ensure that the DS codepoints are acceptable; packets found to have unacceptable codepoints must either be discarded or have their DS codepoints modified to acceptable values before being forwarded. For example, an ingress node receiving traffic from a domain with which no enhanced service agreement exists may reset the DS codepoint to CS0. As a consequence, an interconnect SLA needs to specify not only the treatment of traffic that arrives with a supported interconnect DSCP but also the treatment of traffic that arrives with unsupported or unexpected DSCPs; re-marking to CS0 is a widely deployed behavior.
RFC 2475では、DSコードポイントが受け入れ可能であることを保証するために、入力ノードはすべての受信トラフィックを調整する必要があると述べています。受け入れられないコードポイントがあることが判明したパケットは、転送する前に破棄するか、DSコードポイントを受け入れ可能な値に変更する必要があります。たとえば、拡張サービス契約が存在しないドメインからトラフィックを受信する入口ノードは、DSコードポイントをCS0にリセットする場合があります。その結果、相互接続SLAは、サポートされる相互接続DSCPで到着するトラフィックの処理だけでなく、サポートされていない、または予期しないDSCPで到着するトラフィックの処理も指定する必要があります。 CS0への再マーキングは、広く展開されている動作です。
During the process of setting up a Diffserv interconnection, both networks should define the set of acceptable and unacceptable DSCPs and specify the treatment of traffic marked with each DSCP.
Diffserv相互接続をセットアップするプロセス中に、両方のネットワークで、受け入れ可能なDSCPと受け入れられないDSCPのセットを定義し、各DSCPでマークされたトラフィックの処理を指定する必要があります。
While Diffserv-Intercon allows modification of unacceptable DSCPs, if traffic using one or more of the PHBs in a PHB group (e.g., AF3x, consisting of AF31, AF32, and AF33) is accepted as part of a supported Diffserv-Intercon Treatment Aggregate, then traffic using other PHBs from the same PHB group should not be modified to use PHBs outside of that PHB group and, in particular, should not be re-marked to CS0 unless the entire PHB group is re-marked to CS0. This avoids unexpected forwarding behavior (and potential reordering; see also [RFC7657]) when using Assured Forwarding (AF) PHBs [RFC2597].
Diffserv-Interconは許容できないDSCPの変更を許可しますが、PHBグループ内の1つ以上のPHB（たとえば、AF31、AF32、およびAF33で構成されるAF3x）を使用するトラフィックが、サポートされるDiffserv-Intercon処理集約の一部として受け入れられる場合、その場合、同じPHBグループの他のPHBを使用するトラフィックは、そのPHBグループの外部のPHBを使用するように変更しないでください。特に、PHBグループ全体をCS0に再マークしない限り、CS0に再マークしないでください。これにより、Assured Forwarding（AF）PHB [RFC2597]を使用する場合の予期しない転送動作（および潜在的な並べ替え。[RFC7657]も参照）が回避されます。
The overall approach to DSCP marking at network interconnections is illustrated by the following example. Provider O, provider W, and provider F are peered with provider T. They have agreed upon a Diffserv interconnection SLA.
ネットワーク相互接続でのDSCPマーキングへの全体的なアプローチを次の例で示します。プロバイダーO、プロバイダーW、プロバイダーFはプロバイダーTとピアリングされています。これらは、Diffserv相互接続SLAに同意しています。
Traffic of provider O terminates within provider T's network, while provider W's traffic transits through the network of provider T to provider F. This example assumes that all providers use their own internal PHB and codepoint (DSCP) that correspond to the AF31 PHB in the Diffserv-Intercon Assured Elastic Treatment Aggregate (AF21, CS2, and AF11 are used in the example).
プロバイダーOのトラフィックはプロバイダーTのネットワーク内で終了し、プロバイダーWのトラフィックはプロバイダーTのネットワークを介してプロバイダーFに通過します。この例では、すべてのプロバイダーがDiffservのAF31 PHBに対応する独自の内部PHBとコードポイント（DSCP）を使用することを前提としています。 -Intercon Assured Elastic Treatment Aggregate（例では、AF21、CS2、およびAF11が使用されています）。
Provider O Provider W
| |
+----------+ +----------+
| AF21 | | CS2 |
+----------+ +----------+
V V
+~~~~~~~+ +~~~~~~~+
|Rtr PrO| |Rtr PrW| Rtr: Router
+~~~~~~~+ +~~~~~~~+ Pr[L]: Provider[L]
| Diffserv |
+----------+ +----------+
| AF31 | | AF31 |
+----------+ +----------+
V Intercon V
+~~~~~~~+ |
|RtrPrTI|------------------+ Router Provider T Ingress
+~~~~~~~+
| Provider T Domain
+------------------+
| MPLS TC 2, AF21 |
+------------------+
| | +----------+ +~~~~~~~+
V `--->| AF21 |->-|RtrDstH| Router Destination Host
+----------+ +----------+ +~~~~~~~+
| AF21 | Local DSCPs Provider T
+----------+
|
+~~~~~~~+
|RtrPrTE| Router Provider T Egress
+~~~~~~~+
| Diffserv
+----------+
| AF31 |
+----------+
| Intercon
+~~~~~~~+
|RtrPrF | Router Provider F
+~~~~~~~+
|
+----------+
| AF11 | Provider F
+----------+
Figure 1: Diffserv-Intercon Example
図1：Diffserv-Interconの例
Providers only need to deploy mappings of internal DSCPs to/from Diffserv-Intercon DSCPs, so that they can exchange traffic using the desired PHBs. In the example, provider O has decided that the properties of his internal class AF21 are best met by the Diffserv-Intercon Assured Elastic Treatment Aggregate, PHB AF31. At the outgoing peering interface connecting provider O with provider T, the former's peering router re-marks AF21 traffic to AF31. The domain internal PHB of provider T that meets the requirement of the Diffserv-Intercon Assured Elastic Treatment Aggregate is from the AF2x PHB group. Hence, AF31 traffic received at the interconnection with provider T is re-marked to AF21 by the peering router of domain T, and domain T has chosen to use MPLS TC value 2 for this aggregate. At the penultimate MPLS node, the top MPLS label is removed and exposes the IP header marked by the DSCP that has been set at the network ingress. The peering router connecting domain T with domain F classifies the packet by its domain-T-internal DSCP AF21. As the packet leaves domain T on the interface to domain F, this causes the packet's DSCP to be re-marked to AF31. The peering router of domain F classifies the packet for domain-F-internal PHB AF11, as this is the PHB with properties matching the Diffserv-Intercon Assured Elastic Treatment Aggregate.
プロバイダーは、必要なPHBを使用してトラフィックを交換できるように、Diffserv-Intercon DSCPとの間の内部DSCPのマッピングを展開するだけで済みます。この例では、プロバイダーOは、彼の内部クラスAF21のプロパティがDiffserv-Intercon Assured Elastic Treatment Aggregate、PHB AF31によって最もよく満たされると判断しました。プロバイダーOとプロバイダーTを接続する発信ピアリングインターフェイスで、前者のピアリングルーターはAF21トラフィックをAF31に再マーキングします。 Diffserv-Intercon Assured Elastic Treatment Aggregateの要件を満たすプロバイダーTのドメイン内部PHBは、AF2x PHBグループからのものです。したがって、プロバイダーTとの相互接続で受信されたAF31トラフィックは、ドメインTのピアリングルーターによってAF21に再マーキングされ、ドメインTはこの集約にMPLS TC値2を使用することを選択しました。最後から2番目のMPLSノードでは、最上位のMPLSラベルが削除され、ネットワークの入口で設定されたDSCPによってマークされたIPヘッダーが公開されます。ドメインTをドメインFに接続するピアリングルーターは、パケットをそのドメインT内部DSCP AF21によって分類します。パケットがドメインFへのインターフェイス上のドメインTを離れると、これによりパケットのDSCPがAF31に再マーキングされます。ドメインFのピアリングルーターは、ドメインFの内部PHB AF11のパケットを分類します。これは、Diffserv-Intercon Assured Elastic Treatment Aggregateと一致するプロパティを持つPHBであるためです。
This example can be extended. The figure shows provider W using CS2 for traffic that corresponds to Diffserv-Intercon Assured Elastic Treatment Aggregate PHB AF31; that traffic is mapped to AF31 at the Diffserv-Intercon interconnection to provider T. In addition, suppose that provider O supports a PHB marked by AF22, and this PHB is supposed to obtain Diffserv transport within provider T's domain. Then provider O will re-mark it with DSCP AF32 for interconnection to provider T.
この例は拡張できます。この図は、Diffserv-Intercon Assured Elastic Treatment Aggregate PHB AF31に対応するトラフィックにCS2を使用するプロバイダーWを示しています。そのトラフィックは、プロバイダーTへのDiffserv-Intercon相互接続でAF31にマップされます。さらに、プロバイダーOがAF22でマークされたPHBをサポートし、このPHBがプロバイダーTのドメイン内のDiffservトランスポートを取得すると想定します。次に、プロバイダーOは、プロバイダーTへの相互接続のために、DSCP AF32で再マーキングします。
Finally, suppose that provider W supports CS3 for internal use only. Then no Diffserv-Intercon DSCP mapping needs to be configured at the peering router. Traffic, sent by provider W to provider T marked by CS3 due to a misconfiguration may be re-marked to CS0 by provider T.
最後に、プロバイダーWが内部使用のみのCS3をサポートするとします。その後、ピアリングルーターでDiffserv-Intercon DSCPマッピングを構成する必要はありません。設定ミスによりCS3によってマークされたプロバイダーWからプロバイダーTに送信されたトラフィックは、プロバイダーTによってCS0に再度マークされる場合があります。
This section briefly discusses end-to-end Diffserv approaches related to the Uniform, Pipe, and Short Pipe Model tunnels [RFC2983] [RFC3270] when used edge-to-edge in a network.
このセクションでは、ネットワークでエッジツーエッジを使用する場合の、ユニフォーム、パイプ、およびショートパイプモデルトンネル[RFC2983] [RFC3270]に関連するエンドツーエンドのDiffservアプローチについて簡単に説明します。
o With the Uniform Model, neither the DSCP nor the PHB change. This implies that a network management packet received with a CS6 DSCP would be forwarded with an MPLS TC corresponding to CS6. The Uniform Model is outside the scope of this document.
o Uniform Modelでは、DSCPもPHBも変更されません。これは、CS6 DSCPで受信されたネットワーク管理パケットが、CS6に対応するMPLS TCで転送されることを意味します。ユニフォームモデルは、このドキュメントの範囲外です。
o With the Pipe Model, the inner tunnel DSCP remains unchanged, but an outer tunnel DSCP and the PHB could change. For example, a packet received with a (network-specific) CS1 DSCP would be transported by a Default PHB and, if MPLS is applicable, forwarded with an MPLS TC corresponding to the Default PHB. The CS1 DSCP is not rewritten. Transport of a large variety (much greater than four) DSCPs may be required across an interconnected network operating MPLS Short Pipe Model transport for IP traffic. In that case, a tunnel based on the Pipe Model is among the possible approaches. The Pipe Model is outside the scope of this document.
o パイプモデルでは、内部トンネルDSCPは変更されませんが、外部トンネルDSCPおよびPHBは変更される可能性があります。たとえば、（ネットワーク固有の）CS1 DSCPで受信されたパケットは、デフォルトPHBによって転送され、MPLSが適用可能な場合、デフォルトPHBに対応するMPLS TCで転送されます。 CS1 DSCPは書き換えられません。 IPトラフィックのMPLSショートパイプモデルトランスポートを操作する相互接続されたネットワーク全体で、多種多様な（4をはるかに超える）DSCPのトランスポートが必要になる場合があります。その場合、パイプモデルに基づくトンネルは可能なアプローチの1つです。パイプモデルはこのドキュメントの範囲外です。
o With the Short Pipe Model, the DSCP likely changes, and the PHB might change. This document describes a method to simplify Diffserv network interconnection when a DSCP rewrite can't be avoided.
o ショートパイプモデルでは、DSCPが変更される可能性が高く、PHBが変更される可能性があります。このドキュメントでは、DSCPの書き換えを回避できない場合にDiffservネットワーク相互接続を簡略化する方法について説明します。
4.3. Treatment of Network Control Traffic at Carrier Interconnection Interfaces
4.3. キャリア相互接続インターフェースでのネットワーク制御トラフィックの扱い
As specified in Section 3.2 of RFC 4594, NC traffic marked by CS6 is expected at some interconnection interfaces. This document does not change RFC 4594 but observes that network control traffic received at a network ingress is generally different from network control traffic within a network that is the primary use of CS6 envisioned by RFC 4594. A specific example is that some CS6 traffic exchanged across carrier interconnections is terminated at the network ingress node, e.g., when BGP is used between the two routers on opposite ends of an interconnection link; in this case, the operators would enter into a bilateral agreement to use CS6 for that BGP traffic.
RFC 4594のセクション3.2で指定されているように、CS6でマークされたNCトラフィックは、一部の相互接続インターフェースで期待されています。このドキュメントはRFC 4594を変更しませんが、ネットワーク入力で受信されるネットワーク制御トラフィックは、RFC 4594によって想定されたCS6の主な用途であるネットワーク内のネットワーク制御トラフィックとは一般的に異なることを観察します。具体的な例は、一部のCS6トラフィックがキャリア相互接続は、たとえば、相互接続リンクの両端にある2つのルーター間でBGPが使用される場合、ネットワーク入口ノードで終了します。この場合、事業者はそのBGPトラフィックにCS6を使用するという二国間協定を締結します。
The end-to-end discussion in Section 4.2 is generally inapplicable to network control traffic -- network control traffic is generally intended to control a network, not be transported between networks. One exception is that network control traffic makes sense for a purchased transit agreement, and preservation of the CS6 DSCP marking for network control traffic that is transited is reasonable in some cases, although it is generally inappropriate to use CS6 for forwarding that traffic within the network that provides transit. Use of an IP tunnel is suggested in order to conceal the CS6 markings on transiting network control traffic from the network that provides the transit. In this case, the Pipe Model for Diffserv tunneling is used.
セクション4.2のエンドツーエンドの説明は、一般にネットワーク制御トラフィックには適用できません。ネットワーク制御トラフィックは、通常、ネットワークを制御することを目的としており、ネットワーク間で転送されることはありません。 1つの例外は、購入したトランジットアグリーメントに対してネットワーク制御トラフィックが理にかなっており、トランジットされるネットワーク制御トラフィックのCS6 DSCPマーキングを維持することが妥当な場合がありますが、ネットワーク内でそのトラフィックを転送するためにCS6を使用することは一般に不適切です。トランジットを提供します。トランジットを提供するネットワークからトランジットネットワーク制御トラフィックのCS6マーキングを隠すために、IPトンネルの使用が推奨されます。この場合、Diffservトンネリングのパイプモデルが使用されます。
If the MPLS Short Pipe Model is deployed for unencapsulated IPv4 traffic, an IP network provider should limit access to the CS6 and CS7 DSCPs, so that they are only used for network control traffic for the provider's own network.
カプセル化されていないIPv4トラフィック用にMPLSショートパイプモデルが展開されている場合、IPネットワークプロバイダーは、CS6およびCS7 DSCPへのアクセスを制限して、プロバイダー自身のネットワークのネットワーク制御トラフィックにのみ使用されるようにする必要があります。
Interconnecting carriers should specify treatment of CS6-marked traffic received at a carrier interconnection that is to be forwarded beyond the ingress node. An SLA covering the following cases is recommended when a provider wishes to send CS6-marked traffic across an interconnection link and that traffic's destination is beyond the interconnected ingress node:
相互接続キャリアは、入力ノードを越えて転送されるキャリア相互接続で受信されたCS6マーク付きトラフィックの処理を指定する必要があります。プロバイダーが相互接続リンクを介してCS6でマークされたトラフィックを送信することを希望し、そのトラフィックの宛先が相互接続された入口ノードを超えている場合は、次のケースをカバーするSLAが推奨されます。
o classification of traffic that is network control traffic for both domains. This traffic should be classified and marked for the CS6 DSCP.
o 両方のドメインのネットワーク制御トラフィックであるトラフィックの分類。このトラフィックは、CS6 DSCP用に分類およびマークする必要があります。
o classification of traffic that is network control traffic for the sending domain only. This traffic should be forwarded with a PHB that is appropriate for transiting NC service class traffic [RFC4594] in the receiving domain, e.g., AF31 as specified by this document. As an example, GSMA IR.34 recommends an Interactive class / AF31 to carry SIP and DIAMETER traffic. While this is service control traffic of high importance to interconnected Mobile Network Operators, it is certainly not network control traffic for a fixed network providing transit among such operators and hence should not receive CS6 treatment in such a transit network.
o 送信ドメインのみのネットワーク制御トラフィックであるトラフィックの分類。このトラフィックは、このドキュメントで指定されているAF31などの受信ドメインでNCサービスクラストラフィック[RFC4594]を通過するのに適したPHBで転送する必要があります。例として、GSMA IR.34は、SIPおよびDIAMETERトラフィックを伝送するためにInteractiveクラス/ AF31を推奨しています。これは相互接続されたモバイルネットワーク事業者にとって非常に重要なサービス制御トラフィックですが、そのような事業者間のトランジットを提供する固定ネットワークのネットワーク制御トラフィックではないため、このようなトランジットネットワークでCS6処理を受信することはできません。
o any other CS6-marked traffic should be re-marked or dropped.
o その他のCS6でマークされたトラフィックは、再マークまたはドロップする必要があります。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
The DSCP field in the IP header can expose additional traffic classification information at network interconnections by comparison to the use of a zero DSCP for all interconnect traffic. If traffic classification information is sensitive, the DSCP field could be re-marked to zero to hide the classification as a countermeasure, at the cost of loss of Diffserv information and differentiated traffic handling on the interconnect and subsequent networks. When AF PHBs are used, any such re-marking should respect AF PHB group boundaries as further discussed at the end of Section 4.
IPヘッダーのDSCPフィールドは、すべての相互接続トラフィックでのゼロDSCPの使用と比較して、ネットワーク相互接続で追加のトラフィック分類情報を公開できます。トラフィック分類情報が機密である場合、DSCPフィールドをゼロに再マークして、分類として対策を隠すことができます。ただし、Diffserv情報が失われ、相互接続と後続のネットワークでのトラフィック処理が区別されます。 AF PHBを使用する場合、セクション4の最後でさらに説明するように、そのような再マーキングはAF PHBグループの境界を尊重する必要があります。
This document does not introduce new features; it describes how to use existing ones. The Diffserv security considerations in [RFC2475] and [RFC4594] apply.
このドキュメントでは新機能を紹介していません。既存のものを使用する方法について説明します。 [RFC2475]と[RFC4594]のDiffservセキュリティに関する考慮事項が適用されます。
[RFC2474] 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, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<http://www.rfc-editor.org/info/rfc2474>。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, <http://www.rfc-editor.org/info/rfc2597>.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、DOI 10.17487 / RFC2597、1999年6月、<http：//www.rfc- editor.org/info/rfc2597>。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, <http://www.rfc-editor.org/info/rfc3246>.
[RFC3246]デイビー、B、チャーニー、A、ベネット、J、ベンソン、K、ルブーデック、J、コートニー、W、ダヴァリ、S、フィロイ、V、およびDスティリアディス、 Expedited Forwarding PHB（Per-Hop Behavior）」、RFC 3246、DOI 10.17487 / RFC3246、2002年3月、<http://www.rfc-editor.org/info/rfc3246>。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, <http://www.rfc-editor.org/info/rfc3270>.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P.、J. Heinanen、 "マルチプロトコルラベルスイッチング（MPLS）Support of Differentiated Services」、RFC 3270、DOI 10.17487 / RFC3270、2002年5月、<http://www.rfc-editor.org/info/rfc3270>。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, <http://www.rfc-editor.org/info/rfc5129>.
[RFC5129]デイビー、B。、ブリスコー、B。、およびJ.テイ、「MPLSでの明示的輻輳マーキング」、RFC 5129、DOI 10.17487 / RFC5129、2008年1月、<http://www.rfc-editor.org/ info / rfc5129>。
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, <http://www.rfc-editor.org/info/rfc5865>.
[RFC5865]ベイカー、F。、ポーク、J。、およびM.ドリー、「Capacity-Admitted TrafficのDiffServコードポイント（DSCP）」、RFC 5865、DOI 10.17487 / RFC5865、2010年5月、<http：// www.rfc-editor.org/info/rfc5865>。
[BGP-INTERCONNECTION] Knoll, T., "BGP Class of Service Interconnection", Work in Progress, draft-knoll-idr-cos-interconnect-17, November 2016.
[BGP-INTERCONNECTION]ノールT。、「BGPサービスクラスの相互接続」、作業中、draft-knoll-idr-cos-interconnect-17、2016年11月。
[IR.34] GSMA, "Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines)", Official Document IR.34, Version 11.0, November 2014, <http://www.gsma.com/newsroom/wp-content/uploads/ IR.34-v11.0.pdf>.
[IR.34] GSMA、「IPXプロバイダーネットワークのガイドライン（以前のサービスプロバイダーIPバックボーンガイドライン）」、公式ドキュメントIR.34、バージョン11.0、2014年11月、<http://www.gsma.com/newsroom/ wp-content / uploads / IR.34-v11.0.pdf>。
[MEF23.1] MEF, "Implementation Agreement MEF 23.1: Carrier Ethernet Class of Service - Phase 2", MEF 23.1, January 2012, <http://metroethernetforum.org/PDF_Documents/ technical-specifications/MEF_23.1.pdf>.
[MEF23.1] MEF、「実装契約MEF 23.1：キャリアイーサネットサービスクラス-フェーズ2」、MEF 23.1、2012年1月、<http://metroethernetforum.org/PDF_Documents/ technical-specifications / MEF_23.1.pdf> 。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<http://www.rfc-editor.org/info/rfc2475>。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <http://www.rfc-editor.org/info/rfc2983>.
[RFC2983] Black、D。、「Differentiated Services and Tunnels」、RFC 2983、DOI 10.17487 / RFC2983、2000年10月、<http://www.rfc-editor.org/info/rfc2983>。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003, <http://www.rfc-editor.org/info/rfc3662>.
[RFC3662] Bless、R.、Nichols、K。、およびK. Wehrle、「Differentiated Servicesのドメインごとの動作（PDB）の削減」、RFC 3662、DOI 10.17487 / RFC3662、2003年12月、<http：// www.rfc-editor.org/info/rfc3662>。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <http://www.rfc-editor.org/info/rfc4594>.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、DOI 10.17487 / RFC4594、2006年8月、<http://www.rfc-editor.org / info / rfc4594>。
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, February 2008, <http://www.rfc-editor.org/info/rfc5127>.
[RFC5127] Chan、K.、Babiarz、J。、およびF. Baker、「Aggregation of Diffserv Service Classes」、RFC 5127、DOI 10.17487 / RFC5127、2008年2月、<http://www.rfc-editor.org/ info / rfc5127>。
[RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March 2008, <http://www.rfc-editor.org/info/rfc5160>.
[RFC5160] Levis、P。およびM. Boucadair、「インターネットスケールのサービスの品質（QoS）に関するプロバイダー間の合意の考慮事項」、RFC 5160、DOI 10.17487 / RFC5160、2008年3月、<http：// www .rfc-editor.org / info / rfc5160>。
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <http://www.rfc-editor.org/info/rfc7657>.
[RFC7657]ブラック、D。、エド。およびP.ジョーンズ、「Differentiated Services（Diffserv）and Real-Time Communication」、RFC 7657、DOI 10.17487 / RFC7657、2015年11月、<http://www.rfc-editor.org/info/rfc7657>。
[SLA-EXCHANGE] Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M. Boucadair, "Inter-domain SLA Exchange Attribute", Work in Progress, draft-ietf-idr-sla-exchange-10, January 2017.
[SLA-EXCHANGE] Shah、S.、Patel、K.、Bajaj、S.、Tomotaki、L。、およびM. Boucadair、「ドメイン間SLA交換属性」、作業中、draft-ietf-idr-sla -exchange-10、2017年1月。
[Y.1566] ITU-T, "Quality of service mapping and interconnection between Ethernet, Internet protocol and multiprotocol label switching networks", ITU-T Recommendation Y.1566, July 2012, <http://www.itu.int/rec/T-REC-Y.1566-201207-I/en>.
[Y.1566] ITU-T、「イーサネット、インターネットプロトコル、マルチプロトコルラベルスイッチングネットワーク間のサービス品質マッピングと相互接続」、ITU-T勧告Y.1566、2012年7月、<http://www.itu.int/ rec / T-REC-Y.1566-201207-I / en>。
The MPLS Short Pipe Model (or penultimate hop label popping) is widely deployed in carrier networks. If unencapsulated IP traffic is transported using MPLS Short Pipe, IP headers appear inside the last section of the MPLS domain. This impacts the number of PHBs and DSCPs that a network provider can reasonably support. See Figure 2 for an example.
MPLSショートパイプモデル（または最後から2番目のホップラベルのポップ）は、キャリアネットワークで広く展開されています。カプセル化されていないIPトラフィックがMPLSショートパイプを使用して転送される場合、IPヘッダーはMPLSドメインの最後のセクション内に表示されます。これは、ネットワークプロバイダーが合理的にサポートできるPHBとDSCPの数に影響します。例については、図2を参照してください。
For encapsulated IP traffic, only the outer tunnel header is relevant for forwarding. If the tunnel does not terminate within the MPLS network section, only the outer tunnel DSCP is involved, as the inner DSCP does not affect forwarding behavior; in this case, all DSCPs could be used in the inner IP header without affecting network behavior based on the outer MPLS header. Here, the Pipe Model applies.
カプセル化されたIPトラフィックの場合、外部トンネルヘッダーのみが転送に関連します。トンネルがMPLSネットワークセクション内で終了しない場合、内部DSCPは転送動作に影響しないため、外部トンネルDSCPのみが関係します。この場合、外部MPLSヘッダーに基づくネットワークの動作に影響を与えることなく、すべてのDSCPを内部IPヘッダーで使用できます。ここでは、パイプモデルが適用されます。
Layer 2 and Layer 3 VPN traffic all use an additional MPLS label; in this case, the MPLS tunnel follows the Pipe Model. Classification and queuing within an MPLS network is always based on an MPLS label, as opposed to the outer IP header.
レイヤ2およびレイヤ3 VPNトラフィックはすべて、追加のMPLSラベルを使用します。この場合、MPLSトンネルはパイプモデルに従います。 MPLSネットワーク内での分類とキューイングは、外部IPヘッダーではなく、常にMPLSラベルに基づいています。
Carriers often select PHBs and DSCPs without regard to interconnection. As a result, PHBs and DSCPs typically differ between network carriers. With the exception of best-effort traffic, a DSCP change should be expected at an interconnection at least for unencapsulated IP traffic, even if the PHB is suitably mapped by the carriers involved.
通信事業者は、相互接続に関係なく、PHBとDSCPを選択することがよくあります。その結果、PHBとDSCPは通常、ネットワークキャリア間で異なります。ベストエフォートトラフィックを除いて、PHBが関係するキャリアによって適切にマッピングされている場合でも、少なくともカプセル化されていないIPトラフィックの相互接続でDSCPの変更が予想されます。
Although RFC 3270 suggests that the Short Pipe Model is only applicable to VPNs, current networks also use it to transport non-tunneled IPv4 traffic. This is shown in Figure 2 where Diffserv-Intercon is not used, resulting in exposure of the internal DSCPs of the upstream network to the downstream network across the interconnection.
RFC 3270は、ショートパイプモデルはVPNにのみ適用可能であると提案していますが、現在のネットワークでは、トンネル化されていないIPv4トラフィックの転送にも使用されています。これは、Diffserv-Interconが使用されていない図2に示されています。その結果、相互接続を介してアップストリームネットワークの内部DSCPがダウンストリームネットワークに公開されます。
|
\|/ IPv4, DSCP_send
V
|
Peering Router
|
\|/ IPv4, DSCP_send
V
|
MPLS Edge Router
| Mark MPLS Label, TC_internal
\|/ Re-mark DSCP to
V (Inner: IPv4, DSCP_d)
|
MPLS Core Router (penultimate hop label popping)
| \
| IPv4, DSCP_d | The DSCP needs to be in network-
| ^^^^^^^^| internal Diffserv context. The Core
\|/ > Router may require or enforce
V | that. The Edge Router may wrongly
| | classify, if the DSCP is not in
| / network-internal Diffserv context.
MPLS Edge Router
| \ Traffic leaves the network marked
\|/ IPv4, DSCP_d | with the network-internal
V > DSCP_d that must be dealt with
| | by the next network (downstream).
| /
Peer Router
| Re-mark DSCP to
\|/ IPv4, DSCP_send
V
|
Figure 2: Short Pipe Model / Penultimate Hop Popping Example
図2：ショートパイプモデル/最後から2番目のホップポップの例
The packet's IP DSCP must be in a well-understood Diffserv context for schedulers and classifiers on the interfaces of the ultimate MPLS link (last link traversed before leaving the network). The necessary Diffserv context is network-internal, and a network operating in this mode enforces DSCP usage in order to obtain robust differentiated forwarding behavior.
パケットのIP DSCPは、最終的なMPLSリンク（ネットワークを離れる前に最後に通過したリンク）のインターフェース上のスケジューラーと分類子のために十分に理解されたDiffservコンテキスト内にある必要があります。必要なDiffservコンテキストはネットワーク内部であり、このモードで動作するネットワークはDSCPの使用を強制して、堅牢な差別化転送動作を実現します。
Without Diffserv-Intercon treatment, the traffic is likely to leave each network marked with network-internal DSCP. DSCP_send in the figure above has to be re-marked into the first network's Diffserv scheme at the ingress MPLS Edge Router, to DSCP_d in the example.
Diffserv-Intercon処理がないと、トラフィックはネットワーク内部DSCPでマークされた各ネットワークを離れる可能性があります。上の図のDSCP_sendは、入力MPLSエッジルーターで最初のネットワークのDiffservスキームにマークを付け直す必要があり、例ではDSCP_dになります。
For that reason, the traffic leaves this domain marked by the network-internal DSCP_d. This structure requires that every carrier deploys per-peer PHB and DSCP mapping schemes.
そのため、トラフィックはnetwork-internal DSCP_dでマークされたこのドメインを離れます。この構造では、すべてのキャリアがピアごとのPHBおよびDSCPマッピングスキームを展開する必要があります。
If Diffserv-Intercon is applied, DSCPs for traffic transiting the domain can be mapped from and remapped to an original DSCP. This is shown in Figure 3. Internal traffic may continue to use internal DSCPs (e.g., DSCP_d), and they may also be used between a carrier and its direct customers.
Diffserv-Interconが適用されている場合、ドメインを通過するトラフィックのDSCPは、元のDSCPからマッピングおよび再マッピングできます。これを図3に示します。内部トラフィックは引き続き内部DSCP（DSCP_dなど）を使用する場合があり、キャリアとその直接の顧客の間で使用される場合もあります。
Internal Router
|
| Outer Header
\|/ IPv4, DSCP_send
V
|
Peering Router
| Re-mark DSCP to
\|/ IPv4, DSCP_ds-int Diffserv-Intercon DSCP and PHB
V
|
MPLS Edge Router
|
| Mark MPLS Label, TC_internal
\|/ Re-mark DSCP to
V (Inner: IPv4, DSCP_d) Domain Internal DSCP for
| the PHB
MPLS Core Router (penultimate hop label popping)
|
| IPv4, DSCP_d
| ^^^^^^
\|/
V
|
|
MPLS Edge Router--------------------+
| |
\|/ Re-mark DSCP to \|/ IPv4, DSCP_d
V IPv4, DSCP_ds-int V
| |
| |
Peer Router Domain Internal Broadband
| Access Router
\|/ Re-mark DSCP to \|/
V IPv4, DSCP_send V IPv4, DSCP_d
| |
Figure 3: Short Pipe Model Example with Diffserv-Intercon
図3：Diffserv-Interconを使用したショートパイプモデルの例
Acknowledgements
謝辞
Bob Briscoe and Gorry Fairhurst reviewed this specification and provided rich feedback. Brian Carpenter, Fred Baker, Al Morton, and Sebastien Jobert discussed the specification and helped improve it. Mohamed Boucadair and Thomas Knoll helped by adding awareness of related work. James Polk's discussion during IETF 89 helped to improve the text on the relation of this specification to RFCs 4594 and 5127.
Bob BriscoeとGorry Fairhurstがこの仕様をレビューし、豊富なフィードバックを提供しました。ブライアンカーペンター、フレッドベイカー、アルモートン、およびセバスチャンジョベールが仕様について議論し、仕様の改善に貢献しました。 Mohamed BoucadairとThomas Knollは、関連する仕事に対する意識を高めることで助けました。 IETF 89でのJames Polkの議論は、この仕様とRFC 4594および5127との関係に関するテキストを改善するのに役立ちました。
Authors' Addresses
著者のアドレス
Ruediger Geib (editor) Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany
Ruediger Geib（編集者）Deutsche Telekom Heinrich Hertz Str。 3-7ダルムシュタット64295ドイツ
Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de
David L. Black Dell EMC 176 South Street Hopkinton, MA United States of America
デビッドL.ブラックDell EMC 176サウスストリートホプキントン、マサチューセッツ州アメリカ合衆国
Phone: +1 (508) 293-7953
Email: david.black@dell.com