RFC3786 日本語訳

3786 Extending the Number of Intermediate System to IntermediateSystem (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit.A. Hermelin, S. Previdi, M. Shand. May 2004. (Format: TXT=29164 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        A. Hermelin
Request for Comments: 3786                                 Montilio Inc.
Category: Informational                                       S. Previdi
                                                                M. Shand
                                                           Cisco Systems
                                                                May 2004

コメントを求めるワーキンググループA.ハームリンの要求をネットワークでつないでください: 3786年のMontilio株式会社カテゴリ: 情報のS.Previdi M.シャンドシスコシステムズ2004年5月

                        Extending the Number of
          Intermediate System to Intermediate System (IS-IS)
          Link State PDU (LSP) Fragments Beyond the 256 Limit

中間システムの数を中間システムに広げる、(-、)、256限界を超えて州のPDU(LSP)断片をリンクしてください。

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Copyright(C)インターネット協会(2004)。 All rights reserved。

Abstract

要約

   This document describes a mechanism that allows a system to originate
   more than 256 Link State PDU (LSP) fragments, a limit set by the
   original Intermediate System to Intermediate System (IS-IS) Routing
   protocol, as described in ISO/IEC 10589.  This mechanism can be used
   in IP-only, OSI-only, and dual routers.

このドキュメントはシステムが256以上Link州PDU(LSP)断片を溯源できるメカニズムについて説明します、Intermediate SystemへのオリジナルのIntermediate Systemによる極限集合、(-、)、ISO/IEC10589で説明されるようにプロトコルを発送すること。 IP唯一の、そして、OSI唯一の、そして、二元的なルータにこのメカニズムを使用できます。

Table of Contents

目次

   1.  Introduction .................................................  2
       1.1.  Keywords ...............................................  2
       1.2.  Definitions of Commonly Used Terms .....................  2
       1.3.  Operation Modes ........................................  3
       1.4.  Overview ...............................................  4
   2.  IS Alias ID TLV (IS-A) .......................................  5
   3.  Generating LSPs ..............................................  6
       3.1.  Both Operation Modes ...................................  6
       3.2.  Operation Mode 1 Additives .............................  8
   4.  Purging Extended LSP Fragments ............................... 10
   5.  Modifications to LSP handling in SPF ......................... 10
   6.  Forming Adjacencies .......................................... 11
   7.  Interoperating between extension-capable and non-capable ISs . 11
   8.  Security Considerations ...................................... 12
   9.  Acknowledgements ............................................. 12

1. 序論… 2 1.1. キーワード… 2 1.2. 一般的に使用された期間の定義… 2 1.3. 操作モード… 3 1.4. 概観… 4 2. Alias IDがTLVである、(-、a)、… 5 3. LSPsを発生させます… 6 3.1. 両方のオペレーションモード… 6 3.2. オペレーションモード1添加物… 8 4. 除くのはLSP断片を広げました… 10 5. SPFのLSP取り扱いへの変更… 10 6. 隣接番組を形成します… 11 7. 拡大できて非できるISs. 11 8の間に共同利用します。 セキュリティ問題… 12 9. 承認… 12

Hermelin, et al.             Informational                      [Page 1]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[1ページ]のRFC3786、-、LSPは2004年5月に断片化します。

   10. References ................................................... 12
   11. Authors' Addresses ........................................... 13
   12. Full Copyright Statement ..................................... 14

10. 参照… 12 11. 作者のアドレス… 13 12. 完全な著作権宣言文… 14

1.  Introduction

1. 序論

   In the Intermediate System to Intermediate System (IS-IS) protocol, a
   system floods its link-state information in Link State PDU (LSP) Data
   Units, or LSPs for short.  These logical LSPs can become quite large,
   therefore the protocol specifies a means of fragmenting this
   information into multiple LSP fragments.  The number of fragments a
   system can generate is limited by ISO/IEC 10589 [ISIS-ISO] to 256
   fragments, where each fragment's size is also limited.  Hence, there
   is a limit on the amount of link-state information a system can
   generate.

Intermediate SystemへのIntermediate System、(-、)、プロトコル、システムは略してLink州PDU(LSP)データのUnits、またはLSPsのリンク州の情報をあふれさせます。 これらの論理的なLSPsはかなり大きくなることができます、したがって、プロトコルが複数のLSP断片にこの情報を断片化する手段を指定します。 システムが発生させることができる断片の数はISO/IEC10589[イシス-ISO]によって256個の断片に制限されます。また、各断片のサイズはそこで制限されます。 したがって、限界がシステムが発生させることができるリンク州の情報の量にあります。

   A number of factors can contribute to exceeding this limit:

多くの要因はこの限界を超えているのに貢献できます:

   -  Introduction of new TLVs and sub-TLVs to be included in LSPs.
   -  The use of LSPs to propagate various types of information (such as
      traffic-engineering information).
   -  The increasing number of destinations and AS topologies.
   -  Finer granularity routing, and the ability to inject external
      routes into areas [DOMAIN-WIDE].
   -  Other emerging technologies, such as optical, IPv6, etc.

- LSPsに含まれるべき新しいTLVsとサブTLVsの導入。 - 様々なタイプの情報(交通工学情報などの)を伝播するLSPsの使用。 - 目的地とAS topologiesの増加する数。 - よりすばらしい粒状ルーティング、および領域[DOMAIN-WIDE]に外部経路を注ぐ能力。 - 他の未来技術、光学としてのそのような、IPv6など

   This document describes mechanisms to relax the limit on the number
   of LSP fragments.

このドキュメントは、LSP断片の数における限界を弛緩するためにメカニズムについて説明します。

1.1.  Keywords

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 BCP 14, RFC 2119
   [BCP14].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[BCP14]で説明されるように本書では解釈されることであるべきです。

1.2.  Definitions of Commonly Used Terms

1.2. 一般的に使用された期間の定義

   This section provides definitions for terms that are used throughout
   the text.

このセクションはテキスト中で使用される用語に定義を提供します。

      Originating System
         A router physically running the IS-IS protocol.  As this
         document describes methods allowing a single IS-IS process to
         advertise its LSPs as multiple "virtual" routers, the
         Originating System represents the single "physical" IS-IS
         process.

由来しているSystem Aルータが物理的に走る、-、議定書を作ってください。 このドキュメントがシングルを許容する方法を説明する、-、複数の「仮想」のルータとしてLSPsの広告を出す過程、Originating Systemが「物理的に」シングルを表す、-、処理してください。

Hermelin, et al.             Informational                      [Page 2]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[2ページ]のRFC3786、-、LSPは2004年5月に断片化します。

      Normal system-id
         The system-id of an Originating System.

正常なシステムイド、Originating Systemのシステムイド。

      Additional system-id
         An Additional system-id that is assigned by the network
         administrator.  Each Additional system-id allows generation of
         256 additional, or extended, LSP fragments.  The Additional
         system-id, like the Normal system-id, must be unique throughout
         the routing domain.

ネットワーク管理者によって割り当てられる追加システムイドAn Additionalシステムイド。 それぞれのAdditionalシステムイドは256個の追加しているか、拡張しているLSP断片の世代を許容します。 Normalシステムイドのように、Additionalシステムイドは経路ドメイン中でユニークであるに違いありません。

      Virtual System
         The system, identified by an Additional system-id, advertised
         as originating the extended LSP fragments.  These fragments
         specify the Additional system-id in their LSP IDs.

Additionalシステムイドによって特定されたシステムが拡張LSP断片を溯源するとして広告を出した仮想のSystem。 これらの断片はそれらのLSP IDにおけるAdditionalシステムイドを指定します。

      Original LSP
         An LSP using the Normal system-id in its LSP ID.

LSP IDのNormalシステムイドを使用するオリジナルのLSP An LSP。

      Extended LSP
         An LSP using an Additional system-id in its LSP ID.

LSP IDのAdditionalシステムイドを使用する拡張LSP An LSP。

      LSP set
         Logical LSP.  This term is used only to resolve the ambiguity
         between a logical LSP and an LSP fragment, both of which are
         sometimes termed "LSP".

LSPはLogical LSPを設定します。 今期は使用されますが、論理的なLSPとLSP断片の間のあいまいさを取り除きます。それの両方が断片のために時々"LSP"と呼ばれます。

      Extended LSP set
         A group of LSP fragments using an Additional system-id, and
         originated by the Originating System.

拡張LSPはOriginating SystemによってAdditionalシステムイドを使用して、溯源されたLSP断片のAグループを設定します。

      Extension-capable IS
         An IS implementing the mechanisms described in this document.

拡大できるのは、Anが本書では説明されたメカニズムを実行しているということです。

1.3.  Operation Modes

1.3. オペレーションモード

   Two administrative operation modes are provided:

2つの管理オペレーションモードを提供します:

   -  Operation Mode 1 provides behavior that allows implementations
      that don't support this extension, to correctly process the
      extended fragment information, without any modifications.  This
      mode has some restrictions on what may be advertised in the
      extended LSP fragments.  Namely, only leaf information may be
      advertised in the extended LSPs.

- 操作Mode1は正しく拡張断片情報を処理するためにこの拡大を支持しない実現を許す振舞いを提供します、少しも変更なしで。 このモードには、拡張LSP断片の広告に掲載されるかもしれないことに関するいくつかの制限があります。 拡張LSPsに葉の情報だけの広告を出すかもしれません。

Hermelin, et al.             Informational                      [Page 3]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[3ページ]のRFC3786、-、LSPは2004年5月に断片化します。

   -  Operation Mode 2 extends the previous mode and relaxes its
      advertisement restrictions.  Any link-state information may be
      advertised in the extended LSPs.  However, it mandates a change to
      the way LSPs are considered during the SPF algorithm, in a way
      that is not compatible with previous implementations.

- 操作Mode2は、前のモードを広げていて、広告規制を緩和します。 拡張LSPsにどんなリンク州の情報も広告を出すかもしれません。 しかしながら、LSPsがSPFアルゴリズムの間、考えられる方法への変化を強制します、前の実現と互換性がない方法で。

   These modes are configured on a per-level and area basis.  That is,
   all LSPs considered in the same SPF instance MUST use the same Mode.
   There is no restriction that an L1/L2 IS operates in the same mode,
   for both its L1 and L2 instances.  It can use Mode 1 for its L1 LSPs,
   and Mode 2 for its L2 LSPs, or vice versa.

これらのモードはレベルと地域制で構成されます。 同じSPF例で考えられたすなわちすべてのLSPsが同じModeを使用しなければなりません。 L1/L2 ISがL1とL2例の両方のために同じモードで作動するという制限が全くありません。 それは、L1 LSPsにMode1を使用して、L2 LSPsにMode2を使用できますか、逆もまた同様です。

   Mode 1 has the only advantage of being backwards compatible with
   older implementations.  It does have restrictions which are
   considered drawbacks.  Therefore, routers should operate in Mode 1
   only if backwards compatibility is desired.  Otherwise, it is
   recommended to run in Mode 2.

モード1で、後方に存在の唯一の利点が、より古い実現と互換性があるようになります。 それには、欠点であると考えられる制限があります。 したがって、遅れている互換性が望まれている場合にだけ、ルータはMode1で作動するべきです。 さもなければ、Mode2に立候補するのはお勧めです。

   Routers MAY implement Operational Mode 2 without supporting running
   in Operational Mode 1.  They will still interoperate correctly with
   routers that support both modes.

Operational Mode1へ駆け込むのを支持しない、ルータはOperational Mode2を実行するかもしれません。 それでも、彼らは両方のモードを支持するルータで正しく共同利用するでしょう。

1.4.  Overview

1.4. 概観

   Using Additional system-ids assigned by the administrator, the
   Originating System can advertise the excess link-state information in
   extended LSPs under these Additional system-ids.  It would do so as
   if other routers, or "Virtual Systems", were advertising this
   information.  These extended LSPs will also have the specified limit
   on their LSP fragments; however, the Originating System may generate
   extended LSPs under numerous Virtual Systems.

管理者によって割り当てられたAdditionalシステムイドを使用して、Originating SystemはこれらのAdditionalシステムイドの下で拡張LSPsの余分なリンク州の情報の広告を出すことができます。 ルータ、または「仮想のシステム」がまるで他ようであったことで、それは、この情報の広告を出しながら、そうするでしょう。 また、これらの拡張LSPsは彼らのLSP断片の上に指定限界を持つでしょう。 しかしながら、Originating Systemは多数のVirtual Systemsの下で拡張LSPsを発生させるかもしれません。

   For Operation Mode 1, 0-cost adjacencies are advertised from the
   Originating System to its Virtual System(s).  No adjacencies (other
   than back to the Originating System) are advertised in the extended
   LSPs.  As a consequence, the Virtual Systems are 'stub', meaning they
   can only be reached through their Originating System.  Therefore,
   older implementations do not need modifications in order to correctly
   process these extended LSPs.

Operation Mode1に関しては、Originating SystemからVirtual System(s)まで0費用の隣接番組の広告を出します。 拡張LSPsに隣接番組(Originating Systemを除いた)の全く広告を出しません。 結果として、彼らに彼らのOriginating Systemを通して達することができるだけであることを意味して、Virtual Systemsは'スタッブ'です。 したがって、より古い実現は、正しくこれらの拡張LSPsを処理するために変更を必要としません。

   For both modes, each LSP (set) created by a node will contain in its
   fragment-0 a new TLV (IS Alias ID TLV) that contains the Normal
   system-id and PN Number of the Original LSP created by the router.
   Extension-capable ISs can then use this information and store the
   original and extended LSPs as one logical LSP.

両方のモードのために、ノードによって作成された各LSP(設定する)は断片-0にルータによって作成されたOriginal LSPのNormalシステムイドとPN Numberを含む新しいTLV(アリアID TLVである)を含むでしょう。 拡大できるISsは1論理的なLSPとして次に、この情報を使用して、オリジナルの、そして、拡張しているLSPsを格納できます。

   The only sections that deal only with Mode 1 additions are 3.2,
   3.2.1, and 3.2.2.  All other sections relate to both modes.

Mode1追加だけに対処する唯一のセクションが3.2、3.2である、.1、および3.2、.2 他のすべてのセクションが両方のモードに関連します。

Hermelin, et al.             Informational                      [Page 4]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[4ページ]のRFC3786、-、LSPは2004年5月に断片化します。

2.  IS Alias ID TLV (IS-A)

2. Alias IDはTLVですか?(伊佐a)

   The proposed IS-A TLV allows extension-capable ISs to recognize all
   LSPs of an Originating System, and combine the original and extended
   LSPs for the purpose of SPF computation.  It identifies the Normal
   system-id of the Originating System.

提案、-1、TLVは拡大できるISsにOriginating SystemのすべてのLSPsを認識して、SPF計算の目的のためにオリジナルの、そして、拡張しているLSPsを結合させます。 それはOriginating SystemのNormalシステムイドを特定します。

   The proposed IS Alias ID TLV is type 24, and its format is as
   follows:

提案によるアリアID TLVがタイプ24であるということです、そして、形式は以下の通りです:

   x CODE   - 24.

x CODE--24。

   x LENGTH - total length of the value field.

x LENGTH--値の分野の全長。

   x VALUE  -

x VALUE、-

                            No. of Octets
      +-------------------+
      | Normal system-id  |      6
      +-------------------+
      | Pseudonode number |      1
      +-------------------+
      | Sub-TLVs length   |      1
      +-------------------+
      |                   |     0-247
      : Sub-TLVs          :
      :                   :
      |                   |
      +-------------------+

八重奏+についていいえ-------------------+ | 正常なシステムイド| 6 +-------------------+ | Pseudonode番号| 1 +-------------------+ | サブTLVsの長さ| 1 +-------------------+ | | 0-247 : サブTLVs: : : | | +-------------------+

   Normal system-id
      The Normal system-id of the LSP set, as described in section 1.2
      of this document.

この1.2通のセクションで説明されるように用意ができているLSPのNormalシステムイドの正常なシステムイドドキュメント。

   Pseudonode number
      The Pseudonode number of the LSP set.  LSPs with the same Normal
      system-id and Pseudonode number are considered in SPF as one
      logical LSP, as described in section 5 of this document.

LSPのPseudonode番号が設定するPseudonode番号。 同じNormalシステムイドとPseudonode番号があるLSPsはSPFで1論理的なLSPと考えられます、このドキュメントのセクション5で説明されるように。

   Sub-TLVs length
      Total length of all sub-TLVs.

すべてのサブTLVsのサブTLVs長さのTotalの長さ。

Hermelin, et al.             Informational                      [Page 5]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[5ページ]のRFC3786、-、LSPは2004年5月に断片化します。

   Sub-TLVs
   A series of tuples with the following format:

以下の形式があるtuplesのサブTLVs Aシリーズ:

                         No. of Octets
   +-------------------+
   | Sub-type          |      1
   +-------------------+
   | Length            |      1
   +-------------------+
   |                   |     0-245
   : Value             :
   :                   :
   |                   |
   +-------------------+

八重奏+についていいえ-------------------+ | サブタイプ| 1 +-------------------+ | 長さ| 1 +-------------------+ | | 0-245 : 値: : : | | +-------------------+

   Sub-type
      Type of the sub-TLV

サブTLVのサブタイプタイプ

   Length
      Total length of the value field

値の分野の長さのTotalの長さ

   Value
      Type-specific TLV payload.

Type特有のTLVペイロードを評価してください。

   For an explanation on sub-TLV handling, see [ISIS-TE].

サブTLV取り扱いに関する説明に関しては、[イシス-TE]を見てください。

   Without sub-TLVs, this structure consumes 8 octets per LSP set.  This
   TLV MUST be included in fragment 0 of every LSP set belonging to an
   Originating System running in either Mode 1 or Mode 2.  Currently,
   there are no sub-TLVs defined.

サブTLVsがなければ、この構造はLSPセットあたり8つの八重奏を消費します。 このTLV MUST、Mode1かMode2のどちらかへ駆け込むOriginating Systemに属すのを用意ができているあらゆるLSPの断片0で含められてください。 現在、定義されたサブTLVsが全くありません。

   For a complete list of used IS-IS TLV numbers, see [ISIS-CODES].

全リスト、中古である、-、IS TLV、数、[イシス-CODES]を見てください。

3.  Generating LSPs

3. LSPsを発生させます。

3.1.  Both Operation Modes

3.1. 両方のオペレーションモード

   Under both modes, the Originating System MUST include information
   binding the Original LSP and the Extended ones.  It can do this since
   it is trivially an extension-capable IS.  This is to ensure other
   extension-capable routers correctly process the extra information in
   their SPF calculation.  This binding is advertised via a new IS Alias
   ID TLV, which is advertised in all fragment 0 of Original and
   Extended LSPs.

両方のモードの下では、Originating SystemはOriginal LSPとExtendedものを縛る情報を含まなければなりません。 それが些細なことにするのでこれができる、拡大できる、あります。 これは、他の拡大できるルータが正しく彼らのSPF計算におけるその他の情報を処理するのを保証するためのものです。 この結合はaを通して新しく広告を出しているのが、アリアID TLV(Originalと0すべての断片Extended LSPsの広告に掲載されている)であるということです。

Hermelin, et al.             Informational                      [Page 6]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[6ページ]のRFC3786、-、LSPは2004年5月に断片化します。

   +---------------------------------------------+
   |  Originating System                         |
   |  system-id   = S                            |
   |  is-alias-id = S                            |
   +---------------------------------------------+

+---------------------------------------------+ | 由来しているシステム| | システムイド=S| | 別名がイドである=S| +---------------------------------------------+

   +-------------------+     +-------------------+
   |  Virtual System   |     |  Virtual System   |
   |  system-id   = S' |     |  system-id   = S''|
   |  is-alias-id = S  |     |  is-alias-id = S  |
   +-------------------+     +-------------------+

+-------------------+ +-------------------+ | 仮想のシステム| | 仮想のシステム| | システムイド=S| | 「システムイド=S」| | 別名がイドである=S| | 別名がイドである=S| +-------------------+ +-------------------+

   Figure 1. Advertising binding between all of a system's LSPs
             (both modes).  S' and S'' are configured as Additional
             system-ids.

図1。 システムのLSPs(両方のモード)のすべての間の結合の広告を出します。 「SとS」はAdditionalシステムイドとして構成されます。

   When new extended LSP fragments are generated, these fragments should
   be generated as specified in ISO/IEC 10589 [ISIS-ISO].  Furthermore,
   a system SHOULD treat its extended LSPs the same as it treats its
   original LSPs, with the exceptions noted in the following sections.
   Specifically, creating, flooding, renewing, purging and all other
   operations are similar for both Original and Extended LSPs, unless
   stated otherwise.  The Extended LSPs will use one of the Additional
   system-ids configured for the router, in their LSP ID.

新しい拡張LSP断片が発生するとき、これらの断片はISO/IEC10589[イシス-ISO]で指定されるように発生するべきです。 その上、オリジナルのLSPsを扱うとき、システムSHOULDは同じように拡張LSPsを扱います、以下のセクションで例外が注意されている状態で。 明確に、別の方法で述べられない場合、OriginalとExtended LSPsの両方には、作成、氾濫、更新、除くことおよび他のすべての操作が同様です。 Extended LSPsはそれらのLSP IDでルータのために構成されたAdditionalシステムイドの1つを使用するでしょう。

   Extended LSPs fragment zero should be regarded in the same special
   manner as specified in ISO/IEC 10589 for LSPs with number zero, and
   should include the same type of extra information as specified in
   ISO/IEC 10589 and RFC 1195 [ISIS-IP].  So, for example, when a system
   reissues its LSP fragment zero due to an area address change, it
   should reissue all extended LSPs fragment zero as well.

拡張LSPs断片ゼロは、数ゼロがあるLSPsのためにISO/IEC10589の指定されるのと同じ特別な方法で見なされるべきであり、同じタイプに関する指定されることへのISO/IEC10589とRFC1195[イシス-IP]のその他の情報を含んでいるはずです。 システムが領域アドレス変化のためLSP断片ゼロを再発行するとき、そのように、例えば、それはまた、すべての拡張LSPs断片ゼロを再発行するべきです。

   An extended LSP fragment zero MUST be generated for every extended
   LSP set, to allow a router's SPF calculation to consider those
   fragments in that set.  See section 5 for details.

拡張LSP断片ゼロは設定されるのでそれらの断片を考えるためにルータのSPF計算を許容するのを用意ができているあらゆる拡張LSPのために発生しなければなりません。 詳細に関してセクション5を見てください。

3.1.1.  The Attached Bits

3.1.1. 付属ビット

   The Attached (ATT) bits SHOULD be set to zero for all four metric
   types, on all Extended LSPs.  This is due to the following: if a
   Virtual System is reachable, so is its Originating System.  It is
   preferable, then, that an L1 IS chooses the Originating System and
   not the Virtual System as its nearest L2 exit point, as connectivity
   to the Virtual System has a higher probability of being lost (as a
   result of the extended LSP no longer being advertised).  This could
   cause unnecessary computations on some implementations.

Attached(ATT)ビットSHOULD、すべてのExtended LSPsにすべての4のためにメートル法のタイプのゼロを合わせるように設定されてください。 これは以下のためです: Virtual Systemが届くなら、Originating Systemもそうです。 次に、L1 ISが最も近いL2エキジットポイントとしてVirtual Systemではなく、Originating Systemを選ぶのは、望ましいです、Virtual Systemへの接続性に失われるという(もう広告に掲載されていない拡張LSPの結果、)より高い確率があるとき。 これはいくつかの実現のときに不要な計算を引き起こす場合がありました。

Hermelin, et al.             Informational                      [Page 7]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[7ページ]のRFC3786、-、LSPは2004年5月に断片化します。

3.1.2.  The Partition Repair Bit

3.1.2. パーティション修理ビット

   The Partition Repair (P) bit SHOULD be set to zero on all extended
   LSPs.  This is for the same reasons as for the Attached bits.

Partition Repair(P)はすべてのゼロへのセットが拡張LSPsであったならSHOULDに噛み付きました。 これは同じ理由でAttachedビットに似ています。

3.1.3.  ES Neighbors TLV

3.1.3. ESネイバーズTLV

   ISO/IEC 10589 [ISIS-ISO] section 7.3.7 specifies inserting an ES
   Neighbor TLV in L1 LSPs, with the system ID of the router.  RFC 1195
   [ISIS-IP] relieves IP-only routers of this requirement.  However, for
   routers that do insert this ESN TLV in L1 LSPs (whether IP-only or
   OSI-capable), then in an extended LSP, the ESN TLV should include the
   relevant Additional system-id.  Furthermore, OSI-capable routers
   should accept packets destined for this Additional system-id.

ISO/IEC10589[イシス-ISO]部7.3 .7 ルータのシステムIDでES Neighbor TLVをL1 LSPsに挿入しながら、指定します。 RFC1195[イシス-IP]はIPだけルータにこの要件を取り除きます。 しかしながら、L1 LSPs(IP唯一である、またはOSIできることにかかわらず)と、そして、拡張LSPにこのESN TLVを挿入するルータのために、ESN TLVは関連Additionalシステムイドを含んでいるはずです。 その上、OSIできるルータはこのAdditionalシステムイドのために運命づけられたパケットを受け入れるべきです。

3.1.4.  Overload Bit

3.1.4. オーバーロードビット

   The overload bit should be set consistently across all LSPs, original
   and extended, belonging to an Originating System, and should reflect
   the Originating System's overload state.

オーバーロードビットは、Originating Systemに属して、オリジナルの、そして、拡張しているすべてのLSPsの向こう側に一貫して設定されるべきであり、Originating Systemのオーバーロード状態を反映するはずです。

3.1.5.  Other Fields and TLVs

3.1.5. 他の分野とTLVs

   Other fields and TLVs not mentioned above remain the same, both for
   original and extended LSPs.

他の分野と上に言及されなかったTLVsはオリジナルの、そして、拡張しているLSPsに両方の、同じままで残っています。

3.2.  Operation Mode 1 Additions

3.2. オペレーションモード1追加

   The following additions apply only to routers generating LSPs in Mode
   1.  Routers, which are configured to operate in Operation Mode 2,
   SHOULD NOT apply these additions to their advertisements.

以下の追加はMode1でLSPsを発生させるルータだけに適用されます。 ルータであり、SHOULD NOTはこれらの追加を彼らの広告に適用します。(ルータは、Operation Mode2で作動するために構成されます)。

   Under Operation Mode 1, adjacencies from the Originating System to
   its Virtual Systems are advertised using the standard neighbor TLVs.
   The metric for these connections MUST be zero, since the cost of
   reaching a Virtual System is the same as the cost of reaching its
   Originating System.

Operation Mode1の下では、標準の隣人TLVsを使用することでOriginating SystemからVirtual Systemsまでの隣接番組の広告を出します。 これらの接続のためのメートル法はゼロであるに違いありません、Virtual Systemに達する費用がOriginating Systemに達する費用と同じであるので。

   To older implementations, Virtual Systems would appear reachable only
   through their Originating System, hence loss of connectivity to the
   Originating System means loss of connectivity to all of its
   information, including that advertised in its extended LSPs.
   Furthermore, the cost of reaching information advertised in non-
   extended LSPs is the same as the cost of reaching information
   advertised in the new extended LSPs, with an additional hop.

より古い実現に、Virtual Systemsは彼らのOriginating Systemだけを通して届くように見えるでしょう、したがって、Originating Systemへの接続性の損失が情報のすべてに接続性の損失を意味します、拡張LSPsの広告に掲載されたそれを含んでいて。 その上、非拡張しているLSPsの広告に掲載された情報に達する費用は新しい拡張LSPsの広告に掲載された情報に達する費用と同じです、追加ホップで。

Hermelin, et al.             Informational                      [Page 8]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[8ページ]のRFC3786、-、LSPは2004年5月に断片化します。

   +---------------------------------------------+
   |         Originating System                  |
   |         system-id = S                       |
   |         is-alias-id = S                     |
   +---------------------------------------------+
          |    /\                    |    /\
   cost=0 |    |cost=max-1    cost=0 |    |cost=max-1
          |    |                     |    |
          \/   |                     \/   |
   +-------------------+     +-------------------+
   |  Virtual System   |     |  Virtual System   |
   |  system-id   = S' |     |  system-id   = S''|
   |  is-alias-id = S  |     |  is-alias-id = S  |
   +-------------------+     +-------------------+

+---------------------------------------------+ | 由来しているシステム| | システムイド=S| | 別名がイドである=S| +---------------------------------------------+ | /\ | \がかかった/=0| |=最大-1費用=0かかってください。| |=最大-1かかってください。| | | | \/ | \/ | +-------------------+ +-------------------+ | 仮想のシステム| | 仮想のシステム| | システムイド=S| | 「システムイド=S」| | 別名がイドである=S| | 別名がイドである=S| +-------------------+ +-------------------+

   Figure 2. Advertising connections to Virtual Systems under
             Operation Mode 1.  S' and S'' are configured as
             Additional system-ids.

図2。 Operation Mode1の下のVirtual Systemsに接続の広告を出します。 「SとS」はAdditionalシステムイドとして構成されます。

   Under Operation Mode 1, only "leaf" information, i.e., information
   that serves only as leaves in a shortest path tree, can be advertised
   in extended LSPs.

Operation Mode1の下では、拡張LSPsに「葉」情報(すなわち、葉だけとして最短パス木で機能する情報)しか広告を出すことができません。

   When an Extended LSP belonging to Additional system-id S' is first
   created, the Original LSP MUST specify S' as a neighbor, with metric
   set to zero.  This is in order to consider the cost of reaching the
   Virtual System S' the same as the cost of reaching its Originating
   System.  Furthermore, the Extended LSP MUST specify the Normal
   system-id as a neighbor.  The metric SHOULD be set to MaxLinkMetric -
   1 (this is only for uniformity purpose, any metric greater than zero
   is acceptable).  This in order to satisfy the two-way connectivity
   check on other routers.  Where relevant, this adjacency SHOULD be
   considered as point-to-point.

AdditionalシステムイドSに属すExtended LSPが最初に作成されるとき、Original LSPは隣人としてメートル法のセットでSをゼロまで指定しなければなりません。 これは、Virtual System Sに達する費用がOriginating Systemに達する費用と同じであると考えるそうです。 その上、Extended LSPは隣人としてNormalシステムイドを指定しなければなりません。 メートル法のSHOULD、MaxLinkMetricに設定されてください--1(これは一様性目的のためだけのものであり、メートル法のゼロ以上はいくらか、許容できます)。 これ、両用接続性を満たすには、他のルータについて検査してください。 関連しているところ、この隣接番組SHOULD、ポイントツーポイントであるとみなされてください。

   Note, that the restriction specified in ISO/IEC 10589 section 7.2.5
   holds:  if an LSP Number zero of the Originating System is not
   present, none of that system's neighbor entries would be processed
   during SPF, hence none of its extended LSPs would be processed as
   well.

ISO/IEC10589部7.2の.5で指定された制限が成立するというメモ: Originating SystemのLSP Numberゼロが存在していないなら、そのシステムの隣人エントリーのいずれもSPFの間、処理されないでしょう、したがって、また、拡張LSPsのいずれも処理されないでしょう。

3.2.1.  IS Neighbors TLV (Mode 1 Only)

3.2.1. ネイバーズTLVです。(モード1専用)

   An Extended LSP must specify only the Originating System as a
   neighbor, with the metric set to (MaxLinkMetric - 1).  Where
   relevant, this adjacency should be considered as point-to-point.
   Other neighbors MUST NOT be specified in an Extended LSP, because

Extended LSPはメートル法がセットされたことでの隣人(MaxLinkMetric--1)としてOriginating Systemだけを指定しなければなりません。 関連しているところでは、この隣接番組がポイントツーポイントであるとみなされるべきです。 Extended LSPで他の隣人を指定してはいけません。

Hermelin, et al.             Informational                      [Page 9]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[9ページ]のRFC3786、-、LSPは2004年5月に断片化します。

   those other neighbors would only specify the Originating System and
   not the Virtual System, and hence would not satisfy the bi-
   directionality check in the SPF computation.

それらの他の隣人は、Virtual Systemではなく、Originating Systemを指定するだけであるだろう、したがって、SPF計算における両性愛者の方向性チェックを満たさないでしょう。

3.2.2.  Originating System in the Overload State in (Mode 1 Only)

3.2.2. オーバーロード状態のシステムで起こります。(モード1専用)

   If the Originating System is in the overload state, information in
   the extended LSPs will not be processed by other routers in their SPF
   computation.  This is because in Mode 1, extended LSPs are reachable
   only through adjacencies from the Original LSP.  If this LSP has set
   its OL bit, adjacencies will not be processed in the SPF computation.

Originating Systemがオーバーロード状態にあると、拡張LSPsの情報は彼らのSPF計算における他のルータによって処理されないでしょう。 これは拡張LSPsがOriginal LSPからの隣接番組だけを通してMode1で届いているからです。 このLSPがOLビットを設定したなら、隣接番組はSPF計算で処理されないでしょう。

   This side effect should be taken into consideration when operating in
   Mode 1.

Mode1で作動するとき、この副作用は考慮に入れられるべきです。

4.  Purging Extended LSP Fragments

4. 除くのはLSP断片を広げました。

   ISO/IEC 10589 [ISIS-ISO] section 7.3.4.4 note 25 suggests that an
   implementation keeps the number of LSP fragments within a certain
   limit based on the optimal (minimal) number of fragments needed.
   Section 7.3.4.6 also recommends that an IS purge its empty LSPs to
   conserve resources.  These recommendations hold for the extended LSP
   fragments as well.  However, an extended LSP fragment zero should not
   be purged until all of the fragments in its set (i.e., belonging to a
   particular Additional system-id), are empty as well.  This is to
   ensure implementations consider the fragments in their SPF
   computations, as specified in section 7.2.5.

ISO/IEC10589[イシス-ISO]部7.3 .4 .4 注意25は、実現が断片の最適(最小量の)の数に基づいたある限界の中の断片が必要としたLSPの数を保つのを示します。 また.6がそれを推薦するセクション7.3.4、パージは資源を節約する空のLSPsですか? これらの推薦はまた、拡張LSP断片に当てはまります。 しかしながら、また、セット(すなわち、特定のAdditionalシステムイドに属す)における断片のすべても空になるまで、拡張LSP断片ゼロを掃除するべきではありません。 これは、セクション7.2.5で指定されるように実現が彼らのSPF計算で断片を考えるのを保証するためのものです。

   In Operational Mode 1, when all the extended LSP fragments of a
   particular Additional system-id S' have been purged, the Originating
   System SHOULD remove the neighbor information to S' from its original
   LSPs.

すべての拡張LSPが断片化するとき、Operational Mode1では、特定のAdditionalシステムイドでは、Sを掃除してあって、Originating System SHOULDはオリジナルのLSPsからのSに隣人情報を取り除きます。

5.  Modifications to LSP handling in SPF

5. SPFのLSP取り扱いへの変更

   This section describes modifications to the way extension-capable ISs
   handle LSPs for the SPF computation.

このセクションは拡大できるISsがSPF計算のためにLSPsを扱う方法に変更を説明します。

   When considering LSPs of an extension-capable IS (identified by the
   inclusion of the IS Alias ID TLV), the original and extended LSPs are
   combined to form one large logical LSP.  If the LSP belongs to an IS
   running Operational Mode 1, there might be adjacencies between the
   original and extended LSPs.  These are trivially ignored (since when
   processing them the large logical LSP is already on PATHS), and does
   not complicate the SPF.  Furthermore, this check should already be
   implemented (this scenario could occur on error, without this
   extension).

いつ、LSPsを考えるか、拡大できる、(包含で特定される、アリアID TLV)、オリジナルの、そして、拡張しているLSPsは、1大きい論理的なLSPを形成するために結合されます。 LSPが属す、間の隣接番組がオリジナルの、そして、拡張しているLSPsであったかもしれないならそこのOperational Mode1を走らせるのは、そうです。 これらは、些細なことに無視されて(それ以来、それらを処理して、大きい論理的なLSPがPATHSに既にあります)、SPFを複雑にしません。 その上、このチェックは既に実行されるべきです(このシナリオは誤りのときにこの拡大なしで起こることができました)。

Hermelin, et al.             Informational                     [Page 10]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[10ページ]のRFC3786、-、LSPは2004年5月に断片化します。

   If LSP fragment 0 of the Original LSP set is missing or its
   RemainingLifetime is zero, all of the LSPs generated by that
   Originating System (Extended as well) MUST NOT be considered in the
   SPF.  That is, the large logical LSP is not considered in the SPF.
   The original LSP fragments are identified when the is-alias-id value
   is the same as the system-id of those LSPs.  If an LSP fragment 0 of
   an extended LSP set is missing or its RemainingLifetime is zero, only
   that LSP set MUST NOT be considered in the SPF.  These rules are
   present to ensure consistent SPF results on Mode 1 and Mode 2 LSPs.

Original LSPセットのLSP断片0がなくなるか、RemainingLifetimeがゼロであるなら、SPFでそのOriginating System(また、広がっている)によって発生したLSPsのすべてを考えてはいけません。 すなわち、大きい論理的なLSPはSPFで考えられません。 別名がイドである値がそれらのLSPsのシステムイドと同じであるときに、オリジナルのLSP断片は特定されます。 拡張LSPセットのLSP断片0がなくなるか、RemainingLifetimeがゼロであるなら、SPFでそのLSPセットだけを考えてはいけません。 これらの規則は、Mode1とMode2LSPsで一貫したSPF結果を確実にするために存在しています。

   Note, that the above behavior is consistent with how previous
   implementations will interpret Mode 1 LSPs.

上の振舞いが前の実現がどうMode1LSPsを解釈するかと一致しているというメモ。

6.  Forming Adjacencies

6. 隣接番組を形成します。

   It should be noted, that an IS MUST use the system-id of the LSP that
   will include a neighbor, when forming an adjacency with that
   neighbor.  That is, if a neighbor is to be included in extended LSP
   S', then S' should be used as the system-id in IS Hellos [3] and IS-
   IS Hellos when forming an adjacency with that neighbor.  This is
   regardless of the Operational Mode.  Of course, in Mode 1 this means
   that only the Normal system-id will be used when sending hellos.

それが注意されるべきである、それ、その隣人と共に隣接番組を形成するとき隣人を含んでいるLSPのシステムイドを使用しなければなりません。 '拡張LSP Sに含まれていて、次に、S'がシステムイドとして使用されるべきであるということになるように中にハローズ[3]が'すなわち、隣人がそうならある、存在、ハローズはその隣人と共に隣接番組を形成することでのいつですか? これはOperational Modeにかかわらずあります。 もちろん、Mode1では、これはhellosを送るとき、Normalシステムイドだけが使用されることを意味します。

7.  Interoperating between extension-capable and non-extension-capable
    ISs.

7. 拡大できることの間に共同利用して、できる非拡大ISs。

   In order to correctly advertise link-state information under
   Operation Mode 2, all ISs in an area must be extension-capable.
   However, it is possible to not upgrade every router in the network,
   if the extended information is not routing information, but rather
   data that is of use to only a subset of routers (e.g., optical
   switches using IS-IS could carry optical-specific information in
   extended LSPs)

Operation Mode2の下に正しくリンク州の情報の広告を出すために、領域のすべてのISsが拡大できなければなりません。 しかしながら、ネットワークにおけるあらゆるルータをアップグレードさせるというわけではないのは可能です、拡張情報がルーティング情報ではなく、むしろルータの部分集合だけの役に立つデータであるなら(例えば光学スイッチが使用される、-、拡張LSPsの光学特殊情報のキャリー)であることができました

   If a live network contains routers exceeding the 256 fragment limit,
   and for some reason the upgrade has to be done incrementally, it is
   possible to transition the network, using the following steps:

ライブネットワークが256断片限界を超えているルータを含んでいて、ある理由で増加してアップグレードしなければならないなら、ネットワーク、使用して、以下が踏まれるのは、変遷に可能です:

   -  Upgrade the routers, one-by-one, to run this extension in
      Operation Mode 1.  The other non-extension-capable routers will
      interoperate correctly.

- ルータをひとつずつアップグレードさせて、Operation Mode1でこの拡大を走らせてください。 他のできる非拡大ルータは正しく共同利用するでしょう。

   -  When all routers are extension-capable, configure them one-by-one
      to run in Operation Mode 2.  All extension-capable routers
      interoperate correctly, regardless of what mode they are run in.

- すべてのルータが拡大できるときにはそれらをひとつずつ構成して、Operation Mode2に立候補してください。 すべての拡大できるルータがそれらがどんなモードであるかにかかわらず正しく共同利用します。立候補します。

Hermelin, et al.             Informational                     [Page 11]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[11ページ]のRFC3786、-、LSPは2004年5月に断片化します。

   Implementations SHOULD support a configuration parameter controlling
   the LSP origination behavior.  The default value of this parameter
   SHOULD correspond to the behavior described in [ISIS-ISO], i.e.,
   neither of the two modes described in this document should be enabled
   without explicit configuration when the router software is upgraded
   with this extension.

実現SHOULDはLSP創作の振舞いを制御する設定パラメータを支持します。 このパラメタSHOULDのデフォルト値は[イシス-ISO]で説明された振舞いに対応しています、この拡大でルータソフトウェアをアップグレードさせるとき、すなわち、明白な構成なしで本書では説明された2つのモードのどちらも可能にするべきではありません。

8.  Security Considerations

8. セキュリティ問題

   This document raises no new security issues for IS-IS.

このドキュメントがどんな新しい安全保障問題も提起しない、-

9.  Acknowledgments

9. 承認

   The authors would like to thank Tony Li and Radia Perlman for helpful
   comments and suggestions on the subject.

作者は話題の上で役に立つコメントと提案についてトニー・李とRadiaパールマンに感謝したがっています。

10.  References

10. 参照

10.1.  Normative References

10.1. 引用規格

   [ISIS-ISO]    "Intermediate System to Intermediate System Intra-
                 Domain Routeing Exchange Protocol for use in
                 Conjunction with the Protocol for Providing the
                 Connectionless-mode Network Service (ISO 8473)",
                 ISO/IEC 10589:2002, Second Edition.

[イシス-ISO]、「プロトコルがあるConjunctionにおける、Providing Connectionless-モードNetwork Serviceの使用のためのIntermediate System IntraドメインRouteing Exchangeプロトコルへの中間的System、(ISO8473)、」、ISO/IEC10589:2002、Second Edition。

   [ISIS-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日

   [ISIS-TE]     Smit, H. and T. Li, "Intermediate System to
                 Intermediate System (IS-IS) Extensions for Traffic
                 Engineering (TE)", RFC 3784, May 2004.

[イシス-Te] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(2004年5月)

   [BCP14]       Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

[BCP14] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

10.2.  Informative References

10.2. 有益な参照

   [DOMAIN-WIDE] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix
                 Distribution with Two-Level IS-IS", RFC 2966, October
                 2000.

[ドメイン全体の] 李、T.、Przygienda、T.、およびH.スミット、「2レベルとのドメイン全体の接頭語分配、-、」、RFC2966、10月2000日

   [ISIS-CODES]  Przygienda, T., "Reserved Type, Length and Value (TLV)
                 Codepoints in Intermediate System to Intermediate
                 System", RFC 3359, August 2002.

[イシス-コード] Przygienda、2002年8月のT.、「控え目なタイプ、中間システムへの中間システムの長さと値(TLV)のCodepoints」RFC3359。

Hermelin, et al.             Informational                     [Page 12]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[12ページ]のRFC3786、-、LSPは2004年5月に断片化します。

11.  Authors' Addresses

11. 作者のアドレス

   Amir Hermelin
   Montilio Inc.
   1 Maskit St.
   POB 12253
   Herzelia, 46733
   ISRAEL

アミールハームリンMontilio Inc.1Maskit聖POB12253Herzelia、46733イスラエル

   Phone: +972 9 9511944
   Fax: +972 9 9542430
   EMail: amir@montilio.com

以下に電話をしてください。 +972 9 9511944Fax: +972 9 9542430 メール: amir@montilio.com

   Stefano Previdi
   Cisco Systems, Inc.
   Via Del Serafico 200
   00142 Roma
   Italy

デルSerafico200 00142・ローマイタリア経由でステファーノPrevidiシスコシステムズInc.

   Phone: +39 06 5164 4491
   EMail: sprevidi@cisco.com

以下に電話をしてください。 +39 06 5164 4491はメールされます: sprevidi@cisco.com

   Mike Shand
   Cisco Systems
   250, Longwater Avenue,
   Green Park,
   Reading,
   RG2 6GB,
   UK

マイクシャンドシスコシステムズ250、Longwaterアベニュー、グリーンパーク、読書、RG2 6GB、イギリス

   Phone: +44 20 8824 8690
   EMail: mshand@cisco.com

以下に電話をしてください。 +44 20 8824 8690はメールされます: mshand@cisco.com

Hermelin, et al.             Informational                     [Page 13]

RFC 3786                  IS-IS LSP Fragments                   May 2004

ハームリン、他 情報[13ページ]のRFC3786、-、LSPは2004年5月に断片化します。

12.  Full Copyright Statement

12. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Hermelin, et al.             Informational                     [Page 14]

ハームリン、他 情報[14ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

MIN関数 最小値を求める

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る