[要約] RFC 5332は、MPLSマルチキャストカプセル化に関する標準化されたプロトコル仕様です。その目的は、MPLSネットワークでのマルチキャストトラフィックの効率的な転送を実現することです。
Network Working Group T. Eckert
Request for Comments: 5332 E. Rosen, Ed.
Category: Standards Track Cisco Systems, Inc.
Updates: 3032, 4023 R. Aggarwal
Y. Rekhter
Juniper Networks, Inc.
August 2008
MPLS Multicast Encapsulations
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 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the "multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label".
RFC 3032は、MPLS用の2つのデータリンクレイヤーコードポイントを確立しました。これは、データリンクレイヤーフレームがMPLSユニキャストを運ぶのか、MPLSマルチキャストパケットを運ぶかを区別するために使用されます。ただし、この使用法は展開されませんでした。この仕様は、これら2つのコードポイントの意味を再定義することにより、RFC 3032を更新します。両方のコードポイントを使用してマルチキャストパケットを運ぶことができます。2番目のCodePoint（以前は「マルチキャストCodePoint」）は、Multiaccessメディアでのみ使用されるようになり、「次のラベルスタックのトップレーベルはアップストリーム割り当てのラベルです」を意味します。
RFC 3032 does not specify the destination address to be placed in the "MAC DA" (Medium Access Layer Destination Address) field of an ethernet frame that carries an MPLS multicast packet. This document provides that specification.
RFC 3032は、MPLSマルチキャストパケットを搭載したイーサネットフレームの「MAC DA」（中アクセスレイヤー宛先アドレス）フィールドに配置される宛先アドレスを指定しません。このドキュメントは、その仕様を提供します。
This document updates RFC 3032 and RFC 4023.
このドキュメントは、RFC 3032およびRFC 4023を更新します。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Upstream-Assigned vs. Downstream-Assigned .......................3
4. Ethernet Codepoints .............................................6
5. PPP Protocol Field ..............................................6
6. GRE Protocol Type ...............................................6
7. IP Protocol Number ..............................................7
8. Ethernet MAC DA for Multicast MPLS ..............................7
9. IANA Considerations .............................................8
10. Security Considerations ........................................8
11. Normative References ...........................................9
RFC 3031 [RFC3031] defines the "Next Hop Label Forwarding Entry" (NHLFE). The NHLFE for a particular label maps the label into a next hop (among other things). When an MPLS packet is received, its top label is mapped to an NHLFE, and the packet is sent to the next hop specified by the NHLFE.
RFC 3031 [RFC3031]は、「次のホップラベル転送エントリ」（NHLFE）を定義します。特定のラベルのNHLFEは、ラベルを次のホップにマッピングします（とりわけ）。MPLSパケットが受信されると、そのトップラベルはNHLFEにマッピングされ、パケットはNHLFEによって指定された次のホップに送信されます。
We define a particular MPLS label to be a "multicast label" in a particular context if the NHLFE to which it is mapped, in that context, specifies a set of next hops, with the semantics that the packet is to be replicated and a copy of the packet sent to each of the specified next hops. Note that this definition accommodates the case where the set of next hops contains a single member. What makes a label a multicast label in a particular context is the semantics attached to the set, i.e., the intention to replicate the packet and transmit to all members of the set if the set has more than one member.
特定のMPLSラベルを、特定のコンテキストで「マルチキャストラベル」と定義します。そのコンテキストでマッピングされているNHLFEが次のホップのセットを指定し、パケットが複製されるというセマンティクスとコピーを指定します。指定された次のホップのそれぞれに送信されたパケットの。この定義には、次のホップのセットが単一のメンバーが含まれている場合に対応することに注意してください。ラベルを特定のコンテキストでマルチキャストラベルにしているのは、セットに添付されたセマンティクス、つまり、セットに複数のメンバーがある場合、パケットを複製してセットのすべてのメンバーに送信する意図です。
RFC 3032 [RFC3032] established two data link layer codepoints for MPLS: one to indicate that the data link layer frame is carrying an MPLS unicast packet, and the other to indicate that the data link layer frame is carrying an MPLS multicast packet. The term "multicast packet" is not precisely defined in RFC 3032, though one may presume that the "multicast" codepoint is intended to identify the packet's top label as a multicast label. However, the multicast codepoint has never been deployed, and further development of the procedures for MPLS multicast have shown that, while there is a need for two codepoints, the use of the two codepoints is not properly captured by RFC 3032.
RFC 3032 [RFC3032]は、MPLSの2つのデータリンクレイヤーコードポイントを確立しました。1つは、データリンクレイヤーフレームがMPLSユニキャストパケットを運んでいることを示し、もう1つはデータリンクレイヤーフレームがMPLSマルチキャストパケットを運ぶことを示すためです。「マルチキャストパケット」という用語は、RFC 3032で正確に定義されていませんが、「マルチキャスト」コードポイントは、パケットのトップラベルをマルチキャストラベルとして識別することを目的としていると推測するかもしれません。ただし、マルチキャストCodePointは展開されていないため、MPLSマルチキャストの手順のさらなる開発により、2つのコードポイントが必要なものの、2つのコードポイントの使用はRFC 3032によって適切にキャプチャされないことが示されています。
In particular, there is no need for the codepoint to indicate whether the top MPLS label is a multicast label. When the receiver of an MPLS packet looks up the top label, the NHLFE will specify whether or not the label is a multicast label.
特に、CodePointがTOP MPLSラベルがマルチキャストラベルであるかどうかを示す必要はありません。MPLSパケットのレシーバーがトップレーベルを検索すると、NHLFEはラベルがマルチキャストラベルであるかどうかを指定します。
This document updates RFC 3032 and RFC 4023 by re-specifying the use of the codepoints. The old use of the "multicast codepoint", as specified in those two RFCs, is hereby deprecated.
このドキュメントは、コードポイントの使用を再特定することにより、RFC 3032およびRFC 4023を更新します。これら2つのRFCで指定されているように、「マルチキャストコードポイント」の古い使用は、これにより非推奨です。
Note that an implementation that does MPLS multicast according to RFC 3032 and/or 4023 will be unable to interoperate with implementations that do MPLS multicast according to this document. There may be some deployed platforms that support the deprecated use of the codepoints, but those platforms do not support the control plane mechanisms to support MPLS multicast. The absence of the control plane will prevent a system that implements the deprecated use of codepoints from attempting to interoperate with a system that uses the codepoints as specified herein. (If an MPLS multicast control plane were to be implemented on a platform that only supports the deprecated codepoint, interoperability problems such as black holes and/or misrouting would arise. This does not seem like a potential problem in practice.)
RFC 3032および/または4023に従ってMPLSマルチキャストを行う実装は、このドキュメントに従ってMPLSマルチキャストを実行する実装と相互運用できないことに注意してください。コードポイントの非推奨使用をサポートするいくつかの展開されたプラットフォームがあるかもしれませんが、これらのプラットフォームは、MPLSマルチキャストをサポートする制御プレーンメカニズムをサポートしていません。コントロールプレーンが存在しないと、本明細書で指定されているようにコードポイントを使用するシステムと相互運用しようとするコードポイントの使用が非推奨されるシステムが妨げられます。（MPLSマルチキャストコントロールプレーンが非推奨コードポイントのみをサポートするプラットフォームに実装される場合、ブラックホールや誤った誤った問題などの相互運用性の問題は発生します。これは実際には潜在的な問題のようには見えません。）
While RFC 3032 allows an MPLS packet to be carried in an ethernet multicast frame, it fails to specify how the Medium Access Layer Destination Address (MAC DA) field is to be set in that case. This document provides that specification.
RFC 3032では、MPLSパケットをイーサネットマルチキャストフレームに携帯することができますが、その場合、Medium Access Layer Destinationアドレス（MAC DA）フィールドの設定方法を指定できません。このドキュメントは、その仕様を提供します。
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]に記載されているように解釈される。
Suppose a labeled packet P is sent from Label Switching Router (LSR) R1 to LSR R2, where R1 puts label L on the packet's label stack, and R2 has to look up label L in order to determine the corresponding Forwarding Equivalence Class (FEC), call it F.
ラベル付きパケットPがラベルスイッチングルーター（LSR）R1からLSR R2に送信され、R1がパケットのラベルスタックにラベルLを配置し、R2が対応する転送等価クラス（FEC）を決定するためにラベルLを検索する必要があるとします。、それをFと呼びます。
If the binding between L and F was made by R2 and advertised to R1, then the label binding is known as "downstream-assigned". RFC 3031 only discusses downstream-assigned label bindings.
LとFの間のバインディングがR2によって作成され、R1に宣伝された場合、ラベル結合は「下流割り当て」として知られています。RFC 3031は、下流に割り当てられたラベルバインディングのみについて説明します。
If the binding between L and F was made by R1 and advertised to R2, then the label binding is known as "upstream-assigned".
LとFの間のバインディングがR1によって作成され、R2に宣伝された場合、ラベル結合は「アップストリーム割り当て」として知られています。
If the binding between L and F was made by a third party, say R3, and then advertised to both R1 and R2, we also refer to the label binding as "upstream-assigned".
LとFの間のバインディングが第三者、たとえばR3によって作成され、R1とR2の両方に宣伝された場合、ラベルバインディングを「上流割り当て」と呼びます。
Upstream-assigned labels are not required to come from the same "label space" as downstream-assigned labels. See Section 3.14 of [RFC3031] and especially [RFC5331] for a discussion of the notion of "label space". The procedures for properly interpreting an upstream-assigned label are given in [RFC5331].
上流で割り当てられたラベルは、下流で割り当てられたラベルと同じ「ラベルスペース」から来る必要はありません。「ラベル空間」の概念の議論については、[RFC3031]および特に[RFC5331]のセクション3.14を参照してください。上流で割り当てられたラベルを適切に解釈する手順は、[RFC5331]に記載されています。
If Ru and Rd are LSP adjacencies, then they transmit an MPLS packet to each other through one of the following mechanisms:
RUとRDがLSPの隣接である場合、次のメカニズムのいずれかを使用してMPLSパケットを相互に送信します。
1. by putting the MPLS packet in a data link layer frame and transmitting the frame,
1. MPLSパケットをデータリンクレイヤーフレームに配置し、フレームを送信することにより、
2. by transmitting the MPLS packet through an MPLS tunnel, i.e., by pushing an additional label (or labels) onto the label stack, and then invoking mechanism 1, or
2. MPLSパケットをMPLSトンネルを介して送信します。つまり、追加のラベル（またはラベル）をラベルスタックに押し込み、メカニズム1、または呼び出します。
3. by transmitting the MPLS packet through an IP-based tunnel (e.g., via RFC 4023 [RFC4023]), and then invoking mechanisms 1 and/or 2.
3. IPベースのトンネルを介してMPLSパケットを送信する（例：RFC 4023 [RFC4023]を介して）、メカニズム1および/または2を呼び出します。
In short, an MPLS packet is transmitted through a data link, through an MPLS tunnel, or through an IP tunnel. In any of those cases, when the packet emerges through the tunnel, the downstream LSR must know whether the label that now appears at the top of the label stack has an upstream-assigned label binding or a downstream-assigned label binding. For convenience, we will speak of a label with an upstream-assigned label binding as an "upstream-assigned label".
要するに、MPLSパケットは、データリンク、MPLSトンネル、またはIPトンネルを介して送信されます。これらの場合、パケットがトンネルを介して出現すると、下流のLSRは、ラベルスタックの上部に表示されているラベルが上流のラベル結合または下流に割り当てられたラベル結合を持っているかどうかを知る必要があります。便利なため、「アップストリームが割り当てられたラベル」として上流で割り当てられたラベルのバインディングを含むラベルについて説明します。
Under certain conditions, specified below, multicast labels MAY be upstream-assigned. 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. How this is known is outside the scope of this document.
以下に指定されている特定の条件下では、マルチキャストラベルが上流に割り当てられる場合があります。アップストリーム割り当てのラベルを使用する機能は、オプションの機能です。下流のLSRがそれらをサポートしていることがわかっていない限り、アップストリーム割り当てのラベルを使用してはなりません。これがどのように知られているかは、このドキュメントの範囲外です。
This document makes no changes to the procedures regarding unicast labels.
このドキュメントは、ユニキャストラベルに関する手順に変更を加えません。
We discuss three different types of data link or tunnel:
3つの異なるタイプのデータリンクまたはトンネルについて説明します。
- Point-to-Point. A point-to-point data link or tunnel associates two systems, such that transmissions on that link or tunnel made by one are received by the other, and only by the other.
- ポイントからポイントへ。ポイントツーポイントのデータリンクまたはトンネルは、2つのシステムを結び付けているため、1つによって作成されたリンクまたはトンネルの送信は、もう1つが、もう1つによってのみ受信されます。
For a given direction of a given point-to-point data link or tunnel, the following MUST be the case: either every MPLS packet will carry an upstream-assigned label, or else every MPLS packet will carry a downstream-assigned label. The procedures for determining whether upstream-assigned or downstream-assigned labels are being used are outside the scope of this specification. However, in the absence of any other information, the use of downstream-assigned labels MUST be presumed by default.
特定のポイントツーポイントデータリンクまたはトンネルの特定の指示の場合、次の場合が必要です。すべてのMPLSパケットには上流のラベルが付いているか、すべてのMPLSパケットが下流に割り当てられたラベルを搭載します。アップストリーム割り当てまたは下流で割り当てられたラベルが使用されているかどうかを判断する手順は、この仕様の範囲外です。ただし、他の情報がない場合、下流で割り当てられたラベルの使用は、デフォルトで推定される必要があります。
- Point-to-Multipoint. A point-to-multipoint link or tunnel associates n systems, such that only one of them can transmit onto the link or tunnel, and the transmissions may be received by the other n-1 systems.
- ポイントツーマルチポイント。ポイントツーマルチポイントリンクまたはトンネルアソシエイトNシステム。そのうちの1つだけがリンクまたはトンネルに送信できるようにし、他のN-1システムが送信を受信できるようにします。
The top labels (before applying the data link or tunnel encapsulation) of all MPLS packets that are transmitted on a particular point-to-multipoint data link or tunnel MUST be of the same type; either all upstream-assigned or all downstream-assigned. This means that all the receivers on the MPLS or IP tunnel must know a priori whether upstream-assigned or downstream-assigned labels are being used in the tunnel. How this is known is outside the scope of this document.
特定のポイントツーマルチポイントデータリンクまたはトンネルで送信されるすべてのMPLSパケットのトップラベル（データリンクまたはトンネルのカプセル化を適用する前）は、同じタイプでなければなりません。すべての上流割り当てまたはすべての下流割り当てのいずれか。これは、MPLSまたはIPトンネル上のすべての受信機が、上流で割り当てられたラベルがトンネルで使用されているかどうかのアプリオリを知る必要があることを意味します。これがどのように知られているかは、このドキュメントの範囲外です。
- Multipoint-to-Multipoint. A multipoint-to-multipoint link or tunnel associates n systems, such that any of them can transmit on the link or tunnel, and the transmissions may be received by the other n-1 systems.
- Multipoint-to-Multipoint。マルチポイントからマルチポイントリンクまたはトンネルアソシエイトNシステム。それらのいずれかがリンクまたはトンネルで送信できるようにし、トランスミッションは他のN-1システムによって受信される可能性があります。
If MPLS packets are transmitted on a particular multipoint-to-multipoint link or tunnel, one of the following scenarios applies:
MPLSパケットが特定のMultipoint-to-MultiPointリンクまたはトンネルで送信されている場合、次のシナリオの1つが適用されます。
1. It is known (by methods outside the scope of this document) that the top label of every MPLS packet on the link or tunnel is downstream-assigned.
1. リンクまたはトンネル上のすべてのMPLSパケットのトップレーベルが下流に割り当てられていることは（このドキュメントの範囲外の方法によって）知られています。
2. It is known (by methods outside the scope of this document) that the top label of every MPLS packet on the link or tunnel is upstream-assigned.
2. リンクまたはトンネル上のすべてのMPLSパケットのトップラベルが上流で割り当てられていることは（このドキュメントの範囲外の方法によって）知られています。
3. Some MPLS packets on the link may have upstream-assigned top labels while some may have downstream-assigned top labels.
3. リンク上の一部のMPLSパケットには、上流のトップラベルが付いている場合がありますが、一部のMPLが下流に割り当てられたトップラベルがある場合があります。
If (and only if) the third scenario applies, the data link or tunnel encapsulation MUST provide a codepoint that specifies whether the top label of the encapsulated MPLS packet is upstream-assigned or downstream-assigned. If a particular type of data link or tunnel does not provide such a codepoint, then the third scenario MUST NOT be used.
3番目のシナリオが適用される場合（および場合にのみ）、データリンクまたはトンネルのカプセル化は、カプセル化されたMPLSパケットのトップラベルがアップストリーム割り当てまたは下流に割り当てられているかどうかを指定するコードポイントを提供する必要があります。特定のタイプのデータリンクまたはトンネルがそのようなコードポイントを提供しない場合、3番目のシナリオを使用してはなりません。
The remainder of this document specifies procedures for setting the data link layer codepoints and address fields.
このドキュメントの残りの部分は、データリンクレイヤーコードポイントとアドレスフィールドを設定するための手順を指定します。
Ethernet is an example of a multipoint-to-multipoint data link.
イーサネットは、マルチポイントからマルチポイントのデータリンクの例です。
Ethertype 0x8847 is used whenever a unicast ethernet frame carries an MPLS packet.
EtherType 0x8847は、ユニキャストイーサネットフレームがMPLSパケットを運ぶたびに使用されます。
Ethertype 0x8847 is also used whenever a multicast ethernet frame carries an MPLS packet, EXCEPT for the case where the top label of the MPLS packet has been upstream-assigned.
EtherType 0x8847は、マルチキャストイーサネットフレームがMPLSパケットを搭載している場合はいつでも使用されますが、MPLSパケットのトップレーベルが上流に割り当てられている場合を除きます。
Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", is to be used only when an MPLS packet whose top label is upstream-assigned is carried in a multicast ethernet frame.
以前は「MPLS Multicast CodePoint」として知られていたEtherType 0x8848は、トップラベルがアップストリーム割り当てされているMPLSパケットがマルチキャストイーサネットフレームで運ばれる場合にのみ使用されます。
PPP is an example of a point-to-point data link. When a PPP frame is carrying an MPLS packet, the PPP Protocol field is always set to 0x0281.
PPPは、ポイントツーポイントデータリンクの例です。PPPフレームがMPLSパケットを運ぶとき、PPPプロトコルフィールドは常に0x0281に設定されます。
RFC 4023 is modified as described below.
RFC 4023は、以下のように変更されています。
If the IP destination address of the Generic Routing Encapsulation (GRE) is a unicast IP address, then the ethertype value 0x8847 MUST be used in all cases for the MPLS-in-GRE encapsulation.
一般的なルーティングカプセル化（GRE）のIP宛先アドレスがユニキャストIPアドレスである場合、EtherType値0x8847をすべての場合にMPLS-in-greのカプセル化に使用する必要があります。
If the IP destination address of the GRE encapsulation is a multicast IP address, then:
GREカプセル化のIP宛先アドレスがマルチキャストIPアドレスである場合、次のとおりです。
- the ethertype value 0x8847 MUST be used when the top label of the encapsulated MPLS packet is downstream-assigned,
- カプセル化されたMPLSパケットのトップラベルが下流で割り当てられている場合、EtherType値0x8847を使用する必要があります。
- the ethertype value 0x8848 MUST be used when the top label of the encapsulated MPLS packet is upstream-assigned.
- カプセル化されたMPLSパケットのトップラベルが上流で割り当てられている場合、EtherType値0x8848を使用する必要があります。
Through procedures that are outside the scope of this specification, it may be known that if the destination address of a GRE packet is a multicast IP address, then the top label of the GRE payload is upstream-assigned. In such a case, the occurrence of the 8847 codepoint in a GRE packet with a multicast destination IP address MUST be considered an error, and the packet MUST be discarded.
この仕様の範囲外の手順を通じて、GREパケットの宛先アドレスがマルチキャストIPアドレスである場合、GREペイロードのトップラベルが上流に割り当てられていることがわかっている場合があります。このような場合、マルチキャスト宛先IPアドレスを備えたGREパケットに8847コードポイントの発生をエラーと見なす必要があり、パケットを破棄する必要があります。
RFC 4023 is modified as follows: the IPv4 Protocol Number field or the IPv6 Next Header field is always set to 137, whether or not the encapsulated MPLS packet is an MPLS multicast packet.
RFC 4023は次のように変更されます：IPv4プロトコル番号フィールドまたはIPv6次のヘッダーフィールドは、カプセル化されたMPLSパケットがMPLSマルチキャストパケットであるかどうかにかかわらず、常に137に設定されます。
If the IP destination address of the IP encapsulation is an IP multicast address, the IP tunnel may be considered to be a point-to-multipoint tunnel or a multipoint-to-multipoint tunnel. In either case, either all encapsulated MPLS packets in the particular tunnel have a downstream-assigned label at the top of the stack, or all encapsulated MPLS packets in that tunnel have an upstream-assigned label at the top of the stack. The means by which this is determined for a particular tunnel is outside the scope of this specification.
IPカプセル化のIP宛先アドレスがIPマルチキャストアドレスである場合、IPトンネルはポイントツーマルチポイントトンネルまたはマルチポイントツーマルチポイントトンネルと見なされる場合があります。どちらの場合でも、特定のトンネル内のすべてのカプセル化されたMPLSパケットは、スタックの上部にダウンストリーム割り当てのラベルを持ち、そのトンネルのすべてのカプセル化されたMPLSパケットは、スタックの上部に上流のラベルを持っています。これが特定のトンネルに対して決定される手段は、この仕様の範囲外です。
When an LSR transmits a multicast MPLS packet in a multicast ethernet frame, it MUST set the MAC Destination Address to the value 01-00-5e-8v-wx-yz, where vwxyz is a 20-bit (five-nibble) value set as follows:
LSRがマルチキャストイーサネットフレームにマルチキャストMPLSパケットを送信する場合、MAC宛先アドレスを値01-00-5E-8V-WX-YZに設定する必要があります。ここで、VWXYZは20ビット（5ニブル）値セットです。次のように：
1. vwxyz MAY be set to 0,
1. vwxyzは0に設定できます。
2. vwxyz MAY be set to the value of one of the MPLS labels on the packet's label stack.
2. VWXYZは、Packetのラベルスタック上のMPLSラベルの1つの値に設定できます。
Which of these procedures is the default procedure in any particular LSR is implementation-dependent. However, LSRs using the two different procedures MUST interoperate. That is, an LSR MUST NOT filter packets for which vwxyz has been set to zero, and it MUST NOT indiscriminately filter all packets for which vwxyz has not been set to zero.
これらの手順のどれが特定のLSRのデフォルトの手順であり、実装依存です。ただし、2つの異なる手順を使用するLSRは相互操作する必要があります。つまり、LSRはVWXYZがゼロに設定されているパケットをフィルタリングしてはなりません。VWXYZがゼロに設定されていないすべてのパケットを無差別にフィルタリングしてはなりません。
If an LSR follows the procedure of setting vwxyz to the value of one of the MPLS labels on the packet's label stack, and if that label stack contains two or more labels, then by default, vwxyz MUST be set to the value of the second MPLS label on the packet's label stack. By "the second label", we mean the label that is in the label stack entry that immediately follows the topmost label stack entry. The LSR MAY, if configured to do so, allow a label other than the second to be used for this purpose. If the MPLS packet has only one label, the value of that label will be used instead of the value of the (non-existent) second label.
LSRがVWXYZをパケットのラベルスタック上のMPLSラベルの1つの値に設定する手順に従い、そのラベルスタックに2つ以上のラベルが含まれている場合、デフォルトでは、VWXYZを2番目のMPLSの値に設定する必要があります。パケットのラベルスタックのラベル。「The Second Label」とは、最上部のラベルスタックエントリに直後に続くラベルスタックエントリにあるラベルを意味します。LSRは、そうするように構成されている場合、2番目以外のラベルをこの目的に使用することを許可する場合があります。MPLSパケットに1つのラベルのみがある場合、（存在しない）2番目のラベルの値の代わりに、そのラベルの値が使用されます。
It is expected that the LSR will follow the procedures of [RFC5331], pushing on two labels, with the topmost label being a "context label" that is the same for all MPLS packets being transmitted by the LSR onto the ethernet, but with the second label being different for different LSPs. Thus, if the MAC DA value is a function of the second label, more of the LSP-specific information about the packet appears in the MAC DA field. This can be used to filter multicast packets with "unexpected" non-zero values of vwxyz. Further discussion of such filtering or its uses is outside the scope of this document.
LSRは[RFC5331]の手順に従い、2つのラベルをプッシュし、最上位のラベルはすべてのMPLSパケットでLSRによってイーサネットに送信されるが、LSPが異なる場合、2番目のラベルは異なります。したがって、Mac Da値が2番目のラベルの関数である場合、Packetに関するLSP固有の情報の多くがMac Daフィールドに表示されます。これを使用して、VWXYZの「予期しない」非ゼロ値でマルチキャストパケットをフィルタリングできます。このようなフィルタリングまたはその用途のさらなる議論は、このドキュメントの範囲外です。
The use of ethernet and/or IP broadcast addresses (as distinguished from multicast addresses) does not fall within the scope of this specification.
イーサネットおよび/またはIPブロードキャストアドレスの使用（マルチキャストアドレスと区別される）は、この仕様の範囲内に該当しません。
IANA already owns the set of ethernet multicast addresses in the range 01-00-5e-00-00-00 to 01-00-5e-ff-ff-ff. Addresses in the range 01-00-5e-00-00-00 to 01-00-5e-7f-ff-ff are already reserved for use when an ethernet multicast frame carries an IP multicast packet.
IANAは、01-00-5E-00-00-00から01-00-5E-FF-FF-FFの範囲のイーサネットマルチキャストアドレスのセットを既に所有しています。範囲のアドレス01-00-5E-00-00-00-00〜01-00-5E-7F-FF-FFは、イーサネットマルチキャストフレームにIPマルチキャストパケットを搭載している場合に使用するためにすでに予約されています。
IANA has reserved ethernet addresses in the range 01-00-5e-80-00-00 to 01-00-5e-8f-ff-ff for use when an ethernet multicast frame carries an MPLS multicast packet. Addresses in this range are valid when used with ethertype 8847 or 8848.
IANAは、イーサネットマルチキャストフレームにMPLSマルチキャストパケットを運ぶ場合に使用するために、01-00-5E-80-00-00から01-00-8F-FF-FF-FFの範囲のイーサネットアドレスを予約しています。この範囲のアドレスは、EtherType 8847または8848で使用すると有効です。
As this document modifies the usage of ethertypes 8847 and 8848, IANA has changed the description of these ethertypes as follows. Ethertype 8847 is defined as "MPLS", as defined in RFC 3032 and in this document. Ethertype 8848 is defined as "MPLS with upstream-assigned label", as defined in this document.
このドキュメントがEtherTypes 8847と8848の使用を変更すると、IANAはこれらの倫理の説明を次のように変更しました。EtherType 8847は、RFC 3032およびこのドキュメントで定義されている「MPLS」として定義されています。EtherType 8848は、このドキュメントで定義されているように、「上流に割り当てられたラベルを持つMPLS」として定義されています。
The security considerations of RFC 3032 and RFC 4023 apply.
RFC 3032およびRFC 4023のセキュリティ上の考慮事項が適用されます。
Malicious changing of the codepoint may result in loss or misrouting of packets. However, altering the codepoint without also altering the label does not result in a predictable effect.
CodePointの悪意のある変更により、パケットの紛失または誤った違いが生じる可能性があります。ただし、ラベルを変更せずにコードポイントを変更しても、予測可能な効果は発生しません。
Malicious alteration of the MAC DA on an ethernet can result in packets being received by a third party, rather than by the intended recipient.
イーサネット上のMAC DAの悪意のある変更により、意図した受信者ではなく、第三者がパケットを受信する可能性があります。
[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] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023] Worster、T.、Rekhter、Y.、およびE. Rosen、ed。、「IPまたは汎用ルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。
[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 Upstream Labelの割り当てとコンテキスト固有のラベルスペース」、RFC 5331、2008年8月。
Authors' Addresses
著者のアドレス
Toerless Eckert Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
Toerless Eckert Cisco Systems、Inc。170 Tasman Drive San Jose、CA、95134
EMail: eckert@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ、1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719
EMail: erosen@cisco.com
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
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への情報をお問い合わせください。