RFC4201 日本語訳

Network Working Group                                        K. Kompella
Request for Comments: 4201                                    Y. Rekhter
Updates: 3471, 3472, 3473                               Juniper Networks
Category: Standards Track                                      L. Berger
                                                          Movaz Networks
                                                            October 2005

Kompellaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4201のY.Rekhterアップデート: 3471 3472 3473年の杜松はカテゴリをネットワークでつなぎます: 規格は2005年10月にL.バーガーMovazネットワークを追跡します。

             Link Bundling in MPLS Traffic Engineering (TE)

MPLS交通工学におけるリンクバンドリング(Te)

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 Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   For the purpose of Generalized Multi-Protocol Label Switching (GMPLS)
   signaling, in certain cases a combination of <link identifier, label>
   is not sufficient to unambiguously identify the appropriate resource
   used by a Label Switched Path (LSP).  Such cases are handled by using
   the link bundling construct, which is described in this document.
   This document updates the interface identification TLVs, which are
   defined in the GMPLS Signaling Functional Description.

ある場合には、Generalized Multi-プロトコルLabel Switching(GMPLS)シグナリングの目的、<リンク識別子の組み合わせでは、ラベル>は、明白にLabel Switched Path(LSP)によって使用された適切なリソースを特定するために十分ではありません。 そのような場合は、リンクバンドリング構造物を使用することによって、扱われます。(構造物は本書では説明されます)。 このドキュメントはインタフェース識別TLVsをアップデートします。(TLVsはGMPLS Signaling Functional記述で定義されます)。

Kompella, et al.            Standards Track                     [Page 1]

RFC 4201                Link Bundling in MPLS-TE            October 2005

Kompella、他 2005年10月にMPLS-Teで荷物をまとめる標準化過程[1ページ]RFC4201リンク

Table of Contents

目次

   1.  Introduction .................................................  2
       1.1.  Specification of Requirements ..........................  2
   2.  Link Bundling ................................................  3
       2.1.  Restrictions on Bundling ...............................  4
       2.2.  Routing Considerations .................................  4
       2.3.  Signaling Considerations ...............................  5
             2.3.1.  Interface Identification TLV Format ............  6
             2.3.2.  Errored Component Identification ...............  7
   3.  Traffic Engineering Parameters for Bundled Links .............  7
       3.1.  OSPF Link Type .........................................  7
       3.2.  OSPF Link ID ...........................................  7
       3.3.  Local and Remote Interface IP Address ..................  7
       3.4.  Local and Remote Identifiers ...........................  8
       3.5.  Traffic Engineering Metric .............................  8
       3.6.  Maximum Bandwidth ......................................  8
       3.7.  Maximum Reservable Bandwidth ...........................  8
       3.8.  Unreserved Bandwidth ...................................  8
       3.9.  Resource Classes (Administrative Groups) ...............  8
       3.10.  Maximum LSP Bandwidth .................................  8
   4.  Bandwidth Accounting .........................................  9
   5.  Security Considerations ......................................  9
   6.  IANA Considerations ..........................................  9
   7.  References ................................................... 10
       7.1.  Normative References ................................... 10
       7.2.  Informative References ................................. 11

1. 序論… 2 1.1. 要件の仕様… 2 2. バンドリングをリンクしてください… 3 2.1. バンドリングの制限… 4 2.2. ルート設定問題… 4 2.3. シグナリング問題… 5 2.3.1. 識別TLV形式を連結してください… 6 2.3.2. コンポーネント識別をErroredしました… 7 3. 束ねられたリンクのための交通工学パラメタ… 7 3.1. OSPFはタイプをリンクします… 7 3.2. OSPFはIDをリンクします… 7 3.3. 地方の、そして、リモートなインタフェースIPアドレス… 7 3.4. 地方の、そして、リモートな識別子… 8 3.5. 交通工学メートル法… 8 3.6. 最大の帯域幅… 8 3.7. 最大のReservable帯域幅… 8 3.8. 無遠慮な帯域幅… 8 3.9. リソースは(管理グループ)を分類します… 8 3.10. 最大のLSP帯域幅… 8 4. 帯域幅会計… 9 5. セキュリティ問題… 9 6. IANA問題… 9 7. 参照… 10 7.1. 標準の参照… 10 7.2. 有益な参照… 11

1.  Introduction

1. 序論

   For the purpose of Generalized Multi-Protocol Label Switching (GMPLS)
   signaling, in certain cases a combination of <link identifier, label>
   is not sufficient to unambiguously identify the appropriate resource
   used by a Label Switched Path (LSP).  Such cases are handled by using
   the link bundling construct, which is described in this document.
   This document updates the interface identification TLVs, which are
   defined in the GMPLS Signaling Functional Description.

ある場合には、Generalized Multi-プロトコルLabel Switching(GMPLS)シグナリングの目的、<リンク識別子の組み合わせでは、ラベル>は、明白にLabel Switched Path(LSP)によって使用された適切なリソースを特定するために十分ではありません。 そのような場合は、リンクバンドリング構造物を使用することによって、扱われます。(構造物は本書では説明されます)。 このドキュメントはインタフェース識別TLVsをアップデートします。(TLVsはGMPLS Signaling Functional記述で定義されます)。

1.1.  Specification of Requirements

1.1. 要件の仕様

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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

Kompella, et al.            Standards Track                     [Page 2]

RFC 4201                Link Bundling in MPLS-TE            October 2005

Kompella、他 2005年10月にMPLS-Teで荷物をまとめる標準化過程[2ページ]RFC4201リンク

