RFC 4202 - Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4202
タイトル : RFC 4202 - 一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能
翻訳編集 : 自動生成

[要約] RFC 4202は、GMPLSをサポートするためのルーティング拡張に関する規格です。その目的は、異なるプロトコル間のラベルスイッチングをサポートするための効果的なルーティングメカニズムを提供することです。

Network Working Group                                   K. Kompella, Ed.
Request for Comments: 4202                              Y. Rekhter,  Ed.
Category: Standards Track                               Juniper Networks
                                                            October 2005

Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)

一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE).

このドキュメントは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）のリンク状態情報のキャリーをサポートするルーティング拡張機能を指定します。このドキュメントは、MPLSトラフィックエンジニアリング（TE）をサポートするために必要なルーティング拡張機能を強化します。

Table of Contents

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements for Layer-Specific TE Attributes . . . . .   4
       1.2.  Excluding Data Traffic from Control Channels. . . . . .   6
   2.  GMPLS Routing Enhancements. . . . . . . . . . . . . . . . . .   7
       2.1.  Support for Unnumbered Links. . . . . . . . . . . . . .   7
       2.2.  Link Protection Type. . . . . . . . . . . . . . . . . .   7
       2.3.  Shared Risk Link Group Information. . . . . . . . . . .   9
       2.4.  Interface Switching Capability Descriptor . . . . . . .   9
             2.4.1.  Layer-2 Switch Capable. . . . . . . . . . . . .  11
             2.4.2.  Packet-Switch Capable . . . . . . . . . . . . .  11
             2.4.3.  Time-Division Multiplex Capable . . . . . . . .  12
             2.4.4.  Lambda-Switch Capable . . . . . . . . . . . . .  13
             2.4.5.  Fiber-Switch Capable. . . . . . . . . . . . . .  13
             2.4.6.  Multiple Switching Capabilities per Interface .  13
             2.4.7.  Interface Switching Capabilities and Labels . .  14
             2.4.8.  Other Issues. . . . . . . . . . . . . . . . . .  14
       2.5.  Bandwidth Encoding. . . . . . . . . . . . . . . . . . .  15
   3.  Examples of Interface Switching Capability Descriptor . . . .  15
       3.1.  STM-16 POS Interface on a LSR . . . . . . . . . . . . .  15
       3.2.  GigE Packet Interface on a LSR. . . . . . . . . . . . .  15
       3.3.  STM-64 SDH Interface on a Digital Cross Connect with
             Standard SDH. . . . . . . . . . . . . . . . . . . . . .  15
       3.4.  STM-64 SDH Interface on a Digital Cross Connect with
             Two Types of SDH Multiplexing Hierarchy Supported . . .  16
       3.5.  Interface on an Opaque OXC (SDH Framed) with Support
             for One Lambda per Port/Interface . . . . . . . . . . .  16
       3.6.  Interface on a Transparent OXC (PXC) with External
             DWDM that understands SDH framing . . . . . . . . . . .  17
       3.7.  Interface on a Transparent OXC (PXC) with External
             DWDM That Is Transparent to Bit-Rate and Framing. . . .  17
       3.8.  Interface on a PXC with No External DWDM. . . . . . . .  18
       3.9.  Interface on a OXC with Internal DWDM That Understands
             SDH Framing . . . . . . . . . . . . . . . . . . . . . .  18
       3.10. Interface on a OXC with Internal DWDM That Is
             Transparent to Bit-Rate and Framing . . . . . . . . . .  19
   4.  Example of Interfaces That Support Multiple Switching
       Capabilities. . . . . . . . . . . . . . . . . . . . . . . . .  20
       4.1.  Interface on a PXC+TDM Device with External DWDM. . . .  20
       4.2.  Interface on an Opaque OXC+TDM Device with External
             DWDM. . . . . . . . . . . . . . . . . . . . . . . . . .  21
       4.3.  Interface on a PXC+LSR Device with External DWDM. . . .  21
       4.4.  Interface on a TDM+LSR Device . . . . . . . . . . . . .  21
   5.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  22
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
      7.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  23
       7.1.  Normative References. . . . . . . . . . . . . . . . . .  23
       7.2.  Informative References. . . . . . . . . . . . . . . . .  24
   8.  Contributors. . . . . . . . . . . . . . . . . . . . . . . . .  24

1. Introduction

1. はじめに

このドキュメントは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）のリンク状態情報のキャリーをサポートするルーティング拡張機能を指定します。このドキュメントは、MPLSトラフィックエンジニアリング（TE）をサポートするために必要なルーティング拡張[ISIS-TE]、[OSPF-TE]を強化します。

Traditionally, a TE link is advertised as an adjunct to a "regular" link, i.e., a routing adjacency is brought up on the link, and when the link is up, both the properties of the link are used for Shortest Path First (SPF) computations (basically, the SPF metric) and the TE properties of the link are then advertised.

伝統的に、TEリンクは「通常の」リンクの補助として宣伝されています。つまり、リンクにルーティング隣接性が掲載され、リンクがアップされている場合、リンクの両方のプロパティが最短パスに使用されます（SPF））計算（基本的には、SPFメトリック）とリンクのTEプロパティが宣伝されます。

GMPLS challenges this notion in three ways. First, links that are not capable of sending and receiving on a packet-by-packet basis may yet have TE properties; however, a routing adjacency cannot be brought up on such links. Second, a Label Switched Path can be advertised as a point-to-point TE link (see [LSP-HIER]); thus, an advertised TE link may be between a pair of nodes that don't have a routing adjacency with each other. Finally, a number of links may be advertised as a single TE link (perhaps for improved scalability), so again, there is no longer a one-to-one association of a regular routing adjacency and a TE link.

GMPLSは、この概念に3つの方法で挑戦します。まず、パケットごとに送信および受信できないリンクには、まだプロパティがある場合があります。ただし、そのようなリンクでルーティングの隣接性を持ち出すことはできません。第二に、ラベルスイッチされたパスは、ポイントツーポイントTEリンクとして宣伝できます（[LSP-Hier]を参照）。したがって、広告されたTEリンクは、互いにルーティング隣接を持たないノードのペア間にある場合があります。最後に、多くのリンクが単一のTEリンクとして宣伝される場合があります（おそらくスケーラビリティを改善するため）。したがって、通常のルーティング隣接とTEリンクの1対1の関連付けはもはやありません。

Thus we have a more general notion of a TE link. A TE link is a "logical" link that has TE properties. The link is logical in a sense that it represents a way to group/map the information about certain physical resources (and their properties) into the information that is used by Constrained SPF for the purpose of path computation, and by GMPLS signaling. This grouping/mapping must be done consistently at both ends of the link. LMP [LMP] could be used to check/verify this consistency.

したがって、TEリンクのより一般的な概念があります。TEリンクは、TEプロパティを備えた「論理」リンクです。リンクは、特定の物理リソース（およびそのプロパティ）に関する情報をグループ化/マッピングする方法を表し、パス計算を目的として制約されたSPFおよびGMPLSシグナリングによって使用される情報にグループ/マッピングする方法を表すという意味で論理的です。このグループ化/マッピングは、リンクの両端で一貫して行う必要があります。LMP [LMP]を使用して、この一貫性を確認/検証できます。

Depending on the nature of resources that form a particular TE link, for the purpose of GMPLS signaling, in some cases the combination of <TE link identifier, label> is sufficient to unambiguously identify the appropriate resource used by an LSP. In other cases, the combination of <TE link identifier, label> is not sufficient; such cases are handled by using the link bundling construct [LINK-BUNDLE] that allows to identify the resource by <TE link identifier, Component link identifier, label>.

特定のTEリンクを形成するリソースの性質に応じて、GMPLSシグナル伝達を目的として、場合によっては<TEリンク識別子の組み合わせで、LSPが使用する適切なリソースを明確に識別するのに十分です。それ以外の場合、<teリンク識別子、ラベル>の組み合わせは十分ではありません。このようなケースは、<TEリンク識別子、コンポーネントリンク識別子、ラベル>によるリソースを識別できるリンクバンドリングコンストラクト[リンクバンル]を使用して処理されます。

Some of the properties of a TE link may be configured on the advertising Label Switching Router (LSR), others which may be obtained from other LSRs by means of some protocol, and yet others which may be deduced from the component(s) of the TE link.

TEリンクのプロパティの一部は、広告ラベルスイッチングルーター（LSR）で構成されている場合があります。TEリンク。

A TE link between a pair of LSRs doesn't imply the existence of a routing adjacency (e.g., an IGP adjacency) between these LSRs. As we mentioned above, in certain cases a TE link between a pair of LSRs could be advertised even if there is no routing adjacency at all between the LSRs (e.g., when the TE link is a Forwarding Adjacency (see [LSP-HIER])).

LSRのペア間のリンクは、これらのLSR間のルーティング隣接能力（IGP隣接など）の存在を意味するものではありません。上で述べたように、特定のケースでは、LSRの間にルーティングの隣接性がまったくない場合でも、LSRのペア間のTEリンクを宣伝することができます（たとえば、TEリンクが転送隣接性です（[LSP-Hier]を参照）））。

A TE link must have some means by which the advertising LSR can know of its liveness (this means may be routing hellos, but is not limited to routing hellos). When an LSR knows that a TE link is up, and can determine the TE link's TE properties, the LSR may then advertise that link to its (regular) neighbors.

