RFC5129 日本語訳

5129 Explicit Congestion Marking in MPLS. B. Davie, B. Briscoe, J.Tay. January 2008. (Format: TXT=49496 bytes) (Updates RFC3032) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           B. Davie
Request for Comments: 5129                           Cisco Systems, Inc.
Category: Standards Track                                     B. Briscoe
                                                                  J. Tay
                                                             BT Research
                                                            January 2008

コメントを求めるワーキンググループB.デイビー要求をネットワークでつないでください: 5129年のシスコシステムズInc.カテゴリ: 標準化過程B.ブリスコウJ.タイBT研究2008年1月

                  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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

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.

RFC3270はMPLSネットワークでDiffserv構造をサポートする方法を定義します、MPLSヘッダーでDiffserv Code Points(DSCPs)をコード化する方法を含んでいて。 DSCPsはEXP分野でコード化されるかもしれませんが、その分野の他の用途は排除されません。 RFC3270はExplicit Congestion Notification(電子証券取引ネットワーク)マークがMPLSヘッダーでどうコード化されるかもしれないかに関する声明を全く出しません。 このドキュメントはオペレータが明白な混雑通知のためにどういくつかのEXP codepointsを定義するかもしれないかを定義します、他の用途を排除しないで。

Davie, et al.               Standards Track                     [Page 1]

RFC 5129                      ECN for MPLS                  January 2008

デイビー、他 規格は2008年1月にMPLSのためにRFC5129電子証券取引ネットワークを追跡します[1ページ]。

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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 意図. . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3。 用語. . . . . . . . . . . . . . . . . . . . . . . 4 2。 MPLS EXP分野の電子証券取引ネットワーク. . . . . . . . . . . . . . . . 5 3の使用。 1ドメインあたりのECTの照合. . . . . . . . . . . . . . . . . . . 7 4。 電子証券取引ネットワークによって可能にされたMPLSドメイン. . . . . . . . . . . . . . . . . . . 8 4.1。 より多くの(付加)1ラベルをIPパケット. . . 8 4.2に押します。 より押1すのはラベルされたパケット. . 8 4.3をMPLSとラベルします。 混雑は内部でMPLSノード. . . . . 8 4.4になりました。 Diffservドメイン境界. . . . . . . . . . . 8 4.5に交差しています。 MPLSを飛び出させて、(スタックの端でない)を.94.6とラベルしてください。 スタック. . . . . . . . . 9 4.7における最後のMPLSラベルを飛び出させます。 Diffservトンネリングは.105をモデル化します。 電子証券取引ネットワークが障害があるMPLSドメイン. . . . . . . . . . . . . . . . . . . 10 6。 電子LSPsとL-LSPs. . . . . . 10 7との、より多くのCodepointsの使用。 RFC3168.118におけるトンネルの振舞いとの関係。 展開問題. . . . . . . . . . . . . . . . . . 11 8.1。 できる非電子証券取引ネットワークパケット. . . . . . . . . . . . . 11 8.2をマークします。 MPLSドメイン. . . . . . . . 12 9のできる非電子証券取引ネットワークルータ。 例は.139.1を使用します。 RFCの3168様式の電子証券取引ネットワーク. . . . . . . . . . . . . . . . . . . . 13 9.2。 Diffserv電子LSPs.139.3がある電子証券取引ネットワークの共存。 混雑フィードバックベースの交通工学. . . . . . 14 9.4。 PCN流れ入場コントロールと流れ終了. . . . . 14 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 14 11。 プレ混雑通知. . . . . . 16A.1への承認. . . . . . . . . . . . . . . . . . . . . . . 15付録A.拡大。 IPパケット. . . . . . . . . . . . . . . . . 16へのプッシュをA.2とラベルしてください。 追加MPLSを押すと、.16A.3はラベルされます。 MPLSの中でドメイン.17A.4をマークする入場コントロールか流れ終了。 MPLSラベル(スタックの端でない).17A.5を飛び出させます。 IPのヘッダー.17の引用規格. . . . . . . . . . . . . . . . . . . . . . . 18の有益な参照. . . . . . . . . . . . . . . . . . . . . . 18を暴露する最後のMPLSラベルを飛び出させます。

Davie, et al.               Standards Track                     [Page 2]

RFC 5129                      ECN for MPLS                  January 2008

デイビー、他 規格は2008年1月にMPLSのためにRFC5129電子証券取引ネットワークを追跡します[2ページ]。

