RFC3032 日本語訳
3032 MPLS Label Stack Encoding. E. Rosen, D. Tappan, G. Fedorkow, Y.Rekhter, D. Farinacci, T. Li, A. Conta. January 2001. (Format: TXT=48314 bytes) (Updated by RFC3443, RFC4182, RFC5332, RFC3270, RFC5129) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループE.ローゼン要求をネットワークでつないでください: 3032年のD.タッパンカテゴリ: 規格はTranSwitch社の2001年1月にG.FedorkowシスコシステムズInc.Y.Rekhter杜松ネットワークD.ファリナッチT.李ProcketネットワークInc.A.コンタを追跡します。
MPLS Label Stack Encoding
MPLSラベルスタックコード化
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
「マルチプロトコルLabel Switching(MPLS)」[1]は「ラベルスタック」に従ってネットワーク層パケットを増大させるための手順をセットに要求します、その結果、それらを「ラベルされたパケット」に変えます。 ルータのどのサポートMPLSが「ラベル切り換えルータ」として知られているか、そして、「LSRs。」 特定のデータ・リンクの上でラベルされたパケットを伝えるために、LSRはラベルスタックとネットワーク層パケットを考えて、ラベルされたパケットを作り出すコード化のテクニックをサポートしなければなりません。 Pointからポイントへのプロトコル(PPP)データ・リンクの上でラベルされたパケットを伝えるのにLSRによって使用されるように、このドキュメントはコード化を指定します、LANデータ・リンクと、ことによるとまた、他のデータ・リンクの上で。 いくつかのデータ・リンクの上では、スタックの先端のラベルは異なった方法でコード化されるかもしれませんが、ラベルスタックの残りをコード化するのにここで説明されたテクニックを使用しなければなりません。 また、このドキュメントはラベルスタックコード化の多岐を処理するための規則と手順を指定します。
Rosen, et al. Standards Track [Page 1] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[1ページ]RFC3032MPLSラベルスタック
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
1つの序論… 2 1.1 要件の仕様… ラベルが積み重ねる3 2… 3 ラベルをコード化する2.1が積み重ねられます… 3 ネットワーク層を決定する2.2が議定書を作ります… 5 2.3 ラベルされたIPパケットへのメッセージをICMPに生成します… 6 2.3 .1 トランジット経路ドメインを通ってトンネルを堀ります… 7 2.3 .2 公共のバックボーンを通してプライベート・アドレスにトンネルを堀ります。 7 2.4 ライブ分野に時間を処理します… 8 2.4 .1の定義… 8 2.4 .2プロトコル独立者は統治されます… 8 2.4 .3IP-扶養家族は判決を下します… 9 2.4 .4 異なったカプセル化の間で翻訳します… 9 3断片化と経路MTU発見… 10 3.1用語… 11 3.2最大は初めは、IPデータグラムをサイズとラベルしました… 12 3.3 Labeled IPデータグラムはいつToo Bigですか? ................. 13 3.4 Too Bigである処理Labeled IPv4データグラム… 13 3.5 Too Bigである処理Labeled IPv6データグラム… 14 Path MTUディスカバリーに関する3.6の含意… 15 4 輸送はpppの上にパケットをラベルしました… 16 4.1序論… 16 4.2 pppネットワーク制御はMPLSのために議定書を作ります… 17 4.3 発信はパケットをラベルしました… 18 4.4 LANメディアの上でラベルされたパケットを輸送するプロトコル設定オプション. 18 5と切換制御をラベルしてください… 18 6 IANA問題… 19 7 セキュリティ問題… 19 8知的所有権… 19 9人の作者のアドレス… 20 10の参照箇所… 22 11の完全な著作権宣言文… 23
1. Introduction
1. 序論
"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.
「マルチプロトコルLabel Switching(MPLS)」[1]は「ラベルスタック」に従ってネットワーク層パケットを増大させるための手順をセットに要求します、その結果、それらを「ラベルされたパケット」に変えます。 ルータのどのサポートMPLSが「ラベル切り換えルータ」として知られているか、そして、「LSRs。」 特定のデータ・リンクの上でラベルされたパケットを伝えるために、LSRはラベルスタックとネットワーク層パケットを考えて、ラベルされたパケットを作り出すコード化のテクニックをサポートしなければなりません。
Rosen, et al. Standards Track [Page 2] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[2ページ]RFC3032MPLSラベルスタック
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スイッチなどの)の上に実装されるLSRsは、ラベルスタックの1かトップ2のエントリーをコード化するのに異なったコード化のテクニックを使用するかもしれません。 しかしながら、ラベルスタックに追加エントリーがあると、追加ラベルスタックエントリーに本書では説明されたコード化のテクニックを使用しなければなりません。
1.1. Specification of Requirements
1.1. 要件の仕様
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
2. The Label Stack
2. ラベルスタック
2.1. Encoding the Label Stack
2.1. ラベルスタックをコード化します。
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
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+++++++++++++++++++++++++++++++++ラベル| ラベル| Exp|S| TTL| スタック+++++++++++++++++++++++++++++++++エントリー
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time to Live, 8 bits
以下をラベルしてください。 Value、20ビットをExpとラベルしてください: 実験的なUse、3ビットS: Stack、1ビットのTTLの下部: Liveへの時間、8ビット
Figure 1
図1
Rosen, et al. Standards Track [Page 3] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[3ページ]RFC3032MPLSラベルスタック
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.
ラベルスタックエントリーはデータ・リンク層ヘッダーのAFTERに現れて、唯一のBEFOREはあらゆるネットワーク層ヘッダーです。 ラベルスタックの先端は最も早くパケットに現れます、そして、下部は最新に見えます。 ネットワーク層パケットはすぐに、Sビットを設定するラベルスタックエントリーに続きます。
Each label stack entry is broken down into the following fields:
それぞれのラベルスタックエントリーは以下の分野へ砕けています:
1. Bottom of Stack (S)
1. スタックの下部(S)
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つに設定されます、そして、(すなわち、スタックの下部に)他のすべてのラベルのためのゼロはエントリーを積み重ねます。
2. Time to Live (TTL)
2. 生きる時間(TTL)
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で説明されます。
3. Experimental Use
3. 実験用
This three-bit field is reserved for experimental use.
この3ビットの分野は実験用のために予約されます。
4. Label Value
4. ラベル値
This 20-bit field carries the actual value of the Label.
この20ビットの分野はLabelの実価を運びます。
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.
また、次のホップとラベルスタック操作を学ぶことに加えて、発信データリンクカプセル化、および適切にパケットを進めるのに必要であることによると他の情報を学ぶかもしれません。
Rosen, et al. Standards Track [Page 4] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[4ページ]RFC3032MPLSラベルスタック
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.
i。 0の値は「IPv4の明白なヌルラベル」を表します。 このラベル値は単にラベルの下の方スタックで法的です。 それはラベルスタックが飛び出さなければならなくて、次に、パケットの推進を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の値は「ルータ警戒ラベル」を表します。 下部を除いて、このラベル値はラベルスタックでどこでも法的です。 容認されたパケットがラベルスタックの先端にこのラベル値を保管しているとき、それは処理のためのローカルのソフトウェア・モジュールに提供されます。 パケットの実際の推進はスタックでそれの下でラベルで決定します。 しかしながら、さらにパケットを進めるなら、推進の前にラベルスタックにRouter Alert Labelを押し戻すべきです。 このラベルの使用は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の明白なヌルラベル」を表します。 このラベル値は単にラベルの下の方スタックで法的です。 それはラベルスタックが飛び出さなければならなくて、次に、パケットの推進を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の値は「内在しているヌルラベル」を表します。 これはLSRが割り当てて、分配するかもしれませんが、実際にカプセル化では決して現れないラベルです。 そうでなければ、LSRがスタックの先端でラベルを新しいラベルに取り替えるでしょうが、新しいラベルが「暗黙のヌル」であるときに、LSRは交換することの代わりにスタックを飛び出させるでしょう。 この値がカプセル化では決して現れないかもしれませんが、Label Distributionプロトコルで指定されるのが必要であるので、値は予約されています。
v. Values 4-15 are reserved.
v。 値4-15は予約されています。
2.2. Determining the Network Layer Protocol
2.2. ネットワーク層プロトコルを決定します。
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
最後のラベルがパケットのラベルスタックから飛び出すとき(空にされているスタックをもたらして)、パケットのさらなる処理はパケットのネットワーク層ヘッダーに基づいています。 したがって、スタックで最後のラベルを飛び出させるLSRはパケットのネットワーク層プロトコルを特定できなければなりません。 しかしながら、ラベルスタックは明らかにネットワーク層を特定するどんな分野も含んでいません。
Rosen, et al. Standards Track [Page 5] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[5ページ]RFC3032MPLSラベルスタック
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.
議定書を作ってください。 これは、ネットワーク層プロトコルのアイデンティティがスタックの下部から飛び出すラベルの値から推論可能であるに違いないことを意味します、ことによるとネットワーク層ヘッダー自体のコンテンツと共に。
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を超えています)、ネットワーク層プロトコルを特定できないか、またはエラー条件を扱うためのどんな指定されたプロトコル依存する規則もなければ、静かにパケットを捨てなければなりません。
2.3. Generating ICMP Messages for Labeled IP Packets
2.3. ラベルされたIPパケットへのメッセージをICMPに生成します。
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パケットの源にそのパケットを送らせることができるように、2つの状態が成立しなければなりません:
1. it must be possible for that LSR to determine that a particular
labeled packet is an IP packet;
1. そのLSRが、特定のラベルされたパケットがIPパケットであることを決定するのは、可能であるに違いありません。
2. it must be possible for that LSR to route to the packet's IP
source address.
2. そのLSRがパケットのIPソースアドレスに発送するのにおいてそれは可能であるに違いありません。
Rosen, et al. Standards Track [Page 6] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[6ページ]RFC3032MPLSラベルスタック
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.
セクション2.2で状態1について議論します。 以下の2つの小区分が状態2について議論します。 しかしながら、状態2が全く成立しないいくつかの場合があるでしょう、そして、これらの場合では、ICMPメッセージを生成するのは可能でないでしょう。
2.3.1. Tunneling through a Transit Routing Domain
2.3.1. トランジット経路ドメインを通ってトンネルを堀ること。
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.
1つがトランジット経路ドメインを通って外部経路がドメインの内部のルータに漏らされない「トンネルを堀ること」にMPLSを使用していると仮定してください。 例えば、内部のルータは、実行しているOSPFであるかもしれなく、そのOSPFドメインの中で目的地に達する方法を知っているだけであるかもしれません。 ドメインは数個のAutonomous System Border Routers(ASBRs)を含むかもしれません。(Autonomous System Border RoutersはBGPについて互いに話します)。 しかしながら、この例では、BGPからのルートはOSPFに分配されません、そして、ASBRsでないLSRsは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.
1つのソリューションはASBRsの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.
このソリューションはグローバルにユニークなアドレスを持っているパケット、およびすべてのASBRsが完全なルーティング情報を持っているネットワークで働いているだけです。 次の小区分はこれらの状態が成立しないと働いているソリューションについて説明します。
2.3.2. Tunneling Private Addresses through a Public Backbone
2.3.2. 公共のバックボーンを通してプライベート・アドレスにトンネルを堀ります。
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
この環境で、1つは、ICMPメッセージをパケットの源に送るためにオリジナルのパケットからICMPメッセージまでラベルスタックをコピーして、次に、ICMPメッセージとスイッチをラベルできます。 これはそうするでしょう。
Rosen, et al. Standards Track [Page 7] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[7ページ]RFC3032MPLSラベルスタック
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.
ソースよりむしろオリジナルのパケットの目的地の向きに続くメッセージを引き起こしてください。 メッセージがあて先ホストまでのいっぱいに切り換えられたラベルでないなら、終わるでしょう、ラベルされていません、メッセージがそのポイントで適切な方向に送られるオリジナルのパケットについてソースにおいてルートへのその方法を知っているルータで。
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.
このテクニックがICMPメッセージが「超えられていた時間」メッセージかaであるなら非常に役に立つ場合がある、「目的地Unreachable、必要である断片化とDFが」 メッセージを設定するので。
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.
また、ICMPメッセージがパケットのTTL満了がルーティング輪の存在のためであるならこのテクニックが使用されているなら、輪にされるかもしれないことに注意してください。 ICMPメッセージを受け取ることの結果、ICMPメッセージを決して送らないで、多くの実装がICMPメッセージを生成することができるレートを阻止するので、これが問題を設定しないと予想されます。
2.4. Processing the Time to Live Field
2.4. ライブ分野に時間を処理します。
2.4.1. Definitions
2.4.1. 定義
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、bより少ない1つ) ゼロ。
2.4.2. Protocol-independent rules
2.4.2. プロトコルから独立している規則
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歳であるなら、さらにラベルされたパケットを進めてはいけません。 または、ラベルスタックは全部はぎ取られないかもしれません。そして、ラベルされていないパケットとして進められたパケット。 ネットワークにおけるパケットの寿命が期限が切れたと考えられます。
Rosen, et al. Standards Track [Page 8] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[8ページ]RFC3032MPLSラベルスタック
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分野の値への意味が全くありません。
2.4.3. IP-dependent rules
2.4.3. IP依存する規則
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分野SHOULD BEの値は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.
状況がネットワーク管理がMPLSドメインを横断するのに従ってIPv4 TTLを1つ減少させるのを好むところにあるかもしれないと認められます、LSPホップの数に従ってドメインの中でIPv4 TTLを減少させることの代わりに。
2.4.4. Translating Between Different Encapsulations
2.4.4. 異なったカプセル化の間で翻訳します。
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処理は上で説明されるように続きます。
Rosen, et al. Standards Track [Page 9] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[9ページ]RFC3032MPLSラベルスタック
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インタフェース。
3. Fragmentation and Path MTU Discovery
3. 断片化と経路MTU発見
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.
このセクションは「大き過ぎる」パケットとラベルされた処理のための規則を指定します。 特に、Path 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.
一般に、道具Path MTUディスカバリー[4]ではなく、そうするIPv4ホストが576バイト未満を含むIPデータグラムを送ります。 今日のほとんどのデータ・リンクで使用中のMTUsが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.
Path MTUディスカバリー[4]を実行しない何人かのホストが1500バイトを含むIPデータグラムを発生させるでしょう、IP SourceとDestinationアドレスが同じサブネットにある限り。 これらのデータグラムは、ルータを通り抜けないで、またしたがって、断片化されないでしょう。
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,
残念ながら、何人かのホストが1500同じくらいバイトと、同じくらい長い間IP Sourceを含むIPデータグラムを発生させるでしょう、そして、Destinationアドレスには、同じclassfulネットワーク・ナンバーがあります。 これはそのようなデータグラムがラベルされるとき断片化のどんなリスクもある1つのそうです。 (たとえそうだとしても
Rosen, et al. Standards Track [Page 10] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[10ページ]RFC3032MPLSラベルスタック
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.)
パケットがそれが最初にラベルされる時、それがラベルされていなくなる時の間である種のイーサネットを横断してはいけないなら、断片化はありそうではありません。)
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つがネットワークを構成できる手順を指定するので、ホストからのPath MTUディスカバリーを実行しない大きいデータグラムが一度だけ断片化されます、彼らが最初にラベルされるとき。 これらの手順で、既にラベルされたパケットを断片化するどんな必要性も避けるのは可能に(適当な構成を仮定します)なります。
3.1. Terminology
3.1. 用語
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データグラムを運ぶとき、Frame有効搭載量はただIPデータグラム自体です。 フレームがラベルされたIPデータグラムを運ぶとき、Frame有効搭載量はラベルスタックエントリーと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.
有効搭載量サイズがデータで許容した最大のFrameは規格をリンクします。 例えば、イーサネットのためのConventional Maximum Frame有効搭載量Sizeは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のネットワークでは、True Maximum Frame有効搭載量SizeがConventional Maximum Frame有効搭載量Sizeより何バイトも大きい4-8(どちらも同じくらい現在であって、同じくらい長いことができませんが、802.1Qヘッダーも802.1pヘッダーもそうでない限り)であると信じられています。 例えば、ほとんどのイーサネット設備が正しく1504年のペイロードか恐らく1508バイトさえ運ぶパケットを送って、受けるかもしれないと少なくとも信じられています、イーサネットヘッダーに802.1Qか802.1p分野がない限り。
Rosen, et al. Standards Track [Page 11] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[11ページ]RFC3032MPLSラベルスタック
On PPP links, the True Maximum Frame Payload Size may be
virtually unbounded.
PPPリンクでは、True Maximum Frame有効搭載量Sizeは実際には限りないかもしれません。
- 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.
これは、Conventional Maximum Frame有効搭載量SizeかTrue Maximum Frame有効搭載量Sizeのどちらかです、データ・リンクの上の設備の能力と使用されているデータ・リンクヘッダーのサイズによって。
- 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.
特定のLSRにラベルされていないIPデータグラムを受け取って、データグラムを進める前にLSRがラベルを押すと仮定してください。 そのようなデータグラムはそのLSRにInitially Labeled IPデータグラムと呼ばれるでしょう。
- Previously Labeled IP Datagram:
- 以前にラベルされたIPデータグラム:
An IP datagram which had already been labeled before it was
received by a particular LSR.
それの前に既にラベルされたIPデータグラムは特定のLSRによって受け取られました。
3.2. Maximum Initially Labeled IP Datagram Size
3.2. 初めはラベルされた最大の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) 結果になることを進めながらラベルされていないIPデータグラム、ラベルスタックをデータグラムに加えるb)、およびc)を受けると、パケットはラベルされました。
SHOULD support a configuration parameter known as the "Maximum Initially Labeled IP Datagram Size", which can be set to a non- negative value.
SHOULDは非負の数に設定できる「初めはラベルされた最大の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データグラムが受け取られていて、IPヘッダーにb) そのデータグラムでDFビットを設定しないで、進める前にc) そのデータグラムが、ラベルされる必要があって、d) データグラム(ラベリングの前の)のサイズがパラメタの値を超えて、次に、断片をa) データグラムに細かく分けなければならない。(サイズのそれぞれが断片のためのパラメタの、より値以下です)。
Rosen, et al. Standards Track [Page 12] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[12ページ]RFC3032MPLSラベルスタック
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データグラムも断片化されるでしょう。 それぞれの断片は1500年のバイトのデータ・リンクの上で運ぶことができるでしょう、さらなる断片化なしで、最大3個のラベルがラベルスタックに押されても。
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つは非ゼロ値にこのパラメタを設定するのにPreviously Labeled IPデータグラムのすべての断片化を排除できますが、それはInitially Labeled 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データグラムの処理に影響しないことに注意してください。 したがって、Path MTU発見の結果はこのパラメタの設定のそばで影響を受けないです。
3.3. When are Labeled IP Datagrams Too Big?
3.3. Labeled IPデータグラムはいつToo Bigですか?
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".
サイズがそれが送られることになっているデータ・リンクのConventional Maximum Frame有効搭載量Sizeを超えているラベルされた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".
「大き過ぎる」とサイズがそれが送られることになっているデータ・リンクのTrue Maximum Frame有効搭載量Sizeを超えているラベルされたIPデータグラムを考えなければなりません。
A labeled IP datagram which is not "too big" MUST be transmitted without fragmentation.
断片化なしで「大き過ぎない」ラベルされたIPデータグラムを送らなければなりません。
3.4. Processing Labeled IPv4 Datagrams which are Too Big
3.4. Too Bigである処理Labeled IPv4データグラム
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 MAYは静かにデータグラムを捨てます。
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ビットがそのデータグラムに設定されるなら、以下のアルゴリズムを実行しなければなりません:
1. Strip off the label stack entries to obtain the IP datagram.
1. ラベルスタックエントリーを全部はぎ取って、IPデータグラムを入手してください。
Rosen, et al. Standards Track [Page 13] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[13ページ]RFC3032MPLSラベルスタック
2. Let N be the number of bytes in the label stack (i.e, 4 times
the number of label stack entries).
2. ラベルスタック(i.e、数の4倍のラベルスタックエントリー)でNがバイト数であることをさせてください。
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. それを断片に変換してください。それはそれぞれ少なくともEffective Maximum Frame有効搭載量Sizeより何バイトもそれほどNであるに違いありません。
b. Prepend each fragment with the same label header that would
have been on the original datagram had fragmentation not
been necessary.
b。 Prependは断片化が必要でなかったならオリジナルのデータグラムの上にあったのと同じラベルヘッダーと共にそれぞれ断片化します。
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",
i. 「断片化が必要であり、DFはセットしたこと」にCode分野[3]を設定してください。
ii. set its Next-Hop MTU field [4] to the difference between
the Effective Maximum Frame Payload Size and the value
of N
ii Effective Maximum Frame有効搭載量SizeとNの値の違いにNext-ホップMTU分野[4]を設定してください。
c. If possible, transmit the ICMP Destination Unreachable
Message to the source of the of the discarded datagram.
c。 できれば、ICMP Destination Unreachable Messageをソースに伝えてください、捨てられたデータグラムについて。
3.5. Processing Labeled IPv6 Datagrams which are Too Big
3.5. Too Bigである処理Labeled IPv6データグラム
To process a labeled IPv6 datagram which is too big, an LSR MUST execute the following algorithm:
大き過ぎるラベルされたIPv6データグラムを処理するために、LSR MUSTは以下のアルゴリズムを実行します:
1. Strip off the label stack entries to obtain the IP datagram.
1. ラベルスタックエントリーを全部はぎ取って、IPデータグラムを入手してください。
2. Let N be the number of bytes in the label stack (i.e., 4 times
the number of label stack entries).
2. ラベルスタック(すなわち、数の4倍のラベルスタックエントリー)でNがバイト数であることをさせてください。
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:
3. IPデータグラムが1280バイト以上を含んでいるか(ラベルスタックエントリーを数えないで)、または次に、断片ヘッダーを含んでいないなら:
Rosen, et al. Standards Track [Page 14] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[14ページ]RFC3032MPLSラベルスタック
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
a。 ICMP Packet Too Big Messageを作成してください、そして、Effective Maximum Frame有効搭載量SizeとNの値の違いにNext-ホップMTU分野を設定してください。
b. If possible, transmit the ICMP Packet Too Big Message to the
source of the datagram.
b。 できれば、データグラムの源にICMP Packet Too Big Messageを伝えてください。
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。 それを断片に変換してください。それはそれぞれ少なくともEffective Maximum Frame有効搭載量Sizeより何バイトもそれほどNであるに違いありません。
b. Prepend each fragment with the same label header that would
have been on the original datagram had fragmentation not
been necessary.
b。 Prependは断片化が必要でなかったならオリジナルのデータグラムの上にあったのと同じラベルヘッダーと共にそれぞれ断片化します。
c. Forward the fragments.
c。 断片を進めてください。
Reassembly of the fragments will be done at the destination
host.
あて先ホストで断片のReassemblyをするでしょう。
3.6. Implications with respect to Path MTU Discovery
3.6. Path MTUディスカバリーに関する含意
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ビットが「大き過ぎる」取り扱いデータグラムのために上で説明された手順はRFC1191[4]のPath MTUディスカバリー手順に影響を与えます。 断片化の必要性のないnが実際に現在使用中の経路に沿って押されるラベルの数であるデータグラムに押されて、これらの手順が、十分小さいMTUが、nラベルはそれの道具を許容すると発見するホスト。
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.)
言い換えれば、Path MTUディスカバリーを使用するホストからのデータグラムは、決してラベルヘッダーを置くか、または既存のラベルヘッダーに新しいラベルを加える必要性のため断片化される必要がないでしょう。 (また、Path 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.
パケットのソースアドレスに発送されるべきICMP Destination Unreachableメッセージを引き起こすのがラベルされたIPデータグラムの断片化が起こる必要があるポイントで可能であるなら、Path MTUディスカバリーが適切に働くだけであることに注意してください。 セクション2.3を見てください。
Rosen, et al. Standards Track [Page 15] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[15ページ]RFC3032MPLSラベルスタック
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:
中からICMPメッセージを転送するのが可能でないなら、MPLSはパケットのソースアドレスに「トンネルを堀ります」が、ネットワーク・コンフィギュレーションでトンネルの送信側の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を決定できなければなりません。 それは、トンネルを通してトンネルの受信終点にパケットを送って、それらのパケットでPath 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 Destination Unreachableメッセージをソースに送らなければなりません、「断片化が必要であり、DFは設定する」コード、およびMTU Fieldが上で説明されるように設定するNext-ホップで。
4. Transporting Labeled Packets over PPP
4. pppの上にパケットとラベルされた輸送
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.
Pointからポイントへのプロトコル(PPP)[6]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 PPPは、異なったネットワーク層プロトコルを設立して、構成するために広げることができるLink Controlプロトコルを定義して、Network Controlプロトコルの家族を提案します。
This section defines the Network Control Protocol for establishing and configuring label Switching over PPP.
このセクションは、PPPの上でラベルSwitchingを設立して、構成するためにNetwork Controlプロトコルを定義します。
4.1. Introduction
4.1. 序論
PPP has three main components:
PPPには、3つの主なコンポーネントがあります:
1. A method for encapsulating multi-protocol datagrams.
1. マルチプロトコルデータグラムを要約するための方法。
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
2. データリンク接続を設立して、構成して、テストするためのLink Controlプロトコル(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リンクの各端は、最初に、構成するパケットをLCPに送って、データ・リンクをテストに送らなければなりません。 リンクが設立されて、任意の施設が必要に応じてLCPによって交渉された後に、PPPは、ラベルされたパケットのトランスミッションを可能にするために「MPLS制御プロトコル」パケットを送らなければなりません。 「MPLS制御プロトコル」がいったんOpened状態に達すると、ラベルされたパケットをリンクの上に送ることができます。
Rosen, et al. Standards Track [Page 16] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[16ページ]RFC3032MPLSラベルスタック
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 Controlプロトコルパケットがリンクを閉鎖するか、またはいくつかの外部の出来事が起こるまで(不活発タイマが期限が切れるか、または管理者介入をネットワークでつないでください)コミュニケーションのために構成されたままで残るでしょう。
4.2. A PPP Network Control Protocol for MPLS
4.2. MPLSのためのpppネットワーク制御プロトコル
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 Controlプロトコル(MPLSCP)はPPPリンクにおけるラベルの切り換えの使用を可能にして、無効にするのに原因となります。 それはLink Controlプロトコル(LCP)と同じパケット交換メカニズムを使用します。 PPPがNetwork-層のプロトコルフェーズに達するまで、MPLSCPパケットは交換されないかもしれません。 このフェーズに達する前に受け取られたMPLSCPパケットは静かに捨てられるべきです。
The MPLS Control Protocol is exactly the same as the Link Control Protocol [6] with the following exceptions:
MPLS Controlプロトコルはまさに以下の例外でLink Controlプロトコル[6]と同じです:
1. Frame Modifications
1. フレーム変更
The packet may utilize any modifications to the basic frame
format which have been negotiated during the Link Establishment
phase.
パケットは基本枠形式へのLink特権階級段階の間に交渉されているどんな変更も利用するかもしれません。
2. Data Link Layer Protocol Field
2. データリンク層プロトコル分野
Exactly one MPLSCP packet is encapsulated in the PPP
Information field, where the PPP Protocol field indicates type
hex 8281 (MPLS).
ちょうど1つのMPLSCPパケットがPPP情報分野でカプセルに入れられます。そこで、PPPプロトコル分野は、タイプが8281(MPLS)人に魔法をかけるのを示します。
3. Code field
3. コード分野
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.
Codes1だけ、通じて、7 (要求を構成する、Configure-Ack、Configure-Nak、Configure-廃棄物、Terminate-要求、Terminate- Ack、およびCode-廃棄物) 使用されます。 他のCodesは認識されていないとして扱われるべきであり、Code-廃棄物をもたらすはずです。
4. Timeouts
4. タイムアウト
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がNetwork-層のプロトコルフェーズに達するまで、MPLSCPパケットは交換されないかもしれません。 実現はAuthenticationとLink Quality Determinationが、以前タイミングが外でConfigure-Ackか他の応答を待ち終えるのを待つように準備されるべきです。 実現がユーザ介入か構成可能な時間の後にだけあきらめることが提案されます。
Rosen, et al. Standards Track [Page 17] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[17ページ]RFC3032MPLSラベルスタック
5. Configuration Option Types
5. 設定オプションタイプ
None.
なし。
4.3. Sending Labeled Packets
4.3. パケットとラベルされた発信
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はNetwork-層のプロトコルフェーズに達しなければなりません、そして、MPLS Controlプロトコルは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情報分野でカプセルに入れられます。そこで、PPPプロトコル分野は、タイプが0281(MPLS Unicast)人に魔法をかけるか、またはタイプが0283(MPLS Multicast)人に魔法をかけるのを示します。 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.
2codepointsがラベルされたパケットのために定義されることに注意してください。 マルチキャストのためのものとユニキャストのためのもの。 MPLSCPがいったんOpened状態に達すると、両方が切り換えられたユニキャストを送ることができる切り換えられたマルチキャストとラベルをPPPリンクとラベルします。
4.4. Label Switching Control Protocol Configuration Options
4.4. ラベル切換制御プロトコル設定オプション
There are no configuration options.
設定オプションが全くありません。
5. Transporting Labeled Packets over LAN Media
5. LANメディアの上にパケットとラベルされた輸送
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.
ethertype価値8847の十六進法は、フレームがMPLSユニキャストパケットを運ぶのを示すのに使用されます。
The ethertype value 8848 hex is used to indicate that a frame is carrying an MPLS multicast packet.
ethertype価値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のどちらかと共にこれらのethertype値を使用できます。運ぶLLC/SNAPカプセル化はパケットをラベルしました。 これらの2つのカプセル化のどれを使用するかを選ぶための手順はこのドキュメントの範囲を超えています。
Rosen, et al. Standards Track [Page 18] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[18ページ]RFC3032MPLSラベルスタック
6. IANA Considerations
6. IANA問題
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 Consensusに基づいてIANAによって割り当てられるかもしれません。
7. Security Considerations
7. セキュリティ問題
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カプセル化はここに少しのMPLS構造[1]かカプセル化の中に含まれたネットワーク層プロトコルの構造で既に存在していない安全保障問題も提起しません。
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(「ラベル読者」)との協定によって意味があります。 しかしながら、ラベルスタックはラベル作家が何か特定のラベルのためのだれであったかを決定するどんな手段も提供しません。 信頼できないソースからラベルされたパケットを受け入れるなら、結果はパケットが違法な方法で発送されるということであるかもしれません。
8. Intellectual Property
8. 知的所有権
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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
Rosen, et al. Standards Track [Page 19] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[19ページ]RFC3032MPLSラベルスタック
9. Authors' Addresses
9. 作者のアドレス
Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Driveチェルムズフォード、エリックC.ローゼンシスコシステムズInc.250アポロMA 01824
EMail: erosen@cisco.com
メール: erosen@cisco.com
Dan Tappan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Driveチェルムズフォード、ダンタッパンシスコシステムズInc.250アポロMA 01824
EMail: tappan@cisco.com
メール: tappan@cisco.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
ヤコフRekhter Juniperは1194N.マチルダ・Avenueサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: yakov@juniper.net
メール: yakov@juniper.net
Guy Fedorkow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Driveチェルムズフォード、奴のFedorkowシスコシステムズInc.250アポロMA 01824
EMail: fedorkow@cisco.com
メール: fedorkow@cisco.com
Dino Farinacci Procket Networks, Inc. 3910 Freedom Circle, Ste. 102A Santa Clara, CA 95054
Ste、ディーノファリナッチProcketはInc.3910自由円をネットワークでつなぎます。 102Aサンタクララ、カリフォルニア 95054
EMail: dino@procket.com
メール: dino@procket.com
Rosen, et al. Standards Track [Page 20] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[20ページ]RFC3032MPLSラベルスタック
Tony Li Procket Networks, Inc. 3910 Freedom Circle, Ste. 102A Santa Clara, CA 95054
Ste、トニー李ProcketはInc.3910自由円をネットワークでつなぎます。 102Aサンタクララ、カリフォルニア 95054
EMail: tli@procket.com
メール: tli@procket.com
Alex Conta TranSwitch Corporation 3 Enterprise Drive Shelton, CT, 06484
アレックスコンタTranSwitch社3のエンタープライズDriveシェルトン、コネチカット 06484
EMail: aconta@txc.com
メール: aconta@txc.com
Rosen, et al. Standards Track [Page 21] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[21ページ]RFC3032MPLSラベルスタック
10. References
10. 参照
[1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[1] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
[3] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[4] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[4] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[5] キャッツ、D.、「IPルータ警戒オプション」、RFC2113、1997年2月。
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[6] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、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)仕様を議定書の中で述べます」、RFC1885、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.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、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.は飲み込まれます、「MPLSは自由民主党と気圧VCの切り換えを使用し」て、RFC3035、2001年1月。
Rosen, et al. Standards Track [Page 22] RFC 3032 MPLS Label Stack Encoding January 2001
ローゼン、他 2001年1月をコード化する標準化過程[22ページ]RFC3032MPLSラベルスタック
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Rosen, et al. Standards Track [Page 23]
ローゼン、他 標準化過程[23ページ]
一覧
スポンサーリンク
