RFC5120 日本語訳
5120 M-ISIS: Multi Topology (MT) Routing in Intermediate System toIntermediate Systems (IS-ISs). T. Przygienda, N. Shen, N. Sheth. February 2008. (Format: TXT=30318 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Przygienda
Request for Comments: 5120 Z2 Sagl
Category: Standards Track N. Shen
Cisco Systems
N. Sheth
Juniper Networks
February 2008
Przygiendaがコメントのために要求するワーキンググループT.をネットワークでつないでください: 5120年のZ2 Saglカテゴリ: 規格は2008年2月にN.シンシスコシステムズN.Sheth杜松ネットワークを追跡します。
M-ISIS: Multi Topology (MT) Routing in
Intermediate System to Intermediate Systems (IS-ISs)
Mイシス: 中間システムへの中間システムのマルチトポロジー(MT)ルート設定(-、ISs、)
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 an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology.
このドキュメントがIntermediate Systemの中で任意のメカニズムについてIntermediate Systemsに説明する、(-、ISs、)、今日、それらの雲の中で多くのISPによってIGPルーティングにおいて使用されています。 このドキュメントが中へ走る方法を説明する、シングル、-、ドメイン、私たちがMulti-Topologies(MTs)と呼ぶ独立しているIP topologiesの1セット。 「先端」のバンドにおけるマネジメント・ネットワークなどのさまざまな目的に元のIGPトポロジーについてこのMT拡張子を使用できます、孤立しているマルチキャストのための別々のIGP経路ドメインか背骨、または続くアドレス空間の部分集合を強制する中のIPv6島が異なったトポロジーであると主張して。
1. Introduction
1. 序論
Maintaining multiple MTs for IS-IS [ISO10589] [RFC1195] in a backwards-compatible manner necessitates several extensions to the packet encoding and additional Shortest Path First (SPF) procedures. The problem can be partitioned into the forming of adjacencies and advertising of prefixes and reachable intermediate systems within each topology. Having put all the necessary additional information in place, it must be properly used by MT capable SPF computation. The following sections describe each of the problems separately. To simplify the text, "standard" IS-IS topology is defined to be MT ID #0 (zero).
複数のMTsを維持する、-、後方にコンパチブル方法による[ISO10589][RFC1195]はパケットコード化していて追加しているShortest Path First(SPF)手順にいくつかの拡大を必要とします。 各トポロジーの中で隣接番組の形成と接頭語と届いている中間システムの広告に問題を仕切ることができます。 すべての必要な追加情報を適所に置いたので、MTのできるSPF計算で適切にそれを使用しなければなりません。 以下のセクションは別々にそれぞれの問題について説明します。 「標準」でテキストを簡素化する、-、トポロジー、MT ID#0(ゼロ)になるように、定義されます。
Przygienda, et al. Standards Track [Page 1] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[1ページ]。
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 RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2. Definitions of Terms Used in This Document
1.2. 本書では使用される用語の定義
CSNP Complete Sequence Number Packet. Used to describe all the
contents of a link state database of IS-IS.
CSNPは一連番号パケットを完成します。 リンク州のデータベースのすべてのコンテンツについて説明するのにおいて中古である、-
DIS Designated Intermediate System. The intermediate system elected
to advertise the pseudo-node for a broadcast network.
指定された中間システムをけなしてください。 中間システムは、放送網のための疑似ノードの広告を出すのを選びました。
IIH IS-IS Hello. Packets that are used to discover adjacent
intermediate systems.
IIH、-、こんにちは。 隣接している中間システムを発見するのに使用されるパケット。
LSP Link State Packet. Packet generated by an intermediate system
and lists adjacent systems, prefixes, and other information.
LSPは州のパケットをリンクします。 パケットは、システム、接頭語、および他の情報中間システムで発生して、記載しました。
PSNP Partial Sequence Number Packet. Used to request information
from an adjacent intermediate system's link state database.
PSNPの部分的な一連番号パケット。 隣接している中間システムのリンク州のデータベースから情報を要求するのにおいて、使用されています。
SPF Shortest Path First. An algorithm that takes a database of
nodes within a domain and builds a tree of connectivity along
the shortest paths through the entire network.
SPF最短パス1番目。 ドメインの中でノードに関するデータベースを取って、全体のネットワークを通して最短パスに沿って接続性の木を建てるアルゴリズム。
2. Maintaining MT Adjacencies
2. MT隣接番組を維持します。
Each adjacency formed MUST be classified as belonging to a set of MTs on the interface. This is achieved by adding a new TLV into IIH packets that advertises to which topologies the interface belongs. If MT #0 is the only MT on the interface, it is optional to advertise it in the new TLV. Thus, not including such a TLV in the IIH implies MT ID #0 capability only. Through this exchange of MT capabilities, a router is able to advertise the IS TLVs in LSPs with common MT set over those adjacencies.
インタフェースのMTsの1セットに属すとして形成された各隣接番組を分類しなければなりません。 IIHパケットへのどのtopologiesにインタフェースの広告を出す新しいTLVが属すると言い足すことによって、これは達成されます。 MT#0がインタフェースの唯一のMTであるなら、新しいTLVにそれの広告を出すのは任意です。 したがって、IIHにそのようなTLVを含んでいないと、MT ID#0能力だけが含意されます。 MT能力のこの交換を通して、ルータが広告を出すことができる、それらの隣接番組の上に設定された一般的なMTとLSPsのTLVsはそうです。
The case of adjacency contains multiple MTs on an interface, and if there exists an overlapping IP address space among the topologies, additional mechanisms MUST be used to resolve the topology identity of the incoming IP packets on the interface. See further discussion in Section 8.2.2 of this document.
隣接番組に関するケースはインタフェースに複数のMTsを含んでいます、そして、重なっているIPアドレス空間がtopologiesの中に存在しているなら、インタフェースの入って来るIPパケットのトポロジーのアイデンティティを決議するのに追加メカニズムを使用しなければなりません。 この.2通のセクション8.2ドキュメントにおけるさらなる議論を見てください。
Przygienda, et al. Standards Track [Page 2] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[2ページ]。
2.1. Forming Adjacencies on Point-to-Point Interfaces
2.1. 二地点間インタフェースに隣接番組を形成します。
Adjacencies on point-to-point interfaces are formed as usual with IS-IS routers not implementing MT extensions. If a local router does not participate in certain MTs, it will not advertise those MT IDs in its IIHs and thus will not include that neighbor within its LSPs. On the other hand, if an MT ID is not detected in the remote side's IIHs, the local router MUST NOT include that neighbor within its LSPs. The local router SHOULD NOT form an adjacency if they don't have at least one common MT over the interface.
二地点間インタフェースの隣接番組がいつものように形成される、-、MT拡大を実行しないルータ。 ローカルルータが、あるMTsに参加しないと、それは、IIHsにそれらのMT IDの広告を出さないで、またその結果、LSPsの中にその隣人を含まないでしょう。 他方では、MT IDが遠隔地側のIIHsに検出されないなら、ローカルルータはLSPsの中にその隣人を含んではいけません。 彼らがインタフェースの上に少なくとも1の一般的なMTを持っていないなら、ローカルルータSHOULD NOTは隣接番組を形成します。
2.2. Forming Adjacencies on Broadcast Interfaces
2.2. 放送インタフェースに隣接番組を形成します。
On a LAN, all the routers on the LAN that implement the MT extension MAY advertise their MT capability TLV in their IIHs. If there is at least one adjacency on the LAN interface that belongs to this MT, the MT capable router MUST include the corresponding MT IS Reachable TLV in its LSP, otherwise it MAY include this MT IS Reachable TLV in its LSP if the LAN interface participates in this MT set.
LANでは、LANのMT拡大を実行するすべてのルータがそれらのIIHsに彼らのMT能力TLVの広告を出すかもしれません。 少なくとも1つの隣接番組ができるルータが含まなければならないこのMT(MT)に属すLANインタフェースにあれば対応するMTがLSPのReachable TLVである、さもなければ、それは包含するかもしれません。LANインタフェースがこのMTセットに参加するなら、このMTはLSPのReachable TLVです。
Two routers on a LAN SHALL always establish adjacency, regardless of whether or not they have a common MT. This is to ensure all the routers on the LAN can correctly elect the same DIS. The IS SHOULD NOT include the MT IS TLV in its LSP if none of the adjacencies on the LAN contain this MT.
LAN SHALLの上の2つのルータがいつも隣接番組を確立します、それらに一般的なMTがあるかどうかにかかわらず。これは、LANのすべてのルータが正しく同じDISを選出できるのを保証するためのものです。 LANの隣接番組のいずれもこのMTを含んでいないなら、IS SHOULD NOTはLSPにMT IS TLVを含んでいます。
The DIS, CSNP, and PSNP functions are not changed by MT extension.
DIS、CSNP、およびPSNP機能はMT拡大で変えられません。
3. Advertising MT Reachable Intermediate Systems in LSPs
3. LSPsにMTの届いている中間システムの広告を出します。
A router MUST include within its LSPs in the Reachable Intermediate Systems TLV-only adjacent nodes that are participating in the corresponding topology and advertise such TLVs only if it participates itself in the corresponding topology. The Standard Reachable Intermediate Systems TLV is acting here as MT ID #0, the equivalent of the newly introduced MT Reachable Intermediate Systems TLV. A router MUST announce the MT IS TLV when there is at least one adjacency on the interface that belongs to this MT, otherwise it MAY announce the MT IS TLV of an adjacency for a given MT if this interface participates in the LAN.
ルータは、対応するトポロジーに参加していて、そのようなTLVsの広告を出すReachable Intermediate Systems TLV唯一の隣接しているノードのLSPsの中にそれがそれ自体で対応するトポロジーに関与するだけであるかどうかを含まなければなりません。 Standard Reachable Intermediate Systems TLVはMT ID#0としてここで機能しています、新たに導入されたMT Reachable Intermediate Systems TLVの同等物。 ルータは、少なくとも1つの隣接番組がそうでなければ、このMT、それに属すインタフェースにあるとき、このインタフェースがLANに参加するならMT IS TLVが隣接番組のMT IS TLVを与えられたMTに発表するかもしれないと発表しなければなりません。
Since it is not possible to prevent a router that does not understand MT extensions from being responsible for the generation of the according pseudo-node, it is possible to neither introduce special TLVs in the pseudo-node LSPs, nor run distinct DIS elections per MT. Therefore, a generated pseudo-node LSP by DIS MUST contain
一致している疑似ノードの世代のためにMT拡大を理解していないルータが原因となるのを防ぐのが可能でないので、疑似ノードLSPsで特別なTLVsを導入しないで、またMT単位で異なったDIS選挙を管理しないのは可能です。したがって、aはDIS MUSTによるLSPが含む疑似ノードを作りました。
Przygienda, et al. Standards Track [Page 3] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[3ページ]。
in its IS Reachable TLV all nodes on the LAN as usual, regardless of their MT capabilities. In other words, there is no change to the pseudo-node LSP construction.
中、それ、Reachable TLVはすべて、彼らのMT能力にかかわらず通常通りのLANのノードですか? 言い換えれば、疑似ノードLSP工事への変化が全くありません。
4. MTs and Overload, Partition, and Attached Bits
4. MTs、オーバーロード、パーティション、および付属ビット
For each of the MTs, a router could become potentially partitioned, overloaded, and attached independently. To prevent unnecessary complexity, MT extensions do not support MT based partition repair. The overload, partition, and attached bits in the LSP header only reflect the status of the default topology.
それぞれのMTsに関しては、ルータは、独自に潜在的に仕切られて、積みすぎられるようになることができて、付きました。 不要な複雑さを防ぐために、MT拡大はMTのベースのパーティション修理を支持しません。 LSPヘッダーのオーバーロード、パーティション、および付属ビットはデフォルトトポロジーの状態を反映するだけです。
Attached bit and overload bit are part of the MT TLV being distributed within a node's LSP fragment zero. Since each adjacency can belong to different MTs, it is possible that some MTs are L2 attached, and others are not on the same router. The overload bit in the MT TLV can be used to signal the topology being overloaded. An MT-based system is considered overloaded if the overload bit in the MT is set.
付属ビットとオーバーロードビットはノードのLSP断片ゼロの中に分配されるMT TLVの一部です。 各隣接番組が異なったMTsに属すことができるので、いくつかのMTsが添付のL2であり、他のものが同じルータにいないのは、可能です。 積みすぎられるトポロジーに合図するのにMT TLVのオーバーロードビットを使用できます。 MTのオーバーロードビットが設定されるなら、MTベースのシステムは積みすぎられると考えられます。
Route leaking between the levels SHOULD only be performed within the same MT.
レベルSHOULDの間に漏出を発送してください。同じMTの中で実行されるだけです。
5. Advertising MT Specific IP Prefixes
5. MTの特定のIPが前に置く広告
Each of the MTs commands its own address space so a new TLV is necessary for prefixes stored in MTs other than MT ID #0. To make the encoding less confusing when same prefixes are present in multiple MTs and accelerate SPF per MT, rather than adding a sub-TLV in Traffic Engineered (TE) extensions, a new TLV is introduced for that purpose that closely follows TE encoding [RFC3784].
それぞれのMTsがそれ自身のアドレス空間を命令するので、新しいTLVがMT ID#0以外のMTsに格納された接頭語に必要です。 同じ接頭語が存在しているとき、複数のMTsでコード化をより紛らわしくなくして、サブTLVを加えるよりTraffic Engineered(TE)拡張子で1MTあたりのSPFをむしろ加速するために、密接に[RFC3784]をコード化するTEに続くその目的のために新しいTLVを導入します。
6. MT SPF Computation
6. MT SPF計算
Each MT MUST run its own instance of the decision process. The pseudo-node LSPs are used by all topologies during computation. Each non-default topology MAY have its attached bit and overload bit set in the MT TLV. A reverse-connectivity check within SPF MUST follow the according MT to assure the bi-directional reachability within the same MT.
各MTはそれ自身の決定の過程の例を走らせなければなりません。 疑似ノードLSPsは計算の間、すべてのtopologiesによって使用されます。 それぞれの非デフォルトトポロジーで、MT TLVにその付属ビットとオーバーロードビットを設定するかもしれません。 同じMTの中で双方向の可到達性を保証するSPF MUST尾行の一致しているMTの中の逆の接続性チェック。
The results of each computation SHOULD be stored in a separate Routing Information Base (RIB), in normal cases, otherwise overlapping addresses in different topologies could lead to undesirable routing behavior, such as forwarding loops. The forwarding logic and configuration need to ensure the same MT is traversed from the source to the destination for packets. The nexthops derived from the MT SPF MUST belong to the adjacencies
別々の経路情報基地(RIB)の中に正常な場合で格納されて、そうでなければ、異なったtopologiesでアドレスを重ね合わせると推進などの望ましくないルーティングの振舞いに導くことができた各計算SHOULDの結果は輪にされます。 推進論理と構成は、同じMTがパケットのためにソースから目的地まで横断されるのを保証する必要があります。 MT SPF MUSTから得られたnexthopsは隣接番組に属します。
Przygienda, et al. Standards Track [Page 4] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[4ページ]。
conforming to the same MT for correct forwarding. It is recommended for the administrators to ensure consistent configuration of all routers in the domain to prevent undesirable forwarding behavior.
正しい推進のための同じMTに従います。 管理者が望ましくない推進の振舞いを防ぐためにそのドメインでのすべてのルータの一貫した構成を保証するのは、お勧めです。
No attempt is made in this document to allow one topology to calculate routes using the routing information from another topology inside SPF. Even though it is possible to redistribute and leak routes from another IS-IS topology or from external sources, the exact mechanism is beyond the scope of this document.
SPFの中で別のトポロジーからのルーティング情報を使用することでルートを計算するために1つのトポロジーを許容するために本書では試みを全くしません。 または、それがルートを再配付して、漏らすのにおいて可能である、別のもの、-、トポロジー、外部電源から、正確なメカニズムはこのドキュメントの範囲を超えて来ています。
7. Packet Encoding
7. パケットコード化
Four new TLVs are added to support MT extensions. One of them is common for the LSPs and IIHs. Encoding of Intermediate System TLV and IPv4 Reachable Prefixes is tied to traffic engineering extensions [RFC3784] to simplify the implementation effort. The main reasons we chose to use new TLVs instead of using sub-TLVs inside existing TLV type-22 and type-135 are:
4新しいTLVsが、MT拡大を支持するために加えられます。 LSPsとIIHsに、それらの1つは一般的です。 Intermediate System TLVとIPv4 Reachable Prefixesのコード化は、実現の努力を簡素化するために交通工学拡大[RFC3784]に結ばれます。 私たちが、既存のTLVタイプ-22とタイプ-135にサブTLVsを使用することの代わりに新しいTLVsを使用するのを選んだ主な理由は以下の通りです。
1. In many cases, multi-topologies are non-congruent, using the
sub-TLV approach will not save LSP space;
1. アプローチが取っておかないサブTLV LSPスペースを使用して、多くの場合、マルチtopologiesは非一致しています。
2. Many sub-TLVs are already being used in TLV type-22, and many
more are being proposed while there is a maximum limit on the
TLV size, from the existing TLVs;
2. 多くのサブTLVsがTLVタイプ-22に既に使用されています、そして、最大の限界がTLVサイズにある間、ずっと多くは提案されています、既存のTLVsから。
3. If traffic engineering or some other applications are being
applied per topology level later, the new TLVs can
automatically inherit the same attributes already defined for
the "standard" topology without going through long standard
process to redefine them per topology.
3. 交通工学かある他のアプリケーションが後でトポロジーレベル単位で適用される予定であるなら、新しいTLVsは自動的に長い標準の過程に直面していることのない「標準」のトポロジーがトポロジー単位でそれらを再定義するように既に定義された同じ属性を引き継ぐことができます。
7.1. Multi-Topology TLV
7.1. マルチトポロジーTLV
The TLV number of this TLV is 229. It contains one or more MTs; the router is participating in the following structure:
このTLVのTLV番号は229です。 それは1MTsを含んでいます。 ルータは以下の構造に参加しています:
x CODE - 229
x LENGTH - total length of the value field, it SHOULD be 2
times the number of MT components.
x VALUE - one or more 2-byte MT components, structured
as follows:
No. of Octets
+--------------------------------+
|O |A |R |R | MT ID | 2
+--------------------------------+
x CODE--229 x LENGTH--値の分野の全長、それ、SHOULD、MTコンポーネント以下の1つ以上の2バイトのMTコンポーネントであって、構造化された数の2倍のx VALUEになってください: 八重奏+についていいえ--------------------------------+ |O|A|R|R| MT ID| 2 +--------------------------------+
Przygienda, et al. Standards Track [Page 5] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[5ページ]。
Bit O represents the OVERLOAD bit for the MT (only valid in LSP
fragment zero for MTs other than ID #0, otherwise SHOULD be set to
0 on transmission and ignored on receipt).
ビットOはMT(ID#0、を除いたMTs、そうでなければトランスミッションのときに0に用意ができて、無視されたSHOULDに、領収書で単にLSP断片ゼロで有効な)にOVERLOADビットを表します。
Bit A represents the ATTACH bit for the MT (only valid in LSP
fragment zero for MTs other than ID #0, otherwise SHOULD be set to
0 on transmission and ignored on receipt).
ビットAはMT(ID#0、を除いたMTs、そうでなければトランスミッションのときに0に用意ができて、無視されたSHOULDに、領収書で単にLSP断片ゼロで有効な)にATTACHビットを表します。
Bits R are reserved, SHOULD be set to 0 on transmission and
ignored on receipt.
SHOULD、ビットRは予約されています。トランスミッションのときに0にセットして、領収書の上で無視されます。
MT ID is a 12-bit field containing the ID of the topology being
announced.
MT IDは発表されるトポロジーのIDを含む12ビットの分野です。
This MT TLV can advertise up to 127 MTs. It is announced in IIHs and LSP fragment 0, and can occur multiple times. The resulting MT set SHOULD be the union of all the MT TLV occurrences in the packet. Any other IS-IS PDU occurrence of this TLV MUST be ignored. Lack of MT TLV in hellos and fragment zero LSPs MUST be interpreted as participation of the advertising interface or router in MT ID #0 only. If a router advertises MT TLV, it has to advertise all the MTs it participates in, specifically including topology ID #0 also.
このMT TLVは最大127MTsの広告を出すことができます。 それは、IIHsとLSP断片0で発表されて、複数の回起こることができます。 結果として起こるMTはすべての組合がパケットでのMT TLV発生であったならSHOULDを設定しました。 いかなる他のも-、IS PDU、発生、このTLV MUSTでは、無視されてください。 広告インタフェースかルータコネMT ID#0の参加だけとしてhellosと断片ゼロLSPsのMT TLVの不足を解釈しなければなりません。 ルータがMT TLVの広告を出すなら、参加するすべてのMTsの広告を出さなければなりません、明確にトポロジーID#0も含んでいて。
7.2. MT Intermediate Systems TLV
7.2. MT中間システムTLV
The TLV number of this TLV is 222. It is aligned with extended IS reachability TLV type 22 beside an additional two bytes in front at the beginning of the TLV.
このTLVのTLV番号は222です。 広げられるのに並べられているのが、TLVの始めの前部の追加2バイトの横の可到達性TLVタイプ22であるということです。
x CODE - 222
x LENGTH - total length of the value field
x VALUE - 2-byte MT membership plus the format of extended IS
reachability TLV, structured as follows:
No. of Octets
+--------------------------------+
|R |R |R |R | MT ID | 2
+--------------------------------+
| extended IS TLV format | 11 - 253
+--------------------------------+
. .
. .
+--------------------------------+
| extended IS TLV format | 11 - 253
+--------------------------------+
x CODE--222 x LENGTH--値の分野x VALUEの全長--2バイトのMT会員資格と広げられることの形式は以下の通り構造化された可到達性TLVです: 八重奏+についていいえ--------------------------------+ |R|R|R|R| MT ID| 2 +--------------------------------+ | 拡張IS TLV形式| 11 - 253 +--------------------------------+ . . . . +--------------------------------+ | 拡張IS TLV形式| 11 - 253 +--------------------------------+
Bits R are reserved, SHOULD be set to 0 on transmission and
ignored on receipt.
SHOULD、ビットRは予約されています。トランスミッションのときに0にセットして、領収書の上で無視されます。
Przygienda, et al. Standards Track [Page 6] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[6ページ]。
MT ID is a 12-bit field containing the non-zero MT ID of the
topology being announced. The TLV MUST be ignored if the ID is
zero. This is to ensure the consistent view of the standard
unicast topology.
MT IDは発表されるトポロジーの非ゼロMT IDを含む12ビットの分野です。 TLV MUST、IDがゼロであるなら、無視されてください。 これは、標準のユニキャストトポロジーの一貫した視点を確実にするためのものです。
After the 2-byte MT membership format, the MT IS content is in the
same format as extended IS TLV, type 22 [RFC3784]. It can contain
up to 23 neighbors of the same MT if no sub-TLVs are used.
2バイトのMT会員資格形式、MTがそうであるのになった後に、拡張IS TLVと同じ形式には内容があります、と22[RFC3784]はタイプします。 どんなサブTLVsも使用されていないなら、それは同じMTの最大23人の隣人を含むことができます。
This TLV can occur multiple times.
このTLVは複数の回起こることができます。
7.3. Multi-Topology Reachable IPv4 Prefixes TLV
7.3. マルチトポロジーの届いているIPv4はTLVを前に置きます。
The TLV number of this TLV is 235. It is aligned with extended IP reachability TLV type 135 beside an additional two bytes in front.
このTLVのTLV番号は235です。 それは前部の追加2バイトの横で拡張IP可到達性TLVタイプ135に並べられます。
x CODE - 235
x LENGTH - total length of the value field
x VALUE - 2-byte MT membership plus the format of
extended IP reachability TLV, structured as follows:
x CODE--235 x LENGTH--値の分野x VALUEの全長--2バイトのMT会員資格と以下の通り構造化された拡張IPの可到達性TLVの形式:
No. of Octets
+--------------------------------+
|R |R |R |R | MT ID | 2
+--------------------------------+
| extended IP TLV format | 5 - 253
+--------------------------------+
. .
. .
+--------------------------------+
| extended IP TLV format | 5 - 253
+--------------------------------+
八重奏+についていいえ--------------------------------+ |R|R|R|R| MT ID| 2 +--------------------------------+ | 拡張IP TLV形式| 5 - 253 +--------------------------------+ . . . . +--------------------------------+ | 拡張IP TLV形式| 5 - 253 +--------------------------------+
Bits R are reserved, SHOULD be set to 0 on transmission and
ignored on receipt.
SHOULD、ビットRは予約されています。トランスミッションのときに0にセットして、領収書の上で無視されます。
MT ID is a 12-bit field containing the non-zero ID of the topology
being announced. The TLV MUST be ignored if the ID is zero. This
is to ensure the consistent view of the standard unicast topology.
MT IDは発表されるトポロジーの非ゼロIDを含む12ビットの分野です。 TLV MUST、IDがゼロであるなら、無視されてください。 これは、標準のユニキャストトポロジーの一貫した視点を確実にするためのものです。
After the 2-byte MT membership format, the MT IPv4 content is in
the same format as extended IP reachability TLV, type 135
[RFC3784].
2バイトのMT会員資格形式、MT IPv4内容の後に、広げられるのと同じ形式にはIPの可到達性TLVがあります、と135[RFC3784]はタイプします。
This TLV can occur multiple times.
このTLVは複数の回起こることができます。
Przygienda, et al. Standards Track [Page 7] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[7ページ]。
7.4. Multi-Topology Reachable IPv6 Prefixes TLV
7.4. マルチトポロジーの届いているIPv6はTLVを前に置きます。
The TLV number of this TLV is 237. It is aligned with IPv6 Reachability TLV type 236 beside an additional two bytes in front.
このTLVのTLV番号は237です。 それは前部の追加2バイトの横でIPv6 Reachability TLVタイプ236に並べられます。
x CODE - 237
x LENGTH - total length of the value field
x VALUE - 2-byte MT membership plus the format of IPv6
Reachability TLV, structured as follows:
x CODE--237 x LENGTH--値の分野x VALUEの全長--2バイトのMT会員資格と以下の通り構造化されたIPv6 Reachability TLVの形式:
No. of Octets
+--------------------------------+
|R |R |R |R | MT ID | 2
+--------------------------------+
| IPv6 Reachability format | 6 - 253
+--------------------------------+
. .
+--------------------------------+
| IPv6 Reachability format | 6 - 253
+--------------------------------+
八重奏+についていいえ--------------------------------+ |R|R|R|R| MT ID| 2 +--------------------------------+ | IPv6 Reachability形式| 6 - 253 +--------------------------------+ . . +--------------------------------+ | IPv6 Reachability形式| 6 - 253 +--------------------------------+
Bits R are reserved, SHOULD be set to 0 on transmission and
ignored on receipt.
SHOULD、ビットRは予約されています。トランスミッションのときに0にセットして、領収書の上で無視されます。
MT ID is a 12-bit field containing the ID of the topology being
announced. The TLV MUST be ignored if the ID is zero.
MT IDは発表されるトポロジーのIDを含む12ビットの分野です。 TLV MUST、IDがゼロであるなら、無視されてください。
After the 2-byte MT membership format, the MT IPv6 context is in
the same format as IPv6 Reachability TLV, type 236 [H01].
2バイトのMT会員資格形式の後に、IPv6 Reachability TLVと同じ形式にはMT IPv6文脈があります、と236[H01]はタイプします。
This TLV can occur multiple times.
このTLVは複数の回起こることができます。
7.5. Reserved MT ID Values
7.5. 予約されたMT ID値
Certain MT topologies are assigned to serve predetermined purposes:
あるMT topologiesは予定された目的に役立つように割り当てられます:
- MT ID #0: Equivalent to the "standard" topology.
- MT ID #1: Reserved for IPv4 in-band management
purposes.
- MT ID #2: Reserved for IPv6 routing topology.
- MT ID #3: Reserved for IPv4 multicast routing topology.
- MT ID #4: Reserved for IPv6 multicast routing topology.
- MT ID #5: Reserved for IPv6 in-band management
purposes.
- MT ID #6-#3995: Reserved for IETF consensus.
- MT ID #3996-#4095: Reserved for development, experimental and
proprietary features [RFC3692].
- MT ID#0: 「標準」のトポロジーに、同等です。 - MT ID#1: バンドにおけるIPv4管理目的のために、予約されます。 - MT ID#2: IPv6ルーティングトポロジーに予約されます。 - MT ID#3: IPv4マルチキャストルーティングトポロジーに予約されます。 - MT ID#4: IPv6マルチキャストルーティングトポロジーに予約されます。 - MT ID#5: バンドにおけるIPv6管理目的のために、予約されます。 - MTの#6#のID3995: IETFコンセンサスのために、予約されます。 - MT ID#3996#4095: 開発、実験的で独占である特徴[RFC3692]のために、予約されます。
Przygienda, et al. Standards Track [Page 8] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[8ページ]。
8. MT IP Forwarding Considerations
8. MT IP推進問題
Using MT extension for IS-IS routing can result in multiple RIBs on the system. In this section, we list some of the known considerations for IP forwarding in various MT scenarios. Certain deployment scenarios presented here imply different trade-offs in terms of deployment difficulties and advantages obtained.
MT拡張子を使用する、-、ルーティングはシステムの上の複数のRIBsをもたらすことができます。 このセクションで、私たちは様々なMTシナリオにおけるIP推進のために知られている問題のいくつかを記載します。 ここに提示されたある展開シナリオは困難と利点が得た展開で異なったトレードオフを含意します。
8.1. Each MT Belongs to a Distinct Address Family
8.1. 各MTは異なったアドレス家族のものです。
In this case, each MT related route is installed into a separate RIB. Multiple topologies can share the same IS-IS interface on detecting the incoming packet address family. As an example, IPv4 and IPv6 can share the same interface without any further considerations under MT ISIS.
この場合、それぞれのMTの関連するルートは別々のRIBにインストールされます。 複数のtopologiesが同じように共有されることができる、-、入って来るパケットアドレス家族を検出するとき、連結してください。 例として、IPv4とIPv6はMTイシスの下の少しもさらなる問題なしで同じインタフェースを共有できます。
8.2. Some MTs Belong to the Same Address Family
8.2. いくつかのMTsが同じアドレス家族のものです。
8.2.1. Each Interface Belongs to One and Only One MT
8.2.1. 各インタフェースは唯一無二のOne MTに属します。
In this case, MTs can be used to forward packets from the same address family, even with overlapping addresses, since the MTs have their dedicated interfaces, and those interfaces can be associated with certain MT RIBs and FIBs.
この場合、同じアドレス家族からパケットを進めるのにMTsを使用できます、アドレスを重ね合わせさえしても、MTsには彼らのひたむきなインタフェースがあって、あるMTのRIBsとFIBsにそれらのインタフェースは関連づけることができるので。
8.2.2. Multiple MTs Share an Interface with Overlapping Addresses
8.2.2. 複数のMTsがアドレスを重ね合わせるとのインタフェースを共有します。
Some additional mechanism is needed to select the correct RIBs for the incoming IP packets to determine the correct RIB to make a forwarding decision. For example, if the topologies are Quality of Service (QoS) partitioned, then the Differentiated Services Code Point (DSCP) bits in the IP packet header can be utilized to make the decision. Some IP headers, or even packet data information, MAY be checked to make the forwarding table selection, for example, the source IP address in the header can be used to determine the desired forwarding behavior.
何らかの追加メカニズムが、入って来るIPパケットが、正しいRIBが推進決定をすることを決定するように正しいRIBsを選択するのに必要です。 例えば、topologiesが仕切られたService(QoS)のQualityであるなら、決定をするのにIPパケットのヘッダーのDifferentiated Services Code Point(DSCP)ビットを利用できます。 推進をテーブル選択にするように何人かのIPヘッダー、またはパケットデータ情報さえチェックするかもしれません、例えば、必要な推進の振舞いを決定するのにヘッダーのソースIPアドレスを使用できます。
This topic is not unique to IS-IS or even to Multi-topology, it is a local policy and configuration decision to make sure the inbound traffic uses the correct forwarding tables. For example, preferred customer packets are sent through a Layer 2 Tunneling Protocol (L2TP) towards the high-bandwidth upstream provider, and other packets are sent through a different L2TP to a normal-bandwidth provider. Those mechanisms are not part of the L2TP protocol specifications.
または、この話題が特有でない、-、Multi-トポロジーとさえ、それは、ローカルの方針とインバウンドトラフィックが正しい推進テーブルを使用するのを確実にするという構成決定です。 例えば、Layer2Tunnelingプロトコル(L2TP)を通して高帯域上流プロバイダーに向かって大切なお客様パケットを送ります、そして、異なったL2TPを通して正常な帯域幅プロバイダーに他のパケットを送ります。 それらのメカニズムはL2TPプロトコル仕様の一部ではありません。
The generic approach of packet to multiple MT RIB mapping over the same inbound interface is outside the scope of this document.
このドキュメントの範囲の外に同じ本国行きのインタフェースの上の複数のMT RIBマッピングへのパケットの一般的方法があります。
Przygienda, et al. Standards Track [Page 9] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[9ページ]。
8.2.3. Multiple MTs Share an Interface with Non-Overlapping Addresses
8.2.3. 複数のMTsが非重なっているアドレスとのインタフェースを共有します。
When there is no overlap in the address space among all the MTs, strictly speaking, the destination address space classifies the topology to which a packet belongs. It is possible to install routes from different MTs into a shared RIB. As an example of such a deployment, a special IS-IS topology can be set up for certain External Border Gateway Protocol (eBGP) nexthop addresses.
すべてのMTsの中にアドレス空間にオーバラップが全くないとき、厳密に言うと、目的地アドレス空間はパケットが属するトポロジーを分類します。 ルートを異なったMTsから共有されたRIBにインストールするのは可能です。 そのような展開に関する例として特別番組、-、トポロジー、あるExternalボーダ・ゲイトウェイ・プロトコル(eBGP)nexthopアドレスにおいて、上がっているセットであることができます。
8.3. Some MTs Are Not Used for Forwarding Purposes
8.3. いくつかのMTsは推進目的に使用されません。
MT in IS-IS MAY be used even if the resulting RIB is not used for forwarding purposes. As an example, multicast Reverse Path Forwarding (RPF) check can be performed on a different RIB than the standard unicast RIB, albeit an entirely different RIB is used for the multicast forwarding. However, an incoming packet MUST still be clearly identified as belonging to a unique topology.
中のMT、-、結果として起こるRIBが推進目的に使用されないでも、使用されるかもしれません。 例として、マルチキャストReverse Path Forwarding(RPF)チェックを標準のユニキャストRIBと異なったRIBに実行できます、完全に異なったRIBはマルチキャスト推進に使用されますが。 しかしながら、ユニークなトポロジーに属すとしてまだ明確に入って来るパケットを特定しなければなりません。
9. MT Network Management Considerations
9. MTネットワークマネージメント問題
When multiple IS-IS topologies exist within a domain, some of the routers can be configured to participate in a subset of the MTs in the network. This section discusses some of the options we have to enable operations or the network management stations to access those routers.
いつ、複数、-、topologies、ドメインの中に存在してください、そして、ネットワークでMTsの部分集合に参加するためにルータのいくつかは構成できるか。 このセクションは私たちが操作かネットワークマネージメントステーションがそれらのルータにアクセスするのを可能にするために持っているオプションのいくつかについて論じます。
9.1. Create Dedicated Management Topology to Include All the Nodes
9.1. ひたむきな管理トポロジーを作成して、すべてのノードを含んでください。
This approach is to set up a dedicated management topology or 'in- band' management topology. This 'mgmt' topology will include all the routers need to be managed. The computed routes in the topology will be installed into the 'mgmt' RIB. In the condition that the 'mgmt' topology uses a set of non-overlapping address space with the default topology, those 'mgmt' routes can also be optionally installed into the default RIB. The advantages of duplicate 'mgmt' routes in both RIBs include: the network management utilities on the system does not have to be modified to use a specific RIB other than the default RIB; the 'mgmt' topology can share the same link with the default topology if so designed.
このアプローチはひたむきな管理トポロジーか'コネバンド'管理トポロジーをセットアップすることです。 この'管理'トポロジーはルータが管理されるために必要とするすべてを含むでしょう。 トポロジーの計算されたルートは'管理'RIBにインストールされるでしょう。 また、'管理'トポロジーがデフォルトトポロジーがある1セットについて非の重なるアドレス空間を使用するという条件で、任意にそれらの'管理'ルートをデフォルトRIBにインストールできます。 両方のRIBsの写し'管理'ルートの利点は: システムに関するネットワークマネージメントユーティリティはデフォルトRIB以外の特定のRIBを使用するように変更される必要はありません。 そのように設計されるなら、'管理'トポロジーはデフォルトトポロジーとの同じリンクを共有できます。
Przygienda, et al. Standards Track [Page 10] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[10ページ]。
9.2. Extend the Default Topology to All the Nodes
9.2. デフォルトトポロジーをすべてのノードに広げてください。
Even in the case that default topology is not used on some of the nodes in the IP forwarding, we MAY want to extend the default topology to those nodes for the purpose of network management. Operators SHOULD set high costs on the links that belong to the extended portion of the default topology. This way, the IP data traffic will not be forwarded through those nodes during network topology changes.
デフォルトトポロジーがいくつかのノードの上でIP推進に使用さえされないで、ネットワークマネージメントの目的のためのそれらのノードにデフォルトトポロジーを広げるかもしれなくたいと思います。 オペレータSHOULDはデフォルトトポロジーの拡張部分に属すリンクの上に高いコストを設定します。 この道には、IPデータ通信量がネットワーク形態変化の間、それらのノードを通して送られないでしょう。
10. Acknowledgments
10. 承認
The authors would like to thank Andrew Partan, Dino Farinacci, Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong, Pekka Savola, Mike Shand, Shankar Vemulapalli, and Les Ginsberg for the discussion, their review, comments, and contributions to this document.
作者は議論、彼らのレビュー、コメント、およびこのドキュメントへの貢献についてアンドリューPartan、ディーノ・ファリナッチ、デリックYeung、アレックス・ジニン、ステファーノPrevidi、ハイジOu、スティーブLuong、ペッカSavola、マイク・シャンド、シャンカルVemulapalli、およびレス・ギンズバーグに感謝したがっています。
11. Security Considerations
11. セキュリティ問題
IS-IS security applies to the work presented. No specific security issues with the proposed solutions are known. The authentication procedure for IS-IS PDUs is the same regardless of MT information inside the IS-IS PDUs.
-、セキュリティは提示された仕事に申請されます。 提案された解決策のどんな特定の安全保障問題も知られていません。 認証手順、-、PDUsがMT情報内部にかかわらず同じである、-、PDUs。
Note that an authentication mechanism, such as the one defined in [RFC3567], SHOULD be applied if there is high risk resulting from modification of multi-topology information.
マルチトポロジー情報の変更から生じる高いリスクがあれば[RFC3567]、SHOULDで定義されたものなどの認証機構が適用されることに注意してください。
As described in Section 8.2.2, multiple topologies share an interface in the same address space, some mechanism beyond IS-IS needs to be used to select the right forwarding table for an inbound packet. A misconfiguration on the system or a packet with a spoofed source address, for example, can lead to packet loss or unauthorized use of premium network resource.
複数のtopologiesがセクション8.2.2で説明されるように同じアドレス空間におけるインタフェースを共有します、向こうの何らかのメカニズム、-、本国行きのパケットのために右の推進テーブルを選択するのに使用されるのが必要です。 例えば、システムの上のmisconfigurationかだまされたソースアドレスがあるパケットがプレミアムネットワーク資源のパケット損失か無断使用に通じることができます。
12. IANA Considerations
12. IANA問題
This document defines the following new IS-IS TLV types, which have already been reflected in the IANA IS-IS TLV code-point registry:
このドキュメントが新しい状態で以下を定義する、-、IS TLV、タイプ:(タイプは既にIANA IS-IS TLVコード・ポイント登録に反映されました)。
Name Value
名前値
MT-ISN 222
M-Topologies 229
MT IP. Reach 235
MT IPv6 IP. Reach 237
MT-ISN222M-Topologies山地標準時229IP。 山地標準時235IPv6IPに達してください。 237に達してください。
Przygienda, et al. Standards Track [Page 11] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[11ページ]。
IANA has created a new registry, "IS-IS Multi-Topology Parameters", with the assignments listed in Section 7.5 of this document and registration policies [RFC2434] for future assignments. The MT ID values range 6-3995 are allocated through Expert Review; values in the range of 3996-4095 are reserved for Private Use. In all cases, assigned values are to be registered with IANA.
IANAが新しい登録を作成した、「-、マルチトポロジーパラメタ、」、課題が将来の課題のためにこのドキュメントと登録方針のセクション7.5[RFC2434]に記載されている状態で。 Expert Reviewを通してMT ID値の範囲6-3995を割り当てます。 3996-4095の範囲の値は兵士のUseのために予約されます。 すべての場合では、割り当てられた値はIANAに登録されることです。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[ISO10589] ISO. Intermediate System to Intermediate System Routing
Exchange Protocol for Use in Conjunction with the
Protocol for Providing the Connectionless-Mode Network
Service. ISO 10589, 1992.
[ISO10589]ISO。 プロトコルに関連したコネクションレスなモードネットワーク・サービスを提供する使用のための中間システムルート設定交換プロトコルへの中間システム。 ISO10589、1992。
[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日
[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月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten、T.、「役に立つと考えられた実験的でテストしている数を割り当てます」、BCP82、RFC3692、2004年1月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
13.2. Informative References
13.2. 有益な参照
[RFC3567] Li, T. and R. Atkinson, "Intermediate System to
Intermediate System (IS-IS) Cryptographic
Authentication", RFC 3567, July 2003.
[RFC3567] 李、T.、およびR.アトキンソン、「中間システムへの中間システム、(-、)、暗号の認証、」、RFC3567、7月2003日
[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月)
[H01] C. Hopps, "Routing IPv6 with IS-IS", Work in Progress.
[H01]C.ホップス、「IPv6を発送する、-、」 仕事進行中です。
Przygienda, et al. Standards Track [Page 12] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[12ページ]。
Authors' Addresses
作者のアドレス
Tony Przygienda Z2 Sagl Via Rovello 32 CH-6942 Savosa EMail: prz@net4u.ch
ロヴェッロ32CH-6942 Savosaを通したトニーPrzygienda Z2 Saglはメールします: prz@net4u.ch
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA, 95134 USA EMail: naiming@cisco.com
シンシスコシステムズ225の西Driveサンノゼ、タスマン・カリフォルニア95134米国をNaimingして、メールしてください: naiming@cisco.com
Nischal Sheth Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA EMail: nsheth@juniper.net
Nischal Sheth杜松は1194北でマチルダAvenueサニーベル(カリフォルニア)94089米国メールをネットワークでつなぎます: nsheth@juniper.net
Przygienda, et al. Standards Track [Page 13] RFC 5120 M-ISIS February 2008
Przygienda、他 規格はMイシス2008年2月にRFC5120を追跡します[13ページ]。
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に情報を記述してください。
Przygienda, et al. Standards Track [Page 14]
Przygienda、他 標準化過程[14ページ]
一覧
スポンサーリンク