TEリンクには、広告LSRがその活気を知ることができるいくつかの手段が必要です（これはHellosをルーティングすることができますが、Hellosをルーティングすることに限定されません）。LSRがTEリンクがアップしていることを知っており、TEリンクのTEプロパティを決定できると、LSRはそのリンクを（通常の）隣人に宣伝する場合があります。

In this document, we call the interfaces over which regular routing adjacencies are established "control channels".

このドキュメントでは、通常のルーティング隣接が「制御チャネル」が確立されるインターフェイスを呼び出します。

[ISIS-TE] and [OSPF-TE] define the canonical TE properties, and say how to associate TE properties to regular (packet-switched) links. This document extends the set of TE properties, and also says how to associate TE properties with non-packet-switched links such as links between Optical Cross-Connects (OXCs). [LSP-HIER] says how to associate TE properties with links formed by Label Switched Paths.

[ISIS-TE]および[OSPF-TE]は、標準的なTEプロパティを定義し、TEプロパティを通常の（パケットスイッチ）リンクに関連付ける方法を述べます。このドキュメントは、TEプロパティのセットを拡張し、TEプロパティを光クロスコネクト（OXC）間のリンクなどの非パケットスイッチのリンクに関連付ける方法についても説明します。[LSP-Hier]は、TEプロパティをラベルスイッチ付きパスによって形成されたリンクと関連付ける方法を述べています。

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

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。

1.1. Requirements for Layer-Specific TE Attributes

1.1. レイヤー固有のTE属性の要件

In generalizing TE links to include traditional transport facilities, there are additional factors that influence what information is needed about the TE link. These arise from existing transport layer architecture (e.g., ITU-T Recommendations G.805 and G.806) and associated layer services. Some of these factors are:

従来の輸送施設を含むためにTEリンクを一般化するには、TEリンクに必要な情報に影響を与える追加の要因があります。これらは、既存の輸送層アーキテクチャ（ITU-Tの推奨G.805およびG.806など）および関連する層サービスから生じます。これらの要因のいくつかは次のとおりです。

1. The need for LSPs at a specific adaptation, not just a particular bandwidth. Clients of optical networks obtain connection services for specific adaptations, for example, a VC-3 circuit. This not only implies a particular bandwidth, but how the payload is structured. Thus the VC-3 client would not be satisfied with any LSP that offered other than 48.384 Mbit/s and with the expected structure. The corollary is that path computation should be able to find a route that would give a connection at a specific adaptation.

1. 特定の帯域幅だけでなく、特定の適応でのLSPの必要性。光ネットワークのクライアントは、たとえばVC-3回路など、特定の適応のための接続サービスを取得します。これは、特定の帯域幅を意味するだけでなく、ペイロードの構造を意味します。したがって、VC-3クライアントは、48.384 MBIT/s以外の提供されたLSPおよび予想される構造に満足しません。結果は、パス計算が特定の適応で接続を与えるルートを見つけることができるはずだということです。

2. Distinguishing variable adaptation. A resource between two OXCs (specifically a G.805 trail) can sometimes support different adaptations at the same time. An example of this is described in section 2.4.8. In this situation, the fact that two adaptations are supported on the same trail is important because the two layers are dependent, and it is important to be able to reflect this layer relationship in routing, especially in view of the relative lack of flexibility of transport layers compared to packet layers.

2. 可変適応を区別します。2つのOXC（特にG.805トレイル）の間のリソースは、同時に異なる適応をサポートすることがあります。この例は、セクション2.4.8で説明されています。この状況では、2つの層が依存しているため、同じトレイルで2つの適応がサポートされているという事実が重要であり、特に輸送の柔軟性の相対的な欠如を考慮して、ルーティングでこの層の関係を反映できることが重要ですパケットレイヤーと比較したレイヤー。

3. Inheritable attributes. When a whole multiplexing hierarchy is supported by a TE link, a lower layer attribute may be applicable to the upper layers. Protection attributes are a good example of this. If an OC-192 link is 1+1 protected (a duplicate OC-192 exists for protection), then an STS-3c within that OC-192 (a higher layer) would inherit the same protection property.

3. 継承可能な属性。TEリンクによって多重化階層全体がサポートされている場合、下層属性が上層に適用される場合があります。保護属性はこの良い例です。OC-192リンクが1 1保護されている場合（保護のために重複するOC-192が存在します）、そのOC-192内のSTS-3C（より高い層）は同じ保護特性を継承します。

4. Extensibility of layers. In addition to the existing defined transport layers, new layers and adaptation relationships could come into existence in the future.

4. レイヤーの拡張性。既存の定義された輸送層に加えて、新しい層と適応関係が将来存在する可能性があります。

5. Heterogeneous networks whose OXCs do not all support the same set of layers. In a GMPLS network, not all transport layer network elements are expected to support the same layers. For example, there may be switches capable of only VC-11, VC-12, and VC-3, and there may be others that can only support VC-3 and VC-4. Even though a network element cannot support a specific layer, it should be able to know if a network element elsewhere in the network can support an adaptation that would enable that unsupported layer to be used. For example, a VC-11 switch could use a VC-3 capable switch if it knew that a VC-11 path could be constructed over a VC-3 link connection.

5. OXCがすべて同じレイヤーをサポートするとは限らない不均一なネットワーク。GMPLSネットワークでは、すべてのトランスポートレイヤーネットワーク要素が同じレイヤーをサポートすると予想されるわけではありません。たとえば、VC-11、VC-12、およびVC-3のみが可能なスイッチが存在する場合があり、VC-3とVC-4のみをサポートできる他のスイッチもあります。ネットワーク要素は特定のレイヤーをサポートできませんが、ネットワーク内の他の場所のネットワーク要素が、サポートされていないレイヤーを使用できるようにする適応をサポートできるかどうかを知ることができるはずです。たとえば、VC-3リンク接続を介してVC-11パスを構築できることがわかっている場合、VC-11スイッチはVC-3対応スイッチを使用できます。

From the factors presented above, development of layer specific GMPLS routing documents should use the following principles for TE-link attributes.

上記の要因から、レイヤー固有のGMPLSルーティングドキュメントの開発は、TE-Link属性の次の原則を使用する必要があります。

1. Separation of attributes. The attributes in a given layer are separated from attributes in another layer.

1. 属性の分離。特定の層の属性は、別のレイヤーの属性から分離されます。

2. Support of inter-layer attributes (e.g., adaptation relationships). Between a client and server layer, a general mechanism for describing the layer relationship exists. For example, "4 client links of type X can be supported by this server layer link". Another example is being able to identify when two layers share a common server layer.

2. 層間属性のサポート（例：適応関係）。クライアントレイヤーとサーバーレイヤーの間に、レイヤー関係を記述するための一般的なメカニズムが存在します。たとえば、「タイプXの4つのクライアントリンクは、このサーバーレイヤーリンクによってサポートできます」。別の例は、2つのレイヤーが共通のサーバーレイヤーを共有するときに識別できることです。

3. Support for inheritable attributes. Attributes which can be inherited should be identified.

3. 継承可能な属性のサポート。継承できる属性を特定する必要があります。

4. Layer extensibility. Attributes should be represented in routing such that future layers can be accommodated. This is much like the notion of the generalized label.

4. レイヤーの拡張性。属性は、将来のレイヤーに対応できるようにルーティングに表す必要があります。これは、一般化されたラベルの概念によく似ています。

5. Explicit attribute scope. For example, it should be clear whether a given attribute applies to a set of links at the same layer.

5. 明示的な属性スコープ。たとえば、特定の属性が同じレイヤーのリンクのセットに適用されるかどうかは明確です。

The present document captures general attributes that apply to a single layer network, but doesn't capture inter-layer relationships of attributes. This work is left to a future document.

現在のドキュメントは、単一層ネットワークに適用される一般的な属性をキャプチャしますが、属性の層間関係をキャプチャしません。この作業は将来の文書に任されています。

1.2. Excluding Data Traffic from Control Channels

1.2. 制御チャネルからのデータトラフィックを除く

The control channels between nodes in a GMPLS network, such as OXCs, SDH cross-connects and/or routers, are generally meant for control and administrative traffic. These control channels are advertised into routing as normal links as mentioned in the previous section; this allows the routing of (for example) RSVP messages and telnet sessions. However, if routers on the edge of the optical domain attempt to forward data traffic over these channels, the channel capacity will quickly be exhausted.

OXCS、SDHクロスコネクト、および/またはルーターなどのGMPLSネットワーク内のノード間の制御チャネルは、一般に制御トラフィックと管理トラフィックを対象としています。これらの制御チャネルは、前のセクションで述べたように、通常のリンクとしてルーティングに宣伝されます。これにより、（たとえば）RSVPメッセージとTelnetセッションのルーティングが可能になります。ただし、光ドメインの端にあるルーターがこれらのチャネルでデータトラフィックを転送しようとすると、チャネル容量はすぐに使い果たされます。

In order to keep these control channels from being advertised into the user data plane a variety of techniques can be used.

これらの制御チャネルがユーザーデータプレーンに宣伝されないようにするために、さまざまな手法を使用できます。

If one assumes that data traffic is sent to BGP destinations, and control traffic to IGP destinations, then one can exclude data traffic from the control plane by restricting BGP nexthop resolution. (It is assumed that OXCs are not BGP speakers.) Suppose that a router R is attempting to install a route to a BGP destination D. R looks up the BGP nexthop for D in its IGP's routing table. Say R finds that the path to the nexthop is over interface I. R then checks if it has an entry in its Link State database associated with the interface I. If it does, and the link is not packet-switch capable (see [LSP-HIER]), R installs a discard route for destination D. Otherwise, R installs (as usual) a route for destination D with nexthop I. Note that R need only do this check if it has packet-switch incapable links; if all of its links are packet-switch capable, then clearly this check is redundant.

