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)
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).
著作権（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.
ある場合には、組み合わせシグナリング一般化されたマルチプロトコルラベルスイッチング（GMPLS）の目的のために<リンクID、ラベル>は一義的ラベルスイッチパス（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）の目的のために<リンクID、ラベル>は一義的ラベルスイッチパス（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）リンクが制約SPF（によって使用される情報とその相互接続LSRの特定の物理的リソース（およびそのプロパティ）約グループ/地図情報への道を表す論理構成体であります経路計算の目的のために）と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シグナリングの目的のために特定のTEリンクを形成するリソースの性質に応じて、[GMPLS-ROUTING]で述べたように、いくつかのケースの組み合わせの<TEリンクID、ラベル>は明白使用に適切なリソースを識別するのに十分ですLSPによります。他の例では、<TEリンクID、ラベル>の組み合わせは十分ではありません。例えば、このTEリンクは、いくつかの繊維で構成されているSONET / SDHクロスコネクトの対の間の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リンクID、ラベル>は明白LSPによって使用される適切なリソースを識別するのに十分ではない、ようにTEリンクを考えます。この状況では、リンクバンドル構築物は（a）のパーティションが最小である、および（b）各サブセット内で、ラベルは明確に十分であるように、TEリンクを形成するリソースのセットが互いに素なサブセットに分割することができることを前提としていLSPによって使用される適切なリソースを識別します。私たちは、「コンポーネントリンク」として、そして「バンドルリンク」など、全TEリンクに、このようなサブセットを参照してください。さらに、我々は、彼らが与えられたノードに対して一意であるようにコンポーネントリンクを識別するために使用できる識別子を制限します。バンドルリンクを、<コンポーネントリンクID、ラベル>の組み合わせは明白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.
リンクバンドルの目的は、OSPFによって扱われなければならない、および/または、ある情報の量を低減することにより、ルーティングのスケーラビリティを改善することです。この減少は、情報集合/抽象化を行うことによって達成されます。その他の情報の集約/抽象化と同じように、これは情報の一部を失うことになります。損失の量を制限するためには、/集約抽象化することができる情報の種類を制限する必要があります。
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.
転送隣接コンポーネントリンクであってもよいです。実際には、バンドルは、ポイントツーポイントリンクおよび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.
コンポーネントリンクが全てマルチアクセスリンクである場合、各コンポーネントリンクに接続されている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.
リンクが転送隣接することによって形成される場合を含む無数のコンポーネントリンクの識別子を処理する、（[RFC3477] / [RFC3480]のセクション「リンク識別子」を参照）無数のTEリンクのと同じ規則に従います。さらに、その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.
バンドルリンクの「ライブネスは」バンドルリンク内のコンポーネントリンクのそれぞれの生存性によって決定されます。その成分のリンクの少なくとも一方が生きていると判定された場合バンドルリンクが生きています。コンポーネントリンク、ハローRSVP、LMPのhello（[LMP]参照）を介して、又は層1又は層2つの指標から-ISまたはOSPFのhello：コンポーネントリンクの生存性は、いくつかの手段のいずれかによって決定することができます。
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のhelloは、コンポーネントリンク上で実行されている場合は、IS-IS / OSPFフラッディングはコンポーネントリンクのひとつに制限することができます。これを行うための手順は、この文書の範囲外です。
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.
シグナリングは、使用するコンポーネントのリンクとラベルの両方を指定する必要があります。使用するコンポーネントリンクの選択は、常にパス/ 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-LDPメッセージで運ばれます。無数のリンクに関連する追加の処理が/「IF_ID TLVを処理して」「IF_ID RSVP_HOPオブジェクトの処理」、および[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は、使用されるべきではありません。パスと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.
一方向LSPのために、以下に記載する特別な場合を除いて、単一のTLVはIF_ID RSVP_HOPオブジェクトまたはIF_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つまたは2つのTLVはIF_ID RSVP_HOPオブジェクトまたはIF_ID TLVで使用する必要があり、以下に記載します。最初のTLVは、常にラベルの割り当てが行われなければならないれた下りデータチャネルのコンポーネントリンク識別子を示します。存在する場合、第二のTLVは、常にラベルの割り当てが行われなければならないれた上りデータチャネルのコンポーネントリンク識別子を示します。唯一の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.
同じラベルがすべてのコンポーネントリンク間有効であることである特殊なケースでは、二つのTLVはIF_ID RSVP_HOPオブジェクトまたはIF_ID TLVで使用されるべきです。最初のTLVはラベル割り当てが行われなければならない上、バンドルのTEリンク識別子を示します。二TLVは、バンドルスコープのラベルを示します。 TLVタイプ1と2の場合、これはすべてのものの特別なビット値を使用して行われる（1）（例えば、0xFFFFFFFFのタイプ1 TLVのために）。 [RFC3471]は、TLVタイプ3、4、および5のために、これは特別な値は0xFFFFFFFFにインタフェースIDフィールドを設定することによって行われます。この特殊なケースは、単方向および双方向の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は、（[RFC3473]セクション8.2を参照）IF_ID ERROR_SPECオブジェクトにコピーする必要が受信したことを意味します。オブジェクトのエラーノードアドレスフィールドには、エラーに関連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].
最大のLSP帯域幅はISISで搬送する方法の詳細は[GMPLS-ISIS]で与えられます。最大のLSP帯域幅がOSPFで搬送する方法の詳細は[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.
バンドルリンクを持つLSRにRSVP（またはCR-LDP）トラフィック制御モジュール、またはその等価物は、コンポーネントごとのリンクに基づいてアドミッション制御を適用しなければなりません。少なくとも一つのコンポーネントリンクが優先度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帯域幅を知るために、トラフィック制御モジュールは、各コンポーネントリンクについて予約されていない帯域幅を（優先度ごとに）追跡しなければなりません。
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にアドバタイズされないMUST / 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]で定義されたInterface_IDタイプの2の推奨使用方法を変更します。このため、GMPLSシグナリングパラメータのIANAレジストリが読み取るように更新されました。
4 12 COMPONENT_IF_DOWNSTREAM - DEPRECATED 5 12 COMPONENT_IF_UPSTREAM - DEPRECATED
4 12 COMPONENT_IF_DOWNSTREAM - 5 12 COMPONENT_IF_UPSTREAM非推奨 - 非難
[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.編。そして、Y. Rekhter、エド。、RFC 4205、2005年10月 "中間システム（IS-IS）一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで機能拡張への中間システム"。
[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、エド。、RFC 4203 "一般化マルチプロトコルラベルスイッチング（GMPLS）の支援でOSPF拡張機能"、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.、エド。 、RFC 4202およびY. Rekhter、エド。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）の支援でルーティング拡張機能」、2005年10月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、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]バーガー、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]アッシュウッド・スミス、P。およびL.バーガー、 "一般化マルチプロトコルラベルスイッチング（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]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、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]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）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（制約ルーティングラベル配布プロトコル）シグナリングアンナンバードリンク"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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.、アンダーソン、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、Worster、T.、フェルドマン、N.、Fredette、A.、Girish、 M.、グレー、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]ラング、J.、エド。、 "リンク管理プロトコル（LMP）"、RFC 4204、2005年10月。
Authors' Addresses
著者のアドレス
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompellaジュニパーネットワークス株式会社1194 N.マチルダアベニュー。サニーベール、CA 94089
EMail: kireeti@juniper.net
メールアドレス：kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
ヤコフ・レックタージュニパーネットワークス株式会社1194 N.マチルダアベニュー。サニーベール、CA 94089
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Lou Berger Movaz Networks, Inc.
ルー・バーガーMovazネットワークス株式会社
Phone: +1 703-847-1801 EMail: lberger@movaz.com
電話：+1 703-847-1801電子メール：lberger@movaz.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。