RFC4971 日本語訳
4971 Intermediate System to Intermediate System (IS-IS) Extensions forAdvertising Router Information. JP. Vasseur, Ed., N. Shen, Ed., R.Aggarwal, Ed.. July 2007. (Format: TXT=18541 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group JP. Vasseur, Ed.
Request for Comments: 4971 N. Shen, Ed.
Category: Standards Track Cisco Systems, Inc.
R. Aggarwal, Ed.
Juniper Networks
July 2007
ワーキンググループJPをネットワークでつないでください。 エドVasseur、コメントを求める要求: 4971 エドN.シン、カテゴリ: 規格は2007年7月にエドシスコシステムズInc.R.Aggarwal、杜松ネットワークを追跡します。
Intermediate System to Intermediate System (IS-IS) Extensions
for Advertising Router Information
中間システムへの中間システム、(-、)、広告ルータ情報のための拡大
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain.
このドキュメントが新しい任意のIntermediate SystemをIntermediate Systemと定義する、(-、)、TLVが能力を発表するために中でルータを許容する複数のサブTLVsについて形成されたCAPABILITYと命名した、-、レベルか全体の経路ドメイン。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. IS-IS Router CAPABILITY TLV .....................................3
3. Elements of Procedure ...........................................4
4. Interoperability with Routers Not Supporting the
Capability TLV ..................................................5
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Acknowledgment ..................................................6
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................8
1. 序論…2 1.1. このドキュメントで中古のコンベンション…2 2. -、ルータ能力TLV…3 3. 手順のElements…4 4. ルータが能力TLVを支持していない相互運用性…5 5. セキュリティ問題…6 6. IANA問題…6 7. 承認…6 8. 参照…6 8.1. 標準の参照…6 8.2. 有益な参照…8
Vasseur, et al. Standards Track [Page 1] RFC 4971 IS-IS Extensions for Advertising Router Info July 2007
Vasseur、他 規格がRFC4971を追跡する、[1ページ]-、ルータインフォメーション2007年7月に広告を出すための拡大
1. Introduction
1. 序論
There are several situations where it is useful for the IS-IS [IS-IS] [IS-IS-IP] routers to learn the capabilities of the other routers of their IS-IS level, area, or routing domain. For the sake of illustration, three examples related to MPLS Traffic Engineering (TE) are described here:
それが役に立ついくつかの状況がある、-、[-、]、[IPである、]、他のルータの能力について知るルータ、それら、-、レベル、領域、または経路ドメイン。 イラストのために、MPLS Traffic Engineering(TE)に関連する3つの例がここで説明されます:
1. Mesh-group: the setting up of a mesh of TE Label Switched Paths
(LSPs) [IS-IS-TE] requires some significant configuration effort.
[AUTOMESH] proposes an auto-discovery mechanism whereby every
Label Switching Router (LSR) of a mesh advertises its mesh-group
membership by means of IS-IS extensions.
1. メッシュグループ: TE Label Switched Paths(LSPs)のメッシュを上がっている設定、[TEである、]、何らかの重要な構成の努力を必要とします。 による、[AUTOMESH]がメッシュのあらゆるLabel Switching Router(LSR)がメッシュグループ会員資格の広告を出す自動発見メカニズムを提案する、-、拡大
2. Point to Multipoint TE LSP (P2MP LSP). A specific sub-TLV
([TE-NODE-CAP]) allows an LSR to advertise its Point To Multipoint
capabilities ([P2MP] and [P2MP-REQS]).
2. 多点Te LSP(P2MP LSP)を示してください。 特定のサブTLV([TE-NODE-CAP])はLSRにPoint To Multipoint能力([P2MP]と[P2MP-REQS])に広告を出させます。
3. Inter-area traffic engineering: Advertisement of the IPv4 and/or
the IPv6 Traffic Engineering Router IDs.
3. 相互領域交通工学: IPv4の広告、そして/または、IPv6交通工学ルータID。
The use of IS-IS for Path Computation Element (PCE) discovery may also be considered and will be discussed in the PCE WG.
使用、-、Path Computation Element(PCE)に関しては、発見について、また、考えられるかもしれなくて、PCE WGで議論するでしょう。
The capabilities mentioned above require the specification of new sub-TLVs carried within the CAPABILITY TLV defined in this document.
前記のように能力は本書では定義されたCAPABILITY TLVの中で運ばれた新しいサブTLVsの仕様を必要とします。
Note that the examples above are provided for the sake of illustration. This document proposes a generic capability advertising mechanism that is not limited to MPLS Traffic Engineering.
上記の例がイラストのために提供されることに注意してください。 このドキュメントはMPLS Traffic Engineeringに制限されない一般的な能力広告メカニズムを提案します。
This document defines a new optional IS-IS TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. The applications mentioned above require the specification of new sub- TLVs carried within the CAPABILITY TLV defined in this document.
このドキュメントが新しく任意の状態でaを定義する、-、IS TLV、複数のサブTLVsについて形成されたルータに能力を発表させるCAPABILITYが中で命名した、-、レベルか全体の経路ドメイン。 前記のようにアプリケーションは本書では定義されたCAPABILITY TLVの中で運ばれた新しいサブTLVsの仕様を必要とします。
Definition of these sub-TLVs is outside the scope of this document.
このドキュメントの範囲の外にこれらのサブTLVsの定義があります。
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 [RFC-2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
Vasseur, et al. Standards Track [Page 2] RFC 4971 IS-IS Extensions for Advertising Router Info July 2007
Vasseur、他 規格がRFC4971を追跡する、[2ページ]-、ルータインフォメーション2007年7月に広告を出すための拡大
2. IS-IS Router CAPABILITY TLV
2. -、ルータ能力TLV
The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 1 octet that specifies the number of bytes in the value field, and a variable length value field that starts with 4 octets of Router ID, indicating the source of the TLV, and followed by 1 octet of flags.
-、Router CAPABILITY TLVをタイプ、値の分野でバイト数を指定する1つの八重奏、およびTLVの源を示して、Router IDの4つの八重奏から始まる可変長値の分野に1つの八重奏で構成されて、旗の1つの八重奏があとに続いています。
A set of optional sub-TLVs may follow the flag field. Sub-TLVs are formatted as described in RFC 3784 [IS-IS-TE].
任意のサブTLVsの1セットは旗の野原に続くかもしれません。 サブTLVsがRFC3784で説明されるようにフォーマットされる、[TEである、]
TYPE: 242
LENGTH: from 5 to 255
VALUE:
Router ID (4 octets)
Flags (1 octet)
Set of optional sub-TLVs (0-250 octets)
以下をタイプしてください。 242の長さ: 5〜255値: (1つの八重奏)が設定した任意のサブTLVsのルータID(4つの八重奏)旗(0-250 八重奏)
Flags
旗
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |D|S|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | 予約されます。|D|S| +-+-+-+-+-+-+-+-+
Currently two bit flags are defined.
現在の、2ビットの旗は定義されます。
S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV MUST be flooded across the entire routing domain. If the S bit is not set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking.
Sビット(0×01): Sに噛み付いたならセットが(1)である、-、全体の経路ドメインの向こう側にRouter CAPABILITY TLVをあふれさせなければなりません。 Sビットはセット(0)、TLV MUST NOTではありません。レベルの間で漏らされます。 TLV漏出の間、このビットを変更してはいけません。
D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST be clear. IS-IS Router capability TLVs with the D bit set MUST NOT be leaked from level-1 to level-2. This is to prevent TLV looping.
Dビット(0×02): いつ、-、Router CAPABILITY TLVはレベル-2〜レベル-1まで漏らされて、Dビットを設定しなければならないか。 さもなければ、このビットは明確であるに違いありません。 -、レベル-1〜レベル-2までDビットがあるTLVsが設定するRouter能力を漏らしてはいけません。 これは、TLVが輪にするのを防ぐためのものです。
The Router CAPABILITY TLV is OPTIONAL. As specified in Section 3, more than one Router CAPABILITY TLV from the same source MAY be present.
Router CAPABILITY TLVはOPTIONALです。 セクション3で指定されるように、同じソースからの1Router CAPABILITY TLVが存在しているかもしれません。
This document does not specify how an application may use the Router Capability TLV and such specification is outside the scope of this document.
このドキュメントはアプリケーションがどうRouter Capability TLVを使用するかもしれないかを指定しません、そして、このドキュメントの範囲の外にそのような仕様はあります。
Vasseur, et al. Standards Track [Page 3] RFC 4971 IS-IS Extensions for Advertising Router Info July 2007
Vasseur、他 規格がRFC4971を追跡する、[3ページ]-、ルータインフォメーション2007年7月に広告を出すための拡大
3. Elements of Procedure
3. 手順のElements
A router that generates a CAPABILITY TLV MUST have a Router ID that is a 32-bit number. The ID MUST be unique within the IS-IS area. If the router generates any capability TLVs with domain flooding scope, then the ID MUST also be unique within the IS-IS routing domain.
CAPABILITY TLV MUSTを発生させるルータは32ビットの数であるRouter IDを持っています。 IDが中でユニークであるに違いない、-、領域。 また、ルータがドメイン氾濫範囲があるどんな能力TLVsも発生させるならIDも中でユニークであるに違いない、-、経路ドメイン
When advertising capabilities with different flooding scopes, a router MUST originate a minimum of two Router CAPABILITY TLVs, each TLV carrying the set of sub-TLVs with the same flooding scope. For instance, if a router advertises two sets of capabilities, C1 and C2, with an area/level scope and routing domain scope respectively, C1 and C2 being specified by their respective sub-TLV(s), the router will originate two Router CAPABILITY TLVs:
異なった氾濫範囲で能力の広告を出すとき、ルータは最低2Router CAPABILITY TLVs(同じ氾濫範囲があるサブTLVsのセットを運ぶ各TLV)を溯源しなければなりません。 例えば、ルータが2セットの能力、C1、およびC2の広告を出すと、領域/平らな範囲、それぞれ経路ドメインの範囲C1、およびそれらのそれぞれのサブTLV(s)によって指定されるC2と共にルータは2Router CAPABILITY TLVsを溯源するでしょう:
- One Router CAPABILITY TLV with the S flag cleared, carrying the
sub-TLV(s) relative to C1. This Router CAPABILITY TLV will not be
leaked into another level.
- C1に比例したサブTLV(s)を運んで、S旗がある1Router CAPABILITY TLVがクリアしました。 このRouter CAPABILITY TLVは別のレベルに漏らされないでしょう。
- One Router CAPABILITY TLV with the S flag set, carrying the sub-
TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked
into other IS-IS levels. When the TLV is leaked from level-2 to
level-1, the D bit will be set in the level-1 LSP advertisement.
- C2に比例したサブTLV(s)を運んで、S旗がある1Router CAPABILITY TLVがセットしました。 このRouter CAPABILITY TLVが他に漏らされる、-、レベル。 TLVがレベル-2〜レベル-1まで漏らされるとき、Dビットはレベル-1LSP広告に設定されるでしょう。
In order to prevent the use of stale capabilities, a system MUST NOT use a Capability TLV present in an LSP of a system that is not currently reachable via Level-x paths, where "x" is the level (1 or 2) in which the sending system advertised the TLV. This requirement applies regardless of whether or not the sending system is the originator of the Capabilities TLV. Note that leaking a Capabilities TLV is one of the uses that is prohibited under these conditions.
聞き古した能力の使用を防ぐために、システムは現在「x」が送付システムがTLVの広告を出したレベル(1か2)であるLevel-x経路を通して届いていないシステムのLSPの現在のCapability TLVを使用してはいけません。 この要件は送付システムがCapabilities TLVの創始者であるかどうかにかかわらず適用されます。 Capabilities TLVを漏らすのが、これらの条件で禁止されている用途の1つであることに注意してください。
Example: If Level-1 router A generates a Capability TLV and floods
it to two L1/L2 routers, S and T, they will flood it into the
Level-2 domain. Now suppose the Level-1 area partitions, such
that A and S are in one partition and T is in another. IP routing
will still continue to work, but if A now issues a revised version
of the CAP TLV, or decides to stop advertising it, S will follow
suit, but T will continue to advertise the old version until the
LSP times out.
例: Level-1ルータAが2L1/L2ルータ、S、およびTへCapability TLVを発生させて、それをあふれさせると、それらはLevel-2ドメインへそれをあふれさせるでしょう。 今度は、AとSが1つのパーティション中であり、Tが別のものにあるように、Level-1領域パーティションを仮定してください。 それでも、IPルーティングは、働き続けるでしょうが、Aが、現在CAP TLVの改訂版を発行するか、またはそれの広告を出すのを止めると決めると、Sは先例に従うでしょうが、Tは、外にLSP回まで古いバージョンの広告を出し続けるでしょう。
Routers in other areas have to choose whether to trust T's copy of A's capabilities or S's copy of A's information and, they have no reliable way to choose. By making sure that T stops leaking A's information, this removes the possibility that other routers will use stale information from A.
他の領域のルータは、Aの能力に関するTのコピーかAの情報に関するSのコピーを信じるかどうかを選ばなければなりません、そして、それらには、選ぶどんな信頼できる方法もありません。 Tが、Aの情報を漏らすのを止めるのを確実にすることによって、これはAから他のルータが聞き古した情報を使用する可能性を取り除きます。
Vasseur, et al. Standards Track [Page 4] RFC 4971 IS-IS Extensions for Advertising Router Info July 2007
Vasseur、他 規格がRFC4971を追跡する、[4ページ]-、ルータインフォメーション2007年7月に広告を出すための拡大
In IS-IS, the atomic unit of the update process is a TLV -- or more precisely, in the case of TLVs that allow multiple entries to appear in the value field (e.g., IS-neighbors), the atomic unit is an entry in the value field of a TLV. If an update to an entry in a TLV is advertised in an LSP fragment different from the LSP fragment associated with the old advertisement, the possibility exists that other systems can temporarily have either 0 copies of a particular advertisement or 2 copies of a particular advertisement, depending on the order in which new copies of the LSP fragment that had the old advertisement and the fragment that has the new advertisement arrive at other systems.
中、-、更新処理の原子力単位はa TLVであるか多回入国を値の分野(例えば、隣人である)、原子力ユニットに現れさせるTLVsの場合では、より正確に、TLVの値の分野でのエントリーがTLVです。 TLVのエントリーへのアップデートが古い広告に関連しているLSP断片と異なったLSP断片の広告に掲載されるなら、他のシステムが一時特定の広告のコピー0部か特定の広告のコピー2部のどちらかを持つことができる可能性は存在しています、古い広告を出していたLSP断片と新しい広告を出している断片の新しいコピーが他のシステムに届くオーダーによって。
Wherever possible, an implementation SHOULD advertise the update to a capabilities TLV in the same LSP fragment as the advertisement that it replaces. Where this is not possible, the two affected LSP fragments should be flooded as an atomic action.
どこでも、可能であるところでは、実現SHOULDがそれが取り替える広告と同じLSP断片の能力TLVにアップデートの広告を出します。 これが可能でないところでは、2個の影響を受けるLSP断片が原子動作として水につかっているべきです。
Systems that receive an update to an existing capability TLV can minimize the potential disruption associated with the update by employing a holddown time prior to processing the update so as to allow for the receipt of multiple LSP fragments associated with the same update prior to beginning processing.
既存の能力TLVにアップデートを受けるシステムは処理し始める前の同じアップデートに関連している複数のLSP断片の領収書を考慮するためにアップデートを処理する前に留め具時間を使うことによってアップデートに関連している潜在的分裂を最小にすることができます。
Where a receiving system has two copies of a capabilities TLV from the same system that have different settings for a given attribute, the procedure used to choose which copy shall be used is undefined.
受電方式には同じシステムからの与えられた属性のための異なった設定を持っている能力TLVのコピー2部があるところでは、どのコピーが使用されるかを選ぶのに用いられた手順は未定義です。
4. Interoperability with Routers Not Supporting the Capability TLV
4. ルータが能力TLVを支持していない相互運用性
Routers that do not support the Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP. Routers that do not support specific sub-TLVs carried within a Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and continue processing those sub-TLVs that are supported in the Router CAPABILITY TLV. How partial support may impact the operation of the capabilities advertised within the Router CAPABILITY TLV is outside the scope of this document.
Router CAPABILITY TLVを支持しないルータは、静かにTLV(s)を無視して、同じLSPで他のTLVsを処理し続けなければなりません。 Router CAPABILITY TLVの中で運ばれた特定のサブTLVsを支持しないルータは、静かにサポートされないサブTLVsを無視して、Router CAPABILITY TLVで支持されるサブTLVsであるものを処理し続けなければなりません。 このドキュメントの範囲の外に部分的なサポートがどうRouter CAPABILITY TLVの中に広告に掲載された能力の操作に影響を与えるかもしれないかがあります。
In order for Router CAPABILITY TLVs with domain-wide scope originated by L1 Routers to be flooded across the entire domain, at least one L1/L2 Router in every area of the domain MUST support the Router CAPABILITY TLV.
全体のドメインの向こう側にあふれるようにL1 Routersによって溯源されたドメイン広範囲があるRouter CAPABILITY TLVsにおいて整然とします、ドメインのあらゆる領域の少なくとも1L1/L2 RouterがRouter CAPABILITY TLVを支持しなければなりません。
If leaking of the CAPABILITY TLV is required, the entire CAPABILITY TLV MUST be leaked into another level even though it may contain some of the unsupported sub-TLVs.
CAPABILITY TLVの漏出が必要です、全体のCAPABILITY TLV MUST。いくつかのサポートされなさサブTLVsを含むかもしれませんが、別のレベルに漏らされてください。
Vasseur, et al. Standards Track [Page 5] RFC 4971 IS-IS Extensions for Advertising Router Info July 2007
Vasseur、他 規格がRFC4971を追跡する、[5ページ]-、ルータインフォメーション2007年7月に広告を出すための拡大
5. Security Considerations
5. セキュリティ問題
Any new security issues raised by the procedures in this document depend upon the opportunity for LSPs to be snooped and modified, the ease/difficulty of which has not been altered. As the LSPs may now contain additional information regarding router capabilities, this new information would also become available to an attacker. Specifications based on this mechanism need to describe the security considerations around the disclosure and modification of their information. Note that an integrity mechanism, such as the one defined in [RFC-3567] or [IS-IS-HMAC], should be applied if there is high risk resulting from modification of capability information.
手順で提起されたどんな新しい安全保障問題も本書ではLSPsが詮索されて、変更される機会に依存します。その容易さ/困難は変更されていません。 また、LSPsが現在ルータ能力に関する追加情報を含むとき、この新情報は攻撃者にとって利用可能になるでしょう。 このメカニズムに基づく仕様は、それらの情報の公開と変更の周りでセキュリティ問題について説明する必要があります。 または、保全メカニズムで、[RFC-3567]で定義されたものとしてあれほど状態でそれに注意してください、[HMACである、]、能力情報の変更から生じる高いリスクがあれば、適用されるべきであってください。
6. IANA Considerations
6. IANA問題
IANA assigned a new IS-IS TLV code-point for the newly defined IS-IS TLV type named the IS-IS Router CAPABILITY TLV and defined in this document. The assigned value is 242.
IANAが新しい状態でaを割り当てた、-、IS TLV、新たに定義されているコード・ポイント、-、IS TLV、タイプが命名した、-、Router CAPABILITY TLVであってこのドキュメントで定義されています。 割り当てられた値は242です。
7. Acknowledgment
7. 承認
The authors would like to thank Jean-Louis Le Roux, Paul Mabey, Andrew Partan, and Adrian Farrel for their useful comments.
作者は彼らの役に立つコメントについてジャン・ルイル・ルー、ポールMabey、アンドリューPartan、およびエードリアン・ファレルに感謝したがっています。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[IS-IS] "Intermediate System to Intermediate System Intra-
Domain Routeing Exchange Protocol for use in
Conjunction with the Protocol for Providing the
Connectionless-mode Network Service (ISO 8473)", ISO
10589.
[-、]、「プロトコルがあるConjunctionにおける、Providing Connectionless-モードNetwork Service(ISO8473)の使用のためのIntermediate System IntraドメインRouteing Exchangeプロトコルへの中間的System」、ISO10589
[RFC-3567] Li, T. and R. Atkinson, "Intermediate System to
Intermediate System (IS-IS) Cryptographic
Authentication", RFC 3567, July 2003.
[RFC-3567] 李、T.、およびR.アトキンソン、「中間システムへの中間システム、(-、)、暗号の認証、」、RFC3567、7月2003日
[IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[IPである、]、Callon、R.、「使用、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在、」、RFC1195、12月1990日
[IS-IS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004.
[Teである、]、スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(2004年6月)
Vasseur, et al. Standards Track [Page 6] RFC 4971 IS-IS Extensions for Advertising Router Info July 2007
Vasseur、他 規格がRFC4971を追跡する、[6ページ]-、ルータインフォメーション2007年7月に広告を出すための拡大
8.2. Informative References
8.2. 有益な参照
[AUTOMESH] Vasseur, JP., Ed., Le Roux, JL., Ed., Yasukawa, S.,
Previdi, S., Psenak, P., and P. Mabbey, "Routing
extensions for Discovery of Multiprotocol (MPLS) Label
Switch Router (LSR) Traffic Engineering (TE) Mesh
Membership", RFC 4972, July 2007.
[AUTOMESH]Vasseur(JP)、エド、ル・ルー(JL)、エド、Yasukawa、S.、Previdi、S.、Psenak、P.、およびP.Mabbey、「Multiprotocol(MPLS)ラベルSwitch Router(LSR)交通Engineering(TE)のディスカバリーのためのルート設定拡大はMembershipを網の目にかけます」、RFC4972、7月2007
[TE-NODE-CAP] Vasseur, JP., Ed., and J.L. Le Roux, "Routing
Extensions for Discovery of Traffic Engineering Node
Capabilities", Work in Progress, April 2007.
[Teノードキャップ]Vasseur(JP)、エドJ.L.ル・ルー、「交通工学ノード能力の発見のためのルート設定拡大」は進行中(2007年4月)で働いています。
[P2MP] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
May 2007.
[P2MP]Aggarwal、R.(エド)、Papadimitriou、D.(エド)、およびS.Yasukawa(エド)、「資源予約プロトコルへの拡大--ポイントから多点へのTeラベルのための交通工学(RSVP-Te)は経路(LSPs)を切り換えました」、RFC4875、2007年5月。
[P2MP-REQS] Yasukawa, S., Ed., "Signaling Requirements for Point-
to-Multipoint Traffic-Engineered MPLS Label Switched
Paths (LSPs)", RFC 4461, April 2006.
エド[P2MP-REQS]Yasukawa、S.、RFC4461、「ポイントの多点への交通で設計されたMPLSラベルの切り換えられた経路(LSPs)のための要件に合図すること」での4月2006日
[IS-IS-HMAC] Bhatia, M., Ed. and V. Manral, Ed., "IS-IS Generic
Cryptographic Authentication", Work in Progress, May
2007.
[HMACである、]、エドBhatia、M.、V.Manral、エド、「-、一般的な暗号の認証、」、5月2007、進行中で、働いてください。
Authors' Addresses
作者のアドレス
Jean-Philippe Vasseur CISCO Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com
Boxborough、Inc.1414MA01719米国マサチューセッツ通りがメールするジャンフィリップVasseurコクチマスシステム: jpv@cisco.com
Stefano Previdi CISCO Systems, Inc. Via Del Serafico 200 00142 - Roma ITALY EMail: sprevidi@cisco.com
デルSerafico200 00142を通したステファーノPrevidiコクチマスシステムInc.--ローマイタリアメール: sprevidi@cisco.com
Vasseur, et al. Standards Track [Page 7] RFC 4971 IS-IS Extensions for Advertising Router Info July 2007
Vasseur、他 規格がRFC4971を追跡する、[7ページ]-、ルータインフォメーション2007年7月に広告を出すための拡大
Mike Shand Cisco Systems 250 Longwater Avenue, Reading, Berkshire, RG2 6GB UK EMail: mshand@cisco.com
マイクシャンドシスコシステムズ250Longwater Avenue、読書、バークシャー、RG2 6GBイギリスのメール: mshand@cisco.com
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, Ca. 95035 USA EMail: ginsberg@cisco.com
レスギンズバーグシスコシステムズ510マッカーシーBlvd. ミルピタス、Ca。 95035 米国メール: ginsberg@cisco.com
Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519 USA EMail: acee@redback.com
Acee Lindem20ドル紙幣ネットワーク102こづなつなぎ法廷のケーリー、NC27519米国メール: acee@redback.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: naiming@cisco.com
シンシスコシステムズ225の西タスマンDriveサンノゼ、カリフォルニア95134米国をNaimingして、メールしてください: naiming@cisco.com
Rahul Aggarwal Juniper Networks 1194 N. Mathilda Avenue San Jose, CA 94089 USA EMail: rahul@juniper.net
N.マチルダ・Avenueカリフォルニア94089サンノゼ(米国)がメールするRahul Aggarwal杜松ネットワーク1194: rahul@juniper.net
Scott Shaffer EMail: sshaffer@bridgeport-networks.com
スコットシャッファーEMail: sshaffer@bridgeport-networks.com
Vasseur, et al. Standards Track [Page 8] RFC 4971 IS-IS Extensions for Advertising Router Info July 2007
Vasseur、他 規格がRFC4971を追跡する、[8ページ]-、ルータインフォメーション2007年7月に広告を出すための拡大
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Vasseur, et al. Standards Track [Page 9]
Vasseur、他 標準化過程[9ページ]
一覧
スポンサーリンク