データトラフィックがBGP宛先に送信され、IGPの宛先へのトラフィックを制御することを想定している場合、BGP Nexthop解像度を制限することにより、制御プレーンからのデータトラフィックを除外できます。（OXCはBGPスピーカーではないと想定されています。）ルーターRがBGP宛先Dへのルートを設置しようとしているとします。Rは、IGPのルーティングテーブルでDのBGP Nexthopを検索します。rは、nexthopへのパスがインターフェイスIにあることを発見したとします。その後、インターフェイスIに関連付けられたリンク状態データベースにエントリがあるかどうかをチェックします。-hier]）、rは宛先Dの廃棄ルートをインストールします。それ以外の場合は、rは（通常のように）Nexthop Iで宛先Dのルートをインストールします。そのリンクがすべてパケットスイッチが有能な場合、このチェックは明らかに冗長です。

In other instances it may be desirable to keep the whole address space of a GMPLS routing plane disjoint from the endpoint addresses in another portion of the GMPLS network. For example, the addresses of a carrier network where the carrier uses GMPLS but does not wish to expose the internals of the addressing or topology. In such a network the control channels are never advertised into the end data network. In this instance, independent mechanisms are used to advertise the data addresses over the carrier network.

他の例では、GMPLSネットワークの別の部分のエンドポイントアドレスからGMPLSルーティングプレーンの格差のアドレススペース全体を維持することが望ましい場合があります。たとえば、キャリアがGMPLSを使用しているが、アドレス指定またはトポロジの内部を公開することを望んでいないキャリアネットワークのアドレス。このようなネットワークでは、制御チャネルが最終データネットワークに宣伝されることはありません。この例では、独立したメカニズムを使用して、キャリアネットワークを介してデータアドレスを宣伝します。

Other techniques for excluding data traffic from control channels may also be needed.

制御チャネルからデータトラフィックを除外するためのその他の手法も必要になる場合があります。

2. GMPLS Routing Enhancements

2. GMPLSルーティング拡張機能

In this section we define the enhancements to the TE properties of GMPLS TE links. Encoding of this information in IS-IS is specified in [GMPLS-ISIS]. Encoding of this information in OSPF is specified in [GMPLS-OSPF].

このセクションでは、GMPLS TEリンクのTEプロパティの拡張機能を定義します。IS-ISでのこの情報のエンコードは、[GMPLS-ISIS]で指定されています。OSPFでのこの情報のエンコードは、[GMPLS-OSPF]で指定されています。

2.1. Support for Unnumbered Links

2.1. 数え切れないほどのリンクのサポート

An unnumbered link has to be a point-to-point link. An LSR at each end of an unnumbered link assigns an identifier to that link. This identifier is a non-zero 32-bit number that is unique within the scope of the LSR that assigns it.

数え切れないほどのリンクは、ポイントツーポイントリンクでなければなりません。数値のないリンクの両端にあるLSRは、そのリンクに識別子を割り当てます。この識別子は、それを割り当てるLSRの範囲内で一意の非ゼロ32ビット番号です。

Consider an (unnumbered) link between LSRs A and B. LSR A chooses an idenfitier for that link. So does LSR B. From A's perspective we refer to the identifier that A assigned to the link as the "link local identifier" (or just "local identifier"), and to the identifier that B assigned to the link as the "link remote identifier" (or just "remote identifier"). Likewise, from B's perspective the identifier that B assigned to the link is the local identifier, and the identifier that A assigned to the link is the remote identifier.

LSRS AとB. LSR Aの間の（非数の）リンクを考えてみてください。LSRAは、そのリンクのIdenFitierを選択します。LSR Bも同様です。Aの観点からは、リンクに「リンクローカル識別子」（または「ローカル識別子」）としてリンクに割り当てられた識別子と、リンクにbに割り当てられた識別子を「リンクリモート」として参照します。識別子 "（または単なる「リモート識別子」）。同様に、Bの観点からは、リンクに割り当てられたbがローカル識別子であり、リンクに割り当てられた識別子がリモート識別子です。

Support for unnumbered links in routing includes carrying information about the identifiers of that link. Specifically, when an LSR advertises an unnumbered TE link, the advertisement carries both the local and the remote identifiers of the link. If the LSR doesn't know the remote identifier of that link, the LSR should use a value of 0 as the remote identifier.

ルーティングにおける非数のリンクのサポートには、そのリンクの識別子に関する情報の伝達が含まれます。具体的には、LSRが非自己リンクを宣伝する場合、広告にはリンクのローカル識別子とリモート識別子の両方が搭載されています。LSRがそのリンクのリモート識別子を知らない場合、LSRはリモート識別子として0の値を使用する必要があります。

2.2. Link Protection Type

2.2. リンク保護タイプ

The Link Protection Type represents the protection capability that exists for a link. It is desirable to carry this information so that it may be used by the path computation algorithm to set up LSPs with appropriate protection characteristics. This information is organized in a hierarchy where typically the minimum acceptable protection is specified at path instantiation and a path selection technique is used to find a path that satisfies at least the minimum acceptable protection. Protection schemes are presented in order from lowest to highest protection.

リンク保護タイプは、リンクに存在する保護機能を表します。適切な保護特性を備えたLSPをセットアップするために、パス計算アルゴリズムによって使用できるように、この情報を携帯することが望ましいです。この情報は、通常、パスインスタンス化で最小許容保護が指定され、少なくとも最小許容保護を満たすパスを見つけるためにパス選択手法が使用される階層で編成されます。保護スキームは、最低から最高の保護まで順番に提示されます。

This document defines the following protection capabilities:

このドキュメントは、次の保護機能を定義しています。

Extra Traffic If the link is of type Extra Traffic, it means that the link is protecting another link or links. The LSPs on a link of this type will be lost if any of the links it is protecting fail.

追加のトラフィックリンクがタイプの追加トラフィックの場合、リンクが別のリンクまたはリンクを保護していることを意味します。このタイプのリンク上のLSPは、失敗を保護しているリンクのいずれかが失われます。

Unprotected If the link is of type Unprotected, it means that there is no other link protecting this link. The LSPs on a link of this type will be lost if the link fails.

保護されていないリンクが保護されていないタイプの場合、このリンクを保護する他のリンクがないことを意味します。このタイプのリンク上のLSPは、リンクが故障した場合に失われます。

Shared If the link is of type Shared, it means that there are one or more disjoint links of type Extra Traffic that are protecting this link. These Extra Traffic links are shared between one or more links of type Shared.

リンクが共有されている場合、共有すると、このリンクを保護しているタイプの余分なトラフィックの1つ以上のバラバラリンクがあることを意味します。これらの追加のトラフィックリンクは、共有されたタイプの1つ以上のリンク間で共有されます。

Dedicated 1:1 If the link is of type Dedicated 1:1, it means that there is one dedicated disjoint link of type Extra Traffic that is protecting this link.

専用の1：1リンクが専用のタイプの1：1である場合、このリンクを保護しているタイプの追加トラフィックの専用の分離リンクが1つあることを意味します。

Dedicated 1+1 If the link is of type Dedicated 1+1, it means that a dedicated disjoint link is protecting this link. However, the protecting link is not advertised in the link state database and is therefore not available for the routing of LSPs.

専用1 1リンクが専用のタイプの1 1である場合、それは専用の団体リンクがこのリンクを保護していることを意味します。ただし、保護リンクはリンク状態データベースに宣伝されていないため、LSPのルーティングには使用できません。

Enhanced If the link is of type Enhanced, it means that a protection scheme that is more reliable than Dedicated 1+1, e.g., 4 fiber BLSR/MS-SPRING, is being used to protect this link.

リンクがタイプが強化されている場合、拡張された場合、専用の1 1、たとえば4ファイバーBLSR/MSスプリングよりも信頼性が高い保護スキームがこのリンクを保護するために使用されていることを意味します。

The Link Protection Type is optional, and if a Link State Advertisement doesn't carry this information, then the Link Protection Type is unknown.

リンク保護タイプはオプションであり、リンク状態広告がこの情報を伝えない場合、リンク保護タイプは不明です。

2.3. Shared Risk Link Group Information

2.3. 共有リスクリンクグループ情報

A set of links may constitute a 'shared risk link group' (SRLG) if they share a resource whose failure may affect all links in the set. For example, two fibers in the same conduit would be in the same SRLG. A link may belong to multiple SRLGs. Thus the SRLG Information describes a list of SRLGs that the link belongs to. An SRLG is identified by a 32 bit number that is unique within an IGP domain. The SRLG Information is an unordered list of SRLGs that the link belongs to.

一連のリンクは、セット内のすべてのリンクに障害が影響する可能性のあるリソースを共有する場合、「共有リスクリンクグループ」（SRLG）を構成する場合があります。たとえば、同じ導管にある2つの繊維が同じSRLGに含まれます。リンクは複数のSRLGに属する場合があります。したがって、SRLG情報は、リンクが属するSRLGのリストを記述します。SRLGは、IGPドメイン内で一意の32ビット数で識別されます。SRLG情報は、リンクが属するSRLGの順序付けられていないリストです。

The SRLG of a LSP is the union of the SRLGs of the links in the LSP. The SRLG of a bundled link is the union of the SRLGs of all the component links.

