RFC 7274 - Allocating and Retiring Special-Purpose MPLS Labels 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7274
タイトル : RFC 7274 - 特別な目的のMPLSラベルの割り当てと廃止
翻訳編集 : 自動生成

[要約] RFC 7274は、特定の目的のためにMPLSラベルを割り当ておよび廃止するための手順を定義しています。このRFCの目的は、MPLSネットワークで特別な目的のためにラベルを効果的に管理するためのガイドラインを提供することです。

Internet Engineering Task Force (IETF)                       K. Kompella
Request for Comments: 7274                              Juniper Networks
Updates: 3032, 3038, 3209, 3811, 4182, 4928, 5331,          L. Andersson
         5586, 5921, 5960, 6391, 6478, 6790                       Huawei
Category: Standards Track                                      A. Farrel
ISSN: 2070-1721                                         Juniper Networks
                                                               June 2014

Allocating and Retiring Special-Purpose MPLS Labels

特別な目的のMPLSラベルの割り当てと廃止

Abstract

概要

Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special-purpose labels" in this document.

一部のMPLSラベルは、特定の目的で割り当てられています。この目的のために、ラベルのブロック（0〜15）が確保されています。これらのラベルは一般に「予約済みラベル」と呼ばれます。このドキュメントでは、これらを「特殊ラベル」と呼びます。

As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for.

これらの専用ラベルは16個しかないため、新しい専用ラベルの割り当てには注意が必要です。しかし、同時に、要求されたときに前進することを許可する必要があります。

This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special-purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLS Label Values" and creates a new registry called the "Extended Special-Purpose MPLS Label Values" registry.

このメモは、特殊目的のラベルの割り当てと廃棄の新しい手順、および特殊目的のラベルスペースを拡張する方法と、データプレーンで拡張された特殊目的のラベルを処理する方法の説明を定義します。最後に、このメモは、特別な目的のラベルのIANAレジストリの名前を「特別な目的のMPLSラベル値」に変更し、「拡張された特別な目的のMPLSラベル値」レジストリと呼ばれる新しいレジストリを作成します。

This document updates a number of previous RFCs that use the term "reserved label". Specifically, this document updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790.

このドキュメントは、「予約済みラベル」という用語を使用する以前の多くのRFCを更新します。具体的には、このドキュメントは、RFC 3032、3038、3209、3811、4182、4928、5331、5586、5921、5960、6391、6478、および6790を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7274.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7274で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. Questions .......................................................3
   3. Answers .........................................................4
      3.1. Extended Special-Purpose MPLS Label Values .................5
      3.2. Process for Retiring Special-Purpose Labels ................6
   4. Updated RFCs ....................................................7
   5. IANA Considerations .............................................8
   6. Security Considerations .........................................8
   7. Acknowledgments .................................................9
   8. References ......................................................9
      8.1. Normative References .......................................9
      8.2. Informative References ....................................10

1. Introduction

1. はじめに

The MPLS Label Stack Encoding specification [RFC3032] defined four special-purpose label values (0 to 3) and set aside values 4 through 15 for future use. These labels have special significance in both the control and the data plane. Since then, three further values have been allocated (values 7, 13, and 14 in [RFC6790], [RFC5586], and [RFC3429], respectively), leaving nine unassigned values from the original space of sixteen.

MPLSラベルスタックエンコーディング仕様[RFC3032]は、4つの特別な目的のラベル値（0〜3）を定義し、将来の使用のために値4〜15を確保しました。これらのラベルは、コントロールとデータプレーンの両方で特別な意味を持っています。それ以来、さらに3つの値（[RFC6790]、[RFC5586]、および[RFC3429]の値7、13、および14）が割り当てられ、16の元の空間から割り当てられていない9つの値が残ります。

While the allocation of three out of the remaining twelve special-purpose label values in the space of about 12 years is not in itself a cause for concern, the scarcity of special-purpose labels is. Furthermore, many of the special-purpose labels require special processing by forwarding hardware, changes to which are often expensive and sometimes impossible. Thus, documenting a newly allocated special-purpose label value is important.

