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
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 Code Point（DSCP; DiffServコードポイント）を符号化する方法を含む、MPLSネットワークでDiffServアーキテクチャをサポートする方法を定義します。その分野の他の用途が排除されていないながらのDSCPは、EXPフィールドに符号化されてもよいです。 RFC 3270は、マーキング明示的輻輳通知（ECN）はMPLSヘッダにエンコードされるかもしれない方法についての声明を行うものではありません。この文書では、オペレータが他の用途を排除せず、明示的輻輳通知のための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 Code Point（DSCP; DiffServコードポイント）を符号化する方法を含む、MPLSネットワークでDiffServアーキテクチャをサポートする方法を定義します。その分野の他の用途が排除されていないながらのDSCPは、EXPフィールドに符号化されてもよいです。 RFC 3270は、マーキング明示的輻輳通知（ECN）はMPLSヘッダにエンコードされるかもしれない方法についての声明を行うものではありません。
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の添加を規定活動に平行では、二つの提案が[フロイド] [Shayman] MPLSするECNを追加するためになされました。これらの提案は、しかし、路傍で下落しました。 IPのための電子証券取引ネットワークは今[PCN]提案された標準であること、およびアドミッション制御のためのプレ輻輳通知（PCN）を使用することに関心を開発および終了を流れると、MPLS対応からなるIPネットワークを介してECNをサポートすることができることで結果として関心がありますドメイン。したがって、MPLSシムヘッダとエッジMPLSノードのプロトコルの動作にECNを含むためのプロトコルを指定する必要があります。
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]に、IPヘッダーの2ビットを用いて符号化されたECNマーキングのために使用される4つのコードポイントが存在することに注意してください。 MPLS EXPフィールドが消費コードポイントの数を節約するための明確な動機があり、ECNコードポイントを符号化する論理的な場所であるが、利用可能な唯一の3ビット（8つのコードポイント）と、同じフィールドと同様にDSCP情報を伝達するために使用されていますECNの目的のために。 EXPフィールドの効率的な使用は、従来の文書[フロイド] [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フィールドのデフォルトの使用を定義することに注意してください、それはいくつかのDiffservパーホップ行動（の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マーキングを示すべきであり、どのようにMPLSノードがパケットの輸送がECN可能であるかどうかを理解する方法を指定することです。我々は、さまざまな輻輳通知システムを構築し、そこから、ビルディングブロックとしてこれを提供します。私たちは、結果として輻輳通知が混雑を緩和することができ、上流のノードに帰還される方法を指定するつもりはありません。たとえば、[Shayman]とは異なり、我々は、端から端までMPLSドメインのフィードバックを指定していないが、我々はまた、それを排除するものではありません。それにもかかわらず、私たちは、ECNはIP受信機に向けて以降実施される場合、MPLSドメインの出口ノードは、カプセル化されたIPヘッダーにMPLSシムから輻輳通知をコピーする方法を指定します。しかし、我々は*ない* 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をサポートするネットワークでマークされることができるとの状態のうちの一つ。パケットはこのルータは、パケットが到着した時に輻輳を経験していたことを示すために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の一つは、それがエンドシステムによって送信されるときに、パケットがしている可能性があると述べています。エンドシステムは、トランスポートプロトコルのエンドポイントがECN-可能であることを示すために、ECTコードポイントでパケットをマークします。それが到着した時にパケットがECTをマークした場合に限り、そのルータは、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未-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フィールド。 Diffservの情報を伝えるために使用することができる（また、ECN情報を搬送するために本書で使用されている）、MPLSラベルヘッダ[RFC3032]の3ビットのフィールド。
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。最後から二番目のホップポッピング。 MPLSの操作とは、ラベルスイッチパス（LSP）の最後から二番目のラベルスイッチングルータ（LSR）が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).
私たちは、明示的輻輳通知のために設定のLSRは、MPLSシムヘッダー内のEXPフィールドを使用することを提案しています。しかしながら、[RFC3270]は、すでに差別化サービスのためのEXPフィールドのコードポイントを使用することを規定しています。それはEXPフィールドの互換性のある他の用途を排除するものではないが、これは明らかフィールドは3ビットのみ（8つのコードポイント）が与えられた、ECNのために利用可能なスペースを制限するように思われます。
[RFC3270] defines two possible approaches for requesting differentiated service treatment from an LSR:
[RFC3270]はLSRから差別化されたサービス処理を要求するための二つの可能なアプローチを定義します。
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-推定さ-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.
LSRがその転送とそのスケジューリング動作の両方を決定するようにOラベル専用推定さ-PSC LSP（L-LSP）のアプローチでは、MPLSラベルは、[RFC3260]で定義されるように各PHBスケジューリングクラス（PSCのために割り当てられていますラベルから。
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コードポイント（複数可）のための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コードポイントがマークされていない輻輳（未-CM）のように定義され、少なくとも一つの他のコードポイントが輻輳マーク（CM）のように定義されると仮定します。そのため、ECNマーキングを使用する各PHBは、少なくとも二つのEXPコードポイントを消費しますが、ECNマーキングを使用していないのPHBは一つだけを消費します。
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:
さらに、我々は、各パケットがECN対応トランスポートで受信されるかどうかを内部のLSRを伝えるためにMPLSシムヘッダーで最小限のスペースを使用したい（ECT）。それにもかかわらず、我々はそれ以外の場合はそれが必要として混雑に対応することができなくなり、ECNマークを理解できないだろうエンドポイントが1を受信しないようにする必要があります。過去には、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.
1でない-ECTを意味するかもしれないいずれかまたはそれがCEを意味するかもしれないが0にECTを意味するようにO [フロイド]によって提案された方式では、ECTとCEは、1ビットにオーバーロードされています。上流の経験豊富な輻輳を有するものとしてマークされており、第2混雑LSRでマーキングのために採取され、それはパケットが以前に輻輳を経験またはECNをサポートしていない場合いるかどうかを判断することができないので、第二の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
このようなアプローチは、潜在的においしい見えたが、我々は次のような理由で、ここにそれをお勧めしません。いくつかのケースでは、我々は実際の輻輳（例えば、前の輻輳通知）の前に長いECNマーキングを使用できるようにしたいです。このような状況では、各LSRでのマーキング速度は、ほとんどの時間を無視できないこと、そうかもしれない再びそれをマークするも、無視できないだろう望んでいるLSRに出会う以前にマークされたパケットのチャンス。 CEはなく、ECTは、コアルータに区別できない場合には、そのようなシナリオでは許容できないドロップ率につながります。すべてのルータやLSRの典型的なマーキング率をpである、とのLSRのネットワークの典型的な直径をdとし、マークされたパケットを複数回マークするために選択されることになる確率がある場合
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.
1- [PR（マークされません）+ PR（正確に一つのホップでマーク）] = 1 - [（1-P）^ D + DP（1-P）^（D-1）]。例えば、行6つのLSRと、1％の確率で各マーキングECNは、既に二度目のマーキングのために選択されてマークされたパケットの可能性は0.15％です。ビットオーバーロードスキームは、従って、不必要に0.15％の低下率を導入します。最も近代的なコアネットワークがほぼゼロのパケットドロップを導入するようなサイズにされていることを考えると、不必要千のパケット内の1つの上でドロップする許容できないことがあります。
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.
第3の可能なアプローチO [Shayman]で示唆されました。この方式では、内部のLSRは、エンドポイントがECN対応であることを前提としていますが、最終的にラベルがポップされたときに、この仮定がチェックされます。インテリアLSRはシムヘッダーのEXPフィールドにECNをマークしたが、IPヘッダが言う場合、エンドポイントは、ECNに対応していない、エッジルータ（または最後から二番目のルータ、飛び出る最後から二番目のホップを使用している場合）、パケットをドロップします。我々は `ドメインごとの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.
この議論の目的のために、我々は、IP（または、潜在的に非IP）ヘッダを露出、ラベルスタックから最後のMPLSラベルをポップノードとMPLSドメインの出口ノードを定義します。そのようなノードは最後から二番目のホップのポッピング（PHP）が採用されているかどうかに応じて、LSPの最終又は最後から二番目のホップであってもよいことに留意されたいです。
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は、それを取り巻くすべての出口のLSRが既にマーキングECNを処理するように設定されていない限り、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対応の出口のLSRの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エッジおよびコアのLSRで行うことができるパケットのマーキング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フィールドは、MPLS EXPフィールドにIPパケットから翻訳されなければなりません。 IPパケットのECN状況ではない-ECTまたはECTでない場合-CM（ない輻輳マーク）状態は、MPLS EXPフィールドに設定されている（1）またはECT（0）。 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.
ECN-有効でないドメインにECNに対応しているドメインからCM状態交雑であるMPLSカプセル化パケット（セクション3で定義されるように）場合、に出口チェック手順を実行する必要があります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情報は、以下のようにインナーMPLSラベルを外側のEXPフィールドから転送されるべきです。内部EXPフィールドは-CMされていない場合は、内部EXPフィールドは、外側EXPフィールドと同じCMまたはNot-CMの状態に設定されています。内部EXPフィールドがCMであれば、それが何であれ、外EXPフィールド変更されません。 CMの内部値ではなく、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でない場合-ECTパケットを下げなければなりません。
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情報が以降の送信のために露出したIPヘッダにMPLSヘッダから転送される場合に必要とされる動作を記述する。セクション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パケットが、ECTされていない場合はEXPフィールドは-CMされていない場合は、そのECNフィールドは変更されません。内部パケットのECNフィールドがECT（0）、ECT（1）、またはCEに設定されている場合はEXPフィールドがない-CMに設定されている場合、ECNフィールドは変更されません。 ECNフィールドは、EXPフィールドがCMであればCEに設定されています。 CEの内部値ではなく、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の処理は最終ホップの出口に、または最後のホップを超えて、最後のホップの入口に搬送されているかどうかにあります。ラベルポップを下記露出ヘッダのオペレータ、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.
ECNは、ドメインのすべての出口のLSRで有効になっていない場合は、ECNは、ドメイン全体の任意のLSR上で有効にすることはできません。輻輳がECN-無効MPLSドメイン内の任意のLSRに経験されている場合は、パケットは廃棄されなければなりません。彼らがマークされてはなりません。輻輳時にパケットをドロップするときに決定するための正確なアルゴリズム（例えば、テールドロップ、RED等）ドメインのオペレータのためにローカルの問題です。
[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コードポイントを提供することができます。しかし、E-LSPの対展開L-LSPは、このようなプラットフォームのサポートおよび運用上の複雑さなど、多くの意味を持っています。上記のECNのMPLSソリューションは、ある程度の柔軟性を提供する必要があります。オペレータはPHBスケジューリングクラスごとに1つのL-LSPを展開している場合は、その後、EXP空間は非問題になり、必要な場合は、より洗練されたECNの動作を達成するために使用することができます。オペレータはE-のLSPに固執したいとDiffservのためのEXPコードポイントの一握りを使用している場合、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つのモードを定義しています。二つのモードが「フル機能」と「制限された機能」モードです。全機能モードでは、内部ヘッダから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トンネルへ）。しかし、CE情報が外部ヘッダの内部ヘッダから搬送されることである一つの点で異なります。この異なる設計上の選択のための当社独自の理由は、内部ルータとのLSRに上流のマルチボトルネックの場合、マーキングに関する詳細な情報を提供することでした。例えば、マーキング機構フロー終了は、すでに上流にマークされていないことをマークするためのパケットを考慮してPCN作品のために提案されています。既存のフロー終了マーキングは、内側から、トンネル入口で外部ヘッダにコピーされていなければ、機構は、異常事象が一度に複数のドメインを打つ場合には十分なトラフィックを終了しません。 [RFC3168]は「フル機能」モードで外側に内部ヘッダからCE情報を伝達に対する任意の理由を与えません。さらに、[RFC4301]はマーキングECNは、ここで定義されたアプローチと一致し、IPSecトンネル外側ヘッダに内部ヘッダからコピーされなければならないことを指定します。 [ブリスコー-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?
ECN対応ではないパケットをマーキングの結果は何ですか？それがドメインを離れる前に削除されます場合でも、これは不必要にリソースを消費しないのですか？
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.
同じMPLSドメイン内の以前の混雑キューの下流の輻輳がある場合にのみ問題が発生します。混雑のLSRは、下流の内側のIPヘッダーをカプセル化解除にない-ECTであることが判明したとき、彼らは後に削除されますにもかかわらず、すでにマークされたパケットを転送することがあります。このようなパケットは、下流の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に余分な不要な負荷がなくてもトランスポートがECN対応しない最悪の場合には、上流のLSRからマークされたパケットの割合を超えることはないであろう。したがって、LSR上のマーキング不要（または降下）の量は、そのローカルマーキング速度とにより、同じドメイン内の上流のLSRにマーキング速度の積を超えることはありません - 典型的に小さな2つ（しばしばゼロ）の積確率。
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.
最も可能性の高い効果は非常にわずかにのみ非ECN対応トランスポートのために非常にわずかに高いドロップにつながる率を、マーキングの増加になるので - 私たちは、ドメインごとのECTチェックアプローチを使用することを決めた理由です。私たちも、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ヘッダに（CWR）フラグ低減ECN-エコーおよび輻輳ウィンドウの使用を導入します。 TCP送信者は、ECN-エコー（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.
これは、TCPと同様のトランスポートによって使用されることが期待されるのDiffservのAF等のPHBおよびベストエフォートのためのMPLSドメイン内のECNを有効にすることが可能であろう（例えば、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状態のため、古いコードポイントを保持することにより達成することができます。わずか4展開のPHBを持つオペレータは、当然のことながら、これらすべてののPHBマーキングECNを可能にすることができます。いくつかのPHBは、より多くのECNから他よりも恩恵を受ける可能性がある場合を想像するのは容易である - 例えば、オペレータは、ベストエフォート型のインターネットトラフィックのために使用さPHB上のプレミアムデータサービスにECNを使用していますが、しない場合があります。
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状態のためではない-CM状態と011のためのEXPコードポイント010を使用して、唯一のアシュアード弾性治療の集計のために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のトラフィックエンジニアリング[Shayman]はMPLSドメイン内のECNフィードバックの別の応用例を示します。 Shaymanは、代替パスに流れるシフトなどの動的トラフィックエンジニアリング技術を使用することによって、輻輳を軽減するために、入口LSRに輻輳をフィードバック出口LSRによってECNの使用を提案しました。これは、経路に沿った混雑を示す（トランジットの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の現在のレベルを一度に全領域のためのアドミッション制御決定を通知するために各フローを開始するために使用されるシグナリングによってピックアップされます。例えば、[ARUMAITHURAI]、[LEFAUCHEUR] RSVPとシグナリング（NSIS）における次のステップ[NSIS]への拡張が提案されています。
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における輻輳を示すためにパケットをマークすることができる場合、マーキングPCNは、アドミッション制御のために使用することができ、関係なく、純粋なIPルータ、MPLS LSRの、または両方を含んでいたかどうか、Diffservの領域を横切って終端を流します。凝集体が彼らの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に頼って、-ECTないパケットをマークするという事実を利用することができるかもしれないかどうかを検討してきました。これはソースがより多くのトラフィックが必要以上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ナンス[RFC3540]を使用することができます。 ECNのナンスは、この文書の提案から、特定のサポートを必要とせずにMPLSドメイン間で正しく動作します。ノンスは、不正動作する受信機を検出するためにMPLSシムヘッダに存在する必要はありません。輻輳がLSRが経験されている場合に限り、ノンスがECN情報が最後にMPLSシムヘッダからコピーされたIPヘッダに存在するように、それが上書きされます。これは、送信者が誤動作受信機を検出するために必要なことすべてです。 MPLSシムヘッダー（例えば、1 LSRが同じドメイン内に上流のLSRのマーキングを消去されたかどうかを検出するために）でECNナンスの必要性があったならば、我々はこの提案はECNナンスの後の追加を排除しないと考えていますそれはEXPコードポイントのいずれかの他の使用を排除するものではないと同じように、特定のDSCPのための機能を提供します。
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.のおかげでラマクリシュナンとサリーフロイド最初の場所でこのことについて考えて私たちを取得するためとECNパケットのトンネリングに助言を提供するための、およびサリーフロイド、ジョーBabiarz、ベン・ニーヴン・ジェンキンス、フィル・Eardley、Ruediger Geib、およびマグヌスウェスターへの彼らのコメントについてドキュメント。
Appendix A. Extension to Pre-Congestion Notification
前の輻輳通知に付録A.拡張
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よりもより複雑なシナリオに拡張されますが、1だけ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).
PCNは、ECNのための3つの状態ではなく、2を使用してO - これらは入院マーク（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からTMへ、またはAMからのTMに、AMするNMから行くことができますが、それ以外の移行が可能ではありません。
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をサポートするために、3つのコードポイントの合計は、PHBのために割り当てられる必要があります。これらの3つのコードポイントは、終了マーク（TM）、マーク入場料（AM）を表しており、（NM）の状態をマークされていません。わずかにこのシナリオをサポートするように変更する必要が上記のセクション4に記載された手順。一番上のDSCPまたはEXP値がPCNをサポートしているPHBを示している場合、以下の手順が呼び出されます。
A.1. Label Push onto IP Packet
A.1。 IPパケットへのラベルプッシュ
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を示している場合、AMにラベルスタック内のすべてのエントリのEXP値を設定します。 IPパケットのヘッダは、TMを示している場合、TMにラベルスタック内のすべてのエントリのEXP値を設定します。 IPヘッダのマーキングその他ため、NMにラベルスタック内のすべてのエントリのEXP値を設定します。
A.2. Pushing Additional MPLS Labels
A.2。その他のMPLSラベルを押します
The procedures of Section 4.2 apply.
4.2節の手順が適用されます。
A.3. Admission Control or Flow Termination Marking Inside MPLS Domain
A.3。インサイドMPLSドメインをマーキングアドミッション制御やフロー終了
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.
EXP値は[ブリスコウ-CL]に記載のものと同じ手順に従ってAMまたはTMに設定することができます。このドキュメントの目的のためには、アルゴリズムはAMまたはTMを設定するタイミングを決定するために使用されているかを正確に重要ではありません。すべての重要なことは、ルータがIPヘッダにAM（またはTM）をマークしているならば、それはAM（またはTM）コードポイントへのMPLSヘッダーのEXP値を設定しなければならないことです。
A.4. Popping an MPLS Label (Not End of Stack)
A.4。 MPLSラベルをポップ（スタックの終わりではありません）
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を公開して、以下の方法で露光EXPフィールドに転送する必要があります。
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.
内部EXP値がNMである場合、O、それがポップラベルスタックエントリの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.
内部EXP値がAMであればポップEXP値はAMであり、ポップEXP値がTMであった場合、それはTMに設定する必要がある場合、O、それは不変であるべきです。ポップ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.
内部EXP値がTMの場合は、O、ポップEXP値だったが、TM以外のEXP値がログに記録されなければならないものは何でも変わらなければなりません。
A.5. Popping the Last MPLS Label to Expose IP Header
A.5。 IPヘッダーを公開するために最後のMPLSラベルをポップ
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
ポッピングLSR oをマーキングAMまたはTMが露出IPヘッダフィールドに転送すべき場合にはPCN領域の出口ルータ*ありません。または
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]で定義され、この文書の範囲外です。次のように前者の場合、マーキングは、露出したIPヘッダにポップMPLSヘッダから転送されるべきです。
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.
内側のIPヘッダ値がAMもTM、及びEXPの値のいずれもがNMであった場合、Oは、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.
内側のIPヘッダ値がAMであればポップEXP値はAMであり、ポップEXP値がTMであった場合、それはTMに設定する必要がある場合、O、それは不変であるべきです。ポップ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.
IPヘッダの値がTMの場合は、O、ポップ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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、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.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、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]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、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.
[ブリスコー-CL]ブリスコー、B.、 "プリ輻輳通知マーキング"、進歩、2006年10月に作業。
[BRISCOE-ECN] Briscoe, B., "Layered Encapsulation of Congestion Notification", Work in Progress, July 2007.
[ブリスコー-ECN]ブリスコー、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.、ブリスコー、B.、Eardley、P.、Barbiaz、J.、およびK.チャン、 "プレ輻輳通知を使用して、Diffservの上にアドミッション制御のためのRSVP拡張（PCN）" 、進歩、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]ベイダー、A.、Westberg、L.、Karagiannis、G.、コーネリア、C.、およびT.フェラン、 "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]グロスマン、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]春、N.、Wetherall、D.、およびD.イーリー、 "ロバスト明示的輻輳通知（ECN）ナンスとシグナリング"、RFC 3540、2003年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（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.イェーガーは、進歩、2000年11月に作品 "MPLSドメイン内の信号輻輳にECNを使います"。
[TSVWG] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", Work in Progress, November 2007.
[TSVWG]チャン、K.、Babiarz、J.、およびF.ベイカー、 "DiffServのサービスクラスの集約"、進歩、2007年11月に作業。
Authors' Addresses
著者のアドレス
Bruce Davie Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA
ブルース・デイビーシスコシステムズ株式会社1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 USA
EMail: bsd@cisco.com
メールアドレス：bsd@cisco.com
Bob Briscoe BT Research B54/77, Sirius House Adastral Park Martlesham Heath Ipswich Suffolk IP5 3RE United Kingdom
ボブ・ブリスコーBT研究B54 / 77、シリウスハウスAdastral公園MartleshamヒースイプスウィッチIP5 3REイギリス
EMail: bob.briscoe@bt.com
メールアドレス：bob.briscoe@bt.com
June Tay BT Research B54/77, Sirius House Adastral Park Martlesham Heath Ipswich Suffolk IP5 3RE United Kingdom
6月テイBT研究B54 / 77、シリウスハウスAdastral公園MartleshamヒースイプスウィッチIP5 3REイギリス
EMail: june.tay@bt.com
メールアドレス：june.tay@bt.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。