LSPのSRLGは、LSPのリンクのSRLGの結合です。バンドルされたリンクのSRLGは、すべてのコンポーネントリンクのSRLGの結合です。

If an LSR is required to have multiple diversely routed LSPs to another LSR, the path computation should attempt to route the paths so that they do not have any links in common, and such that the path SRLGs are disjoint.

LSRが複数のダイバーリールーティングLSPを別のLSRに配置する必要がある場合、パス計算は、共通のリンクがないようにパスをルーティングしようとする必要があります。

The SRLG Information may start with a configured value, in which case it does not change over time, unless reconfigured.

SRLG情報は、構成された値から始まる場合があります。その場合、再構成されない限り、時間の経過とともに変化しません。

The SRLG Information is optional and if a Link State Advertisement doesn't carry the SRLG Information, then it means that SRLG of that link is unknown.

SRLG情報はオプションであり、リンク状態広告がSRLG情報を運ばない場合、そのリンクのSRLGが不明であることを意味します。

2.4. Interface Switching Capability Descriptor

2.4. インターフェイススイッチング機能記述子

In the context of this document we say that a link is connected to a node by an interface. In the context of GMPLS interfaces may have different switching capabilities. For example an interface that connects a given link to a node may not be able to switch individual packets, but it may be able to switch channels within an SDH payload. Interfaces at each end of a link need not have the same switching capabilities. Interfaces on the same node need not have the same switching capabilities.

このドキュメントのコンテキストでは、リンクはインターフェイスによってノードに接続されていると言います。GMPLSのコンテキストでは、インターフェイスには異なるスイッチング機能がある場合があります。たとえば、特定のリンクをノードに接続するインターフェイスは、個々のパケットを切り替えることができない場合がありますが、SDHペイロード内のチャネルを切り替えることができる場合があります。リンクの両端にあるインターフェイスには、同じスイッチング機能が必要です。同じノード上のインターフェイスには、同じスイッチング機能が必要です。

The Interface Switching Capability Descriptor describes switching capability of an interface. For bi-directional links, the switching capabilities of an interface are defined to be the same in either direction. I.e., for data entering the node through that interface and for data leaving the node through that interface.

インターフェイススイッチング機能記述子は、インターフェイスのスイッチング機能を説明します。双方向リンクの場合、インターフェイスのスイッチング機能は、どちらの方向でも同じであると定義されます。つまり、そのインターフェイスを介してノードを入力するデータ、およびそのインターフェイスを介してノードを離れるデータの場合。

A Link State Advertisement of a link carries the Interface Switching Capability Descriptor(s) only of the near end (the end incumbent on the LSR originating the advertisement).

リンクのリンク状態広告は、インターフェイススイッチング機能記述子のみを伴います（s）は、端が近い端のみです（広告を発信するLSRの末端）。

An LSR performing path computation uses the Link State Database to determine whether a link is unidirectional or bidirectional.

LSRを実行するパス計算を実行すると、リンク状態データベースを使用して、リンクが単方向か双方向かを判断します。

For a bidirectional link the LSR uses its Link State Database to determine the Interface Switching Capability Descriptor(s) of the far-end of the link, as bidirectional links with different Interface Switching Capabilities at its two ends are allowed.

双方向リンクの場合、LSRはリンク状態データベースを使用して、リンクの遠端のインターフェイススイッチング機能記述子を決定します。

For a unidirectional link it is assumed that the Interface Switching Capability Descriptor at the far-end of the link is the same as at the near-end. Thus, an unidirectional link is required to have the same interface switching capabilities at both ends. This seems a reasonable assumption given that unidirectional links arise only with packet forwarding adjacencies and for these both ends belong to the same level of the PSC hierarchy.

一方向のリンクの場合、リンクの遠端にあるインターフェイススイッチング機能記述子は、ニアエンドと同じであると想定されています。したがって、両端に同じインターフェイススイッチング機能を持つために、単方向リンクが必要です。これは、単方向リンクがパケット転送隣接によってのみ発生することを考えると、合理的な仮定のようであり、これらの両端は同じレベルのPSC階層に属します。

This document defines the following Interface Switching Capabilities:

このドキュメントでは、次のインターフェイススイッチング機能を定義します。

Packet-Switch Capable-1 (PSC-1) Packet-Switch Capable-2 (PSC-2) Packet-Switch Capable-3 (PSC-3) Packet-Switch Capable-4 (PSC-4) Layer-2 Switch Capable (L2SC) Time-Division-Multiplex Capable (TDM) Lambda-Switch Capable (LSC) Fiber-Switch Capable (FSC)

Packet-Switch Capable-1（PSC-1）Packet-Switch Capable-2（PSC-2）Packet-Switch Capable-3（PSC-3）Packet-Switch Capable-4（PSC-4）レイヤー-2スイッチ対応（L2SC）TIME-DIVISION-MULTIPLEX対応（TDM）Lambda-Switch Capable（LSC）Fiber-Switch Capable（FSC）

If there is no Interface Switching Capability Descriptor for an interface, the interface is assumed to be packet-switch capable (PSC-1).

インターフェイスのインターフェイススイッチング機能記述子がない場合、インターフェイスはパケットスイッチ対応（PSC-1）であると想定されます。

Interface Switching Capability Descriptors present a new constraint for LSP path computation.

インターフェイススイッチング機能記述子は、LSPパス計算の新しい制約を提示します。

Irrespective of a particular Interface Switching Capability, the Interface Switching Capability Descriptor always includes information about the encoding supported by an interface. The defined encodings are the same as LSP Encoding as defined in [GMPLS-SIG].

特定のインターフェイススイッチング機能に関係なく、インターフェイススイッチング機能記述子には、常にインターフェイスでサポートされているエンコードに関する情報が含まれています。定義されたエンコーディングは、[GMPLS-SIG]で定義されているLSPエンコードと同じです。

An interface may have more than one Interface Switching Capability Descriptor. This is used to handle interfaces that support multiple switching capabilities, for interfaces that have Max LSP Bandwidth values that differ by priority level, and for interfaces that support discrete bandwidths.

インターフェイスには、複数のインターフェイススイッチング機能記述子がある場合があります。これは、複数のスイッチング機能をサポートするインターフェイス、優先度レベルによって異なる最大LSP帯域幅値を持つインターフェイス、および個別の帯域幅をサポートするインターフェイスの処理に使用されます。

Depending on a particular Interface Switching Capability, the Interface Switching Capability Descriptor may include additional information, as specified below.

特定のインターフェイススイッチング機能に応じて、以下に指定するように、インターフェイススイッチング機能記述子には追加情報が含まれる場合があります。

2.4.1. Layer-2 Switch Capable

2.4.1. レイヤー-2スイッチ対応

If an interface is of type L2SC, it means that the node receiving data over this interface can switch the received frames based on the layer 2 address. For example, an interface associated with a link terminating on an ATM switch would be considered L2SC.

インターフェイスがタイプL2SCである場合、このインターフェイス上でデータを受信するノードがレイヤー2アドレスに基づいて受信したフレームを切り替えることができることを意味します。たとえば、ATMスイッチで終了するリンクに関連付けられたインターフェイスは、L2SCと見なされます。

2.4.2. Packet-Switch Capable

2.4.2. パケットスイッチ対応

If an interface is of type PSC-1 through PSC-4, it means that the node receiving data over this interface can switch the received data on a packet-by-packet basis, based on the label carried in the "shim" header [RFC3032]. The various levels of PSC establish a hierarchy of LSPs tunneled within LSPs.

インターフェイスがPSC-4を介してタイプPSC-1である場合、このインターフェイスを介してデータを受信するノードが、「シム」ヘッダーに掲載されたラベルに基づいて、受信したデータをパケットごとに切り替えることができることを意味します[RFC3032]。PSCのさまざまなレベルは、LSP内でトンネルされたLSPの階層を確立します。

For Packet-Switch Capable interfaces the additional information includes Maximum LSP Bandwidth, Minimum LSP Bandwidth, and interface MTU.

パケットスイッチ対応インターフェイスの場合、追加情報には、最大LSP帯域幅、最小LSP帯域幅、およびインターフェイスMTUが含まれます。

For a simple (unbundled) link, the Maximum LSP Bandwidth at priority p is defined to be the smaller of the unreserved bandwidth at priority p and a "Maximum LSP Size" parameter which is locally configured on the link, and whose default value is equal to the Max Link Bandwidth. Maximum LSP Bandwidth for a bundled link is defined in [LINK-BUNDLE].

単純な（バンドルされていない）リンクの場合、優先Pの最大LSP帯域幅は、優先Pの未自由な帯域幅の小さい方と、リンクで局所的に構成され、デフォルト値が等しい「最大LSPサイズ」パラメーターであると定義されています。最大リンク帯域幅へ。バンドルされたリンクの最大LSP帯域幅は、[Link-Bundle]で定義されています。

The Maximum LSP Bandwidth takes the place of the Maximum Link Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum Link Bandwidth is a single fixed value (usually simply the link capacity), Maximum LSP Bandwidth is carried per priority, and may vary as LSPs are set up and torn down.

最大LSP帯域幅は、最大リンク帯域幅（[ISIS-TE]、[OSPF-TE]）に取って代わります。ただし、最大リンク帯域幅は単一の固定値（通常はリンク容量）ですが、最大LSP帯域幅は優先度ごとに運ばれ、LSPがセットアップおよび破壊されると異なる場合があります。

