[要約] RFC 4201は、MPLS Traffic Engineering（TE）におけるリンクバンドリングに関する規格です。このRFCの目的は、複数のリンクを束ねて1つの論理リンクとして扱い、ネットワークの効率性と信頼性を向上させることです。
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
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達を目的として、特定の場合、<リンク識別子の組み合わせ、ラベル>の組み合わせは、ラベルスイッチ付きパス（LSP）で使用される適切なリソースを明確に識別するのに十分ではありません。このようなケースは、このドキュメントで説明されているリンクバンドリングコンストラクトを使用して処理されます。このドキュメントは、gmplsシグナル機能の説明で定義されているインターフェイス識別TLVを更新します。
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
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.
一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達を目的として、特定の場合、<リンク識別子の組み合わせ、ラベル>の組み合わせは、ラベルスイッチ付きパス（LSP）で使用される適切なリソースを明確に識別するのに十分ではありません。このようなケースは、このドキュメントで説明されているリンクバンドリングコンストラクトを使用して処理されます。このドキュメントは、gmplsシグナル機能の説明で定義されているインターフェイス識別TLVを更新します。
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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
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-routing]で定義されているように、トラフィックエンジニアリング（TE）リンクは、特定の物理リソース（およびそのプロパティ）に関する情報をグループ化/マップする方法を表す論理的な構成です。パス計算の目的で）およびGMPLSシグナリングによる。
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-routing]で述べられているように、GMPLSシグナル伝達を目的として特定のTEリンクを形成するリソースの性質に応じて、場合によっては<TEリンク識別子の組み合わせで、ラベル>は使用される適切なリソースを明確に識別するのに十分ですLSPによって。それ以外の場合、<teリンク識別子、ラベル>の組み合わせでは十分ではありません。たとえば、このリンクがいくつかの繊維で構成されているSONET/SDHクロスコネクトのペア間のTEリンクを検討してください。この場合、ラベルはTDMタイムスロットであり、さらに、今回は特定のファイバー内でのみ重要です。したがって、このようなリンクでLSPを信号する場合、リンクのアイデンティティだけでなく、そのリンク内の特定のファイバーの識別と、そのファイバー内の特定のラベル（タイムスロット）も指定する必要があります。。このようなケースは、このドキュメントで説明されているリンクバンドリングコンストラクトを使用して処理されます。
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シグナル伝達の目的のために、LSPが使用する適切なリソースを明確に識別するのに十分ではない<TEリンク識別子の組み合わせであるTEリンクを考えてみましょう。この状況では、リンクバンドリングコンストラクトでは、TEリンクを形成するリソースのセットを分離サブセットに分割できることを前提としています。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 information. To limit the amount of losses, one needs to restrict the type of information that can be aggregated/abstracted.
Link Bundlingの目的は、OSPFおよび/またはIS-ISで処理する必要がある情報の量を減らすことにより、ルーティングのスケーラビリティを改善することです。この削減は、情報集約/抽象化を実行することで達成されます。他の情報集約/抽象化と同様に、これにより情報の一部が失われます。損失の量を制限するには、集約/抽象化できる情報の種類を制限する必要があります。
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.
バンドル内のすべてのコンポーネントリンクには、同じリンクタイプ（つまり、ポイントツーポイントまたはマルチアクセス）、同じトラフィックエンジニアリングメトリック、リンクの両端に同じリソースクラスのセットがあり、開始して終了する必要があります。LSRの同じペア。
A Forwarding Adjacency may be a component link; in fact, a bundle can consist of a mix of point-to-point links and FAs.
転送隣接はコンポーネントリンクである場合があります。実際、バンドルは、ポイントツーポイントリンクとFAの組み合わせで構成できます。
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.
コンポーネントリンクがすべてマルチアクセスリンクである場合、各コンポーネントリンクに接続されているIS-ISまたは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アドレスと同じスコープを持っていることを意味します。
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.
隣接する転送によってリンクが形成される場合を含む、非仮定コンポーネントリンクの識別子の取り扱いは、非仮定されたTEリンクのルールと同じルールに従います（[RFC3477]/[RFC3480]のセクション「リンク識別子」を参照）。さらに、特定のLSR（コンポーネントリンク、転送、バンドルリンクの場合）のすべての非番号のリンクのローカル識別子をリンクすることは、その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つが生きていると判断されたときに生きています。コンポーネントリンクの活性は、コンポーネントリンク上のIS-ISまたはOSPF Hellos、RSVP Hello、LMP Hellos（[LMP]を参照）、またはレイヤー1またはレイヤー2の適応症からのいくつかの手段のいずれかによって決定できます。
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情報を浸水させることができます。IS-IS/OSPF Hellosがコンポーネントリンク上で実行されている場合、IS-IS/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.
将来的には、新しいトラフィックエンジニアリングパラメーターがIS-ISとOSPFに追加されるため、それらをどのようにバンドルできるか、およびバンドリングの可能な制限に関する説明を伴う必要があります。
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のコンポーネントリンクの選択は、バンドルされたリンクの両端にある2つのLSR間の局所的な問題です。
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.
シグナリングは、使用するコンポーネントリンクとラベルの両方を識別する必要があります。使用するコンポーネントリンクの選択は、常にパス/リクエストメッセージの送信者によって行われます。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-LDPメッセージで運ばれます。非仮定リンクに関連する追加の処理は、[if_id rsvp_hopオブジェクトの処理]/「if_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]は、インターフェイス識別タイプ長値（TLV）タイプを定義します。このドキュメントは、TLVタイプ1、2、および3を使用して、IF_ID RSVP_HOPオブジェクトとIF_ID TLVのコンポーネントリンクを示す必要があることを指定しています。
Type 1 TLVs are used for IPv4 numbered component link identifiers.
タイプ1 TLVは、IPv4番号付きコンポーネントリンク識別子に使用されます。
Type 2 TLVs are used for IPv6 numbered component link identifiers.
タイプ2 TLVは、IPv6番号付きコンポーネントリンク識別子に使用されます。
Type 3 TLVs are used for unnumbered component link identifiers.
タイプ3 TLVは、非仮定コンポーネントリンク識別子に使用されます。
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.
コンポーネントインターフェイスTLV、TLVタイプ4および5は使用しないでください。注パスメッセージとリクエストメッセージでは、リンク識別子を送信者の視点から指定する必要があります。
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.
以下の特別なケースを除き、単方向LSPの場合、IF_ID RSVP_HOPオブジェクトまたはIF_ID TLVで1つの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の場合、IF_ID RSVP_HOPオブジェクトまたはIF_ID TLVで1つまたは2つのTLVのみを使用する必要があります。最初のTLVは、ラベル割り当てを実行する必要がある下流のデータチャネルのコンポーネントリンク識別子を常に示します。存在する場合、2番目のTLVは常に、ラベル割り当てを実行する必要があるアップストリームデータチャネルのコンポーネントリンク識別子を示します。1つのTLVのみが存在する場合、下流および上流のデータチャネルの両方のコンポーネントリンク識別子を示します。
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.
すべてのコンポーネントリンクで同じラベルが有効である特別な場合、2つのTLVをIF_ID RSVP_HOPオブジェクトまたはIF_ID TLVで使用する必要があります。最初のTLVは、ラベル割り当てを実行する必要があるバンドルのTEリンク識別子を示します。2番目のTLVは、バンドルスコープラベルを示します。TLVタイプ1および2の場合、これはすべてのもの（1）の特別なビット値（タイプ1 TLVの0xffffffffff）を使用して行われます。[RFC3471]ごとに、TLVタイプ3、4、および5の場合、これはインターフェイスIDフィールドを特別な値0xffffffffに設定することによって行われます。この特別なケースは、単方向LSPと双方向LSPの両方に適用されることに注意してください。
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.
使用するべきではありませんが、使用する場合は、タイプ5 TLVがIF_ID RSVP_HOPオブジェクトまたはIF_ID TLVの最初の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.
このセクションでは、セクション9.1.1を変更します。[RFC3471]。TLVタイプ3、4、および5のIPアドレスフィールドの定義は明確にされています。
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の場合、値フィールドには、[RFC3477]で定義されているCタイプ1 LSP_Tunnel_Interface_IDオブジェクトの内容と同一の形式があります。これにより、[RFC3471]で定義されているIPアドレスフィールドの名前変更が生じることに注意してください。
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.
インターフェイス識別TLVを使用すると、TLVはエラーに関連付けられた特定のコンポーネントを示すためにも使用されます。RSVPの場合、これは、受信したTLVをif_id error_specオブジェクトにコピーする必要があることを意味します（[RFC3473]のセクション8.2を参照）。オブジェクトのエラーノードアドレスフィールドは、エラーに関連付けられたTEリンクを示す必要があります。CR-LDPの場合、これは、受信したTLVをIF_IDステータスTLVにコピーする必要があることを意味します（[RFC3472]のセクション8.2を参照）。TLVのホップアドレスフィールドは、エラーに関連するTEリンクを示す必要があります。
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].
このセクションでは、コンポーネントリンクとバンドルリンクの構成に基づいて、バンドルされたリンク用に宣伝されるトラフィックエンジニアリングパラメーターを定義します。コンポーネントリンクのこれらのパラメーターの定義は、[RFC3784]および[RFC3630]で行われました。[RFC3630]の用語を使用します。
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.
バンドルされたリンクのリンクタイプは、コンポーネントリンクの（一意の）リンクタイプです。このパラメーターはIS-ISには存在しないことに注意してください。
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.
ポイントツーポイントリンクの場合、バンドルされたリンクのリンクIDは、近隣の（一意の）ルーターIDです。マルチアクセスリンクの場合、これは（一意の）指定されたルーターのインターフェイスアドレスです。このパラメーターはIS-ISには存在しないことに注意してください。
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.
IS-ISでは、ローカルインターフェイスIPアドレスはIPv4インターフェイスアドレスとして知られており、リモートインターフェイスIPアドレスはIPv4隣接アドレスとして知られていることに注意してください。
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.
バンドルされたリンクに番号が付けられている場合、ローカルインターフェイスIPアドレスはバンドルリンクのローカルアドレスです。同様に、リモートインターフェイスIPアドレスは、バンドルリンクのリモートアドレスです。
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に設定されています。
The Traffic Engineering Metric for a bundled link is that of the component links.
バンドルされたリンクのトラフィックエンジニアリングメトリックは、コンポーネントリンクのメトリックです。
This parameter is not used. The maximum LSP Bandwidth (as described below) replaces the Maximum Bandwidth for bundled links.
このパラメーターは使用されません。最大LSP帯域幅（以下に説明する）は、バンドルされたリンクの最大帯域幅を置き換えます。
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.
特定のバンドルされたリンクの場合、各コンポーネントリンクが最大予約可能な帯域幅で構成されているか、バンドルされたリンクが最大予約可能な帯域幅で構成されていると仮定します。前者の場合、バンドルされたリンクの最大予約可能な帯域幅は、バンドルされたリンクに関連付けられたすべてのコンポーネントリンクの最大予約可能帯域幅の合計に設定されます。
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での予約されていない帯域幅の合計です。
The Resource Classes for a bundled link are the same as those of the component links.
バンドルされたリンクのリソースクラスは、コンポーネントリンクのリソースクラスと同じです。
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.
最大LSP帯域幅は、最大帯域幅に取って代わります。バンドルされていないリンクの場合、最大帯域幅は[gmpls-routing]で定義されます。優先Pでバンドルされたリンクの最大LSP帯域幅は、そのすべてのコンポーネントリンクの優先Pでの最大LSP帯域幅の最大値と定義されています。
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].
IS-ISで最大LSP帯域幅がどのように運ばれるかの詳細は、[GMPLS-ISIS]に記載されています。OSPFで最大LSP帯域幅がどのように運ばれるかの詳細は、[Gmpls-ospf]で示されています。
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.
RSVP（またはCR-LDP）トラフィックコントロールモジュール、または同等のLSRにバンドルされたリンクを備えたLSRには、コンポーネントごとのリンクベースで入場制御を適用する必要があります。少なくとも1つのコンポーネントリンクに最大LSP帯域幅> = bが優先pで帯域幅のリンクに適合する帯域幅要件Bとセットアップ優先度Pが適合します。そのようなリンクがいくつかある場合、実装は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帯域幅（優先度ごと）を知るために、トラフィックコントロールモジュールは、各コンポーネントリンクの予約されていない帯域幅（優先度あたり）を追跡する必要があります。
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つのコンポーネントリンクがアップしていれば、関連するバンドルリンクが維持され、宣伝され続けます。ダウンしているコンポーネントリンクの予約されていない帯域幅はゼロに設定されており、バンドルの帯域幅と最大LSP帯域幅を再計算する必要があります。特定のバンドルされたリンクに関連付けられているすべてのコンポーネントリンクがダウンしている場合、バンドルされたリンクをOSPF/IS-ISに宣伝してはなりません。
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-LDP [RFC3212]の新しいセキュリティ問題を提起しません。
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]で定義されている2つのinterface_idタイプの推奨使用法を変更します。このため、GMPLSシグナル伝達パラメーターのIANAレジストリが更新されて読み取られました。
4 12 COMPONENT_IF_DOWNSTREAM - DEPRECATED 5 12 COMPONENT_IF_UPSTREAM - DEPRECATED
4 12 component_if_downStream -deprecated 5 12 component_if_upstream -deprecated
[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-isis] Kompella、K。Ed。およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートする中間システム（IS-IS）拡張」、RFC 4205、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。Ed。and Y. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、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-routing] Kompella、K.、ed。and Y. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、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] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソースリソースプロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、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-Smith、P。およびL. Berger、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達制約ベースのルーティングラベル分布プロトコル（CR-LDP）拡張」、RFC 3472、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] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年6月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、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-LDP（Constraint-routing Label Distribution Protocol）の数のリンクのシグナリング」、RFC 3480、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）」、RFC 3477、2003年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[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.、Andersson、L.、Callon、R.、Dantu、R.、Wu、L.、Doolan、P.、Worster、T.、Feldman、N.、Fredette、A.、Girish、M.、Gray、E.、Heinanen、J.、Kilty、T。、およびA. Malis、「LDPを使用した制約ベースのLSPセットアップ」、RFC 3212、2002年1月。
[LMP] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[LMP] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
Authors' Addresses
著者のアドレス
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks、Inc。1194 N. Mathilda Ave. Sunnyvale、CA 94089
EMail: kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks、Inc。1194 N. Mathilda Ave. Sunnyvale、CA 94089
EMail: yakov@juniper.net
Lou Berger Movaz Networks, Inc.
Lou Berger Movaz Networks、Inc。
Phone: +1 703-847-1801
EMail: lberger@movaz.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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エディター機能の資金は現在、インターネット協会によって提供されています。