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
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は、次いで、上流側に通知します結合の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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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は、一つ以上のコンテキスト固有のラベルスペースを維持することができます。コンテキストに関する何かがラベルは、特定のコンテキスト固有のラベルスペース内で検索することを決定しない限り、一般的には、ラベルは、プラットフォームごとのラベルスペースに調べなければなりません。
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.
コンテキスト固有のラベルスペースの一例は、MPLSパケットは、特定のインタフェースを介して受信されたRFC 3031で説明したインターフェースごとのラベル空間であり、パケットの先頭ラベルは、受信インタフェースのパー内で検索する必要があるかもしれませんインターフェイスのラベルスペース。この場合、受信インタフェースは、パケットのコンテキストです。 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のコンテキストは、ラベルを割り当て、ラベルスイッチパス（LSP）LSP1ためFEC Fにラベルを結合するLSRによって提供されます。ラベルを割り当てLSRは、LrはLSP1でMPLSパケットを受信すると、ラベルLとLSP1でMPLSパケットを受信LSR Lrとに結合し、コンテキストを配信、このパケットのコンテキストを決定できなければなりません。
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トンネルである場合したがって、最後から二番目のホップポッピング（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）に隣接している場合、そのうちの一つは、「上流LSR」および他の「下流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との間の結合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.
上流割り当てられたラベルの一つのユースケースは、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.
他のLSRが上流割り当てられたラベルバインディングを配布しながら、FEC FのためのLSP上のいくつかのLSRは、FEC Fのための下流割り当てられたラベルバインディングを配布することが可能です。 LSRは、その上流の隣接LSRにFEC Fのバインディング下流割り当てられたラベルを配布し、その下流に隣接するLSRにFEC Fのバインディング上流割り当てられたラベルを配布することが可能です。 2つのLSR、Ru及びRdは、（Ruが上流隣接及びRdの下流隣人である）FEC FのためのLSPに隣接している場合、いずれかのRuはRDにFのバインディング上流割り当てられたラベルを配布、あるいはR dは、下流の分配します-assignedラベルは、両方ではなく、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のための上流割り当てられたラベルを、割り当てる必要があります。さらに、これらのトンネルのヘッド識別子と同じIPアドレスを使用する必要があり、複数のトンネルのヘッド上流LSRは、これらのトンネルのヘッド識別子はIPアドレスを含むことを条件とします。 LSRは、割り当てられたダウンストリームとアップストリームに割り当てられたラベルの両方に同一のラベル値を割り当てることができます。第7節で説明したように、下流LSRは常にコンテキスト固有のラベルスペースの上流に割り当てられた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がRDにFEC FのラベルLの結合をアドバタイズするとき、それはNHLFEエントリを使用して転送されたパケットのMPLSラベルスタックにラベルLを課すことにL.このNHLFE入力結果に対応するNHLFEエントリを作成します。 RuはFEC FのためのLSP上のトランジットルータがある場合、それはこのNHLFEへのLSPのためにILMをバインドします。 RuはFEC FのためのLSPの入口ルータである場合、それはNHLFEエントリーにFECをバインドします。
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は、FEC Fのための（a）は、入口LSRのいずれかである場合、または（b）それがすでにからそのFECのための結合上流のラベルを受信した場合にFEC Fに対する結合upstream-割り当てられたラベルを配布します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によって割り当てられたRuに「予備」MPLSラベルに維持することがコンテキスト固有のラベルスペースを使用しています。 RuがRDにFEC FのためのLの結合上流割り当てられたラベルを配布する場合したがって、その後Rdのは、Ruのコンテキスト固有のラベルスペースのための別個のILMにLを留保します。これは、RdがRuので上流割り当てられたMPLSラベルをルックアップするために使用するILMです。このラベルは、Ruから受信したパケットのラベルスタックの一番上のラベルであってもよく、またはそのようなパケットから、ラベルスタックから一枚の以上のラベルをポップrDの結果として、ラベルスタックの一番上のラベルとして公開することができます。
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パケットのトップラベルが上流割り当てられているかどうかを決定し、このパケットのYesの場合、「コンテクスト」できなければならないことを意味します。どのようにこの判定がなされると、RDに上流割り当てトップラベルLとMPLSパケットを送信するための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パケットを受信すると、パケットが受信されたトンネルに基づいて、このパケットの「コンテキスト」を決定します。 RDにruから特定のトンネルが上流割り当てられたMPLSラベルを用いてMPLSパケットを送信するためのRuによって使用されること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アドレスを使用する場合、R dは、それぞれ、このようなヘッドエンドのIPアドレスごとに異なる上流隣接ラベルスペースを維持しなければなりません。
Consider the following conditions:
以下の条件を考慮してください。
1) Ru is the "root" of two tunnels, call them A and B.
1）RuはAとBそれらを呼び出し、2つのトンネルの「根」であります
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）トンネルを設定するために使用されるシグナリングプロトコルは、Aは、IPアドレスXとAのルートノードを識別し
4) The signaling protocol used to set up tunnel B identified B's root node as IP address X.
4）トンネルBを設定するために使用されるシグナリングプロトコルは、IPアドレスXとBのルートノードを識別し
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.
これらの条件が成立する場合にのみ場合時にトンネルBを通って移動するパケットの上流割り当てるラベルを使用することトンネルAを通って移動するパケットの上流割り当てるラベル、次いでRuは同じラベル空間を使用しなければなりません
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）トンネルのために、意図は、トンネルのヘッドエンドが「ルート」であることです。ポイントツーマルチポイント（P2MP）または多対多（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トンネルである場合、R dは、A）はLが割り当てられた上流及びL用B）コンテキスト、ラベルスタックの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は、IPソースアドレスから、上流割り当て[RFC5332]とL用b）の文脈でヘッダ。
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はLが割り当てられた割り当てられた上流または下流缶次いでかどうか、データ・リンク・フレームの中にカプセル化することにより、トップラベルLと、パケットを送信するかどうRu及びR dは、マルチアクセスデータリンク媒体に隣接している場合[RFC5332]に記載されているように、rdで決定すること。 Lが上流割り当てられている場合、[RFC5332]は、データ・リンク・フレーム内の異なるエーテル系を使用するので、これは可能です。 Rdは、このパケットのコンテキストを決定するためしかし、これは十分ではありません。 Rdは、このパケットのコンテキストを決定するために、RuはワンホップMPLSトンネルにパケットをカプセル化します。このトンネルは、Ruによって割り当てられるMPLSコンテキストラベルを使用します。第8節は、コンテキストラベルが割り当てられている方法を説明します。 RdがRuのための独立した「上流隣接ラベルスペース」を維持します。このパケットの「コンテキスト」、即ち、Lが予約されたルテニウムの上流隣接ラベルスペースは、トップコンテキストラベルとパケットを受信したインタフェースからrdで決定されます。データ・リンク・フレーム内のエーテル系は、トップラベルが上流割り当てられていることを示すように設定されています。スタック内の第二の標識は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.)
第二の方法は、コンテキストラベルが自動生成することができるが、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が自動的にユニークなコンテキストのラベルを生成することができます。この値が0xFFFEFより大きくない場合、ラベル値が予約ラベル空間範囲[RFC3032]に該当しないこと自動生成コンテキストを確実にするために、IPv4アドレスのホスト部の値は、0x10のオフセットされています。 IPv4のホスト部の値が0xFFFEFよりも大きいが、コンテキストのラベルとして使用することが許可されていません対処します。
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インターフェイス上RU2（上流）LANインタフェース上RU1（上流）とに接続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がマルチアクセスメディアまたはトンネルを介して<Rd1を...のRdn>に接続されているRuのLSP、LSP1に、いくつかの下流のLSR <Rd1を...のRdn>に隣接している場合に生じる、及びRu <Rd1を...のRdn>にLSPにMPLSパケットの単一のコピーを送信したいです。トンネルの場合、Ruは<Rd1..Rdn>に、LSP1のためのFECに結合している上流割り当てられたラベルLを配布することができ、トンネル上で、MPLSパケット、Lであるのトップラベルを送信します。マルチアクセス媒体の場合、Ruは<Rd1..Rdn>に、LSP1のためのFECに結合している上流割り当てられたラベルLを配布し、MPLSパケットを送信し、コンテキスト・ラベルとなっているトップラベルができますそれは、Ruを識別し、すぐ下のラベルは、マルチアクセスメディア上で、Lです。 <Rd1..Rdn>のそれぞれは、その後のRuのコンテキストでこのMPLSパケットを解釈し、それを適切に転送します。これは、<Rd1..Rdn>は、このすべてを決定できなければならない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は、自動的にLANのためのユニークなコンテキストラベルを生成するために、LSRを可能に手順を説明します。この手順は、LAN上のすべてのLSRインタフェースのIPアドレスは、その下位20ビットに一意であることを想定しています。そのIPアドレスの20ビットはLAN上に設置されているのと同じ下位を持つ2つのLSRは、他のLSRは、問題の2つのLSRのいずれかによってLANに送信するパケットをmisrouteする可能性がある場合。
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.
特に第8のベースとなっているテキストのIJsbrand Wijnandsの貢献のおかげで、。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encpsulations", RFC 5332, August 2008.
[RFC5332]エッカート、T.、ローゼン、E.、アガルワル、R.、およびY. Rekhter、 "MPLSマルチキャスト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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, July 2008.
[MPLS-SEC]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、進歩、2008年7月に作業。
Authors' Addresses
著者のアドレス
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089
ラウール・アガーウォールジュニパーネットワークスの1194北マチルダアベニュー。サニーベール、CA 94089
EMail: rahul@juniper.net
メールアドレス：rahul@juniper.net
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089
ヤコフ・レックタージュニパーネットワークスの1194北マチルダアベニュー。サニーベール、CA 94089
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。