[要約] RFC 5129は、MPLSネットワークでの明示的な輻輳マーキングに関する標準化されたガイドラインです。その目的は、MPLSネットワークでの輻輳制御を改善し、ネットワークのパフォーマンスと信頼性を向上させることです。
Network Working Group B. Davie
Request for Comments: 5129 Cisco Systems, Inc.
Category: Standards Track B. Briscoe
J. Tay
BT Research
January 2008
Explicit Congestion Marking in MPLS
MPLSでの明示的なうっ血マーキング
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses.
RFC 3270は、MPLSヘッダーでDiffServコードポイント（DSCPS）をエンコードする方法など、MPLSネットワークのDiffServアーキテクチャをサポートする方法を定義します。DSCPはEXPフィールドにエンコードされる場合がありますが、そのフィールドの他の使用は排除されません。RFC 3270は、MPLSヘッダーで明示的な輻輳通知（ECN）マーキングがどのようにエンコードされるかについて声明を発表しません。このドキュメントでは、他の用途を排除することなく、オペレーターが明示的な輻輳通知のためのEXPコードポイントの一部をどのように定義するかを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use of MPLS EXP Field for ECN . . . . . . . . . . . . . . . . 5
3. Per-Domain ECT Checking . . . . . . . . . . . . . . . . . . . 7
4. ECN-Enabled MPLS Domain . . . . . . . . . . . . . . . . . . . 8
4.1. Pushing (Adding) One or More Labels to an IP Packet . . . 8
4.2. Pushing One or More Labels onto an MPLS Labeled Packet . . 8
4.3. Congestion Experienced in an Interior MPLS Node . . . . . 8
4.4. Crossing a Diffserv Domain Boundary . . . . . . . . . . . 8
4.5. Popping an MPLS Label (Not the End of the Stack) . . . . . 9
4.6. Popping the Last MPLS Label in the Stack . . . . . . . . . 9
4.7. Diffserv Tunneling Models . . . . . . . . . . . . . . . . 10
5. ECN-Disabled MPLS Domain . . . . . . . . . . . . . . . . . . . 10
6. The Use of More Codepoints with E-LSPs and L-LSPs . . . . . . 10
7. Relationship to Tunnel Behavior in RFC 3168 . . . . . . . . . 11
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 11
8.1. Marking Non-ECN-Capable Packets . . . . . . . . . . . . . 11
8.2. Non-ECN-Capable Routers in an MPLS Domain . . . . . . . . 12
9. Example Uses . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. RFC 3168-Style ECN . . . . . . . . . . . . . . . . . . . . 13
9.2. ECN Co-Existence with Diffserv E-LSPs . . . . . . . . . . 13
9.3. Congestion-Feedback-Based Traffic Engineering . . . . . . 14
9.4. PCN Flow Admission Control and Flow Termination . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Extension to Pre-Congestion Notification . . . . . . 16
A.1. Label Push onto IP Packet . . . . . . . . . . . . . . . . . 16
A.2. Pushing Additional MPLS Labels . . . . . . . . . . . . . . 16
A.3. Admission Control or Flow Termination Marking Inside
MPLS Domain . . . . . . . . . . . . . . . . . . . . . . . . 17
A.4. Popping an MPLS Label (Not End of Stack) . . . . . . . . . 17
A.5. Popping the Last MPLS Label to Expose IP Header . . . . . . 17
Normative References . . . . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . . . . 18
[RFC3168] defines Explicit Congestion Notification (ECN) for IP. The primary purpose of ECN is to allow congestion to be signalled without dropping packets.
[RFC3168]は、IPの明示的なうっ血通知（ECN）を定義します。ECNの主な目的は、パケットをドロップせずにうっ血を信号することを許可することです。
[RFC3270] defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header.
[RFC3270]は、MPLSヘッダーでDiffServコードポイント（DSCPS）をエンコードする方法など、MPLSネットワークのDiffServアーキテクチャをサポートする方法を定義します。DSCPはEXPフィールドにエンコードされる場合がありますが、そのフィールドの他の使用は排除されません。RFC 3270は、MPLSヘッダーで明示的な輻輳通知（ECN）マーキングがどのようにエンコードされるかについて声明を発表しません。
This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. In parallel to the activity defining the addition of ECN to IP [RFC3168], two proposals were made to add ECN to MPLS [Floyd][Shayman]. These proposals, however, fell by the wayside. With ECN for IP now being a proposed standard, and developing interest in using pre-congestion notification (PCN) for admission control and flow termination [PCN], there is consequent interest in being able to support ECN across IP networks consisting of MPLS-enabled domains. Therefore, it is necessary to specify the protocol for including ECN in the MPLS shim header and the protocol behavior of edge MPLS nodes.
このドキュメントでは、他の用途を排除することなく、オペレーターが明示的な輻輳通知のためのEXPコードポイントの一部をどのように定義するかを定義します。IP [RFC3168]へのECNの追加を定義するアクティビティと並行して、MPLS [Floyd] [Shayman]にECNを追加する2つの提案が行われました。しかし、これらの提案は道端に落ちました。IPのECNが現在提案されている標準であり、入学制御とフロー終了[PCN]に事前相合通知（PCN）を使用することに関心を抱いているため、MPLS対応のIPネットワーク全体でECNをサポートできることには関心があります。ドメイン。したがって、MPLSシムヘッダーにECNを含めるためのプロトコルとEDGE MPLSノードのプロトコル挙動を指定する必要があります。
We note that in [RFC3168], there are four codepoints used for ECN marking, which are encoded using two bits of the IP header. The MPLS EXP field is the logical place to encode ECN codepoints, but with only 3 bits (8 codepoints) available, and with the same field being used to convey DSCP information as well, there is a clear incentive to conserve the number of codepoints consumed for ECN purposes. Efficient use of the EXP field has been a focus of prior documents [Floyd] [Shayman], and we draw on those efforts in this document as well.
[RFC3168]には、ECNマーキングに使用される4つのコードポイントがあり、IPヘッダーの2ビットを使用してエンコードされていることに注意してください。MPLS EXPフィールドは、ECNコードポイントをエンコードする論理的な場所ですが、利用可能な3ビット（8コードポイント）のみがあり、同じフィールドがDSCP情報を伝えるために使用されているため、消費されるコードポイントの数を節約する明確なインセンティブがあります。ECNの目的で。EXPフィールドの効率的な使用は、以前の文書[Floyd] [Shayman]の焦点であり、この文書でもこれらの努力を利用しています。
We also note that [RFC3168] defines default usage of the ECN field, but it allows for the possibility that some Diffserv Per Hop Behaviors (PHBs) might include different specifications on how the ECN field is to be used. This document seeks to preserve that capability.
また、[RFC3168]はECNフィールドのデフォルト使用法を定義していることにも注意しますが、HOPごとの動作（PHB）の一部がECNフィールドの使用方法に関するさまざまな仕様を含める可能性があります。このドキュメントは、その機能を維持しようとしています。
Our intent is to specify how the MPLS shim header [RFC3032] should denote ECN marking and how MPLS nodes should understand whether the transport for a packet will be ECN capable. We offer this as a building block, from which to build different congestion-notification systems. We do not intend to specify how the resulting congestion notification is fed back to an upstream node that can mitigate congestion. For instance, unlike [Shayman], we do not specify edge-to-edge MPLS domain feedback, but we also do not preclude it. Nonetheless, we do specify how the egress node of an MPLS domain should copy congestion notification from the MPLS shim into the encapsulated IP header if the ECN is to be carried onward towards the IP receiver; but we do *not* mandate that MPLS congestion notification must be copied into the IP header for onward transmission. This document aims to be generic for any use of congestion notification in MPLS. Support of [RFC3168] is our primary motivation; some additional potential applications to illustrate the flexibility of our approach are described in Section 9. In particular, we aim to support possible future schemes that may use more than one level of congestion marking.
私たちの意図は、MPLSシムヘッダー[RFC3032]がECNマーキングを示す方法と、PacketのトランスポートがECN能力になるかどうかをMPLSノードを理解する方法を指定することです。これをビルディングブロックとして提供し、そこから異なる混雑解釈システムを構築します。結果として生じる混雑通知が、混雑を軽減できるアップストリームノードにどのように供給されるかを指定するつもりはありません。たとえば、[Shayman]とは異なり、Edge-to-EdgeのMPLSドメインフィードバックを指定するわけではありませんが、排除することもできません。それにもかかわらず、ECNがIPレシーバーに向かって前方に運ばれる場合、MPLSドメインの出力ノードがMPLSシムからカプセル化されたIPヘッダーに混雑通知をコピーする方法を指定します。ただし、MPLS輻輳通知をIPヘッダーにコピーして、前向きに送信する必要があることを義務付けていません。このドキュメントは、MPLSでの混雑通知を使用するために一般的であることを目的としています。[RFC3168]のサポートは私たちの主な動機です。アプローチの柔軟性を説明するためのいくつかの追加の潜在的なアプリケーションについては、セクション9で説明します。特に、複数のレベルの混雑マーキングを使用する可能性のある将来のスキームをサポートすることを目指しています。
This document draws freely on the terminology of ECN [RFC3168] and MPLS [RFC3031]. For ease of reference, we have included some definitions here, but refer the reader to the references above for complete specifications of the relevant technologies:
この文書は、ECN [RFC3168]およびMPLS [RFC3031]の用語を自由に描画します。参照のために、ここにいくつかの定義を含めましたが、関連するテクノロジーの完全な仕様については、上記の参照を読者に参照してください。
o CE: Congestion Experienced. One of the states with which a packet may be marked in a network supporting ECN. A packet is marked in this state by an ECN-capable router to indicate that this router was experiencing congestion at the time the packet arrived.
o CE：混雑が発生しました。パケットがECNをサポートするネットワークでマークされる状態の1つ。この状態では、この状態でECN対応のルーターによってマークされており、このルーターがパケットが到着した時点で混雑を経験していたことを示しています。
o ECT: ECN-capable Transport. One of the ECN states that a packet may be in when it is sent by an end system. An end system marks a packet with an ECT codepoint to indicate that the endpoints of the transport protocol are ECN-capable. A router may not mark a packet as CE unless the packet was marked ECT when it arrived.
o ECT：ECN対応輸送。ECNの1つは、パケットがエンドシステムによって送信されるときにある可能性があると述べています。エンドシステムは、ECTコードポイントを備えたパケットをマークして、トランスポートプロトコルのエンドポイントがECN対応であることを示します。ルーターは、パケットが到着時にエクトとマークされていない限り、パケットをCEとしてマークすることはできません。
o Not-ECT: Not ECN-capable transport. An end system marks a packet with this codepoint to indicate that the endpoints of the transport protocol are not ECN-capable. A congested router cannot mark such packets as CE, and thus it can only drop them to indicate congestion.
o not-ect：ECN対応輸送ではありません。エンドシステムは、このコードポイントを使用したパケットをマークして、輸送プロトコルのエンドポイントがECN対応ではないことを示します。混雑したルーターは、そのようなパケットをCEとしてマークすることはできないため、混雑を示すためにドロップするだけです。
o EXP field. A 3-bit field in the MPLS label header [RFC3032] that may be used to convey Diffserv information (and is also used in this document to carry ECN information).
o Expフィールド。MPLSラベルヘッダー[RFC3032]の3ビットフィールドは、DiffServ情報を伝えるために使用できます（このドキュメントでもECN情報を伝達するために使用されます）。
o PHP. Penultimate Hop Popping. An MPLS operation in which the penultimate Label Switching Router (LSR) on a Label Switched Path (LSP) removes the top label from the packet before forwarding the packet to the final LSR on the LSP.
o Php。最後から2番目のホップポップ。ラベルスイッチ付きパス（LSP）の最後から2番目のラベルスイッチングルーター（LSR）がパケットからトップラベルを削除するMPLS操作は、LSPの最終LSRにパケットを転送します。
Requirements Language
要件言語
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
We propose that LSRs configured for explicit congestion notification should use the EXP field in the MPLS shim header. However, [RFC3270] already defines use of codepoints in the EXP field for differentiated services. Although it does not preclude other compatible uses of the EXP field, this clearly seems to limit the space available for ECN, given the field is only 3 bits (8 codepoints).
明示的な輻輳通知用に構成されたLSRSは、MPLSシムヘッダーのEXPフィールドを使用する必要があることを提案します。ただし、[RFC3270]は、差別化されたサービスのEXPフィールドでのコードポイントの使用をすでに定義しています。EXPフィールドの他の互換性のある使用を排除することはありませんが、フィールドが3ビット（8コードポイント）のみであることを考えると、ECNが利用できるスペースが明らかに制限されているようです。
[RFC3270] defines two possible approaches for requesting differentiated service treatment from an LSR:
[RFC3270]は、LSRから差別化されたサービス処理を要求するための2つの可能なアプローチを定義しています。
o In the EXP-Inferred-PSC LSP (E-LSP) approach, different codepoints of the EXP field in the MPLS shim header are used to indicate the packet's per hop behavior (PHB).
o Exp Inferred-PSC LSP（E-LSP）アプローチでは、MPLSシムヘッダーのEXPフィールドの異なるコードポイントを使用して、パケットごとのホップ動作（PHB）を示します。
o In the Label-Only-Inferred-PSC LSP (L-LSP) approach, an MPLS label is assigned for each PHB scheduling class (PSC, as defined in [RFC3260], so that an LSR determines both its forwarding and its scheduling behavior from the label.
o ラベルのみの有力PSC LSP（L-LSP）アプローチでは、各PHBスケジューリングクラス（[RFC3260]で定義されているPHBスケジューリングクラス）にMPLSラベルが割り当てられているため、LSRは転送とスケジューリング動作の両方を決定します。ラベル。
If an MPLS domain uses the L-LSP approach, there is likely to be space in the EXP field for ECN codepoint(s). Where the E-LSP approach is used, codepoint space in the EXP field is likely to be scarce. This document focuses on interworking ECN marking with the E-LSP approach, as it is the tougher problem. Consequently, the same approach can also be applied with L-LSPs.
MPLSドメインがL-LSPアプローチを使用している場合、ECN CodePointのEXPフィールドにスペースがある可能性があります。E-LSPアプローチが使用される場合、EXPフィールドのコードポイントスペースは不足している可能性があります。このドキュメントは、E-LSPアプローチとの相互作用のECNマークに焦点を当てています。これは、より厳しい問題であるためです。したがって、L-LSPで同じアプローチを適用することもできます。
We recommend that explicit congestion notification in MPLS should use codepoints instead of bits in the EXP field. Since not every PHB will necessarily require an associated ECN codepoint, it would be wasteful to assign a dedicated bit for ECN. (There may also be cases where a given PHB might need more than one ECN-like codepoint; see Section 9.4 for an example).
MPLSの明示的な混雑通知は、EXPフィールドのビットではなくコードポイントを使用することをお勧めします。すべてのPHBが必ずしも関連するECNコードポイントを必要とするわけではないため、ECNに専用ビットを割り当てることは無駄です。（特定のPHBが複数のECN様コードポイントを必要とする場合もあります。例については、セクション9.4を参照してください）。
For each PHB that uses ECN marking, we assume one EXP codepoint will be defined as not congestion marked (Not-CM), and at least one other codepoint will be defined as congestion marked (CM). Therefore, each PHB that uses ECN marking will consume at least two EXP codepoints, but PHBs that do not use ECN marking will only consume one.
ECNマーキングを使用する各PHBについて、1つのExp CodePointが輻輳がマークされていない（not-cm）と定義されると仮定し、少なくとも1つの他のコードポイントは輻輳マーク（cm）として定義されます。したがって、ECNマーキングを使用する各PHBは、少なくとも2つのEXPコードポイントを消費しますが、ECNマーキングを使用しないPHBは1つだけ消費します。
Further, we wish to use minimal space in the MPLS shim header to tell interior LSRs whether each packet will be received by an ECN-capable transport (ECT). Nonetheless, we must ensure that an endpoint that would not understand an ECN mark will not receive one, otherwise it will not be able to respond to congestion as it should. In the past, three solutions to this problem have been proposed:
さらに、MPLSシムヘッダーの最小スペースを使用して、各パケットがECN対応輸送（ECT）によって受信されるかどうかをインテリアLSRに伝えたいと考えています。それにもかかわらず、ECNマークがそれを受け取らないことを理解していないエンドポイントがそれを受け取らないことを保証する必要があります。そうしないと、渋滞に対応することはできません。過去には、この問題に対する3つの解決策が提案されています。
o One possible approach is for congested LSRs to mark the ECN field in the underlying IP header at the bottom of the label stack. Although many commercial LSRs routinely access the IP header for other reasons (equal cost multi-path - ECMP), there are numerous drawbacks to attempting to find an IP header beneath an MPLS label stack. Notably, there is the challenge of detecting the absence of an IP header when non-IP packets are carried on an LSP. Therefore, we will not consider this approach further.
o 考えられるアプローチの1つは、混雑したLSRが、ラベルスタックの下部にある基礎となるIPヘッダーのECNフィールドをマークすることです。多くの商用LSRは、他の理由（同等のコストマルチパス-ECMP）で日常的にIPヘッダーにアクセスしますが、MPLSラベルスタックの下にIPヘッダーを見つけようとするには多くの欠点があります。特に、非IPパケットがLSPで運ばれる場合、IPヘッダーの不在を検出するという課題があります。したがって、このアプローチはこれ以上検討しません。
o In the scheme suggested by [Floyd], ECT and CE are overloaded into one bit, so that a 0 means ECT while a 1 might either mean Not-ECT or it might mean CE. A packet that has been marked as having experienced congestion upstream, and then is picked out for marking at a second congested LSR, will be dropped by the second LSR since it cannot determine whether the packet has previously experienced congestion or if ECN is not supported by the transport.
o [Floyd]によって提案されたスキームでは、ECTとCEが1ビットに過負荷になります。上流の混雑を経験したとマークされたパケットは、2番目の混雑したLSRでマークするために選ばれますが、パケットが以前に混雑を経験したかどうか、またはECNがサポートされていないかどうかを判断できないため、2番目のLSRによって削除されます。輸送。
While such an approach seemed potentially palatable, we do not recommend it here for the following reasons. In some cases, we wish to be able to use ECN marking long before actual congestion (e.g., pre-congestion notification). In these circumstances, marking rates at each LSR might be non-negligible most of the time, so the chances of a previously marked packet encountering an LSR that wants to mark it again will also be non-negligible. In the case where CE and not-ECT are indistinguishable to core routers, such a scenario could lead to unacceptable drop rates. If the typical marking rate at every router or LSR is p, and the typical diameter of the network of LSRs is d, then the probability that a marked packet will be chosen for marking more than once is 1-[Pr(never marked) + Pr(marked at exactly one hop)] = 1- [(1-p)^d + dp(1-p)^(d-1)]. For instance, with 6 LSRs in a row, each marking ECN with 1% probability, the chances of a packet that is already marked being chosen for marking a second time is 0.15%. The bit-overloading scheme would therefore introduce a drop rate of 0.15% unnecessarily. Given that most modern core networks are sized to introduce near-zero packet drop, it may be unacceptable to drop over one in a thousand packets unnecessarily.
このようなアプローチは潜在的に味が良いように見えましたが、以下の理由でここではお勧めしません。場合によっては、実際の輻輳のずっと前にECNマーキングを使用できるようにすることを望んでいます（例：前後通知）。これらの状況では、ほとんどの場合、各LSRでのマーキングレートは無視できない可能性があるため、以前にマークされたパケットが再びマークを付けたいLSRに遭遇する可能性もありません。CEおよびNot-ectがコアルーターと見分けがつかない場合、このようなシナリオは容認できないドロップレートにつながる可能性があります。すべてのルーターまたはLSRでの典型的なマーキングレートがPであり、LSRのネットワークの典型的な直径がDである場合、マークされたパケットが1- [PR（マークされていない）PRが1- [Marked）PRであるためにマークされたパケットが選択される確率は（正確に1つのホップでマークされます）] = 1- [（1-p）^d dp（1-p）^（d-1）]。たとえば、6つのLSRが連続して、それぞれが1％の確率でECNをマークすると、すでにマークされているパケットの可能性は0.15％です。したがって、ビットオーバーロードスキームは、不必要に0.15％のドロップレートを導入します。近代的なコアネットワークのほとんどがゼロ近くのパケットドロップを導入するサイズのサイズであるため、1000個のパケットを不必要にドロップすることは受け入れられない場合があります。
o A third possible approach was suggested by [Shayman]. In this scheme, interior LSRs assume that the endpoints are ECN-capable, but this assumption is checked when the final label is popped. If an interior LSR has marked ECN in the EXP field of the shim header, but the IP header says the endpoints are not ECN-capable, the edge router (or penultimate router, if using penultimate hop popping) drops the packet. We recommend this scheme, which we call `per-domain ECT checking', and define it more precisely in the following section. Its chief drawback is that it can cause packets to be forwarded after encountering congestion only to be dropped at the egress of the MPLS domain. The rationale for this decision is given in Section 8.1.
o [Shayman]によって3番目の可能なアプローチが提案されました。このスキームでは、インテリアLSRはエンドポイントがECN対応であると想定していますが、この仮定は最終ラベルがポップされたときにチェックされます。インテリアLSRがShimヘッダーのEXPフィールドでECNをマークしたが、IPヘッダーはエンドポイントがECN対応ではないと述べている場合、エッジルーター（または最後から2番目のルーター、ペノアルティテーションホップポップを使用する場合）はパケットをドロップします。このスキームをお勧めします。このスキームは、「ドメインあたりECTチェック」と呼ばれ、次のセクションでより正確に定義します。その主な欠点は、MPLSドメインの出口でのみ輻輳に遭遇した後にパケットを転送する可能性があることです。この決定の理論的根拠は、セクション8.1に記載されています。
For the purposes of this discussion, we define the egress nodes of an MPLS domain as the nodes that pop the last MPLS label from the label stack, exposing the IP (or, potentially non-IP) header. Note that such a node may be the ultimate or penultimate hop of an LSP, depending on whether penultimate hop popping (PHP) is employed.
この議論の目的のために、MPLSドメインの出力ノードをラベルスタックから最後のMPLSラベルをポップするノードとして定義し、IP（または潜在的に非IP）ヘッダーを公開します。このようなノードは、最後から2番目のホップポップ（PHP）が採用されているかどうかに応じて、LSPの究極または最後から2番目のホップである可能性があることに注意してください。
In the per-domain ECT checking approach, the egress nodes take responsibility for checking whether the transport is ECN-capable. This document does not specify how these nodes should pass on congestion notification because different approaches are likely in different scenarios. However, if congestion notification in the MPLS header is copied into the IP header, the procedure MUST conform to the specification given here.
ドメインごとのECTチェックアプローチでは、出力ノードは輸送がECN対応かどうかを確認する責任を負います。このドキュメントでは、さまざまなシナリオで異なるアプローチが可能性が高いため、これらのノードが混雑通知にどのように渡すべきかを指定していません。ただし、MPLSヘッダーの混雑通知がIPヘッダーにコピーされた場合、手順はここに示されている仕様に準拠する必要があります。
If congestion notification is passed to the transport without first passing it onward in the IP header, the approach used must take similar care to check that the transport is ECN-capable before passing it ECN markings. Specifically, if the transport for a particular congestion marked MPLS packet is found not to be ECN-capable, the packet MUST be dropped at this egress node.
IPヘッダーに最初に渡さずに輸送通知が輸送に渡される場合、使用されるアプローチは、ECNマークを通過する前に輸送がECN対応であることを確認するために同様の注意を払わなければなりません。具体的には、MPLSパケットとマークされた特定の輻輳の輸送がECN対応ではないことがわかった場合、この出口ノードでパケットをドロップする必要があります。
In the per-domain ECT checking approach, only the egress nodes check whether an IP packet is destined for an ECN-capable transport. Therefore, any single LSR within an MPLS domain MUST NOT be configured to enable ECN marking unless all the egress LSRs surrounding it are already configured to handle ECN marking.
ドメインあたりのECTチェックアプローチでは、出力ノードのみがIPパケットがECN対応トランスポートに向けられているかどうかを確認します。したがって、MPLSドメイン内の単一のLSRは、ECNマーキングを囲むすべての出力LSRが既に構成されていない限り、ECNマーキングを有効にするように構成する必要はありません。
We call a domain surrounded by ECN-capable egress LSRs an ECN-enabled MPLS domain. This term only implies that all the egress LSRs are ECN-enabled; some interior LSRs may not be ECN-enabled. For instance, it would be possible to use some legacy LSRs incapable of supporting ECN in the interior of an MPLS domain as long as all the egress LSRs were ECN-capable. Note that if PHP is used, the "penultimate hop" routers that perform the pop operation do need to be ECN-enabled since they are acting in this context as egress LSRs.
ECN対応の出力LSRSに囲まれたドメインをECN対応MPLSドメインと呼びます。この用語は、すべての出力LSRがECN対応であることを意味します。一部の内部LSRはECN対応ではない場合があります。たとえば、すべての出力LSRがECN対応である限り、MPLSドメインの内部でECNをサポートできないレガシーLSRを使用することが可能です。PHPが使用される場合、ポップ操作を実行する「最後のホップ」ルーターは、このコンテキストで脱出LSRとして作用しているため、ECN対応である必要があることに注意してください。
In the following subsections, we describe various operations affecting the ECN marking of a packet that may be performed at MPLS-edge and core LSRs.
以下のサブセクションでは、MPLS-EdgeおよびCore LSRSで実行できるパケットのECNマーキングに影響を与えるさまざまな操作について説明します。
On encapsulating an IP packet with an MPLS label stack, the ECN field must be translated from the IP packet into the MPLS EXP field. The Not-CM (not congestion marked) state is set in the MPLS EXP field if the ECN status of the IP packet is Not-ECT or ECT(1) or ECT(0). The CM state is set if the ECN status of the IP packet is CE. If more than one label is pushed at one time, the same value should be placed in the EXP value of all label stack entries.
MPLSラベルスタックを使用してIPパケットをカプセル化すると、ECNフィールドはIPパケットからMPLS EXPフィールドに翻訳する必要があります。IPパケットのECNステータスがNOT-ECTまたはECT（1）またはECT（0）である場合、NOT-CM（輻輳はマークされていない）状態がMPLS EXPフィールドに設定されます。IPパケットのECNステータスがCEの場合、CM状態が設定されます。一度に複数のラベルがプッシュされる場合、すべてのラベルスタックエントリのEXP値に同じ値を配置する必要があります。
The EXP field is copied directly from the topmost label before the push to the newly added outer label. If more than one label is being pushed, the same EXP value is copied to all label-stack entries.
Expフィールドは、新しく追加された外側ラベルにプッシュする前に、最上部のラベルから直接コピーされます。複数のラベルがプッシュされている場合、同じEXP値がすべてのラベルスタックエントリにコピーされます。
If the EXP codepoint of the packet maps to a PHB that uses ECN marking, and the marking algorithm requires the packet to be marked, the CM state is set (irrespective of whether it is already in the CM state).
ECNマーキングを使用するPHBへのパケットマップのEXPコードポイント、およびマーキングアルゴリズムのマークをマークする必要がある場合、CM状態が設定されます（すでにCM状態にあるかどうかに関係なく）。
If the buffer is full, a packet is dropped.
バッファがいっぱいの場合、パケットがドロップされます。
If an MPLS-encapsulated packet crosses a Diffserv domain boundary, it may be the case that the two domains use different encodings of the same PHB in the EXP field. In such cases, the EXP field must be rewritten at the domain boundary. If the PHB is one that supports ECN, then the appropriate ECN marking should also be preserved when the EXP field is mapped at the boundary.
MPLSでカプセル化されたパケットがDiffServドメインの境界を越えている場合、2つのドメインがEXPフィールドで同じPHBの異なるエンコーディングを使用している場合があります。そのような場合、EXPフィールドはドメイン境界で書き換えなければなりません。PHBがECNをサポートするものである場合、EXPフィールドが境界でマッピングされている場合、適切なECNマーキングも保存する必要があります。
If an MPLS-encapsulated packet that is in the CM state crosses from a domain that is ECN-enabled (as defined in Section 3) to a domain that is not ECN-enabled, then it is necessary to perform the egress checking procedures at the egress LSR of the ECN-enabled domain. This means that if the encapsulated packet is not ECN-capable, the packet MUST be dropped. Note that this implies the egress LSR must be able to look beneath the MPLS header without popping the label stack.
CM状態にあるMPLSエンカプソル化されたパケットが、ECN対応のドメイン（セクション3で定義されている）からECN対応のないドメインに交差する場合は、EGRESSチェック手順を実行する必要があります。ECN対応ドメインの出力LSR。これは、カプセル化されたパケットがECN対応でない場合、パケットを削除する必要があることを意味します。これは、出力LSRがラベルスタックをポップすることなくMPLSヘッダーの下を見ることができる必要があることを意味することに注意してください。
The related issue of Diffserv tunnel models is discussed in Section 4.7.
Diffservトンネルモデルの関連する問題については、セクション4.7で説明します。
When a packet has more than one MPLS label in the stack and the top label is popped, another MPLS label is exposed. In this case, the ECN information should be transferred from the outer EXP field to the inner MPLS label in the following manner. If the inner EXP field is Not-CM, the inner EXP field is set to the same CM or Not-CM state as the outer EXP field. If the inner EXP field is CM, it remains unchanged whatever the outer EXP field. Note that an inner value of CM and an outer value of not-CM should be considered anomalous, and SHOULD be logged in some way by the LSR.
パケットにスタックに複数のMPLSラベルがあり、トップラベルがポップされると、別のMPLSラベルが公開されます。この場合、ECN情報は、外部EXPフィールドから内部MPLSラベルに次の方法で転送する必要があります。内側のEXPフィールドがNot-CMの場合、内側のEXPフィールドは、外側EXPフィールドと同じCMまたは非CM状態に設定されます。内側のExpフィールドがCMの場合、外側のEXPフィールドが何であれ、変更されません。CMの内部値とNot-CMの外側値は異常と見なされるべきであり、LSRによって何らかの方法で記録する必要があることに注意してください。
When the last MPLS label is popped from the packet, its payload is exposed. If that packet is not IP, and does not have any capability equivalent to ECT, it is assumed Not-ECT, and it is treated as such. That means that if the EXP value of the MPLS header is CM, the packet MUST be dropped.
最後のMPLSラベルがパケットからポップされると、ペイロードが公開されます。そのパケットがIPではなく、ECTに相当する機能がない場合、それはeCTでないと想定されており、そのように扱われます。つまり、MPLSヘッダーのEXP値がCMの場合、パケットをドロップする必要があります。
Assuming an IP packet was exposed, we have to examine whether or not that packet is ECT. A Not-ECT packet MUST be dropped if the EXP field is CM.
IPパケットが公開されていると仮定すると、そのパケットがECTであるかどうかを調べる必要があります。EXPフィールドがCMの場合、非接続パケットをドロップする必要があります。
For the remainder of this section, we describe the behavior that is required if the ECN information is to be transferred from the MPLS header into the exposed IP header for onward transmission. As noted in Section 1.2, such behavior is not mandated by this document, but may be selected by an operator.
このセクションの残りの部分では、ECN情報をMPLSヘッダーから露出したIPヘッダーに転送するために転送する場合に必要な動作について説明します。セクション1.2で述べたように、このような動作はこのドキュメントで義務付けられていませんが、オペレーターによって選択される場合があります。
If the inner IP packet is Not-ECT, its ECN field remains unchanged if the EXP field is Not-CM. If the ECN field of the inner packet is set to ECT(0), ECT(1), or CE, the ECN field remains unchanged if the EXP field is set to Not-CM. The ECN field is set to CE if the EXP field is CM. Note that an inner value of CE and an outer value of not-CM should be considered anomalous, and SHOULD be logged in some way by the LSR.
内側のIPパケットがそれでない場合、EXPフィールドがNot-CMである場合、そのECNフィールドは変更されません。内側のパケットのECNフィールドがECT（0）、ECT（1）、またはCEに設定されている場合、EXPフィールドがNoT-CMに設定されている場合、ECNフィールドは変更されません。EXPフィールドがCMの場合、ECNフィールドはCEに設定されます。CEの内部値とNot-CMの外側値は異常と見なされるべきであり、LSRによって何らかの方法で記録する必要があることに注意してください。
[RFC3270] describes three tunneling models for Diffserv support across MPLS Domains, referred to as the uniform, short pipe, and pipe models. The differences between these models lie in whether the Diffserv treatment that applies to a packet while it travels along a particular LSP is carried to the ingress of the last hop, to the egress of the last hop, or beyond the last hop. Depending on which mode is preferred by an operator, the EXP value or DSCP value of an exposed header following a label pop may or may not be dependent on the EXP value of the label that is removed by the pop operation. We believe that, in the case of ECN marking, the use of these models should only apply to the encoding of the Diffserv PHB in the EXP value, and that the choice of codepoint for ECN should always be made based on the procedures described above, independent of the tunneling model.
[RFC3270]は、均一、ショートパイプ、およびパイプモデルと呼ばれるMPLSドメイン全体のDiffServサポートの3つのトンネルモデルを説明しています。これらのモデル間の違いは、特定のLSPに沿って移動するときにパケットに適用されるDiffserv処理が、最後のホップの侵入、最後のホップの出口、または最後のホップを超えて運ばれるかどうかにあります。オペレーターが優先されるモードに応じて、ラベルPOPに続く露出ヘッダーのEXP値またはDSCP値は、ポップ操作によって削除されるラベルのEXP値に依存している場合と依存しない場合があります。ECNマーキングの場合、これらのモデルの使用は、Exp値におけるDiffServ PHBのエンコードにのみ適用されるべきであり、ECNのコードポイントの選択は、上記の手順に基づいて常に行われるべきであると考えています。トンネリングモデルから独立しています。
If ECN is not enabled on all the egress LSRs of a domain, ECN MUST NOT be enabled on any LSRs throughout the domain. If congestion is experienced on any LSR in an ECN-disabled MPLS domain, packets MUST be dropped; they MUST NOT be marked. The exact algorithm for deciding when to drop packets during congestion (e.g., tail-drop, RED, etc.) is a local matter for the operator of the domain.
ドメインのすべての出口LSRでECNが有効になっていない場合、ドメイン全体のLSRでECNを有効にする必要はありません。ECNに障害のあるMPLSドメインのLSRで混雑が発生した場合、パケットを削除する必要があります。それらにマークされてはなりません。輻輳中にパケットをドロップするタイミング（テールドロップ、赤など）を決定するための正確なアルゴリズムは、ドメインの演算子にとって局所的な問題です。
[RFC3270] gives different options with E-LSPs and L-LSPs, and some of those could potentially provide ample EXP codepoints for ECN. However, deploying L-LSPs vs. E-LSPs has many implications, such as platform support and operational complexity. The above ECN MPLS solution should provide some flexibility. If the operator has deployed one L-LSP per PHB scheduling class, then EXP space will be a non-issue, and it could be used to achieve more sophisticated ECN behavior if required. If the operator wants to stick to E-LSPs and uses a handful of EXP codepoints for Diffserv, it may be desirable to operate with a minimum number of extra ECN codepoints, even if this comes with some compromise on ECN optimality. See Section 9 for discussion of some possible deployment scenarios.
[RFC3270]は、E-LSPとL-LSPを使用してさまざまなオプションを提供し、それらのいくつかはECNに十分なEXPコードポイントを提供する可能性があります。ただし、L-LSPとE-LSPの展開には、プラットフォームのサポートや運用上の複雑さなど、多くの意味があります。上記のECN MPLSソリューションは、ある程度の柔軟性を提供するはずです。オペレーターがPHBスケジューリングクラスごとに1つのLSPを展開した場合、EXPスペースは問題ではなく、必要に応じてより洗練されたECN動作を実現するために使用できます。オペレーターがe-LSPに固執したい場合、DiffservにいくつかのExp CodePointsを使用している場合、ECNの最適性に関する妥協がある場合でも、最小数の追加のECNコードポイントで動作することが望ましい場合があります。いくつかの展開シナリオのいくつかの議論については、セクション9を参照してください。
We note that in a network where L-LSPs are used, ECN marking SHOULD NOT cause packets from the same microflow, but with different ECN markings, to be sent on different LSPs. As discussed in [RFC3270], packets of a single microflow should always travel on the same LSP to avoid possible misordering. Thus, ECN marking of packets on L-LSPs SHOULD only affect the EXP value of the packets.
L-LSPが使用されるネットワークでは、ECNマーキングは同じマイクロフローからのパケットを引き起こすのではなく、異なるECNマーキングを使用して異なるLSPで送信されることに注意してください。[RFC3270]で説明したように、単一のマイクロフローのパケットは常に同じLSPで移動する必要があります。したがって、L-LSP上のパケットのECNマーキングは、パケットのEXP値にのみ影響する必要があります。
[RFC3168] defines two modes of encapsulating ECN-marked IP packets inside additional IP headers when tunnels are used. The two modes are the "full functionality" and "limited functionality" modes. In the full functionality mode, the ECT information from the inner header is copied to the outer header at the tunnel ingress, but the CE information is not. In the limited functionality mode, neither ECT nor CE information is copied to the outer header, and thus ECN cannot be applied to the encapsulated packet.
[RFC3168]は、トンネルを使用するときに追加のIPヘッダー内にECNマーク化されたIPパケットをカプセル化する2つのモードを定義します。2つのモードは、「完全な機能」および「制限された機能」モードです。完全な機能モードでは、内側のヘッダーからのECT情報がトンネルイングレスの外側ヘッダーにコピーされますが、CE情報はコピーされません。限られた機能モードでは、ECT情報もCE情報も外側のヘッダーにコピーされていないため、ECNをカプセル化されたパケットに適用することはできません。
The behavior that is specified in Section 4 of this document resembles the "full functionality" mode in the sense that it conveys some information from inner to outer header, and in the sense that it enables full ECN support along the MPLS LSP (which is analogous to an IP tunnel in this context). However it differs in one respect, which is that the CE information is conveyed from the inner header to the outer header. Our original reason for this different design choice was to give interior routers and LSRs more information about upstream marking in multi-bottleneck cases. For instance, the flow termination marking mechanism proposed for PCN works by only considering packets for marking that have not already been marked upstream. Unless existing flow termination marking is copied from the inner to the outer header at tunnel ingress, the mechanism doesn't terminate enough traffic in cases where anomalous events hit multiple domains at once. [RFC3168] does not give any reasons against conveying CE information from the inner header to the outer in the "full functionality" mode. Furthermore, [RFC4301] specifies that the ECN marking should be copied from inner header to outer header in IPSEC tunnels, consistent with the approach defined here. [BRISCOE-ECN] discusses this issue in more detail. In summary, the approach described in Section 4 appears to be both a sound technical choice and consistent with the current state of thinking in the IETF.
このドキュメントのセクション4で指定されている動作は、内側から外側のヘッダーにいくつかの情報を伝えるという意味で、およびMPLS LSPに沿って完全なECNサポートを可能にするという意味で、「完全な機能」モードに似ています（これは類似しています。この文脈でIPトンネルに）。ただし、1つの点で異なります。つまり、CE情報は内側のヘッダーから外側ヘッダーに伝えられます。このさまざまな設計の選択肢の当初の理由は、マルチボットルネックのケースでの上流のマーキングに関するインテリアルーターとLSRに詳細情報を提供することでした。たとえば、PCNワークスに提案されたフロー終了マーキングメカニズムは、まだ上流にマークされていないマーク用のパケットのみを考慮することにより、PCN作品に提案されています。既存のフロー終了マーキングがトンネルイングレスの内側から外側ヘッダーにコピーされない限り、メカニズムは、異常なイベントが一度に複数のドメインに衝突した場合に十分なトラフィックを終了しません。[RFC3168]は、「完全な機能」モードで、内側のヘッダーから外側にCE情報を伝えることに対して理由を与えません。さらに、[RFC4301]は、ECNマーキングをIPSECトンネルの内側ヘッダーから外側ヘッダーにコピーする必要があることを指定します。ここで定義されているアプローチと一致しています。[Briscoe-ecn]この問題については、より詳細に説明します。要約すると、セクション4で説明されているアプローチは、健全な技術的選択の両方であり、IETFの現在の考え方と一致しているようです。
What are the consequences of marking a packet that is not ECN-capable? Even if it will be dropped before leaving the domain, doesn't this consume resources unnecessarily? The problem only arises if there is congestion downstream of an earlier congested queue in the same MPLS domain. Congested LSRs downstream might forward packets already marked, even though they will be dropped later when the inner IP header is found to be Not-ECT on decapsulation. Such packets might cause the downstream LSRs to mark (or drop) other packets that they would otherwise not have had to.
ECN対応ではないパケットをマークすることの結果は何ですか？ドメインを離れる前に削除されたとしても、これは不必要にリソースを消費しませんか？問題は、同じMPLSドメインに以前の混雑したキューの下流の混雑がある場合にのみ発生します。内側のIPヘッダーが脱カプセル化に違反していないことが判明したときに、後でドロップされる場合でも、下流の混雑したLSRSは既にマークされている転送パケットを転送する可能性があります。このようなパケットにより、下流のLSRが他のパケットをマーク（またはドロップ）する可能性があります。
We expect congestion will typically be rare in MPLS networks, but it might not be. The extra unnecessary load at downstream LSRs will not be more than the fraction of marked packets from upstream LSRs, even in the worst case where no transports are ECN-capable. Therefore, the amount of unnecessary marking (or drop) on an LSR will not be more than the product of its local marking rate and the marking rate due to upstream LSRs within the same domain -- typically the product of two small (often zero) probabilities.
通常、MPLSネットワークでは混雑がまれになると予想していますが、そうではないかもしれません。下流のLSRでの余分な不必要な負荷は、輸送が担当しない最悪の場合でも、上流のLSRからマークされたパケットの割合を超えてはなりません。したがって、LSRの不必要なマーキング（またはドロップ）の量は、同じドメイン内の上流のLSRによるローカルマーキングレートの積とマーキングレートを超えてはなりません。確率。
This is why we decided to use the per-domain ECT checking approach -- because the most likely effect would be a very slightly increased marking rate, which would result in very slightly higher drop only for non-ECN-capable transports. We chose not to use the [Floyd] alternative, which introduced a low but persistent level of unnecessary packet drop for all time, even for ECN-capable transports. Although that scheme did not carry traffic to the edge of the MPLS domain only to be dropped on decapsulation, we felt our minor inefficiency was a small price to pay; and it would get smaller still if ECN deployment widened.
これが、ドメインあたりのECTチェックアプローチを使用することを決定した理由です。これは、最も可能性の高い効果が非常にわずかに増加しているため、非ECN対応輸送でのみ非常にわずかに高いドロップをもたらすためです。[Floyd]の代替品を使用しないことを選択しました。これにより、ECN対応の輸送であっても、常に低いが持続的なレベルの不必要なパケットドロップを導入しました。そのスキームは、脱カプセル化で落とすためだけにMPLSドメインの端にトラフィックを運ぶことはありませんでしたが、私たちの軽微な非効率性は支払うべき少額であると感じました。そして、ECNの展開が拡大すると、まだ小さくなります。
A partial solution would be to preferentially drop packets arriving at a congested router that were already marked. There is no solution to the problem of marking a packet when congestion is caused by another packet that should have been dropped. However, the chance of such an occurrence is very low, and the consequences are not significant. It merely causes an application to very occasionally slow down its rate when it did not have to.
部分的な解決策は、すでにマークされている混雑したルーターに到着するパケットを優先的にドロップすることです。渋滞が削除されるべき別のパケットによって引き起こされる場合、パケットをマークする問題に対する解決策はありません。ただし、このような発生の可能性は非常に低く、結果は重要ではありません。それは単にアプリケーションが非常に時々そのレートを遅くする必要がなかったときにそのレートを遅くすることです。
What if an MPLS domain wants to use ECN, but not all legacy routers are able to support it?
MPLSドメインがECNを使用したいが、すべてのレガシールーターがそれをサポートできるわけではない場合はどうなりますか？
If the legacy router(s) are used in the interior, this is not a problem. They will simply have to drop the packets if they are congested, rather than mark them, which is the standard behavior for IP routers that are not ECN-enabled.
レガシールーターが内部で使用されている場合、これは問題ではありません。それらは、それらをマークするのではなく、混雑している場合、単にパケットをドロップする必要があります。これは、ECN対応ではないIPルーターの標準動作です。
If the legacy router were used as an egress router, it would not be able to check the ECN-capability of the transport correctly. An operator in this position would not be able to use this solution and therefore MUST NOT enable ECN unless all egress routers are ECN-capable.
レガシールーターが出口ルーターとして使用された場合、輸送のECNキャピールを正しく確認できません。この位置のオペレーターは、このソリューションを使用できないため、すべての出力ルーターがECN対応でない限り、ECNを有効にしてはなりません。
[RFC3168] proposes the use of ECN in TCP, and it introduces the use of ECN-Echo and Congestion Window Reduced (CWR) flags in the TCP header for initialization. The TCP sender responds accordingly (such as not increasing the congestion window) when it receives an ECN-Echo (ECE) ACK packet (that is, an ACK packet with ECN-Echo flag set in the TCP header), then the sender knows that congestion was encountered in the network on the path from the sender to the receiver.
[RFC3168]は、TCPでのECNの使用を提案し、TCPヘッダーにECN-ECHOおよび輻輳ウィンドウ還元（CWR）フラグの使用を導入します。TCP送信者は、ECN-Echo（ECE）ACKパケット（つまり、TCPヘッダーに設定されたECNエコーフラグを備えたACKパケット）を受信すると、それに応じて応答します（輻輳ウィンドウを増やしていないなど）。送信者から受信機へのパス上のネットワークで混雑が発生しました。
It would be possible to enable ECN in an MPLS domain for Diffserv PHBs like AF and best efforts that are expected to be used by TCP and similar transports (e.g., DCCP [RFC4340]). Then, end-to-end congestion control in transports capable of understanding ECN would be able to respond to approaching congestion on LSRs without having to rely on packet discard to signal congestion.
AFなどのDiffServ PHBのMPLSドメインでECNを有効にすることができます。また、TCPおよび同様の輸送（DCCP [RFC4340]など）で使用されると予想される最善の努力があります。次に、ECNを理解できる輸送のエンドツーエンドの輻輳制御は、混雑を信号するためにパケット廃棄に頼ることなく、LSRの接近する混雑に応答することができます。
Many operators today have deployed Diffserv using the E-LSP approach of [RFC3270]. In many cases, the number of PHBs used is less than 8, and hence there remain available codepoints in the EXP space. If an operator wished to support ECN for a single PHB, this could be accomplished by simply allocating a second codepoint to the PHB for the CM state of that PHB and retaining the old codepoint for the not-CM state. An operator with only four deployed PHBs could, of course, enable ECN marking on all those PHBs. It is easy to imagine cases where some PHBs might benefit more from ECN than others -- for example, an operator might use ECN on a premium data service but not on a PHB used for best-effort Internet traffic.
今日、多くのオペレーターは、[RFC3270]のE-LSPアプローチを使用してDiffservを展開しています。多くの場合、使用されるPHBの数は8未満であるため、EXPスペースに利用可能なコードポイントが残っています。オペレーターが単一のPHBのECNをサポートしたい場合、これは、そのPHBのCM状態にPHBに2番目のコードポイントを割り当て、非CM状態に古いコードポイントを保持するだけで実現できます。もちろん、展開されたPHBが4つしかないオペレーターは、これらすべてのPHBでECNマークを有効にすることができます。一部のPHBが他のPHBよりもECNの恩恵を受ける可能性があるケースを想像するのは簡単です。たとえば、オペレーターはプレミアムデータサービスでECNを使用する可能性がありますが、最高のインターネットトラフィックに使用されるPHBでは使用できません。
As an illustrative example of how the EXP field might be used in this case, consider the example of an operator who is using the aggregated service classes proposed in [TSVWG]. He may choose to support ECN only for the Assured Elastic Treatment Aggregate, using the EXP codepoint 010 for the not-CM state and 011 for the CM state. All other codepoints could be the same as in [TSVWG]. Of course, any other combination of EXP values can be used according to the specific set of PHBs and marking conventions used within that operator's network.
この場合、EXPフィールドがどのように使用されるかの例として、[TSVWG]で提案されている集約されたサービスクラスを使用しているオペレーターの例を考慮してください。彼は、非CM状態でEXP CodePoint 010、CM状態に011を使用して、Assured Elastic Treatment Aggregateの場合のみECNをサポートすることを選択できます。他のすべてのコードポイントは、[TSVWG]と同じである可能性があります。もちろん、EXP値の他の組み合わせは、そのオペレーターのネットワーク内で使用される特定のPHBとマーキング規則のセットに従って使用できます。
Shayman's traffic engineering [Shayman] presents another example application of ECN feedback in an MPLS domain. Shayman proposed the use of ECN by an egress LSR feeding back congestion to an ingress LSR to mitigate congestion by employing dynamic traffic engineering techniques, such as shifting flows to an alternate path. It proposed a new Resource Reservation Protocol (RSVP) message, which was sent by the egress LSR to the ingress LSR (and ignored by transit LSRs) to indicate congestion along the path. Thus, rather than providing the same style of congestion notification to endpoints as defined in [RFC3168], [Shayman] limits its scope to the MPLS domain only. This application of ECN in an MPLS domain could make use of the ECN encoding in the MPLS header that is defined in this document.
Shayman's Traffic Engineering [Shayman]は、MPLSドメインでのECNフィードバックの別の例のアプリケーションを提示します。Shaymanは、ECNの使用を提案して、LSRを侵入LSRに送り返し、動的なトラフィックエンジニアリング技術を交互のパスに移行するなどの動的なトラフィックエンジニアリング技術を採用することにより、混雑を軽減することを提案しました。これは、出口LSRによって侵入LSRに送信された（およびトランジットLSRによって無視される）新しいリソース予約プロトコル（RSVP）メッセージを提案し、パスに沿った混雑を示すことを示しました。したがって、[RFC3168]で定義されているエンドポイントに同じスタイルの混雑通知を提供するのではなく、[Shayman]はそのスコープをMPLSドメインのみに制限します。MPLSドメインでのECNのこのアプリケーションは、このドキュメントで定義されているMPLSヘッダーでエンコードするECNを使用することができます。
[PCN] proposes using pre-congestion notification (PCN) on routers within an edge-to-edge Diffserv region to control admission of new flows to the region and, if necessary, to terminate existing flows in response to disasters and other anomalous routing events. In this approach, the current level of PCN marking is picked up by the signaling used to initiate each flow in order to inform the admission control decision for the whole region at once. For example, extensions to RSVP [LEFAUCHEUR] and Next Steps in Signaling (NSIS) [NSIS], [ARUMAITHURAI] have been proposed.
[PCN]は、エッジからエッジへのdiffserv領域内のルーターでの事前調節通知（PCN）を使用して、地域への新しいフローの入院を制御し、必要に応じて災害やその他の異常なルーティングイベントに対応して既存の流れを終了することを提案しています。。このアプローチでは、PCNマーキングの現在のレベルは、各フローを開始するために使用されるシグナルによってピックアップされ、一度に地域全体の入学管理決定を通知します。たとえば、RSVP [Lefaucheur]への拡張およびシグナル伝達（NSIS）[NSIS]の次のステップ[Arumaithurai]が提案されています。
If LSRs are able to mark packets to signify congestion in MPLS, PCN marking could be used for admission control and flow termination across a Diffserv region, irrespective of whether it contained pure IP routers, MPLS LSRs, or both. Indeed, the solution could be somewhat more efficient to implement if aggregates could identify themselves by their MPLS label. Appendix A describes the mechanisms by which the necessary markings for PCN could be carried in the MPLS header.
LSRがMPLSの混雑を示すためにパケットをマークすることができる場合、純粋なIPルーター、MPLS LSR、またはその両方が含まれているかどうかに関係なく、Diffserv領域全体の入場制御とフロー終了にPCNマーキングを使用できます。実際、集合体がMPLSラベルによって自分自身を識別できる場合、ソリューションはやや効率的に実装できます。付録Aでは、PCNに必要なマーキングをMPLSヘッダーに持ち込むメカニズムについて説明しています。
We believe no new vulnerabilities are introduced by this document.
このドキュメントでは、新しい脆弱性が導入されていないと考えています。
We have considered whether malicious sources might be able to exploit the fact that interior LSRs will mark packets that are Not-ECT, relying on their egress LSR to drop them. Although this might allow sources to engineer a situation where more traffic is carried across an MPLS domain than should be, we figured that even if we hadn't introduced this feature, these sources would have been able to prevent these LSRs dropping this traffic anyway, simply by setting ECT in the first place.
悪意のある情報源が、インテリアLSRが、それが極端なパケットをマークし、出口LSRに依存してそれらを落とすことができるという事実を活用できるかどうかを検討しました。これにより、ソースはMPLSドメインを介してより多くのトラフィックが本来あるべき状況を設計できる可能性がありますが、この機能を導入していなくても、これらのソースはこれらのLSRがこのトラフィックを削除するのを防ぐことができると考えていました。そもそもECTを設定するだけです。
An ECN sender can use the ECN nonce [RFC3540] to detect a misbehaving receiver. The ECN nonce works correctly across an MPLS domain without requiring any specific support from the proposal in this document. The nonce does not need to be present in the MPLS shim header to detect a misbehaving receiver. As long as the nonce is present in the IP header when the ECN information is copied from the last MPLS shim header, it will be overwritten if congestion has been experienced by an LSR. This is all that is necessary for the sender to detect a misbehaving receiver. If there were a need for an ECN nonce in the MPLS shim header (e.g., to detect if one LSR were erasing the markings of an upstream LSR in the same domain), we believe this proposal does not preclude the later addition of an ECN nonce capability for specific DSCPs, just as it does not preclude any other use of the EXP codepoints.
ECN送信者は、ECN NonCe [RFC3540]を使用して、誤動作レシーバーを検出できます。ECN Nonceは、このドキュメントの提案からの特定のサポートを必要とせずに、MPLSドメイン全体で正しく機能します。NONCEは、MPLSシムヘッダーに存在して、誤動作レシーバーを検出する必要はありません。ECN情報が最後のMPLSシムヘッダーからコピーされたときにIPヘッダーに非CEが存在する限り、混雑がLSRによって経験された場合、上書きされます。これは、送信者が誤動作レシーバーを検出するために必要なすべてです。MPLSシムヘッダーにECN Nonceが必要だった場合（たとえば、LSRが同じドメインで上流のLSRのマーキングを消去しているかどうかを検出するため）、この提案はECN非CEの後の追加を排除しないと考えています。特定のDSCPの機能は、Exp CodePointsの他の使用を排除しないのと同じように。
Thanks to K.K. Ramakrishnan and Sally Floyd for getting us thinking about this in the first place and for providing advice on tunneling of ECN packets, and to Sally Floyd, Joe Babiarz, Ben Niven-Jenkins, Phil Eardley, Ruediger Geib, and Magnus Westerlund for their comments on the document.
K.K.に感謝します。RamakrishnanとSally Floydは、そもそもこれについて考えさせ、ECNパケットのトンネルに関するアドバイスを提供し、Sally Floyd、Joe Babiarz、Ben Niven-Jenkins、Phil Aeardey、Ruediger Geib、Magnus Westerlundにコメントを求めてコメントしてくれました。ドキュメント。
This appendix describes how the mechanisms described in the body of the document can be extended to support PCN [PCN]. Our intent here is to show that the mechanisms are readily extended to more complex scenarios than ECN, particularly in the case where more codepoints are needed, but this appendix may be safely ignored if one is interested only in supporting ECN. Note that the PCN standards are still very much under development at the time of writing; hence, the precise details contained in this appendix may be subject to change, and we stress that this appendix is for illustrative purposes only.
この付録では、ドキュメントの本文で説明されているメカニズムをどのように拡張してPCN [PCN]をサポートできるかについて説明します。ここでの私たちの意図は、メカニズムがECNよりも複雑なシナリオに容易に拡張されることを示すことです。特に、より多くのコードポイントが必要な場合には、この付録はECNのサポートに関心がある場合は安全に無視される場合があります。執筆時点では、PCN標準はまだ非常に開発中であることに注意してください。したがって、この付録に含まれる正確な詳細は変更される可能性があり、この付録は説明のみを目的としていることを強調します。
The relevant aspects of PCN for the purposes of this discussion are:
この議論の目的のためのPCNの関連する側面は次のとおりです。
o PCN uses 3 states rather than 2 for ECN -- these are referred to as admission marked (AM), termination marked (TM), and not marked (NM) states. (See Section 9.4 for further discussion of PCN and the possibility of using fewer codepoints).
o PCNは、ECNの場合は2つではなく3つの状態を使用します。これらは、マークされた（AM）、マークされた（TM）、マークされた（NM）状態ではない入場と呼ばれます。（PCNの詳細と、より少ないコードポイントを使用する可能性については、セクション9.4を参照してください）。
o A packet can go from NM to AM, from NM to TM, or from AM to TM, but no other transition is possible.
o パケットは、NMからAM、NMからTM、またはAMからTMに移動できますが、他の遷移は不可能です。
o The determination of whether a packet is subject to PCN is based on the PHB of the packet.
o パケットがPCNの対象かどうかの決定は、パケットのPHBに基づいています。
Thus, to support PCN fully in an MPLS domain for a particular PHB, a total of 3 codepoints need to be allocated for that PHB. These 3 codepoints represent the admission marked (AM), termination marked (TM), and not marked (NM) states. The procedures described in Section 4 above need to be slightly modified to support this scenario. The following procedures are invoked when the topmost DSCP or EXP value indicates a PHB that supports PCN.
したがって、特定のPHBのMPLSドメインでPCNを完全にサポートするには、そのPHBに合計3つのコードポイントを割り当てる必要があります。これらの3つのコードポイントは、マークされた入場（AM）、マークされた（TM）、マークされていない（NM）状態を表します。上記のセクション4で説明した手順は、このシナリオをサポートするためにわずかに変更する必要があります。最上位のDSCPまたはEXP値がPCNをサポートするPHBを示している場合、次の手順が呼び出されます。
If the IP packet header indicates AM, set the EXP value of all entries in the label stack to AM. If the IP packet header indicates TM, set the EXP value of all entries in the label stack to TM. For any other marking of the IP header, set the EXP value of all entries in the label stack to NM.
IPパケットヘッダーがAMを示した場合、ラベルスタックのすべてのエントリのEXP値をAMに設定します。IPパケットヘッダーがTMを示した場合、ラベルスタックのすべてのエントリのEXP値をTMに設定します。IPヘッダーのその他のマーキングについては、ラベルスタックのすべてのエントリのEXP値をNMに設定します。
The procedures of Section 4.2 apply.
セクション4.2の手順が適用されます。
The EXP value can be set to AM or TM according to the same procedures as described in [BRISCOE-CL]. For the purposes of this document, it does not matter exactly which algorithms are used to decide when to set AM or TM; all that matters is that if a router would have marked AM (or TM) in the IP header, it should set the EXP value in the MPLS header to the AM (or TM) codepoint.
[Briscoe-Cl]で説明されているのと同じ手順に従って、EXP値をAMまたはTMに設定できます。このドキュメントの目的のために、AMまたはTMをいつ設定するかを決定するためにどのアルゴリズムが使用されるかは正確には関係ありません。重要なのは、ルーターがIPヘッダーのAM（またはTM）をマークした場合、MPLSヘッダーのEXP値をAM（またはTM）CodePointに設定する必要があることです。
When popping an MPLS Label exposes another MPLS label, the AM or TM marking should be transferred to the exposed EXP field in the following manner:
MPLSラベルをポップする場合、別のMPLSラベルを公開する場合、AMまたはTMマーキングは次の方法で露出した露出場に転送する必要があります。
o If the inner EXP value is NM, then it should be set to the same marking state as the EXP value of the popped label stack entry.
o 内部EXP値がnmの場合、ポップされたラベルスタックエントリのEXP値と同じマーキング状態に設定する必要があります。
o If the inner EXP value is AM, it should be unchanged if the popped EXP value was AM, and it should be set to TM if the popped EXP value was TM. If the popped EXP value was NM, this should be logged in some way, and the inner EXP value should be unchanged.
o 内部EXP値がAMの場合、ポップされたEXP値がAMである場合は変更されず、ポップされたEXP値がTMの場合はTMに設定する必要があります。ポップされたExp値がnmの場合、これは何らかの方法で記録する必要があり、内部EXP値は変更されません。
o If the inner EXP value is TM, it should be unchanged whatever the popped EXP value was, but any EXP value other than TM should be logged.
o 内部exp値がTMの場合、ポップされたExp値が何であれ、変更されていないはずですが、TM以外のExp値を記録する必要があります。
When popping the last MPLS Label exposes the IP header, there are two cases to consider:
最後のMPLSラベルをポップすると、IPヘッダーが公開されると、考慮すべき2つのケースがあります。
o the popping LSR is *not* the egress router of the PCN region, in which case AM or TM marking should be transferred to the exposed IP header field; or
o ポップLSRは * PCN領域の出口ルーターではありません。この場合、AMまたはTMマーキングは露出したIPヘッダーフィールドに転送する必要があります。また
o the popping LSR *is* the egress router of the PCN region.
o ポップLSR *は * PCN領域の出口ルーターです。
In the latter case, the behavior of the egress LSR is defined in [PCN] and is beyond the scope of this document. In the former case, the marking should be transferred from the popped MPLS header to the exposed IP header as follows:
後者の場合、出口LSRの動作は[PCN]で定義され、このドキュメントの範囲を超えています。前者の場合、マーキングは、次のように、ポップされたMPLSヘッダーから露出したIPヘッダーに転送する必要があります。
o If the inner IP header value is neither AM nor TM, and the EXP value was NM, then the IP header should be unchanged. For any other EXP value, the IP header should be set to the same marking state as the EXP value of the popped label stack entry.
o 内部IPヘッダー値がAMでもTMでもなく、EXP値がNMである場合、IPヘッダーは変更されていません。他のEXP値については、IPヘッダーをポップされたラベルスタックエントリのEXP値と同じマーキング状態に設定する必要があります。
o If the inner IP header value is AM, it should be unchanged if the popped EXP value was AM, and it should be set to TM if the popped EXP value was TM. If the popped EXP value was NM, this should be logged in some way and the inner IP header value should be unchanged.
o 内側のIPヘッダー値がAMの場合、ポップされたEXP値がAMである場合は変更されず、ポップされたEXP値がTMの場合はTMに設定する必要があります。ポップされたExp値がnmの場合、これは何らかの方法で記録する必要があり、内側のIPヘッダー値は変更されていません。
o If the IP header value is TM, it should be unchanged whatever the popped EXP value was, but any EXP value other than TM should be logged.
o IPヘッダー値がTMの場合、ポップされたEXP値が何であれ、変更されていないはずですが、TM以外のEXP値を記録する必要があります。
Normative References
引用文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[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, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、「Multi-Protocol Label Switching」（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
Informative References
参考引用
[ARUMAITHURAI] Arumaithurai, M., "NSIS PCN-QoSM: A Quality of Service Model for Pre-Congestion Notification (PCN)", Work in Progress, September 2007.
[Arumaithurai] Arumaithurai、M。、「NSIS PCN-QOSM：事前の通知（PCN）のサービス品質モデル」、2007年9月、進行中の作業。
[BRISCOE-CL] Briscoe, B., "Pre-Congestion Notification Marking", Work in Progress, October 2006.
[Briscoe-Cl] Briscoe、B。、「前の通知マーキング」、2006年10月、進行中の作業。
[BRISCOE-ECN] Briscoe, B., "Layered Encapsulation of Congestion Notification", Work in Progress, July 2007.
[Briscoe-ecn] Briscoe、B。、「混雑通知の階層化されたカプセル化」、2007年7月、進行中の作業。
[Floyd] Ramakrishnan, K., Floyd, S., and B. Davie, "A Proposal to Incorporate ECN in MPLS", Work in Progress, June 1999.
[フロイド]ラマクリシュナン、K。、フロイド、S。、およびB.デイビー、「MPLSにECNを組み込む提案」、1999年6月、進行中の作業。
[LEFAUCHEUR] Faucheur, F., Charny, A., Briscoe, B., Eardley, P., Barbiaz, J., and K. Chan, "RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification (PCN)", Work in Progress, June 2006.
[Lefaucheur] Faucheur、F.、Charny、A.、Briscoe、B.、Eardley、P.、Barbiaz、J。、およびK. Chan、 "RSVP拡張前 - 前構成通知（PCN）を使用したDiffservの入場制御のための拡張、作業中の2006年6月。
[NSIS] Bader, A., Westberg, L., Karagiannis, G., Cornelia, C., and T. Phelan, "RMD-QOSM - The Resource Management in Diffserv QOS Model", Work in Progress, November 2007.
[NSIS] Bader、A.、Westberg、L.、Karagiannis、G.、Cornelia、C。、およびT. Phelan、「RMD -QOSM- Diffserv QoSモデルのリソース管理」、2007年11月、作業。
[PCN] Eardley, P., "Pre-Congestion Notification Architecture", Work in Progress, November 2007.
[PCN] Eardley、P。、「事前の通知通知アーキテクチャ」、2007年11月、進行中の作業。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540] Spring、N.、Wetherall、D。、およびD. Ely、「Noncesによる堅牢な明示的な混雑通知（ECN）シグナル伝達」、RFC 3540、2003年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[Shayman] Shayman, M. and R. Jaeger, "Using ECN to Signal Congestion Within an MPLS Domain", Work in Progress, November 2000.
[Shayman] Shayman、M。およびR. Jaeger、「ECNを使用してMPLSドメイン内の輻輳を知らせる」、2000年11月、進行中の作業。
[TSVWG] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", Work in Progress, November 2007.
[TSVWG] Chan、K.、Babiarz、J。、およびF. Baker、「Diffserv Service Classesの集約」、2007年11月、進行中の作業。
Authors' Addresses
著者のアドレス
Bruce Davie Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
ブルース・デイビー・シスコ・システムズ、Inc。1414Mass。Ave.Boxborough、MA 01719 USA
EMail: bsd@cisco.com
Bob Briscoe BT Research B54/77, Sirius House Adastral Park Martlesham Heath Ipswich Suffolk IP5 3RE United Kingdom
Bob Briscoe BT Research B54/77、Sirius House Adastral Park Martlesham Heath Suffolk IP5 3RE英国
EMail: bob.briscoe@bt.com
June Tay BT Research B54/77, Sirius House Adastral Park Martlesham Heath Ipswich Suffolk IP5 3RE United Kingdom
June Tay BT Research B54/77、Sirius House Adastral Park Martlesham Heath Suffolk IP5 3RE英国
EMail: june.tay@bt.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。