[要約] RFC 5331は、MPLSネットワークでの上流ラベル割り当てとコンテキスト固有のラベルスペースに関するガイドラインです。目的は、MPLSネットワークの効率的なラベル割り当てと管理を実現することです。
Network Working Group R. Aggarwal
Request for Comments: 5331 Juniper Networks
Category: Standards Track Y. Rekhter
Juniper Networks
E. Rosen
Cisco Systems, Inc.
August 2008
MPLS Upstream Label Assignment and Context-Specific Label Space
MPLSアップストリームラベルの割り当てとコンテキスト固有のラベルスペース
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space".
RFC 3031は、MPLSアーキテクチャをダウンストリーム割り当てのMPLSラベルに制限します。このドキュメントでは、上流に割り当てられたMPLSラベルの概念を紹介します。上流のMPLSラベルの割り当ての手順を説明し、「コンテキスト固有のラベル空間」の概念を導入します。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................2
3. Context-Specific Label Space ....................................2
4. Upstream Label Assignment .......................................3
4.1. Upstream-Assigned and Downstream-Assigned Labels ...........4
5. Assigning Upstream-Assigned Labels ..............................5
6. Distributing Upstream-Assigned Labels ...........................5
7. Upstream Neighbor Label Space ...................................6
8. Context Label on LANs ...........................................9
9. Usage of Upstream-Assigned Labels ..............................10
10. Security Considerations .......................................10
11. Acknowledgements ..............................................11
12. References ....................................................11
12.1. Normative References .....................................11
12.2. Informative References ...................................11
RFC 3031 [RFC3031] limits the MPLS architecture to downstream-assigned MPLS labels. To quote from RFC 3031:
RFC 3031 [RFC3031]は、MPLSアーキテクチャをダウンストリーム割り当てのMPLSラベルに制限します。RFC 3031から引用する：
"In the MPLS architecture, the decision to bind a particular label L to a particular Forwarding Equivalence Class (FEC) F is made by the Label Switching Router (LSR) which is DOWNSTREAM with respect to that binding. The downstream LSR then informs the upstream LSR of the binding. Thus labels are "downstream-assigned", and label bindings are distributed in the "downstream to upstream" direction."
「MPLSアーキテクチャでは、特定のラベルLを特定の転送等価クラス（FEC）Fにバインドする決定は、その結合に関して下流のラベルスイッチングルーター（LSR）によって行われます。バインディングのLSR。したがって、ラベルは「ダウンストリーム割り当て」であり、ラベルバインディングは「下流から上流の」方向に分布しています。
This document introduces the notion of upstream-assigned MPLS labels to the MPLS architecture. The procedures for upstream assignment of MPLS labels are described.
このドキュメントでは、MPLSアーキテクチャに上流で割り当てられたMPLSラベルの概念を紹介します。MPLSラベルの上流の割り当ての手順について説明します。
RFC 3031 describes per-platform and per-interface label space. This document generalizes the latter to a "Context-Specific Label Space" and describes a "Neighbor Label Space" as an example of this. Upstream-assigned labels are always looked up in a context-specific label space.
RFC 3031は、プラットフォームごととインターフェイスごとのラベルスペースについて説明しています。このドキュメントは、後者を「コンテキスト固有のラベル空間」に一般化し、「近隣ラベルスペース」をこの例として説明しています。アップストリーム割り当てのラベルは、常にコンテキスト固有のラベル空間で調べられます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
RFC 3031 describes per-platform and per-interface label spaces. This document introduces the more general concept of a "Context-Specific Label Space". An LSR may maintain one or more context-specific label spaces. In general, labels MUST be looked up in the per-platform label space unless something about the context determines that a label be looked up in a particular context-specific label space.
RFC 3031は、プラットフォームごととインターフェイスごとのラベルスペースについて説明しています。このドキュメントでは、「コンテキスト固有のラベル空間」のより一般的な概念を紹介します。LSRは、1つ以上のコンテキスト固有のラベルスペースを維持する場合があります。一般に、コンテキストに関する何かが特定のコンテキスト固有のラベル空間でラベルを調べることを決定しない限り、ラベルをプラットフォームごとのラベル空間で調べる必要があります。
One example of a context-specific label space is the per-interface label space discussed in RFC 3031. When an MPLS packet is received over a particular interface, the top label of the packet may need to be looked up in the receiving interface's per-interface label space. In this case, the receiving interface is the context of the packet. Whether MPLS packets received over a particular interface need to have their top labels looked up in a per-interface label space depends on some characteristic or configuration of the interface.
コンテキスト固有のラベルスペースの1つの例は、RFC 3031で説明されているインターフェイスごとのラベル空間です。MPLSパケットが特定のインターフェイスで受信されると、パケットのトップレーベルを受信インターフェイスのパーマで検索する必要がある場合があります。インターフェイスラベルスペース。この場合、受信インターフェイスはパケットのコンテキストです。特定のインターフェイスで受信したMPLSパケットが、インターフェイスごとのラベルスペースでトップラベルを調べる必要があるかどうかは、インターフェイスの特徴または構成に依存します。
Per-interface label space [RFC3031] is an example of a context-specific label space used for downstream-assigned labels. Context-specific label spaces can also be used for upstream-assigned labels, as described below.
インターフェイスごとのラベルスペース[RFC3031]は、ダウンストリーム割り当てラベルに使用されるコンテキスト固有のラベル空間の例です。以下で説明するように、コンテキスト固有のラベルスペースは、上流のラベルにも使用できます。
When MPLS labels are upstream-assigned, the context of an MPLS label L is provided by the LSR that assigns the label and binds the label to a FEC F for a Label Switched Path (LSP) LSP1. The LSR that assigns the label distributes the binding and context to an LSR Lr that then receives MPLS packets on LSP1 with label L. When Lr receives an MPLS packet on LSP1, it MUST be able to determine the context of this packet.
MPLSラベルがアップストリーム割り当ての場合、MPLSラベルLのコンテキストは、ラベルを割り当て、ラベルをFEC FにバインドするLSRによって提供されます。ラベルを割り当てるLSRは、バインディングとコンテキストをLSR LRに分配し、LSP1でMPLSパケットをレーベルLで受信します。LRがLSP1でMPLSパケットを受信すると、このパケットのコンテキストを決定できる必要があります。
An example of such a context is a tunnel over which MPLS packets on LSP1 may be received. In this case, the top label of the MPLS packet, after tunnel decapsulation, is looked up in a label space that is specific to the root of the tunnel. This does imply that Lr be able to determine the tunnel over which the packet was received. Therefore, if the tunnel is an MPLS tunnel, penultimate-hop-popping (PHP) MUST be disabled for the tunnel.
このようなコンテキストの例は、LSP1のMPLSパケットが受信される可能性があるトンネルです。この場合、トンネル脱カプセル化後のMPLSパケットのトップラベルは、トンネルの根に固有のラベル空間で調べられます。これは、LRがパケットが受信されたトンネルを決定できることを意味します。したがって、トンネルがMPLSトンネルである場合、トンネルのために最後から2番目のホップポッピング（PHP）を無効にする必要があります。
Another example of such a context is the neighbor from which MPLS packets on LSP1 may be received. In this case, the top label of the MPLS packet, transmitted by the neighbor on LSP1, is looked up in a "Neighbor-Specific Label Space".
このようなコンテキストの別の例は、LSP1のMPLSパケットを受信する隣人です。この場合、LSP1で隣人が送信したMPLSパケットのトップレーベルは、「隣接固有のラベルスペース」で見上げられます。
The above two examples are further described in Section 7.
上記の2つの例については、セクション7でさらに説明します。
There may be other sorts of contexts as well. For instance, we define the notion of an MPLS label being used to establish a context, i.e., identify a label space. A "context label" is one that identifies a label table in which the label immediately below the context label should be looked up. A context label carried as an outermost label over a particular multi-access subnet/tunnel MUST be unique within the scope of that subnet/tunnel.
他の種類のコンテキストもあるかもしれません。たとえば、コンテキストを確立するために使用されているMPLSラベルの概念、つまりラベル空間を識別することを定義します。「コンテキストラベル」は、コンテキストラベルのすぐ下のラベルを調べる必要があるラベルテーブルを識別するものです。特定のマルチアクセスサブネット/トンネルの上で最も外側のラベルとして運ばれるコンテキストラベルは、そのサブネット/トンネルの範囲内で一意でなければなりません。
When two MPLS LSRs are adjacent in an MPLS Label Switched Path (LSP), one of them can be termed an "upstream LSR" and the other a "downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd, that have agreed to bind Label L to a FEC F for packets sent from Ru to Rd. Then, with respect to this binding, Ru is the "upstream LSR", and Rd is the "downstream LSR"."
2つのMPLS LSRがMPLSラベルスイッチドパス（LSP）に隣接する場合、そのうちの1つは「上流LSR」と呼ばれ、もう1つは「下流LSR」[RFC3031]と呼ばれます。RUからRDに送信されたパケットのFEC FにラベルLを結合することに同意した2つのLSR、RuとRdを考えてみましょう。次に、この結合に関して、Ruは「上流のLSR」であり、RDは「下流LSR」です。
If the binding between L and F was made by Rd and advertised to Ru, then the label binding is known as "downstream-assigned". RFC 3031 only discusses downstream-assigned label bindings.
LとFの間のバインディングがRDによって作成され、RUに宣伝された場合、ラベルバインディングは「ダウンストリーム割り当て」として知られています。RFC 3031は、下流に割り当てられたラベルバインディングのみについて説明します。
If the binding between L and F was made by Ru and advertised to Rd, then the label binding is known as "upstream-assigned".
LとFの間のバインディングがRUによって作成され、RDに宣伝された場合、ラベルバインディングは「アップストリーム割り当て」として知られています。
If the binding between L and F was made by a third party, say R3, and then advertised to both Ru and Rd, we also refer to the label binding as "upstream-assigned".
LとFの間のバインディングが第三者、たとえばR3によって作成され、RUとRDの両方に宣伝された場合、ラベルバインディングを「上流割り当て」と呼びます。
An important observation about upstream-assigned labels is the following. When an upstream-assigned label L is at the top of the label stack, it must be looked up by an LSR that is not the LSR that assigned and distributed the label binding for L. Therefore, an upstream-assigned label MUST always be looked up in a context-specific label space, as described in Section 7.
上流で割り当てられたラベルに関する重要な観察は、次のことです。アップストリーム割り当てのラベルLがラベルスタックの上部にある場合、Lのラベルバインディングを割り当てて配布したLSRではないLSRを調べる必要があります。セクション7で説明されているように、コンテキスト固有のラベル空間で。
We do not require any coordination between the upstream label assignments and the downstream label assignments; a particular label value may be upstream-assigned to one FEC and downstream-assigned to a different FEC.
上流のラベル割り当てと下流のラベル割り当ての間に調整は必要ありません。特定のラベル値は、1つのFECに上流で割り当てられ、異なるFECに下流に割り当てられます。
The ability to use upstream-assigned labels is an OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless it is known that the downstream LSR supports them.
アップストリーム割り当てのラベルを使用する機能は、オプションの機能です。下流のLSRがそれらをサポートしていることがわかっていない限り、アップストリーム割り当てのラベルを使用してはなりません。
One use case of upstream-assigned labels is MPLS multicast, and an example of this is provided in Section 9.
上流で割り当てられたラベルの1つのユースケースはMPLSマルチキャストであり、この例はセクション9に記載されています。
It is possible that some LSRs on an LSP for FEC F distribute downstream-assigned label bindings for FEC F, while other LSRs distribute upstream-assigned label bindings. It is possible for an LSR to distribute a downstream-assigned label binding for FEC F to its upstream adjacent LSR AND distribute an upstream-assigned label binding for FEC F to its downstream adjacent LSR. When two LSRs, Ru and Rd, are adjacent on an LSP for FEC F (with Ru being the upstream neighbor and Rd the downstream neighbor), either Ru distributes an upstream-assigned label binding for F to Rd, or else Rd distributes a downstream-assigned label binding to Ru, but NOT both. Whether upstream-assigned or downstream-assigned labels are to be used for a particular FEC depends on the application using the LSP.
FEC FのLSPの一部のLSRは、FEC F用に下流で割り当てられたラベルバインディングを分布させ、他のLSRは上流で割り当てられたラベルバインディングを分布させる可能性があります。LSRは、FEC Fの下流で割り当てられたラベル結合を上流の隣接LSRに分配し、FEC Fの上流で割り当てられたラベル結合を下流の隣接LSRに分配することができます。2つのLSR、RUとRDがFEC FのLSPに隣接している場合（RUは上流の隣人であり、RDが下流の隣人です）、RUはFの上流で割り当てられたラベルバインディングをRDに分配するか、RDが下流に分散します。 - RUへのバインディングされたラベルの割り当て。ただし、両方ではありません。上流で割り当てられたラベルまたは下流で割り当てられたラベルは、特定のFECに使用されるかどうかは、LSPを使用してアプリケーションに依存します。
Any application that requires the use of upstream-assigned labels MUST specify that explicitly, or else it is to be assumed that downstream-assigned labels are used. An application on an LSR uses a label distribution protocol to indicate to its peer LSRs whether a particular label binding distributed by the LSR uses upstream-assigned or downstream-assigned label. Details of such procedures are outside the scope of this document. In some cases, the decision as to which is used for a particular application may be made by a configuration option.
アップストリーム割り当てのラベルを使用する必要があるアプリケーションは、明示的に明示的に指定する必要があります。そうしないと、下流で割り当てられたラベルが使用されていると想定される必要があります。LSRのアプリケーションは、ラベル分布プロトコルを使用して、LSRによって分布している特定のラベルバインディングがアップストリーム割り当てまたはダウンストリーム割り当てラベルを使用するかどうかをピアLSRに示します。このような手順の詳細は、このドキュメントの範囲外です。場合によっては、特定のアプリケーションに使用される決定は、構成オプションによって行われる場合があります。
The only requirement on an upstream LSR assigning upstream-assigned labels is that an upstream-assigned label must be unambiguous in the context-specific label space in which the downstream LSR will look it up. An upstream LSR that is the headend of multiple tunnels SHOULD, by default, assign the upstream-assigned labels, for all the LSPs carried over these tunnels, from a single label space, which is common to all those tunnels. Further, an upstream LSR that is the head of multiple tunnels SHOULD use the same IP address as the head identifier of these tunnels, provided that the head identifier of these tunnels includes an IP address. The LSR could assign the same label value to both a downstream-assigned and an upstream-assigned label. The downstream LSR always looks up upstream-assigned MPLS labels in a context-specific label space as described in Section 7.
アップストリーム割り当てのラベルを割り当てる上流のLSRの唯一の要件は、下流のLSRがそれを調べるコンテキスト固有のラベル空間では、上流で割り当てられたラベルが明確でなければならないことです。複数のトンネルのヘッドエンドであるアップストリームLSRは、デフォルトでは、これらのトンネルに共通する単一のラベル空間から、これらのトンネルを持ち歩くすべてのLSPに、上流で割り当てられたラベルを割り当てる必要があります。さらに、複数のトンネルのヘッドである上流のLSRは、これらのトンネルのヘッド識別子にIPアドレスが含まれている場合、これらのトンネルのヘッド識別子と同じIPアドレスを使用する必要があります。LSRは、同じラベル値を、下流で割り当てられたラベルとアップストリーム割り当ての両方のラベルの両方に割り当てることができます。ダウンストリームLSRは、セクション7で説明されているように、コンテキスト固有のラベル空間で常に上流に割り当てられたMPLSラベルを調べます。
An entry for the upstream-assigned labels is not created in the Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these labels are not incoming labels. Instead, an upstream label is an outgoing label, with respect to the upstream LSR, for MPLS packets transmitted on the MPLS LSP in which the upstream LSR is adjacent to the downstream LSR. Hence, an upstream label is part of a Next Hop Label Forwarding Entry (NHLFE) at the upstream LSR.
上流で割り当てられたラベルのエントリは、上流のLSRの着信ラベルマップ（ILM）[RFC3031]で作成されていません。これらのラベルは着信ラベルではないためです。代わりに、アップストリームラベルは、上流LSRが下流LSRに隣接するMPLS LSPに送信されるMPLSパケットの上流LSRに関して、発信ラベルです。したがって、アップストリームラベルは、上流LSRの次のホップラベル転送エントリ（NHLFE）の一部です。
When Ru advertises a binding of label L for FEC F to Rd, it creates a NHLFE entry corresponding to L. This NHLFE entry results in imposing the label L on the MPLS label stack of the packet forwarded using the NHLFE entry. If Ru is a transit router on the LSP for FEC F, it binds the ILM for the LSP to this NHLFE. If Ru is an ingress router on the LSP for FEC F, it binds the FEC to the NHLFE entry.
ruがfec f to rdのラベルLのバインディングを宣伝すると、Lに対応するNHLFEエントリが作成されます。このNHLFEエントリは、NHLFEエントリを使用して転送されたパケットのMPLSラベルスタックにラベルLを押し付けます。RUがFEC FのLSPのトランジットルーターである場合、LSPのILMをこのNHLFEに結合します。RUがFEC FのLSPの侵入ルーターである場合、FECをNHLFEエントリに結合します。
Upstream-assigned label bindings MUST NOT be used unless it is known that the downstream LSR supports them. How this is known is outside the scope of this document.
下流のLSRがそれらをサポートしていることがわかっていない限り、アップストリーム割り当てのラベルバインディングは使用しないでください。これがどのように知られているかは、このドキュメントの範囲外です。
MPLS upstream label assignment requires a label distribution protocol to distribute the binding from the upstream LSR to the downstream LSR. Considerations that pertain to a label distribution protocol that are described in [RFC3031] apply.
MPLSアップストリームラベルの割り当てでは、上流のLSRから下流LSRにバインディングを分配するためのラベル分布プロトコルが必要です。[RFC3031]で説明されているラベル分布プロトコルに関連する考慮事項が適用されます。
The distribution of the upstream-assigned labels is similar to either the ordered LSP control or independent LSP control of the downstream-assigned labels. In the former case, an LSR distributes an upstream- assigned label binding for a FEC F if it is either (a) the ingress LSR for FEC F, or (b) if it has already received an upstream label binding for that FEC from its adjacent upstream LSR for FEC F, or (c) if it has received a request for a downstream label binding from its upstream adjacent LSR. In the latter case, each LSR, upon noting that it recognizes a particular FEC, makes an independent decision to bind an upstream-assigned label to that FEC and to distribute that binding to its label distribution peers.
上流で割り当てられたラベルの分布は、順序付けられたLSPコントロールまたはダウンストリーム割り当てラベルの独立したLSP制御のいずれかに似ています。前者の場合、LSRは、（a）fec fの侵入LSR、または（b）そのFECからの上流のラベルバインディングをすでに受け取っている場合、fec fの上流に割り当てられたラベルバインディングを分布します。FEC Fの隣接するアップストリームLSR、または（c）上流の隣接LSRから下流のラベル結合のリクエストを受け取った場合。後者の場合、各LSRは、特定のFECを認識していることに注目して、アップストリーム割り当てのラベルをそのFECに結合し、そのバインディングをラベル配布ピアに分配するという独立した決定を下します。
If the top label of an MPLS packet being processed by LSR Rd is upstream-assigned, the label is looked up in a context-specific label space, not in a per-platform label space.
LSR RDによって処理されているMPLSパケットのトップレーベルがアップストリーム割り当てされている場合、ラベルはプラットフォームごとのラベルスペースではなく、コンテキスト固有のラベル空間で調べられます。
Rd uses a context-specific label space that it maintains for Ru to "reserve" MPLS labels assigned by Ru. Hence, if Ru distributes an upstream-assigned label binding L for FEC F to Rd, then Rd reserves L in the separate ILM for Ru's context-specific label space. This is the ILM that Rd uses to look up an MPLS label that is upstream-assigned by Ru. This label may be the top label on the label stack of a packet received from Ru or it may be exposed as the top label on the label stack, as a result of Rd popping one or more labels off the label stack, from such a packet.
RDは、RUが割り当てたMPLSラベルを「予約」するために維持するコンテキスト固有のラベル空間を使用します。したがって、RUがFEC Fの上流で割り当てられたラベル結合LをRDに分配する場合、RDはRUのコンテキスト固有のラベル空間を個別のILMに留保します。これは、RDがRUによって上流で割り当てられたMPLSラベルを検索するために使用するILMです。このラベルは、RUから受け取ったパケットのラベルスタックのトップレーベルであるか、RDがそのようなパケットからラベルスタックから1つ以上のラベルをポップした結果、ラベルスタックのトップレーベルとして公開される場合があります。。
This implies that Rd MUST be able to determine whether the top label of an MPLS packet being processed is upstream-assigned and, if yes, the "context" of this packet. How this determination is made depends on the mechanism that is used by Ru to transmit the MPLS packet with an upstream-assigned top label L to Rd.
これは、RDが処理されるMPLSパケットのトップレーベルが上流で割り当てられているかどうか、そしてもしそうなら、このパケットの「コンテキスト」であるかどうかを判断できる必要があることを意味します。この決定がどのように行われるかは、MPLSパケットを上流で割り当てられたトップラベルLとRDに送信するためにRUが使用するメカニズムに依存します。
If Ru transmits this packet by encapsulating it in an IP or MPLS tunnel, then the fact that L is upstream-assigned is determined by Rd by the tunnel on which the packet is received. Whether a given tunnel can be used for transmitting MPLS packets with either downstream-assigned or upstream-assigned MPLS labels, or both, depends on the tunnel type and is described in [RFC5332]. When Rd receives MPLS packets with a top label L on such a tunnel, it determines the "context" of this packet based on the tunnel on which the packet is received. There must be a mechanism for Ru to inform Rd that a particular tunnel from Ru to Rd will be used by Ru for transmitting MPLS packets with upstream-assigned MPLS labels. Such a mechanism will be provided by the label distribution protocol between Ru and Rd and will likely require extensions to existing label distribution protocols. The description of such a mechanism is outside the scope of this document.
RUがIPまたはMPLSトンネルにカプセル化することによりこのパケットを送信する場合、Lが上流に割り当てられているという事実は、パケットが受信されるトンネルによってRDによって決定されます。特定のトンネルが、下流または上流のMPLSラベルのいずれかでMPLSパケットを送信できるかどうか、またはその両方を使用できるかどうかは、トンネルタイプに依存し、[RFC5332]に記載されています。RDは、このようなトンネルでトップラベルLを備えたMPLSパケットを受信すると、パケットが受信されるトンネルに基づいてこのパケットの「コンテキスト」を決定します。RUがRDからRDへの特定のトンネルが、上流で割り当てられたMPLSラベルを使用してMPLSパケットを送信するためにRUによって使用されることをRDに通知するメカニズムが必要です。このようなメカニズムは、RUとRDの間のラベル分布プロトコルによって提供され、既存のラベル分布プロトコルへの拡張が必要になる可能性があります。このようなメカニズムの説明は、このドキュメントの範囲外です。
Rd maintains an "Upstream Neighbor Label Space" for upstream-assigned labels, assigned by Ru. When Ru transmits MPLS packets the top label of which is upstream-assigned over IP or MPLS tunnels, then Rd MUST be able to determine the root of these IP/MPLS tunnels. Rd MUST then use a separate label space for each unique root.
RDは、RUによって割り当てられた上流で割り当てられたラベルの「アップストリームネイバーラベルスペース」を維持しています。RUがMPLSパケットを送信する場合、そのトップラベルがIPまたはMPLSトンネル上で上流で割り当てられている場合、RDはこれらのIP/MPLSトンネルのルートを決定できる必要があります。RDは、一意のルートごとに個別のラベルスペースを使用する必要があります。
The root is identified by the head-end IP address of the tunnel. If the same upstream router, Ru, uses different head-end IP addresses for different tunnels, then the downstream router, Rd, MUST maintain a different Upstream Neighbor Label Space for each such head-end IP address.
ルートは、トンネルのヘッドエンドIPアドレスによって識別されます。同じ上流のルーターであるRUが異なるトンネルに異なるヘッドエンドIPアドレスを使用する場合、下流のルーター、RDは、そのようなヘッドエンドIPアドレスごとに異なるアップストリームネイバーラベルスペースを維持する必要があります。
Consider the following conditions:
次の条件を検討してください。
1) Ru is the "root" of two tunnels, call them A and B.
1) ruは2つのトンネルの「ルート」であり、それらをAとBと呼びます
2) IP address X is an IP address of Ru.
2) IPアドレスXはRUのIPアドレスです。
3) The signaling protocol used to set up tunnel A identified A's root node as IP address X.
3) IPアドレスXとして識別されたAのルートノードをトンネルAのセットアップに使用したシグナリングプロトコル。
4) The signaling protocol used to set up tunnel B identified B's root node as IP address X.
4) トンネルBのセットアップに使用されるシグナル伝達プロトコルは、BのルートノードをIPアドレスXとして識別しました。
5) Packets sent through tunnels A and B may be carrying upstream-assigned labels.
5) トンネルAとBを介して送信されるパケットは、上流のラベルを搭載している可能性があります。
6) Ru is the LSR that assigned the upstream-assigned labels mentioned in condition 5.
6) RUは、条件5で言及された上流の割り当てされたラベルを割り当てたLSRです。
If and only if these conditions hold, then Ru MUST use the same label space when upstream-assigning labels for packets that travel through tunnel A that it uses when upstream-assigning labels for packets that travel through tunnel B.
これらの条件が保持されている場合にのみ、Ruは、トンネルBを通過するパケットの上流に付着するラベルを使用するときに使用するトンネルAを走行するパケットの上流のラベルを上流で付着するときに、同じラベルスペースを使用する必要があります。
Suppose that Rd is a node that belongs to tunnels A and B, but is not the root node of either tunnel. Then Rd may assume that the same upstream-assigned label space is used on both tunnels IF AND ONLY IF the signaling protocol used to set up tunnel A identified the root node as IP address X and the signaling protocol used to set up tunnel B identified the root node as the same IP address X.
RDがトンネルAとBに属するノードであるが、どちらのトンネルのルートノードではないと仮定します。次に、RDは、トンネルAのセットアップに使用されたシグナリングプロトコルがIPアドレスXとしてルートノードを識別し、トンネルBのセットアップに使用されるシグナリングプロトコルが識別された場合にのみ、両方のトンネルで使用されると同じ上流で割り当てられたラベルスペースが使用されると仮定することができます。同じIPアドレスXと同じルートノード。
In addition, the protocol that is used for distributing the upstream-assigned label to be used over a particular tunnel MUST identify the "assigner" using the same IP address that is used by the protocol that sets up the tunnel to identify the root node of the tunnel. Implementors must take note of this, even if the tunnel setup protocol is different from the protocol that is used for distributing the upstream-assigned label to be used over the tunnel.
さらに、特定のトンネルを介して使用される上流に割り当てられたラベルを配布するために使用されるプロトコルは、トンネルを設定してルートノードを識別するプロトコルによって使用される同じIPアドレスを使用して「割り当て者」を識別する必要があります。トンネル。トンネルのセットアッププロトコルが、トンネル上で使用される上流のラベルを配布するために使用されるプロトコルとは異なる場合でも、実装者はこれに注意する必要があります。
The precise set of procedures for identifying the IP address of the root of the tunnel depend, of course, on the protocol used to set up the tunnel. For Point-to-Point (P2P) tunnels, the intention is that the headend of the tunnel is the "root". For Point-to-Multipoint (P2MP) or Multipoint-to-Multipoint (MP2MP) tunnels, one can always identify one node as being the "root" of the tunnel.
トンネルのルートのIPアドレスを識別するための正確な一連の手順は、もちろん、トンネルのセットアップに使用されるプロトコルに依存します。ポイントツーポイント（P2P）トンネルの場合、トンネルのヘッドエンドが「ルート」であるという意図があります。Point-to-Multipoint（P2MP）またはMultipoint-to-MultiPoint（MP2MP）トンネルの場合、1つのノードをトンネルの「ルート」であると常に識別できます。
Some tunnels may be set up by configuration, rather than by signaling. In these cases, the IP address of the root of the tunnel must be configured.
一部のトンネルは、シグナリングではなく、構成によってセットアップできます。これらの場合、トンネルのルートのIPアドレスを構成する必要があります。
Some tunnels may not even require configuration, e.g., a Generic Routing Encapsulation (GRE) tunnel can be "created" just by encapsulating packets and transmitting them. In such a case, the IP address of the root is considered to be the IP source address of the encapsulated packets.
一部のトンネルは構成を必要としない場合があります。たとえば、パケットをカプセル化して送信するだけで、一般的なルーティングカプセル化（GRE）トンネルを「作成」できます。そのような場合、ルートのIPアドレスは、カプセル化されたパケットのIPソースアドレスと見なされます。
If the tunnel on which Rd receives MPLS packets with a top label L is an MPLS tunnel, then Rd determines a) that L is upstream-assigned and b) the context for L, from the labels above L in the label stack. Note that one or more of these labels may also be upstream-assigned labels.
RDがトップレーベルLを持つMPLSパケットを受信するトンネルがMPLSトンネルである場合、RDはa）Lが上流で割り当てられていること、b）ラベルスタックのL上のLのラベルからLのコンテキストを決定します。これらのラベルの1つ以上は、上流に割り当てられたラベルである可能性があることに注意してください。
If the tunnel on which Rd receives MPLS packets with a top label L is an IP/GRE tunnel, then Rd determines a) that L is upstream-assigned [RFC5332] and b) the context for L, from the source address in the IP header.
RDがトップレーベルLでMPLSパケットを受信するトンネルがIP/GREトンネルである場合、RDはa）Lがアップストリーム割り当て[RFC5332]、b）IPのソースアドレスからLのコンテキストを決定します。ヘッダ。
When Ru and Rd are adjacent to each other on a multi-access data link media, if Ru would transmit the packet, with top label L, by encapsulating it in a data link frame, then whether L is upstream-assigned or downstream assigned can be determined by Rd, as described in [RFC5332]. This is possible because if L is upstream-assigned, then [RFC5332] uses a different ether type in the data link frame. However, this is not sufficient for Rd to determine the context of this packet. In order for Rd to determine the context of this packet, Ru encapsulates the packet in a one-hop MPLS tunnel. This tunnel uses an MPLS context label that is assigned by Ru. Section 8 describes how the context label is assigned. Rd maintains a separate "Upstream Neighbor Label Space" for Ru. The "context" of this packet, i.e., Ru's upstream neighbor label space, in which L was reserved, is determined by Rd from the top context label and the interface on which the packet is received. The ether type in the data link frame is set to indicate that the top label is upstream-assigned. The second label in the stack is L.
RUとRDがマルチアクセスデータリンクメディアで互いに隣接している場合、RUがデータリンクフレームにカプセル化することにより、RUがトップラベルLを使用してパケットを送信する場合、Lがアップストリーム割り当てまたは下流の割り当て缶であるかどうか[RFC5332]に記載されているように、RDによって決定されます。これは、Lが上流に割り当てられている場合、[RFC5332]がデータリンクフレームで異なるエーテルタイプを使用するため、可能です。ただし、これはRDがこのパケットのコンテキストを決定するのに十分ではありません。RDがこのパケットのコンテキストを決定するために、RUは1ホップMPLSトンネルのパケットをカプセル化します。このトンネルは、RUによって割り当てられたMPLSコンテキストラベルを使用します。セクション8では、コンテキストラベルの割り当て方法について説明します。RDは、RUの個別の「上流の隣接ラベルスペース」を維持しています。このパケットの「コンテキスト」、つまり、lが予約されているRuの上流の隣接ラベルスペースは、トップコンテキストラベルとパケットが受信されるインターフェイスからRDによって決定されます。データリンクフレームのエーテルタイプは、トップラベルがアップストリーム割り当てであることを示すように設定されています。スタックの2番目のラベルはLです。
For a labeled packet with an ether type of "upstream label assignment", the top label is used as the context. The context label value is assigned by the upstream LSR and advertised to the downstream LSRs. Mechanisms for advertising the context label will be provided by the label distribution protocol between the upstream and downstream LSRs. The description of such a mechanism is outside the scope of this document.
エーテルタイプの「アップストリームラベル割り当て」を備えたラベル付きパケットの場合、トップラベルはコンテキストとして使用されます。コンテキストラベル値は、上流のLSRによって割り当てられ、ダウンストリームLSRに宣伝されます。コンテキストラベルを広告するためのメカニズムは、上流と下流のLSRの間のラベル分布プロトコルによって提供されます。このようなメカニズムの説明は、このドキュメントの範囲外です。
The context label assigned by an LSR for use on a particular LAN interface MUST be unique across all the context labels assigned by other LSRs for use on the same LAN. When a labeled packet is received from the LAN, the context label MUST be looked up in the context of the LAN interface on which the packet is received.
特定のLANインターフェイスで使用するためにLSRによって割り当てられたコンテキストラベルは、同じLANで使用するために他のLSRによって割り当てられたすべてのコンテキストラベルにわたって一意でなければなりません。LANからラベル付きパケットが受信されると、パケットが受信されるLANインターフェイスのコンテキストでコンテキストラベルを調べる必要があります。
This document provides two methods that an LSR can use to choose a context label to advertise on a particular LAN.
このドキュメントは、LSRが特定のLANで宣伝するコンテキストラベルを選択するために使用できる2つの方法を提供します。
The first method requires that each LSR be provisioned with a 20-bit context label for each LAN interface on which a context label is required. It is then left to the provisioning system to make sure that an assigned context label is unique across the corresponding LAN.
最初の方法では、各LSRに、コンテキストラベルが必要な各LANインターフェイスの20ビットコンテキストラベルを提供する必要があります。その後、プロビジョニングシステムに任され、割り当てられたコンテキストラベルが対応するLAN全体で一意であることを確認します。
The second method allows the context labels to be auto-generated, but is only applicable if each LSR on the LAN has an IPv4 address as its primary IP address for the corresponding LAN interface. (If the LAN contains LSRs that have only IPv6 addresses for the LAN interface, then the first method is used.)
2番目の方法では、コンテキストラベルを自動生成できますが、LAN上の各LSRが対応するLANインターフェイスの主要なIPアドレスとしてIPv4アドレスを持っている場合にのみ適用可能です。（LANに、LANインターフェイスのIPv6アドレスのみがあるLSRが含まれている場合、最初の方法が使用されます。）
Suppose that each LAN interface is configured with a primary IPv4 address that is unique on that LAN. The host part of the IPv4 address, identified by the network mask, is unique. If the IPv4 network mask is greater than 12 bits, it is possible to map the remaining 20 bits into a unique context label value. This enables the LSRs on the LAN to automatically generate a unique context label. To ensure that auto-generated context label values do not fall into the reserved label space range [RFC3032], the value of the host part of the IPv4 address is offset with 0x10, if this value is not greater than 0xFFFEF. Values of the host part of the IPv4 address greater than 0xFFFEF are not allowed to be used as context labels.
各LANインターフェイスが、そのLANで一意のプライマリIPv4アドレスで構成されていると仮定します。ネットワークマスクで識別されるIPv4アドレスのホスト部分は一意です。IPv4ネットワークマスクが12ビットを超える場合、残りの20ビットを一意のコンテキストラベル値にマッピングすることができます。これにより、LAN上のLSRが一意のコンテキストラベルを自動的に生成できます。自動生成されたコンテキストラベル値が予約済みのラベルスペース範囲[RFC3032]に分類されないようにするために、この値が0xFFFEF以下でない場合、IPv4アドレスのホスト部分の値は0x10でオフセットされます。0xFFFEFを超えるIPv4アドレスのホスト部分の値は、コンテキストラベルとして使用することは許可されていません。
Consider LSR Rm (downstream) connected to Ru1 (upstream) on a LAN interface and to Ru2 (upstream) on a different LAN interface. Rm could receive a context label value derived from the LAN interface from Ru1 and from Ru2. It is possible that the context label values used by Ru1 and Ru2 are the same. This would occur if the LAN interfaces of both Ru1 and Ru2 are configured with a primary IPv4 address where the lowest 20 bits are equal. However, this does not create any ambiguity, as it has already been stated that the context label MUST be looked up in the context of the LAN interface on which the packet is received.
LANインターフェイス上のRU1（上流）および異なるLANインターフェイス上のRU2（上流）に接続されたLSR RM（下流）を考えてみましょう。RMは、RU1およびRU2からLANインターフェイスから派生したコンテキストラベル値を受信できます。RU1とRU2で使用されるコンテキストラベル値が同じである可能性があります。これは、RU1とRU2の両方のLANインターフェイスが、最低20ビットが等しいプライマリIPv4アドレスで構成されている場合に発生します。ただし、これは曖昧さを生み出しません。これは、パケットが受信されるLANインターフェイスのコンテキストでコンテキストラベルを調べる必要があるとすでに述べられているためです。
A typical use case of upstream-assigned labels is for MPLS multicast and is described here for illustration. This use case arises when an upstream LSR Ru is adjacent to several downstream LSRs <Rd1...Rdn> in an LSP, LSP1 AND Ru is connected to <Rd1...Rdn> via a multi-access media or tunnel, AND Ru wants to transmit a single copy of an MPLS packet on the LSP to <Rd1...Rdn>. In the case of a tunnel, Ru can distribute an upstream-assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and transmit an MPLS packet, the top label of which is L, on the tunnel. In the case of a multi-access media, Ru can distribute an upstream-assigned label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and transmit an MPLS packet, the top label of which is the context label that identifies Ru, and the label immediately below is L, on the multi-access media. Each of <Rd1..Rdn> will then interpret this MPLS packet in the context of Ru and forward it appropriately. This implies that <Rd1..Rdn> MUST all be able to support an Upstream Neighbor Label Space for Ru and Ru MUST be able to determine this. The mechanisms for determining this are specific to the application that is using upstream-assigned labels and is outside the scope of this document.
上流で割り当てられたラベルの典型的なユースケースは、MPLSマルチキャスト向けであり、ここで説明するために説明します。このユースケースは、上流のLSR ruがLSPでいくつかの下流のLSRS <rd1 ... rdn>に隣接している場合に発生します。LSPのMPLSパケットの単一のコピーを<rd1 ... rdn>に送信したい。トンネルの場合、RUはLSP1のFECに結合した上流の割り当てラベルLを<RD1..RDN>に分配し、MPLSパケットを送信できます。トップラベルはトンネル上でLです。マルチアクセスメディアの場合、RuはLSP1のFECにバインドされた上流のラベルLを<RD1..RDN>に配布し、MPLSパケットを送信できます。トップラベルはコンテキストラベルです。それはruを識別し、下のラベルはマルチアクセスメディアのLです。<RD1..RDN>のそれぞれは、このMPLSパケットをRUのコンテキストで解釈し、適切に転送します。これは、<rd1..rdn>すべてがRUとRUの上流の近隣ラベルスペースをサポートできなければならないことを意味し、RUはこれを決定できる必要があります。これを決定するためのメカニズムは、上流のラベルを使用しており、このドキュメントの範囲外であるアプリケーションに固有です。
The security considerations that apply to upstream-assigned labels and context labels are no different in kind than those that apply to downstream-assigned labels.
アップストリームが割り当てられたラベルとコンテキストラベルに適用されるセキュリティ上の考慮事項は、ダウンストリーム割り当てのラベルに適用されるラベルと違いはありません。
Note that procedures for distributing upstream-assigned labels and/or context labels are not within the scope of this document. Therefore, the security considerations that may apply to such procedures are not considered here.
上流で割り当てられたラベルおよび/またはコンテキストラベルを配布する手順は、このドキュメントの範囲内ではないことに注意してください。したがって、このような手順に適用される可能性のあるセキュリティ上の考慮事項は、ここでは考慮されません。
Section 8 of this document describes a procedure that enables an LSR to automatically generate a unique context label for a LAN. This procedure assumes that the IP addresses of all the LSR interfaces on the LAN will be unique in their low-order 20 bits. If two LSRs whose IP addresses have the same low-order 20 bits are placed on the LAN, other LSRs are likely to misroute packets transmitted to the LAN by either of the two LSRs in question.
このドキュメントのセクション8では、LSRがLANの一意のコンテキストラベルを自動的に生成できるようにする手順について説明します。この手順では、LAN上のすべてのLSRインターフェイスのIPアドレスが、低次の20ビットで一意になると想定しています。IPアドレスが同じ低次の20ビットをLANに配置している2つのLSRがLANに配置されている場合、他のLSRは、問題の2つのLSRのいずれかによってLANに送信されるパケットを誤って誤ってパケットする可能性があります。
More detailed discussion of security issues that are relevant in the context of MPLS and GMPLS, including security threats, related defensive techniques, and the mechanisms for detection and reporting, are discussed in "Security Framework for MPLS and GMPLS Networks [MPLS-SEC].
セキュリティの脅威、関連する防御技術、検出およびレポートのメカニズムなど、MPLSおよびGMPLSのコンテキストで関連するセキュリティ問題のより詳細な議論は、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク[MPLS-SEC]）で説明されています。
Thanks to IJsbrand Wijnands's contribution, specifically for the text on which Section 8 is based.
IJSBrand Wijnandsの貢献、特にセクション8の基礎となるテキストに感謝します。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[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月。
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encpsulations", RFC 5332, August 2008.
[RFC5332] Eckert、T.、Rosen、E.、Aggarwal、R。、およびY. Rekhter、「MPLS Multicast Encpsulations」、RFC 5332、2008年8月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2008.
[MPLS-SEC] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2008年7月、進行中の作業。
Authors' Addresses
著者のアドレス
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089
EMail: rahul@juniper.net
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089
EMail: yakov@juniper.net
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ、1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719
EMail: erosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。