1.  Introduction

1. 序論

1.1.  Background

1.1. バックグラウンド

   [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のために、Explicit Congestion Notification(電子証券取引ネットワーク)を定義します。 電子証券取引ネットワークの第一の目的は混雑がパケットを落とさないで合図されるのを許容することです。

   [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構造をサポートする方法を定義します、MPLSヘッダーでDiffserv Code Points(DSCPs)をコード化する方法を含んでいて。 DSCPsはEXP分野でコード化されるかもしれませんが、その分野の他の用途は排除されません。 RFC3270はExplicit Congestion Notification(電子証券取引ネットワーク)マークが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 codepointsを定義するかもしれないかを定義します、他の用途を排除しないで。 IP[RFC3168]への電子証券取引ネットワークの追加を定義する活動に平行です、MPLS[フロイド][Shayman]に電子証券取引ネットワークを加えるのを2つの提案をしました。 しかしながら、これらの提案は路傍のそばに下がりました。 IPのために現在提案された標準と、入場コントロールと流れ終了[PCN]に、プレ混雑通知(PCN)を使用することへの展開している関心である電子証券取引ネットワークで、MPLSの可能にされたドメインから成りながらIPネットワークの向こう側に電子証券取引ネットワークを支持できることへの結果の関心があります。 したがって、MPLS詰め物のヘッダーと縁の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.

私たちは、電子証券取引ネットワークのマークに使用される4codepointsが[RFC3168]にあることに注意します。(codepointsは、IPヘッダーの2ビットを使用することでコード化されます)。 MPLS EXP分野は電子証券取引ネットワークcodepointsをコード化する論理的な場所ですが、3ビット(8codepoints)だけが有効であって同じ分野がまた、DSCP情報を伝えるのに使用されている状態で、電子証券取引ネットワーク目的のために消費されたcodepointsの数を保存する明確な誘因があります。 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]が電子証券取引ネットワーク分野のデフォルト用法を定義することに注意しますが、いくつかのDiffserv Per Hop Behaviors(PHBs)がどう使用されているかに関する電子証券取引ネットワーク分野がことである規格相違を含んでいるかもしれないのが可能性を考慮します。 このドキュメントはその能力を保持しようとします。

Davie, et al.               Standards Track                     [Page 3]

RFC 5129                      ECN for MPLS                  January 2008

デイビー、他 規格は2008年1月にMPLSのためにRFC5129電子証券取引ネットワークを追跡します[3ページ]。

1.2.  Intent

1.2. 意図

   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]がどのように電子証券取引ネットワークのマークを指示するべきであるか、そして、MPLSノードが、パケットのための輸送ができる電子証券取引ネットワークになるかどうかどのように理解しているはずであるかを指定することです。 私たちはブロックとしてこれを提供します。(ブロックから、異なった混雑通知システムを構築します)。私たちは結果として起こる混雑通知はどう混雑を緩和できる上流のノードを提供して戻すかを指定しないつもりです。 例えば、[Shayman]と異なって、縁への縁のMPLSドメインフィードバックを指定しませんが、また、私たちはそれを排除しません。 それにもかかわらず、私たちは電子証券取引ネットワークがIP受信機に向かって前方へ運ばれるつもりであるならMPLSドメインの出口ノードがどうMPLS詰め物からの混雑通知を要約のIPヘッダーにコピーするはずであるかを指定します。 しかし、私たちはMPLS混雑通知があるに違いない*命令ではなく、前方のトランスミッションのためにIPヘッダーにコピーされた*をします。 このドキュメントは、MPLSにおける混雑通知のどんな使用にも一般的であることを目指します。 [RFC3168]のサポートは私たちの第一の動機です。 私たちのアプローチの柔軟性を例証するいくつかの追加潜在的アプリケーションがセクション9で説明されます。 特に、私たちは、1つ以上のレベルの混雑マークを使用するかもしれない可能な将来の計画を支持することを目指します。

1.3.  Terminology

1.3. 用語

   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:

