Network Working Group E. Rosen
Request for Comments: 3032 D. Tappan
Category: Standards Track G. Fedorkow
Cisco Systems, Inc.
Y. Rekhter
Juniper Networks
D. Farinacci
T. Li
Procket Networks, Inc.
A. Conta
TranSwitch Corporation
January 2001
MPLS Label Stack Encoding
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
"Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which support MPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding.
「マルチプロトコルラベルスイッチング（MPLS）は、」[1]「とラベル付けされたパケット」に、それによって、「ラベルスタック」とネットワーク層パケットを増強それらを回転させるための手順のセットを必要とします。 MPLSをサポートするルータは、「ラベルスイッチングルータ」、または「のLSR」として知られています。特定のデータリンク上で標識されたパケットを送信するために、LSRがラベルスタックとネットワーク層パケットを所定の符号化技術をサポートする必要があり、標識されたパケットを生成します。この文書は、同様にポイントツーポイントプロトコル（PPP）データリンク上で、LANのデータリンク上で、そしておそらく他のデータリンク上で標識されたパケットを送信するために、LSRが使用するエンコーディングを指定します。いくつかのデータリンク上で、スタックの最上部のラベルは異なる方法で符号化されてもよいが、ここで説明される技術は、ラベルスタックの残りの部分を符号化するために使用されなければなりません。また、このドキュメントでは、ラベルスタックエンコーディングのさまざまなフィールドを処理するための規則と手順を指定します。
Table of Contents
目次
1 Introduction ........................................... 2
1.1 Specification of Requirements .......................... 3
2 The Label Stack ........................................ 3
2.1 Encoding the Label Stack ............................... 3
2.2 Determining the Network Layer Protocol ................. 5
2.3 Generating ICMP Messages for Labeled IP Packets ........ 6
2.3.1 Tunneling through a Transit Routing Domain ............. 7
2.3.2 Tunneling Private Addresses through a Public Backbone .. 7
2.4 Processing the Time to Live Field ...................... 8
2.4.1 Definitions ............................................ 8
2.4.2 Protocol-independent rules ............................. 8
2.4.3 IP-dependent rules ..................................... 9
2.4.4 Translating Between Different Encapsulations ........... 9
3 Fragmentation and Path MTU Discovery ................... 10
3.1 Terminology ............................................ 11
3.2 Maximum Initially Labeled IP Datagram Size ............. 12
3.3 When are Labeled IP Datagrams Too Big? ................. 13
3.4 Processing Labeled IPv4 Datagrams which are Too Big .... 13
3.5 Processing Labeled IPv6 Datagrams which are Too Big .... 14
3.6 Implications with respect to Path MTU Discovery ........ 15
4 Transporting Labeled Packets over PPP .................. 16
4.1 Introduction ........................................... 16
4.2 A PPP Network Control Protocol for MPLS ................ 17
4.3 Sending Labeled Packets ................................ 18
4.4 Label Switching Control Protocol Configuration Options . 18
5 Transporting Labeled Packets over LAN Media ............ 18
6 IANA Considerations .................................... 19
7 Security Considerations ................................ 19
8 Intellectual Property .................................. 19
9 Authors' Addresses ..................................... 20
10 References ............................................. 22
11 Full Copyright Statement ............................... 23
"Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which support MPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet.
「マルチプロトコルラベルスイッチング（MPLS）は、」[1]「とラベル付けされたパケット」に、それによって、「ラベルスタック」とネットワーク層パケットを増強それらを回転させるための手順のセットを必要とします。 MPLSをサポートするルータは、「ラベルスイッチングルータ」、または「のLSR」として知られています。特定のデータリンク上で標識されたパケットを送信するために、LSRがラベルスタックとネットワーク層パケットを所定の符号化技術をサポートする必要があり、標識されたパケットを生成します。
This document specifies the encoding to be used by an LSR in order to transmit labeled packets on PPP data links and on LAN data links. The specified encoding may also be useful for other data links as well.
このドキュメントは、PPPデータリンク上とLANのデータリンク上のラベル付きパケットを送信するために、LSRが使用するエンコーディングを指定します。指定されたエンコーディングも同様に他のデータリンクのために有用であり得ます。
This document also specifies rules and procedures for processing the various fields of the label stack encoding. Since MPLS is independent of any particular network layer protocol, the majority of such procedures are also protocol-independent. A few, however, do differ for different protocols. In this document, we specify the protocol-independent procedures, and we specify the protocol-dependent procedures for IPv4 and IPv6.
また、このドキュメントでは、ラベルスタックエンコーディングのさまざまなフィールドを処理するための規則と手順を指定します。 MPLSは、任意の特定のネットワーク層プロトコルから独立しているので、このような手順の大半は、プロトコルに依存しています。いくつかは、しかし、異なるプロトコルごとに異なります。この文書では、我々は、プロトコルに依存しない方法を指定し、我々は、IPv4とIPv6のプロトコルに依存する手順を指定します。
LSRs that are implemented on certain switching devices (such as ATM switches) may use different encoding techniques for encoding the top one or two entries of the label stack. When the label stack has additional entries, however, the encoding technique described in this document MUST be used for the additional label stack entries.
（例えば、ATMスイッチなど）は、特定のスイッチング素子上に実装されているのLSRがラベルスタックの一番上または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 RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
The label stack is represented as a sequence of "label stack entries". Each label stack entry is represented by 4 octets. This is shown in Figure 1.
ラベルスタックは、「ラベルスタックエントリー」のシーケンスとして表現されます。各ラベルスタックエントリは4つのオクテットで表現されます。これは、図1に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
| Label | Exp |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time to Live, 8 bits
Figure 1
図1
The label stack entries appear AFTER the data link layer headers, but BEFORE any network layer headers. The top of the label stack appears earliest in the packet, and the bottom appears latest. The network layer packet immediately follows the label stack entry which has the S bit set.
ラベルスタックエントリは、データリンク層のヘッダの後に表示されますが、任意のネットワーク層ヘッダの前。ラベルスタックの最上位は、パケット内の最も初期表示され、下部には、最新表示されます。ネットワーク層パケットは、直ちにSビットが設定されているラベルスタックエントリに続きます。
Each label stack entry is broken down into the following fields:
各ラベルスタックエントリは、次のフィールドに分かれています。
This bit is set to one for the last entry in the label stack (i.e., for the bottom of the stack), and zero for all other label stack entries.
このビットは（すなわち、スタックの底部のための）ラベルスタック内の最後のエントリのための1つ、および他のすべてのラベルスタックエントリはゼロに設定されています。
This eight-bit field is used to encode a time-to-live value. The processing of this field is described in section 2.4.
この8ビットのフィールドは、生存期間値をエンコードするために使用されます。このフィールドの処理は、セクション2.4に記載されています。
This three-bit field is reserved for experimental use.
この3ビットのフィールドは、実験的な使用のために予約されています。
This 20-bit field carries the actual value of the Label.
この20ビットのフィールドは、ラベルの実際の値を運びます。
When a labeled packet is received, the label value at the top of the stack is looked up. As a result of a successful lookup one learns:
ラベル付きパケットを受信した場合、スタックの最上部のラベルの値が検索されます。成功したルックアップの結果、一つは学習します。
a) the next hop to which the packet is to be forwarded;
パケットが転送されるべきa）のネクストホップ。
b) the operation to be performed on the label stack before forwarding; this operation may be to replace the top label stack entry with another, or to pop an entry off the label stack, or to replace the top label stack entry and then to push one or more additional entries on the label stack.
B）動作を転送する前にラベルスタックに実行されます。この操作は、他でトップラベルスタックエントリーを交換するか、ラベルスタックオフエントリをポップするために、またはトップラベルスタックエントリーを交換した後、ラベルスタックの上に1つの以上の追加のエントリをプッシュすることであってもよいです。
In addition to learning the next hop and the label stack operation, one may also learn the outgoing data link encapsulation, and possibly other information which is needed in order to properly forward the packet.
ネクストホップおよびラベルスタックの操作を学習することに加えて、1はまた、発信データリンクのカプセル化、およびおそらく適切にパケットを転送するために必要とされる他の情報を知ることがあります。
There are several reserved label values:
いくつかの予約ラベル値があります。
i. A value of 0 represents the "IPv4 Explicit NULL Label". This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv4 header.
私。 0の値は、「IPv4明示的NULLラベル」を表しています。このラベル値は、ラベルスタックの最下部にのみ法的です。それはラベルスタックをポップする必要があることを示し、及びパケットの転送は、その後、IPv4ヘッダに基づいていなければなりません。
ii. A value of 1 represents the "Router Alert Label". This label value is legal anywhere in the label stack except at the bottom. When a received packet contains this label value at the top of the label stack, it is delivered to a local software module for processing. The actual forwarding of the packet is determined by the label beneath it in the stack. However, if the packet is forwarded further, the Router Alert Label should be pushed back onto the label stack before forwarding. The use of this label is analogous to the use of the "Router Alert Option" in IP packets [5]. Since this label cannot occur at the bottom of the stack, it is not associated with a particular network layer protocol.
II。 1の値は、「ルータアラートラベル」を表します。このラベル値は、下部の以外ラベルスタックに法的どこにでもあります。受信したパケットは、ラベルスタックの最上位にこのラベル値が含まれている場合は、処理のためにローカルのソフトウェア・モジュールに配信されます。パケットの実際の転送は、スタック内のその下のラベルによって決定されます。パケットをさらに転送された場合は、ルータアラートラベルを転送する前にラベルスタックにプッシュバックされなければなりません。このラベルを使用すると、IPパケットにおける「ルータアラートオプション」の使用[5]に類似しています。このラベルは、スタックの底で発生することができないので、特定のネットワーク層プロトコルに関連付けられていません。
iii. A value of 2 represents the "IPv6 Explicit NULL Label". This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv6 header.
III。 2の値は「IPv6明示的NULLラベル」を表しています。このラベル値は、ラベルスタックの最下部にのみ法的です。それはラベルスタックをポップする必要があることを示し、及びパケットの転送は、その後、IPv6ヘッダーに基づいていなければなりません。
iv. A value of 3 represents the "Implicit NULL Label". This is a label that an LSR may assign and distribute, but which never actually appears in the encapsulation. When an LSR would otherwise replace the label at the top of the stack with a new label, but the new label is "Implicit NULL", the LSR will pop the stack instead of doing the replacement. Although this value may never appear in the encapsulation, it needs to be specified in the Label Distribution Protocol, so a value is reserved.
IV。 3の値は、「暗黙のNULLラベル」を表します。これはLSRが割り当てて配布し、実際にカプセル化に表示されないかもしれないラベルです。 LSRは、そうでない場合は、新しいラベルをスタックの最上部にラベルを交換するだろうが、新しいラベルが「暗黙のNULL」である場合には、LSRがスタックをポップ代わりの交換をしています。この値は、カプセル化には表示されないかもしれないが、それはラベル配布プロトコルで指定する必要があり、その値が予約されています。
v. Values 4-15 are reserved.
V。4-15が予約されている値。
When the last label is popped from a packet's label stack (resulting in the stack being emptied), further processing of the packet is based on the packet's network layer header. The LSR which pops the last label off the stack must therefore be able to identify the packet's network layer protocol. However, the label stack does not contain any field which explicitly identifies the network layer protocol. This means that the identity of the network layer protocol must be inferable from the value of the label which is popped from the bottom of the stack, possibly along with the contents of the network layer header itself.
最後のラベルはパケットのラベルスタックからポップされたときにパケットのさらなる処理は、パケットのネットワークレイヤヘッダに基づいており、（スタックをもたらす空にされます）。スタックから最後のラベルをポップLSRは、それゆえ、パケットのネットワーク層プロトコルを識別できなければなりません。しかし、ラベルスタックは、明示的にネットワーク層プロトコルを識別する任意のフィールドが含まれていません。これは、ネットワーク層プロトコルの識別はおそらくネットワーク層ヘッダ自体の内容とともに、スタックの底部からポップされるラベルの値から類推しなければならないことを意味します。
Therefore, when the first label is pushed onto a network layer packet, either the label must be one which is used ONLY for packets of a particular network layer, or the label must be one which is used ONLY for a specified set of network layer protocols, where packets of the specified network layers can be distinguished by inspection of the network layer header. Furthermore, whenever that label is replaced by another label value during a packet's transit, the new value must also be one which meets the same criteria. If these conditions are not met, the LSR which pops the last label off a packet will not be able to identify the packet's network layer protocol.
最初のラベルは、ネットワーク層パケットにプッシュされ、いずれかのラベルは、特定のネットワーク層、またはラベルのパケットに使用されるものでなければならない場合したがって、唯一のネットワーク層プロトコルの指定されたセットのために使用されるものでなければなりませんここで、指定されたネットワーク層のパケットは、ネットワーク層ヘッダの検査によって区別することができます。そのラベルはパケットの通過中に別のラベル値で置き換えられるたびさらに、新しい値も同じ基準を満たすものでなければなりません。これらの条件が満たされない場合、パケットオフ最後のラベルをポップLSRは、パケットのネットワーク層プロトコルを識別することができません。
Adherence to these conditions does not necessarily enable intermediate nodes to identify a packet's network layer protocol. Under ordinary conditions, this is not necessary, but there are error conditions under which it is desirable. For instance, if an intermediate LSR determines that a labeled packet is undeliverable, it may be desirable for that LSR to generate error messages which are specific to the packet's network layer. The only means the intermediate LSR has for identifying the network layer is inspection of the top label and the network layer header. So if intermediate nodes are to be able to generate protocol-specific error messages for labeled packets, all labels in the stack must meet the criteria specified above for labels which appear at the bottom of the stack.
これらの条件の遵守は、必ずしもパケットのネットワーク層プロトコルを識別するために中間ノードを使用可能にしません。通常の条件下では、これは必要ありませんが、それが望ましい、その下のエラー条件があります。中間LSRがラベル付きパケットが配信不能であると判断した場合、そのLSRは、パケットのネットワークレイヤに固有のエラーメッセージを生成するために、例えば、それが望ましいかもしれません。唯一中間LSRは、ネットワーク層を識別するためのトップラベルとネットワーク層ヘッダの検査されたことを意味します。中間ノードは、標識されたパケットのプロトコル固有のエラーメッセージを生成することができるようになっているのであれば、スタック内のすべてのラベルは、スタックの一番下に表示されるラベルの上記指定された基準を満たさなければなりません。
If a packet cannot be forwarded for some reason (e.g., it exceeds the data link MTU), and either its network layer protocol cannot be identified, or there are no specified protocol-dependent rules for handling the error condition, then the packet MUST be silently discarded.
パケットが何らかの理由で転送することができない場合（例えば、それはデータリンクMTUを超えている）、のいずれかのネットワーク層プロトコルを識別することができない、またはエラー状態を扱うための指定されたプロトコルに依存するルールが存在しない場合、パケットがなければならない（MUST）黙って破棄。
Section 2.4 and section 3 discuss situations in which it is desirable to generate ICMP messages for labeled IP packets. In order for a particular LSR to be able to generate an ICMP packet and have that packet sent to the source of the IP packet, two conditions must hold:
2.4節と節3は、ラベルされたIPパケットのICMPメッセージを生成することが望ましいである状況を議論します。特定のLSRは、ICMPパケットを生成し、そのパケットがIPパケットの送信元に送信したことができるようにするために、二つの条件を満たさなければなりません。
1. it must be possible for that LSR to determine that a particular labeled packet is an IP packet;
1.それは、特定の標識されたパケットがIPパケットであることを決定するために、そのLSRのために可能でなければなりません。
2. it must be possible for that LSR to route to the packet's IP source address.
2.それは、パケットの送信元IPアドレスへのルートへのLSRのために可能でなければなりません。
Condition 1 is discussed in section 2.2. The following two subsections discuss condition 2. However, there will be some cases in which condition 2 does not hold at all, and in these cases it will not be possible to generate the ICMP message.
条件1は、セクション2.2で議論されています。次の2つのサブセクションは、条件2が全く保持しないで、いくつかの例があるでしょう。しかし、条件2を議論し、これらのケースでは、ICMPメッセージを生成することはできません。
Suppose one is using MPLS to "tunnel" through a transit routing domain, where the external routes are not leaked into the domain's interior routers. For example, the interior routers may be running OSPF, and may only know how to reach destinations within that OSPF domain. The domain might contain several Autonomous System Border Routers (ASBRs), which talk BGP to each other. However, in this example the routes from BGP are not distributed into OSPF, and the LSRs which are not ASBRs do not run BGP.
一つは、外部ルートは、ドメインの内部ルータに漏れていないトランジットルーティングドメインを介して「トンネル」にMPLSを使用していると仮定する。例えば、内部ルータはOSPFを実行することができる、とだけがOSPFドメイン内の宛先に到達する方法を知っているかもしれません。ドメインは、お互いにBGPを話し、いくつかの自律システム境界ルータ（ASBRは）が、含まれている場合があります。しかし、この例では、BGPからのルートをOSPFに分配されていない、とのASBRでないのLSRはBGPを実行しないでください。
In this example, only an ASBR will know how to route to the source of some arbitrary packet. If an interior router needs to send an ICMP message to the source of an IP packet, it will not know how to route the ICMP message.
この例では、唯一のASBRはどのようにいくつかの任意のパケットの送信元へのルートに知ることができます。内部ルータは、IPパケットの送信元にICMPメッセージを送信する必要がある場合は、それがどのようにルートICMPメッセージをに知ることができません。
One solution is to have one or more of the ASBRs inject "default" into the IGP. (N.B.: this does NOT require that there be a "default" carried by BGP.) This would then ensure that any unlabeled packet which must leave the domain (such as an ICMP packet) gets sent to a router which has full routing information. The routers with full routing information will label the packets before sending them back through the transit domain, so the use of default routing within the transit domain does not cause any loops.
一つの解決策は、のASBRの1つ以上がIGPに「デフォルト」を注入することです。 （N.Bは：これは、BGPによって運ばれる「デフォルト」があることを必要としません。）これは、その後、（例えばICMPパケットなど）のドメインを残しておく必要があり、ラベルが付いていないパケットは完全なルーティング情報を持っているルータに送信されることを保証するであろう。完全なルーティング情報を持つルータはトランジットドメインを介して戻ってそれらを送信する前に、パケットにラベルを付けますので、トランジットドメイン内のデフォルトのルーティングを使用すると、任意のループが発生することはありません。
This solution only works for packets which have globally unique addresses, and for networks in which all the ASBRs have complete routing information. The next subsection describes a solution which works when these conditions do not hold.
このソリューションは、グローバルに一意のアドレスを持っている、そしてすべてのASBRが完全なルーティング情報を持っているネットワークのためのパケットのために動作します。次のサブセクションでは、これらの条件が満たされていない時に機能するソリューションについて説明します。
In some cases where MPLS is used to tunnel through a routing domain, it may not be possible to route to the source address of a fragmented packet at all. This would be the case, for example, if the IP addresses carried in the packet were private (i.e., not globally unique) addresses, and MPLS were being used to tunnel those packets through a public backbone. Default routing to an ASBR will not work in this environment.
MPLSは、ルーティングドメインを介してトンネルに使用されるいくつかのケースでは、それは全くフラグメントパケットの送信元アドレスにルーティングすることが可能ではないかもしれません。パケットで運ばれたIPアドレス（すなわち、グローバルに一意ではない）アドレス、プライベートであった、とMPLSは、公衆バックボーンを介してそれらのパケットトンネルに使用された場合、これは、例えば、場合です。 ASBRへのデフォルトのルーティングは、この環境では動作しません。
In this environment, in order to send an ICMP message to the source of a packet, one can copy the label stack from the original packet to the ICMP message, and then label switch the ICMP message. This will cause the message to proceed in the direction of the original packet's destination, rather than its source. Unless the message is label switched all the way to the destination host, it will end up, unlabeled, in a router which does know how to route to the source of original packet, at which point the message will be sent in the proper direction.
この環境では、パケットの送信元にICMPメッセージを送信するために、一つはICMPメッセージに元のパケットからラベルスタックをコピーし、ICMPメッセージを切り替えるラベルを付けることができます。これは、メッセージは元のパケットの宛先ではなく、そのソースの方向に進むことになります。メッセージは、ラベルが宛先ホストにすべての方法を切り替えられた場合を除き、それはメッセージが正しい方向に送信される時点で、どのように元のパケットの送信元へのルート、知っているルータでは、標識されていない、なってしまいます。
This technique can be very useful if the ICMP message is a "Time Exceeded" message or a "Destination Unreachable because fragmentation needed and DF set" message.
「断片化が必要とDFが設定されているため宛先到達不能」メッセージをICMPメッセージはメッセージまたは「時間が超過」されている場合、この技術は非常に便利です。
When copying the label stack from the original packet to the ICMP message, the label values must be copied exactly, but the TTL values in the label stack should be set to the TTL value that is placed in the IP header of the ICMP message. This TTL value should be long enough to allow the circuitous route that the ICMP message will need to follow.
ICMPメッセージに元のパケットのラベルスタックをコピーする場合、ラベルの値が正確にコピーされなければならないが、ラベルスタックのTTL値はICMPメッセージのIPヘッダ内に配置されたTTL値に設定されるべきです。このTTL値は、ICMPメッセージを実行する必要がありますことを遠回りのルートを可能にするのに十分長くなければなりません。
Note that if a packet's TTL expiration is due to the presence of a routing loop, then if this technique is used, the ICMP message may loop as well. Since an ICMP message is never sent as a result of receiving an ICMP message, and since many implementations throttle the rate at which ICMP messages can be generated, this is not expected to pose a problem.
なお、パケットのTTLの期限切れは、ルーティングループの存在は、この技術が使用される場合、次いで、ICMPメッセージがループもよいによるものである場合。 ICMPメッセージがICMPメッセージを受信した結果として送信されることはないので、多くの実装は、ICMPメッセージを生成することができる速度を絞るため、そして、これは問題にならないと予想されます。
The "incoming TTL" of a labeled packet is defined to be the value of the TTL field of the top label stack entry when the packet is received.
標識されたパケットの「着信TTL」がパケットを受信したときに上部ラベルスタックエントリのTTLフィールドの値であると定義されます。
The "outgoing TTL" of a labeled packet is defined to be the larger of:
標識されたパケットの「送信TTL」は、の大きくなるように定義されます。
a) one less than the incoming TTL, b) zero.
A）着信TTLより1少ない、B）ゼロ。
If the outgoing TTL of a labeled packet is 0, then the labeled packet MUST NOT be further forwarded; nor may the label stack be stripped off and the packet forwarded as an unlabeled packet. The packet's lifetime in the network is considered to have expired.
標識されたパケットの発信TTLが0である場合、標識されたパケットをさらに転送してはいけません。やラベルスタックを剥離し、パケットがラベルのないパケットとして転送することができます。ネットワークにおけるパケットの存続期間が満了していると考えられます。
Depending on the label value in the label stack entry, the packet MAY be simply discarded, or it may be passed to the appropriate "ordinary" network layer for error processing (e.g., for the generation of an ICMP error message, see section 2.3).
ラベルスタックエントリのラベルの値に応じて、パケットは単に破棄されてもよく、またはそれはエラー処理のために適切な「通常の」ネットワーク層に渡すことができる（例えば、ICMPエラーメッセージを生成するために、セクション2.3を参照されたいです） 。
When a labeled packet is forwarded, the TTL field of the label stack entry at the top of the label stack MUST be set to the outgoing TTL value.
標識されたパケットが転送される場合、ラベルスタックの最上部のラベルスタックエントリのTTLフィールドは、発信TTL値に設定しなければなりません。
Note that the outgoing TTL value is a function solely of the incoming TTL value, and is independent of whether any labels are pushed or popped before forwarding. There is no significance to the value of the TTL field in any label stack entry which is not at the top of the stack.
発信TTL値は単に着信TTL値の関数であり、任意のラベルを転送する前に、プッシュまたはポップされているかどうかとは無関係であることに留意されたいです。スタックの一番上にない任意のラベルスタックエントリ内のTTLフィールドの値に意味はありません。
We define the "IP TTL" field to be the value of the IPv4 TTL field, or the value of the IPv6 Hop Limit field, whichever is applicable.
当社は、適用ある方、IPv4のTTLフィールドの値、またはIPv6ホップ限界フィールドの値になるように、「IP TTL」フィールドを定義します。
When an IP packet is first labeled, the TTL field of the label stack entry MUST BE set to the value of the IP TTL field. (If the IP TTL field needs to be decremented, as part of the IP processing, it is assumed that this has already been done.)
IPパケットが最初にラベル付けされている場合、ラベルスタックエントリのTTLフィールドはIP TTLフィールドの値に設定する必要があります。 （IP TTLフィールドはIP処理の一部として、減分する必要がある場合、既に行われているものとします。）
When a label is popped, and the resulting label stack is empty, then the value of the IP TTL field SHOULD BE replaced with the outgoing TTL value, as defined above. In IPv4 this also requires modification of the IP header checksum.
ラベルをポップし、得られたラベルスタックが空である場合に上記で定義した通り、次にIPのTTLフィールドの値は、発信TTL値に置き換えてください。 IPv4では、これはまた、IPヘッダチェックサムの変更を必要とします。
It is recognized that there may be situations where a network administration prefers to decrement the IPv4 TTL by one as it traverses an MPLS domain, instead of decrementing the IPv4 TTL by the number of LSP hops within the domain.
その代わりに、ドメイン内LSPホップの数でIPv4のTTLをデクリメントのネットワーク管理は、それがMPLSドメインを横断するように、1つのIPv4によってTTLをデクリメントすることを好む状況が存在し得ることが認識されます。
Sometimes an LSR may receive a labeled packet over, e.g., a label switching controlled ATM (LC-ATM) interface [9], and may need to send it out over a PPP or LAN link. Then the incoming packet will not be received using the encapsulation specified in this document, but the outgoing packet will be sent using the encapsulation specified in this document.
時々LSRオーバー標識されたパケットを受信することができ、例えば、ラベルスイッチング制御ATM（LC-ATM）インターフェイス[9]、およびPPPまたはLANリンクを介してそれを送信する必要があるかもしれません。そして、着信パケットは、この文書で指定されたカプセル化を使用して受信されませんが、発信パケットは、この文書で指定されたカプセル化を使用して送信されます。
In this case, the value of the "incoming TTL" is determined by the procedures used for carrying labeled packets on, e.g., LC-ATM interfaces. TTL processing then proceeds as described above.
この場合には、「着信TTL」の値は、例えば、LC-ATMインターフェイス上に標識されたパケットを運ぶために使用される方法により決定されます。上記のようにTTL処理は次に進みます。
Sometimes an LSR may receive a labeled packet over a PPP or a LAN link, and may need to send it out, say, an LC-ATM interface. Then the incoming packet will be received using the encapsulation specified in this document, but the outgoing packet will not be sent using the encapsulation specified in this document. In this case, the procedure for carrying the value of the "outgoing TTL" is determined by the procedures used for carrying labeled packets on, e.g., LC-ATM interfaces.
時々、LSRは、PPPまたはLANリンク上のラベル付きパケットを受信し、それを送信する必要がある場合があり、LC-ATMインターフェイスは、言います。そして、着信パケットは、この文書で指定されたカプセル化を使用して受信されますが、発信パケットは、この文書で指定されたカプセル化を使用して送信されません。この場合には、「発信TTL」の値を搬送するための手順は、例えば、LC-ATMインターフェイス上に標識されたパケットを運ぶために使用される方法により決定されます。
Just as it is possible to receive an unlabeled IP datagram which is too large to be transmitted on its output link, it is possible to receive a labeled packet which is too large to be transmitted on its output link.
それはその出力リンク上で送信するには大きすぎる非標識IPデータグラムを受信することが可能であるのと同じように、その出力リンク上で送信するには大きすぎるラベル付きパケットを受信することが可能です。
It is also possible that a received packet (labeled or unlabeled) which was originally small enough to be transmitted on that link becomes too large by virtue of having one or more additional labels pushed onto its label stack. In label switching, a packet may grow in size if additional labels get pushed on. Thus if one receives a labeled packet with a 1500-byte frame payload, and pushes on an additional label, one needs to forward it as frame with a 1504-byte payload.
そのリンク上で送信されるのに十分元々小さかった受信パケット（標識または非標識）がそのラベルスタックにプッシュされ、1つまたは複数の追加のラベルを有するのおかげで大きくなりすぎることも可能です。追加のラベルが上のプッシュされます場合はラベルスイッチングでは、パケットのサイズが大きくなる可能性があります。 1が1500バイトのフレームペイロードで標識されたパケットを受信すると、追加のラベルに押すとこのように、一つは1504バイトのペイロードを持つフレームとしてそれを転送する必要があります。
This section specifies the rules for processing labeled packets which are "too large". In particular, it provides rules which ensure that hosts implementing Path MTU Discovery [4], and hosts using IPv6 [7,8], will be able to generate IP datagrams that do not need fragmentation, even if those datagrams get labeled as they traverse the network.
このセクションでは、「大きすぎる」されているラベル付きパケットを処理するためのルールを指定します。特に、パスMTUディスカバリを実装するホスト[4]、およびIPv6 [7,8]を用いて、ホストは、それらが横切るように、これらのデータグラムが標識を取得しても、断片化を必要としないIPデータグラムを生成することができるであろうことを確実に規則を提供しますネットワーク。
In general, IPv4 hosts which do not implement Path MTU Discovery [4] send IP datagrams which contain no more than 576 bytes. Since the MTUs in use on most data links today are 1500 bytes or more, the probability that such datagrams will need to get fragmented, even if they get labeled, is very small.
一般的には、パスMTUディスカバリを実装していないIPv4ホストは、[4]これ以上の576以上のバイトが含まれているIPデータグラムを送信します。ほとんどのデータリンク上で使用されているのMTU今日が1500バイト以上あるので、そのようなデータグラムは、彼らが標識を取得しても、断片化された取得する必要があります確率は、非常に小さいです。
Some hosts that do not implement Path MTU Discovery [4] will generate IP datagrams containing 1500 bytes, as long as the IP Source and Destination addresses are on the same subnet. These datagrams will not pass through routers, and hence will not get fragmented.
パスMTUディスカバリを実装していない一部のホストは、[4]のように長いIP送信元アドレスと宛先アドレスが同じサブネット上にあるように、1500バイトを含むIPデータグラムを生成します。これらのデータグラムは、ルータを通過しない、したがって、断片化され得ることはありません。
Unfortunately, some hosts will generate IP datagrams containing 1500 bytes, as long the IP Source and Destination addresses have the same classful network number. This is the one case in which there is any risk of fragmentation when such datagrams get labeled. (Even so, fragmentation is not likely unless the packet must traverse an ethernet of some sort between the time it first gets labeled and the time it gets unlabeled.)
残念ながら、いくつかのホストは限りIP送信元と送信先のアドレスが同じクラスフルネットワーク番号を持って、1500バイトを含むIPデータグラムを生成します。これは、データグラムが標識を取得断片化のリスクがあるケースは、この1つです。 （パケットは、それが最初に標識します時、それは非標識取得した時間との間のある種のイーサネットを横切らなければならない限り、そうであっても、断片化はにくいです。）
This document specifies procedures which allow one to configure the network so that large datagrams from hosts which do not implement Path MTU Discovery get fragmented just once, when they are first labeled. These procedures make it possible (assuming suitable configuration) to avoid any need to fragment packets which have already been labeled.
この文書では、それらが最初にラベル付けされたときに1が、パスMTUディスカバリを実装していないホストからの大規模なデータグラムを一度だけ断片化を受けるようにネットワークを構成できるようにする手順を指定します。これらの手順は、すでにラベル付けされたパケットを断片化する必要性を回避するために、（適切な構成を想定して）ことを可能にします。
With respect to a particular data link, we can use the following terms:
特定のデータリンクに関しては、我々は次の用語を使用することができます。
- Frame Payload:
- フレームペイロード：
The contents of a data link frame, excluding any data link layer headers or trailers (e.g., MAC headers, LLC headers, 802.1Q headers, PPP header, frame check sequences, etc.).
任意のデータリンク層ヘッダやトレーラを除くデータ・リンク・フレームの内容（例えば、MACヘッダ、LLCヘッダ、802.1Qヘッダー、PPPヘッダ、フレームチェックシーケンス、等）。
When a frame is carrying an unlabeled IP datagram, the Frame Payload is just the IP datagram itself. When a frame is carrying a labeled IP datagram, the Frame Payload consists of the label stack entries and the IP datagram.
フレームは非標識IPデータグラムを運んでいるときに、フレームペイロードは、単にIPデータグラムそのものです。フレームは、ラベルされたIPデータグラムを運んでいるときに、フレームペイロードは、ラベルスタックエントリおよびIPデータグラムで構成されています。
- Conventional Maximum Frame Payload Size:
- 従来の最大フレームペイロードサイズ：
The maximum Frame Payload size allowed by data link standards. For example, the Conventional Maximum Frame Payload Size for ethernet is 1500 bytes.
データリンク規格によって許容される最大フレームペイロードサイズ。たとえば、イーサネットのための従来の最大フレームペイロードサイズは1500バイトです。
- True Maximum Frame Payload Size:
- 真の最大フレームペイロードサイズ：
The maximum size frame payload which can be sent and received properly by the interface hardware attached to the data link.
データ・リンクに取り付けられたインターフェース・ハードウェアによって適切に送受信することができる最大サイズのフレームペイロード。
On ethernet and 802.3 networks, it is believed that the True Maximum Frame Payload Size is 4-8 bytes larger than the Conventional Maximum Frame Payload Size (as long as neither an 802.1Q header nor an 802.1p header is present, and as long as neither can be added by a switch or bridge while a packet is in transit to its next hop). For example, it is believed that most ethernet equipment could correctly send and receive packets carrying a payload of 1504 or perhaps even 1508 bytes, at least, as long as the ethernet header does not have an 802.1Q or 802.1p field.
イーサネットおよび802.3ネットワーク上で、あれば、802.1Qヘッダーも802.1Pヘッダーのいずれも存在しているように（従来最大フレームペイロードサイズよりも大きいバイト、そして限り、真の最大フレームペイロードサイズが4-8であると考えられていますパケットが次のホップに通過している間もない）スイッチまたはブリッジによって追加することができません。例えば、ほとんどのイーサネット機器が正常であれば、イーサネットヘッダが802.1Qまたは802.1pフィールドを持たないように、少なくとも1504又はおそらく1508バイトのペイロードを運ぶパケットを送信および受信することができると考えられています。
On PPP links, the True Maximum Frame Payload Size may be virtually unbounded.
PPPリンクでは、真の最大フレームペイロードサイズは、事実上無制限のかもしれません。
- Effective Maximum Frame Payload Size for Labeled Packets:
- ラベル付きパケットのための効果的な最大フレームペイロードサイズ：
This is either the Conventional Maximum Frame Payload Size or the True Maximum Frame Payload Size, depending on the capabilities of the equipment on the data link and the size of the data link header being used.
これは、データリンクと使用されているデータ・リンク・ヘッダのサイズに機器の機能に応じて、従来の最大フレームペイロードサイズ又は真の最大フレームペイロードサイズのいずれかです。
- Initially Labeled IP Datagram:
- 当初標識IPデータグラム：
Suppose that an unlabeled IP datagram is received at a particular LSR, and that the the LSR pushes on a label before forwarding the datagram. Such a datagram will be called an Initially Labeled IP Datagram at that LSR.
非標識IPデータグラムは、特定のLSRで受信されていること、およびLSRは、データグラムを転送する前に、ラベルにプッシュすることとします。このようなデータグラムは、そのLSRで最初標識IPデータグラムと呼ばれます。
- Previously Labeled IP Datagram:
- 以前は標識IPデータグラム：
An IP datagram which had already been labeled before it was received by a particular LSR.
それは、特定のLSRによって受信された前に、すでにラベル付けされていたIPデータグラム。
Every LSR which is capable of
することができ、すべてのLSR
a) receiving an unlabeled IP datagram, b) adding a label stack to the datagram, and c) forwarding the resulting labeled packet,
A）、B）データグラムにラベルスタックを追加、非標識IPデータグラムを受信し、そしてc）得られた標識されたパケットを転送し、
SHOULD support a configuration parameter known as the "Maximum Initially Labeled IP Datagram Size", which can be set to a non-negative value.
非負の値に設定することができます「最大当初標識IPデータグラムサイズ」、として知られている構成パラメータをサポートする必要があります。
If this configuration parameter is set to zero, it has no effect.
この構成パラメータがゼロに設定されている場合、それは効果がありません。
If it is set to a positive value, it is used in the following way. If:
それは正の値に設定されている場合は、次のように使用されています。もし：
a) an unlabeled IP datagram is received, and b) that datagram does not have the DF bit set in its IP header, and c) that datagram needs to be labeled before being forwarded, and d) the size of the datagram (before labeling) exceeds the value of the parameter, then a) the datagram must be broken into fragments, each of whose size is no greater than the value of the parameter, and
A）非標識IPデータグラムが受信されると、b）DFを有していないことを、データグラムは、そのIPヘッダに設定ビット、およびc）そのデータグラムは、標識の前に（）データグラムのサイズを転送される前に標識する必要があり、およびd ）、パラメータの値を超えるデータグラムが断片に分割されている必要があり、次いでa）に示すように、そのサイズの各パラメータの値以下であり、かつ
b) each fragment must be labeled and then forwarded.
B）各断片を標識した後に転送されなければなりません。
For example, if this configuration parameter is set to a value of 1488, then any unlabeled IP datagram containing more than 1488 bytes will be fragmented before being labeled. Each fragment will be capable of being carried on a 1500-byte data link, without further fragmentation, even if as many as three labels are pushed onto its label stack.
この構成パラメーターは、1488年の値に設定されている場合、例えば、その後以上1488バイトを含む任意の非標識IPデータグラムは、標識される前に断片化されるであろう。各フラグメントは、最大3つのラベルは、そのラベルスタックにプッシュされていても、さらに断片化することなく、1500バイトのデータ・リンク上で搬送されることが可能であろう。
In other words, setting this parameter to a non-zero value allows one to eliminate all fragmentation of Previously Labeled IP Datagrams, but it may cause some unnecessary fragmentation of Initially Labeled IP Datagrams.
言い換えれば、ゼロ以外の値にこのパラメータを設定することは、1つは、以前は標識IPデータグラムの全ての断片化を解消することができますが、それは最初標識IPデータグラムのいくつかの不要な断片化を引き起こす可能性があります。
Note that the setting of this parameter does not affect the processing of IP datagrams that have the DF bit set; hence the result of Path MTU discovery is unaffected by the setting of this parameter.
このパラメータの設定は、DFビットがセットされているIPデータグラムの処理には影響しないことに注意してください。したがって、パスMTU探索の結果は、このパラメータの設定に影響されません。
A labeled IP datagram whose size exceeds the Conventional Maximum Frame Payload Size of the data link over which it is to be forwarded MAY be considered to be "too big".
そのサイズは、それが転送されるようになる上でデータリンクの従来の最大フレームペイロードサイズを超えたラベルされたIPデータグラムは、「大きすぎる」とみなすことができます。
A labeled IP datagram whose size exceeds the True Maximum Frame Payload Size of the data link over which it is to be forwarded MUST be considered to be "too big".
そのサイズは、それが転送されるようになる上でデータリンクの真の最大フレームペイロードサイズを超えたラベルIPデータグラムは、「大きすぎる」と考えなければなりません。
A labeled IP datagram which is not "too big" MUST be transmitted without fragmentation.
「大きすぎる」ではありませんラベルされたIPデータグラムは断片化せずに送信されなければなりません。
If a labeled IPv4 datagram is "too big", and the DF bit is not set in its IP header, then the LSR MAY silently discard the datagram.
ラベル付きのIPv4データグラムが「大きすぎる」であり、DFビットがそのIPヘッダに設定されていない場合、LSRは黙っデータグラムを捨てるかもしれ。
Note that discarding such datagrams is a sensible procedure only if the "Maximum Initially Labeled IP Datagram Size" is set to a non-zero value in every LSR in the network which is capable of adding a label stack to an unlabeled IP datagram.
そのようなデータグラムを廃棄する「最大最初に標識されたIPデータグラムのサイズは、」非標識IPデータグラムにラベルスタックを追加することが可能なネットワーク内の各LSRにおける非ゼロ値に設定されている場合にのみ賢明な手順であることに留意されたいです。
If the LSR chooses not to discard a labeled IPv4 datagram which is too big, or if the DF bit is set in that datagram, then it MUST execute the following algorithm:
LSRが大きすぎるラベルのIPv4データグラムを破棄しないことを選択した場合、DFビットがそのデータグラムに設定されている場合、または、それは次のアルゴリズムを実行する必要があります。
2. Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries).
2. Nラベルスタック（すなわち、ラベルスタックエントリの4倍の数）のバイト数とします。
3. If the IP datagram does NOT have the "Don't Fragment" bit set in its IP header:
3. IPデータグラムは、IPヘッダに設定されたビットを「フラグメントしない」持っていない場合：
a. convert it into fragments, each of which MUST be at least N bytes less than the Effective Maximum Frame Payload Size.
A。 Nは、有効最大フレームペイロードサイズよりも小さいバイト以上でなければならないその各々の断片に変換します。
b. Prepend each fragment with the same label header that would have been on the original datagram had fragmentation not been necessary.
B。プリペンド元のデータグラムであったであろう同じラベルヘッダを有する各断片は、断片化は必要なかったです。
c. Forward the fragments
C。フラグメントを転送
4. If the IP datagram has the "Don't Fragment" bit set in its IP header:
4. IPデータグラムを持っている場合はビットがそのIPヘッダに設定されている「フラグメント不可」：
a. the datagram MUST NOT be forwarded
A。データグラムを転送してはなりません
b. Create an ICMP Destination Unreachable Message:
B。 ICMP宛先到達不能メッセージを作成します。
i. set its Code field [3] to "Fragmentation Required and DF
Set",
ii. set its Next-Hop MTU field [4] to the difference between the Effective Maximum Frame Payload Size and the value of N
II。そのネクストホップMTUフィールドを設定[4]有効最大フレームペイロードサイズとNの値との差に
c. If possible, transmit the ICMP Destination Unreachable Message to the source of the of the discarded datagram.
C。可能な場合は、廃棄されたデータグラムの源にICMP宛先到達不能メッセージを送信します。
To process a labeled IPv6 datagram which is too big, an LSR MUST execute the following algorithm:
大きすぎるラベルされたIPv6データグラムを処理するために、LSRは次のアルゴリズムを実行する必要があります。
2. Let N be the number of bytes in the label stack (i.e., 4 times the number of label stack entries).
2.ラベルスタック内のバイトの数をNうこと（すなわち、ラベルスタックエントリの4倍の数）。
3. If the IP datagram contains more than 1280 bytes (not counting the label stack entries), or if it does not contain a fragment header, then: a. Create an ICMP Packet Too Big Message, and set its Next-Hop MTU field to the difference between the Effective Maximum Frame Payload Size and the value of N
3. IPデータグラム以上1280バイト（ラベルスタックエントリをカウントしない）が含まれ、またはそれは、次に、フラグメントヘッダが含まれていない場合場合：。 ICMPパケット過大メッセージを作成し、効果的な最大フレームペイロードサイズとNの値との差にその次ホップMTUフィールドを設定
b. If possible, transmit the ICMP Packet Too Big Message to the source of the datagram.
B。可能であれば、データグラムの送信元にICMPパケットにあまりにも大きなメッセージを送信します。
c. discard the labeled IPv6 datagram.
C。ラベルされたIPv6データグラムを破棄します。
4. If the IP datagram is not larger than 1280 octets, and it contains a fragment header, then
4.次に、IPデータグラム1280オクテットより大きくない、そしてそれはフラグメントヘッダが含まれている場合
a. Convert it into fragments, each of which MUST be at least N bytes less than the Effective Maximum Frame Payload Size.
A。 Nは、効果的な最大フレームペイロードサイズよりも小さいバイト以上でなければならないそれぞれの断片に変換します。
b. Prepend each fragment with the same label header that would have been on the original datagram had fragmentation not been necessary.
B。プリペンド元のデータグラムであったであろう同じラベルヘッダを有する各断片は、断片化は必要なかったです。
c. Forward the fragments.
C。フラグメントを転送します。
Reassembly of the fragments will be done at the destination host.
フラグメントの再組み立ては、宛先ホストで実行されます。
The procedures described above for handling datagrams which have the DF bit set, but which are "too large", have an impact on the Path MTU Discovery procedures of RFC 1191 [4]. Hosts which implement these procedures will discover an MTU which is small enough to allow n labels to be pushed on the datagrams, without need for fragmentation, where n is the number of labels that actually get pushed on along the path currently in use.
DFビットが設定されているが、データグラムを処理するための上記の手順は、RFC 1191のパスMTU発見手順に影響を与え、「大きすぎる」である[4]。これらの手順を実行するホストは、n個のラベルは、nが実際に現在使用中のパスに沿って上のプッシュされますラベルの数で断片化を必要とせずに、データグラムにプッシュすることを可能にするのに十分に小さいMTUを発見するでしょう。
In other words, datagrams from hosts that use Path MTU Discovery will never need to be fragmented due to the need to put on a label header, or to add new labels to an existing label header. (Also, datagrams from hosts that use Path MTU Discovery generally have the DF bit set, and so will never get fragmented anyway.)
言い換えれば、パスMTUディスカバリを使用するホストからのデータグラムが原因ラベルヘッダーの上に置くために、または既存のラベルヘッダに新しいラベルを追加するために必要に断片化する必要はありません。 （また、パスMTUディスカバリーを使用するホストからのデータグラムは、一般的にDFビットがセットされている、ので、とにかく断片化されることはありません飽きないでしょう。）
Note that Path MTU Discovery will only work properly if, at the point where a labeled IP Datagram's fragmentation needs to occur, it is possible to cause an ICMP Destination Unreachable message to be routed to the packet's source address. See section 2.3.
標識されたIPデータグラムのフラグメンテーションが発生する必要がある時点で、パケットの送信元アドレスにルーティングされるICMP宛先到達不能メッセージを引き起こすことが可能であるならばMTUディスカバリーにのみ正常に動作しますそのパスに注意してください。セクション2.3を参照してください。
If it is not possible to forward an ICMP message from within an MPLS "tunnel" to a packet's source address, but the network configuration makes it possible for the LSR at the transmitting end of the tunnel to receive packets that must go through the tunnel, but are too large to pass through the tunnel unfragmented, then:
パケットの送信元アドレスにMPLS「トンネル」の中から、ICMPメッセージを転送することはできませんが、ネットワーク構成がトンネルを通過しなければならないパケットを受信するために、トンネルの送信端でLSRのためにそれを可能にした場合は、その後、断片化されていないトンネルを通過するには大きすぎます。
- The LSR at the transmitting end of the tunnel MUST be able to determine the MTU of the tunnel as a whole. It MAY do this by sending packets through the tunnel to the tunnel's receiving endpoint, and performing Path MTU Discovery with those packets.
- トンネルの送信端におけるLSRは、全体としてトンネルのMTUを決定できなければなりません。これは、トンネルの受信エンドポイントにトンネルを介してパケットを送信し、それらのパケットをパスMTUディスカバリを実行することにより、これを行うことができます。
- Any time the transmitting endpoint of the tunnel needs to send a packet into the tunnel, and that packet has the DF bit set, and it exceeds the tunnel MTU, the transmitting endpoint of the tunnel MUST send the ICMP Destination Unreachable message to the source, with code "Fragmentation Required and DF Set", and the Next-Hop MTU Field set as described above.
- 任意の時間は、トンネルの送信エンドポイントは、トンネルにパケットを送信する必要があり、そのパケットはDFビットが設定されている、それはトンネルMTU、ソースにICMP宛先到達不能メッセージを送信しなければならないトンネルの送信エンドポイントを超え上述したように、コード「フラグメンテーション必要とDFセット」、およびネクストホップMTUフィールドで設定されました。
The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols.
ポイントツーポイントプロトコル（PPP）[6]のポイントツーポイントリンク上でマルチプロトコルデータグラムを輸送するための標準的な方法を提供します。 PPPは、拡張可能なリンク制御プロトコルを定義し、異なるネットワーク層プロトコルを確立し、設定するためのネットワーク制御プロトコルのファミリーを提案しています。
This section defines the Network Control Protocol for establishing and configuring label Switching over PPP.
このセクションでは、PPPの上にラベルスイッチングを確立し、構成するためにNetwork Controlプロトコルを定義します。
PPP has three main components:
PPPは3つの主要なコンポーネントがあります。
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
2. Aリンク制御プロトコル（LCP）、確立、構成、およびデータリンク接続をテストします。
3. A family of Network Control Protocols for establishing and configuring different network-layer protocols.
3.異なるネットワーク層プロトコルを確立し、構成するためのNetwork Controlプロトコルのファミリーを。
In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send "MPLS Control Protocol" packets to enable the transmission of labeled packets. Once the "MPLS Control Protocol" has reached the Opened state, labeled packets can be sent over the link.
ポイントツーポイントリンクを介して通信を確立するために、PPPリンクの各端部は、第1のデータリンクを設定し、テストするためにLCPパケットを送信しなければなりません。リンクが確立され、LCPの必要に応じてオプションの施設が交渉された後、PPPは、ラベル付きパケットの伝送を可能にするために、「MPLS制御プロトコル」パケットを送信する必要があります。 「MPLS制御プロトコルは、」オープン状態に達した後は、ラベル付きパケットはリンクを介して送信することができます。
The link will remain configured for communications until explicit LCP or MPLS Control Protocol packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention).
（非アクティブタイマーの期限が切れるか、ネットワーク管理者の介入）明示的なLCPまたはMPLS制御プロトコルのパケットがダウンリンクを閉じるまで、または何らかの外部イベントが発生するまで、リンクは通信用に設定されたままになります。
The MPLS Control Protocol (MPLSCP) is responsible for enabling and disabling the use of label switching on a PPP link. It uses the same packet exchange mechanism as the Link Control Protocol (LCP). MPLSCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. MPLSCP packets received before this phase is reached should be silently discarded.
MPLS制御プロトコル（MPLSCP）は、PPPリンク上のラベルスイッチングの使用を有効化および無効化する責任があります。これは、リンク制御プロトコル（LCP）と同じパケット交換メカニズムを使用しています。 PPPはネットワーク層プロトコルフェーズに達するまでMPLSCPパケットが交換されない場合があります。静かに捨てられるべきです。この段階に到達する前にMPLSCPパケットを受信しました。
The MPLS Control Protocol is exactly the same as the Link Control Protocol [6] with the following exceptions:
MPLS制御プロトコルは、以下の例外を除き、リンク制御プロトコル[6]とまったく同じです。
The packet may utilize any modifications to the basic frame format which have been negotiated during the Link Establishment phase.
パケットは、リンク確立フェーズ中にネゴシエートされた基本的なフレームフォーマットの変更を利用することができます。
Exactly one MPLSCP packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 8281 (MPLS).
正確に一つMPLSCPパケットは、PPPプロトコルフィールドがタイプヘクス8281（MPLS）を示すPPP情報フィールド内にカプセル化されています。
Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects.
唯一のコード1〜7（設定要求、設定肯定応答、通信設定否定応答、構成拒否、終了要求、終了-ACKおよびコード拒否）が使用されます。他のコードは認識されていないとして扱われるべきとコード・リジェクツを生じるはずです。
MPLSCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time.
PPPはネットワーク層プロトコルフェーズに達するまでMPLSCPパケットが交換されない場合があります。実装は、通信設定肯定応答または他の応答を待ってタイムアウトする前に終了する認証とリンク品質の決意を待つために準備する必要があります。実装がユーザ介入や時間の設定可能な量の後にあきらめることが示唆されます。
None.
無し。
Before any labeled packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the MPLS Control Protocol must reach the Opened state.
任意のラベル付きパケットを伝達することができる前に、PPPはネットワーク層プロトコルフェーズに達しなければならない、とMPLS制御プロトコルはOpened状態に達しなければなりません。
Exactly one labeled packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates either type hex 0281 (MPLS Unicast) or type hex 0283 (MPLS Multicast). The maximum length of a labeled packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP encapsulated packet.
正確に1つの標識されたパケットは、PPPプロトコルフィールドがタイプヘクス0281（MPLSユニキャスト）またはタイプヘクス0283（MPLSマルチキャスト）のいずれかを示し、PPP情報フィールド内にカプセル化されています。 PPPリンクを介して送信された標識されたパケットの最大長は、PPPカプセル化されたパケットの情報フィールドの最大長さと同じです。
The format of the Information field itself is as defined in section 2.
セクション2で定義されている情報フィールド自体の形式です。
Note that two codepoints are defined for labeled packets; one for multicast and one for unicast. Once the MPLSCP has reached the Opened state, both label switched multicasts and label switched unicasts can be sent over the PPP link.
2つのコードポイントは、ラベル付きパケット用に定義されていることに留意されたいです。マルチキャストとユニキャストのための1つに1つ。 MPLSCPが開いた状態に達した後は、両方のラベルは、マルチキャストを切り替えてラベルがユニキャストは、PPPリンクを介して送信することができます切り替えます。
There are no configuration options.
構成オプションはありません。
Exactly one labeled packet is carried in each frame.
正確に1つの標識されたパケットは、各フレームで運ばれます。
The label stack entries immediately precede the network layer header, and follow any data link layer headers, including, e.g., any 802.1Q headers that may exist.
ラベルスタックエントリは直ちにネットワーク層ヘッダの前に、そして存在することができ、例えば、任意の802.1Qヘッダーを含む任意のデータリンク層のヘッダに従います。
The ethertype value 8847 hex is used to indicate that a frame is carrying an MPLS unicast packet.
イーサタイプ値8847ヘクスは、フレームがMPLSユニキャストパケットを運んでいることを示すために使用されます。
The ethertype value 8848 hex is used to indicate that a frame is carrying an MPLS multicast packet.
イーサタイプ値8848ヘクスは、フレームがMPLSマルチキャストパケットを運んでいることを示すために使用されます。
These ethertype values can be used with either the ethernet encapsulation or the 802.3 LLC/SNAP encapsulation to carry labeled packets. The procedure for choosing which of these two encapsulations to use is beyond the scope of this document.
これらのイーサタイプ値は、ラベル付きパケットを運ぶためにイーサネットカプセル化または802.3 LLC / SNAPカプセル化のいずれかで使用することができます。これら二つのカプセル化のどちらを使用することを選択するための手順は、このドキュメントの範囲を超えています。
Label values 0-15 inclusive have special meaning, as specified in this document, or as further assigned by IANA.
0-15包括ラベル値は、この文書で指定された、または、さらなるIANAによって割り当てられたとして、特別な意味を持っています。
In this document, label values 0-3 are specified in section 2.1.
このドキュメントでは、ラベル値0-3はセクション2.1で指定されています。
Label values 4-15 may be assigned by IANA, based on IETF Consensus.
ラベル値4-15はIETF合意に基づいて、IANAによって割り当てられることができます。
The MPLS encapsulation that is specified herein does not raise any security issues that are not already present in either the MPLS architecture [1] or in the architecture of the network layer protocol contained within the encapsulation.
MPLSアーキテクチャのいずれかに既に存在していない任意のセキュリティ上の問題を提起する[1]またはカプセル内に含まれるネットワーク層プロトコルのアーキテクチャではない、本明細書で指定されるMPLSカプセル化。
There are two security considerations inherited from the MPLS architecture which may be pointed out here:
ここで指摘されるMPLSアーキテクチャから継承された2つのセキュリティ上の考慮事項があります。
- Some routers may implement security procedures which depend on the network layer header being in a fixed place relative to the data link layer header. These procedures will not work when the MPLS encapsulation is used, because that encapsulation is of a variable size.
- いくつかのルータは、データリンク層ヘッダに対して一定の場所にあるネットワーク層ヘッダに依存するセキュリティ手順を実施することができます。 MPLSカプセル化が使用されたときにカプセル化が可変サイズであるため、これらの手順は、動作しません。
- An MPLS label has its meaning by virtue of an agreement between the LSR that puts the label in the label stack (the "label writer"), and the LSR that interprets that label (the "label reader"). However, the label stack does not provide any means of determining who the label writer was for any particular label. If labeled packets are accepted from untrusted sources, the result may be that packets are routed in an illegitimate manner.
- MPLSラベルは、そのラベル（「ラベルリーダ」）を解釈ラベルスタック（「ラベルライター」）、およびLSRでラベルを置くLSR間の合意によってその意味を有します。しかし、ラベルスタックは、ラベルライターが、特定のラベルにした決定の任意の手段を提供していません。標識されたパケットは、信頼できないソースから受け入れられた場合、結果は、パケットが不正な方法でルーティングされることがあってもよいです。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
エリックC.ローゼンシスコシステムズ社250アポロドライブチェルムズフォード、MA、01824
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Dan Tappan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
ダンタッパンシスコシステムズ社250アポロドライブチェルムズフォード、MA、01824
EMail: tappan@cisco.com
メールアドレス：tappan@cisco.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
ヤコフ・レックタージュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Guy Fedorkow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
ガイFedorkowシスコシステムズ社250アポロドライブチェルムズフォード、MA、01824
EMail: fedorkow@cisco.com
メールアドレス：fedorkow@cisco.com
Dino Farinacci Procket Networks, Inc. 3910 Freedom Circle, Ste. 102A Santa Clara, CA 95054
ディノファリナッチProcketネットワークス株式会社3910自由サークル、マリー。 102Aサンタクララ、CA 95054
EMail: dino@procket.com
メールアドレス：dino@procket.com
Tony Li Procket Networks, Inc. 3910 Freedom Circle, Ste. 102A Santa Clara, CA 95054
トニー・李Procketネットワークス株式会社3910自由サークル、マリー。 102Aサンタクララ、CA 95054
EMail: tli@procket.com
メールアドレス：tli@procket.com
Alex Conta TranSwitch Corporation 3 Enterprise Drive Shelton, CT, 06484
アレックス・コンタTranSwitch社株式会社3エンタープライズ・ドライブシェルトン、CT、06484
EMail: aconta@txc.com
メールアドレス：aconta@txc.com
[1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[1]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[3]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[4] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[4]モーグル、J.およびS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[5]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[6]シンプソン、W.、エディタ、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[7] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, December 1995.
[7]コンタ、A.、およびS.デアリングを、 "インターネット制御メッセージプロトコル（ICMPv6の）インターネットプロトコルバージョン6（IPv6）の仕様は、"、RFC 1885、1995年12月。
[8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[8]マッキャン、J.、デアリング、S.とJ.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、1996年8月。
[9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. and G. Swallow, "MPLS Using LDP and ATM VC Switching", RFC 3035, January 2001.
[9]デイビー、B.、ローレンス、J.、McCloghrie、K.、Rekhter、Y.、ローゼン、E.およびG.ツバメ、RFC 3035、2001年1月 "LDPおよびATM VCスイッチングを使用したMPLS"。
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。