RFC3784 日本語訳
3784 Intermediate System to Intermediate System (IS-IS) Extensions forTraffic Engineering (TE). H. Smit, T. Li. June 2004. (Format: TXT=27422 bytes) (Obsoleted by RFC5305) (Updated by RFC4205) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Smit
Request for Comments: 3784 Procket Networks
Category: Informational T. Li
June 2004
コメントを求めるワーキンググループH.スミット要求をネットワークでつないでください: 3784Procketはカテゴリをネットワークでつなぎます: 情報のT.李2004年6月
Intermediate System to Intermediate System (IS-IS)
Extensions for Traffic Engineering (TE)
中間システムへの中間システム、(-、)、交通工学のための拡大(Te)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations.
このドキュメントがIntermediate SystemへのIntermediate Systemに拡大について説明する、(-、)、議定書を作って、Traffic Engineering(TE)を支持してください。 このドキュメントが広がっている、-、Intermediate System(ルータ)がLink州プロトコル(LSP)データUnitsで入賞できるという新情報を指定することによって、議定書を作ってください。 この情報はネットワークの事情に関する交通工学計算の役に立つ追加詳細について説明します。
1. Introduction
1. 序論
The IS-IS protocol is specified in ISO 10589 [1], with extensions for supporting IPv4 specified in RFC 1195 [3]. Each Intermediate System (IS) (router) advertises one or more IS-IS Link State Protocol Data Units (LSPs) with routing information. Each LSP is composed of a fixed header and a number of tuples, each consisting of a Type, a Length, and a Value. Such tuples are commonly known as TLVs, and are a good way of encoding information in a flexible and extensible format.
-、プロトコル、ISO10589[1]では、RFC1195[3]で指定されたIPv4を支持するための拡大で、指定されます。 各Intermediate System(あります)(ルータ)が1つか以上の広告を出す、-、ルーティング情報があるLink州プロトコルData Units(LSPs)。 各LSPは固定ヘッダー、多くのtuples、Typeの各成ること、Length、およびValueで構成されます。 そのようなtuplesはTLVsとして一般的に知られていて、フレキシブルで広げることができる形式で情報をコード化する早道です。
This document contains the design of new TLVs to replace the existing IS Neighbor TLV, IP Reachability TLV, and to include additional information about the characteristics of a particular link to an IS- IS LSP. The characteristics described in this document are needed for Traffic Engineering [4] (TE). Secondary goals include increasing the dynamic range of the IS-IS metric and improving the encoding of IP prefixes.
このドキュメントが含んでいる、存在を取り替える新しいTLVsのデザインがNeighbor TLV、IP Reachability TLVであり、特定のリンクの特性に関するインクルード追加情報にそうである、存在、IS LSP。 本書では説明された特性がTraffic Engineering[4](TE)に必要です。 二次目標が、ダイナミックレンジを増加させるのを含んでいる、-、メートル法、そして、IP接頭語のコード化を改良すること。
Smit & Li Informational [Page 1] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[1ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
The router id is useful for traffic engineering purposes because it describes a single address that can always be used to reference a particular router.
特定のルータに参照をつけるのにいつも使用できるただ一つのアドレスについて説明するので、ルータイドは交通工学目的の役に立ちます。
Mechanisms and procedures to migrate to the new TLVs are not discussed in this document.
本書では新しいTLVsにわたるメカニズムと手順について議論しません。
2. Introducing Sub-TLVs
2. サブTLVsを導入します。
This document introduces a new way to encode routing information in IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to regular TLVs. They use the same concepts as regular TLVs. The difference is that TLVs exist inside IS-IS packets, while sub-TLVs exist inside TLVs. TLVs are used to add extra information to IS-IS packets. Sub-TLVs are used to add extra information to particular TLVs. Each sub-TLV consists of three fields, a one-octet Type field, a one-octet Length field, and zero or more octets of Value. The Type field indicates the type of items in the Value field. The Length field indicates the length of the Value field in octets. Each sub- TLV can potentially hold multiple items. The number of items in a sub-TLV can be computed from the length of the whole sub-TLV, when the length of each item is known. Unknown sub-TLVs are to be ignored and skipped upon receipt.
このドキュメントがルーティング情報をコード化する新しい方法を導入する、- 新しい物はサブTLVと呼ばれます。 サブTLVsは通常のTLVsと同様です。 彼らは通常のTLVsと同じ概念を使用します。 違いがTLVsが中に存在しているということである、-、サブTLVsがTLVsの中に存在している間のパケット。 TLVsがその他の情報を加えるのに使用される、-、パケット。 サブTLVsは、特定のTLVsにその他の情報を加えるのに使用されます。 それぞれのサブTLVはValueの3つの分野か、1八重奏のType分野か、1八重奏のLength分野と、ゼロか、より多くの八重奏から成ります。 Type分野はValue分野の項目のタイプを示します。 Length分野は八重奏における、Value分野の長さを示します。 それぞれのサブTLVは潜在的に複数の項目を保持できます。全体のサブTLVの長さからサブTLVの件数を計算できます、各個条の長さが知られていると。 未知のサブTLVsは領収書で無視されて、スキップされることになっています。
The Sub-TLV type space is managed by the IETF IS-IS WG (http://www.ietf.org/html.charters/isis-charter.html). New type values are allocated following review on the IETF IS-IS mailing list. This will normally require publication of additional documentation describing how the new type is used. In the event that the IS-IS working group has disbanded the review shall be performed by a Designated Expert assigned by the responsible Area Director.
Sub-TLVタイプスペースはIETF IS-IS WG( http://www.ietf.org/html.charters/isis-charter.html )によって管理されます。 新しいタイプ値にレビューに続くのを割り当てる、IETF IS存在、メーリングリスト。 通常、これは新しいタイプがどう使用されているかを説明する追加のドキュメンテーションの公表を必要とするでしょう。 -、ワーキンググループ、解散されて、レビューは責任があるAreaディレクターによって割り当てられたDesignated Expertによって実行されるものとします。
3. The Extended IS Reachability TLV
3. 広げるのは可到達性TLVです。
The extended IS reachability TLV is TLV type 22.
広げるのによる可到達性TLVがTLVタイプ22であるということです。
The existing IS reachability (TLV type 2, defined in ISO 10589 [1]) contains information about a series of IS neighbors. For each neighbor, there is a structure that contains the default metric, the delay, the monetary cost, the reliability, and the 7-octet ID of the adjacent neighbor. Of this information, the default metric is commonly used. The default metric is currently one octet, with one bit used to indicate whether the metric is internal or external, and one bit that was originally unused, but which was later defined by RFC 2966 to be the up/down bit. The remaining 6 bits are used to store the actual metric, resulting in a possible metric range of 0- 63. This limitation is one of the restrictions that we would like to lift.
存在は可到達性です。(TLVは2をタイプして、ISO10589[1])がシリーズの情報を含む定義されたコネは隣人です。 各隣人のために、メートル法であることでデフォルトを含む構造、遅れ、貨幣原価、信頼性、および隣接している隣人の7八重奏のIDがあります。 デフォルトメートル法であることは、一般的にそうです。この情報について使用する、使用されます。 デフォルト、メートル法であることが、現在の1ビットがメートル法が内部である、または外部であるかを示すのに使用されている1つの八重奏と、元々未使用である1ビットですが、どれが後で上がるか下がるようになるようにRFC2966によって定義されたかに噛み付きました。 0- 63の可能なメートル法の範囲をもたらして、残っている6ビットは、メートル法で実際を格納するのに使用されます。 この制限は持ち上がりたいと思うという制限の1つです。
Smit & Li Informational [Page 2] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[2ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
The remaining three metrics (delay, monetary cost, and reliability) are not commonly implemented and reflect unused overhead in the TLV. The neighbor is identified by its system ID, typically 6-octets, plus one octet indicating the pseudonode number. Thus, the existing TLV consumes 11 octets per neighbor, with 4 octets for metric and 7 octets for neighbor identification. To indicate multiple adjacencies, this structure is repeated within the IS reachability TLV. Because the TLV is limited to 255 octets of content, a single TLV can describe up to 23 neighbors. The IS reachability TLV can be repeated within the LSP fragments to describe further neighbors.
残っている3つの測定基準(遅れ、貨幣原価、および信頼性)が、一般的に実行されないで、未使用のオーバーヘッドをTLVに反映します。 隣人はシステムID、通常6八重奏、およびpseudonode番号を示す1つの八重奏で特定されます。 したがって、既存のTLVは隣人識別のためのメートル法と7つの八重奏のために1隣人4つの八重奏による11の八重奏を消費します。 複数の隣接番組を示すために、この構造で繰り返される、可到達性TLVはそうです。 TLVが内容の255の八重奏に制限されるので、独身のTLVは最大23人の隣人について説明できます。 TLVがたびたびである場合がある可到達性は一層の隣人について説明するLSP断片ですか?
The proposed extended IS reachability TLV contains a new data structure, consisting of:
広げられた提案はTLVが新しいデータ構造、成ることを含む可到達性です:
7 octets of system Id and pseudonode number
3 octets of default metric
1 octet of length of sub-TLVs
0-244 octets of sub-TLVs,
where each sub-TLV consists of a sequence of
1 octet of sub-type
1 octet of length of the value field of the sub-TLV
0-242 octets of value
システムIdの7つの八重奏とサブTLVsのサブTLVs0-244の八重奏の長さのデフォルトメートル法の1八重奏のpseudonode数の3八重奏。そこでは、それぞれのサブTLVが価値のサブTLV0-242の八重奏の値の分野の長さのサブタイプ1つの八重奏の1つの八重奏の系列から成ります。
Thus, if no sub-TLVs are used, the new encoding requires 11 octets and can contain up to 23 neighbors. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall IS reachability TLV. The practical maximum is 255 octets minus the 11 octets described above, or 244 octets. Further, there is no defined mechanism for extending the sub-TLV space for a particular neighbor. Thus, wasting sub-TLV space is discouraged.
したがって、どんなサブTLVsも使用されていないなら、新しいコード化は、11の八重奏を必要として、最大23人の隣人を含むことができます。 お願いします、コード化がサブTLVsの255の八重奏を考慮している間最大値が総合的をうまくはめ込むことができないというメモはそうです。可到達性TLV。 実用的な最大は、上で説明された11の八重奏を引いた255の八重奏、または244の八重奏です。 さらに、特定の隣人のためにサブTLVスペースを広げるための定義されたメカニズムが全くありません。 したがって、サブTLVスペースを浪費するのはお勧めできないです。
The metric octets are encoded as a 24-bit unsigned integer. Note that the metric field in the new extended IP reachability TLV is encoded as a 32-bit unsigned integer. These different sizes were chosen so that it is very unlikely that the cost of an intra-area route has to be chopped off to fit in the metric field of an inter- area route.
メートル法の八重奏は24ビットの符号のない整数としてコード化されます。 新しい拡張IPの可到達性TLVのメートル法の分野が32ビットの符号のない整数としてコード化されることに注意してください。 これらの異なったサイズが選ばれたので、イントラ領域ルートの費用が相互領域ルートのメートル法の分野をうまくはめ込むために切り離されなければならないのは、非常にありそうもないです。
To preclude overflow within a traffic engineering SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
交通工学SPF実現、すべての測定基準の中では、オーバーフローをより排除する、マックス_PATH_METRIC SHALL、aをマックス_PATH_METRICでメートル法にすると考えられてください。 あれほどそんなにマックス_PATHの_のMETRICのプラスのa単一のリンクメートル法でマックス_PATH_METRICを選択するのは最も簡単です。内部のメートル法の計算のためのビットの数から、はみ出しません。 私たちは、これが32ビットであると思います。 したがって、私たちは、42億6141万2864(0xFE000000、2^32--2^25)になるようにマックス_PATH_METRICを選びました。
Smit & Li Informational [Page 3] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[3ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
If a link is advertised with the maximum link metric (2^24 - 1), this link MUST NOT be considered during the normal SPF computation. This will allow advertisement of a link for purposes other than building the normal Shortest Path Tree. An example is a link that is available for traffic engineering, but not for hop-by-hop routing.
最大のリンクがメートル法で(2^24--1)リンクが広告に掲載されるなら、通常のSPF計算の間、このリンクを考えてはいけません。 これは正常なShortest Path Treeを造るのを除いた目的のためのリンクの広告を許すでしょう。 例は、交通工学に利用可能なリンクですが、ホップごとのルーティングのためにそのようなリンクではありません。
Certain sub-TLVs are proposed here:
あるサブTLVsはここで提案されます:
Sub-TLV type Length (octets) Name
3 4 Administrative group (color)
6 4 IPv4 interface address
8 4 IPv4 neighbor address
9 4 Maximum link bandwidth
10 4 Reservable link bandwidth
11 32 Unreserved bandwidth
18 3 TE Default metric
250-254 Reserved for cisco specific extensions
255 Reserved for future expansion
サブTLVタイプLength(八重奏)は今後の拡大にちなんでコクチマスの特定の拡大のための3 4Administrativeグループ(色)6 4IPv4インターフェース・アドレス8 4IPv4隣人アドレス9 4Maximumリンク帯域幅10 4Reservableリンク帯域幅11 32Unreserved帯域幅18の3のTE Defaultのメートル法の250-254Reservedを255Reservedと命名します。
Each of these sub-TLVs is described below. Unless stated otherwise, multiple occurrences of the information are supported by multiple inclusions of the sub-TLV.
それぞれのこれらのサブTLVsは以下で説明されます。 別の方法で述べられない場合、情報の複数の発生がサブTLVの複数の包含で支持されます。
3.1. Sub-TLV 3: Administrative group (color, resource class)
3.1. サブTLV3: 管理グループ(色、リソースのクラス)
The administrative group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface.
管理グループサブTLVはネットワーク管理者によって割り当てられた4八重奏の噛み付いているマスクを含んでいます。 各セット・ビットはインタフェースに割り当てられた1つの管理グループに対応しています。
By convention, the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'.
コンベンションによって、最下位ビットは'グループ0'と呼ばれます、そして、最も重要なビットは'グループ31'と呼ばれます。
This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
このサブTLVはOPTIONALです。 可到達性TLVがそれぞれで広げられた大部分にいったんあると、このサブTLV SHOULDは現れます。
3.2. Sub-TLV 6: IPv4 interface address
3.2. サブTLV6: IPv4インターフェース・アドレス
This sub-TLV contains a 4-octet IPv4 address for the interface described by the (main) TLV. This sub-TLV can occur multiple times.
このサブTLVはインタフェースへのIPv4アドレスが(主)のTLVで説明した4八重奏を含んでいます。 このサブTLVは複数の回起こることができます。
Implementations MUST NOT inject a /32 prefix for the interface address into their routing or forwarding table because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV.
これが、このサブTLVを支持しないシステムと対話するとき、輪を進めるのに通じることができるので、実現はインターフェース・アドレスのためにそれらのルーティングか推進テーブルに/32接頭語を注入してはいけません。
Smit & Li Informational [Page 4] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[4ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
If a router implements the basic TLV extensions in this document, it MAY add or omit this sub-TLV from the description of an adjacency. If a router implements traffic engineering, it MUST include this sub-TLV.
ルータが本書では基本的なTLV拡張子を実行するなら、それは、隣接番組の記述からこのサブTLVを加えるか、または省略するかもしれません。 ルータが交通工学を実行するなら、それはこのサブTLVを含まなければなりません。
3.3. Sub-TLV 8: IPv4 neighbor address
3.3. サブTLV8: IPv4隣人アドレス
This sub-TLV contains a single IPv4 address for a neighboring router on this link. This sub-TLV can occur multiple times.
このサブTLVはこのリンクの上の隣接しているルータのためのただ一つのIPv4アドレスを含んでいます。 このサブTLVは複数の回起こることができます。
Implementations MUST NOT inject a /32 prefix for the neighbor address into their routing or forwarding table because this can lead to forwarding loops when interacting with systems that do not support this sub-TLV.
これが、このサブTLVを支持しないシステムと対話するとき、輪を進めるのに通じることができるので、実現は隣人アドレスのためにそれらのルーティングか推進テーブルに/32接頭語を注入してはいけません。
If a router implements the basic TLV extensions in this document, it MAY add or omit this sub-TLV from the description of an adjacency. If a router implements traffic engineering, it MUST include this sub-TLV on point-to-point adjacencies.
ルータが本書では基本的なTLV拡張子を実行するなら、それは、隣接番組の記述からこのサブTLVを加えるか、または省略するかもしれません。 ルータが交通工学を実行するなら、それは二地点間隣接番組のこのサブTLVを含まなければなりません。
3.4. Sub-TLV 9: Maximum link bandwidth
3.4. サブTLV9: 最大のリンク帯域幅
This sub-TLV contains the maximum bandwidth that can be used on this link in this direction (from the system originating the LSP to its neighbors). This is useful for traffic engineering.
このサブTLVはこのリンクの上にこの方向(LSPを溯源するシステムから隣人までの)に使用できる最大の帯域幅を含んでいます。 これは交通工学の役に立ちます。
The maximum link bandwidth is encoded in 32 bits in IEEE floating point format. The units are bytes (not bits!) per second.
最大のリンク帯域幅はIEEE浮動小数点形式における32ビットでコード化されます。 ユニットは1秒あたりバイト(ビットでない!)です。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
このサブTLVは任意です。 可到達性TLVがそれぞれで広げられた大部分にいったんあると、このサブTLV SHOULDは現れます。
3.5. Sub-TLV 10: Maximum reservable link bandwidth
3.5. サブTLV10: 最大の予約可能リンク帯域幅
This sub-TLV contains the maximum amount of bandwidth that can be reserved in this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link.
このサブTLVはこのリンクに関するこの方向に控えることができる最大の量の帯域幅を含んでいます。 応募超過目的のために、これがリンクの帯域幅よりすばらしい場合があることに注意してください。
The maximum reservable link bandwidth is encoded in 32 bits in IEEE floating point format. The units are bytes (not bits!) per second.
最大の予約可能リンク帯域幅はIEEE浮動小数点形式における32ビットでコード化されます。 ユニットは1秒あたりバイト(ビットでない!)です。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
このサブTLVは任意です。 可到達性TLVがそれぞれで広げられた大部分にいったんあると、このサブTLV SHOULDは現れます。
Smit & Li Informational [Page 5] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[5ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
3.6. Sub-TLV 11: Unreserved bandwidth
3.6. サブTLV11: 無遠慮な帯域幅
This sub-TLV contains the amount of bandwidth reservable in this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link.
このサブTLVはこのリンクに関するこの方向に帯域幅予約可能の量を含んでいます。 応募超過目的のために、これがリンクの帯域幅よりすばらしい場合があることに注意してください。
Because of the need for priority and preemption, each head end needs to know the amount of reserved bandwidth at each priority level. Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. The units are bytes (not bits!) per second. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub-TLV, and priority 7 at the end of the sub-TLV.
優先権と先取りの必要性のために、各ギヤエンドは、各優先順位で予約された帯域幅の量を知る必要があります。 したがって、このサブTLVは32ビットの8つのIEEE浮動小数点を含んでいます。 ユニットは1秒あたりバイト(ビットでない!)です。 値は0〜7のセットアップ優先で控えることができる帯域幅に対応しています、増加するオーダーでは、サブTLVの端にサブTLVと優先権7つのものの始めに起こる優先権0で、整います。
For stability reasons, rapid changes in the values in this sub-TLV SHOULD NOT cause rapid generation of LSPs.
安定性理由で、このサブTLV SHOULD NOTの値における急激な変化はLSPsの急速な世代を引き起こします。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.
このサブTLVは任意です。 可到達性TLVがそれぞれで広げられた大部分にいったんあると、このサブTLV SHOULDは現れます。
3.7. Sub-TLV 18: Traffic Engineering Default Metric
3.7. サブTLV18: 交通工学デフォルトメートル法です。
This sub-TLV contains a 24-bit unsigned integer. This metric is administratively assigned and can be used to present a differently weighted topology to traffic engineering SPF calculations.
このサブTLVは24ビットの符号のない整数を含んでいます。 割り当てられて、これほどメートル法であることが、行政上そうであり、交通工学SPF計算に異なって荷重しているトポロジーを提示するのに使用できます。
To preclude overflow within a traffic engineering SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
交通工学SPF実現、すべての測定基準の中では、オーバーフローをより排除する、マックス_PATH_METRIC SHALL、aをマックス_PATH_METRICでメートル法にすると考えられてください。 あれほどそんなにマックス_PATHの_のMETRICのプラスのa単一のリンクメートル法でマックス_PATH_METRICを選択するのは最も簡単です。内部のメートル法の計算のためのビットの数から、はみ出しません。 私たちは、これが32ビットであると思います。 したがって、私たちは、42億6141万2864(0xFE000000、2^32--2^25)になるようにマックス_PATH_METRICを選びました。
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV. If a link is advertised without this sub-TLV, traffic engineering SPF calculations MUST use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV.
このサブTLVは任意です。 可到達性TLVがそれぞれで広げられた大部分にいったんあると、このサブTLV SHOULDは現れます。 リンクがこのサブTLVなしで広告に掲載されるなら、交通工学SPF計算はこのリンクにおけるメートル法の正常なデフォルトを使用しなければなりません。(それは、広げることの固定部分に広告を出しているのが、可到達性TLVであるということです)。
4. The Extended IP Reachability TLV
4. 拡張IP可到達性TLV
The extended IP reachability TLV is TLV type 135.
拡張IPの可到達性TLVはTLVタイプ135です。
The existing IP reachability TLVs (TLV type 128 and TLV type 130, defined in RFC 1195 [3]) carry IP prefixes in a format that is analogous to the IS neighbor TLV from ISO 10589 [1]. They carry four metrics, of which only the default metric is commonly used. The
既存のIPの可到達性TLVs、(RFC1195[3])で定義されて、TLVタイプ128とTLVタイプ130はそれが類似している形式でIP接頭語を運んでください、ISO10589[1]からの隣人TLVがそうです。 デフォルトメートル法であることは、一般的にそうです。彼らがどれについて4つの測定基準を運ぶか、唯一、使用されます。 The
Smit & Li Informational [Page 6] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[6ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
default metric has a possible range of 0-63. We would like to remove this restriction.
メートル法でデフォルトとしてください。0-63の可能な範囲を持っています。 この制限を取り除きたいと思います。
In addition, route redistribution (a.k.a. route leaking) has a key problem that was not fully addressed by the existing IP reachability TLVs. RFC 1195 [3] allows a router to advertise prefixes upwards in the level hierarchy. Unfortunately there were no mechanisms defined to advertise prefixes downwards in the level hierarchy.
さらに、ルート再分配(通称ルート漏出)には、既存のIPの可到達性TLVsによって完全に記述されたというわけではない主要な問題があります。 RFC1195[3]は、平らな階層構造で上向きに接頭語の広告を出すためにルータを許容します。 残念ながら、平らな階層構造には下向きに接頭語の広告を出すために定義されたメカニズムが全くありませんでした。
To address these two issues, the proposed extended IP reachability TLV provides for a 32 bit metric and adds one bit to indicate that a prefix has been redistributed 'down' in the hierarchy.
これらの2冊を記述するなら、提案された拡張IPの可到達性TLVは、接頭語が階層構造の再配付された'down'であることを示すためにメートル法で32ビットに備えて、1ビットを加えます。
The proposed extended IP reachability TLV contains a new data structure, consisting of:
以下から成って、提案された拡張IPの可到達性TLVは新しいデータ構造を含んでいます。
4 octets of metric information
1 octet of control information, consisting of
1 bit of up/down information
1 bit indicating the presence of sub-TLVs
6 bits of prefix length
0-4 octet of IPv4 prefix
0-250 optional octets of sub-TLVs, if present consisting of
1 octet of length of sub-TLVs
0-249 octets of sub-TLVs,
where each sub-TLV consists of a sequence of
1 octet of sub-type
1 octet of length of the value field of the sub-TLV
0-247 octets of value
制御情報のメートル法の情報1八重奏の4つの八重奏、上がるか下がることの1ビットから成って、IPv4の接頭語長さ0-4八重奏のサブTLVs6ビットの存在を示すのに噛み付かれた情報1は0-250 サブTLVsのサブTLVs0-249の八重奏の長さの1つの八重奏のサブTLVsの、そして、現在の成ることの任意の八重奏を前に置きます、それぞれのサブTLVが価値のサブTLV0-247の八重奏の値の分野の長さのサブタイプ1つの八重奏の1つの八重奏の系列から成るところで
This data structure can be replicated within the TLV, without exceeding the maximum length of the TLV.
TLVの最大の長さを超えていなくて、TLVの中でこのデータ構造を模写できます。
The 6 bits of prefix length can have the values 0-32 and indicate the number of significant bits in the prefix. The prefix is encoded in the minimal number of octets for the given number of significant bits. This implies:
接頭語の長さの6ビットは、接頭語で値0-32を持って、重要なビットの数を示すことができます。 接頭語は重要なビットの与えられた数のための八重奏の最少数でコード化されます。 これは以下を含意します。
Significant bits Octets
0 0
1-8 1
9-16 2
17-24 3
25-32 4
重要なビットOctets0 0 1-8 1 9-16 2 17-24 3 25-32 4
The remaining bits of prefix are transmitted as zero and ignored upon receipt.
接頭語の残っているビットは、ゼロとして伝えられて、領収書で無視されます。
Smit & Li Informational [Page 7] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[7ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
If a prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered during the normal SPF computation. This allows advertisement of a prefix for purposes other than building the normal IP routing table.
接頭語がメートル法の、より大きい当時の_マックス_PATH METRICと共に広告に掲載されるなら(0xFE000000、パラグラフ3.0を見てください)、通常のSPF計算の間、この接頭語を考えてはいけません。 これは正常なIP経路指定テーブルを組立てるのを除いた目的のための接頭語の広告を許します。
4.1. The up/down Bit
4.1. 上がるか下がるBit
If routers were allowed to redistribute IP prefixes freely in both directions between level 1 and level 2 without any additional mechanisms, those routers would not be able to determine looping of routing information. A problem occurs when a router learns a prefix via level 2 routing and advertises that prefix down into a level 1 area, where another router might pick up the route and advertise the prefix back up into the level 2 backbone. If the original source withdraws the prefix, those two routers might end up having a routing loop between them, where part of the looped path is via level 1 routing and the other part of the looped path is via level 2 routing. The solution that RFC 1195 [3] poses is to allow only advertising prefixes upward in the level hierarchy, and to disallow the advertising of prefixes downward in the hierarchy.
ルータがレベル1とレベル2の間で少しも追加メカニズムなしでIP接頭語を両方の方向に自由に再配付できるなら、それらのルータはルーティング情報のループを決定できないでしょうに。 問題は、ルータがレベル2 ルーティングで接頭語を学ぶとき、起こって、平らな1つの領域にその接頭語の広告を出します。そこでは、別のルータは、ルートを拾って、平らな2背骨に上がっている接頭語後部の広告を出すかもしれません。 一次資料が接頭語を引き下がらせるなら、結局、それらの2つのルータにはそれらの間のルーティング輪があるかもしれません。そこに、輪にされた経路の一部がレベル1 ルーティングであって、輪にされた経路のもう片方の地域はレベル2 ルーティングであります。 RFC1195[3]が引き起こす解決策は、平らな階層構造で上向きに広告接頭語だけを許容して、階層構造で下向きに接頭語の広告を禁じることです。
To prevent this looping of prefixes between levels, a new bit of information is defined in the new extended IP reachability TLV. This bit is called the up/down bit. The up/down bit SHALL be set to 0 when a prefix is first injected into IS-IS. If a prefix is advertised from a higher level to a lower level (e.g. level 2 to level 1), the bit MUST be set to 1, indicating that the prefix has traveled down the hierarchy. Prefixes that have the up/down bit set to 1 may only be advertised down the hierarchy, i.e. to lower levels.
レベルの間の接頭語のこのループを防ぐために、情報の新しいビットは新しい拡張IPの可到達性TLVで定義されます。 このビットは上がるか下がると噛み付かれた呼ばれます。 上/下であるのが0への接頭語がそうであるセットが注がれた1番目であったならSHALLに噛み付いた、- 接頭語が、より高いレベルから下のレベル(例えば、レベル2からレベル1)まで広告に掲載されるなら、1にビットを設定しなければなりません、接頭語が階層構造の下側に移動したのを示して。 1に設定されて、上がるか下がるのに噛み付く接頭語のすなわち、階層構造、下のレベルに広告を出すだけであるかもしれません。
These semantics apply even if IS-IS is extended in the future to have additional levels. By insuring that prefixes follow only the IS-IS hierarchy, we have insured that the information does not loop, thereby insuring that there are no persistent forwarding loops.
これらの意味論が適用される、-、将来、追加レベルを持つために広げられます。 それを保障すると尾行だけが前に置かれる、-、階層構造、私たちは、情報が輪にされないのを保障して、いいえしつこい推進輪はそうであって、その結果、そこでそれを保障します。
If a prefix is advertised from one area to another at the same level, then the up/down bit SHALL be set to 1. This situation can arise when a router implements multiple virtual routers at the same level, but in different areas.
接頭語が同じレベルに1つの領域から別の領域まで広告に掲載されるなら、上がるか下がるのがSHALLに噛み付きました。1に、用意ができています。 ルータが同じレベルで複数の仮想のルータを実行しますが、異なった領域で実行するとき、この状況は起こることができます。
The semantics of the up/down bit in the new extended IP reachability TLV are identical to the semantics of the up/down bit defined in RFC 2966 [2].
上がるか下がることの新しい拡張IPの可到達性TLVで噛み付かれた意味論は上がるか下がることのRFC2966[2]で定義されていた状態で噛み付かれた意味論と同じです。
Smit & Li Informational [Page 8] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[8ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
4.2. Expandability of the Extended IP Reachability TLV with Sub-TLVs
4.2. サブTLVsと拡張IP可到達性TLVの拡張可能性
The extended IP reachability TLV can hold sub-TLVs that apply to a particular prefix. This allows for easy future extensions. If there are no sub-TLVs associated with a prefix, the bit indicating the presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the first octet after the prefix will be interpreted as the length of all sub-TLVs associated with this IPv4 prefix. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall extended IP reachability TLV. The practical maximum is 255 octets minus the 5-9 octets described above, or 250 octets.
拡張IPの可到達性TLVは特定の接頭語に適用するサブTLVsを持つことができます。 これは簡単な今後の拡大を考慮します。 サブTLVs SHALLの存在を示す接頭語、ビットに関連しているどんなサブTLVsもなければ、0に設定されてください。 このビットが1に設定されるなら、接頭語がすべてのサブTLVsの長さとして解釈された後に最初の八重奏はこのIPv4接頭語と交際しました。 コード化がサブTLVsの255の八重奏を考慮している間、最大値は総合的な拡張IPの可到達性TLVをうまくはめ込むことができません。 実用的な最大は、上で説明された5-9の八重奏を引いた255の八重奏、または250の八重奏です。
This document does not define any sub-TLVs for the extended IP reachability TLV.
このドキュメントは拡張IPの可到達性TLVのために少しのサブTLVsも定義しません。
5. The Traffic Engineering Router ID TLV
5. 交通工学Router ID TLV
The Traffic Engineering router ID TLV is TLV type 134.
Traffic EngineeringルータID TLVはTLVタイプ134です。
The router ID TLV contains the 4-octet router ID of the router originating the LSP. This is useful in several regards:
ルータID TLVはLSPを溯源するルータの4八重奏のルータIDを含んでいます。 これはいくつかの点で役に立ちます:
For traffic engineering, it guarantees that we have a single stable address that can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces.
交通工学のために、私たちには遠くの複数のホップから届いている経路でいつも参照をつけることができるただ一つの安定したアドレスがあるのを保証します、ノードのインタフェースの状態にかかわらず。
If OSPF is also active in the domain, traffic engineering can compute the mapping between the OSPF and IS-IS topologies.
そして、また、OSPFもそのドメインでアクティブであるなら、交通工学がOSPFの間のマッピングを計算できる、-、topologies。
If a router does not implement traffic engineering, it MAY add or omit the Traffic Engineering router ID TLV. If a router implements traffic engineering, it MUST include this TLV in its LSP. This TLV SHOULD not be included more than once in an LSP.
ルータが交通工学を実行しないなら、それは、Traffic EngineeringルータID TLVを加えるか、または省略するかもしれません。 ルータが交通工学を実行するなら、それはLSPにこのTLVを含まなければなりません。 このTLV SHOULD、LSPの一度ほど含められないでください。
If a router advertises the Traffic Engineering router ID TLV in its LSP, and if it advertises prefixes via the Border Gateway Protocol (BGP) with the BGP next hop attribute set to the BGP router ID, the Traffic Engineering router ID SHOULD be the same as the BGP router ID.
ルータがLSPにTraffic EngineeringルータID TLVの広告を出して、ボーダ・ゲイトウェイ・プロトコル(BGP)で接頭語の広告を出すなら次のホップ属性がBGPルータID、Traffic EngineeringルータID SHOULDに設定したBGPをもって、BGPルータIDと同じくらいが広告を出すなら
Implementations MUST NOT inject a /32 prefix for the router ID into their forwarding table because this can lead to forwarding loops when interacting with systems that do not support this TLV.
これが、このTLVを支持しないシステムと対話するとき、輪を進めるのに通じることができるので、実現はルータIDのためにそれらの推進テーブルに/32接頭語を注入してはいけません。
Smit & Li Informational [Page 9] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[9ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
6. IANA Considerations
6. IANA問題
6.1. TLV Codepoint Allocations
6.1. TLV Codepoint配分
This document defines the following new IS-IS TLV types, which have been reflected in the ISIS TLV code-point registry:
このドキュメントが新しい状態で以下を定義する、-、IS TLV、タイプ:(タイプはISIS TLVコード・ポイント登録に反映されました)。
Type Description IIH LSP SNP
---- ----------------------------------- --- --- ---
22 The extended IS reachability TLV n y n
134 The Traffic Engineering router ID TLV n y n
135 The extended IP reachability TLV n y n
型記述IIH LSP SNP---- ----------------------------------- --- --- --- 22、広げられて、可到達性TLV n y n134は拡張のTraffic EngineeringルータID TLV n y n135IP可到達性TLV n y nです。
6.2. New Registries
6.2. 新しい登録
IANA has created the following new registries.
IANAは以下の新しい登録を作成しました。
6.2.1. Sub-TLVs for the Extended IS Reachability TLV
6.2.1. 広げるサブTLVsは可到達性TLVです。
This registry contains codepoints for Sub-TLVs of TLV 22. The range of values is 0-255. Allocations within the registry require documentation of the proposed use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]).
この登録はTLV22のSub-TLVsのためのcodepointsを含んでいます。 値の範囲は0-255です。 登録の中の配分はIESGによって割り当てられたDesignated Expertによる割り当てられた値と承認の提案された使用をドキュメンテーションに要求します。([5])を見てください。
Taking into consideration allocations specified in this document, the registry has been initialized as follows:
本書では指定された配分を考慮に入れて、登録は以下の通り初期化されました:
Type Description
---- -----------------------------------
0-2 unassigned
3 Administrative group (color)
4-5 unassigned
6 IPv4 interface address
7 unassigned
8 IPv4 neighbor address
9 Maximum link bandwidth
10 Reservable link bandwidth
11 Unreserved bandwidth
12-17 unassigned
18 TE Default metric
19-254 unassigned
255 Reserved for future expansion
型記述---- ----------------------------------- 4-5に3Administrativeグループ(色)に割り当てられなかった0-2はメートル法の255Reservedが今後の拡大のために割り当てられなかった18TE Default19-254が割り当てられなかった8IPv4隣人アドレス9Maximumリンク帯域幅10Reservableリンク帯域幅11Unreserved帯域幅12-17が割り当てられなかった6IPv4インターフェース・アドレス7を割り当てませんでした。
Smit & Li Informational [Page 10] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[10ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
6.2.2. Sub-TLVs for the Extended IP Reachability TLV
6.2.2. 拡張IP可到達性TLVのためのサブTLVs
This registry contains codepoints for Sub-TLVs of TLV 135. The range of values is 0-255. Allocations within the registry require documentation of the use of the allocated value and approval by the Designated Expert assigned by the IESG (see [5]).
この登録はTLV135のSub-TLVsのためのcodepointsを含んでいます。 値の範囲は0-255です。 登録の中の配分はIESGによって割り当てられたDesignated Expertによる割り当てられた値と承認の使用をドキュメンテーションに要求します。([5])を見てください。
No codepoints are defined in this document.
codepointsは全く本書では定義されません。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] ISO, "Intermediate System to Intermediate System Intra-Domain
Routeing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode Network Service
(ISO 8473)", International Standard 10589:2002, Second Edition
[1]ISO、「プロトコルがあるConjunctionにおける、Providing Connectionless-モードNetwork Service(ISO8473)の使用のためのIntermediate System Intra-ドメインRouteing Exchangeプロトコルへの中間的System」国際規格、10589:2002、Second Edition
[2] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix
Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[2] 李、T.、Przygienda、T.、およびH.スミット、「2レベルとのドメイン全体の接頭語分配、-、」、RFC2966、10月2000日
7.2. Informative References
7.2. 有益な参照
[3] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990
[3]Callon、R.W.、「使用、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在、」、RFC1195、1990年12月
[4] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus,
"Requirements for Traffic Engineering Over MPLS", RFC 2702,
September 1999.
[4]AwducheとD.、マルコムとJ.とAgogbuaとJ.とオデルとM.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
8. Security Considerations
8. セキュリティ問題
This document raises no new security issues for IS-IS.
このドキュメントがどんな新しい安全保障問題も提起しない、-
9. Acknowledgments
9. 承認
The authors would like to thank Yakov Rekhter and Dave Katz for their comments on this work.
作者はこの仕事の彼らのコメントについてヤコフRekhterとデーヴ・キャッツに感謝したがっています。
Smit & Li Informational [Page 11] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[11ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
10. Authors' Addresses
10. 作者のアドレス
Henk Smit
ヘンク・スミット
EMail: hhwsmit@xs4all.nl
メール: hhwsmit@xs4all.nl
Tony Li
トニー・李
EMail: tony.li@tony.li
メール: tony.li@tony.li
Smit & Li Informational [Page 12] RFC 3784 IS-IS extensions for Traffic Engineering June 2004
スミットと李Informational[12ページ]RFC3784、-、Traffic Engineering2004年6月のための拡大
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). 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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Smit & Li Informational [Page 13]
スミットと李Informationalです。[13ページ]
一覧
スポンサーリンク