残りの12個の特殊用途ラベル値のうち3つを約12年のスペースに割り当てること自体は問題の原因ではありませんが、特殊用途ラベルの不足が原因です。さらに、専用ラベルの多くは、ハードウェアを転送することによる特別な処理を必要とし、その変更は、多くの場合高価で、時には不可能です。したがって、新しく割り当てられた専用ラベル値を文書化することが重要です。

This memo outlines some of the issues in allocating and retiring special-purpose label values and defines mechanisms to address these. This memo also extends the space of special-purpose labels.

このメモは、特別な目的のラベル値の割り当てと廃止におけるいくつかの問題を概説し、これらに対処するメカニズムを定義しています。このメモは、特別な目的のラベルのスペースも拡張します。

1.1. Conventions Used in This Document

1.1. このドキュメントで使用される規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

Two new acronyms are introduced:

2つの新しい頭字語が導入されました。

XL Extension Label. A label that indicates that an extended special-purpose label follows.

XL拡張ラベル。拡張特殊用途ラベルが続くことを示すラベル。

ESPL Extended Special-Purpose Label. A special-purpose label that is placed in the label stack after the Extension Label. The combination of XL and ESPL might be regarded as a new form of "compound label" comprising more than one consecutive entry in the label stack.

ESPL拡張特別目的ラベル。拡張ラベルの後のラベルスタックに配置される特別な目的のラベル。 XLとESPLの組み合わせは、ラベルスタックに複数の連続したエントリを含む新しい形式の「複合ラベル」と見なされる場合があります。

2. Questions

2. ご質問

In re-appraising MPLS special-purpose labels, the following questions come to mind:

MPLS特殊用途ラベルを再評価する場合、次の質問が思い浮かびます。

1. What allocation policies should be applied by IANA for the allocation of special-purpose labels? Should Early Allocation [RFC7120] be allowed? Should there be labels for experimental use or private use [RFC5226]?

1. IANAは、特別な目的のラベルの割り当てにどのような割り当てポリシーを適用する必要がありますか？早期割り当て[RFC7120]を許可する必要がありますか？実験的使用または私的使用のためのラベルがあるべきですか？[RFC5226]？

2. What documentation is required for special-purpose labels allocated henceforth?

2. 今後割り当てられる特殊用途のラベルにはどのような書類が必要ですか？

3. Should a special-purpose label ever be retired? What criteria are relevant here? Can a retired special-purpose label ever be re-allocated for a different purpose? What procedures and time frames are appropriate?

3. 特別な目的のラベルは廃止される必要がありますか？ここで関連する基準は何ですか？廃止された専用ラベルを別の目的で再割り当てすることはできますか？どのような手順と時間枠が適切ですか？

4. The special-purpose label value of 3 (the "Implicit NULL Label" [RFC3032]) is only used in signaling, never in the data plane. Could it (and should it) be used in the data plane? If so, how and for what purpose?

4. 特別な目的のラベル値3（「暗黙のNULLラベル」[RFC3032]）はシグナリングでのみ使用され、データプレーンでは使用されません。データプレーンで使用できますか？もしそうなら、どのようにそしてどのような目的で？

5. What is a feasible mechanism to extend the space of special-purpose labels should this become necessary?

5. これが必要になった場合に、特別な目的のラベルのスペースを拡張するための実現可能なメカニズムは何ですか？

6. Should extended special-purpose labels be used for load balancing?

6. ロードバランシングに拡張特殊目的ラベルを使用する必要がありますか？

3. Answers

3. 答え

This section provides answers to the questions posed in the previous section.

このセクションでは、前のセクションで提示された質問に対する回答を提供します。

１。

A. Allocation of special-purpose MPLS labels is via "Standards Action".

A.専用MPLSラベルの割り当ては、「標準アクション」を介して行われます。

B. The IANA registry will be renamed "Special-Purpose MPLS Label Values".

B. IANAレジストリは「特別な目的のMPLSラベル値」に名前が変更されます。

C. Early allocation may be allowed on a case-by-case basis.

C.ケースバイケースで早期割り当てが許可される場合があります。

