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)
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
抽象
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
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 [ISIS-TE], [OSPF-TE] required to support MPLS Traffic Engineering (TE).
この文書では、一般化マルチプロトコルラベルスイッチング（GMPLS）のリンク状態情報を運ぶの支援にルーティング拡張子を指定します。この文書では、ルーティング拡張[ISIS-TE]を高め、[OSPF-TE] MPLSトラフィックエンジニアリング（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リンクとして広告することができるので、再度、もはや通常のルーティング隣接し、TEリンクの一対一の関連がありません。
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特性を有する「論理」リンクです。リンクは、それがグループへの道を表すこと/経路計算の目的のために、およびGMPLSシグナリングによって制約SPFによって使用される情報の中に特定の物理的リソース（およびその特性）に関する情報をマッピングする意味で論理的です。このグループ化/マッピングは、リンクの両端で一貫して行う必要があります。 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リンクID、ラベル>の組み合わせは、十分ではありません。このような場合には、<TEリンク識別子、コンポーネントリンクID、ラベル>でリソースを識別することを可能にする[LINK-BUNDLE]を構築バンドルリンクを使用して処理されます。
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）、いくつかのプロトコルによって他の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の対の間のTEリンクは、これらの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（この手段は、helloパケットをルーティングすることができるが、helloパケットをルーティングに限定されるものではなく）その生存性を知ることができるいくつかの手段を持っている必要があります。 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のプロパティのセットを拡張し、また、光クロスコネクト（のOXC）間のリンクなどの非パケット交換リンクとTEのプロパティを関連付ける方法を言います。 [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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
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.
特定の適応でのLSP 1.必要性だけではなく、特定の帯域幅。光ネットワークのクライアントは、例えば、VC-3回路の特定の適応のための接続サービスを得ます。これは、特定の帯域幅を意味しますが、ペイロードがどのように構成されていないだけ。したがって、VC-3クライアントは、48.384メガビット/秒以上と予想される構造を持つ他の任意の提供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リンク（重複OC-192は、保護のために存在する）、1 + 1保護されている場合、その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.
そののOXC 5.異種ネットワークは、すべての層の同じセットをサポートしていません。 GMPLSネットワークでは、すべてのトランスポート層のネットワーク要素は、同一の層を支持することが期待されます。例えば、VC-11、VC-12、およびVC-3、およびのみVC-3およびVC-4をサポートすることができる他のものが存在し得るのみが可能なスイッチが存在してもよいです。ネットワーク要素は、特定の層を支持することができないにもかかわらず、他の場所で、ネットワーク内のネットワーク要素がサポートされていない層を使用することを可能にする適応を支援することができるかどうかを知ることができるはずです。それはVC-11パスは、VC-3リンク接続を介して構成することができることを知っていた場合、例えば、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リンク属性について以下の原則を使用する必要があります。
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.
本書は、単層のネットワークに適用される一般的な属性をキャプチャしますが、属性の層間の関係をキャプチャしません。この作品は、将来の文書に残されています。
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.
このようなのOXC、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.
1は、データトラフィックがIGPの宛先にBGPの宛先、および制御トラフィックに送信されることを前提とした場合、1は、BGPネクストホップ解決を制限することにより、コントロールプレーンからのデータトラフィックを除外することができます。 （のOXCは、BGPスピーカーではないことが想定される。）、ルータRは、BGPの目的地までのルートをインストールしようとしているD. RはそのIGPのルーティングテーブルにDのためのBGPネクストホップを検索すると仮定します。 [LSPを参照して（それがない場合は、インターフェースIと関連したそのリンクステートデータベース内のエントリを持っているかどうかを確認し、リンクが可能なパケットスイッチではないRは、ネクストホップへのパスは、インターフェースIのR以上であることを認める言います-HIER]）、Rは、そうでない場合、宛先Dの廃棄ルートをインストールし、Rは、（通常通り）Rは、それがパケット交換できないリンクがある場合にのみ、このチェックを行う必要があることをネクストホップ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.
制御チャネルからのデータトラフィックを除外するための他の技術が必要になる場合もあります。
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プロパティへの拡張を定義します。 ISISこの情報の符号化は[GMPLS-ISIS]で指定されています。 OSPFにおけるこの情報の符号化は[GMPLS-OSPF]で指定されています。
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.
LSRのAとB LSR A間（番号なし）リンクがそのリンクの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は、無数のTEリンクをアドバタイズする場合、具体的に、広告は、ローカルおよびリモートリンクの識別子の両方を運びます。 LSRは、そのリンクのリモート識別子を知らない場合、LSRは、リモートIDとして0の値を使用する必要があります。
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つまたは複数のリンクの間で共有されています。
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を捧げ、それは専用の互いに素なリンクがこのリンクを保護していることを意味します。しかし、保護リンクは、リンク状態データベースにアドバタイズされず、従って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.
拡張リンクは、タイプ拡張である場合、それは例えば、4ファイバBLSR / MS-SPRING、1 + 1専用よりも信頼性があると保護方式を意味し、このリンクを保護するために使用されています。
The Link Protection Type is optional, and if a Link State Advertisement doesn't carry this information, then the Link Protection Type is unknown.
リンク保護タイプはオプションで、リンクステートアドバタイズメントは、この情報を運ばない場合は、[リンク保護タイプは不明です。
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になります。リンクは、複数のSRLGsに属していてもよいです。したがって、SRLG情報は、リンクが属するSRLGsのリストを記述します。 SRLGは、IGPドメイン内で一意の32ビット番号によって識別されます。 SRLG情報は、リンクが属するSRLGsの順不同のリストです。
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内のリンクのSRLGsの労働組合です。束ねられたリンクのSRLGは、すべてのコンポーネントリンクのSRLGsの労働組合です。
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が他のLSRに複数の多様ルーティングされたLSPを持つ必要がある場合は、経路計算は、彼らが共通して任意のリンクを持っていないように、ルートのパスをしようとすると、パスのSRLGsが互いに素であるようにすべきです。
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が不明であることを意味しています。
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).
リンクのリンク状態アドバタイズメントだけ近端（広告を発信する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)
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.
以下に指定されるように特定のインターフェーススイッチング能力に応じて、インターフェーススイッチング能力記述は、付加的な情報を含むことができます。
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と考えられます。
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].
最小LSP帯域幅と最大LSP帯域幅のための典型的な値は、[GMPLS-SIG]に列挙されています。
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は、LSPの最小帯域幅と最大LSP帯域幅でによって定義された葉と枝のルートと、SDH階層の分岐によって許さ任意の帯域幅を予約することができ優先度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は、優先度pにおいて最小LSP帯域幅および最大LSP帯域幅の間の任意の帯域幅を予約することができ、LSPによって予約帯域幅が最小LSP帯域幅の倍数であることを条件とします。
The Interface MTU is the maximum size of a packet that can be transmitted on this interface without being fragmented.
インタフェースMTUは断片化されずに、このインターフェイス上で送信することができるパケットの最大サイズです。
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ペイロード内のチャネルを多重化または逆多重化することができることを意味します。
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をサポートしているかどうかの情報、及び最小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].
（バンドルされていない）単純なため、優先度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].
最小LSP帯域幅と最大LSP帯域幅のための典型的な値は、[GMPLS-SIG]に列挙されています。
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多重化を有する界面に、葉と枝のルートと、SDH階層の分岐によって許さ任意の帯域幅を予約することができ、優先度pにおけるLSPは、優先度pにおいて最小LSP帯域幅および最大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は、優先度pにおいて最小LSP帯域幅および最大LSP帯域幅の間の任意の帯域幅を予約することができ、LSPによって予約帯域幅が最小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つずつ宣伝されるだろう。インターフェースは、（SDH多重化ツリーの同じブランチの一部ではない）VC-11、VC-12をサポートしている場合、例えば、それは2つの記述子、それぞれに対して1つの広告を出すことができました。
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の確立をサポートすることができます。
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つのラムダに自分自身を制限することはできません。
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が、いくつかのインターフェイスのスイッチング機能をサポートすることができます。例えば、いくつかの他の出力光チャネルにこれらラムダのいずれかを相互接続することができるか、ラムダを終了ことができ、そして抽出（逆多重化）はラムダからデータLSRインタフェースで終端ラムダのセットを運ぶファイバリンクを考えますTDMを使用して、その後いくつかの発信TDMチャネルにこれらのTDMチャネルをクロスコネクト。これをサポートするためのリンク状態アドバタイズメントは、インタフェーススイッチング機能記述子のリストを運ぶことができます。
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つのパケットのLSRとの間のリンク[TDM、TDM] - 2つのデジタルクロスコネクトとの間のリンク[LSC、LSC] - 2つのOXC間のリンク[PSC、TDM] - パケットLSRとデジタルとの間のリンククロスコネクト[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
[PSC、PSC] - ラベルが "シム" ヘッダ[RFC3032] [TDM、TDM]で運ばれる - ラベルはTDMタイムスロットを表す[GMPLS-SONET、SDH] [LSC、LSC] - ラベルは、ラムダ[FSCを表しますFSC] - ラベルOXC [PSC、TDM]のポートを表す - ラベルはTDMタイムスロットを表す[GMPLS-SONET、SDH] [PSC、LSC] - ラベルラムダ[PSC、FSC]を表し、 - ラベルは、[ポートを表しますTDM、LSC] - ラベルは、ポートを表す[LSC、FSC] - - ラベルは、ラムダ[TDM、FSC]を表すラベルは、ポートを表します
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帯域幅（優先順位0で最大のLSP帯域幅がまだSTM-64）全てが、優先度0のため、もはやSTM-64であるが、STM-16という。その後、別のVC-3 LSPがある場合は、インタフェーススイッチング能力記述子に変更はありません。記述子は、もはや（この時点ではより144個のタイムスロットインターフェイス上のLSPによって取られることを意味する）インターフェースを介してVC-4-16c LSPを確立することができないノードまで同じままです。これが起こったら、記述子が再び変更され、変更記述子は、他のノードに通知されます。
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].
[IEEE]未予約帯域幅、最大LSPの帯域幅と最小のLSP帯域幅を識別するために使用され得る離散値のIEEE浮動小数点形式の符号化は[GMPLS-SIG]のセクション3.1.2に記載されています。
Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1
Encoding = SDH
Max LSP Bandwidth[p] = 2.5 Gbps, for all p
If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.
両端のようなインタフェースを有する複数のリンク一つTEリンクとして広告されるならば、リンクバンドリング技術が使用されるべきです。
Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1
Encoding = Ethernet 802.3
Max LSP Bandwidth[p] = 1.0 Gbps, for all p
If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.
両端のようなインタフェースを有する複数のリンク一つTEリンクとして広告されるならば、リンクバンドリング技術が使用されるべきです。
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最小LSP帯域幅= VC-3マックスLSP帯域幅[P]は全てのpのためのSTM-64 =
If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.
両端のようなインタフェースを有する複数のリンク一つTEリンクとして広告されるならば、リンクバンドリング技術が使用されるべきです。
3.4. STM-64 SDH Interface on a Digital Cross Connect with Two Types of SDH Multiplexing Hierarchy Supported
3.4. サポートされているSDH多重階層の2種類のデジタルクロスコネクトのSTM-64 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
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スイッチング：すべてのpについて= TDM [任意SDH]エンコード= SDH最小LSP帯域幅= VC-4マックスLSP帯域[P]はSTM-64 =、インターフェーススイッチング能力を
If multiple links with such interfaces at both ends were to be advertised as one TE link, link bundling techniques should be used.
両端のようなインタフェースを有する複数のリンク一つTEリンクとして広告されるならば、リンクバンドリング技術が使用されるべきです。
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.
（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上のインターフェイスに関係なく、それに対して外部DWDMがあるかどうかの、FSC常にLSCであり、かつありません。
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)
インターフェイスのスイッチング能力記述子：インタフェース機能を切り替え= SDHフレーマによって決定LSCエンコーディング= SDH予約可能帯域幅=（たとえば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.
この例では、DWDMとPXCはPXCの各インターフェイス（ポート）が1つだけの波長を処理するように接続されていることを前提としています。したがって、原理的には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）のインターフェイス
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.
この例では、DWDMとPXCはPXCの各インターフェイス（ポート）が1つだけの波長を処理するように接続されていることを前提としています。したがって、原理的にはPXCのインターフェイスが全体として複数の波長を切り替えたとしても、この特定の場合においてPXC上のインタフェースはFSC LSCとみなされず、。
_______
| |
/|___| |
| |___| PXC |
========| |___| |
| |___| |
\| |_______|
DWDM (transparent to bit-rate and framing)
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 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エンコード=ラムダ（フォトニック）予約可能帯域幅=
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 PXCs間におけるDWDMの不在は、インターフェースは一つの波長に限定されるものではないことを意味します。したがって、インタフェースは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つまたは複数のインターフェイスの基です。 （[GMPLS-SIG]の3.2.1.1を参照）所与PXC上のすべてのインターフェイスは、そのPXCに一意の識別子を有することが必要であり、これらの識別子は、ポートラベルとして使用されています。
Interface Switching Capability Descriptor: Interface Switching Capability = FSC Encoding = Lambda (photonic) Reservable Bandwidth = Determined by optical technology limits
インターフェーススイッチング能力光学技術の限界によって決定= FSCエンコーディング=ラムダ（フォトニック）予約可能帯域幅=能力ディスクリプタスイッチングインタフェース
Note that this example assumes that the PXC does not restrict each port to carry only one wavelength.
この例では、PXCが一つだけの波長を運ぶために各ポートを制限しないことを前提とすることに注意してください。
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]).
TEリンクは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)
DWDMにより決定能力= LSCエンコーディング= SDH（DWDMから来ている）最大LSPの帯域幅を=スイッチングインタフェース（STM-64と言います）
3.10. Interface on a OXC with Internal DWDM That Is Transparent to Bit-Rate and Framing
3.10. ビットレートおよびフレーミングに対して透明な内部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 (transparent to bit-rate and framing)
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]).
TEリンクは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 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エンコーディング=ラムダ光学技術の限界によって決定（フォトニック）最大LSP帯域幅=
There can be many combinations possible, some are described below.
多くの組み合わせの可能な存在でき、いくつかを以下に記載されています。
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.
論じたように、以前の、唯一の波長はPXCのポート上にある外部のDWDM限界が存在します。こうしたポートでは、接続PXC + TDMデバイスは、次のいずれかを行うことができます。 SDHインターフェイスとSDHチャネルを切り換えるように波長他のアウト結合光チャネル、または波長にPXC要素によって相互接続されていてもよいが終了してもよいです。
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種類のインタフェース記述子、TDM用LSCのための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
インターフェーススイッチング能力記述子：インタフェースはスイッチング能力= TDM [標準SDH]エンコード= SDH最小LSP帯域幅= VC-3マックスLSP帯域幅[P]は全てのpのためのSTM-64 =
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として前述の場合とほとんど同じ方法でアドバタイズされるであろう。
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.
論じたように、以前の、唯一の波長はPXCのポート上にある外部のDWDM限界が存在します。こうしたポートでは、接続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種類のインタフェース記述子、LSC用と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
全てのpのためのインターフェーススイッチング能力= PSC-1エンコーディング= SDHマックスLSP帯域[P] = 10 Gbpsの、：機能の記述子をスイッチングインタフェース
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クロスによって相互接続されています。
- 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機能は、単一のインタフェースとして扱われます。インタフェースは、適切なパラメータを使用して、2種類のインタフェース記述子、TDM用とPSCのために別のものを用いて説明します。例えば、
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最小LSP帯域幅= VC-3マックスLSP帯域幅[P]は全てのpのためのSTM-64 =
and
そして
Interface Switching Capability Descriptor: Interface Switching Capability = PSC-1 Encoding = SDH Max LSP Bandwidth[p] = 10 Gbps, for all p
全てのpのためのインターフェーススイッチング能力= PSC-1エンコーディング= SDHマックスLSP帯域[P] = 10 Gbpsの、：機能の記述子をスイッチングインタフェース
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、ジョナサンラング、志偉林、およびQuaizar Vohra著に感謝したいと思います。 「TEリンクの機能の表現」についてのテキストのためにあまりにもスティーブン供えに感謝します。
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]を実装します。
[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-SIG] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[GMPLS-SIG]バーガー、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]マニー、E.およびD. Papadimitriou、RFC 3946、2004年10月 "同期光ネットワーク（SONET）および同期デジタル階層（SDH）コントロールのための一般化マルチプロトコルラベルスイッチング（GMPLS）の拡張"。
[IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593- 7653-8).
[IEEE] IEEE、 "2進浮動小数点演算のための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.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（TE）"、RFC 4201、2005年10月。
[LMP] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[LMP]ラング、J.、エド。、 "リンク管理プロトコル（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は、RFC 4206、2005年10月、 "ラベルパス（LSP）の階層は、一般マルチプロトコルラベルは（GMPLS）トラフィックエンジニアリング（TE））の切り替えとスイッチ"。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[GMPLS-ISIS] Kompella, K., Ed. and Y. Rekhter, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.
[GMPLS-ISIS] Kompella、K.、エド。そして、Y. Rekhter、エド。、RFC 4205、2005年10月 "中間システム（IS-IS）一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで機能拡張への中間システム"。
[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]スミット、H.、およびT.李、 "トラフィックエンジニアリングのための中間システム（ISIS）拡張機能（TE）への中間システム"、RFC 3784、2004年6月。
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
アヤンバネルジーCalientネットワーク5853ルーフェラーリカリフォルニア州サンノゼ95138
Phone: +1.408.972.3645 EMail: abanerjee@calient.net
電話：+1.408.972.3645電子メール：abanerjee@calient.net
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
ジョン・ドレイクCalientネットワーク5853ルーフェラーリカリフォルニア州サンノゼ95138
Phone: (408) 972-3720 EMail: jdrake@calient.net
電話：（408）972-3720 Eメール：jdrake@calient.net
Greg Bernstein Ciena Corporation 10480 Ridgeview Court Cupertino, CA 94014
グレッグ・バーンスタインCienaの株式会社10480 Ridgeview裁判所クパチーノ、CA 94014
Phone: (408) 366-4713 EMail: greg@ciena.com
電話：（408）366-4713 Eメール：greg@ciena.com
Don Fedyk Nortel Networks Corp. 600 Technology Park Drive Billerica, MA 01821
ドン・ルブランノーテルネットワークス株式会社600テクノロジーパークドライブビレリカ、MA 01821
Phone: +1-978-288-4506 EMail: dwfedyk@nortelnetworks.com
電話：+ 1-978-288-4506 Eメール：dwfedyk@nortelnetworks.com
Eric Mannie Libre Exaministe
エリック・マニー無料Exaministe
EMail: eric_mannie@hotmail.com
メールアドレス：eric_mannie@hotmail.com
Debanjan Saha Tellium Optical Systems 2 Crescent Place P.O. Box 901 Ocean Port, NJ 07757
DebanjanサハTellium光学システム2クレセント置き私書箱ボックス901オーシャンポート、NJ 07757
Phone: (732) 923-4264 EMail: dsaha@tellium.com
電話：（732）923-4264 Eメール：dsaha@tellium.com
Vishal Sharma Metanoia, Inc. 335 Elan Village Lane, Unit 203 San Jose, CA 95134-2539
ヴィシャル・シャルマMetanoia、Inc.の335エラン村レーン、ユニット203サンノゼ、CA 95134から2539
Phone: +1 408-943-1794 EMail: v.sharma@ieee.org
電話：+1 408-943-1794電子メール：v.sharma@ieee.org
Debashis Basak AcceLight Networks, 70 Abele Rd, Bldg 1200 Bridgeville PA 15017
Debashishバスクesisielaitaネットワークス、70本のabeliロッド、牽引baladaga 1本の0 brijabhille脚15017
EMail: dbasak@accelight.com
メールアドレス：dbasak@accelight.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
ルー・バーガーMovazネットワークス株式会社7926ジョーンズ支店ドライブスイート615マクリーンVA、22102
EMail: lberger@movaz.com
メールアドレス：lberger@movaz.com
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
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機能のための基金は現在、インターネット協会によって提供されます。