このドキュメントは自由に電子証券取引ネットワーク[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: 経験された混雑。 州のパケットが電子証券取引ネットワークを支持するネットワークでマークされるかもしれない1つ。 パケットはこの状態で電子証券取引ネットワークできるルータによってマークされて、パケットが到着したときこのルータが混雑になっていたのを示します。

   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: 電子証券取引ネットワークできる輸送。 エンドシステムはそれであるときにパケットがあるかもしれない電子証券取引ネットワーク州の1つを送ります。 エンドシステムは、トランスポート・プロトコルの終点が電子証券取引ネットワークできるのを示すためにECT codepointをパケットに付けます。 到着したとき、パケットが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でない: 電子証券取引ネットワークできる輸送でない。 エンドシステムは、トランスポート・プロトコルの終点が電子証券取引ネットワークできないのを示すためにこのcodepointをパケットに付けます。 混雑しているルータはCEのようなパケットをマークできません、そして、その結果、それは混雑を示すためにそれらを落とすことができるだけです。

Davie, et al.               Standards Track                     [Page 4]

RFC 5129                      ECN for MPLS                  January 2008

デイビー、他 規格は2008年1月にMPLSのためにRFC5129電子証券取引ネットワークを追跡します[4ページ]。

   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情報(そして、また、電子証券取引ネットワーク情報を運ぶのに本書では使用される)を伝えるのに使用されるかもしれない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。 終わりから二番目のホップの飛び出し。 Label Switched Path(LSP)の上の終わりから二番目のLabel Switching Router(LSR)がトップラベルをパケットを進める前のパケットから最終的なLSPの上のLSRまで取り除くMPLS操作。

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  Use of MPLS EXP Field for ECN

2. MPLS EXP分野の電子証券取引ネットワークの使用

   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分野でのcodepointsの微分されたサービスの使用を定義します。 これは、電子証券取引ネットワークに利用可能なスペースを制限するためにEXP分野の他のコンパチブル用途を排除しませんが、野原を与えているのが、3ビット(8codepoints)だけであるように明確に思えます。

   [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がPSC LSPを推論している(E- LSP)アプローチでは、MPLS詰め物のヘッダーのEXP分野の異なったcodepointsは、パケットがホップの振舞い(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 LabelがPSC LSPを推論するだけであった(L-LSP)アプローチではMPLSラベルは各PHBのためにクラスの計画をするのが割り当てられます。(LSRがラベルから推進とそのスケジューリングの振舞いの両方を決定するように[RFC3260]で定義されるような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アプローチを使用するなら、電子証券取引ネットワークcodepoint(s)において、スペースがEXP分野にありそうです。 E-LSPアプローチが使用されているところでは、EXP分野のcodepointスペースは不十分である傾向があります。 このドキュメントは、それが、より厳しい問題であるのでE-LSPアプローチによる電子証券取引ネットワークのマークを織り込むのは焦点を合わせます。 その結果、また、L-LSPsと共に同じアプローチを適用できます。

   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

私たちは、MPLSの明白な混雑通知がEXP分野のビットの代わりにcodepointsを使用するべきであることを勧めます。 あらゆるPHBが必ず関連電子証券取引ネットワークcodepointを必要とするというわけではないので、それが必要でしょう。

Davie, et al.               Standards Track                     [Page 5]

RFC 5129                      ECN for MPLS                  January 2008

デイビー、他 規格は2008年1月にMPLSのためにRFC5129電子証券取引ネットワークを追跡します[5ページ]。

   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).

電子証券取引ネットワークのために専用ビットを割り当てるために、無駄です。 (また、ケースが与えられたPHBが1電子証券取引ネットワークのようなcodepointを必要とするかもしれないところにあるかもしれません; 例に関してセクション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.

電子証券取引ネットワークのマークを使用する各PHBに関しては、(CMでない)と、他の少なくとも1codepointであるとマークされたどんな混雑も(CM)であるとマークされた混雑と定義されないとき、私たちは、1EXP codepointが定義されると思います。 したがって、電子証券取引ネットワークのマークを使用する各PHBが少なくとも2EXP codepointsを消費するでしょうが、電子証券取引ネットワークのマークを使用しないPHBsは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:

さらに、電子証券取引ネットワークできる輸送(ECT)で各パケットが受け取られるかどうか内部のLSRsに言うのにMPLS詰め物のヘッダーの最小量のスペースを使用したいと思います。 それにもかかわらず、私たちは、電子証券取引ネットワークのマークが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つの可能なアプローチは混雑しているLSRsがラベルスタックの下部に基本的なIPヘッダーの電子証券取引ネットワーク分野を示すことです。 多くの商業LSRsが他の理由(等しい費用マルチ経路--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 [フロイド]によって示された計画では、ECTとCEは1ビットに積みすぎられます、1がNot-ECTかそれを意味するかもしれませんが、0手段ECTがCEを意味できるように。 パケットが以前に、混雑を経験したかどうか、または電子証券取引ネットワークが輸送で支持されないかどうか決定できないので、上流へ混雑を経験したとしてマークされて、次に第2の混雑しているLSRでのマークのために選ばれるパケットは第2LSRによって落とされるでしょう。

      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

そのようなアプローチが潜在的においしく思えていた間、私たちは以下の理由でここでそれを推薦しません。 いくつかの場合、私たちはずっと前に実際の混雑が(例えば、混雑のプレ通知)であるとマークする電子証券取引ネットワークは使用できるようになりたいです。 こういう事情ですから、各LSRにレートをマークするのがたいてい非取るにたらないかもしれないので、また、以前に著しいパケットが再びそれをマークしたがっているLSRに遭遇するという可能性は非取るにたらなくなるでしょう。 CEとECTでないのがコアルータに区別がつかない場合では、そのようなシナリオは容認できない低下率につながるかもしれません。 あらゆるルータかLSRの典型的なマークレートがpであり、LSRsのネットワークの典型的な直径がdであるなら、著しいパケットが一度以上をマークするのに選ばれるという確率はそうです。

Davie, et al.               Standards Track                     [Page 6]

RFC 5129                      ECN for MPLS                  January 2008

デイビー、他 規格は2008年1月にMPLSのためにRFC5129電子証券取引ネットワークを追跡します[6ページ]。

      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)。] 例えば、6LSRsが並んでいた状態でそれぞれ1%の確率を電子証券取引ネットワークに付けて、もう一度のマークに選ばれていながら既にマークされるパケットの機会は0.15%です。 したがって、ビットを積みすぎる計画は不必要に0.15%の低下率を導入するでしょう。 ほとんどの現代のコアネットワークが近いゼロパケット滴を導入するために大きさで分けられるなら、不必要に1,000のパケットの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.

o 3番目の可能なアプローチは[Shayman]によって示されました。 この計画では、内部のLSRsは、終点が電子証券取引ネットワークできると仮定しますが、最終的なラベルが飛び出すとき、この仮定はチェックされます。 使用終わりから二番目のであるなら、飛び出し) 低下を飛び越してください。LSRは内部であるなら詰め物のヘッダーのEXP分野で電子証券取引ネットワークをマークしましたが、IPヘッダーは、終点が電子証券取引ネットワークできないと言います、縁のルータ、(または、終わりから二番目のルータ、パケット。 私たちは、この計画を推薦して、以下のセクションで、より正確にそれを定義します。(私たちは計画を'1ドメインあたりのECTの照合'と呼びます)。 主要な欠点は混雑に遭遇したときMPLSドメインの出口で落とされる後それでパケットを進めることができるということです。 セクション8.1でこの決定のための原理を与えます。

3.  Per-Domain ECT Checking

3. 1ドメインあたりのECTの照合

   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) ヘッダー。 そのようなノードがLSPの究極の、または、終わりから二番目ののホップであるかもしれないことに注意してください、終わりから二番目のホップの飛び出し(PHP)が採用しているかどうかによって。

   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では、輸送が電子証券取引ネットワークできるかどうかチェックするのに出口ノードは責任を取ります。 このドキュメントは異なるアプローチが異なったシナリオでありそうであるのでこれらのノードがどう混雑通知を伝えるはずであるかを指定しません。 しかしながら、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ヘッダーでは、前方へ、使用されるアプローチは、電子証券取引ネットワーク印をそれに通過する前に輸送が電子証券取引ネットワークできるのをチェックするために同様の注意を払わなければなりません。 明確に、MPLSパケットであるとマークされた特定の混雑のための輸送ができる電子証券取引ネットワークでないことがわかっているなら、この出口ノードでパケットを落とさなければなりません。

   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

アプローチをチェックするドメインECTでは、出口ノードだけが、IPパケットが電子証券取引ネットワークできる輸送のために運命づけられているかどうかチェックします。 したがって、MPLSドメインの中のどんな独身のLSRもそうであってはいけません。

Davie, et al.               Standards Track                     [Page 7]

RFC 5129                      ECN for MPLS                  January 2008

デイビー、他 規格は2008年1月にMPLSのためにRFC5129電子証券取引ネットワークを追跡します[7ページ]。

   configured to enable ECN marking unless all the egress LSRs
   surrounding it are already configured to handle ECN marking.

それを囲むすべての出口LSRsが電子証券取引ネットワークのマークを扱うために既に構成されない場合、電子証券取引ネットワークのマークを可能にするのを構成しました。

   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.

私たちは、ドメインが電子証券取引ネットワークできる出口LSRsによって囲まれると言います。電子証券取引ネットワークによって可能にされたMPLSドメイン。 今期は、すべての出口LSRsが電子証券取引ネットワークによって可能にされるのを含意するだけです。 いくつかの内部のLSRsは電子証券取引ネットワークによって可能にされないかもしれません。 例えば、すべての出口LSRsが電子証券取引ネットワークできた限り、MPLSドメインの内陸部で電子証券取引ネットワークを支持できない何らかの遺産LSRsを使用するのは可能でしょう。 PHPが使用されているなら、飛び出し操作を実行する「終わりから二番目のホップ」ルータが、このような関係においては出口LSRsとして機能しているので電子証券取引ネットワークによって可能にされる必要に注意してください。

4.  ECN-Enabled MPLS Domain

4. 電子証券取引ネットワークによって可能にされたMPLSドメイン

   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縁とコアLSRsで実行されるかもしれないパケットの電子証券取引ネットワークのマークに影響する様々な操作について説明します。

4.1.  Pushing (Adding) One or More Labels to an IP Packet

4.1. より多くの(付加)1ラベルをIPパケットに押します。

   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パケットをカプセルに入れると、電子証券取引ネットワーク分野をIPパケットからMPLS EXP分野に翻訳しなければなりません。 Not-CM(マークされなかったどんな混雑)状態はIPパケットの電子証券取引ネットワーク状態がNot-ECT、ECT(1)またはECT(0)であるならMPLS EXP分野に位置します。 CM状態はIPパケットの電子証券取引ネットワーク状態がCEであるなら設定されます。 1個以上のラベルがひところ押されるなら、同じ値はすべてのラベルスタックエントリーのEXP値に置かれるべきです。

4.2.  Pushing One or More Labels onto an MPLS Labeled Packet

4.2. パケットとラベルされたMPLSに1個以上のラベルを押します。

   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分野は直接プッシュの前の最上のラベルから新たに加えられた外側のラベルまでコピーされます。 1個以上のラベルが押されているなら、同じEXP値はすべてのラベルスタックエントリーにコピーされます。

4.3.  Congestion Experienced in an Interior MPLS Node

4.3. 内部のMPLSノードで経験された混雑

   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).

PHBへのパケット地図のEXP codepointであるなら、それは電子証券取引ネットワークのマークを使用して、マークアルゴリズムは、パケットがマークされるのを必要として、CM状態は設定されます(それがCM状態に既にあることの如何にかかわらず)。

   If the buffer is full, a packet is dropped.

バッファが完全であるなら、パケットは落とされます。

4.4.  Crossing a Diffserv Domain Boundary

4.4. Diffservドメイン境界に交差しています。

   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

MPLSによって要約されたパケットがDiffservドメイン境界を越えるなら、2つのドメインがEXP分野で同じPHBの異なったencodingsを使用するのは、事実であるかもしれません。 そのような場合、EXP分野はそうであるに違いありません。

Davie, et al.               Standards Track                     [Page 8]

RFC 5129                      ECN for MPLS                  January 2008

デイビー、他 規格は2008年1月にMPLSのためにRFC5129電子証券取引ネットワークを追跡します[8ページ]。

   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.

ドメイン境界では、書き直されます。 また、PHBが電子証券取引ネットワークを支持するものであるなら、EXP分野が境界で写像されるとき、適切な電子証券取引ネットワークのマークは保存されるべきです。

   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によって要約されたパケットが電子証券取引ネットワークによって可能にされた(セクション3で定義されるように)ドメインから電子証券取引ネットワークによって可能にされなかったドメインまで交差しているなら、電子証券取引ネットワークによって可能にされたドメインの出口LSRで手順をチェックする出口を実行するのが必要です。 これは、要約のパケットが電子証券取引ネットワークできないなら、パケットを落とさなければならないことを意味します。 これがLSRがMPLSヘッダーの下でラベルスタックを飛び出させないで見ることができなければならない出口を含意することに注意してください。

   The related issue of Diffserv tunnel models is discussed in
   Section 4.7.

セクション4.7でDiffservトンネルモデルの関連する問題について議論します。

4.5.  Popping an MPLS Label (Not the End of the Stack)

4.5. MPLSラベルを飛び出させます。(スタックの端でない)

   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.

パケットがスタックに1個以上のMPLSラベルを持って、トップラベルが飛び出すとき、別のMPLSラベルは露出されています。 この場合、外側のEXP分野から内側のMPLSラベルまで以下の方法で電子証券取引ネットワーク情報を移すべきです。 内側のEXP分野がNot-CMであるなら、内側のEXP分野は外側のEXP分野として同じCMかNot-CM状態に設定されます。 内側のEXP分野がCMであるなら、外側のEXPがさばいても、ものなら何でもそれは変わりがありません。 CMの内側の値とCMでない外側の値が変則的であると考えられるべきであるというメモ、およびSHOULD、何らかの道にLSRによってログインされてください。

4.6.  Popping the Last MPLS Label in the Stack

4.6. スタックにおける最後のMPLSラベルを飛び出させます。

   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に同等にならないなら、それはNot-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であるならNot-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.

このセクションの残りのために、私たちは電子証券取引ネットワーク情報が前方のトランスミッションのためにMPLSヘッダーから露出しているIPヘッダーに移すことであるなら必要とする振舞いについて説明します。 セクション1.2に述べられるように、そのような振舞いは、このドキュメントによって強制されませんが、オペレータによって選択されるかもしれません。

Davie, et al.               Standards Track                     [Page 9]

RFC 5129                      ECN for MPLS                  January 2008

デイビー、他 規格は2008年1月にMPLSのためにRFC5129電子証券取引ネットワークを追跡します[9ページ]。

   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パケットがNot-ECTであるなら、電子証券取引ネットワーク分野はEXP分野がNot-CMであるなら変わりがありません。 内側のパケットの電子証券取引ネットワーク分野がECT(0)、ECT(1)、またはCEに設定されるなら、EXP分野がNot-CMに設定されるなら、電子証券取引ネットワーク分野は変わりがありません。 電子証券取引ネットワーク分野はEXP分野がCMであるならCEに設定されます。 CEの内側の値とCMでない外側の値が変則的であると考えられるべきであるというメモ、およびSHOULD、何らかの道にLSRによってログインされてください。

4.7.  Diffserv Tunneling Models

4.7. Diffservトンネリングモデル

   [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 Domainsの向こう側のDiffservサポートとパイプモデルのために3つのトンネリングモデルについて説明します。 これらのモデルの違いが特定のLSPに沿って移動しますが、パケットに適用されるDiffserv処理が最後のホップのイングレスか、最後のホップの出口か、最後のホップを超えて運ばれるかどうかにあります。 ラベルポップスに従う露出しているヘッダーのどのモードがオペレータによって好まれるかによるか、EXP値またはDSCP値が飛び出し操作で取り除かれるラベルのEXP値に依存しているかもしれません。 私たちはこれらのモデルの使用が電子証券取引ネットワークのマークの場合でEXP値における、Diffserv PHBのコード化に適用されるだけであるべきであり、上で説明された手順に基づいていつも電子証券取引ネットワークのためのcodepointの選択をするべきであると信じています、トンネリングモデルの如何にかかわらず。

5.  ECN-Disabled MPLS Domain

5. 電子証券取引ネットワークが障害があるMPLSドメイン

   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.

電子証券取引ネットワークがドメインのすべての出口LSRsで可能にされないなら、ドメイン中のどんなLSRsでも電子証券取引ネットワークを可能にしてはいけません。 混雑が電子証券取引ネットワークが障害があるMPLSドメインのどんなLSRでも経験されるなら、パケットを落とさなければなりません。 それらをマークしてはいけません。 混雑(例えば、テール低下、REDなど)の間、いつパケットを落とすかを決めるための正確なアルゴリズムはドメインのオペレータのための地域にかかわる事柄です。

6.  The Use of More Codepoints with E-LSPs and L-LSPs

6. 電子LSPsとL-LSPsとの、より多くのCodepointsの使用

   [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] 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.

Davie, et al.               Standards Track                    [Page 10]

RFC 5129                      ECN for MPLS                  January 2008

Davie, et al. Standards Track [Page 10] RFC 5129 ECN for MPLS January 2008

   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.

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.

7.  Relationship to Tunnel Behavior in RFC 3168

7. Relationship to Tunnel Behavior in RFC 3168

   [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] 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.

   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.

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.

8.  Deployment Considerations

8. Deployment Considerations

8.1.  Marking Non-ECN-Capable Packets

8.1. Marking Non-ECN-Capable Packets

   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?

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?

Davie, et al.               Standards Track                    [Page 11]

RFC 5129                      ECN for MPLS                  January 2008

Davie, et al. Standards Track [Page 11] RFC 5129 ECN for MPLS January 2008

   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.

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.

   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.

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.

   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.

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.

   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.

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.

8.2.  Non-ECN-Capable Routers in an MPLS Domain

8.2. Non-ECN-Capable Routers in an MPLS Domain

   What if an MPLS domain wants to use ECN, but not all legacy routers
   are able to support it?

What if an MPLS domain wants to use ECN, but not all legacy routers are able to support it?

   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.

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.

   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

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

Davie, et al.               Standards Track                    [Page 12]

RFC 5129                      ECN for MPLS                  January 2008

Davie, et al. Standards Track [Page 12] RFC 5129 ECN for MPLS January 2008

   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.

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.

9.  Example Uses

9. Example Uses

9.1.  RFC 3168-Style ECN

9.1. RFC 3168-Style 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] 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.

   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.

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.

9.2.  ECN Co-Existence with Diffserv E-LSPs

9.2. ECN Co-Existence with Diffserv E-LSPs

   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.

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.

   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.

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.

Davie, et al.               Standards Track                    [Page 13]

RFC 5129                      ECN for MPLS                  January 2008

Davie, et al. Standards Track [Page 13] RFC 5129 ECN for MPLS January 2008

9.3.  Congestion-Feedback-Based Traffic Engineering

9.3. Congestion-Feedback-Based Traffic Engineering

   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] 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.

