RFC3988 日本語訳
3988 Maximum Transmission Unit Signalling Extensions for the LabelDistribution Protocol. B. Black, K. Kompella. January 2005. (Format: TXT=18841 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Black
Request for Comments: 3988 Layer8 Networks
Category: Experimental K. Kompella
Juniper Networks
January 2005
コメントを求めるワーキンググループのB.の黒い要求をネットワークでつないでください: 3988Layer8はカテゴリをネットワークでつなぎます: 実験的なK.Kompella杜松は2005年1月をネットワークでつなぎます。
Maximum Transmission Unit Signalling Extensions
for the Label Distribution Protocol
ラベル分配プロトコルのためのマキシマム・トランスミッション・ユニット合図拡大
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the Label Distribution Protocol (LDP) does not have the ability to signal the MTU for a Label Switched Path (LSP) to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent off-line mechanisms.
RFC1191経路Maximum Transmission Unit(MTU)発見の適切な機能は、IPルータにはそれらが接続されている各リンクへのMTUに関する知識があるのを必要とします。 現在指定されるように、Label Distributionプロトコル(自由民主党)にはLabel Switched Path(LSP)のためにイングレスLabel Switching Router(LSR)にMTUに合図する能力がありません。 この機能性がないとき、ネットワーク・オペレータか同等なオフラインメカニズムで静的に各LSPのためのMTUを構成しなければなりません。
This document specifies experimental extensions to LDP in support of LSP MTU discovery.
このドキュメントはLSP MTU発見を支持して実験的な拡大を自由民主党に指定します。
1. Introduction
1. 序論
As currently specified in [2], the LDP protocol for MPLS does not support signalling of the MTU for LSPs to ingress LSRs. This functionality is essential to the proper functioning of RFC 1191 path MTU detection [3]. Without knowledge of the MTU for an LSP, edge LSRs may transmit packets along that LSP which are, according to [4], too big. These packets may be silently discarded by LSRs along the LSP, effectively preventing communication between certain end hosts.
現在[2]で指定されるように、MPLSのための自由民主党プロトコルは、LSPsのためにイングレスLSRsにMTUに合図するのを支持しません。 この機能性はRFC1191経路MTU検出[3]の適切な機能に不可欠です。 LSPのためのMTUに関する知識がなければ、縁のLSRsは[4]によると、あまりに大きくあるそのLSPに沿ってパケットを伝えるかもしれません。 事実上、確信している終わりのホストのコミュニケーションを防いで、これらのパケットはLSPに沿ったLSRsによって静かに捨てられるかもしれません。
Black & Kompella Experimental [Page 1] RFC 3988 MTU Signalling Extensions for LDP January 2005
2005年1月に自由民主党のために拡大を示す黒とKompellaの実験的な[1ページ]RFC3988MTU
The solution proposed in this document enables automatic determination of the MTU for an LSP by adding a Type-Length-Value triplet (TLV) to carry MTU information for a Forwarding Equivalence Class (FEC) between adjacent LSRs in LDP Label Mapping messages. This information is sufficient for a set of LSRs along the path followed by an LSP to discover either the exact MTU for that LSP, or an approximation that is no worse than could be generated with local information on the ingress LSR.
本書では提案された解決策はType長さの価値の三つ子(TLV)を加えるのによるLSPが自由民主党Label MappingメッセージでForwarding Equivalence Class(FEC)のためのMTU情報を隣接しているLSRsの間まで運ぶMTUの自動決断を可能にします。 LSPによって続かれた経路に沿ったLSRsの1セットがイングレスLSRのローカルの情報で発生できたほど悪くないそのLSPのための正確なMTUか近似のどちらかを発見するように、この情報は十分です。
1.1. Conventions Used in This Document
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 BCP 14, RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
2. MTU Signalling
2. MTU合図
The signalling procedure described in this document employs the addition of a single TLV to LDP Label Mapping messages and a simple algorithm for LSP MTU calculation.
本書では説明された合図手順は自由民主党Label MappingメッセージとLSP MTU計算のための簡単なアルゴリズムへの独身のTLVの追加を使います。
2.1. Definitions
2.1. 定義
Link MTU: The MTU of a given link. This size includes the IP header and data (or other payload) and the label stack but does not include any lower-layer headers. A link may be an interface (such as Ethernet or Packet-over-SONET), a tunnel (such as GRE or IPsec), or an LSP.
MTUをリンクしてください: 与えられたリンクのMTU。 このサイズは、IPヘッダー、データ(他のペイロード)、およびラベルスタックを含んでいますが、どんな下層ヘッダーも含んでいません。 リンクは、インタフェース(イーサネットかPacket過剰Sonetなどの)、トンネル(GREかIPsecなどの)、またはLSPであるかもしれません。
Peer LSRs: For LSR A and FEC F, this is the set of LSRs that sent a Label Mapping for FEC F to A.
同輩LSRs: LSR AとFEC Fに関しては、これはFECのFからAのためにLabel Mappingを送ったLSRsのセットです。
Downstream LSRs: For LSR A and FEC F, this is the subset of A's peer LSRs for FEC F to which A will forward packets for the FEC. Typically, this subset is determined via the routing table.
川下のLSRs: LSR AとFEC Fに関しては、これはAがFECのためにパケットを送るFEC FのためのAの同輩LSRsの部分集合です。 この部分集合は経路指定テーブルを通して通常、決定しています。
Hop MTU: The MTU of an LSP hop between an upstream LSR, A, and a downstream LSR, B. This size includes the IP header and data (or other payload) and the part of the label stack that is considered payload as far as this LSP goes. It does not include any lower-level headers. (Note: If there are multiple links between A and B, the Hop MTU is the minimum of the Hop MTU of those links used for forwarding.)
MTUを飛び越してください: 上流のLSRと、Aと、川下のLSR、B.Thisサイズの間のLSPホップのMTUはこのLSPが関する限り、ペイロードであると考えられるIPヘッダー、データ(他のペイロード)、およびラベルスタックの一部を含んでいます。 それはどんな低レベルヘッダーも含んでいません。 (注意: 複数のリンクがAとBとの間にあれば、Hop MTUは推進に使用されるそれらのリンクのHop MTUの最小限です。)
LSP MTU: The MTU of an LSP from a given LSR to the egress(es), over each valid (forwarding) path. This size includes the IP header and data (or other payload) and any part of the label stack that was received by the ingress LSR before it placed the packet into the LSP
LSP MTU: それぞれの有効な(推進)経路にわたる与えられたLSRから出口(es)までのLSPのMTU。 このサイズはパケットをLSPに置く前にイングレスLSRによって受け取られたIPヘッダー、データ(他のペイロード)、およびラベルスタックのどんな一部も含んでいます。
Black & Kompella Experimental [Page 2] RFC 3988 MTU Signalling Extensions for LDP January 2005
2005年1月に自由民主党のために拡大を示す黒とKompellaの実験的な[2ページ]RFC3988MTU
(this part of the label stack is considered part of the payload for this LSP). The size does not include any lower-level headers.
(ラベルスタックのこの部分はこのLSPのためのペイロードの一部であると考えられます。) サイズはどんな低レベルヘッダーも含んでいません。
2.2. Example
2.2. 例
Consider LSRs A - F, interconnected as follows:
A--LSRsが以下の通りインタコネクトされたFであると考えてください:
M P
_____ C =====
/ | \
A ~~~~~ B ===== D ----- E ----- F
L N Q R
M P_____ C===== / | \A~~~~~ B===== D----- E----- F L N Q R
Say that the link MTU for link L is 9216; for links M, Q, and R, 4470; and for N and P, is 1500.
リンクLへのリンクMTUが9216であると言ってください。 リンクM、Q、およびR、4470年のために。 そして、NとPのために、1500はそうですか?
Consider an FEC X for which F is the egress, and say that all LSRs advertise X to their neighbors.
FECがFが出口であるXであると考えてください、そして、すべてのLSRsが彼らの隣人にXの広告を出すと言ってください。
Note that although LDP may be running on the C - D link, it is not used for forwarding (e.g., because it has a high metric). In particular, D is an LDP neighbor of C, but D is not one of C's downstream LSRs for FEC X.
自由民主党はCで走っているかもしれませんが、それに注意してください--Dリンク、それは推進に使用されません(例えば、高値をメートル法にするので)。 Dは特に、Cの自由民主党の隣人ですが、DはFEC XのためのCの川下LSRsの1つではありません。
E's peers for FEC X are C, D, and F. Say that E chooses F as its downstream LSR for X. E's Hop MTU for link R is 4466. If F advertised an implicit null label to E, then E MAY set the Hop MTU for R to 4470.
リンクRへのX.EのHop MTUのための川下のLSRが4466であるので、FEC XのためのEの同輩は、EがFを選ぶCと、Dと、F.Sayです。 Fが内在しているヌルラベルのEに広告を出したなら、Eは4470へのRにHop MTUを設定するかもしれません。
C's peers for FEC X are B, D, and E. Say that C chooses E as its downstream LSR for X. Similarly, A chooses B, B chooses C and D (equal cost multi-path), D chooses E, and E chooses F (respectively) as downstream LSRs.
X.Similarlyのための川下のLSR、AがBを選んで、BがCとD(等しい費用マルチ経路)を選んで、DがEを選んで、Eが川下のLSRsとしてF(それぞれ)を選ぶとき、FEC XのためのCの同輩は、CがEを選ぶBと、Dと、E.Sayです。
C's Hop MTU to E for FEC X is 1496. B's Hop MTU to C is 4466 and to D is 1496. A's LSP MTU for FEC X is 1496. If A has another LSP for FEC Y to F (learned via targeted LDP) that rides over the LSP for FEC X, the MTU for that LSP would be 1492.
FEC XのためのEへのCのHop MTUは1496です。 CへのビーズHop MTUは4466であり、Dへの1496です。 FEC XのためのAのLSP MTUは1496です。 Aに別のFEC XのためにLSPを通り過ぎるFECのYからF(狙っている自由民主党を通して、学習される)LSPがあるなら、そのLSPのためのMTUは1492でしょう。
If B had a targeted LDP session to E (e.g., over an RSVP-TE tunnel T)
and B received a Mapping for FEC X over the targeted LDP session,
then E would also be B's peer, and E may be chosen as a downstream
LSR for B. In that case, B's LSP MTU for FEC X would then be the
smaller of {(T's MTU - 4), E's LSP MTU for X}.
BがE(例えば、RSVP-TEトンネルTの上の)への狙っている自由民主党のセッションとまた、次に、狙っている自由民主党のセッション、Eの上のXがビーズが同輩であるならそうして、Eがその時、ケース、FEC XのためのビーズLSP MTUがあるB.Inのための川下のLSRとして選ばれるかもしれないFECのためのB容認されたa Mappingをより小さくした、(TのMTU--、4、)XのためのEのLSP MTU
This memo describes how A determines its LSP MTU for FECs X and Y.
このメモはAがFECs XとYのためにどうLSP MTUを決定するかを説明します。
Black & Kompella Experimental [Page 3] RFC 3988 MTU Signalling Extensions for LDP January 2005
2005年1月に自由民主党のために拡大を示す黒とKompellaの実験的な[3ページ]RFC3988MTU
2.3. Signalling Procedure
2.3. 合図手順
The procedure for signalling the MTU is performed hop-by-hop by each LSR L along an LSP for a given FEC, F. The steps are as follows:
MTUに合図するための手順はホップごとに与えられたFECのためにLSPに沿った各LSR Lによって実行されて、F. ステップは以下の通りです:
1. First, L computes its LSP MTU for FEC F:
1. まず最初に、LはFEC FのためにLSP MTUを計算します:
A. If L is the egress for F, L sets the LSP MTU for F to 65535.
A. LがF出口であるなら、Lは65535へのFにLSP MTUを設定します。
B. [OPTIONAL] If L's only downstream LSR is the egress for F
(i.e., L is a penultimate hop for F) and L receives an implicit
null label as its Mapping for F, then L can set the Hop MTU for
its downstream link to the link MTU instead of (link MTU - 4
octets). L's LSP MTU for F is the Hop MTU.
の代わりにする、B.[OPTIONAL]がLの唯一の川下LSRがF(すなわち、LはF終わりから二番目のホップである)とLのための出口であるならF Mappingとして内在しているヌルラベルを受けて、次に、LがリンクMTUへの川下のリンクにHop MTUを設定できる、(リンクMTU--4つの八重奏)。 LのF LSP MTUはHop MTUです。
C. Otherwise (L is not the egress LSR), L computes the LSP MTU for
F as follows:
C. さもなければ(Lは出口LSRでない)、Lは以下のFのためにLSP MTUを計算します:
a) L determines its downstream LSRs for FEC F.
a) LはFEC Fのために川下のLSRsを決定します。
b) For each downstream LSR Z, L computes the minimum of the Hop
MTU to Z and the LSP MTU in the MTU TLV that Z advertised to
L. If Z did not include the MTU TLV in its Label Mapping,
then Z's LSP MTU is set to 65535.
b) それぞれの川下のLSR Zにおいて、LはHop MTUの最小限をZに計算して、ZがL.If Zに広告を出したMTU TLVのLSP MTUはLabel MappingでMTU TLVを含めないで、次に、ZのLSP MTUは65535に用意ができています。
c) L sets its LSP MTU to the minimum of the MTUs it computed
for its downstream LSRs.
c) Lはそれが川下のLSRsのために計算したMTUsの最小限にLSP MTUを設定します。
2. For each LDP neighbor (direct or targeted) of L to which L decides
to send a Mapping for FEC F, L attaches an MTU TLV with the LSP
MTU that it computed for this FEC. L MAY (because of policy or
for other reasons) advertise a smaller MTU than it has computed,
but L MUST NOT advertise a larger MTU.
2. LがFEC FのためにMappingを送ると決めるLのそれぞれの自由民主党の隣人(ダイレクトであるか狙っている)に関しては、LはそれがこのFECのために計算したLSP MTUと共にMTU TLVを取り付けます。 Lは計算したより小さいMTUの広告を出すかもしれませんが(方針のため他の理由ので)、Lは、より大きいMTUの広告を出してはいけません。
3. When a new MTU is received for FEC F from a downstream LSR or the
set of downstream LSRs for F changes, L returns to step 1. If the
newly computed LSP MTU is unchanged, L SHOULD NOT advertise new
information to its neighbors. Otherwise, L readvertises its
Mappings for F to all its peers with an updated MTU TLV.
3. FEC Fのために川下のLSRから新しいMTUを受け取るか、またはF川下のLSRsのセットが変化するとき、Lはステップ1に戻ります。 新たに計算されたLSP MTUが変わりがないなら、L SHOULD NOTは隣人に新情報の広告を出します。 さもなければ、LはFのためにアップデートされたMTU TLVと共にすべての同輩にMappingsの「再-広告を出」します。
This behavior is standard for attributes such as path vector and
hop count, and the same rules apply, as specified in [2].
経路ベクトルやホップカウントなどの属性において、この振舞いは標準です、そして、同じ規則は適用されます、[2]で指定されるように。
If the LSP MTU decreases, L SHOULD readvertise the new MTU
immediately; if the LSP MTU increases, L MAY hold down the
readvertisement.
LSP MTU減少、L SHOULD readvertiseの新しいMTUである、すぐに。 LSP MTUが増加するなら、Lは再広告を押さえるかもしれません。
Black & Kompella Experimental [Page 4] RFC 3988 MTU Signalling Extensions for LDP January 2005
2005年1月に自由民主党のために拡大を示す黒とKompellaの実験的な[4ページ]RFC3988MTU
2.4. MTU TLV
2.4. MTU TLV
The MTU TLV encodes information on the maximum transmission unit for an LSP, from the advertising LSR to the egress(es) over all valid paths.
MTU TLVはLSPのためにすべての有効な経路にわたって広告LSRから出口(es)までマキシマム・トランスミッション・ユニットの情報をコード化します。
The encoding for the MTU TLV is as follows:
MTU TLVのためのコード化は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| MTU TLV (0x0601) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| MTU TLV(0×0601)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MTU
MTU
This is a 16-bit unsigned integer that represents the MTU in octets for an LSP or a segment of an LSP.
これは、LSPのために八重奏でMTUを表す16ビットの符号のない整数かLSPのセグメントです。
Note that the U and F bits are set. An LSR that doesn't recognize the MTU TLV MUST ignore it when it processes the Label Mapping message and forward the TLV to its peers. This may result in the incorrect computation of the LSP MTU; however, silently forwarding the MTU TLV preserves the maximal amount of information about the LSP MTU.
UとFビットが設定されることに注意してください。 MTU TLV MUSTがLabel Mappingメッセージを処理するとき、それを無視して、TLVを同輩に送ると認めないLSR。 これはLSP MTUの不正確な計算をもたらすかもしれません。 しかしながら、静かにMTU TLVを進めると、最大限度の情報量はLSP MTUに関して保存されます。
3. Example of Operation
3. 操作に関する例
Consider the network example in Section 2.2. For each LSR, Table 1 describes the links to its downstream LSRs, the Hop MTU for the peer, the LSP MTU received from the peer, and the LSR's computed LSP MTU.
セクション2.2のネットワークの例を考えてください。 各LSRに関しては、Table1は川下のLSRsにリンクを説明します、同輩のためのHop MTU、同輩から受け取られたLSP MTU、そして、LSRがLSP MTUを計算しました。
Now consider the same network with the following changes: There is an LSP T from B to E, and a targeted LDP session from B to E. B's peer LSRs are A, C, D, and E; B's downstream LSRs are D and E; to reach E, B chooses to go over T. The LSP MTU for LSP T is 1496. This information is depicted in Table 2.
今度は、以下の変化に伴う同じネットワークを考えてください: BからEまでのLSP T、およびBからE.までの狙っている自由民主党のセッションがあります。ビーズ同輩LSRsはAと、Cと、Dと、Eです。 ビーズの川下のLSRsはDとEです。 Eに達するように、Bは、T.を調べるのを選びます。LSP TのためのLSP MTUは1496です。 この情報はTable2に表現されます。
Black & Kompella Experimental [Page 5] RFC 3988 MTU Signalling Extensions for LDP January 2005
2005年1月に自由民主党のために拡大を示す黒とKompellaの実験的な[5ページ]RFC3988MTU
LSR | Link | Hop MTU | Recvd MTU | LSP MTU
--------------------------------------------------
F | - | 65535 | - | 65535
--------------------------------------------------
E | R | 4466 | F: 65535 | 4466
--------------------------------------------------
D | Q | 4466 | E: 4466 | 4466
--------------------------------------------------
C | P | 1496 | E: 4466 | 1496
--------------------------------------------------
B | M | 4466 | C: 1496 |
| N | 1496 | D: 4466 | 1496
--------------------------------------------------
A | L | 9212 | B: 1496 | 1496
--------------------------------------------------
Table 1
LSR| リンク| ホップMTU| Recvd MTU| LSP MTU-------------------------------------------------- F| - | 65535 | - | 65535 -------------------------------------------------- E| R| 4466 | F: 65535 | 4466 -------------------------------------------------- D| Q| 4466 | E: 4466 | 4466 -------------------------------------------------- C| P| 1496 | E: 4466 | 1496 -------------------------------------------------- B| M| 4466 | C: 1496 | | N| 1496 | D: 4466 | 1496 -------------------------------------------------- A| L| 9212 | B: 1496 | 1496 -------------------------------------------------- テーブル1
LSR | Link | Hop MTU | Recvd MTU | LSP MTU
--------------------------------------------------
F | - | 65535 | - | 65535
--------------------------------------------------
E | R | 4466 | F: 65535 | 4466
--------------------------------------------------
D | Q | 4466 | E: 4466 | 4466
--------------------------------------------------
C | P | 1496 | E: 4466 | 1496
--------------------------------------------------
B | T | 1492 | E: 4466 |
| N | 1496 | D: 4466 | 1492
--------------------------------------------------
A | L | 9212 | B: 1492 | 1492
--------------------------------------------------
Table 2
LSR| リンク| ホップMTU| Recvd MTU| LSP MTU-------------------------------------------------- F| - | 65535 | - | 65535 -------------------------------------------------- E| R| 4466 | F: 65535 | 4466 -------------------------------------------------- D| Q| 4466 | E: 4466 | 4466 -------------------------------------------------- C| P| 1496 | E: 4466 | 1496 -------------------------------------------------- B| T| 1492 | E: 4466 | | N| 1496 | D: 4466 | 1492 -------------------------------------------------- A| L| 9212 | B: 1492 | 1492 -------------------------------------------------- テーブル2
4. Using the LSP MTU
4. LSP MTUを使用します。
An ingress LSR that forwards an IP packet into an LSP whose MTU it knows MUST either fragment the IP packet to the LSP's MTU (if the Don't Fragment bit is clear) or drop the packet and respond with an ICMP Destination Unreachable message to the source of the packet, with the Code indicating "fragmentation needed and DF set", and the Next-Hop MTU set to the LSP MTU. In other words, the LSR behaves as RFC 1191 says, except that it treats the LSP as the next hop "network".
それがMTUを知っているLSPにIPパケットを送るイングレスLSRはパケットの源までIPパケットをLSPのMTUに断片化しなければならないか(どんなFragmentも噛み付かなかったドンが明確であるなら)、パケットを落として、またはICMP Destination Unreachableメッセージで応じなければなりません、Codeが、「断片化が必要であり、DFは設定します」と示して、Next-ホップMTUがLSP MTUに用意ができていて。 言い換えれば、RFC1191が言うようにLSRは振る舞います、次のホップ「ネットワーク」としてLSPを扱うのを除いて。
If the payload for the LSP is not an IP packet, the LSR MUST forward the packet if it fits (size <= LSP MTU) and SHOULD drop it if it doesn't.
LSPのためのペイロードがIPパケットでなく、また合って(サイズ<はLSP MTUと等しいです)、SHOULDがそれを落として、進めないなら、LSR MUSTはパケットを進めます。
Black & Kompella Experimental [Page 6] RFC 3988 MTU Signalling Extensions for LDP January 2005
2005年1月に自由民主党のために拡大を示す黒とKompellaの実験的な[6ページ]RFC3988MTU
5. Protocol Interaction
5. プロトコル相互作用
5.1. Interaction with LSRs that Do Not Support MTU Signalling
5.1. LSRsとの相互作用はそのDo Not Support MTU Signallingです。
Changes in MTU for sections of an LSP may cause intermediate LSRs to generate unsolicited label Mapping messages to advertise the new MTU. LSRs that do not support MTU signalling will, due to message and TLV processing mechanisms specified in RFC3036 [2], accept the messages carrying the MTU TLV but will ignore the TLV and forward the TLV to the upstream nodes (see Section 2.4).
LSPのセクションへのMTUにおける変化で、中間的LSRsは新しいMTUの広告を出す求められていないラベルMappingメッセージを発生させるかもしれません。 MTU合図を支持しないLSRsが上流のノードにメッセージとRFC3036[2]で指定されたTLV処理メカニズムのためMTU TLVを運びながらメッセージを受け入れますが、TLVを無視して、TLVを送るでしょう(セクション2.4を見てください)。
5.2. Interaction with CR-LDP and RSVP-TE
5.2. CR-自由民主党とRSVP-Teとの相互作用
The MTU TLV can be used to discover the Path MTU of both LDP LSPs and CR-LDP LSPs. This proposal is not impacted in the presence of LSPs created with CR-LDP, as specified in [5].
自由民主党LSPsとCR-自由民主党LSPsの両方のPath MTUを発見するのにMTU TLVを使用できます。 この提案はCR-自由民主党と共に[5]で指定されるように作成されたLSPsの面前で影響を与えられません。
Note that LDP/CR-LDP LSPs may tunnel through other LSPs signalled using LDP, CR-LDP, or RSVP-TE [6]; the mechanism suggested here applies in all of these cases, essentially by treating the tunnel LSPs as links.
CR自由民主党/自由民主党LSPsが自由民主党を使用することで合図された他のLSPs、CR-自由民主党、またはRSVP-TE[6]を通してトンネルを堀るかもしれないことに注意してください。 メカニズムは、ケースがこれらのすべてでここで本質的にはトンネルLSPsをリンクとして扱うことによって適用されるのを示しました。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.
Thomas, "LDP Specification", RFC 3036, January 2001.
[2] アンデションとL.とDoolanとP.とフェルドマンとN.とFredette、A.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
[3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[3] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[4] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D.,
Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
January 2001.
[4] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[6] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[6] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
Black & Kompella Experimental [Page 7] RFC 3988 MTU Signalling Extensions for LDP January 2005
2005年1月に自由民主党のために拡大を示す黒とKompellaの実験的な[7ページ]RFC3988MTU
6.2. Informative References
6.2. 有益な参照
[5] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L.,
Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M.,
Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-
Based LSP Setup using LDP", RFC 3212, January 2002.
[5]Jamoussi、B.、アンデション、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、オースター、T.、フェルドマン、N.、Fredette、A.、Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.、およびA.Malis、「規制は自由民主党を使用することでLSPセットアップを基礎づけました」、RFC3212、2002年1月。
7. Security Considerations
7. セキュリティ問題
This mechanism does not introduce any new weaknesses in LDP. It is possible to spoof TCP packets belonging to an LDP session to manipulate the LSP MTU, but LDP has mechanisms to thwart these types of attacks. See Section 5 of [2] for more information on security aspects of LDP.
このメカニズムは自由民主党でどんな新しい弱点も導入しません。 LSP MTUを操作するために自由民主党のセッションに属するTCPパケットをだますのが可能ですが、自由民主党には、これらのタイプの攻撃を阻むメカニズムがあります。 自由民主党のセキュリティ局面に関する詳しい情報のための[2]のセクション5を見てください。
8. IANA Considerations
8. IANA問題
IANA has allocated 0x0601 as a new LDP TLV Type, defined in Section 2.4. See: http://www.iana.org/assignments/ldp-namespaces
IANAはセクション2.4で定義された新しい自由民主党TLV Typeとして0×0601を割り当てました。 見ます: http://www.iana.org/assignments/ldp-namespaces
9. Acknowledgements
9. 承認
We would like to thank Andre Fredette for a number of detailed comments on earlier versions of the signalling mechanism. Eric Gray, Giles Heron, and Mark Duffy have contributed numerous useful suggestions.
合図メカニズムの以前のバージョンの多くの詳細なコメントについてアンドレFredetteに感謝申し上げます。 エリック・グレー、ジャイルスHeron、およびマーク・ダフィーは頻繁な役に立つ提案を寄付しました。
Authors' Addresses
作者のアドレス
Benjamin Black Layer8 Networks
Layer8がネットワークでつなぐベンジャミンBlack
EMail: ben@layer8.net
メール: ben@layer8.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 US
Kireeti Kompella杜松は米国で1194N.マチルダ・Aveサニーベル、カリフォルニア 94089をネットワークでつなぎます。
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
Black & Kompella Experimental [Page 8] RFC 3988 MTU Signalling Extensions for LDP January 2005
2005年1月に自由民主党のために拡大を示す黒とKompellaの実験的な[8ページ]RFC3988MTU
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Black & Kompella Experimental [Page 9]
黒くて、Kompella実験的です。[9ページ]
一覧
スポンサーリンク
