RFC5332 日本語訳

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

コメントを求めるワーキンググループT.エッケルトの要求をネットワークでつないでください: 5332 エドE.ローゼン、カテゴリ: 規格はシスコシステムズInc.アップデートを追跡します: 3032 4023年のR.Aggarwal Y.Rekhter杜松は2008年8月にInc.をネットワークでつなぎます。

                     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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

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".

RFC3032はMPLSのために2データ・リンク層codepointsを設立しました、データ・リンク層フレームがMPLSユニキャストかMPLSマルチキャストパケットを運ぶか否かに関係なく、区別するのにおいて、使用されています。 しかしながら、この用法は決して配備されませんでした。 この仕様は、これらの2codepointsの意味を再定義することによって、RFC3032をアップデートします。 現在、マルチキャストパケットを運ぶのに両方のcodepointsを使用できます。 現在、2番目のcodepoint(以前「マルチキャストcodepoint」)は多重処理メディアだけで使用されることになっています、そして、それは「以下のラベルスタックのトップラベルは上流へ割り当てられたラベルです。」と意味することになっています。

   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.

RFC3032は、MPLSマルチキャストパケットを運ぶイーサネットフレームの「Mac DA」(中型のアクセス層の送付先アドレス)分野に置かれるために送付先アドレスを指定しません。 このドキュメントはその仕様を提供します。

   This document updates RFC 3032 and RFC 4023.

このドキュメントはRFC3032とRFC4023をアップデートします。

Eckert, et al.              Standards Track                     [Page 1]

RFC 5332             MPLS Multicast Encapsulations           August 2008

エッケルト、他 規格はMPLSマルチキャストカプセル化2008年8月にRFC5332を追跡します[1ページ]。

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

1. 序論…2 2. 要件の仕様…3 3. 上流へ川下で割り当てにされるに対して割り当てられる…3 4. イーサネットCodepoints…6 5. pppは分野について議定書の中で述べます…6 6. GREはタイプについて議定書の中で述べます…6 7. IPプロトコル番号…7 8. マルチキャストMPLSのためのイーサネットMAC DA…7 9. IANA問題…8 10. セキュリティ問題…8 11. 標準の参照…9

1.  Introduction

1. 序論

   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.

RFC3031[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が次に模写されるためにパケットがある意味論がある次のホップの1セットとそれぞれの指定に送られたパケットのコピーを指定するなら特定の文脈の「マルチキャストラベル」が跳ぶということになるように特定のMPLSラベルを定義します。 この定義が次のホップのセットが独身のメンバーを含むケースに対応することに注意してください。 特定の文脈でラベルをマルチキャストラベルにすることはセットに付けられた意味論です、すなわち、パケットを模写して、セットに1人以上のメンバーがいるならセットのすべてのメンバーに伝わるという意志。

   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.

RFC3032[RFC3032]はMPLSのために2データ・リンク層codepointsを設立しました: データ・リンク層フレームがデータ・リンク層フレームがMPLSマルチキャストパケットを運ぶのを示すためにMPLSユニキャストパケット、およびもう片方を運ぶのを示す1。 「マルチキャストパケット」という用語はRFC3032で正確に定義されません、「マルチキャスト」codepointが、パケットのトップラベルがマルチキャストラベルであると認識することを意図すると推定するかもしれませんが。 しかしながら、マルチキャストcodepointは一度も配備されたことがありません、そして、MPLSマルチキャストのための手順のさらなる開発は2codepointsの必要がある間2codepointsの使用がRFC3032によって適切に得られないのを示しました。

Eckert, et al.              Standards Track                     [Page 2]

RFC 5332             MPLS Multicast Encapsulations           August 2008

エッケルト、他 規格はMPLSマルチキャストカプセル化2008年8月にRFC5332を追跡します[2ページ]。

   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が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.

このドキュメントは、codepointsの使用を再指定することによって、RFC3032とRFC4023をアップデートします。 「マルチキャストcodepoint」のそれらの2RFCsで指定される古い使用はこれにより非難されます。

   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.)

