RFC3630 日本語訳
3630 Traffic Engineering (TE) Extensions to OSPF Version 2. D. Katz,K. Kompella, D. Yeung. September 2003. (Format: TXT=27717 bytes) (Updates RFC2370) (Updated by RFC4203) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Katz
Request for Comments: 3630 K. Kompella
Updates: 2370 Juniper Networks
Category: Standards Track D. Yeung
Procket Networks
September 2003
コメントを求めるワーキンググループD.キャッツ要求をネットワークでつないでください: 3630のK.Kompellaアップデート: 2370年の杜松はカテゴリをネットワークでつなぎます: 規格は2003年9月にD.Yeung Procketネットワークを追跡します。
Traffic Engineering (TE) Extensions to OSPF Version 2
OSPFバージョン2への交通工学(Te)拡大
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.
このドキュメントはイントラ領域がTraffic Engineering(TE)であるとサポートするためにOSPFプロトコルバージョン2に拡大について説明します、Opaque Link州Advertisementsを使用して。
1. Introduction
1. 序論
This document specifies a method of adding traffic engineering capabilities to OSPF Version 2 [1]. The architecture of traffic engineering is described in [5]. The semantic content of the extensions is essentially identical to the corresponding extensions to IS-IS [6]. It is expected that the traffic engineering extensions to OSPF will continue to mirror those in IS-IS.
このドキュメントはOSPFバージョン2[1]への交通工学能力を加えるメソッドを指定します。 交通工学のアーキテクチャは[5]で説明されます。 拡大の意味内容が本質的には対応する拡大と同じである、-、[6]。 OSPFへの交通工学拡大が、中のそれらを映し続けると予想される、-
The extensions provide a way of describing the traffic engineering topology (including bandwidth and administrative constraints) and distributing this information within a given OSPF area. This topology does not necessarily match the regular routed topology, though this proposal depends on Network LSAs to describe multi-access links. This document purposely does not say how the mechanisms described here can be used for traffic engineering across multiple OSPF areas; that task is left to future documents. Furthermore, no changes have been made to the operation of OSPFv2 flooding; in
拡大は交通工学トポロジー(帯域幅と管理規制を含んでいる)について説明して、与えられたOSPF領域の中でこの情報を分配する方法を提供します。 このトポロジーは必ず通常の発送されたトポロジーに合っているというわけではありません、この提案がマルチアクセスリンクについて説明するためにNetwork LSAsによりますが。 このドキュメントはわざわざ交通工学に複数のOSPF領域の向こう側にどうここで説明されたメカニズムを使用できるかを書きません。 そのタスクは将来のドキュメントに残されます。 その上、変更を全くOSPFv2氾濫の操作にしていません。 コネ
Katz, et al. Standards Track [Page 1] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[1ページ]RFC3630Te拡張子
particular, if non-TE capable nodes exist in the topology, they MUST flood TE LSAs as any other type 10 (area-local scope) Opaque LSAs (see [3]).
特定です、非TEのできるノードがトポロジーに存在するなら、いかなる他のタイプ10(領域の地方の範囲)もLSAsについて不透明にするのに従って、それらはTE LSAsをあふれさせなければなりません。([3])を見てください。
1.1. Applicability
1.1. 適用性
Many of the extensions specified in this document are in response to the requirements stated in [5], and thus are referred to as "traffic engineering extensions", and are also commonly associated with MPLS Traffic Engineering. A more accurate (albeit bland) designation is "extended link attributes", as the proposal is to simply add more attributes to links in OSPF advertisements.
本書では指定された拡大の多くも、[5]に述べられた要件に対応していて、その結果、「交通工学拡大」と呼ばれて、また、一般的にMPLS Traffic Engineeringに関連しています。 より正確な(おっとりとしますが)名称は「拡張リンク属性」です、提案が単にOSPF広告におけるリンクにより多くの属性を加えることであるので。
The information made available by these extensions can be used to build an extended link state database just as router LSAs are used to build a "regular" link state database; the difference is that the extended link state database (referred to below as the traffic engineering database) has additional link attributes. Uses of the traffic engineering database include:
ちょうどルータLSAsが「通常」のリンク州のデータベースを築き上げるのに使用されるように拡張リンク州のデータベースを築き上げるのにこれらの拡大で利用可能にされた情報は使用できます。 違いは拡張リンク州のデータベース(交通工学データベースとして以下に言及される)には追加リンク属性があるということです。 交通工学データベースの用途は:
o monitoring the extended link attributes;
o local constraint-based source routing; and
o global traffic engineering.
o 拡張リンク属性をモニターします。 o ローカルの規制ベースのソースルーティング。 そして、oグローバルな交通工学。
For example, an OSPF-speaking device can participate in an OSPF area, build a traffic engineering database, and thereby report on the reservation state of links in that area.
例えば、OSPF-話しデバイスは、OSPF領域に参加して、交通工学データベースを築き上げて、その結果、その領域でリンクの予約状態に関して報告できます。
In "local constraint-based source routing", a router R can compute a path from a source node A to a destination node B; typically, A is R itself, and B is specified by a "router address" (see below). This path may be subject to various constraints on the attributes of the links and nodes that the path traverses, e.g., use green links that have unreserved bandwidth of at least 10Mbps. This path could then be used to carry some subset of the traffic from A to B, forming a simple but effective means of traffic engineering. How the subset of traffic is determined, and how the path is instantiated, is beyond the scope of this document; suffice it to say that one means of defining the subset of traffic is "those packets whose IP destinations were learned from B", and one means of instantiating paths is using MPLS tunnels. As an aside, note that constraint-based routing can be NP-hard, or even unsolvable, depending on the nature of the attributes and constraints, and thus many implementations will use heuristics. Consequently, we don't attempt to sketch an algorithm here.
「ローカルの規制ベースのソースルーティング」で、ルータRはソースノードAから目的地ノードBまで経路を計算できます。 Aは通常、R自体です、そして、Bは「ルータアドレス」によって指定されます(以下を見てください)。 この経路は少なくとも10Mbpsの無遠慮な帯域幅を持っているリンクと経路が横断するノード、例えば緑色がリンクする使用の属性で様々な規制を受けることがあるかもしれません。 次に、AからBまでトラフィックの何らかの部分集合を運ぶのにこの経路を使用できました、交通工学の簡単な、しかし、効果的な手段を形成して。 トラフィックの部分集合がどう決定しているか、そして、経路がどう例示されるかはこのドキュメントの範囲を超えています。 それを満足させて、トラフィックの部分集合を定義する1つの手段が「IPの目的地がBから学習されたそれらのパケット」であり、経路を例示する1つの手段がMPLSトンネルを使用することであると言ってください。 余談として、規制ベースのルーティングがNP困難である場合があることに注意してください。さもないと、「非-解決でき」、属性と規制の本質によって、およびその結果、多くの実装さえ発見的教授法を使用するでしょう。 その結果、私たちは、ここにアルゴリズムをスケッチするのを試みません。
Katz, et al. Standards Track [Page 2] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[2ページ]RFC3630Te拡張子
Finally, for "global traffic engineering", a device can build a traffic engineering database, input a traffic matrix and an optimization function, crunch on the information, and thus compute optimal or near-optimal routing for the entire network. The device can subsequently monitor the traffic engineering topology and react to changes by recomputing the optimal routes.
最終的に、デバイスは、「グローバルな交通工学」のために全体のネットワークのために最適であるか最適ルーティングで交通工学データベースを築き上げて、トラフィックマトリクスと最適化機能を入力して、情報でかんで、その結果、計算されることができます。 デバイスは、次に、交通工学トポロジーをモニターして、最適のルートを再計算することによって、変化に反応できます。
1.2. Limitations
1.2. 制限
As mentioned above, this document specifies extensions and procedures for intra-area distribution of Traffic Engineering information. Methods for inter-area and inter-AS (Autonomous System) distribution are not discussed here.
以上のように、このドキュメントはTraffic Engineering情報のイントラ領域分配のための拡大と手順を指定します。 ここで相互領域と相互AS(自治のSystem)分配のためのメソッドについて議論しません。
The extensions specified in this document capture the reservation state of point-to-point links. The reservation state of multi-access links may not be accurately reflected, except in the special case in which there are only two devices in the multi-access subnetwork. Operation over multi-access networks with more than two devices is not specifically prohibited. A more accurate description of the reservation state of multi-access networks is for further study.
本書では指定された拡大は、予約がポイントツーポイント接続の状態であるとキャプチャします。 マルチアクセスリンクの予約状態は正確に反映されないかもしれません、2台のデバイスしかマルチアクセスサブネットワークにない特別な場合を除いて。 2台以上のデバイスがあるマルチアクセスネットワークの上の操作は明確に禁止されていません。 さらなる研究にはマルチアクセスネットワークの予約事情の、より正確な記述があります。
This document also does not support unnumbered links. This deficiency will be addressed in future documents; see also [7] and [8].
このドキュメントも無数のリンクを支えません。 この欠乏は将来のドキュメントで扱われるでしょう。 また、[7]と[8]を見てください。
1.3. Conventions
1.3. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。
2. LSA Format
2. LSA形式
2.1. LSA type
2.1. LSAはタイプします。
This extension makes use of the Opaque LSA [3].
この拡大はOpaque LSA[3]を利用します。
Three types of Opaque LSAs exist, each of which has a different flooding scope. This proposal uses only Type 10 LSAs, which have an area flooding scope.
Opaque LSAsの3つのタイプが、どれに異なった氾濫範囲があるかがそれぞれ存在しています。 この提案はType10LSAsだけを使用します。(LSAsは領域の氾濫範囲を持っています)。
One new LSA is defined, the Traffic Engineering LSA. This LSA describes routers, point-to-point links, and connections to multi- access networks (similar to a Router LSA). For traffic engineering purposes, the existing Network LSA is sufficient for describing multi-access links, so no additional LSA is defined for this purpose.
1新しいLSAが定義される、Traffic Engineering LSA。 このLSAはマルチアクセスネットワーク(Router LSAと同様の)にルータ、ポイントツーポイント接続、および接続について説明します。 交通工学目的のために、既存のNetwork LSAがマルチアクセスリンクについて説明するのに十分であるので、どんな追加LSAもこのために定義されません。
Katz, et al. Standards Track [Page 3] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[3ページ]RFC3630Te拡張子
2.2. LSA ID
2.2. LSA ID
The LSA ID of an Opaque LSA is defined as having eight bits of type data and 24 bits of type-specific data. The Traffic Engineering LSA uses type 1. The remaining 24 bits are the Instance field, as follows:
Opaque LSAのLSA IDは8ビットのタイプデータと24ビットのタイプ特有のデータを持っていると定義されます。 Traffic Engineering LSAはタイプ1を使用します。 残っている24ビットは以下の通りInstance分野です:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | インスタンス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs. A maximum of 16777216 Traffic Engineering LSAs may be sourced by a single system. The LSA ID has no topological significance.
Instance分野は複数のTraffic Engineering LSAsを維持するのに使用される任意の値です。 最大16777216Traffic Engineering LSAsがただ一つのシステムによって出典を明示されるかもしれません。 LSA IDには、どんな位相的な意味もありません。
2.3. LSA Format Overview
2.3. LSA形式概要
2.3.1. LSA Header
2.3.1. LSAヘッダー
The Traffic Engineering LSA starts with the standard LSA header:
Traffic Engineering LSAは標準のLSAヘッダーから始めます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS時代| オプション| 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | インスタンス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 広告ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSチェックサム| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Katz, et al. Standards Track [Page 4] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[4ページ]RFC3630Te拡張子
2.3.2. TLV Header
2.3.2. TLVヘッダー
The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets for extensibility. The format of each TLV is:
LSAペイロードは伸展性のための1つ以上の入れ子にされたType/長さ/値(TLV)の三つ子から成ります。 それぞれのTLVの形式は以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値… | . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored.
Length分野は八重奏における、値の部分の長さを定義します(その結果、値の部分のないTLVには、ゼロの長さがあるでしょう)。 TLVは4八重奏の整列に水増しされます。 詰め物は長さの分野に含まれていません(3八重奏価値には、したがって、3の長さがあるでしょうが、TLVの総サイズは8つの八重奏でしょう)。 また、並べられた状態で、入れ子にされたTLVsは32ビットです。 認識されていないタイプは無視されます。
This memo defines Types 1 and 2. See the IANA Considerations section for allocation of new Types.
このメモはTypes1と2を定義します。 新しいTypesの配分に関してIANA Considerations部を見てください。
2.4. LSA payload details
2.4. LSAペイロードの詳細
An LSA contains one top-level TLV.
LSAは1トップレベルTLVを含んでいます。
There are two top-level TLVs defined:
トップレベルTLVsが定義した2があります:
1 - Router Address
2 - Link
1--ルータアドレス2--リンク
2.4.1. Router Address TLV
2.4.1. ルータアドレスTLV
The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any connectivity to it; this is typically implemented as a "loopback address". The key attribute is that the address does not become unusable if an interface is down. In other protocols, this is known as the "router ID," but for obvious reasons this nomenclature is avoided here. If a router advertises BGP routes with the BGP next hop attribute set to the BGP router ID, then the Router Address SHOULD be the same as the BGP router ID.
Router Address TLVは何か接続性があればいつも届いている広告ルータの安定したIPアドレスをそれに指定します。 これは「ループバックアドレス」として通常実装されます。 主要な属性はインタフェースが下がっているならアドレスが使用不可能にならないということです。 他のプロトコルで、これは「ルータID」として知られていますが、明白な理由によって、この用語体系はここで避けられます。 ルータがBGPルートの広告を出すなら、次のホップ属性が次に、BGPルータID、Router Address SHOULDに設定したBGPと共に、BGPルータIDと同じにしてください。
Katz, et al. Standards Track [Page 5] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[5ページ]RFC3630Te拡張子
If IS-IS is also active in the domain, this address can also be used to compute the mapping between the OSPF and IS-IS topologies. For example, suppose a router R is advertising both IS-IS and OSPF Traffic Engineering LSAs, and suppose further that some router S is building a single Traffic Engineering Database (TED) based on both IS-IS and OSPF TE information. R may then appear as two separate nodes in S's TED. However, if both the IS-IS and OSPF LSAs generated by R contain the same Router Address, then S can determine that the IS-IS TE LSA and the OSPF TE LSA from R are indeed from a single router.
そして、-、そのドメインの能動態も、また、OSPFの間のマッピングを計算するのにこのアドレスを使用できるということである、-、topologies。 例えば、ルータRが広告の両方であると仮定してください、-、OSPF Traffic Engineering LSAs、何らかのルータSが両方に基づく独身のTraffic Engineering Database(TED)を造っているとさらに仮定してください、-、そして、OSPF TE情報。 そして、2がSのTEDでノードを切り離すのに従って、Rは現れるかもしれません。 そして、しかしながら、両方である、-、Rによって生成されたOSPF LSAsが同じRouter Addressを含んでいて、次に、Sがそれを決定できる、-、IS TE LSA、RからのOSPF TE LSAが本当にただ一つのルータからあります。
The router address TLV is type 1, has a length of 4, and a value that is the four octet IP address. It must appear in exactly one Traffic Engineering LSA originated by a router.
ルータアドレスTLVはタイプ1であり、4の長さ、および4八重奏IPアドレスである値を持っています。 ちょうど1でTraffic Engineering LSAがルータで起因したように見えなければなりません。
2.4.2. Link TLV
2.4.2. リンクTLV
The Link TLV describes a single link. It is constructed of a set of sub-TLVs. There are no ordering requirements for the sub-TLVs.
Link TLVは単一のリンクについて説明します。 それはサブTLVsの1セットについて組み立てられます。 注文要件は全くサブTLVsのためにありません。
Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology.
トポロジーですばらしい粒状変化を考慮して、1Link TLVだけが各LSAで運ばれるものとします。
The Link TLV is type 2, and the length is variable.
Link TLVはタイプ2です、そして、長さは可変です。
The following sub-TLVs of the Link TLV are defined:
Link TLVの以下のサブTLVsは定義されます:
1 - Link type (1 octet)
2 - Link ID (4 octets)
3 - Local interface IP address (4 octets)
4 - Remote interface IP address (4 octets)
5 - Traffic engineering metric (4 octets)
6 - Maximum bandwidth (4 octets)
7 - Maximum reservable bandwidth (4 octets)
8 - Unreserved bandwidth (32 octets)
9 - Administrative group (4 octets)
1--2--リンクID(4つの八重奏)3--リンク型(1つの八重奏)局所界面IPは、メートル法(4つの八重奏)の6--最大の帯域幅(4つの八重奏)7--最大の予約可能帯域幅(4つの八重奏)8--無遠慮な帯域幅(32の八重奏)9--4--リモートインタフェースIPアドレス(4つの八重奏)5--交通工学が管理グループであると扱います(4つの八重奏)。(4つの八重奏)
This memo defines sub-Types 1 through 9. See the IANA Considerations section for allocation of new sub-Types.
このメモは1〜9にサブTypesを定義します。 新しいサブTypesの配分に関してIANA Considerations部を見てください。
The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear exactly once. All other sub-TLVs defined here may occur at most once. These restrictions need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored.
Link TypeとLink IDサブTLVsが義務的である、すなわち、必須はまさに一度現れます。 ここで定義された他のすべてのサブTLVsが高々一度起こるかもしれません。 これらの制限は将来のサブTLVsに適用される必要はありません。 認識されていないサブTLVsは無視されます。
Katz, et al. Standards Track [Page 6] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[6ページ]RFC3630Te拡張子
Various values below use the (32 bit) IEEE Floating Point format. For quick reference, this format is as follows:
以下の様々な値は(32ビット)のIEEE Floating Point形式を使用します。 クイックリファレンスにおいて、この形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Exponent | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| 解説者| 断片| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S is the sign, Exponent is the exponent base 2 in "excess 127" notation, and Fraction is the mantissa - 1, with an implied binary point in front of it. Thus, the above represents the value:
Fractionは仮数です--Sはサインです、そして、「余分な127」記法でExponentは解説者ベース2です、そして、暗示している2進小数点がそれの正面にある1。 したがって、上記は値を表します:
(-1)**(S) * 2**(Exponent-127) * (1 + Fraction)
(-1) **(S)*2**(解説者-127)*(1+断片)
For more details, refer to [4].
その他の詳細について、[4]を参照してください。
2.5. Sub-TLV Details
2.5. サブTLVの詳細
2.5.1. Link Type
2.5.1. リンク型
The Link Type sub-TLV defines the type of the link:
Link TypeサブTLVはリンクのタイプを定義します:
1 - Point-to-point
2 - Multi-access
1--ポイントツーポイント2--マルチアクセス
The Link Type sub-TLV is TLV type 1, and is one octet in length.
Link TypeサブTLVはTLVタイプ1であり、長さが1つの八重奏です。
2.5.2. Link ID
2.5.2. IDをリンクしてください。
The Link ID sub-TLV identifies the other end of the link. For point-to-point links, this is the Router ID of the neighbor. For multi-access links, this is the interface address of the designated router. The Link ID is identical to the contents of the Link ID field in the Router LSA for these link types.
Link IDサブTLVはリンクのもう一方の端を特定します。 ポイントツーポイント接続に関しては、これは隣人のRouter IDです。 マルチアクセスリンクに関しては、これは代表ルータのインターフェース・アドレスです。 これらのリンク型にとって、Link IDはRouter LSAのLink ID分野のコンテンツと同じです。
The Link ID sub-TLV is TLV type 2, and is four octets in length.
Link IDサブTLVはTLVタイプ2であり、長さが4つの八重奏です。
2.5.3. Local Interface IP Address
2.5.3. 局所界面IPアドレス
The Local Interface IP Address sub-TLV specifies the IP address(es) of the interface corresponding to this link. If there are multiple local addresses on the link, they are all listed in this sub-TLV.
Local Interface IP AddressサブTLVはこのリンクに対応するインタフェースのIPアドレス(es)を指定します。 リンクの上に複数のローカルのアドレスがあれば、それらはこのサブTLVにすべて記載されます。
The Local Interface IP Address sub-TLV is TLV type 3, and is 4N octets in length, where N is the number of local addresses.
Local Interface IP AddressサブTLVはTLVタイプ3であり、長さが4N八重奏です、Nがローカルのアドレスの数であるところで。
Katz, et al. Standards Track [Page 7] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[7ページ]RFC3630Te拡張子
2.5.4. Remote Interface IP Address
2.5.4. リモートインタフェースIPアドレス
The Remote Interface IP Address sub-TLV specifies the IP address(es) of the neighbor's interface corresponding to this link. This and the local address are used to discern multiple parallel links between systems. If the Link Type of the link is Multi-access, the Remote Interface IP Address is set to 0.0.0.0; alternatively, an implementation MAY choose not to send this sub-TLV.
Remote Interface IP AddressサブTLVは隣人のこのリンクに対応するインタフェースのIPアドレス(es)を指定します。 これとローカルアドレスは、システムの間の複数の平行なリンクについて明察するのに使用されます。リンクのLink TypeがMulti-アクセスであるなら、Remote Interface IP Addressが0.0に.0を設定することである、.0。 あるいはまた、実装は、このサブTLVを送らないのを選ぶかもしれません。
The Remote Interface IP Address sub-TLV is TLV type 4, and is 4N octets in length, where N is the number of neighbor addresses.
Remote Interface IP AddressサブTLVはTLVタイプ4であり、長さが4N八重奏です、Nが隣人アドレスの数であるところで。
2.5.5. Traffic Engineering Metric
2.5.5. 交通工学メートル法です。
The Traffic Engineering Metric sub-TLV specifies the link metric for traffic engineering purposes. This metric may be different than the standard OSPF link metric. Typically, this metric is assigned by a network administrator.
Traffic Engineering MetricサブTLVは交通工学目的のためのメートル法のリンクを指定します。 これほどメートル法、標準のOSPFリンクとメートル法であることで異なるかもしれません。 通常、これほどメートル法、ネットワーク管理者によって割り当てられます。
The Traffic Engineering Metric sub-TLV is TLV type 5, and is four octets in length.
Traffic Engineering MetricサブTLVはTLVタイプ5であり、長さが4つの八重奏です。
2.5.6. Maximum Bandwidth
2.5.6. 最大の帯域幅
The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that can be used on this link, in this direction (from the system originating the LSA to its neighbor), in IEEE floating point format. This is the true link capacity. The units are bytes per second.
Maximum BandwidthサブTLVはこのリンクの上に使用できる最大の帯域幅を指定します、この方向(LSAを溯源するシステムから隣人までの)に、IEEE浮動小数点形式で。 これは真のリンク容量です。 ユニットは1秒あたりバイトです。
The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in length.
Maximum BandwidthサブTLVはTLVタイプ6であり、長さが4つの八重奏です。
2.5.7. Maximum Reservable Bandwidth
2.5.7. 最大のReservable帯域幅
The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). This SHOULD be user-configurable; the default value should be the Maximum Bandwidth. The units are bytes per second.
Maximum Reservable BandwidthサブTLVはこのリンクの上に控えられるかもしれない最大の帯域幅を指定します、この方向に、IEEE浮動小数点形式で。 これが最大の帯域幅よりすばらしいかもしれないことに注意してください(その場合、リンクは申込みが超過しているかもしれません)。 このSHOULD、ユーザ構成可能であってください。 デフォルト値はMaximum Bandwidthであるべきです。 ユニットは1秒あたりバイトです。
The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four octets in length.
Maximum Reservable BandwidthサブTLVはTLVタイプ7であり、長さが4つの八重奏です。
Katz, et al. Standards Track [Page 8] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[8ページ]RFC3630Te拡張子
2.5.8. Unreserved Bandwidth
2.5.8. 無遠慮な帯域幅
The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels in IEEE floating point format. 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. The initial values (before any bandwidth is reserved) are all set to the Maximum Reservable Bandwidth. Each value will be less than or equal to the Maximum Reservable Bandwidth. The units are bytes per second.
Unreserved BandwidthサブTLVはIEEE浮動小数点形式における、それぞれの8つの優先順位でまだ控えられていなかった帯域幅の量を指定します。 値は0〜7のセットアップ優先で控えることができる帯域幅に対応しています、増加するオーダーでは、サブTLVの端にサブTLVと優先権7つのものの始めに起こる優先権0で、整います。 初期の値(どんな帯域幅も予約されている前に)はMaximum Reservable Bandwidthにすべて設定されます。 各値はMaximum Reservable Bandwidthによりなるでしょう。 ユニットは1秒あたりバイトです。
The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in length.
Unreserved BandwidthサブTLVはTLVタイプ8であり、長さが32の八重奏です。
2.5.9. Administrative Group
2.5.9. 管理グループ
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. A link may belong to multiple groups.
Administrative Groupサブ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'と呼ばれます。
The Administrative Group is also called Resource Class/Color [5].
また、Administrative GroupはResource Class/色の[5]と呼ばれます。
The Administrative Group sub-TLV is TLV type 9, and is four octets in length.
Administrative GroupサブTLVはTLVタイプ9であり、長さが4つの八重奏です。
3. Elements of Procedure
3. 手順のElements
Routers shall originate Traffic Engineering LSAs whenever the LSA contents change, and whenever otherwise required by OSPF (an LSA refresh, for example). Note that this does not mean that every change must be flooded immediately; an implementation MAY set thresholds (for example, a bandwidth change threshold) that trigger immediate flooding, and initiate flooding of other changes after a short time interval. In any case, the origination of Traffic Engineering LSAs SHOULD be rate-limited to at most one every MinLSInterval [1].
LSAコンテンツが変化するときはいつもルータがTraffic Engineering LSAsを溯源するものとする、別の方法で、OSPF(例えば、LSAはリフレッシュする)が必要です。 これが、あらゆる変化がすぐに水につかるに違いないことを意味しないことに注意してください。 実装は、即座の氾濫の引き金となる敷居(例えば、帯域幅変化敷居)を設定して、短い時間間隔の後に他の変化の氾濫を起こすかもしれません。 どのような場合でも、Traffic Engineering LSAs SHOULDの創作はレートによって最も1つのあらゆるMinLSInterval[1]に限られます。
Upon receipt of a changed Traffic Engineering LSA or Network LSA (since these are used in traffic engineering calculations), the router should update its traffic engineering database. No Shortest Path First (SPF) or other route calculations are necessary.
変えられたTraffic Engineering LSAかNetwork LSA(これらが交通工学計算に使用されるので)を受け取り次第、ルータは交通工学データベースをアップデートするべきです。 Shortest Path First(SPF)か他のどんなルート計算も必要ではありません。
Katz, et al. Standards Track [Page 9] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[9ページ]RFC3630Te拡張子
4. Compatibility Issues
4. 互換性の問題
There should be no interoperability issues with routers that do not implement these extensions, as the Opaque LSAs will be silently ignored.
これらの拡大を実装しないルータには相互運用性問題が全くあるべきではありません、Opaque LSAsが静かに無視されるとき。
The result of having routers that do not implement these extensions is that the traffic engineering topology will be missing pieces. However, if the topology is connected, TE paths can still be calculated and ought to work.
これらの拡大を実装しないルータを持っているという結果は交通工学トポロジーがなくなった断片になるということです。 しかしながら、トポロジーが接続されているなら、TE経路は、まだ計算できて、働くべきです。
5. Security Considerations
5. セキュリティ問題
This document specifies the contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for SPF computation or normal routing, the extensions specified here have no affect on IP routing. However, tampering with TE LSAs may have an effect on traffic engineering computations, and it is suggested that any mechanisms used for securing the transmission of normal OSPF LSAs be applied equally to all Opaque LSAs, including the TE LSAs specified here.
このドキュメントはOSPFv2でOpaque LSAsのコンテンツを指定します。 Opaque LSAsがSPF計算か正常なルーティングに使用されないとき、ここで指定された拡大で、いいえはIPでルーティングに影響します。 しかしながら、TE LSAsをいじると、影響は交通工学計算に与えられるかもしれません、そして、正常なOSPF LSAsのトランスミッションを保証するのに使用されるどんなメカニズムも等しくすべてのOpaque LSAsに適用されることが提案されます、ここで指定されたTE LSAsを含んでいて。
Note that the mechanisms in [1] and [9] apply to Opaque LSAs. It is suggested that any future mechanisms proposed to secure/authenticate OSPFv2 LSA exchanges be made general enough to be used with Opaque LSAs.
[1]と[9]のメカニズムがOpaque LSAsに適用されることに注意してください。 OSPFv2 LSA交換を保証するか、または認証するために提案されたどんな将来のメカニズムもOpaque LSAsと共に使用されているほど一般的にすることが提案されます。
6. IANA Considerations
6. IANA問題
The top level Types in a TE LSA, as well as Types for sub-TLVs for each top level Type, have been registered with IANA, except as noted.
TE LSAの最高平らなTypes、およびそれぞれのトップレベルTypeのためのサブTLVsのためのTypesはIANAに登録されました、注意されるのを除いて。
Here are the guidelines (using terms defined in [10]) for the assignment of top level Types in TE LSAs:
ここに、ガイドラインがあります。(先端の課題に[10])で定義された用語を使用すると、TypesはTE LSAsで平らにされます:
o Types in the range 3-32767 are to be assigned via Standards
Action.
o 範囲3-32767のタイプはStandards Actionを通して選任されることになっています。
o Types in the range 32768-32777 are for experimental use; these
will not be registered with IANA, and MUST NOT be mentioned by
RFCs.
o 範囲32768-32777のタイプは実験用に賛成します。 これらについて、IANAに登録しないで、RFCsは言及してはいけません。
o Types in the range 32778-65535 are not to be assigned at this
time. Before any assignments can be made in this range, there
MUST be a Standards Track RFC that specifies IANA Considerations
that covers the range being assigned.
o このとき、範囲32778-65535のタイプを選任してはいけません。 この範囲でどんな課題もすることができる前に、割り当てられる範囲をカバーするIANA Considerationsを指定するStandards Track RFCがあるに違いありません。
Katz, et al. Standards Track [Page 10] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[10ページ]RFC3630Te拡張子
The guidelines for the assignment of types for sub-TLVs in a TE LSA are as follows:
TE LSAのサブTLVsのためのタイプの課題のためのガイドラインは以下の通りです:
o Types in the range 10-32767 are to be assigned via Standards
Action.
o 範囲10-32767のタイプはStandards Actionを通して選任されることになっています。
o Types in the range 32768-32777 are for experimental use; these
will not be registered with IANA, and MUST NOT be mentioned by
RFCs.
o 範囲32768-32777のタイプは実験用に賛成します。 これらについて、IANAに登録しないで、RFCsは言及してはいけません。
o Types in the range 32778-65535 are not to be assigned at this
time. Before any assignments can be made in this range, there
MUST be a Standards Track RFC that specifies IANA Considerations
that covers the range being assigned.
o このとき、範囲32778-65535のタイプを選任してはいけません。 この範囲でどんな課題もすることができる前に、割り当てられる範囲をカバーするIANA Considerationsを指定するStandards Track RFCがあるに違いありません。
7. Intellectual Property Rights Statement
7. 知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
Katz, et al. Standards Track [Page 11] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[11ページ]RFC3630Te拡張子
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[1]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[3]Coltun、1998年7月のR.、「OSPFの不明瞭なLSAオプション」RFC2370。
[4] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic",
Standard 754-1985, 1985 (ISBN 1-5593-7653-8).
[4]IEEE、「バイナリーの浮動小数点の演算における、標準のIEEE」、規格754-1985、1985(ISBN1-5593-7653-8)。
8.2. Informative References
8.2. 有益な参照
[5] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
McManus, "Requirements for Traffic Engineering Over MPLS", RFC
2702, September 1999.
[5]AwducheとD.、マルコムとJ.とAgogbuaとJ.とオデルとM.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
[6] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering",
work in progress.
[6] 「交通工学のためのイシスExtensions」というスミット、H.、およびT.李は進行中で働いています。
[7] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in
Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)",
RFC 3477, January 2003.
[7] Kompella、K.、およびY.Rekhter、「資源予約に基づく合図の無数のリンクは議定書を作ります--交通工学(RSVP-Te)」、RFC3477、2003年1月。
[8] Kompella, K., Rekhter, Y. and A. Kullberg, "Signalling
Unnumbered Links in CR-LDP (Constraint-Routing Label
Distribution Protocol)", RFC 3480, February 2003.
[8]KompellaとK.とRekhterとY.とA.Kullberg、「CR-自由民主党(規制ルート設定ラベル分配プロトコル)で無数のリンクに合図します」、RFC3480、2003年2月。
[9] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital
Signatures", RFC 2154, June 1997.
[9] マーフィーとS.とムジナとM.とB.ウェリントン、「デジタル署名があるOSPF」、RFC2154、1997年6月。
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Katz, et al. Standards Track [Page 12] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[12ページ]RFC3630Te拡張子
9. Authors' Addresses
9. 作者のアドレス
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
デーヴキャッツJuniperは1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア94089米国
Phone: +1 408 745 2000 EMail: dkatz@juniper.net
以下に電話をしてください。 +1 2000年の408 745メール: dkatz@juniper.net
Derek M. Yeung Procket Networks, Inc. 1100 Cadillac Court Milpitas, CA 95035 USA
デリックM.Yeung ProcketはInc.1100キャデラック法廷カリフォルニア95035ミルピタス(米国)をネットワークでつなぎます。
Phone: +1 408 635-7900 EMail: myeung@procket.com
以下に電話をしてください。 +1 408 635-7900 メールしてください: myeung@procket.com
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Kireeti Kompella杜松は1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア94089米国
Phone: +1 408 745 2000 EMail: kireeti@juniper.net
以下に電話をしてください。 +1 2000年の408 745メール: kireeti@juniper.net
Katz, et al. Standards Track [Page 13] RFC 3630 TE Extensions to OSPF Version 2 September 2003
キャッツ、他 OSPFバージョン2003年9月2日までの標準化過程[13ページ]RFC3630Te拡張子
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Katz, et al. Standards Track [Page 14]
キャッツ、他 標準化過程[14ページ]
一覧
スポンサーリンク