Although Maximum Link Bandwidth is to be deprecated, for backward compatibility, one MAY set the Maximum Link Bandwidth to the Maximum LSP Bandwidth at priority 7.

最大リンク帯域幅は非推奨ですが、後方互換性のために、最大リンク帯域幅を優先度7の最大LSP帯域幅に設定することができます。

The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP could reserve.

最小LSP帯域幅は、LSPが予約できる最小帯域幅を指定します。

Typical values for the Minimum LSP Bandwidth and for the Maximum LSP Bandwidth are enumerated in [GMPLS-SIG].

[GMPLS-SIG]では、最小LSP帯域幅と最大LSP帯域幅の典型的な値が列挙されています。

On a PSC interface that supports Standard SDH encoding, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p.

標準のSDHエンコーディングをサポートするPSCインターフェイスでは、優先PのLSPは、SDH階層のブランチによって許可された帯域幅を予約できます。葉と分岐の根は、最小LSP帯域幅と最大LSP帯域幅によって定義されます。優先P。

On a PSC interface that supports Arbitrary SDH encoding, an LSP at priority p could reserve any bandwidth between the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p, provided that the bandwidth reserved by the LSP is a multiple of the Minimum LSP Bandwidth.

任意のSDHエンコーディングをサポートするPSCインターフェイスでは、優先PのLSPは、LSPの最小LSP帯域幅と優先Pの最大LSP帯域幅の間の帯域幅を留保できます。

The Interface MTU is the maximum size of a packet that can be transmitted on this interface without being fragmented.

インターフェイスMTUは、断片化せずにこのインターフェイスに送信できるパケットの最大サイズです。

2.4.3. Time-Division Multiplex Capable

2.4.3. 時間分割マルチプレックス対応

If an interface is of type TDM, it means that the node receiving data over this interface can multiplex or demultiplex channels within an SDH payload.

インターフェイスがタイプTDMの場合、このインターフェイスでデータを受信するノードがSDHペイロード内のマルチプレックスまたはDemultiplexチャネルができることを意味します。

For Time-Division Multiplex Capable interfaces the additional information includes Maximum LSP Bandwidth, the information on whether the interface supports Standard or Arbitrary SDH, and Minimum LSP Bandwidth.

時間分割マルチプレックス対応インターフェースの場合、追加情報には、最大LSP帯域幅、インターフェイスが標準SDHまたは任意のSDHをサポートするか、最小LSP帯域幅をサポートするかに関する情報が含まれます。

For a simple (unbundled) link the Maximum LSP Bandwidth at priority p is defined as the maximum bandwidth an LSP at priority p could reserve. Maximum LSP Bandwidth for a bundled link is defined in [LINK-BUNDLE].

Aの場合、単純な（バンドルされていない）リンクは、優先Pの最大LSP帯域幅は、優先PのLSPが予約できる最大帯域幅として定義されます。バンドルされたリンクの最大LSP帯域幅は、[Link-Bundle]で定義されています。

The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP could reserve.

最小LSP帯域幅は、LSPが予約できる最小帯域幅を指定します。

Typical values for the Minimum LSP Bandwidth and for the Maximum LSP Bandwidth are enumerated in [GMPLS-SIG].

[GMPLS-SIG]では、最小LSP帯域幅と最大LSP帯域幅の典型的な値が列挙されています。

On an interface having Standard SDH multiplexing, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p.

標準のSDH多重化を備えたインターフェイスでは、優先PのLSPはSDH階層の分岐で許可された帯域幅を予約できます。葉と分岐の根は、最小LSP帯域幅と優先度Pの最大LSP帯域幅によって定義されます。。

On an interface having Arbitrary SDH multiplexing, an LSP at priority p could reserve any bandwidth between the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p, provided that the bandwidth reserved by the LSP is a multiple of the Minimum LSP Bandwidth.

任意のSDH多重化を備えたインターフェイスでは、優先PのLSPは、LSPによって予約されている帯域幅が最小LSP帯域幅の倍数である場合、最小LSP帯域幅と優先Pの最大LSP帯域幅の間の帯域幅を留保できます。

Interface Switching Capability Descriptor for the interfaces that support sub VC-3 may include additional information. The nature and the encoding of such information is outside the scope of this document.

サブVC-3をサポートするインターフェイスのインターフェイススイッチング機能記述子には追加情報が含まれる場合があります。このような情報の性質とエンコードは、このドキュメントの範囲外です。

A way to handle the case where an interface supports multiple branches of the SDH multiplexing hierarchy, multiple Interface Switching Capability Descriptors would be advertised, one per branch. For example, if an interface supports VC-11 and VC-12 (which are not part of same branch of SDH multiplexing tree), then it could advertise two descriptors, one for each one.

インターフェイスがSDHマルチプレックス階層の複数のブランチをサポートするケースを処理する方法は、1つのブランチごとに、複数のインターフェイススイッチング機能記述子が宣伝されます。たとえば、インターフェイスがVC-11とVC-12（SDHマルチプレックスツリーの同じブランチの一部ではない）をサポートする場合、それぞれに1つの記述子を宣伝できます。

2.4.4. Lambda-Switch Capable

2.4.4. ラムダスイッチ能力

If an interface is of type LSC, it means that the node receiving data over this interface can recognize and switch individual lambdas within the interface. An interface that allows only one lambda per interface, and switches just that lambda is of type LSC.

インターフェイスがタイプLSCである場合、このインターフェイス上でデータを受信するノードがインターフェイス内の個々のラムダを認識して切り替えることができることを意味します。インターフェイスごとに1つのラムダのみを許可し、ラムダがタイプLSCであることを切り替えるインターフェイス。

The additional information includes Reservable Bandwidth per priority, which specifies the bandwidth of an LSP that could be supported by the interface at a given priority number.

追加情報には、優先度ごとに予約可能な帯域幅が含まれており、特定の優先順位番号でインターフェイスによってサポートできるLSPの帯域幅を指定します。

A way to handle the case of multiple data rates or multiple encodings within a single TE Link, multiple Interface Switching Capability Descriptors would be advertised, one per supported data rate and encoding combination. For example, an LSC interface could support the establishment of LSC LSPs at both STM-16 and STM-64 data rates.

単一のTEリンク内の複数のデータレートまたは複数のエンコーディングのケースを処理する方法は、サポートされているデータレートとエンコーディングの組み合わせごとに、複数のインターフェイススイッチング機能記述子が宣伝されます。たとえば、LSCインターフェイスは、STM-16およびSTM-64データレートの両方でLSC LSPの確立をサポートできます。

2.4.5. Fiber-Switch Capable

2.4.5. 繊維スイッチ対応

If an interface is of type FSC, it means that the node receiving data over this interface can switch the entire contents to another interface (without distinguishing lambdas, channels or packets). I.e., an interface of type FSC switches at the granularity of an entire interface, and can not extract individual lambdas within the interface. An interface of type FSC can not restrict itself to just one lambda.

インターフェイスがタイプFSCの場合、このインターフェイスを介してデータを受信するノードがコンテンツ全体を別のインターフェイスに切り替えることができることを意味します（ラムダ、チャネル、またはパケットを区別せずに）。つまり、インターフェイス全体の粒度でタイプFSCスイッチのインターフェイスであり、インターフェイス内の個々のラムダを抽出することはできません。タイプFSCのインターフェイスは、1つのラムダだけに制限することはできません。

2.4.6. Multiple Switching Capabilities per Interface

2.4.6. インターフェイスごとの複数のスイッチング機能

An interface that connects a link to an LSR may support not one, but several Interface Switching Capabilities. For example, consider a fiber link carrying a set of lambdas that terminates on an LSR interface that could either cross-connect one of these lambdas to some other outgoing optical channel, or could terminate the lambda, and extract (demultiplex) data from that lambda using TDM, and then cross-connect these TDM channels to some outgoing TDM channels. To support this a Link State Advertisement may carry a list of Interface Switching Capabilities Descriptors.

LSRへのリンクを接続するインターフェイスは、1つではなくいくつかのインターフェイススイッチング機能をサポートする場合があります。たとえば、これらのラムダの1つを他の発信光チャネルとクロス接続できるか、ラムダを終了し、そのラムダから抽出（Demultiplex）データを終了する可能性のあるLSRインターフェイスで終了するラムダのセットを運ぶ繊維リンクを検討してください。TDMを使用して、これらのTDMチャネルをいくつかの発信TDMチャネルにクロス接続します。これをサポートするために、リンク状態広告には、インターフェイススイッチング機能の記述子のリストが付いています。

2.4.7. Interface Switching Capabilities and Labels

2.4.7. インターフェイススイッチング機能とラベル

Depicting a TE link as a tuple that contains Interface Switching Capabilities at both ends of the link, some examples links may be:

TEリンクをリンクの両端にインターフェイススイッチング機能を含むタプルとして描写すると、リンクのいくつかは次のとおりです。

[PSC, PSC] - a link between two packet LSRs [TDM, TDM] - a link between two Digital Cross Connects [LSC, LSC] - a link between two OXCs [PSC, TDM] - a link between a packet LSR and Digital Cross Connect [PSC, LSC] - a link between a packet LSR and an OXC [TDM, LSC] - a link between a Digital Cross Connect and an OXC

[PSC、PSC] - 2つのパケットLSRS [TDM、TDM]間のリンク - 2つのデジタルクロス接続[LSC、LSC] - 2つのOXCS [PSC、TDM]間のリンク - パケットLSRとデジタル間のリンクCross Connect [PSC、LSC] - パケットLSRとOXC [TDM、LSC]の間のリンク - デジタルクロスコネクトとOXCの間のリンク