D. The current space of 16 special-purpose labels is too small for setting aside values for experimental or private use. However, the "Extended Special-Purpose MPLS Label Values" registry created by this document has enough space, and this document defines a range for experimental use.

D. 16の特別な目的のラベルの現在のスペースは、実験的または私的使用のために値を確保するには小さすぎます。ただし、このドキュメントによって作成された「拡張特殊目的MPLSラベル値」レジストリには十分なスペースがあり、このドキュメントは実験的使用の範囲を定義しています。

2. A Standards Track RFC must accompany a request for allocation of Standards Action special-purpose labels, as per [RFC5226].

2. [RFC5226]のように、Standards Track RFCは、Standards Action特殊目的ラベルの割り当ての要求に添付する必要があります。

3. The retirement of a special-purpose MPLS label value must follow a strict and well-documented process. This is necessary since we must avoid orphaning the use of this label value in existing deployments. This process is detailed in Section 3.2.

3. 特別な目的のMPLSラベル値の廃止は、厳格で十分に文書化されたプロセスに従う必要があります。これは、既存のデプロイメントでこのラベル値の使用を孤立させる必要がないため必要です。このプロセスの詳細については、セクション3.2を参照してください。

4. For now, the use of the "Implicit NULL Label" (value 3) in the data plane will not be allowed. If this decision is revisited later, an accompanying Standards Track RFC that details the use of the label, a discussion of possible sources of confusion between signaling and data plane, and mitigation thereof shall be required.

4. 現時点では、データプレーンでの「暗黙のNULLラベル」（値3）の使用は許可されません。この決定が後で再検討される場合、ラベルの使用、シグナリングとデータプレーンの間の混乱の可能性のある原因の議論、およびその軽減についての付属の標準トラックRFCが必要になります。

5. A special-purpose label (the "Extension Label", XL, value 15) is set aside for the purpose of extending the space of special-purpose labels. Further details are described in Section 3.1.

5. 特別な目的のラベル（「拡張ラベル」、XL、値15）は、特別な目的のラベルのスペースを拡張する目的で確保されています。詳細については、セクション3.1で説明します。

6. [RFC6790] says that special-purpose labels MUST NOT be used for load balancing. The same logic applies to extended special-purpose labels (ESPLs). Thus, this document specifies that ESPLs MUST NOT be used for load balancing. It is noted that existing implementations would violate this, as they do not recognize XL as anything other than a single special-purpose label and will not expect an ESPL to follow. The consequence is that if ESPLs are used in some packets of a flow, these packets may be delivered on different paths and so could be re-ordered. However, it is important to specify the correct behavior for future implementations, hence the use of "MUST NOT".

6. [RFC6790]は、特別な目的のラベルをロードバランシングに使用してはならないことを述べています。同じロジックが拡張特殊目的ラベル（ESPL）にも適用されます。したがって、このドキュメントでは、ESPLを負荷分散に使用してはならないことを明記しています。既存の実装はXLを単一の専用ラベル以外のものとして認識せず、ESPLが続くことを期待しないため、これは違反することに注意してください。その結果、ESPLがフローの一部のパケットで使用される場合、これらのパケットは異なるパスで配信される可能性があり、そのため、並べ替えられる可能性があります。ただし、将来の実装では正しい動作を指定することが重要なので、「必須ではない」を使用します。

A further question that needed to be settled in this regard was whether a "regular" special-purpose label retains its meaning if it follows the XL. The answer to this question is provided in Section 3.1.

この点について解決する必要があるさらなる質問は、「通常の」特別な目的のラベルがXLに従う場合にその意味を保持するかどうかでした。この質問に対する回答は、セクション3.1に記載されています。

3.1. Extended Special-Purpose MPLS Label Values

3.1. 拡張専用MPLSラベル値

The XL MUST be followed by another label L (and thus MUST have the bottom-of-stack bit clear). L MUST be interpreted as an ESPL and interpreted as defined in a new registry created by this document (see Section 5). Whether or not L has the bottom-of-stack bit set depends on whether other labels follow L. The XL only assigns special meaning to L. A label after L (if any) is parsed as usual and thus may be a regular label or a special-purpose label; if the latter, it may be the XL and thus followed by another ESPL.