2.  Link Bundling

2. リンクバンドリング

   As defined in [GMPLS-ROUTING], a traffic engineering (TE) link is a
   logical construct that represents a way to group/map information
   about certain physical resources (and their properties) that
   interconnect LSRs with information that is used by Constrained SPF
   (for the purpose of path computation) and by GMPLS signaling.

[GMPLS-ルート設定]で定義されるように、交通工学(TE)リンクはConstrained SPF(経路計算の目的のための)とGMPLSシグナリングによって使用される情報でLSRsとインタコネクトするある物理資源(そして、彼らの特性)の情報を分類するか、または写像する方法を表す論理的な構造物です。

   As stated in [GMPLS-ROUTING], depending on the nature of resources
   that form a particular TE link for the purpose of GMPLS signaling, in
   some cases a combination of <TE link identifier, label> is sufficient
   to unambiguously identify the appropriate resource used by an LSP.
   In other cases, a combination of <TE link identifier, label> is not
   sufficient.  Consider, for example, a TE link between a pair of
   SONET/SDH cross-connects, where this TE link is composed of several
   fibers.  In this case the label is a TDM time slot, and moreover,
   this time slot is significant only within a particular fiber.  Thus,
   when signaling an LSP over such a TE link, one needs to specify not
   just the identity of the link, but also the identity of a particular
   fiber within that TE link, as well as a particular label (time slot)
   within that fiber.  Such cases are handled by using the link bundling
   construct, which is described in this document.

GMPLSシグナリングの目的のために特定のTEリンクを形成するリソースの本質によって、[GMPLS-ルート設定]で述べられているいくつかの場合における、<TEリンク識別子の組み合わせ、ラベル>は、明白にLSPによって使用された適切なリソースを特定するために十分です。 他のケース、<TEリンク識別子の組み合わせでは、ラベル>は十分ではありません。 例えば1組のSonet/SDH十字接続の間のTEリンクを考えてください。そこでは、このTEリンクがいくつかのファイバーで構成されます。 この場合、ラベルはTDMの時間帯です、そして、そのうえ、この時間帯は特定のファイバーだけの中で重要です。 そのようなTEリンクの上にLSPに合図するとき、したがって、人は、そのTEリンクの中にリンクのアイデンティティだけではなく、特定のファイバーのアイデンティティも指定する必要があります、そのファイバーの中の特定のラベル(時間帯)と同様に。 そのような場合は、リンクバンドリング構造物を使用することによって、扱われます。(構造物は本書では説明されます)。

   Consider a TE link such that, for the purpose of GMPLS signaling, a
   combination of <TE link identifier, label> is not sufficient to
   unambiguously identify the appropriate resources used by an LSP.  In
   this situation, the link bundling construct assumes that the set of
   resources that form the TE link could be partitioned into disjoint
   subsets, such that (a) the partition is minimal, and (b) within each
   subset, a label is sufficient to unambiguously identify the
   appropriate resources used by an LSP.  We refer to such subsets as
   "component links", and to the whole TE link as a "bundled link".
   Furthermore, we restrict the identifiers that can be used to identify
   component links such that they are unique for a given node.  On a
   bundled link, a combination of <component link identifier, label> is
   sufficient to unambiguously identify the appropriate resources used
   by an LSP.

GMPLSシグナリングの目的、<TEリンク識別子の組み合わせに、ラベル>がLSPで明白に適切な運用資金を特定するために十分でないように、TEリンクを考えてください。 この状況で、リンクバンドリング構造物は、それが(a) パーティションがTEリンクを仕切ることができたフォームが部分集合をばらばらにならせます、あれほどので最小限であり、各部分集合の中では、(b) ラベルが最小量であるリソースのセットであるとLSPで明白に適切な運用資金を特定できるくらい仮定します。 私たちは「コンポーネントリンク」と、そして、全体のTEリンクへの「束ねられたリンク」のような部分集合を示します。 その上、私たちがコンポーネントリンクを特定するのに使用できる識別子を制限するので、与えられたノードに、彼らはユニークです。 束ねられたリンク、<コンポーネントリンク識別子の組み合わせのときに、ラベル>は、LSPで明白に適切な運用資金を特定するために十分です。

   The partition of resources that form a bundled link into component
   links has to be done consistently at both ends of the bundled link.
   Both ends of the bundled link also have to understand the other end's
   component link identifiers.

束ねられたリンクの両端で一貫して束ねられたリンクでコンポーネントリンクを作るリソースのパーティションをしなければなりません。 束ねられたリンクの両端ももう一方の端のコンポーネントリンク識別子を理解しなければなりません。

   The purpose of link bundling is to improve routing scalability by
   reducing the amount of information that has to be handled by OSPF
   and/or IS-IS.  This reduction is accomplished by performing
   information aggregation/abstraction.  As with any other information
   aggregation/abstraction, this results in losing some of the

そして/または、リンクバンドリングの目的がOSPFによって扱われなければならない情報量を減少させることによってルーティングスケーラビリティを改良することである、- この減少は、情報集合/抽象化を実行することによって、実行されます。 いかなる他の情報集合/抽象化のようにも、これはいくつかを失うのに結果として生じます。

Kompella, et al.            Standards Track                     [Page 3]

RFC 4201                Link Bundling in MPLS-TE            October 2005

Kompella、他 2005年10月にMPLS-Teで荷物をまとめる標準化過程[3ページ]RFC4201リンク

   information.  To limit the amount of losses, one needs to restrict
   the type of information that can be aggregated/abstracted.