9.4.  PCN Flow Admission Control and Flow Termination

9.4. PCN Flow Admission Control and Flow Termination

   [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] 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.

   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.

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.

10.  Security Considerations

10. Security Considerations

   We believe no new vulnerabilities are introduced by this document.

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.

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.

Davie, et al.               Standards Track                    [Page 14]

RFC 5129                      ECN for MPLS                  January 2008

Davie, et al. Standards Track [Page 14] RFC 5129 ECN for MPLS January 2008

   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.

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.

11.  Acknowledgments

11. Acknowledgments

   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.

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.

Davie, et al.               Standards Track                    [Page 15]

RFC 5129                      ECN for MPLS                  January 2008

Davie, et al. Standards Track [Page 15] RFC 5129 ECN for MPLS January 2008

Appendix A.  Extension to Pre-Congestion Notification

Appendix A. Extension to Pre-Congestion Notification

   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.

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.

   The relevant aspects of PCN for the purposes of this discussion are:

The relevant aspects of PCN for the purposes of this discussion are:

   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 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  A packet can go from NM to AM, from NM to TM, or from AM to TM,
      but no other transition is possible.

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  The determination of whether a packet is subject to PCN is based
      on the PHB of the packet.

o The determination of whether a packet is subject to PCN is based on the PHB of the packet.

   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.

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.