XLの後には別のラベルLが続く必要があります（したがって、スタックの最下位ビットがクリアされている必要があります）。 LはESPLとして解釈され、このドキュメントによって作成された新しいレジストリで定義されたとおりに解釈される必要があります（セクション5を参照）。 Lにスタックの最下位ビットが設定されているかどうかは、他のラベルがLに続くかどうかに依存します。XLはLに特別な意味を割り当てるだけです。Lの後のラベル（存在する場合）は通常どおりに解析され、通常のラベルまたは専用ラベル;後者の場合、それはXLであり、したがって別のESPLが続く場合があります。

The label value 15 is set aside as the XL as shown in Section 5.

セクション5に示すように、ラベル値15はXLとして確保されています。

Values 0-15 of the "Extended Special-Purpose MPLS Label Values" registry are set aside as reserved. Furthermore, values 0-6 and 8-15 MUST NOT appear in the data plane following an XL; an LSR processing a packet with an XL at the top of the label stack followed by a label with value 0-6 or 8-15 MUST drop the packet.

「Extended Special-Purpose MPLS Label Values」レジストリの値0〜15は、予約済みとして予約されています。さらに、値0-6および8-15は、XLに続くデータプレーンに現れてはなりません（MUST NOT）。ラベルスタックの一番上にXLがあり、その後に値0-6または8-15のラベルが続くパケットを処理するLSRは、パケットをドロップする必要があります。

Label 7 (when received) retains its meaning as Entropy Label Indicator (ELI) whether a regular special-purpose label or an ESPL; this is because of backwards compatibility with existing implemented and deployed code and hardware that looks for the ELI without verifying if the previous label is XL or not. However, when an LSR inserts an entropy label, it MUST insert the ELI as a regular special-purpose label, not as an ESPL.

ラベル7（受け取ったとき）は、通常の特殊用途ラベルでもESPLでも、エントロピーラベルインジケーター（ELI）としての意味を保持します。これは、以前のラベルがXLであるかどうかを確認せずにELIを探す既存の実装およびデプロイされたコードとハードウェアとの下位互換性があるためです。ただし、LSRがエントロピーラベルを挿入するときは、ESLをESPLではなく、通常の特殊用途ラベルとして挿入する必要があります。

3.1.1. Forwarding Packets with Extended Special-Purpose Labels

3.1.1. 拡張特殊目的ラベルを使用したパケットの転送

If an LSR encounters the XL at the top of stack and it doesn't understand extension labels, it MUST drop the packet as specified for the handling of an invalid incoming label according to [RFC3031]. If an LSR encounters an ESPL at the top of stack (after the XL) that it does not understand, it MUST drop the packet, again following the same procedure. In either case, the LSR MAY log the event, but such logging MUST be rate-limited.

LSRがスタックの最上位でXLに遭遇し、拡張ラベルを理解できない場合、[RFC3031]に従って無効な着信ラベルの処理に指定されたとおりにパケットをドロップする必要があります。 LSRがスタックの最上部（XLの後）でESPLに遭遇した場合、それが理解できない場合は、同じ手順に従ってパケットをドロップする必要があります。どちらの場合でも、LSRはイベントをログに記録できますが、そのようなログ記録はレート制限されている必要があります。

An LSR SHOULD NOT make forwarding decisions on labels not at the top of stack. For load-balancing decisions, see Answer 6 in Section 3.

LSRは、スタックの最上位にないラベルの転送決定を行うべきではありません（SHOULD NOT）。負荷分散の決定については、セクション3の回答6を参照してください。

3.1.2. Choosing a New Special-Purpose Label

3.1.2. 新しい特別な目的のラベルの選択

When allocating a new special-purpose label, protocol designers should consider whether they could use an extended special-purpose label. Doing so would help to preserve the scarce resources of "normal" special-purpose labels for use in cases where minimizing the size of the label stack is particularly important.