情報。 損失の量を制限するために、人は、集めるか、または抜き取ることができる情報の種類を制限する必要があります。

2.1.  Restrictions on Bundling

2.1. バンドリングの制限

   All component links in a bundle have the same Link Type (i.e.,
   point-to-point or multi-access), the same Traffic Engineering metric,
   the same set of resource classes at each end of the links, and must
   begin and end on the same pair of LSRs.

バンドルでのすべてのコンポーネントリンクが、LSRsの同じ組で同じLink Type(すなわち、ポイントツーポイントかマルチアクセス)、それぞれにおける、メートル法で、同じセットのリソースのクラスが終わらせるリンクの同じTraffic Engineeringを持って、始まって、終わらなければなりません。

   A Forwarding Adjacency may be a component link; in fact, a bundle can
   consist of a mix of point-to-point links and FAs.

Forwarding Adjacencyはコンポーネントリンクであるかもしれません。 事実上、バンドルはポイントツーポイント接続とFAsのミックスから成ることができます。

   If the component links are all multi-access links, the set of IS-IS
   or OSPF routers that are connected to each component link must be the
   same, and the Designated Router for each component link must be the
   same.  If these conditions cannot be enforced, multi-access links
   must not be bundled.

マルチアクセスはコンポーネントリンクがすべてならリンクされます、セット、-、または、それぞれのコンポーネントリンクが同じであるに違いないので、接続されているのが、それぞれのコンポーネントリンクへの同じくらいと、Designated Routerであるに違いないということであるOSPFルータ。 これらの状態を励行されることができないなら、マルチアクセスリンクを束ねてはいけません。

   Component link identifiers MUST be unique across both TE and
   component link identifiers on a particular node.  This means that
   unnumbered identifiers have a node-wide scope, and that numbered
   identifiers have the same scope as IP addresses.

コンポーネントリンク識別子は特定のノードでTEとコンポーネントリンク識別子の両方の向こう側にユニークであるに違いありません。 これは無数の識別子にはノード広範囲があって、番号付の識別子にIPアドレスと同じ範囲があることを意味します。

2.2.  Routing Considerations

2.2. ルート設定問題

   A component link may be either numbered or unnumbered.  A bundled
   link may itself be numbered or unnumbered, independent of whether the
   component links of that bundled link are numbered.