A.1.  Label Push onto IP Packet

A.1. Label Push onto IP Packet

   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.

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.

A.2.  Pushing Additional MPLS Labels

A.2. Pushing Additional MPLS Labels

   The procedures of Section 4.2 apply.

The procedures of Section 4.2 apply.

Davie, et al.               Standards Track                    [Page 16]

RFC 5129                      ECN for MPLS                  January 2008

Davie, et al. Standards Track [Page 16] RFC 5129 ECN for MPLS January 2008

A.3.  Admission Control or Flow Termination Marking Inside MPLS Domain

A.3. Admission Control or Flow Termination Marking Inside MPLS Domain

   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.

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.

A.4.  Popping an MPLS Label (Not End of Stack)

A.4. Popping an MPLS Label (Not End of Stack)

   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:

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:

   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 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  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 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  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 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.

A.5.  Popping the Last MPLS Label to Expose IP Header

A.5. Popping the Last MPLS Label to Expose IP Header

   When popping the last MPLS Label exposes the IP header, there are two
   cases to consider:

When popping the last MPLS Label exposes the IP header, there are two cases to consider:

   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 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  the popping LSR *is* the egress router of the PCN region.

o the popping LSR *is* the egress router of the PCN region.

   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:

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:

   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 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.

Davie, et al.               Standards Track                    [Page 17]