RFC3032、そして/または、4023に従ってMPLSマルチキャストをする実現がこのドキュメントによると、MPLSマルチキャストをする実現で共同利用できないことに注意してください。 codepointsの推奨しない使用を支持するいくつかの配備されたプラットホームがあるかもしれませんが、それらのプラットホームは、MPLSマルチキャストを支持するために制御飛行機メカニズムをサポートしません。 制御飛行機の不在は、codepointsの推奨しない使用を実行するシステムが、ここに指定されるとしてのcodepointsを使用するシステムで共同利用するのを試みるのを防ぐでしょう。 (MPLSマルチキャスト制御飛行機が推奨しないcodepointを支持するだけであるプラットホームで実行されることになっているなら、ブラックホール、そして/または、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.

RFC3032は、MPLSパケットがイーサネットマルチキャストフレームで運ばれるのを許容しますが、それはその場合設定されるMedium Access Layer Destination Address(MAC DA)分野がことである方法を指定しません。 このドキュメントはその仕様を提供します。

2.  Specification of Requirements

2. 要件の仕様

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

3.  Upstream-Assigned vs. Downstream-Assigned

3. 上流へ川下で割り当てにされるに対して割り当てられます。

   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.

R2がLabel Switching Router(LSR)R1からR1がパケットのラベルスタックにラベルLを置くLSR R2にラベルされたパケットPを送って、対応するForwarding Equivalence Class(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に広告に掲載されたなら、ラベル結合は「川下で割り当てられる」として知られています。 RFC3031は川下で割り当てられたラベル結合について議論するだけです。

   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に広告に掲載されたなら、ラベル結合は「上流へ割り当てられる」として知られています。

Eckert, et al.              Standards Track                     [Page 3]

RFC 5332             MPLS Multicast Encapsulations           August 2008

エッケルト、他 規格はMPLSマルチキャストカプセル化2008年8月にRFC5332を追跡します[3ページ]。

   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,

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パケット(例えば、RFC4023[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.

以下で指定されたある条件のもとでは、マルチキャストラベルは上流へ割り当てられるかもしれません。 上流へ割り当てられたラベルを使用する能力はOPTIONALの特徴です。 川下の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時までに作られたそのリンクかトンネルにおけるトランスミッションを受けるように。

Eckert, et al.              Standards Track                     [Page 4]

RFC 5332             MPLS Multicast Encapsulations           August 2008

エッケルト、他 規格はMPLSマルチキャストカプセル化2008年8月にRFC5332を追跡します[4ページ]。

        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つは適用されます:

         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がラベルを付けます。

Eckert, et al.              Standards Track                     [Page 5]

RFC 5332             MPLS Multicast Encapsulations           August 2008

エッケルト、他 規格はMPLSマルチキャストカプセル化2008年8月にRFC5332を追跡します[5ページ]。

      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パケットのトップラベルが上流へ割り当てられますかそれとも川下で割り当てられるかを指定するcodepointを提供しなければなりません。 特定のタイプのデータ・リンクかトンネルがそのようなcodepointを提供しないなら、3番目のシナリオを使用してはいけません。

   The remainder of this document specifies procedures for setting the
   data link layer codepoints and address fields.

このドキュメントの残りはデータ・リンク層codepointsを設定するための手順とアドレス・フィールドを指定します。

4.  Ethernet Codepoints

4. イーサネットCodepoints

   Ethernet is an example of a multipoint-to-multipoint data link.

イーサネットは多点から多点へのデータ・リンクに関する例です。

   Ethertype 0x8847 is used whenever a unicast ethernet frame carries an
   MPLS packet.

ユニキャストイーサネットフレームがMPLSパケットを運ぶときはいつも、Ethertype0x8847は使用されています。

   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パケットを運ぶときはいつも、Ethertype0x8847は使用されます、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パケットがマルチキャストイーサネットフレームで運ばれるときだけ、以前「MPLSマルチキャストcodepoint」として知られているEthertype0x8848は使用されていることになっています。

5.  PPP Protocol Field

5. pppプロトコル分野

   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プロトコル分野はいつも0×0281に設定されます。

6.  GRE Protocol Type

6. GREプロトコルタイプ

   RFC 4023 is modified as described below.

RFC4023は以下で説明されるように変更されています。

   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.

Genericルート設定Encapsulation(GRE)の受信者IPアドレスがユニキャストIPアドレスであるなら、GREのMPLSカプセル化にすべての場合にethertype値0x8847を使用しなければなりません。

   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を使用しなければなりません。

Eckert, et al.              Standards Track                     [Page 6]

RFC 5332             MPLS Multicast Encapsulations           August 2008

エッケルト、他 規格はMPLSマルチキャストカプセル化2008年8月にRFC5332を追跡します[6ページ]。

   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ペイロードのトップラベルがGREパケットの送付先アドレスがマルチキャストIPアドレスであるなら上流へ割り当てられるのが知られているかもしれません。 このような場合には、誤りであるとマルチキャスト送付先IPアドレスがあるGREパケットでの8847codepointの発生を考えなければなりません、そして、パケットを捨てなければなりません。

7.  IP Protocol Number

7. IPプロトコル番号

   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.

RFC4023は以下の通り変更されます: IPv4プロトコルNumber分野かIPv6 Next Header分野がいつも137に設定されます、要約のMPLSパケットがMPLSマルチキャストパケットであるか否かに関係なく。

   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パケットがスタックの先端に上流へ割り当てられたラベルを持っています。 この仕様の範囲の外にこれが特定のトンネルに決定する手段があります。

8.  Ethernet MAC DA for Multicast MPLS

8. マルチキャストMPLSのためのイーサネットMAC DA

   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パケットを送るとき、値01-00-5のe-8v-wx-yzにMAC Destination Addressを設定しなければなりません:(そこでは、vwxyzが以下の(5少量)の20ビットの選択値群です)。

      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はパケットのラベルスタックの上の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つの異なった手順を用いるLSRsは共同利用しなければなりません。 それはそうであり、LSR MUST NOTフィルタは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

LSRがパケットのラベルスタックの上のMPLSラベルの1つの値にvwxyzを設定する手順に従って、そのラベルスタックが2個以上のラベルを含んでいるなら、デフォルトで、vwxyzはパケットのラベルスタックの上の2番目のMPLSラベルの値に用意ができなければなりません。 「2番目のラベル」で、私たちは、そんなにすぐに、ラベルスタックエントリーにあるラベルが最上のラベルスタックエントリーに続くと言っています。 そうするために構成されるなら、LSR MAYは2番目以外のラベルを許容します。

Eckert, et al.              Standards Track                     [Page 7]

RFC 5332             MPLS Multicast Encapsulations           August 2008

エッケルト、他 規格はMPLSマルチキャストカプセル化2008年8月にRFC5332を追跡します[7ページ]。

   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.

このために使用されるために。 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]の手順に従うと予想されます、異なったLSPsにおいて、LSRによってイーサネットに伝えられるすべてのMPLSパケットに、同じ「文脈ラベル」である最上のラベルにもかかわらず、2番目のラベルが異なっていた状態で2個のラベルを押して。 したがって、MAC DA値が2番目のラベルの機能であるなら、パケットに関する一層の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放送演説(マルチキャストアドレスと区別されるように)の使用はこの仕様の範囲の中に下がりません。

9.  IANA Considerations

9. IANA問題

   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-5 範囲e-00-00-00で既に01-00-5の電子ffのff ffとしてイーサネットマルチキャストアドレスのセットを所有します。 イーサネットマルチキャストフレームがIPマルチキャストパケットを運ぶとき、01-00-5 e-7f-ff ffへの01-00-5 範囲e-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.

イーサネットマルチキャストフレームがMPLSマルチキャストパケットを運ぶとき、IANAは使用のための01-00-5 e-8f-ff ffへの01-00-5 範囲e-80-00-00のイーサネットアドレスを予約しました。 ethertype8847か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.

このドキュメントがethertypes8847と8848年の用法を変更するとき、IANAは以下のこれらのethertypesの記述を変えました。 Ethertype8847は「MPLS」、RFC3032で定義されるおよびこのドキュメントで定義されます。 Ethertype8848は「上流が割り当てられているMPLSラベル」本書では定義されるように定義されます。

10.  Security Considerations

10. セキュリティ問題

   The security considerations of RFC 3032 and RFC 4023 apply.

RFC3032とRFC4023のセキュリティ問題は適用されます。

   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の悪意がある変化はパケットの損失かmisroutingをもたらすかもしれません。 しかしながら、また、ラベルを変更しないで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の悪意がある変更は意図している受取人でというよりむしろ第三者によって受け取られるパケットをもたらすことができます。

Eckert, et al.              Standards Track                     [Page 8]

RFC 5332             MPLS Multicast Encapsulations           August 2008

エッケルト、他 規格はMPLSマルチキャストカプセル化2008年8月にRFC5332を追跡します[8ページ]。

11.  Normative References

11. 引用規格

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、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ラベルスタックコード化」、RFC3032(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] エドオースター、T.、Rekhter、Y.、およびE.ローゼン、「IPか一般ルーティングのカプセル化(GRE)でMPLSを要約する」RFC4023(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.ローゼン、「MPLSの上流のラベル課題と文脈詳細ラベルスペース」、RFC5331、2008年8月。

Eckert, et al.              Standards Track                     [Page 9]

RFC 5332             MPLS Multicast Encapsulations           August 2008

エッケルト、他 規格はMPLSマルチキャストカプセル化2008年8月にRFC5332を追跡します[9ページ]。

Authors' Addresses

作者のアドレス

   Toerless Eckert
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

Driveサンノゼ、ToerlessエッケルトシスコシステムズInc.170タスマン・カリフォルニア 95134

   EMail: eckert@cisco.com

メール: eckert@cisco.com

   Eric C. Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA 01719

マサチューセッツ通りBoxborough、エリックC.ローゼンシスコシステムズInc.1414MA 01719

   EMail: erosen@cisco.com

メール: erosen@cisco.com

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089

Rahul Aggarwal杜松は1194の北のマチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089

   EMail: rahul@juniper.net

メール: rahul@juniper.net

   Yakov Rekhter
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089

ヤコフRekhter Juniperは1194の北のマチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089

   EMail: yakov@juniper.net

メール: yakov@juniper.net

Eckert, et al.              Standards Track                    [Page 10]

RFC 5332             MPLS Multicast Encapsulations           August 2008

エッケルト、他 規格はMPLSマルチキャストカプセル化2008年8月にRFC5332を追跡します[10ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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に情報を記述してください。

Eckert, et al.              Standards Track                    [Page 11]

エッケルト、他 標準化過程[11ページ]