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
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ユニキャストまたはMPLSマルチキャストパケットを運んでいるかどうかを区別するために使用される、MPLSのための2つのデータリンク層のコードポイントを確立しました。しかし、このような使い方が展開されることはなかったです。この仕様は、これら二つのコードポイントの意味を再定義することで、RFC 3032に更新します。どちらのコードポイントは現在、マルチキャストパケットを運ぶために使用することができます。第二のコードポイント（以前は「マルチキャストコードポイント」）は、唯一のマルチアクセスメディアに使用する今であり、それは、「次のラベルスタックのトップラベルが上流割り当てられたラベルである」を意味することです。
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には、「MAC DA」MPLSマルチキャストパケットを運ぶイーサネットフレームの（メディアアクセスレイヤ宛先アドレス）フィールドに配置される宛先アドレスを指定していません。この文書では、その仕様を提供します。
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.
私たちは、パケットを複製するセマンティクスとコピーと、それがマッピングされているNHLFEは、そのコンテキストで、次のホップのセットを指定した場合、特定の文脈で「マルチキャストラベル」であることを特定のMPLSラベルを定義します指定された次のホップのそれぞれに送信されたパケットの。この定義は次のホップのセットが単一の部材を含む場合が収容ことに留意されたいです。どのような特定のコンテキストでラベルマルチキャストラベルを作成することは、すなわち、意図はパケットを複製し、セットが複数のメンバーを持っている場合はセットのすべてのメンバーに送信するために、セットに付属の意味論です。
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つのデータリンク層のコードポイントを確立：一つはデータリンク層フレームは、MPLSユニキャストパケットを運んでいることを示すために、他方はデータリンク層フレームは、MPLSマルチキャストパケットを運んでいることを示すために。 1は、「マルチキャスト」コードポイントは、マルチキャストラベルとしてパケットのトップラベルを識別するために意図されていることを推測かもしれないが用語「マルチキャストパケットは、」正確には、RFC 3032で定義されていません。しかし、マルチキャストコードポイントが展開されていない、とMPLSマルチキャストのための手続の更なる発展は、二つのコードポイントの必要性がある一方で、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.
特に、トップ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。 「マルチキャストコードポイント」の古い使用は、これら二つの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に従ったMPLSマルチキャストを行い、実装および/または4023本文書によるMPLSマルチキャストを行う実装と相互運用することができません。そこのコードポイントの廃止予定の使用をサポートし、いくつかの展開のプラットフォームかもしれないが、これらのプラットフォームは、MPLSマルチキャストをサポートするための制御プレーンメカニズムをサポートしていません。制御プレーンが存在しないことは、本明細書で指定されるようにコードポイントを使用するシステムとの相互運用しようとするからコードポイントの廃止予定の使用を実現するシステムを防ぐことができます。 （MPLSマルチキャスト制御プレーンは、唯一の非推奨コードポイントをサポートするプラットフォーム上で実装されるためにこのようなブラックホールのように相互運用性の問題だったおよび/またはmisroutingが生じるであろう場合。これは、実際には潜在的な問題のように見えるしていません。）
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パケットがイーサネットマルチキャストフレームで運ばれることを可能にするが、それはメディアアクセスレイヤ宛先アドレス（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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は、R1は、パケットのラベルスタックにラベルLを置き、そしてR2は、対応する転送等価クラス（FEC）を決定するために、ラベルLをルックアップするために持っているLSR R2にルータ（LSR）R1をラベルスイッチングから送信されると仮定、それを呼び出す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の隣接している場合、それらは以下のメカニズムのうちの1つを介して互いにMPLSパケットを送信します。
1. by putting the MPLS packet in a data link layer frame and transmitting the frame,
データリンク層フレームにMPLSパケットを入れてフレームを送信することにより1、
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
ラベルスタックに追加のラベル（またはラベル）を押圧し、その後機構1を呼び出すことによって、すなわち、MPLSトンネルを介してMPLSパケットを送信することにより2、又は
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.
IPベースのトンネル（例えば、RFC 4023を介して、[RFC4023]）を介してMPLSパケットを送信し、その後機構1及び/又は2を呼び出すことによって3。
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.
- ポイントからポイントへ。ポイントツーポイントデータリンク又はトンネル関連付け二つのシステム、いずれかによって作られたそのリンク又はトンネル上の送信が他方によって、及び唯一の他によって受信されるようになっています。
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システムは、他の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.
- マルチポイント・ツー・マルチポイント。それらの任意のリンク又はトンネル上で送信することができるようにマルチポイント・ツー・マルチポイントリンク又はトンネル関連付けNシステム、および送信は、他のN-1システムによって受信され得ます。
If MPLS packets are transmitted on a particular multipoint-to-multipoint link or tunnel, one of the following scenarios applies:
MPLSパケットが特定のマルチポイントツーマルチポイントリンクまたはトンネル上で送信される場合、次のシナリオのいずれかが適用されます。
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パケットは、上流に割り当てられたトップのラベルを有することができます。
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.
ユニキャストEthernetフレームは、MPLSパケットを運ぶたびのEtherType 0x8847が使用されます。
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.
マルチキャストイーサネットフレームは、MPLSパケットのトップラベルが上流割り当てられている場合を除き、MPLSパケットを運ぶたびのEtherType 0x8847も使用されます。
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マルチキャストコードポイント」として知られているの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アドレスである場合には、イーサタイプ値0x8847は、MPLSイン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.
IPv4のプロトコル番号フィールド又はIPv6の次ヘッダフィールドは常にカプセル化されたMPLSパケットがMPLSマルチキャストパケットであるか否か、137に設定されている次のようにRFC 4023が修正されます。
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パケットを送信する場合、それはVWXYZは、20ビット（5-ニブル）値のセットである値01-00-5E-8V-WX-YZ、にMAC宛先アドレスを設定する必要があります次のように：
2. vwxyz MAY be set to the value of one of the MPLS labels on the packet's label stack.
2. VWXYZは、パケットのラベルスタック上の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は、パケットのラベルスタック上のMPLSラベルの1つの値にVWXYZ設定の手順に従って、そのラベルスタックを2つの以上のラベルが含まれている場合、デフォルトで、VWXYZは、第二のMPLSの値に設定する必要がある場合パケットのラベルスタックにラベルを付けます。 「第二のラベル」によって、我々はすぐに最上位ラベルスタックエントリーを次のラベルスタックエントリにあるラベルを意味します。そうするように構成されている場合LSR MAYは、第二以外のラベルは、この目的のために使用することができます。 MPLSパケットが一つだけのラベルを持っている場合は、そのラベルの値が代わりに（存在しない）は、第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が最上位ラベルは、イーサネット上LSRによって送信されるすべてのMPLSパケットについて同じである「コンテキスト・ラベル」であると、2つのラベルを押し、[RFC5331]の手順に従うことが期待が、とされています第二ラベルが異なるのLSPのために異なっています。 MAC DA値は、パケットに関する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でイーサネットマルチキャストアドレスのセットを所有しています。イーサネットマルチキャストフレームがIPマルチキャストパケットを運ぶとき-7F-FF-FFを01-00-5Eする範囲01-00-5E-00-00-00にアドレスが既に使用のために予約されています。
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は、01-00-5E-8F-FF-FFに使用するためのイーサネットマルチキャストフレームがMPLSマルチキャストパケットを運ぶとき範囲01-00-5E-80-00-00のイーサネット・アドレスを予約しました。イーサタイプ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.
この文書はのEtherType 8847及び8848の使用法を変更するように、以下のように、IANAは、これらのEtherTypeの記述を変更しました。 RFC 3032で、この文書で定義されているイーサタイプ8847は、「MPLS」と定義されます。この文書で定義されているイーサタイプ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.
コードポイントの悪意のある変更は、パケットの損失またはmisroutingもたらし得ます。しかし、また、ラベルを変更することなく、コードポイントを変更することは予測可能な効果をもたらすことはありません。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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月。
[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月。
[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.ローゼン、編、 "IP又は総称ルーティングカプセル化（GRE）でMPLSカプセル化"、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]アガルワル、R.、Rekhter、Y.、およびE.ローゼン、 "MPLS上流ラベルの割り当てとコンテキスト固有のラベルスペース"、RFC 5331、2008年8月。
Authors' Addresses
著者のアドレス
Toerless Eckert Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
Toerlessエッカートシスコシステムズ社170タスマン・ドライブサンノゼ、CA、95134
EMail: eckert@cisco.com
メールアドレス：eckert@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
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
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に情報を記述してください。