Both ends of a given TE link has to use the same way of carrying label information over that link. Carrying label information on a given TE link depends on the Interface Switching Capability at both ends of the link, and is determined as follows:

特定のTEリンクの両端は、そのリンク上にラベル情報を運ぶのと同じ方法を使用する必要があります。特定のTEリンクにラベル情報をキャリングすることは、リンクの両端でのインターフェイススイッチング機能によって異なり、次のように決定されます。

      [PSC, PSC] - label is carried in the "shim" header [RFC3032]
      [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [LSC, LSC] - label represents a lambda
      [FSC, FSC] - label represents a port on an OXC
      [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
      [PSC, LSC] - label represents a lambda
      [PSC, FSC] - label represents a port
      [TDM, LSC] - label represents a lambda
      [TDM, FSC] - label represents a port
      [LSC, FSC] - label represents a port

2.4.8. Other Issues

2.4.8. その他の問題

It is possible that Interface Switching Capability Descriptor will change over time, reflecting the allocation/deallocation of LSPs. For example, assume that VC-3, VC-4, VC-4-4c, VC-4-16c and VC-4-64c LSPs can be established on a STM-64 interface whose Encoding Type is SDH. Thus, initially in the Interface Switching Capability Descriptor the Minimum LSP Bandwidth is set to VC-3, and Maximum LSP Bandwidth is set to STM-64 for all priorities. As soon as an LSP of VC-3 size at priority 1 is established on the interface, it is no longer capable of VC-4-64c for all but LSPs at priority 0. Therefore, the node advertises a modified Interface Switching Capability Descriptor indicating that the Maximum LSP Bandwidth is no longer STM-64, but STM-16 for all but priority 0 (at priority 0 the Maximum LSP Bandwidth is still STM-64). If subsequently there is another VC-3 LSP, there is no change in the Interface Switching Capability Descriptor. The Descriptor remains the same until the node can no longer establish a VC-4-16c LSP over the interface (which means that at this point more than 144 time slots are taken by LSPs on the interface). Once this happened, the Descriptor is modified again, and the modified Descriptor is advertised to other nodes.

LSPの割り当て/取引を反映して、インターフェイススイッチング機能記述子が時間とともに変化する可能性があります。たとえば、VC-3、VC-4、VC-4-4C、VC-4-16C、およびVC-4-64C LSPは、エンコードタイプがSDHであるSTM-64インターフェイスで確立できると仮定します。したがって、最初はインターフェイススイッチング機能記述子では、最小LSP帯域幅がVC-3に設定され、最大LSP帯域幅はすべての優先順位でSTM-64に設定されます。優先度1のVC-3サイズのLSPがインターフェイスに確立されるとすぐに、優先度0でLSPを除くすべてのすべてのVC-4-64Cができなくなります。最大LSP帯域幅はもはやSTM-64ではなく、優先度0を除くすべてのSTM-16（優先度0では、最大LSP帯域幅はまだSTM-64です）。その後、別のVC-3 LSPがある場合、インターフェイススイッチング機能記述子に変更はありません。記述子は、ノードがインターフェイス上でVC-4-16C LSPを確立できなくなるまで同じままです（つまり、この時点で144を超えるタイムスロットがインターフェイス上のLSPによって撮影されます）。これが発生すると、記述子が再び変更され、変更された記述子が他のノードに宣伝されます。

2.5. Bandwidth Encoding

2.5. 帯域幅エンコーディング

Encoding in IEEE floating point format [IEEE] of the discrete values that could be used to identify Unreserved bandwidth, Maximum LSP bandwidth and Minimum LSP bandwidth is described in Section 3.1.2 of [GMPLS-SIG].

保証されていない帯域幅、最大LSP帯域幅、最小LSP帯域幅を識別するために使用できる離散値のIEEEフローティングポイント形式[IEEE]でエンコードすることは、[GMPLS-SIG]のセクション3.1.2で説明されています。

3. Examples of Interface Switching Capability Descriptor

3. インターフェイススイッチング機能記述子の例

3.1. STM-16 POS Interface on a LSR

3.1. LSR上のSTM-16 POSインターフェイス

Interface Switching Capability Descriptor: Interface Switching Capability = PSC-1 Encoding = SDH Max LSP Bandwidth[p] = 2.5 Gbps, for all p

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= PSC-1エンコーディング= SDH最大LSP帯域幅[P] = 2.5 GBPS、すべてのPについて

If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.

両端のそのようなインターフェイスを使用した複数のリンクを1つのリンクとして宣伝する場合、リンクバンドリング手法を使用する必要があります。

3.2. GigE Packet Interface on a LSR

3.2. LSRのGigeパケットインターフェイス

Interface Switching Capability Descriptor: Interface Switching Capability = PSC-1 Encoding = Ethernet 802.3 Max LSP Bandwidth[p] = 1.0 Gbps, for all p

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= PSC-1エンコーディング=イーサネット802.3最大LSP帯域幅[P] = 1.0 Gbps、すべてのPについて

If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.

3.3. STM-64 SDH Interface on a Digital Cross Connect with Standard SDH

3.3. Digital Cross上のSTM-64 SDHインターフェイス標準SDHと接続する

Consider a branch of SDH multiplexing tree : VC-3, VC-4, VC-4-4c, VC-4-16c, VC-4-64c. If it is possible to establish all these connections on a STM-64 interface, the Interface Switching Capability Descriptor of that interface can be advertised as follows:

SDH多重化ツリーの分岐：VC-3、VC-4、VC-4-4C、VC-4-16C、VC-4-64Cを考えてみましょう。STM-64インターフェイスでこれらすべての接続を確立できる場合、そのインターフェイスのインターフェイススイッチング機能記述子は次のように宣伝できます。

Interface Switching Capability Descriptor: Interface Switching Capability = TDM [Standard SDH] Encoding = SDH Min LSP Bandwidth = VC-3 Max LSP Bandwidth[p] = STM-64, for all p

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= TDM [標準SDH]エンコーディング= SDH MIN LSP BANDWIDTH = VC-3 MAX LSP BANDWIDTH [P] = STM-64、すべてのpの場合

If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.

3.4. STM-64 SDH Interface on a Digital Cross Connect with Two Types of SDH Multiplexing Hierarchy Supported

3.4. デジタルクロス上のSTM-64 SDHインターフェース2種類のSDH多重階層をサポートする2種類のSDH

Interface Switching Capability Descriptor 1: Interface Switching Capability = TDM [Standard SDH] Encoding = SDH Min LSP Bandwidth = VC-3 Max LSP Bandwidth[p] = STM-64, for all p

インターフェイススイッチング機能記述子1：インターフェイススイッチング機能= TDM [標準SDH]エンコーディング= SDH MIN LSP BANDWIDTH = VC-3 MAX LSP BANDWIDTH [P] = STM-64、すべてのPの場合

Interface Switching Capability Descriptor 2: Interface Switching Capability = TDM [Arbitrary SDH] Encoding = SDH Min LSP Bandwidth = VC-4 Max LSP Bandwidth[p] = STM-64, for all p

インターフェイススイッチング機能記述子2：インターフェイススイッチング機能= TDM [任意のSDH]エンコード= SDH MIN LSP BANDWIDTH = VC-4 MAX LSP BANDWIDWID [P] = STM-64、すべてのpの場合

If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.

3.5. Interface on an Opaque OXC (SDH Framed) with Support for One Lambda per Port/Interface

3.5. ポート/インターフェイスごとに1つのラムダをサポートした不透明なOXC（SDHフレーム）のインターフェイス

An "opaque OXC" is considered operationally an OXC, as the whole lambda (carrying the SDH line) is switched transparently without further multiplexing/demultiplexing, and either none of the SDH overhead bytes, or at least the important ones are not changed.

「不透明なOXC」は、ラムダ全体（SDHラインを運ぶ）がさらに多重化/非脱直せずに透過的に切り替えられ、SDHオーバーヘッドバイト、または少なくとも重要なものは変更されないため、「不透明なOXC」はOXCと見なされます。

An interface on an opaque OXC handles a single wavelength, and cannot switch multiple wavelengths as a whole. Thus, an interface on an opaque OXC is always LSC, and not FSC, irrespective of whether there is DWDM external to it.

不透明なOXCのインターフェイスは、単一の波長を処理し、複数の波長を全体として切り替えることはできません。したがって、不透明なOXC上のインターフェイスは常にLSCであり、FSCではなく、外部のDWDMがあるかどうかに関係なく。

Note that if there is external DWDM, then the framing understood by the DWDM must be same as that understood by the OXC.

外部DWDMがある場合、DWDMによって理解されるフレーミングは、OXCが理解したものと同じでなければならないことに注意してください。

A TE link is a group of one or more interfaces on an OXC. All interfaces on a given OXC are required to have identifiers unique to that OXC, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).

TEリンクは、OXC上の1つ以上のインターフェイスのグループです。特定のOXC上のすべてのインターフェイスは、そのOXCに固有の識別子を持つ必要があり、これらの識別子はラベルとして使用されます（[GMPLS-SIG]の3.2.1.1を参照）。

The following is an example of an interface switching capability descriptor on an SDH framed opaque OXC:

以下は、SDHフレームの不透明なOXCのインターフェイススイッチング機能記述子の例です。

Interface Switching Capability Descriptor: Interface Switching Capability = LSC Encoding = SDH Reservable Bandwidth = Determined by SDH Framer (say STM-64)

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= LSCエンコーディング= SDH予約可能帯域幅= SDH Framerによって決定（STM-64など）

3.6. Interface on a Transparent OXC (PXC) with External DWDM That Understands SDH Framing

3.6. SDHフレーミングを理解している外部DWDMを使用した透明なOXC（PXC）のインターフェイス

This example assumes that DWDM and PXC are connected in such a way that each interface (port) on the PXC handles just a single wavelength. Thus, even if in principle an interface on the PXC could switch multiple wavelengths as a whole, in this particular case an interface on the PXC is considered LSC, and not FSC.

この例では、PXC上の各インターフェイス（ポート）が単一の波長を処理するように、DWDMとPXCが接続されていることを前提としています。したがって、原則としてPXCのインターフェイスが複数の波長を全体として切り替えることができる場合でも、この特定の場合、PXCのインターフェイスはFSCではなくLSCと見なされます。

                     _______
                    |       |
               /|___|       |
              | |___|  PXC  |
      ========| |___|       |
              | |___|       |
               \|   |_______|
             DWDM
         (SDH framed)

A TE link is a group of one or more interfaces on the PXC. All interfaces on a given PXC are required to have identifiers unique to that PXC, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).

