RFC5305 日本語訳
5305 IS-IS Extensions for Traffic Engineering. T. Li, H. Smit. October 2008. (Format: TXT=35313 bytes) (Obsoletes RFC3784) (Updated by RFC5307) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Li Request for Comments: 5305 Redback Networks, Inc. Obsoletes: 3784 H. Smit Category: Standards Track October 2008
コメントを求めるワーキンググループT.李の要求をネットワークでつないでください: Inc.が時代遅れにする5305の20ドル紙幣ネットワーク: 3784時間スミットCategory: 標準化過程2008年10月
IS-IS Extensions for Traffic Engineering
-、交通工学のための拡大
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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 Data Units (LSP). 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州プロトコルData Units(LSP)で入賞できるという新情報を指定することによって、議定書を作ってください。 この情報はネットワークの事情に関する交通工学計算の役に立つ追加詳細について説明します。
Li & Smit Standards Track [Page 1] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[1ページ]5305、-、拡大、交通工学2008年10月
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Introducing Sub-TLVs ............................................3
3. The Extended IS Reachability TLV ................................3
3.1. Sub-TLV 3: Administrative Group (color, resource class) ....6
3.2. Sub-TLV 6: IPv4 Interface Address ..........................6
3.3. Sub-TLV 8: IPv4 Neighbor Address ...........................6
3.4. Sub-TLV 9: Maximum Link Bandwidth ..........................7
3.5. Sub-TLV 10: Maximum Reservable Link Bandwidth ..............7
3.6. Sub-TLV 11: Unreserved Bandwidth ...........................7
3.7. Sub-TLV 18: Traffic Engineering Default Metric .............8
4. The Extended IP Reachability TLV ................................8
4.1. The up/down Bit ...........................................10
4.2. Expandability of the Extended IP Reachability TLV
with Sub-TLVs .............................................11
4.3. The Traffic Engineering Router ID TLV .....................11
5. IANA Considerations ............................................12
5.1. TLV Codepoint Allocations .................................12
5.2. New Registries ............................................13
5.2.1. Sub-TLVs for the Extended IS Reachability TLV ......13
5.2.2. Sub-TLVs for the Extended IP Reachability TLV ......15
6. Security Considerations ........................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................15
1. 序論…2 1.1. 要件言語…3 2. サブTLVsを導入します…3 3. 広げるのは可到達性TLVです…3 3.1. サブTLV3: 管理Group(色、リソースのクラス)…6 3.2. サブTLV6: IPv4はアドレスを連結します…6 3.3. サブTLV8: IPv4隣人アドレス…6 3.4. サブTLV9: 最大のリンク帯域幅…7 3.5. サブTLV10: 最大のReservableは帯域幅をリンクします…7 3.6. サブTLV11: 無遠慮な帯域幅…7 3.7. サブTLV18: 交通工学デフォルトメートル法…8 4. 拡張IP可到達性TLV…8 4.1. 上がるか下がるBit…10 4.2. サブTLVsと拡張IP可到達性TLVの拡張可能性…11 4.3. 交通工学Router ID TLV…11 5. IANA問題…12 5.1. TLV Codepoint配分…12 5.2. 新しい登録…13 5.2.1. 広げるサブTLVsは可到達性TLVです…13 5.2.2. 拡張IP可到達性TLVのためのサブTLVs…15 6. セキュリティ問題…15 7. 承認…15 8. 参照…15 8.1. 標準の参照…15 8.2. 有益な参照…15
1. Introduction
1. 序論
The IS-IS protocol is specified in ISO 10589 [ISO-10589], with extensions for supporting IPv4 specified in [RFC1195]. 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.
-、プロトコル、[RFC1195]で指定されたIPv4を支持するための拡大を伴うISO10589[ISO-10589]では、指定されます。 各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 and 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 [RFC2702]. 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。 本書では説明された特性が交通工学[RFC2702]に必要です。 二次目標が、ダイナミックレンジを増加させるのを含んでいる、-、メートル法、そして、IP接頭語のコード化を改良すること。
Li & Smit Standards Track [Page 2] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[2ページ]5305、-、拡大、交通工学2008年10月
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.
特定のルータに参照をつけるのにいつも使用できるただ一つのアドレスについて説明するので、ルータIDは交通工学目的の役に立ちます。
Mechanisms and procedures to migrate to the new TLVs are not discussed in this document.
本書では新しいTLVsにわたるメカニズムと手順について議論しません。
A prior version of this document was published as [RFC3784] with Informational status. This version is on the standards track.
このドキュメントの先のバージョンはInformational状態がある[RFC3784]として発行されました。 標準化過程の上にこのバージョンはあります。
1.1. Requirements Language
1.1. 要件言語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
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 [ISIS-WG]. 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[イシス-WG]によって管理されます。 新しいタイプ値にレビューに続くのを割り当てる、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 [ISO-10589]) 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
存在は可到達性です。(TLVは2をタイプして、[ISO-10589)がシリーズの情報を含むISO10589で定義されているのは、隣人です。 そして各隣人のために、メートル法であることでデフォルトを含む構造があります、遅れ、貨幣原価、信頼性。
Li & Smit Standards Track [Page 3] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[3ページ]5305、-、拡大、交通工学2008年10月
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 [RFC5302] 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.
隣接している隣人の7八重奏のID。 デフォルトメートル法であることは、一般的にそうです。この情報について使用する、使用されます。 デフォルト、メートル法であることが、現在の1ビットがメートル法が内部である、または外部であるかを示すのに使用されている1つの八重奏と、元々未使用である1ビットですが、どれが後で上がるか下がるようになるように[RFC5302]によって定義されたかに噛み付きました。 0-63の可能なメートル法の範囲をもたらして、残っている6ビットは、メートル法で実際を格納するのに使用されます。 この制限は持ち上がりたいと思うという制限の1つです。
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
システムIDとpseudonode番号の7つの八重奏
3 octets of default metric
デフォルトメートル法の3つの八重奏
1 octet of length of sub-TLVs
サブTLVsの長さの1つの八重奏
0-244 octets of sub-TLVs, where each sub-TLV consists of a
sequence of
0-244 それぞれのサブTLVが系列から成るところでのサブTLVsの八重奏
1 octet of sub-type
サブタイプの1つの八重奏
1 octet of length of the Value field of the sub-TLV
サブTLVのValue分野の長さの1つの八重奏
0-242 octets of value
0-242 価値の八重奏
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. There is no defined mechanism for extending the sub-TLV space. Thus, wasting sub-TLV space is discouraged.
したがって、どんなサブTLVsも使用されていないなら、新しいコード化は、11の八重奏を必要として、最大23人の隣人を含むことができます。 お願いします、コード化がサブTLVsの255の八重奏を考慮している間最大値が総合的をうまくはめ込むことができないというメモはそうです。可到達性TLV。 実用的な最大は、上で説明された11の八重奏を引いた255の八重奏、または244の八重奏です。 サブTLVスペースを広げるための定義されたメカニズムが全くありません。 したがって、サブTLVスペースを浪費するのはお勧めできないです。
Li & Smit Standards Track [Page 4] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[4ページ]5305、-、拡大、交通工学2008年10月
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のMetric分野が32ビットの符号のない整数としてコード化されることに注意してください。 これらの異なったサイズが選ばれたので、イントラ領域ルートの費用が相互領域ルートのMetric分野をうまくはめ込むために切り離されなければならないのは、非常にありそうもないです。
To preclude overflow within a traffic engineering Shortest Path First (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).
交通工学Shortest Path First(SPF)実現、すべての測定基準の中では、オーバーフローをより排除する、マックス_PATH_METRIC SHALL、aをマックス_PATH_METRICでメートル法にすると考えられてください。 あれほどそんなにマックス_PATHの_のMETRICのプラスのa単一のリンクメートル法でマックス_PATH_METRICを選択するのは最も簡単です。内部のメートル法の計算のためのビットの数から、はみ出しません。 私たちは、これが32ビットであると思います。 したがって、私たちは、42億6141万2864(0xFE000000、2^32--2^25)になるようにマックス_PATH_METRICを選びました。
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 established here:
あるサブTLVsはここに設立されます:
+------------+----------------+-------------------------------------+ | Sub-TLV | Length | Name | | type | (octets) | | +------------+----------------+-------------------------------------+ | 3 | 4 | Administrative group (color) | | | | | | 6 | 4 | IPv4 interface address | | | | | | 8 | 4 | IPv4 neighbor address | | | | | | 9 | 4 | Maximum link bandwidth | | | | | | 10 | 4 | Maximum 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| 長さ| 名前| | タイプ| (八重奏) | | +------------+----------------+-------------------------------------+ | 3 | 4 | 管理グループ(色)| | | | | | 6 | 4 | IPv4インターフェース・アドレス| | | | | | 8 | 4 | IPv4隣人アドレス| | | | | | 9 | 4 | 最大のリンク帯域幅| | | | | | 10 | 4 | 最大の予約可能リンク帯域幅| | | | | | 11 | 32 | 無遠慮な帯域幅| | | | | | 18 | 3 | TE Defaultメートル法です。| | | | | | 250-254 | | シスコに特定の状態で、予約されます。| | | | 拡大| | | | | | 255 | | 今後の拡大のために、予約されます。| +------------+----------------+-------------------------------------+
Li & Smit Standards Track [Page 5] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[5ページ]5305、-、拡大、交通工学2008年10月
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接頭語を注入してはいけません。
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を含まなければなりません。
Li & Smit Standards Track [Page 6] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[6ページ]5305、-、拡大、交通工学2008年10月
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: 最大のReservableリンク帯域幅
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は現れます。
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は8つの32ビットの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は現れます。
Li & Smit Standards Track [Page 7] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[7ページ]5305、-、拡大、交通工学2008年10月
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 [RFC1195]) carry IP prefixes in a format that is analogous to the IS neighbor TLV from ISO 10589 [ISO-10589]. They carry four metrics, of which only the default metric is commonly used. The default metric has a possible range of 0-63. We would like to remove this restriction.
既存のIPの可到達性TLVs(TLVは128をタイプします、そして、TLVは[RFC1195]で定義された130をタイプする)がそれが類似している形式でIP接頭語を運ぶ、ISO10589[ISO-10589]からの隣人TLVはそうです。 デフォルトメートル法であることは、一般的にそうです。彼らがどれについて4つの測定基準を運ぶか、唯一、使用されます。 メートル法でデフォルトとしてください。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. [RFC1195] 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]は、平らな階層構造で上向きに接頭語の広告を出すためにルータを許容します。 残念ながら、平らな階層構造には下向きに接頭語の広告を出すために定義されたメカニズムが全くありませんでした。
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は、メートル法で32ビットに備えて、接頭語が階層構造の再配付された'down'であることを示すために1ビットを加えます。
Li & Smit Standards Track [Page 8] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[8ページ]5305、-、拡大、交通工学2008年10月
The proposed extended IP reachability TLV contains a new data structure, consisting of:
以下から成って、提案された拡張IPの可到達性TLVは新しいデータ構造を含んでいます。
4 octets of metric information
メートル法の情報の4つの八重奏
1 octet of control information, consisting of
制御情報、成ることの1つの八重奏
1 bit of up/down information
1 /に噛み付かれて、情報より倒してください。
1 bit indicating the presence of sub-TLVs
サブTLVsの存在を示す1ビット
6 bits of prefix length
接頭語の長さの6ビット
0-4 octets of IPv4 prefix
0-4 IPv4接頭語の八重奏
0-250 optional octets of sub-TLVs, if present consisting of
0-250 サブTLVsの、そして、現在の成ることの任意の八重奏
1 octet of length of sub-TLVs
サブTLVsの長さの1つの八重奏
0-249 octets of sub-TLVs, where each sub-TLV consists of a
sequence of
0-249 それぞれのサブTLVが系列から成るところでのサブTLVsの八重奏
1 octet of sub-type
サブタイプの1つの八重奏
1 octet of length of the Value field of the sub-TLV
サブTLVのValue分野の長さの1つの八重奏
0-247 octets of value
0-247 価値の八重奏
This data structure can be replicated within the TLV, as long as the maximum length of the TLV is not exceeded.
TLVの中でこのデータ構造を模写できます、TLVの最大の長さが超えられていない限り。
Li & Smit Standards Track [Page 9] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[9ページ]5305、-、拡大、交通工学2008年10月
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 |
+------------------+--------+
+------------------+--------+ | 重要なビット| 八重奏| +------------------+--------+ | 0 | 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.
接頭語の残っているビットは、ゼロとして伝えられて、領収書で無視されます。
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 [RFC1195] 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]が引き起こす解決策は、平らな階層構造で上向きに広告接頭語だけを許容して、階層構造で下向きに接頭語の広告を禁じることです。
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
レベルの間の接頭語のこのループを防ぐために、情報の新しいビットは新しい拡張IPの可到達性TLVで定義されます。 このビットは上がるか下がると噛み付かれた呼ばれます。 上/下であるのが0への接頭語がそうであるセットが注がれた1番目であったならSHALLに噛み付いた、- 接頭語が、より高いレベルから下のレベルまで広告に掲載されている、(例えば、2を平らにします。
Li & Smit Standards Track [Page 10] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[10ページ]5305、-、拡大、交通工学2008年10月
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.
レベル1) 接頭語が階層構造の下側に移動したのを示して、1にビットを設定しなければなりません。 すなわち、レベルを下げるために1に設定されて、上がるか下がるのに噛み付く接頭語の階層構造の下側に広告を出すだけであるかもしれません。
These semantics apply even if IS-IS is extended in the future to have additional levels. By ensuring that prefixes follow only the IS-IS hierarchy, we have ensured that the information does not loop, thereby ensuring 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 [RFC5302].
上がるか下がることの新しい拡張IPの可到達性TLVで噛み付かれた意味論は上がるか下がることの[RFC5302]で定義されていた状態で噛み付かれた意味論と同じです。
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も定義しません。
4.3. The Traffic Engineering Router ID TLV
4.3. 交通工学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.
交通工学のために、私たちには遠くの複数のホップから届いている経路でいつも参照をつけることができるただ一つの安定したアドレスがあるのを保証します、ノードのインタフェースの状態にかかわらず。
Li & Smit Standards Track [Page 11] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[11ページ]5305、-、拡大、交通工学2008年10月
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接頭語を注入してはいけません。
5. IANA Considerations
5. IANA問題
Prior IANA requests for this purpose were covered as part of [RFC3784]. The text of those requests is reproduced here for completeness and consistency.
先のIANA要求は[RFC3784]の一部としてこのためにカバーされていました。 それらの要求のテキストは完全性と一貫性のためにここで複製されます。
5.1. TLV Codepoint Allocations
5.1. TLV Codepoint配分
This document defines the following new IS-IS TLV types, which have been reflected in the ISIS TLV codepoint registry:
このドキュメントが新しい状態で以下を定義する、-、IS TLV、タイプ:(タイプはイシスTLV codepoint登録に反映されました)。
+------+---------------------------------------+-----+-----+-----+ | 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| n| | | | | | | | 134 | Traffic EngineeringルータID TLV| n| y| n| | | | | | | | 135 | 拡張IPの可到達性TLV| n| y| n| +------+---------------------------------------+-----+-----+-----+
Li & Smit Standards Track [Page 12] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[12ページ]5305、-、拡大、交通工学2008年10月
5.2. New Registries
5.2. 新しい登録
IANA has created the following new registries.
IANAは以下の新しい登録を作成しました。
5.2.1. Sub-TLVs for the Extended IS Reachability TLV
5.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 [RFC5226]).
この登録はTLV22のサブTLVsのためのcodepointsを含んでいます。 値の範囲は0-255です。 登録の中の配分はIESGによって割り当てられたDesignated Expertによる割り当てられた値と承認の提案された使用のドキュメンテーションを必要とします([RFC5226]を見てください)。
Taking into consideration allocations specified in this document, the registry has been initialized as follows:
本書では指定された配分を考慮に入れて、登録は以下の通り初期化されました:
Li & Smit Standards Track [Page 13] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[13ページ]5305、-、拡大、交通工学2008年10月
+--------+------------------------------------+
| Type | Description |
+--------+------------------------------------+
| 0-2 | unassigned |
| | |
| 3 | Administrative group (color) |
| | |
| 4 | Link Local/Remote Identifiers |
| | |
| 5 | unassigned |
| | |
| 6 | IPv4 interface address |
| | |
| 7 | unassigned |
| | |
| 8 | IPv4 neighbor address |
| | |
| 9 | Maximum link bandwidth |
| | |
| 10 | Maximum Reservable link bandwidth |
| | |
| 11 | Unreserved bandwidth |
| | |
| 12-17 | unassigned |
| | |
| 18 | TE Default metric |
| | |
| 19 | Link-attributes |
| | |
| 20 | Link Protection Type |
| | |
| 21 | Interface Switching Capability |
| | Descriptor |
| | |
| 22 | Bandwidth Constraints |
| | |
| 23-249 | unassigned |
| | |
| 250-254| Reserved for Cisco specific |
| | extensions |
| | |
| 255 | Reserved for future expansion |
+--------+------------------------------------+
+--------+------------------------------------+ | タイプ| 記述| +--------+------------------------------------+ | 0-2 | 割り当てられません。| | | | | 3 | 管理グループ(色)| | | | | 4 | 地方の、または、リモートな識別子をリンクしてください。| | | | | 5 | 割り当てられません。| | | | | 6 | IPv4インターフェース・アドレス| | | | | 7 | 割り当てられません。| | | | | 8 | IPv4隣人アドレス| | | | | 9 | 最大のリンク帯域幅| | | | | 10 | 最大のReservableリンク帯域幅| | | | | 11 | 無遠慮な帯域幅| | | | | 12-17 | 割り当てられません。| | | | | 18 | TE Defaultメートル法です。| | | | | 19 | リンク属性| | | | | 20 | リンク保護タイプ| | | | | 21 | インタフェーススイッチング能力| | | 記述子| | | | | 22 | 帯域幅規制| | | | | 23-249 | 割り当てられません。| | | | | 250-254| シスコに特定の状態で、予約されます。| | | 拡大| | | | | 255 | 今後の拡大のために、予約されます。| +--------+------------------------------------+
Li & Smit Standards Track [Page 14] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[14ページ]5305、-、拡大、交通工学2008年10月
5.2.2. Sub-TLVs for the Extended IP Reachability TLV
5.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 [RFC5226]). No codepoints are defined in this document.
この登録はTLV135のサブTLVsのためのcodepointsを含んでいます。 値の範囲は0-255です。 登録の中の配分はIESGによって割り当てられたDesignated Expertによる割り当てられた値と承認の使用のドキュメンテーションを必要とします([RFC5226]を見てください)。 codepointsは全く本書では定義されません。
6. Security Considerations
6. セキュリティ問題
This document raises no new security issues for IS-IS; for general security considerations for IS-IS see [RFC5304].
このドキュメントがどんな新しい安全保障問題も提起しない、-、。 総合証券問題、-、[RFC5304]を見てください。
7. Acknowledgements
7. 承認
The authors would like to thank Yakov Rekhter and Dave Katz for their comments on this work. This work was funded in part by Procket Networks and Juniper Networks.
作者はこの仕事の彼らのコメントについてヤコフRekhterとデーヴ・キャッツに感謝したがっています。 この仕事はProcket NetworksとJuniper Networksによって一部資金を供給されました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[ISO-10589] ISO, "Intermediate System to Intermediate System intra-
domain routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)",
International Standard 10589: 2002, Second Edition, 2002.
[ISO-10589]ISO、「Intermediate Systemイントラドメインrouteing情報交換への中間的Systemは使用のためにコネクションレスなモードネットワーク・サービス(ISO8473)を提供するためのプロトコルに関連して議定書を作ります」、国際規格10589: 2002 第2版、2002。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix
Distribution with Two-Level IS-IS", RFC 5302, October
2008.
[RFC5302] 李、T.、スミット、H.、およびT.Przygienda、「2レベルとのドメイン全体の接頭語分配、-、」、RFC5302、10月2008日
8.2. Informative References
8.2. 有益な参照
[ISIS-WG] IS-IS for IP Internets (isis)
<http://www.ietf.org/html.charters/isis-charter.html>
[イシス-WG]、-、IPインターネット(isis)<http://www.ietf.org/html.charters/isis-charter.html>。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC1195]Callon、R.、「使用、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在、」、RFC1195、12月1990日
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[RFC2702]AwducheとD.とマルコムとJ.とAgogbuaとJ.とオデル、M.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
Li & Smit Standards Track [Page 15] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[15ページ]5305、-、拡大、交通工学2008年10月
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC3784] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(2004年6月)
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5226] Narten、T.、およびH.Alvestrand(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[RFC5304] 李、T.、およびR.アトキンソン、「-、暗号の認証、」、RFC5304、10月2008日
Authors' Addresses
作者のアドレス
Tony Li Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 USA
トニー李RedbackがInc.300オルガーWayサンノゼ(カリフォルニア)95134をネットワークでつなぐ、米国
Phone: +1 408 750 5160 EMail: tony.li@tony.li
以下に電話をしてください。 +1 5160年の408 750メール: tony.li@tony.li
Henk Smit
ヘンク・スミット
EMail: hhw.smit@xs4all.nl
メール: hhw.smit@xs4all.nl
Li & Smit Standards Track [Page 16] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008
李とスミットStandardsがRFCを追跡する、[16ページ]5305、-、拡大、交通工学2008年10月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Li & Smit Standards Track [Page 17]
李とスミット標準化過程[17ページ]
一覧
スポンサーリンク