コンポーネントリンクは、付番されているか、または無数であるかもしれません。 束ねられたリンクがそうするかもしれない、それ自体、番号付である、または無数になってください、その束ねられたリンクのコンポーネントリンクが番号付であるかどうかの如何にかかわらず。

   Handling identifiers for unnumbered component links, including the
   case in which a link is formed by a Forwarding Adjacency, follows the
   same rules as those for an unnumbered TE link (see Section "Link
   Identifiers" of [RFC3477]/[RFC3480]).  Furthermore, link local
   identifiers for all unnumbered links of a given LSR (whether
   component links, Forwarding Adjacencies, or bundled links) MUST be
   unique in the context of that LSR.

リンクがForwarding Adjacencyによって形成される場合を含む無数のコンポーネントリンクのための識別子を扱うと、無数のTEリンクへのそれらと同じ規則は従われます([RFC3477]/[RFC3480]のセクション「リンク識別子」を見てください)。 その上、与えられたLSR(コンポーネントリンク、Forwarding Adjacencies、または束ねられたリンクであることにかかわらず)のすべての無数のリンクのためのリンクのローカルの識別子はそのLSRの文脈でユニークであるに違いありません。

   The "liveness" of the bundled link is determined by the liveness of
   each of the component links within the bundled link; a bundled link
   is alive when at least one of its component links is determined to be
   alive.  The liveness of a component link can be determined by any of
   several means: IS-IS or OSPF hellos over the component link, RSVP
   Hello, LMP hellos (see [LMP]), or from layer 1 or layer 2
   indications.

束ねられたリンクの「活性」は束ねられたリンクの中にそれぞれのコンポーネントリンクの活性で決定します。 少なくともコンポーネントリンクの1つが生きていると決心しているとき、束ねられたリンクは生きています。 コンポーネントリンクの活性はいくつかの手段のどれかで決定できます: OSPF hellosはコンポーネントの上でリンクします、RSVP Hello、LMP hellos。または、-、([LMP)を見るか、または層1か層の2つの指摘から。

Kompella, et al.            Standards Track                     [Page 4]

RFC 4201                Link Bundling in MPLS-TE            October 2005

Kompella、他 2005年10月にMPLS-Teで荷物をまとめる標準化過程[4ページ]RFC4201リンク

   Once a bundled link is determined to be alive, it can be advertised
   as a TE link and the TE information can be flooded.  If IS-IS/OSPF
   hellos are run over the component links, IS-IS/OSPF flooding can be
   restricted to just one of the component links.  Procedures for doing
   this are outside the scope of this document.

束ねられたリンクがいったん生きていると決心するようになると、TEリンクとTE情報をあふれさせることができるようにそれの広告を出すことができます。 -、/OSPF hellosがコンポーネントリンクの上に走る、-、/OSPF氾濫はちょうどコンポーネントのリンクの1つに制限される場合があります。 このドキュメントの範囲の外にこれをするための手順があります。

   In the future, as new Traffic Engineering parameters are added to
   IS-IS and OSPF, they should be accompanied by descriptions as to how
   they can be bundled, and possible restrictions on bundling.

そして、パラメタが加えられる将来的で、新しいTraffic Engineering、-、OSPF、記述でそれらはバンドリングのどう束ねられて、可能な制限であるかもしれないかに関して伴われるべきです。

2.3.  Signaling Considerations

2.3. シグナリング問題

   Because information about the bundled link is flooded, but
   information about the component links is not, typically, an LSP's ERO
   will identify the bundled link to be used for the LSP, but not the
   component link.  While Discovery of component link identities to be
   used in an ERO is outside the scope of the document, it is envisioned
   that such information may be provided via configuration or via future
   RRO extensions.  When the bundled link is identified in an ERO or is
   dynamically identified, the choice of the component link for the LSP
   is a local matter between the two LSRs at each end of the bundled
   link.

束ねられたリンクの情報が水につかっていますが、コンポーネントリンクの情報が水につかるというわけではないので、通常、LSPのEROはコンポーネントリンクではなく、LSPに使用されるために束ねられたリンクを特定するでしょう。 EROで使用されているのが、ドキュメントの範囲の外では、それが思い描かれるということであるということであるそのような情報が構成か将来のRRO拡張子で提供されるかもしれないコンポーネントリンクのアイデンティティのディスカバリーである間。 束ねられたリンクがEROで特定されるか、またはダイナミックに特定されるとき、LSPのためのコンポーネントリンクの選択は束ねられたリンクの各端の2LSRsの間の地域にかかわる事柄です。

   Signaling must identify both the component link and label to use.
   The choice of the component link to use is always made by the sender
   of the Path/REQUEST message.  If an LSP is bidirectional [RFC3471],
   the sender chooses a component link in each direction.  The handling
   of labels is not modified by this document.

シグナリングはコンポーネントリンクと使用するラベルの両方を特定しなければなりません。 使用するコンポーネントリンクの選択はいつもPath/REQUESTメッセージの送付者によってされます。 LSPが双方向であるなら[RFC3471]、送付者は各方向にコンポーネントリンクを選びます。 ラベルの取り扱いはこのドキュメントによって変更されません。

   Component link identifiers are carried in RSVP messages, as described
   in section 8 of [RFC3473].  Component link identifiers are carried in
   CR-LDP messages, as described in section 8 of [RFC3473].  Additional
   processing related to unnumbered links is described in the
   "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV",
   and "Unnumbered Forwarding Adjacencies" sections of
   [RFC3477]/[RFC3480].

コンポーネントリンク識別子は[RFC3473]のセクション8で説明されるようにRSVPメッセージで運ばれます。 コンポーネントリンク識別子は[RFC3473]のセクション8で説明されるようにCR-自由民主党メッセージで運ばれます。 無数のリンクに関連する追加処理が中で説明される、「処理、_ID RSVP_ホップ物である、」 /、「処理、_ID TLVである、」 [RFC3477]/[RFC3480]の「無数の推進隣接番組」セクション。

   [RFC3471] defines the Interface Identification type-length-value
   (TLV) types.  This document specifies that the TLV types 1, 2, and 3
   SHOULD be used to indicate component links in IF_ID RSVP_HOP objects
   and IF_ID TLVs.

[RFC3471]はInterface Identificationタイプ長さの価値(TLV)のタイプを定義します。 このドキュメントは、TLVタイプ1、2、および3SHOULDがコンポーネントリンクを示すのが_ID RSVP_HOPが反対して、_ID TLVsであるなら使用されていると指定します。

   Type 1 TLVs are used for IPv4 numbered component link identifiers.

タイプ1TLVsがIPv4の番号付のコンポーネントリンク識別子に使用されます。

   Type 2 TLVs are used for IPv6 numbered component link identifiers.

タイプ2TLVsがIPv6の番号付のコンポーネントリンク識別子に使用されます。

   Type 3 TLVs are used for unnumbered component link identifiers.

タイプ3TLVsが無数のコンポーネントリンク識別子に使用されます。

Kompella, et al.            Standards Track                     [Page 5]

RFC 4201                Link Bundling in MPLS-TE            October 2005

Kompella、他 2005年10月にMPLS-Teで荷物をまとめる標準化過程[5ページ]RFC4201リンク

   The Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used.
   Note, in Path and REQUEST messages, link identifiers MUST be
   specified from the sender's perspective.

SHOULD NOT、Component Interface TLVs、TLVは4と5をタイプします。使用されます。 PathとREQUESTメッセージで送付者の見解からリンク識別子を指定しなければならないことに注意してください。

   Except in the special case noted below, for a unidirectional LSP,
   only a single TLV SHOULD be used in an IF_ID RSVP_HOP object or IF_ID
   TLV.  This TLV indicates the component link identifier of the
   downstream data channel on which label allocation must be done.

a単方向LSPの間の独身のTLV SHOULDだけの下に述べられた特別なケースを除いて、中で使用されてください、_ID RSVP_HOPが反対するか、_ID TLVであるなら。 このTLVはラベル配分をしなければならない川下のデータ・チャンネルのコンポーネントリンク識別子を示します。

   Except in the special case noted below, for a bidirectional LSP, only
   one or two TLVs SHOULD be used in an IF_ID RSVP_HOP object or IF_ID
   TLV.  The first TLV always indicates the component link identifier of
   the downstream data channel on which label allocation must be done.
   When present, the second TLV always indicates the component link
   identifier of the upstream data channel on which label allocation
   must be done.  When only one TLV is present, it indicates the
   component link identifier for both downstream and upstream data
   channels.

双方向のLSPのための1か2TLVs SHOULDだけの下に述べられた特別なケースを除いて、中で使用されてください、_ID RSVP_HOPが反対するか、_ID TLVであるなら。 最初のTLVはいつもラベル配分をしなければならない川下のデータ・チャンネルのコンポーネントリンク識別子を示します。 存在しているとき、第2TLVはいつもラベル配分をしなければならない上流のデータ・チャンネルのコンポーネントリンク識別子を示します。 1TLVだけが存在しているとき、それは川下の、そして、上流の両方のデータ・チャンネルのためにコンポーネントリンク識別子を示します。

   In the special case where the same label is to be valid across all
   component links, two TLVs SHOULD be used in an IF_ID RSVP_HOP object
   or IF_ID TLV.  The first TLV indicates the TE link identifier of the
   bundle on which label allocation must be done.  The second TLV
   indicates a bundle scope label.  For TLV types 1 and 2, this is done
   by using the special bit value of all ones (1) (e.g., 0xFFFFFFFF for
   a type 1 TLV).  Per [RFC3471], for TLV types 3, 4, and 5, this is
   done by setting the Interface ID field to the special value
   0xFFFFFFFF.  Note that this special case applies to both
   unidirectional and bidirectional LSPs.

同じラベルがすべてのコンポーネントリンク、2TLVs SHOULDの向こう側に有効であることになっている特別な場合に、中で使用されてください、_ID RSVP_HOPが反対するか、_ID TLVであるなら。 最初のTLVはラベル配分をしなければならないバンドルに関するTEリンク識別子を示します。 第2TLVはバンドル範囲ラベルを示します。 TLVタイプ1と2において、すべてのもの(1)(例えば、タイプ1TLVのための0xFFFFFFFF)の特別な噛み付いている値を使用することによって、これをします。 [RFC3471]に従って、TLVタイプ3、4、および5において、特別な値の0xFFFFFFFFにInterface ID分野を設定することによって、これをします。 この特別なケースが単方向、双方向のLSPsの両方に適用されることに注意してください。

   Although it SHOULD NOT be used, when used, the type 5 TLV MUST NOT be
   the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV.

それである、SHOULD NOT、使用されてください、使用されると1番目が中のTLVであったなら5TLV MUST NOTをタイプしてください、_ID RSVP_HOPが反対するか、_ID TLVであるなら。

2.3.1.  Interface Identification TLV Format

2.3.1. インタフェース識別TLV形式

   This section modifies section 9.1.1. of [RFC3471].  The definition of
   the IP Address field of the TLV types 3, 4, and 5 is clarified.

このセクションは[RFC3471]について.1にセクション9.1を変更します。 TLVタイプ3、4、および5のIP Address分野の定義ははっきりさせられます。

      For types 3, 4, and 5, the Value field has an identical format to
      the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object
      defined in [RFC3477].  Note that this results in the renaming of
      the IP Address field defined in [RFC3471].

タイプ3、4、および5のために、Value分野は[RFC3477]で定義された1個のC-タイプLSP_TUNNEL_INTERFACE_ID物のコンテンツに同じ形式を持っています。 これが[RFC3471]で定義されたIP Address分野の改名をもたらすことに注意してください。

Kompella, et al.            Standards Track                     [Page 6]

RFC 4201                Link Bundling in MPLS-TE            October 2005

Kompella、他 2005年10月にMPLS-Teで荷物をまとめる標準化過程[6ページ]RFC4201リンク

2.3.2.  Errored Component Identification

2.3.2. コンポーネント識別をErroredしました。

   When Interface Identification TLVs are used, the TLVs are also used
   to indicate the specific components associated with an error.  For
   RSVP, this means that any received TLVs SHOULD be copied into the
   IF_ID ERROR_SPEC object (see Section 8.2 in [RFC3473]).  The Error
   Node Address field of the object SHOULD indicate the TE Link
   associated with the error.  For CR-LDP, this means that any received
   TLVs SHOULD be copied into the IF_ID Status TLV (see Section 8.2 in
   [RFC3472]).  The HOP Address field of the TLV SHOULD indicate the TE
   Link associated with the error.

また、Interface Identification TLVsが使用されているとき、TLVsは、誤りに関連している特定のコンポーネントを示すのに使用されます。 RSVPに関して、これが、どんな容認されたTLVs SHOULDもコピーされることを意味する、_ID ERROR_SPECが反対するなら([RFC3473]でセクション8.2を見てください)。 SHOULDが、TE Linkが誤りに関連づけたのを示す物のError Node Address分野。 CR-自由民主党に関して、これが、どんな容認されたTLVs SHOULDもコピーされることを意味する、_ID Status TLV([RFC3472]でセクション8.2を見る)であるなら。 TLV SHOULDのHOP Address分野は誤りに関連しているTE Linkを示します。

3.  Traffic Engineering Parameters for Bundled Links

3. 束ねられたリンクのための交通工学パラメタ

   In this section, we define the Traffic Engineering parameters to be
   advertised for a bundled link, based on the configuration of the
   component links and of the bundled link.  The definition of these
   parameters for component links was undertaken in [RFC3784] and
   [RFC3630]; we use the terminology from [RFC3630].

このセクションで、私たちは束ねられたリンクに広告を出すためにTraffic Engineeringパラメタを定義します、コンポーネントリンクと束ねられたリンクの構成に基づいて。 コンポーネントリンクのためのこれらのパラメタの定義は[RFC3784]と[RFC3630]で引き受けられました。 私たちは[RFC3630]から用語を使用します。

3.1.  OSPF Link Type

3.1. OSPFリンク型

   The Link Type of a bundled link is the (unique) Link Type of the
   component links.  Note that this parameter is not present in IS-IS.

束ねられたリンクのLink Typeはコンポーネントリンクの(ユニーク)のリンクTypeです。 このパラメタが現在でない注意、-

3.2.  OSPF Link ID

3.2. OSPFリンクID

   For point-to-point links, the Link ID of a bundled link is the
   (unique) Router ID of the neighbor.  For multi-access links, this is
   the interface address of the (unique) Designated Router.  Note that
   this parameter is not present in IS-IS.

ポイントツーポイント接続に関しては、束ねられたリンクのLink IDは隣人の(ユニーク)のRouter IDです。 マルチアクセスリンクに関しては、これは(ユニーク)の指定されたRouterのインターフェース・アドレスです。 このパラメタが現在でない注意、-

3.3.  Local and Remote Interface IP Address

3.3. 地方の、そして、リモートなインタフェースIPアドレス

   Note that in IS-IS, the Local Interface IP Address is known as the
   IPv4 Interface Address and the Remote Interface IP Address is known
   as the IPv4 Neighbor Address.

それに注意する、-、Local Interface IP AddressはIPv4 Interface Addressとして知られていて、Remote Interface IP AddressはIPv4 Neighbor Addressとして知られています。

   If the bundled link is numbered, the Local Interface IP Address is
   the local address of the bundled link; similarly, the Remote
   Interface IP Address is the remote address of the bundled link.

束ねられたリンクが番号付であるなら、Local Interface IP Addressは束ねられたリンクのローカルアドレスです。 同様に、Remote Interface IP Addressは束ねられたリンクのリモートアドレスです。

Kompella, et al.            Standards Track                     [Page 7]

RFC 4201                Link Bundling in MPLS-TE            October 2005

Kompella、他 2005年10月にMPLS-Teで荷物をまとめる標準化過程[7ページ]RFC4201リンク

3.4.  Local and Remote Identifiers

3.4. 地方の、そして、リモートな識別子

   If the bundled link is unnumbered, the link local identifier is set
   to the identifier chosen for the bundle by the advertising LSR.  The
   link remote identifier is set to the identifier chosen by the
   neighboring LSR for the reverse link corresponding to this bundle, if
   known; otherwise, this is set to 0.

束ねられたリンクが無数であるなら、リンクのローカルの識別子は広告LSRによってバンドルに選ばれた識別子に設定されます。 リンクのリモート識別子は隣接しているLSRによってこのバンドルに対応する逆方向リンクに選ばれた識別子に設定されます、知られているなら。 さもなければ、これは0に設定されます。

3.5.  Traffic Engineering Metric

3.5. 交通工学メートル法です。

   The Traffic Engineering Metric for a bundled link is that of the
   component links.

束ねられたリンクへのTraffic Engineering Metricはコンポーネントリンクのものです。

3.6.  Maximum Bandwidth

3.6. 最大の帯域幅

   This parameter is not used.  The maximum LSP Bandwidth (as described
   below) replaces the Maximum Bandwidth for bundled links.

このパラメタは使用されていません。 最大のLSP Bandwidth(以下で説明されるように)はMaximum Bandwidthを束ねられたリンクに取り替えます。

3.7.  Maximum Reservable Bandwidth

3.7. 最大のReservable帯域幅

   For a given bundled link, we assume that either each of its component
   links is configured with the Maximum Reservable Bandwidth, or the
   bundled link is configured with the Maximum Reservable Bandwidth.  In
   the former case, the Maximum Reservable Bandwidth of the bundled link
   is set to the sum of the Maximum Reservable Bandwidths of all
   component links associated with the bundled link.

与えられた束ねられたリンクに関しては、私たちは、それぞれのコンポーネントリンクがMaximum Reservable Bandwidthによって構成されるか、または束ねられたリンクがMaximum Reservable Bandwidthによって構成されると思います。 前の場合では、束ねられたリンクのMaximum Reservable Bandwidthは束ねられたリンクに関連しているすべてのコンポーネントリンクのMaximum Reservable Bandwidthsの合計に用意ができています。

3.8.  Unreserved Bandwidth

3.8. 無遠慮な帯域幅

   The unreserved bandwidth of a bundled link at priority p is the sum
   of the unreserved bandwidths at priority p of all the component links
   associated with the bundled link.

優先権pにおける束ねられたリンクの無遠慮な帯域幅は束ねられたリンクに関連しているすべてのコンポーネントリンクの優先権pにおける無遠慮な帯域幅の合計です。

3.9.  Resource Classes (Administrative Groups)

3.9. リソースのクラス(管理グループ)

   The Resource Classes for a bundled link are the same as those of the
   component links.

束ねられたリンクへのResource Classesはコンポーネントのものがリンクされるのと同じです。

3.10.  Maximum LSP Bandwidth

3.10. 最大のLSP帯域幅

   The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth.
   For an unbundled link, the Maximum Bandwidth is defined in
   [GMPLS-ROUTING].  The Maximum LSP Bandwidth of a bundled link at
   priority p is defined to be the maximum of the Maximum LSP Bandwidth
   at priority p of all of its component links.

Maximum LSP BandwidthはMaximum Bandwidthの代理をします。 「非-束ね」られたリンクに関しては、Maximum Bandwidthは[GMPLS-ルート設定]で定義されます。 優先権pにおける束ねられたリンクのMaximum LSP Bandwidthは、コンポーネントリンクのすべての優先権pにおけるMaximum LSP Bandwidthの最大になるように定義されます。

Kompella, et al.            Standards Track                     [Page 8]

RFC 4201                Link Bundling in MPLS-TE            October 2005

Kompella、他 2005年10月にMPLS-Teで荷物をまとめる標準化過程[8ページ]RFC4201リンク

   The details of how Maximum LSP Bandwidth is carried in IS-IS is given
   in [GMPLS-ISIS].  The details of how Maximum LSP Bandwidth is carried
   in OSPF is given in [GMPLS-OSPF].

Maximum LSP Bandwidthがどうあるかに関する詳細が運び込んだ、-、中[GMPLS-イシス]に与えます。 Maximum LSP BandwidthがOSPFでどう運ばれるかに関する詳細は[GMPLS-OSPF]に述べられます。

4.  Bandwidth Accounting

4. 帯域幅会計

   The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an
   LSR with bundled links must apply admission control on a per-
   component link basis.  An LSP with a bandwidth requirement b and
   setup priority p fits in a bundled link if at least one component
   link has a maximum LSP bandwidth >= b at priority p.  If there are
   several such links, the implementation will choose which link to use
   for the LSP.

束ねられたリンクがあるLSRの上のRSVP(または、CR-自由民主党)交通Controlモジュール、またはその同等物が入場コントロールをaに当てはまらなければならない、-、コンポーネントリンク基礎。 少なくとも1個のコンポーネントリンクが優先権pで最大のLSP帯域幅>=bを持っているなら、帯域幅要件bとセットアップ優先pがあるLSPは束ねられたリンクをうまくはめ込みます。 そのような数個のリンクがあると、実現は、LSPにどのリンクを使用したらよいかを選ぶでしょう。

   In order to know the maximum LSP bandwidth (per priority) of each
   component link, the Traffic Control module must track the unreserved
   bandwidth (per priority) for each component link.

それぞれのコンポーネントリンクの最大のLSP帯域幅(1優先権あたりの)を知るために、Traffic Controlモジュールは無遠慮な帯域幅(1優先権あたりの)をそれぞれのコンポーネントリンクに追跡しなければなりません。

   A change in the unreserved bandwidth of a component link results in a
   change in the unreserved bandwidth of the bundled link.  It also
   potentially results in a change in the maximum LSP bandwidth of the
   bundle; thus, the maximum LSP bandwidth should be recomputed.

コンポーネントリンクの無遠慮な帯域幅の変化は束ねられたリンクの無遠慮な帯域幅の変化をもたらします。 また、それは潜在的にバンドルの最大のLSP帯域幅の変化をもたらします。 したがって、最大のLSP帯域幅は再計算されるべきです。

   If one of the component links goes down, the associated bundled link
   remains up and continues to be advertised, provided that at least one
   component link associated with the bundled link is up.  The
   unreserved bandwidth of the component link that is down is set to
   zero, and the unreserved bandwidth and maximum LSP bandwidth of the
   bundle must be recomputed.  If all the component links associated
   with a given bundled link are down, the bundled link MUST not be
   advertised into OSPF/IS-IS.

コンポーネントリンクの1つが落ちるなら、関連は、リンクの残りを包んで、広告を出し続けています、束ねられたリンクに関連している少なくとも1個のコンポーネントリンクが上がれば。 下がっているコンポーネントリンクの無遠慮な帯域幅はゼロに設定されます、そして、バンドルの無遠慮な帯域幅と最大のLSP帯域幅を再計算しなければなりません。 束ねられる当然のことに関連しているコンポーネントリンクがリンクするのが、ダウンすることであるなら、OSPF/に束ねられたリンクの広告を出してはいけない、-

5.  Security Considerations

5. セキュリティ問題

   This document defines ways of utilizing procedures defined in other
   documents, referenced herein.  Any security issues related to those
   procedures are addressed in the referenced documents.  Thus, this
   document raises no new security issues for RSVP-TE [RFC3209] or CR-
   LDP [RFC3212].

このドキュメントはここに参照をつけられる他のドキュメントで定義された手順を利用する方法を定義します。 それらの手順に関連するどんな安全保障問題も参照をつけられたドキュメントに記述されます。 したがって、このドキュメントはRSVP-TE[RFC3209]かCR自由民主党[RFC3212]のためにどんな新しい安全保障問題も提起しません。

6.  IANA Considerations

6. IANA問題

   This document changes the recommended usage of two of the
   Interface_ID Types defined in [RFC3471].  For this reason, the IANA
   registry of GMPLS Signaling Parameters has been updated to read:

このドキュメントは[RFC3471]で定義された2Interface_ID Typesのお勧めの用法を変えます。 この理由で、読むためにGMPLS Signaling ParametersのIANA登録をアップデートしました:

   4      12      COMPONENT_IF_DOWNSTREAM - DEPRECATED
   5      12      COMPONENT_IF_UPSTREAM   - DEPRECATED

4 12コンポーネント、__川下--__上流であるなら5 12コンポーネントを非難します--非難されること。

Kompella, et al.            Standards Track                     [Page 9]

RFC 4201                Link Bundling in MPLS-TE            October 2005

Kompella、他 2005年10月にMPLS-Teで荷物をまとめる標準化過程[9ページ]RFC4201リンク

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [GMPLS-ISIS]    Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate
                   System to Intermediate System (IS-IS) Extensions in
                   Support of Generalized Multi-Protocol Label Switching
                   (GMPLS)", RFC 4205, October 2005.

エド[GMPLS-イシス]Kompella、K.Y.Rekhter、エド、「中間システムへの中間システム、(-、)、一般化されたマルチプロトコルを支持した拡大が切り換え(GMPLS)をラベルする、」、RFC4205(2005年10月)

   [GMPLS-OSPF]    Kompella, K. Ed. and Y. Rekhter, Ed., "OSPF
                   Extensions in Support of Generalized Multi-Protocol
                   Label Switching (GMPLS)", RFC 4203, October 2005.

エド[GMPLS-OSPF]Kompella、エドK.Y.Rekhter、「一般化されたマルチプロトコルラベルを支持したOSPF拡張子は(GMPLS)を切り換えること」でのRFC4203(2005年10月)。

   [GMPLS-ROUTING] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
                   Extensions in Support of Generalized Multi-Protocol
                   Label Switching (GMPLS)", RFC 4202, October 2005.

[GMPLS-ルーティング] エドKompella、K.、エドY.Rekhter、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)を支持して拡大を発送すること」でのRFC4202(2005年10月)。

   [RFC3471]       Berger, L., "Generalized Multi-Protocol Label
                   Switching (GMPLS) Signaling Functional Description",
                   RFC 3471, January 2003.

[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。

   [RFC3473]       Berger, L., "Generalized Multi-Protocol Label
                   Switching (GMPLS) Signaling Resource ReserVation
                   Protocol-Traffic Engineering (RSVP-TE) Extensions",
                   RFC 3473, January 2003.

[RFC3473] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。

   [RFC3472]       Ashwood-Smith, P. and L. Berger, "Generalized Multi-
                   Protocol Label Switching (GMPLS) Signaling
                   Constraint-based Routed Label Distribution Protocol
                   (CR-LDP) Extensions", RFC 3472, January 2003.

[RFC3472]Ashwood-スミス(P.とL.バーガー)は、「規制ベースの発送されたラベル分配プロトコル(CR-自由民主党)拡大に合図しながら、マルチプロトコルラベルの切り換え(GMPLS)を一般化しました」、RFC3472、2003年1月。

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

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

   [RFC3630]       Katz, D., Kompella, K., and D. Yeung, "Traffic
                   Engineering (TE) Extensions to OSPF Version 2", RFC
                   3630, September 2003.

[RFC3630] キャッツ、D.、Kompella、K.、およびD.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」

   [RFC3480]       Kompella, K., Rekhter, Y., and A. Kullberg,
                   "Signalling Unnumbered Links in CR-LDP (Constraint-
                   Routing Label Distribution Protocol)", RFC 3480,
                   February 2003.

[RFC3480] Kompella、K.、Rekhter、Y.、およびA.Kullberg、「CR-自由民主党(規制ルート設定ラベル分配プロトコル)で無数のリンクに合図します」、RFC3480(2003年2月)。

   [RFC3477]       Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                   Links in Resource ReSerVation Protocol - Traffic
                   Engineering (RSVP-TE)", RFC 3477, January 2003.

[RFC3477] Kompella、K.、およびY.Rekhter、「資源予約に基づく合図の無数のリンクは議定書を作ります--交通工学(RSVP-Te)」、RFC3477、2003年1月。

Kompella, et al.            Standards Track                    [Page 10]

RFC 4201                Link Bundling in MPLS-TE            October 2005

Kompella、他 2005年10月にMPLS-Teで荷物をまとめる標準化過程[10ページ]RFC4201リンク

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

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

   [RFC3209]       Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                   V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
                   LSP Tunnels", RFC 3209, December 2001.

[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。

   [RFC3212]       Jamoussi, B., Andersson, L., Callon, R., Dantu, R.,
                   Wu, L., Doolan, P., Worster, T., Feldman, N.,
                   Fredette, A., Girish, M., Gray, E., Heinanen, J.,
                   Kilty, T., and A. Malis, "Constraint-Based LSP Setup
                   using LDP", RFC 3212, January 2002.

[RFC3212] Jamoussi、B.、アンデション、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、オースター、T.、フェルドマン、N.、Fredette、A.、Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.、およびA.Malis、「自由民主党を使用して、規制ベースのLSPはセットアップします」、RFC3212、2002年1月。

7.2.  Informative References

7.2. 有益な参照

   [LMP]           Lang, J., Ed., "Link Management Protocol (LMP)", RFC
                   4204, October 2005.

[LMP] ラング、J.、エド、「リンク管理プロトコル(LMP)」、RFC4204、10月2005日

Authors' Addresses

作者のアドレス

   Kireeti Kompella
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA 94089

Kireeti Kompella杜松はInc.1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089

   EMail: kireeti@juniper.net

メール: kireeti@juniper.net

   Yakov Rekhter
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA 94089

ヤコフRekhter JuniperはInc.1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089

   EMail: yakov@juniper.net

メール: yakov@juniper.net

   Lou Berger
   Movaz Networks, Inc.

ルウバーガーMovazはInc.をネットワークでつなぎます。

   Phone: +1 703-847-1801
   EMail: lberger@movaz.com

以下に電話をしてください。 +1 703-847-1801 メールしてください: lberger@movaz.com

Kompella, et al.            Standards Track                    [Page 11]

RFC 4201                Link Bundling in MPLS-TE            October 2005

Kompella、他 2005年10月にMPLS-Teで荷物をまとめる標準化過程[11ページ]RFC4201リンク

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   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 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機能のための基金は現在、インターネット協会によって提供されます。

Kompella, et al.            Standards Track                    [Page 12]

Kompella、他 標準化過程[12ページ]