TEリンクは、PXC上の1つ以上のインターフェイスのグループです。特定のPXC上のすべてのインターフェイスは、そのPXCに固有の識別子を持つ必要があり、これらの識別子はラベルとして使用されます（[GMPLS-SIG]の3.2.1.1を参照）。

The following is an example of an interface switching capability descriptor on a transparent OXC (PXC) with external DWDM that understands SDH framing:

以下は、SDHフレーミングを理解している外部DWDMを備えた透明なOXC（PXC）のインターフェイススイッチング機能記述子の例です。

Interface Switching Capability Descriptor: Interface Switching Capability = LSC Encoding = SDH (comes from DWDM) Reservable Bandwidth = Determined by DWDM (say STM-64)

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= LSCエンコード= SDH（DWDMから来る）予約可能帯域幅= DWDMによって決定された（STM-64など）

3.7. Interface on a Transparent OXC (PXC) with External DWDM That Is Transparent to Bit-Rate and Framing

3.7. ビットレートとフレーミングに対して透明な外部DWDMを使用した透明なOXC（PXC）のインターフェイス

                        _______
                       |       |
                  /|___|       |
                 | |___|  PXC  |
         ========| |___|       |
                 | |___|       |
                  \|   |_______|
                DWDM (transparent to bit-rate and framing)

The following is an example of an interface switching capability descriptor on a transparent OXC (PXC) with external DWDM that is transparent to bit-rate and framing:

以下は、ビットレートとフレーミングに対して透明な外部DWDMを備えた透明なOXC（PXC）のインターフェイススイッチング機能記述子の例です。

Interface Switching Capability Descriptor: Interface Switching Capability = LSC Encoding = Lambda (photonic) Reservable Bandwidth = Determined by optical technology limits

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= LSCエンコーディング= lambda（photonic）予約可能帯域幅=光学技術の制限によって決定

3.8. Interface on a PXC with No External DWDM

3.8. 外部DWDMのないPXC上のインターフェイス

The absence of DWDM in between two PXCs, implies that an interface is not limited to one wavelength. Thus, the interface is advertised as FSC.

2つのPXCの間にDWDMがないことは、インターフェイスが1つの波長に限定されないことを意味します。したがって、インターフェイスはFSCとして宣伝されます。

A TE link is a group of one or more interfaces on the PXC. All interfaces on a given PXC are required to have identifiers unique to that PXC, and these identifiers are used as port labels (see 3.2.1.1 of [GMPLS-SIG]).

TEリンクは、PXC上の1つ以上のインターフェイスのグループです。特定のPXC上のすべてのインターフェイスは、そのPXCに固有の識別子を持つ必要があり、これらの識別子はポートラベルとして使用されます（[GMPLS-SIG]の3.2.1.1を参照）。

Interface Switching Capability Descriptor: Interface Switching Capability = FSC Encoding = Lambda (photonic) Reservable Bandwidth = Determined by optical technology limits

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= FSCエンコーディング= lambda（photonic）予約可能帯域幅=光学技術の制限によって決定

Note that this example assumes that the PXC does not restrict each port to carry only one wavelength.

この例は、PXCが各ポートを1つの波長のみを運ぶように制限しないことを前提としていることに注意してください。

3.9. Interface on a OXC with Internal DWDM That Understands SDH Framing

3.9. SDHフレーミングを理解している内部DWDMを使用したOXC上のインターフェイス

This example assumes that DWDM and OXC are connected in such a way that each interface on the OXC handles multiple wavelengths individually. In this case an interface on the OXC is considered LSC, and not FSC.

この例では、DWDMとOXCは、OXC上の各インターフェイスが複数の波長を個別に処理するように接続されていることを前提としています。この場合、OXC上のインターフェイスはLSCと見なされ、FSCではなく。

                  _______
                 |       |
               /||       ||\
              | ||  OXC  || |
      ========| ||       || |====
              | ||       || |
               \||_______||/
             DWDM
         (SDH framed)

A TE link is a group of one or more of the interfaces on the OXC. All lambdas associated with a particular interface are required to have identifiers unique to that interface, and these identifiers are used as labels (see 3.2.1.1 of [GMPLS-SIG]).

リンクは、OXC上の1つ以上のインターフェイスのグループです。特定のインターフェイスに関連付けられたすべてのラムダは、そのインターフェイスに固有の識別子を持つ必要があり、これらの識別子はラベルとして使用されます（[gmpls-sig]の3.2.1.1を参照）。

The following is an example of an interface switching capability descriptor on an OXC with internal DWDM that understands SDH framing and supports discrete bandwidths:

以下は、SDHフレーミングを理解し、離散帯域幅をサポートする内部DWDMを備えたOXCのインターフェイススイッチング機能記述子の例です。

Interface Switching Capability Descriptor: Interface Switching Capability = LSC Encoding = SDH (comes from DWDM) Max LSP Bandwidth = Determined by DWDM (say STM-16)

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= LSCエンコード= SDH（DWDMから来る）最大LSP帯域幅= DWDMによって決定されます（STM-16など）

Interface Switching Capability = LSC Encoding = SDH (comes from DWDM) Max LSP Bandwidth = Determined by DWDM (say STM-64)

インターフェイススイッチング機能= LSCエンコード= SDH（DWDMから来る）最大LSP帯域幅= DWDMによって決定されます（STM-64など）

3.10. Interface on a OXC with Internal DWDM That Is Transparent to Bit-Rate and Framing

3.10. ビットレートとフレーミングに対して透明な内部DWDMを使用したOXCのインターフェイス

                         _______
                        |       |
                      /||       ||\
                     | ||  OXC  || |
             ========| ||       || |====
                     | ||       || |
                      \||_______||/
                    DWDM (transparent to bit-rate and framing)

The following is an example of an interface switching capability descriptor on an OXC with internal DWDM that is transparent to bit-rate and framing:

以下は、ビットレートとフレーミングに対して透明な内部DWDMを備えたOXC上のインターフェイススイッチング機能記述子の例です。

Interface Switching Capability Descriptor: Interface Switching Capability = LSC Encoding = Lambda (photonic) Max LSP Bandwidth = Determined by optical technology limits

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= LSCエンコード= lambda（photonic）max lsp帯域幅=光学技術の制限によって決定

4. Example of Interfaces That Support Multiple Switching Capabilities

4. 複数のスイッチング機能をサポートするインターフェイスの例

There can be many combinations possible, some are described below.

可能な多くの組み合わせがありますが、いくつかは以下に説明します。

4.1. Interface on a PXC+TDM Device with External DWDM

4.1. 外部DWDMを使用したPXC TDMデバイスのインターフェイス

As discussed earlier, the presence of the external DWDM limits that only one wavelength be on a port of the PXC. On such a port, the attached PXC+TDM device can do one of the following. The wavelength may be cross-connected by the PXC element to other out-bound optical channel, or the wavelength may be terminated as an SDH interface and SDH channels switched.

前述のように、外部DWDMの存在は、PXCのポートに1つの波長のみがあることを制限します。このようなポートでは、接続されたPXC TDMデバイスは次のいずれかを実行できます。波長は、PXC要素によって他のアウトバウンド光チャネルに相互接続されている場合があります。または、波長はSDHインターフェイスとSDHチャネルが切り替えられると終了する場合があります。

From a GMPLS perspective the PXC+TDM functionality is treated as a single interface. The interface is described using two Interface descriptors, one for the LSC and another for the TDM, with appropriate parameters. For example,

GMPLSの観点からは、PXC TDM機能は単一のインターフェイスとして扱われます。インターフェイスは、適切なパラメーターを使用して、2つのインターフェイス記述子を使用してLSC用、もう1つはTDM用に1つは使用されています。例えば、

Interface Switching Capability Descriptor: Interface Switching Capability = LSC Encoding = SDH (comes from WDM) Reservable Bandwidth = STM-64

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= LSCエンコード= SDH（WDMから来る）予約可能帯域幅= STM-64

and

とそして及びアンド並びに且つ兼又共それですると亦だからそれからはたまた

Interface Switching Capability Descriptor: Interface Switching Capability = TDM [Standard SDH] Encoding = SDH Min LSP Bandwidth = VC-3 Max LSP Bandwidth[p] = STM-64, for all p

