RFC3988 日本語訳

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ページ]