RFC 5129                      ECN for MPLS                  January 2008

Davie, et al. Standards Track [Page 17] RFC 5129 ECN for MPLS January 2008

   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 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  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 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.

Normative References

Normative References

   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3031]       Rosen, E., Viswanathan, A., and R. Callon,
                   "Multiprotocol Label Switching Architecture",
                   RFC 3031, January 2001.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

   [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., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.

   [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., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.

   [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., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.

   [RFC4301]       Kent, S. and K. Seo, "Security Architecture for the
                   Internet Protocol", RFC 4301, December 2005.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

Informative References

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: A Quality of Service Model for Pre-Congestion Notification (PCN)", Work in Progress, September 2007.

   [BRISCOE-CL]    Briscoe, B., "Pre-Congestion Notification Marking",
                   Work in Progress, October 2006.

[BRISCOE-CL] Briscoe, B., "Pre-Congestion Notification Marking", Work in Progress, October 2006.

   [BRISCOE-ECN]   Briscoe, B., "Layered Encapsulation of Congestion
                   Notification", Work in Progress, July 2007.

[BRISCOE-ECN] Briscoe, B., "Layered Encapsulation of Congestion Notification", Work in Progress, July 2007.

Davie, et al.               Standards Track                    [Page 18]

RFC 5129                      ECN for MPLS                  January 2008

Davie, et al. Standards Track [Page 18] RFC 5129 ECN for MPLS January 2008

   [Floyd]         Ramakrishnan, K., Floyd, S., and B. Davie, "A
                   Proposal to Incorporate ECN in MPLS", Work in
                   Progress, June 1999.

[Floyd] Ramakrishnan, K., Floyd, S., and B. Davie, "A Proposal to Incorporate ECN in MPLS", Work in Progress, June 1999.

   [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., and K. Chan, "RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification (PCN)", Work in Progress, June 2006.

   [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., and T. Phelan, "RMD-QOSM - The Resource Management in Diffserv QOS Model", Work in Progress, November 2007.

   [PCN]           Eardley, P., "Pre-Congestion Notification
                   Architecture", Work in Progress, November 2007.

[PCN] Eardley, P., "Pre-Congestion Notification Architecture", Work in Progress, November 2007.

   [RFC3260]       Grossman, D., "New Terminology and Clarifications for
                   Diffserv", RFC 3260, April 2002.

[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.

   [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., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.

   [RFC4340]       Kohler, E., Handley, M., and S. Floyd, "Datagram
                   Congestion Control Protocol (DCCP)", RFC 4340,
                   March 2006.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

   [Shayman]       Shayman, M. and R. Jaeger, "Using ECN to Signal
                   Congestion Within an MPLS Domain", Work in Progress,
                   November 2000.

[Shayman] Shayman, M. and R. Jaeger, "Using ECN to Signal Congestion Within an MPLS Domain", Work in Progress, November 2000.

   [TSVWG]         Chan, K., Babiarz, J., and F. Baker, "Aggregation of
                   DiffServ Service Classes", Work in Progress,
                   November 2007.

[TSVWG] Chan, K., Babiarz, J., and F. Baker, "Aggregation of DiffServ Service Classes", Work in Progress, November 2007.

Davie, et al.               Standards Track                    [Page 19]

RFC 5129                      ECN for MPLS                  January 2008

Davie, et al. Standards Track [Page 19] RFC 5129 ECN for MPLS January 2008

Authors' Addresses

Authors' Addresses

   Bruce Davie
   Cisco Systems, Inc.
   1414 Mass. Ave.
   Boxborough, MA  01719
   USA

Bruce Davie Cisco Systems, Inc. 1414 Mass. Ave. Boxborough, MA 01719 USA

   EMail: bsd@cisco.com

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 Ipswich Suffolk IP5 3RE United Kingdom

   EMail: bob.briscoe@bt.com

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 Ipswich Suffolk IP5 3RE United Kingdom

   EMail: june.tay@bt.com

EMail: june.tay@bt.com

Davie, et al.               Standards Track                    [Page 20]

RFC 5129                      ECN for MPLS                  January 2008

Davie, et al. Standards Track [Page 20] RFC 5129 ECN for MPLS January 2008

Full Copyright Statement

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

Copyright (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.

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.

   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.

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.

Intellectual Property

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.

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.

   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.

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.

   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に情報を記述してください。

Davie, et al.               Standards Track                    [Page 21]

デイビー、他 標準化過程[21ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

scrollbar-highlight-color スクロールバーのハイライトの色を指定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る