新しい専用ラベルを割り当てるとき、プロトコル設計者は拡張された専用ラベルを使用できるかどうかを検討する必要があります。そうすることで、ラベルスタックのサイズを最小化することが特に重要な場合に使用するために、「通常の」特殊用途ラベルの希少なリソースを維持するのに役立ちます。

3.2. Process for Retiring Special-Purpose Labels

3.2. 特別な目的のラベルを廃止するプロセス

While the following process is defined for the sake of completeness, note that retiring special-purpose labels is difficult. It is recommended that this process be used sparingly.

次のプロセスは完全を期すために定義されていますが、専用ラベルの廃止は難しいことに注意してください。このプロセスは慎重に使用することをお勧めします。

a. A label value that has been assigned from the "Special-Purpose MPLS Label Values" registry may be deprecated by IETF consensus with review by the MPLS working group (or designated experts if the working group or a successor does not exist). An RFC with at least Informational status is required.

a. 「特別な目的のMPLSラベル値」レジストリから割り当てられたラベル値は、MPLSワーキンググループ（またはワーキンググループまたは後継者が存在しない場合は指定された専門家）によるレビューにより、IETFの合意により非推奨になる場合があります。少なくとも情報ステータスのあるRFCが必要です。

The RFC will direct IANA to mark the label value as "deprecated" in the registry but will not release it at this stage.

RFCは、IANAにレジストリでラベル値を「非推奨」としてマークするように指示しますが、この段階ではリリースしません。

Deprecating means that no further specifications using the deprecated value will be documented.

非推奨とは、非推奨の値を使用したそれ以上の仕様が文書化されないことを意味します。

At the same time, this is an indication to vendors not to include the deprecated value in new implementations and to operators to avoid including it in new deployments.

同時に、これは、ベンダーが新しい実装に非推奨の値を含めないようにすることと、オペレーターが新しいデプロイメントにそれを含めないようにすることを示しています。

b. Twelve months after the RFC deprecating the label value is published, an IETF-wide survey may be conducted to determine if the deprecated label value is still in use. If the survey indicates that the deprecated label value is in use, the survey may be repeated after an additional 6 months.

b. ラベル値を非推奨にするRFCが公開されてから12か月後に、非推奨のラベル値がまだ使用されているかどうかを判断するためにIETF全体の調査が行われる場合があります。廃止予定のラベル値が使用されていることが調査で示された場合、さらに6か月後に調査が繰り返されることがあります。

c. If the survey indicates that a deprecated label value is not in use, 24 months after the RFC that deprecated the label value was published, publication may be requested of an IETF Standards Track Internet-Draft that retires the deprecated label value. This document will request that IANA release the label value for future use and assignment.

c. 調査により、非推奨のラベル値が使用されていないことが示された場合、ラベル値を非推奨にしたRFCが公開されてから24か月後に、非推奨のラベル値を廃止するIETF標準トラックインターネットドラフトの公開が要求される場合があります。このドキュメントは、IANAが将来の使用と割り当てのためにラベル値をリリースすることを要求します。

4. Updated RFCs

4. 更新されたRFC

The following RFCs contain references to the term "reserved labels":