4.2. Interface on an Opaque OXC+TDM Device with External DWDM

4.2. 外部DWDMを使用した不透明なOXC TDMデバイスのインターフェイス

An interface on an "opaque OXC+TDM" device would also be advertised as LSC+TDM much the same way as the previous case.

「不透明なOXC TDM」デバイスのインターフェイスは、以前のケースとほぼ同じ方法でLSC TDMとして宣伝されます。

4.3. Interface on a PXC+LSR Device with External DWDM

4.3. 外部DWDMを使用したPXC LSRデバイス上のインターフェイス

As discussed earlier, the presence of the external DWDM limits that only one wavelength be on a port of the PXC. On such a port, the attached PXC+LSR device can do one of the following. The wavelength may be cross-connected by the PXC element to other out-bound optical channel, or the wavelength may be terminated as a Packet interface and packets switched.

前述のように、外部DWDMの存在は、PXCのポートに1つの波長のみがあることを制限します。このようなポートでは、接続されたPXC LSRデバイスは次のいずれかを実行できます。波長は、PXC要素によって他のアウトバウンド光チャネルに相互接続されている場合があります。または、波長はパケットインターフェイスとして終了し、パケットが切り替えられます。

From a GMPLS perspective the PXC+LSR functionality is treated as a single interface. The interface is described using two Interface descriptors, one for the LSC and another for the PSC, with appropriate parameters. For example,

GMPLSの観点からは、PXC LSR機能は単一のインターフェイスとして扱われます。インターフェイスは、適切なパラメーターを備えた2つのインターフェイス記述子を使用して、1つはLSC用、もう1つはPSC用に記載されています。例えば、

Interface Switching Capability Descriptor: Interface Switching Capability = LSC Encoding = SDH (comes from WDM) Reservable Bandwidth = STM-64

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= LSCエンコード= SDH（WDMから来る）予約可能帯域幅= STM-64

and

とそして及びアンド並びに且つ兼又共それですると亦だからそれからはたまた

Interface Switching Capability Descriptor: Interface Switching Capability = PSC-1 Encoding = SDH Max LSP Bandwidth[p] = 10 Gbps, for all p

インターフェイススイッチング機能記述子：インターフェイススイッチング機能= PSC-1エンコーディング= SDH最大LSP帯域幅[P] = 10 Gbps、すべてのPについて

4.4. Interface on a TDM+LSR Device

4.4. TDM LSRデバイスのインターフェイス

On a TDM+LSR device that offers a channelized SDH interface the following may be possible:

チャネル化されたSDHインターフェイスを提供するTDM LSRデバイスでは、次のことが可能になる場合があります。

- A subset of the SDH channels may be uncommitted. That is, they are not currently in use and hence are available for allocation.

- SDHチャネルのサブセットはコミットされていない場合があります。つまり、それらは現在使用されていないため、割り当てに利用できます。

- A second subset of channels may already be committed for transit purposes. That is, they are already cross-connected by the SDH cross connect function to other out-bound channels and thus are not immediately available for allocation.

- チャネルの2番目のサブセットは、輸送目的で既にコミットされる場合があります。つまり、それらはすでにSDH Cross Connect関数によって他のアウトバウンドチャネルにクロス接続されているため、すぐに割り当てに使用できません。

- Another subset of channels could be in use as terminal channels. That is, they are already allocated by terminate on a packet interface and packets switched.

- チャネルの別のサブセットは、端子チャネルとして使用できます。つまり、それらはすでにパケットインターフェイスで終了することによって割り当てられ、パケットが切り替えられています。

From a GMPLS perspective the TDM+PSC functionality is treated as a single interface. The interface is described using two Interface descriptors, one for the TDM and another for the PSC, with appropriate parameters. For example,

GMPLSの観点からは、TDM PSC機能は単一のインターフェイスとして扱われます。インターフェイスは、適切なパラメーターを使用して、TDM用、もう1つはTDM用、もう1つはPSC用の2つのインターフェイス記述子を使用して説明されています。例えば、

Interface Switching Capability Descriptor: Interface Switching Capability = TDM [Standard SDH] Encoding = SDH Min LSP Bandwidth = VC-3 Max LSP Bandwidth[p] = STM-64, for all p

and

とそして及びアンド並びに且つ兼又共それですると亦だからそれからはたまた

Interface Switching Capability Descriptor: Interface Switching Capability = PSC-1 Encoding = SDH Max LSP Bandwidth[p] = 10 Gbps, for all p

5. Acknowledgements

5. 謝辞

The authors would like to thank Suresh Katukam, Jonathan Lang, Zhi-Wei Lin, and Quaizar Vohra for their comments and contributions to the document. Thanks too to Stephen Shew for the text regarding "Representing TE Link Capabilities".

著者は、文書へのコメントと貢献について、Suresh Katukam、Jonathan Lang、Zhi-Wei Lin、およびQuaizar Vohraに感謝したいと思います。「TEリンク機能を表す」に関するテキストについては、Stephen Shewにも感謝します。

6. Security Considerations

6. セキュリティに関する考慮事項

There are a number of security concerns in implementing the extensions proposed here, particularly since these extensions will potentially be used to control the underlying transport infrastructure. It is vital that there be secure and/or authenticated means of transferring this information among the entities that require its use.

特にこれらの拡張機能を使用して基礎となる輸送インフラストラクチャを制御するために使用される可能性があるため、ここで提案されている拡張機能を実装する際には、多くのセキュリティ上の懸念があります。この情報を使用する必要があるエンティティ間でこの情報を転送するための安全なおよび/または認証された手段があることが重要です。

While this document proposes extensions, it does not state how these extensions are implemented in routing protocols such as OSPF or IS-IS. The documents that do state how routing protocols implement these extensions [GMPLS-OSPF, GMPLS-ISIS] must also state how the information is to be secured.

このドキュメントは拡張機能を提案していますが、OSPFやIS-ISなどのルーティングプロトコルでこれらの拡張機能がどのように実装されているかは述べていません。ルーティングプロトコルがこれらの拡張機能[GMPLS-OSPF、GMPLS-ISIS]をどのように実装するかを述べているドキュメントには、情報の保護方法も記載する必要があります。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[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-SIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.

[GMPLS-SIG] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。

[GMPLS-SONET-SDH] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004.

[Gmpls-Sonet-SDH] Mannie、E。およびD. Papadimitriou、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）同期光学ネットワーク（SONET）および同期デジタル階層（SDH）コントロールの拡張式」、2004年10月、RFC 3946。

[IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593- 7653-8).

[IEEE] IEEE、「バイナリフローティングポイント算術のIEEE標準」、標準754-1985、1985（ISBN 1-5593- 7653-8）。

[LINK-BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

[Link-Bundle] Kompella、K.、Rekhter、Y.、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。

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

[LMP] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。

[LSP-HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE))", RFC 4206, October 2005.

[LSP-Hier] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE））を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。

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

[OSPF-TE] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、2003年9月。

[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月。

[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.

[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack Encoding」、RFC 3032、2001年1月。

7.2. Informative References

7.2. 参考引用

[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月。

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

[ISIS-TE] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年6月。

8. Contributors

8. 貢献者

Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138

Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose、CA 95138

   Phone: +1.408.972.3645
   EMail: abanerjee@calient.net

John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138

John Drake Calient Networks 5853 Rue Ferrari San Jose、CA 95138

Phone: (408) 972-3720 EMail: jdrake@calient.net

電話：（408）972-3720メール：jdrake@calient.net

Greg Bernstein Ciena Corporation 10480 Ridgeview Court Cupertino, CA 94014

Greg Bernstein Ciena Corporation 10480 Ridgeview Court Cupertino、CA 94014

Phone: (408) 366-4713 EMail: greg@ciena.com

電話：（408）366-4713メール：greg@ciena.com

Don Fedyk Nortel Networks Corp. 600 Technology Park Drive Billerica, MA 01821

Don Fedyk Nortel Networks Corp. 600 Technology Park Drive Billerica、MA 01821

Phone: +1-978-288-4506 EMail: dwfedyk@nortelnetworks.com Eric Mannie Libre Exaministe

電話：1-978-288-4506電子メール：dwfedyk@nortelnetworks.com eric mannie libre exaministe

   EMail: eric_mannie@hotmail.com

Debanjan Saha Tellium Optical Systems 2 Crescent Place P.O. Box 901 Ocean Port, NJ 07757

Debanjan Saha Tellium光システム2 Crescent Place P.O.ボックス901オーシャンポート、ニュージャージー07757

Phone: (732) 923-4264 EMail: dsaha@tellium.com

電話：（732）923-4264メール：dsaha@tellium.com

Vishal Sharma Metanoia, Inc. 335 Elan Village Lane, Unit 203 San Jose, CA 95134-2539

Vishal Sharma Metanoia、Inc。335 Elan Village Lane、Unit 203 San Jose、CA 95134-2539

   Phone: +1 408-943-1794
   EMail: v.sharma@ieee.org

Debashis Basak AcceLight Networks, 70 Abele Rd, Bldg 1200 Bridgeville PA 15017

Debashis Basak Accelight Networks、70 Abele Rd、Bldg 1200 Bridgeville PA 15017

   EMail: dbasak@accelight.com

Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102

Lou Berger Movaz Networks、Inc。7926 Jones Branch Drive Suite 615 McLean VA、22102

   EMail: lberger@movaz.com

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

Full Copyright Statement

完全な著作権声明

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