次のRFCには、「予約済みラベル」という用語への参照が含まれています。

   o  [RFC3032] ("MPLS Label Stack Encoding")
   o  [RFC3038] ("VCID Notification over ATM link for LDP")
   o  [RFC3209] ("RSVP-TE: Extensions to RSVP for LSP Tunnels")
   o  [RFC3811] ("Definitions of Textual Conventions (TCs) for
      Multiprotocol Label Switching (MPLS) Management")
   o  [RFC4182] ("Removing a Restriction on the use of MPLS Explicit
      NULL")
   o  [RFC4928] ("Avoiding Equal Cost Multipath Treatment in MPLS
      Networks")
   o  [RFC5331] ("MPLS Upstream Label Assignment and Context-Specific
      Label Space")
   o  [RFC5586] ("MPLS Generic Associated Channel")
   o  [RFC5921] ("A Framework for MPLS in Transport Networks")
   o  [RFC5960] ("MPLS Transport Profile Data Plane Architecture")
   o  [RFC6391] ("Flow-Aware Transport of Pseudowires over an MPLS
      Packet Switched Network")
   o  [RFC6478] ("Pseudowire Status for Static Pseudowires")
   o  [RFC6790] ("MPLS Entropy Labels")

All such references should be read as "special-purpose labels".

このような参照はすべて、「専用ラベル」として読み取る必要があります。

5. IANA Considerations

5. IANAに関する考慮事項

IANA has made the following changes and additions to its registration of MPLS labels.

IANAは、MPLSラベルの登録に次の変更と追加を行いました。

1. Changed the name of the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry to "Special-Purpose MPLS Label Values".

1. 「Multiprotocol Label Switching Architecture（MPLS）Label Values」レジストリの名前を「Special-Purpose MPLS Label Values」に変更しました。

2. Changed the allocation policy for the "Special-Purpose MPLS Label Values" registry to Standards Action.

2. 「特別な目的のMPLSラベル値」レジストリの割り当てポリシーを標準アクションに変更しました。

3. Assigned value 15 from the "Special-Purpose MPLS Label Values" registry, naming it the "Extension Label" and citing this document as the reference.

3. 「特別な目的のMPLSラベル値」レジストリから値15を割り当て、「拡張ラベル」という名前を付け、このドキュメントを参照として引用します。

4. Created a new registry called the "Extended Special-Purpose MPLS Label Values" registry. The registration procedure is Standards Action, and the ranges for this registry are as shown in Table 1 (using terminology from [RFC5226]). Early allocation following the policy defined in [RFC7120] is allowed only for those values assigned by Standards Action.

4. 「Extended Special-Purpose MPLS Label Values」レジストリと呼ばれる新しいレジストリを作成しました。登録手順は標準アクションであり、このレジストリの範囲は表1に示すとおりです（[RFC5226]の用語を使用）。 [RFC7120]で定義されたポリシーに従う早期割り当ては、標準アクションによって割り当てられた値に対してのみ許可されます。

   +---------------------+---------------------------------------------+
   | Range               | Allocation Policy                           |
   +---------------------+---------------------------------------------+
   | 0 - 15              | Reserved.  Never to be made available for   |
   |                     | allocation.                                 |
   |                     |                                             |
   | 16 - 239            | Unassigned                                  |
   |                     |                                             |
   | 240 - 255           | Reserved for Experimental Use               |
   |                     |                                             |
   | 256 - 1048575       | Reserved.  Not to be made available for     |
   |                     | allocation without a new Standards Track    |
   |                     | RFC to define an allocation policy.         |
   +---------------------+---------------------------------------------+

Table 1

表1

6. Security Considerations

6. セキュリティに関する考慮事項

This document does not make a large change to the operation of the MPLS data plane, and security considerations are largely unchanged from those specified in the MPLS Architecture [RFC3031] and in the MPLS and GMPLS Security Framework [RFC5920].

このドキュメントでは、MPLSデータプレーンの動作に大きな変更は加えていません。セキュリティに関する考慮事項は、MPLSアーキテクチャ[RFC3031]やMPLSおよびGMPLSセキュリティフレームワーク[RFC5920]で指定されているものとほとんど同じです。

However, it should be noted that increasing the label stack can cause packet fragmentation and may also make packets unprocessable by some implementations. This document provides a protocol-legal way to increase the label stack through the insertion of additional {XL,ESPL} pairs at a greater rate than insertion of single "rogue" labels. This might provide a way to attack some nodes in a network that can only process label stacks of a certain size without violating the protocol rules.

ただし、ラベルスタックを増やすと、パケットの断片化が発生する可能性があり、一部の実装ではパケットが処理不能になる可能性があることに注意してください。このドキュメントでは、追加の{XL、ESPL}ペアを1つの「不正な」ラベルの挿入よりも高い速度で挿入することにより、ラベルスタックを増やすプロトコル-法的な方法を提供します。これは、プロトコルルールに違反せずに特定のサイズのラベルスタックのみを処理できるネットワーク内の一部のノードを攻撃する方法を提供する可能性があります。

This document also describes events that may cause an LSR to issue event logs at a per-packet rate. It is critically important that implementations rate-limit such logs.

このドキュメントでは、LSRがパケットごとのレートでイベントログを発行する原因となるイベントについても説明します。このようなログを実装でレート制限することは非常に重要です。

7. Acknowledgments

7. 謝辞

Thanks to Pablo Frank and Lizhong Jin for useful discussions. Thanks to Curtis Villamizar, Mach Chen, Alia Atlas, Eric Rosen, Maria Napierala, Roni Even, Stewart Bryant, John Drake, Andy Malis, and Tom Yu for useful comments.

有益な議論をしてくれたPablo FrankとLizhong Jinに感謝します。有用なコメントを提供してくれたCurtis Villamizar、Mach Chen、Alia Atlas、Eric Rosen、Maria Napierala、Roni Even、Stewart Bryant、John Drake、Andy Malis、Tom Yuに感謝します。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

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

[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、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。、フェドルコフ、G。、レクター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月。

[RFC3038] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P. Doolan, "VCID Notification over ATM link for LDP", RFC 3038, January 2001.

[RFC3038]永見和也、勝部裕子、出水奈美、江崎博之、P。ドゥーラン、「LDPのATMリンクを介したVCID通知」、RFC 3038、2001年1月。

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。

[RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.

[RFC3811] Nadeau、T.、Ed。およびJ. Cucchiara、Ed。、「Definions of Textual Conventions（TCs）for Multiprotocol Label Switching（MPLS）Management」、RFC 3811、2004年6月。

[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005.

[RFC4182]ローゼン、E。、「MPLS明示的NULLの使用に関する制限の削除」、RFC 4182、2005年9月。

[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.

[RFC4928] Swallow、G.、Bryant、S。、およびL. Andersson、「Avoiding Equal Cost Multipath Treatment in MPLS Networks」、BCP 128、RFC 4928、2007年6月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。

[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.

[RFC5331] Aggarwal、R.、Rekhter、Y。、およびE. Rosen、「MPLSアップストリームラベル割り当ておよびコンテキスト固有のラベルスペース」、RFC 5331、2008年8月。

[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.

[RFC5960] Frost、D.、Ed。、Bryant、S.、Ed。、and M. Bocci、Ed。、 "MPLS Transport Profile Data Plane Architecture"、RFC 5960、August 2010。

[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.

[RFC6391]ブライアント、S。、エド、フィルスフィルス、C。、ドラフズ、U。、コンペラ、V。、リーガン、J。、およびS.アマンテ、「MPLSパケット交換ネットワーク上の疑似配線のフロー対応トランスポート」、RFC 6391、2011年11月。

[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, May 2012.

[RFC6478]マティーニ、L。、スワロー、G。、ヘロン、G。、およびM.ボッチ、「静的な疑似配線の疑似配線ステータス」、RFC 6478、2012年5月。

[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.

[RFC6790] Kompella、K.、Drake、J.、Amante、S.、Henderickx、W。、およびL. Yong、「The Use of Entropy Labels in MPLS Forwarding」、RFC 6790、2012年11月。

[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, January 2014.

[RFC7120]コットン、M。、「規格トラックコードポイントの初期IANA割り当て」、BCP 100、RFC 7120、2014年1月。

8.2. Informative References

8.2. 参考引用

[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002.

[RFC3429]太田浩一郎、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）運用および保守（OAM）機能のための「OAMアラートラベル」の割り当て」、RFC 3429、2002年11月。

[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.

[RFC5586] Bocci、M。、編、Vigoureux、M、編、およびS. Bryant、編、「MPLS Generic Associated Channel」、RFC 5586、2009年6月。

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.

[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。

[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.

[RFC5921] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、and L. Berger、 "A Framework for MPLS in Transport Networks"、RFC 5921、 2010年7月。

Authors' Addresses

著者のアドレス

Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 US

Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089 US

   EMail: kireeti.kompella@gmail.com

Loa Andersson Huawei

ロア・アンダーソン・ファーウェイ

   EMail: loa@mail01.huawei.com

Adrian Farrel Juniper Networks

エイドリアンファレルジュニパーネットワークス

   EMail: adrian@olddog.co.uk